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:
Tweaks, Recipes, and Settings
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):
- Bootstrap layout and view generators. We don’t always generate scaffold, but when we do, we want markup that is bootstrap compatible. These generator templates are embedded under lib/, so you can customize (or remove) easily.
- Rspec controller spec generator templates that default to using factory_girl factories.
- Include a new environment called acceptance, based on production. ⤞
rake db:sample_data for loading small set of data for development. ⤞
rake db:spec:without_features and
rspec runs all non-feature specs, then feature specs. ⤞
- Redirect to a canonical hostname by setting the
HOSTNAME environment variable. ⤞
- Enable basic auth by setting
- Connect to mailcatcher if it’s listening. ⤞
- Unicorn configuration (tweak using
- CircleCI configuration. ⤞
- Deploy script for Heroku with some smarts for dealing with workers and the database. ⤞
Significant Changes Over the Last Year
1. Externalizing the Sample Rails Project: raygun-rails
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.
2. No Authentication or Authorization
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.
3. Switch to Sass (SCSS)
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.
Really, I can do all of that stuff on my own in minutes!
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.