Blog

03 July 2019

Meetup des Devs de l'Est Parisien - Session #2

Résumé de la session #2 du meetup des Devs de l'Est Parisien

Un article écrit par Nicolas Martignole

La 2ème session du Meetup des Devs de l'Est Parisien a eu lieu le mercredi 3 juillet dans les locaux de Lunatech. Voici un résumé de la soirée, et des présentations. Avant toute chose : la prochaine soirée aura lieu le mardi 17 septembre, avec comme invité : Rémi Forax. Vous trouverez les informations pratiques sur la page du Meetup.

Au programme de la soirée :

  1. Présentation du projet STAMP par Caroline Landry, de l'INRIA
  2. Docker en 10 minutes par Julien Furgerot, de SFEIR
  3. Akka-HTTP par Vladimir Bodnartchouk, de Lunatech
  4. Les Architectures "-illities" en 10 mn par Nicolas Martignole de Lunatech

Nous avons alterné des sujets longs de 40mn avec 2 petits sujets de 10/15mn, ce qui permettait de voir différents thèmes.

Le projet STAMP, Caroline Landry

Caroline Landry a présenté le projet STAMP (Software testing amplification), projet Européen qui vise à développer plusieurs outils open-source, dans le but d'améliorer la qualité du code. Le postulat de départ est intéressant : nous écrivons tous des tests unitaires ou d'intégration sur nos projets. Prenez par exemple une librairie Java comme Apache commons-collections, que vous avez certainement utilisé. La librairie a 23 713 lignes de codes et 27 919 lignes de tests. Il y a plus de code pour tester, que pour la librairie elle-même. Or, comme le dit Carolin, qui teste le code des tests ? Qui s'assure qu'il couvre le code, et que surtout, il teste réellement le code ?

Après avoir rappelé le cycle classique de développement d'un logiciel, elle présente la boucle d'intégration continue. Le projet STAMP s'intègre dans ce cadre, et elle traitera ce soir des projets liés aux tests unitaires, à la configuration Docker, et aussi à la modification d'instance à l'exécution.

Le projet Descartes est une librairie open-source Java, basée sur le projet pitest.org. Pitest permet d'introduire des tests de mutation. Qu'est-ce que le mutation testing? Des mutations sont introduites sur le bytecode, puis votre suite de tests unitaires est exécutée. Si vos tests qui passaient, continuent à passer, alors c'est que la mutation n'a pas été découverte par le test unitaire. A contrario, si le test se met à échouer, c'est que votre test unitaire... teste réellement et correctement la fonction.

La qualité des tests unitaire peut alors être mesurée par le pourcentage de mutations tuées. Cela complémente la couverture de tests, et surtout, montre que les tests... servent à quelque chose. L'objet des tests de mutation du code original est donc de s'assurer que les tests unitaires détectent réellement quelque chose.

Descartes par rapport à pitest va plus loin, en introduisant l'extreme mutation testing. C'est assez simple à comprendre. Prenez une méthode et une suite de tests unitaires associés. Imaginez que vous vidiez complètement le corps de la méthode, afin de ne garder que le retour. Quel est le comportement de vos tests ? Si certains continuent à passer, est-ce qu'ils testent correctement ? Peut-être qu'ils ne sont plus à jour, et qu'il faut les effacer...

Caroline présente ensuite le projet dspot, qui permet de générer des assertions JUnit manquantes (Junit 3 à 5 supportés), à partir de votre code source. C'est un outil qui permet d'amplifier et d'améliorer le nombre d'assertion dans votre code, en inspectant et en générant des assertions. Le projet va même jusqu'à proposer un outil pour créer automatiquement des Issues Gitlab, ce qui permet de proposer de nouveaux tests, à des projets open-source.

Nous découvrons ensuite d'autres outils, pour générer par exemple des mutations d'images Docker. L'outil est capable de générer différentes combinaisons de dépendances docker (telle version de pgSQL et telle version de tomcat avec telle version du JDK par exemple). L'idée étant de découvrir de nouveaux bugs. Le meilleur exemple d'application est le projet XWiki. Nous vous recommandons aussi la présentation TestContainer de Vincent Massol, donnée à la conférence Devoxx France 2019.

Pour terminer, nous avons aussi vu rapidement la présentation du projet botsing basé sur EvoCrash. Le principe ici, en partant d'une stack-trace Java en production, est de générer une suite de tests JUnit à même de reproduire le crash. Pour cela, l'outil utilise un moteur d'analyse du byte-code. A quoi cela peut-il bien servir ? Et bien cela permet, comme lorsque vous debuger pas-à-pas, de recréer les conditions qui ont conduit à la levée de cette exception. Ceci permet ensuite de parcourir la stack-trace, et vise à aider le développeur à résoudre son bug. C'est ce que l'on appelle du "search-based crash reproduction" ou de la recherche de bug par reproduction de crash. Vous trouverez un exemple sur la page du projet Botsing.

Après toutes ces présentations, nous avons pu aussi poser quelques questions et échanger avec Caroline Landry. Le projet STAMP est un projet Européen, fruit du partenariat entre l'industrie et les Universités. Nous vous invitons à le découvrir et nous remercions Caroline pour sa présentation. Vous pouvez aussi retrouver la présentation sur le channel YouTube de Devoxx France 2019.

Introduction à Docker en 10 minutes, Julien Furgerot

10 slides, et 10 minutes : c'est ce que Julien Furgerot, de SFEIR, a réussi à faire. Le principe des containers, la construction d'une image Docker, l'isolation, la composition avec Docker compose et le déploiement avec Docker Swarm. Au passage, signalons l'initiative de SFEIR (coucou Didier) qui organise des formations gratuites dans leurs locaux chaque mois. La SFEIR School permet de se former pendant une journée ou deux, sur des thèmes comme Docker, Kubernetes, les technologies Google.

Akka-HTTP par Vladimir Bodnartchouk

Après une pause Pizza - Bières*/Soft, nous reprenons pour écouter Vladimir Bodnartchouk, CTO de Lunatech France, qui présente Akka-HTTP. Le projet Akka-HTTP tire ses origines du projet Spray en 2011. Serveur HTTP léger, basé sur le framework d'acteurs Akka, Akka-HTTP propose aussi un DSL pour construire rapidement et simplement vos backends Java ou Scala. La cible visée est plus particulièrement la construction de services Webs avec API type REST, ou alors le développement de backend, lorsque le front-end est fait avec du React, du Vue.JS ou tout autre technologie côté Front. Si vous recherchez un framework plus complet, il est plus judicieux de se tourner vers Play Framework. Au passage, Vladimir rappelle que Play est lui-même basé sur Akka-HTTP depuis la version 2.7.

Après une présentation des principes des Actors, nous découvrons le DSL et plus particulièrement, la façon de construire des routes avec Akka-HTTP. La présentation s'appuie sur l'API Scala, plus facile à lire et moins verbeuse que l'API Java. Cependant, les 2 langages sont supportés nativement par la librairie.

D'ailleurs, Akka-HTTP est plus une librairie, qu'un framework. Vous pouvez combiner des routes, transformer des objets en JSOn et inversement, streamer le contenu d'un fichier vers un autre serveur, interagir en tant que Web client avec d'autres API Webs, le tout en assemblant des briques facilement. Le point fort d'Akka-HTTP, en dehors de sa simplicité, est sa capacité à gérer la notion de "Back pressure". C'est la capacité pour un système à informer l'émetteur d'une donnée, qu'il doit ralentir et envoyer moins rapidement ses données. Akka-HTTP peut ainsi exposer un Stream de données, mais ne déclencher l'envoi que lorsque le client acquitte et valide qu'il a bien lu la data. Ce principe permet par exemple d'éviter de charger en mémoire un fichier, si le client (disons un téléphone mobile) n'arrive pas à lire assez rapidement. Tout ce système de coordination et de streaming est géré par Akka-HTTP.

Les Architectures "-illities" en 10 minutes, Nicolas Martignole

Enfin pour terminer, nous vous avons proposé une petite présentation en 10 minutes des "Architectures -illities". Vous en connaissez certainement quelques unes : Scalability, Auditability, Reusiability... Il s'agit de l'ensemble des spécifications non-fonctionnelles d'un système. La présentation tire son origine d'un article de 2005 du Touilleur Express.

Mettons-nous à la place d'un développeur qui doit construire une application de gestion pour son client. Classiquement, le client va faire son expression de besoins fonctionnels. "....L'application doit exposer des contrats d'assurance vie, avec une interface de recherche, et le gestionnaire doit pouvoir télécharger des fichiers de mise à jour...".

Parfait. Mais le travail du développeur ne s'arrête pas là. Il doit aussi prendre en compte les besoins non-fonctionnels, à savoir les capacités intrinsèques du système. C'est là que nous introduirons les "-ilities" qui ne sont qu'un ensemble d'adjectifs, de caractéristiques à quantifier pour le projet.

Scalabilité, Haute-disponibilité, capacité à auditer et garder des traces applicatives, tolérance à la panne, capacité à configurable à chaud ou non, modularité, sécurité, etc.

Dans tout projet, nous vous conseillons d'identifier une série de mots clés, telle que celle présentée ci-dessus, et de la confronter aux demandes de votre Client. L'important étant de prendre en compte et de ne surtout pas tout traiter. Votre client sera peut-être insensible à votre volonté de modulariser votre logiciel en plusieurs micro-services. Peut-être que ceci ne représente pas d'intérêt pour lui. A contrario, il vous demandera de tracer et d'enregistrer les logs d'activités et peut-être des logs techniques, car il a une obligation réglementaire. Ou peut-être qu'il doit couvrir un risque de sécurité, et qu'il est obligé de tracer les demandes d'authentification...

Lorsqu'enfin vous souhaitez documenter et expliquer vos choix d'architecture, nous vous proposons un modèle de document assez simple, appelé "enregistrement de décisions d'architecture" ou "Architecture Decision Record" en Anglais.

Le format est le suivant :

La soirée s'est terminée autour d'un verre et de pizza, nous comptons sur vous à la rentrée.

Si vous souhaitez être orateur, merci de contacter le groupe via la page MeetUp.

A bientôt !

Nicolas Martignole