other resources:

  http://vitobotta.com/resque-automatically-kill-stuck-workers-retry-failed-jobs/#sthash.oQsaNeb5.dpbs
  http://stackoverflow.com/questions/10757758/find-out-if-a-resque-job-is-still-running-and-kill-it-if-its-stuck

## TODOS

verifications of @config options: raise if no handler, etc.
add daemon example to readme
add a 'resque_stuck_queue/tasks' bit? See tres eg
require 'resque/stuck_queue' instead?
ensure the logging gets flushed into log file correctly? (integration with god?)
add a trap{} to force_stop. ok for overwriting process's trap handlers? use config for that?

fix skeleton recipe https://github.com/shaiguitar/resque_stuck_queue/blame/master/README.md#L103
  raise appname, => :environment, log path

set a redis key instead of doing a manual refresh and have a recover handler. also pass the lag time into the handlers/procs (same semantics)
investigate: why is temple getting triggered? how often? is the enqueing/checking taking too much time?
also, if one queue is bad, does it trigger other queue's handlers? write some tests, asshole.
woes of redis namespace, in regards to Awsm.redis != Resque.redis etc. (which is important for setting the key through @redis)

with lag time, it will continue to trigger, for every heartbeat time it's supposed to tick, find some way to do that, and then maybe add some resolved handler/proc?