For about 6 years now, there's been a lot of talk about this thing called "Ruby on Rails." They're saying it's Ruby's killer app, it's the next best thing in web application development, it's all great! That's what they're saying, but what is it?
Ruby on Rails is a framework that makes the development, deployment, debugging and maintaining of web applications relatively simple and a much more pleasant experience than environments like PHP, and the various frameworks available on Java. It's an MVC (Model View Control) framework with some rather staunch philosophies on how things should be done (almost always to the benefit of the programmer). It's all about making things easy for you, the programmer, instead of giving you a too-simple API (as in PHP) or flooding you with configuration files and XML files and slogging through hundreds of pages of documentation (as in many Java frameworks).
Model View Controller Frameworks
The core idea behind Ruby on Rails is the Model View Controller paradigm. To understand what MVC is, first picture a worst case scenario of what MVC isn't. Imagine you've inherited a PHP website (as I'm sure many of you have) and as soon as you open the source code in your text editor, you shudder. The whole thing is a mess of HTML mixed with PHP, SQL statements scattered throughout the code and you simply can't find anything. I know, PHP can do better than this, but this is how most PHP code seems to be written, and it's a problem for anything but simple pages. There is no separation between the presentation of the application and the code that powers it, it's an incomprehensible mishmash.
An MVC framework gives you a scaffolding on which to bolt your code. Your view code, the part that outputs the HTML, XML, RSS, etc, lives in one place. Your model code, the part that stores and retrieves data, lives in another place. Your controller code, the part that accepts requests, retrieves data and gives it to the view, lives in another place. Everything is neatly organized, if you need to fix how an item is retrieved from the database you know that'll be in the model, and that alone makes it much, much easier to find and fix. And you only have to fix it once in the code, as you'll see in the next point.
Don't Repeat Yourself
When you fixed that little problem retrieving data from a database in the above example, you only fixed it once. If there are SQL statements scattered around your project, you'll have to hunt down every single one that's relevant, probably using the search feature in your editor. But what if one of the queries is structured differently, and your search fails to find one of them? A bug you though you fixed will arise again in the future.
Another important concept in Ruby on Rails is DRY (Don't Repeat Yourself). If something is retrieved from the database, it's retrieved once in the code. If you need to fix it, you fix it once and it's fixed everywhere. Other important uses for this are things like view helpers, that help you format certain things on the output pages. Write it once, use it many places. If it needs to be fixed, it needs to be fixed just once.
Not only is this a huge boon for debugging and maintenance, it just saves a lot of typing. We all do it, take a shortcut because it involves much less typing. But with DRY, you'll encounter this less and less, so your own laziness hurts you less.
Ruby on Rails is built from the ground up to develop web applications in what is called the Test-Drive Development paradigm. In a nutshell, this means you write a test for a feature before you write the code for that feature. For example, if you're implementing the "logout" feature, you would write a test that says "when the user clicks the logout link, they'll be redirected to the homepage, their session will be deleted and authentication cookie cleared." This test will be in Ruby code, and will be run as part of the test suite, a series of tests that are run as often as possible in the development process. Only after this test is written will the actual feature be implemented.
If you haven't done Test-Driven Development before, this sounds both backwards and excessive. Why write tests first? Why write tests for such a simple feature? I respond with another question: What if it breaks? Development is often like making a house of cards. Without TDD, all you have is your confidence that you've done it right. And you may be right in your confidence, but computers do what people tell them to do and people don't always communicate that so clearly, or didn't think out a certain situation. Tests are a safety net, or a scaffolding around this house of cards. If the logout feature does fail because of some feature you implement later, instead of having users beat down your door, you'll know about it before it's ever deployed. Tests are important, tests are not extra work, they save time.
Tests also serve as a type of documentation. Want to know how to use something? Look at the tests, they exercise that feature in bite sized chunks that are easily readable and accessible.
Convention of Configuration
The final brass tack in Ruby on Rails' shining facade is convention over configuration. Many MVC frameworks can do everything Rails can do, but weigh you down with hundreds and hundreds of lines of configuration files. If these configuration files are in a markup language like XML, make that thousands of lines of configuration. Good luck finding anything in that mess. If you've worked with that framework for a long time, you know where everything is, but what about everyone else?
There are a lot of options in MVC frameworks, but Ruby on Rails depends on a sane set of defaults instead of hundreds of configuration options. These defaults are what developers usually want to do. The most obvious example of this is database table names. If you have a model called User, which holds the information about a user, the database table should be called users. Rails will make the name into plural for you and automatically look for that table in the database. You don't have to tell it where to look because that's what you expect it to be. However, if the table is called something else then you can change Rails' behavior, but you rarely have to do that because the most common use case is already covered for you.
This saves a lot of typing, make configuration files very skinny and gives you more insight into what Rails is doing. Rails does, by default, the same things in every web application. You don't have to check the configuration files to see where it's going to look for its tables, or how it's going to generate a link. If you know how Rails does it, then unless a method call specifies otherwise, it's most likely going to do it in the same way every time.