Mon calendrier de l’avent – cases 1 à 6
Puisque c’est la saison, et puisque j’ai envie de relancer ce blog, je vais me lancer dans l’exercice traditionnel du calendrier de l’avent. Mais comme vous êtes sur mon blog, je vais y mettre … ce que je veux. On pourrait donc parler de « calendrier de l’avent des trucs qui m’intéressent », mais franchement, ça n’est pas un nom idéal.
En vrai professionnel, je démarre évidement en retard. Mais promis, je vous rattrape avec une livraison qui rattrape les six premiers jours de ce mois, avec donc six outils.
- Evidement, je ne peux pas commencer sans parler de structurizr, que j’utilise encore en ce moment pour un audit. C’est extrêmement pratique pour un développeur d’être capable de documenter une architecture et de créer des diagrammes lisibles (a défaut d’être beau) à partir d’un seul fichier de configuration. Notez qu’il existe une image Docker permettant d’éditer ce fichier – certes sans WYSIWYG, mais avec un rendu intéressant – et qu’on plus vous pouvez l’étendre avec des scripts … (je mentionne cette possibilité par honnêteté intellectuelle, parce que dans ce cas, j’utilise aadarchi)
- Puisque je parle d’aadarchi, pour construire une doc d’architecture basée sur le système réel, j’utilise toujours dans ce cas Retrofit pour créer des clients d’api divers (le dernier est un client make automation). Si vous utilisez Spring ou Quarkus, vous avez des clients HTTP utilisant les mêmes concepts de génération de proxy – donc n’ajoutez pas Retrofit dans votre système (contrairement à ce que j’écrivais il y a quelques années). Dans tous les autres cas, c’est sans doute la solution la moins pénible à ajouter.
- Pour enchaîner sur le HTTP, il arrive aussi que vous ayez besoin de récupérer des ressources distantes pour les copier localement, avec du HTTP, du FTP, que sais-je encore. Et je m’étonne que cette librairie, incroyable utile dans tout un tas de cas, ne soit pas dans la boîte à outils de tous les développeurs. Il s’agit bien sûr de commons-vfs, dont j’ai déjà parlé … il y a douze ans. C’est le genre de projets pour lesquels je suis vraiment reconnaissant : il résout des problèmes incroyablement pénibles en fournissant une abstraction propre et utilisable sans frontières.
- On continue dans le HTTP ? D’accord, mais cette fois-ci on sort du Java pour rentrer dans VSCode, l’éditeur ubiquitaire. Je vois des tonnes de développeurs utiliser Postman, Bruno ou l’une des innombrables alternatives. Personnellement, je trouve que ces outils masquent un peu trop la requête HTTP. C’est pour a que j’utilise aussi souvent que possible VSCode Rest Client, une extension bien commode qui vous permet d’écrire vos requêtes dans un éditeur de texte, et de les exécuter facilement … Bon, si vous devez faire une authentification OpenId Connect, ce sera un peu plus fastidieux, mais faisable.
- Et puisqu’on parle de développement Java, je devrais vous parler de JUnit, mais tout le monde connaît. A la place, je préfère parler d’assertj. Alors c’est vrai que Java a un mot-clé
assert (totalement inutile, contrairement a celui de Groovy). Et c’est vrai que JUnit dispose d’assertions depuis toujours. Mais depuis toujours, les assertions de JUnit sont … peu pratiques à utiliser. Le premier projet ayant à ma connaissance tenté d’améliorer ca était hamcrest, qui reposait sur les imports statiques pour rendre l’écriture fluente. Je m’en suis même servi dans gaedo. Mais je trouve avec le temps que ces imports statiques sont une fausse bonne idée, puisqu’ils ne facilitent en fait pas l’identification de la classe contribuant la méthode. Assertj, en exploitant mieux le polymorphisme, évite ce problème. En plus, AssertJ fournit un ensemble de méthodes d’extraction de valeurs qui permet bien de séparer le code métier de la manipulation des objets dans le test … Et des SoftAssertions pour valider plusieurs propriétés d’un objet en même temps … Et tout un tas de choses bien pratiques. - Pour ma fête, je vais vous parler du summum du graphisme pour moi : Kroki. Il faut bien comprendre que, même si je suis un amateur de musées, je suis loin d’apprécier le dessin de schémas, diagrammes et autres. Et surtout, j’ai tendance à rappeler dès que je le peux que positionner les éléments d’un diagramme sur un canevas est un problème NP-complet. Donc, je préfère écrire du diagram as code, c’est-à-dire donner à un outil la définition de mon diagramme pour le laisser dessiner. Les deux logiciels les plus populaires pour ça sont Mermaid et PlantUML. Comment choisir ? Eh bien avec Kroki, vous ne choisissez pas, puisqu’il supporte les deux … et en fait bien plus que ces deux-la. Il y a même certains outils qui sont vraiment incroyables (comme Vega ou Pikchr – pour les cas où vous savez quelle allure doit avoir votre diagramme). En plus Kroki est disponible dans une image Docker (pour éviter d’envoyer votre architecture sur Internet) et il y a une extension asciidoc !
#informatique #librairie #noel