Il y a 4 ans -
Temps de lecture 17 minutes
Une journée à Devoxx, l’avis des Xebians
Des Xebians ont pu assister à plusieurs conférences lors de Devoxx France qui s’est tenu du 17 au 19 avril dernier. Retrouvez dans cet article leurs retours !
Mercredi
University
Highway to Elm – pour un meilleur front-end
Jordane Grenat persiste et signe sa passion pour le langage Elm avec cette très bonne université.
Après des informations sur sa syntaxe, son histoire, puis lors d’un live coding d’une petite application web, on a pu voir Elm en action. Pas (trop) de JS bashing, mais une mise en avant de ses faiblesses et des réponses apportées par Elm (exclure la possibilité de run time exception, limitation des dépendances,…).
On a eu une démonstration des différents types de programmes Elm existants permettant de répondre à différents besoins : application web de base, gestion ou non de side effects et gestion du routing. Le live coding a également couvert la gestion des vues en HTML, la façon d’interagir depuis une application Elm vers du JS et inversement et les appels HTTP.
C’était une bonne université, j’ai beaucoup elmé :)
Développer et déployer sur Kubernetes comme un Googler
Au cours de l’université, David Gageot nous présente certains services ou outils de Google (Open Source ou disponibles sur GCP) pour démontrer
Comment déployer et faire tourner une application sur Kubernetes comme un Googler
Dès le début j’apprends une petite chose que je ne savais pas, on peut monter en un clic un cluster K8 sur sa machine avec Docker Desktop (cool).
KNative
Est une solution Open Source qui permet de packager son application dans Docker et la déployer en mode serverless, soit grâce au Service Cloud Run (complètement managé), soit sur GKE (en installant KNative par dessus), soit sur n’importe quel Kubernetes avec KNative installé dessus. Cela rend l’application très portable et évite le vendor lock-in.
Skaffold
Permet de simplifier la configuration et le déploiement d’un conteneur dans Kubernetes. Il propose une configuration en fonction d’un Dockerfile et génère le fichier yaml. En une ligne de commande, cela permet de builder, tagger, déployer et voir les logs d’une application jusqu’au run dans Kubernetes. Il peut même être lancé en mode « watch ». Dès que le code est changé, toutes les étapes jusqu’au run s’exécutent automatiquement. En fonction de la configuration et du langage on peut plus ou moins optimiser les traitements faits pour avoir une boucle de feedback hyper rapide (c’est moins vrai pour Java 😜). Ex. pour un site statique, il est capable de voir le fichier modifié, le copier et l’injecter dans le conteneur qui tourne sur un cluster Kubernetes (à chaud). Il est également capable de faire du port forwarding pour tester une application via un navigateur lancé en local. Très bien pour le développement mais pas pour la production bien sûr.
Jib
Plugin maven / graddle pour construire des images Docker sans aucune config et qui gère également un cache pour éviter de refaire certaines étapes de construction de l’image Docker si ça n’a pas d’incidence sur le livrable (changement de commentaires dans le pom, etc.).
Dive
Petit outil pour inspecter en détail les fichiers ajoutés/modifiés dans chaque layer d’une image Docker.
Cloud Code (Beta)
Série d’extensions pour IDE (VS Code ou JetBrain), pour faciliter le développement avec K8. Cela permet, via l’IDE, de se connecter à un cluster K8 et d’interagir avec grâce à une interface graphique.
Il est également possible de créer des projets « squelettes » pour différents langages avec une configuration Docker d’exemple ou des templates yaml de configuration K8 prêts à l’emploi.
Il est facile depuis l’IDE d’avoir les mêmes fonctionnalités qu’avec Skaffold. L’utilisateur bénéficie de l’autocomplétion et de la validation des fichiers yaml de configuration K8.
Enfin, cela offre aussi une façon de pouvoir débugger dans l’IDE une application qui tourne sur un K8.
Cloud Build
C’est un service cloud de CI/CD sur GCP. Skaffold peut piloter Cloud Build pour gérer… le build. Mais l’inverse est également possible.
Tekton
Permet de gérer des pipelines pour le build grâce à une norme de fichier yaml qui a pour ambition de devenir le format standard. CloudBees & Co vont pousser pour pouvoir convertir les Jenkins files en Tekton.
Istio
David Gageot nous montre comment l’utiliser pour rajouter différents types d’objets customs à K8 afin de configurer des comportements au niveau des pods :
- Introduire des erreurs pour certains services.
- Gérer des retry à un niveau global sur tous les microservices d’un cluster.
- Configurer les ingress K8 pour gérer le routing (UI/microservices/ …) et ainsi éviter une façade embarquée avec l’UI et faire une gateway.
On ressort avec une bonne vision d’ensemble d’outils pouvant nous faciliter la vie au quotidien. Chaque outil était présenté grâce à des démos qui m’ont permis de bien comprendre ce qu’il faisait même si Kubernetes n’est pas directement dans mon domaine d’expertise.
Deep Learning pour le traitement du Langage avec Pytorch
Une présentation très complète pour tous les amateurs de machine learning et de deep learning qui travaillent sur des données textuelles. Le Speaker a commencé par des explications sur des concepts basiques de machine learning et du traitement de texte, ce qui a permis de mettre tout le public au même niveau de connaissance pour la suite de la présentation. Pour la première démo il a implémenté une solution simple, la vectorisation des mots disponibles dans le corpus et l’implémentation d’un modèle basique de machine learning (la régression logistique).
Lors de la deuxième partie du talk, le modèle a été amélioré en utilisant des techniques de plus en plus avancées : représentation de données textuelles avec Spacy grâce avec les word embeddings des frameworks Glove et Fasttext. Ensuite, il a fait une brève introduction sur la modélisation Deep Learning, en particulier les paramètres du réseau (la fonction de loss, la fonction d’activation etc.) et les couches LSTM. La précision du modèle a augmenté avec l’implementation Pytorch, l’utilisation du word embedding et d’un réseau de neurones simple,.
Pourquoi utiliser Pytorch pour la modélisation Deep Learning ? Selon le Speaker, l’avantage principale est la possibilité de gérer des batchs de différentes tailles. Ce qui n’est pas possible avec les autres frameworks en Python.
Quarkus: Pourquoi & Comment faire une appli Java Cloud Native avec Graal VM
Lors de cette Université Emmanuel Bernard et Clement Escoffier nous ont présenté Quarkus. Pour bien expliquer les motivations pour Quarkus, Emmanuel fait un historique rapide de la JVM et de ce qui fait ses défauts dans les paradigmes de déploiement apportés par les plateformes de cloud et la containerisation.
Cette évolution tend à standardiser les applications de demain sous forme de multiples composants autonomes appelés service, micro service ou fonction. Chaque composant, peut avoir un cycle de vie et des technologies différentes.
Cette vision met l’écosystème JAVA ( JVM, Hotspot) en difficulté car il a été conçu pour être une surcouche au système d’exploitation. Ces concepteurs ont pris parti de délaisser la performance de démarrage pour privilégier la performance à long terme. Les développeurs Java parlent de chauffer la JVM.
Les problèmes de lenteur au démarrage sont dus à la compilation, à la vérification du bytecode, aux chargements des classes, à l’exécution de tous les blocs de code “static” et au lancement de la JVM en elle même. La JVM possède une empreinte mémoire excessive en particulier pour de petites applications.
C’est là qu’intervient GraalVM. Graal VM c’est une réécriture complète du compilateur C2 en Java. A l’inverse de C2, Graal génère un code machine qui fonctionne dans une micro VM appelée “Native Image” (également connu sous le nom de code “Subtract VM”). Cette compilation “ahead-of-time” apporte de nouvelles contraintes tel que closed-world assumption. Quarkus est un framework inspiré de Play Framework et reprenant des briques de l’écosystème open source Java. Il est capable de générer, via GraalVM, des applications exécutables sur Native Image.
Tools-in-Action
TensorFlow 1.x n’est plus, Vive TensorFlow 2.0
Dans ce talk, Alexia Audevart, Google Developer Expert Machine Learning, nous a fait un panorama sur les nouveautés de TensorFlow 2.0. Ces changements ont pour but, d’améliorer la productivité des développeurs.
Elle nous a expliqué comment le framework Keras a été introduit dans TensorFlow pour rendre plus facile le développement de nouveaux modèles.
Avec TensorFlow 2.0 Alpha, il est déjà possible d’utiliser Gpu ou Tpu d’une manière beaucoup plus transparente au niveau de la codification de l’algorithme.
Il existe deux modes de codification:
- Le mode fonction, très proche de python, qui permet de debugger beaucoup plus facilement.
- Avec Autograph, il est possible de migrer ce mode de fonctionnement vers le mode traditionnel de Graph.
C’était un parcours très intéressant sur les améliorations du framework, qui sera prochainement en version stable.
Jeudi
Conférence
10 choses que j’aurais aimé savoir avant d’utiliser Spark en production
Après avoir travaillé plusieurs années avec Spark, les Speakers ont constaté que les configurations par défaut ne sont pas toujours optimales. Dans ce talk, ils nous donnent 10 conseils pour que nos applicatifs soient plus efficaces :
- RDD vs DataFrames vs DataSets : avant de commencer à travailler avec Spark, il faut choisir parmi les trois structures de données. RDD est recommandé pour les données non-structurées ou semi-structurées, alors que le Dataframe et le Dataset sont préférés pour les données structurées sur lesquelles nous voulons faire des aggregations. Avantage supplémentaire pour le Dataset : le type des colonnes est connu et vérifié lors de compilation.
- Data Serialisation Format : pour la structure RDD, n’utilisez pas la serialisation Java par défaut, mais plutôt Kryo, qui s’avère plus rapide, plus compacte et plus facile à configurer. Pour les DataSets et DataFrames il est recommandé d’utiliser la serialisation tungsten.
- Storage Formats : évitez les formats csv ou json et préférez les formats binaires : parquet, avro. Voici leurs avantages :
- Apache Parquet : possède une compression élevée, à choisir si l’on requête beaucoup sur quelques colonnes.
- Apache Avro : est rapide lors de l’écriture, possède la fonctionnalité schema evolution. Il est donc à utiliser si le schema de nos données peut évoluer.
- Broadcast Join : le join est l’opération la plus coûteuse pour Spark. Pour la rendre plus efficace, on peut augmenter le timeout du broadcast dans la configuration. Cependant pour les données de moins de 10Mb, le broadcast est fait automatiquement.
- Hardware Tuning: il est nécessaire de bien connaitre les paramètres de notre cluster : la RAM, les Cores, Yarn… Si vous n’avez pas ces connaissances, vous risquez une utilisation excessive des ressources et par conséquent des performances médiocres. Vous pouvez utiliser la fonctionnalité Dynamic Allocation pour ajuster des ressources automatiquement en cours d’utilisation.
- Level of parallelism/partitions : augmentez le nombre de partitions. Pour les fichiers compressés utilisez la méthode repartition.
- Garbage Collector tuning: modifiez les configurations des spark driver et executor en ajoutant des extraJavaOptions.
- Errors : pour gérer les problèmes de mémoires, augmentez le nombre de partition ou réduisez le nombre d’exécuteur.
- Data skew : si vos données ne sont pas distribuées de manière uniforme sur les partitions vous risquez de rencontrer des problèmes. Les solutions possibles sont : de repartitioner les données, de ne pas utiliser la colonne asymétrique pour faire le join.
- Data Locality : tuner les configurations de la fonctionnalité Data Locality pour accélérer le temps de traitement de vos jobs Spark.
Et pour mieux gérer l’ensemble des configurations de vos jobs Spark, les Speakers recommandent d’utiliser l’outil Dr Elephant.
Introduction to Face processing with computer vision
Dans ce talk Gabriel Bianconi, de Scalar Research, nous a fait une introduction à la reconnaissance facial. Il a structuré son talk en cinq sections pour nous expliquer les techniques de traitement de visages :
- Qu’est-ce que la reconnaissance de visages et les tâches associées au traitement du visage : ce sont des techniques qui permettent de localiser des visages dans des photos, les identifier et les manipuler.
- Review des images par ordinateur : pour l’ordinateur, une image est une matrice multidimensionnelle.
- Introduction au machine learning et à la vision par ordinateur : il y a deux approches pour faire de la vision par ordinateur, la plus traditionnelle, consiste à extraire les features d’une image pour inférer un modèle. La deuxième, utilise deep learning (réseaux de neurones).
- Techniques de traitement de visages et exemples :
- Histogram Oriented Gradients (HOG) qui consiste à découper les images en sub-areas, chacune identifiée par 16 gradients représentatifs.
- Neural Networks, en particulier, les Convolutional Neural Networks (CNN).
- Traitement de visages dans la pratique : Gabriel nous a présenté différentes libraries et frameworks spécialisés dans l’exécution des tâches communes au traitement d’image: TensorFlow, OpenFace, dlib, FaceNet et FaceRegognition. Pour faire du traitement de visage à l’échelle, il a aussi mentionné Ms Azure Face Api, Aws Rekognition et Face++
Mob programming
Les deux Speakers nous ont parlé de leurs experiences en mob programming, les avantages ainsi que les pièges.
Le mob programming est une approche de développement dans laquelle toute l’équipe de développeurs travaille sur le même écran pour résoudre un problème. Il est important lors des sessions mob que tous les membres de l’équipe participent de manière active. Une fois le cadre des sessions mob établi, les avantages sont nombreux. Premièrement, cela permet de réduire voire d’éliminer la dette technique cumulée dans le passé. Toute l’équipe est engagée dans la tâche en cours, chacun devient le garde de fou de la qualité du code développé. Deuxièmement, toute l’équipe est synchronisée, il n’y a pas donc pas de risque de truck factor, ni de décalage des tâches à cause des absences des membres de l’équipe. De plus, les décisions technologiques et d’implémentations sont prises collectivement. Cela permet de récolter plusieurs idées, d’évaluer plusieurs possibilités et aussi de responsabiliser toute l’équipe.
Ce qu’il faut veiller et éviter ce sont les débats trop longs et fatigue. Pour cela, les Speakers conseillent de faire tourner une rôle de facilitateur du mob. Il a pour objectif de cadrer le déroulement de la session mob en incluant des pauses.
Un outil à tester pour faciliter vos mob programming : Mobster.
Master Tooling for Containers with DevOps
Dans ce talk, Jessica Deen, Microsoft Cloud Developer Advocate nous a parlé des outils et bonnes pratiques DevOps pour Kubernetes et la gestion des Containers.
Jessica a parlé du conflit historique entre Dev et ops. D’un côté les Dev qui d’un côté ont besoin de développer, migrer et déployer plus rapidement et de l’autre, les Ops recherchent la sécurité, la stabilité et la robustesse. La culture DevOps a commencé avec le besoin de réunir les deux mondes pour travailler ensemble, communiquer et collaborer.
DevOps, c’est l’union des personnes, des processus et du produit pour livrer de la valeur.
Parmi les bonnes pratiques DevOps, elle a mentionné :
- L’infra as code,
- CI/CD,
- L’automation,
- Le monitoring.
Ensuite, Jessica a énuméré les avantages apportés par l’utilisation des conteneurs. Ils nous permettent d’écrire du code une seule fois et de l’exécuter partout. Puis, elle nous a présenté une démo d’un jeu écrit en JavaScript et en Go, containérisé et déployé sur un cluster Kubernetes. La démo a servi d’exemple, pour nous présenter des outils qui facilitent la mise en place des bonnes pratiques mentionnées précédemment.
- build → Docker
- package → helm(package manager de facto de Kubernetes), Kubernetes. Repository: Jfrog Artifactory
- deploy → Kubernetes
- tests → Selenium
Pour elle, le succès de Kubernetes vient de la culture DevOps dans laquelle il a été développé.
Elle a fini par mentionner des bonnes pratiques pour Kubernetes :
- Build de petits conteneurs
- Utiliser des namespaces
- Utiliser Helm Charts
- Contrôler l’accès à la base de rôles (RBAC)
- Implémenter des health checks
- Établir des limites pour les Web Requests
Modern Java: Change is the Only Constant
Lors de cette présentation, Mark Reinhold, l’architecte en chef du groupe “Java Platform” chez Oracle revient sur les récentes évolutions de l’écosystème et celles à venir.
Il explique pourquoi Java doit évoluer et comment il va évoluer ces prochaines années. Il compare le nombre de JEP (Java Enhancement Proposals) clôturées par la version 8 avec la somme des JEP clôturées par les versions 9, 10 et 11 : environ 90 dans les deux cas.
“La vitesse d’innovation reste inchangée, c’est la vitesse de diffusion de ces évolutions qui change”, assure Mark. Il propose une belle métaphore de la situation : vous devez choisir entre une pilule bleue ou rouge. La pilule bleue, c’est une montée de version légère tous les 6 mois. La pilule rouge correspond une montée de version conséquente tous les 3 ans.
L’autre message que Mark a voulu faire passer concerne la fermeture des API Internes (Sun, intern). Pour le moment un avertissement est affiché à la compilation mais très rapidement la compilation ne sera plus possible.
Vendredi
Conférence
L’Intelligence Artificielle pour tous
Comment éviter les biais du passé dans les algorithmes de l’IA ?
Les deux
développeuses, Rachel Orti et Mélanie Rao, ont commencé leur talk par une présentation de l’histoire de l’IA. Elles ont montré les différents types d’apprentissage automatique et les librairies que les développeurs peuvent utiliser pour tester l’IA. La puissance de l’IA et les risques liés à une mauvaise utilisation ont augmenté ces dernières années.
Un point important qu’elles notent, c’est la nouvelle réglementation RGPD. En particulier, le droit de l’explicabilité des modèles ainsi que le fait que les algorithmes d’IA ne peuvent pas prendre des décisions en se basant sur des données personnelles.
Elles proposent plusieurs outils qui permettent d’éviter le biais dans les modélisations :
IBM AI Fairness 360, Google
What-If Tool,
Audit AI de
Pymetrics. Les outils proposés permettent de modifier les données en entrée de l’algorithme pour que les prédictions et les analyses ne soient pas discriminatoires pour les groupes ethniques, ou le genre…
Cette présentation qui ne m’a pas laissée indifférente. Est-ce que les données historiques brutes, qui démontrent les comportements négatifs sur une partie de la population, sont réellement biaisées ? Quelles sont les performances des algorithmes qui utilisent des données sensibles versus les autres ?
Les algorithmes de machine learning se basent sur les données passées, décorrélées des préjudices (au moins quand la machine les traite). Si l’on souhaite traiter le biais introduit dans les données, il faut le faire sur l’ensemble des données, indépendamment du caractère personnel. L’objectif de la plupart des projets d’IA est d’avoir les meilleures prédictions possibles. Notre algorithme va donc faire le maximum de croisements de données pour arriver à bien prédire les phénomènes. Ceux qui permettent par exemple, d’aider les médecins à classifier les maladies, de lutter contre les fraudes ou la criminalité. Mais ce qui est sûr, nos projets data science doivent respecter la vie privée ainsi que la réglementation européenne.
Commentaire