A large number of developers were frustrated with the technologies they were using to create web applications. It didn’t seem to matter whether they used Java, PHP, or .NET—there was a growing sense that their jobs were just too damn hard. And then, suddenly, along came Rails, and Rails was easier.
But easy on its own doesn’t cut it. We’re talking about professional developers writing real-world websites. They wanted to feel that the applications they were developing would stand the test of time—that they were designed and implemented using modern, professional techniques. So, these developers dug into Rails and discovered it wasn’t just a tool for hacking out sites.
For example, all Rails applications are implemented using the Model-View-Controller (MVC) architecture. MVC is not a new concept for web development—the earliest Java-based web frameworks (like Struts) base their design on it. But Rails takes MVC further: when you develop in Rails, you start with a working application, each piece of code has its place, and all the pieces of your application interact in a standard way.
Professional programmers write tests. And again, Rails delivers. All Rails applications have testing support baked right in. As you add functionality to the code, Rails automatically creates test stubs for that functionality. The framework makes it easy to test applications, and, as a result, Rails applications tend to get tested.
Rails applications are written in Ruby, a modern, object-oriented language. Ruby is concise without being unintelligibly terse. You can express ideas naturally and cleanly in Ruby code. This leads to programs that are easy to write and (just as important) easy to read months later.
Rails takes Ruby to the limit, extending it in novel ways that make our programming lives easier. Using Rails makes our programs shorter and more readable. It also allows us to perform tasks that would normally be done in external configuration files inside the codebase instead. This makes it far easier to see what’s happening. The following code defines the model class for a project. Don’t worry about the details for now. Instead, think about how much information is being expressed in a few lines of code:
| | class Project < ApplicationRecord |
| | belongs_to :portfolio |
| | |
| | has_one :project_manager |
| | has_many :milestones |
| | has_many :deliverables, through: milestones |
| | |
| | validates :name, :description, presence: true |
| | validates :non_disclosure_agreement, acceptance: true |
| | validates :short_name, uniqueness: true |
| | end |
A major philosophical underpinning of Rails that keeps code short and readable is the DRY principle, which stands for Don’t Repeat Yourself (see The Pragmatic Programmer [HT99]). Every piece of knowledge in a system should be expressed in one place. Rails uses the power of Ruby to bring that to life. You’ll find little duplication in a Rails application; you say what you need to say in one place—a place often suggested by the conventions of the MVC architecture—and then move on. For programmers used to other web frameworks, where a simple change to the database schema could involve a dozen or more code changes, this was a revelation—and it still is.
From that principle, Rails is founded on the Rails Doctrine,[2] which is a set of nine pillars that explain why Rails works the way it does and how you can be most successful in using it. Not every pillar is relevant when just starting out with Rails, but one pillar in particular is most important: convention over configuration.
Convention over configuration means that Rails has sensible defaults for just about every aspect of knitting together your application. Follow the conventions, and you can write a Rails application using less code than a typical JavaScript application uses in JSON configuration. If you need to override the conventions, Rails makes that easy, too.
Developers coming to Rails find something else, too. Rails doesn’t merely play catch-up with the de facto web standards: it helps define them. And Rails makes it easy for developers to integrate features such as Ajax, modern JavaScript frameworks, RESTful interfaces, and WebSockets into their code because support is built in. (And if you’re not familiar with any of these terms, never fear—you’ll learn what they mean as you proceed through the book).
Rails was extracted from a real-world, commercial application. It turns out that the best way to create a framework is to find the central themes in a specific application and then package them in a generic foundation of code. When you’re developing your Rails application, you’re starting with half of a really good application already in place.
But there’s something else to Rails—something that’s hard to describe. Somehow, it feels right. Of course, you’ll have to take our word for that until you write some Rails applications for yourself (which should be in the next forty-five minutes or so…). That’s what this book is all about.