The Yeah, I Made It Lilac post inspired me to try to do something similar here. I was wondering how complicated a post-specific style-sheet would be.
Turns out it can be quite simple.

First I changed my current style-sheet to use custom properties to define the colors in the :root pseudo-class. This allows to make simple modifications without having to re-define a style-sheet from scratch.
Basically it is enough to re-define some of the custom properties with new colors, and everything else inherits them.

I already had some templating logic in place allowing to inject custom stylesheet fragments (eg. for the About and Statistics pages). And a positive surprise, the logic behaves as desired when used for blog posts as well.
The custom stylesheet is injected when the page of the post is loaded, but is not injected when the post is shown as part of a collection (home page, archives, categories etc.). Thus limiting the change to exactly the page of the post, and not messing with the style-sheet of other pages.

So in the end the lilac.css file which is injected for this post is quite simple:

:root {
	--border-color-3: #6952a7;
	--border-color-2: #a076c6;
	--border-color: #ddabe2;
	--pre-bg-color: #f7f7f9;
}

You’re in a rush and you need to grab a bottle of wine for a special occasion. You’ve got $40 and no preference for red or white, but you like wines with animal labels. Which wine are you buying?

We used ChatGPT Vision to identify animals on close to 1,500 wine labels to see if we could predict the price and quality of a bottle based on the animal on the label.

The Pour-Igin of Species by The Pudding.
TL;DR: New Zealand wines provide good quality for reasonable price. Cats are high quality.

(via)

In the Hiding elements that require JavaScript without JavaScript article, dade explains techniques to hide elements when JavaScript is not enabled.
The result is a generic class that can be applied to hide elements, and works with a clever use of <noscript>:

<noscript>
    <style>
        .d-js-required {
            display: none;
        }
    </style>
</noscript>

(via)

In his latest article Russ Cox explains the concept of using Differential Coverage for Debugging.
It's a clever approach using the difference of the coverage output between two test runs, to directly highlight the lines of code that contributed to a bug.

# collect coverage of a passing test run (skip the failing test)
go test -coverprofile=c1.prof -skip='TestAddSub$'

# collect coverage of a failing test run (run the failing test only)
go test -coverprofile=c2.prof -run='TestAddSub$'

# calculate the coverage difference between the runs (so only the code of the failing test gets highlighted)
(head -1 c1.prof; diff c[12].prof | sed -n 's/^> //p') >c3.prof

# display the code in a web browser (green/covered code did contribute to the failing test)
go tool cover -html=c3.prof

The Web Key Directory (WKD) is a standard for discovery of OpenPGP keys by email address, via the domain of its email provider.
The following command can be used to test/import a key via WKD.

gpg --locate-keys --auto-key-locate clear,nodefault,wkd address@example.org

(via)

Added a -f flag to the pgp-expiry-monitor tool.
It takes the fingerprint of a PGP key and looks it up on keys.openpgp.org to get the keyfile to verify.

% pgp-expiry-monitor -f 401F1D483C69BF624364CC01E9A68DCFA3A54203 -v
Key A3A54203 (401f1d483c69bf624364cc01e9a68dcfa3a54203) expires on 2030-04-13
Key 29A48884 (1e8838bdcf9adf702496866f6baf170e29a48884) expires on 2025-10-15
Key B645E283 (47122b88b77ece545effb494498ea9eab645e283) expires on 2025-11-17
Key 93DDE912 (2f21f0dd9af127d61363423d4099876b93dde912) expires on 2027-04-24
Key 0240ACAF (a1f4c70962f89c2e628e8f05d29a32fd0240acaf) expires on 2026-04-09
Key 0B691623 (0d0bc31f58b8d18cb97c31eeebd187b60b691623) expires on 2027-04-13
Key 3AB76067 (43a83177a4ec64a62bae1ac77d779e883ab76067) expires on 2026-04-09
Key 7AE809A1 (9a6d5dbde2703d7c54806f1b5acb66c47ae809a1) expires on 2027-04-13

Hallucinated package names fuel 'slopsquatting'.

All that's required is to create a malicious software package under a hallucinated package name and then upload the bad package to a package registry or index like PyPI or npm for distribution. Thereafter, when an AI code assistant re-hallucinates the co-opted name, the process of installing dependencies and executing the code will run the malware.

(via)

To ensure I don't forget to rotate/extend one of the subkeys of my PGP key, I created a little monitoring tool.
I wanted something that reminds me well before my published PGP key shows sign of expiry.
And I wanted it built in a way so it can be used in a simple cronjob to continuously nag me until the expiring key has been replaced. 😈

So pgp-expiry-monitor was born.
It takes two parameters, the URL of a PGP key and the number of days in advance it should start warning.
If all is fine and the PGP key does not contain any expiring keys, it returns without any output. Thus ideal for a cronjob.

Discovered a very helpful debugging utility: GPG/PGP Decoder

The hosted version helps to quickly find out which subkey was used to sign a message.
I used it to check that this signature contains the fingerprint and ID of my new subkey 🔐