dherls

If true, this is next level incompetence from PingCap. Apparently the attackers set up a replication pipeline for a month?!

> We even stood up a replication feed of their own control-plane database using credentials committed in their own repositories — GCP service-account keys and an Azure service principal — and let their infrastructure deliver it to us. Every six hours, for the last twenty-two days of the campaign, from 8 September to 30 September, that pipeline faithfully re-exported every table of the operational heart of TiDB Cloud — tenants, users, API keys, cluster credentials, changefeeds, migrations — and pushed it out.

What is the benefit of building the same website twice with different hostnames instead of using relative links to content on the same domain?

Basic details from post:

* $2.99 one-time fee to register without a phone number

* Only works with Google in-app purchases right now, but they are working to expand to other payment methods

* An ID and Key are generated for these accounts which are used for login

* Maybe future support for removing phone numbers from existing accounts

This whole website appears to be Claude slop articles about Postgres.

Seems needlessly angry about what is ultimately a decent if imperfect source of entropy, and a good illustrative example for the general public

Giving LLM agents direct, autonomous access to a real production databases with write access seems insane to me.

NO ONE, agent or human, should have direct write access to production databases outside of emergency break glass scenarios. This is why we have stored routines and API layers to pre-define what writes are allowed. The facts that agents CAN autonomously write to a database does not imply that they should.

For the point about query optimization, again your agents should not be issuing random queries against a production database. We have had the concept of separate analytics databases with different architectures to support exporatory queries for decades.

The author fails to mention any of the negative effects they experience due to this go version selection. They say that the effect is "viral" but don't give any concrete examples of why it's a bad thing to keep your toolchain up to date

It's much easier to detect a single account abusing your API and ban them/require payment. Trying to police an endpoint open to the internet is like playing g whackamole

Really impressive that it's implemented in < 400 lines of Javascript code and runs so smoothly in my phone's browser (Firefox on Android)

I would definitely recommend not putting complex logic like this in your cron definitions. Much more annoying to find and debug in the future. I prefer to write a short wrapper script that contains the test logic instead and track/version control it

Some of the alternatives that the author suggests (Slack, Discord, Matrix rooms) are so much worse to search for answers in. Stack overflow has many disadvantages, but it is extremely good at being a publicly searchable repository of answers to common questions

Even in the case you mention you really shouldn't be overriding these methods. Your load settings method should take the path of the settings file as an argument, and then your test can set up all the fake files you want with something like python's tempfile package

This blog post talks as if mocking the `open` function is a good thing that people should be told how to do. If you are mocking anything in the standard library your code is probably structured poorly.

In the example the author walks through, a cleaner way would be to have the second function take the Options as a parameter and decouple those two functions. You can then test both in isolation.