You’ve made it mostway through your free Ruby on Rails Internals class. Today we’ll be poking around the Rails source code. If you have money but not time, Rebuilding Rails lets you find a lot quickly… But in case you have more time, we’ll see where in the Rails source you can learn the same things for yourself.
First off, Rails has a combination of terse, pithy code (easy to read!) and good, solid tests which help explain what a given piece of code does. I recommend switching back and forth between implementation and tests often when reading.
Head to Rails on GitHub. My screenshots are branch 3.2-stable, or you can look at latest. You can already see the division into gems with the various directories: actionmailer, actionpack, activemodel, activerecord, activeresource and activesupport.
You can see the controller and view code in “actionpack” (note: actionview has been extracted in Rails 4). Rebuilding Rails has an easy simplified version, but you can see the real thing in there with some work. Inside actionpack/lib are subdirectories like action_controller which provide a great start for a deep dive.
Later chapters of Rebuilding Rails talk a lot about Rack, including Rack Middleware. For that, you should look at http://github.com/rack/rack instead of Rails. Luckily, most of the Rack code you care about is quite short. Unluckily, it’s poorly documented. Again, make sure to read tests (where they exist) for best understanding. I don’t know another introduction as good as Chapter 8 of Rebuilding Rails, but you can get some of the same content from a my Ruby Hangout interview on Rack frameworks.
Rails also depends on a number of other libraries. It’s hard to understand ActiveRecord without Arel, for instance. Read through the .gemspec files when you want to know what Rails depends on. That’s also great when thinking, “huh, what else should I add to my own framework?” If you don’t know what a gem does, Google something like “arel gem” or “tzinfo gem” or “ruby mail gem”. You can also check out rubygems.org to track down info and documentation if you know its name.
In general, look at dependencies like Gemfile and .gemspec files for every library you look at. You can learn a lot about any library from what gems it uses.
Get the Code Locally
GitHub is a nice interface and all, but it’s no substitute for having the code locally where you can use it. Make sure to clone the code for the things you care about, and “bundle install” the dependencies you won’t be drilling into yet. If you use a Ruby IDE like RubyMine that may help. We’ll talk about what I use for exploration in the next lesson.
And Now, a Word From…
Incidentally – if you prefer the guided tour, considering buying Rebuilding Rails for your workplace. Companies pay more for your time than just your salary — Rebuilding Rails is probably a good investment if it saves you just half an hour.
Will it, though? Start with the free chapters, and see if anything in there could save you ten minutes. Or just buy it, and if you’re not delighted, I’ll refund your money.