Seems needlessly angry about what is ultimately a decent if imperfect source of entropy, and a good illustrative example for the general public
HN user
dherls
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.
I like how the article uses "Googling" as a verb meaning to shut down a service
I think the sandwich demo is really good. Once you establish the sandwich idea you can start zooming out to OK now you have a cook making multiple sandwiches, now you have a whole kitchen, and use that to talk about levels of abstraction and how SWEs go from solving one specific problem to more general problems by reusing techniques
I think the "joke" is if the US government orders a company to hand over that data, the fact that the servers are physically in the EU won't stop anything
A solution could be enforcing hardware keys for 2FA for all maintainers if a package has more than XX thousand weekly downloads.
No hardware keys, no new releases.
Another scummy tracking move from Meta, shouldn't be surprised.
In general I think browsers should prevent websites reaching out to localhost without explicit opt-in from the user.
With Java, there are a lot of usability issues with checked types. For example streams to process data really don't play nicely if your map or filter function throws a checked exception. Also if you are calling a number of different services that each have their own checked exception, either you resort to just catching generic Exception or you end up with a comically large list of exceptions
I'm confused why it's encrypted as a JPEG image per frame instead of one AES encrypted video file. Since the same AES key is used for each frame it wouldn't add any additional security imo
Charitable, use of system level randomness primitives can be audited by antivirus/EDR.
I was thinking that one solution might be to specify that the "justification" also has to be a justified true belief. In this case, the justification that you see a cow isn't true, so it isn't a JTB.
Of course that devolves rapidly into trying to find the "base case" of knowledge that are inherent
These interviews can identify candidates with strong problem-solving skills and logical reasoning abilities.
I would disagree with this premise. Leetcode identifies people who have just finished cramming for Leetcode questions. You don't need logical reasoning abilities to solve Leetcode, just encyclopedic knowledge of algorithms and data structures