Tuesday, December 9, 2008

The Prodigal Developer Returns to Rails

It has been two days since I posted an article on auditing data modifications using the Zend Framework. I have recently published a number of other articles on Zend in general. I noticed a recurring statement that forced me to rethink the pursuit of using alternative frameworks for openEPRS:

"X is easier with Ruby on Rails than it is with (insert language and/or framework)"

When I started openEPRS in 2007, Ruby on Rails was the chosen platform. I liked it because it was easy to learn, concise and held close DRY development principles. It really is an amazing framework, one that is truly a disruptive platform.

Java and ExtJS

Being a Java developer by trade, I became intrigued with the first releases of Java RESTful Web Services (JSR-311). At that time I also started experimenting with ExtJS as a user interface for openEPRS.  By the end of 2007 I had become increasing frustrated with amount of time spent on managing converter, resource and data classes that come with using Jersey.  ExtJS also seemed to be in a state of flux with a flurry of license changes.

Analysis: high effort and maintenance


There is not a lot to say on the subject of Mono. I tried to develop a basic application framework using ASP.NET. Monodevelop is a non-starter as an IDE, broken functionality and a lack of action from the developer community on reported bugs.

Analysis: valiant effort with a lot of missing functionality

PHP and the Zend Framework

I turned my attention to the Zend Framework in the Fall of 2008.  I thought that this approach would provide an environment similar to Ruby on Rails with the added benefit of a widespread deployment platform that is PHP. I was quickly disappointed as I found that it was much more difficult to implement a basic starter application in Zend than it was with RoR. Unit testing, security and build control while available, required a lot of experimentation to make it work as expected.  Honestly I was not that impressed with the quality of much of the code.  In particular Phing was a major source of frustration requiring a number of patches to get it working correctly.

Analysis: awkward language with the framework having a higher degree of difficulty than necessary.


A major reason for exploring alternatives to RoR was the issue of scalability. When I started using RoR, a lot of concern was raised as to the scalability of the framework. I knew that Java could scale and the same could be said of PHP. With the advent of projects like Rubinius, I am not as concerned with this as much as I was in the past.

Final Thoughts

openEPRS development will go forward on the original platform of choice.  I will be dusting off my old Rails code, updating it to version 2.0 of the framework. Straying off the path has not been all bad.  I believe it makes my decision to use Rails an informed one. At the very least I cannot be accused of being zealot as I have put in quite a bit of effort with the alternatives. I know this article does not provide a detailed analysis; however, other articles on this site make the case. Its good to be back!