Dr Nic

Instant new Rails applications with the App Scrolls

When I start a new project I want to start how I plan to finish.

If I intend to write integration tests then I want to start them immediately. If I intend to set up continuous integration then I want CI setup immediately. If I intend to deploy the app somewhere then I want to deploy it immediately. If I intend to use some background workers, I want to know that they are setup immediately.

I want it all setup as easily as I can generate a new Rails app. They shouldn’t be extra work later. I’ll be busy then.

Assuming you want the same simplicity and speed, then let me share with you the App Scrolls!

gem install appscrolls
scrolls new mydemoapp -s twitter_bootstrap unicorn postgresql resque github eycloud

This one command will:

  • create a new Rails application called “mydemoapp”
  • install Twitter Bootstrap (you choose fixed or floating) and some other Rails basic tweaks
  • sets up Unicorn and Postgresql in the application
  • sets up Resque and Redis for background workers
  • hosts the project on GitHub (public or private repo)
  • deploys the application on Engine Yard Cloud

These are the magical App Scrolls!

Can you run the command above, or do you need a video to see it happen? Let me know.

Scrolls are interactive

$ scrolls new myapp -s twitter_bootstrap github resque postgresql unicorn eycloud
...
   question  Create a GitHub repository?
          1)  Public
          2)  Private
      github  Enter your selection: 1
...
      resque  Enter a secret string for the route /resque/YOUR-SECRET-STRING: mysecret
...
    question  Which Twitter Bootstrap layout?
          1)  Fluid
          2)  Fixed
  twitter_bootstrap  Enter your selection: 2
...
    question  Select application cluster configuration?
          1)  Basic - 1 app VM (5 CPU-based processes) & DB Master VM
          2)  Pro   - 3 app highly-available VMs (15 CPU-based processes) & DB Master VM
          3)  Solo  - 1 VM for app processes, DB and other services
     eycloud  Enter your selection: 1

Deploy automatically

I perfer to host on Engine Yard Cloud and I work there. So I added support to Engine Yard Cloud to all the scrolls and it will automatically boot a new environment and deploy your new application. Thanks to David Calavera’s unofficial ey_cli tool and the unofficial github-ruby CLI for making this possible!

Which Scrolls are supported?

Lots of magical scrolls are available!

administration: active_admin
assets: jquery, prototype
deployment: eycloud, eycloud_recipes_on_deploy, git, github, passenger, unicorn
persistence: mysql, postgresql, redis, sqlite3
stylesheet: twitter_bootstrap
templating: simple_form
testing: capybara, cucumber, rspec, test_unit
worker: delayed_job, resque
other: env_yaml, guard, rails_basics, split

I might blog about individual combinations later. My favourite is guard, which magically combines with other scrolls you choose.

Heroku or CloudFoundry?

If you’re a fan/employee of Salesforce/Heroku or VMWare/CloudFoundry or other platform, can I please ask for your help to make the current set of scrolls work? I’ll pair with you to get you started if you need it; though I think the code base and the scrolls are relatively self explanatory.

Isn’t this like Rails Wizard?

Yes! Before the App Scrolls, there was Michael Bleigh’s Rails Wizard. He created the first version during the 2010 Rails Rumble [Intridea blog post], and iterated on it a few times. I especially like that he extracted the project into two codebases – the CLI/scrolls and the web version.

I renamed it because ultimately I think it could support more than Rails applications and it definitely should become more than a “new application wizard”. And because I’ve been playing Elder Scrolls. Fortunately, Michael convinced me not to name the project after the computer game. Thanks to Thom Mahoney for suggesting “App Scrolls” and saving me from a naming nightmare.

A new name and a new repository? I’m still in two minds as to if I should have done that. Oh well, its done now. App Scrolls is a cool name.

Why “Scrolls”?

Rails Wizard used the word “recipe” to describe each component or service that would be added to a new application. Talking with others at Engine Yard, the word “recipe” got confusing. There were wizard recipes and chef recipes. When you wanted to use Resque you needed both. “Scrolls!” seemed a fun alternative name.

Wizards use scrolls, not recipes. Every D&D person knows that.

Where are all the old scrolls?

For the initial release, I’ve moved many contributed “recipes” from the Rails Wizard into the scrolls/zzz archive folder. There are so many and I don’t yet know how to ensure they all work as expected. I intend to find a good way to allow rubygems to self-host their scroll.

Continuous Integration?

I mentioned that I like CI to be setup immediately for new applications. That’s next. Jenkins, Travis CI (when they release private application support), and what other CI systems should be supported?

I hope you use the App Scrolls for your next big or small Rails app and that its useful to you!

Related posts:

  1. Using CoffeeScript in Rails and even on Heroku I’m pretty excited about CoffeeScript as a clean-syntax replacement for...
  2. First look at rails 3.0.pre This article is out of date in some aspects....
  3. Rails themes can remember things I was getting annoyed at having to remember all the...
  4. Install any HTML theme/template into your Rails app Have you ever even bothered to Google for “rails...
  5. Closing in on The Dream: “one-click-to-deploy Rails apps” Got a simple app you want to build? Allocate...

12 Responses to “Instant new Rails applications with the App Scrolls”

  1. Steve Byrne says:

    Namespacing of scrolls should be a consideration. Having a flat namespace for scroll names can quickly end up with collisions and confusion, and makes a headache for would-be scroll authors who have to search n different repositories to make sure their scroll name is globally unique. Not a requirement, but a feature that should be present.

    Also, I think a syntax and mechanism to control versions of scrolls (and what they use underneath) is worth consideration.

  2. Dr Nic says:

    Steve, I think namespacing is a good idea that Rails added into its plugin/generators.

    What do you mean by “syntax”?

    Scrolls will need to do a more advanced job of versioning what they do when I add the ability to run scrolls on existing applications. Currently they just check “is XYZ scroll also being run?” – in future they’ll also need to test the existing code if XYZ is already included.

  3. Steve Byrne says:

    By “syntax”, I’m thinking some optional suffix on a scroll name to select a specific version, something like “twitter_bootstrap:3.5″, but maybe with a different delimiter than : so it’s differentiable from a scroll namespace prefix. Maybe Gemfile version strings in square brackets would be sufficient? “twitter_bootstrap[3.5]“.

    There is of course some default version that each scroll will use (could be whatever’s latest), so the version would have to be given only when explicit control was desired. Plus ~/.app_scrolls could define the default version overrides on a per-user basis where needed.

    Just thinking out loud…

  4. “and what other CI systems should be supported?”

    https://github.com/tech-angels/moci of course :)

    Nice piece of work by the way !

  5. Zach Inglis says:

    I had started but lost momentum on creating something like this (https://github.com/zachinglis/taco-truck)

    Really happy to see someone actually complete one :)

    Great work as always!

  6. Dr Nic says:

    Zach, nice – I’ll look through it and see if there are ideas/snippets to reuse!

  7. Dr Nic says:

    Steve, you think the scrolls themselves need versioning, rather than the gems they are working with?

  8. Dr Nic says:

    Philippe, I’d love to see a demo and see how to set it up.

  9. Marcin Kulik says:

    Talking about video, I have created asciicast showing App Scrolls in action: http://ascii.io/a/329

  10. Steve Byrne says:

    I was thinking the version given on the scrolls would be used as the underlying gem version; that way, the same scroll could be used flexibly for a wide range of underlying gems.

    But I imagine there may be a need to have versioned scrolls as well, but that could be handled by whatever mechanism (the appscrolls gem version, other “plug in” scrolls versions, etc) retrieves the scrolls.

  11. It’s currently under development, but we’re working hard to have a stable version very soon. README has a “Playing with it at the moment” section :)

  12. Chad Eubanks says:

    AWESOME!!!!! Well done Nic!