Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

‍

Les visiteurs ont pu découvrir sur notre stand un jeu concours en AR, que nos équipes ont créé spécialement pour l’occasion et gagner deux Super Nintendo Mini. Une fois le stand installé, il était temps d’assister aux conférences. Nos équipes techniques ont pu profiter du programme riche et varié proposé par les différents speakers, dont une conférence de Antoine Cheron, notre développeur et chercheur. Dans cet article, nous allons vous résumer les points clés des présentations auxquelles nous avons pu assister.

Mercredi 17 avril

Web-crypto, end-to-end encryption et privacy par Mathieu Ancelin; Fedy Salah de SERLi

Le talk “Web-crypto, end-to-end encryption et privacy”, présenté sous un format court d’une trentaine de minutes, nous a fait le survol d’une API nouvellement disponible dans les navigateurs : la Web Crypto API. Cette interface est un accès simplifié aux différentes fonctions et algorithmes de la cryptographie. Il permet de chiffrer les données d’un utilisateur dans son navigateur avant de les envoyer dans le cloud.

Un des scénarios d’usage, qui nous a été présenté, est une messagerie instantanée privée. Ancelin et Salah nous ont montré la mise en place de cette API dans leur projet en passant par la manière de crypter un message et comment le décrypter.

En conclusion, il ne recommande pas d’utiliser l’API bas niveau Web Crypto, car il est très facile de ne pas être aux standards du marché en matière d’encryption et de faire des erreurs qui compromettraient la sécurité de l’application et des utilisateurs. Voici le slide deck de la présentation et la démonstration.

Jeudi 18 avril

Observabilité : mythes, réalité et Chaos par Benjamin Gakic de OUI.sncf

Lors de cette conférence, Benjamin Gakic nous a présenté une excellente introduction à la notion d’Observabilité et de Chaos Engineering. Très éclairant ! Tests automatisés et monitoring nous aident à surveiller les systèmes que l’on connaît. L’informatique est désormais aussi faite de multiples composants qui démarrent, s’arrêtent et tombent en panne en plein fonctionnement. Quid d’un tel système non maîtrisé ? Observabilité + Chaos Engineering.

L’observabilité passe par la visualisation des flux de son SI, en temps réel donc, le placement d’alertes et indicateurs pertinents selon son contexte. Puis, il faut s’assurer qu’on fait ça bien, alors autant mettre le feu à son SI et voir si l’on est capable de diagnostiquer et réparer rapidement. C’est cette pratique du Chaos Engineering qui a été testé chez OUI.sncf. Benjamin Gakic nous a ainsi présenté leur expérimentation pour tester l’observabilité : faire tomber un data center en production, trois fois, et voir comment les équipes réagissent.

Bilan : une équipe plus performante grâce à de nouvelles procédures, indicateurs et outils d’observation des flux. D’après lui : «Le chaos engineering est certainement un des meilleurs outils de vérification de l’observabilité », « Sans observabilité vous n’avez pas de Chaos Engineering juste du Chaos *», « *Pour le chaos comme l’observabilité, la vérité est ailleurs que les environnements de test ». Testons donc en production !

Sonar Smash: fueling the removal of technical debt through competition par Helen Wallace et James Mac Mahon de Murex

Nous nous attendions à assister à une conférence sur une utilisation particulière de Sonar, outil d’analyse statique que nous utilisons sur notre code à chaque commit effectué, mais nous nous trompions. Helen Wallace et James Mac Mahon de chez Murex ont constaté le problème suivant : il y a de nombreux endroits où la base de code est constituée de longues classes non testées et parfois incompréhensibles, ainsi que de nombreuses autres formes de dette technique.

Ils voulaient essayer de trouver un moyen de motiver les troupes à enlever cette dette technique, ce qui n’est pas facile au quotidien lorsque l’on a des features à développer. C’est pourquoi ils en sont venus à créer un jeu en interne, “Sonar Smash”. Regroupés par équipe, les développeurs avaient pour objectif de retirer au maximum de dette technique.

Tout le challenge pour Helen et James a été de donner envie aux développeurs de participer activement. C’est pourquoi il a fallu identifier les éléments de dette technique, chose faite grâce à Sonar, les prioriser (en excluant par exemple les dettes liées à l’UI, moins prioritaires), les quantifier (nombre de problèmes résolus, différentiel de lignes).

À la clé : déjeuner offert pendant 2 mois pour l’équipe gagnante, une coupe, ainsi que la gloire au sein de l’entreprise. Les équipes se sont pris au jeu assez rapidement. La mise en place d’un leaderboard, d’un système de points empêchant les équipes de prendre trop d’avance ont attisé la compétition et en ont fait un sujet de discussion récurrent entre développeurs : tout a fonctionné ! Peut-être pourrions-nous nous en inspirer aussi.

Kotlin Under the Covers par Chet Haase et Romain Guy de Google

Parmi les tendances du moment, on peut dire que Kotlin tire son épingle du jeu. Nouveau langage à la mode, ce langage créé par JetBrains a su redonner un coup de jeune à la plateforme Android où Java régnait en maître depuis longtemps. Ce langage étant très jeune, Chet Haase et Romain Guy de chez Google se sont amusés à regarder ce qui se trouve sous le capot une fois le code Kotlin compilé.

Ils se sont rendus compte que peut être les développeurs de JetBrains étaient allés un peu vite sur certains aspects. Dans un premier temps, nos deux stars de Google, nous ont montré quelques outils permettant de voir le Bytecode directement depuis l’IDE Android Studio (surcouche de l’IDE IntelliJ). Pour cela, il suffit simplement de sélectionner un bout de code écrit en Kotlin puis de faire Tools -> Kotlin -> Show Kotlin Bytecode. Une fenêtre apparaîtra alors dans laquelle vous verrez toute votre classe transcrite en Bytecode avec le code que vous avez sélectionné en surbrillance.

L’autre fonction pratique de l’IDE est de pouvoir dé-compiler ce ByteCode en Java pour comprendre un peu mieux les rouages de la compilation Kotlin. Dans la fenêtre, vous aurez un bouton “décompiler” qui vous fera la traduction du ByteCode vers Java. Une fois ces outils présentés, Chet Haase et Romain Guy ont passé en revue plusieurs choses assez surprenantes concernant le ByteCode Kotlin.

Un exemple parmi celles-ci concerne la “lazyness” des variables. Vous pouvez déclarer des variables de classes en Lazy dans votre code Kotlin. Ceci a pour effet d’initialiser la variable seulement quand on a besoin, et par conséquent d’éviter potentiellement de lourds calculs si la variable n’est pas utilisée. En décompilant en une lazy var en Java, on s’aperçoit que le processus peut s’avérer assez lourd : allocation de tableau et d’objets et utilisation de la réflexion.

La conclusion est qu’il faut utiliser des lazy var uniquement pour des objets assez lourds (et éviter de ne l’utiliser que pour un Integer par exemple). La conclusion que l’on peut tirer ce talk est que Kotlin est un langage très récent qui pourrait être optimisé sur certains aspects. Les équipes de JetBrains sont toujours en train de l’améliorer, le passage des coroutines en stable en est la preuve, et bientôt nous aurons également les channels et les flows. Nous ne pouvons que vous conseiller de regarder cette présentation en rediffusion pour parcourir toutes les bizarreries de Kotlin.

Hands-On : Flutter par Pierre Tibulle de ASI et Horacio Gonzalez de OVH

Cet atelier nous a permis de créer une application de type liste/détail, permettant d’afficher les différentes plages présentes en Bretagne à partir de la base de données. Vous pouvez reproduire les étapes depuis ce github , ou bien directement télécharger le code final. Flutter est un framework créé par Google permettant de créer des applications à la fois sur iOS et Android en Dart.

Une des forces du framework est le hot reload : il est possible de rafraîchir les vues de l’application sans la relancer lors du développement, permettant de tester instantanément un changement, et il faut reconnaître que c’est bien pratique. Cela est dû à Dart qui peut être compilé aussi bien JIT (Just In Time) que AOT (Ahead Of Time). Ce dernier mode de compilation est utilisé lorsque l’on publie l’application ; il utilise un maximum d’optimisations, permettant un lancement et des temps d’exécution plus rapides.

"Architecturalement" parlant, Flutter propose de tout coder avec des Widgets (toutes les classes, que ce soient des vues ou non, dérivent de Widget), qui viennent se placer au-dessus de l’architecture native d’iOS ou Android. Flutter propose des interfaces pour accéder directement aux fonctionnalités OS des appareils (GPS, Bluetooth, appareil photo…).

Il est intéressant de noter que Flutter tente de s’adapter à l’OS sur lequel il est lancé, par exemple une barre de titre sera centrée sur iOS tandis qu’elle sera sur la gauche sur Android, sans que rien ne soit fait dans le code… mais ça s’arrête généralement là.

Flutter offre également des composants visuels identiques à ceux d’Android, et quasiment identiques pour iOS (Google aurait filmé avec des caméras très précises les animations présentes sur iOS pour les reproduire me disait un des présentateurs), ce qui signifie cependant que si vous voulez coder une application pour les deux plateformes en gardant un aspect natif, il faudra dupliquer le code de vue… ce qui va un peu à l’encontre de la promesse du framework. Néanmoins, si vous optez pour un design entièrement personnalisé dans votre application, la solution peut s’avérer intéressante.

Flutter possède un framework d’animations assez facile d’utilisation nommé “Hero”, très utile pour les transitions entre Widgets. On donne un identifiant à deux widgets situés dans deux vues différentes et Hero se charge tout seul de redimensionner l’élément visuel pendant la transition. Certains aspects de Flutter sont assez décontenançants, comme par exemple le fait que “tout soit un Widget”, en tout cas en ce qui concerne l’UI. C’est un parti pris de Google, nommé “Aggressive composability” (pour en savoir plus).

Flutter reste un framework à observer de près quoiqu’il en soit, d’autant qu’il sera rendu compatible pour les applications desktop prochainement.

Vendredi 19 avril 2019

Philosophy of HumanOps

par David Mytton de StackPath

David Mytton, VP Product Engineering chez StackPath, nous a présenté HumanOps. Il s’agit d’un mouvement qui se concentre sur le côté humain de la gestion d’une infrastructure. Le mantra de ce mouvement est le suivant :

1. Les Hommes construisent des systèmes.
2. Les Hommes ont besoin de temps de repos. Nous sommes fatigués, stressés, heureux ou triste.
3. Notre bien-être impacte directement la fiabilité du système que nous maintenons.
4. Notre santé affecte celle du business.
5. En documentant tout, apprenant à tout le monde, nous sauvons du temps.
6. Automatiser tout et ne faire remonter les problèmes aux Hommes qu’en tout dernier recours HumanOps est clairement un mouvement à suivre et que nous vous conseillons de découvrir si vous ne l’avez pas déjà fait.

The boring architecture, ou comment construire une licorne sur un monolithe par Michel Domenjoud et Nicolas de Nayer de Doctolib

Michel et Nicolas nous ont présenté l’architecture monolithique de Doctolib. Au-delà de l’approche qui détonne en ces temps où tout le monde parle de micro services, ils nous ont, avant tout, présenté les choix pragmatiques faits par les équipes Doctolib, préférant, par exemple, une petite optimisation PostgreSQL à un refactoring coûteux et risqué pour utiliser ElasticSearch. Ces choix pragmatiques permettent aujourd’hui à l’architecture de Doctolib de tenir la charge de 40K utilisateurs simultanés, pour une moyenne de 3K requêtes/secondes et avoir un taux de réponse (95th percentile) inférieur à 250ms.

Cette session a été aussi l’occasion de découvrir la vision de l’entreprise qui préfère éviter d’anticiper des choix techniques à plus de 6 mois (“Peut être qu’un jour...” et “Mais si jamais on doit ...” sont des phrases interdites), pousser l’utilisation verticale d’une technologie, investit très fortement sur les tests E2E (10K tests qui tournent à chaque PR en parallèle sur 256 machines pour un coût du build à 2€), sur des métriques pertinentes notamment via NewRelic. AWS et Azure venant juste d’être agréés données de santé, rien n’affirme que cette architecture monolithique soit toujours d’actualité l’année prochaine. Peut-être qu’un jour…

Traitement Automatique du Langage sur du texte en 2019 par Alexis Agahi de Hyperlex

Lors de cette session, Alexis Agahi nous a déroulé tout un historique du Natural Language Processing (NLP) en se référant à des tâches communes comme la reconnaissance d’entités nommées ou la résolution de co-référence. Cette conférence a permis de repasser sur des bases du Machine Learning traditionnel (stemming, lemmatization, word segmentation, vectorization) et leurs fonctions d’apprentissage.

Nous avons aussi avancé vers des réseaux de neurones et des publications de plus en plus récentes. Par exemple, celle de Tomas Mikolov qui décrit la représentation vectorielle d’un mot. En se posant la question du remplissage d’une phrase avec un trou, il parvient à une vectorisation des mots qui permet de mettre en relation des couples de mots comme “man”/”woman” et “king”/”queen”.

En nous expliquant les pièges qu’on rencontre dans ce domaine, comme les problématiques de propagation des informations dans les réseaux, les intervenants ont aussi parlé de ELMo, qui parvient à capturer un mot en se basant sur son contexte puis, de l’état de l’art actuel, BERT (pour Bidirectional Encoder Representations from Transformers). Ces modèles sont théoriques et en fonction de leur contexte d’utilisation les performances ne sont pas toujours au rendez-vous. Dans le contexte juridique dans lequel travail Alexis par exemple, toutes ces avancées en NLP ne permettent de gagner que très peu de justesse comparée au modèle utilisé historiquement.

Spring Boot avec Kotlin, Kofu et les Coroutines

par Sébastien Deleuze de Pivotal

Vendredi matin, Sébastien Deluze, contributeur Spring Framework, nous a présenté le support officiel des co-routines Kotlin dans Spring. Il est parti d'une application Spring classique et l'a transformé petit à petit dans une application réactive. Tout d'abord il a commencé pour récrire l'application en Kotlin pour avoir une syntaxe plus adaptée à la programmation fonctionnelle. Ensuite il a remplacé les deux librairies classiques du framework WebMVC et JPA par WebFlux et R2DBC.

Ces deux dernières permettent de déclarer des contrôleurs et accéder aux bases de données de façon réactive et d'enchaîner des opérations asynchrones avec les opérateurs classiques de la programmation fonctionnelle (map, flatMap, fold). Elles sont aussi plus performantes car elles ne bloquent pas l'exécution du programme. Après, Deluze a continué par nous montrer comme le support officiel pour les co-routines est compatible avec les Reactive Streams de Webflux et R2DBC.

Avec les co-routines nous pouvons écrire du code asynchrone d'une façonne plus impérative. Cela peut faciliter la montée en compétences des développeurs qui sont moins habitués à la programmation fonctionnelle. Finalement, en utilisant le Kofu DSL, Sébastien nous a montré comment remplacer la configuration classique de Spring qui utilise beaucoup des annotations par une configuration déclarative avec un très bon support de l'IDE pour l'autocompletion.

WebAssembly dans la vraie vie par Nicolas Decoster de Magellium

Comme tout standard finissant dans nos navigateurs, WebAssembly vient supporter et standardiser des expérimentations menées depuis plusieurs années. Et bien c’est par là que commence Nicolas : l’histoire qui a amené WebAssembly.

L’objectif de ce standard ? Rendre des librairies écrites, par exemple, en C, C++, Rust, GO ou C# utilisables dans le navigateur, directement depuis du code Javascript. Le speaker nous explique que cela est rendu possible grâce à WebAssembly, qui fournit un jeu d’instructions relativement bas niveau dans lequel seront compilées les librairies.

Pour C/C++ il faut regarder du côté d’Emscripten. Une machine virtuelle dans le navigateur permet ensuite d’exécuter ce code. De plus, comme les librairies écrites dans de tels langages utilisent souvent le système de fichier, WebAssembly en embarque un dans la mémoire du navigateur, pratique et sécurisé. Et vous savez quoi ? Ça marche ! Nicolas le montre au travers d’exemples qu’il tire de son expérience à travailler sur des images satellites.

Grâce à WebAssembly, il peut utiliser des algorithmes de détection de nuages ou d’avions sur des images de plusieurs centaines de mégaoctets, en un temps raisonnable (!!). Un autre exemple ? Autocad dans son navigateur, qui n’existerait pas sans WebAssembly.

Un turbo dans ton workflow GitHub

par Alain Hélaïli de GitHub

Presque tous les développeurs aujourd’hui ont déjà utilisé GitHub - que ce soit pour des projets personnels, des projets open-source ou dans un cadre professionnel. Mais tous ne sont pas conscients que GitHub peut faire bien plus que simplement héberger leur code source - et Alain Hélaïli est donc venu nous proposer un tour d’horizons de quelques-uns des outils qui pourraient nous épargner bon nombre de tâches répétitives sur nos projets hébergé sur GitHub.

Learning Lab

Hubot

Les GitHub Actions, enfin, sont encore en beta fermé mais semblent prometteuses : il s’agit de créer des workflows d’automatisation complets (par exemple, un déploiement d’application) à partir de “briques” réutilisables (implémentées dans des conteneurs Docker) et assemblables avec un éditeur graphique. Le déclenchement et l’exécution sont entièrement gérés par Github. Pour notre part chez Fabernovel, nous avons déjà commencé à expérimenter l’utilisation de Probot, et le résultat est probant : on peut créer des bots réellement utiles en quelques heures.

Migrer ses APIs vers GraphQL : Pourquoi ? Comment ! par Guillaume Scheibel de Expedia

Dans cette conférence, le speaker commence par nous expliquer son contexte : Expedia, 500 à 800 développeurs front end autonomes, partout dans le monde, de nombreuses cultures, de nombreuses (et très diverses) interfaces : sites webs, applications mobiles, interfaces vocales (Alexa) ou encore WeChat, et un Système d’Information majoritairement fait d’API REST, de beaucoup, beaucoup, d’APIs. Cela amène quelques problèmes à priori très simples, mais particulièrement coûteux dans une telle organisation : des dates et des prix retournés dans des formats très divers (ce qui rend le client confus), et des équipes qui font parfois des implémentations différentes d’une même fonctionnalité.

La conséquence de cela : des APIs pas faciles à comprendre et des coûts de maintenance élevés. En somme, une expérience API non-optimale. La problématique que s’est posé Expedia dans un tel contexte est : comment développer une expérience API cohésive ?

Une expérience API cohésive c’est :

1. un seul schéma comme niveau d’abstraction,
2. faciliter le développement frontend,
3. se concentrer sur les besoins client auxquels répondre et
4. ne pas refléter la complexité du domaine métier.

GraphQL leur a justement permis cela. En plaçant un schéma, fortement typé, au coeur de son système de requête, il permet d’aligner toutes les équipes selon un seul format de date et de prix, une seule requête permet de récupérer toute l’information nécessaire à construire une page et il n’est plus nécessaire de fouiller dans la documentation de chaque API. De plus, l’outillage complet de GraphQL permet d’explorer ce schéma qui contient toute la donnée du SI, avec l’auto-complétion en prime, ainsi que savoir qui utilise quelle donnée (pratique pour gérer les évolutions). La démo finale nous a permis de visualiser les avantages qu’apporte GraphQL dans un tel environnement.

À la découverte de Bazel par Paul Boutes de Elastic

Conférence dédiée à Bazel, outil de build propulsé par Google et promettant des builds rapides, scalables, extensible et surtout, langage-agnostic (ou multi-langage). Le principe est relativement simple, définir chaque étape de son process de build/test/run de manière “hermétique” afin de le rendre parallélisable et "cachable".

Chaque étape (appelée target) doit être définie dans Bazel comme une fonction pure, prenant donc tous les éléments nécessaires en entrée et produisant une sortie ne dépendant que de ses entrées. Tout est explicite, et cela rend parfois la mise en place difficile (beaucoup de paramètres d’entrée à fournir quand d’autres outils de build ne les nécessitent pas).

C’est un gros frein à l’adoption de l’outil, l’impression d’avoir à faire beaucoup de choses qui sont faites automatiquement dans la plupart des build tools utilisés sur le marché. Bazel s’appuie sur un langage spécifique appelé Starlark (dialecte de Python qui se veut être un “langage de configuration”). C’est à l’aide de ce langage que chaque étape hermétique est décrite.

Pour ces raisons, la courbe d'apprentissage de Bazel est décrite par le speaker comme très abrupte à l’adoption de l’outil. Une fois passé la douloureuse expérience de devoir écrire des étapes de build/test/run pures, les bénéfices sont réels : Bazel analyse le graphe de dépendance des étapes de build et à l’aide d’un système de caching et de détection d’indépendance, il permet d’augmenter considérablement l’exécution des étapes, les parallélisant si possible et/ou utilisant le cache lorsque les inputs n’ont pas varié depuis la dernière exécution.

Ce système de cache est même étendu à la possibilité d’utiliser un cache distant (remote cache). Quelqu’un de votre équipe à déjà construit votre code et vous voulez simplement lancer les tests ? Bazel récupère pour vous le cache uploadé par un autre membre de votre équipe et plus besoin de le recompiler.

La vitesse ne réside pas dans la performance pure de Bazel qui n’est qu’un cadre mais à la mise en place d’une stratégie de caching permise par la contrainte de pureté de chaque fonction (chaque build task) définie. Un autre apport est le fait de pouvoir utiliser le même outil de build pour plusieurs langages dans le même repos, back/front, compilation, transpilation, preprocessing, testing, running, dockerizing .. etc.

A la découverte de la réalité augmentée avec ARCore par Christophe Jolliver et Jérémy Voisin de Apside

Ce talk est présenté par Christophe Jollivet et Jérémy Voisin, tous 2 travaillant chez Apside. Ils viennent nous faire toute la lumière sur ARCore et un petit état de l’art de la réalité augmentée sur téléphone mobile en 2019. En guise d’introduction, ils sont revenus sur les différentes notions qui gravitent dans le monde de la réalité augmentée :

• VR - Virtual Reality ou Réalité Virtuelle qui correspond à un monde totalement virtuel dans lequel on s’immerge via un casque de réalité virtuelle comme l’Oculus.
• _AR - _Augmented Reality ou Réalité Augmentée correspond à une surimpression dans la réalité via par exemple les Google Glass ou notre smartphone.
• _MR - _Mixed Reality ou Réalité Mixte permet d’intégrer un modèle 3D dans la réalité en prenant en compte les obstacles et avec lequel nous pouvons interagir avec nos mains. L’hololens ou le magic leap sont des exemples d’utilisation de la MR.

Comme son nom l'indique, ARCore est un framework de réalité augmentée. Héritier du projet Tango, il est disponible pour Android, iOS, WebRX, et Unity. Parmi les avantages cités, on retrouve :

• La détection rapide de point d’intérêts,
• La détection de la luminosité afin d’adapter au mieux les modèles 3D,
• Une meilleure détection de l’inertie notamment via les capteurs du smartphone,
• La localisation du son via le sdk Résonance Audio,
• Augmented Face pour la détection de visage.

Quand on compare ARCore et ARKit, l’équivalent chez Apple, on remarque que les 2 frameworks fournissent exactement les mêmes services à l’exception d’un mode multi joueurs peer-to-peer présent dans ARKit alors qu’ARCore se base sur un cloud nécessitant une connexion internet. Néanmoins, ARKit n’est lui compatible qu’avec… iOS.

La conférence se termine par une démo sur scène de la projection du Kilimanjaro créé à partir des données GPS d’OpenStreetMap. On constate notamment une très bonne stabilité du SDK ainsi qu’une bonne détection des obstacles. Une autre démo faisant intervenir bugdroid, la mascotte d’Android, a permis de mettre en avant une bonne détection des lumières avec une application assez réaliste des ombres et une très bonne détection des plans.