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.

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.

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.


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.


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?

  def self.ebooks
     where(:product_form => "Digital")

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


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:

  has_many :prices

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

  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 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?


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.


    Most popular

  1. Ruby code and why you should care
  2. A quick look at data visualisation and analysis
  3. Menial publishing jobs are destroying our future
  4. It's us in the industry who need to be able to code
  5. A manifesto for skills
  6. Learning how to code, the long way around
  7. Company news

  8. New website
  9. 2018 Customer survey report
  10. 2017 in review
  11. Sara O'Connor to join the team!
  12. And now we are five
  13. Prizes galore
  14. Product news

  15. 'Continuing to solve real problems': Futurebook 40, London Book Fair 2018 and the Works page
  16. How many authors is too many?
  17. Better ONIX fragments
  18. Advanced advance information!
  19. Schedules page
  20. Publishers hack their own bibliographic data
  21. Case studies

  22. Burleigh Dodds Science Publishing
  23. Zed Books
  24. IOP Publishing
  25. Code

  26. A publisher’s guide to APIs
  27. What publishers need to know about Ruby on Rails
  28. How APIs can make publishing more efficient
  29. A day in the life of a programmer
  30. eCommerce

  31. To go direct, publishers must mean business
  32. Don’t outsource your publishing business away
  33. Who has the balance of power over data?
  34. Inbound marketing
  35. The business case for going direct
  36. Why publishers must use direct sales
  37. ONIX

  38. A hidden benefit
  39. Thema Subject Codes Update November 2017
  40. ONIX. Not very standard
  41. Three ways to do more with ONIX
  42. A non-technical, beginners’ guide to ONIX for Books
  43. ONIX Changes
  44. BIC, Thema and artificial intelligence...
  45. How to create a catalogue automatically using ONIX and InDesign
  46. Skills

  47. Embrace the code
  48. Mechanical sympathy
  49. Publishers can learn a few things from programmers
  50. A taste of code
  51. Strategy

  52. Rejuvenation
  53. Why ‘easy’ publishing solutions hardly ever are
  54. The right tool for the job
  55. No computer system can fix a broken publisher
  56. Five things I've learned since moving into enterprise product management
  57. Managing expectations
  58. Start with Why – How to refine your publishing mission
  59. The real price of a strategy shift
  60. Technical debt
  61. Decisions, decisions
  62. Creative industries and the division of labour
  63. A company of one's own.
  64. Responsibility, Authority, Capability
  65. Sometimes, size matters
  66. The search for publishing's holy grails