2.1. Misconceptions about Rails
When a new technology hits the spotlight, a lot people start talking about it. It's a given that not all of them are going to be fully aware of the subject, and new myths and misconceptions will inevitably spring forth. With Rails' exponential success and big promises of easier Web development, this phenomenon is particularly accelerated. In the past four years, all sorts of misinformed comments about Rails have popped up. The next few sections focus on some of the most common ones, but also on those that are very much worth clarifying from the get-go.
2.1.1. You Don't Have to Be a Programmer
Rails developers are often enthusiastic about their framework of choice. The fact that they like to stress how easy and productive Rails is, is very understandable given that programming in Rails is a joy and probably considered (by these developers) much easier and better than anything else they've tried before. In truth, to initially get started with Rails you don't really need to be an expert on how the Web works, nor proficient in SQL, HTML, or JavaScript. Rails takes care of a lot of small details for you.
The notion that you don't have to be a programmer to write Web applications with Rails, however, is false. All but the most trivial applications require a good dose of programming skills and design choices.
When you create a Rails application, one of the first tasks is to define the database structure. You'll have several tools that can help you with this, and you won't have to do it by specifying the SQL code in most cases, but you'll still have to fundamentally decide how the information is going to be stored in the database.
Most of the code that you'll be writing is going to be in Ruby, a full-fledged programming language. All of the most proficient Rails developers are excellent Ruby programmers as well, simply because Ruby is the key to getting the best out of Rails.
In other words, Rails is not a Content Management System (CMS) like DotNetNuke, Community Server by Telligent, or Drupal. Non-programmers are actually much better off with these highly modular CMS applications rather than with Rails, for the simple reason that these don't expect you to be a programmer, whereas Rails definitely does.
Rails makes Web development easier and much more accessible to newcomers, in the same way that programming in C# is more approachable than programming in, say, Assembler. But in both cases, it's still 100% programming.
2.1.2. Rails Is a Silver Bullet
In the famous paper "No Silver Bullet - Essence and Accidents of Software Engineering," Fred Brooks, author of The Mythical Man-Month (Addison-Wesley 1975), makes the following claim:
"There is no single development, in either technology or in management technique, that by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity. In this article, I shall try to show why, by examining both the nature of the software problem and the properties of the bullets proposed."
—Fred Brooks
You should take the time to read No Silver Bullet. You can find it online at http://www.lips.utexas.edu/ee382c-15005/Readings/Readings1/05-Broo87.pdf.
It is now well established in the software development industry that there are "no silver bullets," an expression that's loosely used today to indicate that no new technology is going to be the final solution to all of the problems of software design and productivity.
Yet Rails is often wrongly considered a silver bullet by some, because it is arguably much more productive than working with .NET or Java. As explained by Brooks in his essay, there are two types of complexities: accidental and essential. The former is caused by us developers and our approach, and the latter is intrinsic to the resolution of the problem.
Rails improves productivity by considerably reducing the accidental complexity, but it can't alter the essential complexity of Web development, hence Rails is no silver bullet and it never will be, no matter how much it improves.
This fact shouldn't concern you though, given that no other technology is going to be a silver bullet either. Rails is one of the best tools available today for aiding developers in managing complexity, but it's still just a tool, and one that doesn't aim at being the ultimate solution for every Web development problem and developer out there. Through this book, you'll understand Rails' strengths and weaknesses, and better evaluate when and if it's the right tool for you.
2.1.3. Rails Is Hard to Deploy
Deployment is the act of moving your Web application from your development machine to a production one, where it becomes accessible to your customers through their browser. Deploying Rails applications today is a fairly straightforward process. Several well-known configurations and a series of useful tools are available (for example, Capistrano) to help you out in the process. Many hosting companies have also heavily invested in improving their support for Rails and in providing easy "upload and go" solutions.
Admittedly in the past, especially before mod_rails for Apache was released in 2008, the experience of deploying Rails applications wasn't as pleasant as it was for the ubiquitous PHP. The most common solution was the adoption of a cluster of Mongrel instances, proxy balanced by a Web server like Apache. This configuration is not rocket science, and it's still the favorite one by many large sites, but it requires more configuration fiddling than some would like to do. This option also implies, in most cases, the use of a Virtual Private Server (VPS) or dedicated hosting solution, both of which are more expensive and require more attention than a shared hosting arrangement.
Today, the number of useful tools and hosting options has improved in number and quality, and there is no reason to believe in the myth that deploying Rails applications is hard. Chapter 11 guides you through some of the deployment tools and configurations, including hosting on Windows servers, and you'll realize how deploying Rails applications is generally not much more difficult than developing them.
2.1.4. Rails Doesn't Scale
To borrow an expression from Mark Twain, reports of Rails' scalability problems have been greatly exaggerated. One of the greatest myths surrounding Ruby on Rails is the claim that it doesn't scale. Whenever a large site written in Rails is having troubles (for example, like twitter.com did in 2008), misinformed pundits tend to immediately identify Rails as the culprit.
The reality is that there is nothing in Ruby or in Rails that makes them inherently non-scalable. Au contraire, Rails has a "share nothing" architecture, which allows you to plug in additional hardware with little extra configuration, as long as the data persistence mechanism adopted (for example, your database server) allows you to scale.
Scalability often has little to do with the given language or framework, and everything to do with the architecture and design choices made for the whole application stack.
The misconception that Rails doesn't scale probably originated due to a couple of existing issues surrounding Rails. First, the current main Ruby implementation is not fast. It is generally considered one of the slowest, even among other interpreted languages. Second, Ruby's adoption of green threads and ActiveRecord's historical lack of thread safety implies that Rails' concurrency support and ability to take advantage of multiple processors is limited. As explained in Chapter 4, several Ruby implementations exist with the aim, among others, to solve Ruby's performance issues. Conversely, Rails' performances have been improving with each new release.
ActiveRecord is currently thread safe; however, the C implementation of Ruby still uses threads that are not native to the operating system.
The fact that Ruby is not as fast as C# — and even assuming that a Rails app is much slower than an equivalent one written in ASP.NET — doesn't imply that Rails doesn't scale. It only tells us that more hardware is required to handle a comparably large amount of Web traffic. You also need to keep in mind that often the real bottlenecks are elsewhere, and having a fast framework and language won't do you much good if, for example, caching and database optimization are not fine tuned.
Chapter 11 has further considerations on scaling but, for the time being, don't be too concerned about this aspect: many large sites employ Rails and are able to serve millions of requests on relatively inexpensive hardware.