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.
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.
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.
Free DevOps eBooks, Videos, and more!
Regardless of where you are in your DevOps process, Linux Journal can help!
We offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, and advice & help from the expert sources like:
- Linux Journal