With a brand new project on the horizon (and a good candidate for Ruby on Rails 4 at that), I thought it would be a productive use of my time to bone up on some of the major differences introduced with this new version. My goal was to trade a little research for as many precluded that’s-not-how-we-do-it-anymore-500-errors as I could when fleshing out my first scaffold.
With this goal in mind, I purchased a copy of The Rails 4 Way by Obie Fernandez, Kevin Faustino, Vitaly Kushner, and Ari Lemer. Considering the free-nature of everything else Rails related, I will admit to a slight aversion to paying money for a Rails book. For those of you out there with similar proclivities, I felt compelled to share my experience.
The Rails 4 Way presents itself not as a tutorial of Ruby on Rails, but as “a day-to-day reference for the full-time Rails developer.” The tone of the book and the depth of information presented hints that the authors don’t want to teach you how to write Ruby on Rails applications. They want to share insight that will help you write better Ruby on Rails applications. Much of this is accomplished by fleshing out—
Early on the authors concede the point, “There are definitely sections of the text that experienced Rails developer will gloss over. However, I believe that there is new knowledge and inspiration in every chapter, for all skill levels.” I would classify myself as an experienced Rails developer and I found this statement to be completely true. When settling down to read the book for the first time, I scrolled through the pages until a specific topic caught my eye. As a result of this, I started my read part-way through chapter 4. Upon completion of the last section, I wrapped back around to the beginning and dutifully read everything including the foreword. I did this specifically because each of the chapters, if not sections, had contained at least one little nugget of information that I found valuable. I felt compelled to go back and look for the extra tidbits that I’d passed over with the initial, casual flicks of my mouse.
I mentioned that the authors focus more on helping you produce better code, and to this end, they don’t dance around any issues. My favorite quote from the book illustrates this, “Frankly, there’s not much of a reason why that should be a problem unless you’ve made some pretty bad data-modeling decisions.” By all means, call it like it is.
The book is still a work-in-progress. Somewhere around 10% of the sections contain “TBD” rather than a body. I gather that the book is based on its Rails 3 counterpart and some of the sections have yet to be enhanced with the Rails-4-specific content. A majority share of the Rails 3 content is still applicable, so this shortcoming did not mar my experience at all. Especially since I will be given access to the new content once it is added. At the time of my download, the last change was authored 12 days ago, so for that reason also, I am unconcerned.
In conclusion, I took enough new information away, and enjoyed the process enough that I feel confident in recommending The Rails 4 Way to friends and coworkers. The bulk of this book reads like an API document, and in those sections, there’s nothing technical that you can’t find on the Rails API page itself. What the book does offer is back-story into what these methods were designed to do and what they pair well with. I would compare the Rails API and this book to a map in your hand and a local who knows the area. Most of the time you can figure out how to get where you need to go by carefully reading your unfolded map. But sometimes it’s faster to ask a local who can tell you, “See that red sign off in the distance? Head over to it and take a right.”