Open Sourcing My Rails App
If you’ve read some of my other posts, you’ve learned about my first ‘startup’ attempt StudioJoy. In this post I’m going to describe my reasoning for open sourcing it on Github and some ideas to help you do the same with your Rails app.
So basically StudioJoy is in maintenance mode and since I only have one user (who still uses it every day which I’m pretty happy with), there aren’t many feature requests coming in. Because I’m not actually charging anyone to use the application, I figured I might as well open source it incase someone else could find it helpful. Also, it just feels good to get my work out there and gives me a sense of completion.. even if the code isn’t the cleanest.
I’ve been using Git while developing StudioJoy since the beginning. Originally the project was called ‘Guru’ because at the time I couldn’t come up with a better name. That’s still what the repo is called now as well as the Rails application itself. I’ve also been hosting the source using BitBucket since it allows for free private repos. In order to make the move over to Github, a little cleanup was required.
I started by copying the existing project folder to make sure that I didn’t do any irreparable damage to my repo. I probably could have just created a new branch in Git, however I just wanted to start fresh with a new location.
Because my original commits contained some sensitive information (more on that later) I decided to delete my complete Git history and commit the entire application as one large commit. There are several ways to do this including using ‘git rebase’ or just deleting the .git directory (which is what I did).
Note: You should only delete the .git directory if you truly don’t care about losing your git history. Once it’s gone, it’s gone (this is why we made a copy).
Now that we’ve got a clean, un-versioned application, it’s time to remove that sensitive information I mentioned earlier.
Secrets Don’t Make Friends
Since this is a Rails 3.2 application, I did not have a secrets.yml file to contain my configuration variables (such as S3, New Relic and Mailgun credentials). Also, since my production application is deployed to Heroku, and they are huge proponents (and the creators) of the Twelve Factor App methodology (which states that config variables should be separate from code and stored in config variables), I used the Figaro gem to handle my configuration.
Figaro allows you to store your configuration variables in a file ‘config/application.yml’ like so:
Figaro then parses the YAML file on startup and loads the values into ENV, allowing you to reference those values from within your application:
Even though we have now separated code from configuration, we still have to make sure that we don’t add those values to source control (where they will be public once pushed to Github). Make sure you add any of these ‘secret’ files to your projects .gitignore file.
Here’s what part of mine looks like:
Notice I am also ignoring secret_token.rb which contains the secret token that is used to sign cookies set by the application. To learn why you shouldn’t make this information public, read this post by Daniel Fone.
I took the lazy way out by just ignoring the file all together. Eventually I’ll convert the secret_token to an ENV variable as I described above.
If you check out many projects on Github, you’ll notice that most of them have a README file explaining what the application does and how to get started running it as well as a LICENSE file to handle all of that lawyering stuff dealing with copyrights and what not.
Software licenses could warrant several posts on their own so I’m going to skip all of that. Luckily, Github provides a handy website choosealicense.com to help you decide which one works best for you and your application.
Since I really don’t care what people do with my application I decided to use the WTFTPL license.
As far as the README goes, I put up a few screenshots and listed the application’s major dependencies. Eventually I hope to use a platform such as Docker to make it easy for anyone to get up and running quickly without worrying about dependencies.
Finally we are ready to push the application to Github. We need to initialize the Git repo, add and commit the files, then push to our already created remote repo.
Again, Github already has extensive documentation on how to do all of this (checkout help.github.com).
Now we’re done! Everything is included in a single commit as if we did everything perfect from the start (ha). Grab a beer and pat yourself on the back.
You can view the ‘finished’ project on my Github.