Du code, des gaufres et des BDs, nous étions à la SymfonyCon à Bruxelles
Pour cette nouvelle édition, le rendez-vous était donné à Bruxelles, du mardi 5 au samedi 9 décembre. Après 2 jours de workshops et avant le hackday du samedi, les conférences se sont déroulées le jeudi et vendredi au Square Conference Center de Bruxelles avec 3 tracks parallèles dans les salles Symfony, SensioLabs et Platform.sh. Prêt(e) pour notre récap ? Laten we gaan !
Section intitulée une-opportunite-communautaire-dans-une-ville-a-l-aura-europeenneUne opportunité communautaire, dans une ville à l’aura européenne
Une SymfonyCon c’est une expérience communautaire qui se vit. Entre les workshops, dont celui de Mathieu sur la gestion des traductions, le diner des speakers, la soirée communautaire au musée de la bande dessinée du jeudi, la sortie running et le hackday du samedi, tout était pensé pour faire des rencontres, pour tisser des liens et renforcer la communauté.
Car un framework sans sa communauté n’est rien. Et c’est agréable de voir l’unité, la volonté de faire avancer les choses ensemble, qui se dégage de la communauté Symfony. La Core team se veut très accessible, coordonnant cet ensemble et prête à aider que ce soit sur Slack ou en direct comme nous avons pu le voir lors de la session Q&A dédiée.
Une SymfonyCon c’est aussi l’occasion de (re) découvrir une ville. Après Disneyland Paris l’an dernier, nous sommes allés chez nos voisins belges et n’avons pas résisté à goûter quelques unes de leurs spécialités : gaufres, chocolats, frites. Sans oublier notre passage éclair par la Grand-Place, le marché de Noël et le petit détour pour voir le Manneken-Pis sous toutes ses coutures. Littéralement.
Où se déroulera la prochaine édition ? Réponse en fin d’article. 😌
Section intitulée keynote-d-ouverture-facon-fabpotKeynote d’ouverture, façon fabpot
Fabien Potencier ouvre les festivités de l’édition 2023 en présentant un sujet sur lequel il s’est investi ces derniers mois.
La keynote commence ainsi par un historique sur le composant Console. Il s’agit d’un des plus vieux composants de Symfony, qui trouve ses racines dans la version 1.1 sous le nom de « sfTask ». Depuis, ce composant a très peu évolué. Il est à ce jour le composant le plus téléchargé avec une moyenne de 650 000 téléchargements quotidiens.
Autant de raisons qui expliquent la volonté de se replonger dans les entrailles de ce composant afin de le faire évoluer, d’en améliorer la DX, sans craindre de casser l’existant.
Welcome Symfony Terminal !
Ce futur composant a pour but de fournir à terme une abstraction bas niveau avec des outils tels que Cursor
, Color
, Style
, Widgets
, Pager
. Fabien nous en fait une démonstration avec une TUI riche, comportant des sections, des marges, des bordures, et même des assemblages de styles façon Bootstrap et des styles utilitaires inspirés de Tailwind CSS.
Actuellement, le composant n’est pas sorti. Il s’agit d’un travail de longue haleine et il reste beaucoup d’efforts à fournir pour espérer le voir dans Symfony 8.0 en novembre 2025.
Section intitulée stop-firefighting-with-blackfireStop firefighting with Blackfire!
Thomas Di Luccio poursuit avec sa présentation de Blackfire. L’objectif de cet outil est de se préparer de manière proactive à tout incident en production, et de supprimer le stress induit lors de la résolution de ceux-ci. Il présente les solutions qu’offre Blackfire à ce sujet :
- monitoring de l’activité, des temps et des statuts de réponse, des méthodes PHP et des services les plus utilisés et leur impact ;
- alerting, pour être averti par email ou dans Slack dès qu’un seuil d’alerte (à configurer) est dépassé ;
- health report à consulter 5 minutes par jour pour s’imprégner des performances de sa production et ainsi détecter plus rapidement les anomalies.
Malgré cela, parfois, l’incident se produit. Il faut alors être réactif et utiliser les outils à notre disposition. Thomas nous propose dans ce cas d’utiliser le profiler de Blackfire, qui permet d’explorer à travers un arbre où le code est le plus gourmand en ressources ou en temps d’exécution (opacité plus foncée).
N’hésitez pas à jeter un œil à la démo de Blackfire pour vous faire votre propre avis.
Enfin, il rappelle l’importance des tests unitaires, d’acceptation, de performances et leur automatisation au sein de nos pipelines CI/CD. Il conseille l’utilisation du Blackfire Player, outil permettant de tester son application, d’évaluer la performance des parcours utilisateurs critiques, et bien d’autres choses.
A JoliCode, nous aimons beaucoup Blackfire. Dépendant de nos projets, nous l’utilisons en complément d’autres outils tels que Datadog ou redirection.io.
Section intitulée i-did-it-i-broke-productionI did it! I broke production!
Sur la même thématique des incidents en production, Sofia Lescano nous fait profiter de son retour d’expérience sur l’un des incidents qu’elle a vécu. Elle nous confie comment, avec ses collègues, ils ont réagi et quels sont les processus mis en place pour prévenir ces incidents.
Seuls ceux qui ne font rien ne cassent rien. Bonne chance ! William, un développeur sénior
Mais alors que faire quand cela nous arrive ? S’y préparer ! Via un processus clair. Par exemple, Sofia explique que dans son entreprise à la suite d’un événement PagerDuty, ils s’organisent en équipe, un channel Slack dédié est disponible ainsi qu’un Google Meet ouvert à tous pour centraliser les discussions. La communication est primordiale, autant en interne, avec ses collègues, qu’en externe avec ses clients : mise en place d’une status page, support et enfin rédaction d’un post-mortem.
Gérer les incidents c’est bien, les prévenir c’est mieux.
Sofia rejoint Thomas dans l’idée d’être toujours proactif, de tester son code et de surveiller, de mettre en place de l’alerting. Elle précise aussi l’intérêt des revues de code, servant au partage de connaissance sur le code et recommande par ailleurs de toujours déployer durant les heures de travail.
Section intitulée strings-usage-so-many-tools-are-already-in-your-handsStrings usage: so many tools are already in your hands!
Dans un talk plein d’anecdotes farfelues, Marion Hurteau nous explique comment les chaînes de caractères se comportent derrière nos écrans. L’histoire de l’encoding jusqu’à nos jours nous permet de comprendre les bugs d’aujourd’hui et comment y remédier : notamment en étant cohérent sur l’encodage utilisé dans nos systèmes. Faire appel à la normalisation et aux différentes méthodes de translittération permet aussi par exemple de faire une recherche de caractères spéciaux même lorsque ceux-ci ne sont pas présents sur notre clavier.
Marion continue par un rappel sur les différences d’encodages au sein de nos bases de données : encore une fois, PostgreSQL n’offre aucune mauvaise surprise, contrairement à MySQL. Toujours dans la base de données, on retient la nécessité de normaliser nos données avant de les indexer afin de ne pas avoir de mauvaises surprises si notre jeu de données contient des caractères provenant de différents alphabets.
Elle nous présente également le trop peu utilisé composant String de Symfony, ses méthodes les plus pratiques, mais aussi celles qui permettent de jouer un peu avec les emojis : on peut en mettre dans nos urls, dans nos moteurs de recherche, dans nos bases de données, même dans le nom de nos classes PHP ; tout est possible ! 🦄
Section intitulée need-to-search-through-your-data-heard-about-meilisearchNeed to search through your data? Heard about Meilisearch?
Direction les moteurs de recherche avec la présentation de Meilisearch, alternative à Elasticsearch, OpenSearch et Algolia, par Guillaume Loulier, développeur à SensioLabs.
Meilisearch est une solution d’indexation, de recherche et d’analyse orientée document et développée en Rust. Ses atouts ? Il s’agit d’une solution open-source, française, et son équipe fournit et maintient un SDK PHP et un bundle Symfony ! Nous l’utilisons déjà sur certains projets et ce talk nous conforte dans ce choix.
Elle dispose de fonctionnalités avancées inhérentes aux meilleures solutions d’indexation et de recherche, à savoir :
- une architecture schemaless ;
- la détection de la langue / le support du multi-langue par défaut ;
- un bundle très complet, avec des Live Components fournis (mais très lié à Doctrine).
De plus, meilisync étend les possibilités de Meilisearch en permettant de synchroniser un stockage primaire comme MySQL, PostgreSQL, ou MongoDB vers Meilisearch. Il suffit de quelques étapes de configuration pour que l’outil écoute les logs émis par la base de données et les réplique.
Guillaume souligne également que toute la documentation de Symfony est désormais indexée avec Meilisearch !
Le talk se termine sur les limitations actuelles de Meilisearch. Notamment lorsque l’on souhaite s’en servir à grande échelle. En effet, l’offre commerciale Meilisearch Cloud est à ce jour le seul moyen d’avoir de la haute disponibilité sans devoir bricoler. Autre point de vigilance, la solution n’offre pas de sharding comme peut le faire Elasticsearch. Néanmoins, ces fonctionnalités sont à l’étude dans la roadmap de l’équipe produit. Il n’est donc pas impossible d’y avoir accès un jour dans la version open-source.
Les slides de Guillaume sont disponibles sur Speaker Deck.
Section intitulée a-serverless-symfony-playgroundA serverless Symfony playground
Exécuter un binaire PHP dans le navigateur en WebAssembly (wasm), l’idée vous tente ? Antoine Bluchet, aka s0yuka, l’a fait. Et il nous présente pourquoi et comment.
À l’origine, Antoine souhaitait offrir une manière plus interactive et accessible d’explorer la documentation d’API Platform. A l’instar de 3v4l.org, il décide que la meilleure option est d’exécuter du code en ligne, avec un écran scindé en 2, d’un côté un fichier PHP éditable (basé sur un exemple) et de l’autre le rendu en temps réel. Le playground d’API Platform est né. Problème, la plupart des solutions qui exécutent du PHP dans le navigateur s’appuient sur un serveur, et cela peut vite devenir coûteux. Solution, mettre le serveur dans le navigateur.
Antoine détaille ensuite ses tâtonnements jusqu’à la solution finale. En s’inspirant de la lib oraoto/pib, il retravaille la partie Docker, installe les extensions manquantes (SQLite, libxml), compresse le tout avec LZ4 (particulièrement utile pour les vendors
!), ajoute une bonne dose de magie… Et tada !
Pour les sceptiques, il nous invite à ouvrir la console et à constater par nous-même : aucun appel réseau n’est fait. Autre possibilité, faire un phpinfo()
et observer la valeur du système : Emscripten emscripten 3.1.35 #1 wasm32
.
Antoine termine en évoquant le futur : il souhaite maintenant faire pareil pour le Symfony Book. On a hâte de voir ça !
Si ce sujet vous intéresse, sachez que ce talk rejoint et complète un autre talk qu’Antoine a donné il y a quelques mois à l’API Platform Conference 2023, à Lille, et dont le replay est disponible sur YouTube.
Section intitulée task-scheduling-can-be-boring-but-not-with-symfony-schedulerTask scheduling can be boring, but not with Symfony scheduler
Nous retrouvons dans la grande salle Allison Guilhem, lead developer chez Les-Tilleuls, pour son talk très attendu sur le composant Symfony Scheduler (disponible depuis Symfony 6.3).
Allison commence par un état de l’art. Qu’est-ce que le task scheduling (ou planification de tâches) ? C’est l’automatisation des tâches basées sur un calendrier, et répétées à intervalles réguliers. Dans le monde Unix, nous appelons cela des crons. De nombreuses intégrations PHP existent. Mais les crons souffrent de plusieurs limitations : manque de support de TimeZone, intervalle minimum d’une minute, aucun système de récupération pour les tâches manquées. Des lacunes qui peuvent être compensées par des outils comme Anacron ou Celery, au prix de la complexité et de la maintenabilité.
Symfony Scheduler à la rescousse ! Allison passe ensuite à une présentation exhaustive de Symfony Scheduler, alternative complète au cronjob. Elle expose les nombreux moyens de déclarer une tâche planifiée : avec les méthodes statiques de la classe RecurringMessage
, ou avec les attributs #[AsPeriodicTask]
, #[AsCronTask]
et également #[AsSchedule]
. Pour finir, Allison explique les raisons qui l’ont amenée à contribuer l’ajout d’événements pre_run_event
, post_run_event
et failure_event
: séparer la vérification qu’un message doit être traité de son traitement.
Les slides d’Allison sont disponibles sur Speaker Deck.
Envie d’en savoir plus ? Baptiste Leduc a écrit un article à ce sujet sur notre blog il y a quelques jours. 🤓
Section intitulée how-to-use-gpt-with-your-symfony-appHow to use GPT with your Symfony app
Depuis un an, le mot est sur toutes les bouches. Chat GPT s’immisce partout, jusqu’à provoquer pour certains une lassitude. Mais combien sommes-nous à vraiment comprendre les concepts derrière ? C’est le défi que s’est lancé Christopher Hertel : nous expliquer les LLM et GPT puis en faire une démonstration pratique avec Symfony.
Le concept est assez simple, un modèle pré-entraîné sur un dataset conséquent génère des réponses via des calculs de distances entre vecteurs pour trouver la suite de mots attendue la plus probable. Ainsi, la qualité de l’entrée utilisateur, ou « prompt », est capitale pour orienter le plus précisément le modèle. De la même manière, le « contexte », permet au modèle de tenir compte de l’historique d’une conversation dans ses réponses. De nombreuses options permettent de moduler le modèle selon nos besoins. Citons par exemple la température, qui est une valeur comprise entre 0 (réponse plus déterministe) et 2 (réponse plus aléatoire).
Place aux cas pratiques ! Christopher présente d’abord deComplex, un site web pour simplifier un bout de code via un appel à l’API d’OpenAI et l’utilisation du bundle openapi-php/symfony
. Une seule consigne système est donnée au modèle : « Tu es un développeur PHP expérimenté et assiste les développeurs à réduire la complexité de leur code. Tu reçois un code PHP et tu dois le simplifier. Réponds avec du code seulement ». L’autre cas pratique est celui d’un bot SymfonyCon qui utilise la génération augmentée de récupération (utilisant une base de donnée vectorielle, comme Pinecone par exemple) pour répondre spécifiquement à des questions sur la conférence.
Les slides de Christopher sont disponibles sur Speaker Deck. Si vous souhaitez expérimenter avec l’IA, huggingface.co et replicate.com sont d’excellentes ressources.
Section intitulée hands-on-with-livecomponents-assetmapper-turbo-amp-stimulusHands-on with LiveComponents, AssetMapper, Turbo & Stimulus
Ryan Weaver en clôture, que demander de mieux ? Passionné et énergique comme à son habitude, il a choisi cette année de nous parler de la LAST Stack et de son approche #nobuild.
Le sujet tombe à point. Il a récemment fait débat au sein de JoliCode entre développeurs front et back.
En s’appuyant sur des exemples concrets (la naissance du border-radius
, la démocratisation du HTTP/2), Ryan insiste sur l’importance de remplacer la complexité de nos anciennes habitudes par plus de simplicité. Simplicité qui selon lui rime avec Symfony UX.
Piqûre de rappel, les Twig Components sont des composants d’interface simples et réutilisables. Ils sont chacun constitué d’une classe PHP et de son template associé.
Les Live Components ont quant à eux pour vocation de rendre les Twig Components dynamiques en fonction des interactions (front) utilisateurs.
Parallèlement, l’AssetMapper est un nouveau composant (depuis Symfony 6.3) qui propose une alternative à Webpack Encore en utilisant la nouvelle propriété importmap des navigateurs pour faire de la résolution de modules, sans avoir besoin de builder et de compiler les assets !
Une révolution ? À JoliCode, nous sommes enthousiastes à l’idée de tester Symfony UX sur des projets simples, mais nos développeurs frontend émettent des réserves : si le projet est complexe, il est préférable d’utiliser un build system. Avis partagé par Ryan dans l’introduction du Screencast dédié.
Section intitulée les-replays-a-ne-pas-manquerLes replays à ne pas manquer
D’autres talks ont retenu notre attention par leur qualité, leur clarté et leur accessibilité aux débutants et à tous ceux souhaitant reprendre les bases en douceur. Ce sont d’excellentes ressources, et nous vous encourageons à les visionner dès qu’elles seront disponibles.
Section intitulée github-actions-101-your-1st-actionGithub Actions 101: your 1st action
Vous n’avez jamais mis en place une intégration continue avec Github Actions ? Pas de panique ! C’est le sujet du talk de Paul Gilzow. A travers des cas pratiques, Paul propose une vue d’ensemble de la CI/CD de GitHub et vous donne les clefs pour démarrer : de la création d’un workflow
basique jusqu’à la création de custom action
de type docker container
, javascript
ou composite
.
En attendant le replay, rien de tel que le quickstart de GitHub Actions pour commencer.
Section intitulée phpunit-10-for-symfony-developersPHPUnit 10 for Symfony Developers
Voilà plus de 23 ans que PHPUnit existe. 👴 Sebastian Bergmann, son créateur et mainteneur, nous présente sa version 10. Sortie en ce début d’année, elle est peut-être la plus grosse release de l’histoire de PHPUnit, incluant un refactoring en profondeur et une modernisation qui pose les bases pour les développements futurs. Durant son talk, Sebastian retrace l’évolution des tests unitaires avec PHPUnit puis réalise un tour d’horizon de ses fonctionnalités.
En attendant le replay, pourquoi ne pas faire un tour sur la documentation ? Bonne lecture !
Section intitulée clap-de-finClap de fin
L’arc bruxellois se termine sur les traditionnels remerciements, aux speakers, à l’organisation, aux nombreux contributeurs et à la core team. Puis vient l’annonce tant attendue : quelle sera la ville hôte de l’édition 2024 ? Suspense… Rendez-vous à Vienne, en Autriche, les 5 et 6 décembre ! 🇦🇹
En espérant vous y retrouver, pour continuer les échanges, le partage d’idées, les découvertes et pour faire grandir ensemble, le framework PHP de demain.
Vous avez un sujet qui vous passionne et souhaitez en parler ? Stay tuned, le CFP arrive bientôt ! Et en attendant, vous pouvez toujours soumettre un sujet à un autre des nombreux événements PHP : SymfonyLive, AFUP Day, Forum PHP, etc. Merci 💛
Cet article porte sur la conférence SymfonyCon Brussels 2023.
Commentaires et discussions
Ces clients ont profité de notre expertise
Afin de soutenir le développement de son trafic, Qobuz a fait appel à JoliCode afin d’optimiser l’infrastructure technique du site et les échanges d’informations entre les composants de la plateforme. Suite à la mise en place de solution favorisant l’asynchronicité et la performance Web côté serveur, nous avons outillé la recherche de performance et…
JoliCode accompagne l’équipe technique Dayuse dans l’optimisation des performances de sa plateforme. Nous sommes intervenus sur différents sujets : La fonctionnalité de recherche d’hôtels, en remplaçant MongoDB et Algolia par Redis et Elasticsearch. La mise en place d’un workflow de réservation, la migration d’un site en Twig vers une SPA à base de…
Une autre de nos missions a consisté à réaliser le portail partenaire destiné aux utilisateurs des API Arte. Cette application Web permet de gérer les différentes applications clé nécessaires pour utiliser l’API et exposer l’ensemble de la documentation.