Some of the patterns rely on idiosyncratic Ruby syntax, but most can apply in any programming language.

The One Page Notes

I find that illustrated mind maps help me organize and engage with the information in technical books. I have shared a few with you before, but they tend to look more first-drafty than this one does. That’s because they’ve all been first drafts…until now.

This one I redrew a second time after I finished the book. Since the information falls neatly into a variety of useful categories, it lent itself uncommonly well to a big picture representation like this.

As you’ll quickly discover, the map is no substitute for reading the book. That said, I’ve added a couple of affordances to help you find what you’re looking for inside the book itself.

Each collection of categories has its own color highlight—these are green, yellow, and orange.

I have drawn arrows to indicate concepts that connect to one another despite appearing in different parts of the book.

I have indicated which parts of the map are me editorializing on what I’ve read—you won’t necessarily find these things in the text itself.

Any pattern or step that relies on specific ruby syntax has a ruby icon next to it. If you’re not writing in ruby, though, your language of choice may have an equivalent.

Each pattern also has a page number next to it so you can find that pattern in the book.

So, rather than a summary or a reading guide, think of this one-page notes as a categorized index of the patterns in the book, with a header that explores the overall structure of the code we’re trying to write. If you’ve read the book, the notes can provide a helpful reminder of the ideas it covers.

The Book Itself

Avdi clearly put a lot of thought into the organization of this book. It starts with a story about his experience losing—then rediscovering—the joy of writing ruby (Chapter 1).

The book then discusses offers a step-by-step process for determining all the things a method is meant to do so we can handle each piece in turn (Chapter 2).

Once we’ve covered that general framework, we get into patterns. The largest number of patterns appear under the category ‘Collecting Input.’ Avdi starts with the smallest-scope patterns: one line changes, for example. The scope increases as the patterns continue, up to the level of changing a method definition and, finally, to considering whether our current object’s responsibilities should be divided among several objects (Chapter 3).

After the book discusses collecting input, it moves on to ‘Delivering Output’ (Chapter 4). This section as well as the following section on ‘Handling Failure’ (Chapter 5) have much less material than ‘Collecting Input.’ That’s because the patterns in these two sections build on top of the patterns introduced in that section. As an exercise, I recommend approaching each piece of ‘before’ code presented in these sections by thinking about which patterns you’ve already read could help you out in each of these situations. See how often the ‘after’ code, in fact, uses those patterns you know in combination with something new.

You get to do more of this in the section ‘Refactoring for Confidence’ (Chapter 6), where the book shows you code samples from two real-world open source projects and refactors them toward some of the patterns you read about in the book. For a fun challenge, I recommend trying these techniques out yourself in an open source library that you like to use.

Conclusion

Great book, I highly recommend, and also an excellent book to hone your mind-mapping and note-taking skills, if that’s something you’d like to develop. I found myself stopping to look up the resources Avdi recommended, learn more about the syntax he uses, and copy the ‘after’ code by hand to help commit the patterns to memory. I’ll be using the notes above to help me reference these patterns in the future on real-world problems.