From Beanstalkd to Resque
Yesterday I switched over DNSimple from a home grown background processing solution based on beanstalkd and custom code for handling queue messages as jobs to one using Resque. The switch was relatively painless thanks in large part to the assistance of Darrin in getting Resque installed and getting the worker rake task monitored by Bluepill.
The jobs that run are fairly simple: there is a job for creating DNS domains, one for deleting DNS domains, one for creating DNS records, one for deleting DNS records and one for updating contacts at our domain registration partner.
There were several reasons I made the switch: the first is that with beanstalkd I found that knowing what was working and what wasn't in the queueing system was a challenge. This same task is much easier with Resque thanks to the handy rasque-web Sinatra app that comes with it. Determining what jobs failed is so much easier with Resque because it does the tracking for me. The other thing I found was that Resque's framework for defining jobs took away a lot of the headaches that I was having by writing my own mechanism to do this. Although I haven't really needed it yet I also think that Resque's multiple queue support will be a bit easier to work with than beanstalkd's tubes (tubes + em-jack never did work right for me, but that's another story altogether).
I'm on day 2 now of Resque running in production and quite happy with it so far. Given the amount of background jobs that Github executes with it I am not too concerned that I will have problems with my meager load. Having the monitor tools and a nice simple job framework are turning out to be the real wins for me and for DNSimple.
I break things so Simone continues to have plenty to do. I occasionally have useful ideas, like building a domain and DNS provider that doesn't suck.
We think domain management should be easy.
That's why we continue building DNSimple.
Using time tracking to improve your remote working habits
What we learned, individually, from our collective time tracking experiment.
Two years of squash merge
A retrospective of the last two years where we adopted --squash as our default merge strategy for git branches.