How To: Execute in a Bundler context

I’m writing a small* sinatra-based tool for running tedious command line tools in a nicer environment, and I came across this problem. I wanted to be able to run a tool, say RSpec, in the context of a particular Gemfile. This is the same behaviour as the `bundle exec rspec` command. I’ve spent the last couple of nights figuring it out, and I finally got it going with a little help from StackOverflow, so I thought I’d share it here.

To run a piece of code in a Bundler context, you first need to load up Bundler and the Bundler CLI:

require 'bundler/setup'
require 'bundler/cli'

You then need to set a special environment variable that Bundler reads when performing any actions. This is what gives Bundler its context:

ENV['BUNDLE_GEMFILE'] = "/path/to/Gemfile"

Once this is set, we’re in that particular Gemfile’s context. We can now execute code using that Gemfile’s gems, or we can run the internal Bundler exec method to execute a command:'rspec')

This will do the same thing as if we were on the command line, in the Gemfile’s directory, using the “bundle exec” command.

Pretty nifty, eh?

*I say small, it gets bigger every day.

Migraine Programmers

If there are any programmers out there that, like me, suffer from migraines (of any level), you know what a shit this can be when it comes to what you do best and the fact that it involves staring at lines of text on a bright screen all day long. I myself suffer from hereditary migraines that can be anything from a mild headache to a full blown, week-long (sometimes two) assault on everything in my life.

I’m a geek, so I get real enjoyment out of the problem-solving nature of programming, and it can be really hard to lay in bed in the dark while you have so many ideas and thoughts rushing around your head, and all you want to do is code them out. This is how I’ve come up with these tips.

Because migraines are so unique to the person suffering them, the tips I give here may or may not work for you. I also program pretty much exclusively on Mac and Linux now so some of the apps won’t be directly available to Windows users – sorry!

I’ll start from the top and work my way down (oy vey!).

The Display

The display you use as a migraine sufferer is truly key because for most people, staring at something bright and straining your eyes are two of the biggest triggers for migraines, as well as just plain old headaches. I’ve invested in an LED-lit display that only gives out true organic light. This has made a huge difference to how long I can work at a computer. The light doesn’t aggravate my eyes and I never trigger a migraine because of that fact alone. It also has a built-in light sensor that adjusts the brightness for me based on the environment, just like my MacBook Pro does.

If you can afford one, or if you have an iMac/MacBook Pro/Apple Display:

  1. Keep the contrast at around 50-70%.
  2. If your display has a light sensor, let it decide the brightness.
  3. If it doesn’t, or even if it does, get an app from the Mac app store or something similar that allows you to change the brightness/contrast beyond it’s limits. I use “Brighter Screen Lite” because it’s free and it does one thing and does it well.

The Text Editor / Terminal

The best text editor for me, whether I’m in an attack or not, has to be Sumblime Text Editor 2 with the Soda Dark UI theme (get that using Package Manager). The extremely low contrast is great both in the day and at night and stops my eyes straining, as well as helping it look sexy.

On the subject of day and night, the type of colour theming I use also has a major effect, to the point where I’ve spent hours creating a perfect set of themes for the apps I use. The most common are Sublime and Oh-My-Zsh!, and I’ve included my themes for these here. As you’ll see, I’ve use very faint low-contrast colours even for the day themes. This is because of the huge contrast between having a white/light-grey background and dark text can cause a Migrainepocalypse.

It’s quite important that you use the day theme in the day and the night theme at night because of the way the eye works. If you use a dark theme in a bright environment, you risk straining your eyes and causing a migraine. I do sometimes switch depending on how I feel, but it’s up to you.

I’ve tried to make the Sublime theme not only look nice and be functional, but help your poor brain out too:

  1. Comments are very faint so that they don’t visually clutter the code. I comment on everything that isn’t obvious – I don’t consider it a problem.
  2. Keywords and constants are bold and italic to highlight structure.
  3. Strings have a background to make their content more obvious in formatting code.
  4. Methods have a bright red background, again to highlight structure.

The zsh theme follows the code theme on purpose, but has a few little goodies packed in. By default, the path shows with a green background. If you cd into a git repo, the background will reflect the state of the repo. If there modifications, the background will turn red. This is mostly just a reminder to me to ‘commit often’ as I tend to forget…

You can download the themes at the GitHub page.

A note on colours

Believe it or not, colour plays a huge role in migraine triggering. Personally, bright yellow and green cause me to start swaying like a tree in the wind. Red however, seems to calm my brain down – hence the strong use of it in my themes (that and it’s the Ruby colour!). You will have to choose the colours that best suit you.

Your Environment

Standard working and living tips apply here as for most people, but as a migraine suffering programmer, you need to take a few extra steps:

  1. Cut down or stop drinking coffee while you work. Caffeine is a major cause of migraines so swap to something that’ll keep your brain awake and healthy like (flavoured) water with no fake colourings.
  2. If you listen to music, get a good pair of in-ear or over-ear headphones, not a cheap pair that make everything tinny. On-ear headphones cause the muscles around your ears and by extension your eyes/neck to tense up. Migrainepocalypse.
  3. Take more breaks than most people. I get up and have a walk around, get some air/get a drink/confuse my dog/lay down every 30 minutes or so for 5 minutes if I can. Obviously in a work environment this can’t be as regular, just as long as you give your eyes/brain/body a rest.
  4. Get more exercise. It opens up your blood vessels, gets rid of any junk in your system and is generally quite good for you I’ve heard. I cycle because I have a mutinous ankle but anything helps, and in the long run can actually prevent migraines.


A lot of people (especially parents) say that staring at a computer screen in a dark room is bad for your eyes. I actually find it to be the opposite when I’m IN an attack. When I’m not, I use an LED lamp (again for the organic light) by Phillips which is great low lighting that doesn’t stress my eyes.

That’s all for now – stay tuned on the GitHub page for updates and if you have any migraine friendly tips or themes, please feel free to send a pull request! 🙂

Unicorn+Nginx on Red Hat OpenShift

Although I’m completely buried in personal projects right now (cartridges for Ruby 1.9 and Unicorn+Nginx included), I wanted to share my experience of setting up Unicorn and Nginx on OpenShift for anyone who’s interested. This won’t be a massively in-depth post as the setup is actually quite simple if you’ve followed my previous post on Ruby hacking on OpenShift.

I’ve posted a quick README/HowTo on GitHub here which goes into more detail about how to get it set up. This is really just a quick fix for anyone who’s looking to use this combo as their server setup on OpenShift until I can finish my cartridge and send it off to the lovely people at Red Hat.

Good luck – if you have any problems, contact me via Twitter: @xiy

Install and run RVM and Ruby 1.9.x on Red Hat OpenShift

UPDATE (03-08-12): This post is now largely obsolete as we now have a Ruby 1.9 cartridge available on OpenShift! While this is awesome, I’ll still be working on other little hacks including the Unicorn/Nginx cartridge, a specialised Ruby version manager for DIY cartridges and a little set of tools to quickly interact with your app above and beyond what rhc-tools let’s you do. You can still refer to this post however if you want to use the abilities of RVM on a DIY cartridge. Hope it helped!

When I first started investigating Red Hat’s new Platform-as-a-Service – OpenShift – for deploying my CRM app on, I discovered that they’ve only officially launched a Ruby 1.8.7 environment. I discovered I wasn’t the only person wishing for Ruby 1.9.x support on the forums, so I decided to see if I could install and use RVM on the system. Thankfully, Red Hat give you the ability to SSH into a restricted bash shell to manage your apps and this proved key to getting it to work.

After 3 long nights, I’ve managed to successfully install my own custom version of RVM designed for the OpenShift servers, and built and run Ruby 1.9.3-p125 and Rails 3.2.3, so here I explain how:

1. Create a DIY cartridge and configure SSH Access

Before you start, you need to create a “DIY” cartridge, or app. This is a blank slate where you configure the system yourself. This is just so we don’t get any version conflicts or config errors:

rhc-create-app -a [appname] -t diy-0.1 -l [email] -p [password]

You can also create the app through the new web console, but using the rhc tools will create your repository and perform some other setup (such as SSH public keys), which you’ll have to do manually otherwise.

To get your SSH details, run the following:

rhc-domain-info -l [email] -p [password] --apps

This will print out all the apps in your namespace and their corresponding information. The ‘UUID’ is your SSH username and the ‘Public URL’ (minus the “http://”) is the SSH server. You should then be able to connect like so:


2. Download and Install RVM for OpenShift

Once connected to your app instance, use the following command to download and run the automated installation script I’ve written.

UPDATE (03-05-12): If you were getting an error from curl like in the comments below, its because GitHub altered the  path!  – The curl command should now work properly.

curl -L | bash -s

In short, it will download a working copy of the libyaml-0.1.4 source and compile it, and then dowload and install my version of RVM, as well as installing the latest stable version of Ruby (1.9.3-p125). During my testing, the copy of libyaml that RVM fetched was configured wrongly and failed to build on the servers, hence the custom build.

NOTE: You may also want to build readline if you require it (for irb etc.) and configure with ‘–prefix=$OPENSHIFT_DATA_DIR/.rvm/usr’ to ensure that it’s linked with Ruby when it compiles. This has to be done BEFORE Ruby is compiled.

3. Install and configure a Rails app

Once Ruby and RVM are completely installed, test that it works:

$ source $OPENSHIFT_DATA_DIR/.rvm/scripts/rvm
$ rvm use 1.9.3-p125@global
$ ruby -e 'puts "Hello OpenShift!"'
=> Hello OpenShift!

All going well it should say hello. You should now be able to create your Rails app and code away locally. Make sure you have a ‘.rvmrc’ file in the root of your Rails app that lets RVM know what version of Ruby to use and the name of the gem set.

Update (23-05-2012): You can create AND initialise your project .rvmrc with one command, thanks to @wayneseguin

# NOTE: These commands should be performed INSIDE your Rails app dir.
$ rvm --create --rvmrc 1.9.3-p125@[appname]
$ rvm use --create 1.9.3-p125@[appname];
$ touch .rvmrc && echo 'rvm 1.9.3-p125@[appname]' >> .rvmrc

Also make sure that you edit the action_hook scripts to perform the necessary housekeeping. At this point, I would also suggest using a server such as Thin in place of the clunky WEBrick. You can run it via the rails builtin script or like I’ve done here:


# this will spawn a sub-shell, so make sure we can use rvm
source $OPENSHIFT_DATA_DIR/.rvm/scripts/rvm

# make sure our bundle is up to date
cd $OPENSHIFT_REPO_DIR/[appname]


# this will spawn a sub-shell, so make sure we can use rvm
source $OPENSHIFT_DATA_DIR/.rvm/scripts/rvm

# make sure we're in the app-dir so we use the right gemset
cd $OPENSHIFT_REPO_DIR/[appname]

# start the thin server on the internal ip and port
bundle exec thin start -d -a $OPENSHIFT_INTERNAL_IP -p $OPENSHIFT_INTERNAL_PORT -l $OPENSHIFT_LOG_DIR/thin.log

NOTE: You may also want to symlink the environment logs in the rails app logs directory to the $OPENSHIFT_LOG_DIR to make sure you capture everything from your app, as in testing I’ve found that the Thin process doesn’t seem to log everything.


# kill the server through the pidfile
kill `cat -- $OPENSHIFT_REPO_DIR/[appname]/tmp/pids/`

Unicorn is another great alternative thanks to it’s performance and worker threads, which is ideal for a restricted resource environment like OpenShift. I would also pair it with Foreman and dump the stdout of Foreman into ~/app/logs so that it can be tailed locally with the ‘rhc-tail-files’ command. You can also hook into a service like Travis-CI in your ‘.openshift/action_hooks/pre_build’ script to run your integration tests. I may have to write a blog post about action_hooks soon that can show all this in action.

At this point you should be good to go and code away and push your Rails 3.2+ app up to the OpenShift servers on MRI Ruby 1.9.x. If you want to see a Rails 3.2.3 app running on Ruby 1.9.3-p125 to prove it works, go here.


p.s If you’d like to improve my hacky edits to RVM or if there are any bugs, you can browse the repo on my GitHub:

NCBI BLAST+ Sequence Server

Stretching my legs with some Ruby + Bioinformatics work on the excellent new open-source, Sinatra based web frontend to NCBI BLAST+ called SequenceServer (

I needed to get out of the stuffy C# room I’ve been in for months for a bit, but I’ll be working on my testing framework again when I’ve cleaned out ma’ brain.

My fork is at if you’re an academic interested in using a nice clean interface to your local BLAST databases.

Stay classy, San Diago (which of course means “A Whale’s Vagina”)

Should: Func’y Testing

When it comes to testing anything, testing methods (or functions) is probably the test performed most. I know that most of the time, I want to know if the function I just wrote is going to do what I want it to do:

  1. Will it return the correct value?
  2. Will it return the correct type?
  3. Will it throw an exception?
  4. Will it throw anything else? (like a tantrum)
  5. If it doesn’t return anything, does it perform it’s actions successfully?

These are a few of the things I constantly find myself testing, and I’m sure other people do too. After all, this is what Test-Driven Development (TDD) was created for. I have to admit, because of my previously-mentioned fussiness with current .NET testing frameworks and procedures, I’ve resorted to things like writing console apps to test output, creating obscure debugging classes to record information, and writing messy debug code that eventually just gets deleted.

Current testing procedure seems to follow along all the same lines. Create a class to hold test functions that test specific methods or parts of that class. Once you have all these functions set up, your usual next step would be to fill them with instances of your test class, a few parameters if any are needed, some test data and some assertions.

The problem here is the incredible amount of repetition. Clearly those who designed .NET testing frameworks had never heard of DRY (dont-repeat-yourself).

Now, what if all that could be done in one line? This is where Expectation Tests come in. I mentioned these in my previous post and went over their syntax, and I’m definitely still in the concept stages as I write this, but I’ve discovered that you can do just that:

this.Expects(Context.someFunction(), "should return true"); 

Note: here, this is a class that implements IShouldTest<T> where T is the class, or the “context”. Within this test class, there is a property called Context which obviously points to your passed context, which is instantiated automatically on every test run. You don’t have to do that yourself every time.

Now, this singular line hides a lot of workings behind the scenes, just like a good framework should, but it’s also incredibly powerful. What we’re saying here is that this test context expects the function Context.someFunction() to return true. In one fell swoop we’ve provided the code to test, the expected test parameters and made the test framework aware of the test. Easy peasy.

The concept behind it is pretty simple. Why should I have to specifically define every single element of my test, every single time? Why can’t I just say “I want to test this, this is what it should do”?

This is all made possible due to the improvements in how delegates are used in .NET. I must admit, for a while I just didn’t understand why you’d want to use a delegate, apart from async and event stuff, and the massive waste of time setting these things up was a huge put-off for me personally. Since Func<T> and it’s cousinAction<T> turned up, you can now leave all the annoying delegate work to the framework. It performs all the necessary creation of delegate types for you, and the best thing about this is that it isn’t doing anything more than it used to, so there’s no performance hit.

Another reason why testing using Func<T> and it’s friends is great is LINQ and Lambda. Have you ever wondered, ‘how would my function react if i gave it this?’:

this.Expects((hugeDictionary) => someSortingFunction(hugeDictionary), "should take < 1 minute"); 

Pretty cool, huh?

shoulda, woulda, coulda

I hate Testing Frameworks. Actually, let me be specific…I hate .NET Testing Frameworks. They make me angry and sad; so I’ve decided that because I have nothing better to do, I’ll write my own. But first, a little comparison…

VS2010 Testing Framework (MSTest?)

Microsoft’s built in testing system isn’t too bad. It’s integration is done well, but it’s so bloody overly complicated and slow, and messy. Every test you perform dumps a shit-load of messy files everywhere on your filesystem and inside your solution folder. It then has the CHEEK to complain that you should delete some when it gets “full”?

Poor effort Bill (or is it Steve now?)


As far as I’ve ever been able to tell, this is simply a big, even more bloated version of the above. Some of the testing functionality is simpler and easier to understand, and it does have more assertions…that’s where the good things end. Like a lot of software, it’s probably the most used? Weird that.


Made by the same blokes as the above, but apparently it’s better and easier to use. I went over their comparison table they’ve got up on their Codeplex site….yeah, no. If anything, it’s a massive excercise in how to complicate a piece of supposedly useful software even further. I mean…test methods are called “Facts”? Not only that, the method to actually get testing is beyond annoying.

Getting there…but not quite.


I’m tired. I like ruby, I like libraries like “shoulda” and “cucumber”. You just want to test whether that function does what you want it to; does it fulfil the requirements? Does it do what you expected it to do? I got tired of fumbling around the above libraries. I wanted a simple, easy to use, easy to understand testing framework so that I could test Nucleo quickly and effectively, so I created “Should”. At least that’s what It’s called at the moment.

Creating a test involves (at the moment) two things:

  1. ShouldTestContext<T> object. Think of it as the manager for all your tests. The generic type parameter <T> is the object you want to perform tests on, or the “context”.
  2. One or more Expectation objects. An expectation test is exactly that; it tests an expectation of something else.
  3. Once you’ve set up all your expectation tests, you make a call to theShouldTestContext<T>.RealiseExpectations() method and shazzam, it tests away!

Expectation Test Syntax

I wanted to make writing the actual tests as easy as possible; plain english if i could. Turns out I could:

Expectation ex = new Expectation(() = { return true; }, "should return true"); 

Here, I’ve created a new expectation test and fed it a lambda expression as a delegate that simply returns true (for demo purposes) and my expectation (logically) is that it “should return true”. Using a simple parser, an Expectation is then created by analysing the logic of the expectation string. The parser determines the type of test by what kind of type is passed to it (method, property, field etc.) and then runs a test against the object based on the given expectation. The kind of tests you can run are all your usual suspects, and I may add a few more in the future. Here are some examples of some expectation test strings:

"should contain 'Hello'" (test a collection, array or string) "shouldalways return true" (test a constant) "shouldnot have length > 10" (test a property or field) 

The important thing to note is that, underlying all of this is the same basic usage of assertions. It’s the way in which those assertions are performed which is the cool thing. I am also making it completely programmatic too, so if you want to write your tests in the standard way, you still can, and they’ll still be beautiful:

Should.BeEqual(1, 1); Should.ReturnTrue(() => { return true; }); Etc. etc. - more to come..