-
Notifications
You must be signed in to change notification settings - Fork 3
what is ruby rails
Last updated 8 March 2013
What is Ruby on Rails? Introduction to Rails for a Rails beginner.
Getting started learning Rails? See recommendations for a Rails tutorial to suit your skill level and learning style.
Ruby is a programming language. It was developed in Japan 20 years ago and became well known following the release of Rails in 2004. By most measures of programming language popularity, Ruby ranks among the top ten, though usually as tenth (or so) in popularity, and largely due to the popularity of Rails.
Rails is a software library that extends the Ruby programming language. As named by its creator, David Heinemeier Hansson, it is known as Ruby on Rails, though informally it is often just “Rails.” It is a framework for building websites, providing conventions to make collaboration and maintenance easier. Rails combines the Ruby programming language with HTML, CSS, and JavaScript to create a “web application” that runs on a web server. Thus, Rails is a server-side, or “back end,” web application development platform.
Rails, in a larger sense, is more than a software library used to build websites. Rails is the central project of a vast community that produces software libraries that make it possible to build complex websites. Members of the Rails community share many core values, often use the same tools, and support each other with an informal network that is built on volunteerism. Overlapping the informal community is an economic network that includes jobs, recruiters, consulting firms, conferences, infrastructure services, businesses that build websites with Rails, and investors that fund startups. Rails is particularly popular among web startups, likely because the pool of open source software libraries (RubyGems, or “gems”) makes it possible to build complex sites quickly.
Read on for a more detailed look at Rails. First, we’ll look at why Rails uses the Ruby programming language. We’ll review some basic concepts, then look at Rails from six different perspectives to understand it better.
In a podcast from This Developer’s Life, David Heinemeier Hansson, the creator of Rails, describes his frustration with the PHP programming language, stemming from a lack of abstraction and a tendency to repetitive code. As he began building an online project management website named BaseCamp in 2004, Hansson liked the software enginering abstractions supported in the Java programming language but was more excited about the ease of use (he calls it pleasure) he found in the Ruby language.
Ruby is known among programmers for a terse, uncluttered syntax that doesn’t require a lot of extra punctuation. Compared to Java, Ruby is streamlined, with less code required to create basic structures such as data fields. Ruby is a relatively advanced language that makes it easy to use high-level abstractions (such as “closures” and metaprogramming). In particular, metaprogramming makes it easy to develop a “domain specific language” that customizes Ruby for a particular set of uses (Rails and many gems use this “DSL” capability).
Ruby’s key advantage is RubyGems, the package manager that makes it easy to create and share software libraries (gems) that extend Ruby. RubyGems provides a simple system to install gems. Anyone can upload a new gem to the central RubyGems website, making the gem immediately available for installation. The RubyGems website is where you’ll obtain the most recent version of Rails. And it is where you will obtain all the gems that help you build complex websites.
Ruby has several disadvantages (at least when programmers want to argue). Its processing performance is slow relative to C++ or Java. The execution speed of a language is seldom important, though, relative to the benefits gained by programmer productivity and the general level of performance delivered by most websites. For websites that require lots of simultaneous activity, Ruby is not well-suited to the high-level software engineering required to execute simultaneous activity efficiently (standard Ruby lacks “parallelism”, though some versions support it). Lastly, some programmers complain that Ruby programs (and especially Rails) contain “too much magic” (that is, complex operations that are hidden behind simple directives). These concerns haven’t stopped Rails from becoming a popular web development platform.
You may hear advice that one should study Ruby (the programming language) before attempting to use Rails to build websites. In fact, whether you study Ruby or not, you’ll likely become a skilled Rails developer before you become a skilled Ruby programmer. That’s because Rails is largely a “domain specific language” that has its own set of directives distinct from the Ruby core. You’ll be using the Ruby language syntax but you’ll largely be learning the Rails “language.”
To avoid feeing overwhelmed when you first begin learning Rails, it is advisable to spend an hour or two with an introduction to Ruby so you are comfortable with the syntax of the language. You should be prepared to recognize correct formatting when you type Ruby code in your text editor. You can find several good online tutorials listed on the Ruby and Rails resource page. Get started with a quick lesson from RubyMonk or Try Ruby.
Be assured that you will indeed learn Ruby as you develop proficiency with Rails. Your hardest challenge will be to learn the names of the structures you see in code examples. This is why it is helpful to work your way through a short introduction to Ruby. You’ll need to be able to recognize when you are looking at an array or a hash. You should recognize when you are looking at an iterator or the Ruby block syntax. Eventually, you’ll recognize more exotic Ruby formulations such as the lambda. It is okay if you can’t write a lambda function or even know when to use one; many Rails developers start work before learning Ruby so well.
As experienced Rails developers, we hope you will make an effort to learn Ruby concurrently (or at least in parallel) as you learn Rails. Don’t be lazy; when you encounter a bit of Ruby you don’t understand, make an effort to find out what is going on. Spend time with a Ruby textbook or interactive course as you get more proficient with Rails. By all means, if you love the precision and order of programming languages, dive into the study of Ruby from the beginning. But don’t delay starting Rails while you learn Ruby; realistically, you’ll retain more knowledge of Ruby if you learn it as you build things in Rails.
Let’s start from scratch to get a clear picture of Rails and how it works. You may already know most of this, but let’s review.
Rails combines the Ruby programming language with HTML, CSS, and JavaScript to create a “web application” that runs on a web server. You’re running a web browser on your computer (probably to read this article). A browser obtains the files from a web server. The web server can be remote (connected by the Internet) or on your own computer (when you are doing development).
A web browser combines three kinds of files—HTML, CSS, and JavaScript—to display web pages.
In an “Introduction to Web Design” class, you might have learned how to create HTML, CSS, and JavaScript files. HTML (HyperText Markup Language) is a convention for creating structured documents that combine content (such as text, images, or video) with generic typographic, layout and design elements (such as headlines and tables). CSS (Cascading Style Sheets) directives apply a specific appearance to typographic, layout and design elements. JavaScript is a programming language supported by all web browsers that is used to manipulate HTML and CSS elements, particularly for implementing interactive features such as tabs and modal windows.
Web servers deliver HTML, CSS, and JavaScript, either from static files that are stored on the server, or from an “application server” that creates files dynamically using a programming language such as Ruby. Rails provides an application server that uses Ruby to assemble HTML, CSS, and JavaScript files from component files (often adding content from a database). A software program written in Ruby and organized using Rails conventions is a “web application.”
Why use a web application server? A web browser needs only a single HTML file to display a web page (CSS and JavaScript files are optional). However, if you are creating several web pages, you might want to assemble the HTML file from smaller components. For example, you might make a small file that will be included on every page to make a footer (Rails calls these “partials”). Consider another example: If you are displaying content from a database, you might not want the complex programming code that accesses the database mixed into your HTML (programmers call this separation of concerns and it makes for more modular, maintainable programs). Finally, if you are using a web application server such as the one supplied with Rails, you can add features to your website that have been developed and tested by other people so you don’t have to build everything yourself. These are all reasons to use a web application server.
Those are the basic concepts. Now let’s examine Rails more closely.
To understand Rails better, let’s take a look at different aspects of a Rails web application.
Like the blind men encountering the elephant, you’ll understand Rails better by examining it from six different perspectives.
As we’ve seen, from the perspective of the web browser, Rails is simply a program that generates HTML, CSS, and JavaScript files. These files are generated dynamically. You can’t see them on the server side but you can view these files by using the web developer tools that are built in to every browser (choose the menu item “Web Developer Tools” in Google Chrome or “Web Developer Toolbar” in Firefox).
What do you see on your computer if you are looking at a Rails application?
You’ll see a set of files that you can edit with your text editor to create your web application. The files are organized with a specific structure. The structure is the same for every Rails application; this commonality is what makes it easy to collaborate with other Rails developers. To use Rails, you must learn about this structure and the purpose of each of the folders and files.
Here is how Rails files are organized:
+-app | +-assets | | +-images | | +-javascripts | | +-stylesheets | +-controllers | +-helpers | +-mailers | +-models | +-views +-config +-db +-features +-lib +-log +-public +-script +-spec
The Rails file structure exists for the convenience of developers. “Assets” such as images, CSS stylesheet files, and JavaScript files get their own folders. Other folders are a place for configuration files (“config”) and testing files (“features” and “spec”) As you investigate the Rails file structure, you’ll see other folders that don’t have an evident purpose. For example, the folders for “controllers,” “models,” and “views” are important but may not have an obvious function. These folders correspond to a more abstract organizational system, one imposed by software architecture.
From a coder’s perspective, we can say that Rails is a set of files organized in a specific way. We use text editors to edit the files to make a web application. But what’s in the files?
The contents of the files (particularly the files written in the Ruby language) are organized according to a higher level abstraction we call “software architecture.”
Software is purely conceptual; it takes shape as text files but it comes into being in the mind of programmers. Aside from certain features that are required by computer design (programs must read strings of characters from filesystems), a software program can be a conceptual abstraction that is absolutely unique to the mind of its creator. In practice, most programming languages impose a standard set of abstractions that reflect the common needs of most programmers. We keep lists with an abstraction we call an array; we perform an operation on each element of an array with an abstraction we call an iterator. Every programming language documents these basic abstractions in a language reference (for example, see the Ruby API).
In Ruby (as in many other object-oriented languages), an “object” is the fundamental abstraction which is the basis for all other abstractions. Ruby tutorials say, “In Ruby, everything is an object,” and then show that all objects have state (data or “attributes”), behavior (procedures or “methods”), and identity (unique existence among all other objects). Objects are described with a class definition that describes attributes and methods; objects are used by a program as instances that have identical methods but differing data. Ruby provides a standard syntax for defining classes, creating instances, and calling methods.
At a higher level of abstraction, programmers find that code can be often be optimally organized according to patterns that other experienced developers will recognize. Code is easier to write when it fits a pattern you’ve encountered before; it’s easier to analyze and understand code that another programmer has written if it matches a widely known software design pattern. One example is the Model–view–controller pattern that is fundamental to organizing Rails applications. Though the MVC pattern is enshrined in the file structure of a Rails application, it also exists in the form of a hierarchy of Rails classes, notably ActionController (controller), ActionView (view), and ActiveRecord (model), which are Objects that can be subclassed to be used as components of your web application.
From the perspective of a software architect, a Rails web application is organized as a hierarchy of classes defined by the Rails API.
So far, we’ve seen how a web application is organized from the perspective of a web browser, the filesystem, and software architecture. There’s a temporal perspective that is just as important. Every software development project has this temporal aspect; it’s not unique to Rails, but it’s important to understand if you are going to do development with Rails.
A web application is developed over time; often we make mistakes and need to roll back to a previous version of our work. Computers are data storage machines as much as they are machines for manipulating or communicating data. However, the original concept of a computer file system didn’t allow for travel backward in time; files in disk storage preserve only the most recent version of your work. As programmers, we’ve had to add version control systems (sometimes known as revision control or source control systems) to recover earlier versions of our work.
There are several popular revision control systems; git is used most often by Rails developers. The metaphor of computer folders and files is easy to understand, at least for people who have worked where 20th century office supplies are still used. Git doesn’t offer any similar real-world metaphor which means it is much more difficult to understand how it works. Nonetheless, you must learn to use git if you intend to build more than the simplest Rails application.
Superficially, you can think of git as a series of snapshots of the your project’s filesystem. You can save a snapshot at any time with a “git commit” command in the Terminal. Then you can recover files from that snapshot.
Git is important not just for backing up and recovering files (after all, backup software such as Apple’s Time Machine can do that). You can use git with GitHub for remote backup of your projects. More importantly, git and GitHub are the primary mechanisms for collaborating on Rails application development, whether open source or proprietary projects. You will use git and GitHub constantly on any real-world Rails project.
Strictly speaking, git and GitHub are not part of Rails (they are tools that can be used on any development project). But Rails and the gems that go into a complex web application would not exist without git and GitHub so it’s important to recognize the essential role of these tools as part of a Rails project.
From the time traveler’s perspective, we can say that a Rails project is a series of snapshots of files stored in a git repository.
You read earlier that Ruby’s key advantage is RubyGems, the package manager that makes it easy to create and share software libraries (gems) that extend Ruby. Rails is popular because developers have written and shared so many gems that provide useful features for building websites.
We can think of a Rails application as a collection of gems that provide basic functionality, plus custom code that adds unique features for a particular website. In fact, when a developer begins work on an existing Rails web project, he or she will often first investigate what gems are used by the application.
Every Rails application has a Gemfile in the application root directory. The Gemfile lists each gem that is used by the application. The Gemfile is used by a utility program (named Bundler) that adds each gem to the Ruby programming environment. Some gems are required by every Rails application, for example, a database adaptor that allows Rails to connect to databases. Other gems are used to make development easier, for example, gems for testing that help programmers find bugs. Still other gems add functionality to the website, such as gems for logging in users or processing credit cards.
The art of selecting gems is one of the skills of an experienced Rails developer. There are gems that are recommended by Rails original creators (notably, David Heinemeier Hansson). Skilled developers often replace these “official” gems with alternative sets of gems that have gained popularity more recently. Knowing what gems to use, or why, is an aspect of learning Rails that is seldom explicit.
As you learn more about Rails, you’ll learn about the gems that are most frequently added to Rails projects.
Among development platforms for the web, Rails uniquely includes a “baked-in” test framework. This reflects the platform creator’s commitment to a methodology of software development known as Test Driven Development (TDD). Though test driven development is optional, not required, for any Rails development project, it is so often used (and expected) that we can’t fully understand Rails without considering the tester’s perspective.
Software is always tested. Sometimes only by its users (who don’t know they are guinea pigs) but more often (and more responsibly), before it is released. Historically, on large corporate software projects, a quality assurance process might involve a team of engineers systematically testing every feature of a software product from the point of view of the user. To the QA team, integration testing meant every component was tested to work when assembled together. Acceptance testing, which can be the same as integration testing, meant the team evaluated the product to make sure it performed as described in a requirements specification. In this context of large enterprise software projects, QA testing was something of a software engineering specialty and automated testing was part of the practice, since it often was practical to write software programs to test software programs. If a testing regimen is thorough, automated testing will include unit tests, small test programs to test discrete parts of a software program, in isolation from the rest of the program, often at the class or method level.
Testing serves several purposes. First, it improves the user experience by finding problems before the product is released to customers. Second, it provides oversight for managers, as a verification that the project has been implemented as specified or promised. However, to a software engineer who is skilled at writing tests, the function of testing in the service of quality assurance is often secondary to testing as a method of programming. Instead of tests simply verifying that what you’ve written works, tests can become an integral part of the programming process. Rather than writing unit tests after you’ve written a piece of code, you can write your tests first. This is the essence of Test Driven Development. It may seem odd, or time-consuming, but for a skilled TDD practitioner, it brings coherence to the programming process. First, by writing tests before a writing a specific implementation, the developer will give thought to what needs to be accomplished and think through alternatives and edge cases. Second, by writing tests before writing implementation code, the developer will have complete test coverage for the project. Software products typically contain much hidden interdependency. With good test coverage, programmers (especially those on a team) can rip out and replace code to change features and (just as important) can refactor code, rearranging code to be more obvious or more efficient. Running a test suite after refactoring provides assurance that nothing inadvertently broke after the changes.
Just as writing unit tests can bring coherence to writing portions of a software application, the overall process of developing an application can be improved by writing automated acceptance tests before implementing any parts of a project. Behavior Driven Development (BDD) is similar to Test Driven Development but focuses on writing specifications for a project in the form of descriptive stories that can be the basis for automated acceptance tests.
Before Rails, automated testing was rarely part of web development. A web application would be tested by users and (maybe) a QA team. Rails introduced the discipline of Test Driven Development to the wider web development community. Behavior Driven Development is less commonly used on Rails projects (less so among startups, more frequently among consulting firms and enterprise projects) but TDD is common and seen as a necessary skill of an experienced Rails developer.
Would you like to get started learning Rails? See recommendations for a Rails tutorial to suit your skill level and learning style.