I find Heroku + DJ + HireFire so much simpler, either using that handle_asynchronous method, or just called delay.my_method(*args) is brilliant. No need to think about isolated code or credentials due to the environment variables that are already set on Heroku.
I should look in to integrating Navvy and Resque as well.
The isolated code issue has been a big issue, and we're addressing this through calls like merge_gem(), and soon merge_mailer(). It's a challenging task, and we see the gaps, but we're improving every day.
Runtime: this is also a top priority. We're working with each and every customer to ensure that their workers execute quickly. 3 seconds vs 30-60 is totally unacceptable and we won't leave you hanging here.
Queue speed: we're prototyping alternatives to http queuing which will dramatically speed up queue times.
This is just the tip of the iceberg for roadmap... Great work on HireFire. I see cases for both. Potentially massive parallelization on SimpleWorker (hundreds if not thousands of concurrent jobs), advanced scheduling needs, etc.
Anyways - we're listening - so any and all feedback is well received. If anybody has needs outside HireFire, in conjunction with, or otherwise, shoot me a line and we'll get you up and running at no cost to start.
Chad Arimura chad[at]simpleworker.com
I think for me the hardest part was getting it to work the first time, waiting quite a while for the jobs to run to see if I managed to get it to work. The merge_gem is a huge improvement, though, handling credentials and re-connecting databases and other things are quite a hassle to set up (imo). I have to say that once it's all set up, and if the 30-60 start-up issue is gone, that it does seems like a beast for processing a lot of jobs concurrently and is exciting.
I'm definitely still looking forward to seeing future progress of SimpleWorker. So please do keep up the good work!