Author Interview - The Well-Grounded Rubyist

Now that Manning has released The Well-Grounded Rubyist by David A. Black, I wanted to sit down with him and talk a bit about his new book.

His Ruby for Rails set an awfully high bar as the book that really explained Ruby to Rails users (and everyone else). The current title has been called a "reworking" of the former to remove the Rails bias.

Hopefully this interview will whet your appetite for David's new book.

---

Ruby For Rails has been one of my favorite Ruby books since it came out. I'm really excited that The Well-Grounded Rubyist is coming out in a matter of weeks. What do you think is the best thing about your new book?

David The title! Well, not really, but I do love the title, if I say so myself. (In case anyone's wondering: I did take inspiration from "The Well-Tempered Clavier".)

As for the material and the content: I have always found it gratifying when readers single me out as someone who can explain things clearly and in depth, and I believe TWGR delivers in that area pretty much throughout. I spent thirteen years as a full-time teacher, and I've been writing all my life. I love helping people understand things, and that's what I've worked most diligently at doing in this book.

You call your new book a repurposing of Ruby For Rails. How do you approach Ruby differently when writing for a Ruby developer rather than a Rails developer?

David To a large extent it's a question of the topic coverage. TWGR maintains, I think, very much the same "voice" as R4R, and addresses the reader at the same level. But the topic coverage has changed a lot — and not just because Rails has been taken out. There's material in TWGR on threads, sockets, sets, encoding, enumerators, and more, none of which were in R4R, and greatly expanded coverage of other built-in functionality include file I/O, ranges, system command invocation, and others.

Selecting topics was a big part of writing R4R, since the whole point was to write a Ruby book that was "optimized" for a certain readership. And as I started thinking about TWGR, I realized that careful, creative topic selection was important for a "just Ruby" book too. I wasn't setting out to write a complete language reference, so the process of deciding what to include loomed large.

You take a pretty different approach to explaining Ruby than most other authors/speakers. What do you think makes your approach work so well?

David Typically, introductions to class-based object-oriented languages, including Ruby, start by talking about classes, and then bring objects into the picture as instances of classes. I look at it the other way around. The object is the fundamental unit of meaning in Ruby, so why not start with that?

Furthermore, I like to put object dynamism on the radar very early — the fact that objects are not constrained to the abilities they derive from their class but can take on behaviors of their own. Of course most Ruby developers don't spend their days writing

 def dog.bark

and such. But I do believe that if you learn about objects and their life-cycle first, and then look at classes as a kind of convenience macro for spawning objects, your knowledge of Ruby will build smoothly from there, and you won't think that object-specific behavior is a blemish.

A lot of publishers are opening up the book writing process these days. How much did Manning's MEAP affect your book?

David I'll do a bit of soul-searching here, if I may. I'm a very territorial writer. I don't like the idea of leaving a paper trail showing what I later decided to change or fix or improve; I think of writing as a basically closed-door artistic process, and just as I don't want people listening in while I'm practicing the cello, my instincts run strongly against releasing unfinished written work.

I have, nonetheless, tried to get into the spirit of the open-process era, because I think it's been proven effective for technical writing and because I know that a lot of my territoriality comes from my temperament rather than from concern about the final product. Besides, even without the MEAP, the manuscript is sent out to a body of twelve or fifteen outside reviewers at three points along the way — so the "closed door" isn't all that closed anyway!

So I've participated in the MEAP, probably not plunging into it as fully as some authors do but trying to meet it at least halfway, even if it means leaving (or, perhaps, expanding) my own comfort zone. I think the book has benefited from it.

So far, you've had your hand in books, videos, conferences, and training. What does the future hold for you?

David Don't forget programming :-) As for the future: I've started working on a book for the Pragmatic Bookshelf, entitled "Rails Choices". It's a guide to how to think about and make sense of the many possible choices (and it's an increasing number, as we get toward Rails 3) that face developers and project managers when they're starting a Rails project: everything from which version of Ruby to use to which templating system to which session storage mechanism. I'm not going to try to cover every possible choice; I'm sticking to the out-of-the-box defaults plus a select handful of proven, popular alternatives. I want to get beyond the personal preference level, and help people examine the needs and priorities of their specific projects, and make choices based on that.

In general, I'm finding my multi-faceted Ruby-oriented life very rewarding and enjoyable, and I'm hoping for more of the same.

A lot has changed in the Ruby world since R4R, which of those changes are you most happy about?

David I'm happy about the fact that Ruby is in much wider and more prolific use, and that we have so many books and events. (I don't think any other language has as vibrant a world-wide conference culture as Ruby.) It's also great to see that the "What's this 'Ruby' thing?" syndrome among Rails developers has dwindled; just about everyone seems to understand from the outset how Ruby and Rails related to each other (and if R4R helped bring that about, I'm delighted).

I'm excited about the new Ruby implementations — JRuby, Rubinius, and others — and the coming-of-age of Ruby 1.9. As everyone knows who's followed along, the path to 1.9 has not always been smooth, but 1.9.1 is stable (that's the version the book addresses) and as I've delved into it more and more deeply, I've been more and more impressed by it.

Which ones impacted The Well-Grounded Rubyist the most?

David I choose:
(e) All of the above!

It's true actually. The wider adoption of Ruby is largely responsible for my enthusiasm about writing the book. The way the Rails world has come to terms with Ruby, to the mutual benefit of both, made me realize that a general Ruby book could also be "for Rails", in the sense that many Rails developers are eager to learn as much about Ruby as they can, whether every bit of it pertains directly to the bulk of their Rails work or not. The new Ruby implementations don't enter into the book directly, but it's hard not to feel inspired by that work, and many discussions surrounding implementations have touched on topics in ways that have probably affected TWGR.

And Ruby 1.9 — that's the main event, the major impetus for writing the book. It's been hard, because things have been changing a lot. Sometimes I'd write an example and then discover a few weeks later that the wording of some error message had been altered, or that something had shifted in the core class hierarchy. (I'm thinking specifically of Enumerable::Enumerator becoming just Enumerator.) It's been a moving target at times; but all the more thrilling is it for the book's timing to be such that it can address a stable 1.9 version while there's still a lot to learn and a lot of excitement.

What do you see happening in the Ruby world over the next year or so?

David Very hard to say — which is probably good, since it keeps it interesting. I think that Ruby 1.9 will achieve a lot more penetration. And we're seeing a lot more Ruby implementations, some based on the Matz code and some not. I don't just mean JRuby and Rubinius, but MacRuby, Ruby Enterprise Edition, MagLev, and others. I suspect we'll start seeing specialized subsets and forks of Ruby that aren't necessarily compatible but that are "Rubies", the way different LISP dialects are "LISPs". I think Diamondback Ruby is in that category, though I haven't looked at it closely.

In any case — here's hoping we have many more years of Ruby practice, experimentation, collegiality, and productivity. It's certainly been fun so far!

Click here to Tweet this article