Ylan Segal

Per-Project Environment Variables

I wrote before about using foreman to manage you app’s processes. An additional feature is that it enables you to configure your unix environment when starting an app, by reading environment variables located in a .env file at the root of your project, that looks something like this:

.env
1
2
MY_VARIABLE=/some/path
SECRET_STUFF=get_a_better_password

It is certainly a great feature for setting an common environment for processes that your start with foreman. However, processes that are started manually, like for example a rails console, don’t have this environment setup. Of course, you can always set them manually in your shell profile, but now they need to be maintained in two different places.

Installing Jruby With Rvm and XCode 4.4

I recently setup a new Mac (running Lion) for development using jruby. As I have done many times in the past, I installed Xcode (4.4) and proceeded to install the command line tools. Next comes rvm, and we are humming along, until it complains that gcc-4.2 is not in my path. But it is. I can see it with gcc --version. In any case, the notes for rvm suggest using homebrew to install gcc-4.2 like so:

1
2
3
4
brew update
brew tap homebrew/dupes
brew install autoconf automake apple-gcc42
rvm pkg install openssl

Since I use homebrew to install other packages anyway, this worked out fine.

That took care of my problem, and I proceeded to install jruby as usual:

1
rvm install jruby

Manage Your App's Multiple Processes With a Procfile

On simple web applications, it’s common to talk about a “develpment server” which one starts before coding. Any rails developer is familiar with rails s. It boots up your application and it’s ready to view on your favorite browser. As applications start to grow, so do the number of processes that your application depends on. Using memcached? Make sure it’s running. Need background processing? Better start your background worker. Pretty soon, you have half a dozen terminal tabs open and you haven’t begun coding yet. There is a better way.

Deploy to Heroku With (Near) Zero Downtime

Heroku offers a great hosting platform that abstracts away most of the system administration tasks inherent in running an app. I have generally been very happy hosting productions apps in Heroku and have managed to do very well with it’s platform and it’s available add-ons to increase functionality. I really like the way the handle Postgres databases, which makes things like followers, clones and backups a simple 1-off command.

For a long time, though my main gripe has been deployment. Initiating a deployment could not be easier: Just push to your app’s git repository in Heroku. My problem is what happens on restart.

Better Performance on Heroku: Thin vs. Unicorn vs. Puma

UPDATE: These benchmarks where updated in 2013 and 2014.


Heroku’s Cedar stack provides great flexibility in the type of processes you can run, including the ability to choose which application server to deploy.

I have been running thin, since it’s the recommended option and also the safe default, since that is what the app was running in the Bamboo stack, before migrating to Cedar.

However, I have read recently about getting better performance out of the same amount of dynos, and my interest was piqued. Before heading straight for Unicorn, I decided to give Puma, the new kid on the block a try.