Doing something about my dodgy vacuum cleaner. The one I have really sucks, mainly because it really doesn’t.

Something going on with my Bluetooth headphones and my Android phone. No problems with either connecting with anything else, but it takes about 5 minutes to connect them together. Very strange.

It seems to me that Patreon would’ve been better off not offering an iOS app and just have a really well built website. I can’t imagine many creators would be discovered via the app. At least for me, it’s always via their work: their YouTube videos or podcasts. Apples shenanigan’s not worth it.

Wow. Now I’m getting messages from creators about how their revenue will be affected by Apple’s attempt to extract their pound of flesh from Patreon.

Boo! Dick move, Apple! You so desperate for a service narrative you’d stoop to this level? 👎

Hopefully enough supporters sign up via the web that the impact of this is minimal.

Must be the types of podcasts I tend to prefer, but I do get a bit put off by shows where the hosts are clearly reading either a script or a really detailed outline (like one might have it they’re giving a conference talk), and trying to present it as casual discourse. Through in some less-than-funny humour, and it’s just a little — as the kids say — cringe.

That’s not to say that the podcasts are bad. They’re still informative and interesting to listen to. It just feels like a bit of a trope now.

Excursion today. We’re going to get a tour of a data centre. Ought to be very interesting, at least to me, given that don’t often get to seen them as part of my day to day.

Long day today, playing the role of taxi driver for most of it. Did manage to get two-thirds of a game of mini golf in though.

The trouble with the future is that it eventually arrives.

It’s an interesting phenomenon to find yourself discovering quirks or behaviours of a large software system that you had a hand in designing and building yourself. You can’t really classify them as bugs. More like behaviours you never expected, leaving you to say “that’s strange.”

So MacOS Sequoia is going to introduce weekly nag prompts for app permissions, with no way to just grant permissions for an app perpetually. Hey, Apple: why do it weekly? Why not ask every 15 minutes? Why not blank out my screen and show it as a modal? That way, you can wrestle my attention from what I’m trying to do just so you can get my answer that yes, once again, the app that I launch every day to do my work can continue to have the permissions I granted it years ago.

Does Apple not trust their users? It’s bad enough that they ask whether an app can continue to send notifications after an update, but doing this seems like they think there are zero users of their OS that know what they’re doing. Not saying that everyone needs to be MacOS power-users, but rolling out designs like this without providing an escape hatch for those that are is not only annoying, it’s borderline offensive.

I’m sorry if this comes off as a little strong. But these usability paper-cuts add up.

Want an easy way to break a code editor? Accidentally click the “expand all” button in a project tree panel that has loads of external modules and dependencies. Bonus points for anyone with node_modules, although I think that might be playing on easy mode. 😀

Needed to do something to one of our databases, and I was preparing a multi-step process before I decided to check whether one of my admin tools could help. Turns out the tool had a command to do just the thing I needed to do. Thanks, past me!

It’s disappointing to see Google discontinue their Chromecast line. There are certain use-cases that a small, simple, dongle is perfect for that an overpriced streaming box is not, such as travelling or setting up a dumb TV projector for a meeting room. Plus, an underpowered device makes it harder for app developers to load their Chromecast UI with rubbish (although they try).

I don’t use my Chromecast anymore, but I did for a long time. It was the only way I watched TV. I’m sad to see it go, but I guess the Google graveyard comes for all in the end.

I’ve been using Album Whale as a song-based bookmarking service more and more recently. When there’s a specific track I want to listen to, it’s much easier to recall it from Album Whale, rather than try to navigate Spotify’s annoying UI (Spotify is just unable or unwilling to make this easy to do).

👨‍💻 New post on AWS over at Coding Bits: Force Deleting AWS Secrets

Continuing my exploration of mutual TLS for secure inter-service communication. Wondering how best to include in the certificate what type of service the certificate is for. The best options I can think of is either using the subjectDirectoryAttributes extension, or just using a CN encoded as a URI, with the scheme encoding the type.

This is one of those trade-offs between an approach that’s easy, vs. an approach that’s “correct”. I imagine the “correct” way to do this is to add an attribute to the certificate indicating the service type. This is probably what this extension is for, and even without using it, I don’t think there’s anything about the X.509 format which would prevent me from just adding a custom attribute, apart from the various RFC’s that govern how certificates are exchanged online (this is for internal services, so I can’t imagine that being a problem.)

But even so, I’m learning towards using the URI. Although I can probably organise an OpenSSL config file which enables support for this extension — something that is not guaranteed — I’m worried that if I were to start handing off certificate creation to others, they would need to do likewise. Sure, tooling could help here, but we’ll all need to support that too. Not to mention a vast majority of the documentation out there is about using OpenSSL for creating HTTPS server certificates (apart from, I guess, the documentation on OpenSSL itself, but I don’t think I’m ready for that yet).

So I’m going to keep it simple for now. I guess if the need arises, I could look at this extension in the future.