Ruby Weekly is a weekly newsletter covering the latest Ruby and Rails news.

Ruby Best Practices: The Book and Interview with Gregory Brown

By Peter Cooper / November 14, 2008

ruby-best-practices.gifBack 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.


  1. Gregory Brown says:

    The link was updated, but just so folks know, I wrote the longish, sentimental post-mortem this morning:

  2. Aslak Helles√ły says:

    This is an interesting choice of name for a book.

    Does this mean that Gregory believes the practices described in this book are better than all other practices?

    What makes a practice "best"?

  3. Gregory Brown says:

    Aslak: Definitely not. They're the best practices I know of, and I'm reaching out to the community and to a great group of internal reviewers to poll them for their best tricks too.

    My original title was "The Second Book of Ruby", because that's what I wanted it to be, a book you read to learn how to write Ruby well after learning how the language worked.

    I also suggested "Ruby Techniques and Practices", but O'Reilly felt as if this title was 'too weak'.

    So please don't be off-put by the book. Though it is somewhat opinionated in places, the content does not in any way suggest that there is some 'One true way of Ruby coding'. In fact, in many places, I talk about how the "Best Practice" truly depends on what you're going for.

  4. Aslak Helles√ły says:

    Gregory: Good to hear. I have used Prawn, which is awesome, so I expect this book to contain a lot of great practices. Good luck with the book!

  5. Q says:

    I think this is a great idea. I've been reading programming books for a long time and while they typically describe what _can_ be done with a language, they don't often discuss whether or not things _should_ be done.

    When learning any new technology I typically find myself asking: What would a pro user do in this situation? These are the sort of questions an expert could answer easily if we were sitting together in the same room, but aren't usually found in the books I read.

  6. Markus Jais says:

    sounds great. Looking forward to this book. Will this be similar in style like the excellent "Effective Java" by Josh Bloch?

  7. Gregory Brown says:


    To be fair, I have not read the book. But when my editor read over my outline and talked out the structure of the book with me, he mentioned that it sounded similar to "Effective Java".

    We even considered the title "Effective Ruby" for the book (which I like better than the RBP title), but we avoided this due to potential conflicts with Addison Wesley.

    I'm not looking at other books for inspiration (aside from references, obviously) because I have a clear sense in my head of how the book should come together. But Mike Loukides described "Effective Java" to me as having a "big
    focus on API design, a book for people who already know the language
    but who want to get better." If this is true, RBP will definitely share similarities.

  8. Markus Jais says:

    @Gregory: thanks for the information.

Other Posts to Enjoy

Twitter Mentions