Heroku, Precompiling Assets and Enviroment Variables

It’s easy enough to set up a staging environment on Heroku and have the environment use your staging.rb at runtime by setting the RACK_ENV  variable to “staging”.

Currently there is a problem if you need anything from your staging.rb whilst the slug is being compiled. I ran into this when I specified an asset host. At runtime, assets that were referenced in the rails code were fine, but all assets referenced in my stylesheets pointed at the asset host from the production.rb.

With the default set up, environment variables are ignored during slug compilation. There is a setting in heroku labs that will load the variables before slug compilation:

As with anything in labs, there are no guarantees, butI have had no problems so far.

 

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

https://github.com/ddollar/heroku-accounts is a plugin for Heroku to allow you to use multiple accounts, e.g. work and personal.

To install: heroku plugins:install git://github.com/ddollar/heroku-accounts.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 http://0.0.0.0:5000/

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 git@github.com:JohnPlummer/app_name.git
  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*domain.com’ 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

email: pt@johnplummer.com

Using AT DOT

email: ad AT johnplummer DOT com

Using AT DOT and javascript to de-obfuscate

email:

Using code direction

email: moc.remmulpnhoj@dc

Using style=”display:none”

email: dn@nulljohnplummer.com

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
    1. https://github.com/mxcl/homebrew/wiki/installation
    2. /usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"
  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
    1. https://rvm.beginrescueend.com/rvm/install/
    2. bash < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )
    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.