Last week I sat in on the Training class we held here at the Boston office. I haven’t considered Ruby or Rails from the point of a greenhorn in a few years, and helping the students learn about both opened my eyes quite a bit to some aspects of our language and framework of choice here at thoughtbot.
Ruby is natural, not simple
This is paraphrased one of my now favorite Matz
quotes. Watching others learn about Ruby
for the first time was a lot of fun, because usually they were astounded to find
out that what they used to do was just so…simple. Of course, under the hood,
Ruby is exactly the opposite, but that’s the beauty of it. Scott
Hanselman explains it best by showing a great
example
of using Ruby DSLs such as 20.minutes.ago instead of the more verbose Java
equivalent new Date(new Date().getTime() - 20 * 60 * 1000). He ends up
concluding:
That was a perfect way to describe ____, and there’s no ambiguity.
This aspect of Ruby has stuck with me since I first tried to dive through the
Pickaxe. However, it didn’t really
work out that nicely: I learned Rails first, and Ruby along the way. Having a
basic understanding of Ruby, especially with how blocks and the yield keyword
works can go a long way. The best part is that given a bottom-up approach, it’s
easy to see how the expressiveness of Ruby fits perfectly into Rails.
Rails isn’t full of black magic
Without a good understanding of Ruby, it’s easy to think that this is the case.
ActiveRecord can seem like a bag of tricks dumped on top of your precious
database, and don’t even get me started with some of the ActionView helpers. One
of the best parts of the training was when we hooked up a form, and used
error_messages_for to show the validation errors. Watching the students’ eyes
light up with understanding how that all came together was fantastic, but it did
seem like witchcraft to a few.
Granted, there is a lot of metaprogramming going on in Rails, but I feel the more Ruby one understands, the less magical it seems. Learning Ruby first is the best way to go, especially since it allows one to dive easily into the latest and greatest projects, such as Cucumber or Sinatra.
Someone’s already done this before
Convention over
configuration here
is key: not having to understand some cryptic XML file to set up your database or the application as a whole
is a huge win. Using pure Ruby for
migrations is just one example of how
Rails makes web development easier. Staying on the golden path is a huge part of
Rails, and you can usually bet that someone has solved the problem you’re facing
before. Looking for the solution inside the framework or outside for a
well-tested and maintained plugin before you steam ahead with your own
implementation is always a smart idea. I definitely have been to blame for this:
I began writing my own Prototype implementation of periodically_call_remote
before getting called out on it.
One of the big lessons that I took away from training was that we really do depend on the community for most of our tools: Capistrano, Git, Prawn …the list goes on and on. If you’re not looking to community for your solutions in the Ruby world or are not aware of what’s available, you’re missing out. Keeping in touch with what’s new is tough, but luckily there’s a few sites that make it really easy for you to do so.
Overall, training was a lot of fun. Over the course of three days we went from playing around with Ruby objects in irb, whipping together a simple Rails site, to deploying it live on Heroku. Going back to the basics was definitely eye opening, and it was a good reminder that I should trudge through the Pickaxe for Ruby 1.9 as soon as possible.
