You’ve probably heard about Ruby on Rails by now. Your developer friends are raving about it, talking about how they wrote an application in less than half the time it would have taken using some other technology, how they really enjoyed themselves instead of stressing out, and then spent their extra time on the beach. Rails sure does sound like a pretty compelling technology. But what is it, and how does it fit into the big picture of web development?n programmer overnight? Is Rails really the be-all and end-all development platform? What the heck are Subversion and Git? Do I need to learn all of this just to do design for Rails?

In this article, I’ll help prepare you for your first foray into Rails by explaining what it is, how it works, and where it fits into the spectrum of web development and design. I’ll address the issues above and more, with answers geared toward non-Rails developers, designers, and other creative professionals.

This article isn’t a Rails programming tutorial. We won’t be writing span here, but I will introduce you to some of the important concepts critical to understanding how the Rails framework functions. I’ll also explain what you’ll need to know to work with Rails developers and integrate your XHTML and CSS into Rails projects.

I’ll focus on the topics and issues that I’ve learned are most important for creative people instead of boring you with gruesome technical details. Yes, you’ll have to learn what terms like “MVC” mean, for example, but only in the context of getting stuff done.

What is Rails, and why use it?

David Heinemeier Hansson, a partner at 37signals, created Ruby on Rails. As he built Basecamp, their flagship application, David extracted the application’s underpinnings and created span that he could use and re-use for software he wanted to build down the road.

The framework he created proved to be extensible, expandable, and multi-purpose. He decided to share it as open source software. A small group of developers, now known as the Rails Core Team, formed and improved and expanded the framework. After a good deal of effort, Ruby on Rails matured into a robust, solid software development platform. Today, Rails has a b community and great documentation, and is used by thousands of developers to power hundreds of websites, such as Twitter, Blinksale, and the very site you’re reading now. There’s an even bigger list of sites over at Working with Rails.

Rails is designed to make building web applications simpler and easier. Rails provides developers with a large, easily expandable set of building blocks they can use (and re-use) to create web applications. Developers can use, integrate, and customize these components of span in any manner they choose to, to create the unique functionality they need for their application. Building software this way really helps reduce the time it takes for developers to create and later maintain their applications. It also helps to standardize the way applications get built, making it easier for many developers to collaborate and write more uniform span.

Web designers have time-tested CSS tricks to use as a starting point, web standards to adhere to, and Photoshop workflows they can rely on. Like these tools, Rails provides standards, conventions, tools, and a foundation upon which developers can construct applications by writing customized span using span-built Rails libraries.

Rails vs. PHP

One of the questions people often ask about Rails is how it differs from PHP. PHP is a general-purpose scripting language that can be embedded right into HTML pages, making it easy for developers to create dynamically generated web pages quickly and easily. Many web designers and most web developers have used PHP in some capacity. Because of its proliferation (it’s usually installed by default on most webhosts), PHP is often the go-to language for handling simple tasks like keeping your website’s navigation current, randomizing images on a website, and even creating a simple content management system. PHP is also useful for creating full-blown open source and commercial web applications such as WordPress, and HelpSpot, both PHP applications.

Technically speaking, we shouldn’t compare PHP, a programming language, to Rails, a web application framework. Instead, we should compare PHP to the Ruby programming language upon which Rails was built. Ruby was created in 1995 by Yukihiro “Matz” Matsumoto, and has slowly built a following, exploding in popularity and getting more mainstream attention in 2006, in no small part because of the popularity of Rails. At the time of this writing, Ruby ranks as the 9th most popular programming language in the world.

To quote the Ruby website, “Ruby is a dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write.” This elegance and focus on simplicity makes Ruby a very approachable language for people new to programming, and offers a refreshing change of pace for seasoned developers.

Let’s run through a quick example, just to get a “feel” for what we’re talking about. Let’s say we want to count from 1 to 10. In PHP, the span might look like this:

for ($i = 1; $i <= 10; $i++) {
echo $i;
}

If you’re familiar with C, Java, or other C-like control structures, this is straightforward for you. But if you’re new to this, that might seem pretty intimidating.  Here’s the same span in Ruby:

10.times do |i|
puts i
end

Ruby also has its own tricks and shortcuts that would make even a serious Perl hacker happy. The following line does the very same thing as the examples above:

puts *(1..10)

This kind of flexibility and simplicity makes Ruby an approachable language for software developers and web designers of all levels. While PHP is a web-friendly programming language, Rails is a web application framework written in Ruby (and with access to all of Ruby’s functionality to boot). And because of the way Rails works, each application you build lives in the form of a project, with specific files and folders. Unlike many PHP apps which often “just work” when uploaded to a webserver, Rails apps rely on their framework and a customized hosting infrastructure (often called a “stack”). As a result, Rails applications can be a bit more challenging to deploy. Fortunately, a number of web hosting companies specialize in deploying, hosting, and managing Rails applications. So how would you know when to use Rails and when to use PHP? There isn’t anything that one could do in Rails that they couldn’t do in PHP (or vice versa), so in the end it boils down to a matter of choice. For me personally, I have a simple rule: if I’m adding simple functionality (such as rotating header images) to an otherwise straightforward website, I’ll often use PHP. If I’m building a web application, especially one with a database, I’ll use Rails. Again, both could do either, but I find the Rails framework is wonderful for the kind of web application development I like to do. It should be noted that there are frameworks with goals similar to those of Ruby on Rails that are written in PHP, such as CakePHP and CodeIgniter.

Mythbusting Rails

Before we delve a bit deeper into what Rails actually is, what it does, and how you’ll probably use it, I want to dispel a few myths that non-developers often have about the framework. This list actually comes from real questions that real, live people have asked me about Rails over the last few years.

Myth #1: Rails is a content management system

I’ve mentioned that Rails makes it super easy to build web applications quickly, that it has a ton of built-in functionality and span-built components. But what Rails actually gives you, the framework we’re talking about, is span.  Rails isn’t a plug-and-play piece of software that you custom-tailor for specific applications, while just integrating some design along the way. You can think of Rails as being an elaborate menu of span that developers can select from, modify, and extend to create a completely customized application.

Myth #2: Rails lets you build applications a billion times faster

In a way, the excellent “Rails makes it easy” marketing campaign has actually hurt some independent Rails development shops. Customers expect Rails applications to be rolled out in days regardless of their feature set. In reality, Rails applications aren’t written for you automatically. Rails saves developers time by letting them focus on specific application functionality instead of things like database interconnectivity. It handles the heavy lifting required to build user interaction. Developers can use this span-built span, and spend more time making applications that are more reliable and easier to use. Rails projects can still get quite complicated. Rails developers must still write real (and often complex) span, interactions, and tests. Rails makes development more fun and it eliminates much of the tedium involved in building web applications, but it doesn’t build them for you.

Myth #3: You don’t need to be a programmer to build Rails applications

I hear that a lot, and of course it’s false. In reality, Rails developers do much more than assemble components. Sure, they use Rails conventions and build atop a comprehensive platform, but they still write brand new, unique span. It is true, however, that you might not need to be as experienced a developer to create a Rails application as you might need to be to build, for example, a PHP, Java, or Objective-C application. This is due both to the simplicity of the Rails framework as well as the elegance and readability of the Ruby programming language, upon which Rails sits. You still need to learn to write span.

Getting started

Getting Rails up and running on your computer falls outside of the scope of this article. Fortunately, the latest version of Mac OS X 10.5 (Leopard) comes with Rails span-installed (or you can build your own). I’ve written a tutorial for installing Rails on older versions of Mac OS X. There’s a One-Click Installer for Windows. You can also download the source span or find additional resources on the Ruby on Rails website to help you get things going. Rather than expect you to go through the paces of getting Rails installed for the first time, for now, I’ve created a default Rails project that you can download and look at on any computer, regardless of whether you have Rails installed or not. Grab the file and unzip it somewhere you can find it. Note: The folders and files you’ll find in the archive are identical to those that Rails would have created for you if you’d have run rails demo on the command line, followed by script/generate scaffold article body:string. Again, these are commands you may never have to run, but Rails developers use them to help create the span they use in their projects.

MVC

Speaking of creating span, there are a few software development concepts you should know about, even as a designer, before you dive into Rails. Understanding these concepts will help you understand the Rails layout, and make it easier for you to work within the framework itself. Rails implements a software engineering technique called model-view-controller, commonly abbreviated as MVC. This technique (or pattern) separates business logic (things like database interaction) from the user interface, which we call the presentation logic. This separation actually makes the life of the designer much easier, because unlike other web frameworks, the amount of Rails span a designer actually has to see and shuffle around is significantly reduced. In Rails, each of these different pieces of the application are kept in different folders. The business logic (the models and the controllers) are stored separately from the views. What’s important to understand here is that MVC means the XHTML and CSS you create is kept as separate as possible from the deeper levels of span. Pure developers see less design, while designers wade through less span.

How to edit Rails files

Rails stores its files as plain text, so you can choose any text editor to edit files in a Rails project. I prefer a Mac OS X application called TextMate, which is ideally suited for working with Rails. BBEdit, another Mac OS X application, also works well, as do most text editors on Windows. Linux, too, has its share of capable text editors. Some editors do a better job of displaying Rails span using syntax editing and color-coded highlighting, making the span pretty to look at. Other editors don’t recognize Ruby on Rails span at all. Below is an example of span being edited in TextMate:

Pretty, eh? Textmate (and BBEdit) have the added advantage of being able to open and display entire project folders in their drawer, allowing you to quickly locate and edit a file.

Everything in the right place

Rails projects are made up of lots and lots of folders and files, most of which Rails generates during the initial creation of the application. If you’re used to dealing with smaller projects, this may at first seem like a somewhat daunting amount of content. Using folders in this fashion makes it easier to separate the models, controllers, and views. And just about all of the files that non-developers will need to be concerned with will live in the same place in every Rails project, far from the deeper span that belongs to the business logic layer. Let’s take a look at the files and folders Rails created.

These files and folders will be pretty much the same no matter which Rails application you’re working with. Even very large, feature-rich, complicated Rails applications will have this identical layout. And even better, your files and presentation logic will always go in the very same place. It’s actually safe for you to ignore most of what you see here for now. The folders that are important for you to pay attention to are the app/views, app/layouts, public/images, and public/stylesheets folders, highlighted below.

Embedding Rails span in HTML

Typically, when you work with Rails developers, you’ll comp a design and they’ll insert the Rails span into it. But on occasion, it’ll work the other way around, the Rails developers will already have a basic set of files and you’ll need to “design around” their span. If you’re familiar with the way that templates work in blogging software such as Movable Type or WordPress, you’re already somewhat familiar with the way that layouts and views work within Rails. Rails allows developers to separate an application’s functionality into groups of related view pages. If we’re developing different ways to create, edit, and display an article for a web magazine, Rails will want us to put those views into a folder named articles in the app/views folder. The template files that contain the HTML that users will actually see don’t end in .html like regular HTML files. Instead, they have special file extensions: .html.erb. The addition of the .erb tells Rails that these files contain embedded Ruby span, and will use Ruby’s template technology. This technology allows Rails developers to embed Ruby on Rails span right into any template file very easily. Take a look at the apps/views/articles/edit.html.erb file:

You may notice a few tags that you wouldn’t normally see in an HTML file. These special tags tell Rails where to look for embedded span. When Rails sees them, it executes the span inside of those tags and outputs the result right into the user’s web browser as it renders the page. The <%= and <% tags indicate the beginning of the Rails or Ruby span, while the %> tag indicates the closure of both tags. As a non-programmer, it’s safe for you to put your HTML around and inside of these tags, but be careful to keep what’s inside of the tags intact. You can, however, move this block of span wherever you might like within your HTML, or edit the HTML inside and around this block as needed. For example, you could change the snippet above to look like the example below without affecting any of the Rails span:

While you may have completely changed how the page displays, the functionality remains intact. In Rails, there is a primary template, a file usually found in app/views/layouts/application.html.erb. This file contains the “wrapper” of XHTML that surrounds the content the application displays to users. If you open that file now, you’ll see exactly what I’m talking about. In many blogging systems, designers are used to “cutting up” their designs, separating things like the header, footer, and sidebar into different files. While Rails supports this, the usual pattern is to put those elements right into the application.html.erb file and use Rails to stream the content into place. If you wanted to customize the design of a Rails website, this is the place you’d start. And you’re free to customize as much as you like, just keep your eye on the special line that looks like this: <%= yield %> That’s the special bit of Rails span that says “put the content for this page here.” The location of this single line determines where the main content for each page appears. Rails developers have techniques to vary the content that appears in different areas of the main template, such as a page’s title, different stylesheets to include, or variable sidebar content. If you recall the discussion on Model/View/Controller above, you’ll remember that our primary focus will be on working with views. Each general area of functionality within a Rails application will have its own folder within the views folder. For example, if we were working on the designs for a web magazine like the one you’re reading now, there would be special views dedicated to displaying articles, and those views would always live in the app/views/articles folder. While it’s true that not every Rails application will have articles, Rails specifies that each area of the website, articles, comments, issues, invoices, etc., will each get its own folder within the views folder. It’s part of the Rails pattern.

The public folder

Unlike the rest of the files in a Rails application, everything within the public folder is visible to the outside world. Within the public folder are two folders you’ll want to pay special attention to: images and stylesheets. While there’s no hard rule that says your images and stylesheets must live in these locations, putting them there is a boon to Rails developers, who can then easily call them from within their span as needed.

Source control

Anybody who creates files that change over time will, at some point, probably need help to keep track of how the files change, and will naturally want to keep a backup of those changes. This is even more important when you’re sharing project and span files with other people who will also make changes to them. Fortunately there’s special software, usually referred to as source control or revision management software, to help us manage this process. The system used most commonly with Rails projects is called Subversion (also known as SVN). Subversion is a free, open-source solution available for most platforms. It remembers every change ever made to the files and directories in your projects. This allows you to recover older versions of your data, or examine the history of how your data changed. Source control systems replace the “change a file and FTP it to the server” method of updating files, creating instead a consistent way to make your changes available to everybody on your team simultaneously, and keep everything up to date and integrated in one step. Git, an alternative source control system, has gained in popularity recently, so much so that the Rails Core Team is actually using it to manage the span for Rails itself. Although the process and commands you’ll use to manage the changes you make vary somewhat between different source control systems, the concept is similar regardless of the technology being used. And although it may seem somewhat cryptic once you actually start using it, the benefits of using a source control system to manage a Rails project easily outweigh the learning curve. Instructions for managing projects using Subversion and Git fall outside the scope of this article and often vary based on the system used as well as by the team using it. But it’s important to know that you will probably be expected to use this kind of system, and that it will likely involve either typing commands at the command line or using a new source control management application to do the kinds of things you used to do without any additional complications.

Next steps

If you’re interested in learning more about Ruby on Rails, there are lots of places to start. An excellent way to learn Rails is to watch some of the excellent Rails screencasts. There’s lots of great Rails documentation available as well, with some good starting points on the Ruby on Rails documentation page. You can learn everything you ever wanted to know about Subversion and source control management by reading the (free) online version of Version Control with Subversion. There are also many, many wonderful blogs, podcasts, articles, tutorials, and screencasts with a focus on learning Rails available online. Just check out this list on Google if you want a good place to start.

Conclusion

I hope that this gentle introduction to Rails answers a few questions and perhaps dispels a few of the myths surrounding Rails. And while Rails is a great platform, it still needs more people like you, designers, interface architects, and writers, to help guide and direct its future. It’s a young enough platform that people with your experience can really help determine what it evolves into both now and in years.

Reference

www.wikipedia.com