Introducing Ruby on Rails

Since Ruby on Rails was first released, it has become a household name (well, in developers' households, anyway). Hundreds of thousands of developers the world over have adopted—and adored—this framework. I hope that, through the course of this book, you'll come to understand the reasons why. Before we jump into writing any code, let's take a stroll down memory lane and explore a little of the history of Ruby on Rails.

First, what exactly is Ruby on Rails?

The short-and fairly technical—answer is that Ruby on Rails (often abbreviated to “Rails”) is a full-stack web application framework written in Ruby. That is a distinction worth emphasizing. Ruby is a language and Rails is a framework. Say that last sentence out loud a couple of times. Rails is often mentioned as if it is a language, so understanding that Ruby is the language and Rails is the framework is your first step on this journey of learning.

However, depending on your previous programming experience (and your mastery of tech-jargon, that answer might make little sense to you. Besides, the Ruby on Rails movement—the development principles it represents—really needs to be viewed in the context of web development in general if it is to be fully appreciated.

So, let's define a few of the terms in the definition above while taking in a brief history lesson along the way. Then we'll tackle the question of why learning Rails is one of the smartest moves you can make for your career as a web developer.

A web application is a software application that's accessed using a web browser over a network. In most cases, that network is the Internet, but it could also be a corporate intranet. The number of web applications being created has increased exponentially since Rails came into being, due mostly to the ubiquity of broadband internet access and the proliferation of mobile devices. We can only assume that you're interested in writing such a web application, given that you've bought this book!

A framework can be viewed as the foundation of a web application. It takes care of many of the low-level details that can become repetitive and boring to code, allowing the developer to focus on building the application's functionality.

A framework gives the developer classes that implement common functions used in every web application, including:

• database abstraction (ensuring that queries work regardless of whether the database is MySQL, PostgreSQL, MongoDB, SQLite, or [insert your favorite database here])

• templating (reusing presentational code throughout the application)

• management of user sessions

• generation of clean, search-engine-friendly URLs

A framework also defines the architecture of an application; that is, how the application is physically laid out. This facility can be useful for those of us who fret over which file is best stored in which folder.

In a sense, a framework is an application that has been started for you, and a well-designed application at that. The structure—plus the code that takes care of the boring stuff—has already been written, and it's up to you to finish it off. You are truly standing on the shoulders of giants when you start building a Rails app.

Full-stack refers to the extent of the functionality that the Rails framework provides. You see, there are frameworks and then there are frameworks. Some provide great functionality on the server, but leave you high and dry on the client side; others are terrific at enhancing the user experience in the browser, but don't extend to the business logic and database interactions on the server. Rails, by the way, gives you both.

If you've ever used a framework before, chances are that you're familiar with the model-view-controller (MVC) architecture (if not, don't worry—we'll discuss it in Chapter 4. Rails covers everything in the MVC paradigm, from database abstraction to template rendering, and everything in between.

Ruby is an open-source object-oriented scripting language invented by Yukihiro Matsumoto (affectionately known as "Matz") in the early 1990s. We'll be learning both Ruby and Rails as we progress through the book (remember, Rails is written in Ruby).

Ruby makes programming flexible and intuitive, and with it we can write code that's readable by both humans and machines. Matz designed Ruby to make programmers happy, as you'll see as we move through this book.

History

Ruby on Rails originated as an application named Basecamp, a hosted project-management solution created by Danish web developer David Heinemeier Hansson (affectionately known as "DHH" to Rubyists) for former design shop 37signals. Due largely to Basecamp's success, 37signals has since moved into application development and production, and Heinemeier Hansson has become a partner in the company.

When I say “originated,” I mean that Rails wasn't initially created as a stand-alone framework. It was extracted from an application already in use, so that it could be used to build other applications that 37signals had in mind. Heinemeier Hansson saw the potential to make his job (and life) easier by extracting common functionality such as database abstraction and templating into what later became the first public release of Ruby on Rails.

He decided to release Rails as open-source software to remake the way web applications are built. The first beta version of Rails was initially released in July 2004, with the 1.0 and 2.0 releases following in December, 2005 and 2007 respectively. A little over 2 years later, version 3.0 of Rails was released and the number of contributors had ballooned to approximately 1,600. Rails 4 came out in 2013, with minor releases continuing through to the end of 2014 with 4.2. Rails 5.0, which is the focus of this book, was released in mid-2016.

That the Rails framework was extracted from Basecamp (and is still the foundation of Basecamp today) is considered by the lively Rails community to represent one of the framework's inherent strengths: it was already solving real problems when it was released. Rails wasn't built in isolation, so its success wasn't a result of developers taking the framework, building applications with it, and then finding—and resolving—its shortcomings. Rails had already proven itself to be a useful, coherent, and comprehensive framework.

While Heinemeier Hansson pioneered Rails and still leads the Rails-related programming efforts, the framework has benefited greatly from being released as open-source software. Over time, many developers working with Rails have submitted thousands of extensions and bug fixes to the Rails development repository.The Rails repository, located at https://github.com/rails/rails/, is used to track bugs and enhancement requests. The repository is closely guarded by the Rails core team, which consists of about twelve highly skilled professional developers seen in figure 1-1, chosen from the crowd of contributors, and led by Heinemeier Hansson.

There is also a "committer team" made up of eight or so individuals that can do everything except set policy and make final releases. On top of that, there is the community at large, the source of many patches and plugins. At present, Rails has accepted contributions from over 4,600 programmers!

Finally, a framework as mature as Rails should have some good documentation, and it does. The Rails Guides are an excellent resource on understanding the many pieces of Rails. Bookmark these guides, as you'll likely return to them throughout your journey as a Rails programmer.

So, now you know what Rails is, how it came about, and who supports it. But why would you invest your precious time in learning how to use it?

I'm glad you asked.

Development Principles

Rails supports several software principles (a doctrine, if you will) that make it stand out from other web development frameworks. Those principles are:

• optimize for programmer happiness
• convention over configuration
• the menu is omakase
• no one paradigm
• exalt beautiful code
• value-integrated systems
• progress over stability
• push up a big tent

This doctrine has grown and changed as Rails has grown and changed in the last decade or so. The principles are not without controversy, and understanding them will help you understand how Rails became what it is.

Optimize for Programmer Happiness

I've mentioned that Matz designed Ruby to make programmers happy, and this tenet of the Rails doctrine is pulled directly from that sentiment. Just as Ruby replaces complexity with easy language and offers many ways to achieve a programmer's goal, so does Rails aim to make web application complexity more mundane. You'll see this immediately when we start coding the example application in this book. Using just two simple commands in the terminal, Rails is serving up a functional web application. The amount of complexity that is abstracted away from the programmer is quite amazing, so that we can focus on building the desired application and not the niggling details of web development.

Still, if hiding complexity was all Rails did, programmer happiness would quickly cease. Not all web applications have the same requirements, which means Rails developers often have to get behind the curtain and tweak the magic of Rails. Do you want to change the database you're using? No problem. What about how user sessions are stored? Go for it. Rails hides the complex items until you need to alter them, then it makes changing complexity sensible. This aspect of Rails probably speeds up development of usable applications faster than anything else.

I should also mention that creating a Rails application is as good an experience as you can hope for in your development life. There is a Rails console that opens the guts of your web application, allowing you to poke around and find where the bugs are or test out code. Testing is built into Rails better than any other web development framework in the world, hands down. When I develop web apps in other languages or with other frameworks, I find myself pining for the tools and environment that Rails brings to the table.

Convention Over Configuration

The concept of convention over configuration refers to how Rails assumes a number of defaults for the way one should build a typical web application.

Many other frameworks require you to step through a lengthy configuration process before you can make a start with even the simplest of applications. The configuration information is usually stored in a handful of XML or JSON files, which can become quite large and cumbersome to maintain. In many cases, you're forced to repeat the entire configuration process whenever you start a new project.

While Rails was originally extracted from an existing application, extensive architectural work went into the framework later on. DHH purposely created Rails in such a way that there's no need for excessive configuration, as long as some standard conventions are followed. The result is that no lengthy configuration files are required. In fact, if you have no need to change these defaults, Rails really only requires a single (and short) configuration file in order to run your application.

Other conventions that are prescribed by Rails include the naming of database-related items and the process by which controllers find their corresponding models and views.

Rails is also considered to be opinionated software, a term coined to refer to software that isn't everything to everyone. DHH and his core team ruthlessly reject contributions to the framework that fail to comply with their vision of where Rails is headed, or aren't sufficiently applicable to be useful for the majority of Rails developers. This is a good way to fight a phenomenon known among software developers as bloat: the tendency for a software package to implement extraneous features just for the sake of including them.

The Menu is Omakase

This principle is similar to the goal of optimizing for programmer happiness. "Omakase" comes from the restaurant industry–sushi restaurants, to be more specific–and is the concept of letting the chef pick your meal based on his sophisticated palette. If you are new to ordering sushi, for example, using an omakase method can help you figure out what is good. As such, the Rails team will look at the practices and tools that most developers are using and evaluate whether they deserve inclusion in the core framework. This has resulted in tools such as CoffeeScript (which we'll discuss in Chapter 7) and Spring being included in the framework.

It's only fair to point out that this is probably the most controversial part of the Rails doctrine. While those new to Rails may like being served a stack of tools to use, experienced developers are different beasts altogether. Often, the selected tool is unpopular with a part of the community that is highly vocal about it. The good news is that these tools can be removed or swapped out for other tools without much ceremony.

No One Paradigm

Rails has been growing and changing for almost a decade. In that decade, the languages, tools, approaches, and design patterns have exploded. We know much more as an industry today than we did in 2007. As such, the design concepts and paradigms behind Rails that have been altered or refined are based on new understanding. This kind of change and continued learning will never stop, so Rails has to account for it.

When DHH describes Rails as a quilt, he means it's made up of several paradigms and ideas, instead of a single idea that permeates the framework. You'll hear about design patterns, such as Active Record, that is foundational to Rails models, but can be implemented differently or even completely removed (we’ll discuss Active Record in Chapter 4). Rails is not pedantic in how it uses design patterns, always erring on the side of being practical. As you dive deeper into Rails, you'll be presented with more patterns and languages. Do you need to refine an SQL query? You can do that by writing the SQL yourself or leveraging the tools of Arel and Active Record. Does your client-side JavaScript need to perform some fancier stuff in the browser? You can add front-end libraries or write the code yourself. Do you think the Datamapper pattern is better than Active Record? Okay, swap it out.

The point is, not only is Rails a quilt, each Rails application is a different quilt. The paradigms presented are yours to use, or not. The downside is that you need to know a lot of design ideas and programming concepts to change these paradigms. But, don't worry, Rails will take you a long long way before you need to know about this stuff. Rails gets you excited about doing things fast, then it revs you up by supporting your education and growth as a programmer.

Exalt Beautiful Code

In my opinion, this is another concept that Rails has fully adopted from Ruby and its community. Ruby was designed for humans to read, not computers. As such, it is quite possible to write "beautiful" code. As with any beauty, it is in the eye of the beholder, but I'll bet we can agree that this code is beautiful:

Without telling you anything about the application this code came from, you can still surmise much about what is happening. Ruby and Rails use the excellent design of Ruby's core libraries along with some Domain Specific Languages (DSLs) to allow you, the happy developer, to write code that is expressive and concise. And that to me is beautiful.

One of the age-old adages that fits into this principle is called Don't Repeat Yourself, also known as the DRY principle. Being DRY in your code means you don't copy/paste the same code all over your codebase. Instead, you extract common code and reuse it where needed. This leads to a more maintainable and beautiful code base. I'll reference the DRY principle a few times throughout the book, and you'll see it in the wild.

So what? You might be asking. Well, when you are spending hours in a codebase that is poorly written or hard to read, it's exhausting. Your poor brain has to constantly translate the code and its abstractions. If the code is not expressive, this is a significant mental task. If the code lacks conciseness, it's tiring to read. Beautiful code is easier to share with your peers, making collaboration enjoyable and purposeful. As with anything in life, beauty in code is noble and meaningful.

Value-integrated Systems

This particular principle is another of Rails' more controversial tenets. If you've read anything about web development recently, there's a lot of talk about splitting applications into many applications, creating microservices. These split-up applications are a reaction to large web apps, called monoliths. DHH and the Rails team believe in the value of keeping the application in a single codebase. They certainly believe that the app should start that way, rather than designing a suite of applications and services up front. There are benefits to both approaches, and what you do depends more on a particular use case than a Rails design principle.

Having said that, Rails is designed to build a complete and full-stack web application. In this book, that is what we will do.

Progress Over Stability

When talking about the history of Rails, I mentioned that the 3.0 release was a doozy. It took two years and had many, many breaking changes. This meant that applications on Rails 2.0 had a painful upgrade path. For a couple of years, it was impossible to swing a dead cat without hitting someone who had abandoned Rails rather than continue to try and upgrade. The core team felt that the changes made from 2.0 to 3.0 were necessary to avoid burdening Rails with the heavy baggage of the older framework. Rails 2.0 was cracking under its own weight. We had learned much about better design and new approaches to the problems Rails solves, and the changes had to be made. Looking back, it's hard to argue with the decisions made. Rails is better than ever, largely due to the decisions made for that 3.0 release.

If you stick around and become a Rails developer (and I sincerely hope you do), you'll hear about additions to Rails that rile parts—or even most—of the community. Tools such as Spring, Turbolinks, CoffeeScript, and Action Cable were all brought into the fold in the name of progress. Many breaking changes have been made to shave off the cruft of "old ways," ensuring that the future of Rails doesn't suffer as a result of its past.

Often these additions are the right thing to do, but they need the community to chime in before they are fully cooked. Hence, they are introduced to the framework as the approach or tool is honed and made better by the community and team. This is in the name of progress over stability, and it's likely a reason why Rails is as active as ever a decade after its birth.

Push Up a Big Tent

In the current programming environment, this tenet may be the most important. Rails is a big tent, and there are many, many folks under it with us. There's no entry admission charged; nor will we demand that you produce immediately. We will, however, expect you to value the community and its tools. We'll expect you to express your opinions, and be respectful and professional.

These are the member traits that build a strong foundation for the larger community. The people in the Rails tent are not a cult, they just want to build great things. They are people that want to learn from others. Rubyists are not all cut from the same cloth, and that's why this community is among the very best in the programming world.

DHH writes of his disdain for microservices or certain Ruby libraries that are very popular. Yet these libraries flourish, even without the endorsement of one of the most prominent community members. He loves that, and so do I. I want a tent full of diverse, intelligent, respectful, and fun individuals, and that is what the Rails community is today.

If your head is spinning from trying to digest these principles, don't worry—they'll be reinforced continually throughout this book, as we step through building our very own web application in Ruby on Rails.

Building the Example Web Application

As you read on, I expect you'll be itching to put the techniques we discuss into practice. For this reason, I've planned a fully functional web application that we'll build together throughout the ensuing chapters. The key concepts, approaches, and methodologies we'll discuss will have a role to play in the sample application, and we'll implement them progressively as your skills improve over the course of this book.

The application we'll build will be a functional clone of part of the popular link-sharing website, Reddit: namely, the ability to share a link and vote on it. I've included all necessary files for this application in the book's code archive.

Reddit describes its functionality as follows:

The global Reddit community votes on which stories and discussions are important by casting upvotes or downvotes. The most interesting, funniest, impactful, or simply amazing stories rise to the top.

Basically, if you want to tell the world about that interesting article you found on the Internet—be it a blog post that's right up your street, or a news story from a major publication—you can submit its URL to Reddit, along with a short summary of the item. Your link will sit there, waiting for other users to "vote it up" (give your item a positive vote). As well as voting, users can comment on the story to create often lively discussions within Reddit.

Reddit was launched in 2005, and is consistently listed in the Alexa traffic rankings as one of the Internet's top 50 websites.

This isn't the reason why you'll be developing your own Reddit clone, though; its feature set is not particularly complicated, and is sufficient to allow us to gain firsthand experience with the most important and useful facets of the Ruby on Rails framework.

And while your application might be unable to compete with the original site, reusing this sample project to share links within your family, company, or college class is perfectly conceivable. With any luck, you'll learn enough along the way to branch out and build other types of applications as well.

Features of the Example Application

As I mentioned, we want our application to accept user-submitted links to stories on the Web. We also want to allow other users to vote on the submitted items. In order to meet these objectives, we'll implement the following features as we work through this book:

• A database back end that permanently stores every story, user, vote, and so on. This way, nothing is lost when you close your browser and shut the application down.

• A link submission interface, which is a form that's available only to users who have registered and logged in.

• A simplistic, responsive layout as is typical for today's mobile-aware applications. We'll style it with Cascading Style Sheets (CSS) and enhance it with visual effects.

• Clean URLs for all the pages on our site. Clean URLs (also known as search-engine-friendly URLs) are usually brief and easily read when they appear in the browser status bar. An example of a clean URL is http://del.icio.us/popular/software, which I'm sure you'll agree is a lot nicer than http://www.amazon.com/gp/homepage.html/103-0615814-1415024/.

• A user registration system that allows users to log in with their usernames and passwords.

• The ability to check voting history on a per-user and per-story basis.

It's quite a list, and the result will be one slick web application! Some of the features rely upon others being in place, and we'll implement each feature as a practical example when we look at successive aspects of Rails.

Summary

Well, here we are; your first step towards Rails is complete. This chapter walked us through Rails' beginnings—a framework born as a way to solve real problems. There were mentions of Ruby, the language foundation of the Rails framework, along with some code snippets to whet your whistle. You learned that Ruby and Rails were created to make programmers happy and more productive. We looked at the founders and many contributors to Rails, along with the development principles that serve as its base.

These ambitious and sensible development principles drive Rails programmers, and you are about to be amongst their ilk. As we go through this book and build our application together, try to keep the principles in mind. You'll build habits that will influence your work for your entire career.

Finally, we created a brief specification for the web application we’re going to build throughout this book. We described what our app will do, and identified the list of features that we’re going to implement. We’ll develop a lite clone of the link-sharing website Reddit iteratively, taking advantage of some of the Agile development practices that Rails supports.

In the next chapter, we’ll install Ruby, Rails, and the SQLite database server software in order to set up a development environment for the upcoming development tasks.

Are you ready to join in the fun? If so, turn the page …