Pour cette nouvelle édition de Devoxx France, les Xebians étaient présents. Ils vous proposent à travers cet article de découvrir leur avis sur certaines des conférences présentées.
Découvrez d’ores et déjà leurs
Keynote
French Road
Pendant la keynote, Emmanuel Pesenti nous a présenté une initiative citoyenne, « French Road », dont il est Président du conseil d’administration. Il s’agit d’un projet de construction d’une nation numérique européenne. L’Europe et donc la France ont pris beaucoup de retard dans le développement numérique. Le projet consiste à créer une identité numérique de chaque citoyen qui se matérialise par une carte à puce qui leur permettraient d’accéder aux divers systèmes publics : voter, gérer les paiements des impôts, des dossiers médicaux, inscrire les enfants à l’école et autres.
Emmanuel Pesenti liste les nombreux bénéfices :
- Simplification de la vie de 500 millions d’usagers européens.
- Concentration des efforts sur la création de valeur ajoutée humaine et de plaisir.
- Accélération de la création de valeur.
- Baisse des coûts de gestion administrative liés aux redondances.
- Endiguement du mauvais usage de l’argent public.
- Plus de citoyens aux urnes avec le e-Vote possible.
- Le modèle européen capable d’inverser le rapport de force avec les GAFA et BATX.
- Ajout d’un degré de liberté dans l’orientation des politiques publiques.
Le projet fait aussi face aux grands défis, comme la centralisation et la sécurisation de nombreuses données. Plus d’information sur le site officiel du projet French Road.
La vidéo est disponible ici.
L’ordinateur quantique
David Rousset, «Program manager» chez Microsoft a proposé durant ce talk une introduction à l’informatique quantique.
Vous en entendrez surement parler de plus en plus. Microsoft a d’ailleurs commencé à former ses développeurs à la programmation quantique.
Mais pourquoi l’informatique quantique ? Pour mieux le comprendre il faut revenir à la loi de Moore. Cette loi selon laquelle le nombre de transistors augmenterait de façon exponentielle à intervalle de temps régulier. Une loi qui se confirme depuis son énoncé en 1965 par Gordon Moore.
En effet, en 1971, un transistor faisait 10 microns de large soit
le centième d’un millimètre. En fin 2017, nous avons atteint la taille de 10 nanomètres pour un transistor et on compte désormais 10 milliards de transistors sur un seul microprocesseur.
Le problème, c’est que cette loi atteint peut-être ses limites car il deviendra difficile de fabriquer des transistors plus petits. Car en effet, en dessous de 10 nanomètres, les lois de la physique classique changent, laissant place aux lois de la physique quantique. Plusieurs s’accordent donc sur le fait que l’ordinateur quantique pourrait être la solution à ce problème.
Le calculateur quantique repose sur 4 principes fondamentaux :
- Principe de superposition : un système de type entrée-sortie est linéaire.
-
Une interprétation probabiliste.
-
La dualité onde-corpuscule :
principe selon lequel tous les objets physiques peuvent présenter parfois des propriétés d’ondes
et parfois des propriétés de corpuscules.
-
L’état quantique :
ce qui quantifie ce que l’on peut savoir d’un système quantique.
-
L’effet tunnel : c‘est un effet purement quantique, qui ne peut pas s’expliquer par la mécanique classique.
La physique quantique nous ouvre donc les portes d’un nouveau monde, élargissant ainsi le champs des possibles.
Vous pouvez dès aujourd’hui vous essayer à la programmation quantique avec quelques liens pour vous aider à démarrer :
- Microsoft Q# – Quantum development Kit
- Google Quantum Computing Playground
Pour conclure, David nous a initié tout en douceur et de façon claire au monde de l’informatique quantique tout en nous faisant prendre conscience de son importance dans un futur pas si lointain.
Découvrez vite la vidéo de sa conférence.
Roberto Di Cosmo, docteur en informatique issu de l’école normale supérieure de Pise, nous parle de son association Software Heritage, une association à but non lucratif qui a pour objectif de récolter, classer et archiver la totalité des codes sources libres présents sur internet.
Il nous rappelle que le code, au-delà du fait d’être exécuté par une machine pour être une interface entre l’utilisateur et un document numérique, représente une forme de littérature du XXIe siècle.
Un code source, avant d’être exécuté doit être rédigé pour être lu.
Grâce au mouvement du logiciel libre, les sources ne sont plus jalousement stockées dans les coffres forts des entreprises et détruits
Di Cosmo donne en exemple l’algorithme permettant le calcul de la racine carrée inverse rapide, qui est communément attribué à John Carmack le créateur de Doom, bien que ce dernier dément et attribue la paternité de ce code à Terje Mathisen
Cet exemple illustre parfaitement le principe d’un code source qui a évité de sombrer dans l’oubli grâce au partage et à la mise en ligne sous licence open source.
Il donne aussi l’exemple du programme ayant permis le lancement de la mission Apollo 11 auquel Margareth Hamilton a contribué. moins de 60.000 lignes de codes qui ont été retrouvées, numérisées et qui sont désormais tous, car sur Github.
Le dernier exemple est le noyau Linux, qui est libre, et qui représente approximativement 20 millions de lignes de code.
Le code source contient la connaissance
Cependant, le problème avec le code source, c’est qu’il n’existe aucun catalogue central, tout le monde utilise des gestions de sources différentes (sourceforge, google code, gitlab, gitorious, github, bitbucket. etc.). Actuellement le meilleur moyen de trouver un code source, c’est de demander à un moteur de recherche générique (Google, Qwant)
De plus, une donnée numérique est une chose extrêmement fragile, une clé USB perdue, un accident dans un datacenter ou une attaque suffit à entrainer la destruction de données, ou bien même la fermeture pure et simple d’un outil par son propriétaire, tels que gitorious ou google code, qui conservaient respectivement 100.000 et 1.500.000 repos à leur fermeture.
Le speaker part d’un constat simple : il n’existe pas d’infrastructure de recherche pour récolter et analyser les codes sources existants.
La mission de l’association Software Heritage est le suivant : collecter, préserver et partager le code source de tous les logiciels existant, afin d’améliorer les codes futurs.
À l’heure actuelle, l’association a récupéré 80 millions de projets, qui représentent 4 milliards de fichiers pour 1 milliard de commits.
Pour terminer, il nous explique leur façon de fonctionner : du code et rationaliser le tout afin de ne pas avoir besoin d’avoir la bonne version de git ou de mercurial. Leur objectif est la conservation à long terme et l’absence de dépendance à une version d’un logiciel qui évolue dans le temps.
Il termine cette présentation avec quelques chiffres : Software Heritage représente de données brutes ainsi que 10 To de graphes.
Cette présentation a permis de mettre en lumière ce point bien souvent ignoré qui est la transmission de l’histoire du code, histoire à laquelle nous contribuons tous à plus ou moins grande échelle.
La vidéo est maintenant disponible.
Web, JS, HTML5 et UX
Quickie – Gatsby, le magnifique générateur de site statique !
Devoxx n’est pas juste une conférence dédiée à l’écosystème des applications ou sites dynamiques mais elle propose aussi des conférences sur les sites statiques ! Mais qu’est-ce qu’un site statique ? Il s’agit d’un site n’ayant pas de backend, c’est-à-dire n’ayant pas de contenu “dynamique”, comme une page de login par exemple. Ce type de site se prête bien aux blogs, à la documentation ou à un site “vitrine” d’une entreprise. L’offre est éclectique en la matière et s’est stabilisée autour de la JAM stack. JAM se veut l’acronyme de : Javascript – API – Markdown. Ce n’est pas une stack comme serait la MEAN stack par exemple mais plus un ensemble de bonnes pratiques permettant de générer des sites statiques qui se veulent :
- performants : les pages sont générées côté serveur (Server-Side Rendering),
- sécurisés,
- scalables.
Ainsi, Florent le Gall présentait un nouvel arrivant dans ce domaine: Gatsby. Ce générateur repose sur la stack suivante : React – GraphQL – N’importe-quelle-source-de-contenus-comme-un-CMS-ou-Markdown qui se veut dans l’air du temps.
Le speaker est ensuite entré un peu dans le détail d’utilisation du framework via du live coding. Nous avons pu voir que Gatsby reposait sous un système de Page et de Templates prenant la forme de composants React.
La présentation fut rafraîchissante. Même si le speaker n’a fait qu’effleurer la surface du fait du type de présentation (un quickie), cette dernière a été suffisamment bien amenée et construite pour donner envie d’essayer Gatsby.
Découvrez la vidéo ici.
Conférence – NodeJS: 5 bonnes raisons pour lesquelles vous devriez y jeter un oeil (même si vous êtes un dév Java)
La conférence animée par Alexandre Victoor et Thierry Abaléa, développeurs chez Fluo, a eu non seulement pour but de présenter la plateforme NodeJS à ceux qui ne la connaissent pas encore, mais aussi, et surtout de convaincre les développeurs Java qui ont souvent une mauvaise image de Javascript de s’intéresser à cette plate-forme.
Pour atteindre ce but, les speakers vont présenter, ce qui pour eux sont les 5 principales raisons pour lesquels, tout le monde devrait s’interesser à NodeJS :
1- Simplicité
Une fois que les bases du langage JavaScript sont comprises, la comprehension de NodeJS ne pose pas de grands problèmes. Par exemple, pour exécuter un fichier : une simple commande « node » suffit. Le système de modules de NodeJS est lui aussi très simple et les modules de base ont été conçus pour être minimaux.
Ils ont ensuite insisté sur ce qui est peut-être la seule complexité de NodeJS : le fait que la plupart des opérations se fassent de manière asynchrone. Il s’agit en fait de la motivation principale du developpement de NodeJS : il a en effet été conçu pour être la solution la plus simple permettant à ce qu’aucune entrée/sortie ne soit bloquante, et permettre ainsi des applications hautement performantes. Sous le capot, NodeJS repose donc principalement sur la combinaison du moteur V8 pour éxecuter rapidement du Javascript, et la bibliothèque libuv qui permet d’implementer les opérations asynchrones.
2 – Légereté
Autre grand avantage de NodeJS est sa lègereté. Son empreinte mémoire est faible, et il est rapide à démarrer. Il est aussi basé sur un seul thread. Ce qui peut être problématique dans certains cas d’usage, car on veut parfois maximiser l’usage des CPUs. Mais heureusement NodeJS possede les modules child_process et cluster qui permettent tout de même de faire des programmes multi-threads, même si ce sont en réalité des programmes multi-processus.
3 – Le JS moderne
C’est peut-être le point le plus critiqué par les développeurs back : le langage JavaScript, lui-même. Ce langage est la souvent la cible de nombreuses moqueries : il est non-typé, il a des conditions d’égalité confuses([] == 0, 0 == « 0 », mais [] != « 0 »), oblige souvent à coder salement, etc. Mais, ces dernières années, JavaScript s’est beaucoup amélioré : les dernières normes de JavaScript ES6 et ES2018 on apporté de nombreuses fonctionnalités pour coder proprement.
Mieux : de nouvelles solutions permettent de typer JavaScript. La première est Flow de Facebook, qui est une sorte de type-checker de Javascript : il analyse le code afin de découvrir des bugs en inférant les types des différentes variables de Javascript.
La seconde est TypeScript qui est carrément une extension de Javascript permettant au développeur de typer le code Javascript. Il lui ajoute aussi de nombreuses fonctionalités : des interfaces, des décorateurs, etc…. Par exemple, pour les javaïstes qui aiment le codage d’API » à la Spring Boot« , c’est-à-dire basé sur des annotations, il existe pour NodeJS, le framework Nest qui repose sur les mêmes principes et qui utilise les décorateurs de TypeScript pour remplacer les annotations de Java.
4 – L’écosystème
L’écosystème autour de NodeJs est énorme surtout vis-à-vis de sa relative jeunesse (Ryan Dahl publie NodeJS en 2009). Ainsi, un programmeur NodeJS dispose des outils suivants :
– gestion des dépendances : npm ou yarn,
– formattage de code : Prettier,
– outils de tests : Jest,
– IDE : plusieurs, mais les speakers ont une préférence pour Visual Studio Code, qui dispose d’un environnement Javascript et TypeScript complet (avec debugger),
– Debugger/Profiler : il y a un programme que beaucoup de gens possèdent et qui peut servir de debogueur, de profileur à un programme Javascript : Chrome ! (Avec la page « chrome://inspect« ),
– Framework Web : Express (qui dispose aussi de nombreux plugins) et Koa,
– Bases de données : NodeJS peut se connecter à quasiment toutes les bases : aussi bien les bases relationnelles (SQL Server, PostgreSQL, Sqlite, Oracle, MySql) que les autres (Redis, ElasticSearch, Cassandra),
– Et aussi : il peut s’intégrer avec Kafka, RabbitMQ, etc. Il y a des modules pour faire des API GraphQL ou REST,
C’est à ce moment-là de la réunion que les speakers indiquent que NodeJS n’est pas non plus un « silver bullet », NodeJS souffre de quelques problèmes. En particulier, pour certains besoins spécifiques de performance, l’architecture de NodeJS pourrait ne pas être adaptée.
5 – Et surtout…
Les deux animateurs donnent la raison ultime pour s’interesser à NodeJS : Quand une technologie émerge, tout developpeur un tant soit peu curieux devrait s’interesser à elle. Il n’y a donc aucune raison de ne pas s’intéresser à NodeJS !
Slides de la présentation
Vidéo de la conférence
Java, JVM, Javas SE/EE
Vincent Massol nous présente les outils de test qu’il a mis en place sur son projet XWiki pour faire passer ses tests automatisés à la vitesse supérieur :
- une couverture de tests automatisée avec une stratégie d’effet de seuil,
- des tests de compatibilité ascendante,
- du mutation-testing,
- des tests d’environnements.
La couverture de test de ses projets est calculée automatiquement à chaque pull-request, et bloque le merge si la modification fait baisser le pourcentage de couverture du module. À chaque merge, le seuil à atteindre est ainsi progressivement augmenté
La compatibilité ascendante signifie que chaque version reste compatible avec la précédente, moyennant un besoin d’adaptation mineur. Pour cela, les éléments annotés @Deprecated lors de la précédente version ne sont pas supprimés mais déplacés dans un package à part : le module deprecated, à l’aide du plugin maven Revapi
Les tests par mutations (voir le quickie « Mutation-testing – comment évaluer la qualité de vos tests ») permettent de « tester les tests » : un plugin (pitest) modifie une copie du projet et vérifie que les tests automatisés réagissent à ces modifications. L’inconvénient est que les tests par mutations sont très lents, inconvénient que l’auteur corrige en utilisant l’extension à pitest « descartes »
Vincent utilise également le plugin Dspot, qui propose des assertions complémentaires aux tests déjà existants.
Les tests par environnements permettent en fait de simuler le lancement du programme sur différents environnements, à l’aide de docker et jenkins.
En conclusion,Vincent nous donne un dernier conseil : vous ne pourrez pas tout mettre en place. Du moins, pas sur tout les projets. Choisissez quelles sont les métriques les plus importantes à vos yeux, en fonction du contexte et du projet, et cherchez à automatiser l’extraction, l’analyse et le contrôle de ces métriques.
La vidéo est disponible ici.
Cette conférence présentée par Robert Scholte, président du projet Maven, avait pour thème la coexistence de Maven avec le système de modules introduit dans Java 9.
Contrairement à une idée reçue, Maven a toujours fonctionné nativement avec Java 9, sous réserve de disposer d’une version du plugin compiler suffisamment récente.
Le talk s’est principalement concentré sur les apports de la communauté Maven au projet Jigsaw en matière de gestion de conflits dans le classpath, aux problèmes qui subsistent et aux bonnes pratiques qui permettent de les éviter (en particulier, une lib modularisée ne doit pas dépendre de libs dont les noms de modules sont auto-générés).
La problématique de mise en commun des configurations des modules (côté Java 9) et des dépendances (côté Maven) a été abordée lors de la phase de questions, mais la réponse apportée en décevra beaucoup : non, Maven n’évoluera pas pour prendre en compte cette redondance des informations. En effet, les deux paradigmes ont été jugés trop différents ; une revue en profondeur du modèle des POM serait nécessaire pour adapter Maven, et cela viendrait casser tous les projets existants.
Découvrez la vidéo ici.
La paresse, c’est bien. Dans le code, ça sert toujours : reporter l’évaluation d’un code à plus tard, séparer description et exécution, traiter un flux de données infini ou « presque infini » (streaming), faire de la récursion terminale (tail-recursion)…
C’est pourquoi Mario Fusco nous explique comment importer dans Java ce concept qui lui est étranger. Java est plus impératif et toujours strict, sauf dans quelques cas notables :
- les opérateurs logiques paresseux ||, &&,
- la structure de contrôle if/else (au passage, connaissez-vous un langage dans lequel les deux branches du if/else sont toujours évaluées ?),
- les structures for/while,
- les
Stream de Java 8.
Au contraire, dans des langages comme Scala, la paresse est reine : on passe des paramètres call by name, qui ne sont évalués que s’ils sont utilisés (là où un paramètre normal est évalué avant son passage sur la pile, avant l’appel de la fonction réceptrice), la tail-recursion est déclarable et vérifiée par le compilateur, des variables peuvent être déclarée lazy, etc.
Parmi les exemples donnés par Mario, on peut retenir :
- Les
Stream créés de manière récursive (exemple : Stream de nombres premiers). C’est impossible en Java normalement, car cela nécessite de faire 2 opérations terminales, hors les Stream Java n’en supportent qu’une, après le Stream est… terminé ^^. Son exécution est alors lancée, on ne peut plus ajouter d’autres opérations. En Scala, c’est possible grâce à un opérateur de concaténation paresseux: `#::`. Pour le faire en Java, il faut créer une implémentation de liste récursive (définie comme head+tail), mais avec un lambda de type Supplier pour la queue.
- On remarquera que les lambdas servent aussi à remplacer (de manière plus verbeuse, certes) les paramètres call by name
- La tail recursion en Java doit passer par une « fonction trampoline«
- L’injection par annotation (à la Spring) : c’est immédiat par définition, avec l’énorme inconvénient de transformer un problème de compilation en problème d’exécution. Pour nous sauver en Java, il faut implémenter une monade Reader (par ailleurs bien connue des langages plus fonctionnels comme Scala, Haskell, etc.). On initialise la monade avec un objet et une fonction d’injection et ensuite les opérations sont passées en paramètre de la fonction map. Ne cherchez pas à comparer avec un framework d’injection/IoC, ça ne sert ici qu’à montrer comment faire lorsqu’on doit repousser la décision d’injection au dernier moment, sans empêcher de coder la logique métier. De manière générale, la monade Reader sert à fournir un environnement à un traitement paresseux ; c’est une notion utile et même importante dans les langages fonctionnels.
J’ai personnellement apprécié cette conférence pour sa démarche « rendons Java plus puissant avec des concepts existant dans les langages fonctionnels » (ou au moins « moins stricts/impératifs »). Il y avait d’autres conférences dans la même veine. J’ai désormais l’impression que la maturité de Java fait qu’une grande partie des développeurs historiques s’intéressent à d’autres langages avec des paradigmes différents, et que de plus en plus de bons principes de programmation « étrangers » ruissellent dans Java.
La vidéo est disponible.
DevOps, Agilité, Méthodologie & Tests
Cette conférence était un retour d’expérience sur le refactoring de la solution de paiement chez Videdressing. Le speaker (Hervé Lourdin) nous a présenté le périple mené afin de construire une solution plus robuste.
Tout d’abord, il s’est attardé sur les causes de cette remise en question : l’échec d’ajout d’une nouvelle forme de paiement (Paypal). Pour cela, le chemin suivant a été emprunté.
En premier lieu, les problèmes ont été identifiés et personnifiés sous la forme des « 4 cavaliers de l’apocalypse », qui sont :
-
- la complexité alarmante du code amenant une explosion des temps estimés,
- le grand nombre de bugs,
- le manque d’attrait technique de la plateforme actuelle amenant une difficulté de recrutement,
- les “héros” (experts de la plateforme) fatigués et jouant uniquement le rôle de “pompiers” au lieu d’être des vecteurs de partage de la connaissance.
Ensuite, ces derniers ont été présentés, accompagnés d’un plan d’action (gel des nouveaux développements de features pour une durée de plusieurs mois), au product manager et aux investisseurs. L’accent a été mis sur l’impact financier direct (temps de développement) et indirect (difficulté de recrutement). Ayant eu leur accord, le projet pu démarrer. Néanmoins, vu que personne ne maîtrisait réellement le scope fonctionnel de ce module, une typologie de cette dernière a été créée. Ce qui a permi de remettre à plat le fonctionnement de la solution ainsi que de distinguer le vrai fonctionnement du système des croyances des personnes l’utilisant . Cela a amené une uniformisation du vocabulaire et des termes fonctionnels.
Ensuite, une roadmap et des stories ont été créées. Afin de conserver la motivation des différentes parties prenantes (les développeurs) ou impactées (le service client), le speaker nous a montré quelques solutions utilisées comme la code review pour partager la connaissance technique et fonctionnelle, l’industrialisation des déploiements via Docker ou l’affichage du taux d’avancement.
Enfin, le speaker nous a présenté quelques effets tels le partage de la connaissance et des bonnes pratiques de développement ; sans compter la baisse du nombre de bugs reportés et des réclamations clients. En définitive, cette conférence fut très intéressante à plus d’un point. Outre le fait qu’elle permet d’avoir un post-mortem inspirant d’une problématique que beaucoup d’entreprises connaissent (la dette technique incontrôlable), elle apporte un regard détaillé sur le quotidien d’un CTO de PME. En effet, ce poste ne devient plus un poste purement technique mais de plus en plus managérial, communicationnel et stratégique à mesure que l’entreprise croît.
La vidéo est disponible.
En quoi consiste le métier de CTO dans une startup ?
En effet, les occupations d’un CTO varient énormément suivant le niveau et la taille de l’entreprise
Dans une startup, la première étape est de choisir son CEO.
Le CEO est celui qui porte la vision du produit. Le CTO est celui qui est capable de transformer les ressources mises à sa disposition (argent, materiel, personnes) en cette vision.
À noter qu’une idée moyenne, mais brillamment exécutée, aura plus de valeur qu’une bonne idée mal exécutée : votre CEO doit donc, en plus de sa vision de l’idée, connaitre le marché, avoir un plan marketing, un réseau, etc.
Quant au partage des parts et au calcul des salaires… Il n’y a pas vraiment de règles. Mais de manière générale, les parts sont données comme une compensation du risque pris par un des associés ou du salaire non-touché. C’est donc à voir en fonction de votre contexte personnel si vous préférez un salaire à des parts de la société.
En raison du temps passé ensemble par le CEO et le CTO, il est important que la confiance se créée, que les personnalités s’accordent… et que tout ce qui a été entendu et négocié entre associés soit noté dans le pacte d’associés, une sorte de contrat de mariage entre les différentes parties. Par exemple, quid du partage des parts, si l’un des associés est malade 50% du temps ? Que faire si la cohabitation ne se passe pas bien ? Que faire en cas de faute grave d’un des associés ?
Autre que la réalisation technique, de nombreuses autres tâches s’ajouteront à votre rôle de CTO de startup : recrutement, juridique, management, administration, etc.
La vidéo est maintenant disponible.
Démystifions ensemble le métier de QA !
En effet les QA ont tendance à être confondus par les développeurs avec des Business Analystes.
Les Business Analystes pensent que le travail des QA est de réaliser leurs scénarios de tests.
Les Business Managers imaginent qu’avec un QA dans leurs équipes, ils n’auront plus jamais de bug de prod.
Amandine Fournaise nous présente également le métier du grand pâtissier Pierre Hermes : il écrit ses recettes, mais ne les cuisine pas : c’est sa brigade de sous-chefs qui prépare les pâtisseries.
Elle nous propose donc de ré-imaginer le métier de QA ainsi : imaginons un testeur qui ne teste pas.
En effet, QA est l’abréviation de Quality Assurance : Contrôleur de qualité. Mais pas testeur. Alors, comment contrôler la qualité des livrables sans tester ?
Pour ce faire, notre QA a donc mis en place des outils automatisés de tests de non-régressions et End-to-End, des stratégies de tests, et un vocabulaire commun entre les QA et les développeurs.
Découvrir la vidéo.
Gwen Shapira nous a présenté les challenges classiques de l’intégration de données ainsi que les patterns qui permettent d’y répondre.
Pour commencer, nous avons eu droit à un petit récapitulatif de l’historique de l’intégration de données lors de la dernière dizaine d’années, avec en particulier deux évolutions majeures :
- Avec l’apparition de Hadoop et le passage du paradigme de data warehouse à celui de data lake, la définition de la structure des données ne se fait plus au moment de leur écriture (schema on write) mais au moment de leur lecture (schema on read), ce qui aboutit au déplacement de la responsabilité de l’interprétation des données vers l’ingénieur logiciel.
- Avec l’apparition de Kafka, les batchs, exécutés à intervalles réguliers, ont été remplacés par des flux de données qui permettent de propager les événements au moment où ils se produisent.
Les différentes problématiques abordées :
- Stream of events
Tout ce qui se passe dans le système peut être considéré comme un flux continu d’événements immuables et ordonnés. Chaque événement a potentiellement des usages divers, ce qui aboutit à des échanges complexes quand les canaux de communication sont nombreux et hétérogènes. Kafka vise à concentrer la gestion de ces flux d’événements tout en assurant une excellente scalabilité.
- Keep events compatible
L’introduction des événements permet de découpler publicateurs et consommateurs. Entre eux, c’est le schéma des événements qui sert d’API, de contrat. Il est donc fondamental d’assurer que les événements restent compatibles.
La notion de schema registry vise à répondre à cette problématique : utilisé au niveau des sérialiseurs, le schema registry permet d’adapter ou de rejeter les événements considérés comme incompatibles.
- Ridiculously parallel transformations
Dans les cas d’utilisation simples, c’est-à-dire quand toutes les opérations sur les événements sont stateless (ex : filtres), il est recommandé d’utiliser Kafka de la manière la plus simple qui soit : dans une logique dite de « hipster stream processing » en référence aux vélos des hipsters californiens, qui n’ont ni vitesses ni freins.
- Streaming data enrichment
Les opérations stateful (ex : jointures) sont complexes à gérer, dans la mesure où elles nécessitent la gestion d’états. Le hipster stream processing n’est donc plus adapté, et l’adoption d’un framework tel que Kafka Streams est recommandée. Kafka Streams absorbe la complexité de ces opérations grâce à un cache intégré pour la gestion des états.
Pour résumer, cette conférence nous aura donné une idée de certains concepts importants de l’intégration de données, de manière claire et très abordable.
La vidéo est disponible.
Joshua Bloch est quelqu’un à qui Java doit beaucoup. Il est à l’origine de l’instruction assert ou encore de la lib java.lang.Math ! C’est également l’auteur de Effective Java.
À travers sa longue expérience, il nous fait part avec beaucoup d’humour d’une question intéressante qui lui est parvenue : «comment le concept d’API s’est développé dans l’histoire de l’informatique», question posée par un juge fédéral, certes, mais pas moins intéressante pour autant !
Il nous décrit donc sa réponse et les recherches qu’il a menées au travers de la conférence A Brief, Opinionated History of the API.
Il commence par le tout début, à l’ère du premier ordinateur électronique en 1949, l’EDSAC. Les premiers programmes et l’emploi de tâches répétitives mènent très rapidement à l’invention de la sous-routine et de recueils de sous-routine, que l’on nomme toujours aujourd’hui «librairies». Joshua s’étonne qu’à cette époque déjà, les problématiques de réutilisation, simplification et maintenance de code sont déjà clairement exposées et restent des sujets d’actualité.
La notion explicite d’API semble apparaître pour la première fois dans un papier de 1968. Joshua donne plusieurs définitions équivalentes dont «une extension d’un langage de programmation». Librairie de sous-routine et API sont finalement très proches. C’est surtout les concepts de portabilité et compatibilité de versions qui vont différencier les deux, mais cela n’avait pas raison d’être à l’époque du premier (et unique !) ordinateur et des premiers programmes.
Que peut-on considérer comme une API ? La librairie standard C (libc) ? Les appels systèmes Unix ? Le jeu d’instructions d’un processeur ? Le langage d’impression PostScript ? Le BIOS ? Le protocole d’échange de fichiers SMB ? Les librairies de classes Java 2 ? Tous ces exemples (et bien d’autres) répondent à la définition !
Joshua finit sur l’aspect légal : tous les exemples d’APIs cités ont connu une ou plusieurs réimplémentations. Mais s’agit-il pour autant d’une violation de droit d’auteur ? Le droit d’auteur peut-il être même considéré dans le cadre de la création d’une API ?
L’affaire «Oracle versus Google» concernant la réécriture des APIs Java a déjà fait couler beaucoup d’encre et les décisions prises pourraient bien servir d’exemple pour le futur.
Selon Joshua, la réimplémentation des APIs est souvent une nécessité et de nombreux projets incontournables (Android dans le cas du procès cité) n’auraient jamais vu le jour sans. Interdire la réécriture d’API pourrait avoir des conséquences très lourdes sur l’industrie informatique.
La vidéo est disponible.
Big Data, Machine Learning, IA & Analytics
Conférence : Construire votre propre système de recommandations avec Apache Spark
Christophe Jolif et Othmane Laousy (IBM) ont présenté l’implémentation d’un système de recommandations en utilisant le framework Apache Spark.
Aujourd’hui, de plus en plus de produits grand public (plutôt qu’internes pour les entreprises) implémentent les systèmes de recommandation pour aider les utilisateurs à prendre des décisions. Ce système trouve son utilité surtout quand le choix est vaste et les décisions complexes (comme par exemple Amazon ou Netflix). Dans l’introduction, Christophe Jolif explique les deux approches principales dans le monde des algorithmes de recommandations :
- basée sur le contenu : les recommandations seront calculées grâce aux informations sur les centres d’intérêt des utilisateurs et le contenu des produits à recommander ;
- basée sur le filtrage collaboratif : les recommandations seront calculées grâce aux historiques des notations des autres utilisateurs.
L’exemple utilisé tout au long de la conférence est un système de recommandation sur la plate-forme des bots (imaginaire) . Pour créer un bot, l’utilisateur peut choisir un bot existant, un bot partagé par ses collègues ou bien créer un bot from scratch. Pour aider les utilisateurs à faire le choix, deux questions se posent :
- Si je veux choisir un bot existant (ou partagé) : quel bot utiliser ?
- Si je veux créer mon propre bot : quelle doit être ma prochaine action dans la construction d’un bot ?
Le framework utilisé pour les deux solutions s’appelle Apache Spark.
Pourquoi Apache Spark?
Apache Spark est un framework de calcul distribué. Un de ses avantages est le traitement en mémoire permettant d’obtenir une grande rapidité de calcul. Il est facilement accessible avec des API en Python, Scala, Java et R. MLib, une des librairies du framework, contient plusieurs algorithmes de machine learning qui permettent de répondre au besoin d’un système de recommandations : Alternating Least Square (ALS) et Frequent Pattern Growth (FP-Growth).
Othmane Laousy a présenté son implémentation dans un notebook, outil d’exploration et de prototypage souvent utilisé par les data scientists. Dans sa démonstration, il a montré les étapes de pré-traitement de données ainsi que l’implementation simple des deux algorithmes :
- ALS : une technique de la factorisation matricielle qui permet d’extraire les facteurs latents. Les facteurs serviront à la prédiction des notations manquantes
- FP-Growth : une technique qui permet de modéliser les séquences et par la suite de générer des règles d’associations
Les orateurs nous ont rappelé également que le modèle devait être ré-entrainé. Il suggère deux critères de ré-entrainement du modèle : par fenêtre temporelle ou bien par nombre de données reçues.
Pour finir, les orateurs ont brièvement décrit l’étape cruciale de chaque modèle de machine learning : la mise en production. Une des considérations à prendre en compte est le départ à froid (recommandations pour les nouveaux utilisateurs). Dans ce cas, là ils proposent de développer les recommandations basées sur la popularité ou bien l’utilisation des autres attributs d’un compte d’utilisateur (âge, sexe, département…).
La présentation a été très dynamique. Même si les orateurs ne sont pas entrés dans les détails des algorithmes, la conférence fournit une bonne base, clairement expliquée pour faire l’implémentation simple soi-même avec l’aide d’Apache Spark.
Découvrir la vidéo.
Pour conclure cette dernière journée de Devoxx, Duy Hai Doan se proposait de nous présenter quelques algorithmes de gestion du temps utilisés par des acteurs majeurs de la Data. Cette problématique est cruciale dans les systèmes distribués, dans la mesure où elle permet de garantir l’ordre des événements.
Les algorithmes présentés sont ceux qui sont utilisés respectivement par Apache Kafka Idempotent Producer, Google Spanner et CockroachDB. A noter que l’algorithme HybridTime, qui sert de base à Apache Kudu, n’aura finalement pas été présenté faute de temps.
- L’horloge de Lamport est un algorithme théorisé en 1978 dont le principe plutôt simple nous fournit un ordre partiel uniquement, c’est-à-dire qu’il n’est pas possible d’ordonner les événements qui ne partagent pas un lien de causalité.
Il est utilisé par Kafka pour donner l’ordre des événements pour une partition donnée ; tous les événements d’une partition étant causalement liés, cela permet de gérer le cas où des messages arrivent dans le désordre (pipelining).
- True Time est un algorithme élaboré par Google, qui remet en cause des notions établies telles que le théorème CAP.
L’API True Time qui en résulte a pour particularité de ne pas fournir une date, mais un intervalle auquel la date appartient à coup sûr, en prenant en compte la marge d’erreur. A partir du moment où deux intervalles sont disjoints, il est donc possible de déterminer à coup sûr l’ordre de précédence entre deux événements. En utilisant un système de verrou pessimiste au niveau de l’ensemble du système, Google Spanner garantit que tous les intervalles sont disjoints et peut donc assurer l’ordre des événements.
Pour déterminer l’intervalle et faire en sorte qu’il soit le plus petit possible, True Time est basé sur la présence d’une horloge atomique et sur une synchronisation par GPS, qui permettent des synchronisations temporelles fréquentes et précises, les potentielles failles de chacune de ces deux solutions se compensant respectivement. Le défaut principal de la solution réside dans son prix, une horloge atomique n’étant pas à la portée de n’importe qui.
- HLC (Hybrid Logical Clock) a la même base que l’horloge de Lamport, la notion de temps logique, mais y adjoint une composante causale dans l’objectif est d’ordonner les événements concurrents. La théorie s’en trouve considérablement complexifiée.
HLC est utilisé dans CockroachDB, avec une approche différente de celle de Spanner, dans la mesure où chaque écriture est effectuée puis potentiellement annulée, tandis que Spanner dispose d’un système de verrou pessimiste.
HLC peut être considéré comme le « True Time du pauvre ». En effet, il ne nécessite pas l’acquisition d’horloges atomiques, mais présente plusieurs défauts, comme le fait d’imposer la manipulation de certaines notions au niveau des messages métier échangés entre les serveurs, ou le risque de chutes de serveurs en cascade (ceux-ci étant tués en cas de divergence trop importante).
Pour conclure, c’était une présentation plutôt claire, quoiqu’un peu trop rapide sur la fin, de ce que plusieurs solutions ont sous le capot pour répondre à une problématique primordiale, avec leurs différents avantages et inconvénients.
La vidéo est disponible. Bon visionnage !
Still find the sign fun though! 
.
Looking forward trying all of this 
Really brave from 
