Lors du développement d’une application pour Kubernetes, le développeur est souvent lié à une boucle de feedback assez longue:

1. Développement
2. Contruction de l’image Docker (quelques secondes/minutes)
3. Push de l’image sur un registry
4. Déploiement sur Kubernetes (quelques minutes)

Cette boucle est généralement implémentée par des pipelines de CI/CD. Ces pipelines augmentent encore le temps entre le développement et une application démarrée sur Kubernetes. Ce temps est relativement long lorsqu’on compare un cycle de développement local auquel un développeur peut être habitué.

Le problème

Je suis le genre de développeur qui travaille toujours avec un terminal ouvert sur le côté, en plus de mon IDE. Je lance souvent des commandes mvn pour m’assurer que mon projet compile et que mes tests s’exécutent correctement. C’est un vieux réflexe qui date de l’époque où les IDE n’avaient qu’un support limité de Maven. Lancer ces commandes hors-IDE m’aide souvent à valider que tout fonctionnera bien dans un environnement de CI par exemple. J’ai donc parfois besoin de changer de version de Java en fonction du projet dans lequel je me trouve. Maven utilise la variable d’environnement JAVA_HOME pour localiser l’installation de Java à utiliser. Donc être capable de charger des variables d’environnement différentes en fonction d’un projet peut s’avérer pratique. Un autre usage courant consiste à venir charger des clé d’API ou des secrets d’accès cloud comme des variables AWS_ACCESS_KEY ou autres en fonction de mes différents projets.

Adresse IP/URL du KeyLight

La KeyLight se connecte à votre réseau WiFi. La première étape consiste à récupérer son adresse IP.

La keylight répond aux requêtes mDNS (multicast dns).

C’est d’ailleurs indiqué dans leur documentation:

• What Communication Protocol Is Used by Elgato Wi-Fi Products?
• mDNS Service Strings for Elgato Devices

Pour obtenir l’IP du keylight, il suffit donc d’emettre une requête DNS:

dig -p 5353 PTR _elg._tcp.local @224.0.0.251

; <<>> DiG 9.16.15-Ubuntu <<>> -p 5353 PTR _elg._tcp.local @224.0.0.251
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18533
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;_elg._tcp.local.		IN	PTR

;; ANSWER SECTION:
_elg._tcp.local.	10	IN	PTR	Elgato\032Key\032Light\032Air\032F3DF._elg._tcp.local.

;; ADDITIONAL SECTION:
Elgato\032Key\032Light\032Air\032F3DF._elg._tcp.local. 10 IN SRV 0 0 9123 elgato-key-light-air-f3df.local.
Elgato\032Key\032Light\032Air\032F3DF._elg._tcp.local. 10 IN TXT "mf=Elgato" "dt=200" "id=3C:6A:9D:16:12:45" "md=Elgato Key Light Air 20LAB9901" "pv=1.0"
elgato-key-light-air-f3df.local. 10 IN	A	192.168.1.11
elgato-key-light-air-f3df.local. 10 IN	AAAA	fe80::3e6a:9dff:fe16:1245

;; Query time: 120 msec
;; SERVER: 192.168.1.11#5353(224.0.0.251)
;; WHEN: Fri Apr 15 13:55:25 CEST 2022
;; MSG SIZE  rcvd: 254

On obtient l’URL d’accès au Keylight Elgato\032Key\032Light\032Air\032F3DF._elg._tcp.local., son IP 192.168.1.11 ainsi que son port d’écoute 9123

Je suis tombé sur un cas où un fichier a été ajouté dans git (commité), puis modifié par plusieurs commits successifs.

Malheureusement, ce fichier contient des credentials.

On va donc devoir supprimer ce fichier de tout l’historique git (oui ça implique une réécriture de la sainte branche main 😇).

Trouver dans quel commit le fichier a été ajouté

Le fichier que je recherche s’appelle config.json.

Je vais faire un git log, pour trouver le commit qui a ajouté ce fichier.

J’ai beaucoup joué ces jours-ci avec xdotool, pour essayer d’automatiser certaines choses pour mon Elgato Streamdeck.

Voici les choses que j’essaie de faire :

• Sélectionner une fenêtre, et envoyer une séquence clavier (comme CTRL+B pour couper ou rétablir le son d’un appel Teams)
• Taper des emojis dans la fenêtre active 😅
• Déplacer une fenêtre ou la redimensionner

Voici quelques liens que j’ai trouvés à propos de xdotool :

• Xdotool - Window Stack
• Xdotool - Examples

Vous trouverez ci-dessous les commandes que j’ai trouvées utiles au cours de mes recherches.

Comme je prépare et exécute beaucoup de scripts, j’ai parfois besoin d’exécuter un script à une heure précise de la journée.

Lorsqu’un script ne doit être exécuté qu’une seule fois, cron n’est pas une solution viable. J’ai donc découvert le planificateur at.

Vous devez d’abord l’installer, en utilisant apt comme d’habitude pour les utilisateurs de debian, ubuntu ou autre dérivés :

$ sudo apt install at

Planifier l’exécution d’une commande

1. utilisez la commande at avec une heure / date
2. saisissez les commandes à exécuter dans l’invite
3. tapez CTRL+D pour quitter (^D)

$ at 9AM       
warning: commands will be executed using /bin/sh
at> cd workspaces/github/dotfiles
at> git pull
at> < EOT >
job 1 at Sat Apr 16 09:00:00 2022

Cet exemple va récupérer le contenu d’un dépôt à 9h demain matin !

Cet article explique comment configurer un fichier .gitignore global, pour exclure des fichiers ou des répertoires pour tous vos dépôts git.

Utiliser un fichier global permet d’ignorer des fichiers dans l’ensemble des répertoires Git de votre poste. C’est très utile pour certains fichiers, comme les fichiers .env. Cela empêche surtout les commits accidentels. J’ignore aussi les répertoires communs pour les développements liés à Java et NodeJS (target/ et node_modules), ainsi que les fichiers IntelliJ IDEA (*.iml et .idea/).