Jusqu’au Forum PHP 2021, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Du Domain-Driven-Design avec API Platform Chez Les-Tilleuls.coop, on aime bien se servir d’API Platform. Principalement parce qu’il répond à beaucoup de questions en matière de conception d’API web, mais également pour sa simplicité d’usage. Cette simplicité a cependant un coût qui se fait généralement sentir lorsqu’on a besoin de sortir du cadre. Le fait est que chez Les-Tilleuls.coop on aime aussi beaucoup travailler sur des applications à fortes contraintes métier, et encore plus sortir du cadre. Et quand ça s’y prête, on le fait en s’appuyant sur les principes du DDD. Architecture hexagonale orientée message, logique métier découplée de l’infrastructure, … Tant de préceptes qui deviennent des prérequis lorsqu’il s’agit de mettre le métier au centre de nos applications tout en assurant la bonne maintenabilité de celles-ci. Mais est-ce que tout cela n’irait pas à l’encontre de ce que propose un framework orienté RAD tel qu’API Platform ? Peut-on réellement découpler notre logique métier de ce framework via les techniques liées au DDD sans pour autant lui faire perdre de son intêret ? La réponse est oui, et durant ce talk nous allons vous montrer comment.

Katherine Johnson / Roissy 21/10/2021 15:10-15:50

Mathias, Robin, il s’agit de votre première conférence au Forum PHP. Pouvez-vous vous présenter en quelques lignes ?

Mathias : Développeur backend chez Les-Tilleuls.coop, j’ai commencé à travailler avec Symfony il y a environ 4 ans. Très rapidement, l’envie me prit de contribuer. Participer étant à mon avis une belle manière de prendre part au succès du framework.

Dans un second temps, je me suis essayé à dispenser des formations et à donner des présentations à des conférences. En effet, expliquer, partager mes connaissances à propos d’une solution est quelque chose qui me plaît particulièrement. Non seulement parce que cela oblige à maîtriser pleinement son sujet mais aussi car confronter les points de vues est quelque chose d’extrêmement satisfaisant.

Cette présentation sera donc ma quatrième, et j’ai hâte de vous y retrouver !

Robin : Consultant en architecture et développement chez Les-Tilleuls.coop depuis 2 ans, je développe en PHP depuis un peu plus de 8 ans, et je contribue à des projets open-source depuis environ 6 ans.

J’ai commencé en tant que développeur backend chez Elao. C’est avec eux que j’ai découvert un peu plus le monde de l’open-source et que j’ai commencé à contribuer au code Symfony ainsi qu’à fréquenter les événements AFUP. C’est également là-bas que j’ai pu découvrir les principes du DDD, principes sur lesquels notre conférence sera portée.

Aujourd’hui, je développe presque uniquement sur de l’open-source. Mon travail chez Les-Tilleuls.coop consiste aussi et principalement à accompagner nos clients via des prestations de conseil et de formation en matière d’architecture et de développement d’applications web.

Pour ce qui est de l’aspect speaker, je suis plutôt junior 🙂 C’est donc un honneur que de pouvoir m’améliorer en partageant mes connaissances au Forum PHP 2021.

Robin, tu es membre de la core team Symfony. À l’aube de la sortie de sa 6ème version, as-tu quelques spoilers à dévoiler à notre communauté sur ce que cette version va apporter de nouveau ?

Une chose est sûre, aucune nouveauté ne sera apportée en 6.0 🙂 Pour la simple et bonne raison que 6.0 n’est ni plus ni moins que 5.4 sans les fonctionnalités qui ont été dépréciées au cours des phases de développement des versions 5.x.

Cependant, il y a quand même un intérêt significatif à passer en 6.0 plutôt que de rester en 5.4 : un gain de performance lié à la suppression des features dépréciées.

Je vous rassure, il se passe quand même 2-3 choses sur 6.0.

Symfony 6 requièrera PHP 8+, ce qui ouvre la porte à des améliorations considérables sur l’ensemble de la base de code du framework.
Un gros chantier est en cours pour l’ajout de déclarations de type partout où cela est possible.
Plus de typage équivaut à moins de place pour un mauvais usage du code Symfony, que ce soit dans les applications finales ou au sein même du code Symfony.

Je peux également vous dire que la configuration de vos applications Symfony 6 se fera en grande partie en PHP si ce n’est totalement, avec l’aide des attributs PHP 8.

Aussi, la suppression de l’ancien système d’authentification (composant Guard inclus) va grandement alléger et simplifier les composants et bundles liés à la sécurité, en plus d’améliorer considérablement la DX (Developer Experience) sur cette partie.
Nous allons pouvoir éprouver et continuer à faire évoluer le nouveau système.

Pour le reste, patience 😉

Vous êtes tous deux contributeurs à des projets open-source : contribuer et utiliser un projet open-source, cela peut faire « juge et partie » à la fois. Comment gère-t-on cela avant de proposer et pousser une nouvelle fonctionnalité ?

Il nous semble important de rappeler que la plupart des grandes contributions open-source sont d’abord dues aux utilisateurs et utilisatrices.
Une manière simple et commune de passer du statut d’utilisateur·trice à celui de contributeur·trice consiste à s’exprimer, notamment en faisant part à la communauté du projet des difficultés qu’on a pu rencontrer, des fonctionnalités que l’on souhaiterait voir apparaître, ou encore des fonctionnalités existantes qui pourraient être simplifiées ou améliorées.
Poser une question sur une plateforme de support ou un réseau social, signaler un bug, proposer l’ajout d’une fonctionnalité, partager un retour d’expérience à une conférence ou sur un blog … Ces actions sont quelques unes des nombreuses manières de contribuer à un projet open-source.
Tout ça pour dire que le plus souvent, on devient contributeur·trice de par notre casquette d’utilisateur ou d’utilisatrice.

Pour juger si une fonctionnalité devrait être ajoutée ou non à un projet open-source, plusieurs facteurs entrent en ligne de compte. Ces facteurs diffèrent notamment en fonction du type de fonctionnalité proposée.

Il y a les fonctionnalités orientées dev, celles qui permettent d’écrire du code de meilleure qualité, en adéquation avec l’état de l’art.
Par exemple, faire en sorte qu’une fonctionnalité existante implémente un standard type PSR dans un souci d’interopérabilité, ou implémenter les features introduites dans la dernière version d’un protocole déjà intégré au projet, tel que HTTP ou Mercure sur le projet Symfony.
Pour ce genre de features, les principaux facteurs de décision sont l’opinion de la communauté (décisionnaires inclus) vis-à-vis du changement proposé, et bien sûr la faisaibilité et maintenabilité d’un point de vue technique.

Ensuite il y a les fonctionnalités plus orientées utilisateur qui répondent à des besoins métier, tel que fournir de quoi gérer des traductions ou encore de traiter des formulaires.
Dans ces cas-là, il s’agit surtout de déterminer si la fonctionnalité est utile au plus grand nombre, qu’elle répond à un besoin suffisamment commun pour justifier son ajout.
Pour y arriver, l’expérience de chacun est la première chose sur laquelle on s’appuie.
L’expérience de qui ? Celle de toutes celles et tous ceux qui veulent et peuvent prendre le temps de s’exprimer.

Un autre levier de prise de décision consiste à regarder ce que font les autres. Voir si d’autres projets open-source similaires, potentiellement sur d’autres langages, implémentent ou non cette fonctionnalité et comment.

Si en revanche la fonctionnalité proposée n’est pas des plus communes, le fait qu’elle soit significativement plus difficile à implémenter dans une application finale que si elle l’était directement dans le projet open-source peut aider à ce qu’elle soit acceptée. Si elle est vraiment trop marginale, on peut au moins envisager de faire en sorte qu’elle soit plus simple à implémenter, par exemple en ajoutant de nouveaux « points d’extension ».

En résumé, c’est très subjectif. Les prises de décisions doivent être basées sur plusieurs points de vue, c’est un aspect important de l’open-source.

Une conférence présentée par

Mathias ARLAUD

Développeur Symfony chez Les-Tilleuls.coop, Mathias est un aficionado de l'open source. Il contribue principalement à Symfony, API Platform et est l'auteur de quelques packages en lien avec cet écosystème.

Robin CHALAS

Robin est un architecte logiciel et un développeur backend qui est impliqué dans l'écosystème PHP et Symfony depuis des années. Membre de la Core Team, il contribue à Symfony en corrigeant des bugs et des failles de sécurité, ainsi qu'en ajoutant de nouvelles fonctionnalités au Framework ou à certains packages OSS populaires qu'il maintient au quotidien tels que LexikJWTAuthenticationBundle. Il aime également aider et partager ses connaissances avec la communauté en étant actif sur les plateformes de support telles que StackOverflow, en examinant les contributions ou en prenant la parole lors de conférences techniques. Si il n'est pas sur son clavier, il est probablement en train de manger des burgers à Lyon, de caresser ses chats, de jouer à la pétanque ou encore de s'occuper de ses plantes.

Autres interviews

• La parole est aux speakers : François Zaninotto
• La parole est aux speakers : Kévin Dunglas
• La parole est aux speakers : Pauline Vos
• La parole est aux speakers : Marion Monnet
• La parole est aux speakers : Nicolas Grekas
• La parole est aux speakers : Louis Pinsard
• La parole est aux speakers : David Negrier
• La parole est aux speakers : Elie Sloïm et Martin Supiot
• La parole est aux speakers : Sofia Lescano
• La parole est aux speakers : Damien Seguy
• La parole est aux speakers : Charles Desneuf
• La parole est aux speakers : Romain Camp
• La parole est aux speakers : Stéphanie Trumtel
• La parole est aux speakers : Frédéric Bouchery
• La parole est aux speakers : Anne-Laure Deboissieu et Amélie Defrance
• La parole est aux speakers : Emeric Kasbarian et Jérémy James
• La parole est aux speakers : Benoit Viguier
• La parole est aux speakers : Grégory Planchat
• La parole est aux speakers : Maxime Huran
• La parole est aux speakers : Vincent Laurier
• La parole est aux speakers : Ivan Enderlin
• La parole est aux speakers : Guillaume Loulier
• La parole est aux speakers : Lætitia Avrot
• La parole est aux speakers : Gabriel Pillet
• La parole est aux speakers : Baptiste Langlade