Retour sur le Forum PHP 2021 (partie 1)

Il y a quelques jours, plusieurs membres de notre coopérative se sont réunis afin de participer au Forum PHP de l'AFUP, organisé cette année au Novotel Paris Est. 

Ce retour en présentiel était très attendu par la communauté et par chance, l’AFUP a géré d’une main de maître ces retrouvailles après presque deux ans d’événements à distance. En tant que sponsor Argent, nous faisions partie des exposants avec un stand sur lequel les visiteurs ont afflué afin de gagner tee-shirts, tapis de souris, et autres goodies aux couleurs de notre mascotte API Platform. Trois membres de notre coopérative étaient d’ailleurs invités à présenter leur talks sur scène : Kévin Dunglas nous a présenté le concept d’Edge Side APIs, et le binôme Mathias Arlaud / Robin Chalas nous a démontré qu’il était possible de faire du DDD avec API Platform.

Passons désormais en revue quelques conférences qui nous ont marquées :

Guillaume Loulier de SensioLabs nous parle de peur, et notamment celle qui peut survenir quand on essaie de refactoriser. Tout d’abord la théorie : qu’est-ce vraiment que refactoriser ? Tout est histoire de compromis (jusqu'où va-t-on ? Quel temps peut-on y consacrer ?) Refactoriser peut être une tâche ingrate et pénible, mais qui finalement peut nous apporter des amis (ceux qui vont reprendre le code) mais également améliorer la qualité du projet sur lequel on travaille, et ça, c’est quelque chose de très gratifiant. La réticence à refactoriser vient principalement de la peur de l’inconnu (code que l’on n’a pas développé) mais également de la peur de l’échec (vais-je y arriver ?)

Mais en pratique ? Un refactoring doit toujours apporter une plus-value, sinon il est inutile. On veut améliorer quelque chose. On va corriger un bug, en profiter pour ajouter de la documentation, mettre à jour une dépendance, améliorer la liaison à l’infrastructure, ajouter et améliorer les tests (y avait-il déjà des tests en place ?), éliminer de la dette technique. On doit aussi vérifier les performances et la montée en charge, sinon qui dit que le refactoring ne va pas tout casser de ce côté-là même si le fonctionnel semble correct ? Ça peut être le cas si on travaille avec une base de données locale contenant peu de données.

Quelles méthodes ou quels outils pour nous aider ? Appliquer la méthode RIPP : Rector — Infection — PHPStan / PSalm, ces outils peuvent nous faciliter le travail, automatiser au maximum certaines tâches, mais surtout nous donner plus de confiance dans nos livrables. 

Une chose importante, planifier avant d’agir, même pour des tâches purement techniques. Elles doivent être prises en compte dans les sprints. On peut mettre en place du refactoring continu, ceci va nous permettre de mieux gérer l’évolution du projet, d’en améliorer sa qualité, et donc finalement d’économiser de l’argent. Il faut voir cette tâche comme un marathon et pas comme un sprint.

Compte rendu rédigé par Loïc.

Le réchauffement climatique et les autres menaces écologiques représentent un enjeu d’envergure pour l’humanité : pour survivre, il faut stopper immédiatement les émissions de gaz à effet de serre et limiter au maximum les impacts environnementaux que notre espèce cause.

Chacun doit s’y atteler, et - bien conscients que le changement personnel n’est pas égal au changement social - c’est au niveau de l’industrie, des entreprises et du commerce que nous devons agir le plus vite et le plus fort.

Premier rappel utile : la majorité des émissions sont émises par les clients.

La production des appareils est l’une des causes principales de pollution due au numérique. Hélène, nous rappelle par ailleurs qu’en plus des conséquences écologiques dramatiques, cette production a un impact social délétère : travail des enfants, vagues de suicide dans les usines chinoises, dégradation de la santé des mineurs de métaux rares en Afrique… En tant que professionnels du logiciel, nous pouvons avoir un impact : nous devons nous attacher à permettre de faire fonctionner ces appareils le plus longtemps possible. Pour ce faire, nous devons nous assurer de la comptabilité des logiciels et des sites web que nous développons avec les modèles anciens.

Le deuxième problème causé par les clients est leur importante consommation d’énergie. Là encore, nous pouvons agir. Cette consommation peut être drastiquement réduite en optimisant les sites web, webapps et apps mobiles qu’ils exécutent. Quelques actions simples peuvent être menées comme bannir les vidéos en autoplay ou supprimer les centaines de traqueurs qu’embarquent la plupart des sites (qui sont, de plus, l’un des piliers de la surveillance de masse). Hélène insiste sur le fait que la meilleure manière de ne pas polluer, ça reste de ne rien faire : ne pas réaliser un logiciel inutile voire néfaste, ou tout du moins faire subir une cure d'amaigrissement aux “obésitiels”. Elle nous invite à toujours se demander si nos productions sont utiles, accessibles (sujet auquel une autre conférence était consacrée) et durables. François nous incite également à réfléchir à la finalité des projets sur lesquels nous travaillons : réaliser un site web “éco-conçu” dont l’objectif est de vendre un SUV est une aberration.

D’après la plupart des études, les émissions des serveurs sont inférieures à celles des clients. Mais ce n’est pas une raison pour les négliger. François prodigue quelques conseils pour y parvenir : utilisez des plateformes de cloud, qui permettent de faire des économies d’échelle (en particulier s'ils utilisent de l’énergie renouvelable et ne participent pas à l’extraction pétrolière), mettez du cache et - encore et toujours - optimisez vos applications. Si vous ne savez pas comment faire, n’hésitez pas à nous contacter, ces trois disciplines font partie de nos spécialités !

Reste un problème de taille : en l’état actuel des choses, il est extrêmement difficile de mesurer les émissions réelles d’un logiciel. François s’est appliqué à démolir méthodiquement quelques outils populaires utilisant des formules trop simplistes… voire bancales. Son équipe et lui (aidés par notre coopérateur Alan Poulain) ont donc décidé de travailler sur le sujet. Après plus d’1 an de R&D, ils ont publié un outil de mesure fiable et facile à utiliser : GreenFrame.io.

Le concept de GreenFrame, c’est de faire tourner l’ensemble d’un projet (composants clients et serveurs) dans des conteneurs Docker, de collecter sa consommation CPU et RAM, ses accès disques etc, et d’en extrapoler sa consommation d’énergie réelle.

L’outil peut ainsi être facilement utilisé dans une chaîne d’intégration continue pour déterminer automatiquement si un changement de code augmente ou réduit la consommation d’énergie d’une application. Un outil intéressant que nous ne manquerons pas d’utiliser sur nos projets.

Finalement, Hélène comme François nous rappellent les limites de l’action individuelle et l’importance de l’organisation collective. François le dit haut et fort : dans l’état actuel du marché, les développeuses et les développeurs ont le pouvoir (ceux qu’il emploie “le mènent par le bout du nez”). Nous sommes une denrée tellement rare que nous sommes en mesure d’imposer à nos employeurs et clients de prendre en compte les impacts écologiques de leurs projets. François reste cependant lucide : ça ne suffira pas. Il en appelle à une loi pour réguler les émissions des logiciels et interdire les plus énergivores d’entre-eux (comme certaines blockchains). Hélène nous rappelle l’intérêt de se constituer en tant que force collective et incite à rejoindre les organisations telles que onestla.tech - dont elle est membre, comme de nombreux coopérateurs de Les-Tilleuls.coop.

Compte rendu rédigé par Kévin.

Pauline Vos a voulu nous faire voyager dans le temps. Un petit clin d'oeil à un classique : "Back to the future". C'est un peu une suite qu'elle nous présente, en continuité avec ses premières réflexions sur les commits atomiques. Elle nous présente dans un premier temps la puissance du rebase interactif. La possibilité de squash, supprimer, déplacer des commits par rapport à l'arbre d'origine. Cela permet d'éviter les merges entre branches pour se mettre à jour, de garder un historique clair, de déplacer une modification dans le commit correspondant, de supprimer un commit, etc… 

Elle aborde ensuite un voyage dans le temps plutôt axé sur nos actions, le reflog, combien d'entre nous ont été pris de panique après une erreur avec git ? Je viens d'écraser 3h de dev… que faire ? Reflog nous permet d'accéder à l'historique de nos actions plutôt que de nos commits. Un outil des plus utiles pour voyager dans le temps et nous permettre de reset sur un état précédent. N'ayons plus peur du reset, c'est toute la puissance de l'outil, et quel dommage de ne pas en profiter ! 

Pour terminer, c'est grâce à une métaphore mêlant œufs et immeubles, qu'on comprend parfaitement l'utilité de bisect. L'alliance de tests ou de scripts perso, de rebase interactifs et de cet outil nous permet de connaître le commit précis où notre code a commencé à ne plus fonctionner. Un gain de temps considérable. 

C'est avec clarté (et ce n'est pas toujours évident avec git) et humour que nous avons pu en apprendre davantage sur quelques bonnes pratiques d'un outil dont nous ne pouvons pas nous passer, un plaisir à écouter ! 

Compte rendu rédigé par Justine D.

Avec humour et intelligence, Stéphanie Trumtel a mis en parallèle les codes informatiques et génétiques, ou plus exactement les manières similaires dont une base de code et les organismes vivants peuvent évoluer.

Saviez-vous par exemple, qu’en copiant du code dans un projet, nous reproduisons ce que fait la nature lorsqu’elle croise plusieurs organismes ? Qu’une cellule, avec tous ses composants très spécialisés, s'apparente à une énorme architecture pleine de micro-services ? 

Elle nous a donné des exemples de systèmes complexes, d’utilisations détournées de logiciels ou d’algorithmes qui génèrent du hasard dans lequel on trouve finalement du sens, tels que les IA renards de Skyrim. D’autres liens tels que l’inévitable jeu de la vie ou l’archivage de code (Git ou ADN), nous laissant apprécier notre discipline comme plus riche que nous la voyons au jour le jour.

La citation que nous retiendrons :

En effet, si le code génétique copié fonctionne mal… son hôte meurt. Plus efficace que PHPUnit.

Compte rendu rédigé par Élise.

Ça en surprendra sûrement plus d'un, mais l’équipe PHP des Tilleuls ne fait pas que du Symfony. Et oui, nous développons également avec Laravel. Nous y avons même contribué ! C’est donc avec plaisir que nous avons assisté au passage de cet OVNI : la présentation de l’écosystème Laravel dans une conférence PHP en France. C’est Gabriel Pillet qui s’est prêté à cet exercice difficile, et il s’en est sorti avec brio.

Laravel vient avec une myriade d’outils officiels, qui permettent d’ajouter très facilement des briques fonctionnelles complètes à nos applications : Vapor, Forge, Envoyer, Horizon, Nova, Echo, Lumen, Sail, Spark, Valet, Mix, Cashier, Dusk, Sanctum, Scout, Scoialite, Telescope, JetStream… Des outils de développement aux systèmes de déploiement en production en passant par un moteur de recherche full text, un outil d’échafaudage de projets type “SaaS” ou encore un système de gestion de files… Le moins que l’on puisse dire c'est que Laravel couvre tous les besoins. Et encore, on n’évoque même pas les très nombreux autres outils développés par la communauté (Gabriel en a présenté quelques-uns).

Seule ombre au tableau (mais elle est de taille) : nombre de ces outils ne sont pas des logiciels libres mais sont distribués sous une licence propriétaire et payante.

Compte rendu rédigé par Kévin.

Dans un talk bourré d’humour, Marine Gandy, développeuse Drupal (et oui, il en faut !) chez Ekino nous a parlé du “syndrome” de l’imposteur, ce sentiment de non légitimité qui touche tout de même 70% de la population. Pourquoi “syndrome” entre guillemets ? Parce que ce mot pourrait laisser penser qu’il s’agit d’une pathologie, or n’importe qui pourrait avoir affaire à ce phénomène une fois dans sa vie de façon très ponctuelle : le terme plus approprié pour définir ce mécanisme de dévalorisation serait plutôt “expérience d’imposture”.

Après nous avoir expliqué pourquoi ce “syndrome” est très présent dans les métiers du web (technologies qui évoluent constamment, besoin de se remettre à niveau régulièrement) et nous avoir appris deux synonymes de “peur de l’échec” qui nous feront gagner un max de points au scrabble (kakorrhaphiophobie et atychiphobie), Marine nous a donné des pistes pour faire la différence entre syndrome de l’imposteur et contexte professionnel problématique. 

Vous souffrez d’un manque de communication au sein de votre équipe ? On vous donne des tâches qui ne correspondent pas à votre fiche de poste ? Vos objectifs sont irréalistes? Bonne nouvelle, vous ne souffrez pas du syndrome de l’imposteur mais d’un contexte professionnel défaillant, venez plutôt postuler chez Les-Tilleuls.coop ! (ça ce n’était pas dans la conférence, c’est bonus :) )

Elle nous a ensuite donné les solutions qu’elle a elle-même appliquées pour se sortir de ce syndrome (car même si son aisance à l’oral nous le ferait facilement oublier, Marine souffre elle aussi de ce sentiment d’imposture !) : 

Compte rendu rédigé par Laury.

Pas mal comme premier concentré de conférences ? On vous donne rendez-vous dans quelques jours pour découvrir la suite de notre compte rendu !