Ash Moran's Reviews > Rails Rescue Handbook

Rails Rescue Handbook by Mike Gunderloy
Rate this book
Clear rating

by
3089816
's review
May 03, 10

bookshelves: books-i-read-in-2010, ruby, software, rails
Read on April 26, 2010

This is a short eBook that offers specific advice in the following areas of rescuing a failing Rails project: repairing the relationship with the client / their impression of the project; investigating Rails code; using quality analysis tools; working with the database; testing; security; refactoring; and improving your own (in-need-of-rescue) code.

Mike Gunderloy reveals himself early on as being experienced dealing with disillusioned clients. All his relationship advice is client-focused: work first on the things they find most painful; don't give them false expectations; never lie to them; be communicative; let the them make decisions, as it's ultimately their money.

The bulk of the rest of the book is either Rails-specific technicalities, or agile development practices. In some sense, the Rails-specific content is useful. I learnt about a number of specific areas that tend to be done badly (mainly around security and performance), which is useful as a checklist, as many are things you may not expect to be overlooked. A lot of the rest is tools (such as metric_fu, Rack::Bug, FiveRuns) you can use to make working with Rails code easier. It's interesting, but not really worth more than a blog post.

I found some of his database advice contentious. He advises against storing seed data in migrations. Fine, I'll live with this one, you can argue either side. But, while he advises to run the migrations to get an app up, he advises against "procedural" migrations, that make incremental changes to the database. Maybe it's just that the scope of this recommendation is unclear, but I'd love to know what sort of project he works on that can be developed without incremental change. Not only does it preclude certain types of database change (referential integrity!), but it is not even hard to do. I've seen a project maintain a stable database throughout several years of incremental database migrations.

There's a dose of refactoring in here. He wisely advises to be conservative with refactoring, as merely "modernising" code is not always safe, and not even necessarily useful. But the advice is heavily Rails-specific, and does not talk much about software design. As such, it might be useful to a non-Rails developer doing a rescue; but I question how often this situation actually arises.

Finally, there's an appendix on what to do if you realise you were the one that designed the software, and turned it into a rescue case in the first place. (Tips include setting aside time to learn, and find people to help you grow as a developer.) Interesting, but it highlights the real problem with this book.

If you're an experienced developer, with a good understanding of object-oriented software design and test-driven development, you'll only get value from the Rails-specific bits, assuming you don't know them. The value of this content, however, doesn't add up to much more than a series of blog posts (a lot of it is time-sensitive). But if you don't have this experience, you shouldn't be attempting a Rails rescue in the first place. And here lies the real problem: while the book has useful content, I don't see that there is an audience that would benefit from it in this form.

I would recommend instead:
* Working Effectively with Legacy Code - to learn techniques for dealing with untested code (although, it does have a Java/C++ bias, and not all of it is relevant to a Ruby developer)
* Refactoring in Ruby - to learn techniques for dealing with painful Ruby (disclaimer: I haven't read this thoroughly)
* The Passionate Programmer: Creating a Remarkable Career in Software Development - to learn how to grow as a developer
likeflag

Sign into Goodreads to see if any of your friends have read Rails Rescue Handbook.
sign in »

Reading Progress

04/26/2010 page 89
100.0% "Read in one sitting over a coffee"

No comments have been added yet.