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

Ruby Best Practices: mini-Interview 2

As Gregory Brown (@seacreature) and I discussed the Ruby Best Practices Contest, we also talked about the current state of Ruby Best Practices (or get the Rough Cut). You can read the resulting interview below.

Before we get to that though, we should announce the tow winners of the contest: Jamis Buck (actually entered by Daniel Berger) and Eric Hodel. Eric and Jamis both get free Rough Cut Access to Ruby Best Practices — who knows, they might even find some of their own ideas in there.

---

How is the writing process itself going? How are you dealing with feedback from readers/reviewers?

Gregory The process we've put together really seems to be working. When I first pitched the book, I set the pre-condition that we'd need to have a broad panel of advisers from the get-go. If this book is going to have the title "Ruby Best Practices", I want it to be able to stand on more than my own name, for sure. So I asked a few of my friends, a few of my students, and a few folks I think of as truly masterful Rubyists to be part of an active review process. So far, that has been working really well.

Every chapter gets two levels of review, at a minimum. I start by posting to our internal reviewers a plain text file and a PDF, and collect their comments. After a about a week, I make revisions based on their suggestions and send things off to O'Reilly for a RoughCut update. Usually within a day or so, the changes hit Safari and those who pre-ordered the book can comment on them. That group has already caught a couple problems and made suggestions, so it's definitely useful to have more eyes on the content. I think it's really important to release changes as often as possible, to encourage further review. Of course, we use some great tech to help us with that.

Because the book's sources are in Asciidoc, there is no separate typesetting process. My plaintext files are the same source that the PDF is generated from. This means I can make whatever revisions I want whenever I want, and I don't need to be worried about getting bogged down by the formatting. We can also go back and make changes to old chapters later on without much worry.

So far, O'Reilly has basically let me run things exactly how I wanted to, and it has been working out great. Fast, tight iterations will help make the book grow organically based on the input from our internal reviewers as well as the wider reader base. That's what I'm hoping for, anyway.

I hear that you're converting testing examples from RSpec to Test::Unit is pretty huge. Why are you making the change?

Gregory Oh, for the "Driving Code Through Tests" chapter? I just sent that out to the internal reviewers, so we'll see what they think. :)

But actually, it was their suggestion. The initial RSpec based chapter was meant to reflect the change in the tides in the Ruby community, but it wasn't too hard to convince me that I should reconsider things. I used to think RSpec was easier to teach than Test::Unit until I wrote a chapter about it, and found myself having to show reference implementations of how things like foo.should be_bar work, whereas assert foo.bar? needs no extra explanation. I had to explain what a proxy object was for folks to understand how to build custom matchers, and what a lambda was for people to know how to test their exception raising. I'll be blunt, that sucks.

But to be fair, I use RSpec for a good bit of my work, and I think it's okay once you get the hang of it. But the ideas I wanted to express in RBP weren't really tech-specific. I was mostly talking about overarching strategies like keeping your tests atomic, writing some helpers here and there, that kind of stuff. So some of the 'features' of RSpec were actually getting in the way. Test::Unit (well, now minitest/unit I guess), is standard Ruby, is dirt simple, and was able to demonstrate the strategies I wanted to share with folks with less magic.

So, maybe it's not such a big change. RSpec, Test:Unit, Minispec, Test:Spec ... How much does the specific tool really matter versus being serious about using it?

Gregory The interesting thing is I didn't really need to change the chapter much, aside from translating the source. Some sections were dropped and others will be added in, but for the most part, it's the same chapter and it follows the same general blueprint. This really underscores the fact that what matters are the ideas behind testing, not the technology. I'm hoping the reader will benefit from the simplicity of Test::Unit for my examples, but then take the knowledge and apply it wherever they want, whether it be to RSpec, Shoulda, or whatever it is the cool kids will be using when the book hits the shelf.

I think the specific tool matters, but only when it comes to comfort, not concepts. It's arguable that certain frameworks encourage you to embrace a concept more than others, but I don't think that's as big a factor as people might think.

How important is mocking as a Best Practice? What about Stubbing? Where do they fit in relation to each other?

Gregory Well, I think that mocking and stubbing are both pretty important when you need them, and completely worthless when you don't. I've seen systems in which every interaction with every other class was fully mocked out with all the behaviors specified. These systems are absolutely nightmarish to work with, because the tests become so brittle that you need to re-write your giant, complicated mocks every time you refactor. Tests should aid in refactoring, not get in the way, whenever possible. I've also seen (*cough* written *cough*) systems that stub out so much and produce canned results for everything which gives you wonderful passing tests but, well... don't actually test anything.

But of course, responsible use of mock objects to minimize your dependencies on expensive external resources can really help make your tests run faster and more clearly show what's going on. Stubbing out a method here or there to prevent you from testing things you don't care about can definitely be helpful. In general, I prefer to use whatever technique is the right combination of cheap, fast, and easy. That combination changes wildly from project to project so anyone who tells you that you should never make use of mocking / stubbing is crazy, and so are the people who want you to do it all the time.

As far as where all these things fit together, I think that's more a question for folks with a stronger grasp of theory than me. The best I can do is point you at Martin Fowler, then tell you that I don't really care about their distinctions at the high level. I only care about using the right approach for the job. Libraries like flexmock that intentionally blur the lines between mocks and stubs are great in the hands of responsible users, if you ask me. :)

While Ruby Best Practices is going to end up Free, O'Reilly has even more open in the writing of a couple of other books that are cropping up. How does this go 'round compare with your completely open work on the Ruport Book?

Gregory Well, the Ruport Book taught me a lot, both good and bad, about writing a community oriented book. The idea of having an internal review team is something we had on the Ruport Book as well, and I carried it on to RBP. It seems like because the topic is more general, this has worked out much better on this book than it did for the Ruport Book, simply because most of my internal review team knows a hell of a lot more about Ruby than I do!

But the Ruport Book and RBP are two very different books, so it's hard for me to compare them.

I'm having difficulty expressing my feelings on this, but basically, the way this book is formed in my head doesn't feel much like a textbook. It's more like a quasi-fictional narrative "based on a true story" with notable mentions of various Ruby hackers and their projects. It's sort of like I've stitched together a series of blog posts so that it bleeds into this textbook undercurrent. The book is meant to be read from cover to cover, or at least in whole chapters. This makes it tricky to make wide open in the early phases.

But once the work is done, I want it to be able to bend under the pressures of peer review. I want people to be able to freely use and remix what I've done, however they see fit. And of course, that's already planned to happen and so it will, it will just take some time.

I believe it can be a virtue to keep something a little quiet until you know for sure where it is going. It's sort of like waiting to do a first release of an open source project until you clean up the code a bit and make it useful and approachable to others. That's exactly what I'm doing with RBP now, and hopefully, that will benefit those who might be interested in contributing to the book down the line.

Lots of people coming into Ruby from other languages bring Best Practices (and sometimes Pessimal Practices) with them. What languages/communities do you think offer the best opportunity for finding good practices for Ruby?

Gregory That's a good question. I don't really know. I think we end up getting more bad patterns than good from other languages. This isn't to say anything bad about other languages, but it is to say that best practices aren't always transferable. Look how many patterns from Java aren't even remotely relevant in Ruby. Or how many cool functional programming techniques fall down and die when you try to import them. I think maybe the fact that we only got a few responses to our blog contest here was an indication of that, to some extent.

However, I think many communities within Ruby are a hotbed for best practices. RBP draws almost all of its key points via the influences of notable open source Ruby projects. Rails utterly changed the way people write Ruby, in many ways for better, in other ways for worse. Merb has really made me re-think issues like performance. Smaller libraries also pack a punch. FasterCSV is the source of a lot of inspiration for me, and in turn, I think FasterCSV has been influenced to some extent by Ruport. After-all, it has its roots there, anyway.

So if you pay attention to the conversations between well trodden Ruby projects, both in words, and in code, you'll see a whole lot of great strategies emerge. My hope is that this book will give people a snapshot of some of them so that they can pick up new skills in the way many of us hackers are doing: One new patch at a time.

I see that you've set up a twitter account for RBP. How do you think that will impact the book?

Gregory It'll motivate me a little to keep posting updates, give me a way to keep people informed about book related news (such as this interview), and give readers (or potential readers) a way to connect with me and share their thoughts. I'm not a big twitter addict, but I'll at least let people know when to expect new content and whenever something I think might be interesting comes along. Beyond that, I guess we'll see how it goes.

A 'Ruby Best Practices' Blogging Contest

Update: Due to the holiday press, Gregory and I will not be able to judge this until early 2009. That means everyone has an extra two weeks or so to submit an entry. We'll close up submissions on Jan 9, and announce the awards on the 13th.

Okay, best practices are a good thing, and Gregory Brown's upcoming Ruby Best Practices looks like it's going to be a good book. The question is "Are your best practices good for Ruby?".

O'Reilly has offered up two free 'tokens' for free rough cut access to Gregory's book for me to give away. Gregory and I talked about how we could best use them and decided to run a quick contest. We'd like to have you write up a blog post about a best practice that you've used with another language, or in another community, and how it would translate into Ruby. Talk about why it would help the Ruby community, or talk about why we should avoid it. Then, come back here and post a link in the comments below.

Be interesting, be controversial, but be quick. Gregory and I would like to award our two prizes before December 19th so that you can claim your rough cut before the end-of-December holiday of your choice.

Ruby Best Practices: mini-Interview 1

In case you hadn't heard, O'Reilly has recently released Ruby Best Practices, by Gregory Brown, as a rough cut. This is one of those book that the Ruby community has been waiting for, even if we didn't know we were waiting for it. Not only is Gregory a great person to write a book like this, he's the kind of person who's going to make sure it does the most good for the community as a whole (read below and you'll see what I mean). Right now, we have the opportunity to grab a rough cut and help make it better, it seems like the least that we can do.

This is the first in a series of short interviews I'll be doing with Gregory as the book progresses. Please feel free to drop a question or two in the comments, They might make it into the next interview.

---

Let's start by talking a bit about code and community. You've been a GSoC student and mentor, you were the Ruby Mendicant, and now you're writing Ruby Best Practices for O'Reilly. Tell us a bit about this journey and what you've learned along the way.

I can sum it up very briefly, I'm simply doing my part to pay it forward. I've had wonderful mentors and teachers along the path I took to get me where I am today. Each one of these folks has never asked me for anything in return, but I'd feel far too selfish if I just kept their knowledge for my own personal gain. So GSoC, Ruby Mendicant, and RBP are all ways for me to turn whatever good things I've gained from the people who have helped me over the years into something I can pass forward onto others to enjoy.

I've learned so much over the last few years that it's very difficult to summarize. If you want to know about technical details, I'd say: Writing reporting software is harder than I thought (GSoC), writing a PDF generator is harder than I thought (Mendicant), and writing a book is harder than I thought (RBP). So these things lead me to believe that a strong ability to underestimate complexity combined with an obsessive compulsion with tackling certain problems can turn into a virtue in the right circumstances.

One of the things that I really like about your plans for the book is that it will eventually become a Creative Commons resource to the Ruby community. Why did you decide to do this, and how did you caonvince O'Reilly to go along with it?

I don't see how anyone could write a book that claims to curate "Best Practices" without making it as accessible to the community as possible. Rather than writing this book with the intention of having people think "Hmm, Greg is pretty smart, I will trust what he says", I wanted to foster a healthy level of skepticism so that the work can grow beyond its original content. What might be considered a best practice now won't necessarily be that way a few years from now, and getting the book under a Creative Commons license will help facilitate the necessary changes and make it easier for people to openly question and improve the work.

Because we chose the by-nc-sa license variant, O'Reilly was pretty easy to convince. My editor (Mike Loukides) was more than happy to go down that road. It felt as if there would be some tension if I removed the non-commercial restriction, but this is where you get into the murky territory of whether that removes an incentive for the publisher to support the work, and that's a whole other can of worms.

I'm just happy that 9 months after the book is on the shelves, if you want to print a few copies of it to share among folks you work with, or if you want to translate the book and put it on the web so more people can read it, or if you want to quote a large section of it so that you can pick me apart on your blaag, you can. This will make the book better, and prevent it from losing value over time.

Of course, if during the Rough Cuts period or first 9 months of the book sales people really get behind it and buy copies, that'll make me happy. Not only will I benefit directly from purchases, it'll help encourage O'Reilly to do more of this in the future. But no matter how good or bad it sells, it will certainly have more value once it goes out of print than most books under traditional licensing schemes do.

As part of your own Ruby best practices, I'm sure that you've built a set of tools that you rely on. Can you name a handful of them and why you think they're so important?

Using the right tools for the job definitely makes a difference, but I tend to be a bit of a minimalist. I get by fine with extensive use of rake, irb, and a decent text editor (TextMate on OS X, vim elsewhere). Having nearly everything in revision control under either svn or git means that I've got a large library of my own code (often complete with tests/specs) to refer to which helps me remember how to solve particular problems without having to refer to books. Of course, having written a lot of mailing list posts, API documentation, O'Reilly OnLAMP articles, and the Ruport Book, I've got a lot of explanations in my own words reminding me how to do the things I need to as well, and I tend to use these resources extensively.

Also, when my tools come up short, I can always stand to learn more from some of the smartest folks in our community. Since I'm not bashful about asking for help, my two most valuable tools in software development are email and my IRC client.

This answer may be a little boring, because I'm not one to hunt down the next latest and greatest tool to fix a problem I never knew I had. A simple work flow that involves doing some custom scripting when necessary seems to work best for me.

I've been going back through Code Reading by Diomidis Spinellis recently. I'm really sold on the idea that reading great code can us write better code. What are some code bases you'd recommend readin and what can we learn from them?

I've not yet picked up that book, but I imagine I should. Reading code is a great way to learn, and this is exactly what folks will be doing when they read Ruby Best Practices. I'm picking from my favorite bits of real code, some of them are my own, but many are not. For the functional programming chapter I'm writing right now, I had a fun read through MenTaLguY's lazy.rb and picked up some really interesting ideas for writing transparent proxy objects. I've also been digging through JEG2's Higher Order Ruby blog series and learning a ton.

Because Prawn was written concurrently with my initial work on Ruby Best Practices, and will continue to be a source for examples and case studies throughout the book, I recommend folks to check it out. PDF is a low level domain and that means there is some necessary complexity, and because things are moving fast they get rough around the edges at times. However, many parts of Prawn represent my best effort at writing masterful Ruby code, and I think people might pick up some tricks by reading through its source.

But really, people don't need to be so picky about what they read. Look through the source of every gem you've got installed if you have the time to! Try to think about why people wrote their code the way they did, and pick up some of the stuff you think you can groove with and try it in your own code. Sometimes, the coolness is lost in translation, other times, it's exactly the sort of inspiration you need.

If you want to get stronger at Ruby, don't just read API documentation, read the source of the code you use. You'd be surprised how much cool stuff there is out there.