Hier soir, je suis tombé sur NetPeek et franchement, ça m’a fait plaisir de voir qu’enfin quelqu’un s’attaque au problème de la complexité de nmap pour les utilisateurs normaux.

NetPeek, c’est donc cette nouvelle application qui vient d’arriver sur Flathub et qui promet de simplifier drastiquement le scanning réseau sous Linux. Développée par ZingyTomato avec Python et GTK4/libadwaita, l’app adopte le design moderne de GNOME pour offrir une alternative graphique aux outils en ligne de commande comme nmap.

La première chose qui frappe quand on lance NetPeek, c’est donc sa simplicité. L’interface est épurée, moderne, et on comprend tout de suite ce qu’on doit faire. Vous saisissez votre plage d’adresses IP (notation CIDR, ranges ou adresses simples), vous cliquez sur “Scanner” et hop, l’application se met au travail.

Ce qui rend NetPeek particulièrement efficace également, c’est son système “multithreadé” qui accélère considérablement les scans. L’app détecte ainsi automatiquement votre plage IP locale, ce qui évite de se prendre la tête avec les configurations et une fois le scan terminé, les appareils s’affichent dans l’ordre croissant avec leurs ports ouverts. Ensuite, vous pouvez copier les adresses IP d’un simple clic.

L’outil s’appuie sur des bibliothèques Python classiques telles que socket pour les opérations réseau, ipaddress pour la validation des IP, threading pour le scan concurrent et ping3 pour tester la disponibilité des hôtes.

Et ce qui me plaît avec NetPeek, c’est qu’il ne cherche pas à rivaliser avec les mastodontes comme nmap ou Zenmap. Non, son objectif est clair, à savoir répondre à la question “Quels sont les appareils actifs sur mon réseau et quels ports sont ouverts ?” sans avoir besoin d’un doctorat en administration réseau. D’une certaine manière, ça me fait penser un peu à Angry IP Scanner …

L’installation se fait principalement via Flathub avec la commande

flatpak install flathub io.github.zingytomato.netpeek

Mais les utilisateurs d’Arch Linux peuvent aussi passer par les packages AUR netpeek ou netpeek-git.

L’app s’intègre notamment parfaitement dans l’environnement GNOME moderne avec son interface libadwaita qui respecte les thèmes système. Voilà, si ça vous chauffe, vous pouvez télécharger NetPeek directement depuis Flathub ou consulter le code source sur GitHub .

Ça devrait bien vous aider pour surveiller votre réseau domestique, diagnostiquer des problèmes de connectivité ou simplement découvrir tous les appareils connectés chez vous.

Source

Si vous avez déjà passé 20 minutes à déboguer un cron job qui ne se lance pas parce que vous aviez mis un espace au mauvais endroit dans la syntaxe * * * * *, vous allez adorer CronMaster .

Car le problème avec cron, c’est pas le concept en lui-même. L’idée de planifier des tâches automatiques reste géniale depuis les années 70. Non, le souci c’est cette syntaxe ésotérique qui fait que même les devs expérimentés doivent vérifier trois fois leur ligne avant de valider. Un petit 0 2 * * 1-5 et vous vous demandez si ça va se lancer tous les lundis ou tous les jours de la semaine à 2h du matin.

CronMaster arrive donc avec une proposition simple qui est de conserver la puissance de cron tout en rendant son utilisation intuitive. L’interface web affiche vos jobs sous forme de cartes visuelles, avec le nom de la tâche, sa fréquence d’exécution en langage humain et la possibilité de les activer/désactiver d’un clic. Plus besoin de commenter/décommenter des lignes dans le crontab.

CronMaster ne réinvente pas cron. Il se pose juste comme une couche visuelle par-dessus le système existant. Vos jobs continuent de tourner via le crontab système, mais vous les gérez depuis une interface moderne avec du dark mode, des stats système en temps réel (CPU, RAM, uptime) et même la possibilité de gérer des scripts bash directement depuis l’interface.

L’installation passe par Docker, ce qui simplifie énormément le déploiement. Un simple docker-compose.yml avec quelques variables d’environnement et vous avez votre interface accessible sur le port 40123. Le projet supporte aussi bien AMD64 qu’ARM64, donc ça tourne aussi bien sur votre serveur que sur un Raspberry Pi.

CronMaster n’est pas le seul dans sur créneau. Y’a Cronicle qui propose par exemple une solution multi-serveurs avec des graphiques de performance en temps réel et une gestion des dépendances entre tâches ou encore Crontab-UI qui mise plutôt sur la simplicité avec import/export de configurations et système de backup automatique.

Mais CronMaster a ses propres atouts. Son système d’informations système intégré permet de voir en un coup d’œil l’état de votre serveur pendant que vos jobs tournent. Et le support des variables d’environnement HOST_PROJECT_DIR facilite l’intégration dans des workflows existants. Sans oublier la possibilité de gérer plusieurs utilisateurs crontab depuis la même interface est pratique pour les équipes.

Un détail technique important… CronMaster nécessite les droits root dans le conteneur Docker pour accéder au crontab système. C’est un choix assumé du dev pour garantir une intégration transparente avec le système existant. Donc si vous préférez une approche plus isolée, Zeit propose une alternative desktop en C++ qui tournera sur votre ordi.

Le format cron reste toujours le même : minute (0-59), heure (0-23), jour du mois (1-31), mois (1-12) et jour de la semaine (0-7), mais avec CronMaster, vous avez des sélecteurs visuels qui génèrent automatiquement la bonne syntaxe comme ça, plus besoin de se rappeler que */5 signifie “toutes les 5 minutes” ou que 0,30 veut dire “à la minute 0 et 30”.

L’interface affiche aussi les logs d’exécution de chaque job, ce qui facilite grandement le debug. Au lieu de fouiller dans /var/log/syslog ou de configurer des redirections complexes avec >> /var/log/monjob.log 2>&1, tout est accessible depuis l’interface web.

Pour les développeurs qui bossent sur plusieurs projets, la fonctionnalité de commentaires sur chaque job est également super pratique. Vous pouvez documenter pourquoi tel script doit tourner à 3h du matin ou rappeler les dépendances d’un job particulier. Ces métadonnées restent attachées au job dans l’interface, contrairement aux commentaires dans le crontab qui peuvent facilement se perdre.

Voilà, donc si vous gérez régulièrement des cron jobs et que vous en avez marre de cette syntaxe cryptique, vous adorerez CronMaster !! C’est à découvrir ici !

Y’a quelques mois, je me suis amusé à reprendre le projet DeepSite d’Enzostvs et à le transformer complètement pour fonctionner en 100% local. J’ai baptisé ça LocalSite , et ça permet en gros de générer des pages web ou des éléments HTML / CSS / JS à l’aide d’une IA mais en local.

Ça s’appuie donc sur Ollama pour faire tourner les modèles d’IA directement sur votre ordinateur, comme ça, pas de connexion cloud, pas d’abonnement à payer, pas de données qui partent on ne sait où en Chine ou ailleurs. Vous tapez une description de ce que vous voulez, vous sélectionnez un modèle Ollama, et hop, votre site web se génère sous vos yeux.

L’installation est assez simple. Il vous faut d’abord Ollama installé sur votre machine et ensuite, vous récupérez un modèle, par exemple deepseek-r1:7b avec la commande

ollama pull deepseek-r1:7b.

Et une fois Ollama lancé avec

ollama serve

il ne reste plus qu’à installer LocalSite avec npm :

git clone https://github.com/Korben00/LocalSite.git
npm instal
npm run dev

Ensuite, direction localhost:3001 et c’est parti.

Pour l’interface, vous avez donc un éditeur Monaco intégré (le même que dans VS Code), une preview en temps réel qui s’adapte aux différentes tailles d’écran (desktop, tablette, mobile), et la possibilité de basculer entre génération et édition manuelle du code. C’est super pratique pour peaufiner le résultat une fois que l’IA a fait le gros du travail.

Pour ceux qui se demandent quels modèles utiliser, d’après les benchmarks 2025 , CodeLlama 34B reste une référence pour la génération de code HTML/CSS/JavaScript. Mais si votre machine est plus modeste, les versions 7B ou 13B font déjà très bien le job. Qwen2.5-Coder est aussi une excellente alternative, surtout si vous voulez intégrer du code plus complexe dans vos pages. Vous pouvez aussi tenter avec des modèles “Thinking” comme GPT OSS si ça vous chauffe…

Bref, là où DeepSite original nécessite obligatoirement une connexion à Hugging Face et utilise les serveurs API de DeepSeek (donc ça coûte aussi des sous), mon petit LocalSite fait tout en local. Vos données restent chez vous, vous pouvez bosser offline, et surtout, pas de limite d’utilisation. Vous pouvez donc générer autant de sites que vous voulez, tester différents modèles, expérimenter sans compter comme dirait Macron.

L’aspect vie privée n’est pas négligeable non plus car ça permet de prototyper rapidement, et avoir une solution 100% locale évite pas mal de questions juridiques sur la confidentialité des données.

Techniquement, l’architecture repose sur Node.js côté serveur et communique avec Ollama via son API locale. Le code généré est du pur HTML/CSS/JavaScript vanilla, donc compatible partout. Et vous pouvez directement copier-coller le résultat ou télécharger le projet HTML complet (j’ai ajouté un import / export de projets zip). Pas de framework lourd, pas de dépendances obscures, juste du code web standard.

Pour les développeurs qui veulent pousser plus loin, le code source est bien sûr disponible et modifiable. Vous pouvez ajouter vos propres templates, personnaliser les prompts système, ou même intégrer d’autres modèles compatibles avec Ollama.

Il vous faudra quand même un minimum de RAM pour faire tourner les modèles (comptez 8 Go pour les modèles 7B, 16 Go pour les 13B, et 32 Go pour les gros modèles 33B+) mais vu les capacités de génération et l’indépendance totale vis-à-vis du cloud, ça vaut le coup surtout que les modèles dispo dans Ollama progressent rapidement et deviennent de plus en plus optimisés. Je pense par exemple à GPT-OSS.

Bref, j’ai pris une idée cool (DeepSite), et je l’ai réadapté à l’aide de Claude Code et de mes maigres connaissances, pour la rendre accessible et respectueuse de la vie privée et du coup, je trouve ça encore plus cool ^^. Par contre, je suis un garçon assez occupé et je ne suis pas mainteneur de projet open source donc si vous voulez des modifs dedans ou si vous voyez des bugs, faudra vous y coller vous-même ^^.

Si ça vous dit de tester, c’est par ici.

En ce moment, les développeurs s’extasiaient sur un truc appelé Jujutsu , ou “jj” pour les intimes. Au début, j’ai cru à une énième tentative de réinventer la roue puis j’ai creusé, et j’ai compris pourquoi ça fait autant parler.

Vous connaissez cette frustration avec Git ? Quand vous galérez avec l’index, que vous oubliez de stash vos modifs avant de changer de branche, ou que vous priez pour ne pas foirer votre rebase ? Eh bien, Martin von Zweigbergk, ingénieur chez Google et ancien contributeur Mercurial, a décidé qu’on méritait mieux.

Du coup, il a créé Jujutsu, un système de contrôle de version qui garde tous les avantages de Git en supprimant ses complexités.

Le principe de Jujutsu tient en une phrase : votre répertoire de travail EST un commit. Poh Poh Poh !!

Fini l’index, fini le staging area, fini les acrobaties pour synchroniser vos modifications. À chaque fois que vous sauvegardez un fichier, jj crée automatiquement un nouveau commit avec un hash différent, mais conserve un “change ID” stable qui survit aux réécritures. C’est complètement fou et pourtant ça marche.

Installation de Jujutsu

Pour installer jj, vous avez plusieurs options selon votre OS. Sur macOS avec Homebrew :

brew install jj

# Via Cargo (nécessite Rust)
cargo install --locked jj

# Sur Arch Linux
pacman -S jujutsu

# Sur NixOS
nix-env -iA nixpkgs.jujutsu

# Via Winget
winget install --id martinvonz.jj

# Via Scoop
scoop bucket add extras
scoop install jujutsu

jj config set --user user.name "Votre Nom"
jj config set --user user.email "[email protected]"

# Créer un nouveau repo jj
jj git init myproject

# Coexister avec un repo Git existant
cd existing-git-repo
jj git init --git-repo=.

# Cloner un repo Git avec jj
jj git clone https://github.com/user/repo.git

# Voir l'état actuel (équivalent de git status + git log)
jj st
jj log

# Créer une nouvelle branche de travail
jj new -m "Début de ma nouvelle feature"

# Modifier des fichiers (pas besoin de git add !)
echo "Hello Jujutsu" > README.md
# Les changements sont automatiquement suivis

# Voir les modifications
jj diff

# Créer un nouveau commit basé sur le précédent
jj new -m "Ajout de la documentation"

# Revenir au commit précédent
jj edit @-

# Naviguer dans l'historique
jj edit <change-id></change-id>

# Merger deux branches (les conflits sont sauvegardés si présents)
jj new branch1 branch2

# Voir les conflits
jj st

# Les conflits sont stockés dans le commit, vous pouvez continuer à travailler
jj new -m "Travail sur autre chose pendant que le conflit existe"

# Revenir résoudre le conflit plus tard
jj edit <conflict-commit-id>

# Après résolution manuelle
jj squash # Pour intégrer la résolution</conflict-commit-id>

# Voir l'historique des opérations
jj op log

# Annuler la dernière opération
jj undo

# Revenir à un état précédent spécifique
jj op restore <operation-id>

# Réorganiser des commits (équivalent de rebase interactif)
jj rebase -s <source> -d <destination>

# Éditer un commit ancien
jj edit <change-id>
# Faire vos modifications
jj squash # Pour intégrer dans le commit actuel

# Split un commit en plusieurs
jj split</change-id></destination></operation-id>

# Commencer une nouvelle feature
jj new main -m "feat: ajout authentification OAuth"

# Travailler sur les fichiers
vim auth.js
vim config.js

# Pas besoin de git add ! Les changements sont auto-trackés
jj diff # Voir ce qui a changé

# Créer un checkpoint pour continuer
jj new -m "wip: OAuth provider setup"

# Oh, un bug urgent à fix sur main !
# Pas besoin de stash, on switch directement
jj new main -m "fix: correction crash login"

# Fix le bug
vim login.js

# Revenir à notre feature OAuth
jj edit @- # Revient au commit précédent

# Finaliser la feature
jj describe -m "feat: authentification OAuth complète"

# Pusher vers Git
jj git push

# Synchroniser avec le remote Git
jj git fetch

# Pusher vos changements
jj git push

# Créer une branche Git depuis un change jj
jj branch create ma-feature
jj git push --branch ma-feature

# Importer les changements depuis Git
jj git import

# Exporter vers Git (automatique généralement)
jj git export

# Voir l'historique en mode graphique
jj log --graph

# Chercher dans l'historique
jj log -r 'description(regex:"fix.*bug")'

# Travailler avec plusieurs parents (merge commits)
jj new parent1 parent2 parent3

# Abandonner des changements locaux
jj abandon <change-id>

# Dupliquer un commit ailleurs
jj duplicate <change-id> -d <destination>

# Voir les changements entre deux commits
jj diff -r <from> -r <to>

# Créer un alias pour une commande fréquente
jj config set --user alias.l 'log --graph -r "ancestors(., 10)"'
jj l # Utilise l'alias</to></from></destination></change-id></change-id>

# Définir votre éditeur préféré
jj config set --user ui.editor "code --wait"

# Activer les couleurs dans le terminal
jj config set --user ui.color "always"

# Configurer le format de log par défaut
jj config set --user ui.default-revset "@ | ancestors(@, 10)"

# Voir toute la configuration
jj config list --user

# Éditer directement le fichier de config
jj config edit --user

Vous la connaissez cette fatigue de quand vous lancez votre serveur de dev et que ce satané message d’erreur EADDRINUSE vous annonce que le port 3000 est déjà utilisé ? Et bien moi oui, et visiblement je ne suis pas le seul puiqu’un développeur de talent a décidé que c’était la goutte d’eau et a créé Port Kill , une petite app macOS qui vit tranquillement dans votre barre de menu et qui surveille les ports ouverts comme le vigile de Franprix vous surveille.

Comme ça, au lieu de jouer au jeu du chat et de la souris avec lsof, netstat et kill dans votre terminal, Port Kill scanne automatiquement tous les ports entre 2000 et 6000 toutes les 5 secondes et vous dit ce qui est ouvert. Alors pourquoi cette plage ? Hé bien parce que c’est là que la plupart d’entre nous faisons tourner nos serveurs de développement. React sur 3000, Vue sur 8080, votre API custom sur 5000… Vous voyez le tableau.

Ce qui est sympa avec Port Kill, c’est l’interface. L’icône dans la barre de menu change de couleur selon le nombre de processus détectés. Vert quand tout est clean, rouge quand vous avez entre 1 et 9 processus qui traînent, et orange quand ça part en cacahuète avec plus de 10 processus. Un clic sur l’icône et vous avez la liste complète avec la possibilité de tuer chaque processus individuellement ou de faire table rase d’un coup.

Techniquement, c’est du solide puisque c’est écrit en Rust (hé oui parce qu’en 2025, si c’est pas du Rust, c’est has-been), l’app utilise les commandes système lsof pour détecter les processus. Et la stratégie de kill de l’outil est plutôt intelligente puisqu’il fait d’abord un SIGTERM poli pour demander gentiment au processus de se barrer, et si au bout de 500ms ce dernier fait le têtu, PAF, un SIGKILL dans les dents. C’est la méthode douce-ferme, comme quand vous demandez à votre chat de descendre du clavier.

Le contexte, c’est qu’on a tous galéré avec ça. L’erreur EADDRINUSE est un classique du dev web. Vous fermez mal votre serveur avec Ctrl+C, ou pire, vous fermez juste la fenêtre du terminal, et hop, le processus continue de tourner en arrière-plan comme un zombie. Sur macOS, c’est encore plus vicieux depuis Monterey avec AirPlay qui squatte le port 5000 par défaut.

Il existe d’autres solutions, bien sûr. Par exemple, Killport est autre un outil en ligne de commande cross-platform écrit aussi en Rust qui fait un job similaire. kill-my-port est un package npm qui fait la même chose. Mais ces outils nécessitent de passer par le terminal à chaque fois. Port Kill, lui, est toujours là, discret dans votre barre de menu, prêt à dégainer.

L’installation est simple : vous clonez le repo GitHub, un petit cargo build --release si vous avez Rust installé, et vous lancez avec ./run.sh. L’app tourne en tâche de fond, consomme quasi rien en ressources, et met à jour son menu contextuel toutes les 3 secondes. Pas de fenêtre principale, pas de configuration compliquée, juste l’essentiel.

Pour les puristes du terminal, oui, vous pouvez toujours faire lsof -ti:3000 | xargs kill -9. Mais franchement, avoir une interface graphique pour ce genre de tâche répétitive, c’est pas du luxe. Surtout quand vous jonglez entre plusieurs projets et que vous ne vous rappelez plus quel port utilise quoi.

Le seul bémol, c’est que c’est limité à macOS pour l’instant donc les développeurs sur Linux et Windows devront se contenter des alternatives en CLI. Mais bon, vu que le code est open source, rien n’empêche quelqu’un de motivé de faire un portage.

Voilà, donc si comme moi vous en avez marre de cette danse répétitive pour trouver et tuer le processus qui squatte votre port, Port Kill mérite que vous y jetiez un oeil.

Hier soir, j’ai découvert un outil qui m’aurait évité des dizaines de commits “fix CI”, “fix CI again”, “please work this time” sur GitHub. J’sais pas si vous aussi vous connaissez cette galère ? Vous modifiez votre workflow GitHub Actions, vous poussez, ça plante, vous corrigez, vous repoussez, ça replante… Bref, votre historique Git ressemble à un journal de débugging en temps réel.

Et heureusement, wrkflw vient mettre fin à ce cauchemar.

Ce petit outil codé en Rust vous permet en fait de valider et d’exécuter vos GitHub Actions directement sur votre machine, sans avoir besoin de pusher quoi que ce soit. L’outil vient d’être annoncé sur le forum Rust et ça va bien aider tout le monde je pense.

Grâce à lui, au lieu de tester vos workflows dans le cloud GitHub (et potentiellement faire planter votre CI/CD devant toute l’équipe… La te-hon…), vous les exécutez localement. Wrkflw parse alors votre fichier YAML, résout les dépendances entre jobs, et lance tout ça soit dans Docker/Podman pour matcher l’environnement GitHub, soit en mode émulation si vous n’avez pas de runtime container sous la main.

Ce qui rend wrkflw vraiment pratique, c’est son interface TUI (Terminal User Interface) qui vous permet de visualiser l’exécution en temps réel. Un simple wrkflw tui et vous avez un dashboard interactif où vous pouvez suivre vos jobs, voir les logs, et comprendre ce qui foire sans avoir à jongler entre 15 onglets GitHub.

L’installation se fait en deux secondes si vous avez Rust :

cargo install wrkflw

Le package est aussi dispo sur crates.io et une fois installé, vous pouvez valider un workflow avec la commande :

wrkflw validate .github/workflows/rust.yml

ou le lancer directement avec

wrkflw run .github/workflows/ci.yml

L’outil détectera automatiquement tous vos workflows et les chargera dans l’interface.

Ce qui est fort avec wrkflow, c’est surtout le support quasi-complet des fonctionnalités de GitHub Actions. Les Matrix builds ? Ça passe ! Les Container actions ? Bah ouais, pas de problème ! Tout ce qui est JavaScript actions ? Check ! Même chose pour les Composite actions et les workflows réutilisables et même les fichiers d’environnement GitHub sont supportés. Bon, il y a quelques limitations évidemment. Vous ne pouvez pas par exemple mettre de secrets GitHub (ce qui est logique), et y’a pas de support Windows/macOS runners, ni pas d’upload/download d’artifacts. Mais pour 90% des cas d’usage, c’est largement suffisant.

Wrkflw s’inscrit dans une tendance plus large d’outils qui cherchent à remplacer Make et ses Makefiles cryptiques. Je pense par exemple à Task (Taskfile) qui est un autre exemple populaire, écrit en Go avec une syntaxe YAML plus moderne ou encore à Act, un autre outil open source qui fait à peu près pareil. Les développeurs cherchent clairement des alternatives plus lisibles et maintenables et wrkflw va encore plus loin en se spécialisant sur GitHub Actions.

Le mode Docker/Podman de wrkflw permet par exemple de créer des containers qui matchent au plus près l’environnement des runners GitHub. Et si jamais vous interrompez l’exécution avec Ctrl+C, pas de panique, puisque l’outil nettoie automatiquement tous les containers créés. Comme ça, y’aura plus de containers zombies qui traînent après vos tests.

Et pour tous ceux qui bossent en mode émulation sécurisée (sans Docker), wrkflw exécute les actions dans un environnement sandboxé. C’est moins fidèle à l’environnement GitHub mais au moins ça permet de tester rapidement sans avoir besoin d’installer Docker. Pratique sur des machines de dev légères ou des environnements restrictifs.

Le workflow de test devient donc le suivant : 1/ Vous modifiez votre YAML. 2/ Vous lancez wrkflw run . 3/ Vus voyez immédiatement si ça marche. 4/ Vous corrigez si besoin. 5/ Et c’est seulement ensuite que vous poussez sur GitHub. Plus de commits de debug, plus de CI cassée, plus de collègues qui râlent parce que la pipeline est tout rouge ^^.

L’outil est encore jeune bien sûr mais déjà très prometteur. Les prochaines versions devraient ajouter le support des secrets locaux, une meilleure intégration avec GitLab CI, et peut-être même le support des runners Windows/macOS.

Bref, si vous gérez des workflows GitHub Actions complexes, wrkflw va rapidement devenir indispensable à votre life.

A découvrir ici !

Vous savez ce qui m’a toujours ennuyé avec git blame ? C’est qu’à chaque refactoring, chaque reformatage de code, chaque déplacement de fichier, tous les noms disparaissent pour être remplacés par celui de la personne qui a fait ces modifications. Du coup, impossible de savoir qui a vraiment écrit le code original. Heureusement, un développeur nommé Sinclair Target vient de sortir un outil qui résout ce problème.

git-who (c’est son nom) fait donc exactement ce que git blame aurait dû faire depuis le début à savoir analyser qui a vraiment contribué à votre codebase, et pas juste qui a touché les lignes en dernier. Au lieu de se contenter d’une analyse ligne par ligne comme git blame, git-who analyse les patterns de contribution sur des fichiers entiers, des dossiers, voire des composants complets.

L’installation est simple comme bonjour. Si vous êtes sur Mac avec Homebrew, un petit brew install git-who et c’est réglé. Pour les autres, vous pouvez passer par Go avec go install github.com/sinclairtarget/git-who@latest ou compiler depuis les sources si vous aimez les défis. Docker est aussi supporté pour ceux qui préfèrent…

Ce qui rend git-who vraiment intéressant, c’est ses trois modes d’analyse. Le mode table (par défaut) vous donne un tableau récapitulatif des contributions par auteur, triable par nombre de commits, lignes de code, fichiers touchés ou date de modification. C’est pratique pour identifier rapidement qui sont les principaux contributeurs d’un projet. Le mode tree affiche l’arborescence du projet avec le contributeur principal annoté pour chaque fichier et dossier. Et le mode hist génère une timeline de l’activité des commits avec le top contributeur par période.

Pour vous donner une idée concrète, Sinclair Target a fait une démo sur le projet Vim pour analyser les patterns de maintenance après le décès de Bram Moolenaar. L’outil a permis d’identifier rapidement qui avait pris le relais sur différentes parties du code. C’est quelque chose qu’il aurait été impossible à voir clairement avec un git blame classique.

La différence fondamentale donc avec git blame, c’est que git-who “comprend” le contexte. Si quelqu’un déplace un fichier ou fait un reformatage massif, git blame lui attribuera toutes les lignes alors git-who, lui, va chercher plus loin dans l’historique pour identifier les véritables auteurs du code. Il respecte même les fichiers .mailmap pour consolider les identités multiples d’un même développeur et prend en compte le fichier .git-blame-ignore-revs pour ignorer certains commits de maintenance.

Pour utiliser git-who, il suffit de faire un git who à la racine de votre projet afin d’obtenir l’analyse de base. Vous pouvez filtrer par chemin avec git who Parser/ pour analyser seulement un dossier spécifique. Le tri est customisable avec des options comme -l pour trier par lignes de code ou -m pour la date de dernière modification. Et pour une vue historique entre deux versions, git who hist v3.10.9..v3.11.9 fait le job.

Bien sûr, git-who n’est pas le seul dans sa catégorie. GitLens pour VS Code reste l’extension la plus populaire, offrant une intégration visuelle directement dans l’éditeur. Git Quick Stats est aussi une autre alternative en ligne de commande qui propose des statistiques détaillées sur les repositories. Mais aucun ne va aussi loin que git-who dans l’analyse de la véritable propriété du code.

Qui maintient réellement cette partie critique du code ? Quelle équipe a le plus contribué à ce module ? Comment les contributions ont évolué au fil du temps ? Git-who vous aide à répondre à ces questions essentielles sur la gestion de votre projet, les audits de code ou simplement pour comprendre l’histoire d’un projet open source.

Bref, j’ai trouvé ça cool… Et qui sait, peut-être qu’un jour git-who sera intégré directement dans Git ?

C’est toujours marrant de voir des outils ultra populaires mettre des années à intégrer une fonctionnalité que tout le monde bricole depuis une éternité. Et aujourd’hui, c’est au tour de NGINX qui vient enfin de franchir le pas avec l’intégration native du protocole ACME !

Pour ceux qui ne seraient pas familiers avec cet acronyme, ACME (Automated Certificate Management Environment) c’est le protocole magique qui permet d’automatiser toute la gestion des certificats SSL/TLS. Développé à l’origine par l’Internet Security Research Group pour Let’s Encrypt, c’est donc lui qui vous évite de devoir renouveler manuellement vos certificats tous les 90 jours comme un moine copiste du Moyen Âge.

Le truc vraiment cool, c’est que NGINX a décidé de faire les choses en grand car plutôt que de bricoler une solution rapide, ils ont carrément développé un nouveau module baptisé ngx_http_acme_module qui s’appuie sur leur SDK Rust. Hé oui y’a du Rust dans NGINX ! Cette approche leur permet ainsi d’avoir un module dynamique disponible aussi bien pour la version open source que pour leur solution commerciale NGINX Plus.

Du coup, fini les scripts à la con avec Certbot qui tournent en cron et qui plantent au pire moment. Maintenant, vous configurez tout directement dans votre fichier NGINX comme ceci :

acme_issuer letsencrypt {
 uri https://acme-v02.api.letsencrypt.org/directory;
 state_path /var/cache/nginx/acme-letsencrypt;
 accept_terms_of_service;
}

server {
 listen 443 ssl;
 server_name .example.com;
 acme_certificate letsencrypt;
 ssl_certificate $acme_certificate;
 ssl_certificate_key $acme_certificate_key;
}

Simple, efficace, intégré, plus besoin de jongler entre différents outils, car tout se passe dans la configuration NGINX. Ensuite, les certificats se renouvellent automatiquement, s’installent tout seuls, et vous pouvez enfin dormir tranquille.

Mais attention, selon les discussions sur LWN.net, tout n’est pas rose au pays des bisounours… La communauté a quelques réserves, et pas des moindres. Leur plus gros point de friction c’est que NGINX a décidé de lancer cette première version avec uniquement le support du challenge HTTP-01. Pour les non-initiés, ça veut dire que votre serveur doit être accessible publiquement sur le port 80 pour prouver qu’il contrôle bien le domaine.

Les développeurs frustrés pointent aussi du doigt l’absence du challenge DNS-01. Et je trouve qu’ils ont raison d’être énervés car sans DNS-01, impossible de générer des certificats wildcard (*.example.com), et impossible de sécuriser des services internes qui ne sont pas exposés sur Internet. Donc pour tous ceux qui ont des homelabs ou des infrastructures privées, c’est relou.

Surtout que Caddy, le concurrent direct de NGINX, gère ça depuis des années sans problème. Bref, l’équipe NGINX promet que les challenges TLS-ALPN et DNS-01 arriveront dans le futur, mais pour l’instant, c’est motus et bouche cousue sur les délais.

Pour ceux qui veulent tester, sachez que le code est disponible sur GitHub et des packages précompilés sont déjà disponibles. La documentation officielle explique également bien le processus d’installation et de configuration. Notez que le module utilise une zone de mémoire partagée pour coordonner les renouvellements entre les différents workers NGINX, ce qui est plutôt malin pour éviter les conflits.

Au niveau technique, le workflow est assez classique… vous configurez votre serveur ACME (Let’s Encrypt ou autre), vous allouez la mémoire partagée nécessaire, vous configurez les challenges, et le module s’occupe du reste. Les variables $acme_certificate et $acme_certificate_key sont automatiquement remplies avec les chemins vers vos certificats.

Tout ceci permet de réduire également la surface d’attaque car vous n’avez plus besoin d’avoir Certbot et toutes ses dépendances Python qui traînent sur votre serveur ou plus de scripts externes qui doivent recharger NGINX. Tout est natif, et donc c’est forcément plus sécurisé.

Perso, je trouve que c’est un pas dans la bonne direction, même si l’implémentation actuelle est limitée. Et le faut qu’ils aient codé ça en Rust montre bien que NGINX prend au sérieux la modernisation de sa base de code. Du coup, pour ceux qui ont des besoins simples avec des domaines publics, foncez tester cette nouveauté. Plus d’excuses pour avoir des certificats expirés !