Slashdot Mirror
Interviews: Ask Ruby on Rails Creator David Heinemeier Hansson a Question
David Heinemeier Hansson created the Ruby on Rails open-source web framework in 2003. David is also the founder and CTO of Basecamp, a project management tool that's been used by more than 15 million people. In addition, David is the best-selling author of REWORK, a book about starting and running businesses a better way. David has agreed to take some time to answer some of your questions.
Ask as many questions as you'd like, but please, one per comment. (And feel free to also leave your suggestions for who Slashdot should interview next.) We'll pick the very best questions -- and forward them on to David Heinemeier Hansson himself.
Ask as many questions as you'd like, but please, one per comment. (And feel free to also leave your suggestions for who Slashdot should interview next.) We'll pick the very best questions -- and forward them on to David Heinemeier Hansson himself.
You ended up with something that reads almost as the same as Python, which has a much larger audience and library set. Couldn't you have just started with Python?
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
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?
I can't believe I just read all this crap from these whining beaches. It's like Slashdot gulped a keg of Red Bull while doing an 8-Ball off a teenage hookers ass listening to Nickelback's entire catalog on shuffle repeat.
I guess I don't understand the hate, since I still use Rails almost daily. I work efficiently, my clients pay me well, and because I have enough experience I guess, I don't ever run up against the platform's "performance issues". Granted, I am not building applications that have millions of users per month. Neither are most of the rest of these people. I guess it all boils down to- Haters gonna hate.
On to the questions. I'm going to ask a few, because so many other people threw their questions away already:
1. What's next for Rails 6 (or whatever is beyond Rails 5)?
2. I do notice that people are still talking about performance like it's 2005, and a few programmers I respect have already moved on to Elixir or React. Have you played around with either? Any good ideas we can steal? Better integration opportunities?
3. I feel like I'm always finding out about better "Rails Way" design patterns too late. For instance, when you explained your controllers setup/philosophy on Full Stack Radio. That was a situation where I'd kind of been doing that, but because I never really labeled it or gave it enough thought, it was more like I sometimes got lucky and made good decisions. Sometimes I didn't. Where, in the Rails community, is a resource to pick up on those more advanced patterns? Real world solutions that aren't necessarily a rails default, but are a good idea that will make life easier for developers at all stages of their careers?
Thanks for doing this. I don't know why you would have picked Slashdot for a Q&A though. It's like Reddit's garbage disposal in here.
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?
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.