Notre Forum PHP 2022 à Disneyland

L’équipe des JoliCodeurs était présente en force à Disneyland pour assister au Forum PHP 2022 : le plus gros événement PHP de l’année et notre pèlerinage annuel au pays des éléPHPants.

Nous y avons présenté trois sujets :

• Bastien a raconté une histoire de sauvetage comme nous les aimons, avec un cas client, coincé sur une production instable et précaire – il s’est appuyé sur la flexibilité des PaaS pour migrer en très peu de temps le projet sur une infrastructure robuste et scalable ;
• Loïck s’est attaqué aux workers PHP et particulièrement à systemd – nous avons aussi un très bon article sur le sujet si cela vous intéresse !
• Et enfin Laurent s’est attelé à démystifier les CSP, ces headers HTTP qui aident à protéger les visiteurs de votre site.

Dans cet article nous souhaitons vous parler des conférences qui ont le plus attiré notre attention lors de ces deux jours.

Section intitulée comment-etre-bien-onboarde-en-tant-que-developpeuse-junior-reconvertieComment être bien onboardé en tant que développeuse junior reconvertie ?

Amélie ABDALLAH nous a raconté son histoire de développeuse reconvertie !

Trouver un travail dans le développement après des études courtes n’est pas aisé, et il est plutôt facile de tomber sur une société qui ne saurait pas accueillir et encadrer les juniors – c’est ce qui est arrivé à Amélie et elle a eu l’intelligence de très vite quitter le poste.

Elle trouve alors un nouveau job et c’est le rêve :

• procédure d’accueil complète ;
• rencontre de tous les métiers ;
• présentation de tous les collègues ;
• système de marraine / parrain pour l’accompagnement personnel ;
• rapport d’étonnement quelques semaines après l’arrivée…

Plein de bonnes pratiques qui devraient être la base dans le monde du travail.

C’était aussi l’occasion de vanter les mérites des profils en reconversions, plus motivés et apportant des points de vues plus originaux et diversifiés qu’une équipe uniforme de background et de formation.

Section intitulée watch-the-clockWatch the clock

Andreas HEIGL nous a présenté la PSR-20 qui vise à standardiser les librairies qui fournissent le temps.

L’interface est simple :

<?php

namespace Psr\Clock;

interface ClockInterface
{
    /**
     * Returns the current time as a DateTimeImmutable Object
     */
    public function now(): \DateTimeImmutable;
}

Nous pouvons imaginer une implémentation de SystemClock qui retournerait la date du système, et une FixedClock qui serait fixe et utilisable dans nos tests !

Elle s’utilise de cette façon :

final class PastChecker
{
    public function __construct(private ClockInterface $clock) {}

    public function hasDateTimeAlreadyPassed(DateTimeImmutable $date): bool
    {
        return $date < $this->clock->now();
    }
}

L’intérêt de cette démarche est d’obtenir une méthode pure pour obtenir le temps, et ainsi avoir une programmation plus prédictive (et dire adieu aux flaky test – ces tests qui plantent parfois de façon aléatoire lorsqu’on joue avec le temps).

Nous avons aussi dernièrement mis en place libfaketime dans Docker mais c’est un autre sujet !

Section intitulée sortir-du-cadreSortir du cadre

De la conférence de Robin CHALAS, nous souhaitons surtout retenir les bons conseils et pas tellement les échanges Twitter exposés.

Dans un projet Symfony, une certaine structure de dossiers et d’organisation des fichiers est proposée par défaut : nous avons la liberté de la modifier à notre guise et Robin nous encourage à en profiter.

Depuis l’arrivée de l’auto-wiring, il n’est plus nécessaire de respecter les conventions de nommage des dossiers au sein de ./src/ (Command par exemple).

Pour le reste et notamment partout où Symfony Flex serait amené à faire des ajouts / modifications de fichier, il est recommandé d’être le plus léger possible sur les modifications, dans le but de simplifier la vie de Flex lorsqu’il doit appliquer une mise à jour (et donc nous simplifier la vie à nous aussi).

Évitez par exemple de changer l’intégralité de l’indentation, l’ordre et les commentaires de ./config/packages/framework.yaml si vous ne voulez pas souffrir lors de votre prochain composer recipes:update !

Section intitulée back-to-the-sylius-futureBack to the sylius Future

Loïc Frémont, après un intéressant retour sur les lacunes des versions précédentes de Sylius, nous a présenté la merge request qui ajoute enfin le support de Symfony 6 🎉.

Nous avons pu voyager avec plaisir dans le futur prometteur de Sylius, autour de la simplification des dépendances, de l’intégration progressive du composant workflow de Symfony, de Panther, ou encore de l’amélioration du support API via un travail minutieux et coordonné avec les équipes d’API Platform.

Section intitulée ffi-de-nouveaux-horizons-pour-phpFFI : de nouveaux horizons pour PHP

Cette conférence de bricoleur par Pierre PELISSET aurait pu faire écho à nos petits jeux du JoliDay, axée sur les interactions matérielles entre PHP et et le port série d’un boîtier particulier.

Nous avons apprécié suivre l’histoire et les rebondissements de cette intégration, tout en imaginant les infinies possibilités de FFI pour les projets IoT.

Section intitulée recit-du-passage-d-une-migration-d-un-hebergement-classique-a-une-infra-cloud-paasRécit du passage d’une migration d’un hébergement classique à une infra cloud PaaS

Bastien Jaillot nous raconte une histoire, celle d’un site qui n’arrive plus à scaler, et dont le business est bloqué par les contraintes techniques qui y sont liées.

Rapidement mais sûrement, Bastien nous détaille les étapes qui mèneront ce projet vers une solution de croissance, qui passera par le cloud, et plus précisément le PaaS (Clever Cloud).

L’application est déjà bien découpée, il suffit alors d’ajouter un Varnish, de configurer un proxy, de tweaker quelques parties, afin de rendre la main à l’équipe de développement d’un site à nouveau bien dimensionné, permettant à ce client une croissance de 70% l’année suivante !

Le mot de la fin, il est souvent plus rentable de faire appel à des experts pour débloquer une situation plutôt que de s’embourber et de bloquer sa propre croissance.

Section intitulée les-femmes-a-barbe-et-a-capuche-sortent-de-la-grotte-pour-sauver-le-numerique-et-son-impactLes femmes à barbe et à capuche sortent de la grotte pour sauver le numérique et son impact

Anais SPARESOTTO et Hortense MAHON nous ont raconté leur combat pour faire prendre conscience de l’importance de l’accessibilité dans leur entreprise.

Nous le répétons souvent, 20% des français sont touchés par le handicap, soit 12 millions de personnes. Quel que soit votre cœur de cible, certains de vos utilisateurs en font donc certainement partie. Le constat que font Anaïs et Hortense au début de leur aventure est pourtant sans appel : la direction n’est pas intéressée ou plutôt ne se sent pas concernée par le problème. Commence alors un travail de longue haleine, alliant communication et pédagogie, qu’elles nous ont relaté dans cette conférence. Grâce à l’analyse de certains indicateurs recueillis par leur outil, elles ont pu prouver que leur base utilisateur était au contraire directement concernée et doucement sensibiliser chaque corps de métier à l’importance de créer un Web accessible. Elles ont par exemple mis en place un bot Opquast pour Slack qui publie de temps en temps une règle d’accessibilité. Leur travail acharné a fini par porter ses fruits : la DRH défend maintenant l’accessibilité comme une des valeurs de l’entreprise, plusieurs personnes de l’entreprise ont pu participer à la conférence Paris Web et certains de leurs chefs de produit ont eu à coeur de refuser des maquettes qui leur étaient présentées et qui n’étaient pas accessibles.

Passée cette étape, il a fallu faire un important travail de mise à niveau, via le référentiel RGAA, former les équipes, puis réparer au fur et à mesure les différents problèmes d’accessibilité rencontrés sur leur outil. Une des difficultés lorsqu’on souhaite respecter le RGAA et que certains critères ne peuvent être validés manuellement. Nous pensons par exemple aux attributs alt des images. Un outil automatisé pourra vérifier leur présence mais pas leur pertinence. Elles ont donc implémenté le référentiel RGAA sur leur outil, Toovalu, afin de pouvoir vérifier plus simplement son application en interne, ce qui leur a permis d’identifier plusieurs problèmes sur leur site.

Elles ont également cité certains outils utiles pour tester l’accessibilité d’un site, que vous pourrez trouver par exemple sur les sites de Tanaguru, W3C ou encore Wave.

Leur conclusion est que chacun doit s’impliquer à son niveau pour l’accessibilité. Ne restez pas des techniciens. Même si vous n’êtes que développeur back-end, rien ne vous empêche de remarquer des problèmes d’accessibilité et de les remonter, par exemple en créant des tickets de bug (une anomalie qui empêche certains utilisateurs d’utiliser votre application correctement est un bug). Faites évoluer les choses et n’oubliez pas pour qui vous développez.

Section intitulée de-l-humain-a-l-ordinateur-ou-decouvrir-le-sens-d-un-texte-avec-elasticsearchDe l’humain à l’ordinateur, ou découvrir le sens d’un texte avec ElasticSearch

Nous avions déjà couvert cette conférence lors de l’Afup Day à Lille.

Mathias ARLAUD nous a présenté dans cette conférence très pédagogique le fonctionnement d’une recherche avec le moteur Apache Lucene qui est au cœur d’Elasticsearch.

Nous avons d’abord disséqué ensemble l’équation qui permet à Apache Lucene d’attribuer un score de corrélation à un document pour une recherche donnée (ou plutôt une ancienne version de cette équation, plus simple à vulgariser) : Sigma (TF * IDF) * C.

Concrètement, pour chaque terme du document, nous calculons :

• le term frequency TF, est-ce que le mot de la requête apparaît souvent dans le document ? (nombre d’occurrence du terme dans le document, mis en racine carré par souci de normalisation) ;
• L’inverse document frequency IDF, est-ce que le mot de la recherche est intéressant pour la recherche ? (1 + log(nombre de mots total dans la base de données / (nombre de fois où le mot apparaît dans la base de données + 1)), le logarithme a pour but de normaliser les écarts).

Le score d’un document dépend donc en grande partie de ce que contient la base de données.

Nous calculons ensuite le coordination factor C qui récompense les documents avec le plus haut pourcentage de mots présents dans la requête (nombre de mots de la requête dans le document / nombre de mots total dans la requête) afin de pondérer le score de chaque document.

Évidemment dans la vraie vie nous ne cherchons pas directement sur les termes de la requête ou du document mais nous allons d’abord nettoyer nos données pour enlever le bruit superflu, c’est la tokenisation.

Dans Elasticsearch, cela se fait à l’aide d’analyzer. Ils sont composés de trois étapes :

• Les filtres de caractères : pour ajouter, modifier supprimer des caractères (html_strip, pattern_replace, mapping…) ;
• Les générateurs de tokens : pour découper la requête ou le document en plusieurs tokens. Apache Lucene requiert de travailler avec des tokens ;
• Les filtres de tokens : pour agir sur chaque token individuellement, pour le modifier, le remplacer, le redécouper, etc (word_delimiter, lowercase, synonym, phonetic, stopword…). Par exemple stopword permet de se débarrasser des tokens « inutiles » (le, les, etc).

Pour remplacer des emojis nous utilisons le filtre de token synonym (et la librairie emoji-search développée par JoliCode).

Un autre filtre de token intéressant est le filtre stemmer qui permet de remplacer tous les mots par leurs lemmes (formes canoniques) pour regrouper les mots qui portent le même sens (développer, développeuses, développement…)

Si les sujets de tokenisation vous intéressent, JoliCode a publié un article sur le sujet

Après avoir appliqué le flux d’analyzers sur la requête et sur les documents, si nous appliquons notre équation, nous retrouvons des scores beaucoup plus pertinents.

Section intitulée sauve-un-e-dev-ecris-une-docSauve un-e dév, écris une doc !

La documentation, c’est un sujet que maîtrise parfaitement Sarah HAÏM-LUBCZANSKI, et elle nous l’a prouvé une fois de plus !

Au-delà d’essayer de convaincre qu’écrire de la documentation est une bonne chose (ça l’est, n’en doutez pas), elle nous a surtout expliqué ce qui fait une bonne documentation, et quelles sont les méthodes et astuces à mettre en place pour y parvenir.

Parmi ces méthodes nous retenons particulièrement le Framework Diataxis, grâce auquel nous allons pouvoir découper notre documentation en 4 types (non obligatoires) :

• Reference (typiquement la liste des valeurs de configuration possibles, ou un fichier OpenAPI par exemple) ;
• Explanation (guide de conception, comment notre logiciel est conçu, quelles sont ses fonctionnalités globales) ;
• Tutorials (apprentissage pour l’utilisateur, guide d’utilisation du logiciel à différents niveaux) ;
• How-to-guides (cas pratiques détaillés, contextualisés).

Notons que le MDN utilise Diataxis, c’est ce qui en fait certainement une des documentations techniques les plus agréables à utiliser.

En plus des méthodes, Sarah nous a prouvé par l’exemple que dans certaines équipes, la documentation est prise très au sérieux. Par exemple, chez Stripe 35 personnes travaillent à temps plein sur la documentation du produit (fonctionnelle, et technique). Elle est très riche, contient beaucoup d’exemples personnalisés avec votre clé d’API si vous la consultez en étant connecté à votre compte. Les exemples sont disponibles en fonction des versions précédentes de l’API. En bref, la documentation est un projet à part entière chez Stripe.

Section intitulée revue-de-code-on-n-est-pas-venu-pour-souffrirRevue de code : on n’est pas venu pour souffrir !

Retour sur un sujet déjà abordé à plusieurs reprises lors des dernières éditions : la revue de code.

La présentatrice Anne-Laure De Boissieu a récemment changé d’entreprise, et appréhendait la manière dont son code allait être revu au sein de sa nouvelle équipe, dont la taille était également beaucoup plus grande.

Les commentaires « bruts » peuvent être ambigus et laisser à l’interprétation de chacun sans contexte additionnel, en plus de pouvoir blesser le destinataire du commentaire.

C’est pourquoi Anne-Laure de Boissieu nous a présenté les Conventional Comments , une spécification similaire aux Conventional Commits, permettant d’expliciter le propos du commentaire et donc d’améliorer la communication.

Ce standard consiste à respecter un certain format lors de l’écriture d’une review :

<label> [decorations]: <subject>

[discussion]

Le label permet de qualifier le commentaire, parmi une liste définie par la spécification : un problème identifié sera labellisé issue, une modification peu importante sera un nitpick, et nous pourrons féliciter un collaborateur avec un commentaire labellisé praise (Et oui, c’est important parfois !).

Le subject correspond au contenu du commentaire de revue, qui pourra être explicité avec decorations et discussion qui sont optionnels.

Nous vous invitons à consulter la documentation de cette spécification avant de peut-être la mettre en place dans votre équipe.

Vous pouvez également utiliser des intégrations GitHub et GitLab, permettant d’avoir le format prérempli dans vos commentaires afin de faciliter l’utilisation de ce standard !

Attention néanmoins à ne pas oublier la code-review automatique, par les outils de qualité de code (PHPCS, PHPStan) dans une intégration continue !

Section intitulée en-conclusionEn conclusion

Nous avons beaucoup apprécié encore une fois l’événement phare de l’AFUP.

Nous avons même rencontré Loki !

Côté conférences quelques sujets étaient plus plaisants à écouter qu’à retranscrire, par exemple nous avons apprécié Internet et la géopolitique de Stéphane BORTZMEYER ou encore le sujet sur OpenTelemetry par Benoit VIGUIER – standard très prometteur (avec un gros point d’attention sur le développement d’intégrations user-land).

Côté organisation, nous souhaitons féliciter l’AFUP qui a innové avec un nouveau lieu de très grand standing – l’hôtel Marvel de Disneyland Paris.

Bien que l’apéritif communautaire n’était pas aussi fou que les années précédentes, nous avons beaucoup apprécié le petit jeu des QR Code à scanner – très bon « ice-breaker » !

Avoir une gare TGV accessible à pied du lieu de conférence est aussi un luxe pour les JoliCodeurs en région !

Retrouvons-nous en mai 2023 pour l’Afup Day à Lille et Lyon !

---

Cet article porte sur la conférence Forum PHP 2022.