Retour sur le Symfony Live Paris 2018

Il y a quelques jours, une partie de notre équipe a assisté à la dixième édition du Symfony Live Paris, l’événement incontournable de la communauté Symfony. Plus de 800 personnes se sont rendues à cette convention et cette année, non seulement nous étions exposants en tant que Sponsor Gold, mais aussi 3 de nos coopérateurs sont intervenus sur scène ! Passons en revue les moments phares de ces deux jours de conférences.

Fabien Potencier nous a fait une nouvelle présentation de Symfony 4, sorti en novembre dernier.

Comme annoncé depuis un moment, Symfony 4, c’est : Symfony 3.4 - les fonctionnalités dépréciées et le support de PHP 7. Fabien est également revenu sur le plugin Flex. Avec Flex, on assiste à un changement de paradigme complet : on découpe les librairies du dépôt symfony/symfony et on induit une dépendance avec une librairie de Symfony uniquement si on en a besoin. Ça fonctionne avec Composer et un système de recettes.

Fabien profite de cette keynote pour mettre en avant également le maker-bundle, un remplaçant du generator-bundle des versions précédentes. Pour rappel, c'est un outil qui vous “pré-mâche” le travail de création des "morceaux de code" dont vous aurez besoin pour créer votre application. Un réel gain de temps !

Parmi les autres annonces faites lors de cette keynote :

La conférence de Marc Weistroff présentait l’architecture modulaire à travers son projet AudienceHero.

Il nous a d’abord expliqué la démarche intellectuelle ainsi que les diverses expériences qui l’ont mené à créer ce système : freelance, création du label musical POLAAR, création de la SaaS Mopro. Avec ce dernier, il créée un ensemble de fonctionnalités pour qu’un groupe de musique puisse facilement gérer sa communication.

Faisant le bilan de ce projet, il se rend compte qu’il possède de nombreux problèmes ou plutôt des valeurs en désaccord avec ses principes : c’est un système centralisé, le code est propriétaire et il a été seul à le développer. Il commence ainsi la présentation de AudienceHero, à savoir une transformation de Mopro vers un système open source, basé sur une API, modulaire et décentralisé. S’intéressant plus particulièrement à son architecture modulaire, on retiendra la phrase suivante : “La beauté d’une architecture modulaire est que vous pouvez remplacer ou ajouter n’importe quel composant (module) sans affecter le reste du système“. 

Marc explique ensuite qu’il a utilisé Symfony pour répondre à ces exigences, et, en particulier deux fonctionnalités :

AudienceHero utilise massivement registerForAutoconfiguration, qui permet notamment de configurer automatiquement les EventSubscriber et il nous le montre à travers plusieurs exemples. Marc aborde également l’écosystème de son projet. Il ne tarit pas d’éloges sur API Platform (on cite : meilleure solution pour les API, intelligent, standards ouverts, une architecture top). Il donne également beaucoup d’amour à Admin-on-rest (anciennement React-admin) notamment pour son côté très haut niveau ne l’empêchant pas d’être personnalisable.

Après avoir parlé des enqueues ou encore de la gestion des mails via le bundle Mailer de Sylius, Marc traite de la modularisation des applications SPA (front et back office) de AudienceHero, grâce notamment à de la génération de code et de Symfony Webpack Encore. À la fin de sa conférence, Marc rappelle que malgré la beauté de l’architecture modulaire, elle n’est pas forcément à adopter pour tous les projets, notamment car elle est longue et contraignante et demande ainsi une bonne maturité.

Romain Gautier, lead developer chez SensioLabs, nous présente avec sa conférence de nombreux outils pour rendre la vie des développeurs plus agréable. Une des conférences qui a eu probablement le plus d’impact sur les développeurs qui l’ont suivie !

Il commence donc avec l’outil de gestion de versions par excellence : Git. Un problème récurrent pour les développeurs PHP nous est alors montré. Un checkout sur une branche et la question que l’on se pose à tous les coups : doit-on faire un composer install ou non ? Romain nous propose de ne plus jamais se poser cette question grâce à deux outils : http://git.io/lyrixx-git-hooks et https://github.com/greg0ire/git_template, deux hooks vérifiant que le composer.lock a changé et évitant donc cet oubli. 

Romain s’intéresse ensuite aux fixtures pour les tests. Nous ne pouvons qu’approuver ses choix : AliceBundle, Faker, DoctrineFixturesBundle et DoctrineMigrationsBundle. Après les fixtures, Romain aborde les tests. Dans le cas où un développeur n’utilise que PHPUnit pour ses tests unitaires et fonctionnels, il peut s’avérer pratique de grouper les tests fonctionnels ensemble afin de les exclure. Pour cela, il nous recommande l’annotation @group et l’utilisation des arguments --exclude-group et --group pour la commande phpunit. Pour les tests fonctionnels, il recommande LiipFunctionalTestBundle.

Romain touche ensuite un point important de sa conférence : comment éviter les tâches répétitives des développeurs. Sa solution ? Un Makefile. Il continue de présenter ses outils favoris avec Docker. Quelques slides de présentation de l’utilisation de l’indispensable docker-compose, et il nous montre un problème épineux : la gestion des droits. Voici comment il résout ce problème : il récupère l’UID + GID du volume et utilise gosu ou su-exec pour les changer correctement dans l’image. Voici le code qu’il utilise pour les récupérer : https://github.com/mykiwi/symfony-bootstrapped/blob/master/docker/php/entrypoint.sh. Un grand merci à lui ! Pour accéder facilement aux sites des containeurs Docker, il nous présente de nombreux outils : docker-hostmanager, Docker DNS-gen et nginx-proxy.

Pour l’intégration continue, Romain nous parle de GitLab. En utilisant correctement le fichier .gitlab-ci.yml et en faisant un push / pull plutôt que du build à chaque déploiement, il est possible de réduire la durée des tests. Il est également possible de faire un export / load en local si l’on ne veut pas utiliser de Docker Registry. Lors de l’intégration continue, il est courant d’utiliser de nombreux outils pour vérifier son code. Plutôt que de les ajouter un à un, il nous propose d’utiliser une seule image Docker. Trois nous sont proposées : https://hub.docker.com/r/mykiwi/phaudit/, https://hub.docker.com/r/jolicode/phaudit/ et phpqa. Enfin pour le déploiement continu, il évoque de nombreux outils (Ansible, Docker Swarm, …) mais s’intéresse plus particulièrement à Capistrano. C’est un résumé de ses points précédents : une bonne utilisation de Docker, Make et GitLab permet de simplifier grandement les déploiements.

Voici la liste des références qu’il a utilisées :

Le code source de tous ses exemples est ici : https://github.com/mykiwi/symfony-bootstrapped et ses slides sont là : https://speakerdeck.com/mykiwi/outils-pour-ameliorer-la-vie-des-developpeurs-symfony

Nicolas Grekas, l’un des plus gros contributeurs à Symfony, nous explique grâce à sa conférence comment faire pour rendre son code le plus performant possible avec PHP 7.

Après un bref historique du moteur PHP, il nous conseille d’aller lire les blogs de deux contributeurs du moteur, à savoir les blogs de Julien Pauli et Nikita Popov. Nicolas commence par rappeler le fonctionnement global du moteur PHP : un processus (master) qui gère de nombreux processus enfants qui exécutent le script PHP. Il nous explique ensuite que le moteur est paresseux : il ne charge les classes que lorsqu’il en a réellement besoin et cela lui permet de garder un bon niveau de performance. Grâce à la fonction spl_autoload_register, c’est l’autoloader de Composer qui est utilisé et qui est donc appelé de nombreuses fois dans le cas d’une application Symfony classique.

Nicolas s’intéresse ensuite au principe roi permettant de gagner en performance et qui fait que PHP 7 est aussi efficace : le cache. Il nous explique que chaque processus enfant du moteur PHP dispose de sa propre mémoire mais aussi d’une mémoire partagée entre les différents processus. C’est cette mémoire qui correctement utilisée va permettre de gagner en performance. Le moteur PHP met plusieurs types d’éléments en cache : les chemins des fichiers, les résultats d’appels de fonctions coûteuses sur les fichiers, la compilation des expressions régulières et enfin les opcodes.

Autre point évoqué, l’exécution d’un script PHP en plusieurs étapes : l’analyse lexicale et syntaxique (lexing et parsing) aboutissant à la construction d’un arbre syntaxique abstrait (AST) et la compilation de ce dernier en opcodes. Grâce à l’AST, le moteur de PHP 7 réalise de nombreuses optimisations de code : la concaténation de chaînes (‘foo’.”bar” devient ‘foobar’), la suppression du code mort, les chaînes de caractères mises en mémoire partagée avec leur hash et leur longueur... Il revient également sur le fait que les chaînes de caractères et les tableaux sont stockés dans la mémoire partagée. Cela a permis d’améliorer certaines parties du code de Symfony en remplaçant les tableaux construits avec des variables par des tableaux ne faisant appel par exemple qu’à des constantes magiques (__DIR__ étant par exemple résolu à la compilation). Ces optimisations sont détaillées dans les articles suivants : https://blog.blackfire.io/speeding-up-autoloading-on-php-5-6-7-0-for-everyone.html et https://blog.blackfire.io/php-7-performance-improvements-immutable-arrays.html.

Nicolas nous explique également qu’il cherche à éviter un maximum le copy-on-write et du collecteur de miettes de PHP, qui peut être un frein aux performances d’une application. On retiendra que PHP 7 effectue de nombreuses optimisations transparentes, que l’opérateur coalescent est très efficace et que les constantes de classe ne le sont pas (mais utilisez-les quand même !). Et que les développeurs de PHP travaillent activement sur la compilation à la volée pour PHP 8 ! Pour conclure, Nicolas nous rappelle que toutes ces optimisations ne doivent se faire que pour des parties de code bien spécifiques et que toute modification à des buts de performance doivent être mesurées avant d’être certain de leur impact. Et que PHP 7 c’est génial.

Retrouvez ses slides : https://speakerdeck.com/nicolasgrekas/tirer-le-maximum-du-moteur-php-7-lexemple-de-symfony

Samuel Rozé nous a expliqué comment utiliser le nouveau composant de Symfony : le composant Messenger.  

En quelques mots, ce composant va aider les applications à envoyer et recevoir des messages depuis/vers d'autres applications ou via des systèmes de queues (comme RabbitMQ, Amazon SQS, etc). Messenger fournit un bus de messages et un routage permettant d’envoyer des messages dans n'importe quel service où vous en aurez besoin, comme dans un contrôleur. La contribution du composant lui a permis de rejoindre la core team de Symfony. Nous lui souhaitons encore une fois toutes nos félicitations !

Enfin, Samuel nous invite à tester ce composant : il n’est pas nécessaire d’avoir tous les composant de Symfony en 4.1 pour l’essayer et vos retours sont les bienvenus pour continuer de l’améliorer . Cette conférence était plus qu'intéressante et nous donne énormément envie d’utiliser ce composant ! Découvrez ses slides : https://www.slideshare.net/samuelroze/symfony-messenger-queues-workers-more

Kévin Dunglas a donné une conférence axée sur les avantages et inconvénients de REST et GraphQL à travers de multiples exemples et en nous rappelant à chaque fois quand il était préférable de les utiliser, en complément ou séparément.

On peut comparer Rest et GraphQL via API Platform, qui les implémente tous les deux. Pour rappel, API Platform permet de générer rapidement une API et un admin supportant différents formats comme Hydra, JSON API, OpenAPI etc… Avec l'intégration de GraphQL dans sa nouvelle version, on a une alternative aux architectures REST pour la création d'APIs web.

Sorti par Facebook en 2015, GraphQL comporte de nombreux avantages et fait la une de nombreux articles techniques pour ses différentes qualités comme sa syntaxe indéniable ou encore sa limitation du nombre de requêtes et sa récupération des données utiles permettant un gain de temps fou en développement. Cependant, GraphQL souffre aussi de nombreux défauts comme l'incompatibilité avec les mécanismes de cache, de sécurité ou d'auth. Autre problème majeur de GraphQL : les logs. Ayant un seul point d’entrée HTTP, GraphQL ne permet de pas de faire des statistiques avec les logs sans implémenter soi même une solution applicative. 

D'un point de vue éthique, on peut se demander pourquoi avoir des systèmes centralisés, des accès aux données limitées et peu d'intéropérabilité quand on sait que GraphQL est développé par Facebook (et que l'on est au courant des derniers événements liés aux accès à leurs données) et que les Linked Data et le format de données REST proviennent de la communauté scientifique, se basent sur un web totalement ouvert avec une intéropérabilité globale et des systèmes complètement décentralisés.

Découvrez davantage d'informations sur ce comparatif via ses slides : https://speakerdeck.com/dunglas/rest-vs-graphql-illustrated-examples-with-the-api-platform-framework

Hamza Amrouche, membre de notre équipe et de la core team API Platform nous a fait un retour d’expérience de l’utilisation du composant Workflow de Symfony, dans le cadre de sa mission chez le client Quotatis (groupe Adeo).

Après nous avoir brièvement expliqué comment fonctionne la plateforme Quotatis (solution de mise en relation entre les particuliers et les professionnels du bâtiment), Hamza nous a fait un rappel théorique sur les graphes. On passe alors en revue les graphes orientés, non orientés, cycliques ou encore les connexes. Il nous fait également un rappel sur le réseau de pétri : le composant workflow est basé sur une extension de réseau de pétri (le workflow-net) et par ce biais, il nous montre comment les transitions sont faites et comment les tokens arrivent dans les places.

Place ensuite à la présentation du composant Workflow, un composant introduit dans Symfony en version 3.2 par Grégoire Pineau et Fabien Potencier et quelle est la configuration utilisée dans le cadre du projet Quotatis. Via cette mission et ce composant, on va pouvoir gérer les status des projets (soit la bonne mise en relation entre un artisan et un particulier). Lorsque le projet est créé, il a un status de base “en cours” qui passera à “à valider” lorsque l’utilisateur mettra à jour son projet et une fois qu’il sera validé, le projet passera à “validé”. Hamza revient ensuite sur la configuration utilisée (machine à états ou Workflow, quel type, quelle propriété, quelles transitions…) permettant de garantir que les projets qui sont dans les places ont bien passé toutes les règles de validation.

Cette conférence se conclut par une liste des nouveautés arrivées avec les versions 3.4 et 4.1 de Symfony :

Retrouvez les slides d’Hamza : https://speakerdeck.com/simperfit/le-composant-workflow-de-symfony-cest-graphement-bien

C'est Sarah Khalil qui a clôt cette dixième édition en nous faisant un récapitulatif des mises à jour dans l’écosystème Symfony depuis l’année dernière. Évidemment, elle n’est pas revenue point par point sur l’intégralité de ce qu’il s’est passé, mais elle nous a sélectionné plusieurs informations capitales. 

D’abord quelques chiffres :

L’année 2017 a également été signe de changements majeurs côté développements : Symfony a été considérablement allégé au point que l’on peut presque considérer Symfony 4 comme un micro-framework. Partant de ce constat, il a été décidé de ne plus conserver Silex (sauf si des personnes souhaitent le maintenir), qui s’arrêtera en juin 2018 tout comme l’installateur “Symfony” et le projet “symfony/standard-edition” qui eux s’arrêteront en novembre 2020. Plusieurs améliorations ont également été notées au niveau des composants Dependency Injection, Workflow et Router. Toujours au niveau des composants, un notable a fait son apparition : le composant Messenger. 

Enfin, Sarah a touché un mot sur la diversité dans la communauté. Ce n’est un secret pour personne, la parité dans ce secteur n’est pas du tout égalitaire : dans l’Open Source, on compte 2 à 10% de femmes (contrairement au secteur du logiciel propriétaire où on dénombre près d’un tiers d’entre elles). Dans la communauté Symfony, ce n’est pas mieux : la core team n’est constituée que d’hommes et seulement deux femmes font partie des 100 premiers contributeurs au framework. Idem au niveau des conférences, 80 à 90% des conférenciers sont des hommes, tout comme au niveau des participants. Plusieurs initiatives se mettent en place pour contrer ces chiffres alarmants : un guide est disponible pour que les contributeurs·trices au framework rédigent des commentaires constructifs afin de ne pas les décourager les plus novices pendant le processus de révision d’une PR. Des programmes de mentorat sont de plus en plus lancés pour encourager les femmes à faire du développement Open Source : nous pensons notamment au programme RGSOC auquel nous participons, ou encore Outreachy et Powercoders. Enfin des règles d’utilisation du Slack Symfony Dev ont été communiquées, et deux chaînes nommées #victory et #thankyou ont été créées afin que chacun•e montre sa reconnaissance aux autres membres de la communauté dans le but de créer de l'énergie positive.

Le chemin est encore long pour que la communauté soit diversifiée, mais c’est en bonne voie ! Ses slides : https://speakerdeck.com/saro0h/symfonylive-paris-une-annee-de-symfony

Comme l'an passé, en plus des talks habituels, nous avons eu la possibilité de participer aux Unconferences, des conférences en marge du track principal qui sont tout autant intéressantes. Notre coopérateur, Grégoire Hébert, a eu l’opportunité d’en animer une dans une salle bondée. 

La conférence traitait du premier type d’intelligence artificielle, c’est à dire une intelligence “prévisible” étant donné que l’on connaît à l’avance les résultats attendus par rapport aux entrées fournies. On parle alors de Reactive Machines, qui agissent selon différents scénarios. Ces intelligences artificielles s’entraînent via des jeux de données et par back propagation et post analyse des erreurs. Grégoire nous a présenté comment sont activées les décisions par rapport aux différentes entrées tel que “j’ai faim” (dans une certaine mesure), “dois-je manger” et comment sont effectués les tests et retours d’erreurs qui vont permettre à L’IA de s’améliorer, le but étant de trouver le moyen d’apprentissage le plus rapide et efficace.

Retrouvez ses slides : https://slides.com/gheb/neat-plus-ultra-uc#/

Cette année encore, nous faisions partie des sponsors de l'événement et le moins qu'on puisse dire, c'est qu'on a pas eu le temps de souffler ! Vous avez été très nombreux·ses à venir vous renseigner sur notre mode de fonctionnement en tant que SCOP, nos offres de formation Masterclass ou encore faire une démo du framework API Platform.

Encore merci à Sensiolabs pour l'organisation et à l'année prochaine !