Devfest Nantes 2019 : Résumé des conférences
Les 21 et 22 octobre derniers a eu lieu le DevFest Nantes 2019. Au programme : des conférences, des animations et du Rock !
Pour ceux qui n’ont pas eu la chance d’y assister, retour sur les conférences auxquelles Pierre Yves et moi avons assisté ! C’est parti !
Duniter : la blockchain écolo
J’ai choisi d’aller voir cette conférence, parce que, dans mon esprit, la blockchain est associée à une grosse puissance de calcul destinée à fournir les preuves de travail (PoW) ensuite validés par les membres du réseau.
Dans le cas du bitcoin par exemple, il y a compétition entre les membres du réseau afin d’être le premier à produire une preuve de travail et obtenir le bénéfice de la création monétaire. La conséquence est qu’une quantité importante de puissance de calcul du réseau est consommée sans produire de résultat.
Avec Duniter, l’approche est un peu différente.
Pour commencer, la constitution du réseau est basée sur la confiance accordée au nouveau membre afin de constituer une toile de confiance sur lequel on pourra ensuite s’appuyer pour tirer les bénéfices de cette confiance.
Notamment, un des objectifs est d’éviter de distribuer systématiquement le calcul des PoW sur tous les noeuds du réseau tout en conservant l’intérêt de la répartition.
Pour cela, la difficulté de calcul des PoW est adaptée pour chaque noeud en fonction de différents facteurs :
- Puissance de calcul disponible
- Succès sur les calculs précédents
Je ne suis pas particulièrement féru de blockchain, mais j’ai apprécié cette approche qui propose des solutions aux problèmes de consommation énergétique engendrés par certaines crypto-monnaies.
Lien vers les slides et vers la vidéo de la conférence.
Performance tuning of Go applications in Cloud
La première partie de cette présentation ne concernait pas seulement le langage Go, mais consistait en des rappels standards sur les performances dans le monde du web.
Notamment la différence entre le “service time” et le “response time”, le premier étant uniquement le temps d’exécution nécessaire à la réalisation du travail demandé, alors que le second comprend l’ensemble des étapes (sérialisations/désérialisations, transfert réseau…) nécessaires à la transmission de la requête et de la réponse.
Le point déterminant étant de prendre en compte l’expérience utilisateur, car l’objectif est de diminuer la latence de son point de vue.
En seconde partie, Valentin a mis en pratique des méthodes et des outils permettant d’améliorer les performances d’une application Go.
Une première approche consiste à utiliser une vue waterfall afin de mesurer l’impact des différentes étapes d’un appel
- Utilisation des WaitGroups pour paralléliser les tâches indépendantes
- Présentation de pprof afin de connaître les graphes d’appel de fonction : “go test -bench” and “go tool pprof”
- Identification des goulots d’étranglement : CPU Flame graph
Un des avantages des Flame graph par rapport à pprof est la conservation de la stack complète de chaque appel, alors que pprof ne donne qu’un aperçu général de du graphe d’appel.
Cette présentation m’a permis de découvrir des outils directement disponibles dans l’écosystème Go afin d’améliorer les performances.
Si vous souhaitez en savoir plus sur le sujet, vous pouvez consulter cet article ou regarder la vidéo de la conférence.
Back in Black Hat : Comment se faire pogoter (hacker) bien comme il faut!
Julien nous a proposé un tour d’horizon des 10 failles les plus courantes d’applications web recensées par l’OWASP.
Sa présentation est très didactique et progressive, avec des exemples pour chaque faille ainsi que les contre-mesures à mettre en place.
Outre les classiques injections SQL et autres CSRF, Julien nous a présenté des exemples de faille touchant les désérialiseurs XML (XML External Entities), ainsi que les failles touchant les dépendances.
De mon côté, je retiens la présentation de Dependency Track que j’avais déjà eu l’occasion de tester et qui permet d’avoir une vue globale sur l’exposition de vos composants à des failles héritées de dépendances. Je complèterai même avec des outils comme renovate, qui permettent d’automatiser la mise à jour de ces dépendances.
Lien vers les slides et vers la vidéo de la conférence.
How to Build Cloud-Native CI/CD Pipelines with Tekton on Kubernetes
En tant qu’utilisateur des outils de CI/CD, je suis toujours curieux de découvrir leurs nouveautés. J’avais déjà entendu parler de Tekton lors de l’annonce de la création de la CI/CD Foundation, mais je souhaitais en apprendre davantage.
Ce projet répond à une évolution des besoins en termes de CI/CD.
- On souhaite une solution plus légère
- Qui propose une approche serverless : pas d’outil central tournant en permanence
- Des constructions et actions déclenchées par des événements (webhook, …)
- Pouvoir réutiliser des composants ou des éléments de la chaîne de CI
Le projet tekton est écrit en Go, et se base sur knative pour l’approche serverless.
Il propose de déclarer les Pipeline sous forme de descripteurs yaml :
- Un pipeline permet de décrire un processus complet de construction/déploiement
- Les pipelines se composent de Tasks qui seront exécutées dans des Pods Kubernetes
- Il est possible de définir des Input et des Output aux tasks afin de les combiner
L’approche me fait beaucoup penser à ce qui se fait lorsqu’on utilise gitlab-ci, CircleCI, Travis CI, ou encore les Github Actions… Mais plus proche de ce qu’on connaît avec Kubernetes.
La vidéo de la présentation est disponible ici.
À tester rapidement !
Quarkus
Quarkus est un framework java permettant de démarrer très rapidement une application avec une empreinte mémoire très faible. L’idée est de construire des API pouvant être lancées rapidement lors d’un pic de charge dans une infrastructure élastique.
Quarkus permet plusieurs types de programmation inspirés des autres écosystèmes : impératif / asynchrone / réactif.
Pour faciliter le développement, le live reload est déclenché à chaque sauvegarde des fichiers java. Cela permet d’économiser le temps de redémarrage de la webapp. Par contre, les informations qui auraient été montées en mémoire au chargement précédent sont perdues : la webapp complète redémarre.
Quarkus est conçu pour fonctionner avec GraalVM : cette JVM n’implémente pas toutes les fonctionnalités de Java afin de faire table rase du passé et d’optimiser son fonctionnement : par exemple, l’API Reflection n’est pas disponible simplement, les proxys dynamiques habituellement construits avec Spring ne marcheront plus du premier coup. Des opérations de paramétrages supplémentaires permettent de pallier ces désactivations.
Pour qu’une application soit rapide à démarrer, Quarkus effectue des traitements habituellement exécutés au lancement de l’application lors de la phase de construction : par exemple, le fichier persistence.xml utilisé par hibernate est lu au build maven, des métadonnées sont créées pour que le démarrage d’hibernate s’effectue tout de même correctement à son lancement. Ainsi, la librairie de chargement de fichier XML n’est pas chargée au démarrage de la webapp. Par contre, la durée du traitement maven est sensiblement plus longue (mais ce n’est pas trop grave, c’est la CI qui s’en charge). En mode dev via mvn clean compile quarkus:dev, le chargement de ce fichier s’effectue bien au démarrage de l’application ce qui ne change pas l’expérience développeur.
Quarkus fournit également le nécessaire pour créer des images Docker optimisées : pas de fat jar comme avec spring, mais plutôt un dossier lib contenant les dépendances commitées dans une couche et le jar applicatif dans la dernière couche. Le stockage de l’image sur une registry est ainsi bien mutualisé.
Pour ajouter des comportements supplémentaires à la webapp, Quarkus implémente les microprofiles pour rationaliser les librairies chargées en mémoire. Ainsi pour ajouter du monitoring, il faut importer la dépendance io.quarkus:quarkus-smallrye-metrics ce qui permettra d’exposer un endpoint /metrics au format prometheus aisément.
Idem pour un endpoint de healthcheck.
Lien vers la vidéo
Premier pas avec un micro contrôleur et Google Cloud IoT Core
Pour débuter dans l’utilisation des micro-contrôleurs, l’Arduino Nano est un excellent candidat. Par contre, son manque de connectivité réseau va vite devenir un facteur limitant. D’autres plateformes existent à savoir la famille des ESP : le plus connu étant l’ESP8266 qui est un Arduino survitaminé en termes de ressources auquel un contrôleur Wifi est ajouté. Le processeur de ce dernier est cadencé à 80 MHz par rapport à 16 MHz du Nano. La RAM et Flash sont également beaucoup plus conséquente. Il existe également l’ESP32 qui fonctionne à 240 MHz.
Le point commun entre ces plateformes ESP est leur coût (quelque dollars frais de port compris) ainsi que leur facilité de programmation accompagnée d’une très forte communauté.
Plusieurs languages de programmation peuvent être utilisé : C (en utilisant le SDK esp-idf), C Arduino et même python.
Le speaker illustre son propos en branchant un capteur de température et d’humidité, le BME280, connecté en I2C. Ce protocole de communication est très utilisé dans le monde industriel et est géré nativement par ces micro-contrôleurs. En ajoutant la librairie idoine dans l’IDE Arduino puis en chargeant le fichier exemple, le programme s’upload sur la plateforme de prototypage et affiche finalement sur la console série les valeurs mesurées du capteur.
Pour dépasser le hello world qui affiche les données sur la console série, l’orateur présente la plateforme Google cloud IOT Core qui intègre des standards utilisés par les devices type IOT comme MQTT : basée sur un broker, les différents appareils publient des événements et des consommateurs peuvent exploiter les valeurs ainsi récupérées.
Gautier explique que l’enregistrement d’un device se fait par le biais d’une paire clé publique / privée et montre la génération et l’injection dans le micro-contrôleur.
Comme pour la sonde de température, il est possible d’installer une librairie Arduino Cloud Iot Core via l’IDE Arduino afin de l’ajouter dans le SDK.
Une fois l’ESP32 flashé, les données sont publiées sur le MQTT de Google.
Dans le cadre de la démo, les données sont consommées par une lambda qui met en forme les données dans un graphique.
Gautier sort une paire de lunettes bluetooth sur laquelle il affiche la température mesurée !!
Pour aller plus loin, il illustre son propos à l’aide d’un moniteur cardiaque relié en bluetooth à son ordinateur qui, à l’aide d’un programme en Node.js publie les valeurs sur une base timeseries InfluxDB. Grafana est branché dessus et affiche sous forme de graphique les données. Le tout est hébergé sur un cluster Kubernetes.
Pour continuer (parce qu’on n’est pas au bout de nos surprises!), Gautier montre l’outil Fritzing qui permet de construire le schéma électronique du prototype composé de la sonde de température BME280 et du micro-contrôler ESP 32.
Directement depuis fritzing, il est possible de commander la fabrication du circuit imprimé pour une petite somme via pcbway.
Pour terminer, Gautier montre un boîtier en plastique qu’il a imprimé sur une Elegoo NEPTUNE 3D modélisé en 3D avec Fusion 360.
Voir la vidéo
Bootiful testing
La présentation de Josh commence par un rappel de l’interêt du “clean code” : écrire un code qui peut être testé, documenté et avec lequel le design de l’application est facilité.
Il décrit ensuite le sentiment de la joie de vivre lorsque son code fonctionne et est testé mais pour cela, il faut le faire dans le bon sens : d’abord écrire les tests puis le code et non l’inverse. Dans le cas contraire, lorsque le code fonctionne déjà, la motivation tombe au moment d’écrire les tests puisque tout marche déjà.
L’approche bottom<->top ou top<->bottom est décrite en terme de stratégie d’écriture des tests :
- bottom<->top est souvent utilisé pour tester en premier les composants de plus bas niveau puis les couches supérieurs sont testées successivement jusqu’aux appels des services externes. Cette approche fonctionne bien lorsque les développements dépendent de d’autres API qui ne sont pas encore prêtes au démarrage des travaux.
- top<->bottom est l’approche inverse : les tests IHMs sont d’abord écrits puis les couches descendantes sont couvertes. Cette technique est à utiliser lorsque l’intégration entre les équipes va être dure et risquée.
La suite de la présentation est une démo sur la mise en oeuvre d’une API Rest utilisant Spring Boot.
Pour commencer, le bootstrap du projet est fait avec start.spring.io puis l’API est construite en écrivant d’abord les tests puis les implémentations.
Mais, le dev d’une API ne s’arrête pas là, il faut également fournir des Mocks à ses clients pour qu’ils puissent travailler sereinement. Entre en jeu la librairie Spring Cloud Contractqui permet d’écrire, à l’aide d’un DSL en groovy, des jeux de données de l’API et de produire un jar auto exécutable contenant ces mocks.
L’intégration de ce jar dans un client spring s’effectue à l’aide d’annotation permettant de toujours récupérer la dernière version de l’artefact afin d’assurer la cohérence des appels.
J’ai beaucoup aimé cette approche et nous l’avons priorisé pour le prochain sprint ^^.
