Forum PHP 2019 : Jour 1

Les Jeudi 24 et Vendredi 25 Octobre dernier se tenait à Paris le Forum PHP, organisé par l’AFUP (Association Française des Utilisateurs de PHP).

Vous trouverez ci-dessous un compte rendu de plusieurs conférences données le 24 octobre.

Le compte rendu par Sébastien des conférences données le 25 octobre est disponible ici. On y parle de Panther, de PHP 7.4, de Symfony HTTPClient et de Symfony Checker.

Le Forum PHP, qu’est-ce que c’est ?

C’est “[l]e grand rendez-vous pour toute la communauté PHP !” selon l’AFUP : s’étendant sur 2 jours, il réunit une trentaine de conférenciers pour 700 participants.

Le forum s’est déroulé au Centre Conférencier à l’Hôtel Mariott Rive Gauche, qui pour l’événement avait aménagé le rez-de-chaussée de sorte qu’il y ait 2 salles : la salle Katherine Johnson, la plus spacieuse, permettait à l’ensemble des participants de la journée de s’asseoir, et était destinée aux conférences susceptibles d’attirer le plus de monde. La salle Grace Hopper à l’inverse, était deux fois plus petite, et accueillait les conférences avec un auditoire plus modeste, notamment les présentations en anglais.

Il y avait donc 15 conférences par jour. Cependant, à chaque créneau, deux conférences se déroulaient en même temps, une dans chaque salle, et une conférence unique venait clôturer la journée. Il était donc possible pour un participant de n’assister qu’à 8 conférences au maximum.

Précédant chaque demi-journée, une très courte présentation de chaque speaker permettait de finaliser son choix, ou de renforcer un dilemme cornélien.

Enfin, l’une des nouveautés de l’édition était la retranscription live de la parole des speakers sur un écran situé près de la scène, destiné aux sourds, malentendants, et éventuellement au personnes nécessitant une aide pour les conférences en anglais.

Conférences du 24 Octobre

Writing effective PHP

Pour la première conférence en anglais, Nuno MADURO nous explique que son code “efficace” peut se résumer en 3 mots : sûr, robuste et maintenable. Nuno commence par affirmer qu’il faut coder défensivement, c’est à dire toujours présumer le pire : chaque ligne de code est une responsabilité. Ainsi il nous conseille quelques pratiques pour garder un code sain :

1. Garder le state immuable : là où c’est plus aisé d’y parvenir dans d’autre langage comme le java par exemple, il est nécessaire d’y prêter attention en PHP (ou en Python). Pour cela, Nuno donne la consigne suivante : le Constructeur doit être le seul point d’entrée. Pas de setters, tous les attributs et le state sont privés.
2. Toujours utiliser des assertions : le “dumb proofing” est le maître mot ici. Que ce soit dans un formulaire ou dans une classe, il est nécessaire de s’assurer que la valeur d’entrée est conforme aux exigences. Le speaker préconise l’utilisation de helpers (classes d’outils utilisable partout dans une application) et de package/plugins.
3. Faire des contrats d’API solides : établir une documentation exhaustive pour les services : ce qu’ils sont, ce qu’ils font, ce qu’ils renvoient, quels sont leur comportement en fonctionnement nominal et en cas d’erreur.
4. Rendre les classes finales par défaut : “Composition over inheritance” : utiliser moins — voire plus du tout — l’héritage mais y privilégier la composition (agrégation entre deux classes)
5. Produire des tests qualitatifs
6. Utiliser des outils d’analyse statique de code, comme PHPStan ou PHP Insight — dont Nuno est l’auteur — : L’analyse statique c’est tout simplement l’analyse du code sans nécessiter son exécution. Les outils peuvent identifier des failles de sécurité, vérifier la complexité cyclomatique, ou plus simplement trouver des erreurs dans le code, parmi tant d’autres.

Enfin, Nuno conclue en citant l’expérience comme un atout majeur pour un code “efficace” : savoir choisir les bonnes pratiques et les bons outils, connaître les pièges à éviter, etc…

Une application résiliente dans un monde partiellement dégradé

Pascal MARTIN, le speaker, commence par une anecdote dans laquelle le client montre son mécontentement quand on lui indique qu’il n’est “pas possible” de lui garantir que l’application fonctionnera toujours.

Retour aux bases, et voyons les X-nines : les X-nines indiquent la disponibilité d’une application, d’un service ou d’une plateforme. Par exemple une disponibilité de 3-nines est donc de 99.9%. Oui mais 99.9% de quoi ? C’est là que ça se complique.

Comme Pascal le dit, c’est variable : ça peut être que le service est opérationnel 99.9% du temps, que 99.9% de requêtes réussissent, ou encore que 99.9% de requêtes répondent en moins de X millisecondes. Après plusieurs exemples pertinents, le conférencier enchaîne sur les micro-services.

Imaginons une page web qui appelle une et une seule API. Si cette API a 4-nines de disponibilité, alors la page web a elle même 4-nines de disponibilité.

Disons maintenant que cette page dépend de 2 API qui chacune a 4-nines de disponibilité.

La disponibilité de la page est maintenant de : 99.99*99.99 = 99.98%, ce qui n’est plus que 3-nines !

Pascal continue ainsi en complexifiant les schémas avec 4 API, dont certaines sont interdépendantes. Il ajoute que quelques API dépendent de bases de données, d’elastic search ou de serveurs redis. En allant même plus loin, chaque requête se fait via un nom de domaine et donc utilise un service DNS, faillible. S’ajoute à tout cela l’hardware, qui est lui aussi sujet à de potentielles pannes. Pascal montre ainsi la complexité monumentale du calcul de disponibilité.

Il appuie ses propos en citant la disponibilité d’un des services d’amazon, RDS, le système de base de données relationnelle, qui n’affiche “que” 99.95%.

Pascal explique par la suite la notion de “Blast Radius”. Le rayon d’explosion d’un service est l’impact qu’il a sur les autres service autour de lui. Plus petit le blast radius est, moins son dysfonctionnement impactera le reste.

Sont ensuite introduites 3 notions, toutes trois intimement liées :

SLI - Service Level Indicator : une mesure qualitative d’un aspect du niveau de service, soit une mesure de performance (latence, taux d’erreurs, débit, disponibilité, durabilité)

SLO - Service Level Objective : avec les indicateurs, il est possibles de fixer des objectifs : une valeur cible pour un niveau de service mesuré par un SLI. Exemple : < 25 ms pour répondre à ce type de requête, < 0,01 % des requêtes échouent, etc…

SLA - Service Level Agreement : c’est un contrat avec le client, il spécifie les conséquences si les SLOs ne sont pas atteints

Petit exemple des trois

Après avoir expliqué tout ceci, Pascal arrive au coeur de sa présentation avec la partie “Améliorer la résilience”

Il commence par stipuler qu’améliorer la résilience c’est avant tout être prévoyant, et qu’être prévoyant, c’est ne pas improviser.

Puis, il explique la différence entre de vrais micro-services et des faux : de vrais micro-services restent opérationnels malgré un service interne défectueux, notamment grâce à une transmission de données interne asynchrone.

Le speaker enchaîne ensuite sur les “Fallbacks” : lorsque le dynamisme d’une page n’est plus possible, il faut penser à fournir une version statique, de la donnée par défaut; ou encore à réutiliser une donnée du cache, même s’il est expiré.

Cela le fait donc arriver à la notion de “Mode dégradé” : une page web est constituée de blocs (carrousel, info, publicité,…) et, si une erreur survient sur un des ces blocs, on l’enlève, au lieu de planter toute la page, quitte à n’afficher que du contenu textuel. Mieux vaut ça qu’une page d’erreur.

Vient ensuite le “Circuit Breaker”, un design pattern qui consiste à couper, ou tout du moins réduire, l’accès à un service dans le cas où celui-ci rencontre des difficultés de fonctionnement.

Par exemple, si la BDD est surchargée, le système refusera purement et simplement 10% des requêtes. Et 10% d’insatisfaits vaut mieux que 100%.

Pascal continue de plus belle avec la redondance. Bien connue dans le domaine des systèmes embarqués, la redondance, en informatique, consiste tout bonnement à dupliquer la BDD. En cas de panne de la BDD principale, la suppléante prend le relais.

Enfin il mentionne le “Chaos engineering”, qui est un état d’esprit où l’on prévoit que tout peut et va casser. La logique est simple, plus les pannes sont fréquentes, mieux elles sont tolérées. Ce qui mène donc à “Chaos Monkey”, un outil créé par Netflix dont le rôle est de tuer des machines virtuelles ou des conteneurs aléatoirement. Sensations garanties nous assure Pascal.

Vers la fin de la conférence, le speaker donne quelques consignes dans le cas d’un incident en prod, en nous rappelant qu’il faut communiquer, ne pas paniquer, prendre soin de soi-même — en dormant suffisamment — et qu’une fois le problème résolu, il est fort utile de faire un rapport post-mortem.

Enfin, Pascal conclut sa conférence en nous disant que c’est à nous de trouver le juste milieu entre le besoin de résilience et l’effort à fournir.

Concevoir des applications PHP résilientes en 2019

Dans le même thème que la présentation précédente, celle-ci en différait par son côté plus technique ainsi que par une durée plus courte.

Le speaker, Mickaël ANDRIEU, est développeur chez PrestaShop, et après une brève introduction de l’entreprise, il nous parle directement d’un problème auquel ils ont fait face, qui empêchait l’accès au back-office côté utilisateur. Les conséquences ? Perte d’image et de confiance, perte d’argent et difficultés à résoudre le problème de façon pérenne.

Le terme résilience apparaît alors, cette fois avec une définition plus concrète : La résilience d’une application est sa capacité à résister à une altération de son environnement.

Mickaël donne alors deux conseils :

• améliorer son infrastructure, en la déléguant à des services tiers, comme Google Cloud Platform, utiliser des CDN, et même des outils de reverse proxy et load balancing comme Traefik.
• améliorer son code avec de la gestion de timeout, du code non bloquant, et du fallback

Il s’ensuivit une explication plus poussée du “Circuit Breaker” vu précédemment, notamment avec une analogie entre le design pattern et l’action de frapper à une porte :

• la personne ouvre : le service est disponible, le “Circuit Breaker” est fermé, il laisse passer les requêtes
• la personne n’ouvre pas : le service est indisponible, le circuit est ouvert, il intercepte les requêtes, et retourne une réponse définie, un service dégradé.
• après un certain temps, on frappe de nouveau : le “Circuit Breaker” est semi-ouvert ou semi-fermé, il laisse passer une requête sur le service, si elle réussit, le circuit se referme, si elle échoue, le circuit se réouvre.

Schéma fonctionnel du “Circuit Breaker”

Pour finir sa conférence Mickaël a présenté un petit comparatif entre trois librairies disponibles pour implémenter un circuit breaker : PrestaShop Circuit Breaker, Resiliency et Ganesha.

When you get lost in API testing

Deuxième conférence en anglais de la journée, elle était présentée par Paula ČUČUK et Antonio PERIC-MAŽAR, respectivement développeuse et CEO chez Locastic, une agence digitale croate.

La présentation portait sur les tests. L’ensemble des tests, à savoir les tests unitaires, les tests d’intégration et les tests fonctionnels. Là où les tests unitaires agissent sur une échelle infinitésimale, les tests d’intégration et les tests fonctionnels apportent une certaine macroscopie.

Les tests unitaires, comme leur nom l’indique, viennent tester une unité dans le code. Une unité est la plus petite partie testable d’une application. Cependant, d’après les speakers, ce n’est pas suffisant pour garantir le bon fonctionnement. Ainsi prônent-ils l’utilisation de tests d’intégration d’une part, qui testent les interactions entre les “modules” de l’application, testés par groupe, et d’autre part les tests fonctionnels qui logiquement sont destinés à la fonctionnalité complète de l’application.

Les tests d’intégration vérifient l’intégration des services tiers ou les requêtes vers la BDD par exemple. Les tests fonctionnels, quant à eux, et dans le cas d’une API par exemple, vont affecter la vérification des requêtes et de leur réponse.

Un puzzle a été choisi pour une analogie.

Les test unitaires concerne une pièce unique : s’assurer que c’est une image, qu’elle est en forme de puzzle, qu’elle peut être bougée et qu’elle peut être emboîtée.

Pour les tests d’intégration, cela concerne deux pièces : il faut s’assurer que les deux pièces s’emboîtent correctement et que les images s’accordent.

Enfin, les tests fonctionnels permettent de s’assurer que toutes les pièces ont leur place et que l’image finale est bien celle attendue.

Paula et Antonio ont ensuite expliqué ce qu’ils ont tiré de l’implémentation de tous ces tests et ont cité quelques outils comme Infection, qui est un framework PHP de tests par mutation, c’est-à-dire qu’il modifie le programme légèrement à certains endroits et analyse la réponse de tests du projet, si les tests réussissent, c’est que le code n’est pas assez bien testé.

PHP Stan a été une fois de plus cité. On retient aussi PHP Matcher, qui vérifie les formats des champs des réponses d’API et Faker, qui génère de la fausse donnée aléatoirement, pour par exemple peupler une base de données. Sans oublier le fameux Postman.

Se prémunir contre l’imprévisible : une analyse des failles les plus courantes en PHP

Il est bien connu que le PHP est un des langages les plus exposés aux failles. Paul MOLIN revient ici sur une liste des plus marquantes, pas forcément liées au langage. Il parle entre autre de :

• Cross-Site Scripting (XSS) : l’injection de code HTML ou JavaScript, en utilisant par exemple le formulaire d’un site web
• Injection SQL : il s’agit une fois de plus d’introduire du code extérieur, dans une requête SQL cette fois.
• Remote Code Execution (RCE) : c’est une faille permettant à une personne extérieure au site d’exécuter du code directement sur le serveur, par exemple en utilisant l’upload de fichier du site qui ne serait pas suffisamment protégé.
• Denial of Service (DoS) : le déni de service consiste à “occuper” le serveur de telle sorte que son fonctionnement soit perturbé. Pour cela, à l’aide de requêtes, il faut lui demander de réaliser des tâches coûteuses (en stockage, RAM et/ou CPU), le plus de fois possible par seconde
• DrupalGeddon : une faille sur Drupal permettant, à l’aide du formulaire de connection, de pratiquer l’injection SQL.

Pour chaque exemple, Paul explique l’origine, ainsi que la méthode pour pallier la faille.

A propos des formulaires d’inscription, il ajoute un petit tip pour joindre l’utile à l’agréable : ne pas empêcher le copié-collé de mot de passe sur le formulaire d’inscription, car cela empêche la génération automatique de mot de passe du browser/gestionnaire de mot de passe.

Neuroatypie et IT

Alex ROCK vient nous parler des neuro-atypies et plus particulièrement de l’autisme. Étant lui même autiste, il nous explique que l’autisme, ce n’est pas comme dans le film Rain Man, mais c’est un trouble du développement qui entraîne des difficultés dans l’apprentissage social et de la communication.

Alex parle ensuite de quelques autistes — plus ou moins — connu(e)s :

• Alan Turing et sa machine Enigma
• Daniel Tammet, écrivain et poète anglais atteint du syndrome d’Asperger et du syndrome du savant
• Josef Schovanec, philosophe et écrivain français
• Kim Peek, un américain atteint du syndrome du savant ayant inspiré le personnage de Rain Man
• Greta Thunberg, l’environnementaliste suédoise atteinte du syndrome d’Asperger

Il continue ensuite sur les causes et conséquences de l’autisme. Les TOC, la synesthésie (par exemple l’association des couleurs avec les chiffres) ou encore une mémoire exceptionnelle font partie des phénomènes connus du public. Cependant ils ne représentent qu’une fraction de la vaste palette des troubles et pathologies chez les autistes.

Alex ensuite élargit le sujet en passant aux neuro-atypies, qui peuvent se manifester sous plusieurs formes : la maladie de Parkinson, la Schizophrénie, les troubles bipolaire, le syndrome Gilles de la Tourette, le TDAH (trouble de l’attention), les troubles dys* (dyslexie, dyscalculie,…), et bien sûr l’autisme, parmi tant d’autres.

Vient ainsi le sujet du recrutement des neuro-atypiques pour lequel Alex prodigue quelques recommandations: se renseigner sur les particularités de la personne, être clair et précis sur les process, donner des conditions de travail adaptées et le plus important, communiquer !

Pour venir conclure cette présentation, Alex annonce que ces conseils sont valables pour tout recrutement…peu importe la personne.

Concevoir pour des futurs souhaitables

La conférence était la dernière de la journée. Loin du sujet du PHP, ou même du développement, les deux speakers, Marie-Cécile GODWIN et Thomas DI LUCCIO venaient nous parler de l’impact de l’Anthropocène (l’ère de l’Homme) sur la planète. Pour cela, ils présentaient différents futurs de manière binaire : ouvert ou fermé.

Un futur fermé est un futur qui ne sera jamais atteignable. A l’inverse, un futur ouvert est possible.

La conférence était principalement constitué d’exemple de futurs (plutôt positifs) fermés, à cause des actions de l’Homme : pollution, surpopulation, les raisons sont multiples et d’après Marie-Cécile et Thomas il est bien trop tard pour ne serait-ce qu’espérer les envisager.

Seul le dernier futur présenté était ouvert, mais à quel prix ? La condition pour y parvenir est que l’Homme commence immédiatement à maîtriser son impact écologique, notamment en limitant fortement sa consommation.

Adieu veau, vache, cochon, couvée et futur optimiste, si l’Homme n’est pas voué à disparaître, sa survie se fera dans la modération du consommable.

Conclusion

Le forum PHP étant mon premier gros évènement dev, je me demandais quels allaient être les sujets des conférences. En effet, pour un langage récent, comme Kotlin par exemple, il est aisé de s’imaginer la multitude de sujets que les conférenciers peuvent aborder. Le PHP, apparu en 1995, a déjà vécu l’euphorie de la jeunesse. Et il se trouve, au final, qu’une certaine tendance est discernable dans les sujets, et vous, lecteurs, l’avez sûrement déjà remarqué. Peu de thèmes liés au coeur du fichier, mais plutôt portés sur la globalité d’un projet, sur son bien-être et son environnement. Les notions de Defensive Programming, tests et sureté, omniprésentes en cette première journée, restent abstraites, comparé à du code et à de la pratique pure et dure. On peut ajouté que les deux dernières conférences étaient complètement excentrées vis-à-vis du sujet du forum.

Je regrette donc un peu l’absence de contenu approfondi. Cependant je me rends bien compte qu’en 40 minutes, il peut être difficile d’entrer dans les spécificité du code, d’autant plus que le désir des participants n’est peut-être pas tourné vers le détail.

Sur une note plus positive, les conférenciers semblaient bien maîtriser leur sujet. J’ai beaucoup apprécié la première conférence sur la résilience, d’une part car je ne connaissais pas la thématique et d’autre part car le speaker était dynamique et motivé.