Ce qu'il faut retenir du Forum PHP 2022 - partie 1

La semaine dernière, une (très) grande partie de notre équipe s’est rendue à Disneyland Paris pour assister à la vingt-troisième édition du Forum PHP 2022. Après une reprise en douceur l’année dernière au Novotel Paris Est, l’AFUP a (re)mis les petits plats dans les grands et nous a offert deux jours de convention inspirante dans un cadre d’une autre dimension. Les conférences ont eu lieu à l’hôtel New York - The Art of Marvel et, entre les mélodies des Avengers et salles de conférences visuellement impressionnantes, notre équipe vous a concocté un retour des conférences qui l’ont marquée. Voici une première partie.

Notre coopérateur Mathias Arlaud démarre son talk en présentant deux photos légèrement différentes. Ces photos vont nous montrer la différence d’interprétation entre l’homme et la machine : pour l’homme ces images sont les mêmes alors que pour une machine ces fichiers sont totalement différents. Il nous montre également comment les caractères ASCII sont encodés ainsi que leur représentation hexadécimale. 

Il explique ensuite comment la recherche Elasticsearch fonctionne : pour chaque recherche, le texte recherché est comparé avec les documents présents dans Elasticsearch puis un score est calculé pour chaque document afin d’en connaître sa pertinence.

Il nous présente ensuite comment ce score est calculé : Sigma(TF*IDF)*C

Mathias nous présente ensuite comment fonctionnent les analyses qui sont faites lors de l’indexation des documents et lors de la recherche. Un analyseur est composé de trois choses : un ou plusieurs character filters, un tokenizer et un ou plusieurs token filters.

Compte rendu rédigé par Quentin.

Nous assistons à la présentation de la PHP Foundation et des speakers, Sebastian BERGMANN (le créateur de PHPUnit) et Roman PRONSKIY (product marketing manager chez JetBrains). 

RFC, corrections de bugs, maintenance… Tout cela prend du temps et nécessite des ressources. Ils nous rappellent que ces 30 dernières années, nous avons assisté à la naissance des logiciels Open Source Apache, MySQL, Linux… Ils nous expliquent également que la connaissance principale de PHP a très longtemps été basée sur seulement deux personnes (Dmitry Stogov et Nikita Popov) sans qui PHP ne serait pas là où il en est aujourd’hui.

La PHP Foundation consiste à financer des équipes de devs permettant de maintenir et de développer le langage pour lequel nous nous retrouvons au Forum PHP. Les financements de cette fondation sont obtenus via la plateforme Open Collective. À ce jour, plusieurs centaines de milliers de dollars (600 000 $) ont été collectés pour continuer de faire vivre le langage. 80 % de ces fonds proviennent de sociétés. Parmi tous ces fonds, environ 100 000 $ reviennent aux développeurs du langage. 

Pourquoi si peu par rapport à ce qui est collecté ? Le besoin de la PHP Foundation “d’épargner” et de potentiellement ouvrir ces fonds à d’autres recrues. 10 personnes sont actuellement membres de la PHP Foundation, personnes qui se rassemblent toutes les deux semaines pour échanger sur les futures évolutions du langage.

Compte rendu rédigé par Vincent C.

Amélie Abdallah donne sa première conférence… en tant qu’alternante ! Elle fait à travers cette conférence un retour personnel de ce qu’elle a vu, entendu et ressenti lors de son changement de carrière. 

Elle évoque sur scène ses premières expériences de développeuse. Elle se retrouve dans des PME à écrire ses premières lignes de code dès le premier jour et face à une absence de formation métier. Rapidement, elle est perdue (à l’écoute de tous les noms de postes qui circulent autour d’elle, du manque d’accompagnement…). Elle fait face à une dissonance entre la promesse de sa reconversion et la réalité.  

Avec de l’humour mais toujours avec sérieux, elle invite les recruteurs et recruteuses (mais également les devs) à ne pas faire écrire du code dès le premier jour à un nouvel arrivant reconverti (attendre au moins deux semaines). Elle invite aussi à une mise à niveau de tous les postes : présentation de tous les métiers, des fondateur.rice.s, créer des dépôts sur la mise à jour technique… Le système de marrainage / parrainage revient également sur la table et enfin, elle invite à rédiger des rapports d’étonnement au bout de un à deux mois.

Amélie nous offre à travers sa première conférence une sorte de thérapie très intéressante, avec presque un jeu théâtral. Son feedback nous permet même de nous donner chez Les-Tilleuls.coop des pistes pour améliorer l’onboarding de nos reconverti·e·s !  

Compte-rendu rédigé par Vincent C.

Matthieu Napoli, développeur PHP et ex Serverless, est allé voir du côté de Node pour y piocher des idées. Il en a retenu trois différences principales :

D’abord, l’utilisation de l’asynchrone de manière omniprésente. En PHP, on a très peu besoin d’en utiliser, car les calculs se font souvent sur plusieurs processus, et sont donc plus rapides ; mais pas Node, qui lui utilise les event loop. Node alterne en effet les processus au niveau du langage, et pas l'OS, ce qui force à penser la structure du code différemment. 

Ensuite, en JavaScript, tout est une variable, que ce soit un attribut, une fonction ou une classe. On peut donc la modifier à la volée après instanciation, ce qui peut être utile pour les mocks (redéfinir une fonction de classe) ou la décoration d’objets par exemple.

En dehors de Node mais toujours dans l’univers JavaScript, il faut également parler de TypeScript, qu’il compare aux interfaces PHP qui permettent de spécifier notre code, ou aux annotations PHPStan. Mais la beauté de ce typage est qu’il est évalué en permanence, avant d’avoir besoin d’être compilé : pas besoin de DTO ou autres classes de mapping entre objets, on code plus facilement car on type plus facilement !

Il aborde enfin un point sujet à de nombreux débats : l’omniprésente de l’injection de dépendance (DI) en PHP en particulier avec Symfony. Il argumente qu’un service étant stateless, il pourrait tout autant être statique. C’est ce qui est le cas en JavaScript, où les services sont des fonctions importées depuis d’autres fichiers. Laravel utilise une autre alternative équivalente qui sont les Facades. Il vante donc le pattern Service Locator qui mériterait à être utilisé plus souvent.

En résumé, il nous invite à sortir de la zone de confort de nos automatismes pour utiliser d’autres paradigmes et découvrir d’autres façons de coder. On ne doit pas avoir honte non plus d’utiliser une architecture progressive, c'est-à-dire tester une nouvelle manière de faire différente du reste de l’application, sans avoir besoin de changer tout un projet, pour avoir une idée plus rapide de notre nouvelle approche.

Compte-rendu rédigé par Élise.

Sarah Haïm-Lubczanski est Technical Writer. Elle écrit non pas du code, mais la documentation sur ce que fait le code, ce qui nécessite à la fois une connaissance technique et une compétence d'écriture.

Elle évoque les différents types de documentations que l’on peut trouver : d’abord dans le code lui-même, du commentaire redondant (à éviter) à l’explication des besoins métiers (à privilégier).

Puis les documents annexes au code, comme les tests automatisés, le `README`, `GETTING_STARTED`, release notes, fichier Swagger, qui facilitent la compréhension du projet par les nouveaux développeurs. De même, les `Makefile` ou `man pages` constituent un bel exemple de documentations basiques mais riches.

Mais l’intérêt principal de la documentation est de rendre visible, d’expliquer le but de notre logiciel à celles et ceux qui en ont besoin. En effet, pourquoi publier notre code en premier lieu si personne ne peut l’utiliser ?

Pour cela, Sarah conseille de bien nommer notre projet, de le décrire simplement, d’accompagner à l’utilisation, de s’adapter aux interlocuteur.rice.s, de faciliter la remontée des bugs.

Ensuite, d’architecturer la documentation, en suivant le framework Diátaxis, bible du domaine, qui détaille les différents objectifs :

En rangeant notre doc de cette manière, on peut s’apercevoir des zones d’ombres qui existent et les combler.

Parmi ses autres conseils : copier les documentations qui nous plaisent s’avère un bon exercice, par exemple celles de GitLab, Stripe, ou API Platform.

Également soigner son style, se priver de toutes références culturelles et expressions obscures, humour douteux, qui peuvent perdre le lecteur. Et privilégier une écriture accessible et correcte, en s’aidant du Google Developers Style Guide. 

Automatiser une partie du travail peut être une solution efficace, par exemple à l’aide des GitHub Actions, ou de génération des exemples à partir du code, pour s’assurer d’être toujours à jour. En effet, mieux vaut ne pas montrer de documentation périmée au risque de perdre ses lecteurs !

Et enfin évidemment, soigner l’UX, et ne pas hésiter, pour les équipes nombreuses, à demander des conseils à l’équipe communication et aux DevRels, voire à embaucher une personne dédiée, car c’est bien un métier à part entière !

Compte-rendu rédigé par Élise.

Benoit VIGUIER de chez Platform.sh a pris le micro pour nous présenter OpenTelemetry. Propulsé par la Cloud Native Computing Foundation (déjà à l’origine de l’orchestrateur Kubernetes), ce nouveau standard Open Source propose de normaliser la communication entre nos applications et les nombreux systèmes qui nous permettent de surveiller leur état de fonctionnement. Conçu pour être très générique, le protocole peut être utilisé pour tous les types de télémétrie auxquels nous sommes habitués, des outils analytiques (Matomo, Google Analytics) aux outils de tracing (Blackfire, New Relic).

Grâce à OpenTelemetry, il est donc plus facile de communiquer avec nos outils de télémétrie habituels sans avoir besoin d’un bundle spécifique à chacun d’eux, ce qui, à terme, simplifiera et allègera grandement nos projets. 

Pour y arriver, il nous faudra installer un collecteur qui sera chargé de traiter et envoyer les données de télémétrie à nos outils habituels. Ce collecteur est situé idéalement sur le même réseau, voire sur la même machine que celui de notre application, afin de réduire les risques de perte d’informations en cas de rupture de communication avec les applications de télémétrie, et ainsi de s’assurer d’avoir réellement l’ensemble des données.

Compte-rendu rédigé par Jérôme.

Stéphane Bortzmeyer est un informaticien français spécialiste des réseaux informatiques. Il est considéré comme l’un des pionniers de la promotion du chiffrement dans les échanges numériques. Il introduit sa conférence en rappelant qu’internet est un réseau physique, et qu'en tant que tel il est soumis aux réalités géopolitiques des États. La guerre en Ukraine nous le rappelle, dans les territoires occupés par l'armée russe les opérateurs locaux sont contraints de faire passer les connexions par la Russie et les soumet ainsi à la censure de Poutine. En effet, il est plus simple d'exercer un contrôle sur le flux d'informations lorsque les outils physiques qui le permettent se trouvent à l'intérieur des frontières. C'est pourquoi les États-Unis imposent que les connexions entre deux pays d'Amérique latine transitent par leur territoire.

Stéphane souhaite également rappeler qu'Internet existe avant tout par son infrastructure, avant les services dont on parle beaucoup plus. N'oublions pas qu'Internet n'est pas le web. D'ailleurs, certains gouvernements enclins à mélanger Internet et ses services savent bien lorsqu'il s'agit d'instaurer une censure qu'il est plus efficace de le faire via l'infrastructure.

Ainsi l'État iranien interfère dans les communications et prive de couverture réseau des pans entiers de sa population et de son territoire, notamment le Kurdistan iranien, pour contrer le soulèvement populaire consécutif à l'assassinat de Mahsa Amini. Le peuple en lutte se sert de Signal malgré la répression du régime des mollah, dont l'utilisation est rendue possible grâce à la mobilisation de certains acteurs du logiciel libre et l'interconnexion à des serveurs situés à l'étranger.

Il existe cependant des manières de résister à la direction mortifère que pourrait prendre internet. La maîtrise démocratique des flux de communication ou encore le fait d'imposer des interconnexions locales plutôt que l'entremise d'une grande puissance régionale sont des pistes.

Stéphane conclut en rappelant qu'internet n'est pas un concept immatériel mais bien une infrastructure ancrée dans le monde réel. Ce constat appelle donc toutes les personnes qui se soucient de son évolution à se saisir des enjeux (géo)politiques qui détermineront les directions que prendra ce réseau.

Compte-rendu rédigé par Manus et Raph. 

Retrouvez très prochainement la suite de notre compte-rendu !