Hal Fulton is a longtime Ruby hacker and the author of one of my favorite Ruby books, The Ruby Way. Recently, he's been hard at work on a second edition (due out in November). The second edition will come with a change in publishers, The Ruby Way will now be an Addison-Wesley book. When he's not working on his book, Hal is active on the ruby-talk mailing list and in the Ruby community at large.
Besides Ruby, his life consists of reading, writing, movies, plays, and concerts. A member of Austin Scriptworks and had his first play produced early in 2006. He's also a huge space advocate, and lives with a cat named Meg (short for Megabyte). He visits his parents whenever he can. They say they're not getting any younger, but sometimes he suspects they are.
Hal and I have known each other for a while, we even worked together on the t-shirt for RubyConf 2002 in Seattle — Ruby in the Emerald City.
How did you discover Ruby?
Hal: I was at IBM in '99 and was talking to Conrad Schneiker. He is the one who got comp.lang.ruby going (and if you're an AIX user, he's the inventor of the smit utility). I complained to him that I was never on the ground floor of any new technology. I was a late adopter of everything, and I wanted to change that. And he said, "Well, you should learn Ruby then." It was the first time I had heard of it. I started reading the mailing list; this was mostly Japanese people speaking English, although there were these two guys named Dave Thomas and Andy Hunt hanging out there. Later on, they came out with the first Ruby book in English.
What role does Ruby play in your day to day work?
Hal: My regular job is on the usage data warehouse team for a telecom company. I have sneaked Ruby into production wherever it's practical. It's used in our control and status web page, in numerous little convenience scripts, in test harnesses, and in a few Oracle apps.
As one of the really early birds, can you tell us a bit about the Ruby community 'back in the day'?
Hal: When I started learning Ruby (version 1.4), I could find *one* Ruby tutorial on the web in English. There were no books in English. I had a friend Miho who went back to Japan to visit family; at my request, she bought a Japanese Ruby book for me (one by Matz). I couldn't read the commentary, but I could read the code and learn from it.
The newsgroup hadn't been approved yet. The mailing list had perhaps 10-20 messages a day if I recall correctly.
Ruby didn't have class variables. The standard way to fake them was to use an array or similar container class.
Google searches for Ruby at that time returned numerous things unrelated to the language. You would have to go several pages into the results before you found relevant links. There was little on the web in English. There was no RubyForge, no RubyDoc, no RubyCentral. The first international Ruby Conference was nearly two years into the future.
There were fewer standard libs. There was no REXML, no YAML, no RMagick, very few web tools.
There was no "one-click installer" for Windows. The best way to run Ruby on Windows was to use Cygwin or the mingw version.
And our computers ran on kerosene, and we walked five miles in the snow to get printouts, and it was uphill both ways.
Do you have any hints about sneaking Ruby into the workplace?
Hal: I've always used the trickle-up method. Start using it for one-off scripts. Then use it for little convenience scripts and tools. Then use it for glue code. Then start using it in testing. Then web development. Then less-important production code. Finally one day you are using Ruby in mission-critical apps in production, and your bosses may not even know. It's easier to get forgiveness than permission.
How did you first come to write a book about Ruby?
Hal: I was one of the first N Americans to learn Ruby (for some small value of N). So when Sams went looking for someone to write a book, I was one of the ones who responded. At first, I had a coauthor; he wrote pieces of the first four chapters before leaving the project.
How did you swing the second edition?
Hal: I didn't really swing it. The publisher asked me if I was willing to update it. I had given it some thought, and had collected many notes. So I said yes; but I dreaded the actual work. In many ways, the second edition was more work than the first.
How is the second edition going to be different from the first?
Hal: First of all, Ruby has changed since version 1.6 that I was using then. It doesn't seem like much as you're watching it, but when you stop to add up all the changes in syntax, semantics, the core, and the standard libraries, it's quite a bit.
Second of all, I wanted to broaden the scope a little. There were all these cool things that were not covered in the first edition, like Rinda and Ring and RMagick and RSS and YAML and many others. I wanted to cover more of these, and I did. Though, believe me, there are many others I left out for lack of time and space.
Writing a book like that is all about compromise. If it were "complete" — whatever that means — it might be 2000 pages long. And by the time you write a 2000-page book, the subject has changed and it's no longer complete. So I wanted to produce a book that was of a reasonable size, written in a reasonable length of time. And I ended up dropping some topics that I really wanted to cover, but I just ran out of time.
And of course, I added quite a bit of material. To make room for it, I deleted the four appendices (which were dated anyhow) and some of the less important material in the chapters. At the beginning of the project, I estimated I would delete 100 pages and add another 250. I'm not certain how the numbers actually turned out, though.
What sets The Ruby Way apart, why should people buy it?
Hal: It's like an inverted reference — it covers topics by category rather than by alphabet.
It's not a tutorial, but it does have a good overview of Ruby in the first chapter.
It was written with knowledge of the Pickaxe, and was specifically designed to be complementary to it — not to overlap too much.
It's a how-to book, but it also tries to cover the *why*. It's very important to understand the motivations behind the way Ruby is constructed.
It's perhaps more broad than deep. It "breaks ground" in many different areas, and tries to give hints, clues, and pointers when it can't actually cover detail.
Some have told me it's entertaining. I scattered quotations throughout the book, sometimes at section heads as well as chapter heads. Half these are profound, the other half are tongue in cheek. Once somebody suggested I delete them since space was tight. But they are far less than 1% of the text. For flavor, for entertainment, they are well worth the space they take up.
People have also told me they appreciated the humor (sometimes very dry) in the examples. And there's the geek factor: I put in countless references to Star Trek, Lord of the Rings, Alice in Wonderland, and so on.
It's supposed to teach Ruby syntax, semantics, and programming tricks and techniques. But I'd like to believe that it also makes people think and makes them laugh.
What was the most rewarding part of writing The Ruby Way?
Hal: I'd have to say the respect of my peers. It's incredibly energizing when people tell me they bought it, they read it, they loved it, they learned Ruby from it, and so on. That makes it all worthwhile.
What was the biggest challenge in writing The Ruby Way?
Hal: Because the coverage is fairly broad, it strains the bounds of my expertise. Many times I had to seek knowledge, advice, and code from others. Sometimes these were in conflict, and I had to try to do enough research to decide what was actually going into print. Because, after all, the credit goes to many people, but the blame for mistakes all rests with me.
What did you learn from writing The Ruby Way?
Hal: I learned that I didn't know Ruby as well as I thought. I was constantly turning up little-known features and edge cases and things I had never tried.
It's a fact of life. You think you know something. Then you try to teach it, and you end up learning more. Then you try to write a book, and you learn the most of all that way.
I also learned that books are never written by one person. Besides people assisting me with content, the number of people on the publisher's side that touch the book is truly astonishing.
I've learned that writing a second edition is NOT that much easier than writing the first one. I would almost say it's harder to rewrite a book than to write from scratch.
And if I may be a little cynical, I've learned that I can read a chapter five times, and have it read by eight other people, and then read it again in PDF, and it will still have errors in it that won't be found until it's on the shelf.
What are your favorite five libraries for Ruby?
Hal: Good question. RMagick is a lot of fun to play with. The feedtools library is pretty cool for RSS and Atom. The mathn lib does a decent job of "unifying" some of the mathematical pieces of Ruby. The open-uri lib is a great example of how to abstract away complexity and make an API simple and uniform. KirbyBase is excellent for a small, full-featured non-SQL database. And I'm partial to scanf, because it was written in my house, mostly by David Alan Black. (It's pure Ruby, not a C wrapper; and if you think it's trivial, take a look at the code.) I contributed numerous test cases to it, because it's fun to break someone else's code.
What do you think is next for Ruby?
Hal: Who knows? I think YARV is going to be important. I think interoperability with CLR will be important. I think the international support will improve. I also think that it's going to be used more and more in science and engineering.
I don't foresee "giant" changes in the syntax and semantics of the language itself, even in 2.0; Matz has always been conservative and deliberate in crafting Ruby.
What's next for you?
I keep thinking about the third edition of _The Ruby Way_. If it's going to be finished by 2012, I should probably get started on it right away.