# Les nouveaux outils en ligne de commande
par Xavier Calland
Il y a quelques semaines, Julia Evans (on a déjà partagé ses questionnaires sur l’informatique, ce qui me fait penser qu’il faudra que je parle de wizardzines un jour) a lancé un appel sur Twitter pour faire un petit recensement des nouveaux outils en ligne de commande.
Le résultat ? un résumé des réponses organisé en 2 catégories :
- des outils pour remplacer les standards : des versions améliorés de grep, cat, fd, etc
- des inventions
De quoi perdre investir quelques heures à tester tout ça et, qui sait, peut-être trouver le petit truc qui simplifie la vie.
De mon côté je connaissais et utilisais déjà (j’en profite pour en parler) :
- delta : coloration syntaxique et pager pour git, diff, et grep output
- bat : clone de cat avec pagination, coloration syntaxique, intégration git et bien d’autres choses encore
- tig : une interface en mode texte pour git
- httpie : client HTTP user-friendly
Mon coup de cœur (lui je l’ai découvert) : fuck qui se propose de corriger les commandes saisies précédemment dans un terminal. Le principe est simple, après une commande erronée, taper « fuck » pour qu’il suggère des versions corrigées.
Par exemple :
- « apt-get install » → « sudo apt-get install »
- « git brnch » → « git branch »
- « code. » → « code . »
# React 18 (la définitive cette fois ci par une RC)
par Mathieu Petit
Quelques heures après notre publication du dernier bot, la version 18 de React est sortie. Nous avons donc de nouveau l’auto-batching, les transitions,des nouvelles fonctionnalités sur les suspense, des ajouts sur l’api des rendu, quelques nouveaux hooks.
# Keycloak en version 18.0.0 est disponible depuis le 20 Avril 2022
par Laurent Meunier
Cette nouvelle version 18.0.0 est la suite logique de la version 17 dont le principal changement concernait le remplacement de Wildfly par Quarkus. Ainsi, la déclinaison Quarkus reçoit quelques évolutions intéressantes comme l’import de realms au démarrage, l’amélioration des logs, et l’utilisation de variables d’environnement dans le fichier de configuration.
Plusieurs nouveautés sont également présentes en mode preview dans cette nouvelle version : une nouvelle console d’administration (qui devrait devenir la console par défaut avec la prochaine version), un nouvel Operator Kubernetes, la rotation des secrets et l’utilisation de codes de secours comme 2nd facteur d’authentification.
Au niveau authentication, Keycloak permet maintenant de gérer le “Step-up authentication”. Cette fonctionnalité permet de demander une réauthentification avec un niveau de d’assurance plus élevé pour certaines actions (par exemple : une authentification à deux facteurs est nécessaire pour accéder à une interface d’administration).
Autre nouveauté intéressante : la limitation du nombre de sessions par utilisateur.
# Architectures web : everything old is new again
par Thomas Broyer
Le 29 mars (le jour où nous publiions le précédent BOT), ThoughtWorks publiait le nouveau volume semestriel de son Technology Radar, avec une entrée notable : alerter sur l’utilisation de Single Page Applications (SPA) par défaut plutôt que par choix éclairé d’architecture après avoir pesé les avantages et inconvénients et l’adéquation avec les besoins métiers.
Étonnamment, Shopify a pris ce chemin justement avec son framework Hydrogen annoncé en novembre dernier, basé sur React et ses React Server Components (toujours expérimentaux), et générant donc des SPA. Pourtant un site e-commerce ne réclame pas d’être une SPA : les plus grands sites de e-commerce tels qu’Amazon, eBay, CDiscount ou Rue du Commerce n’en sont pas (mais incidemment pas des PWA non plus 🤷) ; et le site starter de npx create-hydrogen-app ne fonctionne pas du tout sans JavaScript côté client par exemple, avec essentiellement une page blanche.
Tailor Hunt, qui travaille sur le site de e-commerce des magasins Kroger aux États-Unis, a commencé une série d’articles sur sa réécriture du site (une démo seulement, pour le moment), actuellement en React (CDiscount s’est d’ailleurs battu avec React pour obtenir des performances satisfaisantes), pour le rendre plus rapide : il est donc parti sur une Multi-Page Application (MPA) et décrit les challenges de performance (spoiler: everything old is new again). La quatrième partie détaille notamment tout ce que les SPA requièrent de la part des développeurs pour finalement réimplémenter des comportements natifs des navigateurs avec les MPAs, et d’autres inconvénients propres aux SPA : sécurité, accessibilité (d’ailleurs également un problème avec Hotwire, pourtant mis en avant par ThoughtWorks), performance, stabilité/résilience.
Pendant des années, le choix de faire des SPA a probablement été guidé par l’expérience de développement, mais le vent semble être en train de tourner, avec des petits nouveaux comme Astro avec son approche orientée island architecture (et qui a d’ailleurs annoncé début avril un support expérimental pour le rendu côté serveur, mais pour le moment sans streaming de la réponse), ou des anciens mais restés longtemps confidentiels comme Marko (né chez eBay d’ailleurs), et bien d’autres, qui permettent de créer facilement des MPA sans (trop de) compromis sur l’expérience de développement ; une approche MPA qui ne remet d’ailleurs pas en question la possibilité de créer une PWA avec échanges réseaux minimes, et fonctionnant hors ligne.
# Rome – Yet another formatting tool
Par Alexandre Nicolas
Depuis 1 an, Rome s’est lancé dans la lourde tâche de réécrire ses outils en Rust. Début Avril, un premier outil basé sur cette réécriture est enfin disponible : leur formateur.
Ce dernier a pour volonté de s’appuyer au maximum sur le style du bien connu Prettier, tout en apportant son lot d’améliorations. On notera donc
- Une performance accrue, entre 9 et 12 fois plus rapide !
- Une meilleure gestion des erreurs syntaxiques, aka mon code ne ressemblera pas à un tableau de Jackson Pollock si une erreur de syntaxe est présente en plein milieu de mon code.
Le revers de la médaille est qu’actuellement seuls Javascript et Typescript sont supportés et que les options de formatage sont très limitées : tab vs spaces, line-width et tab-width.
Le support d’autres langages est prévu (JSX, HTML, CSS, …), ainsi que la refonte d’autres outils (linter, bundler, …)
Le début semble en tout cas prometteur, à suivre donc !
# Docker sbom
par Xavier Calland
La qualité et la sécurité logicielle sont des enjeux importants dans le développement de solutions logicielles.
On le voit régulièrement avec les failles découvertes dans des bibliothèques (Log4j2 en fin d’année ou Spring ces dernières semaines), la maîtrise des composants fournis et l’analyse des éventuelles failles répertoriées sur ces composants sont des aspects importants à prendre compte qui s’intègre dans cette approche de sécurité logicielle. Cela permet notamment de réagir rapidement et de manière adaptée.
Une approche pour cela est d’utiliser des SBOM pour lister les dépendances d’une application et vérifier si des failles sont répertoriées pour ces dépendances.
À Atol c’est ce que nous utilisons :
- CycloneDX génère le SBOM de l’application (via des plugins dans les outils de build : gradle, maven, composer, npm, etc)
- Dependency-track s’occupe de l’analyse vis-à-vis des bases de vulnérabilités connues (NVD, GitHub Advisory, etc)
Avec Docker les choses se compliquent un peu. Le livrable n’est plus seulement l’application et des dépendances (par exemple le code java et d’autres jars), on embarque en plus les composants systèmes (la JVM et même tout un OS).
Construire un SBOM des dépendances applicatives n’est pas suffisant, il faut également prendre en compte les composants système.
C’est là que le plugin Docker SBOM prend tout son sens. Disponible depuis peu, ce plugin permet de produire un SBOM correspondant à une image en utilisant Syft, SBOM qu’on pourra intégrer dans Dependency-track et ainsi suivre les failles des composants système au même titre que les dépendances applicatives.
Justin Cormack nous en dit plus sur ce plugin qui est pour le moment en version expérimentale.
Laisser un commentaire