intertwingly

Agile Web Development with Rails, 3rd Edition is about to have its third printing.  Translations are under way for Chinese, Japanese, Korean, and Spanish.

One thing I wasn’t aware of before participating in the development of this book is that printers have an opportunity to address errata in each printing.  I don’t know how widespread this practice is, but this is definitely something that Pragmatic Programmers takes advantage of.  The ground rules on what changes are allowed are a bit flexible, but in general work out to be something along the lines of “no new features” (i.e., bug fixes only) and “don’t affect pagination”.  Process wise, I make changes to the source, provide a diff to a layout editor who verifies the layout and makes tweaks as necessary (e.g., adjusting inter-line spacing if necessary to ensure that changes are localized), and the results are sent off to the printer.

Other changes are fodder for a new edition (or possibly even a new title).  Examples of this include the changes required to use this book with Rails 2.3.2.

What would I like to see in a follow-on to this book?

• First, basic hygiene.  All the examples should be changed so that they work without any deprecation warnings against the first 3.0 public release of Rails.  Given that Yehuda Katz is now actively monitoring these tests, this should not be an issue.  This brings up a naming issue, as a fourth edition of this book being the one that targets the third release of Rails is a point of confusion.  Those that remember the early days of the NEcho wiki know that I suck at naming, so I’m happy to leave this problem to others.
• Second, widen the base.  The first edition of this book had a near cult following from a number of Rails enthusiasts, so the introduction to Ruby tucked into the back was sufficient, and perhaps even overkill.  Based on the errata I have seen, it now is a necessity, and should both be moved into the front of the book and updated to specifically target refugees from other languages. But I mean more than that.  It is clear that a number of readers have never found the command line (translation for Mac users: Terminal.app).  A few pages on that topic, as well as another couple on SQL would go a long way.
• Third, pruning.  This book contains in depth coverage of topics aren’t fundamental or are no longer exemplary (e.g. database constraints, data migrations, active record based sessions, non-REST routing, non AR objects in sessions, non AR objects in forms, forms without underlying models, ...).  At a minimum, these topics should be deemphasized by being moved later in the book.  In some cases, they should be moved outside the book entirely (fodder for future “recipe” books perhaps).  Additionally, over time, the state of Rails documentation has improved, so this book can afford to reference the documentation more.
• Fourth, refactoring.  This book starts with scaffolding, and then takes a walk through a number of Rails features.  As Rails is getting more modular, a more phased introduction is possible.  one could imagine a book that starts out with a “we don’t need no steenken framework” approach to life, and starts out with a single file (Sinatra style) application, and then one by one adds in a Rails feature, explores what benefits (and tradeoffs) that feature provides.  Initially, the approach could stay entirely with Rails defaults, and then once that is complete, subsystems can be swapped out or augmented.  Concretely, this could mean starting with an XML file on another machine with products that needs to be parsed and stored in a database.  This could start with no Rails (coding direct to SQLite3), substituting in ActiveRecord.  Introducing Rack, then Metal, then ActionController::Http, ... eventually dovetailing with the current Depot application.  When Depot gets to the point where it generates XML, it won’t seem so random.  And when we get to ActiveResource, it will complete the loop as it will essentially be parsing the XML with zero code.
• Fifth, radical refactoring.  This is the part that is most speculative, and may not be successful.  I’ve talked about eliminating or moving forward the appendixes.  I’ve talked about pruning the “Rails In Depth” chapters.  If the remainder of these chapters could be made small enough, they could be integrated with the chapters in Depot where these concepts are introduced.  Additionally, the very first Rack based-application could be automated using whenever, tested using Rack-Test, deployed using Capistrano, establishing best practices early on.  I’ll be honest: while this is highly desirable, it is also a considerable challenge.  If the end result is that this overwhelms the coverage of Rails it ends up being a disservice and a distraction.  I definitely don’t want to get to the point where you have to get 2/3rds of the way through the book before you learn about scaffolding.

Hopefully, this work can get underway by the end of the month and be complete as near as possible to the first public release of Rails.