Open-sourcing

Written

Quick post today: I've open-sourced my blog code, and the code for a mobile application I've been working on. They are both on my GitHub account:

Projects

Hey Jane is an iOS app that lets you share, rate and view messages by location. Basically the way it works is anyone can post a message from their location (optionally with a name associated) that anyone can view and up or down vote. When viewing, you only see the 10 most popular, recent messages in you geographical area. So if you zoom out you'll see globally popular messages, if you zoom in you see locally popular messages.

MyBlog: this is simply the current code I have for my blog. It's pretty much a vanilla Ghost 0.5.2 with the Syndney theme plus some simple customizations.

Obfuscation

I had (bad, I know) stored my private database and API key details in the repositories, so I had to do some quick obfuscation before I could make these repositories public. I didn't mind sharing what I'd done, but I (previously) didn't have a good way to make it public without sharing important keys and such.

Anyway, this required me to clean my repository to remove all traces of this private information. GitHub has some steps on doing this, but I ended up just using one BFG command:

bfg --delete-files config.js

This removes the config.js file from any and all commits. Handy! Now... what about my database connection details?

Heroku environment variables...

For my blog, I simply changed my configuration file to use Heroku environment variables for the database connection details (the only private information I have in my blog code). Then I pushed the actual values into my Heroku environment:

heroku config:set DATABASE_USER=root

Deploy the latest and I'm done.

What if I need private keys and strings locally?

For Hey Jane it was a bit tricker. Because it's an xCode compile I need to store my Parse account details somewhere the compiler can reach them. I settled for storing a HJSecretKeys.h file in an encrypted volume on my machine, and symlinked it to my build directory. This is a bit sucky because for now I have no version control on that file, but since these private keys will rarely change I'm okay with that.

Private version control

A better way (if I get around to it), would be to have a private repository for all my secret keys that I clone to an encrypted volume locally. Then I can symlink whatever header/config file I need into the actual project, but still have version control via a private repository. Maybe that'll be my next step...

comments powered by Disqus