The rails native way to do this is to track state in a db row and queuing “next step” jobs as the data changes. This can get verbose especially for smaller pass/fail workflows. However, I find this works better (not worse imo) in more complex workflows as the state is tracked, queryable, can be surfaced in UIs, and resumed “manually” in the event of an outage.

It’s a bad look for the ruby ecosystem. Continuing to rehash, throw mud, and speculate at this point likely harms the greater community more than any “side” would “win”.

If folks understood this better, there would be less reason for software like Huntress' EDR to exist.

Get what ya pay for? If felt extremely expensive at the time but after hearing a few horror stories…

For those who don’t understand why you might want something like this: if you’re doing high enough throughput where eventual consistency is effectively the same as atomic consistency and IO hurts (i.e. redis calls) you may want to cache in memory with something like this.

My implementation above was born out of the need to adjust global state on-the-fly in a system processing hundreds of thousands of requests per second.

Not a single company survived afterwards.

Are you the CEO? If so, gain the buy-in from your cofounder to follow your direction. If not, find a way to get onboard… or probably damage the company with a departure.

The post reeks of privilege.

Go work a manual labor job outside in the sun for a few weeks and tell me how bad tech employees have it. Most of non-tech America is not empathetic to our plights. They’ll probably cheer on the offshoring of our jobs.

Allowing ai to eval() code or execute any sql statement would scare the crap outta me personally.