Kitify is a project I built a few years ago; it was my first web app using a modern framework (Ruby on Rails). I had written web stuff before, but never something using MVC.

It was an extremely valuable experience to build Kitify; I still remember most of what I learned about the architecture of modern web applications, and the knowledge comes in handy pretty frequently since managing web development is part of my job, now.

However, Heroku has been deprecating their Bamboo stack over the past year or two, which meant that the Kitify app had been slowly degrading. It stopped running at all a few months ago.

In keeping with some beliefs I’m developing about what marketers will need five years from now (the subject of a separate post to come), I’ve decided I need to commit regular time to writing code. Getting Kitify fixed up, migrated to Rails 4, and relaunched, seemed like a good way of starting that process.

This post details some of the steps I took to get it running again. Here’s the set of commits, as well.

Setting up a convenient local environment

The local environment for the first version of Kitify was a virtual machine. Why? I didn’t feel comfortable dealing with tools Homebrew and RVM, which are standard tools for developing natively on Mac OS X.

I don’t know why this was. One major problem was that RVM had some problems dealing with the local Ruby installed as part of previous versions of Mac OS X, but that seems to be easily fixable now.

Updating gems

When I originally buit Kitify, it was necessary to have specific versions of the dozen or so gems I was using, for compatibility.

As a first step in updating Kitify, I tried removing all of those version specifications, and everything worked surprisingly well, except for Jammit, which doesn’t like the way routes work in Rails 4.

Fortunately, there’s a recent commit that fixes this problem. So I used:

gem 'jammit', :git => 'git://github.com/documentcloud/jammit.git'

Switching over to Postgres from MySQL

For some reason, the old version of Kitify ran on MySQL. I don’t know why I did this, since Heroku natively supports Postgres.

This actually was surprisingly easy to fix - I updated the gem, ran a schema migration, and updated the Heroku environment variables specifying the database location - and there’s a great GUI for Mac OS X Postgres that helps with seeing what’s in the database.

Adding back bin/bundle, bin/rails and bin/rake

You have to copy these files into the correct location, or you can run rake rails:update:bin as the Rails upgrade documentation suggests.

Dealing with static assets

Since Heroku is read-only, you can’t generate assets (e.g. JS and CSS) once your site has been deployed there. The way around this is to generate your assets before deploying, then commit them to the repo that you deploy to Heroku.

In order for this to work, there are a couple other small changes you need to make, specifically adding:

config.assets.compile = true
config.assets.digest = true

config.action_dispatch.x_sendfile_header = nil

Failing to set x_sendfile_header to nil will cause Heroku to serve blank files for all your assets.