DEV Community: Jean-Noël

Comment bien signer ses programmes avec OpenSSL ?

Jean-Noël — Tue, 07 Apr 2026 11:40:54 +0000

Pourquoi signer ?

En 2025, 72% des entreprises à l'échelle mondiale ont constaté une intensification des risques de cyberattaque et 91% des experts en cybersécurité s'attendent à une augmentation des menaces augmentées à l'IA¹ 😮. Et cela, notamment à partir de contenu falsifié.

Face à cette menace, comment s'assurer que les données reçues à travers le réseau proviennent du bon expéditeur, et, surtout, contiennent des données authentiques plutôt qu'un programme malveillant ?

Une des solutions à cela, évidemment, c'est la signature des fichiers !

Aujourd'hui nous allons donc voir comment signer et vérifier la signature de ces fichiers avec OpenSSL, un outil en ligne de commande gratuit, universel (Windows, Linux, Mac OS), et largement éprouvé.

Qu'est-ce que la signature, plus précisément ?

On peut hésiter entre 4 techniques : signer, chiffrer, obfusquer ou checksum ? Même si elles sont complémentaires dans le domaine de la sécurité, elles n'ont pas les mêmes fonctions !

Chiffrement : protéger des données confidentielles à l'aide d'une clé mathématique. Sans la clé, les données sont incompréhensibles.
Obfuscation (néologisme pour "offuscation") : brouiller la lecture humaine des données et les rendre plus difficiles à comprendre. En termes de sécurité, c'est une technique très (trop) minimaliste, mais néanmoins complémentaire. Exemple : "l'uglification"🧌 du code JavaScript pour le frontend.
Checksum : vérifier l'intégrité d'un fichier avec un hash calculé à partir de la somme des octets de ce dernier.
Signature : authentifier la provenance ET vérifier l'intégrité d'un fichier.

Vous l'aurez remarqué : la signature est un procédé ayant une similarité avec les checksums, mais encore plus sécurisé, bien qu'elle soit à peine plus complexe à utiliser !

Grâce à une paire de clé privée/clé publique (algorithme asymétrique, donc) elle permet de bien séparer les rôles entre le signataire et les vérificateurs de la signature :

Clé privée : secret uniquement détenu par le signataire.
Clé publique : distribuée à toutes les personnes désirant vérifier la signature.

Le processus de signature se fait donc en deux temps :

La signature d'un fichier :
La vérification de la signature par les personnes ayant reçu le fichier signé :

Ici le RSA est choisi comme algorithme de chiffrement avec un hash SHA-256. Bien entendu, il en existe d'autres dont certains seront mentionnés ci-après.

Signer avec OpenSSL

Voyons ensemble comment signer un fichier avec OpenSSL dans un invité de commande Windows (outil que presque tout le monde doit avoir quelque part, donc 😛).

Habituellement, une version d'OpenSSL est déjà présente dans l'emplacement de votre gestionnaire de version git.

Mais si la commande where openssl ne vous renvoie rien, vous devrez l'installer manuellement : soit en installant git (solution la plus simple finalement !), soit avec MSYS2 et pacman, soit avec winget.

Une fois OpenSSL installé, commencez par créer une clé privée sécurisée par mot de passe :

openssl genrsa -aes256 -out private.pem 4096

Notez le -aes256 qui indique qu'il faut utiliser l'algorithme AES-256 pour chiffrer la clé privée avec le mot de passe qui vous sera demandé lors de l'exécution. Cet algorithme de chiffrement est encore considéré comme très sécurisé, et le restera pendant encore un bon moment.
Ainsi, même si la clé fuite par mégarde, elle restera "inutilisable".

Votre fichier private.pem généré doit globalement ressembler à ça :

Ensuite, créez la clé publique associée, avec par exemple l'algorithme de chiffrement RSA (pour plus de compatibilité) :

openssl rsa -in private.pem -pubout -out public.pem

Ce qui donne un fichier public.pem de cette forme-là :

Enfin, signez le fichier de votre choix avec la clé privée grâce aux mots clés dgst (pour digérer le fichier, miam 😋) et -sign :

openssl dgst -sha256 -sign private.pem -out sign.sha256 <file-to-sign>

Il est possible de convertir la signature binaire en base64, parfois plus simple à échanger sur le réseau :
openssl base64 -in sign.sha256 -out base64-sign.txt

Vérifier une signature

Maintenant, plaçons-nous du côté d'une personne souhaitant cette fois-ci vérifier la signature d'un fichier program-signed.cpp fraîchement reçu.

À ce stade, notez qu'il est possible de re-convertir la signature reçue en base64 vers du binaire :
openssl base64 -d -in base64-sign.txt -out sign.sha256

Tout d'abord cette personne doit se procurer la signature sign.sha256, ainsi que la clé publique public.pem, bien entendu.

Elle peut alors vérifier la signature du fichier avec les mots clés dgst et -verify :

openssl dgst -sha256 -verify public.pem -signature sign.sha256 program-signed.cpp

Verified OK

Vous pouvez toujours vous amuser à changer juste un caractère à l'intérieur de ce fichier afin de volontairement le falsifier :

openssl dgst -sha256 -verify public.pem -signature sign.sha256 FALSE-program-signed.cpp

Verification failure

La vérification d'authenticité échoue bien. Ouf, on a évité un logiciel potentiellement malveillant ! 😅

Recommandations en termes de sécurité

En ce début d'année 2026, voici quelques recommandations importantes de sécurité vis-à-vis du processus de signature et de ses paramètres :

Bien utiliser l'algorithme de hachage SHA-256 ou SHA-512 (famille des SHA-2) plutôt que les 'SHA-1' et 'MD5' qui sont maintenant considérés comme compromis.
Pour le format de la clé, choisir une longueur minimum de 4096 bits pour l'algorithme de chiffrement RSA, afin d'anticiper la prochaine obsolescence du 2048 bits.
Créer une API de signature sur un serveur avec un accès restreint à une faible quantité de personnes et avec des accès temporaires (token et multifacteurs).
La clé privée doit être chiffrée avec mot de passe, placée dans un coffre-fort numérique, et n'être accessible que par le script de signature le temps de l'opération. Jamais par l'API (voire placer le script en question directement à l'intérieur du coffre-fort !). Exemple d'implémentation de l'API de signature :

Conclusion

Voilà, maintenant vous savez tout ce qu'il faut savoir pour sécuriser vos programmes ou packages, et protéger les utilisateurs qui recevront vos fichiers 👍.

Sachez que le système de signature est très utilisé aujourd'hui dès qu'il y a un déploiement de programme inter-plateformes.
Les gestionnaires de packages du monde UNIX (apt-get ou dnf) utilisent même une vérification d'identité en complément de la signature brute que nous venons de voir.

Par ailleurs, nous avons ici utilisé l'algorithme de chiffrement RSA largement répandu, mais il faut savoir qu'il en existe d'autres comme le EdDSA ou les ECDSA qui ont la particularité de présenter un niveau de sécurité similaire pour des clés beaucoup plus petites. Cela réduit la complexité algorithmique à l'exécution. Idéal donc pour des environnements limités comme l'embarqué !

Un système de chiffrage post-quantique est même en préparation à l'heure où nous parlons : le Post-quantum Cryptography (PQC) pour prévenir les attaques des ordinateurs quantiques.
Très avant-gardiste, mais on n'est jamais trop prudents !

¹ (sources : World Economic Forum 2025)

Dioxus : des IHM Cross-Platform en Rust !

Jean-Noël — Tue, 17 Feb 2026 12:55:28 +0000

Aujourd'hui je vous propose un petit diaporama pour découvrir un framework en Rust qui permet de développer efficacement des IHM Cross-Platform, et dont la syntaxe est largement inspirée de React : Dioxus.

Bonne lecture 🙂

Alpha-bêta, l'algo qui a battu le champion du monde aux échecs

Jean-Noël — Tue, 06 Jan 2026 12:38:36 +0000

Introduction

Le 11 Mai 1997, pour la première fois dans l'histoire, un ordinateur, Deep Blue d'IBM, a battu le champion du monde d'échecs Garry Kasparov dans le cadre d'un tournoi. Cet évènement marqua un tournant décisif dans les débuts de l'intelligence artificielle et des avancées algorithmiques.

Pourtant, il existe environ 10¹²⁰ parties théoriques possibles aux échecs (à un pion près 😅), soit 10⁴⁰ de plus que le nombre d'atomes qui constitue l'Univers observable !

Comment un ordinateur avec des capacités matérielles beaucoup plus limitées que les supercalculateurs d'aujourd'hui a pu déterminer en un temps réalisable les meilleurs coups menant à une victoire quasi certaine ?

L'heure est venue de découvrir (ou redécouvrir ?) les algorithmes MinMax – aussi appelé "minimax" – et l'élagage alpha-bêta, bijoux d'aide à la prise de décision stratégique, même encore aujourd'hui !

L'algorithme de recherche MinMax

Commençons par l'épine dorsale de la théorie des jeux : évaluer tous les coups possibles et les gains théoriques associés. Plaçons-nous justement dans le contexte d'une partie d'échecs entre un joueur humain et un ordinateur.

On souhaite faire gagner l'ordinateur.

Chaque mouvement d'une pièce de l'ordinateur ou du joueur humain conduit à une nouvelle situation de jeu. On peut modéliser ces situations de jeu à travers un arbre :

Imaginons maintenant que la partie soit un peu plus avancée, et que ce soit à l'ordinateur de jouer.

Afin de trouver LE meilleur coup possible pour l'ordinateur, on commence par déterminer une profondeur de recherche maximum – ici 3 – puis on construit l'arbre des évolutions du jeu en fonction des coups joués par chaque adversaire :

(Si vous n'êtes pas familier de la notation algébrique des coups aux échecs "Cc3, Pa3, ...", vous pouvez toujours aller jeter un œil ici, mais ce n'est pas indispensable pour comprendre l'algorithme dans cet article.)

Chaque nœud est un choix de coup parmi toutes les branches descendantes directes.

On appelle nœuds Max les décisions prises par l'ordinateur à son tour de jeu. En effet, étant donné que l'on souhaite le faire gagner, nous allons lui faire jouer les meilleurs coups (donc gain Maximal).

A contrario, on dit que c'est un nœud Min lorsque c'est au joueur humain de jouer, car on considère qu'il va jouer le coup le plus défavorable dans l'intérêt de l'ordinateur, et donc Minimiser les gains de son adversaire.

Arrivés à la profondeur maximale, on calcule le gain qu'offre chaque situation de jeu atteinte.

Le gain peut-être estimé de différentes façons : gain matériel, positionnel, victoire par mat, égalité par pat, etc. Pour simplifier l'explication, nous modéliserons le gain par une simple valeur qui peut très bien représenter la valeur d'une prise. Par exemple, prendre une Tour (valeur 5) donnera un gain matériel supérieur à la prise d'un Pion (valeur 1).

Notez également que seuls quelques coups seront traités dans notre exemple. Tous les autres coups possibles seront représentés par les flèches en pointillé et ne seront pas évalués dans l'algorithme (sinon imaginez la tête du schéma 😜).

En remontant tous les gains du bas vers le haut de l'arbre avec cette logique, on peut alors conclure que le meilleur coup à jouer pour l'ordinateur dans la situation de départ sera Cc3 👍 (et donc le cavalier en c3).

Seulement voilà, comme on peut le constater, l'arbre peut rapidement devenir gigantesque, même en limitant la profondeur de recherche. Et les calculs de gains peuvent nécessiter des algorithmes lourds si on ne se limite pas à un gain matériel. Il faudrait trouver un moyen de réduire cette complexité d'exploration.

Mais d'ailleurs, en y réfléchissant bien, est-il réellement nécessaire d'explorer absolument tous les nœuds ? 🤔

L'optimisation par élagage alpha-bêta

L'idée de cette optimisation est simple : si nous sommes capables d'affirmer avec certitude qu'une branche ne changera pas la valeur d'un nœud Min parent ou d'un nœud Max parent, il est alors inutile d'aller explorer cette branche enfant et de calculer ses gains. On peut alors l'élaguer.

Eh oui ! Quel intérêt d'envisager ce que donnerait la partie en prenant un Pion, si nous venons de trouver un autre coup qui permet de prendre une Dame ? (toujours dans une logique purement matérielle)

Pour appliquer cette optimisation, on définit deux variables α et β dont les valeurs se transmettent de parent à enfant dans l'arbre :

α contient la valeur maximale rencontrée par les nœuds Max, et ne sera mis à jour que sur des nœuds Max ;
β contient la valeur minimale rencontrée par les nœuds Min, et ne sera mis à jour que sur des nœuds Min

On fixe la règle suivante : si dans un nœud α > β, alors on élague les branches enfants non explorées sous ce nœud. Pas la peine d'aller plus loin ! 🫥

Voyons concrètement ce que cela donne avec notre partie d'échec :

En parcourant la branche de gauche (Cc3) on transmet α et β à chaque nœud avec leurs valeurs initiales respectives -infini et +infini.
On commence à évaluer les gains tout en bas à gauche. Puisque c'est un nœud Max, on met à jour α qui vaut maintenant 5, car 5 > -infini.
On remonte le gain au nœud parent (le nœud Min 5). Puisque c'est un nœud Min, on met à jour β qui vaut alors 5, car 5 < +infini.
On redescend les valeurs α et β dans le deuxième nœud enfant, et en déterminant seulement les gains 3 et 10, on se rend compte que α > β (car 10 > 3 > -infini pour α). Alors on peut se permettre d'élaguer les autres branches à droite du nœud 10 sans même les regarder !

De la même manière, on remonte le gain 5 au premier nœud tout en haut en mettant à jour α, car c'est un nœud Max :

Et on réapplique la même logique sur les branches de droite !

On remarque très vite que sur le nœud Min 1 de droite, α > β. Bim ! On peut appliquer un deuxième élagage de toute la partie droite ! 😎

Bilan ? Avec ces deux élagages, nous venons d'économiser 3 calculs de gains sur 11, si on ne compte que les coups visibles sur le schéma. Soit environ 30 % de complexité en moins sur l'algorithme MinMax initial !

Le mot de la fin

Nous venons de comprendre comment un problème à explosion combinatoire peut être simplifié jusqu'à une échelle devenue résoluble. Un des secrets de la victoire de l'ordinateur Deep Blue, donc.

L'élagage alpha-bêta est d'ailleurs d'autant plus efficace qu'il y a de possibilités à chaque nœud. Ce qui est une aubaine pour des modèles plus riches et plus ancrés dans la réalité.

Depuis la victoire de Deep Blue, d'autres techniques d'élagage ont vu le jour dans d'autres domaines, comme la PVS (Principal Variation Search) ou les élagages probabilistes, comme dans certaines IA d'aujourd'hui où l'approche peut être plus heuristique.

Outre les échecs, les algorithmes MinMax sont utilisés aujourd'hui dans bien d'autres cas d'application comme la prise de décision en robotique, des scénarios politiques, la gestion des risques financiers, etc.

Tant que la meilleure décision est gardée à la fin… 😄

Top 4 des astuces avec WSL !

Jean-Noël — Tue, 15 Jul 2025 08:53:51 +0000

Top 5 des astuces WSL

Introduction

Connaissez-vous le WSL ou Windows Subsystem for Linux, cette fonction très pratique permettant d'exécuter un système Linux au sein de Windows, mais sans passer par une virtualisation lourde comme VirtualBox ?

En tant que développeur, sous Windows, c'est l'outil idéal au quotidien. Il permet de travailler facilement et simultanément avec les environnements Windows et Linux pour différents besoins.

La techno du WSL s'améliorant chaque année, il nous paraissait logique aujourd'hui de partager avec vous nos meilleures trouvailles, de la petite ligne de commande astucieuse jusqu'à la fonctionnalité cachée 🙂 (oui, il y en a !).

Astuce n°1 : Manager ses WSL en CLI

Gérer de multiples instances

Le programme WSL2 nous permet de gérer non pas une, mais plusieurs instances Linux, et ce, directement depuis l'invité de commande (ou PowerShell).

Avant d'installer une distribution de Linux, nous pouvons commencer par afficher les distributions disponibles au téléchargement :

wsl --list --online

Voici une liste des distributions valides qui peuvent être installées.
Installer en utilisant 'wsl.exe --install <Distro>'.

NAME                            FRIENDLY NAME
Ubuntu                          Ubuntu
Debian                          Debian GNU/Linux
kali-linux                      Kali Linux Rolling
Ubuntu-18.04                    Ubuntu 18.04 LTS
Ubuntu-20.04                    Ubuntu 20.04 LTS
Ubuntu-22.04                    Ubuntu 22.04 LTS
Ubuntu-24.04                    Ubuntu 24.04 LTS
OracleLinux_7_9                 Oracle Linux 7.9
OracleLinux_8_7                 Oracle Linux 8.7
OracleLinux_9_1                 Oracle Linux 9.1
openSUSE-Leap-15.6              openSUSE Leap 15.6
SUSE-Linux-Enterprise-15-SP5    SUSE Linux Enterprise 15 SP5
SUSE-Linux-Enterprise-15-SP6    SUSE Linux Enterprise 15 SP6
openSUSE-Tumbleweed             openSUSE Tumbleweed

Avec la commande wsl --install, la distribution installée par défaut sera normalement la dernière version LTS d'Ubuntu.
Mais il est possible d'installer également une 2e distribution spécifique qui nous intéresse. Par exemple, la 22.04 LTS, plus ancienne :

wsl --install -d Ubuntu-22.04

On peut alors lister toutes nos versions installées avec un wsl -l :

Ubuntu-22.04 (par défaut)
Ubuntu-24.04

Note : il faut bien se rappeler que chaque distribution est une instance bien différente avec un espace de stockage différent :

toutes les instances Linux peuvent accéder aux fichiers du lecteur C:\ avec un cd /mnt/c/,

mais depuis le PowerShell, on accède aux fichiers Linux via cd \\wsl$\Ubuntu-24.04 (ou cd \\wsl$\Ubuntu-22.04, etc.)

Maintenant que plusieurs instances WSL sont présentes sur Windows, il faudra penser à désigner la bonne à chaque commande wsl, histoire de ne rien laisser au hasard.

Pour cela, deux options s'offrent à nous :

soit sélectionner l'instance par défaut avec un wsl --set-default Ubuntu-24.04, qui sera implicitement choisie pour toutes les futures commandes wsl
soit indiquer l'instance utilisée uniquement pour la commande actuelle : wsl -d Ubuntu-22.04

Exécuter des commandes dans WSL depuis Windows

Avec l'argument --exec, on peut exécuter une commande simple directement dans la machine Linux, mais sans quitter son PowerShell ! 😯
Par exemple, avec cette commande qui nous permet d'obtenir la version du système :

wsl --exec cat /etc/os-release

Ce qui nous affiche :

PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

Et pour des commandes plus complexes, on peut exécuter un script bash présent sur le système de fichiers Linux :

wsl --exec ~/my_script.sh

D'expérience, lancer des commandes avec --exec permet de réduire les intermédiaires en agissant directement dans l'environnement voulu, ce qui est très pratique pour lancer des commandes dans une double virtualisation avec Docker Linux par exemple (voir section "Docker dans WSL").

Changer l'emplacement du disque virtuel WSL

Il n'y a pas de magie : s'il y a un système de fichiers persistant dans les WSL, c'est qu'il y a un emplacement de stockage réservé quelque part !

Les fichiers des environnements Linux sont en réalité stockés dans C:\Users\<UserName>\AppData\Local\Packages\CanonicalGroupLimited.<Distrib>_<ID>\LocalState\ sous forme de fichier *.vhdx.

Pour rappel, un fichier vhdx ou "Virtual Hard Disk V2" est un disque dur virtuel. Créé initialement par Connectix puis repris par Microsoft, il peut être utilisé avec les émulateurs VirtualBox, Parallels Desktop, ou Hyper-V. Il peut s'étendre jusqu'à 64 To (contre 2 To avec l'ancien format vhd).

Pour en revenir à notre espace de stockage WSL : si on voulait stocker nos instances sur un autre disque physique situé sur le lecteur D: ? (Au hasard, un bon SSD 🙃)

Eh bien, c'est possible. Pour déplacer ce fameux fichier VHDX :

wsl --shutdown
wsl --manage Ubuntu-24.04 --move D:\My-WSLs

Astuce n°2 : Une IHM avec WSLg

Nous avons appris comment installer et accéder à WSL en ligne de commande. Mais depuis le build 19044 de Windows 10 (et depuis le début de Windows 11), il est également possible d'exécuter des applications possédant une interface graphique. Ces applications sont alors intégrées dans notre environnement Windows (raccourci dans le menu démarrer, icône dans la barre des tâches durant l'exécution, accès au presse-papier, etc.)

Sur une machine Windows 10 sur laquelle WSL était déjà installé, il est nécessaire de réaliser quelques vérifications avant de lancer des applications :

Vérifier que la distribution se lance bien en mode WSL version 2

  wsl --list --verbose

  NAME      STATE           VERSION
  * Ubuntu    Running         2

Si ce n'est pas le cas, la commande suivante y remédiera : wsl --set-version Ubuntu 2.

S'assurer que le noyau WSL soit à jour :

wsl --update
wsl --shutdown # Attention: cela équivaut a éteindre WSL, toute application éxécutée sera terminée"

Une fois cela fait, ou si la machine était suffisamment à jour, la manipulation est transparente :

On commence par installer une application possédant une interface graphique (ex : GIMP) : sudo apt install gimp

Il ne nous reste plus qu'à lancer l'application :

Soit par l'icône qui est apparue dans le menu démarrer (sous le dossier qui porte le nom de votre distribution)
Soit lancer l'application via une CLI ouverte dans la distribution WSL

L'application devrait maintenant s'afficher sur votre bureau.

Astuce n°3 : Docker dans WSL

Docker Desktop est le moyen le plus courant pour installer Docker sous Windows. Cependant l'application Docker Desktop (pas le moteur d'exécution de conteneur docker lui-même) requiert maintenant une licence dans un cadre professionnel pour toute entreprise d'une certaine taille.

Comment faire pour utiliser docker si nous n'avons pas besoin de Docker Desktop ?

Utilisons WSL !

Nous allons principalement suivre les instructions pour la distribution que nous avons installée, ici, Ubuntu : https://docs.docker.com/engine/install/ubuntu/.

Toute commande fournie ci-dessous devra être exécutée dans le contexte de votre distribution WSL, sauf mention contraire.

Commençons par nous assurer de commencer sur une base propre et de désinstaller tout paquet existant pouvant avoir un lien avec docker :

for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do sudo apt-get remove $pkg; done

Il est possible qu'aucun de ces paquets ne soient installés et qu'apt vous en notifie.

Configurons le dépôt apt de docker (pour avoir des versions à jour) :

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

Maintenant, installons docker et ses utilitaires :

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Nous pouvons maintenant utiliser docker, mais nous avons besoin de le faire en utilisant sudo :

sudo docker run hello-world

Pour pouvoir l'utiliser de manière plus fluide, il nous faut ajouter notre utilisateur au groupe docker.

Commençons par le créer : sudo groupadd docker.
Puis, ajoutons ce groupe à notre utilisateur : sudo usermod -aG docker $USER.

Forçons la déconnexion en lançant depuis un terminal windows (non WSL) : wsl --shutdown.

Et nous pouvons maintenant utiliser : docker run hello-world.

Astuce bonus : un alias pour utiliser docker directement depuis windows

Sous PowerShell éditez votre fichier de profil :

notepad $profile.CurrentUserAllHosts

et ajoutez-y ce contenu :

function docker {
    wsl -- docker $args
}

Vous pourrez maintenant, pour vos prochaines sessions PowerShell appeler les commandes docker directement (ex : docker ps).

Pour CMD, la mise en place d'alias est bien plus complexe et sort du cadre de cet article.

Astuce n°4 : Passerelle USB avec Usbipd

D'accord, il est possible d'échanger des fichiers entre l'hôte Windows et l'environnement Linux. Mais qu'en est-il des périphériques USB ?

En vérité cette passerelle existe depuis un certain nombre d'années, mais aujourd'hui elle est grandement simplifiée avec l'outil en CLI usbipd.

Comme son nom l'indique, c'est un programme qui va ouvrir un canal d'échange TCP/IP sur un réseau local à la machine, et rediriger les flux d'un périphérique USB vers et depuis ce canal.

Notez qu'il existe une version IHM de l'outil (capture d'écran ci-dessus), mais en tant que développeurs, nous allons nous concentrer sur la version CLI qui nous offre une interopérabilité plus intéressante, par exemple avec des scripts.

Après avoir installé l'outil depuis le setup ou le package manager de Windows : winget install usbipd, nous allons être capables de lister les devices disponibles :

usbipd list

Connected:
BUSID  VID:PID    DEVICE                                                        STATE
2-6    0c45:6a17  Integrated Webcam, Integrated IR Webcam                       Not shared
2-10   8087:0033  Intel(R) Wireless Bluetooth(R)                                Not shared
13-6   0424:284c  Hub Feature Controller, Périphérique d’entrée USB             Not shared
14-3   0bda:8153  Realtek USB GbE Family Controller #2                          Not shared

Sur cette liste, on notera le BUSID qui nous permettra de désigner un périphérique spécifique à partager, ainsi que le STATE qui nous indique l'état de partage à proprement parler.

En ouvrant un PowerShell administrateur, on saisit la commande bind pour ouvrir un canal de partage, par exemple sur la webcam :

usbipd bind -b 2-6

À ce stade, si on liste à nouveaux les périphériques, on doit voir apparaître le statut Shared :

Connected:
BUSID  VID:PID    DEVICE                                                        STATE
2-6    0c45:6a17  Integrated Webcam, Integrated IR Webcam                       Shared

Il ne nous reste plus qu'à assigner le périphérique à une instance WSL :

usbipd attach --wsl --busid 2-6

usbipd: info: Using WSL distribution 'Ubuntu-22.04' to attach; the device will be available in all WSL 2 distributions.
usbipd: info: Using IP address 172.25.224.1 to reach the host.

Le device passe alors dans l'état Attached côté Windows, et apparaît dans le contexte Linux :

lsusb

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0c45:6a17 Microdia Integrated_Webcam_FHD
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Le tour est joué ! 🙂

Le mot de la fin

Nous avons pu vous montrer plusieurs astuces assez étonnantes autour du WSL qui, en parallèle, continue d'évoluer, permettant ainsi de se passer d'outils de virtualisation lourde comme VirtualBox.

Si, comme nous, vous aimez en apprendre toujours plus, il reste encore d'autres sujets très intéressants à explorer du côté des IHM de configuration, de la nouvelle distribution Red Hat RHEL, ou encore de l'import/export des WSL sous forme de fichier, etc.

Cet article a été coécrit avec Antoine-Ali. N'hésitez pas à aller voir également ses publications !

AVIF : le nouveau format d'image Next-Gen !

Jean-Noël — Mon, 26 May 2025 12:12:21 +0000

Aujourd'hui je vous propose un article rapide sous forme de mini-diaporama, sur ce nouveau format d'image révolutionnaire !

Le lien du comparateur en question ICI.

Codez votre PPT avec Slidev !

Jean-Noël — Thu, 06 Mar 2025 14:40:47 +0000

Codez votre PPT avec Slidev

Introduction

Vous qui avez déjà peaufiné des dizaines de présentations PowerPoint, que ce soit pour une soutenance, un support de formation, des solutions techniques, ou d'adorables petits exposés scolaires 😇, savez-vous qu'il existe des alternatives logicielles à PowerPoint ou Keynote mais ultra orientées dev ?

Il existe en réalité plusieurs projets comme Reveal.js ou Marp qui proposent concrètement d'utiliser un langage de programmation ou équivalent pour préparer un diaporama avec du contenu multimédia et des animations.
Mais aujourd'hui je vous invite à en découvrir un en particulier : Slidev.

Slidev est un jeune projet Node.js Open Source et un peu "fou". Essentiellement écrit en TypeScript, il est doté d'une interface graphique en Vue.js.
Il propose de coder ses diapos à l'aide de Markdown enrichi, un format assez simple et déjà bien connu de tous.

À l'heure où j'écris ces lignes, Slidev est encore en version 0.49 – donc très expérimental – mais vous allez voir à travers ce tuto qu'il présente déjà quelques fonctionnalités qui valent vraiment le détour !

Note : pour ceux qui sont pressés, vous pouvez directement tester Slidev ici.

Pourquoi diable s'embêter à coder un diaporama ?

On pourrait croire qu'un pseudo langage comme le Markdown nous ferait économiser du temps d'écriture, comparé aux déplacements sinueux de la souris dans un logiciel classique (PowerPoint, Keynote, …).

Oubliez ça.

Bien que l'on puisse gagner un peu de temps lorsqu'on se contente d'un layout très simple (car Slidev positionne automatiquement les éléments sur chaque diapositive avec le layout et le thème choisis), il y a une autre vraie bonne raison : les possibilités.

Les possibilités, c'est de pouvoir faire des présentations ultra techniques avec une meilleure intégration de code (une intégration de code tout court, en fait 😄). Vous pouvez par exemple montrer des extraits de code avec coloration syntaxique, créer des animations avancées sur des parties précises, intégrer des formules LaTeX, coder directement en Vue.js ou même ajouter des fonctionnalités dynamiques comme le "live coding" !

Enfin, une autre bonne raison est de pouvoir mettre en place un système de synchronisation entre un thème de référence et celui appliqué sur le diaporama. Ainsi, votre diaporama suivra automatiquement les évolutions de la charte graphique de l'entreprise !

Explorons maintenant ensemble toutes ces possibilités offertes par cette étonnante lib.

Codons un diaporama

La base

Commencez par initialiser un projet Node.js en suivant les instructions ici et créez un fichier d'entrée slides.md à la racine.

Placez une image d'arrière-plan dans un répertoire imgs, et ajoutez alors ce contenu minimal dans votre fichier slides.md (pensez à adapter le chemin de votre image) :

---
background: ./imgs/background.webp
---

# Le titre de ma première diapo

Créez des diapos tech et dynamiques !

<!--
Quelques notes réservées au présentateur pour la première diapo.
-->

Lancez la commande npm exec slidev -- --port 3030 "slides.md".
Vous aurez alors accès à 3 espaces principaux :

une interface web sur http://localhost:3030/ pour montrer le diaporama à votre public (et avec une vignette caméra déplaçable, trop cool !) :

une page localhost:3030/presenter pour contrôler votre diaporama en mode présentateur :

et une dernière page localhost:3030/overview histoire d'avoir un aperçu global de toutes vos diapos, même si vous préfèrerez sûrement l'affichage en grille depuis le mode présentateur (icône "Show slide overview").

Vous pouvez également installer une extension pour VS Code qui ajoute l'autocomplétion, vous permet de vous déplacer directement à une section depuis un titre, de réorganiser l'ordre des diapos, ou même d'avoir un aperçu en temps réel dans une vignette :

Et tous ces espaces sont globalement synchronisés entre eux !

Attention : si vous utilisez Prettier, il faudra le configurer pour éviter les conflits avec ce Markdown un peu spécial !

Configurez le thème et les layouts

Commençons à configurer les slides de notre diaporama.

Il faut savoir que Slidev construit chaque diaporama en composant le contenu des fichiers .md avec un thème graphique et un ensemble de layouts.

Tout d'abord je vous propose de choisir un thème dans la galerie officielle.
Vous pouvez le spécifier une (et une seule) fois dans ce que l'on appelle la partie headmatter, tout en haut du fichier Markdown :

---
theme: default
transition: slide-left
background: ./imgs/background.webp
title: Mon premier diaporama
---

# Le titre de ma première diapo

Créez des diapos tech et dynamiques !

Toutes les polices, tailles, couleurs et images par défaut seront automatiquement configurées !

Notez bien les --- avant et après l'en-tête, car ils délimitent la partie "en-tête" de la partie "contenu" pour chaque slide.

Au passage, on en profite également pour configurer les animations entre chaque diapo : transition: slide-left qui va faire glisser la diapo suivante de la droite vers la gauche. Sobre, mais efficace.

Ensuite, créez une nouvelle slide et ajoutez un layout image-right, dans la partie que l'on appelle alors frontmatter (tout un vocabulaire 😌).
Ce layout vous permettra d'ajouter le chemin d'une image, qui peut tout à fait être une URL d'ailleurs !

# Le titre de ma première diapo

Créez des diapos tech et dynamiques !

---
layout: image-right
image: https://domain.org/imgs/background.webp
---

Ici on ajoute du contenu uniquement sur la partie gauche de la diapo.

Il existe également les layouts center, full, fact, iframe-right, quote, etc.

Il ne peut y avoir qu'un seul thème par diaporama, mais chaque slide peut avoir un layout différent.

De manière générale, les layouts disponibles par défaut restent très simples et la plupart du temps, ils sont suffisants.
Si toutefois vous cherchez une disposition personnalisée, il faudra soit aller chercher un plugin existant, soit écrire quelques lignes de code (cf. doc officielle).

Maintenant, entrons dans le vif du sujet et expérimentons des contenus riches autour de code et de schémas qu'un logiciel de diaporama classique ne serait pas en mesure de gérer !

Présentez du code avec classe

Extraits de code et animations

Dans la diapo que vous venez de créer, commencez par ajouter un extrait de code de la même façon qu'en Markdown :

On obtient une présentation basique du code avec coloration syntaxique et le texte sélectionnable.

Mais avec le Markdown enrichi que nous propose Slidev, nous allons pouvoir ajouter des options très intéressantes, comme l'affichage du numéro des lignes et la surbrillance successive des lignes 5, 1 puis 2 au clic de souris (ou les flèches du clavier), comme si l'on simulait un débogage !

Et si on allait un peu plus loin dans les animations ?

Imaginez que vous souhaitiez présenter une refactorisation ou tout simplement un JSON, par exemple, qui évoluerait plusieurs fois, successivement.
Eh bien, vous allez pouvoir animer ce code automatiquement avec la feature shiki-magic-move pour mettre en évidence ces évolutions :

Et le rendu slidev, toujours animé au clic de souris ou flèches clavier :

Magique ! 😲

Live Coding

Nous venons de voir la présentation de code statique. Maintenant nous allons construire une slide qui va nous permettre de réaliser une démonstration de code en direct, et sans quitter la présentation.

Ajoutez une nouvelle slide avec un layout de type full pour un affichage confortable. Puis ajoutez la suite de Fibonacci dans un extrait de code avec la mention {monaco-run} pour activer l'éditeur.

L'éditeur Monaco intégré va alors nous permettre de modifier le code en direct avec le linter, l'autocomplétion, et même l'exécution en temps réel !

Construisez des schémas avancés

Slidev prend en charge les graphes PlantUML et Mermaid. Si vous ne connaissez pas encore ce dernier, je vous conseille d'aller faire un tour sur notre article ici.

Mermaid offre beaucoup plus de possibilités qu'un système de drag-n-drop de formes qu'on trouverait dans un logiciel classique : diagrammes de séquence, classes, mindmap, git graph…

Ici je vous propose de partir sur un diagramme de Gantt, car c'est typiquement le genre de diagramme qui pourrait décourager à dessiner dans un soft classique.

Créez une nouvelle slide intitulée "Organisation du projet", avec le layout default qui, ici, convient à un diagramme qui a tendance à s'étendre sur la longueur. Ensuite, vous allez pouvoir ajouter directement un extrait de code de type mermaid pour dessiner un diagramme de Gantt, par exemple, sur l'organisation des développements d'une appli web entre une équipe UI/UX, une front, et une back.

Ce qui nous génère un magnifique diagramme de Gantt dans notre diapo !

Comme vous pouvez le constater, la syntaxe nécessite quand même une certaine prise en main. Mais avec un peu d'expérience, l'écriture, et surtout, la mise à jour du diagramme dans le diaporama deviennent très intéressantes !

Multipliez les possibilités avec des composants externes

Dans cette partie nous allons pousser l'intégration d'éléments externes en combinant une scène 3D du système solaire avec un Component Vue.js dans une seule et même diapositive.

Tout d'abord, commençons par créer une diapo très simple, qui va juste se contenter d'afficher notre composant Vue.js :

---
title: Contenus externes
layout: full
---

# Un composant Vue.js dynamique

<PlanetTeleporter />

Ensuite, créez un fichier components/PlanetTeleporter.vue à la racine du projet.

Dans ce nouveau composant, nous allons construire :

un iframe ouvert sur une page web intégrant un système solaire en 3D (basé sur Three.js) ;
et un bouton superposé qui va légèrement modifier l'URL de la scène 3D pour se téléporter directement à la planète Saturne.

<script setup lang="ts">
import { ref } from 'vue';

const url = ref("https://eyes.nasa.gov/apps/solar-system/")

function toSaturn(){
    url.value = "https://eyes.nasa.gov/apps/solar-system/#/saturn"
}
</script>

<template>
  <section>
    <iframe :src="url" title="Page externe système solaire"></iframe>
    <button @click="toSaturn">Vers Saturne !</button>
  </section>
</template>

<style scoped>
section {
    position: relative;
    height: 85%;
}

button {
    position: absolute;
    left: 380px;
    top: 15px;
    border: 1px solid white;
    color: white;
    width: 120px;
    padding: 5px;
    font-family: mono;
    background-color: black;
}

button:hover {
    background-color: gray;
}

iframe {
    width: 100%;
    height: 100%;
}
</style>

Si vous regardez alors le rendu :

… et toujours sans quitter votre slide !

Imaginez maintenant tout ce que vous allez pouvoir faire en intégrant des composants dynamiques encore plus avancés, ou en manipulant directement du SVG pour une qualité graphique toujours nickel ! 🤩

Maintenant, vous avez toutes les clés en main pour créer des diaporamas techniques complètement dingues !

Et si vous cherchez encore de l'inspiration, je vous invite à jeter un œil à la galerie d'exemples.

Conclusion

À travers ce tuto, nous avons pu explorer de nombreuses fonctionnalités qu'offre la lib Slidev, surtout d'un point de vue intégration de code dynamique, de schémas et contenus externes.

Avec du recul, on constate également que Slidev est un projet encore très récent, qui manque peut-être encore un peu de stabilité et d'uniformité dans la syntaxe par rapport à d'autres projets comme Reveal.js.
Par ailleurs, dès que l'on souhaite une disposition ou une animation particulière, la tâche peut rapidement s'annoncer plus ardue que prévu et nécessiter un investissement assez important. Mais au bout du compte, le jeu en vaut peut-être la chandelle ?

Et comme je le disais au début de ce tuto, ce qui nous intéresse surtout ici, ce sont les possibilités !

J'ai essayé de passer à Vue.js depuis React.js

Jean-Noël — Mon, 04 Nov 2024 09:59:28 +0000

Introduction

Il y a quelques années, comme beaucoup d'autres, j'étais "hypé" par l'arrivée des hooks et les composants fonctionnels de la librairie frontend React.js. Ils proposaient une toute nouvelle manière de développer en écrivant beaucoup moins de code qu'avec les class Components. J'ai véritablement accroché, et pour un bon moment.

Aujourd'hui, j'ai dû opter pour le framework Vue.js afin de répondre aux besoins d'un tout nouveau projet client. Et étant arrivé au bout de ce projet, je me suis dit que c'était l'occasion de vous proposer un retour d'expérience en tant que nouvel utilisateur de ce framework !

Alors, est-ce que cette montée en compétence a été à la hauteur de la notoriété de Vue.js ?
Est-ce qu'il vaut mieux, aujourd'hui, développer du frontend en Vue qu'en React ?

C'est ce que nous allons voir !

Démarrage du projet

Boilerplate

Qui dit démarrage de projet, dit recherche d'un bon boilerplate pour nous épargner des heures, voire des jours de configuration laborieuse !
Sans avoir besoin de chercher très loin, la commande npm create vue@latest répond largement à mes besoins :

✔ Project name: … myproject-vue
✔ Add TypeScript? … No / Yes
✔ Add JSX Support? … No / Yes
✔ Add Vue Router for Single Page Application development? … No / Yes
✔ Add Pinia for state management? … No / Yes
✔ Add Vitest for Unit Testing? … No / Yes
✔ Add an End-to-End Testing Solution? › Playwright
✔ Add ESLint for code quality? … No / Yes
✔ Add Prettier for code formatting? … No / Yes
? Add Vue DevTools 7 extension for debugging? (experimental) › No / Yes

Le langage Typescript est déjà pris en charge, un système de routage et un store sont proposés, et il y a même de quoi réaliser des tests unitaires et End-to-End !

Par défaut, c'est le bundler Vite qui est installé. Ce qui n'est pas pour me déplaire !😄 En effet, les builds sont rapides et, la plupart du temps le Hot Module Replacement (HMR) fonctionne bien.

Un petit npm run dev pour lancer le serveur de dev local, et hop ! Ça tourne déjà dans le navigateur !

Et pour la mise en prod ? Il suffit de saisir la commande npm run build, et le projet s'exporte en fichiers statiques dans un répertoire dist après avoir vérifié les typages (dans le cas où l'on a activé le Typescript) :

vite v5.2.11 building for production...
✓ 48 modules transformed.
dist/index.html                      0.43 kB │ gzip:  0.28 kB
dist/assets/AboutView-C6Dx7pxG.css   0.09 kB │ gzip:  0.10 kB
dist/assets/index-D6pr4OYR.css       4.21 kB │ gzip:  1.30 kB
dist/assets/AboutView-CEwcYZ3g.js    0.22 kB │ gzip:  0.20 kB
dist/assets/index-CfPjtpcd.js       89.23 kB │ gzip: 35.29 kB
✓ built in 591ms

Architecture du projet

.
├── README.md
├── e2e/
├── index.html
├── package.json
├── public/
├── src/
│   ├── App.vue
│   ├── assets/
│   ├── components/
│   │   ├── HelloWorld.vue
│   │   ├── TheWelcome.vue
│   │   ├── WelcomeItem.vue
│   │   ├── __tests__/
│   │   └── icons/
│   ├── main.ts
│   ├── router/
│   │   └── index.ts
│   ├── stores/
│   │   └── counter.ts
│   └── views/
│       ├── AboutView.vue
│       └── HomeView.vue
├── tsconfig.json
└── vite.config.ts

Côté architecture du projet, on trouve notamment :

le fichier index.html, avec la balise <div id="app"></div> sur laquelle vient se greffer toute notre application Vue ;
le main.ts, avec la création successive du composant App, du router et du store :

import './assets/main.css';

import { createApp } from 'vue';
import { createPinia } from 'pinia';

import App from './App.vue';
import router from './router';

const app = createApp(App); // composant racine

app.use(createPinia()); // store
app.use(router); // routage des pages front

app.mount('#app');

des fichiers .ts purs, pour gérer le routage et le store ;
quelques fichiers de config et de test ;
... et bien sûr les fichiers *.vue, distingués en components (qui correspondent plutôt à des éléments génériques et réutilisables), et views (qui correspondent plutôt à des pages haut niveau)

En bref, l'architecture des fichiers est plutôt simple et relativement similaire à celle de React, même en ayant coché pas mal d'options dans le boilerplate.
Jusque-là, venant de React, rien de bien nouveau. C'est ensuite qu'apparaissent des différences significatives !

Architecture d'un fichier Vue

Voici un extrait de code inspiré du site officiel. Il se contente de changer la couleur du texte si l'on clique dessus et d'afficher la phrase "Le texte ci-dessus est vert", le cas échéant, mais il représente une architecture typique des fichiers *.vue :

<script setup>
  import { ref } from 'vue';

  const color = ref('green');

  function toggleColor() {
    color.value = color.value === 'green' ? 'blue' : 'green';
  }
</script>

<template>
  <p class="main-text" @click="toggleColor">
    Cliquez sur ce texte pour changer de couleur.
  </p>
  <p v-if="color === 'green'">Le texte ci-dessus est vert.</p>
</template>

<style scoped>
  .main-text {
    color: v-bind(color);
  }
</style>

Notez le binding des évènements avec @click, l'affichage conditionnel avec le v-if, et le binding dans le CSS avec v-bind().

Le code est séparé en 3 parties bien distinctes :

script : le code de contrôle ;
template : la structure HTML ;
style : la feuille de style CSS.

Et ces trois parties ne se mélangent jamais 😮.
Cela présente plusieurs avantages que j'ai personnellement éprouvés tout au long mon expérience sur le projet client :

La structure HTML est claire, fixe, et dans un style très déclaratif - tout est là, même les balises affichées sous conditions ;
la partie logique est bien séparée de la partie affichage ;
on peut écrire du pur CSS en place, directement lié au composant, et sans installer de librairies tierce ;
malgré la séparation du style, on peut quand même insérer des variables dans le CSS.

Avec le tag scoped sur la balise <style>, on peut même générer automatiquement des classes locales afin d'isoler sa feuille de style !

Petit inconvénient : a priori il n'existe pas de polyfill CSS automatique. Il faut alors plutôt viser une librairie comme vue-emotion.

De mon point de vue, je trouve que ce genre de librairie "all-in-JS" casse un peu l'architecture que propose Vue, et de toute évidence, les propriétés CSS spécifiques aux navigateurs sont beaucoup plus rares de nos jours. La balise <style> de Vue est donc souvent autosuffisante.

Bref, j'ai trouvé très plaisante cette architecture tout-en-un mais avec des sections bien séparées. Cela permet de garder un code propre, mais aussi plus concis. En effet, la présence simultanée des 3 sections "logique métier / affichage / style" incite souvent à redécouper son code en plus petits modules, et donc en plus petits fichiers.

Maintenant, si on se penchait un peu plus sur l'API Vue.js elle-même ?

L'API Vue.js

Ici je ne vous ferai pas la liste exhaustive de tous les éléments de l'API Vue.js que j'ai pu rencontrer, mais seulement de certains, bien spécifiques, que j'ai trouvés assez représentatifs de la logique de Vue.

Les valeurs (re)calculées

Commençons par une opération bien connue de l'univers React : recalculer intelligemment un rendu HTML (ou une variable) suite à la mise à jour d'une donnée.
Il y a la fonction très intuitive computed() qui bénéficie d'un système de mémoïsation (sorte de "cache") pour éviter de recalculer à chaque fois la valeur de sortie :

<script setup>
  import { ref, computed } from 'vue';

  const pushedBtn = ref(1);

  const magicNumber = computed(() => {
    console.log('computed again!');
    return pushedBtn.value * 21;
  });
</script>

<template>
  <button @click="pushedBtn = 1">Button 1</button>
  <button @click="pushedBtn = 2">Button 2</button>
  <p>Magic number: {{magicNumber}}</p>
</template>

Ici le magicNumber est calculé uniquement si la valeur de pushedBtn vient à changer. Et c'est vérifiable : le message "computed again!" ne s'affiche dans la console que lorsqu'un bouton différent est cliqué.
Donc, contrairement à React, pas besoin de spécifier explicitement les variables qu'il faut surveiller dans cette fonction.

Dans la même lignée, on trouve également les watch et watchEffect qui permettent respectivement de réagir aux changements de tout ou partie des propriétés du composant, à l'image du useEffect en React :

<script setup>
  import { ref, watch } from 'vue';

  const num = ref(1);
  const text = ref('a');

  const countWatchs = ref(0);

  // Attente d'un changement de 'num'
  watch([num], () => {
    countWatchs.value++;
  });
</script>
<template>
  <button @click="num += 4">Modify num</button>
  <button @click="text += 'a'">Modify text</button>
  <p>Props:</p>
  <ul>
    <li>num: {{num}}</li>
    <li>text: {{text}}</li>
  </ul>
  <hr />
  <p>Nb watchs calls: {{countWatchs}}</p>
</template>

Seul un clic sur le bouton modificateur de num va incrémenter le compteur de "watchs".
Le watch() nous permet alors de déclencher une callback à chaque fois que certaines variables changent.

La force de cette fonction réside dans l'analyse en profondeur des modifications de variable : Vue détecte les changements même au fin fond d'un sous-objet !

La synchronisation bidirectionnelle

Déclarer et transmettre une propriété d'un composant parent à un composant enfant est une opération assez récurrente. Synchroniser cette valeur entre l'enfant et le parent l'est également, par exemple dans l'input un formulaire.

Aussi, plutôt que de gérer à la fois une propriété et une callback de mise à jour sur évènement comme ici :

<!-- Child.vue -->
<script setup>
  const props = defineProps(['myModelValue']); // déclaration propriété
  const emit = defineEmits(['update:myModelValue']); // déclaration callback
</script>
<template>
  <h3>Textfield:</h3>
  <input
    :value="props.modelValue"
    @input="emit('update:myModelValue', 
     ($event.target as HTMLInputElement).value)"
  />
</template>

… il est possible d'utiliser à la place la macro defineModel qui permet de simplifier l'écriture :

<!-- Child.vue -->
<script setup>
  const myModelValue = defineModel('myModel');
</script>
<template>
  <h3>Textfield:</h3>
  <input v-model="myModelValue" />
</template>

Beaucoup plus court ! 😎 D'ailleurs, n'ayant qu'un seul modèle, j'aurais même pu me dispenser de le nommer !

Et avec le parent :

<!-- Parent.vue -->
<script setup>
  import { ref } from 'vue';
  import Child from './Child.vue';

  const data = ref('my default value');
</script>

<template>
  <div>Parent value: {{data}}</div>
  <Child v-model:my-model="data"></Child>
</template>

La boucle for

Enchaîner sur les v-for après avoir vu les v-model m'a fait réaliser que Vue.js commençait à introduire pas mal de "magie" à travers du code implicite :

<script setup>
  const commonGitActions = ['Pull', 'Commit', 'Push', 'Merge', 'Rebase'];
</script>

<template>
  <h1>Actions git communes</h1>
  <ul>
    <!-- Boucle "for" intégrée -->
    <li v-for="action in commonGitActions">{{action}}</li>
  </ul>
</template>

Et le rendu :

Comme on pouvait s'y attendre, l'instruction v-for permet donc de répéter automatiquement une partie d'un patron HTML (ici la balise <li>) pour chaque élément d'un itérable.

Côté React, il aurait fallu utiliser du JSX pour construire soi-même chaque élément, rendant le code moins lisible au fur et à mesure que le composant grandit :

import React from 'react';

const commonGitActions = ['Pull', 'Commit', 'Push', 'Merge', 'Rebase'];

export function App(props) {
  return (
    <>
      <h1>Actions git communes</h1>
      <ul>
        {commonGitActions.map((action) => (
          <li key={action}>{action}</li>
        ))}
      </ul>
    </>
  );
}

Personnellement, j'ai une préférence pour la structure de Vue en termes de propreté de code, tant qu'il n'y a pas besoin de déboguer. 😅
Et d'ailleurs, puisqu'on parle de déboguer, qu'en est-il des outils de l'écosystème Vue ?

Les outils de dev

Voici 3 outils qui ont retenu mon attention dans le développement de mon projet.

Extension VSCode : Vue Official

Je commence par une évidence, mais oui, il y a bien une extension pour VSCode Vue (et pour d'autres IDEs) qui ajoute la coloration syntaxique, autocomplétion, snippets, etc. Un indispensable !

Toutefois, j'ai constaté quelques instabilités sur la coloration et l'autocomplétion, qui étaient parfois un peu capricieuses 😕, là où j'ai pu apprécier une plus grande stabilité côté React.

Vue.js devtools

À l'image du plugin de navigateur React Developer Tools, il existe le plugin Vue.js devtools, qui, je dois l'avouer, est déjà très bien fourni :

On y retrouve 4 onglets :

Components, où on l'on peut observer, mais également modifier les états des composants ;
Timeline, qui permet d'enregistrer les évènements et les temps de rendu des composants, ce qui correspond en fait à une version de l'onglet "Performances" du navigateur mais focalisée sur Vue ;
Pinia, qui permet d'observer et modifier directement les états du store standard 😯, une intégration déjà toute prête que j'ai trouvée particulièrement bienvenue ;
Routes, où l'on peut lister les différentes routes et leur activité - c'est un onglet que j'ai trouvé un peu gadget sur mon projet de taille modérée (d'autant plus que les informations sont un peu redondantes avec celles de l'onglet "Components"), mais qui peut s'avérer bien utile sur un routage complexe.

Bref, pour du débogage, il y a tout ce qu'il faut et même plus !

Vuetify

Quasiment sans surprise (mais avec du mérite tout de même !), il existe aussi une librairie UI pour Vue qui implémente les Material Design de Google et fournit également une liste d'icônes standards : Vuetify.

<v-alert border='left' icon='$mdiVuetify' type='success'></v-alert>

Cela permet de gagner beaucoup de temps sur des démarrages de projet, ou sur des projets qui ne nécessitent pas de personnalisation graphique trop poussée.

Mais comme toujours, je recommande de garder un œil sur les performances de rendu avec ce genre de librairie haut niveau. La capacité de configuration d'une librairie se paie souvent ailleurs !

Conclusion

Que dire de cette expérience de migration de React vers Vue ?

Tout d'abord, d'un point de vue du code, par rapport à React je dirais que la lib Vue est :

plus structurée ;
plus déclarative ;
plus concise.

Toutefois, grâce à son code qui s'écrit plutôt en JSX, je trouve que React reste beaucoup plus interopérable, plus programmatique et plus explicite que Vue, et avec une meilleure stabilité du linter.

Côté environnement de développement et communauté, Vue a pour moi toutes les cartes en main pour assurer des développements efficaces jusqu'à la mise en prod.

Alors est-ce que cette montée en compétence sur Vue a été à la hauteur de sa notoriété ? Je dirais que oui. J'ai trouvé la courbe d'apprentissage efficace, et je continuerai de développer avec Vue si l'occasion se présente.

Enfin, est-ce qu'aujourd'hui il vaut mieux développer du frontend en Vue qu'en React ?
D'un point de vue totalement personnel, je pense que non. Même si Vue et React ont chacun des cas d'application un peu différents, je préfère me fier à un système de typage fiable et à un code plus souple avec React. Mais peut-être que les prochaines versions de Vue et leurs outils me feront changer d'avis ?

Et vous, quels sont vos retours d'expérience ?

CSS : En 2024 les Grids c'est has been ?

Jean-Noël — Mon, 29 Jul 2024 08:56:19 +0000

Introduction

Tout le monde sait ce qu'est un affichage responsive en 2024 : c'est occuper intelligemment l'espace disponible pour un affichage optimal en terme d'esthétique et d'ergonomie vis-à-vis des différents supports d'affichage (smartphone, tablette, ordinateur de bureau...).

Mais histoire de revenir aux fondamentaux, en full CSS comment fait-on du responsive design aujourd'hui ?

Pour ce faire, le CSS a mis à notre disposition ces principaux outils :

les grids (...et subgrids 😯) !
les flexboxs
et les media queries

En pratique, nombreux sont les développeurs à avoir complètement abandonné les grids (plutôt historiques, donc) au profit des flexboxs, qui paraissent très similaires tout en étant (un peu) plus modernes.

Mais alors : pourquoi les grids existent toujours ? Ne serait-on pas là, en présence d'un outil quelque peu dépassé ?

Dans l'optique de mieux situer les grids par rapport aux flexboxs, je vous propose de refaire un tour d'horizon de leurs fonctionnalités : comment, mais aussi quand se servir plutôt de l'un ou de l'autre. Et vous allez voir que les grids ont peut-être un peu plus à proposer que ce qu'on croyait !

Les Flexboxs

Comme vous le savez sans doute, la Flexbox propose un système d'alignement beaucoup plus flexible que son homologue Grid. Mais elle a la particularité de se concentrer avant tout sur 1 seul axe principal pour la répartition des éléments :

<div class="container">
  <div class="column col1">Colonne 1</div>
  <div class="column col2">Colonne 2</div>
  <div class="column col3">Colonne 3</div>
  <div class="column col4">Colonne 4</div>
</div>

.container {
  display: flex; /* Activation de la flexbox */
  flex-direction: row; /* Choix de la direction principale */
  justify-content: center; /* Centrage des éléments sur l'axe principal */

  width: 100%;
  background-color: #fff9e6;
}

.column {
  background-color: #fbbe00;
  width: 100px;
  height: 50px;
  color: white;
}

Ce qui nous donne :

En fait, la Flexbox est idéale pour aligner un nombre variable d'éléments sur un seul axe, sans définir au préalable le nombre de colonnes.

Mais il est tout de même possible de régler l'alignement sur l'axe secondaire (vertical dans notre cas 🙂) si, par exemple, notre .container occupait plus de place :

.container {
  /* ... */

  height: 100vh; /* Occuper toute la hauteur du viewport */
  align-items: center; /* Centrer sur l'axe secondaire */

  justify-content: space-between; /* (Autre exemple d'alignement sur l'axe principal) */

  /* ... */
}

...Et il est par ailleurs possible d'utiliser la propriété flex-wrap pour autoriser la création d'une ou plusieurs lignes supplémentaires dans le cas où nos éléments seraient trop grands pour tenir sur une seule ligne :

.container {
  /* ... */
  flex-wrap: wrap;
  /* ... */
}

Vous noterez qu'en réalisant ce dernier exemple, j'ai volontairement introduit des tailles différentes sur les éléments 4 et 5. On constate alors que les flexboxs ne garantissent pas un alignement identique des colonnes sur plusieurs lignes 😕. La flexbox s'est juste contentée d'afficher les éléments les uns derrière les autres. C'est une limitation à prendre en compte.

Enfin, pour terminer ce tour d'horizon sur les Flexboxs, je mentionnerai la propriété notable flex sur les éléments enfants pour justement répondre à la problématique responsive "occuper intelligemment l'espace disponible" :

.container {
  display: flex; 
  flex-direction: row;
  align-items: center;
  height: 100vh;
  gap: 5px; /* (Espaces inter-éléments) */

  width: 100%;
  background-color: #fff9e6;
}

.column {
  background-color: #fbbe00;
  color: white;
}

.col2 {
  flex: 1; /* Petite capacité d'occupation d'espace */
}

.col3 {
  flex: 2; /* Moyenne capacité d'occupation d'espace */
}

.col4 {
  flex: 3; /* Grande capacité d'occupation d'espace */
}

La propriété flex nous permet donc de simplifier la répartition et le partage de l'espace disponible entre les éléments, ici en suivant un coefficient.

Mais attention à ne pas tout confondre : il s'agit bien ici d'étirer les éléments pour occuper l'espace, et non de leur attribuer une ou plusieurs colonnes ! On ne peut donc pas non plus espérer garantir un alignement, par exemple, entre plusieurs flexboxs sur une même colonne ! ...Ca, c'est le boulot des Grids !😋

Les Grids

L'usage classique

Parfois un peu "oublié", comme je vous le disais, depuis les multiples évolutions du CSS, le système de grid consiste à déclarer une grille 2D invisible sur laquelle on peut positionner les éléments enfants. Chaque case de cette grille étant dynamiquement extensible selon la taille du viewport et/ou des éléments.

Le système de Grid est idéal, par exemple, pour définir les dispositions fondamentales d'une page avec ce genre de structure :

<body>
  <header>
    <h1>Header</h1>
  </header>
  <aside>
    <h2>Sidebar</h2>
  </aside>
  <main>
    <h2>Main Title</h2>
    <p>Content content content...</p>
  </main>
</body>

On peut alors typiquement déclarer une grille avec le grid-template-areas que je qualifierai d'assez visuel :

body {
  display: grid; /* Activation de la grille */
  grid-template-areas: /* Déclaration des zones de la grille */
    "header header header header"
    "sidebar content content content";

  grid-template-columns: repeat(4, 25%); /* Répartition des longueurs de nos 4 colonnes */
  grid-template-rows: 30% 70%; /* Répartition des hauteurs de nos 2 lignes */

  margin: 0; /* (Pour étendre notre grille... */
  height: 100vh; /* ...sur toute la page) */
}

header {
  grid-area: header; /* Attribution à la zone 'header' de la grille */
  background-color: #fbbe00;
  color: white;
}

aside {
  grid-area: sidebar;/* Attribution à la zone 'sidebar' de la grille */
  background-color: #fff9e6;
}

main {
  grid-area: content;/* Attribution à la zone 'content' de la grille */
  background-color: white;
}

La propriété grid-template-areas nous permet donc de définir un ensemble de colonnes et de lignes en leur donnant un nom arbitraire (et explicite tant qu'à faire ! 😊). Les balises enfants pouvant alors être attribuées aux zones ainsi nommées grâce à la propriété grid-area.

Auto flow

Si vous trouvez le système de Grid un peu trop "rigide" 🤖, sachez qu'il est également possible d'utiliser un layout automatique indépendamment du nombre d'éléments, un petit peu comme les flexboxs :

body {
  display: grid; /* Activation de la grille */

  grid-auto-flow: column; /* <== Répartition automatique sur les colonnes */

  margin: 0; /* (Pour étendre notre grille... */
  height: 100vh; /* ...sur toute la page) */
}

Il faut noter cependant, que si l'on spécifie les dimensions des colonnes et lignes avec un grid-template par exemple, la grille peut se permettre de modifier l'ordre d'apparition des éléments, et ce afin de privilégier ceux qui peuvent rentrer en premier dans les cases du template. Comportement qui peut être un poil déconcertant pour les non avertis...

Souvenez-vous : les Grids gèrent une répartition en 2 dimensions ! Contrairement aux flexboxs il n'y a pas d'axe principal !

Le saviez-vous ? Les propriétés justify-items et align-items peuvent aussi être utilisées sur les grids pour gérér l'alignement des éléments sur les axes verticaux et horizontaux, à la manière des Flexboxs !

Les Subgrids

Une propriété qui gagne à se faire connaître depuis quelques années ! (cf State of CSS 2023).

Admettons que vous ayez défini les colonnes principales de votre site (exactement comme nous venons de le voir tout au début avec les grid-template-areas). La hiérarchie HTML commence à grandir à force de rajouter du contenu.

Comment alors garantir que les balises n-ièmes sous-enfants sont correctement alignées sur nos colonnes définies à la racine du site, à l'image des Layout du Material Design 2 ?

C'est là que les subgrids interviennent ! Elles nous donnent la possibilité de se référer au template du parent direct (donc forcément, il faudra transmettre la subgrid à chaque niveau) :

main {
  grid-area: content; /* Attribution à la zone 'content' de la grille */

  display: grid;
  grid-template-columns: subgrid; /* <== Héritage du template de colonnes du parent ! */

  background-color: white;
}

Ce qui nous permet de retrouver les 3 colonnes de la partie "content" parfaitement alignées avec les colonnes du parent. Le graal 😎!

(Les zones violettes ont été ajoutées pour mettre en valeur les alignements)

Conclusion

Alors, les grids c'est has been ?

Comme nous avons pu le voir, si les grids ne sont pas dépréciées, c'est qu'il y a de bonnes raisons !

La Grid reste idéale pour définir des zones de base sur la page web, et garantir le même alignement 2D, inter-lignes ou inter-colonnes.

De son côté, la Flexbox est idéale pour définir plus simplement des alignements sur un seul axe ou partager l'espace disponible par rapport à un nombre variable d'éléments, et ce à un niveau plutôt secondaire, donc.

Au final, l'idée, c'est de savoir doser, comme une recette de cuisine :

des grids pour les fondations
quelques subgrids pour les sous-zones de la page
des flexboxs pour les alignements secondaires et/ou dynamiques
...et le tout saupoudré de media queries pour adapter les dimensions et nombre de colonnes en fonction du support

Plus d'excuses pour être responsives avec les bons outils ! 🙂

À quel niveau de qualité est votre code ?

Jean-Noël — Mon, 18 Mar 2024 13:00:41 +0000

Level up sur la qualité du code

Introduction

Vous êtes-vous déjà dit en regardant votre code "Je peux faire mieux !" ?

C'est normal. On peut toujours mieux faire.

Mais la vraie question est : jusqu'où aller ? Quel niveau de qualité faut-il donc atteindre pour les besoins du projet ?

À moins d'être vraiment (super) balèze, il faudra repasser plusieurs fois sur un même code pour atteindre un niveau satisfaisant.

À travers toutes mes expériences et tout un panel de langages, j'ai justement pu identifier cinq niveaux de qualité du code. Et croyez-moi, atteindre chacun de ces niveaux n'est jamais une évidence !

Level 1 : le code est fonctionnel

Est-ce qu'on commence par enfoncer une porte ouverte ? Sans aucun doute. Est-ce que ce niveau est systématiquement atteint ? Hélas, non.

La question n'est pas d'avoir un code qui peut ou ne peut pas s'exécuter, encore que dans certains langages comme le Python ou le Javascript, c'est souvent le grand suspens étant donné que l'exécution n'est pas garantie en amont par un compilateur au même titre qu'avec le Rust.

Je parle de répondre effectivement à la problématique de départ, à la specification fonctionnelle (quand elle a la chance d'exister 😬).

Il est vrai, cela nécessite d'avoir une chaîne de définition et développement de produit impeccable : bien identifier le besoin client, bien le traduire, bien le comprendre, et bien l'implémenter. Mais c'est un niveau hyper important à garder à l'esprit dans tous les choix techniques car il constitue l'unique valeur perceptible depuis l'extérieur du projet.

Pour l'anecdote : dans un de mes projets client d'IHM, l'équipe UX & Produit souhaitait que l'on rajoute un nouvelle stratégie de sauvegarde à travers le parcours utilisateur d'un Wizard, car ils avaient identifié un besoin. Sauf qu'en tant que développeurs nous savions que cette nouvelle stratégie était contradictoire avec les contraintes techniques existantes, et présentait même des failles fonctionnelles. Mais c'était pourtant l'objectif, ce qui était demandé et validé par l'équipe produit, et dans le Sprint actuel.

Alors qu'avons-nous fait ?

Totalement à l'improviste, j'ai proposé au responsable UX un petit brainstorming devant un tableau blanc pour présenter nos points de vue respectifs. Et ça a été la discussion la plus enrichissante et créative qu'on ait jamais eue. Ai-je réussi à démontrer que j'avais raison ? Spoiler alert : on avait tort tous les deux. Nos deux stratégies comportaient chacune des failles et si on en avait suivi une seule, on serait tombés systématiquement dans des comportements indéterminés.
Cela nous a permis de recréer une nouvelle spec juste impeccable.

Alors en amont, n'hésitez pas à poser des questions au Product Owner, à décortiquer les problèmes, à essayer de comprendre le pourquoi du comment. Plus vous serez informé et concerné par l'objectif, mieux vous l'implémenterez.

De même, lors de l'implémentation, vérifiez que le code répond bien au besoin et ce dans les conditions du client. Souvenez-vous que même si votre programme marche sur votre PC, ce n'est pas votre PC qui sera vendu au client.

Level 2 : le code est fiable

D'accord, le code répond maintenant au cas nominal. Mais est-ce vraiment le seul cas que l'on va rencontrer ?

D'expérience je peux d'ores et déjà vous répondre "non".

Déjà car la spec fonctionnelle recense rarement tous les cas d'usage du premier coup. Mais aussi (et surtout) car l'ajout de nouveau code introduit statistiquement de nouveaux bugs et comportements inattendus.

On repense aux fameuses dix lignes de code efficaces produites par jour et par développeur ("The Mythical Man Month" - Brooks). En tant que développeur, il faudra tester et corriger son code un bon nombre de fois afin de gérer correctement tous les cas d'erreurs possibles. Votre code doit être à l'épreuve des balles !

Tout d'abord il faut identifier les situations qui ne sont pas gérées dans le code : un champ qui pourrait être vide ? Une combinaison de valeurs qui donne lieu à une situation inattendue ? Un serveur qui ne répond plus ? La saturation de l'espace disque ?... Le code doit les gérer.

Pour s'aider, on devra aussi implémenter des tests End-to-End, tests unitaires et d'intégration. Ces phases de tests doivent être vues comme de véritables crash-tests : si vous rencontrez des erreurs, c'est gagné ! L'occasion de corriger une faille ! Souvenez-vous que des tests qui n'échouent jamais n'ont aucun intérêt.

Voir aussi le mutation testing.

Level 3 : le code est générique

Je pourrais écrire une flopée d'articles rien que sur ce niveau, car il regroupe en fait de nombreuses qualités en termes d'architecture ou de scalabilité (même si ce dernier aspect est plutôt propre aux projets web).

En fait l'idée de ce niveau est de pouvoir gérer un maximum de cas d'usage avec un minimum de code.
Il faut être capable de lire entre les lignes de l'énoncé, d'être visionnaire !

Dit autrement, demain on doit pouvoir ajouter facilement de nouvelles fonctionnalités avec moins de code que ce qu'il a fallu au départ à la création de l'architecture, voire sans ajouter de code du tout ✌️.

De nombreuses méthodes existent pour y parvenir, comme par exemple :

implémenter une architecture SOLID ;
ajouter des niveaux d'abstraction sur les objets ;
utiliser des templates ;
refactoriser les parties de code similaires en fonctions réutilisables ;
découper en petits modules indépendants plutôt que tout coder au même endroit ;
...

Avec un code générique, on balaie déjà la plus grande partie d'une dette technique qui pourrait nous retomber dessus dans un avenir souvent plus proche qu'on ne l'imagine.

Attention : piège, un code trop générique peut vite perdre en lisibilité si on ne fait pas attention ! C'est donc un équilibre à trouver.

Level 4 : le code est performant

Ici on parle de consommation de ressources matérielles et de rapidité d'exécution. Ce niveau peut parfois être facultatif, car les ressources de nos machines sont chaque jour un peu plus fournies, et bien souvent si un programme répond déjà au besoin initial, on ne se soucie des problèmes de performances que lorsqu'ils deviennent vraiment gênants.

Toutefois pour éviter d'être débordé à moyen terme, il vaut mieux rester consciencieux à chaque ligne de code que l'on écrit au fur et à mesure : chaque structure de donnée, chaque boucle, chaque requête réseau a une empreinte plus ou moins importante qu'il faut jauger.

Voici quelques généralités applicables dans une grande partie des langages :

évitez les copies inutiles de données en utilisant le système de références du langage ;
méfiez-vous des conteneurs à taille dynamique (par exemple, string), si possible, réservez une capacité en amont pour éviter les multiples réallocations et copies en interne à force de redimensionnement ;
placez toujours les conditions (if) qui ont le plus de chances de se produire en premier ;
si applicable, utilisez des fonctions asynchrones pour les opérations longues en attente afin d'éviter les blocages ;
spécifiez des types de variables adaptés au besoin (par exemple, un entier sur 64 bits n'est pas nécessaire pour des nombres allant de 0 à 10 000) ;
libérez la mémoire et les verrous (mutex) au plus tôt ;
réduisez les boucles de traitement successives sur une même liste de données en les regroupant en une seule ;
utilisez le mot-clé const car, dans la plupart des langages, il réduit drastiquement les instructions bas niveau générées derrière (assembleur ou autres) ;
regroupez les accès disques et les requêtes réseaux ;
...

Gardez aussi à l'esprit le classement général des goulots d'étranglement en termes de temps d'accès (du plus lent au plus rapide) :

accès réseaux ;
disque dur ;
SSD ;
RAM ;
caches CPU (L1-L2-L3) ;
registres CPU.

Bref, il y a vraiment de quoi faire sur ce sujet, et à défaut d'avoir besoin d'un code performant dans le projet, il faut avoir conscience de ces enjeux pendant la conception de l'architecture et l'écriture du code.

Plus de réflexion sur l'optimisation ici.

Level 5 : le code est... simple

J'en avais déjà parlé dans cet article en citant Léonard de Vinci, et ce n'est pas un hasard si cette qualité arrive en dernier : "La simplicité est la sophistication suprême".

Cela peut paraître contradictoire avec le "Level 3 : le code est générique", mais c'est là toute la difficulté de mise en place !

C'est un luxe qu'on ne se permet d'appliquer que trop rarement. Pourtant il s'inscrit aussi dans le cadre de la pérennité du code, et de la facilité à le maintenir, le relire dans le temps !

Cela implique un code explicite, concis, qui dans le meilleur des cas ne nécessite même pas de commentaires pour comprendre ce qu'il fait et pourquoi. Sur ce sujet je ne peux que vous conseiller le livre "Coder proprement" (Robert C. Martin).

Excellente nouvelle : dans la majorité des cas, plus le code est simple et plus il sera fiable et performant, car il réduit le nombre d'étapes et la complexité pour atteindre la même finalité. De quoi passer 3 Levels en 1 ! 😎

Conclusion

Vous l'aurez deviné : atteindre systématiquement les cinq niveaux de qualité de code est rare. D'autant plus que les priorités peuvent varier d'un projet à un autre, et que bien souvent tous les niveaux précédents ont tendance à empiéter sur la simplicité du code.

D'un côté, se soucier de cette simplicité le plus tôt possible apporte un retour sur investissement ultra rentable. Mais comme toujours, les délais de livraison obligent parfois à faire des compromis pour atteindre les objectifs en temps et en heure.

Malgré tout, ces niveaux restent un véritable défi d'amélioration continue et de perfectionnement pour réaliser des projets toujours plus impeccables. À la fois pour les développeurs, et pour le client final.

Et vous, quel niveau atteignez-vous ?

(Mention : toutes les images de cet article ont été générées avec Microsoft Copilot.)

L'ownership en Rust !

Jean-Noël — Wed, 15 Nov 2023 11:20:25 +0000

Introduction

On m'a souvent demandé :

"Parmi toutes les fonctionnalités de Rust, si tu devais en retenir une seule qui fait sa force, ce serait quoi ?"

Eh ben ce serait ça.

Aujourd'hui, je vais vous parler de ce concept clé du langage, et pas des moindres : ☄ L'Ownership ☄. Je vais ainsi vous montrer pourquoi Rust est un langage sûr pour la mémoire.

À celles et ceux qui veulent un résumé rapide pour découvrir le langage : Rust : ce langage natif safe et puissant

Principes fondamentaux de l'ownership

L'allocation mémoire dans un programme, c'est le nerf de la guerre. Une mauvaise gestion des allocations peut entraîner une surcharge de la RAM, des pointeurs zombies 🧟‍♂️,... bref, des trucs vraiment pas cool et qu'on a malheureusement trop rencontré avec des langages comme le C++.

Le but de l'Ownership, c'est justement de maintenir la mémoire propre : minimiser les duplications de données, éviter les comportements imprévisibles avec les opérations de lectures/écritures, et nettoyer rapidement les données inutilisées.

Alors, comment ça marche ?

Concrètement, toutes les allocations suivent les règles fondamentales suivantes :

Chaque allocation mémoire a un unique propriétaire
Seul le propriétaire (ou l'emprunteur dans certains cas) a les droits de modification
S'il n'y a plus de propriétaire, la mémoire est libérée

Ces règles sont appliquées sur l'ensemble de notre code, à chaque compilation ! Bien évidemment si une seule règle est enfreinte..., ça ne compile pas !

Notez que le concept de lifetime participe aussi activement à la protection mémoire, mais c'est un sujet à part entière que je ne traiterai pas dans cet article.

Sémantique de mouvement

Etant donné que les allocations n'ont pas toutes le même coût, le comportement du symbol = va être différent selon le type de variable.

Par exemple, sur l'affectation d'un entier, que l'on peut considérer comme une variable "simple" :

    let x = 5; // allocation à taille fixe
    let y = x; // l'affectation d'un entier déclenche une copie par défaut

    println!("x = {}", x); //OK

Jusque là, rien de bien nouveau. Mais si l'on essaye de faire la même chose avec un String, que l'on peut considérer comme une variable "complexe" :

    let s1 = String::from("hello"); // allocation à taille dynamique, s1 est propriétaire
    let s2 = s1; // s2 prend désormais l'ownership

    println!("{}, world!", s1); // erreur de compilation : s1 has moved!!

"Quoi ? quoi ? 😲"

Féliciations, vous venez de rencontrer la sémantique de mouvement en Rust ! 😀
Par défaut en Rust, les variables complexes (allocation dynamique, taille variable, structures,...) ne sont pas copiées. Il y a simplement un transfert de propriété !

Attention, cela n'a rien à voir avec les références implicites d'objets comme en Java ! Ici il n'y a pas de référence.

Autre exemple avec une fonction :

fn main() {
    let s1 = String::from("hello"); // allocation à taille variable, s1 est propriétaire
    my_func(s1); // s1 est transféré dans le scope my_func !

    println!("{}, world!", s1); // erreur de compilation : s1 has moved!!
}

fn my_func(s: String){
    println!("{}, world!", s); // s est le propriétaire de "hello"
}

La bonne pratique ici est donc de passer la valeur par référence immutable :

fn main() {
    let s1 = String::from("hello");
    my_func(&s1); // s1 est passé par référence immutable dans le scope my_func

    println!("{}, world!", s1); // OK : s1 est toujours propriétaire
}

fn my_func(s: &String){
    println!("{}, world!", s); // s est une référence immutable
}

Remarque : pour les structures légères, on peut aussi implémenter automatiquement les traits Clone et Copy. Mais cela risque de dupliquer inutilement les données, ce qu'on veut justement éviter ! À utiliser consciencieusement donc.

Avec cette référence immutable, on vient d'aborder une autre notion : l'emprunt (borrowing).

Les emprunts (borrowing)

En toute franchise, il est difficile de prévoir la réaction du compilateur et de son redoutable borrow checker sans une bonne expérience, mais on pourrait résumer les règles de borrowing comme suit :

S'il n'y a pas de référence mutable, il peut y avoir autant de références immutables que l'on souhaite sur une même variable.
Il ne peut y avoir qu'une seule référence mutable à la fois sur une même variable => et c'est ce concept qui nous protège de bien des erreurs en écriture concurrentielle ! Et directement à la compilation ! ✌

C'est là que les choses peuvent se compliquer un peu... mais c'est pour notre bien !

Observons quelques exemples :

    let mut s = String::from("hello");

    let r1 = &s; // référence immutable 1 : OK
    let r2 = &s; // référence immutable 2 : OK

    println!("{} and {}", r1, r2); // affiche "hello and hello"
    // variables r1 et r2 ne sont plus utilisées après ce point

    let r3 = &mut s; // 1 emprunt par référence mutable : no problemo
    *r3 += " world"; // modification de la String d'origine par déréférencement

    println!("{}", r3); // OK : affiche "hello world"

Mais si on modifiait juste la fin de cet exemple :

    let mut s = String::from("hello");
    // [...]

    let r3 = &mut s; // 1 emprunt par référence mutable : no problemo
    *r3 += " world";

    println!("{}", s); // erreur de compilation : "cannot borrow `s` as immutable because it is also borrowed as mutable"

    println!("{}", r3); // OK : affiche "hello world"

Impossible d'emprunter et printer s car il est potentiellement en cours de modification par r3 ! Et cela est vrai seulement car r3 est utilisé juste après dans le print.

Si on change alors simplement l'ordre des prints :

    let mut s = String::from("hello");
    // [...]

    let r3 = &mut s;
    *r3 += " world";
    println!("{}", r3); // OK : affiche "hello world"

    println!("{}", s); // OK : r3 ne peut plus être utilisé ici

Bingo ! le compilateur est rassuré 😎

Conclusion

On a vu comment étaient transmises les variables d'un contexte à un autre, et des exemples simples pour comprendre la puissance des vérifications d'ownership.

Au final, Rust révèle les erreurs potentielles à la compilation plutôt que nous laisser subir les conséquences à l'exécution, ce qui constitue une de ses plus grandes forces. Dites vous bien que si votre programme compile ~~enfin~~, c'est que votre code est sûr !

On pourrait passer des journées entières à tester d'autres cas, mais c'est justement l'expérience pratique qui permet de découvrir les différentes problématiques au fil du temps. Je vous invite donc à expérimenter par vous même le borrow checker sur le Rust Playground 😉

"...et sinon, qu'en est-il des accès concurrents dans du multithreading ?"

C'est un autre sujet très intéressant que nous aborderons sans doute une prochaine fois, et vous verrez qu'avec des outils comme les Mutex<T> et Arc<T>, on peut aussi venir efficacement à bout de ces problématiques ! Affaire à suivre...

Javascript: on clone des robots !

Jean-Noël — Wed, 12 Apr 2023 15:02:11 +0000

Introduction

Le Javascript est un langage souple qui peut paraître facile au premier abord. Mais je vous le dis : en réalité, il recèle de subtilités qui peuvent rapidement mettre le bazar si on ne les maîtrise pas !

Une de ces subtilités dont on va parler aujourd'hui, c'est le clonage d'objets. Et pour changer un peu des moutons, on va cloner des objets robots (n'en déplaise à Will Smith, alias Del Spooner) ! C'est parti !

Le clonage naïf

Partons du principe que l'on dispose d'une instance d'un premier prototype de robot, et que l'on veuille alors le cloner dans une production. Ici, on représentera une production par un tableau production contenant nos robots :

(Notez que pour aider à modéliser le problème, j'utiliserai du Typescript)

Résultat de la console:

------- Production check -------
robot 1 = {id: 10, isConform: true}
robot 2 = {id: 10, isConform: true}
robot 3 = {id: 10, isConform: true}
robot 4 = {id: 10, isConform: true}
...

Quoi ?! Mais ils ont tous les mêmes identifiants ! 😱

Si vous le souhaitez, vous pouvez vous exercer à débugger le code ci-dessus en ajoutant du code et des logs.

Et en effet, il y a bien un problème dans cette production : en JS, l'opérateur = n'effectue Pas de copie d'un objet ou d'un array à proprement parler, mais uniquement de la référence de cet objet en question.

Ainsi, const newRobot = robotProto; ne crée pas un nouvel objet mais référence le robot proto. A chaque tour de boucle.

Du coup, sans le savoir, on a toujours affecté le même objet dans toutes les cases du tableau, et par conséquent modifié le même objet à chaque itération. Au final, on se retrouve évidemment avec la dernière valeur enregistrée : 10.

Cette explication est d'ailleurs vérifiable avec l'opérateur de comparaison === :

// 2 contenus identiques mais dans des objets différents
const robot1 = { id: 0, isConform: true };
const robot2 = { id: 0, isConform: true };
console.log(robot1 === robot2); // false => pas les mêmes objets

//...et si on revient à notre production râtée
console.log(production[0] === production[9]); // true => c'est le même objet !

Bon, comment corriger cette production ?

Nouvel objet et spread operator

Une solution consiste à utiliser le spread operator. Combiné aux accolades {} pour déclarer un nouvel objet, le spread operator ... permet de copier tous les champs de l'objet robotProto. Très efficace si l'on a un paquet de champs à copier d'un coup !

Résultat de la console :

------- Production check -------
robot 1 = {id: 1, isConform: true}
robot 2 = {id: 2, isConform: true}
robot 3 = {id: 3, isConform: true}
robot 4 = {id: 4, isConform: true}
...

Aah c'est mieux !

Dans notre cas, cette solution minimaliste convient parfaitement !

Sauf que cette technique a des limites... En effet, le spread operator souffre du même défaut que l'opérateur = : il ne clone pas réellement les champs qui sont de type objets et arrays 😟

Ainsi, si l'on enrichit la structure de données avec des objets à plusieurs niveaux, on retombe sur le problème des références aux niveaux plus profonds :

interface Robot {
  id: number;
  isConform: boolean;
  head: {
    eyesColor: string;
  };
  body: {
    material: string;
  };
}

const complexRobot: Robot = {
  id: 0,
  isConform: true,
  head: {
    eyesColor: 'blue'
  };
  body: {
    material: 'carbon'
  };
};

const badClone = {...complexRobot};

console.log(badClone.head === complexRobot.head);//true => on a encore le même objet

La méthode stringify

Une solution consiste à transformer un objet en string, puis le re-parser successivement :

const newRobot = JSON.parse(JSON.stringify(complexRobot));

Cela peut paraître empirique, je vous l'accorde. Pourtant dans beaucoup de cas, c'est le meilleur équilibre entre fiabilité et rapidité d'exécution dans la catégorie du clonage en profondeur.

Gros warning cependant : du fait de la transformation intermédiaire en string, les types correctement pris en charge sont très limités. Les fonctions par exemple seront tout simplement perdues !

structuredClone

La fonction structuredClone est une nouveauté supportée par tous les principaux navigateurs depuis début 2022. Elle permet de cloner automatiquement et en profondeur tout le contenu d'un objet :

const newRobot = structuredClone(complexRobot);

L'avantage par rapport au JSON.stringify, c'est qu'elle prend en charge plus d'objets spéciaux comme les Date, RegExp ou Set, mais toujours pas de prise en charge de types spéciaux comme les fonctions. Voir ici la liste exhaustive des types supportés.

Toute puissance ayant un coût, c'est également la méthode standard la plus lente à exécuter pour le clonage.

L'historique Object.assign

Parce qu'il faut respecter les anciens 😄, je terminerai cette liste en évoquant Object.assign.

Très similaire au spread operator, il a l'avantage de pouvoir modifier un objet déjà instancié tout en se conformant au type d'origine et à ses méthodes lorsque c'est une classe. Personnellement, je trouve qu'avec le Typescript cette méthode a moins de cas d'usage, car on va utiliser des types (comme l'interface) qui vont déjà nous aider à garantir la conformité d'une structure de données avec ses attributs et ses fonctions.

// usage basique dans notre cas
const newRobot = Object.assign({}, complexRobot);

Mais tout comme le spread operator, il ne clone qu'au premier niveau, et ne copie que les références des objets et arrays.

Conclusion

De manière générale, il ne faut cloner que s'il y a un réel besoin. Si par défaut le clonage des objets et arrays n'est pas automatique, c'est qu'il y a une raison : l'optimisation.

Mais dans le cas où le clonage est nécessaire, il vaut mieux choisir :

le spread operator pour une copie à un seul niveau (sans objets ou arrays)
l'Object.assign pour une assignation à un seul niveau (sans objets ou arrays) plutôt pour des classes
le JSON parse/stringify pour une copie en profondeur rapide (mais sans objets spéciaux)
le structuredClone pour une copie en profondeur plus complète mais plus lente

Et si aucune de ces méthodes standard n'est satisfaisante, je vous invite à chercher du côté d'une librairie comme lodash, ou à implémenter votre propre méthode de clonage adaptée à votre cas d'usage !

Comme toujours, il faut s'adapter à chaque situation...

Rust : l'héritage n'existe pas !

Jean-Noël — Fri, 21 Oct 2022 08:32:13 +0000

Rust : l'héritage n'existe pas

Après avoir vu le dernier opus de la saga The Matrix, j'ai été pris d'une envie de revenir aux sources. Alors, ici, il ne sera pas question de critique de film, mais de revenir sur un sujet technique essentiel qu'est l'héritage.

Tenez, Rust par exemple. Un langage natif, certes, mais moderne (article découverte ici). Eh bien ! il faut faire éclater une vérité, Néo : en Rust, l'héritage n'existe pas !

Alors dans ce cas, comment transmettre des fonctions ou des propriétés qui sont communes à de multiples structures de données, ou encore imposer un pattern de fonctionnalités ? Bref, ce qu'on a toujours fait avec les classes abstraites en C++, par exemple ?

Si vous aussi vous vous êtes déjà posé ces questions, alors suivez le lapin blanc...

Note : tous les extraits de code ci-après sont testables sur le Playground Rust.

Pas d'héritage : pourquoi ?

Soyons clair, l'héritage est un concept essentiel de la programmation orientée objet (OOP en anglais), ce que Rust n'est pas.

Rust est un langage C-like où les "classes" sont avant tout des structures de données, et pas nécessairement des fonctionnalités. C'est aussi un langage qui se veut explicite. En C++, à travers plusieurs héritages successifs, on a tendance à perdre cet aspect.

En Rust, on est incité à coder des petits modules indépendants et génériques.

Bien entendu, Rust n'est pas en reste (haha) pour autant. Il a été pourvu d'un minimum vital pour gérer un certain niveau d'abstraction. Il y a principalement 2 solutions qui s'offrent à vous : les traits et les compositions.

Pilule rouge : les traits

Un trait est l'équivalence d'une interface en Java : on impose l'implémentation d'une liste de fonctions.

Prenons l'exemple des 3 grands agents du film : Smith, Jones et Brown (si vous ne connaissiez pas les 2 derniers noms, c'est cadeau !). Ils font initialement tous partie d'une même faction : les agents. Un agent, quel qu'il soit, doit être en mesure de repérer et d'éliminer les anomalies de la Matrice.

Si on devait les modéliser avec des struct on pourrait donc imposer la compétence eliminer_anomalies de cette manière :



// Trait générique
trait Agent {
    fn eliminer_anomalies(&self);
}

// Différentes "classes"
struct Smith {}
struct Jones {}
struct Brown {}

// Implémentations des traits
impl Agent for Smith {
    fn eliminer_anomalies(&self){
        println!("Smith doit éliminer anomalies")
    }
}

impl Agent for Jones {
    fn eliminer_anomalies(&self){
        println!("Jones doit éliminer anomalies")
    }
}

impl Agent for Brown {
    fn eliminer_anomalies(&self){
        println!("Brown doit éliminer anomalies")
    }
}

fn main() {
    let agent_smith = Smith {};
    let agent_jones = Jones {};
    let agent_brown = Brown {};

    agent_smith.eliminer_anomalies(); // "Smith doit éliminer anomalies"
    agent_jones.eliminer_anomalies(); // "Jones doit éliminer anomalies"
    agent_brown.eliminer_anomalies(); // "Brown doit éliminer anomalies"
}

Voilà nos 3 agents opérationnels !

Pour information, on peut voir les traits en Rust un peu comme des traits de caractère d'un personnage : une structure peut également implémenter autant de traits que nécessaire.

Pilule bleue : les compositions

Autre solution à préférer si vous avez besoin de transmettre des propriétés (et des fonctions par la même occasion) : composer les structures entre elles. C'est ce qui se rapproche le plus d'un "héritage" de propriétés.

Plaçons nous cette fois-ci du côté des êtres humains. Ils ont chacun un nom et peuvent évoluer au sein de la Matrice. Puis il y a les humains libérés qui en plus ont la capacité de sortir de la Matrice comme bon leur semble. Et pour finir, il y a l'élu : il dispose de toutes les capacités précédentes, et en plus il sait voler (le veinard !).

On pourrait donc imaginer une modélisation de ces classes de personnes comme suit :



struct Humain {
    nom: String
}

impl Humain {
    fn evoluer_dans_matrice(&self){
        println!("Dans la matrice...")
    }
}

struct Libere {
    humain: Humain
}

impl Libere {
    fn sortir_de_la_matrice(&self){
        println!("Hors de la matrice...")
    }
}

struct Elu {
    libere: Libere,
}

impl Elu {
    // (constructeur pour gagner en lisibilité)
    fn new() -> Self {
        Elu {
            libere: Libere {
                humain: Humain { nom: String::from("Néo") }
            }
        }
    }

    fn voler(&self){
        println!("Vole dans les airs !")
    }
}

fn main() {
    let elu = Elu::new();

    println!("Nom de l'élu: {}", elu.libere.humain.nom); // "Nom de l'élu: Néo"
    elu.libere.sortir_de_la_matrice(); // "Hors de la matrice..."
    elu.libere.humain.evoluer_dans_matrice(); // "Dans la matrice..."
    elu.voler(); // "Vole dans les airs !"
}

Ainsi, Néo hérite bien de toutes les compétences et propriétés en tant qu'élu et humain libéré. Evidemment d'un point de vue modélisation UML, l'élu devrait être une instance unique, mais ce n'est pas le sujet ici.

Petit inconvénient : la composition n'impose pas l'implémentation de fonctions. Pour ça, il faut compléter avec les traits.

Vous l'aurez compris, il y a un autre inconvénient bien plus visible : le code est bien explicite, mais il faut traverser toute la hiérarchie manuellement pour accéder aux propriétés les plus hautes. Pas toujours folichon.

En réalité, il existe une astuce lorsque la profondeur de données devient trop grande...

Ptit verre d'eau pour faire passer : Deref

Le trait std::ops::Deref sert à la base à surcharger le déréférencement des pointeurs, et il est conseillé de plutôt les utiliser sur les smart pointers.

Mais ici nous allons l'utiliser pour simplifier l'accès à nos variables, en ajoutant :



use std::ops::Deref;

// ...

impl Deref for Libere {
    type Target = Humain;
    fn deref(&self) -> &Humain {
        &self.humain
    }
}

impl Deref for Elu {
    type Target = Libere;
    fn deref(&self) -> &Libere {
        &self.libere
    }
}

Nous pouvons alors changer notre main :



fn main() {
    println!("Nom de l'élu: {}", elu.nom); // "Nom de l'élu: Néo"
    elu.sortir_de_la_matrice(); // "Hors de la matrice..."
    elu.evoluer_dans_matrice(); // "Dans la matrice..."
    elu.voler(); // "Vole dans les airs !"
}

Et hop, un accès direct !

Si besoin, il faudra aussi implémenter le trait std::ops::DerefMut pour obtenir un accès mutable à ces éléments. Rappelez vous : par défaut, tout est immuable en Rust.

Toutefois, retenez bien que c'est plus un hack utilitaire. À utiliser avec modération donc.

Conclusion

L'héritage en Rust est un sujet qui revient régulièrement dans les discussions et les demandes d'évolution du langage. Mais bien que Rust ne soit pas un langage fondamentalement orienté objet, il dispose tout de même de fonctionnalités suffisantes pour gérer les abstractions. C'est aussi un coup à prendre ! Une autre façon de coder.

En résumé, privilégiez une déclaration explicite avec des traits pour des fonctions virtuelles, et passez plutôt par des compositions de struct pour transmettre des propriétés.

One More thing

Pour votre curiosité, il existe un crate (comprenez module) intitulé inheritance en version alpha. Il propose des macros pour implémenter automatiquement des traits sans avoir besoin de les réécrire dans toute la hiérarchie. Mais qui est seulement resté au stade expérimental...