Learning Ruby, and telling the layers apart

Ruby is a small language with a large standard library and a reputation for being pleasant to read, and most people meet it through Rails rather than on its own. That order of arrival shapes everything about learning it: a great deal of what a newcomer first encounters is not Ruby at all but a framework’s conventions written in Ruby, and telling the two apart is most of the early difficulty.

The language, briefly

Everything is an object, including numbers and nil. Blocks are passed to methods routinely rather than exceptionally, which is why so much Ruby reads as a sentence with an indented clause. Classes are open, so behaviour can be added to types that were defined elsewhere. And a great deal of the standard library is built on a small number of methods that appear everywhere once recognised.

What surprises people arriving from elsewhere: the absence of ceremony. There is no required class wrapper, no compilation step, and a file with one line in it runs. That is pleasant and it removes the scaffolding that in other languages tells a newcomer where they are.

The order that causes the least trouble

Enough of the language to read it, then a framework, then back to the language properly. Trying to learn all of Ruby before touching Rails is a common plan that rarely survives contact with wanting to build something, and going straight to Rails without any of the language produces the layer confusion the chart describes.

The practical marker for “enough”: being able to read a method and say what it returns without running it. Blocks, hashes, arrays and the common enumerable methods cover most of it, and that is days rather than months.

Enough of the language to read it. Not enough to have finished it.

Where newcomers most often get stuck

Three places, and none of them is syntax.

The environment. Version managers, native extensions that fail to build, and a project that works on somebody else’s machine. This has nothing to do with programming and consumes a disproportionate share of early time, which is covered on gems and Bundler.

Magic. Behaviour that appears from nowhere because a framework generated it. The fix is not to avoid frameworks but to learn where to look, which is usually a matter of knowing that the method exists somewhere and finding out where.

The layer question. Something breaks and it is unclear whether the language, a gem or the framework is responsible. Getting good at that one question makes almost everything else faster, and it is the skill the chart above is really about.

Reading other people’s code

The most underrated way to learn Ruby is to read a small, well-maintained gem end to end. Gems are usually a few hundred lines, they are written by people who cared, and they use the language rather than a framework’s conventions, which makes them the clearest available demonstration of what plain Ruby looks like.

The second is to read the tests. A test suite is an executable description of what something is supposed to do, and for anybody trying to work out what a library is for it is frequently a better document than the documentation. That habit connects to testing, which is where a great deal of Ruby’s culture lives.

Where a conference fits

Badly, as a way to learn a language, and very well as a way to find out what is worth learning next. Nobody learns Ruby in forty minutes. What a talk does is show a problem somebody had and how they thought about it, which is the part that is hard to get from documentation.

For somebody early on, the useful sessions are the ones nearest to work already in hand, which is the argument on beginner tracks, and the useful part of the day is frequently not a session at all: see the hallway track.

The language itself is covered properly in the next section: Ruby and Rails, with a learning path, the release timeline and Rails. What a first event looks like from the inside is on a first conference.

Questions