My new ebook, Unfuck A Monorail For Great Justice, refers to a frequent problem: monolithic Rails apps (or "monorails"), and the fact that the people who work on them will often describe them as fucked. My first book covers some of the reasons that monorails happen in the first place. This book is more about how to solve that problem -- how to take a monolithic Rails app, make its specs much faster, make its design more object-oriented, and use that more object-oriented design to fragment the app into services, where necessary.
This book does not cover Rails antipatterns, which is in fact the name of another terrific book on that subject. If you don't know how to spot problematic code in your Rails app, then you should get that book. My book is about the best way to solve these problems, and solve them much more quickly than you would expect.
With my first book, I made an effort to be as not-NSFW as possible, but I was only moderately successful, and in fact I believe I used the word "fuck" 12 times. However, many people praised the NSFW-ness of that book on Twitter and in emails to me, so I didn't bother with that this time around. Basically, I decided not to give a fuck.
However, you might notice an unusual contrast; I use NSFW language all over the place, yet when I mention the work or ideas of other people, I refer to them with their last names, in a more formal style, because I believe that conveys a certain modicum of respect. I kind of wanted to balance the general informality with a deliberate formality in that one particular area, because I don't like flame wars and don't want anybody taking any disagreements personally. When it comes to talking about other people and/or their work, I think it's important to use a default which signals respect.
The book has three main parts. In the first section, I go through an experience I had where I was able to hit the ground running in a Rails rescue project with more context and detail on the state of the code base than I believe the company's CTO had during his entire time at the company. I got this information by writing bash and Ruby scripts against git history, and I show you how that code works, and how you can do the same thing. This is similar to material in Gary Bernhardt's Destroy All Software videos, but differs in some important ways. The bulk of the book consists of advice on how to make Rails specs faster, and make Rails code more object-oriented. (If you understand TDD, of course, you will realize that these two topics are two sides of the same coin.) The final section goes into detail about how to dramatically accelerate refactoring with judiciously applied automation.
Unfuck A Monorail For Great Justice: $41, 85-page PDF