Could you just name a couple of them?

One of the things, for example, is how you configure your applications. A lot of environments, especially before Rails came around, had a notion that you basically started with a blank sheet of paper every single time. Everything had to be configured from scratch. How do I talk to the database? How do I map these fields between objects and records and rows and so on and so forth? You had to configure that explicitly every time, even though you might be doing the same thing over and over and over again. Like Groundhog Day, everything just started over and over and over again. So with Rails, we decided it's not going to be Groundhog Day. We're going to make some decisions and we're going to make them once. And once we've made those decisions, we're going to turn them into conventions, and we're going to teach you those conventions. And once you've learned them, it's done. Like we're no longer going to talk about what the primary key field in database tables are going to be called. They're going to be called ID, that's it. Now, [it's] done. Let's move on to the next decision. And like that we progressed through a ton of standard configuration points and literally removed them. We replaced them with conventions that said if you're just doing what most developers are doing the same [way] most of the time, you're going to get it for free. So they're going to be called ID. You don't care about that anyway. You shouldn't be caring about what the primary key fields are called, and if you can lift yourself above that and not care about it, you can get all this configuration stuff for free. So I think that's probably the biggest contribution we've made to thinking about frameworks. How can we get less configuration? How can we replace it with conventions instead? And how can we get a lot of productivity out of that?

How does Ruby on Rails compare to Java framework like Spring?

I think one of the big differentiators is definitely that notion of convention over configuration. Java frameworks in particular have been peculiarly fond of XML for wiring pretty much everything together, and in some sense, it sounds great. You get ultimate flexibility, you get the opportunity to wire everything together exactly like you want it, but most people don't really care. That amount of flexibility is not worth the tradeoff. And I think that's the fallacy of a lot of frameworks, especially in Java, they thought flexibility was free. Flexibility is not free. It's overrated. And if you trade that flexibility in for some constraints, you get a lot of complexity removed from the equation, you get a lot of productivity back from all the stuff you don't have to do. So that's one of the reasons that Rails is different from something like Spring or Struts and so on. Another thing is just the aspects of something like Ruby. The Ruby programming language is just an amazing programming language to be able to work with, and we choose to employ it across the stack. So everything is written in Ruby. We write the views in Ruby, we write the models in Ruby, we write the controllers in Ruby. We try to keep everything as Ruby as we can instead of mixing something up with XML this or configuration files that.

Could you name a couple of the major Web applications or Web sites that have been developed with Ruby on Rails?

Sure. So my own company, 37signals, has been kind of the poster child for some time, it's the original, the first Rails applications. We have something called Basecamp, a project collaboration tool. We have something called Highrise, just managing context online. But there's a ton of other companies out there too. I especially like 43things.com, which is like a social networking site about the goals you want to achieve in life. There's shopify.com, which is a really cool e-commerce marketplace where you can create a beautiful-looking shop in very little effort at all and start selling merchandise for very little up-front cost.

Are you following any of the Ruby and Ruby on Rails tools that are being released, such as Ruby In Steel from SapphireSteel, CodeGear's upcoming Ruby offering, and the FiveRuns's Management Suite for Rails?

I am. And I'm very pleased to see all that work going on. One of the things that I've wanted from day one for Ruby on Rails was to create an economic ecosystem around it because I think that's one of the factors that make sure that something like a framework like Rails will stick around. When people start depending on this for their jobs, when people start depending on this for their paycheck, it'll ensure a long life for the framework. And that happened early on with consultants who shifted to making Ruby on Rails projects instead of whatever they were using before, and now it's happening in second tier. People were building up businesses around selling tools to Rails developers, and I think that's just -- it's such an important point in the evolution of the ecosystem and a great milestone for Ruby on Rails.