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.
No comments:
Post a Comment