Skip to content

skeleton rails app starter

I’ve found a few tools that I like to use on all new projects, mostly for the presentation and testing layers. Following the dictum that lazy is good (and I’m far too lazy to make sure that’s the correct usage of ‘dictum’), I’ve created a starter app that has all those tools in place, so I don’t have to do all the script/generating etc each time.

In case it helps you, you can find it at

Suggestions welcome.

So far, the list includes:




In case you want to do it by hand, here’s how:


rails rails_skeleton
cd rails_skeleton


sudo gem install haml (if needed)
haml --rails .

in environment.rb:

config.gem 'haml-edge'

(for compass)


sudo gem install compass
rake rails:template LOCATION=

add to layout header:

 = stylesheet_link_tag 'compiled/screen.css', :media => 'screen, projection'
 = stylesheet_link_tag 'compiled/print.css', :media => 'print'
 /[if lt IE 8]
   = stylesheet_link_tag 'compiled/ie.css', :media => 'screen, projection'


config.gem ‘formtastic’ script/generate formtastic


= javascript_include_tag ‘’


in environments/test.rb:

config.gem "rspec", :lib => false
config.gem "rspec-rails", :lib => false

script/generate rspec


script/generate cucumber


script/generate cucumber --spork</>
Reblog this post [with Zemanta]

migrating a rails app from 2.x to 3.0

I’m sitting here with @gavinstark at major coffee/sandwich chain playing with rails 3.0 for the railsbridge bugmash weekend.

Here’s what I had to do to get the omnominator app migrated to 3.0. Some (most) steps taken from Yehuda Katz’s post.

Check out rails source:

git clone git://

Run rails update script

I forked a copy of the omninator code for this; from the root dir of the app:

 ruby /path/to/rails3/railties/bin/rails .

Note that I had to call that with ruby, as it wasn’t pre-set to be an executable ruby script.

I let that overwrite all the script/ files etc.

Note about config/environment

The config/environment.rb now basically just requires config/application.rb, and all the config statements in config/development.rb, etc are wrapped in an initializer block like:

 Myapp::Application.configure do
      config.cache_classes = false

So, do that for each of your env-specific config files, and (I think) move the config code from environment.rb to application.rb.


Gems are now handled in Gemfile, instead of using config.gem in environment.rb etc.

Update the gemfile

Again, from Yehuda’s post, copy this block to your new Gemfile:

 # Add to the top
 directory "/path/to/rails", :glob => "{*/,}*.gemspec"
 git "git://"
 git "git://"

and then from the root of the app run:

gem bundle

(note that you need to have the ‘bundler’ gem installed, so ‘sudo gem install bundler’ if you need to..)

I had to remove a couple of initializers:

  • Hoptoad notifier initializer fails, so I commented it out for now; I’ll update this post when I figure out the Hoptoad compatibility
  • new_rails_defaults, which was added in 2.x to ease migration, failed under 3.0; that makes sense ’cause it’s redundant now.

That was it. The omnominator is a one-controller basically two-view app, so I’m sure there are other upgrade issues for more complicated apps, but maybe this will get you started.

Setting up a new development environment on OSX

I recently set up a new MacBook Pro for development. Here’s what I did, mostly as notes to myself for next time:

Basic rails environment

I mostly followed Robby Russell’s guide, here.

That got xcode, macports, ruby and rails, mongrel and postgres installed.


Most of my projects use MySql instead of postgres. I installed Mysql from the binary on the mysql site, not through macports. The download link is here. For a new MacBook, I used the x86-64 package. Also install the startup item, which is included in the package.

Installing the mysql gem requires some path trickery, since I didn’t install the macports version. I followed these instructions, which worked well:

 sudo gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config

To get the databases copied over with minimal effort, I just copied the /usr/local/mysql/data dir from my old machine to the new one.


Most of my projects are now on git. Following the githubs, I installed it via macports. I included subversion, for those that still use it:

  sudo port install git-core +svn

Also gitx, which I’ve come to like; installs with a dmg.


At this point, it’s time to get the gem dependencies for projects installed. You should be able to clone a project and do

sudo rake gems:install
sudo rake gems:install RAILS_ENV=test

to get them installed.


Having installed gems using the above, the groovy nokogiri started complaining that it was built against 1.7.3 but was loaded with 1.7.6, or something. This post, which is the best-titled post ever, fixed it.

Computer name

Not strictly related to development, but a question that came up for me setting up the new machine: How do I give it a good name?

Other tools

After all of the above, you should have a working environment for coding and running rails apps. There are several other tools I’ve come to rely on; here’s a few:

  • Textmate
  • The adobe suite, especially photoshop
  • xScope, a fantastic layout toolbox
  • SequelPro, a mysql client. This is handy for accessing databases via ssh tunnels.
  • growl
  • Firefox, with pixel perfect, web developer toolbar, and firebug, found here
  • OmniWeb, OmniFocus, and OmniOutliner Pro, from the omni group
  • For irc, colloquy or lime chat
  • I use DevonThink Pro Office for a kind of brian trust, but not as deeply as I might;
  • For time tracking and invoices, Billings
  • Some kind of virtualization, for testing in windows and IE. I’ve been using parallels, but am trying VMWare Fusion. I’ve also heard good things about Sun’s VirtualBox.
  • Pathfinder for finder goodness
  • I’m using Jolly’s Fast VNC for accessing my old machine remotely, via ssh
  • And, stepping out of my dev hat, Movie Magic Screenwriter, iWork, and the fantastic Scrivener

deploying php with capistrano

Capistrano is to deployment what a spatula is to scrambled eggs. It’s mostly thought of as a rails tool, but it works for any code you need to export from a source-control repository to a server on a regular basis.

Php, for instance. I’ve got a rails site that uses an open-source php shopping cart (I know), and as part of a server move and overhaul of deployment processes, I set it up with cap.

Mostly, deploying something other than rails with cap is a matter of subtraction. First, capify your app; go to the root directory and type capify .

Then, you’ll need to create a config directory off of the root, and a deploy.rb inside of that.

Here’s basically what the deploy.rb should look like: set :application, "myapp" set :repository, "my_repository_url"

role :web, "my_server_name" #eg "" or "123.456.789.10" role :app, "my_server_name" role :db, "my_server_name", :primary => true set :user, 'my_deployment_user' set :use_sudo, false

set :svn_username, 'my_svn_user' set :svn_password, 'my_svn_pwd' set :svn_repository_url, 'my_repository_url' set :checkout, 'export' set :deploy_via, :export set :deploy_to, "/path_to/#{application}" set :shared_dir, "shared" set :log, "#{shared_dir}/log" set :etc, "#{shared_dir}/etc"

namespace :deploy do task :restart do # no need to restart the app - it's php! end end

and that’s it. I’ve got a couple of duplicate lines in there, and if I were slightly less lazy I would have figured out which ones can be removed before I posted this. Alas, such is not the case.

You can then go to the root of the app and type cap deploy and it’ll deliver the latest version to the server.

By default cap tries to restart the server and/or mongrel after it updates the code. With php that’s not necessary; the recipe above just overwrites the default restart task. You could also just say cap update_code which wouldn’t try to restart the server, or some other probably better solution.

running rake from cron

Quick tip, mostly for myself:

I’m moving a site to a new server. I’ve got several cron jobs set up to do things like delete caches, rotate logs, backup the db, etc. Most of the code for those tasks is written as rake tasks, so it’s nice, readable ruby code and included in the code repository for the project.

The tasks weren’t working on the new server. Here’s a few things I did to track down the problem, from ps ax | grep cron : yep, cron is running * * * * * /bin/echo “hello world” >> /mydir/crontest.txt as a cron task: yep, cron is running for my user * * * * * cd current_path && rake my_task > /mydir/crontest2.txt 2>&1 : that gave me the error message “rake: command not found.”

“rake mytask” was working from the command-line, but not from cron; I’m guessing cron doesn’t load up the same env stuff that my user does. So, I set up the cron task like so: 1 * * * * bash /var/www/vhosts/myapp/shared/scripts/

and looks like so:

cd /app_curr_dir /usr/local/bin/rake mytask

And that works like a charm. So if you need to do some maintenance tasks on a schedule, that’s one nice way to handle it.

Non-profits in Second Life – Best Practices

Come by the Nonprofit Commons in Second Life tomorrow for a presentation and discussion of a new paper on best practices for non-profits in the virtual world. More info here. You can read the paper here.

Easy Reporting with Ruport and Chronic

One of the five minute lightning talks at a recent tampa.rb meetup:

Testing for URLs with rspec

I’ve become a big fan of rspec, and the idea of testing models, views and controllers independently of each other. View testing has for me tended to get short shrift, though; there’s not typically a lot of code in there, and who cares what it looks like, right? (kidding)I recently changed how authorization and authentication were handled on a project, though, so I really needed to make sure admin links only appeared for admins, etc. So, what I needed was a matcher for urls; does it have one in this case? Not in this other case? There’s not a url matcher built in to rspec, so I wrote one. Here it is, in case it helps you:

module ViewMatchers

A custom matcher to see if an expected url is included in the response. This one checks# the url itself, not the hyperlink text

class HaveLinkTo

def initialize(expected)

@expected = expected


def matches?(response)

result = false

@actual = response.body

@actual =~ /(<a\s+href="(http:\/)?(.?)#{expected}">\s((\n|.)+?)\s*<\/a>).?/


def failure_message

"expected #{expected.inspect}, got #{actual.inspect}"


def negative_failure_message

"expected #{@actual.inspect} not to include a url of #{@expected}"



attr_reader :expected

attr_reader :actual


A custom matcher to see if an expected url is included in the response. This one checks

the hyperlink text, not the url

class HaveLinkedText

def initialize(expected)

@expected = expected


def matches?(response)

@actual = response.body

@actual =~ /(<a\s+href="(http:\/)?(\/.+?)">\s((#{expected})+?)\s<\/a>).?/


def failure_message

"expected #{expected.inspect}, got #{actual.inspect}"


def negative_failure_message

"expected #{@actual.inspect} not to include a url of #{@expected}"



attr_reader :expected

attr_reader :actual


def have_link_to(expected)


def have_linked_text(expected)


end</a\s+href="(http:\></pre> Save that into view_matchers.rb in your /lib dir, and put this at the top of your spec_helper.rb: <pre> <code> config.include(ViewMatchers)

Then, in your view specs you can do things like:

response.should have_link_to(new_user_path)

response.should have_linked_text("New User")

Which is about 90% of the sort of testing I need to do with my views, so I hope that’s helpful to you.