The Rails BetaBook is Ready:

The Rails BetaBook is Ready

PragDave and friends have done it again. Having been in on the review team for the book (though, really, that just means I got to read it early, since I only submitted comments for one chapter) I can say that the book is a thorough, and much needed, work. Rails is here. Its momentum is, if not unstoppable, at least undeniable. Though the online docs and wiki are valuable, somebody needed to write the whole story down in one place. Dave, as always, has done an admirable job.

I also like the new beta book approach. In my experience, people like to have the paper copy of a book like this, and delivering an electronic version early is only going to increase actual sales. Let’s hope that the PragExperiment proves that theory.

I was speaking at the Reston, VA No Fluff Just Stuff symposium this weekend, and the panel discussion got a little out of hand. Here we are at a traveling Java technology conference, and every question and every answer was about Ruby or Python. I’m afraid the attendees walked away from the panel thinking we all hate Java, which couldn’t be farther from the truth. Its just that Rails is a soccer ball, and we’re the Forest View 5-and-under Kids Soccer Team.

After loads of discussion of the relative merits of strong- vs. duck-typed languages, and tool support for Ruby and Python and managed versions of dynamic languages, we ended up where we always end up on these talks: how do we deal with all the losers we have to work with? It never ceases to amaze me how the audience, not the panel, always gets around to this question. "I work with a bunch of cavemen; how do I protect myself and my project from them?"

I finally came up with a good answer: Honeypot projects. Just invent something important-sounding but impossible to achieve, set up a $399 Celeron Dell desktop box but put one of the $150 cases on it that you get from Intrex that makes it look imposing and important, tell everyone that its the new Sun Optipylon 4500 server, give the cavemen logins on the box and let them build something. Just make sure the new Sun Optipylon 4500 is on its own subnet, and voila!

I kind of prefer Dave Thomas’ answer, though. If you are really scared of so many folks on your team, you need to either rethink your hiring practices, or rethink your firing practices.

Bruce Tate and I, on the heels of Better, Faster, Lighter Java, set out to introduce people to Spring. Committed as we both were to the ideas we were espousing (simplicity, ease of configuration, choosing tools that get out of your way), and admirers of what Rod and company had done with Spring, we wanted to write a book that would let people get right at the things that make Spring sing. O’Reilly suggested the book would fit well into the Developer’s Notebook series, a code-heavy, to-the-point format that would highlight code and not prose. We agreed, and were off.

The end result of our work, published just two weeks ago, has flaws. Instead of waiting for the inevitable trickle of mediocre to poor reviews to poison the book on Amazon, though, I want to acknowledge those flaws now. Oh, its a good book which does what we intended it to do: introduce developers new to Spring to the variety of ways it can make their lives easier. Its flaws are not in intent, or even content. The flaws are in the execution.

There are typos, for sure, but every book has typos. There are mislabeled figures, and missing angle brackets at the end of XML snippets, and a variety of errors that creep into any book. Those are what errata pages and reprints are for, and you’ll find both attached to this book. The bigger problem is with omissions: as the chapters progress, important pieces of information about how to make the code you see in the book run are missing. A taglib here, an interface there, a new dependency in the /lib directory over here, and it all adds up. People who try to follow the code in the book and make it run, quickly run afoul of these frustrating omissions and start getting (rightfully) upset.

Perhaps we were relying too heavily on people’s willingness to download the code samples and dependencies. That, I believe, was the heart of my mistake, anyway. And the kernel of a valuable lesson: when you set out to make a book, make a book. Not a book, plus a website, and a blog and an errata page. If you want to write a book for print, make sure the book contains everything that it might need, soup to nuts, within its covers. The downloadable code all works; I urge readers of the book to grab copies and refer to them as you read the book. We broke them up by exercise in the book so it is pretty easy to see what has changed.

But you shouldn’t have to, and for that, I apologize. We’re issuing a reprint of the book now that fills in those holes. In the meantime, you can find the missing pieces on the errata page or follow along here as I enumerate them over a series of posts, starting with the one right after this.