Ruby Best Practices: mini-interview 3

Gregory Brown (@seacreature) recently announced two things: 1) that he's content-complete with his Ruby Best Practices book, and 2) that he's started a Ruby Best Practices Blog. Between the two, it seemed like a great time to run a third interview (you can read the first and second to catch up if you'd like).

If you're anxious to get your hands on the book (which is due to be released in June, you can always grab the shortcut straight from O'Reilly.

---

Now that you've finished the text of Ruby Best Practices what's left before we see the book hit the shelves?

Gregory Not too much on my end, which means I can come up for air a bit. We've already gone through the copyedit review, which went super smooth thanks to Nancy Kotary (@nancykotary).

So now, all that's left to do is wait for production to do all the magic that's necessary to make my manuscript into a book, and then I'll need to take a couple passes through to catch any last minute problems before the book goes off to print in June.

We will also be sneaking in a foreword at some point from a special guest, but I'm not revealing who it is just yet. The book needs some mystery, afterall.

Any time you're writing a book, you deal with constraints about what to put into it. What would you have written (more) about if you had more time/space?

Gregory With this book, I was really aggressive about making cuts. Readers will find it has a very specific 'feel' to it, and this was quite intentional. There were a lot of topics that were really valuable that I ended up avoiding because I couldn't find where to place them in the book. Basically, if I could not find enough real world examples that were clear enough to be covered in the space of a chapter while remaining non-trivial, the content didn't get written.

If I had more time, I could have probably managed to keep the performance chapter that we cut. We ran into some issues there with libraries such as ruby-prof not running on Ruby 1.9 and a lack of research material as to how to optimize code for YARV. I guess I'm not alone in building up a lot of assumptions about how to optimize Ruby based on my experience with MRI and Ruby 1.8.6, and not all of that translates directly to Ruby 1.9.1.

For almost every chapter in the book, there were extra sections I would have added. I had to cut it down to the essentials though, because I feared that 60 page chapters would anger my editor. :)

How will the new Ruby Best Practices Blog allow you to build on the foundation that the book lays?

Gregory The book doesn't really lay down a foundation, since its topics are fairly diverse. Instead, it gives you a number of different lenses to look at Ruby development through. When you combine them together, they work to fulfill the common goal of writing better code. However, as one person, the number of different vantage points I can offer are limited, even with help and suggestions from my friends.

The Ruby Best Practices blog is meant to continue this idea along, but open it a bit wider so that the necessary diversity is preserved moving forward. I'm convinced that the group I've put together will do a great job of this. As near as I can tell, best practices and idioms tend to emerge from open discussion about real problems, evolving over time as the technology and the challenges themselves change. In this sense, the RBP Blog is a logical continuation of the work I did on the book, and I'm really hoping the two can be complimentary to one another.

Any chance of seeing some of the material you cut from the book on the RBP blog?

Gregory This is a definite possibility. Unfortunately, I am a terrible historian and actually just deleted large chunks of the book when they didn't fit. That means that while the topics I cut from the book might be covered on the blog, it'll likely be new content. But I also want the blog to have a life of its own, so maybe I'll just start fresh with my posts. Time will tell.

I love the section 'Capturing the Essence of a Defect' in chapter 6. In the Perl world, there's a tool called Delta to automate some of this, but it seems like building a tool on top of the AST would be better than delta's text munging approach. How many debugging/refactoring/code analysis best practices do you think are automatable? What do we lose by automating them?

Gregory Honestly, I have no idea. It's probably not the most geek-friendly answer, and not even something I'd recommend in my book, but I very much work by intuition when debugging. I'd definitely give code analysis tools a try if they were out there, but honestly, if I really need a tool for refactoring or debugging, my code might be excessively complicated to begin with.

This isn't to say that I try to stick to simple projects or that I think I have a Herculean ability to keep all these details in my head. Neither would be true. In my current work, I'm developing a fairly massive Rails based ERP system for a food distributor. It's really a huge problem space, with all sorts of complex challenges both at the technical and business level. Maybe over time, some code analysis tools might make our life easier, but for now we're attaining simplicity the old fashioned way. By splitting up the project into various single-purpose applications that have decent test coverage and clean code, we can still rely on intuition somewhat when working through problems. The only really tricky bit is managing the interactions between systems, and maybe that's a place where some analysis tools might be helpful.

The real danger I see with using automated tools for debugging, refactoring, and code analysis is that you can become too dependent on them. This may encourage you to manage complexity rather than reduce it, and in my opinion, that's treating the symptom and not the disease.

I'm also happy to see a chapter devoted to Functional Programming with Ruby. Is a chapter enough, or should Rubyists be looking for 'Higher Order Ruby' or playing with Haskell/Scheme/OCaml?

Gregory Much of this chapter was sourced from James Gray's Higher Order Ruby blog series, which I can't recommend enough. To be fair though, the chapter is less about functional programming than it is about writing Ruby code that's inspired by functional programming techniques. Ruby is not a great functional programming language, and no amount of parenthesis will change that. However, the higher level concepts are valuable, without a doubt.

For those who wish for a more intense experience, you might want to dabble in Haskell and maybe some Erlang. I'm not very experienced with either language, but even a couple weekends of hacking in a functional language can expose you to a lot of interesting concepts that you can bring back to Ruby with you. While a direct translation will surely lead to disaster, some indirect inspiration can go a long way.

But of course, the real reason why I covered functional programming in this book is because it's a lot of fun. That's my best reason for why people should learn more about it. :)

You've been in the Ruby community for a long time, and have even been involved in some efforts to 'bring back the good old days'. What changes in the Ruby community do you enjoy/appreciate? Which changes would you like to revert?

Gregory Personally, I think it's about time we stop asking this question. That may sound like a bit of a surprise coming from me, but it is really how I feel. I've learned over the years that what matters to me most is to solve interesting problems in an elegant way while remaining in contact with bright and fascinating people. Despite all the hype, anti-hype, and anti-hype-hype, none of these things that matter to me have changed.

If we work hard, manage to be kind to one another, and share with each other, we'll have a good community experience. Nowadays, I think you'll find the old-school spirit alive and well at regional conferences, in various Ruby-based open source projects, and on the mailing lists of local Ruby users groups. With this in mind, it doesn't matter so much to me what the global state of the Ruby community is like.

One thing we did lose the ability to drink from the firehose and know everything that was going on. However, that opportunity is still available at the ground floor of a number of languages that are only on the horizon of mainstream acceptance, or off the radar entirely. I'd recommend some, but that'd sort of defeat the point, huh?

So far, you've been a GSoC student and a Mentor, the Ruby Mendicant, and now you've written your second Ruby book. What's next for you?

Gregory I'm not sure how many people know this, but I'm only 23 years old. Since about 2004, I've been more-or-less dedicating my life to Ruby. It's been a blast, but it also feels like it has isolated me a bit from the outside world. So, next on my agenda is to find a reasonable work-life balance that will be sustainable moving forward. I want to spend more times with my friends and family, and my girlfriend Jia, who I plan to marry sometime soon. In short, I want my geek hat to be one I can happily wear when I want, but hang up when I'm feeling tired.

But that doesn't mean I'll disappear. The book and new blog will need to be promoted, and my projects need to be maintained. I'm hoping to see a Prawn 1.0 by the end of the summer, which I'm sure would make a lot of people happy. I'm also going to be talking at GoRuCo this year, which I'm really looking forward to. Beyond that, I guess we'll see what happens.

Click here to Tweet this article