Ruby on Rails Creator and founder/CTO of Basecamp, David Heinemeier Hansson has responded to questions submitted by Slashdot readers. Read on for his answers.
Can you give us a glimpse into what your main work computer looks like? What's the hardware and OS, your preferred editor and browser, and any crucial software you want to give a shout-out to?
DHH: I've been all Mac since about 2002, I believe. I use a 5K iMac on my desk and a Macbook for travel. For editor, I'm on TextMate 2. I only just switched from TextMate 1.5 a few months ago when an OS X update broke something in it. That editor was just perfect for me. Perhaps in part because I helped Allan Odgaard project manage and promote the very first version. I use both Chrome and Safari for browsing. I prefer Chrome for development due to the better inspector, but I prefer Safari for general browsing and native feel.
Besides that, I'd say that my most useful development tool on OS X is probably Dictionary.app. I constantly look up words and meanings in search of the perfect variable, method, and class names. (See here for a trip down that lane).
"Ruby on Rails" ? Is there a good reason for the name, or were you watching too many old western train movies?
DHH: When I first came up with Rails, it was inspired by an old Java framework called Struts. I liked how it was short and had a builder's taste to it. But when I went to register rails.org, it was taken, but RubyOnRails.org wasn't. I ended up liking the longer name even better as it highlighted the true magic of Rails: How it uses Ruby.
by Parker Lewis
What were the influences (I mean, other frameworks, even in other languages) you used while building the first Rails version?
DHH:I looked at everything I could get my hands on in PHP, Python, Perl, Smalltalk, but, most importantly, Java. Java had the most well-developed framework scene back in the early 2000s. There were a ton of great ideas just waiting to be liberated from the shackles of that awful language. So I went on a great intellectual pillage tour. As much of the inspiration was things "I absolutely abhor and wouldn't want people subjected to" (like the practice of 1000s of lines of XML configuration situps that were common at the time).
A lot of the inspiration also just came through the pattern movement, particularly Martin Fowler's Patterns of Enterprise Application Architecture. That book used Java to describe the concepts, but that was just a minor annoyance. The strength of ideas still shone clearly through. So I kinda went shopping in that book for ideas that gelled with my sensibilities for speed and cleanliness of code in Ruby.
A few times that did lead me astray. There are concepts like dependency injection that are critical for testing in languages like Java, which just don't carry their own weight in a language like Ruby. So a few times I ported an idea only to realize it just didn't fit and wasn't needed in Ruby. There was a lot of A/B testing of the code: Is it better when I apply this pattern or not? Oh, not. Gotta go then!
How do you have so much time for development?
Hi DHH. How much of the code for Basecamp 3 did you personally write? and is it a challenge to clear out long stretches of time for concentrating on development (vs meetings, etc) due to your seniority at the company? From your blog posts it seems that you're definitely still significantly involved in day to day development.
DHH: I wrote the lion's share of the first release of Basecamp 3 myself. In terms of the code needed for majestic monolith at its core. We had teams working on native apps for iOS and Android and we had teams doing a new WYSIWYG editor + other supporting frameworks like Turbolinks 5. But I really did spend a ton of time programming for Basecamp 3 over the course of the 18 months we spent making it and enjoyed it tremendously.
That did come with some sacrifices to other aspects of the business at times. We did put some initiatives on the backburner and I checked in somewhat less frequently with other teams during that time. But it was greatly helped by the fact that we have such a light organization already. We don't do a lot of meetings as is. Even now, I can easily go a whole week with maybe only 1-2 meetings. And by meetings, I just mean jumping on a Google Hangout or Skype video chat with someone for less than 1 hour anyway.
This is what I enjoy most: Building software. So I'll be damned if I stop doing that just because we've had enough success that I perhaps technically don't need to. Jason perhaps doesn't need to design much of our software, but he still does that too. It's just what we love to do. Building things! And then we design a lightweight organization around that which enables us to spend most of our time doing just that.
I think that's really the key. We could easily have designed an organization where just sitting in meetings all day was how the weeks went for Jason and I. But that would be a special kind of hell for us both. And we get to call the shots on the direction of the company and its design, so why on earth would we subject ourselves to that?
cross-pollination with racing?
by izzo nizzo
Have you ever had a eureka or solved a bug while you were racing, or at least driving? More generally, do the abstractions that help you learn to race assist you in understanding parts of your web & technology systems?
DHH: Driving a race car fast is surprisingly similar to programming software. And managing and influencing a race team is incredibly similar to managing a software team. It's all systems theory. What are your positive feedback loops? What are the constraints you have to exploit? Same with developing a feel for grip. It's like developing an eye for good software. You get a sense of quality that's embedded in your gut feeling when you get good enough that you can just make the right calls most of the time without too much deliberation. It's a great feeling.
So is the feeling of flow. Outside of programming, racing is the one activity that has given me access to the most flow states. Learning something new just beyond the grasp of my current abilities. That's happiness.
What would you do differently?
You are quite famous for being loudly dismissive of Rails critics. But do you ever get the urge to learn from your experience (and mistakes) and build a new framework that's different from Rails? In other words, if you could burn Rails to the ground and start over without the need to maintain any sort of backwards compatibility, what would you do differently?
DHH: Generally speaking, Rails today is my ideal version of a web development framework. Whenever I stumble across something I don't like, I change it. It's still a malleable thing. We've made enormous strides between the major versions. Every time I use Rails I think "is this the very best it could be?", if the answer is no, I either try to fix the problem myself or at least record it so others can take a stab.
So basically, I wouldn't really change anything. I don't spend a lot of time looking back at the past with regrets. I got to where I am by going where I went. Trying to retrace those past steps to fantasize about a more optimal path seems like a complete waste of time to me. It's sunk cost. A path already traveled. What interests me is looking forward and figuring out how to improve from where things stand now.
Ruby vs Python
by Anonymous Coward
Python has gained what could be called a critical mass of popularity and works at a similar level of abstraction to Ruby. If you were creating Rails today, would you still choose Ruby? What are its advantages?
DHH: Tons of languages have reached critical mass. That makes it a poor filter for selection. Ruby did so a decade ago. But I specifically picked Ruby BEFORE it had reached critical mass because I didn't give much of a damn what everyone else was using. Rails is a love letter to Ruby. Written by and for myself. Even if nobody else ever had shown interest in reading it, it would still have been worth it. I first and foremost created Rails such that I could use Ruby to build software every day.
I've yet to find another programming language that speaks to me like Ruby does. There are other languages with great ideas or some specific constructs that I find appealing, but nothing brings it together for me like Ruby does. I unashamedly love Ruby. I love writing it. I love reading it.
Python just doesn't do anything for me. I very much respect it. There's lots of shared cultural heritage between the two languages. But why would I spend my time writing software in a language below the grade of love, if I can use one that makes my brain sing?
I tried to "get" the philosophy of RoR, but ultimate failed. It seems RoR has a steep learning curve; but once mastered, one is allegedly more productive. Some use the analogy of becoming a medical doctor: a long slog through medical school, but big benefits (such as money) await you in the end. Do you agree with this alleged trade-off profile of RoR? And, how can this approach work for decentralized departmental groups with lots of coder turn-over, especially if the bureaucracy makes it difficult to hire such that coders from other platforms are to be retrained? The ramp-up time for re-training seems hard to justify under such an environment without a RoR-only edict from on high. Would you agree RoR may not fit certain organizational environments? Thank You.
DHH: I don't agree that Rails is any harder to learn that any of the environments I know of, if your target is to build modern, full-fledged web applications. There are certainly environments, like PHP, that'll get you started more easily. And I respect PHP very much for that focus. But as soon as you go beyond the very basics, I think the learning curve there is steeper. Rails simply has so many answers to so many questions, and it introduces those answers in a pretty progressive way. You don't even have to learn what SQL injection is if you're using the preferred query methods. You SHOULD learn what that is, but you don't have to to get started. If you don't know what SQL injection is and you use the MySQL db query functions with a string-interpolated query in PHP, well, you're going to be in trouble.
Secondly, I don't care at all about solving the problem of revolving-door shops where the purpose is to churn through low-skilled labor as quickly as possible. That's a dystopian world of development. What's funny, though, is that Rails actually DOES work pretty well in that environment given all the strong conventions. Most people can jump from one Rails app to another an quickly have a very good idea of what's going on. Try that in an environment that either emphasizes home-grown frameworks or stitching a thousand tiny packages together. Good luck!
I think the fact is that development software with a revolving-door team is always going to be a clusterfuck.
Elixir and Phoenix
What do you think of Elixir and Phoenix? I haven't used Ruby on Rails but I really like Phoenix and looking at Rails I can see a lot of influences. But it's hard to beat the foundation that Erlang brings. Maybe I should have taken a better look at Rails while I was still using Python.
DHH: I love seeing entirely new paradigms being popularized and explored. Erlang is fascinating and I can totally see where some of its trade-offs make perfect sense. You'd be crazy to write the message bus of WhatsApp in Rails, for example. But likewise, I think you'd be wasting your time trying to make Basecamp happen in Elixir. And as it so happens, I write Basecamp and not WhatsApp, so naturally I gravitate towards technology that works best for that.
But it's also great to see many of the ideas, conventions, and even vocabulary we developed for Rails is spreading to other environments. Rails itself borrowed so much from earlier frameworks and languages that its wonderful to see it pass that forward.
Personally, my brain works better with object-oriented programming than it does functional. And so too does my sense of aesthetic.
But it seems like that's one of the lessons people have to learn by themselves. Just try to string things together on your own a few times and you'll quickly get an appreciation for what Rails provides as a backend framework. We've had tons of programmers try just that and come back for refuge.
As far as I can tell, by default ActiveRecord does not enforce referential integrity at the database level. Is there a reason for this omission? Also is there any plan to introduce parameterized queries for raw SQL queries. I still keep seeing people on stack-overflow recommending interpolation as an alternative, and this seems rather dangerous.
DHH: Active Record defaults to using foreign keys for dependent tables and has done so for a while. It's supported doing so for even longer. It also supports parameterized queries for custom WHERE statements and you can you the escape helpers if you're writing the whole SQL statement from scratch.
We don't have a single full SQL statement in Basecamp 3. The number of cases where that's needed is simply vanishingly small these days. But yeah, sure, you can still take off all the safety gear we provide by default and jump head first into murky water.
I worked on a project around 2007 that used Ruby on Rails. That was my first experience with Ruby and my first experience with a real web product. I liked Ruby and Rails, but it was easy to get bitten by some of the abstractions. I remember the site bogged down really bad whenever we searched for a record in a large database table. The problem was that the database was hidden behind ActiveRecord, so it was easy to forget we were using a database at all. Writing a for loop to search for a record that matched some criteria felt natural, because our interface was with objects, not the underlying tables. However, behind the scenes, each iteration was a separate query. The result was thousands and thousands of queries, instead of just a single query with a simple WHERE clause. We were essentially doing in Ruby what we could have done much more efficiently in SQL. Once we realized the problem, we rewrote that kind of code so it used more or less raw SQL. The result was much faster, but we lost the readability of the abstraction. Everyone on the team was new to Ruby and Rails (grad students who shuffled in and out each semester), so it's possible that we were just doing things completely wrong. Still, it feels like it shouldn't have been that easy to shoot ourselves in the foot. Have things improved since then? How do you balance nice abstractions like ActiveRecord with performance? How do you make it clear to novices what's going on internally, so they can avoid the mistakes that we made?
DHH: Rails makes it really easy to get going, it tries to guide you to an enlightened path, but ultimately, you still have to learn a lot to be a successful developer. I don't know why people keep expecting that it doesn't require careful, prolonged study to become proficient with a development platform like Rails. All we promise is that it's easy to get started, which means you'll hopefully gather the motivation to keep going. Because making your way through "My First Rails App" isn't the destination, it's the start of the journey.
Developing web applications is complicated. As in there are a lot of moving parts and learning about all of them is key to mastering the domain. Yes, you can get started with very little base knowledge, and that's wonderful. It helps more people start the journey rather than having a 4-day tall wall of byzantine XML configurations to complete before your app server will say HELLO WORLD. But it's not the matrix. You can't just load a cartridge and proclaim I KNOW RAILS NOW. It doesn't work like that.
In terms of the specifics, you should look into preloading. We don't use any raw SQL any where in Basecamp 3 and we don't need to. You can easily avoid N+1 queries and other performance bottlenecks and still keep the abstractions in place. But yes, it takes some time to learn that. And if all you know is SQL plus a little bit of Ruby and Rails, I can definitely see how you end up with "fuck it, let's just write raw SQL, rather than learn the abstractions". That's the tradeoff with frameworks. I think that's the natural evolution of learning. Beginners make mistakes. Those mistakes motivate learning how you can avoid them in the future. After a few runs through that cycle, you're no longer a beginner, but a novice. Keep going and you'll get proficient. Go further still and you just might one day become an expert. Expect to be an expert on day one? You'll likely never become one.
What are your thoughts on the MEAN stack?
What are your thoughts on the MEAN stack ( MongoDB, Express.js, Angular, and Node.js)?
DHH: It takes all kinds of people to make the world go around :)
what still makes you excited about Rails?
by Anonymous Coward
First of all, thank you for Rails, it helped me to convince my former employer to look beyond Java for web application development and now about half of the projects I do is helping teams of smart people who've painted themselves into a corner using the platform. What a beautiful statefull mess we living in! I personally feel your contribution to web application development in general is not Rails but the explosion of batteries included web frameworks we are seeing around us now. Things got shaken up 10+ years ago and they are still stirring. Yes, the github is full of failed frameworks withering away but also some really cool stuff spawned in the ripples Rails caused. My question: now that things have cooled down a bit regarding Ruby on Rails (merb and arel have been assimilated, framework upgrades are almost doable, most have settled on minitest, etc) what still makes you excited about this project or are you secretly migrating basecamp to phoenix and assimilate that into Rails too?
DHH: I love writing software for the web in Ruby. The web changes, our applications change. Both those vectors of change cast new light on what the perfect framework should look like. So I keep chasing those rays as they deflect. It's a lot of fun. The work is never done. We've just released Rails 5.0 which was a major step forward. It adopted WebSockets as a first-class target for Rails applications and did it in a way that builds on everything else we already have in Rails. I got to use that feature to build some awesome real-time stuff in Basecamp 3. That's such an addictive and rewarding cycle. One that I doubt I'll ever tire from.
Talking about Danish devs
Why is Denmark so keen to develop languages?
DHH: Danes simply have to learn other languages to communicate with the world at large. Danish is spoken by some six million people. It's almost impossible for foreigners to learn. So I guess a bunch of us combine those two factors to come up with ways to communicate with computers and communities.
Just stopping by to say: Thanks!
I am impressed by all the sour bitching about RoR in /. If you tried, and cannot learn it, then programming just might not be for you. Granted, it might not be the perfect fit for everybody, but RoR has an impressive merit on the growth of the web. 10 years ago I discovered it, and the framework taught me how to structure complex business applications and back them with proper unit and integration testing. Today we run a company on the 6 digit revenue that is backed mostly by RoR. Thanks David!
DHH: Thanks! Always great to hear people who bootstrap new businesses with Rails.