Category Archives: Rails

Rails lets us focus on the hard stuff




What’s the hard stuff?

Here’s what shouldn’t be hard when first building an application:

  • Accounting for low-bandwidth connections
  • Supporting a wide array of browsers
  • Implementing a test framework and writing tests
  • Choosing and configuring build tools
  • Setting up a database
  • Setting up hosting
  • Adding basic security (CSRF protection, user authentication)

Here’s what should be hard:

  • Creating a great user experience
  • Making sure the features make sense for the intended customers
  • Defining a data model that makes sense
  • Writing maintainable code




Rails’ nice surprises


My reservation platform loaded quickly. Navigating the app was zippy.


A time and a place





Run Rails migrations automatically on Heroku





A (very) quick walkthrough




A case for decorators in Rails



A particular use case sold me on decorators’ benefits.

Use case: default field values

TourExec is a Rails app that helps businesses take reservations online.


Screen Shot 2016-08-06 at 7.13.49 PM



Option 1: Use conditionals in views


- if @business.intro.present?
  = @business.intro
- else


Screen Shot 2016-08-06 at 7.18.33 PM


- f.input :intro, value: (
  (@business.intro.present? && @business.intro) ||

This felt messy and unclear.

Option 2: Use the model


# app/models/business.rb


def intro


Option 3: Use a decorator



# app/decorators/business.rb

class BusinessDecorator < Draper::Decorator

  def intro
    if object.intro.present?
      "Book a tour with #{} below!"



@business =


= @business.intro

And I have to do absolutely nothing to my form helpers:

- f.input :intro

Decorators won!


More about decorators

Decorators can do a lot more, like:

  • Show a date field in a particular format throughout your app
  • Show a status field with particular language throughout your app


Separation in a Rails monolith: layouts, assets, and controllers






Multiple layouts

The public section of TourExec is pretty minimal:

Booking a reservation on TourExec

Admin has a fuller layout, with a navigation bar:

Admin section of TourExec


Create two layouts

  • app/views/layouts/admin.html.haml
  • app/views/layouts/public.html.haml

In each of your controllers, specify which layout to use


Use multiple JavaScript manifests


Separate the default manifest


  • /app/assets/javascripts/application.js

TourExec has two:

  • /app/assets/javascripts/admin.js
  • /app/assets/javascripts/public.js



Tell Rails to precompile both manifests


Update your layouts to use each manifest

Our admin layout uses:

Our public layout uses:


Separate styles?



Namespace controllers


Here is a preview of the structure:

  • ApplicationController
    • AdminController
      • Admin::ToursController
    • PublicController
      • Public::ToursController



Starting with a monolith



Consider Turbolinks 5 for your next Rails project






Consider it, every time

You should strongly consider Turbolinks 5 for any new Rails project.


Why consider Turbolinks now?



Booking a tour





Pairing Turbolinks with a JavaScript MVC




The trade-offs





  1. Add new users to a mailing list
  2. Send a welcome e-mail to new users
  3. Alert users when something happens in the app


Mailing lists vs. transactional e-mails


Mailing lists





Events might include:

  1. The customer was billed.
  3. A charge to the customer’s credit card failed.









This generates a new job:






Sitemaps in Rails, in five minutes

Not every web app needs a sitemap, but in certain cases having one can significantly improve your visibility on Google.

For instance, you might have pages that are hard to find, or that you haven’t entirely exposed to the public. You might be a brand new site that wants to get indexed as quickly as possible.

Read over Google’s reasons for having a sitemap. Take it from the authority on the matter, the ultimate “SEO expert.”

If you’re on the fence, go with a sitemap. Google states that “In most cases, webmasters benefit from sitemap submission, and in no case can you be penalized for it.”

Don’t you love the word “webmaster”?

Adding a sitemap to a small-to-medium size Rails app is a breeze. Here’s the how-to:

Step 1. Create a view for your sitemap

Your sitemap is going to be a plain old Rails view, albeit one in XML format. Below are examples in HAML and ERB.

HAML (haml-rails gem required):

A couple of important notes:

  • We’re using the post_url helper, not the post_path helper, because we need absolute URL’s in the sitemap.
  • Obviously, replace post with whatever model(s) holds the stuff you want in the sitemap.
  • If your site heavily features images and videos that you want indexed, add media metadata to your sitemap.

Step 2. Create a controller

The view above uses the @posts variable. It needs to get that from a sitemap controller:

Step 3. Add a route

Step 4. Test it out

This very simple test ensures that the sitemap is basically working, and exists mainly to ensure it doesn’t get broken in the future.

For real sitemap validation, see the next step.

Step 5. Test your sitemap and submit it to Google

Register your site on Google Webmaster Tools.

From there, you can validate and submit your sitemap for crawling.

At the end, you should see a count of the URL’s in your sitemap. You’re done!

Sitemap submission confirmation


The sitemap above is generated on-the-fly as search engines request it. If your site is particularly huge, you could generate the sitemap on a schedule. This certainly complicates things, but there are gems to help: sitemap_generator, for instance. I evaluated these but found they added too much overhead to the deployment and maintenance processes for a medium-size app.

Inspired by this Stack Exchange answer

React JS and Flux in Rails, a complete example

I recently wrote about real-world results with React JS. Here is a concrete example of adding React to a Rails app, start to finish.

React JS is a library from Facebook that powers user interfaces. It is simpler, faster, and less opinionated than many JavaScript MVC frameworks, making it easier to bring into an existing app. Start by reviewing our recommended React resources, then check out an example below.

The example

At Cook Smarts, we want recipes to be consistent, so we provide administrators with suggested ingredient names. That way, a red bell pepper is always called a red bell pepper.

Suggestions are populated from previous recipes automatically, but they need to be pruned by an administrator to make sure they’re accurate.

The app needs to provide an Excel-like way to quickly prune suggestions.

React JS, in under 150 lines of readable code, gets us exactly what we need, an Excel-like data editor.

Editing ingredient suggestions


The example below relies upon Ruby on Rails, the react-rails gem (latest stable version), and Fluxxor (added to the app’s JavaScript manifest).

Our server actions in Rails

A Rails controller provides JSON data to the view and processes edits and deletions to the database.

Our data model in Fluxxor

A typical React implementation includes a data model, or store, which manages data and the actions that can be taken on the data. At a Cook Smarts, we use Fluxxor,  inspired by Facebook’s Flux concept.

A JavaScript object holds our store and defines the actions that the store will take (renaming and deleting ingredients):

The object contains the store itself, instantiated through Fluxxor’s createStore method.

The object also contains the store’s actions, which communicates with the simple API we defined in the Rails controller:

Finally, the object includes a method for creating a Flux object containing the store and its actions. The Flux object is passed to the React-based UI in the next section.

Read more about Fluxxor and how it helps you easily define data models that play well with React. For more on the concept, check out Facebook’s Flux overview.

Our UI in React

So far, we have covered the server-side API and the client-side data store. We still need to build our client-side UI, and that’s where React comes in.

React apps are basically component trees. The ingredient suggestions editor contains multiple ingredient suggestions,, so our component tree at its simplest is:

  • IngredientSuggestionsEditor
    • IngredientSuggestion
    • IngredientSuggestion
    • IngredientSuggestion

The IngredientSuggestionsEditor component is the parent, and watches the Flux store for any changes (see code comments):

The component above renders an IngredientSuggestion component for each ingredient. The IngredientSuggestion component shows the name of the ingredient and allows the user to edit it (see code comments):

Tying it all together

All of the code above is in a global JavaScript function that we call from our Rails view.  That function spins everything up and renders the UI to the page. Global functions aren’t ideal, but Rails’ asset pipeline leaves us with few other options. While a bit inelegant, this approach works well in a Rails app.

The global function creates the Fluxxor store and renders React components to the page. Here is its code, excluding the snippets we’ve already covered:

The Rails view containing the suggestion editor runs the global function on page load, passing all the ingredient suggestions in JSON format, which we passed to the view from the Rails controller:

Here’s the full code for the Rails controller, Rails view, Fluxxor store/actions, and React components.

In the future it will only get easier to connect React and Rails, with a new 1.0 version of the React gem in the works. At Cook Smarts, we use the latest stable React gem and include Fluxxor in the app’s JavaScript manifest.

React allowed us to get a client-side interface up and running in a couple of hours.  React presents few surprises and operates consistently. It’s no wonder that it powers much of Facebook and Instagram, two sites that have to work for a wide array of users.

Avoid the N+1 problem in Rails by harnessing your database

The #1 cause of slow apps may be the N+1 problem, where the app queries a database over and over again to get information about a list of items.

To avoid this, learn the powers of your database so you can query it more efficiently.

Say that you have an app to manage meetings. When someone creates a meeting, there is a standard checklist that they must complete.

The standard checklist items, which are the same for every meeting, are stored in the Checklist table. When someone checks off an item for a particular meeting, that action is stored in Checklist Checked Items table.

Here is the database structure and the sample records we’ll use in this example. For the only meeting in the database, the user has completed two of the checklist items.


  • id: 1, title: A Meeting


  • id: 1, title: Book meeting location
  • id: 2, title: Arrange catering
  • id: 3, title: Invite people


  • id: 1, checklist_item_id: 1, meeting_id: 1
  • id: 2, checklist_item_id: 2, meeting_id: 1

Say you want to retrieve, for a given meeting, the checklist items and whether each has been checked. You want any checked items to appear at the end of the list.

Here is the app-centric way to do that:

  1. Query the checklist items
  2. Loop through the checklist items, and for each, query the checked items to see if it’s been checked for that meeting
  3. Place each of the items, and whether it’s been checked, in an array of hashes
  4. Sort the array of hashes to place checked items last

This is inefficient and presents the N+1 problem, with step 2 producing multiple queries that will only increase in number as your app grows. Furthermore, there is an unnecessary array middleman and a sorting operation on that array.

Here is the database-centric way:

  1. In one query, get the checklist items, whether each is checked, sorted by whether each is checked.

That’s right, one query has replaced many, and the databsae is doing all the work.

The secret lies in Postgres’s CASE function, which lets you insert conditional logic into queries.

Here, we join checklist_items and checklist_checked_items a checked field that shows whether the checklist item is checked for that particular meeting:

Or, using ActiveRecord:

This returns the checklist items and whether they’re checked, with checked items last:

  • title: Arrange catering, checked: false
  • title: Invite people, checked: true
  • title: Book meeting location, checked: true

By understanding Postgres’s CASE function, we were able to replace many queries with one, speeding up our app.

This is just one example of how your database can take the burden and handle it better. Read your database’s documentation to discover more.

Further reading: