Back in March, Ruby developer Gregory Brown raised the idea of receiving donations so he could work on open source Ruby projects full-time. It went well, and out of this project came Prawn, a pure Ruby PDF generation library. Not one to rest on his laurels, Gregory's now working on a book for O'Reilly called Ruby Best Practices, billed as "for programmers who want to use Ruby the way Rubyists do." The book will cover how to design "beautiful" APIs and DSLs, along with lots of other general topics that will make your code more expressive and make you a better Ruby developer into the bargain.

The book is not due for final release until August 2009, but thanks to O'Reilly's "Rough Cuts" program, the first three chapters (Driving Code Through Tests, Designing Beautiful APIs, and Text Processing and File Management) are already available. Online-only access is $17.99 and you'll get the latest version as it becomes available. Print-only and Print + Online bundles are also available.

Gregory gave me a copy of the first three chapters to look over, and they're well crafted. This definitely isn't a reference book, a "cook book" or any sort of book you merely "dip" into. It's designed to be read by the chapter. The first chapter, Driving Code Through Tests, for example, takes you on a journey through the world of testing in Rubyland from motivation through to best practices - it's a full introduction to a single topic.

The Interview

I decided to ask Gregory a few questions to get more background on the book, as well as an update on his Ruby Mendicant project:

What was the inspiration for writing Ruby Best Practices?

Right now, it's entirely possible for one to learn enough Ruby to get by without ever understanding why people love the language. I think one reason is that our books have disproportionately emphasized on solving particular problems, via some recipe or pattern. We've also got a ton of introductions to the language, some better than others, but these books don't dive into code that looks or feels real. Our reference books are great (at least IMO), but they're only telling you what sharp tools are in the shed, not how to use them.

Ruby Best Practices is a book about why Rubyists tend to write Ruby the way they do. So this book looks at a lot of real code, most of it from open source projects, and tries to make it approachable to any reader who's got a reference book handy, so long as their willing to engage their brain a bit. I'm hoping that people will have fun learning a bit more about the 'why' behind a lot of the design decisions we face when writing code.

Does the rapid pace of change in the Ruby community makes writing a book like this more difficult?

I think change is generally good, and that folks who wish to live on the edge must be willing to pay the price. There's nothing wrong with using older versions of software if you're not ready to make the jump to the new hotness of the week.

However, I want this book to be current when it prints, and I also want to help encourage people to move forward, so I've been writing against Ruby 1.9.1 only. Because the only place 1.8 is mentioned is in my chapter on how to write backwards-compatible code, I don't have the pain that most people do with updating their notes constantly about changes in 1.9 vs 1.8. I just need to make sure my code keeps running properly on 1.9.1 until the time the book is released. There are hiccups from time to time, but I've definitely been in less pain than anyone who's trying to write a reference book right now.

What sort of developer should be buying this book right now?

I think that any developer who has worked through some introductory Ruby material and has a reference book handy can learn something from RBP. I've got a couple internal reviewers who are in exactly that position, so they help keep that target audience in range.

However, in terms of the Rough Cuts release, what I need most is folks who are fairly strong in idiomatic Ruby to pick up a copy and help correct me where I am wrong. I put together a great team of internal reviewers who check every chapter before it becomes public, but more eyes will surely help shape the book before it hits the shelves.

I definitely want the book to have the kind of authority that comes from extensive peer review instead of having people trust it based on name recognition. If people provide feedback through Rough Cuts, I think it'll be easier to accomplish that goal.

How is the Ruby Mendicant project going?

The Ruby Mendicant project officially ended on September 30th, two weeks after the scheduled end-date. However, I'm still actively working on Prawn and will continue to move things forward over the coming months. I came up a little short of the hours I initially pledged, but accomplished most of the goals I had in mind. We're getting closer and closer to providing a replacement for PDF::Writer, and many users have already made the jump.

I gave a talk on Ruby Mendicant / Prawn at RubyConf, and it's probably the best summary I've done so far, which people could check out once Confreaks gets the video online. I also plan to write a post-mortem about the whole experience but haven't found time just yet. I'll link it on that talk page once it's available.