RailsWizard Reimagined

TL;DR: I’ve rewritten RailsWizard from the ground up to be as fast and useful to developers as possible. You can now also run it through the command line with the RailsWizard Gem.

Last year for the RailsRumble I built a tool for Rails developers called RailsWizard.

RailsWizard allowed people to build a Rails 3 application template step by step, removing a lot of the tedious and repetetive setup that comes with building a new application. However, there were a few problems:

1. There was no way for the recipes to get updated by the community. This was a hoped-for feature but one that didn’t have time to come to fruition within the confines of the contest.
2. I didn’t love the design of the thing.
3. There was too much overhead to creating a recipe. There were multiple pages with multiple steps and it was all too complicated.

RailsWizard v2

So a short time after the rumble I decided to tackle the problems I saw with the site and built RailsWizard v2. This version was all on one page (a major improvement) and featured a dark, gradient-heavy design with some relatively slick “big click target” radio selectors and such.

When it was first released it still didn’t address the community recipe problem (recipes for v1 and v2 were stored in MongoDB so not accessible from the git repo), but still seemed to be an improvement. Push it out, job well done, all that business.

But as time went on I still found myself very dissatisfied. So I added a community-submitted recipes feature via GitHub login that put things into a moderation queue (can’t have arbitrary code running unchecked on your system). But I’m not even sure it ever worked, because no one seemed to pick up on the recipe submission process. I considered this to be mostly a failure.

Today: RailsWizard v3

Here is RailsWizard as it stands today:

I found myself coming upon a weekend with few to no plans and I decided to finally go for the gusto and build the tool I’d always wanted to have in the first place. My focuses for the rewrite were:

1. Fast
2. Configurable
3. Git-backed Recipes
4. A command line version of the wizard

For the interface, I wanted everything to be as fast as possible. Remove as many options as possible to make it the simplest thing that can possibly work. I wanted there to be configuration options for recipes, thinking of the needs for API keys or choices of database for ActiveRecord. I wanted everything to be stored in Git so that anyone could fork, add a recipe, and get it added via pull request. And I wanted to be able to run the wizard from the command line. RailsWizard v3, now public, allows you to do all of these things!

User Interface

I was inspired by (and used) the Isotope library to make filtering through recipes as fast as possible. Recipes, I decided, would be grouped into categories and would also have “exclusivity” in that if you select MongoMapper as your ORM ActiveRecord would automatically become unavilable. I wanted the whole thing to take less than a minute to completely choose all the recipes and generate your template.

Git-Backed Recipes

This took some real thought. I wanted git-backed recipes, but how was I going to store the metadata associated with them? Also, even though recipes would be Ruby code, they would not actually be needed as executable code in RailsWizard itself, only as text. However, I still wanted them to be as accessible and readable as Ruby code as possible. This is when I decided to get a little bit clever.

I wanted to borrow from Sinatra’s clever “in-file template” system to allow for “in-file metadata” for each recipe. I found this blog post that walked through how to read the data afer __END__ in a Ruby file. I didn’t find out until later that this only worked for the file that was being executed and could not really be used in a library setting (whoops!).

Undaunted, I decided on a new strategy: I would simply read in the strategy files as if they were text files, and split on the __END__ statement. Before the __END__ statement would be the code that would be executed for the recipe and after would be some YAML metadata “back-matter”. This actually worked out incredibly well and made it easy and readable to develop new recipes. You can find out more about this part of the library on the wiki. I now feel that it is exceedingly easy for a person to write custom recipes and contribute them back to the RailsWizard Core.

Configuration

It will often be necessary/convenient for recipes to ask for some configuration information about themselves. For instance, if you’re using Hoptoad, you might need an API (or know to install the Heroku) addon. I decided to put together a robust question-driven configuration system that would be as easy as adding something like this to the YAML back-matter:

config:   - key_name:       prompt: What is your favorite color?       type: string 

This allows recipe authors to get configuration details in a consistent manner without having to do the heavy lifting themselves. Again, more information about this aspect of RailsWizard is available on the wiki.

Command Line RailsWizard

This for me was the “holy grail” of my goals for RailsWizard. What if, when you wanted to build a new project, it was as simple to run RailsWizard as it was to run rails new. Now that’s possible:

$ gem install rails_wizard $ rails_wizard new APP_NAME 

This will automatically let you type in desired recipes and build a template using the exact same code that drives the web version. It’s all one library so they will be kept easily in sync. This, for me, is a big deal.

Endgame

All of this comes together to build a framework that I hope the community can really expand upon. I would love to see dozens of user-submitted recipes for every library imaginable. As the recipe collection grows there may be new challenges and features needed to support them all, but I believe that RailsWizard now has the proper foundation to encourage such growth.

If you’re a Rails developer and find yourself frequently creating new Rails projects for experimentation, research, prototyping, or even if you only do it once in a while, RailsWizard can save you hours of initial setup and configuration time. It’s all designed to work together seamlessly and without any complex requirements on you as a developer.

For developers who have built their own custom templates before, please try to break them down into RailsWizard recipes! If you look at the codebase you’ll see how easy it is to build them. So what are you waiting for, get forking already!

Edit: One thing that I wanted to make note of is that for this iteration I focused on fast as the motivating factor for the web UI. This means that, as it stands now, RailsWizard is much more friendly for advanced Rails developers looking to speed up the project kick-off process than it is for beginning Rails developers looking for more explanation and help along the way. One of my future goals will be to provide interfaces to make it a great experience for both!