xavdid

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.

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.

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.

One of my favorites!

https://www.reddit.com/r/calvinandhobbes/comments/u3dqja/how...

If my cloud provider brings my startup down, it's my problem. If they bring all the startups down, that's their problem.

Stripe publishes a very similar doc: https://support.stripe.com/questions/stripe-shares-or-stock-...

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.

Yes, but it depends on the context.

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!

There's a little more context about the project on my blog: https://xavd.id/blog/post/predicting-the-future/

Not all the way down to 4KB, but https://512kb.club/ matches this vibe

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!

https://youtube.com/watch?v=dNYMQpcqscA

Ah, these are great! f-strings are so powerful, but I can never remember the arcane little syntax. Definitely bookmarking this.

that's fascinating - I've definitely been saying "you've" and "tie". I assumed this was "picks"

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.

https://www.imdb.com/title/tt22937658/

I don't remember if it links to it, but this pairs well with https://cryptopals.com/, which are practical examples of many of these theories.

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.

[0] https://tldp.org/LDP/Bash-Beginners-Guide/html/sect_07_01.ht...

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.

It works occasionally, but unpredictably. Consistently frustrating though

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!"

I honestly don't get why people like Face ID more

Big +1. Face ID fails way more than Touch ID ever did. I know you couldn't your finger with wet hands or gloves, but that didn't come up all that much.

Face ID fails multiple times per day, every day. I can't unlock my phone well in bed, while brushing teeth, while it's sitting on a table not directly in front of me, if I'm in direct sunlight, in a car mount, etc. The only time it's more useful is when I'm already using the phone and need to auth for an app (bank, 1Password, etc). Then it's seamless. It just doesn't make sense as an unlock mechanism, IMO. iPad has the same problem - I can't unlock it if it's on the couch next to me without picking it up and holding it in front of my face.

Face ID would make a lot of sense on a laptop, which is always used in basically ideal conditions for unlocking: straight on view, probably inside, always centered on my face.

I'd love Touch ID on a phone's lock button, but that's not an option. And I'm worried that if it was an option, it would be relegated to the budget phones (like it is on ipads).

disclosure timeline (mm/dd/yyyy)

09/03/2025 - vulnerability disclosed

a security vulnerability and time travel to go with it!

It's great to see them coming back! I adored my Pebble(s). 2 fun stories:

1. Pebble supported 3rd party watch faces based on a file. There was a great little site that let you use a visual UI to build the file and, if done from your phone, upload it right to the watch. Once, when out at midnight beer launch, I made a custom face for the beer and won a little keychain from the brewery. My Apple watch could never.

2. Once time in 2014, I ran into some Pebble engineers at an ice cream shop in Palo Alto, they spotted my watch, they bought my scoop! Fun, weird little Silicon Valley moment.

Whoa, I loved that app! I used to track scores for intramural games in college. the UI was so clean and simple!

Bluesky supports them! If you append `/rss` to any profile, it redirects to a feed. e.g.:

https://bsky.app/profile/xavd.id -> https://bsky.app/profile/did:plc:fp2izjrrcsbsqphlu7f5sixa/rs...

More info: https://openrss.org/blog/bluesky-has-launched-rss-feeds

I'm excited about this! I'll be sticking to Python so I can practice writing maintainable code. I'm also looking forward to keeping up with my explanations of each puzzle, which helps me (and others!) learn a lot.

Everything is here: https://advent-of-code.xavd.id/

I'm unlikely to finish it all in December (the puzzles get hard and I get busy) but I _do_ love the event.

The word "tweet" itself came from a 3rd party developer:

The Iconfactory was developing a Twitter application in 2006 called "Twitterrific" and developer Craig Hockenberry began a search for a shorter way to refer to "Post a Twitter Update."

https://en.wikipedia.org/wiki/Tweet_(social_media)#History

He's done a lot of great work. Selfishly, one of my favorites is narrating the University of Michigan (his alma mater) football hype videos and stadium announcements. Always felt unique and fun.

https://www.youtube.com/watch?v=E1PFH3w_b8g

Mail and Notifications will show summaries instead of str[:x]

While it's true that the first x characters of an email don't always have the most important bits, they're never _wrong_. It's always exactly what's in the email.

I'm worried about cases like this [0], where a summary is inaccurate or misleading. It may not happen often, but it's possible, so I have to be a little skeptical of every summary. Though I can see where AI summaries are a plus, the move from 100% accurate to <100% feels like a big downgrade.

[0] https://mastodon.macstories.net/@johnvoorhees/11288700482217...

Exercism is a great site and I'll be sad if it goes away entirely. It's a really wonderful service and community.

I used it [throughout 2023](https://xavd.id/blog/post/12-languages-in-12-months/) to tour new languages and have been on a deep dive of Rust this year in their [48in24 program](https://exercism.org/challenges/48in24). The UI and tooling is great, there are real humans available to mentor and everything is open source and volunteer driven. They make learning fun and that's no small feat.

Of course, things like this cost money to run, especially when there's so much going on behind the scenes. Sad that the current iteration hasn't worked out financially, but I have every faith in the team that there are good things ahead.