Being only an occasional coffee drinker, I lack any coffee making machinery at home. Not even some instant-coffee.
Thus this text is going to be less extensive than the inspiration post from Mike.

I have my coffee usually outside. Sometimes a cup in the office at work (when not working from home).
And quite often in one of the nice cafes in Zurich.
This afternoon I had a very yummy Flat White made from «UBA purple» beans at MAME 😋

In the Passkeys for Normal People article, Troy Hunt explains in simple terms how Passkeys work.
The article covers also what type of attack they prevent against (using Troy Hunt's recent falling for phishing experience) and how to setup Passkeys for common services.
At the end it briefly touches on using hardware U2F keys as well 🔐

Added some subtle links to the next and previous posts.
Turns out this is a built-in feature of Jekyll, which I never thought about using so far :-)

Here's the snippet which I just added to my custom post layout template:

<footer class="navfooter">
<nav>
{%- if page.next.url %}
<a rel="next" href="{{ site.url }}{{ page.next.url }}" title="{{ page.next.title | strip_html | escape_once }}">&larr;</a>
{% endif -%}
{%- if page.previous.url %}
<a rel="prev" href="{{ site.url }}{{ page.previous.url }}" title="{{ page.previous.title | strip_html | escape_once }}">&rarr;</a>
{% endif -%}
</nav>
</footer>

(Only thing left now, is to tame the ugly Discus comments section so these links become more visible…)

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