1.2. What Is Rails?

Rails is an open source, cross-platform, full-stack, Model-View-Controller (MVC) framework for the Agile development of database-driven Web applications that use the Ruby language. This dense definition incorporates quite a few concepts that you may not be familiar with. Let's break things down so as to get a better overview of the framework.

1.2.1. Open Source

Rails is an open source project. It's released under a very liberal license (MIT) that enables you to freely modify, contribute, and distribute the framework. In the vernacular of the Free Software world, Rails is free as in beer and as in speech. As a Microsoft developer, you're probably used to proprietary software, where several of the components that you employ in your applications are closed source.

The fact that Rails is open source implies that, whenever you encounter a bug in the framework itself, you'll have full access to the source code of the libraries that constitute the framework. You will be able to identify where the problem lies, report it with accuracy, and even correct it yourself and submit a patch to the project. In other words, stepping through and reviewing the source code helps you to better understand how the framework operates and in turn enables you to build better applications.

1.2.2. Cross-Platform

Unlike ASP.NET (with an exception made for its alternative implementation through the Mono project), Rails runs on a number of platforms. The most popular choices within the community are operating system members of the *nix family (like GNU/Linux, Mac OS X, and *BSD), but Rails can be used on Windows as well.

1.2.3. Full-Stack

The term full-stack means that the framework provides you with a supportive, integrated environment in which it's possible to develop complete Web applications from start to finish. To borrow an expression from the Python world, Rails "comes with batteries included." Aside from handling the request-response cycle and providing you with the necessary libraries for easier database, server-side, and Web Service programming, on the client side, Rails also includes a JavaScript framework (Prototype) and a library (script.aculo.us) for creating Ajax-powered applications.

Support for testing, a very important topic for Rails developers, is baked-in as well. To top it all off, Rails provides you with a handy HTTP server known as WEBrick which, albeit meant for development purposes only, enables you to get started right away without having to worry about configuring more complicated Web servers.

If you're accustomed to developing with large frameworks such as ASP.NET or J2EE, Rails' full-stack nature may seem "not full enough." This is intentionally so, in order to avoid complexity and bloat in the framework and leave a core that's reasonably slim and extendable through free, third-party plugins. Rails' plugin architecture encourages code reuse and enables the developer to extend Rails' core behavior and out-of-the-box features in reusable plugins that are often shared with the whole world. As a Rails beginner, you can learn a lot by simply studying the code of high-quality Rails plugins, and you can take advantage of a wealth of functionalities by simply installing them within your own Rails projects on an as-needed basis. Plugins are, in my opinion, one of Rails' best features.

1.2.4. The MVC Pattern

MVC is an architectural pattern designed to satisfy the principle of separation of concerns. When successfully applied to the design of a software project, it promotes the isolation of the user interface from the business logic. This separation is extremely important in order to create maintainable applications, and it's especially true on the Web, where the distinction between business logic (server side) and presentation layer (client side) is almost intrinsic to the medium.

Models represent the data, views the user interface, and controllers act as coordinators, controlling the flow of the application. Controllers are the glue of the application; they allow modification and retrieval of model data, and preparation of the content so it can be rendered in the view. Changes performed to the view by, your designer, for example, shouldn't affect the team of developers working on the backend.

If you have done ASP (classic) or PHP development, where access to the database, business logic, and presentation layer are often intermingled, you'll find RoR's approach rather refreshing, tidy, and even elegant.

Rails generates the skeleton of an application and, in effect, forces you to adopt an MVC-style of programming. Every Rails application applies separation between the model, the view, and the controller, storing the files for each of these components in different folders. You'd have to go out of your way to be able to intentionally break the enforcement of this pattern in Rails. But don't let this apparent strictness toward MVC get you down. In most cases ASP.NET developers who switch to Rails find themselves liberated by the rigidity of the language (be it C# or VB.NET) and the framework they were used to.

In Chapter 2, the MVC pattern is described in further detail, with particular emphasis on the way Rails implements each entity and their interaction with each other.

1.2.5. Agile Development

Agile development is a perfect match for the Rails developer. It can be argued that Rails is an attempt to bring Agile methodologies to the Web, where development has often been led by opposite principles. If you are not familiar with the Agile movement, I invite you to read the following Manifesto for Agile Software Development (http://agilemanifesto.org). The Agile Manifesto was the brainchild of 17 pioneers who decided to start a movement to improve the practice of software development. Among these folks, three individuals (Martin Fowler, Dave Thomas, and Andy Hunt) are deeply involved with the Ruby and Rails communities.

Rails absolutely embraces each of these four principles, and the so-called "Rails Way" of programming faithfully adheres to the Agile methodologies. Rails' main philosophies are often condensed into mnemonic mantras that originated and are well-known in the Extreme Programming (XP) and Agile communities. The three canonical ones are: Don't Repeat Yourself (DRY), Convention over Configuration, and You Ain't Gonna Need It (YAGNI).

"Convention over Configuration" expresses Rails' philosophy of adopting a series of sensible assumptions, which frees programmers from defining and configuring every single detail of their application. Most Web applications share common elements and Rails requires configuration only when the conventions adopted by the framework are not endorsed and, therefore, need to be overwritten. For example, Rails assumes that the class Order will correspond to the pluralized orders table in the database. Unless you're required to overwrite this convention, the mapping between the Ruby class and the database table is automatic and no explicit configuration is required.

Even if you intend to overwrite a given convention, unlike with other frameworks, Rails' configuration is performed in simple readable text files, rather than using verbose XML files. A medium-sized application in a traditional framework can end up having hundreds, if not thousands, of lines of XML just to define a correspondence between the objects within the code and the relational structure in the database. This is intentionally not the case with Rails, even if it provides programmers with the ability to configure and overwrite conventions in order to meet their needs.

The "Don't Repeat Yourself" mantra implies that writing less redundant code and reducing duplication ends up producing maintainable and less bug-prone applications, which can easily evolve and change. A change in a given point of an application should not affect unrelated elements and should be properly reflected in related ones, without requiring multiple changes. Localizing change is a principle that is fundamental to Rails development, and the framework structure promotes and enforces this.

Finally, the "You Ain't Gonna Need It" principle is a reminder about the importance of implementing features that are actually needed now, and fighting the urge to write code for features that may only be necessary in the future. This approach to software engineering has been embraced by Rails' creators as well as being common among developers using Rails. Following the YAGNI principle offers a greater focus on the required core functionalities, keeps software lean, and helps in retaining the application's flexibility to change as needed. 37signals endorses this principle and extends it into the principle of "less software," which is aimed at outsmarting the competition with focused software that has fewer features than their competitors. So far, it has worked wonders for them.

Understanding the Rails philosophy of Web development is essential to successfully employing the framework and becoming an effective programmer.

These principles are closer to the Unix philosophy, rather than the one that's common within the Microsoft development world. This by no means implies that, as a Microsoft developer, you may not have already adopted and sought out these development practices, but it was essential to explain them further and state their importance throughout the book.

1.2.6. Database Driven

Rails assumes that each Web application is going to store data within a database. It is a reasonable assumption for all but the most trivial of applications. More importantly, Rails uses an Object Relational Mapper (ORM) Ruby library called ActiveRecord, that follows the Active Record design pattern as defined by Martin Fowler in his popular book, Patterns of Enterprise Application Architecture (Addison-Wesley 2002).

ActiveRecord greatly simplifies CRUD, the four basic functions of persistent storage — create, read, update, and delete — enabling you to favor Ruby code over SQL queries (most of the time). It's the abstraction that allows domain models to wrap database objects and handle their underlying relationships. Thanks to a series of adapters, ActiveRecord, and therefore Rails, can be used with all of the most popular databases, from the file-based SQLite (Rails' current default) to more "enterprisey" choices such as Microsoft SQL Server, IBM DB2, or Oracle. The Rails community has a clear preference toward open source databases such as MySQL and PostgreSQL, but you are more than welcome to adopt whatever RDBMS you have at hand or are more comfortable with.

This book uses the default database (SQLite) and recommends that you do the same to follow along, but don't be too concerned if you're using a different one. That's the beauty of ActiveRecord's abstraction: the Ruby code will be (virtually) the same no matter what database is being used. That said, there are special considerations for SQL Server, DB2, and Oracle, and pointers for these are provided in Chapter 11.

1.2.7. Ruby: Rails' Secret Sauce

Ruby is an open source, modern, object-oriented programming language — and a fantastic one at that. It synthesizes the best lessons learned from other programming languages like Smalltalk, Perl, and Lisp, combining the elegance of the object-oriented paradigm (in Ruby everything is an object; there are no primitive types) with the immediacy of a scripting language, further combined with functional programming. If you are not familiar with this last programming style, but have had a chance to try out the language extensions to C# 3.0 and Visual Basic 9 — provided by LINQ in the .NET 3.5 Framework — you've already had your first contact with the functional world.

If you're used to programming languages like C#, VB.NET, C++, or Java, you'll be blown away by how Ruby is concise yet readable, expressive, powerful, and easy-to-learn. Its dynamic, interpreted nature makes it much less tedious to work with, when compared to the aforementioned compiled programming languages.

Ruby is a very high-level language and it's truly Rails' secret sauce. Its flexibility and reflective nature make it an ideal language with which to implement a framework/DSL like Rails.

A good part of the fun of writing Rails applications lies in the fact that you get to code in Ruby, a language that was invented by Yukihiro Matsumoto (commonly known as Matz), with the specific intention of being programmer-friendly, productive, and maintainable.

Rails takes Ruby to the next level, by expanding its out-of-the-box capabilities through utility classes and extension to the Standard Library; on the other hand, Ruby's openness and flexibility enable you, the developer, to extend Rails to suit your needs.

Rails is written in Ruby for Ruby programmers, so it is essential to be well versed in Ruby before attempting to create interesting Rails applications. This is a common mistake by people who are trying to learn Rails. They skip Ruby and dive right into the framework, tempted by Rails' approachability. The end result is not pretty, with a lot of confused newcomers and very basic Ruby questions popping up in the Rails mailing lists and forums.

In this book Ruby is not an afterthought. I deemed it crucial to include two whole chapters dedicated to the language, as opposed to a simple appendix as often happens in other Rails books. I've also tried to emphasize and clarify aspects of the language throughout this book, whenever required.

1.2.8. Greater Than the Sum of Its Parts

Reading about Rails features and design choices may lead you to realize that Rails didn't invent anything particularly new. The powerful MVC pattern was first described back in 1979 and was already adopted by other MVC frameworks. Conversely, the Active Record pattern was well known, too. Over the past few years, all sorts of Ajax libraries and frameworks have been released into the wild; and Test Driven Development (TDD) and the Agile methodologies were also not invented by Rails.

What Rails did was to put each component in the right place, in a coherent manner, while attempting to keep everything as simple as possible for the programmer. The end result is a powerful and fun toolkit that lets you concentrate on the actual application, rather than on small technical details that are repeated over and over in each project. Does the programmer really need to specify the whole connection string in order to access the data within the database? Rails doesn't think so. Rails favors "Convention over Configuration" because when these conventions are sensible, they truly free the developer from having to take care of minutiae in configuration files.

This homogeneous set of features, conveniences for the developers, "best practices," and guiding philosophies make Rails invaluable when it comes to producing solid Web applications in very short time frames, when compared to other existing solutions. The Rails community has done a good job of conveying the framework's strengths, and understandably many developers are excited about the chance to use Ruby on Rails in their projects.