Mavvie

Sounds like my coworkers.

That makes sense, but surely there's a middle ground somewhere between "AI does everything including architecture" and writing everything by hand?

Indeed, the correct term here is nullipotent.

I haven't tried this yet, but I wanted to say I think there's a lot of potential in this space. There's so much friction with the current popular solutions...and yet it's so hard to justify trying some of the newer and less popular ones.

I wish you luck because there are a lot of good ideas in here. Running locally and remote debugger are the most exciting to me.

I'd argue that Tenerife was due to taking off (in bad weather), not landing. But of course, a bunch of planes landing at the same airport without ATC sounds quite dangerous.

This sounds like a very nice compromise actually. I'm surprised it helped with abuse though, since there's a lot of email providers that are easier to create an account with than gmail.

Well, you have to go out of your way to prevent it. The sub-addressing complexity is on the email provider side; ticketmaster doesn't have to do anything for it to work except not reject valid email addresses.

In my experience, most but not all sites will accept "+" email addresses.

I think that's exactly correct. You either do split queries (with more latency) or you do a join (and risk Cartesian explosion). Most ORMs should do this for you.

Wouldn't it cause the cost of consoles to go up and the cost of games to go down, in a way that on average has no significant effect to consumers?

As long as it applies to all companies, why is it an issue?

I don't think that's how it works... It's a checksum, not letting you check if each section is part of the key.

At worst, the key would have some portion less entropy since there's a lot of bits used for checksums.

Can you (or someone else) explain what the alternatives are? How can I write unit tests without mocks or fakes?

I strongly agree with this.

I would add that, at least for me, planning each day out is beneficial as well. When I don't have a plan for a day, I often will sit there, not really doing anything, and not sure what to start doing. This typically ends when I get distracted by something (maybe a question on Slack), and overall leads to some very unproductive days.

Even a simple high-level plan, like "today I want to get these tickets ready for review and work on this RFC", is incredibly helpful for me. A weekly plan may be even more effective, but I struggle to plan that far in advance.

Thank you, I hadn't considered that aspect.

This is pretty interesting. It's not like HTTP needs an intermediate representation, but since cURL is so ubiquitous, it ends up functioning as one. cURL is popular so people write tools that can export requests as cURL, and it's popular so people write tools that can import it.

I wonder if that could be because MySQL 8's replication is backwards compatible but MySQL 5.7's isn't forwards compatible. If so, it makes sense that you're only able to move forward.

That's actually the formula for nullipotency, where applying it 0 times is the same as applying it any number of times.

I believe idempotency is when f(f(x)) = f(x)

GitHub outages have always been fairly common, I don't think that changed since being acquired.

I'm not too familiar with the details here, but probably hit the brakes and stop ASAP? If there could be someone under my car I wouldn't keep driving to "pull over safely".

Great, thanks for the reply!

Huh, can you explain that a bit more for a rust noob like myself?

1. How does it know how to create your Error enum? I guess it's from the #[from]? 2. What happens if your method tries to return something that's not an io::Error or a gz::Error? I guess the compiler catches that? 3. How would you handle doing this for multiple methods in the same file? Would you rename your enum to DecompError or something to avoid conflicts?

Thanks for your post. While it might not be the optimal approach for maximizing profit, I think your Stocketa blog post is absolutely stunning and shows an incredible commitment to quality as well as a very impressive work ethic to spend so much time on it.

If I may ask a question - how did you do it?

I don't disagree, but the quote is from 10 years ago. Long before COVID.

The actual quote:

There's a level of admiration I actually have for China. Their basic dictatorship is actually allowing them to turn their economy around on a dime.

I don't think that's wrong? Although it is certainly in bad taste for a prime minister.

I've only ever done river sailing (including some intentional rudderless sailing), but I imagine in the open seas rudderless sailing isn't really feasible (at least in some conditions). Waves might make it impossible on their own.

No, because they're setting acquired_at which marks it as "handled". You only need FOR UPDATE (SKIP LOCKED) if you want to process the event inside a transaction; but the approach in the article is to just bulk "grab the events and mark them as done, atomically"

Thank you! It was a great article, and definitely pointed out a few things I'm doing wrong in my Postgres setups.

Setting acquired_at on read guarantees that each event is handled only once. After they've been handled, you can then delete the acquired events in batches too (there are better options than Postgres for permanently storing historical event data of unbounded size).

This bothers me. It's technically true, but ignores a lot of nuance/complexity around real-world event processing needs. This approach means you will never be able to retry event processing in case it fails (or your server is shut down/crashes). So you either have to update the logic to also process events where "acquired_at is older than some timeout", which breaks your "handled only once" guarantee, or you can change to a SELECT FOR UPDATE SKIP LOCKED approach which has its own problems like higher database resource usage (but at least it won't process a slow job twice at the same time).

Does pgbouncer tend to run out of CPU? Or just at the large scale this article is about?

So what do you think the disadvantage is of a pull approach? Presumably it's not just better or else tools would use it?

For sure, I agree with you.

I would say that queued jobs being lost is different from an in-flight transaction being auto-rolled-back, but it's not a super important distinction. Like others have said, I think Sidekiq really nailed the free vs premium features and its success is evidence of that.