A few days ago, we experienced some problems with Redis. It occasionally blew up. When we examined the server at those times, we saw interesting things like thousands of open TCP connections on port 6379.

Any reasonably sized Rails application will eventually find itself in need of background job processing. Sending users email, generating reports, and interacting with third party APIs are just a few examples of secondary things that can ideally happen without slowing down web requests. There are several answers to the background job question for Rails, but the architectural differences usually boil down to a choice between threads or processes for concurrency. Resque is one that uses processes, and it’s one we use at Optoro. Several work projects have given me a reason to familiarize myself with the internals of Resque, and as a result I routinely end up supporting my teammates when they have questions about how it works and deploying things that use it. Here is a high level look at how Resque does its magic.

Deploying 100% bug-free code is the Holy Grail of software development. Everyone wants it, but sometimes it seems like an impossible quest. This is increasingly true if you happen to be working on a large project that contains a significant amount of legacy code. We’ve all been there: Sitting at our desks, sweating bullets while pushing the deploy button and praying that none of those lovely green servers on the load balancer dashboard turn red. We develop processes like regression testing in an attempt to avoid those dangerous deploys, but bugs still slip through the cracks. What’s to be done?