mrzor

As they were previously running client jobs, I can see an attractive side to building up the team experience on new tech using their in-house project rather than on client projects.

Put otherwise, in their previous line of business, it matters to be current with regards to state-of-the-art application development. Where's the harm in experimenting with your 'on the side' app?

Sometimes the forking model have desirable properties.

Numerous past articles covered this in one way or another.

Choosing between SideKiq and Resque is primarily a matter of choosing between forked processes and threads. Retiring Resque and let SideKiq be the present and the future would destroy that choice.

SideKiq, as a threaded impl., can claim some cool benefits : - shorter job launch times (only interesting if you actually run thousands of second spanning jobs a minute) - reduced memory footprint (you probably have little to no amount of thread local storage)

I will venture that the reduced memory footprint is mostly the result of the unfriendly to copy-on-write GC we have to live with using 1.9.

Resque has a clean and simple API and a decent ecosystem. It can and hopefully will evolve into something cooler and more powerful - even if worthy alternatives exist.

Hello everyone !

We recently released jobco, a simple Resque distribution. You can check it out at https://github.com/mrzor/jobco

We attempted to address some of the issues we had with our resque 1.x stack regarding productivity (ease to use both in development, and ease to deploy) and regarding API consistency (rewrote resque-status to keep the Resque API intact).

It doesn't address any of the high throughput issues that were mentioned earlier.

I'm definitely up to help fixing stuff within Resque when appropriate. However, the Jobco project is possibly more appropriate if the feature you're looking after can be provided using plugins, or involves providing better CLI interface to Resque.

You can find out my email address using `git log` on the jobco repo.