A web blog posting month

This site was built to share and revel in each others’ personal sites. Witness these in wonderment and awe. Immaculate. Stunning. How did they do that? Yes, you should definitely get around to redesigning yours soon.

How a QR code encodes information step by step. How to decode it by hand.

A nvm like but for all programs.

a development environment setup tool.

How to install quickly multiple tools coming from different sources (pipx, cargo, npm, ...). Mise solve that.

Development tools can also be set per project. Each project has a "mise.toml" file for it. The file declares what tools are needed for this project, and mise install them.

Part 1: https://shaarli.lyokolux.space/shaare/-zGjpg

1. Stop doing the agile theater. Drop the ceremonies that aren’t helping. Cancel one meeting. Stop pointing stories if it just leads to negotiation and resentment.
2. Show real things: monitoring and alerting. When teams know they’ll see when something breaks, they get bolder. Safer. Smarter. They write better tests. They clean things up before shipping. And they stop emailing the ops team after hours.
3. Give a damn about the again again. Refactoring is how teams stay healthy. The minute a team has to ask permission to fix something they just touched, you’ve lost. Every line they don’t improve is a tax on the next change. And the next. Until nobody knows how it works and your best developer ragequits into a DevRel job.
4. Put the Product back in the room: a good Product Owner is available. They answer questions. They clarify intent. They help you understand why a feature matters. When product and engineering work together like adults, you don’t need a sprint review to get aligned.
5. Stop scaling, start coordinating
6. Eventually the process quietly disappears- That’s when we realized Agile wasn’t the thing helping us anymore—we were just doing the work.

What It Feels Like When It’s Working?

It’s quiet. Calm. Focused.

People are talking, but not in meetings.
They’re shipping, but not sweating it.
The process is invisible, because it’s doing its job.

Nobody says “Agile” anymore, because they don’t have to.
They’re just building good software—together—and getting better every week.

Strip away the branding and it’s embarrassingly simple. Agile is:

• Just enough structure to let teams deliver good software quickly
• A way to shorten feedback loops so you stop building the wrong thing
• A way to change direction without needing a three-month steering committee

When it works:

• Developers talking—constantly, and not just during standups
• Pair programming when it helps, not when the process says so
• Teams who own the product, including how it behaves in production
• Enough time to write proper tests and refactor without begging
• Everyone knowing what the goal is and why it matters
• A calm, steady pace—not a death march disguised as a “sprint”
• Monitoring and alerting built into the work, not bolted on later

But for now, just know this: if Agile feels exhausting, it’s not Agile. It’s cosplay.

Let's create a project and benchmark it :D

Il y a plusieurs moyens de générer des URLs. L'auteur recherche la meilleure.

Avoir des URLs pratique à saisir: courtes avec 4 caractères. 4 chiffres ou lettres donnent déjà 1 679 616 URLs possibles. C'est plus que suffisant pour un blog. Il est possible d'étendre cela à 5 au besoin pour 60 466 176 de possibilités.

Avoir des URLs non prédictibles nécessitent au moins 64 bits d'espace d'adresse, soit 11 caractères. C'est moins pratique à saisir.

Avoir des URLs faciles à saisir est aussi idéal. En optimisant la lisibilité (supprimer les 0, O, 1, I qui peuvent se confondre), on arrive à une base 57 au lieu de 64.

Avoir des URLs significatives implique des noms, donc que ce soit plus long. Est-ce vraiment nécessaire ?

Mis bout à bout, cela donne des URLs comme https://survol.fr/n/2qQVKC6AumxR

Si les liens n'ont pas à être confidentiel, alors 4 à 5 caractères pour un identifiant est idéal. Sinon une suite de mots (3 à 5) est aussi bien lisible. Enfin, pour avoir un compromis entre non prédictibilités et néanmoins lisible, 2qQVKC6AumxR est correct, mais difficilement partageable oralement.

Il y a donc 3 approches possibles.

Deux autres idées sont suggérées en commentaire:

En étant un peu tordu, on peut concilier identifiants courts et contenu non découvrable par bruteforce en renvoyant toujours un code HTTP 200 et affichant un contenu généré aléatoirement sur les URI non-existants.

Créer des mots inexistants qui sont pourtant justes: https://lehollandaisvolant.net/tout/tools/fake-words/

tl;dr: the issue isn’t the @import rule itself, but that files under 1kb often end up the same size or even bigger when gzipped, so you get no compression benefits.

The experience shows that atomic css files is not optimal.

If the files I was importing were larger, it might make sense. As tiny, modular files? Not so much!
The complete library concatenated and gzipped is less than a single HTTP request. It’s just over 25-percent of the transfer size of sending modular gzipped files instead.

PNG 3.0 https://www.w3.org/TR/png-3/

1. Animated PNG will be supported (.apng)
2. HDR support
3. Exif metadata support

The working group work on better interoperability of HDR/SDR.

More on https://www.programmax.net/articles/png-is-back/

Changer d'entreprise après 25 ans

The project can be useful to provide search results on a static site.

Des informations utiles sur le logement