1.3. A Brief History of Rails

To fully understand the reasons behind Rails' design choices, it is beneficial to very briefly learn about its history.

1.3.1. Understanding Rails' Origins

Rails was released to the world back in July 2004. The framework was extracted from a Web-based management and collaboration application project called Basecamp. Rails was created by David Heinemeier Hansson (often referred to simply as "DHH"), a Danish programmer and partner with 37signals, the firm that produces Basecamp and other similar Web applications. This brief piece of information offers us some important preemptive insight.

Rails was not designed by a committee. It was extracted from a real-world application. Even after Rails' incredible success, David has insisted that there won't be a Rails, Inc. because he firmly believes in the importance of working on real applications and only then applying the most useful lessons learned (and possible missing features) back into the framework.

This approach guarantees that Rails doesn't end up becoming a bloated framework that includes all sorts of features, to satisfy the requirements of any possible company or scenario out there. Rails is intentionally general enough to be used for a wide range of applications, but its focus has always been the needs of 37signals and other companies/developers who take up similar principles. That's where Rails really shines. To paraphrase what David said during a keynote at Startup School (http://startupschool.org): 37signals targets Fortune 5,000,000 companies.

37signals' team has strong opinions about how software development should be done. They embrace Agile development, simplicity, and software that focuses on a relatively small number of features (the previously mentioned YAGNI principle). Rails is opinionated software because it was tailored for the needs of 37signals, their products, and their way of developing. The good news is that, not only are they very successful, but the practices that they promote are well proven within the industry, and make a great deal of sense from a business and engineering standpoint.

Born into this kind of context, Rails makes assumptions about your applications. It assumes that you are going to use a database and that you'll be dividing your work into three environments: development, test, and production. It assumes that you'll be starting from scratch, rather than working with legacy databases. Ruby is not the fastest language out there, but that's acceptable because from 37signals' viewpoint, a need for extra hardware implies a greater number of paying customers. Developer time is much more expensive than hardware. Having to make a choice while creating Rails, they opted in favor of programmer productivity, code maintainability, scalability, and speed of development, as opposed to the raw speed of the framework and the chosen language.

Rails' origins help you better comprehend what its sweet spot is. Rails is particularly well suited to applications that have the following characteristics:

• Applications and sites that aren't trivial. Employing a whole framework for a page or two is still probably overkill and there are more straightforward solutions.

• Applications built from scratch, following Rails conventions. Working against Rails conventions is possible, but if your project heavily requires going against the stream, working with Rails won't be as easy. An example of this situation is when you are trying to deal with legacy databases and corporate environments.

• Applications hosted on VPS (Virtual Private Servers), dedicated servers, or elastic/cloud computing services. Shared hosting is an acceptable solution for non-critical applications and low volume websites, but it is neither ideal nor within Rails' sweet spot. You can read more on deployment options and considerations in Chapter 11.

Rails doesn't usually prevent you from building any type of applications, but it is opinionated and you'll be able to get the best out of it when you take advantage of "the Rails Way" of development or, in other words, when your opinions match those of Rails.

If the core Rails functionalities don't quite cut it for your project, you can still decide to use other open source plugins (or write them yourself) in order to allow Rails to behave in manner that's closer to one of your specific needs. For example, you may require support for composite primary keys, which by default are not supported by Rails. There is a homonym plugin that extends ActiveRecord to add this functionality.

It isn't uncommon for the Rails core team (a group of a few open source developers captained by David) to reply to requests of the "wouldn't it be cool if Rails was able to..." sort with the acronym PDI, which stands for Please Do Investigate. Theirs is not a flippant answer, but rather a pragmatic one. It's an open source project after all and anyone can contribute or pay someone else to do it for them in order to get the kind of features that they may require for their own purposes, which don't quite fit into the Rails core.

If your development style, environment, and practices are entirely opposite to the Agile ones promoted by Rails, chances are that you have a bigger problem than deciding whether or not Rails is a good tool for you. In this case, the answer is clear: Rails may not be the best tool in this kind of context, and a .NET or J2EE solution might end up being less problematic.

1.3.2. Powering the Web 2.0

Since its release in the summer of 2004, Rails has managed to become one of the most used and appreciated frameworks on the Web. By 2006, Rails had arguably already achieved its tipping point, and nowadays most developers have heard about Ruby on Rails. It quickly became the tool of choice for most of the (so-called) Web 2.0 startups, and today is widely adopted by some of the largest sites on the Web.

Scribd.com, YellowPages.com, Hulu.com, Twitter.com, RevolutionHealth.com, 43things.com, Helium.com, and Funnyordie.com are but a few examples of popular sites that are currently written in Rails, which you may have visited or heard of.

And the list of Rails users doesn't end with startups and popular websites. Companies of all sizes are employing Rails talent and starting new projects, embracing Ruby and a more Agile style of programming in pursuit of productivity. While typically very popular with smaller and medium companies, Rails has also been used within the borders of giants like IBM (which I work for), Amazon, Yahoo!, NASA, Oracle, EA, BBC, Cisco, and a long list of other successful Fortune 500 members.

Ruby on Rails took the Web by storm and, along with Ajax, it became one of the greatest "revolutions" in modern Web development history. In fact, Rails' influence isn't limited to the Ruby community. It helped popularize the concept of MVC for many beginners, and inspired other developers to start similar projects (or clones) using Ruby and other programming languages, including but not limited to C#, PHP, Python, Java, and even JavaScript.

You may be familiar with the fact that the .NET community created its own open source version, called MonoRail, through the Castle Project (http://castleproject.org) before Microsoft made the wise move to respond to Rails' success with its ASP.NET MVC framework.

1.3.3. The Rise of Ruby

Despite its tagline of being a "programmer's best friend," and its ever growing popularity in its homeland (Japan), Ruby's worldwide adoption was initially limited by its lack of English documentation. In 2000, with the appearance of the first English literature on Ruby, and the involvement of "The Pragmatic Programmers" within the community, Ruby started to become more widely used. But the advocacy and promotion from early adopters was not enough to bring it directly into the spotlight because, at this stage, relatively few programmers had even heard of this thing called Ruby.

When Rails became such a smash hit, developers started using Ruby and began to appreciate it for its own merits. Today, most people still use Ruby to develop with RoR, but it has become quite a common choice outside of the Web or in conjunction with alternative Web frameworks, too. Ruby made Rails great, and Rails made Ruby much more common and accepted within the development world.

This works well for Rails developers, who can benefit from a larger Ruby community that's ready to improve the existing implementation of the language and share libraries for all sorts of development purposes.