The recent best-selling success of the 'Pickaxe' Ruby guide and Agile Web Development With Rails has been a jolting wake-up call to the relatively dormant technical publishing industry. Although the Pragmatic Programmers were first from the gate, every other publisher is now catching up fast with new books (or revised old gems like The Ruby Way) and even brief digital shortcuts distributed only online. More than introducing Ruby to the world, this movement is creating a new wave of technical authors. Jacob Harris is the author of one of Addison-Wesley's first new Ruby titles - "Rubyisms in Rails" - released as a digital shortcut in September. A longtime infrastructure developer, Jacob ran into Ruby through an early version of Rails and liked what he saw. He started writing a blog, read computer books voraciously, became involved in the NYC Ruby Users Group, and hacked Ruby as a relief from his day job coding C++. Recently, he left his longtime employer to start working at New York Times Digital, where he hopes to shake things up at the Gray Lady.
How did you discover Ruby?
Jacob: As I said before, I ran into Ruby through an early version of Rails (I think it was 0.4 or something). I wasn't just looking at languages however, I decided I needed to play catch-up on a whole bunch of trends I had missed in the last 8 years (e.g., design patterns, dynamic languages, agile development, etc.). Then, as now, I found the best way to keep up with the zeitgeist was to add a bunch of feeds to my aggregator and soak it all up. This is how I stumbled into the Pragmatic Programmers and Chad Fowler particularly, whose book My Job Went To India
What role does Ruby play in your day to day work?
Jacob: Well, I've only just started at my new job, so it's a bit early for me to be making declarations. But I'm sure there will be a place for Ruby here. Rails is a promising web framework that would be good for both internal and external applications. But Ruby in itself has insanely great potential as an "enterprise" glue (where you have many disparate databases and applications to tie together). It's also good to see big consultancies like Thoughtworks raising awareness of Ruby as large-scale development language.
Still, I've always considered myself more of a Ruby dilettante than a hardcore hacker. I am humbled to be in the same company as Hal Fulton here! My previous job was coding in C++, so I had to squeeze all my Ruby hacking into my spare time. I'm just now coming into using Ruby in my real work, and it's an awesome feeling.
How did you come to write a book about Ruby?
Jacob: Last March, I decided it would be good to practice giving a presentation because I've never given a talk, so I signed up to give a talk to NYC.rb. Initially, it was just going to be a talk on some particular tips for people new to Ruby from PHP or Java. But as I began to cast about for examples of distinctive Rubyisms like blocks or metaprogramming, I found I could find good example code within Rails itself -- all of it silently operating just beneath Rails' frontend. All of which made for some excellent real-world examples of what Ruby can do.
Anyhow, it was a fun little talk, very well-received, especially when I posted it on my blog with readers around the globe (I seem to have particular fans in Taiwan). I had already met Debra [my editor at Addison-Wesley] through NYC.rb and I had been reviewing book proposals for her. When I heard in May she was looking for writers in a new series of shortcuts on Ruby, I thought it would be fun to pitch my proposal. Especially since I felt I could turn it around for her to sell in time for Railsconf in June. I was rather naive though, in that the whole process of writing-editing-revising-reviewing took me three months longer!
What other libraries have you peered into and found great code to look at?
Jacob: Hmm, this is a good question. I really like what Eric Hodel has been doing at Robot Coop. He built all these geocoding API stubs on top of a REST client he wrote (dev.robotcoop.com/Libraries/). Anything _why writes is amazing to read as well. Jim Weirich's XML Builder is also really cool, and I should probably look at Ruse as well. In any event, I'm just starting this process myself and I'm sure readers might be able to suggest some other wonderful living examples of Ruby code to read. I suppose we could even create a website where people could write about code like critics wax rhapsodical over movies or music.
I seem to recall there used to be a Computer Science course way back in the early days of Unix where the professor just printed the source for BSD and taught off the source, with yellowing pages of printouts being passed from student to student. I don't remember more than that (I'm not that old), but it's a lovely idea and kinda what I'm talking about. You don't learn how to code by reading documentation, you learn it by reading source. It's like a remote mentorship or rather a fellowship of those who really understand.
What sets your book apart, why should people buy it?
Jacob: My book is targeted to those coders who have reached a particular level of Rails experience. They've created applications and are maybe even lucky enough to be hacking Rails in their job. But they still have yet to become fluent in Rails and write code that resembles some sort of Ruby-inflected Java or PHP more than natural Ruby. Furthermore, they might have the nagging suspicion that Rails is just too "magical" and want to learn more. This book draws aside the curtain a little to explain how things work and illustrate how Ruby is coded in a real-world situation.
)]) on the same subject, but I think there is an advantage to my book's brevity as well; it's a very easy book to pick up and pass along and I think it provides enough insight and inspiration to give readers a new way of looking at Ruby.
What was the most rewarding part of writing your book?
Jacob: Computer books are boring. It's just all too easy to fall back on pages of function arguments or code snippets beating your readers' brains into submission. So for me, the most rewarding part was figuring out how to make it interesting. Here, I hatched a silly conceit of the book being a road trip. Which then let me formulate smaller metaphors of iterators as highways, DSLs as road signs, and other things that hopefully made it as fun to read as it was to write. I really hope the personal tone comes through, and it's been rewarding when people write me to say they liked it and it really helped them make sense of how things work.
What was the biggest challenge in writing it?
Jacob: Finding the time to write is really the hardest challenge. Writing turns out to be very much like coding; some days you're in the flow state cranking out pages of text, and other days you can barely manage a few sentences. This is particularly agonizing when you can only schedule a bit of writing time here and there. You'd think a 54-page book would be a walk in the park, but it still involves several iterations of writing-edits-revisions. It is an excellent preview of the process of writing a full book, and I highly recommend it if you ever think you want to write a book yourself. The other main challenge is keeping things brief. I think the initial draft was actually about 70 pages, but I spent a significant amount of time cutting it down to 2/3rds the size. Given that these ebooks sometimes seem to be sold by the page count, I'm glad my publisher never put any pressures on me to make it a certain length or pad it out.
What did you learn from writing it?
Jacob: Mainly, I realized how little I knew Ruby and Rails. I had dabbled around with Rails, but like many developers, I had been content to treat its whole interior workings as a black box. And when I started to look more at Rails' innards, I realized I didn't know a lot of the cool stuff in Ruby they were using: things like metaprogramming, runtime evaluation, domain specific languages, etc. Socrates once said "True knowledge is knowing you know nothing," which meant I was the wisest person in the world. In any event, I think that actually helped, since I was targeting it at newcomers to Ruby and I realized I was a newcomer myself. Which I guess is another point: know your audience. I don't think Socrates said that, it's too _creative writing 101_ for him to say. But it's true. And don't be afraid to be personal; I've noticed that saying _I_ a lot makes it a lot easier to write; I only hope it makes it good to read!
You mentioned that you've been reading voraciously. What five books (Ruby or not -- shoot, technical or not) do you think Ruby and Rails developers should be reading today?
But of course, there are a lot other cool books that didn't quite make the cut. Some of which are worth it just because they moved my thinking in a particular direction; some because they are very well-written; even some that completely and utterly useless for my job but transmogrify how I think (eg, the Wizard book).
In any event, I'd recommend that technical books are less than 50% of your total reading. You can learn more from a good history book or even a well-crafted novel than 10 technical books sometimes, and you'll be a better person for it as well. We are more than mere hidebound coders. But I'll get off that soapbox for now.
Before you hop off, what are the last couple of non-technical books you've read that you really liked?
Yeah, I guess that's way more than a couple. Let's call it a Baker's Couple I guess.
What are your favorite five libraries for Ruby?
Jacob: Okay, I'll be brief here: Builder for making XML generation easy; FeedTools for taking a stab at Atom/RSS support; Rubyful Soup for more fun XML; ZenTest (and RSpec as a bonus!) because I really, really, _really_ should be testing more; and Camping for keeping it fun.
What do you think is next for Ruby?
Jacob: This is an interesting question. Depending on who you talk to, Ruby seems to be at a crossroads between being a small "hobby" language and the next big thing after Java. I think we will see growing interest in Ruby within the corporate world, although this is freaking the hell out of some people especially in the Rails community. But I honestly think Dave Thomas has it mostly right; Rails has to work with legacy databases or other _enterprise_ environments if it wants to be used in places (like the Times for instance) where you can't just start from scratch; but I sympathize with DHH at the same time, there needs to be some pushback to keep it from getting too bloated and compromised. Still, I think Ruby beyond Rails could really be helped by more professional attention to fill in areas where Ruby's libraries are weak. So, Sam Ruby at IBM has been doing some serious work to support Atom, and I think Ruby could use some outside help to get the same level of fast and fully-featured XML support you find with Java or Python. I've also seen some interesting arguments over whether Unicode has a place in the heart of Ruby. One thing I like about Ruby though is that it's so easy to extend even core libraries that you don't have the same pressures to turn the core language into some bloated Enterprise Edition version; people can add what they need on their own.
But the real next thing for Ruby is the performance problem. Yeah, Joel Spolsky is being a twit here, but Ruby _is_ slower than you want sometimes. Even die-hard Rubyists sometimes have admitted a bit of dismay at how long it's taking for YARV to arrive. Sure, I could write C extensions for slow parts, but most of us went to Ruby to get away from C! For the sake of an example, it does irk me somewhat there are like 4 different opcode caching options for PHP at this point for instance. I'd like to see something similar for Ruby. JRuby seems like a promising initiative too, now that Sun is supporting it (another positive example of corporate involvement). I don't doubt that YARV will ultimately be great, but I'd like to see what other cool things happen. Don't get me wrong: Ruby is amazing, but super fast amazing Ruby would be incredible!
What's next for you?
Jacob: It'll be interesting. I can't really say a lot, but the Times is really poised to do some great things in the years ahead, and I will be part of it. So, hopefully you'll be hearing more of me soon. See you at Rubyconf!
Technorati tags: Ruby interviews
No comments:
Post a Comment