DEV Community: Sébastien Roccaserra

Blog inactif + nouvelle adresse

Sébastien Roccaserra — Mon, 10 Jul 2023 10:10:59 +0000

Bonjour, si vous visitez ce blog, pour information il n'est plus actif et mon activité principale est sur :

https://sroccaserra.github.io/

Hello, if you come across this blog, please understand that it is not active anymore, and you might want to visit my new blog instead:

https://sroccaserra.github.io/

Numérique et accords de Paris

Sébastien Roccaserra — Thu, 18 May 2023 13:50:25 +0000

J'ai été intéressé par cet article du Monde dans lequel on trouve que pour respecter les accords de Paris, il faudrait réduire les émissions de gaz à effet de serre du secteur du numérique de 7 % par an jusqu'en 2050. On y lit aussi que le rythme actuel est une augmentation des émissions du secteur de 6 % par an. On ne va pas dans la bonne direction.

La recherche au défi de la sobriété énergétique du numérique ~ (réservé aux abonné·es)

+ 6 %, - 7 %, on ne se rend pas compte mais les deux sont énormes car les courbes sont exponentielles (principe des intérêts cumulés). Pour visualiser un peu les ordres de grandeur, j'ai fait rapidement ces deux courbes qui montrent :

le résultat de la croissance actuelle si elle est maintenue jusqu'en 2050 = multiplier nos émissions actuelles par presque 5
le résultat de la baisse nécessaire si on commençait aujourd’hui (ce qui est loin d’être le cas) = diviser nos émissions actuelles par plus de 5

Note : l’axe vertical part bien de zéro, on doit réellement arriver bien bas si on veut respecter les accords de Paris.

On lit aussi dans l'article que les émissions de gaz à effet de serre ne sont pas le seul impact négatif du secteur du numérique dans la catastrophe écologique actuelle.

Conclusion

Ça me paraît évident que :

Prendre des décisions stratégique en se fiant au rythme de croissance actuel du secteur du numérique n'est pas réaliste.
Les sociétés doivent prendre conscience du problème et agir ASAP dans la bonne direction et avec les bons ordres de grandeur.

Savoir construire ses outils

Sébastien Roccaserra — Sun, 14 May 2023 10:18:57 +0000

Parfois, face à une situation nouvelle que je ne comprends pas, j’ai besoin de voir le problème sous un autre angle. Dans ces conditions, je suis content d’utiliser tous les outils que j’ai déjà. Et parfois, quand mes outils habituels ne sont pas adaptés, savoir fabriquer très vite un nouvel outil spécifique à la situation est très utile.

Voici le dernier exemple en date, où j’ai eu besoin de visualiser des événements sur un axe temporel pour les corréler et chercher des patterns.

Dans ma mission actuelle, nous avons eu besoin d’établir une connexion VPN entre un serveur applicatif et un serveur SMTP pour envoyer des emails. Et nous avons détecté que cette connexion était défectueuse régulièrement, car environ un email sur dix ne partait pas : le serveur applicatif n’arrivait pas à joindre le serveur SMTP.

Autre point important : sur ce projet on n’a pas encore pris le temps ni le budget de s’outiller sur l’analyse de logs, avec des outils du marché comme Datadog par exemple. Ces outils fonctionnent très bien et je les recommande, mais nous ne les avons pas encore sous la main, d’où cette démarche un peu plus rustique.

Voilà la démarche que j’ai suivie pour rendre visible les patterns de perte de connexion :

activer les logs de ping VPN
extraire des logs de ping les événements qui m’intéressent
dessiner un graph avec tous ces événements

Exploration des logs

Une connexion VPN, pour se maintenir, envoie à interval régulier des pings entre client et serveur. J’ai activé les logs de ces pings du point de vue de mon serveur applicatif. J’ai donc dans mes logs des pings envoyés et des pings reçus.

Ces logs sont très verbeux, ils contiennent beaucoup d’information. En plissant les yeux, on peut voir dans ces lignes des lignes ‘RECEIVED PING PACKET’ et ‘SENT PING’. On peut voire aussi des lignes ‘Inactivity timeout’ et ‘ping-restart’ : ce sont les lignes qui montrent le problème, le redémarrage fréquent de la connexion VPN qui causait les pertes d’emails.

2023-05-12 17:21:28.999239998 +0200 CEST [web-1] 2023-05-12 15:21:28 us=359574 UDP WRITE [41] to [AF_INET]12.34.56.789:1194: P_DATA_V2 kid=0 DATA len=40
2023-05-12 17:21:28.999245803 +0200 CEST [web-1] 2023-05-12 15:21:28 us=364929 UDP READ [41] from [AF_INET]12.34.56.789:1194: P_DATA_V2 kid=0 DATA len=40
2023-05-12 17:21:28.999246770 +0200 CEST [web-1] 2023-05-12 15:21:28 us=364965 TLS: tls_pre_decrypt, key_id=0, IP=[AF_INET]12.34.56.789:1194
2023-05-12 17:21:28.999247475 +0200 CEST [web-1] 2023-05-12 15:21:28 us=364984 PID_TEST [0] [SSL-0] [] 0:0 0:1 t=1683904888[0] r=[0,64,15,0,1] sl=[0,0,64,528]
2023-05-12 17:21:28.999248049 +0200 CEST [web-1] 2023-05-12 15:21:28 us=364993 RECEIVED PING PACKET
2023-05-12 17:21:39.000111417 +0200 CEST [web-1] 2023-05-12 15:21:38 us=479455 TLS: tls_pre_encrypt: key_id=0
2023-05-12 17:21:39.000143400 +0200 CEST [web-1] 2023-05-12 15:21:38 us=479527 SENT PING
2023-05-12 17:21:39.000152558 +0200 CEST [web-1] 2023-05-12 15:21:38 us=479567 UDP WRITE [41] to [AF_INET]12.34.56.789:1194: P_DATA_V2 kid=0 DATA len=40
2023-05-12 17:21:49.001203807 +0200 CEST [web-1] 2023-05-12 15:21:48 us=710285 TLS: tls_pre_encrypt: key_id=0
2023-05-12 17:21:49.001231283 +0200 CEST [web-1] 2023-05-12 15:21:48 us=710359 SENT PING
2023-05-12 17:21:49.001235143 +0200 CEST [web-1] 2023-05-12 15:21:48 us=710413 UDP WRITE [41] to [AF_INET]12.34.56.789:1194: P_DATA_V2 kid=0 DATA len=40
2023-05-12 17:21:59.002236188 +0200 CEST [web-1] 2023-05-12 15:21:58 us=745173 TLS: tls_pre_encrypt: key_id=0
2023-05-12 17:21:59.002246836 +0200 CEST [web-1] 2023-05-12 15:21:58 us=745261 SENT PING
2023-05-12 17:21:59.002287152 +0200 CEST [web-1] 2023-05-12 15:21:58 us=745302 UDP WRITE [41] to [AF_INET]12.34.56.789:1194: P_DATA_V2 kid=0 DATA len=40
2023-05-12 17:22:09.003668616 +0200 CEST [web-1] 2023-05-12 15:22:08 us=957512 TLS: tls_pre_encrypt: key_id=0
2023-05-12 17:22:09.003689111 +0200 CEST [web-1] 2023-05-12 15:22:08 us=957579 SENT PING
2023-05-12 17:22:09.003693708 +0200 CEST [web-1] 2023-05-12 15:22:08 us=957618 UDP WRITE [41] to [AF_INET]12.34.56.789:1194: P_DATA_V2 kid=0 DATA len=40
2023-05-12 17:22:20.004539495 +0200 CEST [web-1] 2023-05-12 15:22:19 us=79677 TLS: tls_pre_encrypt: key_id=0
2023-05-12 17:22:20.004544393 +0200 CEST [web-1] 2023-05-12 15:22:19 us=79749 SENT PING
2023-05-12 17:22:20.004545188 +0200 CEST [web-1] 2023-05-12 15:22:19 us=79805 UDP WRITE [41] to [AF_INET]12.34.56.789:1194: P_DATA_V2 kid=0 DATA len=40
2023-05-12 17:22:29.005460487 +0200 CEST [web-1] 2023-05-12 15:22:28 us=327448 [OpenVPN-Server-mon-serveur-vpn.com] Inactivity timeout (--ping-restart), restarting
2023-05-12 17:22:29.005472487 +0200 CEST [web-1] 2023-05-12 15:22:28 us=327506 PID packet_id_free
2023-05-12 17:22:29.005495216 +0200 CEST [web-1] 2023-05-12 15:22:28 us=327605 PID packet_id_free
2023-05-12 17:22:29.005500324 +0200 CEST [web-1] 2023-05-12 15:22:28 us=327617 PID packet_id_free
2023-05-12 17:22:29.005501491 +0200 CEST [web-1] 2023-05-12 15:22:28 us=327624 PID packet_id_free
2023-05-12 17:22:29.005552612 +0200 CEST [web-1] 2023-05-12 15:22:28 us=327640 PID packet_id_free
2023-05-12 17:22:29.005555228 +0200 CEST [web-1] 2023-05-12 15:22:28 us=327647 PID packet_id_free
2023-05-12 17:22:29.005555749 +0200 CEST [web-1] 2023-05-12 15:22:28 us=327654 PID packet_id_free
2023-05-12 17:22:29.005556455 +0200 CEST [web-1] 2023-05-12 15:22:28 us=327661 PID packet_id_free
2023-05-12 17:22:29.005568587 +0200 CEST [web-1] 2023-05-12 15:22:28 us=327672 TCP/UDP: Closing socket
2023-05-12 17:22:29.005569472 +0200 CEST [web-1] 2023-05-12 15:22:28 us=327690 PID packet_id_free
2023-05-12 17:22:29.005574817 +0200 CEST [web-1] 2023-05-12 15:22:28 us=327709 SIGUSR1[soft,ping-restart] received, process restarting
2023-05-12 17:22:29.005575207 +0200 CEST [web-1] 2023-05-12 15:22:28 us=327727 Restart pause, 5 second(s)

On peut déjà en tirer des informations mais ce n’est pas très pratique : dans l’exemple il y a une ou deux minutes de logs, et pour mon problème j’ai besoin d’analyser un bon quart d’heure pour chercher des patterns.

Transformation des logs

J’ai commencé par extraire les événements qui m’intéressent avec rg (un genre de grep) et à les structurer pour isoler le timestamp.

Isoler les envois de pings :

$ rg 'SENT PING' logs
99694:2023-05-12 17:20:53.995533501 +0200 CEST [web-1] 2023-05-12 15:20:53 us=775530 SENT PING
99697:2023-05-12 17:21:03.996518529 +0200 CEST [web-1] 2023-05-12 15:21:03 us=991544 SENT PING
99739:2023-05-12 17:21:18.998396048 +0200 CEST [web-1] 2023-05-12 15:21:18 us=82178 SENT PING
99833:2023-05-12 17:21:28.999163512 +0200 CEST [web-1] 2023-05-12 15:21:28 us=359535 SENT PING
99840:2023-05-12 17:21:39.000143400 +0200 CEST [web-1] 2023-05-12 15:21:38 us=479527 SENT PING
99843:2023-05-12 17:21:49.001231283 +0200 CEST [web-1] 2023-05-12 15:21:48 us=710359 SENT PING
99846:2023-05-12 17:21:59.002246836 +0200 CEST [web-1] 2023-05-12 15:21:58 us=745261 SENT PING
99849:2023-05-12 17:22:09.003689111 +0200 CEST [web-1] 2023-05-12 15:22:08 us=957579 SENT PING
99852:2023-05-12 17:22:20.004544393 +0200 CEST [web-1] 2023-05-12 15:22:19 us=79749 SENT PING
99894:2023-05-12 17:22:34.006820819 +0200 CEST [web-1] 2023-05-12 15:22:33 us=328337 SENT PING
99992:2023-05-12 17:22:44.007459739 +0200 CEST [web-1] 2023-05-12 15:22:43 us=490301 SENT PING
99995:2023-05-12 17:22:54.008443004 +0200 CEST [web-1] 2023-05-12 15:22:53 us=684270 SENT PING

Extraire le timestamp avec cut (on délimite sur les espaces et on prend les deux premiers champs) :

$ rg 'SENT PING' logs | cut -d' ' -f1-2
2023-05-12 17:20:53.995533501
2023-05-12 17:21:03.996518529
2023-05-12 17:21:18.998396048
2023-05-12 17:21:28.999163512
2023-05-12 17:21:39.000143400
2023-05-12 17:21:49.001231283
2023-05-12 17:21:59.002246836
2023-05-12 17:22:09.003689111
2023-05-12 17:22:20.004544393
2023-05-12 17:22:34.006820819
2023-05-12 17:22:44.007459739
2023-05-12 17:22:54.008443004

Ajouter le marqueur ‘ >’ (pour signifier “envoyé”) en fin de ligne, et envoyer le résultat dans un fichier “sent” (ici avec tee pour visualiser le résultat en même temps) :

$ rg 'SENT PING' logs | cut -d' ' -f1-2 | rg '$' -r ' >' | tee sent
2023-05-12 17:20:53.995533501 >
2023-05-12 17:21:03.996518529 >
2023-05-12 17:21:18.998396048 >
2023-05-12 17:21:28.999163512 >
2023-05-12 17:21:39.000143400 >
2023-05-12 17:21:49.001231283 >
2023-05-12 17:21:59.002246836 >
2023-05-12 17:22:09.003689111 >
2023-05-12 17:22:20.004544393 >
2023-05-12 17:22:34.006820819 >
2023-05-12 17:22:44.007459739 >
2023-05-12 17:22:54.008443004 >

Faire la même chose avec les pings reçus :

$ rg 'RECEIVED PING' logs | cut -d' ' -f1-2 | rg '$' -r ' < Received' | tee received
2023-05-12 17:20:12.991392556 < Received
2023-05-12 17:21:28.999248049 < Received
2023-05-12 17:22:44.007432531 < Received
2023-05-12 17:22:54.008453476 < Received

Et les redémarrages de session VPN :

$ rg '12 17:.*Inactivity timeout' logs | cut -d' ' -f1-2 | rg '$' -r ' * Restart !!' | tee restart
2023-05-12 17:21:13.997629899 * Restart !!
2023-05-12 17:22:29.005460487 * Restart !!

Ensuite on peut joindre les fichiers avec cat et les trier (par date puisque c’est le début de ligne) dans un fichier “history”::

$ cat received sent restarts | sort > history
$ cat history
2023-05-12 17:20:53.995533501 >
2023-05-12 17:21:03.996518529 >
2023-05-12 17:21:13.997629899 * Restart !!
2023-05-12 17:21:18.998396048 >
2023-05-12 17:21:28.999163512 >
2023-05-12 17:21:28.999248049 < Received
2023-05-12 17:21:39.000143400 >
2023-05-12 17:21:49.001231283 >
2023-05-12 17:21:59.002246836 >
2023-05-12 17:22:09.003689111 >
2023-05-12 17:22:20.004544393 >
2023-05-12 17:22:29.005460487 * Restart !!
2023-05-12 17:22:34.006820819 >
2023-05-12 17:22:44.007432531 < Received
2023-05-12 17:22:44.007459739 >
2023-05-12 17:22:54.008443004 >
2023-05-12 17:22:54.008453476 < Received

C’est déjà plus lisible, on peut maintenant commencer à corréler et voir des patterns. En plissant les yeux, on peut voir que les pings envoyés sont beaucoup plus fréquents que les pings reçus.

On peut voir aussi que le redémarrage de 17h22 survient une minute et une seconde après le dernier ping reçu : ça correspond à notre configuration VPN : envoyez-vous des pings toutes les 10 secondes, et redémarrez si vous n’avez pas de nouvelles après 1 mn. Mais j’avais envie de voir ces infos sur un graph pendant une longue période pour mieux confirmer mes intuitions.

Affichage dans un graph

Ça tombe bien, ça fait longtemps que j’avais envie d’explorer l’aspect visuel de Smalltalk, un petit langage qui contient tout ce qu’il faut pour générer des images et les afficher out of the box (petit, en effet : 30 Mo le zip avec la VM, la lib standard, toutes les sources, et un IDE puissant intégré !).

J’ai donc exploré un peu et j’ai trouvé une classe RSChart qui pouvait afficher des RSLinePlot et des RSScatterPlot. Dans les commentaires de la classe il y a même tout ce qu’il faut pour démarrer.

En explorant quelques minutes de plus, j’ai trouvé comment ajouter des marqueurs, et en peu de temps j’avais ce résultat à partir de mes logs, exactement ce dont j’avais besoin :

On peut voir qu’il y a effectivement un pattern super régulier : mon client VPN reçoit des pings du serveur pendant quelques dizaines de secondes, ne reçoit pas les pings du serveur pendant une minute et redémarre. Et ainsi de suite.

En réfléchissant un peu, j’ai pu faire l’hypothèse qu’il y avait une autre machine qui utilisait la même configuration. Quand le serveur voyait cette autre machine arriver, il lui se mettait à lui envoyer les pings et mon serveur ne les recevait plus. Ma connexion redémarre, le serveur m’envoie les pings, (donc l’autre machine ne les reçoit plus et redémarre), et ainsi de suite, à toi, à moi, etc.

Et bingo, j’avais bien utilisé la même conf VPN sur deux de mes serveurs qui se volaient la vedette à chacun leur tour 🤦. Problème enfin résolu ! 🎉

Conclusion

Pour résumer, bien connaître GNU core-utils et un langage de programmation un peu visuel permet de se fabriquer ses propres outils spécifiques rapidement et à peu de frais, à tel point que je ne “capitalise” pas sur ces outils, je n’en fait surtout pas une librairie. Je conserve quelques snippets pour me rappeler rapidement les détails, et je me reconstruis un outil vite fait à chaque fois, en jetant parfois un œil à un de mes vieux snippets.

Annexe

Version awk

On peut aussi faire toute la phase d’exploration de logs en une seule ligne de awk :

$ awk <logs '/SENT PING/ { print $1 $2 " >" } ; /RECEIVED PING/ { print $1 $2 " < Received"} ; /Inactivity/ { print $1 $2 " * Restart !!" }'
2023-05-1217:20:43.994461854 >
2023-05-1217:20:53.995533501 >
2023-05-1217:21:03.996518529 >
2023-05-1217:21:13.997629899 * Restart !!
2023-05-1217:21:18.998396048 >
2023-05-1217:21:28.999163512 >
2023-05-1217:21:28.999248049 < Received
2023-05-1217:21:39.000143400 >
2023-05-1217:21:49.001231283 >
2023-05-1217:21:59.002246836 >
2023-05-1217:22:09.003689111 >
2023-05-1217:22:20.004544393 >
2023-05-1217:22:29.005460487 * Restart !!
2023-05-1217:22:34.006820819 >
2023-05-1217:22:44.007432531 < Received
2023-05-1217:22:44.007459739 >
2023-05-1217:22:54.008443004 >
2023-05-1217:22:54.008453476 < Received

Code du graph en Pharo Smalltalk

Si vous connaissez Ruby, une bonne partie de Smalltalk va vous paraître familière : les collections, les blocks de code, et le paradigme "tout est message".

Exemple de graph qui affiche une sinusoïde :

x := -3.14 to: 3.14 by: 0.1.
y := x sin.

c := RSChart new.
c addPlot: (RSLinePlot new x: x y: y).
c addDecoration: (RSChartTitleDecoration new title: 'hello'; fontSize: 20).
c addDecoration: (RSXLabelDecoration new title: 'My X Axis'; fontSize: 12).
c addDecoration: (RSYLabelDecoration new title: 'My Y Axis'; fontSize: 15).
c show

Voilà tout le code écrit à l’arrache pour le graph des redémarrages. Ça tient en une vingtaine de lignes :

file := FileSystem disk workingDirectory
        / 'Developer/project/history'.
lines := file contents lines allButFirst: 8.

c := RSChart new.

y := 1.
xS := (lines select: [ :each | each endsWith: ' >' ]) collect: [ :line |
        (DateAndTime fromString: (line first: 23)) asUnixTime ].
c addPlot:
    (RSScatterPlot new x: xS y: (OrderedCollection new: xS size withAll: y)).

y := 1.5.
xRc := (lines select: [ :each | each endsWith: 'Received' ]) collect: [ :line |
        (DateAndTime fromString: (line first: 23)) asUnixTime ].
c addPlot:
    (RSScatterPlot new x: xRc y: (OrderedCollection new: xRc size withAll: y)).

((lines select: [ :each | each endsWith: 'Restart !!' ]) collect: [ :line |
     (DateAndTime fromString: (line first: 23)) asUnixTime ]) do: [ :value |
    c addDecoration: (RSXMarkerDecoration new value: value) ].

c addDecoration: (RSHorizontalTick new labelConversion: [ :value |
      (DateAndTime fromUnixTime: value) asTime ]).
c addDecoration: (RSXLabelDecoration new
      title: 'Heure';
      fontSize: 12).

c padding: 0 @ 80.
c show

Le site de Pharo Smalltalk, qui permet de faire tourner ce code out of the box : https://pharo.org/

Dysfonctionnement du jour : la "recette tardive"

Sébastien Roccaserra — Thu, 11 May 2023 06:07:28 +0000

Disclaimer: well, that’s just, like, my opinion, man.

Pourquoi on s’est mis à utiliser des méthodes agiles autour de l’an 2000 ? Parce-que des dysfonctionnements systémiques étaient la norme, quasiment systématiquement, et un peu les mêmes partout. C’est pour répondre à ces dysfonctionnements qui étaient devenus des normes qu’on a changé de façon de penser et de travailler. (By the way, autre opinion gratuite en passant, c’est que “on” = “un faible pourcentage d’équipes”, même aujourd’hui, mais c’est un autre sujet.)

C’est utile je trouve de connaître ces dysfonctionnements de systèmes, afin de les reconnaître et de les éviter. En effet, j’ai pu observer plusieurs fois que “appliquer” une “méthode” (agile ou pas) comme on suivrait une recette n’est pas la chose qui apporte des résultats, ce qui apporte des résultats c’est l’intention qu’on y met. Donc appliquer une méthode sans chercher à éviter les dysfonctionnement qu’elle est censé éviter c’est passer à côté du problème (cf les équipes qui deviennent “agiles” en calquant les mots “qui vont bien” —sprint, PO, user story, roadmap, etc. — sur un process dysfonctionnel sans trop changer ledit process ou sans s’attaquer aux dysfonctionnements).

Du coup, je réfléchis à mettre par écrit des exemples de dysfonctionnements pour m’aider à expliquer au client / à la cliente pourquoi je lui demande de travailler d’une certaine façon, et pourquoi c’est important pour lui ou pour elle et pour les personnes qui vont utiliser le produit qu’on est en train de développer ensemble.

Le dysfonctionnement du jour : la “recette tardive”. En quoi c’est un problème ?

Ce que j’appelle “la recette tardive”, c’est quand dans un process de développement logiciel :

il y a une étape “finale” qui “valide” qu’une tâche / un ticket / une story / un PBI (Scrumspeak pour Product Backlog Item) est “terminé”
au lieu de recetter ces items au fil de l’eau (on dev → on recette le plus vite possible → terminé, etc.), on choisit de (ou donne notre accord pour) le faire plus tard, souvent parce-que “on n’a pas le temps maintenant”
ces recettes non faites s’accumulent pendant plusieurs jours / semaines
voilà, on a une “recette tardive”.

Autre mécanisme de recette tardive observé :

“on a bien X et Y mais il manque encore Z, je ferai la recette quand il y aura tout pour être bien sûr”
parfois, le “quand il y aura tout” = quand “l’application sera terminée”. On attend une livraison “finale”, livrée “clé en main” et on fera la “vraie recette” là dessus.

Alors, je me demandais pourquoi c’est un problème ? Quand on retarde la recette à plus tard voire au dernier moment au lieu de recetter au fur et à mesure, alors on met en risque le produit. J’ai mis ici quelques réflexions par écrit pour tenter de rendre visible cette mise en risque du produit. J’essaie de montrer un peu les enchaînements de conséquences que j’ai observées, pas forcément dans l’ordre, mais au ralentit.

Quand on retarde la recette, alors :

on détecte tard des défauts qui datent de longtemps
on perd l’empathie utilisateur : quand ce qu’on fait ne va pas en prod rapidement, on perd le contact avec les personnes qui ont besoin du produit
on accumule le travail en cours
plein de travail en cours ⇒ plus personne ne sait réellement ce qui reste à faire
le pire c’est qu’on s’habitue à vivre avec un reste à faire flou, des tickets qui s’éternisent avant de passer en Done, et des utilisateurs tellement loins de nous dans le temps qu’ils ne sont même plus dans nos pensés ⇒ plus rien n’est important ⇒ ça ou autre chose, bof : en perdant l’objectif on perd la motivation
en rendant flou le reste à faire, on perd complètement prise sur notre capacité à réaliser X en un temps Y
comme on ne va pas se tourner les pouces en attendant la recette, on se dépêche de commencer plein d’autres sujets (~ unpopular opinion : et pourtant dans cette situation se tourner les pouces serait en réalité “moins pire” pour le résultat final)
en commençant beaucoup de choses sans les terminer, on a l’impression d’aller vite car on est occupé à 100 %
mais en réalité on ne fait que créer une illusion sur notre capacité à faire en nous maintenant dans un sentiment d’urgence sur la mauvaise chose, urgence de commencer pour montrer qu’on est sur le pont, au lieu de l’urgence de terminer ces sujets qui sont devenus “old news” et moins valorisés
on s’endort jusqu’au réveil, la fin de l’illusion : quand une date importante arrive, on se rend compte qu’on a vécu au dessus de nos moyens
on détecte les défauts au dernier moment, juste avant l’ouverture de service ⇒ ça met le produit en risque et les équipes en stress au plus mauvais moment. Gros crunch en mode cowboy (allez les requêtes SQL en prod, on y va 🤠) avec aucune garantie de résultat.
en étant occupé à 100 % en permanence, on perd totalement notre capacité à gérer l’imprévu (note : la survenue de l’imprévu est paradoxalement la chose la plus certaine sur un projet)
en étant occupé à 100 % en permanence, on rate complètement toutes les opportunités d’améliorer quoi que ce soit qui se présentent tous les jours
en n’ayant pas le temps pour les améliorations, on ralentit notre vitesse de x % par mois — Attention ! Mefiat ! Beware ! Cave Canem ! Même un ralentissement de 1 % par mois c’est énorme car les intérêts cumulés c’est exponentiel 😨
l’autre fin d’illusion sur notre capacité à faire, c’est quand l’ajout de nouvelles fonctionnalités devient si pénible qu’on accepte le big rewrite (quelle horreur). Mais si on ne change pas les conditions qui ont conduit à cette situation, on ne changera pas le résultat. Without changing the quality of the “building”, you can’t really change the quality of the thing built.

Bref, je n’aime pas les recettes tardives.

Découverte du langage Go, court retour d'expérience

Sébastien Roccaserra — Sat, 16 Jul 2022 12:30:11 +0000

Cette semaine j'ai fait un peu de Go et j'aime bien, voilà ce que j'ai observé en résolvant quelques problèmes d'Advent of Code.

TL;DR

C'est top d'avoir un langage curly brackets qui soit typé statiquement et qu'on peut lancer en ligne de commande aussi facilement que du JavaScript, c'est pas si fréquent que ça, et c'est ce que je recherchais en ce moment, c'est une belle découverte pour moi.

Plus de détails

Un langage typé statiquement

Go est un langage typé statiquement, ce qui fait qu'on a beaucoup de feedback en temps réel sur son code, impossible d'oublier un paramètre dans un appel de fonction ou de passer un paramètre du mauvais type par exemple. Ça va plus loin, car s'il y a une variable déclarée mais non inutilisée, le programme ne compile pas. J'apprécie, ça aide à la rigueur.

func solve_01_1(numbers []int) int {
    previous := huge
    result := 0
    for _, n := range numbers {
        if n > previous {
            result += 1
        }
        previous = n
    }
    return result
}

Ci-dessus on peut observer la signature de la fonction, func solve_01_1(numbers []int) int, qui prend en entrée une liste d'entiers ([]int) et qui renvoit un entier (int). Du classique.

On peut observer aussi le mécanisme d'inférence de type à la déclaration des variables bien pratique. Les variables previous et result sont déclarées sans type mais sont bien typées statiquement et vérifiées par le type checker. On n'arrive pas au niveau de Haskell qui peut inférer quasi tous les types d'un programme mais c'est déjà bien.

Exemple de Generics

Le système de generics a l'air bien, j'ai pu m'en servir assez intuitivement.

///
// Declaration

func GetParsedLines[T any](parse func(string) T) []T {
    //...
}

///
// Uses

func GetInputLines() []string {
    return GetParsedLines(Id[string])
}

func GetInputInts() []int {
    return GetParsedLines(ParseInt)
}

Ci dessus on peut observer une utilisation des generics, avec la définition d'une fonction GetParsedLines() paramétrable, et son utilisation avec deux types différents dans GetInputLines() et GetInputInts().

GetParsedLines() prend en argument une fonction parse(). Cette fonction parse() doit prendre en argument une string et doit renvoyer une valeur de type T, qui peut être n'importe quel type. La fonction GetParsedLines déclare qu'elle renvoit une liste de T, qui doit être le même type renvoyé par parse().

J'ai trouvé ça facile à découvrir, j'ai quasiment écrit cette fonction à l'instinct en m'aidant des erreurs du compilateur.

On peut imposer des contraintes sur les types paramétriques, comme comparable ou Ordered, mais je n'en ai pas trouvé beaucoup, et je ne sais pas dans quelle mesure c'est extensible.

Go en ligne de commande

C'est un langage typé statiquement qu'on peut lancer très facilement en ligne de commande 🎉, une super feature pour moi :) go run monscript.go et hop. Ça compense le manque de REPL (il n'y a pas de REPL officiel 😔).

Un langage raisonnablement petit

Le langage est petit, on peut lire une grosse partie de la doc sans se faire trop mal, j'apprécie beaucoup les petits langages (Scheme, Lua, Smalltalk ❤️). La contrepartie c'est qu'il peut manquer certaines choses dont on a l'habitude.

Pas de try / catch, on récupère les erreurs en sortie de fonctions un peu comme en C
Les collections sont limitées (pas de set ni de tuple par exemple, un peu comme en Lua - mais : on a quand même droit à une heap et une liste doublement chaînée en plus des maps et tableaux dynamiques)
Pas de map / reduce / filter génériques out of the box. Il y a bien quelques personnes qui tentent de fournir des genres de libs équivalentes à LoDash mais si j'ai bien compris les devs Go préfèrent tout faire à coup de boucles for (voir le premier exemple ci-dessus), et pourquoi pas, on assume la simplicité des briques de base et un côté impératif.
Pas d’héritage (mais du polymorphisme avec les interfaces)

Encore une fois, l’avantage de ces omissions c’est que le langage reste petit, et avec un peu de créativité on s’en sort. Tant que j'ai des tableaux dynamiques, des hashmap et des fonctions du premier ordre je peux travailler en général.

Autres Features

Le système d'interface est super souple, on dirait du duck typing en langage statique. Je n'ai pas vraiment pu me faire une opinion là dessus, ça a l'air pas mal pour développer de manière opportuniste tout en gardant les avantages du type checker.

Le système d'erreur est bien pensé, ça compense un peu le manque d'exception.

Je n'ai pas utilisé les killer features de concurrence (les goroutines), ça a l'air bien 🤷

Le système de packages / modules m'a un peu mis des bâtons dans les roues, ça s'est mieux passé quand j'ai compris qu'il y avait un seul package par répertoire, et que les fichiers du package se partagent le même namespace pour la compilation. Si j'ai bien compris ça fait qu'on a un namespace par répertoire, que se partagent tous les fichiers du répertoire. Je ne suis pas fan de çe point, j'aime bien quand le scope de chaque fichier est isolé mais je peux vivre avec.

Docs et outils

Les docs sont bien, mais je suis le genre de personne qui trouve beaucoup de docs bien, je vous laisse vous faire votre opinion. C'est facile de trouver les docs de référence et plein d'article pour préciser des points du langage sur le blog Go (il y a un blog Go).

La lib standard est pas mal, pas aussi fournie que celle de Python mais on y trouve quand même de quoi décoder des png par exemple.

Le langage est livré avec pas mal d'outils, dont un formateur de code, et il y a même un language server officiel (gopls) ! Top, je peux faire des renames à tire larigot dans Vim 🎉 Globalement ça présage d'un langage bien outillé pour travailler. Dommage : le formateur go fmt impose des tabs, dans mon éditeur ça passe quand je les affiche comme 4 espaces, mais github les affiche comme huit espaces, je trouve ça moche 🤷 Heureusement il y a un réglage perso pour la largeur des tabs dans github.

C'est facile d'installer et de gérer des dépendances avec go get, beaucoup plus simple qu'en Java par exemple pour comparer avec un autre langage curly brackets typé statiquement.

Conclusion

Dans mon usage j'ai trouvé que ça ressemble à un Lua typé statiquement ou un meilleur TypeScript (des types non optionels, plus exigent, pas de point virgules, on peut le lancer facilement en ligne de commande sans installer et configurer des libs de transpilation, ça juste marche). Je comprends mieux l'intérêt du coup, en plus c'est moins compliqué que Rust et un peu dans le même esprit (ça compile en WebAssembly par exemple).

J'en ressors avec l'impression qu'avec un peu plus d'expérience je pourrais très bien faire un projet côté serveur en Go, en plus de m'en servir comme un langage de script typé statiquement, je suis très content d'y avoir passé un peu de temps 👍🏼

Références

Pour aller plus loin, plein de docs :

Documentation ~ https://go.dev/doc/
A Tour of Go ~ https://go.dev/tour/list
Using Go Modules ~ https://go.dev/blog/using-go-modules
How to Write Go Code ~ https://go.dev/doc/code
The Go Programming Language Specification ~ https://go.dev/ref/spec
Go Modules Reference ~ https://go.dev/ref/mod
Standard Library ~ https://pkg.go.dev/std
Frequently Asked Questions (FAQ) ~ https://go.dev/doc/faq
Error Handling and Go ~ https://go.dev/blog/error-handling-and-go

Outils :

gopls ~ https://pkg.go.dev/golang.org/x/tools/gopls

Random

C’est quoi les langages curly brackets ? C'est les langages avec beaucoup de { et de } dans leur syntaxe, pour délimiter les scopes de fonctions, boucles for, if et autres switch, les classes ou les structures...
Exemples de langages avec beaucoup de curly brackets : C, C++, Java, C#, JavaScript, TypeScript, Go, Rust.
Exemples de langages avec peu de curly brackets : Python, Ruby, Lisp, Lua, Smalltalk, Haskell, Elixir.

Je cherchais un langage typé statiquement que je pourrais lancer facilement en ligne de commande et pour lequel installer des dépendances serait simple. Un genre de croisement des avantages combinés de Java et de JavaScript. C'est un peu ce que j'ai trouvé en Go, je trouve ça chouette.

J'aime pas forcément les curly brackets, je suis content d'en avoir trouvé un qui a ces avantages combinés. Il redore un peu le blason de la famille curly brackets.
J'apprécie beaucoup Java pour sa robustesse et ses réfactos autos dans IntelliJ, sans doute C# me plairait aussi, mais pour lancer un script Java en ligne de commande, ou installer une lib en faisant du XML dans un .pom, je trouve ça un peu triste.
J'apprécie JavaScript pour se lancer superfacilement en ligne de commande, et tout installer avec npm install, et aussi pour sa souplesse, mais dans une grosse base de code quand je vois une variable "user" au fin fond d'un appel de fonctions et que je suis incapable de dire quels champs il a et il n'a pas, je trouve ça un peu triste.
Go a l'air de réconcilier un peu tout ça, sans doute qu'il apporte aussi son lot de problèmes.

Dans la famille non curly brackets, j'avais déjà trouvé mon bonheur, avec Python et Ruby qui font quand même un poil plus de vérifications que JavaScript (par exemple le nombre d'arguments) et qui arrivent avec une lib standard bien fournie, et Haskell qui fonctionne très bien en ligne de commande. en plus de son système de types costaud.

Comprendre un modèle métier est plus facile dans un langage à typage fort

Sébastien Roccaserra — Sat, 14 Nov 2020 19:44:42 +0000

Pour moi, comprendre un modèle métier précisément est plus difficile dans des langages typés dynamiquement (comme JavaScript, Python, Ruby) que dans des langages à typages forts (comme Java, C#, Haskell).

Pour illustrer les difficultés que je peux avoir, voici un exemple qui utilise une modélisation un peu riche, tirée du livre Domain Modeling Made Functional (chapitre 4 : Understanding Types).

Dans un langage typé dynamiquement

Dans un langage typé dynamiquement, quand on observe une fonction, il est souvent très difficile de savoir ce que peuvent et ne peuvent pas contenir ses arguments. Par exemple quand on voit une fonction comme :

function isAuthorized(payment) {
  // ...
}

Ou même :

function isAuthorized({amount, currency, method}) {
  // ...
}

Comment savoir avec rigueur ce que contiendront exactement les arguments de cette fonction quand elle sera appelée au runtime ? Est-ce que parfois le paramètre method sera une simple string, un objet structuré, avec la bonne structure, autre ? Qu'est-ce qu'on va récupérer comme devise ?

On peut se contenter de lire l'implémentation actuelle : ce qui est utilisé dans l'implémentation est un sous ensemble probablement suffisant si le code fonctionne. Mais quand on change ce code, sur quels autres champs peut-on s'appuyer ? Seront-ils présents dans tous les cas d'usage ?

Peut-être qu'il y a une classe Payment déclarée quelque-part, mais même si je la trouve, rien n'empêche le code d'ajouter ou de supprimer des champs avant l'appel de cette fonction, ou même d'utiliser un simple Object qui a à peu près la bonne forme à la place, comme dans la deuxième version ci-dessus.

En pratique on se retrouve souvent à utiliser grep sur tout le code pour explorer les appels de cette fonction, et à déboguer le code dans plusieurs cas d'usage si on veut avoir la réponse.

Dans un langage avec typage fort

Pour montrer le niveau d'information apporté par une modélisation métier avec un typage fort, voici la même fonction déclarée en Haskell :

isAuthorized :: Payment -> Bool
isAuthorized p =
  -- ...

La grosse différence est que dans ce cas je peux aller observer la déclaration du type Payment, je n'ai pas à lancer grep sur tout le code ou à poser des points d'arrêt et autres console.log un peu partout. La vérification de type me garantit que cette fonction sera toujours appelée avec une valeur de type Payment, et que cette valeur aura toujours la bonne forme.

Voici par exemple ce qu'on pourrait trouver comme déclaration riche du type Payment :

data CardNumber = CardNumber Int
data CheckNumber = CheckNumber Int

data CardType = Visa | Mastercard
data CreditCardInfo = CreditCardInfo { cardType :: CardType
                                     , cardNumber :: CardNumber
                                     }

data PaymentMethod = Cash
                   | Check CheckNumber
                   | Card CreditCardInfo

data PaymentAmount = PaymentAmount Decimal
data Currency = EUR | USD

data Payment = Payment { amount :: PaymentAmount
                       , currency :: Currency
                       , method :: PaymentMethod
                       }

On peut observer que ce type est à la fois riche et définit très précisément. On est aussi certain en un coup d’œil de ce qu'il contient exactement au runtime. On sait qu'on va avoir :

un montant qui est un nombre décimal
une devise soit en euros soit en dollars
une méthode de paiement qui est à son tour précisément définie : c'est soit du cash, soit un chèque avec un numéro, soit une carte bancaire qui à son tour définit un type et un numéro de carte.

On peut aussi voir avec certitude tous les cas qu'on devra traiter lorsqu'on utilise une valeur de ce type. Paiement cash, par chèque, par carte, paiements en euro et en dollars.

De même quand on remanie l'implémentation d'une fonction utilisant ce type, on connait précisément les éléments dont on dispose pour la nouvelle implémentation.

Il est rare d'avoir autant de connaissances et ce niveau de certitude dans un langage typé dynamiquement.

Conclusion

Les difficultés des langages à typage dynamique illustrées ici n'apparaissent pas toujours. Sur des projets de petite taille, avec deux ou trois personnes bien alignées qui réinjectent régulièrement leurs compréhension du métier dans le code (ce qui est une discipline très difficile à avoir), grâce par exemple à TDD et au refactoring systématique, on peut trouver du code facile à suivre.

Et c'est vrai que malgré mes difficultés, j'apprécie beaucoup des langages comme Ruby, Smalltalk, Lisp, Python, et même Lua, Awk et JavaScript (qui décrochent le pompon en terme de permissivité ?). C'est dans ces langages que j'ai travaillé quasiment exclusivement depuis 2015.

Cependant, pour mes prochains projets je souhaite retrouver un typage fort afin de travailler avec plus de confort la modélisation du métier dans le code. Et en bonus, afin d'avoir le plus d'expressivité possible, je souhaite pouvoir profiter :

des types sommes,
du filtrage par motif,
de l'inférence de type (disponible depuis ML, soit bientôt 50 ans ?).

Je crois que c'est le cas pour Kotlin, Rust, Haskell, F# / OCaml, Elm, PureScript, Reason, ReScript ce qui laisse pas mal de choix.

Ce qui est certain, c'est que si je participe au démarrage d'un projet en JavaScript ou Node.js, je vais militer pour partir sur TypeScript dès le départ.

Photo by Crystal Kwok on Unsplash.

Quelques références sur le couplage dans le code

Sébastien Roccaserra — Sat, 31 Oct 2020 23:27:44 +0000

Récemment j'ai fait un petit tour des tables des matières d'ouvrages classiques pour trouver des références sur le couplage dans le code. Voici ce que j'ai récolté, sans ordre de préférence.

The Pragmatic Programmer

Tout d'abord, The Pragmatic Programmer est une super référence sur le sujet.

Notamment dans la 2e édition, le topic 28, Decoupling, pp. 130-137.

Pour vous donner envie de le lire (et ça me donne super envie de le relire !!), ça parle de :

Structural Rigidity,
Tip 44 : Decoupled code is easier to change,
Train wrecks,
Tip 45 : Tell, don’t ask,
The law of Demeter,
Tip 46 : Don’t chain method calls
The evils of globalization
Tip 47 : Avoid global data
Tip 48 : If it’s important enough to be global, wrap it in an API
Inheritance adds coupling
Again, it’s all about change

Refactoring

Dans Refactoring, il y a les code smells opposés “Divergent Change” et “Shotgun Surgery” (p. 76 de la 2ème édition), et "Message Chain" (p. 81) avec les refactorings associés.

Code Complete

Dans Code Complete :

Loose coupling: Loose coupling means designing so that you hold connections among different parts of a program to a minimum. Use the principles of good abstractions in class interfaces, encapsulation, and information hiding to design classes with as few interconnections as possible. Minimal connectedness minimizes work during integration, testing, and maintenance.

Et le chapitre Design Building Blocks: Heuristics, dont l’heuristique Keep Coupling Loose, p. 100, qui parle de :

Coupling Criteria (size, visibility, flexibility)
Kinds of Coupling (simple data parameter coupling, simple object coupling, object parameter coupling, semantic coupling)

Et aussi l’heuristique “Aim for strong cohesion”, p. 105.

Clean Architecture

Clean Architecture a un chapitre Component Cohesion, un chapitre Component Coupling et un chapitre Independance, qui parle de Decoupling Layers, Decoupling Use Cases et Decoupling Mode.

Working Effectively with Legacy Code

Dans Working Effectively with Legacy Code il y a le chapitre 25, Dependency-Breaking Techniques, qui donne des techniques pour découpler des classes suffisamment pour pouvoir les tester.

Articles

Il y a aussi l’article sur le pattern Big Ball of Mud que j’aime bien :

http://www.laputan.org/mud/

Cette conférence récente d’Arnaud Lemaire :

https://www.lilobase.me/votre-application-a-besoin-de-son-jardin-secret-attention-a-la-localite-de-linformation/

Et coïncidence, ce tweet d'aujourd'hui de Kent Beck :

Coupling vs cohesion.

Coupling:
• Can be hard to find
• Can be really hard &/| expensive to eliminate.

Cohesive sub-elements are:
• Usually easy to find
• Cheap to achieve, &
• Help you find de-coupling.

Conclusion

C’était chouette de faire ce petit tour de tables des matières dans ces ouvrages, maintenant il me faut du temps pour les lire ou relire, et mettre en pratique 😯 Bonne lecture, bonne pratique de vos apprentissages !

Crédit photo : https://pixabay.com/fr/photos/nerfs-cellules-sépia-dendrites-3115722/

Découverte de OCaml

Sébastien Roccaserra — Fri, 30 Oct 2020 21:47:40 +0000

Cette semaine j'avais envie d'explorer un nouveau langage. Je souhaitais avoir un typage fort et des fonctions currifiées par défaut : j'ai essayé OCaml, et j'ai été agréablement surpris.

Kata Bowling en OCaml

Pour découvrir le langage, je me suis lancé sur une implémentation du kata bowling :

type roll = Roll of int

type frame = Frame of int
let next (Frame n) = Frame (n + 1)

let rec score ?(f=Frame 1) = function
  | [] -> 0
  | [Roll x; Roll y; Roll z] when is_last_frame f ->
      x + y + z
  | r1 :: (Roll y as r2) :: (Roll z as r3) :: rest when is_strike r1 ->
      10 + y + z + score ~f:(next f) (r2 :: r3 :: rest)
  | r1 :: r2 :: (Roll z as r3) :: rest when is_spare r1 r2 ->
      10 + z + score ~f:(next f) (r3 :: rest)
  | Roll x :: Roll y :: rest ->
      x + y + score ~f:(next f) rest
  | [_] -> failwith "wrong number of rolls"
and is_strike = (=) @@ Roll 10
and is_spare (Roll x) (Roll y) = 10 == x + y
and is_last_frame = (=) @@ Frame 10

Le répo github est ici, la liste des commits montre le cheminement :

https://github.com/sroccaserra/bowling-game-kata-ocaml

Ce que j'ai apprécié

Quand on connait un peu Haskell, on se sent vite à la maison
La documentation en français
Il y a des guidelines et des cheatsheets pour démarrer
Le paradigme fonctionnel et le pattern matching
En OCaml, il n'y a que des expressions
Ne pas avoir à répéter le nom de la fonction pour chaque pattern
Le pattern matching implicite avec function
Les paramètres nommés et avec valeurs par défaut (voir ci-dessus, ?(f=Frame 1))
Je n'ai pas essayé, mais je suis curieux de l'aspect orienté objet
L'inférence de type et le typage fort, c'est chouette d'être aidé par un compilateur
Avoir une erreur de compilation par défaut pour les patterns non exhaustifs et les variables non utilisées
Le système de build (dune), je n'ai pas eu de mal à le prendre en main (pour ce tout petit projet)
C'est facile de lancer les tests en mode watch (dune runtest -w)
Installer des libs avec opam, ça fonctionne
C'est facile de visualiser les erreurs de compilation à la volée dans Vim
Les sources de gros projets sont dispos pour s'inspirer (JaneStreet et Mirage par exemple)
OCaml a des variantes plus ou moins populaires, comme F# (une base de OCaml sous .NET), et Reason / ReScript.

Ce que j'ai moins apprécié

~~On ne peut pas suivre la step down rule (définir la fonction appelante au dessus de la fonction appelée) si j'ai bien compris~~ <-- en fait si, avec and, voir la fonction is_strike ci-dessus
Devoir répéter le pattern pour chaque guarde when
Des symbols un peu plus présents qu'en Haskell (:: pour :, @@ pour $, les ~ devant les paramètres nommés)
Le ;; pour finir une instruction dans le repl

Kata Bowling en Haskell

Pour explorer les ressemblances, j'ai fait le même kata en Haskell :

module Bowling (score, Roll(..)) where

data Roll = Roll Int
  deriving (Eq)

data Frame = Frame Int
  deriving (Eq)
next (Frame n) = Frame (n + 1)

score = score' $ Frame 1
score' f xs = case xs of
  [] -> 0
  r1@(Roll x):r2@(Roll y):r3@(Roll z):rest
    | isLastFrame f ->
      x + y + z
    | isStrike r1 ->
      10 + y + z + score' (next f) (r2:r3:rest)
    | isSpare r1 r2 ->
      10 + z + score' (next f) (r3:rest)
  Roll x:Roll y:rest ->
    x + y + score' (next f) rest
  [_] -> error "Wrong number of rolls"
  where
    isStrike = (==) $ Roll 10
    isSpare (Roll x) (Roll y) = 10 == x + y
    isLastFrame = (==) $ Frame 10

Le répo github est ici, la liste des commits montre le cheminement :

https://github.com/sroccaserra/bowling-game-kata-haskell

Conclusion

Je suis content d'avoir découvert OCaml, je pense en refaire plus tard, par exemple pour explorer l'orientation objet. Ou peut-être découvrir F# pour explorer encore un autre langage de ce type ?

Note : je ne suis un expert ni en OCaml, ni en Haskell. Je suis preneur d'avis pour améliorer tout ça.

Pair / Mob programming à distance avec tmux et ssh

Sébastien Roccaserra — Mon, 12 Oct 2020 11:01:47 +0000

Quand on veut faire du pair programming à distance en n’utilisant que le terminal, on peut utiliser tmux et ssh (les invités n’ont besoin que d’un client ssh), avec un google meet pour la voix uniquement.

Fonctionnalités : dans tmux, on peut ouvrir plusieurs fenêtres (un vim et un shell par exemple) qui sont toutes partagées. Tous les participants peuvent soit observer, soit prendre la main (le clavier a un léger lag pour les personnes à distance, à voir sur la durée si c’est ok -- voir Mosh dans les références si c'est un problème).

Avantage : ce setup est très léger et facile à utiliser quand on n’a pas besoin de montrer son navigateur aux autres. Fini les écrans flous et les ordinateurs qui rament à cause du partage d'écran.

Avertissement : si vous ne connaissez pas bien ssh, tmux, votre shell et un bon éditeur en ligne de commande comme Vim ou Emacs, il vaut mieux se familiariser avec ces outils avant de proposer des sessions à distance à vos collègues.

En passant, je pense qu'apprendre ces outils est un très bon investissement. Ce sont des outils puissant, répandus et stables dont vous aurez l'usage pendant des dizaines d'années. (Voir les références en fin d'article pour des recommandations sur comment apprendre Vim et tmux.)

Note : il y a un easy mode, tmate semble très bien et plus simple : https://tmate.io/. Si vous êtes déjà à l’aise avec tmux et la configuration de ssh, le mode d’emploi ci-dessous ne devrait pas être tellement plus compliqué.

Prérequis

Les invités n’ont besoin que d’un client ssh.

Pour l’hôte de la session, avoir un ngrok ou équivalent, et un tmux opérationnel (brew install tmux ?) et apprendre un peu à l’utiliser (il y a un crash course en bas).

Ajout des clés publiques des invités

La première fois uniquement, l'hôte ajoute les clés publiques des invités dans ~/.ssh/authorized_keys, sur ce modèle :

command="/usr/local/bin/tmux attach -t shared" ssh-rsa AABBCC...123== michel

Note : la commande peut varier en fonction de votre installation de tmux et de si votre shell peut le trouver sans être un login shell.

Note : j'ai eu besoin plusieurs fois de vérifier les clés publiques des invités, voir dans la section Caveats pour un exemple.

Lancer la session

L'hôte lance ngrok (qui va indiquer un numéro de port et une url en réponse) :

$ ngrok tcp 22
...
Forwarding                    tcp://0.tcp.ngrok.io:12345 -> localhost:22
...

L'hôte lance une session tmux nommée "shared" (ça doit être le même nom que dans la commande ssh spécifiée pour les invités dans le fichier authorized_keys) :

$ tmux new -s shared

Partager la commande pour se connecter

Les invités peuvent maintenant se connecter à votre session tmux par ssh en lançant cette commande que vous pouvez leur partager. Dans la ligne ci-dessous, remplacer le nom d’utilisateur par votre nom d’utilisateur Linux, et remplacer le port et le hostname par ce que donne ngrok (ne pas mettre "tcp://" devant le hostname) :

$ ssh -p 12345 user@0.tcp.ngrok.io

Utiliser tmux pendant la session

Sur macOS, utiliser Cmd + et Cmd - (iTerm2) pour avoir une taille de fonte qui donne une taille d'écran confortable pour tout le monde. Pro tip : ce sont les invités qui adaptent leur taille de police pour correspondre à celle de l'hôte, afin d'avoir une référence commune.

tmux crash course (utiliser le préfix avant la touche, Ctrl-b par défaut) :

? pour lister les raccourcis
% pour ouvrir un pane à droite
" pour ouvrir un pane en dessous
z pour zoomer et revenir
x pour fermer un pane
[ pour passer en scroll mode (q pour quitter)
q pour numéroter les panes
M-Right agrandir de 5 vers la droite (fonctionne avec Up Down et Left)
:resize-pane -R 20 # pour étendre le pane de 20 caractère à droite (marche avec U D L R)
{ et } pour échanger les panes
c pour créer une fenêtre
& pour fermer une fenêtre
w pour lister les fenêtre
option + double click pour sélectionner par mots

Caveats

Les utilisateurs voient leur police de caractères et leurs couleurs de terminal.

Quand un observateur clique sur sa fenêtre, ça peut modifier le pane qui a le focus pour l'hôte.

Sur macOS on a observé que cat ~/.ssh/id_rsa.pub | pbcopy peut manger la fin de la clé publique, penser à la vérifier. Pour vérifier une clé publique, on peut faire dans bash :

$ ssh-keygen -l -f <(echo ssh-rsa AAAAM...F6VRP5== bob@bob.com)

dans fish :

$ ssh-keygen -l -f (echo ssh-rsa AAAAM...F6VRP5== bob@bob.com | psub)

Voir aussi

Pour apprendre Vim :
- https://vim.fandom.com/wiki/Tutorial
- Practical Vim
Pour apprendre tmux : tmux 2
https://www.hamvocke.com/blog/remote-pair-programming-with-tmux/
https://mosh.org/
https://tmate.io/