Notice: Undefined index: order_next_posts in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 194

Notice: Undefined index: post_link_target in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 195

Notice: Undefined index: posts_featured_size in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 196

Yehuda Katz on Merging into Merb

Alex Handy talks to Yehuda Katz, one of the brains behind big changes in Ruby on Rails 3.0…

This article originally appeared in issue 86 of Linux User & Developer.
Linux User & Developer, one of the nation’s favourite Linux and Open Source publications, is now part of the award winning Imagine Publishing family. Readers can subscribe and save more than 30% and receive our money back guarantee – click here to find out more.


In December of 2008, the Ruby on Rails community was at a crossroads. The mainline Rails project was losing ground to Merb, an alternative open source MVC framework for building Ruby applications. The community was fragmenting. Yehuda Katz was the creator of the Merb framework, and rather than continue on with that project, he and his fellow contributors decided to merge Merb and Rails. The decision sparked a number of Rails homecomings for other outside projects, and in February the first beta of an integrated Rails 3.0 arrived. We sat down with Katz to discuss the past, present and future of Ruby on Rails.

How have things been on Rails since the merge with Merb?
It’s been good. The interesting thing that’s happened since that is a lot of other Ruby projects have done it. There’s a tool called Webrat, which is a full stack testing tool; and abstraction around HTML Unit. Someone said I can make it better,
they called it Capybara and they pushed it into Rails.

Also, Micronaut. It’s basically guys who said “we can do rspec better”. This has started to happen in the Ruby community, and it makes me happy. I think there is too much in the open source world of people building
software because you want to put your name back out there.

That’s been a positive outcome. Also the Rails core team diversity has been very helpful. Rails core, before, was 37Signals and some people doing client work. Now we have people doing custom development around it. We have people working on problems we didn’t have before. It’s definitely caused us, both people who are new and veteran contributors, to question our assumptions. The conclusions have been almost 100% positive.

The community has gotten a lot healthier since the merge. Like Rails was getting stagnant. A lot of people who are coming back now are coming to Rails to first contribute. A big chunk of the time I spend every day on Rails is cat herding. And trying to balance the need to be involved in the architecture of the thing, and getting things done by real people interested in doing things.

We hear things are being uncoupled, starting with Prototype?

Unobtrusive JavaScript. Rails is no longer coupled to Prototype. That was a community effort. DHH tweeted “we’re running behind”, and a community formed out of the ether. Less than a week later it’s all done. Basically, what Rails did before, when you said ‘link to remote’, like, I want a link that when you click it makes an AJAX request and when it comes back, put it in a div. In Rails onclick, you would have to go through and find all those places where you used Prototype and remove that reference. People made shims they got out of sync. The way it works in Rails 3, it’s straight HTML: a href = ‘actual URL’ and it uses the HTML 5 data tag. It supports custom attributes. We’ve created a library that says ‘find any links and wire them up’. Anybody else in other libraries like Dojo who want this benefit just have to write JavaScript and not Ruby. Before, having someone go and hack in the helpers and such required someone on both sides of the fence at all times.

What are the biggest changes for Rails 3.0?
The biggest thing is security. We went through the known remaining security vulnerabilities based on having spoken to Twitter and having them say “your security tools are too manual right now” [to prevent cross-site-scripting vulnerabilities]. Almost every framework says if you use user content, just escape it. It’s easy to forget to escape it. As an attacker, you have to find the places in web applications where they forgot to escape. What we’ve essentially done is made Rails pessimistic by default. If you try to put in a string into HTML at any time, we automatically escape it. We went through all of Rails’s internals and marked the form tags as safe, which means that for the vast majority of cases, users won’t have to do a lot. But there will be cases where they were relying on content input by the user that was unsafe. But it’s now almost impossible to have an accidental XSS attack.

We’ve also gone into cross-site request forgery (CSRF) protection. We were pretty rock solid before, but there were cases where we were blacklisting things which were not vectors for an attack. We made it less annoying to work with the systems. If there was a form you were submitting with JavaScript, you had to form a token even though that was not a possible vector. This makes it less likely for people to turn [CSRF protection] off.

The second big thing is improving interoperability, mainly with other Ruby libraries. We’ve gone through Rails systematically, and found where we were coupling ourselves to ourselves and removed those. Rails controller view code is no longer coupled to the models, so you can use any views you want. We also added support other templating languages. We made it a lot easier to support other testing frameworks. TestUnit was standard, and others had to do a lot of work to strip out our support for TestUnit and add their own. Using rspec felt worse than using TestUnit. TestUnit itself is a plug-in now.