SymfonyCon 2023 : notre retour sur les talks (partie 1)

Après le succès de sa précédente édition, Symfony organisait les 7 et 8 décembre dernier sa conférence internationale annuelle, la SymfonyCon. Plus de 1200 personnes se sont données rendez-vous au Square Conference Center de Bruxelles pour assister à une quarantaine de talks inédits donnés par des speakers venant du monde entier. Découvrez à travers cet article les conférences qui nous ont marqués.

La SymfonyCon a commencé par la Keynote de Fabien Potencier qui a présenté l'un des prochains composants, Terminal, et dont le développement devrait s'étaler sur plusieurs années et être terminé pour la version 8.0 de Symfony. 

Le créateur de Symfony revient sur l'histoire du composant Console, le plus vieux composant du framework (et le plus utilisé de tous) qui n’a pas changé tant que ça depuis Symfony 2.0 (sortie en 2011).

Symfony Terminal, la refonte de Symfony Console, propose un véritable framework haut niveau pour construire des applications interactives s'exécutant dans un terminal. Il rend possible de créer très facilement des applications similaires à ce qu’il est possible de faire avec Ncurses : fenêtres modales, boîtes de dialogue, barres de défilement, blocs de texte, tableaux, boutons, couleurs…

L'approche se veut similaire aux possibilités existantes en HTML et CSS, inspirée par Bootstrap ou encore Tailwind CSS et utilisant des emprunts à Python notamment pour la gestion des bordures. La présentation se termine par une démonstration en direct des possibilités de ce nouveau composant avec un tableau de résultats équivalent à ce qu’on peut retrouver habituellement dans un back-office d’administration : du tri par colonne, de la prévisualisation de détails dans un panel latéral et le support du scroll avec le trackpad.

Stefan Koopmanschap, qui était présent également à l’API Platform Conference 2023, nous a introduit à la conception orientée par le métier (DDD). Premier avertissement, nous allons discuter de conception et non de développement logiciel, aucune ligne de code ne sera présentée. Deuxième avertissement, il peut être plus important de comprendre quelles sont les limites de cette approche, afin de l’utiliser partiellement ou de ne pas l’utiliser. En fil rouge, la déclinaison de la théorie avec la conception d’un site e-commerce. 

Il aborde d’abord la nécessité d’utiliser des termes communs entre les différents acteurs d’un projet, concept appelé Ubiquitous Language. Stefan revient ensuite sur la définition du Domain en tant que tel, la nécessité de créer des Bounded Contexts, quand les objets peuvent avoir différentes significations suivant le contexte métier : un Payment peut avoir un sens différent dans des contextes différents. Il continue la conceptualisation avec la présentation de l’Event Storming et de la Context Map, puisse rapproche plus près des objets avec les notions d’Aggregrate : une collection d’objets du métier qui ne pourraient pas exister indépendamment. L’exemple se poursuit avec les lignes de commande et le paiement qui ne peuvent pas exister en dehors d’une commande, et le passage en revue des Value Object.

Dernier avertissement et non des moindres, il faut expérimenter la méthode mais certainement pas en commençant par le projet d’un client. En conclusion, la conférence est une bonne entrée en matière pour celui ou celle qui voudrait comprendre l’approche orientée métier, un ensemble de ressources est disponible : https://stefankoopmanschap.com/ddd/.  

Thomas di Luccio a dévoilé la dernière version de Blackfire avec un tour d’horizon du profiler, ce qu’il est possible de faire avec et comment aller plus loin dans son utilisation.

En plus d’être une référence dans la correction de problèmes de performances ou de bugs, Blackfire offre des outils pour agir de manière proactive qui s’intègrent facilement dans le cycle de vie d’un développement et permettent d’améliorer le code au fil de l’eau, avant d’être dans l’urgence.

La mise en place de tests de performance, possiblement automatisés pour être intégrés dans la pipeline CI/CD, permet notamment de mettre en place des attendus sur des parties de l’application ou sur des scénarios critiques. Des tests sur le temps de réponse ou la mémoire bien sûr, mais pas seulement. Thomas attire notre attention sur l’importance d’écrire des tests sur les causes plutôt que les conséquences, en définissant par exemple des limites sur le nombre attendu de requêtes SQL, le nombre de création d’entités ou le calcul des changements.

Autant d’assertions qui permettent d’éviter les problèmes en amont. Blackfire continue d’évoluer et en 2024 viendra le support du continuous profiling dans d’autres langages, dont Go, JavaScript, Python… affaire à suivre !

Tugdual Saunier, qui après avoir rappelé à quels besoins répondent les applications multi-tenant, nous a présenté plusieurs approches pour créer des applications :  

Toutes les approches proposées jusque-là se divisent en deux catégories et induisent donc une complexité sur le code ou son déploiement. Tugdual continue sa présentation avec deux alternatives visant à résoudre les problèmes rencontrés par les approches précédentes :

Tout en rappelant les raisons pour lesquelles nous pouvons être amenés à créer des applications multi-tenant, Tugdual conclue avec des recommandations sur le choix des approches et des recommandations d’implémentation. 

Rémi Janot nous a parlé du composant ExpressionLanguage de Symfony. Le problème est d’abord posé, celui de la création d’utilisateurs et plus précisément, la variation des informations demandées suivant la qualification. Trois approches sont alors proposées pour répondre à cette problématique.

La première consiste à établir la liste de toutes les combinaisons possibles, le formulaire proposé à l’utilisateur provient donc une association entre des informations présentes en base de données et des morceaux de requêtes SQL pour récupérer ces dernières. Cette solution, sûrement la plus directe et naïve, pose cependant plusieurs problèmes, car elle impose un couplage important entre l’ajout de nouvelles règles et la base de code. Autre point à noter, cette implémentation induit inévitablement la création d’une requête complexe.

La seconde solution consiste à stocker directement en base de données la logique métier sous forme de code PHP. Même si cette solution répond à une partie des problèmes de la précédente, le recours à un développeur semble inévitable. Autre point rédhibitoire, le code sera exécuté en utilisant la méthode eval avec tous les problèmes de sécurité connus.

Dernière solution, celle qui passe par le composant ExpressionLanguage de Symfony. Après une brève présentation des utilisations à travers le framework (paramètres, attribut, workflow…), on passe à la déclinaison sur le cas présenté. En résumé, cela offre la même flexibilité que la précédente solution mais les désavantages en moins. On utilise l’évaluation du composant qui comporte donc moins de risques de sécurité. Des fonctions spécifiques peuvent être ajoutées pour étendre les possibilités offertes avec plus de facilité d’utilisation. Même si cela reste du pseudo-code PHP, les règles sont écrites sous forme de conditions logiques. Plus besoin d’un développeur pour modifier des règles existantes, à l’instar de ce qu’on peut obtenir avec Gherkin pour l’écriture de tests fonctionnels.

Sebastian Bergmann, créateur de PHPUnit, commence son talk par un passage en revue de la documentation du composant PHPUnit Bridge présent dans Symfony. On peut retenir notamment que certains des problèmes évoqués dans la documentation justifiant la présence du composant, ne sont plus existants dans les versions les plus récentes de PHPUnit. On notera également qu’utiliser le PHAR plutôt que Composer est la meilleure option pour résoudre les problèmes de dépendances. Enfin, les dépréciations du framework sont disponibles grâce au Bridge et c’est une bonne chose.

Il enchaîne avec des informations relatives à PHPUnit. La parallélisation des tests n’est pas (encore) disponible nativement pour l’instant, on peut utiliser ParaTest ou Paraunit pour paralléliser les tests. PHPUnit 10 a pris du retard pour de multiples raisons parmi lesquelles le Covid, la migration sur PHP 8, mais aussi la maintenance des anciennes versions. Parmi les avancées présentées, on peut retenir le passage des annotations en attributs PHP, qui sont bien plus résilients car moins permissifs que des commentaires. La documentation a été complètement ré-écrite.

On termine avec une partie nommée Issue Handling, derrière ce terme, le fonctionnement interne de PHPUnit par rapport à la gestion des messages de log définies par les développeurs ou les frameworks. Plus précisément, le changement majeur introduit dans la version 10 qui ne traite plus les dépréciations en tant qu’erreur et qui a pris bien plus de temps que prévu à sortir. Le changement a eu plus d’impact que prévu et a nécessité plusieurs versions mineures pour aboutir.

Autre point à retenir, la prochaine version de PHPUnit sortira le 2 février 2024. Sebastian Bergmann a conclut sa conférence en évoquant le financement de la PHP Foundation.

Marion Hurteau, développeuse chez JoliCode, est revenue sur les débuts de l’utilisation des strings dans les applications et plus particulièrement en PHP, ainsi que sur l’évolution des normes depuis l’ASCII dans les années 1960 jusqu’à la dernière version d’UTF8 v15 en 2013.

Sorti avec la version 5.0 de Symfony, le composant String offre une approche orientée objet pour manipuler les chaînes de caractères avec des méthodes utiles pour tout un tas d’usages : concaténation, découpage de chaînes, vérification d’encodage, remplacement, changement de casse, etc.

Marion a fait un petit tour d’horizon de ce que le composant nous permet de faire en toute simplicité, en passant par la normalisation de chaînes ou encore la gestion des singuliers/pluriels grâce à Inflector, sans oublier bien sûr la transformation d’emojis !

Salle comble pour notre CTO Kévin Dunglas, qui nous a montré comment créer un binaire autonome permettant d’exécuter une application Symfony, comme on peut le faire en Go ou en C par exemple. Pour cela, il s’appuie notamment sur FrankenPHP, dont il publie la version 1.0 stable sur scène, sous les applaudissements du public !

Kévin commence par rappeler les étapes et dépendances que nécessite le déploiement d’une application PHP de manière habituelle : mise en place d’un serveur web, d’un exécuteur PHP, des extensions PHP, du code source, des dépendances tierces (vendors), etc.

L’interpréteur PHP, nécessaire pour exécuter le code, utilise habituellement des bibliothèques C chargées de manière dynamique au runtime. Mais ici on cherche à compiler un binaire autonome “tout compris”, ce qui nécessite d’embarquer en statique les bibliothèques et les dépendances : le serveur Caddy, PHP et ses dépendances, FrankenPHP, le code source, les assets, les dépendances de l’application…

C’est grâce au langage Go, utilisé notamment par le serveur web Caddy et FrankenPHP, et par la lib static-php-cli qui compile PHP de façon statique avec la plupart de ses extensions et de ses dépendances, que cela se joue. Kévin fait ainsi une démonstration en compilant une application Symfony pour obtenir un fichier binaire, qu’il lance ensuite sur sa machine : mission accomplie ! Binaire compilé qu’il ne manquera pas de partager aussitôt avec un certain Fabien Potencier en vue de la session de Q&A prévue en fin de journée…

Nous espérons que ce premier retour de la SymfonyCon vous plaît. Rendez-vous demain pour la suite !