Seems to me like the better action would be to implement rate-limiting, rather than complain when people use your resource in ways you don't expect. This is a solved problem.
I can't believe we're going to forever have to live with people who don't speak English as a first language having their written work assumed to be done by AI. It's pretty disappointing.
When the next best option is "serialize", suddenly stringify doesn't seem so bad. I would prefer a silly-sounding but immediately clear function to a more abstract concept.
Great read, and an interesting warning sign about overly-controllable configuration files. If there's no conceivable good reason to to much of this, then the ability to do so becomes bad design that fails to protect your users.
Bisect is a very cool feature that I used once over 5 years ago. The collection of git tools that I use often is very small. I've found that the more experienced I got with git, the less I found myself in scenarios where I needed git's more complex tools.
Tools like direnv gets .env files out of repo paths and improves things a lot. You can integrate secrets management in code, but with that there's still no getting away with the assumption that some kind of auth mechanism exists in your env
I think the joy of working at this scale makes up for that for a lot of people. There are plenty of low-stress, low-impact companies that someone that's bigtech-approved can go to
Saying it's targeted at beginners because it supports MacOS shows a lot of disconnection with what many DevOps people use these days. The year of the linux desktop has yet to arrive, and Mac is king for people in IT (at least in the US)
You didn't also factor in the time to learn Pandoc (and to relearn it if you haven't used it lately). This is also just one of many daily use cases for these tools. The time it takes to know how to use a dozen tools like this adds up when an LLM can just do them all.
I might be misremembering but I think slosh was the failure cause for one of the three failed Falcon 1 flights. It was number 11 out of a pre-flight list of top 10 most likely failure scenarios. Definitely a difficult problem.
No company does things out of the kindness of their own heart. That's just not how enterprise is designed to work, and it is a mistake to ever assume otherwise. Regulation needs to always be the driving force for something like this.
You're right, you are old-fashioned. I love order by phone. Any amount of time I'm sitting at a table trying to get a waiter to notice me and come by just feels like agony. Let me tell you exactly what I want, exactly when I want it.
Part of this is a consequence of Amazon's hesitance towards shutting down old features. They are getting better at this lately, but S3 remains an example of a system with too many ways of doing things simply because they don't want to take the step of eliminating legacy functionality.
People don't use Slack in this way though. I've worked at several organizations where the freshest documentation we had was in Slack. The truest FAQ is when someone actually asks a dev a question in a Slack channel, and not the questions they anticipated being asked when writing documentation. Capturing this in a meaningful way would be highly valuable, and maybe all that takes is feeding it to a RAG based LLM