Devfest Nantes 2021
J’ai quitté Paris pour aller vivre à Nantes à l’été 2018, avec ma petite famille. J‘ai maintes fois vu les annonces pour le Devfest sans pouvoir y aller : La première fois (2018) je suis arrivé trop tard sur Nantes pour avoir des billets, la seconde fois (2019), les dates tombaient mal, et je m’étais dit que la suivante serait la bonne, mais est arrivée 2020, tous les problèmes que vous connaissez, et l’annulation de l’évènement…
Une fois le report à 2021 officiel, j’ai demandé à OpenClassrooms le financement, très en avance, histoire d’être prêt pour l’édition 2021.
Cette année, plus de 60 conférences ont eu lieu sur 2 jours, il a donc fallu faire des choix. J’ai fait le mien en fonction de mon profil développeur front end, un peu touche a tout, aimant aussi le devops et le design.
Keynote introduction
Par Antonin Fourneau
La keynote d’introduction s’est articulée autour du street art et de la tech, avec un surprenant designer/coder qui nous a présenté son travail, et notamment son Waterlight Graffiti, une invention pour dessiner sur un mur de led, avec de l’eau.
Son leitmotiv est l’innovation, mais en utilisant des technologies d’aujourd’hui, voir d’hier. Dans cet exemple, des leds et de l’eau (bon, et quelques capteurs…), mais il a également montré des inventions avec des balles de ping-pong, des joypads de vieilles consoles, du bois etc.
Prenant une bonne place dans ces inspirations, Nintendo, qui effectivement a l’art de faire des choses très innovantes sans utiliser de technologies de pointe.
Component Driven Development
Par Debbie O’Brien
La conférence de Debbie était vraiment top, pour au moins 2 raisons. La première est le sujet. J’ai toujours été fan du développement par composants, et j’ai poussé cette façon de voir le design et le code dès mon arrivée dans la société il y a 8 ans.
La seconde raison, c’est que Debbie est la preuve vivante de ce qui nous anime tous chez OpenClassrooms. Ironiquement, je n’avais pas fait le rapprochement avant qu’elle en parle, mais il se trouve qu’elle est en home page de la version anglaise du site, depuis longtemps !
Je vous invite à aller voir son interview, mais rapidement, Debbie a voulu changer de carrière à un moment. Elle a choisi le développement front (bonne pioche !) et OpenClassrooms (re bonne pioche !) pour le faire. Quelques années plus tard, elle se retrouve à donner des conférences devant des centaines de personnes sur des sujets front assez pointus. Notre mission est bien accomplie, et Debbie n’a pas manqué glisser un petit mot sur OpenClassrooms pour le souligner.
Elle présentait Bit.dev, que j’ai dans mon radar depuis longtemps, mais que je n’ai pas regardé de plus près encore.
Il permet de découper sa librairie de composants, chacun étant développé et géré de manière indépendante, et installable via npm ou yarn. Vous pouvez ensuite dans vos applications les importer individuellement pour composer votre UI.
Les composants peuvent avoir un scope, et ainsi voir leur développement / maintenance distribués sur plusieurs équipes si besoin.
Une modification sur un composant peut automatiquement ouvrir une pull request sur tous les projets l’utilisant, pour faire la mise à jour.
Leur outil permet d’avoir une vision claire de tous les composants, les dépendances entre eux, leurs scopes, qui les maintient etc.
J’ai été complètement convaincu en apprenant que tout ceci est totalement open source, Bit.dev ayant une plateforme accessible moyennant un abonnement, mais tout est disponible sur GitHub si vous voulez l’installer vous-même.
Github Actions : enfin des pipelines accessibles aux développeurs
Après un rapide historique des solutions de continuous intregration / delivery (Jenkins, les plug-ins, l’utilisation de docker etc.), Antoine nous a présenté Github Actions, qui reprend toutes les bonnes idées apparues jusqu’alors, et en rendant le tout plus accessible aux développeurs, au sein de github.
Il a notamment appuyé le fait que les actions sont directement dans le dépot, au plus proche du code, ce qui rend leur utilisation très simple. Il a montré l’immense collection d’actions créée par la communauté, tout en soulignant les potentiels problèmes de sécurités d’intégrer un tel code dans son pipeline.
Reboot JS on the Server with Deno and Typescript
Par M4dz
Une présentation très intéressante articulée autour des raisons pour lesquelles Ryan Dahl (créateur de NodeJs en 2009), a créé Deno en 2018 :
- ne pas s’appuyer sur les Promises,
- avoir une sécurité défaillante,
- GYP (compilation des extensions Node natives),
- package.json (et surtout le fait que le repos standard de Node soit centralisé a un seul endroit, contrôlé par une entité commerciale),
- par extension, node_modules (cf le célèbre meme sur la masse des choses dans l’univers, avec node_modules en tête…),
- rendre l’extension des fichiers importés invisible require(‘thing’) -> beaucoup de magie noire pour en arriver là, et des problèmes de performance,
- index.js Pour faire un parallèle avec index.html dans le monde du front end, mais devenu un standard, sans aucune raison…
Bien que Node ai évolué sur certains points, il a, selon Ryan, pas évolué dans la bonne direction, un rewrite était pour lui nécessaire.
Deno est sécurisé par défaut, il se base entièrement sur TypeScript. Il est écrit en Rust, et est donc très rapide.
Les concepts de package.json et node_modules ont complètement disparu, puisqu’on import maintenant directement les packages comme ceci :
import { copy } from “https://deno.land/std@0.113.0/io/util.ts";Deno gérant un cache en interne pour ne pas dépendre que du réseau.
Petit guide pratique pour commencer un design system
Cécile nous a expliqué comment commencer son design system. D’abord en se posant les bonnes questions (notamment… En a t-on besoin pour son projet ?), puis en donnant quelques astuces pour savoir par où commencer :
- faire un état des lieux des composants existants dans l’application
- essayer de voir s’il y a des composants redondants (Loi de la similitude Principes de la Gestalt)
- les trier par familles (boutons, formulaire, cartes etc.), un bon exercice à faire en groupe lors d’un workshop
- inclure toute l’équipe dans le processus. Il est important que tout le monde parle le même langage (“ubiquitous language”)
Ce dernier point étant primordial. L’idée étant qu’un fichier de design ai le même nom que le fichier du composant dans votre code, et le même nom dans la documentation.
Elle a insisté sur le fait d’y aller progressivement, tous les composants n’ayant pas vocation à finir dans le design system. Elle nous a indiqué que dans son équipe, ils dupliquaient souvent un composant, et a la troisième fois, celui-ci devient éligible. Cela évite de lancer un gros travail (code, tests, documentation, etc.) pour un composant qui ne sera au final utilisé qu’une seule fois.
Et si vous appreniez à programmer à vos enfants
Tombé dans le développement à l'âge de 6 ans, et papa d’une pré ado de 12, complètement imperméable a cet aspect, j’avais très envie d’avoir des clés pour partager cette passion avec ma fille.
Stéphanie nous a indiqué qu’elle a aussi une fille (7 ans), et qu’elle a également très envie de partager ceci avec elle.
Je m’attendais à une conférence plus axée sur la pédagogie, mais Stéphanie nous a surtout présenté des outils. Code combat, Makey Makey, Lego Boost, Microsoft Make code, et surtout la carte Micro:bit.
La carte est très petite, mais bourré de senseurs (accéléromètre, température, lumière, compas) et possède des leds, des boutons, peut produire du son, peut communiquer avec d’autres cartes, bref, un joli jouet :)
Stéphanie s’en sert pour faire bouger des petits robots, soit qu’elle a tricoté (oui…), soit imprimé en 3D, car la carte peut piloter des moteurs.
Elle utilise Scratch pour piloter la carte, ce qui est une bonne base pour apprendre la programmation aux enfants.
Sa présentation était très ludique, et intéressante pour des passionnés de tech comme nous. Néanmoins, elle a rapidement laissé de côté le rôle de sa fille dans ses créations… Et pour cause, à la fin, elle nous a avoué que sa fille n’accroche pas spécialement, et que si elle joue avec les robots, l‘aspect programmation ne l’attire absolument pas !
React Query, le server state facile pour React
Par Olivier THIERRY
Nous utilisons React Query depuis des mois chez OpenClassrooms, je pensais pouvoir récupérer quelques astuces, mais la conférence était un “quickie” donc juste 15 minutes. Difficile dans ces conditions d’être exhaustif sur un sujet aussi complexe.
Olivier a rapidement présenté la librairie, qui est bien un “server state”, par opposition à Redux, qui est un “client state”. Ce qui m’a conforté dans notre choix de l’utiliser, car effectivement on utilisait Redux avant pour synchroniser la data avec notre api, et ça n’était pas tellement adapté.
Coupable de code legacy en JS : comment s’en sortir ?
Par Adrien JOLY
Si vous travaillez sur un projet depuis longtemps, ou si vous reprenez un projet perso après plusieurs mois de pause, invariablement, vous allez tomber sur du code que vous trouvez mal conçu, et parfois le responsable c’est vous-même :) On a tendance à dire qu’il s’agit de code “legacy” : du code qui fonctionne, mais qui n’est pas suffisamment claire pour que quelqu’un ne s’amuse à le modifier, même la personne qui l’a écrite. Mais parfois il faut absolument rajouter une fonctionnalité au milieu de ça, et ça devient compliqué…
L’exercice mené par Adrien pendant ces 50 minutes est assez périlleux, et a demandé pas mal de préparation (6 jours selon lui) :
Il reprend un projet node qu’il a écrit depuis longtemps, et, devant nous en live, il le réécrit pour le rendre bien plus lisible.
Évidemment, la première des choses qu’il a faite, et ce, en dehors de la conférence, c’est d’écrire plein de tests. Il y avait 120 tests qui passaient avant la refactorisation, ce qui l’a bien aidé à modifier le code petit à petit.
Globalement, il a sorti beaucoup de code pour créer des fonctions, en les nommant correctement. À chaque déplacement de code, il relançait les tests, et il faisait un commit. C’est important d’avoir des commits avec peu de changement, cela permet de revenir facilement en arrière si besoin.
C’était hyper intéressant car on pouvait suivre ses erreurs (qu’il n’a pas manqué de faire, à 9h du matin en live devant autant de monde ce n’est pas un exercice simple !)
Au final, le plus important dans cette refacto, c’est la présence de tests. Sans ça, effectivement personne n’ose toucher le code !
Next.js à la rescousse de mon frontend
Par Nordwin Hoff
Nordwin est venu nous expliquer comment Gens de confiance est passé graduellement d’une application web symfony/twig/jquery, a une application React + api, pour arriver à une application NextJS.
Pour migrer, ils ont décidé de choisir les pages en fonction de leur visibilité et de leur complexité. La première a été la home page (plus grand nombre de vues) et ensuite la recherche (plus complexe). Ils ont ainsi pu valider le fait que les pages étaient rendues bien plus rapidement, avec un score Lighthouse mobile qui est passé de 9 à 80 sur certaines pages. Ils ont aussi validé que comme la page la plus complexe était migrée, tout le reste n’était plus qu’une question de temps, les aspects techniques ayant été résolus.
Pendant la migration, ils ont essayé plusieurs techniques pour mettre le code commun utilisé dans les deux stacks (passer par npm, sous package dans un mono repos etc.) mais finalement ils ont fait ce qu’il y a de plus simple : dupliquer le code. Comme ils savaient que le code “legacy” allait disparaître rapidement, c’était de loin le plus efficace !
Notre recette de l’équipe parfaite
Par Estelle Landry & Yvonnick FRIN
Une conférence remarquable, et sur le contenu, et sur la forme, a propos de l’organisation des équipes chez Pix.
Estelle et Yvonnick avaient chacun une toque de chef cuisinier pour expliquer leur “recette” (vous l’avez ? ;p), et ont entamé des dialogues, souvent drôles, tout en faisant participer le public avec des “mais pourquoi chef ?” très ludiques.
L’organisation chez Pix est très proche de ce qu’on a chez OpenClassrooms :
5 équipix (oui… Ils mettent le nom de la boîte dans beaucoup de leurs termes…), constitué de 8 personnes, de métiers différents (développeurs back / front, product owners, etc.)
Chacune étant responsable d’un domaine de l’application.
Ensuite ils font évoluer leur produit suivant 4 valeurs, chaque décision étant prise en considérant ces 4 valeurs qui sont :
Qualité, Agile, Utilisateur et Esprit d’équipe (chez OpenClassrooms, c’est Dare, Care, Persist, et Tell it as it is)
Ils ont ensuite montré le cycle de vie d’une user story chez eux, de sa création jusqu’à sa mise en production.
Beaucoup de choses chez eux se font en groupe, y compris le développement (mob programming)
Les tests manuels sont faits par les développeurs tous au long du développement, et la recette finale par le Product Owner, qui est aussi celui ou celle qui va déclencher la mise en production. Cette mise en production se fait via Slack, grâce à un plug-in maison, qui une fois la mise en production faite, va envoyer un message sur un channel dédié, avec un message comportant toutes les nouvelles fonctionnalités, correction de bug, etc.
The blind test
Par Florent Lévêque & Hervé Boisgontier
Encore une super conférence et sur le fond et sur la forme ! Le titre était un peu mensonger, mais la description était très claire : nous n’avons pas écouté de musique pendant ces 50 minutes :)
Florent est non voyant, et en reconversion dans le développement web, et Hervé prof de développement web, justement. Ils étaient tous les deux sur un site web avec beaucoup de problèmes d’accessibilité, et la mission, c’était de le rendre accessible, en live.
Florent utilisait la page, avec son lecteur écran. Il n’avait donc que le rendu sonore de la page… Et nous aussi ! Le site n’était pas projeté du tout, nous laissant donc également dans le noir.
À chaque problème rencontré, Florent indiquait la nature du problème, et Hervé modifiait le code en live. À la fin, la page était complètement utilisable pour un non voyant, mais également, étant plus propre sémantiquement, plus efficace d’un point de vue seo.
Les points changés, en vrac :
- les titres H1, H2, H3 etc.
- une meilleure structure sémantique (header, footer, main…)
- des listes utilisant correctement ul/li
- correction des liens “vides” (juste une icône)
- formulaire utilisant les labels
- validation du formulaire plus accessible
La dette UI : en finir avec les interfaces jetables et concevoir une UI durable, adaptable et structurée
Loïc nous a expliqué le concept de dette UI. Nous avons l’habitude d’entendre parler de dette technique, mais sur un projet de longue durée, la dette UI est aussi compliquée à gérer.
Il nous a donné quelques astuces pour repérer cette dette :
- ça peut être des illustrations ou photos très spécifiques. Cela va marcher pour les premières que vous allez faire. Ensuite vous en aurez besoin de plus, plus souvent, et il faudra faire intervenir le même illustrateur, le même photographe, ou faire les mêmes retouches. Et puis les équipes vont changer, et on va alors commencer à utiliser un autre type de photo ou d’illustration…
- ça peut être une barre de navigation non évolutive : designée pour 4 entrées, et quand on en a une 5 ème… On la résigne et redéveloppe du début.
- Ça peut être un design trop artistique : la page d’info d’un utilisateur est très belle, mais l’ajout d’un seul nouvel élément devient l’enfer.
Pour un projet qui dure pendant des années, il faut absolument penser à la façon d’évoluer de votre UI. L’idée étant d’éviter les grands redesign, et s’organiser de manière à permettre l’évolution de l’UI.
Pour ce faire, la conception d’un Design System est une bonne base. Elle permet de coucher sur le papier les éléments qui vont constituer votre UI, en réfléchissant beaucoup plus sur les évolutions possibles.
Loïc nous a appris la notion de Design Ops, qui est la personne qui va se charger d’orchestrer le design dans l’entreprise, de manière transverse. Il va faire le liant entre les développeurs et les designers par exemple. Il va aussi s’occuper de faciliter tous les échanges, avec des outils ou des process.
Le but étant d’amplifier, de mesurer et de valoriser l’impact du design à grande échelle dans l’entreprise.
J’ai presque fini !
Par David Laizé
Une conférence a propos de Michel.
Michel est un développeur fictif (ou pas !?) dans l’équipe de David. Tous les jours au daily standup, il dit qu’il a bientôt fini. Tous les jours, depuis 5 jours.
Vous pouvez penser que ce n’est pas votre problème, sauf que vous êtes dans la même équipe et que :
- vous voulez éviter les tensions entre les gens
- vous voulez limiter les taches qui s’étalent sur des semaines
- vous voulez que Michel devienne meilleur.
Cette situation de work in progress qui s’éternise est due à 2 biais cognitif selon David :
- “Overconfidence Effect” : Michel est (trop) sûr de lui, il sait que sa solution est la meilleure
- “Escalation of commitment” : une fois passé 3 jours sur une tache, il est difficile d’admettre que la solution est mauvaise, et ça ne s’améliore pas avec le temps…
Il faut absolument détecter ça le plus tôt possible, car au moment de la code review, il est possible que personne n’y trouve son compte… Michel va se faire retoquer plusieurs jours de boulot, et l’équipe qui attendait son code va être déçue de la qualité.
La conclusion de David est intéressante : nous sommes potentiellement tous des Michel en fait… Et il va du bon équilibre de notre équipe de prendre soin chacun les uns des autres en repérant très tôt ces problèmes.
Trucs et astuces pour réussir son burn-out
Par Cynthia Staebler & Julia Lehoux
J’avoue que je n’ai pas trop compris pourquoi je suis allé voir cette conférence… Il n’y avait pas grand-chose d’autre à cette heure-ci déjà. Et puis c’était dans la même salle que la conférence vu précédemment…
J’ai un peu espéré au fond de moi qu’il y aurait de vrais messages dans la conférence. Mais non.
Dès les premières minutes, j’ai ri un peu… Et puis ce fut le malaise.
Comment et pourquoi rire d’un sujet aussi grave que le burn-out ?
Keynote de fin
Par toute l’équipe
La fin de l’évènement était en fait un Question pour un champion, semi improvisé (les candidats, du staff, n’avaient pas l’air de savoir ce qu’il allait se passer) et semi-préparé (des questions, des buzzers, des pupitres avec les scores).
Les questions tournaient autour de la tech, de Nantes, de la culture geek dans son ensemble. Le tout fut assez drôle (bien qu’un peu long !)
Bravo aux 5 participants (4 candidats et le présentateur) l’exercice n’est quand même pas simple devant des centaines de gens !
Ma conclusion
Le Devfest de Nantes a tenu toutes ces promesses me concernant.
Une organisation impeccable (pourtant compliqué par la situation sanitaire, les contrôles de pass etc.)
Des conférences assez pointues, très diverses. J’ai surtout assisté à celles parlant front end, mais il y en avait sur les DB, les solutions cloud, le développement natif, des sujets plus sociétaux etc.
Le thème (street art) me plaisait beaucoup, et n’était pas juste un prétexte. La décoration, les mini-événements dans l’événement, les activités, tout y faisait référence, et nous sortait de la tech un peu, de manières rafraîchissantes.
J’ai hâte d’y retourner l’année prochaine !
Retrouvez les photos que j’ai prises pendant l’évènement ici.
Retrouvez les vidéos de toutes les confs.
