Curious, Healing

Recommended to me by: Sam Livingston-Gray

This book conveys tips, tricks, and cautions in a conversational style without talking down to the reader. Several topics became immediately useful when I recognized them in the code at work the next day.

Some of Ruby’s oddities, I mean special features, are:

• No static type-checking. Pass any object as an argument to a method, and if it answers to the methods called on it, all is well. This is formally known as “duck typing,” as in “if it looks like a duck, and quacks like a duck…”
• Pass anonymous blocks to functions. For example Array.each will call a block on each element of an array.
• Add/change/delete methods in classes at runtime.
• Mix in new functionality by including modules in a class.
• Override method_missing to extend a class on the fly. This is considered a “standard” trick.

Highly recommended if you’re programming in Ruby. I’d read Russ Olsen’s writing on any topic based on the quality of this book.

Available at bookshop.org.

Recommended to me by: Sam Livingston-Gray

This book is written in a more formal, technical style than Test-Driven Design by Example. I’m glad I read the latter book first.

The main new idea I learned from this book is to set up a testable skeleton of a new application at the beginning. This involves researching infrastructure decisions up front, as well as dealing with the thorny issue of installation. The authors’ point is that this work has to be done at some point, and it makes project schedules a lot more reliable in the long run when it is done first.

The authors advocate for making software objects small and shifting emphasis to the communication between them.

Available at bookshop.org.

Recommended to me by: Sam Livingston-Gray

Test-Driven Development (TDD) is a tool to manage the complexity and difficulty of writing software. It offers an alternative to the “waterfall” approach: design specification, functional specification, implementation, testing, release. In theory each step is finished before going on to the next. The problem is that there is a whole lot of debugging during and after implementation, testing, and release.

In TDD, the programmer writes a test for one small aspect of a program, then implements the minimum code required to satisfy that test. Once the new test passes, the code is refactored to remove duplication while still passing all tests. Repeat as needed. In this way, designs evolve to satisfy existing conditions rather than guessing about what’s needed months or years in advance. In addition, the code is always in a working state.

This is the most conversational software book I’ve read. It’s like having the author next to you at a computer, explaining the steps as you type. After years of battling waterfall development cycles, I’m convinced TDD is a useful approach, and I’m eager to try it.

Available at bookshop.org.