BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles The Well-Grounded Rubyist, David A. Black

The Well-Grounded Rubyist, David A. Black

Leia em Português

The Ruby language was first released 14 years ago and since that time as experienced great growth with thanks to Ruby frameworks such as Ruby on Rails.

InfoQ's Robert Bazinet had the opportunity to talk with David A. Black, the author of The Well-Grounded Rubyist. This book covers intricate details of the Ruby language today, including the latest Ruby 1.9.1, and gives developers a solid foundation for creating Ruby applications.

The conversation with David supplements a recent item on InfoQ by Charlie Martin, which gives an overview of the book. This interview is accompanied by a sample chapter from the book, Chapter 15. Callbacks, hooks and runtime introspection (PDF).

Robert Bazinet (RB): Tell us about your new book The Well-Grounded Rubyist?

David A. Black (DB): It's what I call a "re-purposing" of my 2006 book, "Ruby for Rails". It's a Ruby book (not Rails-specific at all), and it covers Ruby 1.9.1.

RB: I often talk to authors that say they will never write another book after their last one. In your case you wrote Ruby for Rails, what was your inspiration to write another Ruby book?

DB: I'd always wanted to write a Ruby book -- just Ruby -- and Ruby for Rails provided what you might call the kernel for such a book. So it was a natural step. As for not writing another: I'm already at work on my next book, which has the working title "Rails Choices" and is being published by the Pragmatic Bookshelf. I published my first single-authored book in 1999, in a completely different field, and I wrote many book chapters, scholarly articles, and encyclopedia entries in my academic career. So writing itself is a major part of what I've always done, and while writing a book always leaves you pretty drained, I've never felt that any given book would be my last.

RB: Who is the intended audience for this book?

DB: Anyone who is new to Ruby and wants to start out right, or anyone who has done some Ruby (including, but not limited to, Rails) and wants to go through the chief features, techniques, and principles of the language in a systematic way. I've learned from my experience as a Ruby teacher that even if you pick up the language to a point where you can use it to get many jobs done, there's always something more to learn. I can't tell you how many "Ah ha!" moments I've seen while training programmers who are already using Ruby, when I explain something to them about the object model, the way scoping works, code blocks, metaprogramming -- any number of topics. And it's not because they aren't good programmers; it's because they happen not to have had the chance (yet!) to sit down and have the language explained to them that way.

Reading a book is different from having a trainer or teacher, but I'm pleased to say that one thing people said about Ruby for Rails was that it was like having an expert sitting at your side explaining things to you. I hope some of the spirit of my teaching shows through in The Well-Grounded Rubyist too!

RB: Is The Well-Grounded Rubyist a follow-up to your book, Ruby for Rails and what is different about it and what have you learned about writing for this audience that is applied to the new book?

DB: It's not exactly a follow-up; it's definitely not "Ruby for Rails, volume 2" or anything like that. Nor is it exactly a superset of R4R. The relationship between the two books is kind of unusual, and there's no perfect word for it. The choice of topics is different; TWGR is not a full language reference, but it's got a lot more Ruby topics in it than R4R, and topic choice was not governed by anything as specific as the "for Rails" concept. And any topics that they have in common have been completely revised and updated.

As for the audience: one thing that I think has changed is that the Rails developer community is ready, so to speak, for Ruby instruction and exploration that isn't necessarily "for Rails" in the way that R4R did it. There's real traction for Ruby as a language. So TWGR is by no means *not* for Rails -- it's just more expansive, broader, more welcoming. (Mind you, a number of people said that R4R was the best Ruby book they knew of, "for Rails" or otherwise. Hopefully TWGR won't be any less so :-)

RB: Why did you choose Ruby as a language to use, write and teach about instead of a language such as Python or other dynamic or static language?

DB: Ruby chose me. I was in a Borders bookstore, circa the first week of November, 2000. I spotted the Pickaxe book, which had just come out. I took it off the shelf, opened it, and fell in love.

Five years later, I resigned from a tenured university professorship to pursue full-time Ruby and Rails consulting and training. At that point I was already working on Ruby for Rails, so the pendulum of my interests had clearly swung toward computer work and Ruby in particular. (My academic position was in a different field.) I stuck with Ruby largely because of the people involved with it. I found a "home" in the Ruby community, and have had the most extraordinary time. I love the Ruby world because people really aren't into hierarchies and cults of personality. There's somewhat more of that stuff nowadays than there used to be, but if you just kind of sidestep it, you can get to the cool stuff.

RB: If someone new to Ruby picks up your book and you were given the opportunity to help them along, which parts of the book and/or chapters do you think would be most helpful to them to give a great foundation for learning Ruby?

DB: I would start at the beginning. The book falls into three major parts: Ruby Foundations; Built-in Classes and Modules; and Ruby Dynamics. So it's designed to ramp you up into the language from the start. If you've already used Ruby, you'd probably want at least to flip the pages of the first chapters, and start reading in depth when you hit something unfamiliar (or at least make sure you know what's in those chapters, in case you want to go back).

RB: Many Ruby on Rails developers learn Ruby by learning Rails. Do you think this is a good way to approach Ruby on Rails or do you think people should first learn Ruby?

DB: I don't think you have to avoid all contact with Rails until you've mastered Ruby. That was a major focus of Ruby for Rails: integrating the experience of learning Ruby with the experience of using Rails. It's important to remember, though, that if you decide to learn Rails, you have decided to learn Ruby (unless you're just going to play with Rails a little and then drop it). There are different ways of going about it, but you definitely want to do it.

RB: The book includes Ruby 1.9.1. What are some of those features of 1.9.1 that you are excited about or you feel should be most important to developers?

DB: I'm committed to the idea that people should move to 1.9 because it's there and it's ready. Some of the new features I like; some I could live without. But that's always going to be true of major new releases.

Among the things I like: a lot of new Enumerable methods. I grumble sometimes when the method count gets too big... but I've come around to thinking that it's often good to put methods in the language that everyone is writing their own versions of anyway, or that are different enough from existing methods that they pull their weight.

Enumerable#each_with_object is a good example. It lets you do something like this:

&gr;&gr; names = ["David Alan Black", "Yukihiro Matsumoto", "Rob Bazinet"] 
=&gr; ["David Alan Black", "Yukihiro Matsumoto", "Rob Bazinet"] 
&gr;&gr; h = names.each_with_object({}) do |n,hash| 
    hash[n] = n.scan(/\b(\w)/).join 
  end 
=&gr; {"David Alan Black"=&gr;"DAB", "Yukihiro Matsumoto"=&gr;"YM", 
   "Rob Bazinet"=&gr;"RB"}

Instead of the ugly inject equivalent where you have to name the accumulator at the end of each block:

names.inject({}) {|hash,n| hash[n] = n.scan(/\b(\w)/).join; hash }

So #each_with_object doesn't do anything you can't already do, but it addresses a common use case in a much more idiomatic way.

There's a lot of that kind of addition of functionality in 1.9.1. Some of the smaller syntactic changes I don't mind but don't feel strongly about one way or the other. I've come around to liking this, though:

{ a: 1, b: 2 }  # same as { :a => 1, :b => 2 }

I'm always skeptical about "magic" and what I think of as syntax that uses "invisible ink". But in this case, I think it's nice.

RB: What do you think needs to be done to get Ruby 1.9.1 into mainstream use?

DB: People need to read my book :-) Also, we have to make sure that the many gems that people need to use are 1.9-ready. I can't claim any glory in this area; I'm way behind where I should be on testing and patching people's gems. There's at least one initiative underway, though, where it's being addressed systematically: http://www.ruby19orbust.com

I'm afraid that, with all due respect to the core Ruby development team, I'm not a believer in 1.8.7. It's been described as a stepping-stone to 1.9, and that, together with some of the birth pains of 1.9 as a stable version, has provided a kind of safe haven for people who want some 1.9-era features but are skittish about 1.9. That's kind of unfortunate.

I'd encourage people very strongly at least to install 1.9.1, and see what problems you come up against. I don't think that making 1.8 more like 1.9 is the answer. It sends the message that there's a reason to avoid 1.9 -- and while that may have been true before 1.9.1, as far as I can tell it's now stable and on as solid a footing as any such release before it.

RB: Do you recommend current Ruby 1.8.6 developers skip 1.8.7 and make the leap to 1.9.1? What should developers do as they find plugins and gems that don't work in 1.9.1?

DB: Fix them! :-) The answer to the skipping 1.8.7 question is, on the whole, yes. It may be more work to get things to run in 1.9.1 (more backward incompatibilities), but you're going to have to do that work eventually if you want to move to 1.9 at all. I suppose doing two transitions means smaller increments, and every developer and team will have to decide whether they feel that's more manageable. And, to be fair, I have to say that lots of very widely different opinions have been expressed on this topic, and it's probably a good idea to look into some of them.

Going back to the plugins and gems question: it has definitely been far from a seamless transition, but there's been a lot of attention to it lately (see the link I gave earlier). It's not inconceivable that a given project would end up deciding to hold off on the transition. But my impression is that the pace of 1.9 pickup is increasing.

Mind you, if anything is holding 1.9 back at this point, it may be the fact that Ruby was already incredibly cool prior to 1.9! :-) Still, even if this transition is more prolonged than some, I'd encourage everyone to keep as current as your circumstances allow. Ruby will continue to be interesting, and you want to be there!

RB: David, thank you for taking the time to talk with me about the new book.

David A. Black is an internationally active Ruby and Rails programmer, consultant, trainer, author, event organizer, and speaker. He has been programming in Ruby since 2000. David is one of the founding directors of Ruby Central, Inc., the parent organization of the International Ruby Conference (RubyConf), an event he has been involved with every year since its 2001 debut. He is the author of the highly acclaimed book "Ruby for Rails" (Manning Publications, 2006), as well as the newly released book "The Well-Grounded Rubyist" (Manning, 2009). His next book is "Rails Choices", due out from the Pragmatic Bookshelf in late 2009.

David is the owner and director of the Ruby/Rails consultancy Ruby Power and Light, LLC, through which he conducts on-site and public training courses and offers consulting and code-review services.

Manning Press has been kind enough to offer InfoQ readers a 40% discount on David's book, The Well-Grounded Rubyist using code "ruby40".

Rate this Article

Adoption
Style

BT