A few days ago, Ryan came to my desk and asked me if I knew anything about Rails. In response, I laughed.
You see, only a few hours earlier I had come to the conclusion that I could not ignore Rails any longer. I have long had Rails on my list of things to look into, but after being slapped in the face almost hourly with other people blogging about Rails, I had to bump it up a bit. It seems that Ryan came to the same conclusion at almost the same time...thus the reason I laughed.
I've spent a few hours over the past few days tinkering with Rails. I was met with several levels of frustration, but mostly in the setup of my environment (missing iconv on Windows, needing to manually install gems on MacOS X, etc). Once my environment was setup, however, I was able to quickly recreate the somewhat famous Cookbook example from Curt Hibbs' article on Rails.
Honestly, I'm quite impressed. I found that the productivity claims surrounding Rails to be quite accurate. After writing only a single line of code, I had a reasonably functional application. Adding a couple of more lines, I had a one-to-many relationship between two model objects. The biggest chunk of work comes in customizing the view, but that's to be expected because there's no way that Rails can anticipate your desired look-and-feel. All in all, I spent 15 minutes putting together a simple application that might have taken me several hours with any of the other frameworks that I'm familiar with.
If you haven't tried Rails yet and you're like me, you're reading the last paragraph in disbelief. How can you write a functional application in only 3 lines of code (plus some HTML/Ruby for the view)? I know...it sounds crazy. But it's true. Here's how it works:
First, Rails is made up of two pieces: A set of scripts that automatically generate code for you and a framework under which your application runs. This is a case of extreme code generation. There's probably thousands of lines of code behind my application, but I only wrote 3 of them.
Second, Rails has a philosophy of "convention not configuration". Unlike other frameworks where you write several lines of XML configuration, I only had to configure enough of Rails to tell it how to get to my database. Instead of configuring every little thing that Rails does, Rails asks you to follow some simple conventions that help it to find what it needs. (For those of you keeping score, this is much of the same philosophy behind Maven.)
The jury's still out on whether the productivity gains extend to a much larger, real-world application. But I can see how Rails eliminates a lot of repetitive grunt work and can likely have a positive impact on productivity even with larger projects.
The biggest challenge for me is my lack of Ruby understanding. I own PickAxe II (required reading for anyone wanting to program in Ruby) and have read much of it. But I live in a Java world most of the time and so I don't get as much opportunity to exercise my Ruby knowledge as I'd like. But now that I've found Rails, maybe I'll make some time to become well-versed in Ruby.
