#JaiDécouvert un autre leaderboard : Political Email Extraction Leaderboard (from).

#JaiDécouvert le projet communautaire LLM-Stats.com (https://llm-stats.com/)

A comprehensive set of LLM benchmark scores and provider prices.

J'observe que LLM-Stats.com se base principalement sur le benchmark : A Graduate-Level Google-Proof Q&A Benchmark (GPQA).

En creusant le sujet, j'ai découvert cette page Wikipédia qui liste les principaux outils de LLM Benchmark : Language model benchmark.

Je pense avoir compris que le benchmark MMLU était populaire, utilisé par pratiquement tous les développeurs de LLM jusqu'en 2024, mais peu à peu remplacé par GPQA, qui est plus récent et plus compliqué.

Par exemple, GPQA est "Google-proof", ce qui signifie que les questions de GPQA sont difficiles à trouver en ligne, ce qui réduit le risque de contamination des données d'entraînement.

#JaiDécouvert "Leaderboard des modèles de langage pour le français" : https://fr-gouv-coordination-ia-llm-leaderboard-fr.hf.space

C’est dans cette dynamique que la Coordination Nationale pour l’IA, le Ministère de l’Éducation nationale, Inria, le LNE et GENCI ont collaboré avec Hugging Face pour créer un leaderboard de référence dédié aux modèles de langage en français. Cet outil offre une évaluation de leurs performances, de leurs capacités et aussi de leurs limites.

source

Il y a quelques mois, j'ai publié la note : J'ai découvert « Timeline of AI model releases in 2024 ».

Aujourd'hui, #JaiDécouvert le site The Road To AGI 2015 - 2025 (https://ai-timeline.org/).

Ce projet est Open source, voici son repository : jam3scampbell/ai-timeline.

Il me permet d'avoir une d'ensemble des publications des 6 premiers mois de l'année 2025 :

Bien que la réalisation de ce site soit techniquement réussie, après utilisation, je trouve qu'une simple liste Wikipedia répond mieux à mes besoins : https://en.wikipedia.org/wiki/List_of_large_language_models

J'ai découvert la semaine dernière, le concept de "Brouillard de la guerre" de Carl von Clausewitz. Depuis, je n'arrive plus à quitter ce concept de mon esprit.

Je vois dans ce concept énormément de points communs avec ce qu'il se passe dans les organisations de travail.

Je pense qu'à l'avenir je vais utiliser les termes "brouillard organisationnel" ou "brouillard corporate" pour décrire ces concepts.

Voici quelques éléments qui caractérisent de "Brouillard organisationnel" :

• L'opacité informationnelle - Les informations cruciales circulent de manière fragmentée, déformée ou retardée entre les différents niveaux hiérarchiques et départements.
• L'ambiguïté stratégique - Les objectifs réels de l'organisation, les priorités changeantes et les non-dits politiques créent une vision floue de la direction à prendre.
• La complexité relationnelle - Les jeux de pouvoir, les alliances informelles et les agendas cachés rendent difficile la compréhension des véritables enjeux et motivations.
• L'incertitude décisionnelle - Les processus de prise de décision opaques, les responsabilités diluées et les changements fréquents de cap génèrent confusion et stress.

---

Autres réflexions qui me viennent à l'esprit.
Pour les concepts de "brouillard de la guerre" et de "brouillard organisationnel", je vois des liens avec :

• avec les concepts décrients dans le livre Systemantics.
• le féodalisme managérial de David Graeber

---

Je me suis aidé de Claude Sonnet 4 pour la rédaction de cette note.

Je viens de créer : Projet 31 - "Réaliser un POC d'une integration ProConnect dans un projet SvelteKit".

Actuellement, un freelance qui fait plus de 34 000 € de chiffre d'affaires annuel est assujetti à la TVA (note en lien) et doit donc ajouter 20% de TVA à toutes ses factures.

Généralement, le montant de la TVA facturé par le freelance est transparent pour son client. Ce montant entre dans la catégorie de la TVA "déductible".

Si l'entreprise cliente du freelance est au régime réel normal de TVA, alors elle peut soustraire du montant de TVA encaissé auprès de ses propres clients (TVA collectée), la TVA qu'elle a payée sur ses achats professionnels (TVA déductible) — dont les factures freelances — pendant cette même période. Cela permet de ne verser à l'État que la différence entre ces deux montants.

Exemple : en janvier 2025, le client a collecté 20 000 € de TVA, le même mois, le client a payé une facture de prestation freelance de 1000 €, dont 200 € de TVA, le client devra verser 19 800 € (20 000 - 200 = 19 800) de TVA aux impôts.

Mi-avril 2025, j'ai pris conscience que la TVA n'était pas "transparente" pour tous les types de clients.

Les associations ou la plupart des structures étatiques ne collectent pas de TVA. En conséquence, si je propose des prestations freelances à une association ou à beta.gouv.fr, la TVA représente un surcoût direct de 20% supplémentaire par rapport à une personne employée.

Ensuite, j'ai pensé que la TVA représente aussi un surcoût par rapport à des salariés pour les entreprises de type "startup", qui dépensent beaucoup d'argent alors qu'elles n'ont pas ou peu de revenu et donc peu de TVA collectée.
Mais j'étais dans l'erreur, car j'ai découvert qu'une entreprise peut bénéficier d'un crédit de TVA qu'elle pourra déduire à l'avenir, quand elle pourra collecter de la TVA et même dans certains cas se la faire rembourser.
Toutefois, même avec un crédit de TVA, je pense que les 20% de surcoût de TVA des freelances peuvent avoir un impact sur la trésorerie de l'entreprise.

Je ne suis pas du tout expert dans ce domaine, si vous rencontrez des erreurs dans mon analyse, n'hésitez pas à m'en informer en m'écrivant à «contact@stephane-klein.info>.

Il y a un an, Alexandre m'avait fait découvrir Kopia : Je découvre Kopia, une alternative à Restic.

Ma conclusion était :

Ma doctrine pour le moment : je vais rester sur restic.

source

En septembre 2024, j'ai découvert rustic, un clone de restic recodé en Rust. Pour le moment, je n'ai aucun avis sur rustic.

Il y a quelques semaines, Athoune m'a fait découvrir Plakar, mais je n'avais pas encore pris le temps d'étudier ce que cet outil de backup apportait de plus que restic que j'ai l'habitude d'utiliser.

Depuis, Athoune a eu la bonne idée d'écrire un article très détaillé sur Plakar, enfin, surtout son moteur de stockage avant-gardiste nommé Kloset : "Kloset sur la table de dissection" (au minimum 30 minutes de lecture).

Ce que je retiens, c'est que Kloset propose un système de déduplication plus performant que par exemple celui de restic qui est basé sur Rabin Fingerprints :

For creating a backup, restic scans the source directory for all files, sub-directories and other entries. The data from each file is split into variable length Blobs cut at offsets defined by a sliding window of 64 bytes. The implementation uses Rabin Fingerprints for implementing this Content Defined Chunking (CDC). An irreducible polynomial is selected at random and saved in the file config when a repository is initialized, so that watermark attacks are much harder.

Files smaller than 512 KiB are not split, Blobs are of 512 KiB to 8 MiB in size. The implementation aims for 1 MiB Blob size on average.

For modified files, only modified Blobs have to be saved in a subsequent backup. This even works if bytes are inserted or removed at arbitrary positions within the file.

source

Au moment où j'écris ces lignes, je n'ai aucune idée des différences ou des points communs entre l'algorithme Rolling hash dont parle l'article et Rabin Fingerprints qu'utilise restic.

Chose suprernante, je trouve très peu de citations de Plakar ou kloset sur Hacker News ou Lobster :

• Recherche avec "Plakar"
  • Hacker News
    • dans les stories
      • Mars 2021 : March 2021: backups with Plakar – poolp.org : 0 commentaire
      • Octobre 2024 : Open source distributed, versioned backups with encryption and deduplication : 0 commentaires
      • Mars 2025 : CDC Attack Mitigation in Plakar : 0 commentaires
    • dans les commentaires
  • Lobsters => rien
• Recherche avec "Kloset"
  • Hacker News :
    • dans les stories
    • dans les commentaires
  • Lobsters => rien

Je tiens à remercier Athoune pour l'écriture, qui m'a permis de découvrir de nombreuses choses 🤗.

En étudiant l'article Wikipedia "Base de données vectorielle", je découvre la liste de différents algorithmes Approximate Nearest Neighbor.

#JaiDécouvert feature extraction algorithms.

These feature vectors may be computed from the raw data using machine learning methods such as feature extraction algorithms, word embeddings or deep learning networks. The goal is that semantically similar data items receive feature vectors close to each other.

source

J'apprends :

In recent benchmarks, HNSW-based implementations have been among the best performers.

source

Je lis :

Databases that use HNSW as search index include:

• Apache Lucene Vector Search
• Chroma
• Qdrant
• pgvector
• Clickhouse
• …

source

En interrogeant Claude Sonnet 4, j'apprends :

Benchmark indicatif (1M vecteurs 768D) :

Métrique	Qdrant	pgvector	Elasticsearch
Temps indexation	15 min	45 min	25 min
Requête/sec	2000+	500-800	800-1200
RAM utilisée	4 GB	6 GB	8 GB+
Précision @10	0.95	0.92	0.94
Date création	2021	2021	2022 (support HNSW)
Langage	Rust	C	Java
	Open Source	Open Source	Open Source

Claude Sonnet 4

Par sérendipité, je suis tombé sur la palette Wikipedia nommée "Apprentissage automatique et exploration de données".

Je pense que cette liste d'articles est une bonne porte d'entrée d'exploration de ces sujets. Elle me permet d'avoir une vue d'ensemble du domaine.

Quand j'aborde un nouveau domaine, j'aime recevoir ce type de présentation. C'est par exemple pour cela que j'aime beaucoup les "Developer Roadmaps" (https://roadmap.sh/).

Dans cette fonction filtre Open WebUI, #JaiDécouvert Detoxify (https://github.com/unitaryai/detoxify).

Trained models & code to predict toxic comments on 3 Jigsaw challenges: Toxic comment classification, Unintended Bias in Toxic comments, Multilingual toxic comment classification.

source

#JaimeraisUnJour prendre le temps de le tester.

Je viens de découvrir la fonction inspect.cleandoc de la librairie standard de Python.

Exemple :

# foobar.py
from inspect import cleandoc

def foobar(body):
    print(body)


foobar(
    body=cleandoc("""
        My text, with indentation

        - item 1
            - item 1.1
        - item 2

        Last line
    """)
)

$ python foobar.py
My text, with indentation

- item 1
    - item 1.1
- item 2

Last line

Je trouve cela très pratique pour améliorer la lisibilité du code source sans générer des indentations qui ne devraient pas être présentes dans les données.

La semaine dernière, j'ai fait des étapes de randonnée entre 15 et 21 km par jours.

Mon record de distance en randonnée, date du 11 avril 2024, 33 km avec 1075m de dénivelé positif cumulé, en 9h, soit 3,6 km/h de moyenne.

En ce moment, je m'intéresse au concept de brouillard de la guerre de Carl von Clausewitz et dans l'émission Radio France "Épisode 3/4 : Clausewitz a-t-il inventé la guerre absolue ?" j'ai appris (à partir de 17min) :

• Le régime de mobilité (capacité de déplacement quotidienne d'une armée) pendant la guerre de Sept Ans, 1756-1763 était de 25 km par jour
• Le régime de mobilité des armées napoléoniennes pouvait être de 40 km par jour !

40 km par jour avec l'équipement — chaussure, etc — du 19ᵉ siècle, je trouve cela énorme !

---

Un ami m'a partagé : La vitesse de César et de ses troupes durant les campagnes militaires en Occident

Je me pose souvent des questions sur l'histoire des notations mathématiques. Quelle est l'origine d'une notation, pourquoi avoir fait ce choix, etc.
Comprendre comment une notation a émergé m'aide à la retenir.

Au cours de mes recherches par sérendipité sur ce sujet, #JaiDécouvert Florian Cajori :

Florian Cajori est un historien des mathématiques, véritable fondateur de cette discipline aux États-Unis, et auteur dans ce domaine d'ouvrages qui ont fait date.

source

Il a, entre autres, écrit le livre : "A History of Mathematical Notations".

Je suis ensuite tombé sur cette excellente page Wikipedia nommée "Table de symboles mathématiques", (et surtout sa version anglaise) que j'aurais adoré avoir quand je faisais mes études.

Autres ressources que j'ai croisées :

• List of mathematical constants
• Table of mathematical symbols by introduction date
• List of mathematical abbreviations
• List of letters used in mathematics, science, and engineering
• Glossary of mathematical jargon

Alexandre m'a partagé le projet LocalAI (https://localai.io/).

Ce projet a été mentionné une fois sur Lobster dans un article intitulé Everything I’ve learned so far about running local LLMs, et quatre fois sur Hacker News (recherche pour "localai.io"), mais avec très peu de commentaires.
C’est sans doute pourquoi je n'ai jamais remarqué ce projet auparavant.
Pourtant, il ne s’agit pas d’un projet récent : son développement a débuté en mars 2023.

J'ai l'impression que LocalAI propose à la fois des interfaces web comme Open WebUI, mais qu'il est aussi une sorte de "wrapper" au-dessus de nombreux Inference Engines comme l'illustre cette longue liste.

Pour le moment, j'ai vraiment des difficultés à comprendre son positionnement dans l'écosystème.

LocalAI versus vLLM ou Ollama ? LocalAI versus Open WebUI ?, etc.

Je vais garder ce projet dans mon radar.

Je viens de publier : Projet 30 - "Setup une instance personnelle d'Open WebUI connectée à OpenRouter".

J'ai utilisé le "Workflow de gestion des secrets d'un projet basé sur Age et des clés ssh" dans un projet professionnel et un collègue a rencontré un problème au niveau du script /scripts/decrypt_secrets.sh :

#!/usr/bin/env bash
set -e

cd "$(dirname "$0")/../"

# Prepare identity arguments for age
identity_args=()
for key in ~/.ssh/id_*; do
    if [ -f "$key" ] && ! [[ "$key" == *.pub ]]; then
        identity_args+=("-i" "$key")
    fi
done

# Execute age with all identity files
age -d "${identity_args[@]}" -o .secret .secret.age

cat << EOF
Secret decrypted in .secret
Don't forget to run the command:

$ source .envrc
EOF

Sa clé privée ssh n'était pas présente dans ~./ssh/ parce qu'il utilise "1Password SSH agent" (disponible depuis mars 2022).
Je ne connaissais pas cette fonctionnalité (merci).

#JaiDécouvert que cette fonctionnalité existe aussi dans Bitwarden depuis février 2025 : "SSH Agent".

#JaiDécouvert qu'une solution alternative pour Bitwarden existait depuis 2020 : bitwarden-ssh-agent. Mais beaucoup moins bien intégré à Bitwarden.

---

Au cours des 15 dernières années, j'ai régulièrement reçu des demandes de redéploiement de clés SSH de la part des développeurs, parfois plusieurs mois après leur onboarding. La cause principale : la plupart des développeurs ne pensent pas à sauvegarder leurs clés SSH dans leur gestionnaire de password et les perdent inévitablement lors du changement de workstation ou de réinstallation de leur système.

Face à ce constat récurrent, j'envisageais depuis plusieurs années de créer une issue chez Bitwarden pour leur proposer d'implémenter un système de sauvegarde automatique des clés SSH.
L'approche basée sur un ssh-agent ne m'avait jamais traversé l'esprit.

---

À l'avenir, j'envisage d'intégrer l'usage de Bitwarden SSH Agent (ou équivalent) dans les processus d'onboarding dont j'ai la responsabilité.

---

J'ai tenté d'ajouter le support de ssh-agent au script /scripts/decrypt_secrets.sh, mais d'après le thread "ssh-agent support", age ne semble pas supporter ssh-agent.

Conséquence : en attendant, j'ai demandé à mon collègue de placer sa clé privée ssh dans ~/.ssh/.

Mon objectif dans cette note est de rassembler une liste d'issues que j'ai à l'esprit pour le projet gibbon-replay.

Dans cette note, les issues sont décrites en moins de 280 caractères, de manière approximative et sans doute un peu idiosyncrasique. Elles sont présentées dans un ordre quelconque.

• Dans le README, expliquer pourquoi j’ai créé ce projet et son ambition. Indiquer clairement que l’objectif est de rester simple à déployer (architecture monolithique) et que les utilisateurs plus ambitieux peuvent se tourner vers des solutions comme Posthog ou OpenReplay.
• Toujours dans le README, indiquer comme dans l'introduction de SilverBullet : « gibbon-replay is optimized for people with a hacker mindset ».
• [x] En tant qu'utilisateur, je peux visualiser l'espace mémoire total utilisé par l'ensemble des sessions. Issue GitHub : #4.
• [x] En tant qu'utilisateur, je peux visualiser l'espace mémoire consommé par chaque session individuellement.
• [x] En tant qu'utilisateur, je peux visualiser la durée de chaque session. Issue Github : #3.
• [x] En tant qu'utilisateur, je peux consulter, session par session, la présence ou non des actions utilisateur. Issue GitHub : #6.
• [ ] Optimiser la densité d'affichage de la liste des sessions en regroupant plusieurs données dans des cellules multilignes.
• En tant qu'utilisateur, dans la page liste des sessions, je peux appliquer un filtre sur les champs suivants : durée, taille mémoire ou mouvement de souris.
• En tant qu'utilisateur, dans la page détail d'une session, je peux visualiser les titres et les URLs des pages décrivant le parcours effectué par l'utilisateur.
• En tant qu'utilisateur, je peux visualiser un résumé textuel, du parcours utilisateur d'une session, rédigé par un agent conversationnel de petite taille.
• En tant qu'utilisateur avancé, je peux effectuer des recherches avancées sur le contenu des URLs présentes dans le parcours utilisateur. Par exemple, l'utilisateur peut saisir du code JavaScript qui permet de tester une condition sur toutes les URLs parcourues lors d'une session. Si la condition est positive, alors le résultat doit être sauvegardé dans un champ json de la session.
• En tant qu'utilisateur avancé, je peux rechercher des informations spécifiques dans le contenu des URLs présentes dans le parcours d'une session. Par exemple, je peux saisir un code JavaScript personnalisé pour tester une condition (comme la présence d'un utm_source ou campaign) sur toutes les URLs parcourues. Si cette condition est vérifiée, les résultats correspondants sont stockés dans un champ json dans la session, permettant d'effectuer par la suite un filtre sur la liste des sessions.
• User Story qui ressemble à la précédente : en tant qu'utilisateur avancé, je peux rechercher les balises HTML qui ont déclenché un événement "click" durant un parcours de session. Pour ce faire, il peut saisir du code JavaScript personnalisé pour tester une condition spécifique (comme la présence d'un attribut, d'une classe, etc.) sur ces balises. Les résultats de cette recherche sont enregistrés dans un champ JSON associé à la session, permettant d'effectuer par la suite un filtre sur la liste des sessions.
• En tant qu'utilisateur, je peux activer / désactiver l'envoi de notifications web sur des filtres de session, filtres avancés inclus.
• Permettre à une instance gibbon-replay d'enregistrer et de gérer plusieurs sites en même temps, en single-tenant.
• Ajouter un support multiutilisateurs — toujours en mode single-tenant. Permettre l'authentification par magic link et par username et password.
• Permettre la gestion des utilisateurs par API REST.
• Permettre de supprimer automatiquement des sessions en fonction de critères de filtres.
• En tant qu'utilisateur, je peux supprimer des sessions en mode batch.

Prochaine étape : créer ces issues plus détaillé dans : https://github.com/stephane-klein/gibbon-replay/issues

Je viens de terminer un POC nommé poc-sveltekit-web-notification , qui m'a permis d'apprendre à implémenter la fonctionnalité Push API dans une PWA.

Quelques ressources qui m'ont été utiles :

• Push API
• Web Workers API
• Using VAPID with WebPush
• Cet exemple de MDN Web Docs : push-subscription-management.
  Je n'ai aucune idée de pourquoi ce repository est archivé et par quoi il a été remplacé.
• J'ai lu en partie Voluntary Application Server Identification (VAPID) for Web Push - RFC 8292
• SvelteKit - Service workers

Ma prochaine étape : intégrer cette fonctionnalité dans gibbon-replay.

#JaiDécouvert Datatracker de IETF. Voici un exemple d'utilisation : https://datatracker.ietf.org/doc/rfc8292/

J'ai fini le tracé d'une randonnée de 4 jours, que j'ai prévu du dimanche 1ᵉʳ juin au mercredi 4.

• Jour 1 : 20 km
  • Nous sommes déposés en voiture à L'Espace naturel départemental des mégalithes de Lampouy
  • Destination un hôtel à Évran
• Jour 2 : 12,5 km
  • Départ Évran
  • Destination un hôtel à Dinan
  • Visite de la ville fortifiée
• Jour 3 : 19,5 km
  • Départ de Dinan
  • Destination un hôtel à la Rigourdaine
• Jour 4 : 25 km
  • Départ la Rigourdaine
  • Destination une location à Dinard
• Ensuite, 3 jours en thalassothérapie 🙂.

Lien vers le tracé : http://u.osmfr.org/m/1209152/

J'ai bien fait de partager poc-sveltekit-custom-server dans la section discussion GitHb de Sveltekit car cela m'a permis de découvrir via ce commentaire l'existence de la fonctionnalité native SvelteKit nommée Shared hooks init.

This function runs once, when the server is created or the app starts in the browser, and is a useful place to do asynchronous work such as initializing a database connection.

source

Cette fonctionnalité a été introduite dans la version 2.10.0 de SvelteKit publiée le 10 décembre 2024.

C'est particulièrement frustrant car j'ai cherché cette fonctionnalité à plusieurs reprises entre mi-2022 et mi-2024, sans la trouver. Je me souviens même avoir lu une issue de Rich Harris expliquant que cette fonctionnalité était complexe à implémenter.

Il y a quelques semaines, lors du développement de poc-sveltekit-custom-server, j'ai refait une recherche de fonctionnalité "init", mais en me limitant à la documentation "Node servers". La présence de "Graceful shutdown" m'a paradoxalement induit en erreur : j'en ai déduit que s'il n'y avait pas d'équivalent pour l'initialisation sur cette page, c'est que la fonctionnalité n'existait toujours pas 😔.

Conséquence de tout cela :

• Je vais utiliser Shared hooks init dans gibbon-replay ;
• J'ai indiqué dans poc-sveltekit-custom-server que je recommande d'utiliser "Shared hooks init"

Dans ma note Bilan de poc-sveltekit-custom-server je finis par ceci :

La suite...

Je souhaite rédiger cette note en anglais et la publier sur https://github.com/sveltejs/kit/discussions et https://old.reddit.com/r/sveltejs/ afin :

• d'avoir des retours d'expérience
• de découvrir des méthodes alternatives
• et partager la méthode que j'ai utilisée, qui sera peut-être utile à d'autres développeurs Svelte 🙂

source

Voici ce que je viens de publier :

• https://github.com/sveltejs/kit/discussions/13841
• https://old.reddit.com/r/sveltejs/comments/1kxtz1u/custom_sveltekit_server_dev_production_with/

---

2025-05-29 : voir J'ai découvert la fonctionnalité SvelteKit Shared hooks init

Contexte et objectifs

Dans le projet gibbon-replay, j'ai besoin d'exécuter une tâche une fois par jour pour supprimer des anciennes sessions.

gibbon-replay utilise une base de données SQLite qui ne dispose pas nativement de fonctionnalité de type Time To Live, comme on peut trouver dans Clickhouse.
SQLite ne propose pas non plus d'équivalent à pg_cron — ce qui est tout à fait normal étant donnée que SQLite est une librairie et non pas un service à part entière.

Le projet gibbon-replay est un monolith (j'aime les monoliths !) et je souhaite conserver ce choix.

Face à ces contraintes, une solution consiste à intégrer une solution comme Cron for Node.js directement dans l'application gibbon-replay.
Je pense que je dois implémenter cela dans un SvelteKit Custom Server, ce qui me permettrait d'exécuter cette tâche de purge à intervalles réguliers tout en conservant l'architecture monolithique.

Il y a quelques jours, j'ai décidé de tester cette idée dans un POC nommé : poc-sveltekit-custom-server.

J'ai aussi décidé d'expérimenter un objectif supplémentaire dans ce POC : lancer la migration du modèle de données dès le lancement du monolith et non plus lors de la première requête HTTP reçue par le service.

Enfin, je souhaitais ne pas dégrader l'expérience développeur (DX), c'est à dire, je souhaitais pouvoir continuer à simplement utiliser :

$ pnpm run dev

ou

$ pnpm run build
$ pnpm run preview

sans différence avec un projet SvelteKit "vanilla".

Résultats du POC et enseignements

Tout d'abord, le POC fonctionne parfaitement 🙂, sans dégrader l'expérience développeur (DX), qui ressemble à ceci :

$ mise install
$ pnpm install
$ pnpm run load-seed-data
Start data model migration…
Data model migration completed
Start load seed data...
seed data loaded

Lancement du projet en mode développement :

$ pnpm run dev
Start data model migration…
Data model migration completed
Server started on http://localhost:5173 in development mode

Lancement du projet "buildé" :

$ pnpm run build
$ pnpm run preview
Start data model migration…
Data model migration completed
Server started on http://localhost:3000 in production mode

Les migrations et les données "seed.sql" se trouvent dans le dossier /sqls/.

Le SvelteKit Custom Server est implémenté dans le fichier src/server.js et il ressemble à ceci :

import express from 'express';
import cron from 'node-cron';
import db, { migrate } from '@lib/server/db.js';

const isDev = process.env.ENV !== 'production';

migrate(); // Lancement de la migration du modèle de donnée dès de lancement du serveur

// Configuration d'une tâche exécuté toutes les heures
cron.schedule(
    '0 * * * *',
    async () => {
        console.log('Start task...');
        console.log(db().query('SELECT * FROM posts'));
        console.log('Task executed');
    }
);

async function createServer() {
    const app = express();

    ...

Personnellement, je trouve cela simple et minimaliste.

Point de difficulté

SvelteKit utilise des "module alias", comme par exemple $lib.
Problème, par défaut, ces "module alias" ne sont pas configurés lors de l'exécution de node src/server.js.

Pour me permettre d'importer dans src/server.js des modules de src/lib/server/* comme :

import db, { migrate } from '@lib/server/db.js';

j'ai utilisé la librairie esm-module-alias.

Ceci complexifie un peu le projet, j'ai dû configurer ceci dans /package.json :

{
    "scripts": {
        "dev": "ENV=development node --loader esm-module-alias/loader --no-warnings src/server.js",
        "preview": "ENV=production node --loader esm-module-alias/loader --no-warnings build/server.js",
        
    ...

	"aliases": {
        "@lib": "src/lib/"
    }
}

• ajout de --loader esm-module-alias/loader --no-warnings
• et la section aliases

Et dans /vite.config.js :

export default defineConfig({
    plugins: [sveltekit()],
    resolve: {
        alias: {
          '@lib': path.resolve('./src/lib')
        }
    }
});

• ajout de alias

Le fichier src/server.js contient du code spécifique en fonction de son contexte d'exécution ("dev" ou "buildé") :

    if (isDev) {
        const { createServer: createViteServer } = await import('vite');

        const vite = await createViteServer({
            server: { middlewareMode: true },
            appType: 'custom'
        });

        app.use(vite.middlewares);
    } else {
        const { handler } = await import('./handler.js');
        app.use(handler);
    }

En mode "dev" il utilise Vite et en "buildé" il utilise le fichier build/handler.js généré par SvelteKit build en mode SSR.

Le fichier src/server.js est copié vers le dossier /build/ lors de l'exécution de pnpm run build.

J'ai testé le bon fonctionnement du POC dans un container Docker.

J'ai intégré au projet un deployment-playground : https://github.com/stephane-klein/poc-sveltekit-custom-server/tree/main/deployment-playground.

La suite...

Je souhaite rédiger cette note en anglais et la publier sur https://github.com/sveltejs/kit/discussions et https://old.reddit.com/r/sveltejs/ afin :

• d'avoir des retours d'expérience
• de découvrir des méthodes alternatives
• et partager la méthode que j'ai utilisée, qui sera peut-être utile à d'autres développeurs Svelte 🙂

---

Update du 2025-05-29 à 00:07 - Je viens de publier ceci :

• https://github.com/sveltejs/kit/discussions/13841
• https://old.reddit.com/r/sveltejs/comments/1kxtz1u/custom_sveltekit_server_dev_production_with/?

---

2025-05-29 : voir J'ai découvert la fonctionnalité SvelteKit Shared hooks init

#JaiLu cet excellent article "The future of Flatpak".

J'y ai appris énormément de choses au sujet de Flatpak. Le sujet est bien plus complexe que je l'imaginais. Je découvre aussi que les axes d'amélioration du projet sont nombreux.

#JaiDécouvert l'origine du nom du projet Flatpak :

Flatpak was originally developed by Alexander Larsson, who had been working on similar projects stretching back to 2007. The first release was as XDG-App in 2015. It was renamed to Flatpak in 2016, a nod to IKEA's "flatpacks" for delivering furniture.

source

J'adore l'idée derrière ce nom !

Dans ce billet de Simon Willison, #JaiDécouvert llm-prices (https://www.llm-prices.com).

#JaiDécouvert le concept de LLM-as-a-Judge.

#JaiLu l'article Wikipédia à ce sujet "LLM-as-a-Judge".

"Abstract" du papier de recherche Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena datant du 24 décembre 2023 :

Evaluating large language model (LLM) based chat assistants is challenging due to their broad capabilities and the inadequacy of existing benchmarks in measuring human preferences. To address this, we explore using strong LLMs as judges to evaluate these models on more open-ended questions. We examine the usage and limitations of LLM-as-a-judge, including position, verbosity, and self-enhancement biases, as well as limited reasoning ability, and propose solutions to mitigate some of them. We then verify the agreement between LLM judges and human preferences by introducing two benchmarks: MT-bench, a multi-turn question set; and [[Chatbot Arena]], a crowdsourced battle platform. Our results reveal that strong LLM judges like GPT-4 can match both controlled and crowdsourced human preferences well, achieving over 80% agreement, the same level of agreement between humans. Hence, LLM-as-a-judge is a scalable and explainable way to approximate human preferences, which are otherwise very expensive to obtain. Additionally, we show our benchmark and traditional benchmarks complement each other by evaluating several variants of LLaMA and Vicuna. The MT-bench questions, 3K expert votes, and 30K conversations with human preferences are publicly available at https://github.com/lm-sys/FastChat/tree/main/fastchat/llm_judge.

source

J'ai parcouru rapidement l'article "Evaluating RAG with LLM as a Judge" du blog de Mistral AI. Je n'ai pas pris le temps d'étudier les concepts que je ne connaissais pas dans cet article, par exemple RAG Triad.

J'ai effectué une recherche sur « LLM as Judge » sur le blog de Simon Willison.

#JaiLu la discussion GitHub du projet nginx-proxy : "How can we scapre metrics from nginx-proxy container".

J'y ai découvert le Prometheus exporter : nginx-prometheus-exporter (https://github.com/nginx/nginx-prometheus-exporter). Il semble être l'exporter officiel de nginx pour Prometheus.

Je pense tester son installation et sa configuration d'ici à quelques jours.

Liste des éléments que je souhaite étudier :

• Est-ce qu'il existe un dashboard Grafana qui permet de consulter par domaine et peut-être par URLs :
  • le temps moyen de réponse
  • la mediane de temps de réponse
  • le temps de réponse au 90ème percentile (p90)
  • le temps de réponse au 95ème percentile (p95)

Je pense que la metric nginxplus_upstream_server_response_time me permettra peut-être d'obtenir cette information.

J'ai identifié ce dashboard Grafana mais il ne semble pas afficher les informations dont j'ai besoin.

Aujourd'hui, j'ai implémenté des tests de montée en charge à l'aide de Grafana k6. En ciblant un site web hébergé sur un petit serveur Scaleway DEV1-M, j'ai constaté que le serveur est devenu inaccessible à la fin des tests. Aucun swap n'était configuré sur cette Virtual machine de 4Go de RAM.

Je me suis souvenu qu'en 2019, j'ai rencontré aussi des problèmes de freeze sur une VM AWS EC2 que j'ai corrigés en ajoutant un peu de swap au serveur. Après cela, je n'ai constaté plus aucun freeze de VM pendant 4 ans.

Ce sujet de swap m'a fait penser à la question qu'un ami m'a posée en octobre 2024 :

Désactiver le swap sur une Debian, recommandé ou pas ?

Alors que j'ai 29Go utilisé sur 64, le swap était plein (3,5Go occupé à 100%), les 12 cœurs du serveur partaient dans les tours. J'ai désactivé le swap et me voilà gentiment avec un load average raisonnable, pour les tâches de cette machine.

C'est une très bonne question que je me pose depuis longtemps. J'ai enfin pris un peu de temps pour creuser ce sujet.

Sept mois plus tard, voici ma réponse dans cette note 😉.

#JaiDécouvert le paramètre kernel nommé Swappiness.

swappiness

This control is used to define how aggressive the kernel will swap memory pages. Higher values will increase aggressiveness, lower values decrease the amount of swap. A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone.

The default value is 60.

documentation du kernel

Dans la documentation SwapFaq d'Ubuntu j'ai lu :

The swappiness parameter controls the tendency of the kernel to move processes out of physical memory and onto the swap disk. Because disks are much slower than RAM, this can lead to slower response times for system and applications if processes are too aggressively moved out of memory.

• swappiness can have a value of between 0 and 100
• swappiness=0 tells the kernel to avoid swapping processes out of physical memory for as long as possible
• swappiness=100 tells the kernel to aggressively swap processes out of physical memory and move them to swap cache

The default setting in Ubuntu is swappiness=60. Reducing the default value of swappiness will probably improve overall performance for a typical Ubuntu desktop installation. A value of swappiness=10 is recommended, but feel free to experiment. Note: Ubuntu server installations have different performance requirements to desktop systems, and the default value of 60 is likely more suitable.

source

D'après ce que j'ai compris, plus swappiness tend vers zéro, moins le swap est utilisé.

J'ai lu ici :

vm.swappiness = 60 : Valeur par défaut de Linux : à partir de 40% d’occupation de Ram, le noyau écrit sur le disque.

source

Cependant, je n'ai pas trouvé d'autres sources qui confirment cette correspondance entre la valeur de swappiness et un pourcentage précis d'utilisation de la RAM.

J'ai ensuite cherché à savoir si c'était encore pertinent de configurer du swap en 2025, sur des serveurs qui disposent de beaucoup de RAM.

#JaiLu ce thread : "Do I need swap space if I have more than enough amount of RAM?", et voici un extrait qui peut servir de conclusion :

In other words, by disabling swap you gain nothing, but you limit the operation system's number of useful options in dealing with a memory request. Which might not be, but very possibly may be a disadvantage (and will never be an advantage).

source

Je pense que ceci est d'autant plus vrai si le paramètre swappiness est bien configuré.

Concernant la taille du swap recommandée par rapport à la RAM du serveur, la documentation de Ubuntu conseille les ratios suivants :

       RAM      Swap    Maximum Swap
      256MB    256MB           512MB 
      512MB    512MB          1024MB
     1024MB   1024MB          2048MB
        1GB      1GB             2GB
        2GB      1GB             4GB
        3GB      2GB             6GB
        4GB      2GB             8GB
        5GB      2GB            10GB
        6GB      2GB            12GB
        8GB      3GB            16GB
       12GB      3GB            24GB
       16GB      4GB            32GB
       24GB      5GB            48GB
       32GB      6GB            64GB
       64GB      8GB           128GB
      128GB     11GB           256GB
      256GB     16GB           512GB
      512GB     23GB             1TB
        1TB     32GB             2TB
        2TB     46GB             4TB
        4TB     64GB             8TB
        8TB     91GB            16TB

source

#JaiDécouvert aussi que depuis le kernel 2.6, les fichiers de swap sont aussi rapides que les partitions de swap :

Definitely not. With the 2.6 kernel, "a swap file is just as fast as a swap partition."

source

Suite à ces apprentissages, j'ai configuré et activé un swap de 2G sur la VM Scaleway DEV1-L équipée de 4G de RAM, avec le paramètre swappiness réglé à 10.

J'ai relancé mon test Grafana k6 et je n'ai constaté plus aucun freeze, je n'ai pas perdu l'accès au serveur.

De plus, probablement grâce au paramètre swappiness fixé à 10, j'ai observé que le swap n'a pas été utilisé pendant le test.

Suite à ces lectures et à cette expérience concluante, j'ai décidé de désormais configurer systématiquement du swap sur tous mes serveurs de la manière suivante :

if swapon --show | grep -q "^/swapfile"; then
    echo "Swap is already configured"
else
    get_swap_size() {
        local ram_gb=$(free -g | awk '/^Mem:/ {print $2}')
        
        # Why this values? See https://help.ubuntu.com/community/SwapFaq#How_much_swap_do_I_need.3F
        if [ $ram_gb -le 1 ]; then
            echo "1G"
        elif [ $ram_gb -le 2 ]; then
            echo "1G"
        elif [ $ram_gb -le 6 ]; then
            echo "2G"
        elif [ $ram_gb -le 12 ]; then
            echo "3G"
        elif [ $ram_gb -le 16 ]; then
            echo "4G"
        elif [ $ram_gb -le 24 ]; then
            echo "5G"
        elif [ $ram_gb -le 32 ]; then
            echo "6G"
        elif [ $ram_gb -le 64 ]; then
            echo "8G"
        elif [ $ram_gb -le 128 ]; then
            echo "11G"
        else
            echo "11G"
        fi
    }

    SWAP_SIZE=$(get_swap_size)
    fallocate -l $SWAP_SIZE /swapfile
    chmod 600 /swapfile
    mkswap /swapfile
    swapon /swapfile

    if ! grep -q "^/swapfile.*swap" /etc/fstab; then
        echo "/swapfile none swap sw 0 0" >> /etc/fstab
    fi
fi

# Why 10 instead default 60? see https://help.ubuntu.com/community/SwapFaq#:~:text=a%20value%20of%20swappiness%3D10%20is%20recommended
echo 10 | tee /proc/sys/vm/swappiness
echo "vm.swappiness=10" | tee -a /etc/sysctl.conf

#JaiDécouvert la définition du mot "Bastide" :

Une bastide peut être aussi bien la maison d'habitation des maitres d'une exploitation agricole que l'ensemble d'une exploitation agricole, puis plus tardivement, une maison rurale bourgeoise provençale.

Le terme bastide désigne aussi un type de villes, créées au Moyen Âge, dans l'objectif de constituer de nouveaux foyers de population. Les bastides, nombreuses dans le Sud-Ouest de la France, étaient le plus souvent fondées sur initiative seigneuriale, royale ou ecclésiastique (parfois conjointement). Des privilèges fiscaux furent généralement octroyés aux personnes qui acceptaient de peupler les bastides nouvellement construites.

source

Je me suis posé la question suivante : « Qui contribue au projet Open WebUI ? »

Si je regarde les contributions au projet, je constate que, à la louche, 95% du repository /open-webui/open-webui/ et /pipelines/graphs/ est réalisé par Tim Jaeryang Baek.

Contributions au dépôt /open-webui/open-webui/ :

Contributions au dépôt /open-webui/open-webui/ sur les 6 derniers mois :

D'après la section "People" de la page LinkedIn "Open WebUI", James W. semble être dédié et peut-être rémunéré pour travailler sur /open-webui/helm-charts/.

Voici mon estimation de Fermi de calcul du coût de développement d'Open WebUI (seulement ce composant) :

• Estimation du taux journalier de Tim Jaeryang Baek : bien que Tim a commencé depuis peu sa carrière professionnelle, je pense qu'il n'aurait pas de difficulté à trouver des missions entre 500 et 1000 € HT la journée.
• Le dépôt Open WebUI a reçu ses premiers commits le 1ᵉʳ octobre 2023. Cela fait 20 mois de travail.
• Si j'estime, 20 jours de travail par mois sans vacances, j'obtiens 400 jours de travail
• J'obtiens un coût total entre :
  • 500 x 400 = 200 000 €
  • 1000 x 400 = 400 000 €

Je tiens à préciser que ce montant n'a pas de lien avec une valeur économique d'usage, ni une valeur d'échange.

Comme on a pu le voir au début de cette note, ce projet a été développé par une seule personne, réduisant considérablement les "frais de couplage" (coûts liés à la coordination, communication et synchronisation entre développeurs, management, recrutement…). Si ce même projet avait été réalisé au sein d'une startup, son coût aurait été d'un ordre de grandeur nettement supérieur. Selon mon estimation, il aurait été multiplié par 50, voire davantage.

J'ai découvert que dans ses premières versions, bits-ui était un "wrapper" au-dessus de Melt UI, pour y ajouter un support d'accessibilité. Ce commit confirme que bits-ui utilisait Melt UI.

Depuis, ce n'est plus le cas, bits-ui n'est plus un wrapper de Melt UI. Je pense que ce changement a eu lieu le 26 juillet 2024, dans ce commit.

Un ami m'a partagé la chaine YouTube "Le lab du vieux geek" :

Chaine YouTube consacrée à l'IA l'IT la culture Geek et de nombreux autres sujets autour de l'IA. Je m'appelle Jerome Fortias, je suis français vivant en Belgique, et j'ai utilisé mon premier robot en 1986, depuis je travaille dans le monde de l'IT et de l'IA. Cette chaine c'est un peu une expérimentation d'un youtuber amateur.

source

J'ai écouté "La fin des LLM (Yann LeCun a raison)" et ensuite "Comment les machines pourraient-elles atteindre l'intelligence humaine ? Conférence de Yann LeCun".

Énormément de contenu, j'en ai saisi qu'une petite partie.

#JaimeraisUnJour prendre le temps de lire les 509 commentaires sous la vidéo "La fin des LLM (Yann LeCun a raison)".

L'écoute de ces vidéos m'a fait penser aux vidéos suivantes de Thibault Neveu que j'ai écoutées il y a un an :

• "Voici pourquoi GPT-5 n'est pas encore arrivé - The Bitter Lesson, Chinchilla, Chronique d'une IA #2".
• "Comprendre JEPA et ses limites - Yann LeCun, Energy Based model, MPC & RL - Chronique d'une IA #3" (au sujet de JEPA, MPC)

En étudiant le projet https://github.com/OriPekelman/alpair, j'ai découvert le blog d'Ori Pekelman, personne que j'ai déjà croisée à divers endroits sur Internet (podcast, commentaires…).

#JaiLu ces deux billets :

• Techno-Optimism
• In a gold rush rent a food truck

et j'ai vraiment beaucoup apprécié le fond et la forme.

#JaimeraisUnJour prendre le temps de lire tous ses autres billets.

Depuis que j'ai commencé ma mission chez la DINUM, je me retrouve à rencontrer de nombreuses personnes en présentiel.

En ligne — sur Internet, le partage d'informations personnelles est simple et fluide. Je peux facilement communiquer mon prénom, mon nom, et des URLs avec précision. C'est pourquoi j'ai créé https://sklein.xyz, porte d'entrée vers toutes les informations me concernant.

Quand une rencontre s'effectue en présentiel, les choses sont plus compliquées.

Il y a deux semaines, par exemple, j'échangeais avec un collègue assis en face de moi. Après plusieurs minutes, il a lancé la discussion et a cherché à mieux me connaître. Ma présentation a été maladroite et je doute qu'il ait retenu mon prénom ou mon nom...

Lorsque j'ai commencé à l'interroger à mon tour, j'ai découvert qu'il était l'un des deux créateurs du projet Open Food Facts, un projet que j'admire depuis plusieurs années.

Cette expérience m'a fait prendre conscience une nouvelle fois de deux choses : j'aurais vraiment apprécié avoir des cartes de visite à partager, et si je n'avais pas posé de questions, j'aurais manqué l'opportunité d'échanger pendant près d'une heure sur un projet qui me passionne.

Suite à cela, j'ai pour objectif :

• Concevoir une carte de visite personnelle
• Créer un sticker personnalisé à apposer sur le capot de mon Thinkpad T14s

Par le passé, j'avais le sticker suivant sur mon laptop, acheté chez Redbubble :

Ce dessin suscitait des discussions autour du Yak shaving à presque chacune de mes nouvelles rencontres. Je trouvais cela à la fois amusant et efficace pour briser la glace.

Informations que je souhaite intégrer sur ces supports :

• Simplement l'URL : https://sklein.xyz
• Et mon https://notes.sklein.xyz/avatar_stephane-512x512.jpg

Rien de plus.

Pour me permettre d'analyser les sources de connexion (tracking), je souhaite :

• Imprimer l'URL https://sklein.xyz/1/ sur le sticker de laptop
• Imprimer l'URL https://sklein.xyz/2/ sur les cartes de visite

Un collègue m'a partagé le projet Marker (https://github.com/VikParuchuri/marker) :

Marker converts documents to markdown, JSON, and HTML quickly and accurately.

• Converts PDF, image, PPTX, DOCX, XLSX, HTML, EPUB files in all languages
• Formats tables, forms, equations, inline math, links, references, and code blocks
• Extracts and saves images
• Removes headers/footers/other artifacts
• Extensible with your own formatting and logic
• Optionally boost accuracy with LLMs
• Works on GPU, CPU, or MPS

source

Voici comment fonctionne Marker :

Marker is a pipeline of deep learning models:

• Extract text, OCR if necessary (heuristics, surya)
• Detect page layout and find reading order (surya)
• Clean and format each block (heuristics, texify, surya)
• Optionally use an LLM to improve quality
• Combine blocks and postprocess complete text

source

Voici-ci dessous, une partie de la liste de labels d'Issues que l'équipe tech de Spacefill utlisait sous GitLab. Cette liste de labels est le fruit d'un travail itératif d'environ 15 personnes, sur une période de 4 ans.

Voici comment cette liste a été élaborée :

• Au départ, quelques labels ont été créés de manière organique par 3 développeurs et un product manager.
• Après 3 mois d'usage, une page de documentation nommée "GitLab Spacefill labels" a été ajoutée au handbook de l'équipe.
• Ensuite, au fur et à mesure des nouvelles problématiques rencontrées et de l'évolution des workflows, ce fichier de documentation a été amendé plus de 70 fois en 3 ans, par 11 contributeurs différents.
• Ce document était modifié suivant le même processus que le reste du handbook et le code :
  • Une personne commençait par créer une issue pour décrire une problématique
  • Ensuite, cette même personne ou une autre faisait une proposition d'évolution du processus par la rédaction d'une Merge Request qui modifiait cette page de documentation
  • Puis cette Merge Request entrait dans une phase de review par l'équipe, était corrigée, amendée...
  • Et finalement, quand cette Merge Request était approuvée par toute l'équipe, elle était mergée et ensuite respectée par tous

J'ai conservé cette liste afin de pouvoir l'utiliser comme source d'inspiration ou de fondation pour mes prochains projets en équipe.

Pour ceux qui souhaitent s'en inspirer, je recommande de ne pas adopter cette liste intégralement d'emblée. Privilégiez plutôt une sélection ciblée des labels qui correspondent à vos processus actuels, puis incorporez progressivement de nouveaux labels selon l'évolution de vos besoins.

Mon expérience m'a démontré que la mise en place de processus dans une organisation humaine fonctionne mieux par petites étapes successives. Cette approche incrémentale s'avère bien plus efficace que de tenter d'imposer en bloc un processus complet qui risquerait d'être inadapté à votre contexte spécifique.

Voici cette liste.

---

Labels pour indiquer les types d'issue

Une issue doit avoir dans tous les cas un type et un seul type.

• type::user-story : une issue qui apporte une fonctionnalité à l'application
• type::improve : une issue qui apporte une amélioration mineure à une fonctionnalité existante, qui est plus simple de ne pas exprimer sous forme d'une user story, et qui bien sûr n'est pas un bug.
• type::documentation-and-process : problème ou amélioration d'un process ou d'une documentation interne (les deux sujets documentation et processus sont liés parce que les processus sont documentés). La documentation du logiciel à destination des usagers de l'application n'entre pas dans cette catégorie, elles sont du type user-story, improve ou bug.
• type::enabler : un changement qui n'apporte pas directement de valeur aux utilisateurs de l'application. Ce type est utilisé pour des issues dont le but est d'améliorer l'expérience des développeurs (voir définitions : SAFe Enablers,Les enablers en agile)
• type::technical-debt : definition, label à utiliser, par exemple pour des issues dont le bug est d'upgrader une librairie, d'améliorer une implémentation, ou une proposition de refactoring… Ce label ne doit pas être utilisé pour des issues "produit".
• type::support-ops : pour les tâches de support qui ne nécessitent généralement pas de merge request, par exemple : des migrations de données, des corrections de données, des extractions de données…
• type::spike : voir la definition
• type::meta : pour des issues de type "meta", par exemple, des issues dont le but est de créer d'autres issues, de faire de l'affinage d'issues, ou organiser des rituels…
• type::meta-spec-writing : pour des issues dont l'objectif est de créer des issues ou des Epic, dont le but est de rédiger des spécifications techniques, ce sont des sortes d'issues de type "meta", mais plus spécifiques.

• type::bug : pour des issues qui décrivent des dysfonctionnements de l'application
• type::bug-job-CI : pour des issues qui décrivent des bugs de CI

Labels pour indiquer la priorité des issues

• priority::critical : une issue qui doit obligatoirement être traitée tout de suite par un développeur
• priority::24h : une issue qui doit être traitée d'ici 24h
• priority::7days : une issue qui doit être traitée d'ici à 1 semaine

Labels de workflow

Une issue doit avoir un et seulement un label de type workflow, un et un seul label de type product-review.

• Draft
  • workflow::need-product-specs : l'issue doit être spécifiée par un membre de l'équipe produit
  • workflow::need-design : l'issue a besoin de wireframe, design, …
  • workflow::need-tech-specs : l'issue doit être affiner par un membre de l'équipe tech
• To do
  • workflow::ready-for-development : l'issue est prête à être implémentée
  • workflow::to-be-continued : l'issue a été commencée, mais mise en pause parce que le développeur est assigné sur une autre issue.
  • workflow::doing : un développeur est en train de travailler sur cette issue
  • workflow::ready-for-first-review : l'issue est prête à être review par un développeur
  • workflow::ready-for-maintainer-review : l'issue est prête à être review par un maintainers
  • workflow::blocked : l'issue est bloquée Par exemple :
    • l'issue est commencée, elle peut avoir une merge request de prête, mais le développeur ne peut pas la terminer, car elle dépend d'une autre Merge Request en cours d'élaboration ;
    • l'auteur de l'issue attend une réponse d'une personne externe de l'équipe produit ou tech, par exemple un client.
  • workflow::ready-for-merge : l'issue a été review et est prête à être mergé
  • need-cto : l'issue est bloquée parce qu'elle est en attente d'une validation par le CTO
• Product review
  • product-review::needed : indique que l'issue doit être review par un membre de l'équipe produit
  • product-review::not-needed : indique que l'issue n'a pas besoin d'être review par l'équipe produit
  • product-review::pending : issue en attente de review par un membre de l'équipe produit
  • product-review::feedback : une demande de correction a été émise par un membre de l'équipe produit
  • product-review::approved : la Merge Request a été review et validée par un membre de l'équipe produit avec plus aucune demande de correction

Labels d'intégration dans des boards

• board-product-refinement : pour intégrer des issues dans un Kanban board qui contient une liste d'issues que l'équipe produit doit affiner
• board-tech-refinement : pour intégrer des issues dans un Kanban board qui contient une liste d'issues que l'équipe tech doit affiner
• board-support : pour intégrer des issues dans un Kanban board qui contient une liste d'issues de support qui traitent des demandes externes à l'équipe tech ou produit.
• board-cto : utilisé par le CTO pour suivre des issues "cross team"

Labels divers

• first-contribution : pour identifier des issues en théorie facilement réalisables par un nouveau développeur en phase d'onboarding.
• sprint-planning : pour les issues de type meta, dont l'objectif est d'organiser le rituel Sprint Planning.
• sprint-retrospective : pour les issues de type meta, dont l'objectif est d'organiser le rituel Sprint Retrospective.
• sprint-retro-follow-up : pour identifier les sujets qui ont été remontés lors d'une session de Sprint Retrospective.
• triage : pour identifier les issues qui doivent être triées, c'est-à-dire, décider si l'issue doit être abandonnée pour être placée dans un backlog.
• need-to-be-planned : pour identifier des issues validées, mais qui doivent être planifiées, c'est-à-dire, être ajoutées dans un sprint
• danger : pour identifier des issues qui doivent être traitées avec prudence, qui par exemple risquent de détruire des données.
• tech-refinement : pour identifier une issue qui doit être affiner par l'équipe tech, mais qui n'a pas encore été ajoutée dans le board-tech-refinement.
• tech-refinement-removed : pour identifier des issues qui étaient dans un board-tech-refinement mais qui n'ont pas été affiné par manque de temps et donc repoussées à une future session.
• security : pour identifier des issues en lien avec la sécurité informatique, par exemple, un risque de fuite de données, de perte de données, d'intrusion…
• version-outdated : pour identifier les issues dont l'objectif est la mise à jour de librairies ou de services.

Label de compétences nécessaires

Liste de labels peu utilisés, ils permettaient d'identifier les compétences techniques nécessaires pour pouvoir traiter l'issue.

• skills:ansible
• skills:terraform
• skills:nodejs
• skills:postgraphile
• skills:html/css
• skills:docker
• skills:gitlab-ci
• skills:docker
• skills:dev-ops
• skills:postgres
• skills:postgres-rls
• skills:postgres-rbac
• skills:postgresql-plsql
• skills:postgresql-policy
• skills:reactjs
• skills:shellscript
• skills:sql

Je viens de publier un playground au sujet de Gitleaks : gitleaks-playground.

Mes objectifs étaient les suivants :

• Tester la détection d'une clé privé ssh
• Tester la détection d'un password
• Tester la configuration de Gitleaks dans un git hook pre-commit
• Tester comment ignorer les secrets présents dans certains fichiers

J'ai compris que les règles de détections de secrets sont définies dans le fichier /config/gitleaks.toml.

J'ai constaté que par défaut, Gitleaks ne détecte pas ce password :

export PASSWORD="aeFeaxoo3phaikae"

pour corriger ce problème, j'ai été obligé de modifier le niveau de sensibilité de l'entropy de la règle generic-api-key dans le fichier /.gitleaks.toml:

[[rules]]
id = "generic-api-key"
entropy = 2

Le paramètre entropy est définit ici par défaut à 3.5.

J'ai compris qu'il est possible d'ignorer la détection d'un secret soit en ajoutant les Fingerprint dans .gitleaksignore ou alors en ignorant totalement des fichiers, comme ceci dans .gitleaks.toml :

[[allowlists]]
description = "Ignore README"
paths = [
    "README.md"
]

[[allowlists]]
description = "Ignore .secret"
paths = [
    ".secret"
]

Pour configurer le git hooks, j'ai préféré de ne pas utiliser pre-commit afin de ne pas dépendre d'un projet en python. J'utilise un simple script shell : /git-hooks/pre-commit.

Pour activer ce hook, j'utilise la commande git config core.hooksPath git-hooks.

Je trouve cela plutôt simple avec aucune dépendance.

Ici dans le code source de Open WebUI, #JaiDécouvert Pyodide :

Pyodide is a Python distribution for the browser and NodeJS based on WebAssembly.

source

Depuis un an, j'ai pris conscience d'une difficulté inhérente aux organisations qui suivent le paradigme Multirepos, difficulté dont je ne m'étais pas rendu compte auparavant : décider où publier ses issues !

J'ai observé que dès qu'une organisation commence à utiliser plusieurs repositories, la question de l'endroit où créer de nouvelles issues se pose. Par exemple :

• Où poster une issue d'amélioration qui nécessite des changements dans le repository A et B ?
• Où créer une issue d'une proposition d'un process qui ne concerne pas spécifiquement le code source d'un projet hébergé dans un repository ?
• Où créer une issue dont le but est de créer un nouveau service ?

Quand une organisation suit le paradigme Monorepo avec issues colocalisées et utilise, comme je l'explique dans la note "Nom et arborescence de Monorepo" un nom non spécifique, alors la question de l'endroit où publier ses issues ne se pose pas ! Il suffit de publier l'issue dans le Monorepo (par exemple sur GitHub, GitLab ou Forgejo).

Le gestionnaire d'issue du Monorepo est un point de schelling, c'est-à-dire un endroit où tous les développeurs convergent naturellement en l'absence de communication explicite pour trouver et créer des issues.

Ce paradigme évite des débats à propos de l'endroit où publier les issues.

Je suis un adepe du paradigme Monorepo, de la documentation colocalisée et des issues colocalisées.

Je conseille de nommer le repository avec le nom de l'organisation.

Par exemple, si mon organisation se nomme « Dummy Tech » et si elle utilise GitLab, alors je conseille d'utiliser le slug dummy-tech, ce qui donne gitlab.com/dummy-tech/dummy-tech/ et « Dummy Tech Monorepo » comme titre de repository.

La neutralité de ce nom facilite les décisions concernant ce qui peut ou non être inclus dans le repository, sans être limité par un nom trop restrictif. Il est flexible face à l'évolution du projet. Il permet d'éviter bien des débats à propos du nommage.

En 2018, sur GitHub, j'ai découvert un exemple de monorepo d'une organisation. Cet exemple m'a servi de base et je l'ai fait évoluer quand je travaillais chez Spacefill.

Voici un exemple d'arborescence de monorepo que j'aime utiliser :

dummy-tech
├── deployments
│   ├── prod
│   └── sandbox
├── ci
├── docs
├── playgrounds
│   ├── playground_a
│   └── playground_b
├── services
│   ├── service_a
│   ├── service_b
│   └── service_c
└── tools
    ├── tool_a
    ├── tool_b
    └── tool_c

Je gère actuellement un projet comprenant 8 Merge Requests empilées (Stacked PRs) en cours de review, s'étendant sur une période d'environ deux mois.

Au fur et à mesure que je continue à travailler sur ce projet, j'ai effectué à plusieurs reprises des améliorations ou des corrections qui concernent des commits déjà en cours de review.

Si ces Merge Request étaient mergés, cela ne me poserait pas de problème. Je proposerai de nouvelles Merge Request avec ces changements.

Dans la situation actuelle, si je souhaite effectuer une amélioration dans la Merge Request numéro 2, je préfère modifier directement cette Merge Request plutôt que d'en créer une nouvelle. Cette approche me semble plus logique et propre, surtout pour une Merge Request qui n'a pas encore été review.

En pratique, la modification de la Merge Request numéro 2 est une tâche fastidieuse. Si je modifie cette Merge Request, je vais devoir propager mon changement sur 6 branches et résoudre de nombreux conflits. J'ai peur de faire une erreur.

Cette opération est très pénible.

C'est pour cette raison que j'ai étudié dernièrement Stacked Git et Jujutsu.

Je me demande quel outil serait le plus adapté pour gérer ma problématique.
git-stack, git-branchless, Stacked Git ou Jujutsu 🤔.

Suite à la lecture du thread "jj tips and tricks" Lobster, je suis tombé dans un rabbit hole (1h30) : #JaiLu les articles ci-dessous au sujet de Jujutsu.

• "What I've learned from jj" (134 commentaires Hacker News et 57 commentaires Lobster)
  • Et ses sous-articles :
    • "First-class conflicts"
    • "Why some of us like "interdiff" code review"
    • "In Praise of Stacked PRs"
      • "Small CLs"
• "jj tips and tricks"

Quelques commentaires au sujet de l'article "What I've learned from jj"

Along with describing and making new changes, jj squash allows you to take some or all of the current change and “squash” it into another revision. This is usually the immediate parent, but can be any revision.

...

With jj squash, the current change is pushed into whatever target revision you want. And if that change has children, they’ll all be automatically rebased to incorporate the updated code, no additional work is needed.

source

J'ai hâte de tester si, à l'usage, c'est sensiblement plus simple qu'avec Git 🤔.

Conflict resolution

One of the consequences of being able to modify changes in-place is that all subsequent changes need to be rebased to account for the updated parent. If there were a sequence s -> t -> u -> v and you’d modified t, jj will automatically rebase the rest: s -> t' -> u' -> v'. This includes conflicts, if any arise. The difference from git is that conflicts are not a stop-the-world event! You’ll see in the jj log output that changes have a conflict, but it won’t prevent a command (like an explicit or implicit rebase) from running to completion. You get to choose when and how to resolve the conflicts afterward. I found this a surprising benefit: rebases are already less stressful because of how easy undo is, but now I’m no longer interrupted and forced to resolve conflicts immediately.

source

Cette simplicité annoncée me surprend vraiment. J'ai du mal à imaginer le fonctionnement, sans doute parce que je suis trop habitué à utiliser Git. J'ai l'impression que c'est de la magie !

J'ai hâte de tester !

... efforts to add Change-ID as a supported header in git itself to enable durable change tracking on top of commits.

source

J'ai découvert cette initiative, je trouve cela très intéressant👌.

---

Un commentaire au sujet de l'article "First-class conflicts"

First-class conflicts

...

Unlike most other VCSs, Jujutsu can record conflicted states in commits. For example, if you rebase a commit and it results in a conflict, the conflict will be recorded in the rebased commit and the rebase operation will succeed. You can then resolve the conflict whenever you want. Conflicted states can be further rebased, merged, or backed out. Note that what's stored in the commit is a logical representation of the conflict, not conflict markers; rebasing a conflict doesn't result in a nested conflict markers (see technical doc for how this works).

source

Je trouve cela très intéressant.

Voici une commande pour extraire un patch avec l'inclusion des "Conflict markers" (je n'ai pas encore testé) :

$ jj diff --include-conflicts > conflicts.patch

---

Un commentaire au sujet de l'article "In Praise of Stacked PRs"

“Stacked PRs” is the practice of breaking up a large change into smaller, individually reviewable PRs which can depend on each other, forming a DAG.

source

Je suis ravi de découvrir que le terme "Stacked PRs" existe pour décrire le concept que j'expliquais souvent quand j'étais chez Spacefill.

---

En lisant ces articles, #JaiDécouvert :

• git-rerere
• Mercurial Changset Evolution
• git-machete
• git-stack (git-stack)
• GitBulter (https://github.com/gitbutlerapp/gitbutler)

et j'ai "redécouvert" :

• git-branchless git-branchless

#JeSouhaiteLire :

• Working branches and the JJ "way"
• Use the Mikado Method to do safe changes in a complex codebase

Je continue mon travail de mise à niveau en Kubernetes.

Je viens de réaliser que Helmfile ne fait pas directement partie du projet Helm. Je trouve cela surprenant. Ces deux projets sont réalisés par deux equipes différentes :

• Dépôt GitHub de Helm : https://github.com/helm/helm/
  • Développeurs principaux :
    • Matt Butcher basé aux États-Unis
    • Adam Reese basé aux États-Unis
• Dépôt GitHub de Helmfile : https://github.com/helmfile/helmfile/
  • Développeurs principaux :
    • Yusuke Kuoka basé au Japon
    • yxxhero basé en Chine

D'après ce que je comprends, si je simplifie, Helmfile est pour Helm l'équivalent de ce qu'est docker-compose.yml pour Docker.

---

Je m'intéresse aujourd'hui à Helmfile parce que je souhaite effectuer une tâche qui correspond au use-case numéro 2 décrit dans la documentation :

ArgoCD has support for kustomize/manifests/helm chart by itself. Why bother with Helmfile?

The reasons may vary:

• 1. You do want to manage applications with ArgoCD, while letting Helmfile manage infrastructure-related components like Calico/Cilium/WeaveNet, Linkerd/Istio, and ArgoCD itself.
• 2. You want to review the exact K8s manifests being applied on pull-request time, before ArgoCD syncs.
• 3. This is often better than using a kind of HelmRelease custom resources that obfuscates exactly what manifests are being applied, which makes reviewing harder.

source

Suite à cette lecture, voici comment j'ai mis en application une partie du use-case 2.

J'ai ce helmfile.yaml :

environments:
  dev:
    values:
      - version: 6.1.0
  production:
    values:
      - version: 6.1.0
---
repositories:
  - name: open-webui
    url: https://helm.openwebui.com/
---
releases:
  - name: openwebui
    namespace: {{ .Namespace }}
    chart: open-webui/open-webui
    values:
      - ./env.d/{{ .Environment.Name }}/values.yaml
    version: {{ .Values.version }}

Et ensuite, j'ai exécuté :

$ helmfile template -e dev --output-dir-template $(pwd)/gitops/{{.Release.Name}}
Adding repo open-webui https://helm.openwebui.com/
"open-webui" has been added to your repositories

Templating release=openwebui, chart=open-webui/open-webui
wrote .../gitops/openwebui/open-webui/charts/pipelines/templates/service-account.yaml
wrote .../gitops/openwebui/open-webui/templates/service-account.yaml
wrote .../gitops/openwebui/open-webui/charts/pipelines/templates/service.yaml
wrote .../gitops/openwebui/open-webui/templates/service.yaml
wrote .../gitops/openwebui/open-webui/charts/pipelines/templates/deployment.yaml
wrote .../gitops/openwebui/open-webui/templates/workload-manager.yaml
wrote .../gitops/openwebui/open-webui/templates/ingress.yaml

Cela me permet ensuite de pouvoir observer avec précision ce qui va être déployé par ArgoCD.

Depuis un an que j'effectue des missions Freelance, j'ai régulièrement besoin d'effectuer des changements dans des projets pour intégrer mes pratiques development kit, telles que l'utilisation de Mise, .envrc, docker-compose.yml, un README guidé, etc.

Généralement, ces missions Freelance sont courtes et je ne suis pas missionné pour faire des propositions d'amélioration de l'environnements de développement.

En un an, j'ai été confronté à cette problématique à cinq reprises.

Jusqu'à présent, j'ai utilisé la méthode suivante :

• J'ai intégré mon development kit dans une branche sklein-devkit
• Cette branche m'a ensuite servi de base pour créer des branches destinées à traiter mes issues, nommées sous la forme sklein-devkit-issue-xxx
• Et pour finir, je transfère mes commits avec git cherry-pick dans une branche du type issue-xxx que je soumettais dans une Merge Request ou Pull Request.

À la base, ce workflow de développement n'est pas très agréable à utiliser, et devient particulièrement complexe lorsque je dois effectuer des git pull --rebase sur la branche sklein-devkit !

Dans les semaines à venir, pour le projet Albert Conversation, je dois trouver une solution élégante pour gérer un cas similaire. Il s'agit de maintenir des modifications (série de patchs) du projet https://github.com/open-webui/open-webui qui :

• seront soit intégrées au projet upstream après plusieurs semaines ou mois
• soit resteront spécifiques au projet Albert Conversation et ne seront jamais intégrées en upstream, comme par exemple l'intégration du Système de Design de l'État.

Je me souviens avoir été marqué par l'histoire du projet Real-Time Linux mentionnée dans l'épisode 118 du podcast de Clever Cloud : les développeurs de Real-Time Linux ont maintenu pendant 20 ans toute une série de patchs avant de finir par être intégrés dans le kernel upstream (source : la conférence "PREEMPT_RT over the years") !

Voici la liste des patchs maintenus par l'équipe Real-Time Linux :

└── patches
    ├── 0001-arm-Disable-jump-label-on-PREEMPT_RT.patch
    ├── 0001-ARM-vfp-Provide-vfp_state_hold-for-VFP-locking.patch
    ├── 0001-drm-i915-Use-preempt_disable-enable_rt-where-recomme.patch
    ├── 0001-hrtimer-Use-__raise_softirq_irqoff-to-raise-the-soft.patch
    ├── 0001-powerpc-Add-preempt-lazy-support.patch
    ├── 0001-sched-Add-TIF_NEED_RESCHED_LAZY-infrastructure.patch
    ├── 0002-ARM-vfp-Use-vfp_state_hold-in-vfp_sync_hwstate.patch
    ├── 0002-drm-i915-Don-t-disable-interrupts-on-PREEMPT_RT-duri.patch
    ├── 0002-locking-rt-Remove-one-__cond_lock-in-RT-s-spin_trylo.patch
    ├── 0002-powerpc-Large-user-copy-aware-of-full-rt-lazy-preemp.patch
    ├── 0002-sched-Add-Lazy-preemption-model.patch
    ├── 0002-timers-Use-__raise_softirq_irqoff-to-raise-the-softi.patch
    ├── 0002-tracing-Record-task-flag-NEED_RESCHED_LAZY.patch
    ├── 0003-ARM-vfp-Use-vfp_state_hold-in-vfp_support_entry.patch
    ├── 0003-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
    ├── 0003-locking-rt-Add-sparse-annotation-for-RCU.patch
    ├── 0003-riscv-add-PREEMPT_LAZY-support.patch
    ├── 0003-sched-Enable-PREEMPT_DYNAMIC-for-PREEMPT_RT.patch
    ├── 0003-softirq-Use-a-dedicated-thread-for-timer-wakeups-on-.patch
    ├── 0004-ARM-vfp-Move-sending-signals-outside-of-vfp_state_ho.patch
    ├── 0004-drm-i915-Disable-tracing-points-on-PREEMPT_RT.patch
    ├── 0004-locking-rt-Annotate-unlock-followed-by-lock-for-spar.patch
    ├── 0004-sched-x86-Enable-Lazy-preemption.patch
    ├── 0005-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
    ├── 0005-sched-Add-laziest-preempt-model.patch
    ├── 0006-drm-i915-Drop-the-irqs_disabled-check.patch
    ├── 0007-drm-i915-guc-Consider-also-RCU-depth-in-busy-loop.patch
    ├── 0008-Revert-drm-i915-Depend-on-PREEMPT_RT.patch
    ├── 0053-serial-8250-Switch-to-nbcon-console.patch
    ├── 0054-serial-8250-Revert-drop-lockdep-annotation-from-seri.patch
    ├── Add_localversion_for_-RT_release.patch
    ├── ARM__Allow_to_enable_RT.patch
    ├── arm-Disable-FAST_GUP-on-PREEMPT_RT-if-HIGHPTE-is-als.patch
    ├── ARM__enable_irq_in_translation_section_permission_fault_handlers.patch
    ├── netfilter-nft_counter-Use-u64_stats_t-for-statistic.patch
    ├── POWERPC__Allow_to_enable_RT.patch
    ├── powerpc_kvm__Disable_in-kernel_MPIC_emulation_for_PREEMPT_RT.patch
    ├── powerpc_pseries_iommu__Use_a_locallock_instead_local_irq_save.patch
    ├── powerpc-pseries-Select-the-generic-memory-allocator.patch
    ├── powerpc_stackprotector__work_around_stack-guard_init_from_atomic.patch
    ├── powerpc__traps__Use_PREEMPT_RT.patch
    ├── riscv-add-PREEMPT_AUTO-support.patch
    ├── sched-Fixup-the-IS_ENABLED-check-for-PREEMPT_LAZY.patch
    ├── series
    ├── sysfs__Add__sys_kernel_realtime_entry.patch
    └── tracing-Remove-TRACE_FLAG_IRQS_NOSUPPORT.patch

46 files

J'ai été impressionné, je me suis demandé comment cette équipe a réuissi à gérer ce projet aussi complexe sur une si longue durée sans finir par se perdre !

Real-Time Linux n'est pas le seul projet qui propose des versions patchées du kernel, c'est le cas aussi du projet Xen, Openvz, etc.

J'ai essayé de comprendre le workflow de développement de ces projets. Avec l'aide de Claude.ia, il semble que ces projets utilisent un outil comme quilt qui permet de gérer des séries de patchs.

Il semble aussi que Debian utilise quilt pour gérer des patchs ajoutés aux packages :

Quilt has been incorporated into dpkg, Debian's package manager, and is one of the standard source formats supported from the Debian "squeeze" release onwards.

source

J'ai creusé un peu de sujet et à l'aide de Claude.ia j'ai découvert des alternatives "modernes" à quilt.

• Git lui-même :
  • git format-patch pour créer des séries de patches
  • git am pour appliquer des patches
  • git range-diff pour comparer des séries de patches
  • Branches de fonctionnalités + git rebase -i pour organiser les commits
• Stacked Git (https://stacked-git.github.io/) :
  • Conçu spécifiquement comme une alternative moderne à Quilt
  • S'intègre mieux avec Git
  • Maintient une pile de patches comme Quilt mais dans l'écosystème Git
• Topgit (https://github.com/mackyle/topgit) :
  • Gère des changements de code sous forme de piles (stacks)
  • Permet de maintenir des patches à long terme pour des forks
• Git Patchwork - (https://github.com/getpatchwork/patchwork) :
  • Système de gestion et suivi des patches envoyés par email
  • Utilisé par le noyau Linux et d'autres projets open source
• Guilt (http://repo.or.cz/w/guilt.git) :
  • Clone de Quilt implémenté comme scripts Git
  • Intégration très proche de Git
• Jujutsu :
  • Système de contrôle de version moderne basé sur Git
  • Meilleure gestion des branches et séries de patches
• Git Series (https://github.com/git-series/git-series) :
  • Outil pour travailler avec des séries de patches Git
  • Permet de suivre l'évolution des séries au fil du temps

Après avoir jeté un œil sur chacun de ces projets, j'envisage de créer un playground pour tester Stacked Git.

Depuis quelques semaines, je vois de plus en plus de sites web qui intègrent Anubis. Par exemple sur https://gitlab.gnome.org/, https://priv.au/ et à l'instant sur https://forge.libre.sh/indiehosters.

Anubis weighs the soul of your connection using a proof-of-work challenge in order to protect upstream resources from scraper bots.

source

Voici ce qu'Anubis affiche à la première connexion au site web :

Alexandre m'a partagé kubectx et kubens (https://github.com/ahmetb/kubectx) :

What are kubectx and kubens?

kubectx is a tool to switch between contexts (clusters) on kubectl faster. kubens is a tool to switch between Kubernetes namespaces (and configure them for kubectl) easily.

source

---

#JaiDécouvert Kubebuilder (https://github.com/kubernetes-sigs/kubebuilder) (from)

Kubebuilder is a framework for building Kubernetes APIs using custom resource definitions (CRDs).

source

#JaiDécouvert Krew (https://github.com/kubernetes-sigs/krew) :

Krew is a tool that makes it easy to use kubectl plugins. Krew helps you discover plugins, install and manage them on your machine. It is similar to tools like apt, dnf or brew. Today, over 200 kubectl plugins are available on Krew.

source

---

#JaiDécouvert MetalLB (https://metallb.io/) :

MetalLB is a load-balancer implementation for bare metal Kubernetes clusters, using standard routing protocols.

source

---

#JaiDécouvert cert-manager (https://github.com/cert-manager/cert-manager)

cert-manager adds certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of obtaining, renewing and using those certificates.

It supports issuing certificates from a variety of sources, including Let's Encrypt (ACME), HashiCorp Vault, and Venafi TPP / TLS Protect Cloud, as well as local in-cluster issuance.

source

J'ai publié une première version du Projet 28 - "Publier un repository playground de déploiement de Open WebUI basé sur docker-compose.yml".

https://github.com/stephane-klein/open-webui-deployment-playground/

Je vais maintenant attaquer le Projet 29 - "Publier un repository playground de déploiement de Open WebUI sur un cluster Kubernetes".