Do It Right
At the core of the mission statement of the firm Antistar Consulting is the mantra, “We like to do it what we call the ‘right way.’”
Too many times a project goes unscoped, unplanned, undocumented, and ends up near-unusable mess of bloated spaghetti code.
In my 10-year career I’ve had to fix such sites and have been extorted (because of time factors) into creating them as well.
In the long term this has been proven over and over to very simply not work.
Adhering to standards, observing programming methodologies, and organizing and separating the project into modular parts makes for less errors and specialized component development which can be done in or out of house.
With two years of experience coding Java in a fast-pace, start-up environment, and having been exposed in that time to multiple “Enterprise” technologies, chiefly the JavaEE suite of tools, Java is an obvious choice for rapid web development.
Java has the behemoth Oracle and a handful of other large supporting companies behind it, documented standards and APIs, thousands of users, thousands of resources.
Assume a simple project, one in which the standard fare of websites exists: a few information pages, login authentication, credit card charging.
To implement the above in Java, the following must be configured, their framework learned and tested, and then deployed remotely: JPA, Mule (ESB), JSF, and JBoss.
The project was originally bid with the above in mind, however, the actual setup and testing time alone far exceeded reasonable estimations.
Setting up, configuring JPA, and testing JPA, for example, alone, took more time than the sum of estimation of the entire project.
Finally setup, configured, and locally tested, initial deployment of the code was unsuccessful, resulting, ultimately, in a mysterious out-of-memory error which required (a) an upgrade of hosting services– out of the question; (b) tweak the configuration settings, or (c) switch application servers.
It wold seem that a JavaEE implementation is far better employed in a very large setting, where there are hundreds of different types of developers, deep pockets, and unlimited access to resources.
The above site is simply too small. Implementing JavaEE and Mule is like killing ants with nuclear missiles.
After coming so far in the development process but being blocked such trifles, having far exceed estimates to the point that billing said hours would be immoral and ridiculous, the JavaEE framework and all labor spent to produce it must be thrown out.
Your Neighborhood PHP/ASP Programmer
Sure, I’ve been programming straight HTML and basic PHP and ASP for years, however, the simplicity of inline scripting doesn’t, by default, lend itself to any sort of methodology.
Time and time again what usually ends up happening is a thrown-together site that becomes more and more confusing, monolithic, buggy, and ultimately getting re-written.
A Viable Solution
PHP or– god forbid– ASP still remain 100% viable solutions precisely because of this simplicity. The site map is simple, the data can easily be directly SQL injected, session maintenance is a breeze, and it’s easy to modify the presentation layer.
Embedding your script in your HTML files is so 1990s and we absolutely, positively don’t do this anymore. If anyone does they’re about 20 years behind and haven’t heard of a little thing called Web 3.0 (yep, we’re there already).
Instead, the trend is APIs and frameworks, and a handful exist for every language. JavaEE falls under this category for Java, Zend or Cake for PHP or at the very least Smarty (which may or may not still exist), Django for Python, and Rails for Ruby.
There is also the matter of self-interest. Antistar Consulting does promote the use of PHP/ASP for simple and cost-effective sites, however, remains neutral as to their usage and implementation.
Antistar Consulting is an SoA firm and as such uses and associates with the appropriate enterprise technologies, chiefly Java and .NET. So far, PHP does not demonstrably present a strong argument for its usage in an SaaS model.
PHP is and will remain a “last resort” solution. The deadline for the project is fast approaching, however, there are still literally weeks of testing that can (and should) be done to ensure the best choice of platforms.
Compromise and Proposition
The company proposes to research the following frameworks: Django and Ruby on Rails.
If, upon reasonable and basic MVC tests, observing factors such as (1) ease of implementation, (2) prevalence of documentation and examples, (3) speed of development, a suitable framework cannot be found, PHP will be implemented, the project finished and closed, and the company’s policy revised to exclusively use PHP for small projects.