Un jeudi à Devoxx, découvrez le retours des Xebians !

Un jeudi à Devoxx, découvrez le retours des Xebians !

Pour cette nouvelle édition de Devoxx France, les Xebians étaient présents. Ils vous proposent à travers cet article de découvrir leurs avis sur certaines des conférences présentées :

Retrouvez leurs avis sur les conférences du vendredi ici.

Keynote

La e-residence estonienne et l’entrepreneuriat sans frontieres

Arnaud Castaignet nous présente le programme e-Residency cree par le gouvernement estonien en 2014.En effet l’Estonie a mis en place un service administratif en ligne pour toutes les transactions administratives ou presque (à l’exception du mariage, du divorce et des transactions immobilières).

Outre les avantages d’un tel service, une telle infrastructure a permis l’émergence de nouvelles notions, telles que l’e-residence (quelqu’un qui n’existe que par la trace informatique dans le système administratif estonien). Cela permet à n’importe quel individu dans le monde d’avoir une cyber identité estonienne, et peut ainsi lui permettre d’entreprendre diverses activités à distance, par exemple de créer une entreprise. De nombreux entrepreneurs ont franchi le pas et peuvent ainsi créer un commerce dans l’UE, tout en restant dans leur pays d’origine.

La vidéo est disponible ici.

 

Le Smart Building : par où commencer ?

Olivier Selles, le speaker de cette keynote, ne vient pas du monde de l’informatique mais celui du bâtiment. S’il est venu à Devoxx, c’est pour nous présenter une étude prospective sur l’avenir des liens entre le monde de l’IT et celui de la construction.

Olivier Selles part d’un constat sombre pour le secteur de la construction : c’est un secteur déclinant.
En effet, les durées de construction s’allongent, les erreurs se multiplient. C’est même un des rares secteurs de l’économie où la productivité diminue ! En outre, les bâtiments modernes ne plaisent pas au public : celui-ci préferera toujours un bâtiment Hausmannien malgré tous ses défauts à un bâtiment moderne.
Un autre problème est que ce secteur méconnait totalement le secteur de l’IT. L’un des seuls secteurs qui investit moins que le bâtiment en pourcentage dans l’IT est … la chasse !

Du coup, Olivier Selles nous présente une solution qui va non seulement marier le monde de la tech et celui de la construction mais aussi, et surtout, a la capacité de faire rebondir l’industrie du bâtiment : le Smart Building. Ce concept recouvre toutes les idées d’application des nouvelles technologies à la construction pour rendre les bâtiments plus intelligents. L’exemple typique est « The Edge » à Amsterdam, qui est considéré comme un des bâtiments les plus intelligents du monde.
Pour rentrer un peu plus dans les détails, le speaker défini le terme SMART par l’équation suivante :

En effet, pour rendre un bâtiment intelligent, il faut d’une part installer des capteurs et les faire communiquer afin de collecter un maximum de données ; et d’autre part, il faut prendre des décisions pour réagir à ces données.
L’auteur donne plusieurs exemples d’application dans différents domaines :

• Gestion des salles de réunion : si leur gestion se fait de plus en plus informatiquement, un batiment intelligent peut aller plus loin en pré-chauffant les salles avant les réunions, ce qui optimise la consommation énergétique. Il peut aussi repérer les salles réservées mais vides pour les rendre de nouveau disponibles à la réservation.
• Sécurité : au lieu d’utiliser des cartes magnétiques d’entrée comme on le fait actuellement, dans le futur, on pourra intégrer les progrès modernes en reconnaissance d’images pour savoir qui entre et qui sort du bâtiment.
• Maintenance / Exploitation : si l’on prend l’exemple de toutes les ampoules d’un bâtiment, il existe actuellement plusieurs stratégies de maintenance : on peut remplacer une ampoule à chaque fois qu’elle grille ; ou on peut remplacer préventivement une ampoule dès qu’elle atteint un certain âge. Grâce aux technologies modernes, on pourra, de plus en plus utiliser une nouvelle stratégie : la maintenance prédictive. En effet, grâce aux capteurs connectés et aux avancées dans l’analyse des données, on peut détecter (voire apprendre) les signes avant-coureurs d’une panne et remplacer uniquement les pièces qui présentent ces signes. Par exemple, dans le cas des ampoules, un des signes avant-coureurs de la fin de vie est l’instabilité de la tension aux bornes de l’ampoule.
• Économie positive : par exemple, dans des régions agricoles riches en colza, on peut tout à fait imaginer un bâtiment intelligent dans lequel l’énergie soit fournie par la combustion de l’huile de colza. Cette combustion produira aussi du CO2 qui servira à alimenter une brasserie au sous-sol et un plant de tomates sur le toit. Ces tomates serviront ensuite à la cantine du bâtiment. On privilégie ainsi les circuits courts, on économise l’énergie et on soutient l’économie locale.

Si les promesses du Smart Building sont nombreuses, il y a tout de même beaucoup d’obstacles avant que les bâtiments intelligents ne s’imposent dans les nouveaux projets de construction. L’un des principaux obstacles est le manque de compétences informatiques dans les entreprises de construction. Ce manque de compétences est encore plus criant dans le domaine de la sécurité des nouvelles infrastructures informatiques des constructions. En effet, qui dit informatisation dit souvent problèmes de sécurité. Et déjà, en 2016, une équipe de chercheurs en sécurité informatique ont piraté des ampoules connectées d’un bâtiment à Beer-Sheevah (Israel), prouvant que le problème n’est pas que théorique

Du coup, le speaker pose une dernière question : qui va répondre aux défis technologiques et sécuritaires que pose le Smart Building ? Il voit quatre types d’acteurs qui pourraient y répondre :

• des RSSI (Responsables de la sécurité des systèmes d’information) qui s’occuperont des SI des bâtiments comme on s’occupe des SI d’entreprise,
• les entreprises du bâtiment (Bouygues, Eiffage,…) qui imposeront leurs solutions,
• les GAFAM (Google, Apple, Facebook, Amazon, Microsoft) qui risque eux-aussi d’imposer leurs solutions en apportant leur savoir faire technique (ce qui leur permettra aussi de récupérer encore plus de données sur nos usages),
• les développeurs eux-mêmes, qui pourront apporter une solution collaborative par le biais de programmes open-source.

C’est clairement cette dernière hypothèse que le speaker préfère, il conclut donc sa présentation par un appel aux développeurs présents pour bâtir de façon collaborative les constructions intelligentes de demain.

Le Smart Building est donc peut-être un futur enjeu majeur pour la croissance des entreprises informatiques. Il prouve en tout cas que la révolution numérique du monde n’est pas terminé puisqu’il reste encore des secteurs entiers de l’économie qui gagneraient à utiliser les nouvelles technologies, et c’est en cela que cette Key note était passionnante.

Vidéo de la conférence

Web, JS, HTML5 et UX

Conférence – Et si Mario était UX Designer…

Alexandra Nemery et Sarah Colmon

Au travers du prisme du jeu vidéo, le duo UX Designer / Product Owner de ce talk nous a démontré par l’exemple quelques uns des grands principes de l’UX.

Il a été question d’éviter des « pièges UX » présents dans certains jeux vidéos récents, mais aussi de s’inspirer de l’excellence intuitive de certains jeux comme le tout premier Super Mario.

Ce talk était de bonne qualité, avec des arguments qui tenaient la route. Les différents profils des deux speakers permettent d’enrichir leur argumentation.

Ajoutez à cela un quizz via Kahoot, des références bibliographiques pour compléter les takeaway, et un support bien conçu, et vous obtenez la recette d’un talk qu’on a plus qu’envie de revoir.

La vidéo est disponible ici.

Conférence – La toile en VR

Florent Berthelot et Barthelemy Jonathan nous présentent comment réaliser facilement une application de réalité virtuelle pour le web.

La réalisation de scènes 3D en web se fait via la combinaison de la balise <canvas> et de l’api webGl. Problème : il est assez fastidieux de réaliser le moindre objet, à titre d’exemple, la réalisation d’un simple cube oblige le développeur à écrire 24 lignes de coordonnées.
La librairie Three.js permet de tout simplifier, mais celle-ci ne gére que la 3D, il manque toujours l’aspect VR.
Pour palier ce manque l’api webVR a vu le jour. Elle est exploitée notamment par deux frameworks :

• ReactVR : le framework React ne produit pas de html ou de component mobile mais du Three.js
• A-frame : Mis en place par Mozilla, il n’y a pas besoin de connaitre Javascript puisque tout se fait via des markups

Dès lors la présentation devient une succession de comparaisons entre les deux frameworks, Florent s’occupant de ReactVR et Barthelemy de A-frame.
Leur but est de créer une voiture et de pouvoir la déplacer (une dodge pour ReactVR et Kit pour A-frame)
Les cas d’usages présentés :

• Réalisation de formes géometriques simples,
• Import audio,
• Import de modèles (.obj),
• Interactions,
• Déplacements.

Dans tous ces exemples, les deux frameworks s’avèrent être relativement simples d’utilisation et similaires, avec une légère préfèrence pour l’approche full markup.
Finalement, la killing feature sera proposée par A-frame qui fournit un mode debug riche. Il permet de voir en temps réel les differents objets de la scène ainsi que leurs compositions à l’instar de ce que propose les IDEs de game engine moderne (unity, unreal engine …) là où ReactVR ne propose rien d’autre que les modes debug des naviguateurs et l’inspecteur de code javascript.

La présentation bien rythmée et instructive se terminera malheureusement sans question faute de temps, à titre personnel j’aurai aimé savoir s’il n’est pas préférable de passer directement par un moteur de jeu comme Unity et les assets WebVR, ainsi que d’avoir quelques exemples d’utilisation concrète de ces frameworks.

La Video de la conférence est maintenant disponible.

Java, JVM, Javas SE/EE

Conférence – Effective Java, Third Edition: Keepin’ it Effective

L’un des plus gros contributeurs (et auteurs) du langage Java est venu pour nous donner un avant goût de son livre Effective Java, Third edition. 4 ans après la sortie de Java 8, Joshua Bloch se concentre sur les bonnes pratiques avec les lambdas et les Streams.

On retiendra par exemple :

• L’utilisation de lambdas pour ajouter du comportement aux instances spécifiques d’une Enum tout en évitant de créer des sous-classes.
• Choisir le plus succinct entre lambda et lambda ref.
• Préférer déclarer des interfaces fonctionnelles standard (comme BinaryOperator, parmi les 43 existantes) qui sont plus parlantes pour un utilisateur de votre code. Exceptionellement, on pourra préférer des interface spécifiques mais universellement connues, comme Comparator ; dans un certains contexte, ça sera plus clair au niveau des intentions qu’une BiFunction<T,U,R>.
• Utiliser l’API Stream judicieusement.
  
  • Est-ce que cela simplifie vraiment le code ? Dans l’exemple donné de la recherche des N premiers nombres de Mersenne, oui ; mais dans la recherche de groupes d’anagrames dans un dictionaire, non ! Au passage, petit tacle involontaire sur Java en faveur de Scala, puisqu’on remarquera qu’une String en Java n’est pas supportée comme Stream de caractères, mais plutôt d’entiers courts non-signés (représentation interne du char natif en Java).
  • Attention au parallélisme : dans l’implémentation de Stream par défaut, l’exemple des N premiers nombres de Mersenne va nécessiter le calcul des n – 1 prédécesseurs pour chaque itération n < N, d’où la transformation de votre CPU en grille-pain et d’un ralentissement très rapide de la progression (temps marginal exponentiel). Au contraire, le calcul des N nombres premiers sur un ensemble déterminé va bénéficier pleinement d’un Stream parallèle.

Nous avons tous été déçus ne pas pouvoir revenir avec un ou deux exemplaires dédicacés… :troll:

La vidéo est disponible ici.

DevOps, Agilité, Méthodologie & Tests

Conférence – DevOps As A Service : approche globale et rationnelle du CI/CD pour les entreprises

Jonathan Roquelaure

Les contraintes de déploiement logiciel ne sont pas les mêmes selon qu’on est un éditeur d’applications mobiles ou un industriel de l’avionique. Aussi, la culture d’entreprise, les savoirs présents et la géographie sont autant de paramètres supplémentaires à prendre en compte quand on veut mettre en pratique les principes DevOps pour l’intégration continue.

Que font les grosses entreprises qui se lancent dans cette transformation ? Avec quels résultats ? Jonathan propose des morceaux choisis de ce qu’il a pu voir expérimenté chez les clients de JFrog avec qui il traite.

Les problématiques abordées vont du Pokemon Dilemma des choix technologiques offerts aux difficultés d’adoption par les employés en passant par la création d’outillage dédié et les besoins nouveaux qui émergent.

On repart avec quelques pistes à explorer et des phrases choc qui permettront de garder le cap :

• Tout système complexe produira toujours des résultats imprévisibles, il faut donc bâtir un modèle qui réagira au mieux à l’imprévisible ;
• Harmonisation et standardisation plutôt que centralisation ;
• « DevOps is a mindset, not a toolset » ;
• Exposez la surveillance et les mesures faites sur vos outils ;
• Les gens font confiance à leur pairs, trouvez des avocats du changement parmi eux ;
• Démarrez petit mais représentatif, pensez grand ;
• Comptez au moins 1 à 3 ans pour réussir la transformation.

La vidéo est disponible ici.

Conférence – Prise de décisions asynchrone, pourquoi et comment ?

Mais comment font donc les intervenants des projets open-source pour se concerter et prendre des décisions efficaces sans jamais se rencontrer en vrai ? Comment se fait-il que les réunions, de plus en plus nombreuses en entreprise, perdent en efficacité ?

Autant de questions auxquelles Bertrand Delacrétaz tente de répondre dans sa conférence.

L’idée derrière la prise de décision asynchrone est qu’il n’est pas obligatoire d’être tous réunis pour échanger, communiquer et prendre des décisions dans un but commun. Les technologies modernes fournissent en effet de nombreux outils qui nous permettront ainsi de transmettre et décider sans que les différents acteurs soient réunis au même endroit ou ne serait-ce que disponibles au même moment. Pour ce faire, Bertrand propose la mise en place d’un canal de décision partagé asynchrone (slack par exemple) et un outil de diffusion partagé (Bertrand prend les exemples de Jira et de Git).

Bertrand découpe la prise de décision en 4 phases :

• le brain-storming : chacun expose ses idées ;
• les options : les différentes idées sont observées, clarifiées et triées suivant leur faisabilité et leurs avantages ;
• le consensus: les différents protagonistes convergent vers un accord concernant la décision à prendre ;
• la décision: la décision est actée, puis on historise les éléments qui ont mené à cette décision.

Les avantages de découper les réunions en 4 étapes, séparées dans le temps sont nombreux : outre le fait que les intervenants peuvent être en remote, ils ont également plus de temps pour réfléchir, pour comprendre les problématiques, chercher des informations et formuler leurs opinions. De plus, les réunions physiques ont souvent des coûts cachés : fragmentation de la journée de travail, participants peu ou pas impliqués, etc.

Pour illustrer ses propos, Bertrand nous présente des exemples concrets avec la gestion du projet Cordova ou bien avec le gouvernement Suisse.

La prise de décision finale a ainsi souvent lieu plusieurs jours après le workshop, laissant ainsi un temps de réflexion et de maturation.

Il est également, possible d’avoir des réunions hybrides : elles seront préparées en asynchrone (l’ordre du jour sera précisé à l’avance, les éventuelles demandes de recherche effectuées au préalable, etc).

La vidéo est disponible ici.

Quickie – Améliorer la qualité du code source à l’aide de la Complexité Cognitive

Inutiles, les métriques de code ? En tous cas, la fameuse complexité cyclomatique a du plomb dans l’aile : Xavier Bourguignon de SonarSource expose un exemple qui montre clairement que sur deux codes avec la même complexité cyclomatique, l’un est acceptable, l’autre peu lisible. L’idée de SonarSource est alors d’introduire la complexité cognitive, qui prend en compte le niveau d’imbrication de la ligne de code qui augmenterait la complexité cyclomatique. Exemple : un « if » ajoute 1 à la « cyclo ». S’il est à l’intérieur d’un autre « if », on ajoute 2.

Ensuite, des techniques très classiques de refactoring sont données pour réduire cette métrique :

• collapsing des if/else/if,
• return dans les if sans else,
• switch à la place d’une cascade de if/else,
• utiliser le « multicatch » pour simplifier le traitement des exceptions,
• dans un finally avec de nombreuse release de ressources, créer une fonction « releaseQuietly » pour tout remplacer,
• lire le livre Clean Code de Robert C. Matin.

Si cette métrique est une bonne nouvelle pour le code Java, malgré le support officiel de Scala qui va bientôt arriver dans SonarSource, la programmation dans un style plus fonctionnel ne bénéficiera d’aucune analyse supplémentaire spécifique. Si ajouter une lambda ajoutera bien de la complexité, aucun autre critère n’aidera la « FP ». Pourtant, l’imbrication des paramètres « types » a autant d’importance que celle du code…

La vidéo de la conférence est disponible ici.

Architecture, Performance et Sécurité

Conférence – #RetourAuxSources : les cookies HTTP

Hubert Sablonnière

En partant des attributs de base des cookies, Hubert explique avec pédagogie les subtilités, limites et largesses de leur fonctionnement. On découvre alors un véritable jeu du chat et de la souris sécuritaire au travers de quelques démonstrations de failles (CSRF, XSS, etc.) et les contre-mesures désormais associées (mise en œuvre de la « Same Origin Policy », apparition des propriétés Secure, HttpOnly, SameSite, etc.).

Le ton est léger, le discours riche en enseignements. En bref, une conférence de référence pour quiconque voudrait (re)découvrir les problématiques associées aux cookies.

Conférence – DDD & Event Sourcing à la rescousse pour implémenter la RGPD ?

Guillaume Lours et Jérôme Avoustin

La RGPD entre en vigueur dans quelques semaines pour quiconque exerce une activité professionnelle sur le sol de l’UE ou traite des données de citoyens de l’UE.

Guillaume et Jérôme ont expliqué simplement les tenants et aboutissants d’un certain nombre de points que cette réglementation définit, notamment :

• « Privacy by Design » : la protection des données personnelles doit faire partie intégrante du logiciel dès sa conception ;
• consentement éclairé nécessaire pour traiter toutes données personnelles ;
• conditions d’anonymisation et de pseudonymisation des données ;
• obligation de déclaration des fuites de données constatées ;
• sanctions financières importantes en cas de manquement.

Une fois les bases de la RGPD posées, un certain nombre de concepts liés au DDD sont vulgarisés pour permettre d’entrer dans le vif du sujet : comment l’Event Sourcing peut apporter une réponse intéressante, à défaut d’être clefs-en-main, aux problématiques de la RGPD. Guillaume et Jérôme exposent alors quelles étapes ils suivent actuellement pour transformer une application CRUD qui ne devrait pas l’être en une application basée sur les évènements. Chaque avantage de l’Event Sourcing vis-à-vis du CRUD est abordé, avec en toile de fond l’utilité vis-à-vis de la RGPD :

• facilité de test ;
• versionning d’aggrégats ;
• débogage et reproductibilité améliorés ;
• opérations de compensation pour implémenter les rollbacks ;
• traçabilité gratis.

L’accent était mis sur la compréhension des mécanismes de base en prenant soin de ne pas apporter de vocabulaire parfois chargé en Fear Factor comme les « Bounded Context », les fonctions de décision, fonctions d’évolution, etc. J’ai trouvé cette approche parfaite pour vulgariser les principes exposés. On ressort de cette conférence avec l’envie d’implémenter de l’« Event Sourcing » pour en approfondir les concepts et une recette empirique pour transformer un mauvais CRUD.

La vidéo est disponible ici.

Quickie – Spectre et Meltdown, 15 min pour tout comprendre

Dans cette vulgarisation des exploits Meltdown et Spectre, Alexis Duque rappelle le fonctionnement des CPUs modernes avant d’expliquer le fonctionnement de ces deux attaques. Pour chacune, il donne également les moyens d’atténuation (mitigations).

Intéressante pour sa pédagogie, la présentation résume bien les « take away » des différents articles sortis sur le sujet :

• Les CPUs modernes (depuis le Pentium Pro pour Intel) peuvent exécuter les instructions dans un ordre différent de celui prévu par le programme, et même d’essayer de deviner la prochaine instruction afin de commencer à l’exécuter plus tôt ; le tout afin d’optimiser le pipelining (le but étant de ne jamais laisser le pipeline se vider, afin de ne pas gâcher des cycles CPU).
• Spectre/meltdown appartiennent à la catégorie des attaques par canal auxiliaire (side channel attack) : un canal auxiliaire est un moyen utilisé par un attaquant pour transmettre une information via un moyen qui n’a pas été prévu pour cela au départ ; ici c’est le cache CPU.
• Meltdown utilise le fait que le CPU peut avoir déjà exécuté un instruction avant de contrôler si elle est autorisée. Évidemment, si elle est finalement interdite, le CPU remet les registres dans l’état précédent et abandonne l’instruction, mais c’est trop tard pour le cache qui, par effet de bord, contient la valeur interdite. L’attaquant, qui n’a pas le droit d’accéder à cette valeur, va créer dans son code un tableau rempli des valeurs possibles pour le résultat à l’appel interdit. Il va ensuite parcourir le tableau en mesurant les temps d’accès. Si une valeur du tableau est récupérée plus rapidement que les autres, c’est qu’elle est déjà dans le cache, donc c’est la valeur retournée par la fonction inderdite !
  
• Spectre utilise la prédiction de branche. L’attaquant utilise une simple condition pour exécuter plusieurs fois la même branche de son programme. Le CPU apprend donc à exécuter en avance les instructions de cette branche. Puis l’attaquant change la condition: le CPU va faire une erreur de prédiction, car il a déjà exécuté la banche « habituelle » et doit désormais exécuter l’autre. Comme dans Meltdown, on dispose de moyens pour mesurer l’effet produit sur le cache.
• Ces attaques permettent de lire l’intégralité de la mémoire du noyau.
• Les moyens d’atténuation sont logiciels.
• Les chercheurs commencent juste à s’intéresser à ce type d’attaque « hardware ». D’autres pourraient sortir et forcer les fondeurs à trouver une nouvelle manière de concevoir des CPU.

En revanche, si vous avez déjà lu des articles sur le sujet, vous n’apprendrez rien. Les 15 minutes d’un quickie ne sont pas suffisantes pour parler de toutes les variantes et de donner tous les détails permettant de comprendre en profondeur.

La vidéo est disponible ici.

Conférence – Monitor Kafka Like a Pro

Survoltée, Gwen Shapira présente avec Xavier Léauté le sujet du monitoring Kafka : quelles métriques suivre ? Pourquoi ? Que signifient-elles ? Quels problèmes puis-je résoudre ? La présentation était dense et fournie en REX clients types, afin d’illustrer un problème typique et les métriques qu’il faut regarder pour en déterminer la cause.

Elle a illustré ses propos par des retours d’expérience avec des clients qui se retrouvent au pied du mur face à des dysfonctionnements d’un cluster Kafka (broker qui ne redémarre plus ou qui n’arrive plus à rejoindre le cluster, etc).

Le plus intéressant était certainement le pragmatisme des explications, qui donnaient en filigrane une méthodologie pour savoir comment trouver la cause d’un problème sur un cluster Kafka avec applications clientes. Les speakers ont bien insisté sur le fait que l’impressionnant dictionnaire de métriques sert davantage à anticiper et à remettre en fonctionnement rapidement, plutôt que simplement au post-mortem.

Les outils d’aide à l’analyse étaient l’autre take away ; passé le flash-publicité sur Confluent Control Center, les speakers nous lâchent gceasy.io pour décoder des logs du garbage collector, Flamescope pour le temps passé par fonction avec toute la pile d’appel, des options extras de JVM comme « PreserveFramePointer » pour faciliter l’analyse des dumps, etc.

Les recommandations données ciblaient aussi bien les brokers Kafka eux-mêmes que l’utilisation des API clients de consommation/production. Gwen a également donné des take away pour se lancer dans les métriques Kafka, aussi bien pour des novices que des experts.

Voici un condensé des métriques à observer sur un cluster :

• les traditionnels CPU/RAM/disk IO/net IO pour toutes les machines,
• les métriques JMX pour toutes JVM,
• latence de requêtes sur les applications clients,
• les métriques spécifiques aux brokers,
• les métriques spécifiques aux topics,
• lag relatif par partition (consumer offset lag),
• offset de fin de chaque topic/partition.

En conclusion, si vous avez du Kafka en prod ou même si vous envisagez d’en installer ou d’en utiliser, voici une conférence indispensable à voir et à revoir.

La vidéo est disponible ici.

Conférence – gRPC, échanges à haute fréquence !

David Caramelo et Carles Sistare nous racontent leur expérience sur Ogury, une plateforme de data mobile engrangeant une grande quantité de données basée sur une architecture micro-services.

Ils nous expliquent que cette architecture, qui prend de plus en plus d’ampleur dans les architectures modernes amène avec lui une problématique : comment limiter l’impact de la latence des requêtes HTTP lors des différents appels aux services ?

Leur objectif est de trouver un moyen d’optimiser au maximum ces requêtes afin d’améliorer les temps de réponse, qui même si unitairement ne représente pas une grande quantité de temps perdus, cela devient un goulot d’étranglement bien visible dès lors qu’une grande quantité de requêtes est effectuée, ce qui arrive rapidement dans le cas de la collecte de data.

La question s’est donc posée : doit-on conserver le modèle REST communément utilisé ou bien trouver une alternative ?

Les problèmes principaux de REST sont :

• Il n’est pas possible de réaliser un flux en streaming de données, chaque requête est synchrone.
• REST ne représente pas un contrat d’API formel et la moindre modification peut être compliquée à propager.

• Les payloads à fournir et les requêtes TCP à ouvrir et fermer font qu’il est gourmand en bande passante.

Plusieurs solutions ont alors été étudiées :

• Websocket :
  • + : Il est possible de maintenir un flux de données.

  • – : Il est compliqué de faire du healthcheck et est plutôt conçu pour du web.

• Swagger :
  • + : On peut s’en servir pour générer du code et ainsi simplifier la propagation des modifications d’API et avoir une documentation constamment à jour.
  • – : C’est un modèle REST.
• Apache Thrift :
  • + : Il utilise le RPC et permet la génération de code pour la maintenance.
  • – : La communauté et le suivi est beaucoup trop faible.

Après avoir étudié ces alternatives, les speakers ont décidé de s’intéresser à gRPC.

gRPC, framework RPC, travaille sur l’optimisation des 3 premières couches du modèle OSI, c’est-à-dire la couche Application, Présentation et Session.

• Pour la couche Application, gRPC utilise par défaut HTTP/2, afin de profiter de sa capacité à faire du multiplexage de requête.

• Pour la couche Présentation, il utilise un framework nommé Protobuf, qui représente la plus grosse optimisation en réduisant au maximum les payload envoyés lors des requêtes.

• Pour la couche Session, il utilise le protocole RCP qui donne un large choix de méthode de communication qui va de la requête synchrone à une communication full duplex.

Protobuf permet avant chaque requête de sérialiser les payloads avant d’envoyer l’information sur le réseau grâce à un fichier de configuration commun partagé entre le client et le serveur, qui permettra à ce dernier de dé-sérialiser le payload et retrouver l’information qui a été réceptionnée, cette sérialisation par exemple permet de transformer un payload de 17 octets à un payload de seulement 3 octets, ce qui n’est pas négligeable quand on traite plusieurs millions de requêtes.

La communication full duplex grâce à RCP ainsi que l’utilisation de HTTP/2 et de Protobuf leur a permis de réduire de 50% les temps de réponse nécessaire à la réalisation des appels à leurs différents services.

La vidéo est disponible ici.

Big Data, Machine Learning, IA & Analytics

Conférence – Génération de code, moteur Catalyst… Démystifions Apache Spark !

Lors de cette conférence, Marc Alonso et Adrien Besnard nous expliquent comment Spark, le framework de calcul distribué, procède pour transformer une requête SQL en code généré.

La présentation commence par des rappels de base sur Spark :

• le RDD (Resilient Distributed Dataset) est l’équivalent d’un itérateur distribué ;
• les DataFrame et Dataset offrent un DSL de manipulation de données distribuées et bénéficient des optimisations du moteur d’exécution SQL de Spark.

Puis Tungsten est évoqué : il s’agit du nom du projet visant à améliorer drastiquement les performances du moteur d’exécution de Spark en termes d’utilisation mémoire et processeur. L’un des grands axes de ce projet est la génération de code à la volée.

S’ensuit une démonstration de génération de code avec un exemple simplifié :

• définition d’une chaine de caractères contenant une définition d’une classe ;
• utilisation de URLClassLoader ;
• instanciation par réflexion (newinstance) ;
• explicitation de la solution pour faire le pont entre le code compilé et généré : l’utilisation d’interfaces (compilées) dans le code généré.

Enfin, il est présenté comment Spark exécute une requête SQL. Schématiquement, le moteur Catalyst passe par les transformations suivantes :

Requête SQL → Sequence[Token] → AST (Abstract Syntax Tree) → LP (Logical Plan) → OLP (Optimized Logical Plan) → PP (Physical Plan) → Iterator[Row] (RDD)

Les grandes étapes sont les suivantes :

• analyse lexicale : permet de passer de la requête SQL brute à une Sequence[Token], où un Token est un mot-clé plus une ou des valeurs ;
• analyse sémantique : permet d’obtenir l’AST ;
• calcul du plan d’exécution logique : résolution des attributs et des types de données ;
• calcul du plan d’exécution logique optimisé : application de règles mathématiques prouvées. Exemple simple : appliquer un filtre avant une jointure permet de la rendre moins coûteuse ;
• plan physique : plusieurs plans physiques (avec les opérateurs de Spark) sont calculés et celui avec le meilleur coût est sélectionné ;
• génération de code.

Marc et Adrien concluent la présentation en synthétisant : la génération de code permet d’améliorer les performances en profitant de divers éléments (JIT, pipelining, etc.) mais n’est possible que sur certains opérateurs, avec comme exception notable les UDF (User Defined Functions). Pour ces dernières, ils recommandent de toujours privilégier les fonctions déjà fournies par Spark lorsque c’est possible.

Bon visionnage.

Conférence – Helpdesk on steroids : How a chatbot and 1 person support 10,000 daily users

Les deux speakers de chez Pictarine ont présenté les étapes de la création de leur chatbot. Pictarine est une application qui permet de rassembler les photos de différents réseaux et de créer des albums collaboratifs. La plupart de ses utilisateurs se trouvent aux USA, et vu le décalage horaire, cela posait des problèmes pour le support. C’est là où l’idée de chatbot est apparue.

Les développeurs ont créé l’outil en plusieurs phases. Ils ont utilisé le framework Dialogflow (anciennement api.ai), de Google. Dans la première phase, ils ont implémenté le fake chat, pour récolter le maximum de questions possibles (et oui, l’interlocuteur ne répondait jamais). Vient ensuite une étape manuelle de catégorisation des questions et de création des réponses associées. Dès qu’ils ont réussi à récolter 200 intents (la correspondance entre la question de l’utilisateur et la réponse du système) la première version du chatbot a été mise en production. Le travail de récolte et de catégorisation continuait jusqu’a 60 % de réponses exactes. Les développements suivants concernaient l’integration du contexte (une fonctionnalité fournie par Dialogflow) pour améliorer l’experience utilisateur. Ainsi le bot a commencé à suivre le sujet tout au long de la conversation (ex. : « quel est le format de l’image ? -> quel est son format ? »).

Aujourd’hui le bot traite de nombreux tickets – il est même capable de les fermer tout seul – et la seule personne du support passe maximum 2 h par jour pour compléter les réponses du chatbot ou bien pour gérer les sujets comme le remboursement qui n’entre pas dans les sujets des intents. L’historique des échanges avec les clients est sauvegardé ce qui rend le service plus efficace et une relation avec le client réussie.

Mobile, IoT

Conférence – La sécurité dans l’IoT : difficultés, failles et contre-mesures

Alexis Duque, Doctorant à l’INSA de Lyon, nous propose lors de cette conférence un tour d’horizon sur l’état de l’IoT dans le monde. Les objets connectés se multiplient à toute vitesse et les problèmes de sécurité qu’ils rencontrent, en faisant un récapitulatif des 10 causes principales de la faible sécurité de ces appareils, issue principalement des fabricants qui sous-estiment la nécessité d’une haute sécurité pour ces objets connectés et la méconnaissance des utilisateurs sur le sujet.

Gartner estime que d’ici 2020, il y aura plus de 20 milliards d’objets connectés en circulation dans le monde. Autant d’appareils qui peuvent potentiellement être piratés et utilisés à des fins malveillantes, telles que l’attaque via le botnet Mirai qui a permis de réaliser des attaques de type DDoS en septembre et octobre 2016 contre le journaliste Brian Krebs ainsi que la société Dyn mettant à mal plusieurs sociétés pendant plusieurs heures (Ebay, Twitter, Netflix, Github et PayPal notamment) en réalisant des attaques pouvant aller jusqu’à 623 Go par seconde. Tout cela grâce à des objets connectés accessibles depuis internet dont les utilisateurs n’avaient pas pris la peine de changer le mot de passe par défaut ou de n’utiliser que des mots de passe faibles.

Cela amène le speaker à nous faire un récapitulatif des 10 principales causes des problèmes de sécurité.

1. Les mots de passe faibles : les mots de passe par défaut ou bien des mots de passe beaucoup trop simples du genre azerty123.

2. La transmission des identifiants trop faible : envoie des mots passe en clair sur le réseau, des id de sessions exposées dans les URL et toute autre méthode permettant la subtilisation des mots de passe

3. Les services réseau non sécurisés : les ports ouverts inutilement sur une machine, un accès wifi inutile.

4. Les problèmes de chiffrement : c’est le cas des réfrigérateurs connecté Samsung, dont les données de connexion aux services Google utilisés n’étaient pas suffisamment chiffrés et ont pu être subtilisés.

5. Les problèmes de confidentialité : c’est le cas des attaques de type Man in the Middle, où l’attaquant se place entre l’utilisateur et l’objet (ou serveur) afin de subtiliser les identifiants lors du transit de l’information sur le réseau.

6. L’insécurité des interfaces web : une interface administration d’un outil qui est accessible par internet et qui serait sujet à des attaques de type XSS.
7. L’insécurité des interfaces mobiles.

8. Les problèmes de configuration : les accès par défaut sont par défaut root ou l’utilisateur à plus de droits que ce qui est nécessaire.

9. Les problèmes logiciels ou firmwares : Les absences de mises à jour de sécurité qui exposent les objets à des failles qui sont révélées au public.

10. La faible sécurité physique : un accès physique à l’objet qui permet d’attaquer via les ports USB ou autre interface (JTAG, Bus Pirate, etc).

Un des problèmes avec les objets connectés est la faible puissance de calcul de ces derniers, ce qui limite aussi grandement leur capacité à utiliser des moyens de chiffrement avancés qui requièrent souvent une capacité de calcul non négligeable.

Alexis Duque nous explique aussi les soucis liés à la technologie Bluetooth v4, qui présente une facilité de piratage déconcertante à cause de son faible niveau de sécurité, bien que corrigé avec la v4.2 qui utilise un algorithme nommé ECDH pour Elliptic Curves Diffie Hellman. Malheureusement, il semblerait que 80% des appareils n’appliquent pas cette implémentation. De plus, aucune méthode d’appairage ne protège des attaques de type MITM (Man in The Middle).

La dernière version de la technologie Bluetooth (la V5) appelée aussi BLE pour Bluetooth Low Energy, n’améliore pas spécialement la sécurité introduite par la 4.2, mais améliore simplement la quantité d’énergie nécessaire à son bon fonctionnement ainsi que sa portée.

La dernière partie de la conférence se concentre sur les bonnes pratiques de la sécurité dans l’IoT qui sont :

• La sécurité par le design : mettre au cœur de la conception les notions de sécurité.
• Réaliser une analyse des risques que peut subir un objet (langage, design, protocoles).

• Concevoir les façons dont un appareil pourra se mettre à jour, notamment pour les correctifs de sécurité.

• Chiffrer toutes les communications et les méthodes d’authentification avec des méthodes de cryptographie standards.

• Ne pas partager les clés de chiffrement entre différents appareils.

• Restreindre les accès, que ce soit pour l’utilisateur connecté ou bien le matériel.

• Assurer la confidentialité des données qui sont utilisées.

Néanmoins, le speaker n’est pas complètement alarmiste sur les objets connectés et conclut avec le futur des objets connectés, tels que le lightweight Crypto for IoT (LWC), une méthode de chiffrement suffisamment sécurisée et ne demandant pas de grandes ressources de calcul qui simplifiera le chiffrement des données et des communications, l’amélioration globale de la sécurité (que ce soit d’un point de vue logiciel ou matériel), l’arrivée des concepts de secure boot, déjà implémenté dans les smartphones ainsi que la sensibilisation générale des différents acteurs sur ce domaine.

Découvrez la vidéo de la conférence.

Langages alternatifs

Conférence – Le code d’aujourd’hui est-il libéré du style impératif à la von Neumann

Thomas Jaskula nous présente son analyse de l’évolution des style de langage : Historiquement, le style de code impératif a été choisi pour répondre aux contraintes techniques des processeurs construit dans les années 50. Or, en 77, John Backus publia un papier où il critique le style impératif imaginé par von Neumann, et propose de nouvelles pistes de langage et d’architecture.

Malgré la percée dans langage fonctionnels et orientés objets, fort est de constater que notre code reste dans les schémas de pensées de von Neuman.

Les raisons sont multiples : les ingénieurs ne sont pas formés à de nouveaux mode de pensées, les architectures existantes sont trop lourdes pour être migrées en d’autre styles, et les langages alternatifs manquent de support marketing pour être promus.

La vidéo est disponible ici.

Tools-in-Action – un Loof ça va, de Loof bonjour les dégâts 😜

Pour cette édition de Devoxx, Nicolas De Loof est venu en famille avec son fils Thomas pour nous parler de l’apprentissage du code chez les jeunes générations et de transmission entre un père et son fils. Thomas 13 ans, déjà très à l’aise devant une salle quasi comble, nous a présenté ses différentes expérimentations du code qu’elles soient poussées par son père, rencontrées à l’école ou liées à ses propres initiatives.

Thomas a commencé par présenté Scratch, logiciel de programmation par bloc qui permet d’animer un avatar très facilement. Il nous a également parlé de son expérience avec les Lego Mindstorm, qui ressemble à du Scratch mais en vrai avec un robot que l’on peut programmer. Nicolas nous confie que les ambitions de son fils dépasse parfois ses capacités ce qui le pousse à expérimenter mais qui peut aussi parfois être frustrant lorsque l’on arrive pas faire ce que l’on veut. Thomas s’est ensuite essayé à la programmation en C avec un Raspberry Pi avec pour objectif de faire clignoter les décorations de Noël. Le passage d’un langage de programmation par bloc au C n’a pas été chose facile, malgré les conseils de son père (« Tu n’as qu’à utiliser un IDE comme Eclipse ! »), cela ressemblait finalement davantage à une punition !

Nicolas a alors décidé de laisser son fils expérimenter par lui même et c’est ce qu’il fit pour offrir à son père un cadeau d’anniversaire mémorable ! Thomas a en effet développé une aventure complète dans MineCraft en apprenant grâce à des tutos sur Youtube. Il s’est approprié les concepts de base de la programmation (comme une boucle ou un wait) avec des blocs d’actions. Nicolas ne pouvait pas espérer plus beau cadeau 🙂.

Bien qu’un peu en décalage par rapport aux autres présentations de la journée, j’ai adoré ce retour d’expérience et je vous invite vivement à voir la vidéo une fois qu’elle sera disponible.

Découvrez la vidéo.