Retour sur les conférences de la saison 3 du DevFest de Lille ! (2/2)

Nous y voilà ! Il y a quelques jours, Guillaume vous parlait de la saison 3 du DevFest de Lille et de ressenti sur cette journée de conférences autour des sujets du Web, du Mobile et du Cloud.

Aujourd’hui, Matthias, lead tech à La Mobilery, revient sur les différentes conférences auxquelles il a participé.

On y est, DevFest 2019. Cette année est placée sous le signe du cinéma et pas n’importe lequel, le cinéma du petit écran ! On nous loue les mérites du cinéma français qui avait, il y a près de 50 ans déjà, inventé les styles de séries parmi les plus regardées aujourd’hui. On retrouve par exemple “Les Rois Maudits” ou “Planète Interdite” qui peuvent étrangement faire penser à des séries comme Game of Thrones ou Star Trek. Et oui, ça fait déjà quelque temps que les Français font preuve d’imagination, d’inventivité et prennent l’initiative en tant que précurseurs dans certains domaines. C’est aussi pour ça que nous sommes présents à l’ouverture d’un des salons les plus emblématiques du développement “à la française”.

Au menu de la journée, une trentaine de conférences réparties sur 4 salles de cinéma (Mince, on va devoir faire une liste de priorités !), les sujets sont variés : Big Data, Cloud, DevOps, Backend, IOT, Web et bien sûr du Mobile 😉

“La programmation réactive avec Spring Webflux”

Une fois n’est pas coutume j’ai décidé de suivre une conférence Backend… Et en plus c’est du Java ! Comme vous le savez peut-être la programmation réactive est de plus en plus présente dans nos univers de développement. En ayant moi-même pas mal utilisé en Swift, Kotlin et Javascript ces dernières années j’étais très curieux de savoir ce que nos confrères du monde Java allaient nous montrer.

La question est posée : comment réaliser une API REST avec Spring Webflux ? Et quoi de mieux pour présenter cette technologie qu’avec une étude comparative entre une API Spring Weblux et une API Java classique ?

Le premier gros points qu’on note c’est au niveau des performances de charge du serveur. Alors qu’une API classique est limitée par le nombre de threads accessibles (100 thread = 100 connexions simultanées), l’API Webflux peut partager des threads pour plusieurs requêtes. Les stress tests de charge montrent du coup beaucoup moins de retours d’erreur. Point de vue temps de réponse c’est à peu près similaire, pas de miracle sur ce point.

Ce qui m’a beaucoup intéressé par la suite c’est le parallèle inévitable entre le reactive programming Java et Javascript. Les principes sont quasiment identiques à quelques exceptions près. Le Java a une exécution multi-thread dont il faut tenir compte, il y a donc une limitation à 256 appels simultanés pour chaque fonction callback définie dans un “map” ou “flatMap” par exemple.

En bonus il existe déjà des librairies compatibles pour créer des tests d’intégration et on notera aussi la possibilité d’avoir toute une palanquée de fonctions très pratiques comme le retry() ou le retryWhen() qui permettent de gérer certains cas d’erreur.

Pour finir sur un défaut, on nous dit que la courbe d’apprentissage est assez rude si on n’a jamais fait de reactive programming. Quand bien même, le développeur qui utilise ces concepts depuis près d’un an nous assure qu’il aurait beaucoup de mal aujourd’hui à se passer de ça. Et je ne peux qu’être d’accord avec lui, le reactive programming c’est génial ! https://youtu.be/WhDCcdPVV_s

“Comment perdre sa surcharge featurale”

C’est une ex-développeuse, aujourd’hui Product Owner qui nous présente ce néologisme franglais. Les plus perspicaces l’auront compris, on souhaite nous parler ici de la surcharge fonctionnelle dans nos applications.

En tant que développeur, combien de fois avons-nous entendu un client, chef de projet ou product owner nous dire qu’il voulait une feature en plus parce qu’un utilisateur a trouvé qu’il manquait quelque chose ou “pour simplifier la vie des contributeurs” ou encore plus simplement pour dire “Je trouve que le bouton est trop gros et trop vert…”

La conséquence logique de tout bon développeur qui ne sait pas dire non c’est d’ajouter et ajouter jusqu’à ajouter LA feature de trop. Celle qui casse tout le projet ou qui demande de réécrire la majorité du code.

Elle nous tient … Vous l’aurez compris, ce sujet parle malheureusement à beaucoup trop de gens présents dans la salle et c’est tout naturellement que l’attention atteint son paroxysme. La question se pose alors, comment faire comprendre à tous ses gens que supprimer des fonctions d’une application peut être bénéfique ? Ou mieux encore, parfois laisser mourir une application est peut être la meilleure solution. Elle nous parle de l’exemple de FogBugz, peu sont capables de dire de quoi il s’agissait et c’est pourtant ce sont les gens de Trello qui l’ont laissé se consumer pour mieux le faire renaître de ses cendres dans l’application que nous connaissons tous…

On nous parle ensuite de quelques outils empruntés au monde de la psychologie qui peuvent s’avérer utile si on considère la RAZ d’un projet. Comme par exemple le golden circle, trois cercles imbriqués les uns dans les autres qui représentent au centre le Why, puis le How et enfin le What. Ce sont les questions qu’il faut se poser et qui permettent de redéfinir l’essence d’une application ou d’une entreprise.

Pour répondre à la première question “why” on nous présente la “cover story” ou comment voit-on l’entreprise dans 5 ans. Plusieurs personnes de tous les métiers imaginent ensemble le futur en remplissant la page de couverture d’un magazine qui exposerait les meilleurs traits. Le but est de définir ce à quoi on tend, le but.

Ensuite la question “how” avec l’invention de personas applicatifs fictifs. Le but étant d’imaginer avec le plus de détail possible des utilisateurs clefs pour pouvoir déterminer comment arriver au mieux vers les buts qu’on s’est fixés.

Enfin, pour la question “what”, on nous présente le “card sorting” et le “dot voting” pour prioriser les tâches. De préférence laisser la priorisation à un utilisateur lambda permet d’avoir une meilleure estimation de l’importance des tâches.

On nous parle éventuellement d’une quatrième question, “how far” qui concerne l’évolution après que le projet soit fini et la vérification qu’il suit bien les attentes et qu’il ne se détériore pas. Parmi les quelques tests intéressants on note :

  • Le test des 5 secondes. Montrer l’application à une personne qui ne l’a jamais vue pendant 5 secondes et lui demander de la redessiner. Ce qui permettrait de voir tout de suite si le design est intuitif et que les features importantes sont bien mises en avant. Le test peut être réitéré ensuite avec des périodes plus longues comme 10 ou 15 secondes pour laisser le temps à l’utilisateur de préciser les features secondaires voire tertiaires.
  • Le test “de la ménagère”. Laisser une personne qui a peu de maîtrise de la technologie et constater les pires “Bah ça marche pas votre truc”. Tout ça avec si possible un enregistrement du parcours utilisateur pour mieux comprendre les blocages.
  • Le test de complétion de phrases. On donne des phrases à trous aux utilisateurs du genre “l’application XXXX est particulièrement ______” ou “je trouve qu’il est ______ de prendre en main XXXX”

Enfin la conférence est clôturée par la mention des outils connus tels que Google Analytics ou Hotjar qui permettent d’évaluer les parcours utilisateur avec beaucoup de précision.

“Premiers pas avec un microcontrôleur et Google Cloud IoT Core”

L’Internet of Things ou IoT est en vogue depuis quelques années déjà, on n’imagine pas la quantité de nouveaux objets “intelligents” qui existe actuellement. Aujourd’hui notre interlocuteur nous présente Google IoT Core, un service de gestion des données ainsi qu’un petit microcontrôleur de plus en plus connu, l’ESP8266.

Avant de commencer une question est lancée, “Qui a déjà développé sur microcontrôleur ?”. Une majorité des développeurs présents répondent par l’affirmative. Mine de rien c’est un sujet qui passionne plus d’un curieux, même parmi les développeurs qui ne pratiquent pas dans leur milieu professionnel.

On s’aperçoit très vite que cette conférence n’est pas juste un cours théorique mais une vraie démonstration en temps réel. Muni d’une petite caméra sur son pupitre, notre hôte nous présente en gros plan plusieurs références parmi les plus connues des microcontrôleurs. On note par exemple l’Arduino nano de la taille d’un pouce ou le fameux ESP8266, lui-même très compact. C’est d’ailleurs cette caractéristique qui le rend si populaire car en plus d’être compact il dispose d’un module Wifi, d’une puissance plusieurs fois supérieure à l’Arduino (80Mhz et 64Kio de RAM) et peut utiliser les protocols de communication I2C et SPI. Un rapide passage par un site de vente en ligne nous démontre que les prix sont vraiment abordables pour la plupart des composants, aux alentours de 5 euros.

Une rapide démonstration est mise en place, on nous apprend à programmer un Arduino grâce à l’IDE Arduino et on note tout de même qu’il est possible de programmer ce genre de carte via plusieurs langages tels que C, C++, Java, JavaScript bien que le C Arduino soit le plus facile à appréhender pour un novice. Le but de la démo est d’afficher toutes les secondes la température d’un capteur connecté via I2C, on voit d’ailleurs que l’IDE Arduino est assez utile puisqu’il permet de voir des exemples d’implémentation et d’utilisation de librairie.

Voilà, on affiche la température dans la salle, génial … (Je me disai bien qu’il faisait chaud, plus de 24°C !) C’est bien beau tout ça mais jusqu’à présent on n’a rien appris de plus que de se créer un thermomètre. La suite arrive à vitesse grand V, notre hôte change de fenêtres à la vitesse de l’éclair pour nous montrer l’interface Google IoT Core et un shell dans lequel il implémente des commandes Curl. Le but est de nous montrer qu’en très peu de temps il est possible de créer une requête pour inscrire des données dans une base Google. De manière très similaire à Firebase les données sont non structurées et séparées par envoi (une mesure = une ligne), créant une liste d’input qu’il est ensuite facile d’exploiter pour dessiner un graph par exemple.

Ah, j’allais oublier, l’un des gros avantage de Google IoT Core et de la plateforme Arduino est qu’au lieu d’utiliser un protocol HTTP classique on utilise ici le MQTT, c’est une version moins gourmande en bande passante et très adaptée dès qu’on parle d’IoT et de transferts simples comme des données de capteurs.

“Designers, Développeurs, créons la différence !”

“The last but not the least” comme diraient les anglophones. Cette dernière conférence nous parle de design et plus spécifiquement des interactions designers/développeur qui ont lieu tout au long du déroulement d’un projet. Avant d’aller plus loin, j’aimerais souligner et mettre en gras la notion qui pour moi est la plus importante à retenir dans cette conférence: Un design system ne peut fonctionner que si toute l’équipe est impliquée. Si vous n’êtes pas d’accord vous aurez sans doute du mal à adhérer à la suite de cet article.

La présentation se base sur un exemple concret et simpliste, la réalisation d’un site pour gérer son aquarium. Les mécaniques d’interactions sont simples, définir un nouvel aquarium, ajouter des poissons, visualiser les températures optimales pour toutes les espèces… L’objectif est de nous expliquer le déroulement d’un projet tel qu’il devrait se produire avec les différentes étapes d’interactions développeur/designer/client ainsi que quelques outils pratiques qui permettent d’échanger plus facilement et de garder une continuité dans la manière de concevoir.

L’une des premières questions que vous vous posez si vous êtes comme moi c’est “Qu’est-ce qu’un design system ?”. C’est tout simplement le fait de découper et prévoir son application grâce à des éléments réutilisables. Si je parle de dossier “shared” ou “common” je suis certain que ça parlera à certains d’entre vous et c’est, en essence, le principe du design system. On peut aller plus loin avec l’atomic design qui prône la réutilisation de micro-parties au sein même d’un composant graphique. De plus en plus de librairies graphiques utilisent ce concept, Material de Google en est l’un des plus connu. Le concept le plus important à retenir dans le design system c’est que chaque composant est responsable d’une fonction, ni plus ni moins. Sans ça le système peut vite devenir un monstre inefficace et difficile à maintenir. L’intérêt est de simplifier les développements à la fois côté UI que développeur et d’aider l’utilisateur à se retrouver dans l’application avec des éléments d’interaction qu’il reconnaît facilement. On nous parle ici d’un premier outil, zeroheight, qui permet de documenter son design et ses guidelines une bonne fois pour toutes.

Au cours du déroulé de leur pseudo-projet, le duo de développeur/designer nous explique que ce n’est pas gênant de commencer un projet en empruntant une librairie comme Material pour concevoir et tester l’application, c’est ce qu’on appelle un dette technique assumée. C’est même une étape indispensable car de cette manière on peut définir les features réellement utiles et changer l’implémentation si besoin. À ce stade, on travaille déjà main dans la main avec le client, le designer et le développeur pour définir l’ux de l’application. Ce n’est qu’à la fin ou presque de cette étape qu’on passe à la définition du design system. Cette fois le but est de remplacer brique par brique les éléments qui utilisent la librairie lambda par des éléments plus adaptés et personnalisés. Le changement peut se faire pas à pas mais la finalité est bien de supprimer complètement notre import de Material (ou autre) de notre projet. Ah, qu’est-ce que ça fait plaisir de pousser le commit de suppression d’une librairie encombrante ! Pour nous aider dans cette phase de définition de nouveaux composants graphiques le duo nous présente storybook, petit logiciel qui permet de définir une implémentation de composant. Le mieux est d’utiliser cet outil en pair programming avec un UI/UX designer pour bien appréhender les limites techniques et fournir le meilleur rendu possible.

Pour finir et mettre un peu d’eau dans son vin on nous rappelle que le design system n’est pas une obligation. Il faut savoir repérer quand et si une application requiert cette surcharge de travail. De manière générale, on considère que lorsqu’une application est destinée au grand public, alors elle aura forcément besoin de passer par cette étape de réflexion avec un designer. En revanche s’il s’agit d’une application interne ou juste s’il n’y a que très peu de features alors le jeu n’en vaut peut-être pas la chandelle…