Our Book Promotion: “Ruby Best Practices” starts soon. Win one of four books to be given out for active participation. The coolest thing? Author Gregory Brown will be on site to answer questions! Click here for more details. Here, in this brief interview, Satish Talim of RubyLearning talks to Gregory Brown.

Satish>> Gregory, could you tell us something about yourself – your background, where you are based?

Gregory>> I’m a Ruby hacker that tends to spend a lot of time on free software. Right now, I’m mainly working on two things: Working towards getting my pure Ruby PDF generation library Prawn to a 1.0 release, and starting up on a web based reporting system for RubySpec that I’m calling Unity. Beyond that, I do most of my commercial work for a dev shop called Madriska Media Group, where I get to hack on hard and interesting problems with Brad Ediger. Though we are doing Rails work, you could hardly call it that, as many of our projects have some seriously hard CS problems in their critical path. But I like that stuff, so its a lot of fun!

As for my background, I’ve been programming since I was little, toying with various languages and systems that I could find. So I basically have my roots as a tinkerer, not a career programmer or academic. But things changed when I met James Edward Gray II over the net many years ago when I was writing some bad Perl code and releasing on Sourceforge. He helped show me how real programmers attack problems, helped turn my bad Perl code into good Perl code, and then later, when he moved into Ruby, helped me turned my bad Ruby code into good Ruby code. That helped me meet a lot of other really talented hackers, who I’ve learned a lot from as well.

Satish>> What inspired/prompted you to write “Ruby Best Practices?” What need were you trying to fill?

Gregory>> I’ve tried to teach a lot of people how to program over time. These days, I have a pretty high success rate, but it used to be a real struggle for me. In my experience, a lot of people reach the technically proficient stage with a language or technology, but never reach the point where they see the beauty or power behind truly elegant code. When the novelty of learning a new skill wears off, I’ve seen folks either start to hate their work, or just drop out entirely. I wanted to fix that, and RBP was born as a result of this itch of mine.

The book has a heavy focus on exploring real code, and isn’t very preachy. This way, the reader can discover for themselves the merits of the practices and idioms it exposes. I think this is key. Some Ruby books let you phone it home and make for an easy skim. RBP is better as a doorstop if you don’t want to crack open your editor and try some things out. At the same time, its not aimed at gurus only. I think different people will get different things out of it, and that’s what I shot for.

Satish>> Who’s the audience for your book – Ruby Best Practices?

Gregory>> This book is for those who care about improving their craft. A raw beginner may not find it very approachable, but anyone who’s done at least a small project in Ruby could probably learn a lot from it. A key thing for prospective readers to keep in mind is that it is *not* just an information dump. You should plan to read the whole thing, or at least read it by the chapter. Keep your brain engaged, and your development environment at the ready. For those who enjoy experimenting a bit and sharpening their code reading skills, the book will be enjoyable and helpful.

My hopes is that a more advanced reader might find the book downright fun. There is some seriously cool code in here, from a number of very interesting Ruby projects.

Satish>> What direction do you see Ruby taking in the years to come?

Gregory>> I really don’t know. I’m a poor fortune teller and I think there needs to be a closer look at where we are right now before we can talk much about the future.

I recently did a talk on this, which might be an interesting watch for those curious what I think about the current state of Ruby.

If we can get a good sense of how things stack up right now, we can focus more on the immediate issues than on the more glamorous, pie-in-the-sky problems. I think if we do that, things will be just fine.

Satish>> I know that it is too early to say, but looking back are there some topics that you now wish should have been covered or dropped from the book?

Gregory>> For a book that’s a little over 300 pages, I wrote over 700 pages of content. I aggressively edited things down to make sure the book is lean and tight. I am pretty happy with the outcome.

As far as topics I wish I covered, some were limited by Ruby 1.9’s progress at the time of writing, and my deadline expired before I had a chance to fully give certain things the respect they deserve. This book would have been better with a chapter on YARV performance tuning, but the tools and common practices basically still aren’t there for that. It would have been nice to add a chapter on higher level design, things like SOLID and Connascence and other hardcore topics like that. But maybe that would have bloated the book too much.

Luckily, we have the Ruby Best Practices blog now. We can cover other topics there as they come up, and RBP can stay small and focused. That seems like the best of both worlds.

Satish>> Anything else you would like to add?

Gregory>> I’d like to say thanks for inviting me here. I really look forward to questions and feedback from the folks who participate in this promo. It should be fun.

Thank you Gregory. In case you have any queries and/or questions, kindly post your questions here (as comments to this blog post) and Gregory would be glad to answer.