litany against fear

RailsConf 2009 DHH Keynote

This is part of my series of notes on RailsConf 2009. Check them all out here.

Rails 3! This year marks the fifth year of working with Rails (six really for him). We’re largely doing the same things from 5 years ago. Stop fretting so much if you’re up to date with the most up to date practices. It’s possible to enjoy Rails without knowing everything new that’s going on, and definitely not necessary to rewrite apps as a whole that are using the ‘old’ practicies.

We were supposed to be killed a long time ago. Going through some memories of why Rails isn’t supposed to make it. First off: it wasn’t ‘enterprise-ready’. There was this notion that it was a group of consultants more interested in getting more billable hours and selling their books. This is obviously not the case. It takes time for these arguments to settle.

The next step was copying Rails: Grails, Sails, Monorail, etc. By bringing a few parts that makes Rails awesome into a different language, it can help to make that language not suck. Well, maybe not. If you can boil down what makes Rails coders more efficient, then you don’t need to learn about Ruby or Rails.

Switching back to old systems: the first big one was ‘7 Reasons I Switched back ot PHP after 2 years on Rails’. For some reason since Rails didn’t meet his needs, people saw it as a reason to ignore Rails. News sites like Slashdot and Reddit seem to intensify the arguments behind these posts, but it only lasts for a really short amount of time.

The failwhale! The core argument behind this: Rails doesn’t scale. It’s hard to fight a meme like this, and it’s better just to accept them. Rails has the both good and the bad with this situation, and it doesn’t really matter in the long run.

One of the big ‘storms’ was the Array#second and so on methods, which only lasted for a few days like the other ones. Merb was one of these too, but it’s stuck around. The arguments at face value may seem very heated, but once you dive in, people are trying to solve the same problems.

Chill out. We’re still here despite all of what’s been going on and it’s not going anywhere.

The Philosophy of Rails 3:

• Lock up the unicorns: Not going to solve all of the problems or be a huge rewrite.
• No holy cows: Question what’s going on, get away from things that can’t or shouldn’t be changed. Huge example: alias_method_chain. Nothing is sacred in Rails. Definitely up for improvements that break existing Rails apps, if the arguments are good.
• Have it your way: the real merge! It allows you to choose whatever you want, there’s an accepted way to do things, but you can modify it as you want. Keeping people in the community because of this is most important.

The progress of Rails 3:

No new gems or huge release today. Going over some nice parts of Rails 3 that’s already in the repo.

• New router: Rewriting it again. Routing based on subdomains and user agents as well. Bake Rack into the router so you can mount multiple Rack apps at the same time. Going through some new ways that the router could be designed, both for old style declarations and new REST routing.
• XSS protection: For a long time, it’s been a holy cow and left to the developers to determine when to use the h function to escape HTML. Flipping the convention: all default views will be escaped. You have to use the raw helper to unescape. Mark a string as being safe HTML with String#html_safe!. Thiswill probably cause the most pain for upgrades.
• JavaScript: Unobstrusive means that no javascript in your HTML. Rails needs to do this too, but it’s skipped over this for a long time. Rails is going to adopt HTML5 standards of custom attributes in order to get around this. Showing an example of data-remote: true for link_to_remote, data-method: delete for link_to :method => :delete, :confirm => true.
• Lots of more agnosticism: ActionORM, more flexible generators.
• The great refactoring: Lots of ideas from Merb being brought over. AbstractController + ActionDispatch for making the controllers better and cleaner. ActionRelation will help out with some of the relational math going on under the hood of ActiveRecord.

DHH’s secret to productivity: renegotiating requirements. Most programmers don’t seem to be able to do this and push back. The real lesson here seems to be reflecting on what the customers really need, and trying not to sink tons of time into fruitless efforts. We want to be the hero and do everything the client wants. This is bad, obviously. You need to balance motivation along with what the clients want. The definition of programmer is bad: consider them partners instead.