Installation

Usage

The primary usage of the appscrolls gem is to utilize its interactive terminal command to build a new Rails application. To get started, you can simply run the command thusly:

appscrollsnewAPP_NAMEscrollsnewAPP_NAME

Where APP_NAME is the directory in which you wish to create the app (it mirrors the Rails creation syntax). You will then be guided through the scroll selection process and subsequently the Rails app generator will automatically run with the template and all appropriate command line options included.

To transform an existing Rails app, you ... wait, that's not implemented yet. But since the "apply template" feature of rails new APP_NAME -m template.rb is implemented in Thor, I mean, how hard could it be?*

Heroku

CloudFoundry

The App Scrolls needs a CloudFoundry Master to support CloudFoundry for the App Scrolls.

Authoring Scrolls of Magical Mystery

Create new scrolls using:

thor:newscroll-name

Submitting a scroll is actually a very straightforward process. Scrolls are made of up template code and YAML back-matter stored in a ruby file. The __END__ parsing convention is used so that each scroll is actually a valid, parseable Ruby file. The structure of a scroll looks something like this:

gem'supergem'after_bundlerdogenerate"supergem:install"end

It's really that simple. The gem has RSpec tests that automatically validate each scroll in the repository, so you should run rake spec as a basic sanity check before submitting a pull request. Note that these don't verify that your scroll code itself works, just that App Scrolls could properly parse and understand your scroll file.

History

This project wouldn't exist without Michael having created Rails Wizard during Rails Rumble and maintaining and upgrading it for a long time. Sadly support dropped off, several recipes did not work with Rails 3.1+,

Dr Nic originally worked on Rails Wizard to provide Engine Yard Cloud support, his employer and his favourite hosting platform. He also merged in a lot of recipes from other forks, and added new recipes for modern projects.

Support for Engine Yard Cloud meant integration with Chef Recipes. This meant confusing language - Rails Wizard Recipes and Chef Recipes. He decided that wizards don't use recipes - they use scrolls. Alchemists use recipes. And screw alchemists and their dinky potions. Recipes became Scrolls.

3rd party services/add-ons enabled within deployment platform or directly with service

Padrino / Sinatra applications

Non-Ruby applications (Lithium for PHP, etc)

Missing scrolls

MongoDB - branch "mongodb"

OmniAuth - branch "omniauth"

Sidekiq - branch "sidekiq"

How hard could it be?

* 'How hard could it be to transform applications?' - pretty hard. Scrolls need to be aware of the current code base, rather than merely the list of other scrolls being used to create a new app. Scrolls also need to know about versions of Rails rather than just latest rails.