On a déjà tous passé 10 minutes à chercher dans notre historique bash LA commande SSH avec tous les bons paramètres pour nous connecter à ce foutu serveur obscur qu’on a configuré il y a 3 mois… Port custom, clé spécifique, nom d’utilisateur bizarre… Un vrai cauchemar. Et du coup, je me suis souvenu d’un outil dont on m’avait parlé y’a pas longtemps : GGH .

Écrit en Go par Binyamin Yawitz, ce petit outil CLI garde en mémoire toutes vos sessions SSH et vous permet de les retrouver instantanément. Plus besoin de fouiller dans votre historique comme un archéologue ou de maintenir un fichier notes.txt avec toutes vos connexions.

Le principe est con comme la lune… à chaque fois que vous utilisez GGH pour vous connecter, il enregistre tout (hôte, utilisateur, port, clé). Après, vous tapez juste ggh et vous avez une liste interactive de toutes vos sessions précédentes. Vous pouvez même filtrer en tapant quelques lettres, comme ggh - stage pour retrouver tous vos serveurs de staging.

Pour l’installer, c’est rapide. Sur Unix/Linux/Mac, une petite ligne de curl :

curl https://raw.githubusercontent.com/byawitz/ggh/master/install/unix.sh | sh

Sur Windows avec PowerShell :

powershell -c "irm https://raw.githubusercontent.com/byawitz/ggh/master/install/windows.ps1 | iex"

Ou si vous avez Go installé :

go install github.com/byawitz/ggh@latest

Une fois installé, utilisez-le exactement comme SSH. Par exemple :

ggh [email protected]
ggh [email protected] -p2222

La magie opère quand vous tapez simplement ggh sans paramètres. Vous obtenez une liste interactive de toutes vos connexions précédentes, triées par fréquence d’utilisation. Flèche haut/bas pour naviguer, Entrée pour se connecter. Simple et efficace.

Ce qui est malin, c’est que GGH lit aussi votre fichier ~/.ssh/config. Du coup, si vous tapez ggh -, vous avez accès à tous vos hôtes configurés. Et vous pouvez filtrer directement, genre ggh - prod pour voir uniquement vos serveurs de production.

Notez que GGH ne remplace pas SSH. C’est juste un wrapper intelligent qui facilite la vie. SSH doit encore être installé sur votre système pour que GGH fonctionne. L’outil se contente juste de mémoriser vos connexions et de relancer les bonnes commandes SSH.

Le projet est open source sous licence Apache 2.0, le code est propre, écrit à 80% en Go, et l’outil reste super léger. Pas de dépendances folles, pas de configuration complexe. Ça fait le job, point.

Quelques commandes utiles à connaître :

• ggh --config pour voir où sont stockées vos configs
• ggh --history pour accéder directement à l’historique
• ggh tout seul pour la liste interactive

Voilà, si comme moi vous en avez marre de chercher vos commandes SSH dans votre historique ou de maintenir des alias à n’en plus finir, donnez une chance à GGH , vous m’en direz des nouvelles.

Vous savez ce qui est frustrant quand, comme moi, on fait plein de trucs avec Claude Code ? C’est de devoir rester scotché à son ordi pour suivre l’avancement d’une build ou d’une tâche un peu longue. Heureusement des ingénieurs de San Francisco ont ressenti exactement la même frustration, et au lieu de râler dans leur coin comme des cons, ils ont créé Happy .

L’idée leur est venue dans au café où ils passaient leur temps à vérifier constamment l’avancement de leurs projets sur Claude Code. Comme ils l’expliquent sur leur site , ils checkaient leurs laptops toutes les 5 minutes pendant les pauses déjeuner et ça commençait à les relouter. Du coup, ils ont développé une solution mobile qui permet de garder un œil sur Claude Code depuis n’importe où, avec des notifications push et tout le tralala.

Happy fonctionne de la manière suivante. Sur votre machine, vous remplacez simplement la commande claude par happy dans votre terminal et l’application se charge ensuite de créer un pont chiffré de bout en bout entre votre ordinateur et votre téléphone. Comme ça, quand vous voulez contrôler Claude depuis votre mobile, le système bascule automatiquement en mode distant. Simple et efficace.

L’installation de Happy est simple. Vous téléchargez l’app iOS ou Android, puis vous installez le CLI sur votre ordi avec

npm install -g happy-coder

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/happy-mobile-claude-code/happy-mobile-claude-code-1.mp4">lien vers la vidéo</a>.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/happy-mobile-claude-code/happy-mobile-claude-code-1.webm">lien vers la vidéo</a>.

Vous recevez un fichier Word et votre premier réflexe, en bon libriste, c’est de lancer LibreOffice qui met 30 minutes à démarrer, juste pour lire trois paragraphes. Ou pire, vous êtes en SSH sur un serveur et là, c’est le drame total, impossible de lire un doc Word là bas. Hé bien ce bon Ben Greenwell en a eu marre de cette galère et a créé doxx , un outil écrit en Rust qui affiche vos .docx directement dans le terminal.

Ce concept m’a rappelé Glow , vous savez, ce magnifique renderer Markdown pour terminal créé par l’équipe de Charm, sauf qu’ici, on s’attaque à un format bien plus casse-pieds : les fichiers Word.

Doxx gère donc non seulement le texte formaté, mais aussi les tableaux avec de jolies bordures Unicode, les listes, et même les images si votre terminal le supporte (Kitty, iTerm2, WezTerm). Et comme c’est écrit en Rust, il parse le XML des fichiers .docx en un clin d’œil.

Pour utiliser l’outil, rien de plus simple :

doxx rapport.docx

Et boom, votre document s’affiche. Vous cherchez quelque chose ?

doxx contrat.docx --search "paiement"

Et il vous surligne toutes les occurrences. Il peut aussi exporter vers d’autres formats comme le Markdown, le CSV pour les tableaux, le JSON pour les devs, ou du plain text pour les puristes.

Pour l’installer, si vous êtes sur macOS avec Homebrew, c’est

brew install doxx

Et pour les rustacés :

cargo install doxx

Les utilisateurs d’Arch ont leur paquet AUR, et il y a même une option Nix et Conda. Bref, peu importe votre setup, vous devriez pouvoir l’installer.

Alors comment ce truc fonctionne pour afficher le format de Microsoft dans le terminal. Et bien c’est simple vous allez voir. En fait, les fichiers .docx sont des archives ZIP contenant du XML. Donc techniquement, vous pourriez les dézipper et parser le XML vous-même avec sed ou awk. Mais qui a envie de faire ça ?

C’est pourquoi doxx utilise la bibliothèque docx-rs pour le parsing, ratatui pour l’interface terminal interactive, et viuer pour l’affichage des images. Bref, c’est solide. Il y a même déjà un port en Go créé par keskinonur qui maintient la parité des fonctionnalités.

Alors oui, Doxx ce n’est pas un éditeur mais juste un viewer mais je trouve quand même que c’est bien pratique ! Donc si vous en avez marre de lancer des applications lourdes juste pour consulter un fichier Word, cet outil mérite clairement le détour.

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 !