Category Archives: Services

Run Rails migrations automatically on Heroku

Heroku has a beta feature called release phase that allows you to run commands automatically when you deploy your app. The commands run in a separate process before your app is made available to users.

The most common use case for Rails developers to is automatically run database migrations on deploy.

There are other ways to auto-run migrations. In the past, I’ve done this in CI. Release phases are generally better, since they run migrations before your app is available to users. This way, you avoid serving your new release while migrations are still running.

This is awesome for handling failed migrations. If a migration fails, the new release is aborted without impacting users. Because Rails migrations operate within a transaction, your database will be just as it was before the failure.

A (very) quick walkthrough

Just about every app on Heroku has a Procfile at its root. Here’s what a typical Procfile with release phase looks like:

That’s. It. Migrations will run automatically each time you deploy, before the new release is available to users. This is Heroku at its seamless best.

So, if you have a Rails app on Heroku, check out release phase!

E-mail in Rails with MailChimp and Mandrill, a comprehensive guide


This tutorial walks through adding e-mail to a Rails app, using MailChimp and Mandrill. We will:

  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

Our example app is Puppify, an aggregator of cute puppy videos. Read the tutorial, and then check out the source.

Mailing lists vs. transactional e-mails

It is important to distinguish your app’s mailing list from its transactional e-mails. Generally, a mailing list is used for periodic announcements and marketing e-mails, while transactional e-mails are used to notify individual users of specific events.

Mailing lists

Mailing lists handle messages sent to all or many of your users. For instance, you might send a monthly update about new features, or promote a sale on gift certificates.

MailChimp is a popular tool for managing mailing lists. It’s free for many smaller lists.


Transactional e-mails are sent to individual users in response to particular events.

Events might include:

  1. The customer was billed.
  2. A new video was posted to a category that the customer chose to monitor.
  3. A charge to the customer’s credit card failed.

When an action above occurs, we need to notify a particular user – or, as we cover in Advanced Transactional E-mail, multiple users.

Mandrill, from the folks at MailChimp, is a popular tool for sending transactional e-mails. It’s free for apps with low e-mail volumes.

Continue reading E-mail in Rails with MailChimp and Mandrill, a comprehensive guide

MailChimp and Active Job on Rails 4 – adding users to your mailing list in the background

When a user registers for your app, you might want to add them to your mailing list.  This normally takes a few seconds, as your app has to communicate with the mailing list provider. Still, the user should not have to wait, so we’ll immediately bring the user to the next page while subscribing them to the mailing list in the background.

Rails 4.2 offers Active Job, an easy way to define background jobs.

This example uses MailChimp for the mailing list and Devise for authentication, but Active Job does not depend on either. The example uses gibbon gem to communicate with MailChimp, and dotenv to store the MailChimp API key and list ID as environment variables on dev.

First, add a job for adding a user to the mailing list.

This generates a new job:

Next, customize the job to accept a user parameter, and subscribe that user to the MailChimp list.

Finally, in our user class, run the job after a new user is created:

Notice that we are passing the newly created user to the job, which then subscribes them to the mailing list.

Active Job is smart enough to realize that we don’t currently have a background job backend, so it performs the action right away, thus making the user wait. Once you add a backend, let Active Job know and you’ll have yourself a true background job. There are many backends to choose from, including Delayed Job, Sidekiq, and Resque,

Performing tasks in the background and eliminating delays for users has never been easier, thanks to Rails 4.2 and Active Job.

11 Essential Services for Rails Apps

Developing an app is never a solo effort, even if you are the only developer in a company. We live an ecosystem of services and open source tools that make development more rapid than ever before.

This article covers services and tools that are critical to most modern web applications.

1. Error handling

You need to be aware of any exceptions that occur in your app in production, as they generally indicate bugs.


Recommended. After you take five minutes to set up Honeybadger, it will alert you to any errors on your app, and allow you to easily browse through each time that error happened. Information with the error will generally tell you who was logged in at the time, so you can provide proactive support to your users.


Airbrake may be the dominant error reporting service, as it just acquired its competitor Exceptional. From my experience, Setup is not as simple as Honeybadger’s, and the interface is so minimal that browsing through the history of an error can be cumbersome.

2. Commerce

Stripe and Braintree offer customers a seamless purchase experience in your app, allowing you to sell one-off items and subscriptions. Both are customizable enough to be transparent to the customer, providing you with full control over the user experience.


Recommended. Stripe is extremely developer-friendly on its own, so can be used in quite a custom manner in your Rails app. Unless you use a Stripe partner, you will be writing custom code to interface with Stripe. Stripe Checkout can shave off time off front-end development.


Recommended. Unlike Stripe, Braintree offers PayPal integration and phone support. It has matched Stripe’s features including user interface elements that you can plug right in to your app. As of October 2014, Braintree is offering no transaction fees on your first $50,000 of transactions, which could save you around $1,500. Braintree has made Stripe less of a default choice than it was before. Be sure to compare both.

3. E-mail – transactional

Transactional e-mail is specific to a customer. It may include an invoice, an alert about the customer’s account, a summary of the customer’s recent activity, etc. Generally, the contents of a transactional e-mail is different for every customer.


Recommended. From the creators of MailChimp comes an extremely powerful service with generous pricing. Just plug in Mandrill’s SMTP information into Rails ActionMailer, or use Mandrill’s API to send a ton of messages at once. Mandrill offers robust logging, allowing you to see the full contents of recently sent messages. Its deliverability stats demonstrate MailChimp/Mandrill’s excellent record in getting e-mails to people. It is reliable and fast, churning through thousands of messages in just a few minutes (from my experience). Finally, it is free under a certain message limit, and very reasonable thereafter, particularly for MailChimp customers. Many apps will spend just a few bucks a month on Mandrill, if that.

Having transitioned a web app from Sendgrid to Mandrill, it is difficult for me to recommend anything other than Mandrill. Do check out SendGrid and Mailgun, though.

4. E-mail – mailing list

You may want to send all of your users, or particular subsets of them, updates on your service, promotions, and other marketing e-mails.


Recommended. MailChimp has strong libraries for Ruby and other languages lets you add, manipulate, and remove users from your lists easily. You can send custom information about your users, such as which plan they are on, to MailChimp, for targeting purposes.

Customer automation tools

Many apps have needs beyond simple mailing lists. You may want to segment customers based on their behaviors – for instance, reminding a customer to take a certain action if they haven’t already. Check out MailChimp’s newly revamped automation features.

If you need more advanced customer segmentation, check out AWeber and Infusionsoft. Other specialized offerings, like Drip, address niches like e-mail-based courses. With these three tools, be prepared to pay more for a small list than you would with MailChimp.

5. Storage

Generally, you should store static assets, such as your logo, in a separate location from your app. Certainly, you should store any user-submitted images in a separate location.

Amazon S3 + Carrierwave

Recommended. Amazon S3 provides a place to store static assets, such as images and attachments. In the simplest use case, you would manually upload images like your logo, and reference those from your views.

In a more advanced use case, you could allow users to attach images to items in the app, and dynamically upload those images to S3. For that, check out Carrierwave, which makes file uploads to S3 amazingly easy.  Also check out the Paperclip gem.

6. Database


Recommended. PostgreSQL is a relational database that enjoys wide adoption among hosting providers like Heroku and EngineYard, and recently introduced highly optimized JSON fields that support more free-form data. It’s a well-maintained, reliable, fast database that should do the trick for most production apps.  Check out how to get started.  If you’re on a Mac dev environment, use to set up a local Postgres server on dev.


MongoDB is a non-relational database suited to more fluid information like documents and “mashups” of data from multiple sources. Some use MongoDB to bring in data from relational database and present it in a different way, since it is so flexible.

Beware, though, that without the rules of a relational database, a MongoDB database is harder to govern, and bulk changes a bear. Consider Mongo if you feel the data you are storing would not be appropriate for a relational database, but be sure to check out Postgres’ new JSON features first.

7. Performance monitoring

New Relic

Recommended. New Relic tells you which methods in your app are running slowly. In many cases, it’s free to use, and you can always upgrade for more granular information. It will alert you to sudden slowness in your app, which is important as you scale. There’s no reason not to get started with a free account for a production app.

App Signal

App Signal, based on Europe, integrates error reporting and performance monitoring in a very clean interface. It’s worth checking out.

8. Code quality

Static analysis checks out your code to find antipatterns, or poor practices could make your app less efficient or more difficult to maintain.

Code Climate

Code Climate quickly finds the poorly-formed or inefficient Ruby and JavaScript code in your app, so you know what to refactor first. Then, it monitors your GitHub repo so you don’t regress.


Prefer to do it yourself rather than use a hosted service? Code Climate likely uses RuboCop for much of its analysis, and you can run it locally for free.

Ruby Science

This isn’t a service, rather a book, but it’s excellent reading that can help you address some of the issues brought up by Code Climate or RuboCop.

9. Authentication

Authentication these days still includes user names and passwords, but is quickly expanding to social sign-in through networks like Google, Facebook, Twitter, and GitHub.

Devise (+ optional Omniauth)

Recommended. The long-time gold standard for authentication in Rails app, Devise pulls its weight as a solution that is quick to implement but also very extendable. It supports user name and password authentication out of the box, and has built-in support for Omniauth to support social sign-in without much pain.


Clearance is for people who either, 1.) want very simple user name and password authentication and don’t envision going beyond that, or 2.) want to further control and customize the authentication in their app. Most importantly, it is easier to understand what Clearance is doing because it’s code is lighter. Without turnkey integration with Omniauth, Clearance makes it harder to integration social sign-in.

10. Hosting


Recommended. EngineYard’s support is exceptional, with e-mail and phone available no matter what plan you’re on. You know exactly what you’re getting, because your app and database are hosted on fully-fledged virtual machines with clear specs. You can deploy, manage backups, and spin up/down servers through a simple web interface, never touching the command line.


Heroku is conceptually interesting and powers a lot of Rails app. It uses an original concept called “dynos” to allocate your app’s resources and allow you to scale. This abstraction could be helpful, but many might prefer to work with the actual VM’s that EngineYard offers. You’ll most certainly be dealing with the command line, but Heroku’s tools are good.

I’m hesitant about Heroku’s support. You can’t pick up your phone and call them, like you can with EngineYard. Heroku’s default support plan has a “1+ day” response time,  while EngineYard offers a 30 minute response time around the clock for urgent issues. Both services offer enhanced support plans, but EngineYard’s built-in support appears to be better.

11. Backup

If you use a platform-as-a-service provider like Heroku or EngineYard, you’ll generally get backup in the package. Just be sure to use it!

There’s more I haven’t covered here, like continuous integration and deployment. It goes to show that 1500 words don’t do justice to the vast ecosystem available to developers.

Creating and selling a course online – the tools

When I first took an course on edX, I was struck by the power of online education. There I was, learning Ruby on Rails for free, taking the same curriculum from the same professors as a group of students at Berkeley. I watched videos from the instructors, took quizzes, completed assignments, and tracked my progress along the way.

The next wave of online education, I believe, will come from individual experts marketing online courses. Sean McCabe is a prime example. He holds a unique skill, hand lettering, and successfully marketed a course teaching others how to master the skill and build a business from it.

The first challenge to teaching online is, of course, developing content. Another is finding a place to host and sell that content.

This guide highlights tools available for hosting and selling online courses, aiming to at least cover the different categories available to course creators. The guide is aimed toward robust online courses that may include video, written material, quizzes, and discussion. (Simpler courses – containing eBooks and other static, downloadable content – could be sold through services like Gumroad, with no need for robust courseware.)

Core features

First, it’s important to highlight how tools differ.

Branding independence (B)
Does the author retain control of the his or her brand within the course? This is particularly important to those who use their courses to sell other products, like consulting, or who plan to create a related suite of courses.

Content ownership (C)
Does the course author maintain full ownership over content, including the ability to pull it from the tool and/or publish it elsewhere?

Course design (D)
Can the author easily design a robust course, without custom code or advanced customization? This allows independent authors to focus on content, not technology.

Infrastructure control (I)
Does the author retain control of content and users regardless of the uptime of external service providers? Does the course continue to exist if a service provider goes out of business?

Price control (P)
Can the author set and control the price of the course? Can others discount the price without asking the author?

User control (U)
Can the author reach out directly to course participants, on his or her own terms (assuming the course participants have agreed to such outreach)?

Now, for the tools…


Core features: C-, D, P-, U-

Udemy and Skillshare are two examples of marketplaces. They allow anyone to set up and sell a course. They ask for no upfront fees from authors, host all course materials, and promote courses to a wide community of users. In exchange for these services, they take a cut of course revenue.

Marketplaces provide limited content ownership, price control, and user control. To find economy of scale, the services need to take something away from each of those elements. They’re centrally hosted and thus provide no infrastructure control. They take on the brand of the marketplace, so offer you no branding independence.

Authors maintain control over course content and retain ownership, but give up control over pricing. Both services apply their own discounts to courses (though may provide a way for authors to opt out), impacting revenue.

Sean McCabe shared his experiences with one such provider, in this podcast worth listening to if you are comparing your options. In short, he lost control over his content and pricing.

Subscription communities

Core features: D

Subscription communities like Lynda, Treehouse, and Learnable bundle courses into subscriptions. They provide the course author with no content, price, user, infrastructure, or branding control, but do provide rich course design tools. In exchange, they provide guaranteed payment to course authors.

The author receives an upfront payment and commissions based on the number of people who take the course (and often other factors).

Hosted tools

Core features: C, P, U, B-, D

Thinkific and similar tools provide full content, price, user control, and course design tools, but no infrastructure control. They generally charge monthly and transaction fees to course authors, their only revenue source.

They provide limited branding control, allowing you to place your own logo and styles on your course. Generally, though, it is somewhat clear that the course is hosted on their platform.

Self-hosted WordPress plugins

Core features: B, C, P, I-, U

WordPress has a number of plugins that allow people to sell content online. MemberMouse and Wishlist Member are two examples. These tools live on your own WordPress site, not on the service provider’s platform.

They provide full content, price, and user control. They provide full branding control, as you can customize your WordPress site to your heart’s content.

They do not provide complete infrastructure control. MemberMouse charges course authors a monthly fee, and phones home to ensure it’s collected. It’s not entirely clear what happens if that home goes away (i.e. MemberMouse goes out of business). MemberMouse also handles a few things on its own servers, like recurring billing.

Importantly, such tools are not courseware, per se. They take care of the business side of running an online course – that is, allowing people to purchase courses on a subscription or one-time basis – but do not provide the user interface for the course itself. It is up to the author to create the course within WordPress.

Custom development

Core features: C, P, U, I, B, D

There’s no beating the control you get with custom development, but it’s expensive. It’s worth listening to Sean McCabe’s take on what he went through to build his own platform, and the rewards he gained.

Open-source tools

Solid open-source tools for selling online courseware don’t really exist, from what I’ve seen.

In conclusion

There is a gap in the market for solid, affordable self-hosted solutions that would deliver all of the elements first identified in this article. In the mean time, authors are left to choose custom development or consider tools like those listed above.

User analytics for your Rails app, with Ahoy

Google Analytics provides solid, aggregate statistics for your Rails app. It answers questions like, “How many visitors do I receive a day?” and “Which parts of my app are most popular?”

It cannot track individual users over time, however. Questions like, “How long does the average user remain active over time?” or “How long does it take the average user to go from a free to a paid account” require user analytics.

Services like Mixpanel and KISSMetrics specialize in user analytics, offering robust tracking and reporting for a fee.

There is another option, a free, open-source Ruby gem (technically, a Rails engine) called Ahoy. In just a few minutes, you can have robust user analytics for your Rails app.

Let’s walk through an example; say that on our site we want to track visits and actions for each user.

First, install Ahoy and perform the post-installation steps. This takes only a few minutes.

Track visits

Visit tracking starts immediately after you install Ahoy. You can customize the length of each visit (i.e. after how long does one visit turn into two); it defaults to 4 hours.

Ahoy automatically ties each visit to a user. You not only know how many visits you receive each day, but which users visit the most. Already, we have user analytics.

Track events

Users do stuff in your app. If you have a todo list app, for instance, they add todo items. In modern-day apps, user actions may be processed on the server with Rails and/or on the client via JavaScript.

Ahoy lets you log user events in your Rails code or your JavaScript code.

For instance, if a user adds a to-do item on the front-end, log it with JavaScript:

If the user takes an action handled by your Rails code, log it with Ruby:


Ahoy does not provide a dashboard for reporting, though it’s in the pipeline and they offer advice for building your own.

Third-party services vs. Ahoy

Mixpanel and KISSMetrics offer advanced reporting out of the box, but have a cost and require you to send your user data to a third party. If you choose to leave either service, extracting your data in a useful way is difficult.

Ahoy is free and your data stays local, but you’ll spend time creating a stats dashboard and reports.

There is no right answer, but while evaluating user analytics tools, be sure to consider Ahoy alongside the paid options.

Rails and external services: allow for failure

At Cook Smarts we rely on external services for payments, image processing, and more. Sometimes, the app will fail to reach a service. Perhaps the service is down or there’s a network error somewhere along the line.

How can we tolerate such errors with a minimum impact to the user?

Here’s an example of how we addressed a recurring error with an external service:

A user can export a recipe as a PDF, including an image of the meal.* We retrieve the appropriately-sized image form reSRC, our external image processor.

PDF exported recipe from Cook Smarts

Occasionally, the connection to retrieve the image times out, preventing the image from importing into the PDF. Before, this caused an exception, preventing the user from exporting the recipe at all.

For a better user experience, we now show a friendly error message in place of the image.

Exported PDF recipe from Cook Smarts with image error message

To show the friendly error instead of a fatal exception, we use ‘begin’ and ‘rescue’ in Ruby, in the midst of our Prawn PDF code.

Fault tolerance is crucial when using external services. Assume that your app and the services will clash sometimes, and plan accordingly.

* Eventually, we’ll cache these PDF’s, but for now they are generated whenever a user requests them.

Sending Mandrill e-mails from Rails, the MVC way

Update: For updated guidance, see E-mail in Rails with MailChimp and Mandrill, a comprehensive guide

Mandrill is a transactional e-mail service for developers. It allows you to quickly reach out to users from your app via e-mail, through SMTP or Mandrill’s  API.

Cook Smarts‘ transactional e-mails sometimes go to many users at once, and we quickly hit the limits of SMTP. It was time to use Mandrill’s API to send out e-mails from our Rails app.

Here’s how we moved from ActionMailer/SMTP to Mandrill’s API while staying true to the model-view-controller (MVC) nature of Rails.

Install the Mandrill gem

Add the Mandrill API to your gemfile.

Then run ‘bundle install’ from the same directory.

Send e-mail

Want the simple version of the code needed to send a message? Check out Mandrill’s documentation.

Below we’re going to cover Cook Smarts’ more complex use case.

We specify the subject, from name, and from e-mail above, which is pretty self-evident.

But – surprise! – we’re sending this particular e-mail to a ton of users at once, and we want to address each user by name.

Addressing the message

This message is going to all users with a subscription. We have a scope in our User class called ‘paid,’ which returns all the paid users.

We need to get these users’ e-mail addresses into an array for Mandrill. A class method, User.to_mandrill_to, takes care of this.

When we call ‘User.to_mandrill_to(User.paid),’ we get all our paid users’ e-mail addresses back as an array.

Merge tags

Mandrill uses merge tags to personalize messages. For instance, we want to say “Dear Mary” if the message is to Mary, and “Dear John” if it’s to John.

When we send multiple messages at once, we need to tell Mandrill which name is related to which e-mail address.

Our e-mail template, stored in a Rails view, contains a placeholders for the user’s name:

Another class method, User.to_mandrill_merge_vars, associates each user’s e-mail address with their first name:

This gets us the value we need for the ‘merge_vars’ argument of the API request above.

The message

As stated earlier, the e-mail template lives as a view in our Rails app.

We’ll use render_to_string to process the template and insert it into our API request.

The view should be a full HTML page, including and tags. We add ‘:layout => false’ to avoid bringing in other header/footer content from our app.

Avoid an embarrassing mistake

Remember to include ‘:preserve_recipients => false’ in your API request, unless you want all the people you’re e-mailing to appear in the To line in every message. Mandrill has the details.

MVC Summary

Our Users model provides the addressee information, the meal plan e-mail template/view provides the message, and the admin controller sends the actual e-mail.

All of this without the use of SMTP or Rails ActionMailer – just Mandrill’s API.

We’ve found that this solution has worked well for transactional e-mails with multiple recipients.

If you’re looking for tight Mandrill + ActionMailer integration, check out the Mandrill delivery method gem.

We’re starting a series called Mailing on Rails, which will cover all the bases to get you up and running with mail in your app. Want us to let you know when it’s up?

Responsive images and the beauty of food

Food is beautiful, and Cook Smarts has plenty of it to show. The service provides a meal plan each week, with high-res photos of each meal.

The Cook Smarts archive, where you can view previous meal plans, did not take advantage of the pictures. It was far too text-y.

The old, text-based archives
The old, text-based archives

We started to think of a better way to incorporate the photos, and came up with a design for each week of meals.

Sketch of the new visual archive

We also thought of a more engaging way to welcome people who were trying out the service, with a personal message from Jess.

Sketch of call to action

Here’s how it actually came out:

New, visual archives

We faced a lot of challenges putting this together. Here are a few, and we how we solved them:

Respecting the user’s bandwidth

It was important to minimize load time, particularly for mobile users.

We used reSRC to serve the appropriate image size for each device, without having to generate thumbnails ourselves.

It saved a ton of time, and I encourage graphics-heavy site owners to check it out. Here’s a screencast showing reSRC in action.

Adjusting for mobile

Four images in one row would not work on mobile, so we went from four columns to one.

But the images were too tall. One meal took up nearly the entire iPhone screen, making it time-consuming to scroll through all of the plans.

Tall images make it time-consuming to scroll through meal plans on mobile

Too much scrolling!

Then someone had a genius idea: on mobile, show a slice from the middle of the image. You still got the idea, with far less scrolling. You can see the full image after clicking the meal.

Center-cropped images make it faster to scroll on mobile

By adding a simple parameter to the reSRC image URL, we cropped the images with the result above.,h133/

In the reSRC image URL, we set the image’s width to 400px, and took a 133px slice through the middle of it.

Surely, we could also have done this with a tool on our server like ImageMagick, but using reSRC was faster than rolling our own thumbnails.

Showing different images on desktop and mobile

We had to find a way to load different images on desktop and mobile, in order to achieve the crop described above.

Image tags don’t support image swapping without JavaScript, so we instead used containers with background images. We applied media queries to the containers to serve a different background image depending on the screen width.

The default image is regular size:

The mobile image is center-cropped version:

Separate CSS for each image

Each meal needed a separate background-image style. That’s a lot of styles!

In Rails, we dynamically generate the style tags and place them under a <style> tag on top of the archives.

At first, we tried a separate <style> tag for each image, but this bombed on IE 9 and below, which place a limit on the number of style sheets and tags.

Making the image fit its background container

Our site is responsive, so the image widths change based on the user’s screen size.

With regular image tags, you can simply say…

… and they will scale to their containers.

Background images are a little different. We had to use…

… on the meal containers, in order for the meal images to scale properly.

To support older browsers, we included the background-size polyfill, and confirmed that everyone worked well using BrowserStack (not cheap, but excellent).

Preventing jumping around while loading

Images won’t load right away, particularly on a phone.

Unless you specify the width and height of an image in advance, the page will jerk around as each image loads.

We don’t not know the width and height of the image in advance since the site is responsive, but we still wanted to avoid page jerk.

We do know the proportion of the photos (the relationship between width and height), so we used the padding-bottom technique from Smashing Magazine. With this technique, knowing the proportion has the same effect as knowing the exact width and height, leaving the proper amount of room for the images before they load and eliminating page jerk.

On desktop:

… and on mobile, which is a bit different since we’re only taking a center crop:

To get the proportion (the % above), we divided the height by the width and multiplied by 100. The proportion is always the same no matter the image’s width.

In closing, content is paramount

Web projects are much more achievable when the content is great. In this case, I was lucky to have beautiful pictures of food. Had Jess not taken pictures of every Cook Smarts meal from the beginning, the visual archives would not have launched as quickly.

Want a screencast about the techniques above? Please leave a comment and let me know, or tweet me @coreyITguy.

To see the archives in their glory, sign up for a test drive account on Cook Smarts.