Rails debuted ten years ago, and its promise of productivity was staggering: build a blog in 15 minutes! Of course, real work is messier than that, buRails debuted ten years ago, and its promise of productivity was staggering: build a blog in 15 minutes! Of course, real work is messier than that, but that's the magic of screencasts and tutorials: everything is rehearsed and distilled for maximum pizazz. You skip over all the dead ends and googling, and you're left with a series of clean steps to layer on complexity, and in the end you have a delicious code cake.
This is more of a bran-muffin book.
The example that carries through most of the chapters is a task list, which is such a simple application of CRUD that it's a sample app trope. In other words, it's not that interesting, and I can already see the interesting parts implemented elsewhere. In [a somewhat unfair] comparison, the Rails book walks you through building an entire online e-commerce website.
Part of the appeal of Flight is supposed to be that you can compose fairly complex applications from more primitive general-purpose components. You start with components that have a clear set of responsibilities and inputs/outputs, which makes them easy to test and easy to maintain; by using many of these components on a single page, you end up with a whole that is more than the sum of its parts.
I had hoped that this book would lead me through several components like these, and then illustrate how to combine them. The Flight website does just that: its example is a webmail app! But no such luck. Late in this book, there's reference to such an example; the author explains how you might componentize TweetDeck, and why a flat structure is better than a nested structure. But the chapter is just a few pages and totally glosses over how the components would actually be linked.
There are a few other really promising or helpful spots in the book; the chapter on testing, for example, is full of useful code. Except, most of it is evidently now available as part of the jasmine-flight project, so it's kind of moot to have it in print. And I was excited to read the chapter on performance... until I found out that it's only three pages, and it doesn't address one of my team's biggest concerns (about how to share templates between the client and the server).
As others have mentioned, the code is also full of errors. I didn't mind those so much, since I could spot them, and I wasn't trying to run the code. But it's still a knock against this book.
To be fair, I know a lot more about Flight now. This is still a good introduction to the philosophy. But I still have so many questions about how it would work in a real app — questions I had hoped that people with intimate ties to the creation and early applications of Flight would have been able to answer....more
I'll get this out of the way first: the author can be a little pompous. For example, there's a long footnote on effective metaphors in the middle of aI'll get this out of the way first: the author can be a little pompous. For example, there's a long footnote on effective metaphors in the middle of a confused, ineffective metaphor. An excerpt:
Let me get all serious for a second: I think I'm better at explaining technical matters to non-technical people than almost any other programmer I've ever met, and I believe that studying Homeric simile is why.
He immediately follows with, "There's ego and pretension in this claim, obviously," so at least he's honest, but I still wanted to roll my eyes a bit.
That said, his critiques of Rails are even-handed and mostly thoughtful. Many of them highlight quirks in Rails that I've been vaguely aware of but now understand better and can articulate more clearly for having read this book. I really love Bowkett's generous use of quotations and other citations; it places his points in the context of ongoing conversations in the Rails community, so when he advocates a certain practice, I know what real-world problem it's supposed to solve. I can also jump quickly to his sources, which makes for great exploration.
The best chapters are 8, 9, and 10 ("Rails Unit Tests Are Not Unit Tests", "ActiveRecord vs Active Record", and "DCI"). Every Rails developer should read these chapters, because every Rails developer has bloated classes, and DCI is a great model for decomposition that improves maintainability and testability. I'm looking forward to Clean Ruby, an upcoming book that Bowkett recommends for more detail on this topic.
The rest of the book is interesting as a study of Rails from a Computer Science perspective. It's less directly actionable, but just as it's healthy for an engineer to know where Ruby ends and Rails begins, it's healthy to know how Rails works its magic. In some cases, Ruby and OO deserve all the credit; in other cases, Rails is really doing a lot of heavy, awkward, non-OO lifting (with the magical transference of instance variables from controllers to views, for example). The end result is the same either way: using Rails is easy.
This point is belabored a bit in the final chapters (which are about code generation), but I suppose I can't blame Bowkett too much, because it's an excellent point. Rails is successful despite internal messiness because it has always focused on its customers, a.k.a. developers, which means that the top priority is having a great API. Developers would do well to think the same way a bit more often when writing their own software....more