Since so much of the publishing ecosystem is becoming more and more web-based every day, it helps even those who aren’t strictly on the tech side to understand the fundamentals about how Rails works.

Ruby on Rails—or just “Rails” for short—is my web development framework of choice.

If your job has anything to do with the Internet—which if you’re reading this it does—then you’ve likely used a Rails application already today. Groupon, Airbnb, Shopify, Bloomberg, Indiegogo and hundreds of thousands of other websites are all written in Rails.

As a mature framework, Rails has a thriving open-source ecosystem of developers, so if someone’s pitching a new web product to you, for instance, there’s a good chance they’ll be pitching a Rails app.

Simple websites whose data rarely change don’t need sophisticated frameworks like Rails. You can just write plain old HTML in a text file and upload it to your web server. If, however, you’ve got an interactive website where the data change a lot, or there’s a lot of data to start with—and these days there is—then a static HTML page won’t work. You’ll need a database to store the data in, a way of accepting inputs from users and the ability to display different data depending on what the user types and clicks.

Enter Rails: a set of conventions, written in the Ruby programming language, that makes writing complicated websites less complicated.

A Rails app is a set of files in folders, just like you’d see in Finder on Macs or Explorer on PCs. Rails apps are all organized the same way—into folders called models, controllers and views. What follows is a quick, guided tour through each one, plus a zoomed-out look at what publishers should understand about the broader system as they continue to develop their web presences.

Models

Model files are the engine rooms of a Rails app. They are where the objects of the application are defined and where business logic is stored.

Methods

Say you’ve got an online bookshop, and you want to display all your ebooks, rather than print books, on a single page. You’d write some logic in the model that would let the bookshop determine what an ebook is. In pseudocode:

The definition of “Ebooks” is: Books where the product_form is Digital

As a matter of fact, the real code is simpler. Want to see it?

1
2
3
  def self.ebooks
     where(:product_form => "Digital")
  end

(This code is in a file called “models/book.rb”)

Associations

Models are also where we establish the relationships among the objects that appear in the app. If you had a Book model, it can be related to a Price model like this:

1
  has_many :prices

(This code is in a file called “models/book.rb”)

1
  belongs_to :book

(This code is in a file called “models/price.rb”)

So a book can have many prices, and a price belongs to a book.

Models talk to the database. When the data are all nicely stored in the right place, all of it becomes easily manageable, checkable and accessible—which tends to mean more sales and lower costs for you.

Controllers

Controllers are the busy command centers of a Rails app, taking instructions from the user, passing them on to other parts of the Rails app for processing, then delivering back the results.

So a user might enter their username and password to sign into their account on a website. The browser (Chrome, Firefox or similar) will send the username and password to the user’s controller file. The user’s controller, in turn, will hand over the data to the model and database, to check that it’s the right password, and wait for feedback.

Next, the model lets the controller know that all’s well. The controller can then hand the message back to the user’s browser, refreshing the page to say “you’re all signed in!”

Controllers, in other words, check to ensure that your app’s code is organized and optimized and that requests from the browser are dealt with accurately and quickly. Everyone loves a fast website, right?

Views

Last but not least, views are files that often contain a lot of HTML. They’re the bit of the Rails app that describes what the webpage will look like.

Have you ever done a mail merge in Microsoft Word? You have the bulk of the letter typed out, but when you want to put in a bit of dynamic data, such as a name or an address, you pop a placeholder tag in. When you run the mail merge, lots of versions of the letter get produced, with the right data magically appearing in the placeholder tags.

That’s what Rails views are like—some static HTML with bits of dynamic, changing data being swapped in and out according to what the model and controller tell it.

Which means you don’t have to write hundreds of pages of HTML for your hundreds of books. You write one template, and Rails fills in the data dynamically. Sounds like a time saver to me!

Design Patterns

Rails sensibly uses some tried and tested programming patterns. Patterns are ways of doing something that people have thought through and found to be a good idea. Here are two:

Convention over configuration: By sticking to a series of rules that govern the basic setup of a web application, Rails developers can avoid writing repetitive code and get to the good bit faster—the actual design and logic of a particular application brief.
DRY (“Don’t Repeat Yourself!”): We only write code once and reuse it. This makes code more maintainable. For clients, that means cheaper and, ideally, more scalable applications.

What It All Means

With such a regimented approach to code organization, Rails apps are great for teams because they provide a lingua franca. Everyone knows where to find the sort of code they’re looking for. So your project can be worked on by more than one developer or picked up by a new developer, and there’s no awful learning curve to figuring out one coder’s particular take on things.

Rails’s popularity and longevity (its first release was in 2004, an eternity ago) means there’s a phenomenal infrastructure built around it, in terms of the number of active developers; the number of code libraries it plays nicely with, such as jQuery (Javascript code that runs in web browsers, making the user experience smoother); and services such as Heroku, a “platform as a service” that makes deploying applications to web servers fast, cheap, robust and reliable.

Rails means developers can create complex websites, fast and cheaply. From publishers’ points of view, that means more bang per buck. And even for publishing professionals who don’t work in Rails or develop websites, simply understanding how Rails functions can be a great practical asset as the industry finds its footing in the online marketplace.

Are your current systems sabotaging your growth ambitions? Are you hungry to implement new business models, but concerned you lack the strong administrative foundations needed for innovation?

We're always amazed at how resigned publishers have had to become to the low bar in publishing management systems. Demand more.