I’d been away from Ruby on Rails for a while. There were several reasons for that but I was asked for help on a project that would be best done in Rails in my opinion and I took the opportunity to catch up with the new and noteworthy changes in the Rails world.

The application was a simple web application with end user facing content and online sales of a couple of services. First and foremost the reason I’ve chosen Rails was that I was 100% sure specs would be changing along the way, and that would make a good case for Ruby and Rails. I wasn’t wrong. It all went according to the plan of expecting the unexpected and both Ruby and Rails served well. The reason for writing this post however is to compare my ancient Rails experience with the current set of Rails arsenal.

First and foremost, I must say it took a while to get adjusted to using only the text editor and no IDE. Boy how lazy we’ve grown to be with all the code completion and auto import stuff. But after a day I was typing code with 10 fingers (again).

Rack Middleware

Rails now is at version 3.2 and preparing to get to 4.0 milestone. I’ve seen there have been a lot of changes. One of the most significant changes and development actually is the middleware architecture called Rack. Rack goes beyond Rails and also enables other frameworks like Sinatra to share the same set of interaction with the web server. That is really a move forward. I was impressed to see how much the Rack middleware accomplishes with *so-many-little-number-of-lines-of-code*. Even if you don’t like Rails you must admit how productive and self explanatory the configuration files are. That’s what I call “DSL’s done right”.

Bundler way of dependency management

Dependency management is hell and Rails was no exception. But the solution seems to be pretty effective. Bundler helps you manage your gems, which are the packages of software that is managed centrally on your system like cpan packages of perl. Bundler, as the name implies, bundles the requirements of your project and localizes them for you. So your project becomes a self contained package and deployment becomes easy.

Client side goodies

It’s not an uncommon practice for java frameworks to leave the developers out in the dark for client side of things. Throw in some server side code and tell the developer that he/she can use whatever ajax library he/she likes. That’s bullshit. Rails does not do that. The asset pipeline is carefully engineered. Coffeescript is default, and you can generate javascript actions in server responses. When writing views, you don’t feel that you’re in another world.

Gems are valuable

The dynamic nature of Ruby enables development of pieces of software that fit like a glove to te existing code. For example, consider this. At some point of the project, client asked that they need to see who changed what in the data. Sounds like a fundamental requirement that should have been in place at design time right? No worries. Especially for generic requirements there are tons of gems smal to large that save the day.

Query API

Rails uses dynamic method building extensively. For example you can do things like Order.find_by_product_and_quantity(….) … But interestingly I’ve seen that they have moved a bit away from dynamic methods in favor of builder pattern, e.g. Order.where(…).and().where(…).sort() … While the builder like interfaces are almost the only option in java, some projects have picked up the idea. Spring Data is a good example of that. In spring data, you declare an interface and through code generation, declared methods got implemented in concrete classes. This is a hard or at least a tedious task to do in Java. Nevertheless I’ve never liked dynamic finders except for very trivial tasks. I like the builder style much more.


Rails provides an invaluable console. Although it has always been there, I just want to reiterate the importance of it. At the command prompt you can interact with the domain of your application and do whatever is needed in very short time, including instantiating your model objects and interacting with actual data.

Background Tasks

This has been the weak part of Rails when I left it. But it seems like a load of options have arisen since then. among lots of choices, I found Resque to be very handy. It’s a redis backed queuing and background task processing system. I was up and running in minutes.

All the other good stuff

In addition there are many improvements in testing, specifications, application deployment and production environments. I’ll not go into detail in each of these.

I loved doing a project in Rails again and I’m looking forward to do it again. However that does not replace Java for my daily cpu intensive backend system software development purposes.