Creating a staging environment on Heroku

If you’re hosting your app on Heroku (possibly even if you aren’t) it is a good idea to create a staging environment also. Heroku has docs on this but the short version for a new app is:

  • heroku create staging-app-name --stack cedar --remote staging(if the app is already on Heroku, just add the remote: git remote add staging git-url-on-heroku)
  • git push staging master
  • heroku rake db:migrate --remote staging
  • heroku rake db:seed --remote staging

Hopefully you have a staging environment set in config/environments/staging.rb so:

  • heroku config:add RAKE_ENV=staging --remote staging
  • heroku config:add RAILS_ENV=staging --remote staging

If you want to push a different branch to staging such as develop:

  • git push staging develop:master

Once staging is set, create the production app in the same way:

  • heroku create app-name --stack cedar --remote production
  • git push production master
  • heroku rake db:migrate --remote production
  • heroku rake db:seed --remote production

Heroku error with conditional rb-fsevent gem

Using the guard gem to run tests etc in your Rails app normally requires some form of file system monitoring.

The monitoring will be OS dependant and rb-fsevent is the gem for OSX. This can be added to the Gemfile conditionally with:

gem 'rb-fsevent', :require => false if RUBY_PLATFORM =~ /darwin/i

Unfortunately when you next push to Heroku you are likely to get an error along the lines of:

This is due to Heroku not allowing conditions in the Gemfile, even in the dev group.

The alternative is to put the gem in it’s own group:

And on non Mac systems run bundle install --without darwin (this only needs to be run once, the without setting is remembered for future bundle installs). Then for Heroku run heroku config:add BUNDLE_WITHOUT="development test darwin"

Don’t forget to add –remote remote_name if you are pushing to a remote other than heroku (e.g. heroku config:add BUNDLE_WITHOUT="development test darwin" --remote staging) and don’t forget to merge your amended Gemfile into master before running git push heroku master.

Use multiple accounts with Heroku is a plugin for Heroku to allow you to use multiple accounts, e.g. work and personal.

To install: heroku plugins:install git://

Then set up each account:

  • heroku accounts:add personal --auto
  • heroku accounts:add work --auto

Set your default: heroku accounts:default personal

Then to switch account for an app: heroku accounts:set work

Optional Parameters in View Partials

It’s generally good practise to pass variables to view partials using locals rather than littering your code with @variables.

This allows better reuse of the partial.

To make the locals optional, provide default values if they are nil or undefined. I have seen many recommendations to do this with a test for defined?

According to the rails api this will not work and local_assigns.has_key? should be used.

My preference is to use ||=

With 2 caveats:

  • If the default value is nil or false the right hand side of the expression will always be evaluated. I can live with this as I think the any effect on performance will be insignificant.
  • The second caveat is when the default is true. The above statement would convert a local passed in as false to true which is obviously not the intent. Instead, for default values of true, this should be used.

Rails 3.1 on Heroku, TLDR Version

Create the app

  1. If not installed, install PostgreSQL
  2. rails new app_name -T -d=postgresql
  3. cd app_name/
  4. rvm --create --rvmrc 1.9.2@app_name
  5. rvm rvmrc trust
  6. Edit .Gemfile
  7. bundle install
  8. createuser -P -S -R -d app_name (no to ‘Superuser’ and ‘Create roles’, yes to ‘Create databases’)
  9. rake db:create
  10. Create procfile in app root.
  11. foreman start and check

Push to Github

  1. Edit .gitignore
  2. git flow init
  3. git add .
  4. git commit -m 'Project skeleton'
  5. Create app_name on Github
  6. git remote add origin
  7. git push -u origin develop
  8. git push -u origin master

Push to Heroku

  1. heroku create app-name --stack cedar
  2. git flow release start '0.0.1'
  3. git flow release finish '0.0.1'
  4. git push --all
  5. git push heroku master
  6. heroku run rake db:seed
  7. heroku open

Does Email Obfuscation Work?


It seems to be common wisdom that if you put your email address on the web in plain text you will get spammed (more). There are various ways to try and hide an email address from various crawlers whist still displaying it to visitors, most involving javascript and relying  on the crawlers not having javascript or not having the script to un-obfuscate your email.

My requirements for any solution are, in order of importance:

  1. A clickable link.
  2. Gracefull degrade for users without javascript.
  3. Users should be able to copy the email address to the clipboard.
  4. It should be easy for me to insert an email address on a page.
  5. It should reduce spam.

A standard <A> tag with a mailto link satisfies the first four requirements but doesn’t help reduce spam. An address written as ‘name@*removethis*’ will probably defeat all the crawlers but fails the first three requirements and is painful for your visitors.

Silvan Mühlemann did some research between 2006 and 2008. He found three methods that stopped all spam but, to different extents, don’t meet the first four requirements. more interesting to me is he found using ‘name AT domain DOT com’ drastically reduced spam as did building the address with javascript.

With this in mind my current preference is to enter an email address as:

Then call a de-obfuscate function on document ready

This provides a clickable and copyable link to most visitors and degrades to ‘name AT domain DOT com’ for those without javascript.

I suspect that this method will cause the least pain for most visitors and stop some of the spam but it depends on how much the crawlers have moved on since Silvan’s test. One way to find out is to rerun the test.

I’ll just use the top 5 results from Silvan’s test and add plain text for comparison purposes. I intend to let the test run but will report back when I get something statistically significant. If you know of any other tests running or run recently let me know and I’ll include links at the end of the post, you can mail me at :).

Using plain text


Using AT DOT

email: ad AT johnplummer DOT com

Using AT DOT and javascript to de-obfuscate


Using code direction

email: moc.remmulpnhoj@dc

Using style=”display:none”


Using ROT13

email: rot mail

Installing Postgresql and pgAdmin


The default database for Heroku is PostgreSQL and, while you could use SQLite for development and Postgres for production, there are some inconsistencies between the two. Ideally you would use the same version of the database server but currently Heroku uses version 9 for dedicated databases and 8.3 for shared databases and seem to recommend you install the latest version for development.

Install Postgres with Homebrew with brew install postgresql and follow the instructions after the install to initialise a database.

initdb /usr/local/var/postgres

The database server can be set to start at login with

mkdir -p ~/Library/LaunchAgents
cp /usr/local/Cellar/postgresql/9.1.1/org.postgresql.postgres.plist ~/Library/LaunchAgents/
launchctl load -w ~/Library/LaunchAgents/org.postgresql.postgres.plist

But I prefer to add aliases to .bashrc to start and stop the server:

alias pgs='pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start'
alias pgq='pg_ctl -D /usr/local/var/postgres stop -s -m fast'

Postgres can be managed with the command line utility psql but, as much as I like the command line, I don’t really want to have to write SQL to edit or remove a user role. PgAdmin is a free GUI for Postgres management. Once installed, ensure the Postgres server is running then run pgAdmin and connect to the server.

In the server properties add a name for the connection and add your login as the username.

Server  1

pgAdmin provides the management tools you would expect.

PgAdmin III


Setting up Rails on a Clean Install of Mac OS X Lion

I realise that OSX does not have a registry to clog up but I have just reinstalled Lion on my Macbook Air; probably a hang up from Windows. This is a checklist for installing Homebrew >> Rails.

  1. Install XCode 4.1 (There are issues with the 4.2 compiler and certain rubies and gems)
  2. Install Homebrew
    2. /usr/bin/ruby -e "$(curl -fsSL"
  3. Ensure Homebrew apps are in path before Mac apps
    1. export PATH=/usr/local/bin:$PATH or edit /etc/paths
  4. Install Git
    1. brew install git (thanks Brendan)
  5. Install SSH keys
    1. Generate or copy from ~/.ssh from a backup.
  6. Install RVM
    2. bash < <(curl -s )
    3. Add [[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"  # This loads RVM into a shell session. to bash_profile
    4. Restart shell
    5. Run rvm | head -1
  7. Install latest Ruby and set as default
    1. rvm install 1.9.3 (make sure you are using Xcode 4.1)
    2. rvm --default use 1.9.3
  8. Install Rails
    1. gem install rails

I keep all my .config files in Dropbox and run a bash script to create aliases in my home folder.


Rails default scripts and jquery-rails

I recently had an issue in a (3.0.7) rails app where link_to some_path, :method => :post was calling the action associated with GET, this was caused by not having a link to jquery_ujs.js (I’m using jquery so don’t want rails.js) in my html output.

Googling turns up a number of suggestions to add jquery_ujs.js and the other jquery script files to the default javascripts by amending config/application.rb. This works ok but it’s not ideal as you probably want minified versions of the files in production and non minified in development.

Digging into the jquery-rails gem reveals railtie.rb:

This sets the default scripts before config/application.rb is run. Unfortunatley with application.rb as it is generated if you run rails new with the -J switch (you probably don’t want prototype if you plan to use jquery) these defaults are overridden. Commenting out

From config/application.rb allows the jquery-rails scripts to load but doesn’t allow you to add to the defaults. I did submit a pull request amending the railtie to run it’s code on before_initialize (after config/application.rb has been run). This allowed defaults to be set and the jquery defaults appended but as Indirect pointed out, this prevents you overriding the jquery defaults in application.rb.

The way to add your own scripts is to append them to the defaults using:

This works but there are 2 related issues; jquery_ujs.js should be the last script loaded as it needs to hook into any submission events for ajax elements and it can’t unless scripts for those events are loaded before it.

With the solution above we have application.js (added by Rails) and our scripts loaded after jquery_ujs.js. Our scripts can be placed first by changing application.rb to:

This still leaves application.js loaded after jquery_ujs.js but that should be fine as long as there aren’t any submission events scripted in it.

Using the railtie to set the default scripts then allowing you to append or override these defaults is a neat solution by the jquery-rails gem, unfortunately it doesn’t seem that many know about it as there seems to be a lot of advice to add the jquery script files directly in config/application.rb. It looks as these issues will go away in Rails 3.1 anyhow.