We are here with David Black working on Rails. Do you want to talk a little bit about your presentation, about your upcoming book? Why don't we start with a little bit about your background?

In terms of my Ruby background I discovered Ruby literary the week the first edition of the Pickaxe book came out. "Programming Ruby" by Dave Thomas and Andy Hunt had actually been using a lot of Pearl at that point and I happened to wonder into a book store and see the Pickaxe book on the shelf and have never looked back. This was like the first week of November 2000.

The following summer, I got involved in organising the first international Ruby conference which was held in Tampa, Florida in October 2001. Subsequent to that it kind of snowballed when Chad Fowler and I founded Ruby Central Incorporated, which is a non-profit organization dedicated to supporting Ruby projects and Ruby advocacy. Ruby Central was created to be the parent organization of the annual conference and it has now expanded; it is now also the parent organization of the RailsConference which we are having the first one in June in Chicago.

I also got involved in writing about Ruby fairly early, also in 2001 I was invited to contribute with some chapters to the book "Teach yourself of Ruby in 21 days", which Mark Slagell was writing for Sams.

What makes the Ruby community so special in your opinion?

I think at a certain point I've might have said because it's kind of small to medium and self-selecting and a bit of a secret, but now that it isn't such a secret any more I'd add something. I also like it because it's scaling very well. [Obie: "So Ruby does scale!"] I'm quite impressed with the fact with what I think as the second way of Ruby popularity outside of Japan. The first way being the Pickaxe book in 2000, the second way being the spread of the popularity of Rails over the last year and a half. In the face of that growing popularity I think the community has held up very well and things somehow managed to still have a very nice feel them.

How big are we growing? Do you have a handle on some of the numbers?

It's hard to quantify love which accounts for a lot of this, but for example on terms of the Ruby conference, in 2004 we had 65 people. David Hannsson did a presentation on Rails and there were a number of us, including me, introduced to Rails then. That was October or November and Rails has been introduced in June or July. A number of people were using it , but a number of us were unfamiliar with it; it was quite obscure. When I saw that he submitted a proposal and I sort of thought "I've seen that mentioned on the list, I'm not quite sure what it does". After he gave the talk I understood more and I got very into.

Was Rails special even back then?

I thought so. I had no axe to grind against other frameworks. Most of them I haven't used. For me Rails is certainly the one that caught my attention. Just to finish the talk about the growth and the quantification: in 2004 we had approximately 65 people, in 2005 we had 200, so it tripled in size in one year. We were also for the first time, turning people away. We actually were caught a little bit by surprise. We knew it was going to grow, but I don't we really thought we were going to have to drop the axe at 200, but we did. I think we could have filled it up to maybe 230. The Rails conference in June is bursting at the seams, I think we have 550 people [Editor's note: RailsConf attendance was actually over 700.]

The Rails Conf started as a one track conference, but that had to change. Can you share a little bit about what you and Chad dealt with?

Certainly. Chad has been more involved in the Rails Conference than I have but we've talked about it. We both feel very strongly that we really love one track conferences and most of the really good conferences that we have been to have all been one track conferences. I believe in that pretty firmly. We stuck to that with the Ruby conference and we are going to stick to it this year, although we're thinking of capping it at 240.

You're capping Ruby Conf at 240 people even though last year there were only 200. So it's still going to maintain some exclusivity.

I guess that's a good way to put it. We like the format and we think it has worked every year. We're going to keep the one track format and we're not looking to turn it into something other than itself.

RailsConf from a registration perspective must have blown your mind, in the sense of the demand that came about. did that really surprise you?

Not really. I'll tell you why. With the Ruby conference tripling in one years that gave us a pretty good sense of the demand.

Did it actually sell out? I've heard some rumbling that maybe they are holding back tickets to make it seem more exclusive.

No. I think there may have been one round of deciding to let in more. I think it had to do with the venue. It may have even had to do with the two tracks decision and just logistics and so on. But also consider that a 500 person conference is a big deal for us, it's not like that's a tiny, exclusive event. From the point of view of Ruby Central and our resources and so on that represents a pretty substantial leap in the size of the event.

What kind of concerns do you have since you're custodians of the language here in some way. With this influx people are coming to the Rails community, a lot of them don't even know Ruby and they might be coding Rails for a while before they even start to get into the language.

I think we are custodians of aspects of the culture and the activity of the language and I make that distinction because I think it's important to remember that Matz is the custodian of the language and that's not just a technicality. The reason I emphasize it is not because you didn't know it, which you do obviously, but because one of the great things about having this kind of influx on people is one's faith and trust in Matz. He's just so even-keeled and level-headed about the language. Matz is Yukihiro Matsumoto, the creator of Ruby, who released the first version on February 1994.

Was Ruby really just a personal language that Matz was writing for himself or was that overblown?

Let me answer a question with a question. Is Rails really a framework David Hansson is just writing for himself or is that over? David was talking about that in his talk yesterday and obviously he's talked about it before too, and that reminded me a lot of things that Matz has said. I think it's sort of unanswerable. One can't fathom that literally if nobody showed any interest in this, would they continue to do it? Who knows? But it has worked out well for everybody and I think Matz is a great person to be sort of custodian of a language partly because I love the way he designs it. He's talked in the past about the principle of least surprise, although that's kind of a deprecated principle because it has been overused and people start criticizing things. At one of the conferences in 2002 or 2003 he said policy of least surprise (to me.) [Obie: Ruby was certainly a pleasant surprise to me!] What I love about the design of Ruby is when you're suddenly realising that you can do something in even less code than you thought or things are expressive in certain ways that are really good.

How does Matz feel about Rails and the success of this?

I really don't know and that interesting too. [Obie: He keeps a low profile, doesn't he?] He keeps a medium profile. He's very visible on mailing lists, not necessarily everyday. He answers things on the Ruby talk list, on the Ruby core list, presumably on the Japanese developers list of which we get in English some translations and some weekly digest and so on.

Matz has done a great job so far, as custodian of the language. Is there confidence in the community that Matz is going to stick with it as it continues to grow? Java has millions of users. If Ruby has even a small percent of that, it's going to be hundreds of thousands; maybe someday we could have a million. That's a lot different dynamic than what we have now.

I think so, but again it's a question of scaling. A thing that popped into my head was in fact that when you ask that question some of the scalability of Rails, by the same token as if you have a view in Rails and you have three database records or 300 thousand, the view just sits there and is itself. I think Matz is kind of like that. He's just interested in the language and his relationship to it. I mean, he's interested in the community too, but I think things are set up that he doesn't necessarily have to deviate from that interest very much and it has proven track record of rippling outward in useful and interesting ways for other people.

You have a direct contribution to making sure that the growing Rails community adopts the Ruby idioms and good practices that are making it so pleasant to scale down.

In the form of my book I have. My book "Ruby for Rails" which as we speak is on sale in its pdf form and will materialise in paper format in the first week of May (2006).

Why do we need a book called "Ruby for Rails"?

The reason I decided to is that when I started to use Rails (that was sort of the latter two or three month of 2004), one of the things that I saw immediately when I looked at IRC channels and mailing lists and so on- was a certain amount of debate about the question whether Rails developers needed to learn Ruby. I was puzzled and I even more puzzled when people were saying "NO". If you're going to ask the question somebody should intervene and not answer yes or no; or answer it yes but also explain why the terms of the question don't really make sense. It doesn't make sense to say "Do I need learn Ruby?", because if you're writing a Rails application you're writing a Ruby program. So you've already decided to use Ruby, it is not an issue.

You're saying that in order to do Rails development you need to know Ruby.

I certainly think so. In fact it's also true that once you start to use Rails at all, you're using Ruby. In other words when you write a Rails application, you're writing Ruby code. My feeling about that was always: "Why wouldn't you embrace that?" since logically if you're writing Ruby code, the more you know about Ruby the better you can write it. Unless there's some other way to understand it like "I'm writing Ruby code but it doesn't really matter how good it is, or I'm writing Ruby code but Rails will protect me from Ruby". If any of that were true it would make sense, bit the thing I really want to put across and why I decided to write the book is that learning and using Ruby is not fundamentally either an alternative to Rails or in conflict with Rails.

It's an orthogonal issue in the sense that you can know a lot of basic Ruby, but what is it going to buy you to know more advanced Ruby idioms as a Rails developer?

I think it buys you several things. First of all it buys you the ability to learn what you're doing. But again one of the things about Rails that's actually very impressive in some ways is that you can cut and paste from other applications and you can get the hang of what one thing has or means.

That's what people attribute to Rails being a DSL for web apps.

I'm not sure I agree with that. It's a bit loose usage of the term, but still I think of it as an environment. It presents itself as kind of self-fulfilling or self-defining and I think part of the difficulty or dilemma when looking at Ruby in regard to Rails, is whether Ruby is in fact a departure from Rails, or is it going to make it much harder and so on. My feeling was always that learning Ruby just grows naturally out of Rails. (If you know what you're doing) But if you don't know what you're doing, you hit the wall at a certain point. It means you've decided that you just want to use and re-hash some of these idioms.

Case in point: One of the reasons that Rails has been successful for beginners and people have found it easy to adopt is because of the use of code generation, the scaffolding. Good thing, bad thing, neutral? Where does code generation belong in the future of Rails?

I think it's basically a good thing. I really do tend to root for people to know what is going on. My inclination in explaining Rails is to sort of walk through the structure of the framework and the logic behind it. It can be a fine line maybe, but not have things be too much just turn-key, because I think people should understand what is going on. It's not that they have to know exactly how every line is going to assemble in terms of CPU, but in terms of the design of the framework, in terms of how things work.

What is the target audience for your book "Ruby for Rails"?

The target audience is people who use Rails and want to know more about Ruby. It is a big target, but I think part of the reasons it is a big target is that Rails has attracted people from very different backgrounds. It has been pretty challenging to come up with an image in my own mind of the average reader.

Give us a picture of that range. What is the range of different backgrounds?

I think the range of different backgrounds includes basically programmers at various levels of expertise. Some of whom have Ruby expertise, some of whom don't, some of whom have web development backgrounds, and some of whom don't. there are people like me for example who did a lot of ad-hoc CGI programming in Perl, but was not particularly versed in framework-type stuff and then got very interested in Rails. It was a turning of the corner for me, but I also had continuity and knew Ruby.

My impression is that Rails has attracted a lot of people who are in the administrative project managerial categories or on the fringes of these web-development projects and Rails allows them in, because it casts a pretty wide net and that makes sense. I have researched this a lot and found people who did not identify themselves as career programmers and who were feeling that Rails was a point of entry for them. They could work close to a project like that and get things done in a way that they hadn't before.

Can Rails make it to the stage where it's like Excel, where people are programming and they don't even realise it? Millions of people use Excel every day and they're essentially programming. They just see it as getting their jobs done. As the web gets to be more and more pervasive in our lives do you see Rails going in that direction or does it have to be some other higher level framework?

I tend to think it would be some other higher level framework. Maybe something that sort of piggybags on Rails or forks away from it, or something.

So the book is coming out soon?

The book is out in PDF and will be out in paper in the first week of May

Are you planning on continuing your strong work for the Ruby community? In which direction are you taking it?

Absolutely. We've got the Ruby conference coming up in October, the Rails Conference coming up in June. I personally am getting involved in some Ruby trainings and I've been doing some Rails consulting also. Hopefully that will continue to develop and to grow.

On a final note: If someone who's watching is curious about Ruby and Rails and hasn't dipped their toe in the water yet, what kind of learning curve can they expect?

It depends a lot who they are. I think Ruby and Rails are both known for having what I would describe as a relatively low barrier to entry. One can argue back and forth forever about this. But over time I've heard more and it's kind of sappy, but also the community really is supportive and you can glide along with a lot of help.