AFUP Day 2021 Rennes [Canceled and switched online]
28 May 2021 at Online

En bref : les statiques devraient être évitées autant que possible. Méthodes, variables ou propriétés, elles introduisent une dose de programmation procédurable en programmation objet : avec ce fonctionnement hybride, c’est le pire des deux mondes qui s’assemble : statut global, hyperstatismes d’application, tests difficile. Et en plus, ‘static’ est un mot clé PHP avec de nombreux usages, qui eux, sont à la fois bons et méconnus. Alors, passont au régime anti-statiques : on va garder les static dont nos applications ont besoin pour se maintenir saines et pour fonctionner correctement. Et on va éliminer les mauvaises statiques.

Avec la popularité de REST, nous pouvons parfois oublier qu'il s'agit simplement d'une solution parmi de nombreuses autres. REST est une très bonne solution architecturale pour un nombre varié d'APIs mais il existe d'autres solutions pour des scénarios plus nuancés tels que GRPC (Google Remote Procedure Protocol). RPC est un mécanisme client serveur permettant à une machine sur un serveur d'exécuter un programme distant sur un autre serveur. gRPC créé en 2015 par google est basé sur RPC mais permet de traiter des milliards de requête par seconde grâce notamment au multiplexing de requêtes et de réponses, ainsi qu'à son mécanisme de sérialisation binaire Protocol Buffers. GRPC est particluièrement adapté pour les communications inter micro services, permettant de réduire la latence et d'augmenter ainsi les performances. Très peu d'applications PHP actuellement implémentent GRPC, pourtant très puissant. Nous verrons donc comment des cas réels d'utilisation avec des exemples en live au cours de la conférence !

En agilité, on travaille en équipe auto organisée. OK, ça c'est la théorie. Dans la pratique, j'en ai pas vu beaucoup des vraies équipes autonomes... Ce lightning talk de 20 min est un REX d'une équipe qui envoie, vu de l'intérieur par un membre de l'équipe. Des pratiques, des outils et surtout un témoignage : à quel point le travail en équipe et l'agilité c'est incroyable quand tout le monde est aligné et que les gens ont envie d'avancer ensemble.

Notre code date de 2013, sans tests, avec 63 000 commits, 400 000 lignes de code, déployé à la main grâce à un .doc de 47 pages... Difficile d'imaginer qu'on puisse y intégrer un framework moderne, l'utiliser dans une architecture hexagonale en faisant du Domain Driven Design, le tout en déploiement continu... C'est pourtant ce qu'on a fait en 2 ans, et on va vous expliquer comment, vous présenter ce qu'on a réussi mais aussi nos échecs et fausses pistes, et aussi comment on voit les choses pour la suite. Si vous connaissez l'enfer du code legacy, il est temps de retrouver le sourire !

Quand on se lance dans la programmation orientée objet et que l’on souhaite respecter le principe de responsabilité unique et d’inversion de contrôle, on peut se retrouver rapidement en difficulté avec le nombre croissant de classes et de dépendances, et construire un objet peut devenir assez complexe. Pour ce sortir de cet enfer des dépendances, nous avons recours aux conteneurs d’injection. Le but de la conférence est donc d'expliquer les fondements du Conteneur d'Injection de Dépendances avec ses avantages et ses inconvénients, tout en égrainant des conseils sur les bonnes pratiques de programmation orientée objets.

Retour d'expérience sur les deux premières années d'une développeuse web au profil atypique. Durant cette conférence j'aimerais raconter mon parcours de reconversion du social à la tech en pointant du doigt les challenges (la formation en accéléré, s'adapter à un métier technique...), les problèmes (le gatekeeping, le sexisme, ...) mais aussi les choses positives (les rencontres, l'accueil de certaines personnes, le soutien...) que j'ai rencontrés durant ces deux ans pleins de rebondissements. En partageant mon parcours et échangeant avec le public, j'espère que des pistes de réflexions sur comment rendre notre industrie plus inclusive pourront émerger.

Être développeuse ou développeur implique de suivre l'évolution de technologies, de méthodes et d'outils qui évoluent à une vitesse telle qu'il est difficile de rester à jour. Comment faire pour ne pas se laisser dépasser par cet afflux constant de nouveautés ? Comment concilier un apprentissage permanent avec les projets et la vie privée ?

Qu'est-ce que le pattern Atomic Design et comment l'adapter sur un projet Symfony avec Twig ? Ce talk a pour but de "réconcilier" le Front et le Back au travers du pattern Atomic Design. Sommaire : Présentation du pattern Atomic Design En quoi est-il une solution aux "conflits" Front et Back dans un contexte PHP / Symfony Comment l'appliquer efficacement sur Symfony, avec les outils en notre possession

Comment aider les équipes à concevoir et communiquer sur l'architecture du logiciel, tant lors des sessions de conception initiales que lors de la documentation rétrospective d'une base de code existante ? Nous allons découvrir ensemble comment nous pouvons en équipe partager nos connaissances sur un logiciel par des diagrammes simples et clairs adaptés à son audience. Nous parlerons également des avantages du "Documention as Code" pour décrire nos diagrammes sous forme de code.

Présentation de 20 minutes sur les tests fonctionnels, nous suivrons ensemble un cheminement simple et rapide sur : ce qu'est un test fonctionnel, à quel moment il se situe dans la chaine de développement du produit, comment les mettre en place (principes génériques / outils), en quoi ils sont importants / nécessaires, pour qui ils sont faits, et enfin, pour quoi !

Dans notre industrie, la seule chose qui est inévitable c’est le changement. Ce que nous utilisons ou créons à un instant T peut vite devenir obsolète pour diverses raisons (techniques, sectorielles, …), et sera remplacé par quelques chose de nouveau. La nécessité de livrer de la valeur rapidement dans un contexte agile a bousculé la manière de concevoir des architectures techniques. Entre la philosophie DevOps, et la création d’équipe de plus en plus autonome et indépendante, l'architecture technique doit s'adapter à cette nécessité croissante d’aller et de grandir vite. Comment planifier et concevoir un système en sachant que les problèmes d’aujourd’hui sont complètement différents des problèmes de demain ? Quelles bases poser de manière pérenne mais en étant flexible ? Pourquoi de temps à autre les architectures deviennent un frein au lieu de proposer un terreau pour amener de la valeur au produit ? L’architecture technique idéale n’existe pas, à l'inverse le dogme « pas d’architecture » également. Nous allons voir dans ce talk quels sont les principes de design et les méthodes que les devs ont à leur disposition aujourd’hui pour accueillir le changement facilement et délivrer de la valeur rapidement.