Julik Tarkhanov

I will be delighted if you can pick up my implementation and drive it to completion, I won't have time in the coming months to do it.

We already have a leaky-bucket rate limiter which is Postgres-based, it works quite well. If we were to open-source it, could good_job take it on as a dep?

It is described here http://live.julik.nl/2022/08/the-unreasonable-effectiveness-of-leaky-buckets and roughly does this: ```ruby def fillup(n_tokens) conn = ActiveRecord::Base.connection # Take double the time it takes the bucket to empty under normal circumstances #...

@sergiodj thank you so much for this!

The problem is that a ZIP file which has been "chopped off" at the end is likely not to unarchive well, because the list of files inside the ZIP comes...

That should actually work if you surround your call to `write_deflated_file` with a block with a `rescue`. If you do that, zip_tricks will ~move on to the next file and...

> "compression" option for `zipline` method, maybe? that is for @fringd to ponder 😆 The feature would be nice, indeed - I'd wager it would have to be added in...

For those pondering "heuristic" choice between using stored or deflated modes, here is something that could work nicely. It will monitor how well the input compresses (you could also pick...

@Urist-McUristurister @suhastech @fringd Now that the zip_tricks situation has been resolved - maybe we should think about an API for this? I've added a feature to zip_kit which excludes the...

Storage backends like S3 do, but it is not guaranteed - also S3 will not respond to a HEAD, only to a GET - you will need to do a...