Devoxx France 2017 : Retour sur les conférences du jour 1 et 2

Du 5 au 7 avril au Palais des Congrès, c’était la 6ème édition de Devoxx France, la conférence des développeurs passionnés.

Nous ne pouvions pas manquer ce rendez-vous incontournable. Une trentaine des Xebians était présente. Voici les retours sur leurs conférences « Coup de coeur ».

Et si votre backend était une Google Spreadsheet ? – Frédéric Camblor

Par Ivan Beauvais

Dans ce Tools in Action, Frédéric Camblor nous présente comment utiliser les feuilles de calcul Google Apps et les outils gravitant autour pour avoir un backend web flexible et gratuit.

En effet,  les données d’une Google sheet peuvent être publiées sur une URL au format JSON. À partir de là, il devient très simple de venir lire ces informations et les utiliser dans une application web. Cette simple fonctionnalité (qu’il faut activer via Fichier -> Publier sur le web) couplée avec les autres possibilités de Google sheet permettent d’arriver à un résultat plutôt cool et pourtant simple à mettre en oeuvre.

Les avantages sont, entre autres  :

• Historique des révisions => gestion de versions gratuit.
• Restriction en lecture/écriture dont la granularité peut aller jusqu’à une colonne de la feuille de calcul (permet donc de limiter les informations publiées).
• Alimentation automatique d’une spreadsheet à partir d’un Google form.
• Utilisation de scripts en Javascript pour ajouter des menus ou des comportements dans votre feuille de calcul.
• Importation/exportation aisée de données.
• Utilisation des librairies existantes pour interagir avec d’autres outils des Google Apps et création de ses propres librairies.
• Création d’une ressource REST qui va lire/écrire dans la feuille de calcul.

Tout cela est présenté, démonstration à l’appui, à travers son expérience de gestion du site bdx.io qui s’appuie sur ces outils :  bluffant tellement ça a l’air simple !

Une histoire de rate-limiting, ou comment les sysadmins de MANGOPAY ont retrouvé le sommeil – Laure Némée, Bertrand Lemasle et Yann Person

Par Cyril Verdier

Dans cette conférence, Laure Némée, Bertrand Lemasle et Yann Person de MangoPay nous présentent pourquoi et comment ils ont mis en place du rate-limiting sur les APIs de leur solution de paiement.

Le rate-limiting consiste à contrôler et limiter le débit d’appels qui peuvent être effectués sur une API particulière. Si vous avez déjà développé avec les services des principaux fournisseurs de cloud comme AWS, vous y avez probablement été confronté du point du vue du client.

Plaçons-nous à présent du point de vue du serveur : l’équipe de MangoPay nous présente leur service et le comportement de leurs clients, d’autres sites qui utilisent leur système de paiement en ligne. Certains font tourner des batchs de synchronisation qui enchaînent les appels à leur API, d’autres font simplement face à un trafic variable avec des pics importants. L’infrastructure a alors la vie dure. Elle fait face à une activité difficilement prévisible et il coûterait très cher à MangoPay de la faire évoluer pour supporter ces périodes exceptionnelles, et surtout le principal problème : la sur-activité d’un client qui mettrait en péril leur système complet et pénalise tous les autres. Autant dire que les astreintes de leurs équipes d’exploitation étaient rarement de tout repos.

Entre alors en scène le rate-limiting. L’équipe de MangoPay nous explique leur approche en partant d’un cas simpliste : un simple compteur sur une fenêtre de temps, appelée « bucket » permet de connaître le nombre d’appels pour un client authentifié, et le bloquer s’il dépasse un seuil configuré. Ils améliorent ensuite le système en ajoutant et combinant des « buckets glissants » plus dynamiques pour éviter un effet «top départ» au moment du reset du bucket et pouvoir prendre en compte des activités de type « burst ».

Leur solution est construite sur Redis, et des scripts Lua qui fonctionnement directement sur Redis, pour un overhead minimal, mesuré entre 1 et 2 millisecondes sur chaque requête. Pour le dépassement, comme leurs APIs sont des APIs REST, le code HTTP prévu à cet effet est retourné : 429 Too many requests. De plus, ils construisent des Headers HTTP pour indiquer au client à quel niveau de consommation il est, et à quel moment est renouvelé le bucket de mesure. Il serait ainsi possible de construire un système vraiment adaptatif, malheureusement les clients ne se prêtent pas encore assez à ce jeu.

Ce n’est pas encore exhaustif, la solution ne s’applique qu’aux appels authentifiés et travaille sur le volume de requête, pas sur les requêtes concurrentes par exemple. Elle intervient au niveau applicatif et donc ne résout pas le problème d’une attaque de type déni de service (mais c’est au final plutôt le rôle d’une autre couche telle qu’un pare-feu).

À chaque exemple, le parallèle est fait avec ce qu’ils avaient effectivement constaté auprès de leurs clients, afin de pouvoir à la fois protéger leurs APIs des comportements réellement incorrects mais améliorables (tels que des batchs sans limitations) mais aussi prendre en compte des surcharges d’activités normales pour lesquelles il faut essayer de ne pas bloquer un service crucial pour le client (par exemple l’effet « BFM TV » où un site relativement modeste doit faire face à un trafic ponctuel très élevé. Cela est loin d’être évident.

Enfin, l’équipe nous résume l’ensemble de leur stratégie pour introduire le rate-limiting :

• Établir une typologie de l’activité des clients, prendre en compte leurs besoins. On pourra ajuster le système client par client pour des activités différentes.
• Être capable de monitorer efficacement les APIs pour chaque client et d’alerter sur les dépassements
• Construire la solution avec un back-office
• Communiquer fortement avec leurs clients en aval pour leur présenter le changement, les accompagner pour migrer certaines approches, en particulier les batchs…
• Faire un test « transparent » de la solution : activer et monitorer le système de mesure en Production, mais sans déclencher le blocage, afin de constater réellement sur une période quelles seraient les conséquences pour les clients.

En conclusion, l’équipe de MangoPay insiste sur l’aspect relationnel avec leur clients, qui a mené à une transition réussie. Ce sont maintenant leurs clients qui sont proactifs et viennent leur porter leurs besoins ou leur demander conseil pour utiliser correctement leurs APIs.
Enfin, ils notent qu’un de leur important concurrent américain a tout récemment mis en place une solution similaire, et détaille des concepts très proches : Stripe : rate-limiters.

Java 9 modulo les modules  – Jean-Michel Doudoux

Par Jérémy Pinsolle

Jean-Michel Doudoux nous fait découvrir les nouveautés de Java 9 en omettant volontairement la modularisation Jigsaw. Le rythme soutenu était plaisant et permettait de balayer un nombre important de JEP.

Changement mineurs

La conférence commence en douceur avec les changements mineurs dans le JDK. Nous apprenons ainsi que lors de l’utilisation de l’instruction try-with-resources, le développeur n’a plus besoin de redéfinir la variable si cette dernière est en réalité finale. Coté interface, il est autorisé d’écrire des méthodes privées dans les interfaces afin de partager du code tout en respectant ainsi l’encapsulation.
Déjà sujet à un warning dans Java 8, le caractère _ (underscore) ne peut plus être utilisé seul comme variable car il devient un mot clé du langage (pour un usage à venir dans les lambdas).

Nouvelles APIs

Qui dit nouvelle version d’un langage dit également nouvelles APIs. La première abordée est la Stack-Walking API qui permet de récupérer la stack trace du thread courant, de naviguer et d’interagir avec ses éléments. En Java 8 et versions antérieures, la méthode Thread::getStackTrace permettait déjà d’obtenir la stack trace mais n’offrait pas la même richesse de filtres, d’assertion et de récupération (stack trace courte ou complète). Grâce à cette API, lors d’une erreur, il est désormais possible de filtrer les classes en supprimant par exemple toutes les mentions de framework/proxies pour ne conserver que les classes métiers de l’application.

Les Reactive Streams font leur apparition au travers de l’API Flow. Cet ensemble minimal (4 interfaces et une classe) capture le cœur du framework Reactive Streams (publish-subscribe).

L’API Process a été enrichie de l’interface ProcessHandle qui permet, entre autres, d’obtenir le processus courant avec ses informations (le PID, le nom du processus, l’utilisateur qui l’a lancé, le chemin, l’utilisation des ressources etc.) et de déclencher du code lors de la terminaison du processus lancé (onExit).

Il est désormais possible de créer en une seule ligne des collections immutables. Oubliez les instructions du genre :

Set<String> s = Collections.unmodifiableSet(new HashSet<String>(Arrays.asList("a", "b", "c")))

et utilisez simplement la méthode of des interfaces Set.of("a", "b", "c"). Attention toutefois, il n’existe pas de type spécifique pour les collections immutables, Jean-Michel Doudoux propose alors d’utiliser une convention de nommage pour différencier les collections mutables et immutables.

Les streams se voient dotés des méthodes takeWhile et dropWhile qui limitent les streams en passant une fonction plutôt qu’une valeur en dur.

Dernière grosse nouveauté présentée, le MRJAR pour Multi-release jar files. Avant Java 9, pour délivrer une classe compilée pour chaque version de Java, il fallait livrer un jar pour chaque version. Désormais, un jar peut contenir plusieurs fichiers .class d’une même classe. La version courante se situe à la racine tandis que les autres versions sont dans META-INF/versions/$NUM_VERSION. Pour être pris en compte, l’instruction Multi-Release: true doit être positionnée dans le fichier MANIFEST.MF.

Mise à jour des outils du JDK

Le but est de simplifier les outils du JDK qui trainent des choses historiques en harmonisant notamment les options de la ligne de commande avec un style GNU (-- pour les options longues, un seul tiret et une lettre pour la version courte). Les répertoires du JDK et du JRE sont réorganisés pour arborer une structure plus simple et cohérente (bin, lib, conf, jmods).

En vrac

– Un REPL (Read Eval Print Loop) est enfin prévu et il se nomme JShell.
– Le versionning sera plus simple en s’inspirant fortement du versionnage sémantique. La version est composée de 4 parties séparées par un point : $MAJOR.$MINOR.$SECURITY.$PATCH.
– La javadoc générée en HTML5, offre une vue par package ou par module jigsaw et implémente une recherche en JavaScript coté navigateur.
– Possibilité de charger les fichiers .properties en UTF8 avec la classe PropertyResourceBundle.
– Support de SHA-3 (SHA3-224, SHA3-256, SHA3-384, SHA3-512).
– Du nettoyage est également fait en marquant les applets comme @deprecated (mais sans date de retrait). Des outils tels que jhat, Java DB, hprof sont retirés au même titre que des exemples et des démo plus à jour.
– Avec la JEP 182, la plateforme Java ne supportera que les 3 versions précédentes.

Java 9 devrait sortir le 27 juillet, en attendant il est possible de télécharger les versions Early Access.

Les race conditions, nos très chères amies – Pierre Laporte (@pingtimeout)

Par Damien Baron

Ah ces chères races conditions… C’est presque avec une certaine tendresse qu’on viendrait à évoquer ce type de bug. Aussi vieux que la JVM, ils sont durs à découvrir, durs à comprendre et durs à tester. La cerise sur le gâteau ?  Ils ne se dévoilent quasiment qu’en production !

Mais qu’est-ce qu’une race condition ? Pour Pierre, elles ne sont rien de plus qu’un mauvais agencement d’opérations subissant les aléas des réordonnancements internes de la JVM ou du CPU. Les réactions face aux races conditions sont généralement de :

• relire le code à l’envie et faire confiance à son intellect pour envisager tous les cas possibles ;
• relancer encore et encore les tests ;
• augmenter artificiellement divers paramètres et espérer reproduire le contexte initial ;
• capituler en se disant qu’après tout, ce n’était pas un bug.

Pas très rassurant n’est-ce pas ? Le manque de confiance dans le code est flagrant et c’est justement sur la confiance que Pierre insiste pour résoudre efficacement une race condition.
Pourquoi manque-t’on de confiance alors ? Car personne ne se place au bon niveau ! Pierre propose alors deux approches.
En tant que concepteur de ce code, vous êtes les mieux placés pour savoir quels sont les enchaînements et états acceptables.

Partant de là, Pierre propose un premier outil, jcstress.

Via des annotations et un système d’acteurs, jcstress provoque des changements de contexte fréquents au sein de votre test. On espère alors que les résultats obtenus pendant ce « chaos volontaire » resteront dans les limites décrites par les annotations attachées. Simples dans leur écriture, les tests jcstress ont pour principal avantage de forcer le développeur à poser explicitement les états et transitions qu’il souhaite obtenir.

Pierre enchaîne ensuite sur la méthode « The box ». Commençons par modéliser notre chaîne de traitement sous la forme de boîtes (décidément que de boîtes dans cette présentation). On distingue quatre entités avec chacune des responsabilités exclusives :

• Les acteurs.
• L’application.
• La JVM.
• Le système.

De manière naturelle, nous tentons de reproduire les races conditions via des moyens situés au niveau des acteurs. C’est une erreur car on occulte alors la part des autres éléments. Pierre nous suggère donc quelques pistes pour arriver à influer sur les autres composants.

Au niveau Application, une méthode volontairement laissée vide mais surchargeable peut rendre des précieux services. Dans un contexte de test, injecter une temporisation de threads (sleep, yield ou autre) peut suffire. Une méthode vide est indolore dans le code déployé en production mais laisse cependant une porte d’entrée pour introduire le grain de sable qui fera tout gripper.

Au niveau de la JVM, un outil formidable existe : il s’agit du Garbage Collector ! Par conception, le GC entraîne un phénomène de « stop and go » pendant son passage. Avant la collecte, un safepoint est créé. La collecte terminée, le safepoint est levé et les threads reprennent leurs activités. À ceci près qu’un nouvel ordonnancement est appliqué. Or c’est justement ce changement non déterministe qui favorise l’apparition des races conditions.

Pierre se livre alors à un calcul simple. Avec une activité de 1 Go / s et un espace alloué de 2 Go, la Young Generation se remplira en 2s. Le GC sera déclenché quasiment au même rythme et vous obtiendrez grossièrement 30 réordonnancements de threads par minute. Mais que se passerait-il avec une Young Generation de taille plus réduite ? Avec 10 Mo le remplissage passe à 10 ms pour un temps de collecte de 1 ms. Sauf que maintenant, on frôle les 5500 réordonnancements par minute ! Ce sont autant d’occasions d’observer une race condition !

En conclusion, Pierre nous a montré que, en pensant hors de la boîte et en adoptant un point de vue plus global, les races conditions ne sont pas forcément une fatalité. On peut les combattre efficacement à condition de savoir où intervenir et en ayant bien posé les états et transitions acceptables de son système. Pas étonnant alors que cette conférence ait fait un carton chez les Xebians.

10 méthodes pour rendre heureux les développeurs, la 7ème va vous étonner ! – Cyril Lakech et Romain Linsolas

Dans cette conférence, les deux speakers (développeurs chez Axa et Société Générale) proposent leurs méthodes pour améliorer le quotidien des développeurs. Une bonne partie est déjà bien enracinée dans l’ADN de Xebia. Je vous laisse lire tout ce que j’ai retenu de la conférence et n’hésitez pas à réagir sur les différents points !

Selon un questionnaire de Stack Overflow, environ 60% des développeurs sont à l’écoute du marché, donc ouverts aux nouvelles opportunités. L’enjeu pour les entreprises est alors de ne pas seulement recruter les meilleurs développeurs mais (surtout) de les garder. Pour y arriver voici une courte description des 10 méthodes proposées par les speakers :

1. Recrutement, investir dans le recrutement. Pendent l’entretien il est important de commencer par la présentation de la vision et des valeurs de l’entreprise. Les speakers proposent également de parler rapidement et ouvertement de la rémunération. Pendant la partie technique, ils encouragent d’échanger avec le candidat sur ses pratiques de développement (TDD, revue de code), ses outils et à poser des questions sur les choix des architectures et des langages. Cela permettra d’impliquer la personne et d’évaluer plus efficacement ses connaissances. Évitez aussi les exercices sur tableau blanc et favoriser les outils de programmation en ligne. Une des pratiques en vogue est de proposer au candidat de passer une demi-journée sur place avec l’équipe en pratiquant le pair-programming, en impliquant le candidat dans la revue de code, les tests unitaires et pourquoi pas à la fin de la journée en lui proposant de prendre un verre de façon moins formelle.
2. Perspective de carrière, démontrer les possibilités d’une expérience durable au sein d’une entreprise avec plusieurs axes de développement. Par exemple, si la raison de départ d’un employé est l’envie de changer de technologie ou de métier, le rôle de l’entreprise sera de lui donner la possibilité de multiplier ses connaissances dans différentes technologies et métiers en interne pour devenir pluri-disciplinaire et de valoriser ces doubles compétences en proposant des projets innovants et stratégiques. Selon les propos des speakers, “apprendre c’est notre métier”. Il est donc fortement conseillé de donner du temps aux développeurs pour se former.
3. Environnement de travail, Il est déconseillé de proposer des open spaces, sauf s’ils peuvent être personnalisés et aménagés de façon plus conviviale. Les speakers proposent des bureaux flexibles, voire même des bureaux debout. Pas d’ économies non plus au niveau du matériel et des logiciels : 1h de productivité perdue par jour, c’est au final 30 jours gâchés par an ! Il est important de donner la confiance aux employés tant au niveau du choix des logiciels que sur la question du lieu de travail (home office).
4. Organisation de travail, on voit de plus en plus souvent des feature teams. Ce sont des petites équipes (pizza team : pour qu’une pizza soit suffisante à partager entre les membres de l’équipe), qui regroupent plusieurs profils différents (les développeurs, les métiers, etc.). Le but de l’équipe est commun permettant ainsi de mieux responsabiliser des membres de l’équipe à chaque étape du développement.
5. Software Craftsmanship, les speakers citent le craftsmanship manifesto et soulignent l’importance des livrables de qualité.
6. Ouverture aux technologies, avec l’ensemble de technologies existantes et arrivant sur le marché, on peut se perdre dans la maintenance. Ils proposent donc d’utiliser le techno radar. Il s’agit de structurer et décrire les technologies disponibles dans l’entreprise. Ils passent par plusieurs étapes : une techno est évaluée par une personne par rapport à son coût d’intégration, UX, analyse SWOT et ensuite soit elle est mise en phase assess (ensuite reinforce et excel) soit elle est dépréciée.
7. Les petits plus, pizza, café, baby foot ;)
8. Communautés, dans les feature teams proposées au point 4, l’équipe est composée des différents profils. Néanmoins, pour que des profils similaires puissent échanger, ils proposent de créer des communautés dédiées pouvant durer de 6 mois à 1 an. Cela permet d’échanger avec les gens qui ont probablement rencontré les mêmes bugs, échanger plus en détails sur les choix d’algorithme, etc. Il est important que les communautés aient un temps dédié, un espace délimité et l’ensemble des outils collaboratifs à disposition.
9. Contribution à l’open source, la possibilité d’ouvrir le code en interne permet de capitaliser sur la connaissance et les sources déjà développées ainsi que rationaliser le développement.
10. Participer aux événements,  BBL, meetups, conférences internes, sponsoring. Autant de possibilités de rencontrer des nouvelles personnes, de s’exercer à parler en public, de tester un nouveau sujet et d’agrandir son réseau.

Un bot pour gérer l’agenda de ta conférence – Guillaume Laforge

Lors de cette conférence, Guillaume Laforge a proposé une découverte d’un service Google api.ai pour construire des bots intelligents. Pour commencer, on découvre une application qui a été créée à l’aide de ce service pour le jour de pi (le 14 mars – 3.14). Un petit robot répond donc à la première question de la démonstration : “C’est quoi le dixième digit de pi ?” et au bout d’un moment, on entend la réponse du robot. En utilisant le même framework, G. Laforge présente les étapes de la création d’un bot pour gérer nos agendas Devoxx.

Il y en a 3 :

• le design,
• le développement
• et le déploiement.

Les concepts de design lient en découpage des dialogues en intentions, entités et contexte. Pour un simple dialogue comme “A: I want to eat some bananas B: How many bananas?”, on décompose en entité : bananes, intention: eat et contexte : la phrase d’avant.

Dans la partie design, il est essentiel de bien définir la persona de notre bot donc son vocabulaire, rôle, maturité, la durée des dialogues et autres détails qu’on peut consulter ici. Pour un exemple de bot qui gère l’agenda, la voix de bot est celle d’une femme de 30 ans, plutôt sérieuse, qui parle en anglais. La partie développement, faite en node.js contient l’ensemble des méthodes d’analyse syntaxique pour définir les parties des dialogues (avec des built-in fonctions ask, tell qui facilite la tache). Ensuite, le déploiement dans api.ai nécessite de définir les composants du bot. Les entités seront à la fois le type de conférence (talk, hands-on, etc.) et les salles (amphi, 242, etc.). La liste exhaustive des salles et type de talks a été renseignée, ainsi que les synonymes. Le contenu des talks, récupéré du site des CFP constitue les intentions.

Dans la démo, Guillaume Laforge demande au robot “Where is the next talk about bots?”. Le robot répond “Sorry, there is no talks about boats”…  Après plusieurs essais le robot comprend et répond correctement. Le service peut être intégré dans nombreuses applications : Google home, Slack, Messenger, etc. Je vous encourage à le tester.

Introduction à la détection d’anomalies avec Graphite – François Nollen

Par Giulia Bianchi

François Nollen commence son quickie en disant tout de suite qu’il ne faut pas s’attendre à du Machine Learning pendant son talk. Bizarre – je me dis – mais en même temps je deviens encore plus curieuse de découvrir de quoi il s’agit.

Graphite est un outil de monitoring dans lequel on peut stocker des séries temporelles de types divers et variés et qui permet de les rendre sous forme de dashboards. Les dashboards sont très visuels et peuvent communiquer beaucoup d’information, mais voici le piège, c’est difficile à surveiller !

Alors, une solution très simple nous vient à l’esprit. Mettons des alarmes, et dès qu’un signal dépasse un certain seuil, nous sommes alertés. Ce type d’alarme est effectivement très facile à mettre en place, il suffit de définir les seuils et un scheduler (ordonnanceur) qui scanne les signaux à intervalles réguliers. Par contre, cette détection des extrêmes présente pas mal d’inconvénients : la maintenance de seuils n’est pas optimale, les tendances périodiques ne sont pas prises en compte, et il y a beaucoup de faux négatifs.

Pour montrer le potentiel de Graphite, le speaker nous présente une démo de cerebro, un outil développé chez Voyage-SNCF, et entièrement disponible sur GitHub, pour manipuler Graphite et fournir une interface graphique user friendly. Une fois les données chargées, c’est alors possible de créer des alertes classiques basées sur des seuils, ainsi que de mettre en place un système plus complexe qui consiste à enchaîner des fonctions intégrées dans Graphite. Pour la démo, il nous a montré l’usage de la fonction holtWintersAberration, qui fait une prédiction basées sur un historique de notre choix, et donne l’écart positif ou négatif par rapport à la prédiction.

Le retour des utilisateurs apparemment est positif, il pourrait être intéressant de l’essayer avec l’ajout du Machine Learning !

Kit de survie pour l’IoT façon DIY – Laurent Huet

Par Giulia Bianchi

Laurent Huet présente cette année un topo sur les possibilités de bidouille, comme il le dit lui-même, dans le domaine de l’IoT. Sa présentation est assez complète, et fait un tour en trois chapitres – construire, développer et débugger –  de l’horizon IoT. Les slides de sa présentation sont disponibles.

Construire

Les novices découvrent qu’il n’y a pas que Raspberry Pi et Arduino. Il existe toute une série de cartes, plus ou moins similaires et plus ou moins bon marché. Nous découvrons alors le Odroid C2, comparable au Raspberry Pi 3 avec 2 GB de RAM mais ni de wifi ni de bluetooth embarqués, et le NanoPi NEO 2, tout petit et vraiment pas cher ! En ce qui concerne les contrôleurs, il a bien sûr parlé de la famille Arduino, ainsi que des ESP, en particulier du ESP8266 et du ESP32. Ces derniers ont tous les deux le wifi intégré et même le bluetooth dans le cas de l’ESP32. Dans les deux cas, on parle d’un prix avoisinant 3 ou 4$ à l’unité ce qui rend le hardware vraiment accessible au grand public.

Un point d’attention est mis sur l’alimentation de ces cartes. Pour maximiser leurs performances et leur durée de vie – et prévenir de brûler la carte – il conseille de bien choisir l’alimentation. Opter pour une alimentation plutôt puissante, 2A à minima, 3A si possible, est une bonne pratique, aussi bien que prendre en considération les différentes caractéristiques électriques d’input et output.

Une autre bonne pratique consiste à ajouter une résistance. Laurent Huet a montré un exemple très parlant pour faire comprendre à quoi cela peut servir. À ce propos, il a cité un tweet de Henri Gomez qui dit : “ une led sans résistance, c’est comme du code sans coverage. Ça peut marcher un temps, mais attention au refactoring “. Bref, elle a une fonction de protection.

Le dernier point du premier chapitre touche à la carte SD. Elle se révèle être une technologie fragile pour laquelle il serait mieux de limiter au maximum le nombre d’écritures. Le speaker propose donc une stratégie pour avoir la SD en mode read only.

Développer

Arduino a mis à disposition un IDE, Arduino IDE. Même s’il s’est amélioré par rapport aux premières versions, il reste assez simple et loin de l’expérience que l’on peut avoir avec une IDE classique, type IntelliJ. Un nouveau projet voit le jour, PlatformIO, et il est bien prometteur. Pour la programmation de micro-contrôleurs, il existe des libraires qui permettent d’écrire du firmware en langage “ haut niveau “ plutôt qu’en C par exemple, permettant ainsi de coder dans son langage préféré. C’est le cas de Firmata et Micro Python.

Débugger

Laurent Huet nous a parlé de deux types de problème : les pannes réseau et les problèmes de montage.

La bonne nouvelle est que pour les pannes réseau la solution est facile ! Sur la quasi totalité des cartes, il y a un lien série (UART) disponible que l’on peut utiliser pour connecter un convertisseur UART/USB et communiquer avec notre carte.

Pour les problèmes de montage, la solution est un peu plus compliquée, et surtout plus coûteuse. Les oscilloscopes classiques sont chers est souvent surdimensionnés, exception faite pour le DSO Nano. Par contre, pour pousser le concept de DIY à la limite, c’est aussi possible de construire son propre oscilloscope à partir des composants élémentaires. On divise le prix par 4, mais là c’est vraiment du bricolage !

Migrating to microservice databases: from relational monolith to distributed data – Edson Yanaga

Par Ilja Kempf

Nous en sommes convaincus, les microservices sont une approche architecturale valide voire nécessaire pour de nombreux systèmes. Pourtant le terme microservices n’a que six ans. Qu’en est-il alors des systèmes d’informations un peu « plus vieux » ? Faut-il revoir leurs architectures ? Non. Enfin, pas toujours. Soyons clairs, les architectures modulaires existaient bien avant les microservices. Mais force est de constater que nombre de systèmes d’informations sont plus monolithiques que modulaires et qu’ils n’arrivent pas à faire face à l’épreuve du temps.

Aux yeux d’Edson Yanaga, le plus gros avantage de faire du microservice est de réduire les cycles de mise en production. L’objectif est de raccourcir la boucle de feedback et la taille (en lignes de code) des mises en production afin de les rendre plus sûres. Il existe un frein à cette approche de déploiement continu : le downtime. Déployer en production fréquemment c’est bien, couper le service l’est beaucoup moins.

1ère étape : Zero downtime

Il n’y a qu’une bonne solution, le « zero downtime ». Edson nous présente alors le « Blue/Green deployment » qui permet le déploiement d’une nouvelle version sans downtime au travers d’un proxy orchestrateur.

• Une ancienne version, dite Blue, tourne en production. Tout le trafic est dirigé vers elle.
• Une nouvelle version, dite Green, est déployée et tourne en parallèle.
• Le proxy redirige le nouveau trafic vers la version Green.
• Une fois toutes les connexions vers Blue terminées, nous l’arrêtons.

La technique est simple mais suppose que les versions Blue et Green soient compatibles et utilisent la même base de données. Comment faire pour y apporter une quelconque modification de schéma ? Pas de solution magique, il faut faire la migration au travers de nombreuses étapes rétrocompatibles.

Prenons par exemple un scénario visant à modifier une colonne d’une table (renommage, changement de type ou de contraintes etc.). Chaque étape du scénario se transforme en mise en production :

• Ajout d’une colonne avec les propriétés cibles ;
• L’application écrit maintenant dans l’ancienne ET la nouvelle colonne (de façon transactionnelle) ;
• Les données de la colonne existante sont copiées vers la nouvelle colonne. Attention, selon les données, il faut le faire par petits lots pour ne pas verrouiller la table (downtime) ;
• L’application lit (et écrit) dans la nouvelle colonne ;
• Suppression de l’ancienne colonne si tout c’est bien passé.

Les étapes sont similaires pour l’ajout d’une colonne, la suppression d’une colonne, le renommage d’une table etc. On se rend vite compte de la complexité de la chose. Pour espérer y arriver, il faut donc obligatoirement automatiser le déploiement du code et les migrations de bases. Pour les migrations de bases de données, il est conseillé d’utiliser des outils comme Flyway ou Liquidbase pour générer les scripts (de différence) automatiquement.

2ème étape : Séparer les bases

Maintenant que la mise en production est automatisée et sans downtime, nous pouvons commencer à découper le monolithe. C’est la séparation de la partie base de données, plus difficile que le code, qui est présentée durant cette conférence. Dans la mesure où nous souhaitons procéder de façon prudente et incrémentale, comment extraire une partie de la base de données, utilisée par un nouveau microservice, alors que le monolithe existant utilise toujours cette donnée ? Il faut synchroniser les bases. La synchronisation peut se faire dans un sens quelconque avec une consistance forte ou éventuelle selon les besoins.

Pour ce faire il existe de nombreux outils à base de DBlink (shared table, database views, database triggers etc.) ou des outils style ETL/BI. Si par chance votre monolithe est basé sur de l’event sourcing ou similaire, vous pouvez faire la synchronisation au travers de ces événements. Une autre solution, particulièrement efficace, est le Change Data Capture qui vous permet de générer un flux d’événements traduisant les modifications de données à partir du commit log de votre base de données. C’est une technique de synchronisation asynchrone (consistance éventuelle) qui a l’avantage d’être simple et systématique, un outil tel que Debezium vous permettra de vous connecter à la majorité des bases du marché.

Raconte-moi X.509 : anatomie d’une autorité de certification – Charles Sabourdin et Jean-Christophe Sirot

Par Ilja Kempf

Charles Sabourdin et Jean-Christophe Sirot nous présentent le standard X.509 qui définit un format pour certificats à clé publiques. Ces certificats, aussi nommés certificats d’identité, sont entre autres utilisés par le protocole HTTPS. Un certificat X.509 est constitué d’une identité (nom de domaine, raison sociale, adresse etc.), d’une clé publique et d’une signature. C’est la signature, apposée par une autorité de certification, qui garantit la validité du certificat. Ainsi, si l’autorité en question est une autorité de confiance alors le certificat sera considéré comme sûr.

Le standard repose donc sur la confiance entre le client et l’autorité de certification émettrice du certificat. Le format X.509 prévoit une hiérarchie d’autorité de confiance constituée d’autorités racines et d’autorités dites intermédiaires. Les autorités racines ont la possibilité de faire entrer de nouvelles autorités (intermédiaires) dans le cercle de confiance. Toute autorité du cercle de confiance pourra émettre des certificats finaux. Un certificat a une durée de validité limitée dans le temps. Les autorités de certifications mettent aussi à disposition des listes de révocations pour les certificats invalidés après leurs émissions.

Infrastructure de gestion de clés (IGC)

Le réseau de confiance repose sur les autorités racines. Ce sont ces dernières qui construisent le réseau en émettant des certificats signés. Mais alors, par quels moyens et sous quelles conditions sont émis ces certificats ?

L’obtention d’un certificat est une procédure administrative usuellement payante. Il faudra prouver l’identité de la personne, physique ou morale, qui souhaite acquérir le certificat. La génération de la clé (privée), qui servira pour signer les certificats, est faite durant la « cérémonie des clés ». Cette dernière doit suivre un protocole bien précis (présence d’un huissier, témoins de confiance, sécurité des locaux etc.) avec du matériel adapté. Il existe des exceptions telles que Let’s Encrypt, autorité de certification racine qui émet des certificats gratuitement avec une procédure de vérification légère. Le protocole HTTPS en devient plus accessible, ce qui démocratise l’utilisation de communications chiffrées. Mais le niveau de confiance dans l’identité de la personne, physique ou morale du certificat est considérablement plus faible.

Une aventure ultrasonique – Hubert Sablonniere

Par Olivier Ghizzo

Hubert Sablonniere nous présente comment il a répondu avec succès à la question : « Est-il possible de faire communiquer deux pages Web sur deux machines différentes sans serveur ? ». Du vrai serverless donc, réalisé dans le cadre d’un projet personnel.

La conférence, très bien bien menée, démarre sur une note de musique. Le thème d’Ocarina of Time est joué en live par Hubert via une manette de Snes avec peu de fausses notes. S’ensuit une introduction expliquant comment il en est venu à s’intéresser à l’API webaudio.
Tout a commencé par un constat. Les outils de présentation (Keynote et Powerpoint) ont un défaut, il y a trop d’espace vide dans le mode lecture. Il se lance donc dans le développement d’une application web qui exploitera toute les zones visibles. Un autre problème se dresse devant lui. Il souhaite pouvoir afficher ses slides et ses notes sur différents écrans. Son objectif devient alors de pouvoir partager sa présentation entre deux navigateurs sur deux machines.

Il étudie différentes solutions de communication :

• L’utilisation de websocket, mais cela implique d’avoir constamment un serveur faisant le relais entre les deux pc.
• L’utilisation de WebRTC, c’est mieux, un serveur n’est utilisé que pour la mise en place de la communication, la suite se déroulant en connexion directe

Comment faire pour se passer définitivement de l’utilisation d’un serveur ?
Hubert évoque évidement la possibilité d’utiliser des pigeons pour établir la connexion mais le dressage et la latence l’inquiètent un peu. Il s’est souvenu que la chromeCast peut émettre des ultrasons pour connecter les smartphones environnants. Il a choisi l’API webAudio pour émettre et enregistrer des sons via les navigateurs, il va donc transmettre les données permettant d’établir la connection WebRTC via des ultrasons, et ça fonctionne !

Pourtant très enrichissant l’aspect technique n’est peut être pas le plus important du slot. En effet, Hubert démontre à quel point il est intéressant de ne pas hésiter à se lancer dans des projets personnels. Il n’est pas grave de ne pas les finir ou d’y passer peu de temps, l’essentiel est de réfléchir sur un sujet qui nous plait sans se soucier du résultat ou des contraintes de production. À titre d’exemple, pour ce projet, Hubert a abordé des notions aussi diverses et variées que : WebRTC, websocket, l’infra réseau, les fréquences sonores, l’API webaudio et même appris à jouer de l’ocarina.

Un langage que tout le monde ELM ! – Jordane Grenat

Par Julien Tard

• Langage typé et fonctionnel.
• Interopérable avec JS.
• Plus performant que les frameworks front du moment.
• Pas de runtime exception.

Attendez je répète : pas de runtime exception. « Qui peut en dire autant de JS » lance-t-il !

• Syntaxe extrêmement concise : pas de parenthèses, accolades ou virgules superflues.
• Typage fort qui permet d’éviter beaucoup d’erreurs au runtime.
• Obligation de couvrir tous les cas pour les if et switch case par exemple.
• HTML codé directement en ELM à la manière de JSX.
• Erreurs de compilation extrêmement précises et didactiques.
• Et comme promis sans l’ombre d’ une runtime exception.

Bref, un langage très convainquant ! Le fait que cela soit un langage fonctionnel typé résout des problèmes de test et de maintenabilité. Lorsque ça compile, ça fonctionne.