February 3, 2014

Test if memcache is running and accessible

I’ve been writing a Rails template for our future projects at Brightbit and I’ve been testing everything, including our application’s environment. I’ve wrote a special rake task to test our different environments (development, test, staging, production, etc). This helps us ensure each environment is configured correctly. Ideally it would let the person running the tests know what is wrong with their environment and how to resolve it.

One of the environment details I wanted to test was that memcache was setup and running correctly. I could of course test for the memcached binary or check if it was running, but since we are running these tests in the context of a Rails app, why not just ask Rails if it can connect to the memcache server?


There’s a multitude of ways to test for this. We don’t have memcache setup in our test environment’s config file, so I’ll have to ask Rails to lookup a memcache store. Also, I wanted to have something that would give a true/false rather than raise an exception (such as Rails.cache.read 'some-made-up-key'). After poking around a bit, I found that Rails.cache.stats would always return something if memcache was up but have nil values in its result hash if it was down.

So, if you just want to check in your console, you can run:

Rails.cache.stats.values.include? nil

But since we’re writing a test which doesn’t have memcache configured, we’ll need to ask ActiveSupport to lookup a mem cache store:

ActiveSupport::Cache.lookup_store(:mem_cache_store).stats.values.include? nil

So there ya go: quick and simple.

March 22, 2013

Sharing a team Heroku account

tl;dr: Share a Heroku account for a single place to add/remove team members for all shared apps. Permission allocation/revocation made simple! How? Add a new key for each team member to the shared account; access app repos using the heroku-accounts plugin

Currently at Brightbit there’s 4-5 team members to add to each Heroku app. And with some projects having two, three or more apps (staging, production, splash, etc) it gets a bit cumbersome adding all of us and it will only get worse with more team mates.


What makes this problem worse is we don’t re-bill hosting; we let our clients create an account and then they add us as collaborators. Some clients like this control, some just have us do it for them. Whatever the case, adding a single email for each app is much nicer.

To add to the convenience, if we want to add a team member to every Brightbit project we simply add their key to the team account. And if a team member leaves, we change the password and remove their key: instant permission revocation on every project.

So how do we achieve this? Open your favorite terminal and follow along.

Create a work account with a new key

You can only link an SSH key to one Heroku account at a time (how else would it know what account you were pushing from?), so you’ll need to create a new key for your work account.

  1. Install the Heroku accounts plugin by David Dollar:
heroku plugins:install git://github.com/ddollar/heroku-accounts.git
  1. Add a work account and login using the shared team email/password (don’t add anything to your ssh config yet — we’ll get to that):
heroku accounts:add work
  1. Generate a dedicated ssh key for your work account (this is your personal key — don’t share this with your team):
ssh-keygen -f ~/.ssh/id_rsa_heroku_work
  1. Add your key to the team Heroku account:
heroku keys:add ~/.ssh/id_rsa_heroku_work.pub --account work
  1. Add the key to a heroku.work host (so you can push/pull with git):
cat << 'EOF' >> ~/.ssh/config
Host heroku.work
  HostName heroku.com
  IdentityFile ~/.ssh/id_rsa_heroku_work
  IdentitiesOnly yes

Change team heroku repositories

Now to use the account you’ll need to replace the heroku.com hostname with heroku.work. You can do this by removing and re-adding the remote or you can edit your current .git/config.

  1. Here’s a 3 liner to modify your current .git/config that should work on any system (it would be a 1 liner if BSD and GNU sed agreed on inline replacement). You’ll need to run it on the root of each repository:
TMP_FILE=$(mktemp /tmp/config.XXXXXXXXXX)
sed -e "s/heroku.com/heroku.work/" .git/config > $TMP_FILE
mv $TMP_FILE .git/config
  1. Verify it worked (you’ll get a public key denied if it didn’t):
git remote update
  1. You also may want to set your team repo’s default Heroku account (you can use –global for a system-wide change):
git config heroku.account work


  • You won’t know who deployed what when you run a heroku releases.

That’s all, folks

Mention me on twitter (@ericboehs) if you run into any problems.

Happy coding!