Original URL: https://www.theregister.com/2006/02/16/ruby_rails/
Ruby on Rails
The Reg sits down with David Heinemeier Hansson
Posted in Software, 16th February 2006 10:55 GMT
Ruby on Rails is an open-source application framework which has won praise for its elegance and high productivity. Its creator, David Heinemeier Hansson of 37signals, was in London for the Carson conference on the Future of Web Apps.
So what’s so good about Rails? 
I’ve billed Rails in the past as PHP meets Java. You get the clean, structured approach from J2EE and Java, but at the same time you get the quick, short feedback loop, instant results from PHP. We have a lot of people coming from J2EE because it’s just too complex, they can’t get anything done. Then we have a ton of people coming from PHP because they’re realising, it's simply too unstructured. I can’t figure out my code after I’ve written it, I have decreasing productivity over time. Getting those two factions together is the big goal of what we’re doing with Rails.
And why Ruby?
Ruby is a language unlike any other I’ve tried. Matz, the Japanese creator of Ruby, wanted to create a programming language that was optimised for programmer happiness, instead of being optimised for machines. So instead of being a slave to the compiler you’re making the compiler a slave to you. I tried it out for a week and really liked it, and got something done, and within a month there was just no way I would ever go back to a language like PHP or Java.
A key feature of Ruby is its dynamic typing, in contrast to the static typing of C/C++ or Java. If you give up the safety of static typing, then is a rigorous testing methodology necessary in compensation?
That’s the wonderful thing that’s been working out so well for dynamic languages like Ruby and Python and the others. We’ve had this resurgence of programmer-driven tests. If you have no tests, then static typing gives you something. I don’t agree that it gives you very much, because it’s usually not compile errors but the logic of your program that is wrong. Unit testing and functional testing catch all types of errors, including logic errors. In a world where testing is considered a good, I think static typing is like a ball and a chain.
Ruby on Rails may be flavour of the year, but is it secure? Will it scale?
Security vulnerabilities are logic errors. You can have just as many security violations in a Java program or a Perl program or something else.
So would he recommend Rails for a highly secure application like online banking?
Definitely. But what gets used is not necessarily decided on technical excellence but more: ‘I wouldn’t get fired for using Java.’ It’s a political concern more than it’s a technical concern. As for scalability, we didn't try to solve that problem with Rails, because it is already solved. How is Yahoo scaling? They’re doing billions of page views a day, and they’re using PHP. The thing about PHP, Perl, Python and Ruby is that they can all be architected in the same manner, which is this notion of not having session state in the application layer. You push that down to the database, or you push it down to a shared memory store. That gives you the freedom of adding new application servers at will. You have load balancers, then you have web servers, then you have load balancers, then you have application servers. Rails is intensely scalable in that fashion.
So is there ever a case for J2EE?
There’s definitely a case, but I think it’s misguided for the majority of cases. Most people vastly over-estimate the importance of their application. They vastly over-estimate how much of a snowflake they really are. Once people realise that they’re just putting out another web application, then they can use tools that are just more productive. If you need to do very advanced legacy integration with mainframes and stuff like that, then Java and the J2EE platform is great. If you need to make just another web application, like most people do most of the time, then in my opinion J2EE is a horrible choice.
One thing Hansson does not like is stored procedures.
Any kind of logic in the database is misguided unless your database is accessed by multiple independent applications. And that is true in some shops. They have logic in the database to protect it from being inconsistent, because they have a lot of different application developers who write applications straight to that database. I think that’s a bad architectural model though. If you are writing stored procedures you’re usually writing them in a place where it’s hard to revision track them, where it’s hard to test them, where it’s hard to figure out whether you’re doing this right or wrong, and where it’s also hard to move it somewhere else. I think that people instead should have one database per application, and if you need to share a database or share data, expose that as services. [Ed: as an ex-DBA, I find the implications of that last remark for duplicate data management a tad worrying, depending on how the “services” are implemented, I suppose]
We asked Hansson for some insight into the future of Rails. It turns out that he’s fighting to keep it small and simple.
We don’t want Rails to end up just like every other Framework. Given enough time they’ll add the kitchen sink. So we’ve slowed down the development of the core Rails framework, and started focusing on other things.
He mentions Switchtower, a deployment tool; and Gauge, for system monitoring. But isn’t there pressure to extend Rails itself?
We get lots of pressure to do that. One way we’re fighting back is that we’ve added a plug-in architecture. When you make something as a plug-in, it feels just like Rails code. So you can change anything in Rails by making a plug-in. And that’s really Ruby helping out, because it’s so dynamic. That’s a way to push back and say we don’t need everything in the framework. The only things we want in a framework is what most people do the same most of the time. There’re lots of things where some people do the same things some of the time, and that’s not a good fit for what should be in the core part of Rails.®