Un regard sur le Devfest Strasbourg 2024

"Désolé, on n'aura pas le temps pour les questions, mais vous pouvez me retrouver dans le hall."

Cette phrase, répétée au fil des conférences, résume bien l'état d'esprit de ce Devfest 2024 : une conférence extrêmement dense avec énormément de sujets sur plein de thèmes et à peine une minute pour souffler entre chaque.

On a choisi de vous en faire un résumé choisi autour de deux axes. D'abord, trois sujets sur lesquels on voudrait porter un regard critique, du point de vue de nos pratiques à Marmelab. Et dans un second temps, trois autres sujets que l'on a découverts et qui nous ont positivement surpris ou marqués.

La "bonne" stack React

React est au cœur de la majorité de nos projets à Marmelab, alors voyons ce que nous propose Olivier Abderlnour.

On aurait probablement préféré le choix d'un Remix à celui de Next.js mais c'est plus par affinités personnelles. C'est juste un peu dommage que l'alternative n'aie pas été évoquée.

Pour le reste, la quasi-totalité des outils suggérés fait déjà partie de notre stack de base dans react-admin (Storybook, Tanstack-query, Typescript, Vitest). Ou encore des outils qu'on préconise au quotidien pour tous nos projets (Eslint, Prettier, Testing library, Playwright).

Il nous recommande un shadcn pour l'UI (assorti d'un traditionnel Tailwind). Shadcn est une librairie de composants légère qui semble très intéressante. Certains développeurs chez Marmelab l'ont déjà essayé. On se note de la tester rapidement sur un projet pour vérifier ce qu'elle vaut.

Côté tips de développement, les recommandations sont assez standard mais peuvent mériter d'être rappelées :

• Diviser le code en petits composants avec chacun sa logique.
• Limiter et optimiser au maximum les useEffect en préférant par exemple de simples variables locales lorsque c'est possible.

Et une astuce très maligne à laquelle on ne penserai pas forcément :

• Utiliser la prop key pour forcer le re-rendu d'un composant sans passer par un useEffect

L'exposé se termine par un petit teasing sur react-compiler qui promet notamment de pouvoir se passer de useMemo() ou useCallback(). À surveiller.

On approuve donc ce talk et ses conseils sans trop de réserve. Et on aurait même tendance à être encore plus catégoriques : si vous ne suivez pas ces conseils, il y a de fortes chances que vous fassiez du mauvais React 😱.

Deadly meeting

Le trio de Davidson nous présente, à travers une succession de petits sketchs rafraîchissants, les multiples formats de daily meeting possibles.

L'idée est de choisir et de varier le format en fonction des besoins identifiés du moment : mettre l'accent sur la livraison, sur les obstacles, sur le partage d'information, etc. Il y en aurait trop pour tous les détailler (nous n'en avons d'ailleurs vu qu'un petit échantillon) mais voici un lien pour se faire une idée et piocher des formats nouveaux : Quelques formats de daily meetings

De notre point de vue, adapter l'heure du daily est essentiel pour qu'il se passe bien (les heures de daily de nos différentes équipes s'étalent sur toute la journée).

Tenter de contenir les gens trop bavards et de laisser la parole aux gens réservés est une bonne approche, mais ne se fera pas en cinq minutes. Les habitudes ont la vie dure et il faut la force d'un facilitateur chevronné pour cadrer efficacement un daily.

Le talk a amené une discussion sur la présence parfois problématique du Product Owner et sur le fait qu'il faut pouvoir éventuellement l'exclure en organisant des réunions produit séparées des réunions de l'équipe de développement. C'est sur ce point que notre approche à Marmelab est radicalement différente.

Nos formats de daily (et de travail en général) incluent impérativement :

• tous les développeurs (membres de Marmelab et aussi parfois d'équipes internes du client)
• un facilitateur pour cadrer et fluidifier les échanges et les besoins avec le client
• un Product Owner côté client

En conséquence, non seulement la présence au daily du product owner est importante, mais c'est même la présence du client lui-même qui est fondamentale.

De cette façon, les développeurs sont en contact quotidien avec le client. Les points de blocage et les succès lui sont donc transmis directement et il peut prendre des décisions stratégiques pour adapter les contenus des sprints, car il possède toutes les informations nécessaires.

Les développeurs peuvent faire valoir leurs choix et leur travail directement auprès du client et influer sur la direction du produit. Bien sûr, il faut quelques aménagements côté client pour pouvoir le mettre en place et les développeurs doivent savoir vulgariser leur travail. Mais le résultat, c'est une agilité accrue et un meilleur produit.

Nous avons étés surpris de voir que la tendance dans la salle était plutôt, à l'inverse, à l'isolation des développeurs entre eux. Alors, est-ce que cette façon de faire est un ovni dans le monde du développement ?

Une chose est sûre, c'est qu'elle fonctionne particulièrement bien chez nous.

Oh my docs

Dans ce talk, Geofrey Graveaud nous fournit une série de bonnes pratiques pour disposer de documentations, au sein d'une équipe ou d'une entreprise, qui respectent trois principes majeurs :

• Être claire, limpide et sans quiproquos
• Être pertinente et fiable
• Être facilement trouvable et accessible

Les principes sont bons et doivent effectivement mener l'objectif annoncé d'une bonne documentation.

Pour résumer :

• A l'écriture d'une nouvelle documentation, faire sa revue en solo, comme une revue de code.
• Puis faire une revue des commentaires en équipe, qui permet alors un alignement du vocabulaire et de la compréhension dans l'équipe. Pour fluidifier cette étape, il conseille l'utilisation des conventionnal comments (si vous ne connaissez pas, aller voir notre article, c'est un super principe).
• Ensuite, tuner la documentation, en ajoutant des hyperliens si nécessaires, les auteurs, contacts, des tags
• Et enfin, la tester, en tester l'accès, les liens, et informer spécifiquement les personnes concernées.

Ce concept tient en quelques mots : "Documentation as a product". On traite ce document avec les mêmes principes que l'on aurait appliqués au développement d'une application.

Et de notre point de vue, c'est une excellente approche avec des étapes qu'on a trop souvent tendance à bypasser.

Mais c'est arrivé à cette étape finale que nos points de vues commencent à diverger. Comment garantir que le document sera maintenu dans le temps ? Comment garantir que les personnes concernées sauront toujours la trouver et sauront même qu'elle existe ?

Alors, chez Marmelab, on a ajouté un quatrième principe essentiel pour tenter de palier au mieux à ces problèmes :

• La documentation doit être là où on en a besoin.

Ce qui en découle, c'est que la documentation relative à un projet doit être directement dans le code du projet.

Tous les fichiers Readme de nos produits décrivent comment les installer, quels outils sont nécessaires, ou les trouver, où sont les accès et les clés.

On évite le plus possible d'utiliser des documents externes pour expliquer des features ou des choix, mais on écrit directement des ADR (Architecture Decision Record) ou des documents dans les projets concernés.

Et au besoin on commente le code impacté avec les explications nécessaires ou des liens vers les contextes nécessaires.

Bien sûr la perfection n'existe pas et il restera toujours des documents attachés à rien de précis qu'il faut bien ranger quelque part (la règle de prise des congés par exemple :) ). Pour ceux-là, on restera sur les trois principes évoqués dans ce talk.

Voyons maintenant trois sujets qu'on a adorés.

SELECT 'amazing_features' from "postgresql"

Kevin Davin, le conférencier, connaît son sujet sur le bout des doigts et après un historique détaillé de la naissance de Postgres à nos jours, il nous arrache un grand sourire avec cette phrase :

"Arrêtez de vous faire crier dessus par du SQL !"

SELECT QUELQUECHOSE FROM "MATABLE";

Ça c'était la préhistoire du SQL, maintenant, on a évolué, on a la coloration syntaxique, les minuscules et des tas d'autres choses.

select quelquechose from "matable";

Effectivement, c'est bien plus doux ainsi 😃

Puis nous avons eu droit à un enchaînement frénétique de pleins de fonctions géniales de pg que l'on ne connait pas, ou qu'on ne pense pas assez à utiliser. On va essayer de parcourir celles qui nous paraissent les plus utiles ou les plus dingues.

La principale c'est l'utilisation des CTE (Common Table Expressions) qui permettent de découper les requêtes de façon lisible et de créer des blocs réutilisables. On connaissait, mais on n'a pas assez le réflexe de partir sur cette syntaxe pourtant très pratique qui isole chaque sous-requête.

WITH
  s_count AS (
    SELECT species.*, COUNT(id_carrot) as nb_carrots
    FROM species
    inner join carrot using (id_species)
    GROUP BY id_species
  ),
  s_max AS (
    SELECT MAX(nb_carrots) as max_carrots
    FROM s_count
  )
SELECT *
FROM s_count sc
INNER JOIN s_max sm ON sc.nb_carrots = sm.max_carrots

Puis l'usage des window functions, qui offrent des possibilités impressionnantes. Par exemple, nous avons découvert la fonction filter() qui permet de faire de l'agrégation d'une façon très fluide:

SELECT
	min(weight) FILTER (WHERE status = 'rotten') min_rotten,
	max(weight) FILTER (WHERE status = 'rotten') max_rotten,
	min(weight) FILTER (WHERE status = 'fresh') min_fresh,
	max(weight) FILTER (WHERE status = 'fresh') max_fresh
FROM
	carrot;

On a appris l'existence d'un genre de mini-rabbitmq dans Postgres. Avec l'utilisation du mot clé listen, il est possible de manipuler, d'empiler et de dépiler des channel de données. Une limitation non négligeable tout de même : contrairement à un vrai rabbitmq, il n'y a pas de re-jouabilité possible.

Il nous a également présenté postgrest qui permet de montrer une API en deux claquements de doigts. Une fonctionnalité très sympa dont on a déjà parlé sur ce blog (ici et là) et qu'on utilise déjà dans certains projets.

Le Foreign data wrapper a été une des plus grosses features présentées. Avec l'extension file_fdw, on peut naviguer dans des fichiers comme dans une base de données et même créer des jointures.

CREATE FOREIGN TABLE films (
 code char(5) NOT NULL,
 title text NOT NULL,
 rating text OPTIONS (force_null 'true')
) SERVER film_server
OPTIONS ( filename 'films/db.csv', format 'csv' );

Par ailleurs, avec le même genre d'extensions, il est aussi possible de requêter dans une table distante dans un autre pg, ou dans un mongoDB,etc.

La puissance d'un tel outil est difficile à quantifier, mais on a très envie d'essayer.

La conférence a fini par quelques recommandations de choses à faire ou à éviter que l'on va partager ici en quelques lignes :

• Utilisez le type Jsonb pour les données structurées complexes, il est là pour ça
• N'utilisez pas l'héritage, c'est le reliquat d'un mauvais choix du passé
• Utilisez le full text search, il est très puissant
• N'utilisez pas timestamp mais timestampTZ, vos dates seront toujours correctes
• Evitez le NOT IN car il est très très couteux
• Utiliser des uuids comme clef primaire, et non des id numériques autoincrémentés. C'est plus secure, et cela évite une variable globale.

La révolution quantique

Impossible d'expliquer ici les principes de l'ordinateur quantique ou des qbits aussi bien que l'a fait notre orateur de chez Google Paris. Il a tout de même passé en revue l'informatique depuis les tous premiers circuits imprimés et la logique booléenne de base jusqu'aux algorithmes quantiques.

Mais il y a des points intéressants que l'on a appris et qui méritent d'être partagés ici.

Les technologies

Il existe plusieurs technologies pour mettre en œuvre un ordinateur quantique. Un qbit peut être obtenu avec des électrons, ou des photons, ou des ions.

Et dans tous les cas, un qbit est la combinaison de trois états. (La Sphère de Bloch sur l'image les représente).

La stabilité

Aujourd'hui, la problématique principale pour que l'ordinateur quantique sorte des laboratoires, c'est presque uniquement la stabilité. Le froid absolu est indispensable (moins de 2 kelvin). Même ainsi un qbit a une durée de vie maximum de 10 minutes environ.

Les systèmes actuels multiplient les qbit pour obtenir une stabilité "statistique" et contrer la "décohérence quantique". Mais sans ça, 100qbit suffiraient théoriquement à stocker plus d'informations que l'univers.

L'amélioration de la stabilité et la correction d'erreur quantique est le domaine de recherche en vogue actuellement dans ce milieu.

Algorithmie et sécurité

L'algorithmie quantique à déjà bien progressé, même s'il n'y a pas encore forcément de machine en mesure de l'exploiter aujourd'hui.

Il nous a cité quelques exemples d'algorithmes quantiques connus :

• Algorithme de Deutsch-Joza pour déterminer si une fonction est constante
• Algorithme de Grover pour faire une recherche dans un ensemble
• mais surtout, l'algorithme de Shor, qui permet la factorisation des grands nombres.

Ce dernier algorithme permet donc théoriquement de casser les cryptages actuels. Adieu SHA-1, SHA-512 ou peu importe. Cet algorithme nécessite des millions de qbit pour fonctionner, mais en théorie, il fonctionne. Et cela signifie que nos sécurités actuelles sont déjà virtuellement compromises.

Car, comme nous l'a rappelé le conférencier, bien qu'aucun ordinateur ne puisse encore faire tourner cet algorithme aujourd'hui, lorsque ce sera le cas, toutes les données que l'on croit aujourd'hui totalement inaccessibles ne le seront plus. Et il sera parfaitement possible de décrypter, à posteriori, des données sensibles mises de côté en attendant ce moment. Des secrets d'état ou de sécurité nationale, etc.

Bref, ça fait froid dans le dos. (un froid de 2 kelvins environ 😊 ).

Autisme en entreprise

Angi Guyard nous a parlé avec passion de l'autisme et de la vie en entreprise et ça va être difficile d'en faire un résumé aussi intéressant en moins de 15 lignes.

Spoiler alert : les bonnes pratiques pour intégrer une personne autiste en entreprise sont largement applicables pour simplement améliorer le fonctionnement et les relations au sein de l'entreprise, qu'il y ait des neuro-atypiques ou pas.

Un point de situation pour commencer, il y a environ 25 % de neuro-atypiques dans la population, dont 3 % d'autistes. C'est une proportion importante de la population. Si on n'en fait pas partie, on en côtoie et en fréquente assurément. Bien qu'invisible, c'est donc un sujet à prendre au sérieux.

Le vocabulaire est sensible, car tantôt imprécis, tantôt irrespectueux. On préférera alors le terme neuro-atypique plus englobant. Mais le plus simple est encore de poser la question aux personnes concernées et ainsi éviter d'être désobligeant.

"Ce n'est pas une maladie. On naît autiste, on ne le devient pas et on n'en guérit pas"

On va trouver une longue liste de caractéristiques attachées à l'autisme et de nombreuses personnes vont se sentir concernées par plusieurs d'entre elles. C'est finalement le nombre, l'intensité et l'impact de ces éléments sur la vie privée et professionnelle qui déterminent si une personne peut être diagnostiquée autiste ou non.

• Troubles de la communication
• Ne pas savoir trouver sa place dans une conversation
• Difficulté avec les expressions imagée ("il tombe des cordes")
• Regard soutenu
• Difficulté pour adapter un comportement à un contexte
• Difficulté à comprendre les messages implicites
• Tics nerveux
• Intérêts restreints et spécifiques
• Collectionnite
• Hypersensibilités
• Difficulté à reconnaître les gens à leur visage (prosopagnosie)
• Posture de tortue
• Du mal à gérer son temps

Alors que faire pour améliorer la situation des personnes dans cette situation ? On peut le résumer à quelques principes simples et à l'usage de la bienveillance.

Bannir l'implicite

Cela peut déjà commencer par une présentation les codes sociaux de salutation dans l'entreprise qui peuvent être un casse-tête pour n'importe qui. On se serre la main ? On se check ? On se fait la bise ? On fait le tour des personnes du bureau ? Présenter ce qui se pratique aux nouveaux venus et leur demander s'ils sont OK avec les usages, c'est le début de l'inclusion.

Des phrases comme "Il faudra traiter ce dossier" sont à proscrire. Il faut verbaliser les choses au maximum pour les rendre explicites. Qui doit traiter ce dossier ? Qu'est ce qui est attendu exactement ?

Avec ce genre d'attention, on pourra également éviter un nombre incalculable de ratés dans l'entreprise liés à des quiproquos du type : "C'est Jean Michel qui a dit qu'il le ferait, mais c'est Patrick qui a dût le faire en urgence".

Cadre clair

Ici, encore des choses simples :

• Respecter les processus établis. Et les établir clairement lorsqu'ils sont manquants.
• Ne pas donner d'instruction contradictoires.
• On doit pouvoir savoir à chaque instant qui a la charge de quoi et avec quels moyens.
• Bien signifier l'exception lorsqu'elle existe.
• Et évidemment lorsque le scope ou le contexte change, il faut remettre à jour et expliciter ce changement.

Accepter les difficultés

Les neuro-atypiques peuvent avoir des tics qui peuvent être bruyants ou gênant pour l'entourage (clic de stylo, taper du pied par example). Il existe des accessoires anti-stress conçus pour canaliser ce genre de pression sans la transmettre à tout le bureau (Angi nous conseille la boutique Hoptoy).

Faire attention aux sur-stimulations, l'autiste tend à mal filtrer les informations sensorielles. Il ou elle est vite épuisé quand il y a beaucoup de stimuli.

"On est dans une boîte de nuit avec un videur qui filtre les infos. Chez une personne autiste, la boîte est plus petite et le videur est bourré"

Pour ça, on va éviter que les bureaux soient trop bruyants et agités. Aller toujours dans les salles de calls pour faire des calls. Aller toujours dans les salles de pauses pour faire des pauses. Ne pas hurler sur son bug mais l'aborder sereinement en demandant de l'aide au besoin. En bref, uniquement des usages qui vont améliorer l'ambiance du bureau pour tout le monde, on aurait tort de s'en priver.

Dans le cas extrême pour un autiste, si la situation devient insupportable, il y aura shutdown. En gros, il ou elle craque. Il n'est plus possible de prendre la moindre décision à quelque échelle que ce soit et tout devient agression.

Pour gérer une telle situation, on ne peut qu'attendre, laisser la personne isolée, se reposer, dans une lumière faible et sans bruit.

La conclusion, c'est que nous devons traiter les neuro-atypiques avec le plus d'humanité et de bienveillance possible, et les autres personnes de la même façon. Ainsi tout le monde travaillera mieux et dans de meilleures conditions

Fin de la visite

La conférence s'est achevée par une Keynote magistrale mêlant urgence écologique et impact numérique. Un sujet difficile qui est au centre de nos préoccupations chez Marmelab.

Le principe d'inversion de la loi de Moore est simple et brillant : arrêtons d'améliorer les capacités des appareils par plus de puissance de calcul. Gardons nos vieux appareils et continuons d'améliorer leur puissance de calcul en codant mieux nos applications.

À vos claviers !

Nous avons vu également de nombreuses autres conférences qu'il est impossible de toutes aborder ici, sur Bruno, Signals, Tabby, et plein d'autres.

Vous l'aurez compris, on a adoré.

Le programme complet du Devfest est ici

PS : Et nous avons fait gagner 20€ à une association au stand "Mariage à Vegas" de Davidson en répondant à des questions fourbes sur javascript ;)