DRY: Don't Repeat Yourself or the DRY principle, if applied properly, reduces the duplication of tasks within a project. Duplication of any kind, within a project, leads to difficulty in modification and maintenance and inconsistency. In RoR, you can see this principle at work in almost everything—from the reusable components in the form of plug-ins to the way database tables are mapped.

Convention-over-Configuration(CoC): Configuration has taken over the web application frameworks so much that even a simple task such as applying 'compulsory field' validation for just one field requires entries in an XML file. In RoR, the principle is to supply information about only those aspects that are different from usual application settings. The ORM (Object Relational Mapping) framework provided by RoR is an example of the Convention-over-Configuration principle. Unless you specify a different name for an ORM object, the object uses the name of the table to which it is mapped. Whereas in the case of configuration-based ORM frameworks, such as Hibernate, the mapping of each table along with its columns has to be given in the configuration file. So, a change in the schema means a change in the configuration file. However, in the case of RoR, a change in the schema doesn't mean a change in the object unless the name of the table itself changes. We will see more about the ORM framework in Chapter 2.

Automatic setup of Application structure: If you have worked with J2EE technologies, this would come as a pleasant surprise. The structure of any application need not be created manually. Just one command and the complete structure including folders and basic web files such as index.html will be generated for you. Therefore, no more hunting for third party tools such as those that provide the initial setup or setting up the structure manually.

Generation of Boilerplate Code: Every application has certain blocks of code that are essentially the same for all other applications of the same type or category. Such blocks are called Boilerplate code. One of the examples of Boilerplate code is the code block setting up a connection to the database. The same code can be used with different applications with only a little change. Though this is the case, most of the frameworks do not provide any inbuilt mechanism to reduce this 're-invention of the wheel'. RoR avoids the duplication using scaffolding. In essence, a scaffold contains the bare minimum of code to accomplish tasks such as connecting to the database, setting up a log, and so on. Scaffolds reflect the DRY principle that RoR adheres to.

Dynamic mapping of classes to database schemas: No web application can go online without having a database as its back-end. ORM frameworks have eased the database access. However, the configuration aspect reduces any advantage to the developer. In the case of RoR, ORM does not need any configuration. At runtime, RoR reads and maps the schema based on the names of classes and corresponding tables using reflection and meta-programming. Moreover, what the developer gets is more productivity.

Ajax at the core of presentation: Ajax is the technology that provides interactivity to websites without becoming intrusive. All the current server-side technologies claim to support Ajax, but the support is peripheral and not at the core. You would have to download new libraries, configure them, and then start the develop-compile-deploy-test cycle again. Whereas in RoR, Ajax is part of the core libraries. So when you install RoR, Ajax support is also made available to you. Using them is as easy as when you use any other library provided by RoR.

Batteries included: RoR contains many more libraries that provide for essentially all the requirements of a dynamic website including layout management, mailing, and so on. If you look at these libraries, you will understand that they are, in fact, fully-fledged components in themselves, representing different services provided by a website or a portal.