Outil

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 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. ...

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. ...

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. ...

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. ...

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 : ...

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 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). ...

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 "...". ...

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 : ...