Choice Is Good

Thursday, December 13th, 2007

I was happy to note that Dion Almaer commented on my blog post on Merb. Dion is one of my favorite bloggers/podcasters and I value what he writes highly.

But I disagree with him on this one. The problem with using Java for web application development was never one of too much choice. In fact, it was because of that choice that Java became a player in the server side market at all. Sun alone never had the answer to what was needed for server side development, instead the open source world stepped in and made incremental corrections.

The same thing is happening to the Rails world. The core team cannot create a framework that is a one-size-fits-all. The initial Rails proposal is great for a large number of webapps, but it is other things around it like plugins and JRuby that is making Rails a viable choice for all.

My Java tools of choice was usually Tomcat/Jetty, FreeMarker, iBatis, WebWork tied together with Spring or PicoContainer. What I hated was having some frankensteinian-enterprise-architect-design-by-comittee-lets-not-be-different stack forced upon me with a fullblown J2EE server, EJB’s, Struts or the JSF monster, sprinkled with an Eclipse-only development environment. And I hope dearly that Rails development is not going the same way where people question you on your choice of tools and wonder why you are not using MySQL and TextMate like the rest.

There is one choice that I do not miss though - directory layout. I am truly happy every time I do not have to choose it.

Instead of not having to choose, the most important difference I’ve experienced is that Java as a language together with the Servlet/J2EE spec induces a lot of accidental complexity, which is almost non-existent in the Ruby/Rails world. It is that which enables the increased velocity many development teams experience when switching to Ruby.

How to best develop half of a web application?

Friday, August 26th, 2005

At work, the task at hand is extending an existing J2EE based product. This means that half of the .war that is to be deployed is hands-off, and the other half is written by us.

The problem I am having is how to get a productive environment. Unfortunately the products file organization is a mess, so there is no way to have a version checked into the version control system as it never would survive an upgrade. Also the deployed app needs to be initialized with a lot of data that is - surprise - saved both in a database and on the filesystem, meaning no easy test db setup.

The developers who have been in the project for a while have used an army of symbolic links to connect the dots, probably inspired by the products overgenerous use of such. But I am not content with what I’ve seen, but I cant really point my finger at what to do. Anyone who has done anything similar?