> People will claim real harms but the connections are spotty at best.
This is a wild claim because it's trivially provable. There's been tons of reporting around the effect they have on the immediate vicinity, and that's without even getting into the unknown long-term effects.
Is every single mad person doing investigative reporting and / or living next to a data center? No. But something doesn't have to personally affect me to know it's harmful.
There's a sign next to a bridge that says "Weight Limit: 10 tons". Calvin asks how they know the limit and his dad says they build the bridge, then drive progressively heavier trucks across it until it falls down. Then they rebuild it exactly how it was and put up the sign for the how heavy the last truck was.
Sure, where you draw the line will vary between projects. As long as its exact placement doesn't matter too much.
For me personally, I tend to draw the line at write operations. So in your example, I'd want a dry run to verify the permissions that it can (if I expect those to be a problem). But if that can't easily be done without a write, then maybe it's not worth it. There are also situations where you want a dry run to be really fast, so you forego some checks (allowing for more surprises later). Really just depends.
For little scripts, I'm not writing unit tests- running it is the test. But I want to be able to iterate without side effects, so it's important that the dry mode be as representative as possible for what'll happen when something is run for real.
I like this pattern a lot, but it's important that the code in the dry path is representative. I've been bitten a few too many times by dry code that just runs `print("would have updated ID: 123")`, but not actually running most of the code in the hot path. Then when I run it for real, some of the prep for the write operation has a bug / error, so my dry run didn't actually reveal much to me.
Put another way: your dry code should do everything up until the point that database writes / API calls / etc actually happen. Don't bail too early
We recently welcomed a new baby and have been discussing whether she'll ever learn to drive. I love bets with long time horizons, so we put together a survey so friends and family could pick a side. We kept thinking of fun questions to ask, so it grew into the survey I've linked above, which we're opening to the public.
It's short, fun, and totally informal. Thanks for looking!
This was originated (or at least popularized) in an episode of Archer from season 1. It remains maybe my favorite 5 minutes of comedy ever out to screen. It's just so tight!
If you're interested in some (light) science behind rivalry and/or the Michigan/OSU rivalry, I highly recommend the documentary "Rivals: Ohio State vs. Michigan". It's a fun look into why a rivalry drives better performance.
I found this to be an interesting new direction from Airtable, a product I've really enjoyed. I hope it doesn't muck up the core functionality too much.
I mean, there are 3 equally valid ways to write an if statement: `test`, `[`, and `[[`. In the case of the latter two, there are a mess of single-letter flags to test things about a file or condition[0]. I'm not sure what makes them "fake syntax", but I also don't know that much about bash.
It's all reasonable enough if you go and look it up, but the script immediately becomes harder to reason about. Conditionals shouldn't be this hard.
My rule of thumb is that as soon as I write a conditional, it's time to upgrade bash to Python/Node/etc. I shouldn't have to search for the nuances of `if` statements every time I need to write them.
I've been a happy starship user for a few years at this point (after a long time with oh-my-zsh). For me, it's killer feature is the `starship.toml` file. Gone are the days of arcane bash escape sequences to style the prompt. It's a well-documented shape and easy to reason about. So no matter if you got maximalist or minimalist for your, it's easy to tweak. That rocks.
I have no idea, but it's a constant source of frustration. Sunglasses also lead to failed reads, which makes a little more sense but is just as frustrating. "Here's a new phone. It works great except you can't use it quickly if you're wearing sunglasses. Sorry!"
This is a wild claim because it's trivially provable. There's been tons of reporting around the effect they have on the immediate vicinity, and that's without even getting into the unknown long-term effects.
Here's a decent piece, but there's plenty more out there if you look at all: https://www.youtube.com/watch?v=t-8TDOFqkQA
Is every single mad person doing investigative reporting and / or living next to a data center? No. But something doesn't have to personally affect me to know it's harmful.