Why You Should Learn Ruby on Rails

35 comments

Welcome to the first episode of the Learning Rails podcast.

My name is Michael Slater, and my colleague Chris Haupt and I have created this podcast to help web designers and developers get started with Ruby on Rails.

There are other excellent podcasts about Ruby on Rails, but for the most part they’re intended for people who are already knowledgeable about Rails. Learning Rails is the only Rails podcast that assumes you’re new to the platform.

We’re not going to try to teach programming specifics – audio isn’t a great media for that. Instead, we’ll focus on the concepts that underlie Ruby on Rails. Once you have a good conceptual grounding, it’s a lot easier to dive into writing code.

You don’t need to be a computer scientist to build Rails applications. But you do need to take the time to learn some new concepts. You can start slowly, building simple Rails sites, and gradually expand your capabilities. In this podcast, we’re assuming you understand basic programming principles, but we don’t expect you to be a professional software developer.

To kick off the series, in this episode we’ll introduce Ruby, and Rails, and explain why it is worth your time learn another language and another way of building web sites.

What is Ruby on Rails?

If you’re taking the time to listen to this podcast, you’ve no doubt heard something about Ruby on Rails. It is arguably the hottest technology in web application development today, and it is at the heart of many “Web 2.0” sites. Developers love it, and entrepreneurs are delighted by how quickly applications can be created with it.

Ruby on Rails gained its early popularity with startups and small companies, but it has grown far beyond that early base. Big players such as Amazon, eBay, and AOL are using Rails for some of their newer projects. And it is not limited to the consumer web: Thoughtworks, an 800-employee global IT company, is now using Rails in many of its enterprise projects. Here’s a brief quote from the Thoughtworks web site:

“Ruby’s elegance, along with Rail’s emphasis on Agile practices, is providing many adopters with several-times higher productivity than traditional Java and .NET web-development platforms, creating enterprise-worthy systems in many domains.”

Keep in mind that this quote comes from a substantial firm that built a large part of its reputation on Java applications.

To understand why Ruby on Rails is so popular, let’s first take a look at what it actually is, and where this strange name comes from.

There’s two separate parts to Ruby on Rails: the Ruby language, and the Rails framework. Think of Rails as a set of “tracks” to make development of web applications with Ruby go faster.

Ruby is a general-purpose programming language that is not in any way specific to web applications. You can use Ruby without Rails – people use it for stand-alone application programs, scripting server administration tasks, and even for web applications that don’t use Rails.

Rails is a web application framework, written in Ruby, and all Rails applications are written in Ruby. An application framework such as Rails provides a structure for your code and includes a variety of powerful code modules that make many programming tasks simpler.

A quick tour of the Ruby Language

Let’s first take a quick look at the Ruby language.

Ruby is among the newer computer languages, having emerged in the mid-90’s. It was designed by Yukihiro Matsumoto, generally known as Matz. It is a dynamic, object-oriented, interpreted language, and draws its inspiration from scripting languages Perl and Python, object-oriented languages Lisp and Smalltalk, and other more obscure languages. Matz had a vision for a clean, expressive language, and Ruby delivers on that promise.

In an object-oriented language such as Ruby, objects are the fundamental building blocks of your program. An object is a way of encapsulating some data and the actions that can be taken on that data. If these ideas are new to you, the following section may be a little confusing, but you can gloss over it for now; we’ll go into much more detail about Ruby and object-oriented programming in later podcasts. There’s also some pointers to good introductions in the show notes, which you can access at learningrails.com.

For now let’s touch on a few key areas to convey an overall sense for the language.

Ruby is what is called a dynamic language. This means at least three different things:

• First, it is dynamically typed. You can assign any kind of data object to a variable, without having to specify its type, such as integer or string, in advance.

• Second, classes and objects in the language are dynamic: you can modify class definitions and create methods while a program is executing. Writing Ruby code that itself creates code is called metaprogramming, and it plays a big role in how Rails works internally.

• Third, Ruby is dynamically interpreted as the program is executed: there is no compilation step. The program is stored in its source-code form, and this source code is decoded and executed by the Ruby interpreter when the program runs.

In Ruby, everything is an object. This approach, combined with the language’s dynamic nature, means that you can define new methods that apply to even basic data types, such as integers and strings.

Ruby is very clean in terms of how it looks. You don’t need semi-colons at the end of lines. You don’t need parentheses around parameters. The language syntax does its best to support expressive, highly readable code. This too is a significant part of Rails’ appeal; at its best, parts of the code read like English declarations describing what you want the code to do.

Earlier I said that Ruby and Rails were entirely separate, but in fact this is a little bit of an exaggeration. Ruby is a language and Rails is a framework, but their designs, and their fates, are interwoven. The Ruby language’s unusual abilities are crucial enablers for many aspects of Rails’ design. Furthermore, the Rails framework includes important extensions to the Ruby language, and it is the popularity of Rails that has made Ruby more than an obscure, niche language.

There’s lot’s more to say about Ruby, but this is enough to understand why Ruby is such an important part of Rails.

An overview of the Rails framework

Now let’s turn our attention to the Rails framework. Rails was created by David Heinemeier Hansson at 37signals. He didn’t set out to build a general-purpose framework for others to use; he wrote the code that evolved into Rails to make it easier for him to build Basecamp, a hosted service for project management and collaboration. Rails was extracted from Basecamp and put out as an open-source project in the summer of 2004.

Since then, a core team of 10 developers and dozens of other contributors have steadily and rapidly advanced the framework. There’s been a series of major releases, with 1.2.5 being the current version as we speak. A release candidate for version 2.0 is available, and very soon Rails 2.0 will be the standard for new projects.

Rails is both broad and deep, providing a wide range of capabilities with significant depth in many of them. This complexity can make Rails hard to learn for a beginner; it takes many months of development to become familiar with all, or even most, of Rails. But we’ll help you get started by explaining first just what you need to get started, so you can begin building sites and pick up new skills and knowledge as needed.

Part of the Rails way is an approach called “convention over configuration.” There’s a lot in common across most web applications. When you have to make every decision about how to structure things, you spend a lot of time on decisions that really don’t matter, or for which you may not have the expertise to make the best choice. Rails is often called “opinionated software,” because it is built around a set of opinions about how to build web applications.

By going with the flow and following Rails conventions, vast amounts of configuration code are entirely eliminated. Lots of things “just work”, like collecting data from a form, validating it, and then either writing it to the database or displaying error messages, because of the built-in plumbing that makes a set of assumptions about how everything is named and organized.

It takes a while to get accustomed to the Rails way of doing things, and you may have a hard time giving up some of your preconceived notions. But there’s a huge payoff for going with the flow and following Rails conventions. You’ll write less code, accomplish more, and all your applications will be similarly structured and quickly understandable by any Rails programmer.

Rails implements a design pattern called Model-View-Controller, which is an approach to partitioning applications that makes them easier to write, understand, and maintain. It is possible to use this pattern with any language, and you don’t necessarily need a framework to do so. But without a framework like Rails, it takes a lot more knowledge and design discipline to follow this pattern.

We’ll dive deep into model-view-controller in later podcasts. For now, let’s continue with a quick tour of Rails’ major features.

Rails is designed for database-backed web applications. Whenever you have a database being accessed by an object-oriented program, you need some way to relate the objects in your program to tables and rows of data in the database. You can do all this in your own code, if you want to do things the hard way, but there’s a handy tool called an object-relational mapper that simplifies your task.

In Rails, the object-relational mapper is called ActiveRecord. ActiveRecord is one of the largest and most important parts of Rails. All communication with the database goes through ActiveRecord.

ActiveRecord provides a key part of the “magic” of Rails: you just create your database, and ActiveRecord examines the database schema and automatically creates rich, powerful classes that let you deal with your data as software objects. It also handles relationships between tables, since in a relational database information is often spread across many tables.

If you have a customers table, an addresses table, and an orders table, you can write code in your customer model class that literally reads “customer has one address”, and “customer has many orders”, and it is then trivial to retrieve a customer’s address, or all of a customer’s orders.

ActiveSupport is another important module in Rails. It extends the Ruby language and provides lots of helpers that simplify many of the things a web application needs to do. It lets you write code like “4.days.from.now” and is part of how Rails extends Ruby to act as a domain-specific language for creating web applications.

The final major part of Rails that I want to discuss in this episode is the facilities for rendering views – that is, creating the visual pages that, from the user’s perspective, are the web site.

Rails includes a templating system that enables you to easily modularize your pages. Most pages are rendered within a “layout”, which is a file that defines the overall structure of the page. With this approach, you don’t have to worry about all the repeating elements every time you create a new page. And as with other scripting languages used for web sites, you can intermix HTML and Ruby code, using something called embedded Ruby, or ERB.

The Rails term for a subset of a page is a “partial.” You can define a partial for the page header, one for the navigation bar, one for each column of the page, and one for the footer. Then your page layout file doesn’t have to include any details about what’s in any of these areas; it just defines the area, and calls the partial to provide the contents. You can use the same partial in multiple layouts, making it easy to provide multiple page templates that use the same components. There are some slick shortcuts like calling a partial with an array, which renders the partial once for each element in the array.

Rails has “helpers” that make it easy to produce forms and other common HTML elements. It also has built-in support for the Prototype and Scriptaculous JavaScript frameworks, which simplifies writing Ajax code. There’s even something called RJS – Ruby JavaScript – that lets you write Ruby code to define interactive behavior to be executed in the browser. The Rails framework automatically translates the Ruby code to JavaScript.

There’s a lot more to be said about the technology of Ruby and Rails, such as database migrations, the built-in testing framework, the Rake automation utility, and support for RESTful designs. But it’s time for us to move on and explore the reasons why it is worth your time to learn all this. Once we have you convinced, the later episodes in the series will provide more details.

Why invest the time to learn Ruby on Rails?

Should you learn Ruby on Rails? It does take a significant effort, and if you’re already proficient in PHP, Python, Java, or .net, switching to Rails will take an investment of time and effort before it delivers any returns. I believe that, for most web developers, this is an investment well worth making. Here’s why.

The core reason is simple: once you’re up to speed, building web applications in Rails is easier and more fun, and the resulting applications are reliable and easily maintained and modified. Rails works very well with an Agile approach to design, which is a great fit for web development.

If you’re using PHP and working without an MVC framework, switching to Rails will bring order to your creations. If you’ve tried something like CakePHP or the Zend framework, you’ll see how much more elegant a framework can be when it is written in Ruby.

If you come from the Java world, get ready for a breath of fresh air. With Java MVC frameworks, you can easily spend more time writing XML configuration files than it takes to write your entire application in Rails. Experienced Java developers have estimated that they can build applications three to ten times more quickly using Rails.

Compared with .net, you’ll appreciate the merits of the open-source software model, the focus on web applications, and the rapid evolution of the platform.

The bottom line is that Rails enables you to build applications more quickly, have fewer bugs, more readily meet user needs, and have more fun doing it.

The Rails Sweet Spot

Does this sound too good to be true? There are, of course, a couple of caveats.

First, Rails only delivers its full value for applications that fall within its sweet spot – but it’s a pretty big spot. Rails is best suited for “green field” web applications, in which you’re starting from scratch and can design the application from the ground up using the Rails approach. It’s a great fit for the vast majority of web applications.

Here’s a few concrete examples:

• Basecamp, at basecamphq.com, is the original Rails application. It provides shared to-do lists, documents, time tracking, file storage, and messaging to enable teams to work together more effectively.
• Revolution Health, at revolutionhealth.com, is one of the largest Rails-based consumer sites. It provides a vast array of personalized health information, including a directory that lists hundreds of thousands of health professionals.
• Strongspace, at strongspace.com, is an online storage service.
• Twitter, at twitter.com, is a messaging service that sends brief updates to all your friends’ instant messaging clients, mobile phones, or special twitter clients.

There are a few applications that fall outside of the Rails sweet spot. These include:

• Simple, static sites
• Sites that fit well within the capabilities of content management systems such as Drupal and Joomla
• Sites that depend on large existing bodies of code
• Sites which must access a legacy database that is still used by other code, so it can’t be restructured to fit naturally with the Rails paradigm
• Situations that require dozens or even hundreds of low-volume sites to be hosted on a single server
• Very large scale sites that need to deliver maximum performance from a given amount of hardware

These exceptions to the rule illustrate where Rails doesn’t fit: applications that are too simple to justify its complexity; that are too tied to existing technology to gain the full value of Rails; or for which performance is the paramount concern.

Rails weaknesses

Some developers would argue that for very large projects, with dozens of developers, the structure of Java may be more effective. This is certainly true if the team is experienced with Java and new to Ruby, but it remains to be seen if it will remain true as more developers gain Ruby and Rails experience and the Ruby and Rails tools continue to improve.

One issue that is often listed as a key weakness of Ruby on Rails is speed. It is undeniably true that Ruby is not particularly fast, at least as it is implemented today. If compute speed is your number-one priority, there are better languages. But the reality is that most web applications do very little computing, and factors such as network latency and bandwidth, disk access, and database performance are usually far more important. In addition, there are multiple efforts under way to improve Ruby’s performance.

Rails does sacrifice some raw machine efficiency, but it does so for a good cause: your productivity. The most expensive part of building and maintaining a web application is the developers’ time. It’s a lot more cost-effective to use twice as many servers than to use twice as many developers. Scaling to truly high volume is hard, but it is hard with any platform, and there’s more and more experience every week in how to make it happen with Rails.

Rails sites can be harder to deploy that sites using technologies such as PHP. This was a serious issue in the early days of Rails, in which the technology was young and there were few hosting providers experienced with it. Today, you may still have challenges with generic, low-cost hosts, but there’s an ample assortment of capable Rails hosting companies. It does tend to cost a little more to host a Rails application, but remember that your time is your most valuable asset, and it is well worth paying a bit more for hosting to make better use of your time.

Is it worth making the switch to Rails?

Ultimately, the factor that probably keeps more developers away from Rails than any other is the learning curve. If you’ve already been working with one technology, it’s always more time consuming in the short term to switch to a different one. And if you’re only working on simple sites, it may not be worth the investment.

But if you want to advance your skills and become as productive as you can be, you owe it to yourself to learn Ruby on Rails. You’ll need to invest a few months of study and practice to become proficient, but from that point forward you’ll be building better sites more quickly and having more fun doing it.

If you’re a PHP developer, you many wonder whether you can take a short-cut and use a PHP-based MVC framework instead of having to learn Ruby. In the short term, this may save you time. But Ruby is a key enabler of many aspects of Rails, and it just isn’t possible to build a framework that really matches Rails in a language such as PHP. Learning any powerful framework takes a significant effort, whether it’s a PHP framework or a Ruby framework. Learning the basics of Ruby isn’t hard. The payback is that you’ll be working in a more modern, more elegant language, and with a more powerful framework as well.

In future episodes of this podcast, we’ll explore all the key concepts that underlie Ruby on Rails. Ultimately, though, you need to begin building sites with it to really understand it. There’s a variety of good books and online resources available, many of which you’ll find listed in the show notes at learningrails.com.

---