In this second part of a three-part series introducing the Rails framework, you'll learn some of the advantages of working with Rails, as well as its central tenets. It is excerpted from chapter one of the book Beginning Rails: From Novice to Professional, written by Jeffery Allan Hardy, Cloves Carneiro Jr. and Hampton Catlin (Apress, 2008; ISBN: 1590596862).
Advantages of the Rails Framework - Less Software (Page 2 of 4 )
One of the central tenets of Rails philosophy is the notion of less software. What does less software mean? It means using convention over configuration, writing less code, and doing away with things that needlessly add to the complexity of a system. In short, less software means less code, less complexity, and fewer bugs.
Convention Over Configuration
Convention over configuration means that the programmer needs to define only configuration that is unconventional.
Programming is all about making decisions. If you were to write a system from scratch, without the aid of Rails, you would have a lot of decisions to make: how to organize your files, what naming conventions to adopt, and how to handle database access are only a few. If you decided to use a database abstraction layer, you would need to sit down and write it, or at least find an open source implementation that suits your needs. You would need to do all this before you even got down to the business of modeling your domain.
Rails lets you get started right away, by encompassing a set of intelligent decisions about how your program should work, alleviating the amount of low-level decision-making you need to do up front. As a result, you can focus on the problems you’re trying to solve and get the job done quicker.
Rails ships with almost no configuration files. If you’re used to other frameworks, this fact might surprise you. If you’ve never used a framework before, you should be surprised. In some cases, configuring a framework is nearly half the work.
Instead of configuration, Rails relies on common structures and naming conventions, all of which employ the often-cited principle of least surprise (POLS). Things behave in a predictable, easy-to-decipher way. There are intelligent defaults for nearly every aspect of the framework, relieving you, the developer, from having to explicitly tell the framework how to behave. This isn’t to say that you can’t tell Rails how to behave. In fact, most behaviors can be customized to your liking and to suit your particular needs. But you’ll get the most mileage and productivity out of the defaults, and Rails is all too willing to encourage you to accept the defaults and move on to solving more interesting problems.
While you can manipulate most things in the Rails setup and environment, the more you accept the defaults, the faster you can develop applications and predict how they will work. The speed with which you can develop without having to do any explicit configuration is one of the key reasons why Rails works so well. If you put your files in the right place and name them according to the right conventions, things will just work. If you’re willing to agree to the defaults, you generally have less code to write.
The reason Rails does this comes back to the idea of less software. Less software means making fewer low-level decisions, which will make your life as a web developer a whole lot easier. And easier is a good thing.