The original podcast can be found here. It was recorded in July 2009. The interview itself starts at 0:02:47 and ends at 1:14:16. Note: I'm not a native speaker of English. Sometimes I couldn't figure out what was said. I've placed those parts between [square brackets]. Here and there I removed some interjections (like 'sort of'). If you have any corrections or suggestions, please mail them to Michiel Overtoom and I will amend this transcription.
02:47 Q: David, where are we speaking to you today?
This is actually from my second bedroom/office in my home in Chicago. So I am in the U.S. now pretty much permanently. No more Denmark time.
03:05 Q: And, how long have you been in the U.S.?
I've been here for three and a half years. I came over in December four years ago.
03:17 Q: So how long have you been programming? Are you one of the people who started programming when you were very young, or did you pick it up later in life?
Absolutely not. I did not start programming right away. I had a lot of programming friends growing up, but it was sort of looking at them that kept me off programming for a long time. I didn't get into programming really until I was in my twenties.
03:40 Q: Really? What made you not want to be a programmer? This is curious.
I had a bunch of friends who I loved dearly, but in many ways were exhibiting all the traditional programmer stereotype themes of being just overly focused on things I didn't think mattered and at that time programming perhaps also was a little bit different. Growing up, programming was assembler and C. I had a lot of friends in what was called the ‘demo scene’, which is mostly an European thing where you had all these guys on the Commodore 64 and on the Amiga writing these really awesome visual displays of various kinds, and all that stuff was usually in assembler. I had absolutely zero interest in learning or doing anything with assembler, it just didn't make any sense to me at all.
I only really got interested in programming when I stumbled across languages that made sense to me on the level that makes sense to me, which is at the very least high level languages like Java, PHP, or whatever have you, anything that's above the “I have to dick around with pointers” or I actually have to move memory spaces around; that stuff has absolutely zero interest to me at all.
I didn't start programming until I was in my late twenties, and even then I didn't start programming because I wanted to be a programmer. I started programming because I wanted a few programs. And that was apparently the easiest way to get there because the other way of getting programs is that you actually have to talk to programmers, which is surprisingly painful at times. I found that the easiest way was just to pick it up and learn it myself.
05:23 Q: Wow. And what was your first programming language?
I started with... I'm trying to remember whether I first got exposed to ASP (which is the Microsoft Visual Basic stuff for web pages) or PHP. I think the first stuff I actually did personally, more of sort of a concerted effort, was PHP. I was always interested in programming for the Web side of things. I never cared for any other types of programs. I wasn't interested in writing desktop programs, I wasn't interested in writing anything else. I was just interested in getting information out on the Web. So that was sort of the avenue I took to it.
06:05 Q: So really for you programming was just a tool to get to where you wanted to go, it wasn't really like the fascination that maybe some of us have with being able to move ones and zeros around in real fancy ways.
Absolutely, at first. And this was in part due to the languages I was exposed to: PHP, Java, ASP; those were the languages I actually did something in, where I wanted the programs. I got a little bit exposure to C and a few other languages in college, but it wasn't until I discovered Ruby that I personally got interested in it to a level where I truly cared, that sort of the craft itself had meaning, and it wasn't just the end products that had meaning.
For me it was very much about the tools which is why it's always a little... you get this whole Spiel about “Oh, just pick the right tools for the job”. Well, for me there's a bunch of tools out there that sure, you could pick for the job, but I would have zero interest in doing so. To me my interest in programming is very intimately married to a certain set of tools that give me just one particular experience of it. I have absolutely zero interest in doing programming if it means working with tools that I have no compassion for.
07:22 Q: You spent some time working with Java. What was your least favorite feature of Java?
Oh, there's so many things. It's really hard to pick out any individual parts. On the flip side, it's hard to pick out any individual part of “what is it that you like about Ruby”?
The experience of a programming language is so much more than the sum of its parts then looking at any individual thing and saying, oh, Ruby is awesome because it has blocks. That really doesn't tell the story. For me, the overarching theme for Java was just that it was so needlessly cumbersome. I would look at this structure and I would think to myself: there's going to be a million bazillion Java programmers out there who are sitting right now, and writing the same freaking bullshit ten lines to get the same one result. Why are we wasting World productivity like this? It just felt like this was a scam on the World, that we're sucking useful productivity out of the Universe that could've been appointed to something meaningful. So in some sense I was just enraged on a global level about this stuff that it just seemed so completely mindless that we all have to do this stuff over and over and over again.
08:39 Q: Sort of like of giving a bunch of carpenters whose job was to screw things together just a bunch of hammers?
Exactly! I mean, why are we wasting all these peoples time when there's so obviously a better way to do it? It's not even finding out the better way, it's just looking at the repetition that I was seeing in Java programs. It did not make any sense at all. I [noticed] all this duplication, that everybody was doing it the same way, or making changes in, or making differences in sort of ways that had no significance.
09:12 Q: So along comes Ruby. What was your first exposure to Ruby?
I think I was reading an article in IEEE I believe, by Martin Fowler or Dave Thomas. I was following both of those guys for some time and I would always read these articles by either Dave or Martin, and they would always preface their articles by “I usually do Java (or whatever it is) by day because that's what my clients want me to do, but now I'm explaining this really interesting concept, let me show it to you in a language I actually care about”. And then they would go on and write about this whatever topic it was, and use Ruby as the example code.
I found this to be intensely interesting that you'd have all these really smart guys who would prefer to use this programming language, but for some reason there was this magical force that was keeping them from doing it. And apparently that magical force was ‘customer demand’.
I was thinking to myself when I started working on Basecamp, which is the first product of 37signals: “Hey, I don't have a client. I can pick whatever I want. The only thing people care about is whether a web application comes out of the other side that does what they want in a reasonable amount of time, and blah-blah-blah. Why am I not picking what all these really smart guys would prefer to work with? It's probably a better experience that what I'm currently working with”. I gave myself one week to see if I could get up roughly to speed of where I was with PHP which would otherwise been the alternative I was going to use and see if I could build from there.
I think it took a couple of days of a little bit of frustration, and then after one week it was: Oh my god, this is awesome. And after one month it was: Oh my god,
I am never going to touch PHP, Java, or any of those other environments I've been working with ever again, if I can help it.
I sort of pretty quickly got just that lightbulb over my head saying: this is so much better. This is what's programming is supposed to be like. This is what it's supposed to feel like to be a programmer. This was probably the first time where I truly identified myself as a programmer, as somebody who actually cared about the craft they were doing.
11:29 Q: So for those of us, the people at home that aren't familiar yet with what Ruby is, can you give us an executive summary?
Sure. Ruby is a dynamic language. I really don't like the notion of ‘scripting languages’, which is what Ruby is often being called [then what Perl and Python these other languages], because it implies that it's only useful for tying stuff together, which is absolutely @#$%. It's useful for so much more than that. So, dynamic languages, whatever. The whole thing being with Ruby that it has a mission that I find to be really interesting.
Matz, the creator of the Ruby language, formulated it at some point as “Ruby is the programming language designed to make programmers happy”. That's the primary optimization target: the human behind the keyboard. When you have that sort of intention there's a lot of tiny decisions that flow from that. It's a lot about the usability of the language. How does it feel to write a Ruby program, and what comes out on the other side? If we go back to that Java example where we're seeing these repeated lines of boilerplate code over and over again, obviously that's one of the things that's not going to make happy programmers. When I program in Ruby I very rarely see multi-line idioms. Because if there is a multi-line idiom, it can be summed up and made shorter and usually arrive at something that can fit on one line. So that's one part of it.
The other part of Ruby which I find intensely interesting to me as a sort of framework builder, is the amount of leeway you have to mold the language. The Python guys often talk with a sort of half scorn about the notion of ‘monkey patching’, which is the extension of existing base classes, like adding functions to String or to Integer, that you design yourself. Well, to me that is one of the absolute key features that makes me love Ruby.
The whole notion of Rails is that we're taking this general purpose language and then we're molding it into a slight special case language that is exceptionally well suited for creating web applications. There are just things you do with strings or with numbers or whatever, that... If you can change those classes and you can suit them to your particular need it's going to be so much nicer a ride. So that's one of the absolute key features that I truly enjoy.
But it's still it's in the same class as Perl or Python or languages like that. There's a plenty of shared cultural affection between those camps. I think we agree on way more things that we disagree on. If you know Perl or know Python, Ruby is very similar. But it's also very different. I don't think that they're, just because you can do the same thing, or a Python program and a Ruby program perhaps would be roughly the same amount of lines of code, the way they go about it and the cultural deeper values of the communities are actually pretty different on a number of core issues.
14:53 Q: Now you played obviously a lot with Matz' implementation, have you looked at some of the alternate implementations of Ruby?
I have, but only ever so slightly. I love the fact what's going on with jRuby, [there's a Ruby Andy Brian is working on] and there's a bunch of other implementations, and I find them interesting. I think it's great that that work is going on. But, I have to commit that in some ways I'm a little bit indifferent, just because the Ruby 1.8 line is pretty damn good. The only thing I'm really passionate about is that if they could make it use slightly less memory and if they could make it slightly faster. But even that is a very very low level concern for me. Because the wonderful thing as I was just talking about with Ruby is that you don't have to wait around for the language designer to tweak the language in ways where you want it to go. When the core classes are open for extension, most of the interesting work that's going on can happen outside of the core release cycle.
The amount of stuff that we've shoved into the Ruby language through the Active Support extension library in Rails is staggering. Some people would even say scary ;-) That's why I don't really yearn for a new version of Ruby that much. Because whatever we can think of of ways that would improve Ruby, we've done it already in most cases. I have a tendency to just care mostly about the API, the API feel. Like spotting more of those idioms we've been talking about. Hey, I recognize these three lines over and over again. We can sum that up to a single method and add it to String, and *boom*, we're done.
16:44 Q: Have you had a chance to play much with other languages like Perl and Python in your experience?
Ah, I have a little bit. I haven't written anything material. I think in some ways I'm very mono-language. That's not even a word ;-) I don't care. Once I find something that I truly like, which is the case with Ruby, and don't have that natural affection of Dave Thomas [supposed] “You should learn a language every year”. Well, I've been failing that test for the past five years. I just haven't cared. Ruby has been so much enough for what I'm interested in, I haven't tapped it out yet, that all my energy has gone into that.
I keep sort of a half eye on it but I don't learn that much unless I actually dip deep into something and try to program in anger, build something real. I haven't had a chance to build something real yet. I don't get a whole lot of enjoyment out of just doing toy programs in a variety of languages. That's not my flavor So, not really.
17:54 Q: Okay. It's often said that Ruby owes part of its heritage to Smalltalk. Do you have any smalltalk experience?
Not short of reading a fair amount of Smalltalk, and especially Kent Beck's absolutely wonderful ‘Smalltalk Best Practices’ book, which is really a fantastic book. Probably one of the best books I've ever read on programming. It's a tiny book too, it's like a 140 pages or something like that. When I ordered one off Amazon it was like 85 dollars. It's out of print and there's a few guys hawking the remaining copies.
It's a really good book and it uses Smalltalk for all the examples, but almost everything in that book applies directly to Ruby, exactly because there is that close heritage between Ruby and Smalltalk. A lot of that Smalltalk wisdom that you can take directly and apply it to Ruby, which I think is wonderful. But Smalltalk in itself... I tried a few times with some of the images, but it's too much of a different world. It's too idealistic for me in some senses. It's too much “throw out everything you know and I will show you a new world”. I haven't been ready to take that red pill.
I really like that Ruby is sort of, lets extract 80, 90 percent of what awesome about that and inject it with some real-world pragmatic approaches, like: You can use the text editor you like; You can save files on the file system; You can all these things in tracks with the real world. You don't have to leave everything behind to jump into this Smalltalk world. To me the whole thing about the Smalltalk images which is always just too confusing to me. Why? There's all this different distributions, they're not really compatible, it just seems like a hassle. I just didn't have the patience to wade through all that. But I'm glad somebody else did. I'm glad that all that wisdom is available mostly to people using Ruby. So, yeah, again: Not really.
20:08 Q: Okay. Long answer for “not really”, that's good ;-) How did you come across 37signals? What was your relationship like at the beginning there?
Back in 2001 I had already been following 37signals for a few years. Well, a ‘few’ meaning ‘two’, because 37signals was founded 1999. But shortly after they were found they had this awesome website that was totally unlike any other website for a web consultancy from what I've ever seen. A very minimalistic manifest actually, I think it was like 35 essays on the type of clients, the type of projects, the type of designs that 37signals were doing. I was just finding that uniquely interesting and I was also finding the design aesthetic very interesting. At that time I wasn't full fledged into the program world, I was still dabbling in web design and trying to learn from 37signals.
Anyway. 2001, 37signals runs this weblog called ‘Signals vs. Noise’. Jason Fried, the co-founder of the company, and my partner, posts on the blog that he's trying to learn PHP because he wants to make this program, and I think he's having a question about pagination or something. He's writing out in his blog doing the lazy web approach to learning how to program: “how do you do this?”. I write him back a long letter explaining, we trade a few additional emails, and sort of at the end of it he's like: “Actually, what if I just hire you to make the program instead? That would probably easier then me trying to learn PHP”.
So here I am, sitting in Denmark, seven time zones away, and I strike up this working relationship with Jason and with 37signals, and first we work on a product called Singlefile, which is actually the first published web application I ever got out there, which was a ‘manage you books on-line’ kind of thing. It never really took off. It had a core constituency of some really passionate fans, but it never took off.
For the next three years or something I'm going to school and part-time working for 37signals doing client projects. They would do the design, I would do the programming. And then, the turning point for the company comes in 2003 when we decide to start working on Basecamp. And this is when I get interested in Ruby. Sort of start working on Basecamp I learn Ruby. I start creating Rails on the side as part of the Basecamp experience, and in 2004 we release Basecamp and things follow rapidly from there.
22:55 Q: Did 37signals specify that you build this in Ruby, or did you bring this idea to them?
Actually I didn't even tell Jason for some time. I was like: You know what? This whole discussion is going to be a little awkward. I know he's comfortable with this whole PHP thing. If I'm telling him I'm gonna use a new language, he might freak out a little bit. So I think we actually made some substantial strides on the application before I told Jason “hey, by the way, this is not actually PHP, this is Ruby”, and he's like “Ok, I guess?”; at that point it wasn't really a choice, I just made a decision there that –if I was gonna make it– it was gonna be in Ruby.
23:39 Q: Well I know that some of my friends have gotten Perl into very large corporations that very same way. I guess it works.
I think it's actually the best way. There is absolutely no way a programmer can successfully convince somebody that they should give up what they already know for his own benefit. Basically the sales argument would be: “You know this PHP style, for which we successfully delivered tons of applications before? I don't really want to do that anymore because I'm bored. So, let me use this unproven technology that you've never heard of that you probably will fear will fail spectacularly, to do application instead, because that will make me feel better”. Eh, no. That's not a very sellable argument. A very sellable argument is though: “See this running software? It's running on Ruby. Can you tell the difference? No, you can't. So, it's pretty awesome isn't it?” That's an argument that I think works a lot better in most cases.
24:35 Q: That's interesting because most of what I hear when I hear about engineers being upset at their work environment, you know, all the tools they have to use, that were generally forced upon them by upper management reading some magazine or some advertisement. And whenever I have talked to people that are really enjoying what they're doing it's always because they were able to sneak technology in from the last conference they went to.
Yes, totally, absolutely. There is just so much mandated technology out there that is being sold to people who don't have a freaking clue of whether they should use one thing or the other thing, so they take the one that has the most steaks and the most strippers. Which tends to be from companies who have expense accounts to have salespeople who can sell them very expensive application servers, over six months, and wine and dine them with all this crap. So getting technologies in that doesn't have expense accounts, like Ruby on Rails and Perl and Python and all this other stuff, often requires getting in the back-door. Because you have nothing to bribe upper management with. I think that's just the nature of the game.
Fortunately though, there is plenty of alternative programming jobs out there now. I think it was more true perhaps in the past where your choice of being a programmer meant working for a big corporation. These days they're so many startups, small companies, where you don't have that traditional structure, where you don't have purchasing managers who's only job it is to pick technology (which is a @#$% job anyway). You don't have those people getting in the way, you have tons of companies that are filled with builders, people who will actually care about the tools that they're picking. So it tends to be less of a problem for these guys, which is of course also why those are the guys who pickup technology like Ruby on Rails the first. In the beginning we certainly didn't have all these enterprise uses that we do now. We had all the small companies who were willing to take a ‘risk’ on something because they felt it was the obvious good choice, regardless of whether of no strippers and steak were attached.
26:40 Q: I like the idea of the Web being the great equalizer, making it possible for small companies to deliver some product without having to hire a big sales infrastructure and getting into a distribution channel of some kind. I often talk about the ‘three guys in Starbucks’ as I'm talking about web development: you got the web programmer, the ponytail designer guy or gal, and the guy with the idea that brings them together. And those three guys meeting in Starbucks over and over again can generate a company with something like Ruby on Rails or Smalltalk Seaside or something like that.
And I think the wonderful thing about the Web is that not only that it is an equalizer on business side of things, it's an equalizer for the technology. Before, if you wanted to write a piece of software you would have to write it preferably in the native environment of that platform. So if you wanted to write something for OSX, you better damn well write it in Objective-C and use the core infrastructure classes and the same thing on the Microsoft side: you better damn well write it in .Net or whatever, because that's the native environment.
For me, Rails was just as good when we had a thousands users as it is now, when we have hundreds of thousands of users. Because it doesn't do anything different. Basecamp looks the same now as it did roughly five years ago, in terms of what it's generating, regardless of whether the platform was a lot smaller back then and it was just me working on it. The web is exciting on so many levels, but as an equalizer both for businesses and for technologies, it is especially wonderful.
28:50 Q: People don't have to know that when they're going to Basecamp it's written in Ruby and when they're going to Ticketmaster it's written in Perl. They don't care.
Yep, totally. And that's so awesome. Then, the playing field becomes: Who creates the best business on-line? Who creates the best website? Who creates the best and most compelling experience? And we don't give two hoots about what you're write it in.
29:20 Q: So you created Rails during the building of Basecamp. Did you know that it was going to be separate framework at that point, or were you just simply fulfilling the task of Basecamp?
I didn't. When I started building Basecamp blocks for myself At that time Ruby didn't have really just the treasure trove that it does now. It had a lot of things, but it also had a lot of things that wasn't especially meant for Web construction. I came in with a lot of preconceived notions about how web development should be done. I came in with a lot of learned idioms from PHP if how easy so many things are in PHP to do, that if they weren't as easy to do that in Ruby, I damn well would want to change that, so that it would be just as easy.
I started building all of these frameworks bit by bit, and I was about halfway or two-thirds through, I was thinking: Wow, I have an ORM now to talk to the database, I have a templating language to format my HTML, I have a controller framework, I have all of these frameworks and I'm really enjoying what I'm doing right now. I've never had more fun doing programming then I had with the Ruby stuff and the Rails bits I was building. It'd be pretty selfish from me to keep it all to myself, wouldn't it?
I was just thinking: I'm getting all these things for free, Ruby is free, all the infrastructure pieces: Apache, MySQL, Linux, whatever else you have, all those pieces are free. It just felt like I'd be a dick if I then took the one [pawn] I have and just kept it to myself. I just decided, well, the right thing to do would be to share it. And if people like it, that'd be wonderful. At least I'd put it out there. So, a few months before the release of Basecamp I decided that I was going to put something out there.
But at the same time I didn't want to just put something out there that was going to languish just like a ton of other open source projects. If I was going to put something out there, I was going to put it out there with enough effort, that it'd had a fighting chance to make a difference for people. So, I think for six months after I had a completely working framework sitting on my hard-drive, I said screw ‘release early and release often’ I'm going to polish the hell out of this thing. I'm going to write the documentation, I'm going to build up some marketing intensity around it. I'm going to do all of these things that a lot of Open Source projects do not. And a result of that they have a tendency to not get very far. I wanted this to have an impact. I wanted this for my time to be worthwhile, I was not going put all this freaking effort into bundling this stuff up if it meant just two people playing with it for 5 minutes. That's freaking wasted effort. It took about another six months of me [chalking] it up, polishing it up, writing documentation, doing all these things, before I felt: “hey, it's good enough now to release it”.
32:20 Q: Now at this point was this owned as a work for hire by 37signals or was it owned by your company? How did the ownership work out?
I said to Jason: You know what? I'm going to put all this time in into it. Mind you too: when I started working for 37signals, and while I was working on Basecamp at the beginning I was paid $25 an hour. That was a fortune back then because the dollar was worth something, and I was in Denmark. Things have since changed. But I was still aware of that $25 an hour is not enough to own my mind, it's certainly not enough to own my passion. The deal was that I would only bill 37signals for the working hours I put in on Basecamp itself. And then all the extra polishing work I put in would be in my own time.
So I just said: This is gonna be mine. I'm going to run with it, I'm going to put in the effort to it. It's also going to be something that I control. And most importantly just that I wanted to make sure that, especially in the beginning, that I could absolutely control the vision of where this thing was going to go. Which was also why for at least a year Rails had one committer: me. There was plenty of people submitting patches, but there was one committer, and I was that. Because I wanted to make absolutely sure that this had a clarity of vision, it had a very targeted design. I did not want it to become this mess that in many ways was what drove me away from PHP.
I think PHP is a wonderful platform for many reasons, but consistency of vision and design is not one of them. It's just a grab bag of so many people injecting their own ideas into how this thing is going to be designed. I wanted something that was a ton more streamlined than that. And the only way I knew how to secure that in the beginning was why I'm going to be the one making the decisions around it.
34:25 Q: Speaking of the design, can you describe the executive summary what the architecture of Rails is really about?
Sure. The architecture of Rails is that it's going to be full stack. Which means this is not going to be just one piece and then you have to go out shopping for another ten pieces to build an web application. I wanted something more... you have the entire box. With Rails today, just using Rails and nothing else, you can build an awesome application from the bottom up. That meant including the database, the templating, the MVC structure, bla-bla-bla. The core reason of why I wanted to do this was because I wanted all the pieces to fit together just as well as an integrated Apple stack. Apple products were definitely a leading inspiration for the design of this.
Just how well the whole flow of the iPod works together with... it's not just the iPod, it's the iPod, the iTunes player, it's syncing with your library, it's all of these things are very neatly integrated because every single piece knows about the other piece. Rails was designed with that same approach in mind. That the whole flow was going to be awesome. That you weren't going to have these big cracks in the seams between the frameworks that you get with a lot of other technologies: just include everything. You get a lot of different cams, they have their own motivations, they have their own time-lines, they have their own priorities, but when you run everything in one monolithic design structure you get to control everything. Controlling everything is absolutely key to ensuring that perfect experience.
36:24 Q: It starts with the fact that I think that Ruby is actually in most cases the thing that's listening on port 80, right? You actually starting with your web request all the way from Ruby forward, it's not separate, then?
Sort of. There's been ways back and forth between that. When I started working with it I was actually using mod_ruby, which had its own list of problems. But what I was using it for in the beginning, it was fine. I was still using Apache. But everything else, from Apache handing over the request and all the way through to pulling stuff out of MySQL was handled by Ruby. And was handled by Rails in most cases. The whole end-to-end spectrum was like that.
The other key overarching theme is the notion of convention over configuration which is really probably the number one design imperative that we have. We're going to put the stack together for you, configure everything for you, in a way such that if you're building an application that is put together just like most applications are put together most of the time, most decisions will be made for you.
One example I always pull out is “what you gonna call the primary key in your tables?” When I was working with PHP and Java, every single shop, almost every single application, would have its own naming scheme. Some would say they have the ‘Products’ table and then they'd have ‘productid’, others would have ‘product_id’, some people would have ‘prod_id’ or ‘p_id’ or ‘P_id’, and every time somebody made a new design decision it meant configuration. You now have to tell your models, your objects, how they're going to talk to this database table. Because it needs to know what the hell you called the freaking primary key column, and it just doesn't matter! Who cares what the primary key column is called? It just doesn't matter. It's going to have zero impact on the usefulness of your application.
So, the idea is: what about we make that decision once? Let's just frigging call it ‘id’ and be done with it. If you call it ‘id’, I can assume you're calling it ‘id’, and then we don't have to talk about it again. And there are thousands of decisions just like that. Decisions that you could make a variety of choices [for], but the decisions just don't matter. What matters way more is the productivity you get out of *not* making them. By just deciding on these conventions, instead of requiring you to configure everything from scratch — this is especially true with the Java frameworks: one of the sort of jokes we had in the beginning was XML setups: you have all these Struts and other Java frameworks that require reams and reams of XML setups, telling the system how that piece work with that piece, over and over and over again. And again, from this notion of thousands of programmers who are making the same stupid, meaningless, insignificant decisions every single freaking day. And it's a drain on productivity. Just decide it once! It just doesn't matter that much. Your ego just doesn't matter that much. Your intellect should be applied to something much more worthwhile than picking the name of the goddamn primary key table.
39:50 Q: So, you rely a lot on good, well chosen defaults then, but you do have ways of overriding all that, right?
Absolutely. I mean, there will always be special cases. You have legacy databases. You have some guy who really cares about what do you call the primary key. And I mean fine, all right, let him have it. It's not gonna sink the ship. It's also a bait and switch. We had a lot of people coming to Rails, especially in the early days with their own set of really hard-held beliefs about what things should be called or whatever. And the first three days they'll try to reconfigure Rails to fit all of their conventions. And then after three days they're thinking: “God, this is a lot of work. Look at how simple my model could be if I just stuck with the Rails conventions”... and then they convert all their stuff over to Rails conventions and they cut out a ton out of configuration work and everybody is happy.
40:45 Q: Along with ‘convention and configuration’ I also see the phrase “Dont repeat yourself” a lot with Rails. Can you describe what that means?
‘Dont repeat yourself’ is all about not having the same intentions spread out in multiple places. Don't have one configuration. If you're calling something, let's again take the example of the primary key. If you're calling that for ‘id’ you shouldn't have to configure that in three different places that all have to work together and all have to be changed together. You should just pick one authoritative place to have that information stored. And then you can make changes from there. It also goes with the the whole Ruby idiom: we don't want those Java boilerplate ten line things: that's repeating yourself. If you have the same idiom, if you have the same intentions, that should really be exceedingly a short expression. And that goes up throughout the entire framework. Just keep one place to change those things, and keep the idioms very short.
41:50 Q: So Rails is a web framework, that you said earlier, is a MVC. Can you fill that out a little bit? What's MVC?
MVC is ‘model view controller’. Which is just basically a way of splitting up the logical parts of an application into individual segments that make sense in their own. The model part in an MVC application is where all the business logic is kept. Those are all the classes like ‘Post’ and ‘Category’ and ‘Author’ and all those things –say if you're making a weblog– you'd keep all that stuff in the Model. And you'd have all the logic about whether the author is allowed to make a post and how the relationship between posts and comments work together. Those are all sitting in the model, so that's all the business logic.
42:40 Q: That's typically mapped using an object-relational mapper?
Yes, very often backed by a database in some sense, not always, but most of the time. And that's where in Rails we're using something called ‘ActiveRecord’. Which is this way of mapping database tables to objects, and then decorating those objects with logic.
The second part would be the controller part, which is basically the logic that accepts a request from the outside world, like: the user clicks the ‘delete’ link. Now what's supposed to happen? The delete link goes into the controller, and the controller has a Post-controller delete method. That delete method will first look up the appropriate comment, and then it will destroy that comment, and then will redirect the user to the index page, for example. All that logic about the how flow of the application and the flow of the interface is going to work, lives in the controller.
And the final part, the view, is all the UI the user will see. So for example the index page has to be (in a web application that's probably going to be HTML) and you have to have some way of decorating and filling that up, and you do that in the view. A view is usually consisting of these various forms of templates, where you mix logic with presentation and somehow end up with a dynamic UI.
So basically you split those three parts up, because it's much easier to maintain. You can test each of the individual parts by themselves, and you're going to have some way of keeping your head straight. If you have any application of a meaningful size, if you just munch it all together in huge scripts that does all of that, it's going to be very hard to keep it all together in your head, to keep it logically separated, and it's going to be very hard not to repeat yourself. You're probably going to repeat yourself over and over again if you don't split these parts up.
44:40 Q: One of the things I've noticed with a lot of the Rails applications, is that they seem to be all, or at least for a predominant part, they use RESTful URLs to do this mapping to the controllers. Is that something that was designed in from the beginning, or something you stumbled across later on?
It wasn't designed in from the beginning. The whole restful approach is actually something the rails community picked up on. Three years ago I had a presentation at one point at RAILSconf where I introduced “we're gonna do this in Rails” because I've really gotten just enthralled with the idea of REST. And the reason I got enthralled with that idea of REST is exactly the same reasons why I like convention over configuration.
REST is a set of very clear conventions about how you should structure your application, that on the outside is all about resources – it doesn't talk about the implementation of it, it talks about how URLs are supposed to work and how the HTTP verbs are supposed to be applied to get that, but if you let it seep into the framework just a little bit deeper, if you let it seep into the controller level it can also have a magnificent impact on the design of your application, because it brings such a clarity to what supposed to go where. Before I got interested in REST the one spot in my applications that were always out of control, would be my controllers.
I have a global controller. The thing is, if you don't have to right vocabulary to talk about something, it's very easy to get sucked into these trashcan notions, a sort of grab bag, a ‘misc’ library, that includes all these functions you don't know where to stick anywhere else. With the global controller for example, in Basecamp we still have a global controller, it would control what the color scheme was supposed to be, it would control sending invoices, it would control all these things that have nothing to with each other, that have absolutely zero cohesion.
Internally the REST framework is saying: Let's expose everything as a resource, which in my mind often maps very well to a single model, and lets expose four main verbs. You have your GET, your POST, your PUT and your DELETE. That framework, looking through the world in those four things makes everything a lot simpler. Now all of a sudden, looking at the global controller how was I supposed to apply that to the global controller? Obviously I couldn't. I had to start picking out these resources. So wait a minute, I should probably have a color scheme controller because that's the only way I'm going to fit GET, PUT, POST and DELETE on it. Because if I just have a delete on my global controller, what's that going to delete? Is that going to delete the color scheme? Is that going to delete the invoice?
So it gave you this vocabulary, gave you these constraints basically, of saying “There is no way you can make this mess. This mess does not fit in very nicely RESTful view of the world. So you have to clean up your goddamn mess.” And the constraints would come on early on. The global controller didn't [use] all this bullshit. You'd have just three methods, but just like the ‘misc’ library, three methods grows into 20 methods, grows into 50 methods, grows into a 100 methods, and all of the sudden you have a huge mess of which you have no idea how to clean it up, and how it even got to be this messy.
The REST approach gives you this discipline of splitting everything out really early on. And it is a little bit cumbersome and it requires some getting used to. And I remember asking “Why are we doing this? Is this even worth it? Do users even care?” To be frank I don't even care about the users: for me this is an internal design tool. In some sense just like test driven design is not really about the tests; it's a lot about the design which comes out of that. To me, RESTful web applications are the same thing. They're about the web in the sense that it's going to be nicely behaved web citizen application you get out of it in the end, but the key benefit to me is the internal design constraints that [put] some things.
49:00 Q: Part of the idea of not having a lot of configuration to do is that you're mapping these RESTful URLs almost directly to the names of classes that are happening as controllers, right?
Yes, absolutely. You map resources ‘Posts’, that's the one line of configuration put in. Then it'll automatically know you're gonna have a Post controller and that Post controller is gonna have a set set of methods. The index method is going to be called when you do a GET on just the ‘/Posts’. The show method is going to be called when you do a GET on ‘/Posts/1’, or any other integer. The destroy method is going to be called when you call ‘DELETE /Posts/1’. So you have this entire mapping scheme that's already set for you. It's this wonderful convention where all your controllers look the same. They all have the same methods. They all have index, they all have show, they all have destroy. They all have these things. And you don't have to configure that. There is no configuration going on between telling you how is this URL scheme actually going to map to my internal controller. No! Because you already this mapped out, at least for the 80% case, the default case, of all these standard methods that most controllers have most of the time.
50:30 Q: The responses are coming back –obviously in HTML in order for the browser to understand that– you have some sort of templating language in Rails. Has that evolved over time or did you put in the entire design effort in the beginning?
The template language that I use for Rails is something called ERB, which is basically just mixing Ruby with HTML. There's a bunch of other templating languages out there that are more involved, more intricate, or use more indirect methods of different things. But for me, Ruby is a good enough language that can be used as a templating language. That to me says a ton about Ruby. Because you cannot say, for example, the same thing about Java.
Java is simply not a succinct enough language to be used as a template language. It's too verbose. The HTML would drown out in between all the needless Java code. In Ruby, the code itself is succinct enough that it's not gonna drown out the HTML. HTML is actually more verbose than Ruby — definitely not the case with Java. Java is much more verbose than HTML. So you have to have that balance and it is a wonderful enough language that you can use it for templating. I never found the need to come up with another language for that. There's a bunch of other reasons and concerns for why you would want to do that sometimes. Say, you have end-users who are designing templates. You don't want them to give them the full power of Ruby. That's sort of giving a toddler a light saber. You don't want that much power in his hands; something bad is gonna happen.
You have more restricted template languages; you have languages that are for other styles. There's not a clear division between the Ruby and the code itself. There's something HAML which tries to make XML less verbose... there's a lot of other approaches, I think there's something like twenty different template engines you can use with Rails. But the default one has been the same since day one, which is basically just HTML + Ruby.
52:31 Q: Almost as many templating languages as that there are for Perl, what a deal ;-) I guess because both are really good at string processing. We used to call it a rite of passage in the Perl world that everybody would eventually write their own templating language.
It's a very popular thing to dig into and write your own thing. We have so many choices. But it's very much a long tail. In the Rails world there is Ruby plus ERB, and then it digs down really deep before you find the next templating language. I don't even know what number two is, but the vast majority would just use Ruby + HTML.
I do everything in an editor called TextMate, which is actually an interesting story because when I first came to the Mac... I sort of worked for 37signals on a PC I seem to remember, but I've luckily repressed all those memories. I [got] to a Mac early on, but there was really not a good editor at the time. I was using ‘Project Builder’ or something which was basically just a text field with no other helper support. I was never into the whole Unix editor world of vi and Emacs. I know my way around vi but I prefer not to. Back in 2004 I had a really good friend in Denmark named Allan Odgaard, who was working on a new text editor for the Mac. And he had already rewritten this text editor four or five times, and he was on the brink of giving up on the whole project. And I was like: “No you can't. I need this thing. I need this text editor, because Project Builder sucks, and nobody else seems to have a good text editor.” I'm not gonna use the staple-mate of the Apple text editors which is called BBEdit. I used BBEdit once or so, and I was like: this is from another time zone, it felt like this is from another time capsule, and definitely wasn't my style.
[OS7 interjection]. There's obviously a lot of Mac users from back in those days. Back in those days I had absolutely no allegiance to the Mac tho. For me, the Mac is all about post-OSX. I wanted something that had that feel to it, so I got really involved with Allan and work with him over a couple of months to narrow down what exactly was TextMate going to do, and get it to a point where we could actually push it out there. Also for my self-interest, because I wanted to use TextMate. It is still to this date the text editor I use, and I'm really happy with it. I alluded to it a few times, use everything on the Mac. Between just a Terminal and TextMate, I'm pretty set for a development environment.
58:58 Q: Do you have a preferred version control system? Are you using svn or git these days?
Well, Git. Git is one of those things for I was a little skeptical upfront. Does it really matter that much? But it does. Git totally does matter. I'm really happy that in some ways I got dragged into it from svn. I was pretty happy with Subversion and I still think that git is such a... it doesn't have very good usability. It is a very powerful tool, but sometimes you want to do a simple thing, and you're like: “What? I have to do these five steps? How does that make any sense at all?” I think Subversion in many cases has lot better usability, but some things it doesn't do well enough. Git is more powerful technology, even if it's harder to use. Git is definitely a big part of the setup and I love it these days. You keep finding these small things about git, I remember the first time I discovered cherry-pick. I'm like, wow!, that's freaking awesome. Or bisect, merge, or some of these other, sounds like they're exotic things, but after you use them once or twice you're like, how the hell did I ever get by without this stuff in the past?
1:00:12 Q: Rebase, have you seen that? Let's just reorder these and merge these two together...
Oh yeah, awesome. It's pretty damn fantastic. Which is actually similar to the experience I have with Ruby. When I first came to Ruby there was so much meta-programming in Ruby that you can do. I was looking into all these internal things, especially around ObjectSpace, and I was like, who the hell would ever want to use this? It usually wouldn't be more than three or four days where I would sit with some program, like: This is exactly why Matz started that method. OMG, this guy is a genius. Sometimes you have that feeling with git too. You have a problem and then you realize, somebody actually thought about this, and they have a really eloquent solution for it.
1:01:00 Q: And there's also an overlap of git and Rails, right? Isn't GitHub done in Rails?
Yes, GitHub is a Ruby on Rails application. That's actually a big part of it too. There's a lot of other version control systems that are similar to git in their structure, but only git has GitHub. And GitHub is freaking awesome. We host the Ruby on Rails project on GitHub. I host all my personal projects on GitHub. GitHub is really sweet. And it certainly doesn't hurt that it's all done in Ruby on Rails, and the team behind it is absolutely wonderful. I was just visiting them in San Francisco not too long ago, and if you're not already on GitHub, if you're not already using GitHub to share your personal projects, you should absolutely sign up for an account today. It's completely free. The only thing you have to pay for is if want private repositories. One of the best Ruby on Rails applications out there, for sure.
1:01:50 Q: Now, keeping the list down to 20 minutes, can you tell me some other famous Rails sites that we might be familiar with?
Twitter is obviously one of the big ones. Sometimes it was a mixed blessing, they had some performance issues for a while, but I still think is absolutely a wonderful site. It's one of those other things where at first I was like: I don't get it. I was first shown Twitter when it was exclusively about mobile phones, it was just about your friends, I was like: “I don't care what Florian had for breakfast. How is this useful to me?” I didn't get it for a very long time, but once you get it, which is usually the point when you find somebody on-line who is posting stuff you care about, you're like: OMG, this is awesome. So, that's one of the big applications.
Yellowpages.com is another big application that's using it. Hulu, which is an app here in the US for streaming TV and movies, is using it, which is really cool. Gini, Anchestry, FindingThings... Shopify, which is a really awesome application by Toby and the guys from Pixelsoup. He's one of the original Rails core members. Shopify is really a cool place if you want to set up a new shop for somebody. They basically took Yahoo shops and made it awesome, and made it feel like it was written in this century. So, that's pretty cool.
I'm looking through the list. We have a long list at http://rubyonrails.org/applications. There's Congregate, which is all about these Flash games. Rivalry, knitting community, ... 43things, which is one of the very early applications for tracking your goals in life. You basically make these lists of up to 43 things that you want to do in life, and you have all these people who can cheer you on and see your progress, and talk to other people about the goals you try to accomplish, which is really cool. Urban Dictionary, I use that all the time to look stuff up. That's written in Rails. That's sort of a grab-bag of some of the... I mean, there's so many applications these days that I'm even having a hard time. And often surprised, I learn that some application I'm using is actually written in Rails.
1:04:15 Q: You can't tell that by the REST URLs?
You can't always. There's a few clues I look for. Usually I do a ‘view source’ and if they're time-stamping their assets, like their images and so on, in the standard way, that's usually the one I use for picking it out. But there's actually a fair amount of other frameworks that picked up the same RESTful naming scheme that we have for Rails. So it's a little hard these days just to tell it by the URLs. In the past it was easier because we used something like ‘/projects/show/1’ which was a clear giveaway that that was a Rails application.
1:04:50 Q: You should have put a little secret [?] item [?]
Right, and link back to some site that I could then farm for Google creds.
1:05:01 Q: You mentioned briefly Twitter. There was a big controversy that came on when Twitter started rolling over badly, and they said, “Oh, it's because of Rails”. Anything you want to say about that?
It wasn't about Rails, but... I doesn't even matter. Whatever language you write in, what matters is the algorithm you use. The worst algorithm implemented in assembler will be much slower than the best algorithm implemented in Ruby, or any language. Faster... not better... And that was exactly the case with Twitter for a while. They had some infrastructure pieces that were just not designed to handle that kind of uses that they were seeing in that kind of scale. They got it under control, and have been reasonable trouble-free ever since. The other thing is that Rails, as any other high-level application framework, is never going to solve the problems of the highest scaling applications on the web. Because no framework can. If you look anywhere...
What's the infrastructure that's running Yahoo or Google? Are they using an off-the-shelf framework for this stuff? Of course not. They're rewriting all the super-performance critical pieces in something really really fast and really custom and really tailored to their environment. It was never going to be the job of a generic framework to solve those peak scalability issues. You were always going to farm those out. At Yahoo! they have a ton of infrastructure pieces written in C++, and then they have a ton of customer-facing stuff written in PHP because the performance of it doesn't really matter. That's a good split to go. I don't find that a failure of Rails at all, because that would be a failure of web application frameworks in general, because they're just never gonna solve that problem.
1:06:55 Q: On your blog recently, you've been posting a series of articles about the Myths of Rails. You want to address the one or two most important of those?
Yes, sure, that's actually a while ago, let me scroll back and see some of the ones I can talk about. Here. For a long time, there's a lot of misconceptions out there. They're either born out of what Rails used to or didn't used to do five years ago, or they were born out of misconceptions entirely. One of them was, that Ruby could only speak English, and therefore Rails could only speak English. So if you wanted to make an application that was in any other language then English, you'd be straight out of luck. Which is of course totally not true. Ruby on Rails speaks UTF-8 just fine. We have a really strong internationalization framework built-in these days. Absolutely no problems. We're currently in the process of experimenting with Basecamp and setting it up to be internationalized and use other languages, and the experience with that we find a pretty good experience.
Another thing being that Ruby is like a hard language to learn. I think that's so untrue. I find that languages like Java much harder to learn. I went to a joint degree college program in Computer Science and Business Administration, and I found that so many of my classmates got turned off from programming entirely because it took freaking twenty-five lines to say ‘Hello World’ in Java. And that's needlessly hard when something like that in Ruby is like puts “Hello World”. How is that harder?
Other myths that are out there, what else we have. Just a bunch of myths about how Rails, since we have this convention over configuration approach that you can only use the built-in frameworks that ship with Rails. Well, that's actually not true. We put a ton of effort into the template engine, making those pluggable. That you can plug in Haml, you can plug in something else that you want to use and just because there is some bunch of people who choose not to do that doesn't mean that that's not possible. It just means that perhaps the defaults that we've chosen are pretty damn good and you don't need to do it most of the time. But that gives rise to some of those misconceptions sometimes. It's not that big of a problem anymore.
We're at the level where Rails is five years old, it's proven itself well enough, that these things have a tendency not to be that much of a problem. Because a lot of this would come up in discussion internally in companies, like “Do we want to use Ruby on Rails? Whoa, I heard it doesn't scale! I heard you can [only] write in English.” You really don't have to make logical arguments these days when you can just point to sites: “Hey dude, check out Twitter. Hey dude, check out Yellowpages.com, or some sites that internationalize”. I mean, they can do it, obviously you can too. I think more than anything, the things that are winning over hearts of the business owners is: what are other people doing? Is this happening on other sites, or are other people able to make this work? If so, we can probably make it work too. Which is why sometimes adoption just takes time.
1:10:22 Q: Current and future of Ruby on Rails. I understand you're merging with Merb or something like that?
Merb was another Ruby web framework that got developed for a time along very similar lines as Ruby. It was born out of picking a few parts of things that Rails didn't do well at the time, and saying “We're going to make a framework that does those things very well”. And what we just realized over time was these things were converging. You had Merb, that was focusing on a number of issues that Rails, for whatever reasons perceived or real, wasn't doing very well, and then you had Rails trying to fix those issues too, from another angle.
We realized we were working under the same assumptions, we had roughly the same intentions and ideas about what a great framework would be. Wouldn't it just be much easier if we pulled our efforts and all pull in the same direction? And luckily that was the conclusion that all the key constituents reached. And we thought: Hey, lets take all the best ideas form Merb and put them into Rails 3, and we'll be reducing again the effort of duplicating all the things from the other camp and we can focus on just moving forward the state of the art, and adding more awesome stuff to a key framework. And I think in some ways it's definitely unique the Ruby community to be able to have such a tight base around Rails. It's very unique vs. Perl or Python or other languages. We have a lot of different web frameworks that all have some following. In the Ruby world we really do have a very narrow power band of... there's a bunch of web frameworks in Ruby, but Rails has a pretty strong hold on the majority of the mind-share in there.
1:12:16 Q: So where do you see Rails in a year or two?
It's getting incrementally better. I think I'm not currently seeing any one thing like REST or Ajax on the immediate horizon that's truly gonna shake things up in such a way that you can't recognize a Rails application written one year form now. Most of the changes that we're making are incremental. We're cleaning up a bunch of things, we're making things faster, we're documenting things better, we're doing all the polishing parts that... if you just take out one of the things and say “Oh, you polish that, well I guess that's nice, but it doesn't really have that big of an impact.” But if you put all these things together, the amount of polish you can put into a year or two worth of effort is going to make a huge deal in the end. Again, just like if you're comparing Ruby and Java, you could pull out a single feature, yeah that's nice, but it's the sum of the parts. I think the Rails from a year or two from now is going to be the sum of the parts, not just one major feature we're dying to implement, but all the little things that are gonna make things better.
1:13:25 Q: I'm definitely looking forward to that, David. It's been wonderful having you on the show today. I really appreciate you taking some time out of your schedule to talk to us about Rails, past, future and all that sort of stuff. Where can people find out more info about Rails?
Of course! Rubyonrails.org is the main portal, and we have links to a bunch of other sites from there. The list of applications is at rubyonrails.org/applications, which is a good place to start. And rubyonrails.org/screencasts is probably the main place to get excited, because you can see somebody build a weblog in 15 minutes and see all the steps to go through, and we have a bunch of presentations there, so that's a good place to get started.
1:14:05 Q: And where can people find out more about you, if they want to follow you, be a stalker I guess? ;-)
Sure! I have a twitter at twitter.com/dhh. I also have a blog that I'm actually not updating that frequently anymore: loudthing.com. And the main blog I'm writing on these days is the 37signals blog, it's at 37signals.com/svn.
1:14:33 Q: David, thank you very much for today's show. I really appreciate it. A lot of people were looking forwards to this show since we start tweeting about it. Again, thank you.
It's been a pleasure, thanks so much. Bye!
1:14:16 Q: Bye! That was David Heinemeier Hansson. He is the creator of Ruby on Rails, as you heard. Wonderful speaker. I love it when I can ask a guest a question and then they just go on like 20 minutes. Very cool.