Beyond Java - Bruce Tate [64]
The Numbers Game
As a fairly content Java programmer, I really didn't go searching for an alternative. In some ways, Rails found me. Dave Thomas and I speak at the same conference. I taught several sessions on the Spring framework with Hibernate, and I was very happy with my productivity. Of course, compared with EJB, I was very productive. Dave pointed out that even in Hibernate with Spring, you tend to repeat yourself on a fairly regular basis.
I reflected on David's comments. To make a persistent domain model, you need to specify a database table with its fields and indexes, specify an object domain model with a class (repeating yourself) and a field as an attribute (repeating yourself), and add accessors for that field (repeating again and again). Then, you need to build a mapping with the database table (repeating again) and the class name (and yet again). Finally, your mapping must specify each database column and the corresponding database field (repeating each column twice more). Of course, most sane Java developers do not do all of that repeating. They let the tools do most of it for them, but now your programming model dictates your tool set, your development experience, and generates more lines of code to maintain. I came to the conclusion that ORM makes sense when the domain model and object model are sufficiently different, and I decided I'd take the slight productivity hit and be compensated with better performance and the possibilities of better mapping.
A Blinding Flash of Insight
As I've said, I worked with a company that builds safety software for a manufacturing plant. We effectively build a web user interface to manage a complex domain model. We decided to build this application with a lightweight Java stack of Spring, Hibernate, and Web Work. We moved pretty quickly, and were pleased with our progress. We were proud of our accomplishments, because we'd rewritten a one-year Microsoft application in four months with Java. Naturally, as we accumulated a bigger code base, coding began to take longer.
Over time, Dave's arguments nagged at my subconscious. Dave and my business partner had the same conversations. As luck would have it, over the same week, we tried building a part of the application in Rails. I banged out the model and scaffolding in a couple of days. With his stronger HTML experience, Justin got further than I did. He actually implemented the whole application in Rails in four nights. The Rails version shocked us in another way—it was actually faster!
Justin Gehtland: A Ruby on Rails Case Study
Coauthor of Better, Faster, Lighter Java
Justin Gehtland is the co-founder of Relevance, a consulting/training organization based in Durham, North Carolina. He's the coauthor of the Jolt-winning book, Better, Faster, Lighter Java, and has been developing applications of all sizes since the early 1990s. Over the last six years, he has delivered products using Java, .NET, LAMP, and now, Ruby on Rails.
You've recently moved a Java project to Ruby on Rails. What Java frameworks did the application use?
JG: The original stack was the usual suspects in the lightweight movement: Spring and Hibernate, plus a little JSTL on the frontend (so that the end customers could more easily customize the interface). I was using the ACEGI security framework for authentication and authorization, but only to authenticate against a local database of accounts.
What surprised you the most about the experience?
JG: After porting the app and talking about the experience, I was really surprised by the heated discussion it generated. There's that old saw about disruptive technologies; if the temperature gauge on the discussion is any indication, Rails is clearly in the disruptive category.
From a technology perspective, I was surprised at the level