sideofbacon

4 ms·

1.
by sideofbacon 1y ago
Who? Everyone I recognize is continuing to contribute. https://github.com/rubygems/rubygems/graphs/contributors?fro...
2.
We enabled Ruby's YJIT on GitHub.com today(ruby.social)
5 points by sideofbacon 3y ago|0 comments
3.
by sideofbacon 3y ago
I'm the GoodJob author. Here's the class that is responsible for implementing Postgres's LISTEN/NOTIFY functionality in GoodJob: https://github.com/bensheldon/good_job/blob/10e9d9b714a668dc
4.
“What the fuck are you talking about?”: The story of NodeTiles(island94.org)
2 points by sideofbacon 4y ago|0 comments
5.
by sideofbacon 6y ago
Yay!
6.
by sideofbacon 6y ago
That was mentioned in another thread. I have two thoughts about it: - Going off of my own experience, I've never used PgBouncer and I've worked on some moderately sized applications (1s of millions of users). So I could say "
7.
by sideofbacon 6y ago
Thanks! That's really helpful context.
8.
by sideofbacon 6y ago
GoodJob author here. I'm curious why you're specifically looking for listen/notify? I'm trying to prioritize that in the backlog.
9.
by sideofbacon 6y ago
GoodJob author here. The core reason I wrote it was to see how lean/simple I could write a database-backed ActiveJob adapter today. And hope In practice any adapter should _just work_, but also all the other adapters pre-date ActiveJob
10.
by sideofbacon 6y ago
GoodJob author here. Excellent observation. It should work if PgBouncer is using session-level pooling, but not transaction-level pooling. I made a ticket to document this: https://github.com/bensheldon/good_job/is
11.
by sideofbacon 6y ago
GoodJob author here. The reason is that I don't have any production experience with Sidekiq. My target right now is someone, like myself, who would typically spin up a new project with delayed_job or que, and provide a better alternati