Ylan Segal

Faster Rspec: Jruby, Spork and Nailgun

UPDATE: You can use bundler binstubs to squeeze a bit more performance


Much has been said about Rails slow start-up time on large projects. It is especially painful when trying to do TDD and each test takes 30 seconds to run, mainly in startup time.

As a consequence, there have been many attempts to pre-load the Rails environment and have it ready to test. I tested some options and saved 25 seconds on each test run.

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.