I used to do lots of imports using rake on our production-machine. This is quite handy if you have some legacy-data (a CSV-file from an old excel-file etc.) and works super-easy. Until I moved all my apps to heroku: here, long-running is fine if long is under 30 seconds: Then your job gets killed by heroku just like any other long-running request that comes in via the web-interface.

Heroku treats a rake-task just like any other request: if it runy longer than 30 seconds, heroku assumes that your task has gone broke and kills it. But not every rake-tasks will be finished within 30 seconds – if you insist on running these tasks on heroku, there are three things you will need:

• delayed_job: The 30second-limitation does not apply to worker-dynos, so the idea here must be to pass the rake task to a worker dyno instead of letting it run within the standard heroku-loop.
• delayed_task: delayed_task is a very thin wrapper around delayed job. It basically reads in all your rake-tasks and produces a delay: from it. If you now run heroku rake delay:, instead of running the tasks directly, it produces a delayed job with this task and places it in the queue.
• HireFire: You probably don’t want to pay for the worker dyno if you don’t use it. And you definitely don’t want to start it up manually, when you run your rake-task. This is where HireFire comes handy: It hooks into the delayed-job startup-process and starts a worker-dyno if none is running. When the last job has been done, it fires the worker-dyno. Tough life for a worker, but this saves you a lot of money&manual configuration.

Using these three tools together, you can now run your rake tasks on heroku without being hit by a timeout. Be careful though: There seems to be a timeout on the worker-dynos too: When a job runs longer than 15 minutes, it seems as if you get randomly hit by a timeout error. It is always a good idea to make your jobs small (separate one longer job into many shorter ones) and make sure that they can be restarted without breaking things. e.g. for an import, skip data that has already been imported. delayed_job will try to restart the job if it breaks, so make sure that you will eventually get to the end of your tasks.

PS: Just a quick update – the timeout actually did not come from heroku, but was the result of an issue with fog/S3 when uploading huge files. So, actually, no, there seems to be no timeout for workers on heroku.

Just in case you wonder why your spec-rake-tasks are not found – this does not work

group :test do
  gem "rspec-rails", "~>= 2.7.0"
  gem "database_cleaner"
  gem "spork", '~> 0.9.0.rc' 
  ...
end

although it looks obvious on first sight. But now, your spec-tasks are not available in the development-environment and so

rake -T spec

comes up empty.

Therefore

gem "rspec-rails", "~>= 2.7.0", :group => [:development, :test]

is not optional, but absolutely required. The docs do state this explicitly, although they omit why it has to be in the development-group – hopefully this tip prevents other people from having to learn this the hard way like I did when I accidentally removed rspec-rails from the development-group…

2011 came and went without any of the existing javascript-frameworks coming out as a clear winner. For a while, it looked liked sproutcore would get some steam with the gigantic carlhuda getting behind it, but now it looks like the whole project is in flux, with both technical (moving from 1.6 to 2.0 to amber.js to ember.js) and organisational issues. Meanwhile, knockout.js made a strong case, and backbone.js is still just that: A solid backbone. Still confused? Don’t know which one to choose? So are we. Thankfully, Addy Osmani took up the challenge to compare all the greater frameworks by implementing the very same Todo-App in now 11 popular frameworks. The only truth is in code, so let’s give all give a big THX to Addy and head over to the repository to see which style fits you best.