Retour sur la conférence ElixirConf Europe 2020

Article écrit par Nicolas Cavigneaux

Hugo, Eddie et moi-même avons eu la chance cette année de participer à l’ElixirConf EU.

Nous aurions donc dû passer quelques jours à Varsovie mais en ces temps de crise sanitaire, la conférence s’est déroulée à distance, chacun chez soi. Nous devions déjà y être en 2019 mais faute au COVID, l’événement avait été annulé. Les organisateurs ne voulant plus repousser la prochaine édition, ils ont opté pour une conférence virtuelle. Qu’à cela ne tienne, nous visiterons cette belle ville l’année prochaine !

L’ElixirConf a lieu tous les ans et donne la parole à celles et ceux qui utilisent Elixir dans leurs projets, qui développent des frameworks ou autres bibliothèques.

Comme vous le savez, chez Ouidou Nord, on est particulièrement attaché à Ruby et ce depuis le début. Malgré cela, ça fait déjà quelques années qu’on lorgne du côté d’Elixir parce que la techno nous plaît et qu’on pense qu’elle peut parfaitement s’adapter à certaines problématiques. On a même des applications et POC en Elixir ! Il nous semblait donc impensable de rater l’évènement majeur de l’année !

Nous essayerons d’apporter, dans cet article, un résumé rapide du contenu des différentes conférences. Puis, dans une série d’articles à venir, nos retours d’expérience, essais techniques et réflexions autour des problématiques rencontrées.

C’est armés de casques, de micros et de café que nous avons attaqué les premières conférences.

Jour 1

— Bon, c’est bon le son chez toi ? Ça marche ?

— Ralala, c’est trop fort ! Il n’y a pas moyen de baisser le son via le lecteur web de Zoom.

— Tu ne peux pas le faire via le mélangeur de ton système ?

— Pas sous MacOs. Mais c’est bon, j’ai installé un programme pour le faire.

Turn.io / World Health Organization

C’est parti, le premier intervenant nous présente un outil développé au sein de Turn.io qui propose une solution permettant de s’informer et questionner autour de la crise sanitaire actuelle du COVID.

L’idée est d’utiliser la plate-forme WhatsApp et d’y intégrer un chatbot intelligent qui répondra de la façon la plus appropriée aux questions qui lui seront posées.

Il pourra donc informer sur le nouveau nombre de cas recensés ou encore les nouvelles découvertes faites en termes de prévention ou de traitement.

— Combien ? Combien de jour il a dit ?

— 7

— 7 jours ! Des premiers devs à la mise en production ?!

L’application a effectivement été écrite et mise à disposition en privé en 7 jours puis 3 jours plus tard pour l’ouverture au public.

La stack technique pour répondre au besoin est composée comme suit :

• Kubernetes -> AWS -> Terraform
• PostgreSQL
• ElasticSearch
• Phoenix + React
• Absinthe + Apollo (GraphQL)
• Quantume + Highlander pour les tâches programmées
• Faktory pour les files de messages
• ExRated pour limiter le nombre d’appels aux API externes

L’application a été mise à disposition dans plusieurs zones du monde pour la rendre plus réactive et répartir la charge.

On remarque que grâce à BEAM, il est facile de se passer de certains outils externes pour les remplacer par des outils fournis par OTP. La stack Elixir permet de concevoir des applications qui vont facilement au-delà de la logique requête / réponse, elle facilite le code distribué et le monitoring.

Le lancement public a été un franc succès :

— 10 millions d’utilisateurs en 48h ? Difficile de vérifier les chiffres, mais c’est impressionnant !

Développement d’un interpréteur WebAssembly en live

Nous enchaînons sur une nouvelle conférence en live-coding cette fois. Nous allons voir du code !

L’intervenant développe un interpréteur WebAssembly basique devant nos yeux ébahis.

Il utilise un code WebAssembly compilé, donc, et nous présente comment le pattern matching lui permet de détecter facilement les suites binaires et d’exécuter les instructions correspondantes en Elixir.

— J’aimerais tellement avoir ça sur mon projet actuel !

Fin de cette première présentation, c’est la récré !

Le temps idéal pour remplir les auges, rapporter quelques fruits et de s’aérer l’esprit.

Questions ouvertes

La prochaine séance sera un #AskMeAnythingAbout où différents intervenants répondront aux questions posées.

Dans le «Ask Me Anything About Phoenix LiveView», les points qui reviennent le plus souvent sont les suivants :

Le plus gros avantage de LiveView ?

• Continuer d’écrire le code et les tests en Elixir pour le front
• Faciliter l’écriture d’une application front stateful

Framework front + LiveView sur la même page, ça fonctionne ?

Ça reste tout à fait possible avec un peu de code pour faire communiquer les deux. Heureusement LiveView propose tout un tas de hooks accessibles en JavaScript et qui permettent d’être tenu au courant au moindre changement ou même de déclencher un comportement dans LiveView.

La plus grosse limitation de LiveView

La possibilité de l’utiliser en mode hors-connexion. LiveView a besoin de parler au serveur même si ces échanges sont très petits et fonctionnent parfaitement avec une connexion modeste.

Sans connexion internet, pas de LiveView !

— La suite, la suite !

Big Data en Elixir

Nouveau retour d’expérience dans lequel on nous présente l’utilisation d’Elixir pour du traitement de big data ainsi que les difficultés rencontrées.

Le service développé permet de programmer des pipelines de traitement de données en tirant parti d’instances de cloud computing à la demande ce que ne semble pas pouvoir faire (facilement) Apache AirFlow ou Luigi qui représentent pourtant l’état de l’art en ce qui concerne les workflows DAG.

On parle de 53TB de données à traiter et 65 milliards de points d’analyse.

Une fois encore, pourquoi utiliser Elixir ? Simplement pour utiliser le même langage partout. Il s’est avéré qu’OTP a de nouveau été d’une aide très précieuse.

La bonne surprise, c’est la facilité à utiliser les ressources machine disponibles à leur maximum grâce à BEAM et Elixir. La machine virtuelle s’en occupe pour nous sans qu’on ait trop à y penser, là où dans d’autres langages ça aurait pu être un vrai défi.

De ce fait, les traitements se font de manière optimale, plus vite et à moindre coût. L’intervenant va même jusqu’à dire qu’utiliser OTP était quasiment de la triche.

Il nous est vivement recommandé d’utiliser Exexec dès que nous avons besoin de faire appel à des programmes externes à l’environnement BEAM, sous peine de laisser traîner des processus fantômes, ou de faire planter l’ensemble de la VM si le programme externe venait à planter. Ça serait effectivement dommage puisque l’un des gros avantages de BEAM est sa robustesse et sa capacité à relancer les processus qui plantent.

Pour la conférence suivante, nous avons commencé à nous séparer pour couvrir plus de terrain. Certains talks se déroulaient en même temps.

— Je prends celui sur le clavier !

— Moi aussi

— Ça tombe bien, je connais déjà un peu Nerves. Je vais voir l’autre.

Créer son clavier avec Nerves

Du côté d’Eddie et Hugo, l’intervenant se présente comme un passionné de claviers.

Il en a déjà construit plusieurs, mais aujourd’hui il va expliquer comment Nerves lui permet de simplifier la couche logicielle de son dernier jouet.

Nerves est un outil pour déployer un environnement Linux pré-configuré embarquant un programme Elixir à destination de micro-ordinateurs comme les RaspberryPi.

Il nous montre comment cette solution lui a permis de coder facilement la couche logicielle pour interpréter et envoyer le bon signal lors de l’appui sur les touches.

— Ouah, c’est quand même stylé. Il peut modifier la disposition de son clavier à la volée !

— C’est vrai que c’est pas mal. Mais bon, ça reste un peu lourd comme solution pour simplement gérer un clavier…

— Ça montre au moins le potentiel !

Surface – une lib orientée composants pour LiveView

Ce talk est donné par un développeur de chez Dashbit, la boîte de José Valim, créateur d’Elixir, Wojtek Mach core developer d’Ecto et Marlus Saraiva le créateur de Broadway.

Et c’est donc Marlus qui parle, ça promet du bon !

Il commence par nous donner les motivations derrière l’écriture de Surface, un bibliothèque qui permet d’utiliser des composants dans LiveView.

LiveView semble déjà bien robuste malgré son jeune âge, c’est donc intéressant de comprendre les lacunes que Surface se propose de combler :

• les templates LiveView sont flexibles mais difficiles à maintenir sur les gros projets
• Il n’y a aucun standard pour créer des composants (au sens Vue.js / React) malgré les bonnes fondations de LiveComponent

Alors qu’apporte surface ?

• création de composants très similaire à ce qu’on peut faire en Vue.js
• introspection dans l’éditeur pour connaître les propriétés d’un composant, celles requises ou non, les valeurs par défaut, etc
• utilisation de slots comme placeholders qu’on pourra venir remplacer avec du contenu personnalisé, les slots pouvant être obligatoires ou avoir du contenu par défaut
• composants renderless
• MacroComponent dont le but est de laisser le composant interpréter lui-même le contenu qui lui est passé. On pourra par exemple créer un composant capable de lire du Markdown et d’en faire le rendu
• Validation du code à la compilation

Et quoi pour la suite ?

• composants orientés UI (Bulma, Tailwind)
• styles CSS scopés
• ajout de tâches Mix

— C’était bien la préz Surface ?

— Super intéressant ! Ça donne envie de tester ! On doit se séparer à nouveau là aussi non ?

— Oui, à toute !

Erlang et typage

De notre côté (Hugo et Eddie), l’intervenante nous présente un historique des tentatives d’introduction d’un système de typage au sein d’Erlang.

Qu’est-ce qu’un système de typage et pourquoi c’est si difficile d’introduire ça dans Erlang ?

Cet écosystème permet de mettre en place du code hot swap (changer du code dans une app qui tourne sans avoir à l’arrêter). Cela pose énormément de problèmes dès lors qu’on cherche à valider le type des données utilisées au cours d’un programme.

Certaines solutions sont toujours envisagées et les essais se tournent maintenant vers la technique de « Session Types » qui consiste à appliquer des types uniquement sur les protocoles, le reste du code se basant sur ces protocoles pour implémenter leur logique.

Introduire Elixir dans le SI d’une banque

Ce talk est un retour d’expérience sur la création et mise en place d’un système de paiement par reconnaissance faciale. Il a été mis en place dans des cafés en Finlande et a connu un bon succès avec la crise du COVID et la peur des gens de toucher des choses potentiellement contaminées.

Les banques sont des institutions dans lesquelles il est difficile d’introduire de nouvelles technos. C’est facilement compréhensible quand on pense aux enjeux derrière le SI d’une banque.

Pour développer une application pour une banque, il faut pouvoir répondre à quelques contraintes :

• possibilités d’audit
• impossibilité pour les développeurs d’accéder aux environnements de production
• les données doivent être gérées de manière à respecter les RGPD et la vie privée
• les applications doivent être stables et pouvoir tourner pendant des décennies
• tout le code tierce utilisé doit être traçable

Pour que ce système de paiement sans contact rencontre un succès et soit adopté, il fallait absolument que le temps de paiement entre le moment où l’utilisateur présente son visage et le moment où son paiement est confirmé prenne moins de trois secondes.

Une fois le produit développé, il a fallu faire auditer le code par une société tierce. Cette société auditait pour la première fois du code Elixir, elle a fait comme retour à l’équipe de développement que c’était probablement le code le plus compréhensible qu’ils avaient eu à revoir. Ceci étant sûrement dû au côté fonctionnel d’Elixir et à l’immutabilité.

— Le prochain talk c’est sur les game engines ! Je l’attendais tellement !

— J’espère qu’on ne sera pas déçus

Building Game Engines in Elixir

On est forcément curieux dès que l’on parle de game engines.

Gabriel Kolawole nous présente son jeu qui se limite malheureusement à une roulette virtuelle ce qui met fin à notre enthousiasme.

Malgré tout, la logique du jeu se prête bien à l’utilisation de GenServer. La supervision des différents processus permet aux joueurs de rejoindre les parties à la volée.

La durée des présentations étant assez limitée, c’est finalement un bon point de départ pour commencer à imaginer les possibles architectures d’un game engine plus évolué.

The perils of large files

L’autre keynote en parallèle avait pour thème un retour d’expérience sur la gestion des gros fichiers en Elixir, les pièges et techniques pour découvrir les goulots d’étranglement.

Claudio Ortolina, développeur chez PSPDFKit nous explique donc comment ils ont fait pour pouvoir recevoir et traiter sur leur service en ligne de manipulation de fichiers PDF des fichiers allant de quelques Kb à plusieurs Gb.

Pour commencer il nous explique que les fichiers sont envoyés en direct vers S3 puis qu’un hachage est fait dessus pour être ensuite cachés.

Les dangers identifiés liés au traitement de fichier si lourds et complexes étaient :

• consommation excessive de mémoire
• fuite de mémoire
• consommation excessive de CPU / ES lors du traitement des fichiers

Claudio nous fait donc la démonstration de la lecture d’un fichier volumineux d’une traite (en utilisant File.read!) à travers un GenServer.

Il écrit ensuite un test qui va permettre de vérifier la mémoire totale disponible, lire le fichier, vérifier à nouveau la mémoire totale disponible pour savoir si le processus de lecture des fichiers crée une fuite de mémoire.

Pour avoir une analyse détaillée, il utilise le paquet recon et notamment sa fonction bin_leak qui permet de forcer le déclenchement du garbage collector (GC) et obtenir un delta.

Le code et l’outil utilisés pour faire ces comparatifs semblent vraiment très simples à mettre en œuvre. Ils permettent de voir très clairement que, sans forcer le GC, la mémoire a été très largement retenue par la lecture de fichier.

C’est un souci dans le cas de Claudio qui doit, pour ses besoins, générer un SHA des fichiers qui sont uploadés. Il doit les lire dans leur entièreté.

C’est pourquoi il nous présente ensuite File.stream! qui va permettre de lire le fichier morceau par morceau et de construire le SHA de manière incrémentale.

Avec cette modification plutôt simple à mettre en œuvre, les tests montrent qu’après un hachage, quasiment aucune mémoire supplémentaire n’a été consommée, sans que le GC n’ait besoin d’intervenir.

Cette présentation montre bien que les fonctions de stream en Elixir sont une pierre angulaire lorsque vous voulez écrire des applications qui doivent traiter une grande quantité de données tout en restant réactives et légères. Il y a d’ailleurs une keynote à venir complètement dédiée à ce sujet !

Pour finir, Claudio nous conseille de collecter des métriques autour des opérations de manipulation de fichiers et de faire du Soak testing avant d’aller en production.

Telemetry and LiveDashboard

Cette première journée se termine sur une keynote de Sophie DeBenedetto qui nous présente Telemetry, un module Erlang qui permet de mesurer et reporter différentes métriques.

Telemetry est intégré au framework web Phoenix depuis sa version 1.5.

On a maintenant accès, sans aucun effort, à un dashboard rempli d’informations nous indiquant tout ce qu’il se passe dans notre app Phoenix, que ce soit :

• les versions des bibliothèques utilisées
• l’uptime, la consommation mémoire et CPU
• les requêtes et réponses HTTP
• les requêtes à la base de données
• les sockets utilisées
• les tables ETS
• …

Ce dashboard est très facilement extensible grâce à un protocole qui nous est mis à disposition et peut être utilisé sans souci en production.

À partir du dashboard, il est possible d’accéder aux stats et informations de n’importe quel autre nœud inter-connecté.

Ce dashboard utilise LiveView ce qui permet d’avoir des informations mises-à-jour en temps réel.

Finalement, ce dashboard rend quasiment inutiles toute une flotte d’outils externes de monitoring.

L’effet « Wahou » devrait être présent la première fois où vous découvrirez cet outil.

Bilan de la journée

Pour cette première journée, les sujets ont été vraiment variés et on a pu voir un peu de tout.

Elixir profite d’un écosystème riche et auto-suffisant. Si on se concentre sur la partie Web, qui est notre cœur de métier, une application web Phoenix est différente des autres. Elle peut aller au-delà de la traditionnelle boucle requête / réponse, gérer des processus longs ou des tâches récurrentes sans avoir à faire appel à des outils tiers. Sa VM lui permet d’être indépendant du système d’exploitation et monitorable. Et avec LiveView on peut maintenant créer des interfaces web interactives sans avoir besoin de sortir du langage Elixir.

Jour 2

C’est le matin, les oiseaux chantent, et en fait non, il est déjà 13 heures ! L’heure de l’ElixirConf ! On fait comme la veille, le café, les fruits, tout ça tout ça. Vous avez l’idée !

— C’est quoi la première conf ?

— Un retour d’expérience sur la création d’une application pour contacter des secours en Phoenix Elixir

Building an emergency software with Phoenix Elixir

Nos deux intervenants nous parlent de leur solution qui permet de contacter rapidement les hôpitaux environnants. Cette application est à destination des personnes à la santé fragile ou à risque de crise et/ou perte de connaissance.

On a finalement peu de choses à se mettre sous la dent puisque aucune ligne de code ne sera présentée. La présentation se concentre principalement sur l’historique du projet, les raisons de sa naissance et parle peu des solutions techniques employées.

Les deux protagonistes semblent être des profils plutôt junior en développement de manière générale.

C’est parti pour les keynotes en parallèle ! Une fois n’est pas coutume, on se sépare.

6 Lessons that Elixir taught me about Distributed Systems

La présentation suivante semble beaucoup plus concrète que la précédente. En tout cas, c’est ce que laisse présager l’intitulé. Veronica Lopez nous présente 6 leçons qu’elle a tiré des systèmes distribués grâce à Elixir.

Elle nous explique notamment qu’elle a beaucoup travaillé avec Kubernetes et qu’elle trouve beaucoup d’avantages à développer avec Elixir.

En fin de compte, ces points sont plutôt nébuleux et on a du mal à tirer du concret de cette présentation.

Visual concurrency cookbook

Daniel Vamosi nous présente un outil développé pour sa société qui fait du booking de transport aérien.

L’outil nommé « Paparazzi ! » permet de visualiser la vie des acteurs au sein de la machine virtuelle Erlang.

Cet outil est impressionnant et nous sort de très beaux graphiques qui évoluent en temps réel en fonction de ce qu’il se passe dans la VM. On y voit qui est qui, ses relations avec les autres acteurs (ou processus). Une timeline est également générée dessous pour comprendre à quel moment un acteur prend vie et meurt.

Cet outil est basé sur une brique Elixir pure (Recorder), un analyseur de données qui est une API en Phoenix et D3.js pour l’affichage du graphe et de la timeline.

On a donc pu voir l’outil en action mais rien de plus, pas d’explication précise sur le fonctionnement ou des exemples de code. J’ai également essayé de trouver trace de cet outil en ligne mais le GitHub de l’auteur ne contient qu’un fichier de licence.

Ce n’est donc pas une présentation qui m’a spécialement marquée comme vous devez vous en douter.

— Décidément on ne commence pas avec du concret aujourd’hui.

Ask me anything about Nerves

Pour ma part (Nico), j’assiste à la session autour de Nerves, un sujet qui m’intéresse beaucoup et qui me donne clairement envie de faire un peu plus d’embarqué en Elixir pendant mon temps libre.

Ces questions / réponses mènent à plusieurs constats :

• l’outillage de Nerves est extrêmement fiable et mature
• le meilleur moyen de commencer à utiliser Nerves est d’utiliser un RaspberryPi ainsi qu’un kit de composants électroniques
• puis de trouver des petits problèmes de la vie de tous les jours qui vous ennuient depuis plusieurs mois et d’essayer de les résoudre
• on achète beaucoup de gadgets « intelligents » mais en faisant ça, on vend sa vie, ses données personnelles aux géants de l’industrie, pourquoi ne pas les remplacer ?

Les autres «Ask me anything about X»

Les deux autres sujets étaient dédiés à :

• Faire de l’Elixir quand on vient d’un autre langage / paradigme
• Œuvrer pour le bien en codant

Event Sourcing with Elixir

— L’event sourcing, là c’est bon, on va voir du code !

— Attends ne crie pas victoire trop vite.

Peter Ullrich commence par présenter le concept d’event sourcing. C’est un paradigme par lequel tout ou partie des actions qui vont affecter les données (ou plus largement le système d’information) sera stocké sous la forme d’événements.

Pourquoi ? Dans quel contexte ?

Eh bien il y a des industries dans lesquelles c’est tout simplement obligatoire d’avoir une traçabilité des événements survenus, que ce soit pour des raisons légales ou d’audit. On pensera naturellement au milieu bancaire mais c’est loin d’être le seul à avoir ce besoin.

L’event sourcing peut également être très pratique lorsqu’il s’agit de debugger. Comme chaque changement est tracé et rejouable il devient plus facile de savoir quelle action a introduit une erreur. On peut même imaginer corriger un bug et faire rejouer des flux entiers pour corriger les données.

L’event sourcing permet également de faire des voyages dans le temps à travers les données, de simuler des états alternatifs, de revenir à un état qui était perdu et même dans certains cas de booster les performances d’une application, en se passant d’une base de données, grâce au stockage des états courants en mémoire.

Comment ?

Il s’agit de documenter chaque changement d’état au travers d’événements.

On stockera les arguments d’entrée ainsi que d’autres meta-données comme l’utilisateur ayant déclenché l’action ou l’URL de provenance.

L’un des objectifs étant de pouvoir rejouer une suite d’événements, chaque événement est placé dans une stream qui est une liste ordonnée d’événements correspondant au cycle de vie complet d’un élément donné.

Peter, après nous avoir expliqué le pourquoi et le comment, nous fait une démonstration en Elixir.

Cette démo se base sur le paquet eventstore qui facilite la mise en place des concepts d’event sourcing. Tous les événements et flux sont stockés dans une base PostgreSQL au format JSONB. Il n’y a donc pas besoin de mettre en place une infra plus lourde à base de RabbitMQ, Kafka, SQS.

Il nous montre notamment sa méthode de prédilection pour encapsuler les actions courantes comme la publication et la consommation d’événements.

Cette présentation, à laquelle nous avons assisté tous les trois, nous a beaucoup plu ; le sujet est très intéressant et les explications étaient concrètes grâce à la démo.

Probablement la présentation qui nous a le plus captivés jusque-là.

Crashing BEAM applications

Pour la présentation suivante, un nouveau retour d’expérience.

Cette fois-ci, Guilherme de Maio nous parle des différents grains de sables qui ont réussi à faire planter son application et parfois même la VM. Bien que le credo de BEAM soit la résilience, il reste possible d’écrire du code qui ne pardonnera pas.

Les exemples vont du mauvais choix d’arguments pour définir la politique de redémarrage de processus jusqu’à une mauvaise gestion de la libération de mémoire.

On notera particulièrement :

• les « atoms overflow » qui, à l’instar de Ruby il n’y a pas encore si longtemps, peuvent saturer la mémoire. Les atomes (équivalent des symboles en Ruby) ne sont pas garbage-collectés par la VM. C’est un choix, mais un choix dont il faut avoir conscience ! Alors attention à ne pas créer des atomes à la volée (String.to_atom())
• le mauvais usage de start_link qui peut mener à des processus enfants orphelins par dizaines.
• le mauvais usage des stratégies de supervision des processus (transient vs temporary) qui faisait que lorsqu’une API distante était indisponible des processus étaient créés en boucle dans son application.

Ce talk nous apprend beaucoup sur le fonctionnement interne de BEAM et c’est très enrichissant.

Comme le dit Guilherme, lisez la documentation, ça vous épargnera bien des surprises. Les problèmes qu’il a rencontrés ont pu être réglés en changeant la plupart du temps un seul paramètre dont le fonctionnement était clairement décrit dans la documentation.

— Le sujet sur la team de 5 personnes qui a créé une open bank au Brésil ne me dit rien !

— Tous sur le talk Nerves alors !

Taking back control of your file with Nerves

Ju Liu nous invite à la méfiance éthique et économique vis-à-vis des appareils connectés et nous propose une alternative, le DIY.

En tant que développeurs, nous avons un rôle à jouer pour inciter à garder un contrôle sur nos appareils.

Aujourd’hui il n’est plus rare de voir un Amazon Echo, une sonnette connectée, des drones ou autres montres ou frigos connectés à peu près partout.

Le souci c’est que bien souvent, derrière ces gadgets qui nous facilitent la vie, se trouve une poignée de géants de l’industrie dont le seul but est de collecter des données sur ses utilisateurs pour les revendre aux plus offrants.

Même les petites boîtes, qui aujourd’hui sont pleines de bonnes intentions, finiront par être rachetées par des géants moins scrupuleux.

Nous n’avons aucun contrôle sur nos gadgets intelligents, difficile de savoir ce qu’ils font, les données qu’ils collectent ou envoient. L’alternative, pour nous développeurs, pourrait être le DIY. En construisant ces gadgets nous-mêmes, nous sommes en mesure de savoir ce qu’ils font.

Nerves semble être, en effet, une solution facile à mettre en place et qui présente plusieurs avantages.

Pour l’exemple, Ju nous présente une problématique qu’il rencontre au quotidien avec sa cafetière italienne. L’exposé est simple : Comment avertir le développeur à son bureau que le café est prêt dans l’autre pièce avant qu’il ne brûle ?

Pour répondre à ce besoin, Ju nous montre sa solution. Un Raspberry Pi relié à un capteur d’humidité, à une diode et pour lequel il a codé un petit programme pour le prévenir par message dès qu’un certain taux d’humidité souhaité est atteint. La diode lui servant à être sûr que le soft tourne avant de quitter la cuisine.

Cet exemple, basique mais amusant, est surtout un moyen de montrer comment Nerves lui permet de déployer facilement son logiciel sur l’appareil sans avoir à se soucier de l’installation d’un OS. Il nous parle également de NervesHub qui permet de déployer facilement de nouvelles versions sur toute une flotte de gadgets connectés pour qu’il redémarre sur la nouvelle version du logiciel sans intervention.

Il nous fait la démonstration d’ajouter la gestion de l’allumage d’une diode lorsque le RaspberryPi est prêt pour la détection de l’humidité. Cette nouvelle version est déployée à travers un simple upload vers NervesHub et il finit même en accédant en SSH à son RaspberryPi à distance depuis l’interface Web.

Pour ceux qui aiment Elixir et les gadgets, ça donne envie !

Practical Elixir Streams

Pour ce dernier talk avant la keynote de fermeture, c’est Evadne Wu qui va nous parler en profondeur des fonctionnalités de stream en Elixir.

Elle a l’air déterminée, ça ne rigole pas, ça ne sourit pas, ça code en expliquant et plutôt vite !

Globalement sa présentation a pour but d’expliquer comment faire en sorte de minimiser les latences, empêcher le système de saturer et réduire l’utilisation des ressources en éliminant les pics.

Pour ce faire, son conseil est simple. En Elixir tout est Enumerable ou peut l’être puisque ça se base sur des protocoles.

La plus grande partie de notre code, langage fonctionnel oblige, se base sur map, reduce, for etc.

Les Enumerable peuvent être infinis et générer du contenu à la volée. Aussi si vous voulez optimiser votre code, le plus simple sera de remplacer vos appels à Enumerable par Stream puisque la plupart des fonctions du premier ont leur contrepartie dans le deuxième.

Avec cette simple règle, plutôt que de traiter vos collections d’un seul bloc au risque de mettre votre machine à genoux, vous pourrez les traiter par morceaux.

Les streams ont la particularité de déclencher les calculs à la demande, ce qui nous permet d’imbriquer des boucles et des fonctions récursives sans que les calculs soient déclenchés au fur et à mesure.

Pour faire court, jetez un œil aux docs de Stream, Task.async_stream ou encore Ecto.Repo.stream.

Un article au sujet de l’utilisation des streams en Elixir viendra bientôt, promis !

And it’s a wrap !

Et nous voilà arrivés à la keynote de clôture de cette édition 2020 de l’ElixirConf EU !

Sans surprise, ce sera Chris McChord la vedette, et le thème sera un Q&A autour de LiveView qui décidément reste un sujet très chaud !

Beaucoup de questions seront posées, mais on retiendra que Chris ne souhaite pas que LiveView deviennent un framework JavaScript complet qui tenterait de refaire ce que font déjà les frameworks actuels. Il n’y aura donc pas une multiplication des hooks pour pouvoir faire tout et n’importe quoi.

Chris semble dire qu’à titre personnel, il utilise de plus en plus LiveView en lieu et place des vues HTML classiques pour produire le rendu de ses pages, ce qui lui permet de les rendre très facilement dynamiques. Il continue évidemment à utiliser des contrôleurs classiques pour les endpoints API.

En fin de keynote, suite à une question sur la difficulté d’utiliser LiveView pour créer un système de visio, Chris a tout simplement dit « Je vous montre ! ».

Cinquante lignes d’Elixir et une trentaine de lignes de JS plus tard, il avait un système fonctionnel avec un délai de l’ordre de 5 secondes. Un début de Twitch en quelque sorte ! Cette démo se base sur des fonctionnalités ajoutées récemment à Phoenix mais qui ne sont pas encore disponibles dans la dernière version stable.

Pour conclure, cette conférence nous aura permis de passer un moment agréable même si les conférences virtuelles n’ont pas le charme des conférences classiques où on peut rencontrer des personnes, discuter de vive voix, manger ensemble.

On aura pu y apprendre des choses et prendre la température de la communauté et des projets phares. Nerves et Phoenix LiveView semblent être les sujets les plus chauds en ce moment.

Vous pouvez retrouver quelques-unes de ces keynotes sur YouTube.