Russ Olsen: Michael, let me start by saying how happy I am to get this chance to talk to you. I've been a big fan of the first edition of the Ruby on Rails Tutorial for some time. Not only have I used it to help programmers new to Rails come up to speed, I'm happy to say that I've profited from going through it myself.
Michael Hartl: I've enjoyed Design Patterns in Ruby, so the feeling is mutual. :-)
Russ: One thing that surprised me as I was preparing for this interview is that you have a Ph.D. in theoretical physics. How did you start in physics and end up in Ruby?
Michael: My work was mainly in computational physics, so I was writing programs all the time as part of my Ph.D. research. I also got interested in the idea of starting a company when I graduated. It was obvious in the late '90s that software was moving online, so I decided to learn web development. I started with PHP, moved on to Python (in the pre-Django days), and then found Rails.
Russ: The 2nd edition of the Ruby on Rails Tutorial is due out in August. What's new with this latest version?
Michael: The new edition uses Ruby 1.9 and Rails 3.2. This includes the new asset pipeline and a rewrite of the authentication system using has_secure_password. The sample application's site design has also been completely re-done using Twitter's Bootstrap framework.
Russ: One of the best parts of the Ruby on Rails Tutorial is the combination of the video lessons with the book. How do you decide what goes in the videos versus what goes into the book?
Michael: My process is simple. I put the book's PDF on my iPad and then read along while developing the sample application. This invariably leads to commentary and digressions that wouldn't be natural in the context of a book but make sense as part of a hypothetical conversation with the watcher of the video. I also make a point of keeping some of my mistakes (instead of editing them all out), both to teach debugging techniques and to reassure the watcher that nobody's perfect (especially me).
Russ: I'd also like to ask you about what I've come to think of as the Rails 'magic' problem: The good news about Rails is that it takes care of so many of the mundane details of building an application. The bad news -- at least if you are trying to learn or teach Rails -- is that to the newcomer, all that help seems indistinguishable from magic. How do you cope with this in the Ruby on Rails Tutorial?
Michael: I'm not convinced that "magic" is a problem. Rails includes a domain-specific language for making web applications, which shields you from the underlying implementation. I think this is a feature, not a bug. After all, Ruby is written in C, but you don't need to understand C to use Ruby. I consider that a good thing, even if it does seem a little magical at times.
Russ: One of the fears that I have heard voiced with increasing frequency lately is that as Rails has grown more mature and capable, it is also slowly drifting away from its original concept as a simple, easy to use framework. What do you think?
Michael: Rails was always designed to be a "full-stack" framework, and I think that's a major virtue. My hypothesis is that almost all websites, even ones that are originally only static content, eventually become full-blown web applications. This means you should always start with a full-stack web framework. For example, the official Rails Tutorial site is a Rails app, despite being almost all static content, and this has saved me enormous headaches over the past couple of years. (This includes custom redirects, caching, and the occasional signup form.)
One role the Rails Tutorial can play in this context is to offer those new to Rails a path to basic competence without having to face the complexity of the full framework. Once they have a good foundation, they can proceed to the many intermediate and advanced Rails resources to improve their expertise.
Russ: Another good news/bad news aspect of Rails is just how fast it is moving. How do you manage to keep yourself and the tutorial up to date?
Michael: I pay attention to changes that might affect the tutorial, mainly by subscribing to Riding Rails, the main Rails blog. Rails has matured significantly in the last few years, and most new changes make little difference to beginning Rails developers.
Russ: Along the same lines, do you have a favorite recent change or new feature in Rails? A least favorite?
Michael: The introduction of has_secure_password made writing custom authentication systems much easier. In fact, it led to the elimination of an entire chapter of the Rails Tutorial, so the second edition actually has one fewer chapter. (It's slightly longer, though, due to material new in the second edition.) I can't think of any changes I really dislike, and I hope Rails 4 keeps it that way.
Russ: I've always advocated that people learn some Ruby before they dive into Rails. In the Ruby on Rails Tutorial you take a hybrid approach -- teach a little Rails, then a little Ruby. Why did you go that way?
Michael: Many people come to the subject with a great enthusiasm for writing web applications, and I don't want to dampen their enthusiasm by telling them that they first need to read a 500+ page book on Ruby. I can go either way on this one, though, and it really depends on each particular reader.
Russ: So what do you do when you are not working on the Ruby on Rails Tutorial?
Michael: I like to take time off when I'm not writing or screen casting. Last year, after the first edition was done, I took several trips, including one that evolved into a global circumnavigation. This time my leisure is less ambitious, but I am planning a trip to New York, and I'm reading a lot of old books.
Russ: What's next for you?
Michael: I have a four-step plan for world domination. The Rails Tutorial is Step 1. Next up: Step 2. Further updates as events warrant. :-)
Russ: One last question. Higgs boson: myth or reality?
Michael: It's real, all right, and finding it was an impressive piece of detective work. Now all we need is to find a Bigfoot and a Loch Ness Monster and our sleuthing will be complete.