Une fois de plus Clever Age a eu l’occasion de participer au Forum PHP qui se déroulait pour la 3ème fois consécutive à Paris Marriott Rive Gauche Hotel les 24 et 25 octobre 2019.
Le programme de cette année était très riche en retours d’expérience !
Voici un compte-rendu de ce que nous avons pu voir :
Writing Effective PHP
par Nuno Maduro
Cette première conférence avait pour objectif de nous apprendre à construire du code plus robuste, plus défensif via des exemples concrets.
Dans les conseils nous avons pu noter :
- Pourquoi, quand et comment doit-on créer des classes immuables. ?
- Comment avoir des objets toujours dans un état valide avec des assertions ?
- Comment définir des APIs avec des contrats claires en typant de manière plus stricte les méthodes et en effectuant des commentaires décrivant leurs comportements ?
- Comment faire des classes “final” afin de forcer les développeurs à penser composition au lieu d’héritage ?
Enfin, Nuno a parlé d’outils d’analyses statiques avec en premier PHPStan et en second, PHP Insights dont il est lui même l’auteur. Le principal intérêt mis en avant était la rapidité de retour de ces outils qui ne nécessitent pas d’exécuter le code contrairement aux tests automatisés ou manuels. Cela permet donc de remonter des erreurs et métriques très rapidement et sans effort. PHP Insight permet de visualiser des métriques supplémentaires liées à la sécurité, aux conventions de codage, à la complexité cyclomatique, à l’architecture de l’application et au code de manière générale.
Nous avons particulièrement apprécié cette conférence qui nous a proposé des exemples de code en live très pratiques pour appuyer les arguments cités. Nous avons pu également découvrir PHP Insights que nous ne connaissions pas.
PHP Pragmatic Development
Conférence présentée par Frédéric Bouchery qui a expliqué ce qu’est le pragmatisme dans le développement, celui-ci permettant de favoriser l’expérience et la pratique.
Il a expliqué l’effet de Dunning-Kruger avec le niveau de confiance que peut avoir un junior débutant face à un senior ayant beaucoup de pratique dans le monde du dev.
Cet effet est dû à une surévaluation de la confiance par rapport à une compétence. En voici une courbe représentative :
Il a énoncé également des principes de développement tels que:
- KISS (“keep it simple, stupid”)
- DRY (“don’t repeat yourself”)
- WET (“write everything twice”)
- YAGNI (“you ain’t gonna need it”)
Dans la pratique, il a adopté une solution créée par lui même : la matrice de décision.
Il s’agit d’une adhésion collective à l’aide d’un tableau grâce à des scores pour choisir un outil à travers les différents choix possibles. Les participants mettent un score pour chaque technologie choisie selon des critères (par exemple, si l’outil est déjà connu par l’équipe ou non).
Je viens de mettre en ligne le support de ma conférence donné lors du #ForumPHP @afup sur le développement pragmatique.
N’oubliez pas de noter les conférences sur https://t.co/2Xiinqsxi4https://t.co/Wbcihr3LI2 pic.twitter.com/a0WAfsrD40— Frédéric Bouchery (@FredBouchery) October 28, 2019
La clean architecture : Pourquoi ? Comment ? Pour qui ?
par Nicolas De Boose
2ème talk de la journée et apparemment une première pour le speaker qui s’est en très bien sorti avec un sujet bien expliqué ! Nicolas a commencé avec un exemple fictif sur un projet en modèle MVC qui s’agrandit pour nous expliquer qu’on finit souvent par mettre le code là où ça fait le moins mal.
Nicolas est passé du Modèle MVC à une architecture dite “hexagonale” en utilisant :
- le principe de “ports” et “adapters” dont l’idée est que l’hexagone (le domain de l’application) définit des ports représentant des interfaces métier et que la partie infrastructure (à l’extérieur de l’hexagone) implémente ces interfaces par des “adapters”. Cela rejoint les principes SOLID et permet de ne plus dépendre des librairies externes dans toute l’application (seul l’”adapter” en dépendra)
- le pattern MVP (Model View Presenter) qui permet de simplifier la vue en utilisant une couche supplémentaire d’abstraction, le presenter. Il est là pour contenir les informations que l’on souhaite rendre à la view. Nous pouvons donc tester ses informations sans tester la façon dont elles sont rendues et sans se coupler directement à la view.
Redis, ce n’est pas que pour le cache
par Grégoire Pineau
Nous n’avons pas assisté à cette conférence au Forum car nous l’avions déjà vu a un SfPot et nous en avons gardé un très bon souvenir !
Grégoire y montre des fonctionnalités de Redis avec des exemples de cas d’utilisation réels dépassant la simple utilisation du cache.
Une vidéo de la même conférence donnée à Webmardi juste avant le forum PHP est disponible.
L’e-commerce sans accroc avec Sylius
Une application résiliente, dans un monde partiellement dégradé
par Pascal MARTIN
Une des conférences les plus intéressantes du Forum PHP à notre goût ! Pascal nous a donné certaines définitions, expliqué comment définir des métriques et proposé des conseils pour améliorer la résilience de nos applications.
La résilience est la capacité à s’adapter à des dysfonctionnements. Pour introduire ce concept, Pascal nous a parlé de SLI, SLO et SLA :
- Service Level Indicator : c’est une mesure qualitative pour un niveau de service sur la disponibilité, la durabilité, le taux d’erreur, le débit ou encore la latence. Par exemple on parle souvent de X-nines (99,99%, 99,9%…) sur le pourcentage de disponibilité d’un service;
- Service Level Objectif : valeur cible pour un niveau de service mesuré par un SLI;
- Service Level Agreement : définie les conséquences financières si l’objectif n’est pas atteint.
Pour la SLI, ce qui compte vraiment c’est la vision utilisateur et non la métrique technique. Un point d’attention a été évoqué sur les services externes possédant leurs propres SLIs :
- une application dépendante d’un service externe possédant elle même une SLI de disponibilité à 99,9% ne pourra pas dépasser cette SLI,
- une application dépendante de deux services externes possédant pour chacun d’entre eux une SLI à 99,9% ne pourra pas dépasser 99,8%
Au niveau des objectifs, il peut être difficile d’en choisir. On doit se demander quel effort on est prêt à fournir pour y répondre. Après la définition de ces objectifs on peut regarder le budget qui y est accordé pour en déduire des actions :
- si le niveau de service est supérieur au budget, on peut faire ce que l’on veut, tout casser et expérimenter
- si le niveau de service est inférieur à nos objectifs, on n’a plus le droit de tout casser, il faut arrêter les nouveaux développements et stabiliser l’application.
Les SLAs viennent en dernier et pourtant on en parle plus que des SLIs et SLOs, alors qu’ils dépendent bien de ces deux derniers.
Pascal Martin nous a ensuite listé un ensemble de conseils pour améliorer la résilience de nos applications :
- être préparé : ne pas improviser et agir de manière précipité en production. Travailler d’abord en staging, documenter et ensuite agir en prod ou encore mieux, automatiser la résolution du problème et déployer ;
- faire de vrais microservices notamment en limitant les dépendances présentent entre eux ;
- faire des fallbacks avec par exemple l’utilisation d’une version statique d’un site, des données par défaut côté client, ou encore la réutilisation de données en cache qui ont expiré ;
- utiliser un mode dégradé : si on n’arrive pas à afficher une liste de 10 articles on peut en afficher 9, ignorer un 4ème article et commander les autres si on n’arrive pas à afficher ses informations ;
- scaler en fonction de la durée des requêtes (et pas du CPU) ;
- faire du feature flipping (désactiver des fonctionnalités automatiquement lorsque le site est surchargé) ;
- être prudent lors des déploiements : déployer une nouvelle application à 5% des utilisateurs et non à 100% ;
- si la bdd s’écroule, basculer sur un réplica ;
- faire du Chaos Engineering avec par exemple Chaos Monkey en simulant des pannes ;
- choisir des technologies anciennes “boring” parce que, au moins, vous aurez du support en cas de problème, à l’inverse de la dernière technologie hype du moment avec laquelle personne n’a encore rencontré le bug en question ;
- une fois l’incident terminé, c’est le moment d’apprendre : faire une timeline, ce qui a marché ou non, définir des actions d’amélioration.
Concevoir des applications PHP résilientes en 2019
par Mickaël Andrieu
Dans la même lignée que la conférence précédente, Mickaël Andrieu nous parle de résilience mais avec cette fois-ci un retour d’expérience sur Prestashop où un fichier css externe empêchait l’ensemble des back-office de prestashop de charger.
Mickaël, nous a également énoncé quelques conseils, puis il s’est focalisé sur le design pattern Circuit Breaker encore peu répandu dans l’univers PHP. L’idée du circuit breaker est de prendre le relais lorsqu’un problème survient afin de fournir une réponse dégradée au lieu d’une interruption de service. Un circuit breaker est une machine à état :
- fermé : le circuit breaker laisse passer les requêtes ;
- ouvert : le service tiers va se fermer, le circuit breaker s’ouvre et l’on va maîtriser et avoir le contrôle sur le comportement souhaité ;
- semi-ouvert : permettant d’effectuer des tests sur le service tiers afin de vérifier s’il est de nouveau accessible.
A la suite de la présentation du concept, Mickaël a effectué une comparaison des 3 librairies disponibles en PHP :
- Prestashop Circuit Breaker : librairie utilisée par Prestashop
- Resiliency fork du Circuit Breaker de Prestashop avec des tests d’implémentation sur des fonctionnalités dont prestashop n’a pas besoin, fait par le conférencier
- Ganesha : la plus ancienne présente depuis 2014
Accueillir des junior·e·s en reconversion : comment éviter l’échec
Prénommée Cindy Liwenge, elle a pris la parole en tant que développeuse junior en reconversion pour montrer les difficultés auxquelles un(e) dev junior peut être confronté(e) dans sa réorientation.
Elle a mis en évidence les principales qualités qu’un dev débutant peut apporter à une entreprise.
Mercure, et PHP s’enamoure enfin du temps réel
Kévin Dunglas a initié la conférence en effectuant une comparaison de Mercure avec WebSocket et SSE (Server-Sent Events) afin de nous expliquer l’intérêt de ce nouveau protocole qui permet de faire du temps réel.
Dans les distinctions, on peut retrouver notamment le fait que :
- Mercure tire parti des nouveautés d’HTTP/2 et HTTP/3 à l’inverse du protocole SSE qui devient obsolète à cause de ces mêmes nouveautés,
- il est “full-duplex” avec une communication dans les deux sens,
- il ne maintient pas de connexion persistante ce qui lui permet d’être facilement utilisable avec des APIs
Bien que le protocole soit encore en statut “Draft”, Kévin nous a démontré avec l’aide d’Eric Comellas qu’il pouvait dès à présent être utilisé en production et répondre à de vrais besoins de temps réel avec un retour d’expérience pour Igraal.
PHP 8 et Just In Time Compilation
Le langage PHP a toujours été critiqué par d’autres langages (C, JAVA…) à cause de sa lenteur liée au temps d’interprétation et d’exécution. C’est pourquoi, Benoît Jacquemont a voulu mettre en avant les avantages de l’utilisation de PHP et JIT (Just In Time) lors de cette conférence.
JIT : est une technique visant à améliorer la performance de systèmes bytecode-compilés par la traduction de bytecode en code machine natif au moment de l’exécution. La compilation à la volée se fonde sur deux anciennes idées : la compilation de bytecode et la compilation dynamique.
Afin de démontrer que le JIT permettra un gain de performance avec la version 8 de PHP, le conférencier a mis en avant les tentatives échouées de l’utilisation du JIT ces dernières années sur les versions 7 et 5 de PHP.
Le premier échec a été constaté sur la version PhP5, en 2014, quand Andrei Zmievski a constaté diverses lenteurs. Il pensait que la solution se trouvait avec l’implémentation de JIT, mais il s’agissait d’un problème lié au Zval. Après avoir réécrit l’ensemble de l’interprétation, les performances de PHP5 étaient meilleures mais l’ajout de JIT n’y a absolument rien changé.
Ensuite, avec la version 7 de PHP, les performances natives ont été largement améliorées et l’utilisation de JIT dépend vraiment du projet. Certains tests montrent que JIT n’est pas nécessaire et dans d’autres cas oui.
Sur le schéma ci-dessous, on peut voir que l’installation d’Akeneo PIM EE est plus rapide de 3 secondes sans JIT.
