What do you think?
Rate this book
Rails Rescue Handbook
A few years ago, there was no Rails rescue business. The framework was young, the developers were few, and the applications were being written by early adopters. As a group, the early Rails developers were by and large at the top of their profession.
But things have changed since then. After all the great press that Rails got in its early days, its popularity soared. Thousands of new developers began coding in Rails. Sadly, some of them didn’t really know what they were doing. Others, through no fault of their own, ended up on projects with unrealistic deadlines or impossibly tight budgets, and were forced to cut corners.
The there are some substandard Rails applications out in the wild now. There are applications that don’t run at all, applications where the tests bear no relation to the code, applications with crushing performance issues. Some of these applications are destined for the bit bucket. But others are prime candidates to be rescued - and that’s where you, with the help of this book, can come in.
I’ve spent a lot of time over the past few years working with Rails projects that were written by other people. Sometimes I’ve come on as a subcontractor to an existing codebase, sometimes I’ve taken over when another developer got bored or fired, and sometimes I’ve been asked to do a code review.
Over the course of these engagements I’ve come up with a strategy for getting up and running on a new-to-me Rails codebase quickly. And in the cases where I’ve found serious issues, I’ve come up with ways to mitigate them. If you’ve inherited (or even created) a Rails problem, don’t despair! Help is at hand.
But things have changed since then. After all the great press that Rails got in its early days, its popularity soared. Thousands of new developers began coding in Rails. Sadly, some of them didn’t really know what they were doing. Others, through no fault of their own, ended up on projects with unrealistic deadlines or impossibly tight budgets, and were forced to cut corners.
The there are some substandard Rails applications out in the wild now. There are applications that don’t run at all, applications where the tests bear no relation to the code, applications with crushing performance issues. Some of these applications are destined for the bit bucket. But others are prime candidates to be rescued - and that’s where you, with the help of this book, can come in.
I’ve spent a lot of time over the past few years working with Rails projects that were written by other people. Sometimes I’ve come on as a subcontractor to an existing codebase, sometimes I’ve taken over when another developer got bored or fired, and sometimes I’ve been asked to do a code review.
Over the course of these engagements I’ve come up with a strategy for getting up and running on a new-to-me Rails codebase quickly. And in the cases where I’ve found serious issues, I’ve come up with ways to mitigate them. If you’ve inherited (or even created) a Rails problem, don’t despair! Help is at hand.
89 pages, ebook
First published June 29, 2009
2 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 of 1 review
May 3, 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
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
Displaying 1 of 1 review