Heavyweight template for Rails 2.3.x
Switch branches/tags
Nothing to show
Pull request Compare This branch is 11 commits ahead, 48 commits behind ffmike:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


Big Old Rails Template

This template assists in spinning up new Rails applications quickly using Rails 2.3. To use it, just specify the -m switch when creating a Rails application:

rails new_app_name -m lark_template.rb

This template has not been tested with the new architecture of the Rails 3.0 master branch. That is, it can create Rails 3 applications, but it may not run under Rails 3.

Two things you should take note of:

  1. It’s a pretty heavyweight template, sticking a lot of stuff into the new application. This suits me, because I have a lot of things I use in just about every application, but it may not suit you.
  2. Rails templates are not one-size-fits-all; you should understand what the template does before blindly using it. Unlike most other Rails templates though, it allows you to configure the application that it builds.

Getting started:

  1. Clone BigOldRailsTemplate to somewhere on your hard drive (let’s say /templates/BigOldRailsTemplate though of course you can put it anywhere).
  2. Copy /templates/BigOldRailsTemplate/configs/lark/config.yml to ~/.big_old_rails_template/configs/lark/config.yml – this gives you a copy of the config file that will override the defaults and not get replaced if you update the template.
  3. Edit the file you just copied to control the behavior of the template; it’s pretty well commented.
  4. rails NewProjectName -m /rails/BigOldRailsTemplate/lark_template.rb will then use your installed copy of Rails to create NewProjectName based on the template.


You can configure this template to control the application that it generates. See configs/default/config.yml to set persistent configuration information. The template will use a configuration file located at ~/.big_old_rails_template/configs/lark/config.yml if it finds one; otherwise, it will use the copy embedded in the template’s configs/default directory. If you don’t have a config.yml, or it doesn’t have an option that the template is looking for, you’ll be prompted at runtime for some of the information, and reasonably sensible defaults will be used for the rest. You should review config.yml before you first run the template.


The list of gems that the application will install is housed in configs/default/gems.yml. You’ll need to have all of the gems installed on your development machine to successfully run the template (otherwise the rake tasks will fail). If you have the geminstaller gem already installed, then the template framework will create a geminstaller.yml file and use geminstaller to bootstrap the necessary gems on to your machine.


Most of the files that this template generates are copied from the /patterns and /snippets folders within the template. You can override any of these patterns or snippets by supplying your own version in the corresponding spot under ~/.big_old_rails_template. For example, by default the application.html.erb layout is copied from patterns/default/app/views/layouts/application.html.erb by default. If you create the file ~/.big_old_rails_template/patterns/default/app/views/layouts/application.html.erb then your version will be used instead of the version in the template. Of course, it’s up to you to make sure that the contents are sensible and have any expected substitution points included.

Generated Application

Here’s a list of what this template sets up:


  • Uses the edge of the 2-3-stable branch in the Rails git repository. You can change the branch in config.yml, so you can use, for example, 2-2-stable or (if you’re feeling brave) master.
  • Uses formtastic for forms.
  • Optionally uses Haml and Sass for views and CSS.
  • Optionally uses inherited resources to DRY up controllers.
  • Optionally uses Bluetrip CSS or Compass for design.
  • Choice of prototype or jQuery. Loading jQuery will include jRails for backwards compatibility.
  • Uses Erubis and the rails_xss plugin to provide safe HTML


  • git repo
  • master, staging, and development branches (you can adjust this in config.yml)
  • Rails and plugins installed with Piston by default – you can change this to use Braid, git submodules, or just straight code in config.yml.
  • Vendored Rails. You can also choose to depend on gem rails, or to symlink to a local copy of Rails, instead of vendoring it to the project.

Coding Tools

  • Authlogic for user authentication, including password resets, anonymous_only, authenticated_only, and admin_only application helpers. Optionally installs user activation support.
  • World’s simplest authorization system: manage multiple string roles on users with User#add_role, User#remove_role, User#clear_roles, and User#has_role?
  • Date formats: :us, :us_with_time, :short_day, :long_day
  • Paperclip for attachment management
  • /pages/css_test will show most CSS styles in action
  • Searchlogic for magic named scopes and search forms. Includes attribute_equals, attribute_does_not_equal, attribute_begins_with, attribute_like, attribute_ends_with, attribute_greater_than, attribute_null, attribute_blank, etc., etc.
  • Stringex for extra string functionality – acts_as_url, String#to_ascii, String#to_html, String#to_url, String#remove_formatting, String.random
  • US State application helpers
  • will-paginate for pagination
  • annotate to annotate models, exemplars, and routes

Database Tools

  • Hooked up for PostgreSQL, MySQL, or sqlite depending on your configuration options.
  • foreigner installed for foreign key support.
  • admin-data plugin for administrative UI. http://localhost:3000/admin_data will get you to the application’s data. On production, only admin can view data, no one can edit (modify config/initializers/admin_data.rb to adjust this)
  • db-populate for seed data
  • Bullet in development mode to help find N+1 queries (enable in config/environments/development.rb)

Deployment Tools

  • fast_remote_cache strategy for deployment
  • rubiadhstrano for deployment recipes; automatically uses multiple targets, so: cap production deploy for deployment to production
  • superdeploy for additional Capistrano tasks. cap -T for full list.

External Services

  • Exceptional or Hoptoad for error tracking. Go to /pages/kaboom to test after finishing setup.
  • New Relic or Scout for performance tracking, depending on your configuration options.

Testing Tools

  • Shoulda and Test::Unit for testing
  • rr or Mocha for mocking. Note that tests are currently failing under rr; I think this is an issue with rr but haven’t dug into it yet. You’ll currently have better luck if you build Christopher Redinger’s fork of the rr gem.
  • Object Daddy for factories
  • Generated code is already covered by tests
  • parallel-specs for faster testing. rake spec:parallel:prepare2 to set up two test databases. rake test:parallel2 to distribute tests across two cores
  • rack-bug for request/response/perf analysis. http://localhost:3000/rack_bug/bookmarklet.html to add bookmarklet to browser.
  • shmacros for additional Shoulda macros: should_accept_nested_attributes_for, should_act_as_taggable_on, should_callback, should_delegate, more
  • More extra shoulda macros: should_have_before_filter, should_have_after_filter, should_protect_from_forgery, should_have_helper_method
  • metric-fu for static code analysis. rake metrics:all, configure in Rakefile
  • inaction-mailer is installed for development environment, so mails sent during dev will end up as files in /tmp/sent_mails. rake mail:clear will clean out this directory.
  • test-unit 2.0 for nicer output.


  • Code to encourage IE6 users to get a real browser is included on the home page by default. You can adjust this in the configuration.
  • The generated application is localization-ready, with all strings in an English locale by default.

Post-creation Hooks

By adding keys to the post_creation section in config.yml you can perform some operations with the finished application:

  • “heroku” deploys the application to Heroku. You should already have the heroku gem installed, and have performed at least one Heroku creation so that the gem has your credentials installed.
  • “github” duplicates the repository to your GitHub account, and sets up the local branches to track the remote branches. You will need to supply your GitHub username and API token in config.yml. Private repository creation is allowed if your GitHub account supports private repositories.


I welcome suggestions and contributions. See the project’s wiki to contribute to the wishlist, or fork the project on GitHub and submit a pull request when you’ve got something to add.

Thanks to:

  • Darcy Laycock (download, commit_state, from_repo methods in framework)
  • Eric Davis (bug fixes, better architecture for config)
  • Paco Guzman (bug fixes)
  • Jeraimee (MySQL translation of database.yml)
  • Maran Hidskes (fix to allow running with no config)
  • Wynst (bug fixes)
  • Rob Zolkos (typo fix)
  • Matt Hooks (inspiration for Authlogic activation code)
  • Joey Geiger (typo fix, bug fixes)
  • Reuben Doetsch (original implementation of file/snippet loading code)
  • Maxim Chernyak (bug fixes, jRails, Haml & Sass support, Compass support, internationalization, inherited_resources, test updates)
  • Christopher Redinger (test and rr fixes)
  • Mark Dodwell (rake gems:specify task)