Riding the Rails Train

A few weeks back I decided to bite the bullet and get on the Rails Train. Complete confusion was my first thought upon reading through a few Rails tutorials. There is no end to the number of articles about Rails on the web (now there is one more!) and I was feeling a little lost trying to determine where to start. So I figured I'd start with the basics and began reading about Ruby (created by Matz in Japan), the base language of Ruby on Rails.

I purchased Ruby by Oreilly and read through it diligently, computer always at the ready to test out examples from the tome. Ruby takes a little while to get your head around, especially if you are a closet, wannabe coder n00b like myself. For example, I was used to iterative loops such as (for PHP):

for($i=0; $i > myCollectionOfThings.len(); $i++) { prints myCollectionOfThings[$i] }

What the heck are blocks? Yield? Bah! Needless to say, it took a few days to get used to.

So now with just enough Ruby under my belt to make me dangerous, I moved on to Rails. I started with the basics again, reading through each section of the Ruby on Rails website. I was thrust into a land of migrations, YAML, DRYing, REST, MVC (model, view, controller), routing, and other magical concepts.

As I pushed forward from topic to topic, making progress here, hitting a wall there, it started to make sense why the Rails logo-of-choice is a train. I started to feel like a coding conductor, all my objects easily aboard my locomotive, quickly eating up the track and rushing towards project creation (wow, that was possibly the nerdiest thing I've said in a long, long while). I remember being amazing, even feeling a little sorry for myself for not getting aboard sooner! I started to see projects written in other languages would take immensely longer to develop, and worse, would not be as elegant, well organized, and easily shared. The MVC framework and "Convention Over Configuration" principle guide Rails developers, from the newbies to the veterans, on how a basic web-app is structured, how to use as little code as is efficiently and "readibly" possible, and what goes where.

The train metaphor was also driven home recently when I was trying to deploy an app on a remote server. I felt like I was in the middle of a train wreck. As wonderful and beautiful as Rails is, it is also a complicated organism with a lot of deep, moving parts. Rolling out an application has even more layers to it and computers don't really do "hey, you *almost* got the configuration right", but rather just crash.

But after spending about and hour or two tracking down my issue and debugging (more to come on this via another post), I pulled myself from the twisted metal and wreckage, relieved and happy again. Rails does a great job of telling you where it is getting tripped up so you can Sherlock Holms your way out of it (the issue ended up being an outdated gem the hosting service was forcing me to unknowingly use, rather than my nice, shiny, up-to-date ones). Using a different technology likely would have taken me several times longer.

Gems bring another element to Rails that really should make anyone thinking about getting into Rails jump on in. The iPhone is the beautiful gadget, but the apps put it head and shoulders above the rest. Same with Rails. There is a vibrant, talented, and witty group of developers that contribute amazing add-ons to a Rails application ("There's a gem for that" anyone?).

It really amazes me how abstracted web development has become. A year or two ago I was writing straight HTML, crafting SQL statements, writing login scripts, and the like. Now its all HAML, find_by_this's, acts_as_auth, etc. While I initially felt a bit disconnected by this, the benefits it brings are immense: less time worrying about stuff that has been done and tested a thousand times leaves more time to build a better service and be a better developer.

Tweet