Outil on FtBx.fr

just : un Makefile moderne que j'ai quitté pour make

Sun, 08 Jun 2025 00:00:00 +0000

J’ai découvert just en parcourant des projets Rust lorsque j’ai commencé à apprendre le langage.

just c’est un Makefile sans la syntaxe particulière de Make. Les recettes sont plus lisibles, le langage est pensé pour lancer des commandes (pas pour compiler du C). Et la syntaxe des dépendances est plus intuitive :

# justfile
deploy: build push
 kubectl apply -f deploy/

build:
 docker build -t monapp .

push:
 docker push monapp:latest

Moi qui ai tendance à utiliser pas mal Make pour ce genre de raccourcis (et jamais pour builder du C), ça m’a convaincu pendant 3 mois. Puis j’ai travaillé sur des machines où just n’était pas installé. Et là, Make est toujours installé. Prêt à opérer. Aucun obstacle.

k9s : l'UX qui fait aimer Kubernetes, au prix de l'amnésie kubectl

Mon, 28 Apr 2025 00:00:00 +0000

k9s est un excellent TUI Kubernetes. Quand je l’ai découvert, j’ai eu l’impression de passer du terminal IBM 3270 à un OS graphique. Tu navigues dans les pods avec ↑↓, tu filtres avec /, tu lances des commandes avec :. Plus besoin de taper kubectl get pods -n machin -o wide | grep bidule.

Mais il y a un prix : tu oublies kubectl. Vite. Très vite.

Ce que k9s fait mieux que kubectl

Navigation : :pods → liste des pods → Enter sur un pod → logs. 3 touches au lieu de kubectl get pods -n X && kubectl logs -n X pod/Y.
Filtrage : /error filtre en temps réel. Ctrl+A pour désactiver. C’est grep intégré, réactif à chaque frappe.
Actions : d pour décrire, s pour shell, l pour logs, y pour YAML. Tout le monde a les mêmes raccourcis — pas besoin d’apprendre les flags.
Nodes : :nodes → tu vois l’état des nœuds, les pods par nœud, les ressources utilisées. En une vue. kubectl describe node × 10 nœuds, c’est 10 commandes. k9s = une vue.

Le revers

Après 3 mois de k9s intensif, j’ai réalisé que j’étais incapable d’écrire un kubectl get pods --sort-by=.status.startTime sans Google. k9s m’a rendu plus rapide au quotidien mais plus dépendant d’un outil qui n’est pas installé partout.

uv a remplacé pip dans mon workflow Python

Mon, 10 Mar 2025 00:00:00 +0000

J’ai découvert uv en février 2025. En mars, pip n’existait plus chez moi.

Avant, gérer les dépendances Python c’était pip + pip-tools + virtualenv + un fichier texte pour se souvenir de la commande d’activation. Trop de pièces mobiles pour un truc qui devrait être simple. (Quant à poetry, j’ai jamais passé le pas)

uv pip install est 10 à 100× plus rapide que pip. uv venv crée un virtualenv en moins d’une seconde. Et uv pip compile remplace pip-tools sans avoir à installer quoi que ce soit. Tout est dans un seul binaire.

age vs GPG : pourquoi j'ai arrêté de m'arracher les cheveux

Mon, 17 Feb 2025 00:00:00 +0000

Pendant des années, chiffrer un fichier c’était : générer une clé GPG, la stocker sur une clé physique, gérer l’expiration, prier pour que le keyring ne soit pas corrompu, et relire la doc GPG pour la trente-septième fois.

age a remplacé tout ça. Une clé publique, une clé privée, zéro concept de keyring. La clé privée tient sur une ligne. La clé publique aussi. C’est tellement simple qu’on peut les stocker dans son gestionnaire de mots de passe.

zellij : pourquoi je n'ai jamais eu besoin de tmux

Sun, 19 Jan 2025 00:00:00 +0000

Je n’ai jamais utilisé tmux. Pas par principe, juste parce que quand j’ai commencé à chercher un multiplexer, zellij est tombé au bon moment.

C’est contre-intuitif : tmux est plus réputé, plus ancien, installé partout. Mais zellij a une qualité rare : il est utilisable sans config. Pas de .tmux.conf à écrire. Pas de préfixes bizarres à mémoriser. Une barre d’état qui montre les onglets et les processus en cours, sans plugin. Des raccourcis qu’on découvre en appuyant sur Ctrl+G.

direnv + .envrc : j'arrête de source des variables à la main

Sun, 22 Sep 2024 00:00:00 +0000

J’en avais assez de taper source .env en entrant dans chaque projet. Et surtout d’oublier de le faire une fois sur trois, et de perdre 10 minutes à comprendre pourquoi la variable d’environnement n’était pas chargée.

direnv règle ça en un hook shell. Tu entres dans un dossier, il exécute .envrc. Tu en sors, il décharge tout. Plus rien à faire.

Mais ce qui change tout, c’est quand on le combine avec un password manager en CLI (pour ma part rbw) pour injecter les secrets automatiquement :

fzf + rg + fd : la trinité qui rend mon terminal plus rapide que l'explorateur

Sat, 03 Aug 2024 00:00:00 +0000

Trois outils. Chacun remplace un binaire POSIX vieux de 40 ans. Ensemble, ils transforment le terminal en interface plus rapide que n’importe quel explorateur graphique.

Alors oui, c’est dans les vieux pots qu’on fait les meilleures soupe et si un binaire qui a 40 ans est toujours utilisé, c’est qu’il y a une bonne raison, mais là, ce serait dommage de se privée d’une UX shell bien léchée.

fd remplace find. Même usage, syntaxe humaine :

zoxide : j'ai remplacé cd et ma mémoire musculaire a survécu

Sun, 14 Jul 2024 00:00:00 +0000

zoxide remplace cd par un saut intelligent. Tu tapes z projet et il t’emmène dans le dossier projet, même s’il est à 4 niveaux de profondeur. Il apprend tes habitudes : plus tu vas souvent dans un dossier, plus il le priorise.

La commande s’appelle z. Pas zoxide, pas zoxide cd. Juste z. Un alias alias cd="z" et ni vu ni connu !

Setup

# Installer
sudo apt install zoxide # ou cargo install zoxide

# Ajouter à .zshrc / .bashrc
eval "$(zoxide init zsh --cmd z)"
# (Le --cmd z renomme la commande en 'z' au lieu de 'zoxide')

Cheatsheet zoxide

Commande	Équivalent cd	Effet
`z projet`	`cd ~/dev/machin/truc/projet`	Va au dossier le plus utilisé contenant “projet”
`z proj bidule`	-	Combine “proj” et “bidule” pour trouver
`zi`	-	Interface interactive avec fzf
`z -`	`cd -`	Retour au dossier précédent
`z ..`	`cd ..`	Remonte d’un niveau

Le zi avec fzf est le plus utile : tu tapes zi, tu scrolles dans ton historique, tu choisis. Plus rapide que cd $(find . -type d | fzf).

glab CLI : gérer GitLab sans jamais ouvrir le navigateur

Fri, 14 Jun 2024 00:00:00 +0000

Quand tu gères 120 dépôts et que chaque action commence par “ouvrir GitLab → Projects → chercher le projet → cliquer → …”, tu perds un temps fou. glab remplace l’interface web pour toutes les opérations courantes.

# Installer
brew install glab # macOS
sudo apt install glab # Linux (ou télécharger le binaire)

# Authentification (une fois)
glab auth login

Ce que j’utilise souvent

# Créer une MR depuis la branche courante
glab mr create --title "Fix: pipeline timeout" --assignee @me

# Lister mes MRs ouvertes
glab mr list --assignee @me

# Voir le statut d'une pipeline
glab ci status --branch main

# Relancer un job spécifique
glab ci retry --job build

# Lister les issues
glab issue list --label "bug" --assignee @me

# Créer un snippet (partage de code rapide)
glab snippet create fichier.py --title "Debug: race condition"

Le combo qui tue avec git

# Créer une branche, commit, push, MR en une passe
git checkout -b fix/timeout
git commit -am "fix: increase pipeline timeout"
git push -u origin HEAD
glab mr create --fill # --fill utilise le message du commit comme titre

Cheatsheet glab

Commande	Équivalent UI GitLab
`glab mr list -a @me`	Merge Requests → Assignees → Moi
`glab mr view 42`	Ouvrir la MR #42
`glab mr merge 42`	Bouton “Merge”
`glab ci status`	CI/CD → Pipelines
`glab ci trace`	Logs du job en cours
`glab release create 1.0`	Deploy → Releases → New release
`glab api projects/:id`	API GitLab sans curl ni token

glab api est la killer feature : tu appelles l’API GitLab directement avec ton token géré par glab. Plus besoin de curl -H "...".

gitlab-ci-local : tester ses pipelines sans pousser

Fri, 08 Mar 2024 00:00:00 +0000

Pousser un commit juste pour tester un changement de .gitlab-ci.yml, c’est 30 secondes par tentative. Sur une pipeline un peu tordue, 20 essais. 10 minutes perdues à corriger des erreurs de syntaxe.

gitlab-ci-local exécute tes pipelines en local, avec Docker. Tu modifies ton .gitlab-ci.yml, tu lances gitlab-ci-local, tu vois les erreurs immédiatement. Zéro push, zéro attente de runner.

# Installer
npm install -g gitlab-ci-local

# Lancer tous les jobs du .gitlab-ci.yml courant
gitlab-ci-local

# Lancer un job spécifique
gitlab-ci-local --job build

# Lister les jobs disponibles
gitlab-ci-local --list

Ce que ça supporte

image, services, before_script, script, after_script
artifacts, cache (local, pas partagé)
variables, extends, !reference, needs
parallel:matrix (partiellement)

Ce que ça NE supporte PAS

trigger (pipelines enfants)
environment (pas de déploiement réel)
rules:if avec des variables GitLab prédéfinies ($CI_COMMIT_BRANCH)
Runner tags, Kubernetes executor

Le piège

gitlab-ci-local utilise Docker pour exécuter les jobs. Si ton job fait référence à $CI_REGISTRY_IMAGE ou $CI_JOB_TOKEN, ces variables n’existent pas en local. Il faut les définir manuellement :