Retour sur le Forum PHP - jour 2

Découvrez aujourd'hui les conférences marquantes du Forum PHP 2024, qui s'est tenu les 10 et 11 octobre derniers à l'Hôtel New York - The Art of Marvel. Si vous ne l'avez pas encore consultée, la première partie de compte-rendu est disponible sur cette page. Dans cet article, nous revenons sur quelques conférences programmées le vendredi 11 octobre. Bonne lecture !

Qui ne connaît pas Pascal Martin ? Légende vivante de la communauté PHP francophone, auteur de livres qui font référence dans notre domaine (et aussi d’un super livre à destination des futurs speakers), spécialiste Cloud et conférencier réputé.

Pendant 40 minutes, Pascal a suivi le parcours d’une requête HTTP pour faire un tour d’horizon complet de nos métiers et de la complexité des stacks modernes. Logiciel, matériel, réseau, hébergement, back, front, architecture, tests, CI/CD et même gestion de projet, légal et sécurité… Dans cette conférence léchée, Pascal nous a décrit les nombreuses facettes des projets complexes, montré l’importance du travail d’équipe et les différentes options qui s’offrent aux développeuses et développeurs pour évoluer dans leur carrière.

Écrit par Kévin Dunglas.

En programmation fonctionnelle, les fonctions pures sont celles qui ne provoquent pas d’effets de bord et dont les variables sont immuables, la programmation fonctionnelle est donc sans état. Comment avoir de l’état ou des effets de bord avec des variables immuables ? Une monade est une structure qui combine des fonctions et englobe leurs valeurs de retour dans un type avec des effets additionnels.

Durant sa conférence, Gina Peter Banyard nous a présenté quelques exemples d’implémentation de monades en PHP. Pourquoi ne pas simplement avoir quelques méthodes sur mes classes et les utiliser via le null-safe operator ? La monade Either englobe justement cette stratégie dans un type union L | R. Il est alors possible, par exemple, de combiner toutes les conditions avec une gestion d’erreurs via un match intégré à la monade. La monade Maybe englobe la monade Either avec le type null | T. La monade Exception englobe la monade Either avec le type T | Exception. La monade List englobe des transformations naturelles sur des listes.

Écrit par Vincent Chalamon.

Charles Fol nous a parlé d'une vulnérabilité de type buffer overflow découverte par hasard dans la glibc, en travaillant sur des failles de "lecture de fichier". Ces failles exploitent une lecture insuffisamment contrôlée pour outrepasser les permissions et ainsi accéder à des fichiers de configuration normalement inaccessibles, voire à forcer le serveur à établir des connexions réseau. 

En combinant cela avec des protocoles spécifiques à PHP comme phar://, il est possible d’exécuter du code à distance via la désérialisation de métadonnées malicieuses. Heureusement, depuis PHP 8, la désérialisation automatique des métadonnées des phars a été désactivée. Charles a également exploré les filtres PHP, permettant à un attaquant de modifier le contenu d'un flux. 

En testant différentes combinaisons, il a découvert qu'un filtre particulier essayait de lire à une adresse mémoire invalide, révélant un bug dans la glibc présent depuis 24 ans ! Ce bug survient lors de la conversion de certains charsets chinois avec iconv(), provoquant un buffer overflow qui permettrait de manipuler la mémoire et d'exécuter du code malveillant sur le serveur.

Écrit par Thibaut Arnoud.

Matthias Noback est revenu sur scène pour nous présenter des outils d'analyse statique permettant d’automatiser le refactoring. Contrairement à l'analyse dynamique, qui échoue en cas d'erreur, l'analyse statique anticipe les erreurs comme le ferait un être humain en lisant le code. Des outils comme PHPStan et Psalm identifient des problèmes potentiels sans exécuter le code. 

L'analyse statique se distingue de celle des IDE, car les configurations et les outils peuvent varier d'un développeur à l'autre. Elle parcourt chaque fichier, applique des règles, et génère des objets représentant les éléments significatifs du code (AST). Par exemple, PHPStan collecte des informations sur les types et signale des éventuels problèmes. Matthias a ensuite insisté sur le fait que ce sont les normes des projets qui déterminent l'utilisation de ces outils ; mais une fois en place, les revues de code peuvent alors se concentrer sur la conception et les fonctionnalités. Matthias a conclu sa conférence en évoquant  Rector et ses capacités de refactoring automatisé qui vont bien au-delà de celles de PHPStan.

Écrit par Vincent Chalamon.

Pour sa seconde conférence du Forum, Nicolas Grekas est revenu sur le concept du "lazy loading", une stratégie qui consiste à initialiser des objets seulement quand ces derniers sont nécessaires, le tout évidemment dans le but d’améliorer les performances du code. Par exemple, un mailer injecté dans un objet ne sera initialisé que lorsqu'il est effectivement utilisé. Cette technique aide aussi à résoudre les références circulaires et permet de "réinitialiser" certains objets, comme l’Entity Manager de Doctrine.

Nicolas nous a ensuite présenté les quatre stratégies de lazy loading définies par Martin Fowler :

Ces deux dernières méthodes sont implémentées dans Symfony via le composant VarExporter et utilisées dans Doctrine. Avec PHP 8.4, ces mécanismes seront intégrés nativement grâce aux travaux de Nicolas et Arnaud Le Blanc, améliorant la gestion des classes finales ainsi que la performance des Virtual Proxies et des Ghost Objects.

Écrit par Nicolas Philippe.

Après une première visite en 2021, Pauline Vos est revenue au Forum PHP pour donner une conférence captivante sur Git, avec un focus sur la commande git bisect, particulièrement utile pour identifier les commits responsables d'une régression.

Elle a illustré son propos avec un exemple simple : face à une régression sur un site web, plutôt que de fouiller manuellement dans l'historique Git, git bisect permet de cibler le commit fautif en partant d'un commit stable et en testant successivement des commits intermédiaires, indiquant s'ils sont bons ou mauvais, jusqu'à isoler celui qui cause le problème. Elle a expliqué que bisect peut également être utilisé dans d’autres situations, par exemple pour identifier la cause d’un build anormalement long ou des tests qui ralentissent la CI.

Pauline a également suggéré quelques astuces comme remplacer des termes par défaut good/bad par des termes plus adaptés, corriger des erreurs via git bisect replay, et automatiser ces tâches  avec des scripts bash. Elle a conclu en insistant sur l'importance de maintenir des commits atomiques et d'écrire des scripts pour les cas plus complexes.

Écrit par Justine Delalleau.

Je le confesse, j’ai une aversion pour les Makefile dans les projets qui ne sont pas écrits en C ou en C++. Les développeurs PHP maîtrisent souvent mal make et ses subtilités. L’usage impropre de l’outil entraîne souvent plus de problèmes qu’il n’en règle. Cependant, il faut bien le reconnaître, dans des projets complexes et/ou ayant une pile technique hétérogène (utilisation de plusieurs langages de programmation, microservices, dépôts Git monolithiques…), ainsi que pour créer des pipelines de CI/CD efficaces, disposer d’un outil de création de tâches automatisées (aka un task runner) s’avère bien pratique.

Ça tombe bien,  Grégoire Pineau vient de tuer le game ! Il a créé Castor, un task runner écrit en PHP qui exécute des tâches elles-même écrites en PHP. L’usage de Castor est extrêmement simple, et pourtant l’outil propose un grand nombre de fonctionnalités ! Grâce au recours massif aux attributs PHP, à l’API de reflection du langage ainsi qu’aux composants Symfony, l’expérience développeur est léchée, jugez plutôt :

Et oui, l’appel à la fonction notify() va bien afficher une fenêtre de notification via le système de notification de votre système d’exploitation à la fin de la tâche !

Castor est nativement capable de : 

Ça n'est pas assez ? Vous pouvez aussi utiliser toutes les bibliothèques que vous voulez via son Composer intégré, et étendre l’outil à votre guise. 

Reste un problème de taille : Castor est écrit en PHP… Il faut donc que PHP soit installé pour l’exécuter. Dans l’exemple plus haut, on utilise Castor pour lancer le projet via Docker Compose. Mais rien ne garantit que PHP sera installé sur l’hôte. Il est aussi très courant que les machines exécutant les pipelines de déploiement ne disposent pas d’un PHP local. Qu'à cela ne tienne, les scripts Castor peuvent être distribués sous la forme d’un binaire contenant son propre interpréteur PHP compilé en statique (le génial outil static-php-cli est utilisé pour ça) ! On peut alors simplement copier le fichier sur la machine qui va exécuter les tâches et les lancer sans avoir à installer aucune dépendance externe.

Quoi de mieux que PHP pour automatiser les tâches d’un projet PHP ? Adoptez un castor !

Écrit par Kévin Dunglas.

David Buros nous a proposé une petite introduction à la domotique à budget réduit et complètement résiliente qu’il a mise en place dans sa maison.

Pour cela, il s’est basé sur des solutions open source, en connectant des modules électriques et différents capteurs permettant de remonter des données sur certains  éléments de sa maison. Il a ensuite utilisé le système de domotique Home Assistant qui présente un dashboard complet avec les témoins de température de chaque pièce, la consommation électrique globale et par appareil, ou encore… le solde de son compte bancaire !

David nous a expliqué s’être  appuyé sur le protocole Zigbee, la librairie MQTT, et le bridge Zigbee2MQTT pour collecter les données des différents périphériques et les publier dans des topics MQTT, qui sont ensuite consommés par le système de domotique Home Assistant. La consommation électrique est quant à elle mesurée via une carte électrique connectée au réseau local via un port ethernet afin de mettre à disposition un serveur WES accessible via un script PHP. Il a ensuite packagé le tout dans un binaire standalone grâce à FrankenPHP ! Un système domotique complet sur mesure, à moindre coût, qui tourne grâce à des éléPHPants !

Écrit par Marion Agé.

Smaïne Milianni nous a présenté comment mettre en place le ZDD (Zero Downtime Deployment) et les avantages de cette pratique. Il débute par la technique du blue-green deployment, qui constitue un premier pas vers le ZDD. Cette méthode consiste à déployer une version n+1 de l’application mais uniquement sur l’un des deux serveurs afin de s'assurer, dans des conditions réelles, de son bon fonctionnement, en redirigeant dessus une partie limitée du trafic. Quand le bon fonctionnement est validé, l’intégralité du trafic peut être basculée vers le serveur possédant la version n+1.. En plus d’améliorer la fiabilité des déploiements,  cette méthode permet de revenir facilement à l'ancienne version si nécessaire.

Smaïne a ensuite expliqué que le ZDD permet des déploiements sans downtime, à tout moment, qu’il facilite les rollbacks et qu’il évite les migrations nocturnes. Deux règles fondamentales sont mises en avant : les modifications doivent être compatibles avec le passé, et elles doivent être déployées progressivement. Cela évite les plantages en production et réduit le besoin de maintenance pour corriger les erreurs.

Il a illustré l'utilisation du ZDD avec des exemples concrets, tels que les modifications de schéma de base de données, l’ajout de contraintes not null, les ajustements liés aux message brokers comme RabbitMQ, ou encore des modifications d’API. Smaïne a ensuite présenté plusieurs outils pour détecter les éléments non compatibles avec le ZDD, tels que Yousign/safe-migrations et Yousign/zdd-message-bundle.

Enfin, il a terminé en évoquant les limitations du ZDD, précisant qu'il est utile uniquement pour des mises à jour fréquentes, tandis que les changements critiques nécessitent toujours une période de maintenance. Il a conclu en partageant des conseils pour implémenter le ZDD au sein des équipes : sensibiliser les collègues, désigner un référent ZDD et créer une documentation enrichie de retours d'expérience.

Écrit par Vincent Amstoutz.

Chez Les-Tilleuls.coop, nous utilisons souvent WordPress lorsque nous avons besoin d’un CMS (mais également Drupal lorsque le besoin s’en fait sentir). Notre propre site est d’ailleurs basé sur WordPress (en mode headless), nous n’allions donc pas rater l’unique talk du Forum sur le sujet, d’autant plus que ces derniers temps, WordPress défraie la chronique !

Cyrille Coquard, développeur spécialiste de WordPress, commence par nous rappeler que le CMS propulse près de 44% de l’ensemble des sites web, ce qui en fait le CMS le plus utilisé au monde. Cyrille nous a ensuite retracé l’historique du projet ces 21 dernières années et présenté dans les grandes lignes l’architecture de WordPress. L’outil est conçu pour être très facile d’utilisation, son administration avancée, permet aux utilisateurs finaux de créer leurs sites et de construire leurs pages en quasi totale autonomie.

L’interface de l’outil est intuitive, encore plus depuis l’introduction du constructeur de page Gutenberg. Son écosystème est gigantesque : les plugins et les thèmes sont légion. L’intervention d’un développeur est rarement nécessaire : quand le client final n’a pas le temps ou n’est pas capable de créer lui-même son site, un chef de projet avec éventuellement le renfort d’un intégrateur HTML suffisent généralement. Quand ce n’est pas le cas, il faut créer un thème (personnalisation des éléments visuels du site), ou encore plus puissant, un plugin.

Grâce au puissant système d’évènement fourni par WordPress, les plugins permettent de surcharger, d’étendre ou de spécialiser l’ensemble des composants du CMS. Cyrille a d’abord créé un petit plugin pour montrer comment cela fonctionne. Il a ensuite présenté quelques recommandations et outils pour créer des plugins en phase avec les bonnes pratiques de développement en PHP : utilisation de Composer grâce à Mozart, utilisation de l’injection de dépendance…

Cyrille nous a finalement présenté son projet nommé Launchpad, un framework inspiré de Laravel pour développer des plugins WordPress et qui reprend les bonnes pratiques présentées lors de ce talk.

De notre côté, nous utilisons acorn, qui permet d’utiliser facilement les composants Laravel (Illuminate) dans les projets WordPress, mais nous suivrons avec attention l’évolution de Launchpad qui pourrait bien devenir une bonne alternative !

Écrit par Kévin Dunglas.

À partir de l’exemple d’un projet gérant des systèmes virtuels, Alexandre Daubois (qui parlait aussi le jeudi 10) nous a présenté les problématiques de base posées par l’héritage et le typage strict. En PHP, on a le droit d’élargir le type d’argument mais pas de le réduire. Par contre, pour le typage de retour, c’est l’inverse !

Les principes SOLID recommandent d’appliquer le principe d’inversion de dépendance (e.g. typer sur une abstraction plutôt qu’une implémentation), et le principe de substitution de Liskov. Ces principes sont essentiels pour définir la covariance : “ensemble dans le même sens”. Il n’est pas possible de définir des types de retour différents pouvant enfreindre cette définition. Concernant les types de paramètre, ils peuvent au contraire être élargis. C’est le principe de contravariance : “dans des directions opposées”. Respecter le principe de substitution de Liskov est la garantie d’implémentation de covariance et contravariance.

PHPStan intègre la notion de generics, permettant de documenter les implémentations de covariance et contravariance.

Dans un tout autre registre, Alexandre nous a rappelé que PHP ne supporte pas l’héritage multiple, il nous a ainsi invité à imaginer un monde où cela serait possible… c’est le problème du Diamant ! Si une classe PHP pouvait hériter de plusieurs parents implémentant une même méthode, laquelle devrait être choisie dans la classe enfant ? Alexandra a terminé sa conférence en mentionnant que  les traits sont une “alternative” à cette problématique en PHP, mais qu’ils apportent également leur lot de problèmes.

Écrit par Vincent Chalamon.

Le Forum PHP a été un excellent cru, tant au niveau de l'organisation toujours impeccable (on apprécie fortement le buffet devenu presque végétarien et les fontaines à eau à disposition) que de la programmation, qui s'est avérée beaucoup plus technique cette année, après une édition précédente légèrement plus axée sur des sujets transverses. Nous avons hâte d'avoir accès aux replays des conférences auxquelles nous n'avons pas pu assister, ainsi que d'assister au Forum PHP 2025, qui marquera les 30 ans de PHP et les 25 ans de l'AFUP. Encore bravo à Amélie Defrennes, la directrice opérationnelle de l'AFUP, qui coordonne d'une main de maître cet événement de grande envergure, entourée d'une quinzaine de bénévoles tous autant accueillants les uns que les autres. À l'année prochaine !