Text

· · to read

This was two years ago:

You’re correct, the routing mesh does not behave in quite the way described by the docs. We’re working on evolving away from the global backlog concept in order to provide better support for different concurrency models, and the docs are no longer accurate. The current behavior is not ideal, but we’re on our way to a new model which we’ll document fully once it’s done.

Heroku ought to have fixed this by now.

Text

· · to read

With the Rails 3.1 Asset Pipeline, there’s the rake assets:precompile command which precompiles assets into public/assets along with a manifest.yml file which rails uses to put the paths to the assets in its templates. Precompiling generates a few files, which can clutter commit logs if they’re committed. For this reason I might add public/assets to my .gitignore and build them on the server, rather than committing them to git and uploading them. Or, if the server had trouble compiling them, I might precompile them locally, and scp them up rather than committing them to git, because they can make a lot of noise in my git logs.

On Heroku, though, git is the only way to deploy. So if I’m having trouble having heroku precompile them, I need to commit them and push them via git. This could clutter up my commit log.

There is a way around this, though: use a branch! If I create a branch just for heroku, and just commit them to the branch, I can keep my commit logs free of changes to public/assets.

Here is a sketch of this process:

  1. Add public/assets to my .gitignore and commit it
  2. Create a heroku branch with git checkout -b heroku
  3. remove public/assets from my .gitignore and commit it. This just affects my heroku branch.
  4. Run RAILS_ENV=production rake assets:precompile there.
  5. Run git add . and git commit -m 'precompile assets' to commit the files to my heroku branch
  6. Run git push heroku heroku:master to push my heroku branch to heroku as master (heroku only uses the master branch)
  7. Run git checkout master and continue development on my master branch.

A deploy rake script could be used to automate this.

The heroku branch wouldn’t need to be pushed to github, because it doesn’t contain any information that can’t be regenerated. The only reason the history would need to be preserved is so it can be cleanly pushed to the heroku app. Fortunately, if the local repo was lost, it’s possible to pull from the heroku repository. Heroku shouldn’t be used as a place to store git repositories because the lifecycle for a heroku app is often different than that of a repository. For this purpose, though, the usefulness of the old assets commits is tied to the life of the Heroku app so it works out well.

Text

· · to read

I’m developing a Rails site that uses MySQL and runs on Heroku. I’m using Xeround for the database, which has a free trial. Xeround is a database PaaS (Platform as a Service) that runs on several places, including Amazon Web Services in their U. S. East region, which is where Heroku runs. Running it in the same place where Heroku runs gives it a low latency.

To set up Xeround, sign up for an account and set up a database instance in the AWS U. S. East region. Go to the page for the database instance, and you will see the username and the database URLs.

Rails reads its database configuration from config/database.yml. Heroku overwrites config/database.yml with a file it generates from the DATABASE_URL configuration variable. The configuration variable uses the database driver name as the network scheme (e. g. mysql://). There is more than one mysql driver for Rails; the one suggested in the Rails Guide is mysql2.

To use mysql2 as the database driver with Xeround, use the following for the DATABASE_URL configuration variable:

heroku config:add DATABASE_URL='mysql2://{{username}}:{{password}}@{{hostname}}:{{port}}/{{dbname}}'

The username, hostname, and port number can be seen on the DB Instance Manager page on Xeround. The hostname and port are under one of the three DNS Names; I picked the top one. The password is what was entered for the database password during signup. The database name is the name of the database to be added using PHPMyAdmin.

The driver also needs to be included in the Gemfile. To include it just for production, use:

group :production do
  gem 'mysql2'
end

After adding this, run bundle install, commit your changes, and push to Heroku.

The database still needs to be created. To create the database, click on one of the links under DNS Names on the DB Instance Manager. This brings up PHPMyAdmin. Enter the database password and log in. Then create the database, with the same name used for the DATABASE_URL configuration variable.

Now that the database has been created, the DATABASE_URL is set, and the Gemfile is updated and pushed, you should be able to migrate the database by running heroku run rake db:migrate.

I’m using the latest version of Rails (3.1.1) on Heroku’s cedar stack.

It will be interesting to see how well Xeround works for this project. There are other MySQL hosting options for EC2 if I need them, and migrating is fairly simple.

Text

· · to read

I started building a Rails 3.1 app that runs on Heroku using the Cedar stack. In this app I really want to take advantage of the Rails 3.1 Asset Pipeline. I’m using CoffeeScript, Sass, and Compass. The former two come with Rails 3.1 but I needed to add Compass myself. I used the instructions here, but used the latest version of Compass because it now works, and I added a check in the initializer to see if sass was loaded. The check in the initializer is needed because Heroku only runs with the asset gems from the Gemfile when it compiles the assets, and it only compiles the assets when a new slug is loaded. So what happened is that the Rails 3.1 initializer, sass.rb, tried setting a configuration parameter in sass when sass wasn’t loaded.

Here’s the relevant code. The asset section of my Gemfile now contains compass:

group :assets do
  gem 'sass-rails', "  ~> 3.1.0"
  gem 'coffee-rails', "~> 3.1.0"
  gem 'uglifier'
  gem 'compass'
end

…and I added config/initializers/sass.rb:

if Rails.configuration.respond_to?(:sass)
  Rails.configuration.sass.tap do |config|
    config.load_paths << "#{Gem.loaded_specs['compass'].full_gem_path}/frameworks/compass/stylesheets"
  end
end

It uses respond_to? to see if it there is a sass configuration object.

Right now I’m using Compass to set a border radius.