software

Subtitle: A Practical Guide to Object-Oriented Design

Recommended to me by: Sam Livingston-Gray

This book creates and then refactors (edits to improve) code to generate the “99 Bottles of Beer” song. (When I was a kid on field trips, we started at 100 Bottles.)

I read most of this book in 2015, but didn’t finish it, so didn’t add a post for it here. Apparently the initial “Shameless Green” code (straightforward code that makes the tests succeed) stuck with me, because I mostly reproduced it in the half-hour recommended to attempt the problem before reading the rest of the book.

There are lots of great points about object-oriented design and recipes for refactoring. The Ruby code that results at the end is elegant and easy to modify, although its readability benefits from the step-by-step walkthrough to get there. I will probably refer back to the book for refactoring tips when faced with Ruby code to improve.

Recommended for people wanting to improve their object-oriented coding skills, especially in Ruby. There are now editions available with code examples in PHP and Javascript as well, and the beverage can be beer or milk. Now I’m curious to see their code that generates the different versions of the book!

The book’s page and Sandi Metz’s website.

Available at SandiMetz.com.

Subtitle: An Agile Primer

Recommended to me by: Sam Livingston-Gray

I first read this back in 2012. It struck me as friendly rather than condescending this time, which is an interesting shift.

In 2012 I was just learning Ruby and focused on deciphering the example code as I read. Coming back to it after having programmed in Ruby for three years, I could read the examples fluently and focus more on the general points in the book, even though I haven’t looked at Ruby code in a while.

Some points that stuck with me this time:

• The purpose of design is to allow future changes in code, since requirements and circumstances keep changing.
• In object-oriented design, pay attention to the messages passing between the objects.
• Each object should have a single responsibility. (I’ve seen a downside to this, where you have to chase through a mass of fine-grained objects to find where something is actually done.)
• Manage dependencies to reduce risk. An object should depend on objects that change less often than it does.
• Inject dependencies, use Ruby’s duck typing: Send in an object as an argument that responds to the needed message
• Delay design decisions until you have at least three examples of what a class needs to do. (Two, if pressed.)
• Good design is TRUE: Transparent, Reasonable, Usable, Exemplary
• DRY: Don’t Repeat Yourself.
• Law of Demeter: Don’t chain calls through many objects, since that entails knowing too much about the insides of other objects.
• Isolate risky bits of code inside a wrapper, so they can be improved easily later.
• Test an object’s public interface (messages it responds to), and command messages it sends (messages with side effects).
• Use Ruby Modules to share code and tests.

Highly recommended as a guide for both general design, and how to write maintainable, flexible Ruby code.

The book’s website and Sandi Metz’s website.

Available at bookshop.org.

Subtitle: Create a Beautiful and Maintainable User Experience

Recommended to me by: Working with the authors

It took me two years to get around to reading this book, but fortunately (?) my project is on a version of Rails that’s three years old, so it’s a perfect time to read it.

This book is the next best thing to sitting down with Bruce and John to learn about Rails views. It’s organized as a tutorial with specific code examples. It would be beneficial to follow along and actually type in the code, although I didn’t do that.

The language is casual and friendly, with lots of tips, tricks, and best practices. There are some sexist (“marketing guys”) and ableist (“don’t get too insane”) phrases that detract from an otherwise great book.

Website.

Available at biblio.com.