THOUGHTS in resque_stuck_queue-0.0.13 vs THOUGHTS in resque_stuck_queue-0.1.1

@@ -3,21 +3,18 @@
   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?
+
+rm redis locking (since it works by keys now, no need for it, recover/trigger ping pong).