Internbot Chronicles #5: Training Reflections

Nick Quaranto

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.