"Agile Web Development with Rails: Second Edition," by Dave Thomas and David Heinemeier Hansson with Leon Breedt, Mike Clark, James Duncan Davidson, Justin Gehtland, and Andreas Schwarz

Pros: Thorough, clear, and complete
Cons: Now what do I do with my other Rails books
Rating: 5 out of 5

This is the second book in a row with which I’ve been exceptionally happy. As any engineer who’s been in the service of the federal government can tell you, two points is a trend, implying that my enjoyment of Agile Web Development with Rails may not be so exceptional after all. I hope the next book I read is substandard; reviewing just won’t be the same without the regular opportunity for carping.

The book still leads off with the extended example of building an online shopping cart system that I complained so much about in the first edition. My gripe was that it seemed a rather easy and contrived example of the benefits of agile development with some rails thrown in. In this edition, however, it works quite well. Perhaps it’s because of the explosion of features that have been added through Rails 1.2. There’s now sufficient complexity to the material that the extended example is helpful, even necessary.

Speaking of Rails 1.2, most of the additions to the book are sections covering the changes and new features. Migrations are covered in depth. No more hand-patching and transforming the database schema for you. Both the example and a chapter later in the book delve even deeper into using AJAX to pretend the web is a rich user interface. The book also includes information on Rails’ new support for unicode.

There’s also a section on REST. Most of what I’ve read about REST waxes poetic about resources, ease of discovery, and architectural bliss without any real substance. Agile Web Development with Rails gets straight to the point and lays out what it is and what it does: using HTTP’s “verbs” of GET, POST, PUT, and DELETE as a basis for dispatching actions. Having read it, I don’t see why everyone is quite so excited about REST. It seems to me that shuffling around the information-bearing parts of an HTTP request for a URL does not a bold new architecture make.

When my wife is evaluating a cookbook – bear with me folks, it’ll make sense in a paragraph or two – she looks for evidence that the book was kitchen tested. We once made a recipe with instructions to boil off nearly a gallon of water over ten to fifteen minutes. Either the author’s stove is located on the launch pad at Kennedy Space Center or they never made the recipe. (I know what you’re thinking, and it wasn’t just a typographical error; that cookbook was filled with impossibilities.) A prerequisite of a good cookbook is thorough kitchen testing.

Dave Thomas has written a book with outstanding kitchen testing. I suspect this is due to the beta book release. Every significant step in his example application is followed by detailed error handling text. Did the command not execute? Your environment was probably flawed in this way. Did the page show this error? You probably made this typo in the view code. Did the screen just go awash with flame and screaming of dying elves? You’re probably playing World of Warcraft instead of coding. Most likely errors are covered. This is good for being able to follow the example and even better for acclimatizing the reader to the diagnostic thought process they’ll need when working with Rails.

Of course, now I have a new problem. I have to figure out what to do with the rest of this stack of Rails books I don’t need anymore.

Posted in Reviews Tagged with: ,

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.