This post originated from an RSS feed registered with Ruby Buzz
by Obie Fernandez.
Original Post: Rails Enterprise Case Study
Feed Title: Obie On Rails (Has It Been 9 Years Already?)
Feed URL: http://jroller.com/obie/feed/entries/rss
Feed Description: Obie Fernandez talks about life as a technologist, mostly as ramblings about software development and consulting. Nowadays it's pretty much all about Ruby and Ruby on Rails.
Found this case study description today written by a team that is converting a large health-care application: Moving from Java to Ruby on Rails for the CenterNet Rewrite. Interesting information in there, including the following comments on productivity...
Preliminary tests by our Technical Lead put the code reduction for a normal module in our Java stack converted to Rails at roughly 20:1. Rails uses the dynamicity of Ruby to extreme advantage and produces 4GL-like effects without resorting to code generation techniques (which suffer from inflexibility post-generation). The reported productivity increases point as well to underreported problems in the industry: web development as a whole likely lags application development productivity significantly due to the relative youth of the paradigm (stateless, distributed, thin-client applications); and the Java development model for web applications is additionally verbose and needlessly complex.
On code conversion...
Of the coding which has been undertaken to date some portions can be kept under a platform switch, while other portions would be discarded. SQL scripts, conversion scripts, test data would all remain the same. Hibernate mapping files would be discarded, with very little effort required to duplicate their functionality in Active Record?at a great savings in mapping elimination, and significant decoupling. Java code generated from Hibernate mappings would be discarded, but replaced trivially in the same terse Active Record model objects which replaced the Hibernate mappings above. EJB code, which is small in quantity would be replaced with Ruby business objects which should be even more terse?the API design work would still be of value here. The Struts controller/action/view code would be discarded, with JSP templates being converted over to the more terse rhtml templates and partials (and layouts) that Rails uses. This would result in up-front loss of effort, sinking additional effort into realizing those views/controllers/actions in Rails. Bringing our Struts code up to full functionality using AJAX appears to this author to require at least as much effort as converting the view and controller implementation to Rails (ignoring retraining effort which is hard to quantify currently). The Rails view-controller code is more decoupled, more terse, and more reusable than its Struts equivalent.
Previous Topic
