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.
"Ruby on Rails" ? Is there a good reason for the name, or were you watching too many old western train movies?
Ruby On rails had a huge spike in popularity a decade ago. Then the traditional forms of development had taken over. How do you plan on keeping the language up to date on the current trends?
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
What were the influences (I mean, other frameworks, even in other languages) you used while building the first Rails version?
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?
Are you in the mindset of embracing Angular, React, Ember, etc, or is your vision focused solely on Turbolinks as the future of Rails?
Using the power of hindsight what would you have done differently if you were to start Rails again from scratch?
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.
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.
Table-ized A.I.
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?
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?
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.
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?
With the rise of Javascript front-end frameworks (Ember, Angular, etc.), is there really a serious place for large opinionated server-side frameworks any more?
Is Rails destined to be a framework for writing APIs to feed front-end frameworks? And if so, is that enough?
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 recomending inerpolation as an alternative, and this seems rather dangerous.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.