Catchy memory from the first weekend of ZÜRICH OPENAIR 2024: Armin van Buuren's version of Artemas - I Like the Way You Kiss Me, which is very similar to the Bassjackers Remix 🔊

Artemas - I Like the Way You Kiss Me (Bassjackers Remix)

Added the /reading page to the blog to keep a list of various books I'm currently reading.

It is very bare-bones currently, I expect over time it will grow (both in number of books and also in amount of content, such as ratings, links and commentary).
Might take a while, stay tuned 🤓

Amazing discovery from the recent Paléo Festival: Lucie Antunes

Lucie Antunes - Carnaval

Not seeing any emoji in Chrome on Linux?
The following fixed it for me on Debian.

sudo apt-get install fonts-noto-color-emoji
fc-cache -f -v

Afterwards restart Chrome and enjoy the colorful emoji 🥳

Instead of using AI tools to tear people down, what if we used them to uplift others? Introducing Praise my GitHub profile:

https://praise-me.fly.dev/

Xe Iaso made this cool tool, which creates happiness ❤️

Added the HTML5 Validator GitHub Action to the repo of my blog.
It runs after the Jekyll site generation step (and before the deploy-to-server step) to catch invalid HTML syntax.

It is configured to validate all generated pages, and promptly surfaced some invalid HTML.
This was rather surprising, as I manually did run the validation for the blog pages not too long ago.
Turns out when you have a blog with 20 year old comments, then some of them have HTML from 20 years ago which is no longer valid nowadays 🤷

After a round of fixing old comments, all HTML validaton errors are now gone ✅
And future invalid HTML syntax will be alerted upon before it ends up on the Internet 😎

With Git it is possible to push only certain local commits to a remote repository.
This can be done with the following git push command, which pushes all commits up to commit to the branch remote branch in the remote repo repository:

git push <repository> <commit>:<remote branch>

For example the following pushes all except for the latest local commit to the main branch in the origin remote repo:

git push origin HEAD~1:main

Following up on yesterday's post about the Website Carbon Calculator, I saw that there is also the option to add a Website Carbon Badge.

Quickly this badge was added to the About page.

To make it more accurate and avoid hitting their API every time someone loads the About page, I made some changes to the provided code:

1. Calculate the results for the front page of the blog instead of the page where the badge is displayed (which would be the less significant About page).
2. Call the API to load the JSON file with the CO₂ results only once per week via a cronjob instead of every time someone new visits the About page.
3. Have the script load the cached JSON file from my server instead of directly calling the API.
4. Store the CSS and Javascript required to render the results on my own server instead of using the unpkg.com CDN (also helps with the above custom modifications).

While surfing around, stumbled upon this cool tool which allows to calculate the carbon footprint of a website: Website Carbon Calculator.

After having it analyze my blog, I was very pleased to see the resulting A⁺ carbon rating 🎉
The tool reports that every time someone loads my blog, 0.01g of CO₂ is produced.

I suspect that this value and rating might fluctuate based on how many images or videos appear in the last 10 posts shown on the front page of the blog.
The results page, also allows to calculate how much CO₂ would be produced in a year based on 10, 100, 1000, … monthly page views and compares this to everyday tasks.
Having 1000 monthly page views on this blog over a whole year, theoretically produces as much CO₂ as boiling water for 16 cups of tea 🍵

(via)

As the CSS code of the blog has been growing lately, I moved it from inline <style> definition to a dedicated css/plain.css file.

With caching headers configured to cache *.css files for 10 days, this brings the problem that browsers need to be instructed to load a new version whenever the content of the file changes.

Removing the caching headers is not desired (as we want to leverage caching and the file does not change so often after all).
Thus I came up with a different workaround:

We add a query parameter to the <link> element that references the CSS file, and then change this query parameter whenever the file content changes.
This way browsers will load the newest version and keep it cached until a newer version is available.

To achieve this, the following script is used to compute and inject the query parameter into the layout template before running Jekyll to generate the HTML pages for the blog:

#!/bin/bash

CSSFILES="css/plain.css"

TARGETFILE="_layouts/x-log.html"


for CSS in $CSSFILES ; do
	sum=$(sha256sum "$CSS"|head -c 6)
	sed -i -e "s_${CSS}_&?${sum}_g" $TARGETFILE
done

It performs the following change in the template file.
Before:

...
<link rel="stylesheet" href="https://blog.x-way.org/css/plain.css" type="text/css" media="all">
...

After:

...
<link rel="stylesheet" href="https://blog.x-way.org/css/plain.css?f00bad" type="text/css" media="all">
...

As the computed query parameter is based on the hashsum of the content of the CSS file, it only changes when the CSS file is changed, thus ensuring caching still works as expected.