It was about a year ago that we first announced Raygun, our Rails applications generator. Since then, many apps have been zapped into existence, both internally at Carbon Five and in the wild. Raygun evolved over the year; it does more of some things and less of others. Let’s see what Raygun does and what has changed…
Raygun is a command-line tool, installed as a gem, that generates new Rails apps with a bunch of tweaks, settings, and other time-saving enhancements. It bakes in the libraries and recipes we find useful when building Rails apps. Rather than including everything we might need, it provides a foundation that, by and large, is applicable to most projects.
Raygun also serves as living documentation of our conventions at Carbon Five. Changes are made via pull requests, where people propose ideas and others chime in with their thoughts. It evolves in small ways all the time, as our preferences and the available tools change.
This gist details the steps for using Raygun to generate a new app, pushing it to GitHub, deploying it to Heroku, and setting up continuous integration and deployment using CircleCI.
Raygun generates an app with these libraries all ready to go:
The good news is that between Rails 3.2 and 4.1, at least a few of the tweaks have become moot (e.g. sync logging, disable schema.rb on migrate in production). This is a sample of what remains (with links to source when appropriate):
rake db:sample_datafor loading small set of data for development. ⤞
rspecruns all non-feature specs, then feature specs. ⤞
HOSTNAMEenvironment variable. ⤞
Raygun no longer embeds a sample application, it instead pulls the latest from the raygun-rails git repo. The old version of raygun embedded a project skeleton in the gem, which meant every change to the sample project required a new gem release. Users may be using an old version of the gem without knowing they were missing out on updates.
Now, the Raygun gem doesn’t change very often and we are free to make frequent changes to the project skeleton. Also, the project skeleton is run through code climate () and continuously (deployed to Heroku) from CircleCI ().
You can also have Raygun use another repo, like your own public fork of raygun-rails or something altogether new:
raygun -p your-github/your-repo your-project. Check the readme for documentation on how to set up your repo. I recommend kicking the tires with the defaults first.
The requirements for auth* vary from project to project. We found ourselves pulling that stuff out of newly generated apps as often as we left it in. That doesn’t meet the project’s goal of including only things that you almost always want/need. We thought about baking in omniauth, and might do that someday, but for now… we’re leaving auth out. And we’re fans of pundit for authorization.
This is a half-dozen/six of the other situation. We use Less on node projects. Rails defaults to Sass. Bootstrap is built with Less (Zurb Foundation with Sass)… etc. We switched because some people like compass and using less offered no discernible benefits, while going ever so slightly against the Rails grain.
Raygun shaves off an hour or two off setting up a new project, which is nice but isn’t that big a deal. Those hours add up if you create projects frequently, which we do. What’s more important is having our ever-evolving stack codified someplace.
Give Raygun a try the next time you create an app by following these steps.
Christian is a software developer, technical lead and agile coach. He's passionate about helping teams find creative ways to make work fun and productive. He's a partner at Carbon Five and serves as the Director of Engineering in the San Francisco office. When not slinging code or playing agile games, you can find him trekking in the Sierras and playing with his daughters.