Author Interview: Leonard Richardson

How did you discover Ruby?

Leonard: I'd known about Ruby for many years but only started seriously using it in 2005. My first serious Ruby project was Rubyful Soup (a port of my Python HTML parser), and my first professional project was the Cookbook.

At the time I was working in a Java-oriented job, tired of Java, and writing articles about Python web frameworks, so I probably would have entered Ruby through Rails were it not for the Cookbook.

What role does Ruby play in your day to day work?

I'm working on a book now that's not about Ruby, but that uses Ruby as the implementation language, the way _Design Patterns_ uses C++. I'm also doing miscellaneous Ruby consulting work.

How did you come to write a book about Ruby?

Leonard: That's a good question because I came into this project something of a Ruby newbie, certainly not anyone's top choice for a name on a Ruby book. I think I'd built up a good reputation from my work on the Wrox book _Beginning Python_, and when my agent suggested me, O'Reilly listened. It probably didn't hurt that all the big Ruby names were busy working on their own books. :)

As for coming into tech writing in general, I owe it to a former co-worker of mine, Tony Steidler-Dennison.

What sets your book apart, why should people buy it?

Leonard: I think it's got better breadth than other books (as you'd hope from a cookbook), but also good depth. I tried to make the recipes solve not just the specific problem stated in the title, but also a conceptual cluster of related problems. My idea was that we can't have a recipe for every possible problem you might encounter, but we can group similar solutions together to increase the chance that you'll find what you need.

Of course, some problems are really open-ended and some libraries have a huge number of features. A recipe can only be a few pages long, so for some recipes, all we could write was "solve the problem with this library, here's basically how to use it, good luck". Those recipes contribute more to the breadth than the depth.

My other goal was to write a book that you can use as a Ruby tutorial if you already know two or three programming languages. Most programming tutorials are written as though you've never written a variable assignment before, and it's kind of patronizing by the time you're learning your third or tenth programming language. My plan is that that you can start up an irb session, work the examples in the first ten chapters, and then you know Ruby. As far as I know no one has actually tried this, but I'm really interested in hearing whether or not it works.

What was the most rewarding part of writing your book?

Leonard: Ever since I bought my first O'Reilly animal book ten years ago (it was probably Shishir Gundavaram's CGI Programming on the World Wide Web) I've wanted to have my name on one; I feel like I'm part of an old tradition. Probably not as important a tradition as it was back when O'Reilly was the only publisher putting out books for hackers, but I'm still proud of it.

But really the most rewarding part is that people are using the book. I wrote it to be used, I use it all the time, and when other people use it I'm happy.

What was the biggest challenge in writing it?

Leonard: Coming to terms with my own foolishness. I'd write a huge chunk of code and a reviewer would point out that you could do it in one line, or that there was a gem for it. And that's the stuff that got caught. My favorite recipe in the whole book (14.20, "A Real-World HTTP Client") has a bug in it. It'll be fixed in the next printing, and I think there are actually relatively few bugs in the book because I could automatically test most of the code, but it's still aggravating.

What did you learn from writing it?

Leonard: I learned a lot about Ruby internals, from diving into the libraries and the C code to see how things really work. I learned a huge amount about Ruby in general, since as I mentioned earlier I started out almost a newbie. I think the best way to learn something is by teaching. The next best way is by doing, which is why the Cookbook focuses so heavily on trying out concepts for yourself in an irbsession.

The book was also a good general education in fields I'd never really looked at before: SSL, GUIs, distributed programming... I also enjoyed going through the RAA and the gems on Rubyforge, looking for interesting software to write about.

What are your favorite five libraries for Ruby?

Leonard: Hard to pick just five, but I'll showcase some lesser-known libraries that I think deserve attention:

• hpricotby _why, which makes me think I should just pack up Rubyful Soup.
• Starfish, a really simple distributed programming library that Lucas wrote.
• char-encodings deserves more attention. By which I mean, people should work on it as a way to improve Ruby's internationalization support, and yet I shouldn't have to do any work on it.
• Ferret is a Ruby port of Lucene, the best Java library ever. It lets you do full-text search on structured data.
• Finally, ActiveResource isn't a real library yet, and everybody knows about it, but it's going to be awesome.

What do you think is next for Ruby?

Leonard: I'm looking forward to more libraries that use Ruby's idioms to radically simplify entire domains. I think this is where dynamic languages like Ruby and Python show their power: Rails, ActiveRecord, ActiveResource, gserver, DRb, Starfish, Twisted, PyGame, etc. These libraries tackle a problem that's been around for years, and succeed by hiding a huge amount of the work and/or changing the way you think about the problem.

Many Ruby libraries (I'm thinking right now of the GUI libraries and RMagick) are just simple bindings to C libraries. Working with them feels like writing C code except without the performance benefits. Ferret is awesome but, because it's a Java port, you need to instantiate five different classes just to blow your nose.

It's great that Ruby has access to the best of other programming languages, but I think a binding or a port should be a signal to enterprising hackers to radically rethink the whole thing. For instance, just off the top of my head it seems like Ferret could support a simple ActiveRecord-like interface with no loss of power. (There I go, putting work on someone else's plate again.)

What's next for you?

Leonard: As I mentioned, I'm working on another book, which will hopefully be out early next year. I'm also writing science fiction, which might or might not ever be published. Financially, writing science fiction is to writing technical books as writing technical books is to having a "real" programming job.