At the Forge - Ruby on Rails 3

I still remember an IM conversation I had with a friend several years ago. He asked whether I'd heard of Ruby on Rails, and I replied that although I'd heard of it, I hadn't yet gotten the chance to work with it. Several months later, I had such an opportunity, and it wasn't long before I was hooked on both the Ruby language and the Rails framework.

It turns out that I wasn't the only one to be so smitten with Rails. During the past few years, Rails has changed the face of Web development. It has attracted many people (including myself) to the Ruby language, while also affecting, influencing and inspiring Web development frameworks in other languages.

When people ask why I like to work in Rails, I tell them there's no one answer, because I don't believe any one part of Rails is revolutionary. Rather, the developers have found hundreds, and perhaps thousands, of things that were traditionally difficult or annoying in other Web frameworks and have tried to sand down those sharp edges. For example, database migrations, which let you define and create your database schema in pieces, building it up over time, have saved me enormous headaches. The same is true for Active Record's automatic getter and setter methods for columns in the database. And for controller filters—the list goes on and on.

So, I have approached the development of Rails 3, which was released late last year, with some trepidation. After all, most things in Rails 2 worked well enough for me—why mess with a good thing? Besides, the merger with the development of Merb, a competing Web framework written in Ruby, didn't strike me as a particularly necessary thing. True, Merb was more open to alternative ORM, HTML and JavaScript libraries, but it wasn't too terribly painful to use such alternatives in Rails. Did we really need a major overhaul just to enjoy those benefits?

The answer, I'm happy to say, is that it was, indeed, worthwhile. Ruby on Rails 3 hasn't changed too much from its predecessor; it still looks, feels and acts like the Rails we know and love. Most changes are small and subtle, but where they aren't, you can understand the reasoning behind them and quickly adjust to the changes. I've been surprised to discover just how easily I've adjusted to the Rails 3 way of doing things.

This month, I give a whirlwind tour of Ruby on Rails 3. I describe where things have changed a lot, where they've changed a little, and where they haven't changed at all—at least, for a developer using it. Under the hood, Rails has changed quite a lot, adding a number of new classes, modules and abstractions that have made it into a more modular framework than it was before. This means if you want to implement a new database-storage adapter, for example, Rails 3 will provide you with tools to make its implementation and integration fairly easy.

Before I go into what has changed in Rails 3, it's probably worth saying what's remained the same. First, Rails remains true to the model-view-controller (MVC) paradigm, with an emphasis on “fat” models—that is, the classes you define using models should contain the bulk of the business logic, as well as acting as an ORM and connection to the database. Controllers remain in the role as a go-between, accepting connections from the user and rendering the output in whatever format is appropriate. Views contain a combination of HTML and logic (with as little code as possible) that allow you to display everything from personalized menus and buddy lists, to XML and even PDF output.

Other classic areas of Rails, designed to support your main MVC design, also remain. Helpers, methods that allow you to remove code from your views, are still there. So is the lib directory, into which you can (and should) still put custom classes and modules, including those that will be used by multiple controllers or models. The public directory continues to be the repository for static assets, from JavaScript and CSS files to images and Flash that can be served up as-is.

Rails 3 certainly is more open to alternatives than was previously the case. When you create an application, you can specify that you want to remove Active Record, Prototype and/or test-unit if you prefer to use something else in their place. But these are options, and it means that for programmers who want to use the same systems they used in Rails 2, no changes will be necessary.

Although I haven't personally benchmarked the performance of Rails 3 in comparison with Rails 2, there's no doubt that it feels faster than Rails 2. This is especially true if you run Rails 3 with Ruby 1.9.2, the latest version of the language significantly faster than Ruby 1.8.7 in many respects. A great deal of attention has been spent on making Rails 3 more modular and much faster than Rails 2, and it shows.