Catégorie AFUP Day 2020

La parole est aux speakers : Stéphane HULARD

Jusqu’à l’AFUP Day 2020, 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

Unplug the HTTPlug !

ll y a beaucoup de librairies qui permettent de faire des appels HTTP depuis nos applications. Parfois un projet utilise plus d'un "client" et il devient compliqué de savoir et contrôler comment ces appels sont déclenchés.

HTTPlug est un petit écosystème (librairies, adapteurs, bridges avec les frameworks, actif dans la création des PSRs…) qui peut aider à créer une abstraction autour du client HTTP. Il contient les adapteurs vers les librairies les plus connues (Guzzle, cURL, …) et adopte complètement les PSR7 et PSR18. En utilisant quelque chose comme HTTPlug, vous aurez la possibilité de normaliser le comportement et d'avoir un seul point d'entrée pour interagir avec les APIs.

Avec ce talk, l'objectif est de présenter l'écosystème, ses avantages, inconvénients et comment il peut aider votre projet à être plus solide.

Manufacture des Tabacs
15/05/2020
15:15-15:35

L’arrivée d’un nouveau composant Symfony dédié à faire des appels HTTP a parfois été questionnée. Quel est ton avis sur cette pluralité et le nombre de librairies disponibles dédiées à cette tâche ?

Lorsque j’ai entendu l’annonce du composant HTTP de Symfony j’avoue avoir été très surpris au début. À une époque où l’interopérabilité est au centre des préoccupations, pourquoi créer un nouvel outil pour répondre à cette problématique courante dans nos projets et surtout pourquoi le faire un peu hors des sentiers battus ?
En effet les recommandations sur les messages HTTP (PSR7) et sur les clients HTTP (PSR18) avaient été acceptées quand ce composant est sorti et ont pourtant été un peu boudées au départ… La sortie de Symfony du PHP-FIG en novembre 2018, quelques mois avant l’annonce du HttpClient n’a clairement pas aidé.

Malgré tout, après avoir pris un peu de recul, lu un peu de code et vu les adapteurs pour les PSR j’étais rassuré. J’ai découvert dans ce composant une approche différente pour résoudre certaines problématiques (compatibilité HTTP2 et multiplexage par exemple) qui n’était pas disponible ailleurs à ma connaissance. Il a donc apporté sa brique à l’écosystème et a permis à toute la communauté d’avancer.

Le côté un peu “fermé” qui est induit par la création de tout ces composants sous la bannière Symfony ne me plait pas toujours mais la communauté derrière ce framework est tellement active qu’il est difficile d’y trouver à redire. Cependant je pense qu’il est important que tout ceux qui n’ont qu’une vision Symfony de l’écosystème découvrent les autres solutions qui leur sont offertes.

Pour terminer, je dirais que ça ne me gêne pas qu’il y ait pluralité tant que tout le monde est libre de s’appuyer sur la solution qui lui convient le mieux, quel que soit le framework qu’il a choisi pour l’accompagner.

Que ce soit pour des appels HTTP ou pour d’autres librairies, quels sont les critères de choix que tu regardes avant d’en utiliser une ?

Mes critères sont différents en fonction du contexte dans lequel je dois faire ce choix. Quand je travaille sur un projet perso, tout seul, je le fais souvent pour expérimenter. Dans ce cas je choisis les librairies avec lesquelles j’ai envie de jouer. C’est souvent celles qui ont une approche qui m’est inconnue ou que j’ai envie de tester qui attirent mon attention. Ça me permet d’enrichir ma vision de la programmation en la confrontant à celles des contributeurs derrières ces outils.

Par contre quand je travaille dans le cadre professionnel avec une équipe je vais plutôt me poser ces questions dans l’ordre :
– Est-ce que l’équipe connaît déjà cette solution et est à l’aise avec ?
– Est-ce que la librairie est correctement maintenue (mise à jour régulière, réponse aux tickets, activité en ligne) pour obtenir de l’aide en cas de besoin ?
– Est-ce qu’elle répond bien à ce dont nous avons besoin ? Qu’est ce qu’il y a en trop ? Qu’est-ce qui manque ?
– Est-ce que l’équipe pourra utiliser facilement ce nouveau code ?

Le reste n’est qu’une histoire de compromis. Intégrer un code tiers nécessite de le brancher correctement dans l’application et c’est finalement le dernier point. Si la librairie est trop compliquée à connecter dans le projet on essaie de se tourner vers d’autres solutions quand il y en a. Sinon la documentation est de mise pour décrire cette complexité.

Tu interviens lors du programme de mentorat, quels retours peux-tu nous faire à ce sujet ?

Effectivement, j’interviens depuis plus de six mois maintenant dans ce programme. J’ai eu le plaisir d’accompagner deux personnes, avec lesquelles ça s’est bien passé (et ça continue de bien se passer). Les échanges autour du métier, des contraintes, des évolutions, du code ont été très enrichissants pour moi et je l’espère pour eux.

Le mentorat est très intense pour les deux parties, mentor comme mentoré·e car il nous met face à la réalité. De mon côté, je confronte mes points de vue, idées et solutions à de nouvelles situations ce qui me permet de continuellement me remettre en question. Expliquer des choix est un bon moyen de se rendre compte qu’ils sont perfectibles ou qu’il existe aussi d’autres chemins pour atteindre le même but. De leur côté j’espère partager ma passion pour cet univers et leur donner envie de persévérer dans cette voie en les accompagnant de mieux que je le peux !

Il y a tellement de belles choses à faire qu’il est important que tout le monde trouve sa place 😉

Le speaker

Stéphane HULARD
Stéphane HULARD
Depuis 2006, il baigne dans le web et son écosystème. Consultant et formateur indépendant, il apprécie particulièrement travailler sur des projets legacy pour accompagner les équipes à les reprendre en main et il s'obstine à la mise en place des méthodes d'ingénierie logicielle sur le web (intégration et déploiement continu, tests unitaires, documentation…). Il essaie de rendre à la communauté au maximum à travers des contributions Open Source. Il télétravaille presque à 100% ce qui lui permet de vivre à l'étranger la moitié de l'année.

Autres interviews

La parole est aux speakers : Julien BRAURE

Jusqu’à l’AFUP Day 2020, 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

Vos tests sont-ils de qualité ? Découvrez le avec le Mutation Testing

Manual testing, c'est déja ca 😉 Automated Unit Testing, c'est un bon début Integration Testing, un cran plus haut niveau et après ?

Lors de ces procédure de tests il est (trop) souvent mis en avant qu'une des metrics reine est le code-coverage. Cependant, c'est plutot le nombre d'assertions qui prime au final, le coverage étant surtout le nombre de lignes ayant été exécutées durant les tests. En poussant à l'extrême, on peut facilement imaginer un code 100% "couvert" par les tests, mais avec 0 assertion, ces tests "blancs" (passeront donc quelques soient les entrées) mais à fort coverage, semble avoir une valeur ajoutée.

Une deuxième hantise du testeur est de "Ne jamais faire confiance à 1 test que l'on a jamais vu FAIL".

C'est là que le Mutation Testing entre en scene.

Des frameworks existent (en PHP il y a Infection https://infection.github.io ) qui vont prendre les 2 "artifacts" existants déjà dans votre projet (le code source et vos tests) et va tout simplement

  1. modifier votre code (1 seule modification ! ceci étant 1 mutation)
  2. faire tourner les tests
  3. s'attendre à ce que vos tests "détectent" cette mutation en reportant au moins 1 test FAIL.
  4. répéter avec 1 nouvelle mutation

Une approche simple, mais coûteuse sur le temps de build, d'avoir un bon retour sur la qualité et valeur réelle de vos tests, et ce avec un cout d'entrée vraiment faible.

Une approche où finalement le but est d'avoir des tests qui FAIL ! mais aussi surtout pour le plaisir de tuer des mutants 😉

Akeneo
15/05/2020
11:15-11:55

Ton sujet portera sur le mutation testing. Comment as-tu découvert cette pratique ?

Je cherchais simplement à améliorer ma pratique de tests. Une conversation banale sur un projet IT:
– « J’ai fini !
– Merci, mais as-tu testé ton code ?
– Oui, oui, manuellement.
– Ah, écris donc des tests automatisés !
– Ok…
– J’ai ajouté des tests !
– Merci ! Mais au fait, as-tu testé tes tests ?
– Pardon ? »

J’ai souvent entendu (et je le répète maintenant à celles et ceux qui veulent l’entendre) « Ne faites jamais confiance à un test que vous n’avez pas vu rouge ».
Au début, on écrit un test, il est vert, on est content. Mais ce test est-il pertinent mais également fiable ? Je changeais donc subtilement mon code source, et j’espérais voir mon test passer au rouge, et honnêtement ce n’est pas toujours le cas…

Au final, j’ai réalisé que je faisais du Mutation Testing, sans le savoir, car je le faisais manuellement. Le Mutation Testing, c’est simplement un outil qui automatise ce travail laborieux pour vous. Je cherchais également un outil me permettant de mesurer de la qualité des tests lors que je reprenais un projet.

Il est parfois difficile de vendre à sa direction du temps pour effectuer des tests. Comment vendre au mieux du temps passé sur du mutation testing ? Quel est son retour sur investissement ?

La bonne nouvelle avec le Mutation Testing, c’est que c’est plus un outil à utiliser que du temps de développement. Au final, vous possédez déjà les 2 choses essentielles dont vous avez besoin:
1. votre code source
2. vos tests (unitaires ou d’intégration)

À partir de ces 2 ingrédients, il vous reste à configurer l’outil de Mutation Testing, et vous le faites tourner pour obtenir un rapport et un score. L’investissement est plus dans l’analyse de ce rapport, et ensuite les modifications de vos tests, et/ou de votre code source, afin d’améliorer l’un et/ou l’autre. Son retour sur investissement est donc des tests de meilleure qualité (fiabilité et pertinence), grâce à une métrique : le MSI (Mutation Score Index), qui idéalement est de 100%.

Avoir beaucoup de tests, et/ou une couverture de code haute, mais un score de MSI bas est un bon signal d’alarme.

On cherche toujours à réduire au maximum les temps de build en intégration continue, faire du Mutation Testing ne va-t-il pas à l’encontre de ça ?

Oui, c’est vrai. Inévitablement rien n’est gratuit. La qualité c’est un coût ! Si vous investissez dans la qualité, mieux vaut donc la mesurer, ce qui est également indispensable si vous voulez l’améliorer.

Au départ, faire tourner ses tests une fois peut déjà être long, donc en effet les faire tourner N fois pour tuer les mutants générés va forcément prendre du temps. Cependant, plusieurs leviers peuvent être explorés:
1. Il n’est pas nécessaire de jouer tous les tests pour tuer un mutant donné. En théorie un seul test suffit ! L’outil de Mutation peut être guidé afin qu’il commence par le(s) test(s) le(s) plus pertinent(s), par exemple en ajoutant des annotations « @covers » sur les tests.

2. Il n’est pas nécessaire de faire tourner le Mutation Testing à chaque commit sur une branche, ni à chaque merge sur develop. On pourrait simplement faire tourner le Mutation Testing 1 fois par jour ou par semaine (la nuit et/ou weekend)… On peut également ne le faire que sur la branche principale au lieu de toutes les features branches.

3. Il est également possible de faire tourner le Mutation Testing en parallèle, mais cela peut apporter son lot de conflits, généralement avec les tests d’intégration.

Le speaker

Julien BRAURE
Julien BRAURE
Julien est un développeur confirmé, tant en PHP que Java, travaillant dans le FinTech. Il aime les choses simples et bien faites. Depuis 5 ans, il profite de la douceur de vivre nantaise en vélo biporteur.

Autres interviews

La parole est aux speakers : Gaël CRISPYN

Jusqu’à l’AFUP Day 2020, 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

Infection : Quand les X-men nous aident à mieux tester

Ecrire des tests unitaires c'est super ! On ne démontre plus aujourd'hui leur utilité tant sur la partie "Documentation du code" que sur la partie "Test du code".

Mais comment être sûr•e que l'on a testé tous les cas de figure de l'utilisation d'une méthode? Y-a-t'il un moyen de tester nos tests unitaires ?

Je vous propose de répondre à cette question en vous parlant du mutation testing au travers d'un des outils PHP mettant en oeuvre ses principes : Infection.

Euratechnologies
15/05/2020
15:10-15:50

Dans un projet client, il est souvent difficile de justifier l’implémentation de tests. Quels conseils donnerais-tu aux développeurs afin de convaincre leurs clients d’en mettre en place ?

Je leur conseillerais une très grande pédagogie en mettant l’accent sur le côté « détection de problèmes éventuels futurs » et gain en terme de documentation. Il n’est pas facile pour une personne extérieure à la technique de comprendre que les temps de développement d’une tâche vont être multipliés par 2 à cause des tests d’autant plus que le ROI ne va pas forcément être immédiat. Cependant, en y allant petit à petit, en mettant l’accent sur le côté « coût du bug » et en se servant des retours d’expérience que peuvent faire les conférenciers lors des AFUP Day ou lors du Forum PHP, les choses devraient pouvoir se faire 😉 De plus, cela peut être bénéfique lors de l’accueil d’un nouveau collaborateur car l’écriture ou la lecture d’un test peuvent être très efficaces pour comprendre une architecture existante.

Peux-tu nous dire si la stratégie de test diffère de façon conséquente selon les projets / équipes, et si oui, dans quelle mesure ?

De façon conséquente, je ne saurais dire, en revanche, les outils utilisés, la quantité de tests écrite ainsi que leur durée d’exécution peuvent varier du simple au double. Lorsque par exemple, on se retrouve avec une foultitude de tests fonctionnels et unitaires écrits qui prennent des dizaines de minutes à s’exécuter, on ne va pas être dans le même cas qu’un petit projet qui en a très peu. On va se poser la question de la fréquence de lancement et on va peut être enclencher des actions d’optimisation ou de refactorisation. Tout est une question de temps et de moyens.

Es-tu déjà tombé sur un cas particulier où la mise en place d’une stratégie de test sortait des sentiers battus ? Si c’est le cas, peux-tu nous en dire plus ?

Jusqu’ici, non. En revanche, je suis tombé sur bon nombre de tests écrits que je définirais comme « farfelus » 😀

Le speaker

Gaël CRISPYN
Gaël CRISPYN
Développeur Web à la Caisse d’Épargne Hauts-de-France depuis plus d'un an avec une dizaine d'années de développement PHP à son compteur, Gaël est également un fan de sport (sauf le golf)... Papa d'un petit garçon d'un an, il essaie de jongler entre sa vie de famille et une curieuse envie de parfaire son travail et découvrir les nouveautés autour de ce langage qu'il aime tant. Ah !! Chose très importante, il adore rencontrer des gens et leur parler donc évitez absolument cet homme.

Autres interviews

La parole est aux speakers : Thomas DUTRION

Jusqu’à l’AFUP Day 2020, 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

Tu n'es pas un {framework} developpeur !

Quand on leur demande leur métier, beaucoup de développeurs et développeuses ont tendance à s'associer au framework X ou Y, souvent dev Symfony ou Laravel en ce moment. Cette tendance, conduite et amplifiée par les offres d'emploi et les différentes formations, est nuisible à notre profession. Être un bon développeur ou développeuse, c'est aussi accepter que la valeur que l'on crée n'est pas liée à notre outil, mais bien à nos connaissances et capacités. Dans cette présentation, nous reviendrons à la base, en parlant d'intéropérabilité et de développement framework agnostic. Quelles pratiques d'ingéniérie logicielle retrouve-t-on communément, comment implémenter les principes que vous connaissez ou que vous pouvez trouver dans la littérature à votre framework favori ? En se basant sur des exemples de Symfony et Laravel, nous allons parcourir différents exemples et voir que notre code métier peut très largement survivre notre framework ! Amateurs de Rapid Application Development, attention, ce talk peut vous donner des boutons !

Manufacture des Tabacs
15/05/2020
16:50-17:30

Tu es impliqué dans l’organisation de conférences comme ScotlandPHP qui a lieu à Edinburgh. Pourrais-tu nous présenter l’événement et nous parler de son organisation ?

En effet, j’ai eu la chance de pouvoir passer quelques années en Écosse qui est un pays merveilleux et plein de ressources et de dynamisme. Assez rapidement, je me suis rapproché d’EdPUG (le groupe PHP d’Edinburgh), qui existait depuis longtemps, et j’ai pu profiter de cette mini-communauté de 7-8 personnes. Cherchant à m’impliquer et voyant le manque de besoin à Edinburgh, j’ai finalement trouvé ma place aux côtés de Mike qui a fondé GlasgowPHP, Danny qui a ensuite ouvert AberdeenPHP et enfin Iain qui a créé DundeePHP. Me déplaçant à chaque meetup sauf Aberdeen (plus difficile d’accès), j’ai pu rencontrer l’intégralité de la communauté, et notamment Paul, ancien organisateur de WhiskyWeb, avec qui nous avons décidé de lancer le projet de conférence.
Nous sommes maintenant 5 organisateurs pour la conférence, dont deux qui organisent Dundee et Aberdeen, et fêtons cette année notre 5ème édition (avec une surprise pour les attendees) !
Pour ceux qui ne connaissent pas la conférence, nous essayons de garder une petite taille (150-200 personnes), avec des speakers experts dans leur domaine et basé sur les retours d’expérience le plus possible. La petite taille permet une ambiance familiale et facilite le contact individuel avec les speakers et sponsors. Nous faisons aussi tous les ans un Ghost Tour dans Edinburgh pour permettre à tout le monde de découvrir cette ville magnifique !

Que penses-tu du PHP-FIG et de son impact (ou non) grâce aux PSR sur l’interopérabilité entre frameworks ?

Conceptuellement le PHP-FIG est pour moi une des meilleures choses dont la communauté PHP dispose. Permettre une interopérabilité, c’est donner la chance aux développeurs et développeuses de ne pas se coincer avec un code non maintenu, car le changement d’implémentation est sensé être grandement facilité. Les interfaces proposées permettent aussi de réduire en théorie les dépendances, par exemple si je veux faire du Symfony PSR-7 Bridge et du Guzzle dans le même projet, je vais pouvoir choisir de le faire soit avec la bibliothèque de Tobias Nyholm, soit avec Diactoros, soit avec les deux (ce qui serait dommage mais malheureusement courant car les développeurs·euses suivent des fois les documentations sans réfléchir…).
Pour moi, le rôle du développeur·euse n’est pas de coder, mais de comprendre une problématique métier et de la résoudre avec du code. Le PHP-FIG, tout comme les designs patterns, ou encore les principes de développement exposés dans la littérature, permettent de faciliter la vie des développeurs·euses en garantissant des implémentations standard, légères et ciblées qu’il faut ensuite composer en forme de solution au problème.
Ce que l’on peut cependant déplorer à l’heure actuelle, c’est le manque de support de certaines recommandations, pour des raisons diverses et variées allant de l’égo au marketing, en passant par des raisons tout à fait valables aussi. Je pense malheureusement que c’est dans l’essence du travail de ce groupe, car standardiser réduit le vendor locking. On ne peut qu’espérer que les gros projets, notamment Symfony et Laravel, reviennent un jour dans ce groupe. En tout cas bravo à tous les participants du PHP-FIG, tous les développeurs ne sont pas capable de supporter ce niveau de discussions politiques, je sais que personnellement je ne suis pas équipé pour !

Nous voyons parfois des membres de notre communauté dont les CVs sont rejetés par de nombreuses entreprises parce qu’ils ne mentionnent pas « symfony » ni « Laravel », malgré parfois plusieurs années d’expérience en PHP, avec ou sans framework « maison ». Est-ce que se présenter en tant que « développeur·euse {framework} » n’est pas aussi une façon de rassurer son intervenant, parfois insuffisamment au courant de nos métiers ?

Je vais essayer de ne pas spoiler ma présentation, mais en effet. Derrière ce titre provocateur, j’évoque ce point avant de me lancer dans le contenu technique, car c’est en effet une des bases de réflexion qui m’a amené sur ce sujet. De part mon travail de CTO, je rencontre pas mal de clients qui cherchent maintenant des ingénieurs logiciels, ou même des développeurs·euses PHP, mais c’est vrai essentiellement sur le marché parisien. Pour des profils plus junior, il est nécessaire d’avoir le nom d’au moins un framework. Cependant, je recommande de ne pas l’utiliser dans le titre, mais le mettre en valeur directement dans les premières lignes, pourquoi pas en commençant le CV avec les expériences directement si l’on en a suffisamment.
Personnellement je suis Zend Framework Certified Architect (Zend Framework 2), et je pense que si j’avais défini mon titre pendant un temps, j’aurais pû être développeur Zend Framework, ce qui me rendrait aujourd’hui invendable, et encore pire d’ici quelques années quand Laminas sera vraiment connu et que ZF aura fini de disparaître.
Je dirais donc comme d’habitude en informatique : « ça dépend du contexte ». Ceci étant, il faut en effet nécessairement avoir les noms des frameworks dans le CV, mais savoir aussi s’en distancer pour ne pas rester bloqué. Et bien sûr, faire la part des choses entre ce qui devrait être et ce qui est, mais ça j’en parle aussi dans ma présentation !

Il fut un temps où nous n’étions que de « simples » développeurs·euses. Maintenant, il y a des fronts, des backs, des mobiles, des leads, des architectes, des full-stacks. Pourquoi avons-nous tendance aujourd’hui à vouloir « étiqueter » les développeurs·euses et les considérer comme {Framework} dev, etc.

Je pense que pour répondre à cette question, il faut séparer différents groupes, et supprimer des légendes. Déjà, le développeur·euse fullstack qui maîtrise les domaines n’existe pas, simplement parce qu’il n’y a que 24h par jour. Dans les années 2000, tout était simple, et il était possible de faire de bout en bout car les technologies étaient moins nombreuses et plus simples, maintenant c’est un choix stratégique qui doit être fait par la direction de l’entreprise. Les besoins aussi ont changé, et personne n’aurait eu l’idée de faire certains gros systèmes actuels à l’époque (par exemple, les problèmes de notifications sur smartphone et de responsive design n’avaient pas raison d’être à ce moment là).
Deux stratégies s’opposent donc selon les besoins définis : soit on veut quelques personnes, fullstack, interchangeables, et lors du départ ou de l’ajout d’une personne la complexité de changement est mitigée par le reste de l’équipe en place, soit on choisit la spécialisation, et là les choses sont probablement livrées plus vite, mais les changements d’équipe sont plus complexe. Ajoutons à ça le très grand nombre de technologies, la difficulté pour certain·e·s à changer de syntaxe, et on se retrouve à privilégier la cohérence avec l’état de notre projet à l’instant T (production plus rapide à court terme) sur l’évolution du projet à long terme.
Pour moi, malgré le titre de ma conférence, les deux stratégies se valent encore une fois, tout dépend du contexte, et dans un contexte où le recrutement est difficile et où il faut que les fonctionnalités aient un time to market le plus court possible, je ne vois pas comment on pourrait ne pas « spécialiser » les offres. Je pense cependant qu’en dehors du cadre de recrutement, il ne faut pas être dogmatique et vraiment trouver des alternatives qui garantissent pérennité, rapidité, et faible coût, mais tout ça on en discutera ensemble sur place le 15 mai n’est-ce pas ?

Le speaker

Thomas DUTRION
Thomas DUTRION
Développeur web depuis environ 10 ans, Thomas s'est spécialisé dans la qualité de code et la programmation orientée objet. CTO chez Darkmira, consultant et développeur web freelance et enseignant en école d'informatique en alternance, Thomas s'intéresse désormais plus particulièrement aux implémentations dans des contextes professionnels et à la transmission de connaissances. Vous pourrez aussi le croiser à l'occasion des User Groups PHP en Écosse et de la conférence annuelle ScotlandPHP qu'il co-organise, du Darkmira Tour Brasil ou encore de l'antenne AFUP Lorraine dans lesquels il s'investit au quotidien.

Autres interviews

La parole est aux speakers : Baptiste LANGLADE

Jusqu’à l’AFUP Day 2020, 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 test à la preuve : introduction au Property Based Testing

La plupart du temps nous écrivons nos tests unitaires ou fonctionnels en hardcodant les valeurs qui passent à travers notre code. Dans certains cas cela peut être suffisant, mais ce genre de test ne permet de valider notre code que pour les cas auxquel on a pensé. Le problème est que le monde dans lequel notre application va évoluer est chaotique, il est humainement impossible de prévoir toutes les formes que pourront prendre les données entrant notre système. Ayant pris connaissance de cette problématique on a commencé à utiliser des librairies comme Faker pour générer les données à notre place. Cependant cette solution ne permet de tester qu’un jeu de données à la fois. Entre alors en jeu le Property Based Testing. Celui-ci nous permet de valider un comportement en utilisant toutes les combinaisons possible des données d’entrée.

Manufacture des Tabacs
15/05/2020
12:25-12:45

Lors du Forum PHP 2018 tu nous parlais de tester « le temps ». Est-ce que ton sujet aujourd’hui est une suite logique aux pistes que tu as évoquées à l’époque ?

Effectivement les deux sujets sont liés. Au Forum PHP 2018 j’évoquais en quoi « le temps » représente un état implicite (mais connu) dans nos applications, avec le Property Based Testing on va essayer de dénicher les implicites (inconnus) de nos applications.

Lorsque tu dois expliquer le concept de test unitaire à une personne qui le découvre, est-ce que tu expliques simultanément le Property Based Testing ou cela vient plutôt dans un second temps ?

Le Property Based Testing vient clairement dans un second temps car il implique d’avoir une réflexion sur le système de typage et un certain recul sur le code que l’on produit. Lorsqu’on commence à utiliser les tests unitaires, l’objectif premier à mon sens est de s’assurer que le code que l’on a écrit fonctionne pour les cas qu’on connait et se prémunir d’éventuelles futures régressions. Alors que le PBT va nous aider à tester des cas qu’on ne peut pas prévoir.

Est-ce que le Property Based Testing à changé ta façon de concevoir ton code ? En te poussant vers l’utilisation du Value Object par exemple ou en t’aidant à franchir des limites imposées par un test unitaire classique?

J’utilise les Value Object depuis quelques années maintenant mais l’année dernière j’ai commencé à remettre en question leur usage intensif car ils impliquent un surcoût à l’utilisation des fonctions pouvant dégrader l’expérience développeur. Cependant sur la même période j’ai utilisé de plus en plus le Property Based Testing ce qui m’a permis de me rendre compte de l’importance du typage et de la valeur des Value Object, qui permettent de réfléchir de façon de plus en plus abstraite à un système. Avoir ces « blocs » de haut-niveau simplifie également la lecture et l’écriture des tests, puisque ça permet de se concentrer plus sur le comportement que l’on veut tester.

Le speaker

Baptiste LANGLADE
Baptiste LANGLADE
Baptiste Langlade est un développeur PHP (certifié symfony2) passionné par indexer internet, Neo4j et le fonctionnement du cerveau.

Autres interviews

La parole est aux speakers : Cécile ESPECEL

Jusqu’à l’AFUP Day 2020, 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

Avant de faire du pair-programming, faites du pair-recruiting !

Etre une équipe auto-organisée et pluri-disciplinaire implique une forte cohérence : il faut bien s'entendre, mais oser se dire les choses, il faut se compléter et se soutenir autant humainement que techniquement. Cette valeur forte de l'agilité est souvent mise à rude épreuve selon la manière dont sont constituées les équipes. Et à la base de la constitution des équipe, il y a l'embauche même des collègues.

Dans ma boite, nous nous embauchons les un·e·s, les autres, du coup nous travaillons notre cohésion dès l'embauche et ça fonctionne ! On aime travailler ensemble et on se tire vers le haut.

Dans cette conf, je vous propose de détailler notre process de recrutement pas si courant et pourtant plein de bon sens, en espérant qu'il fasse germer des idées pour que vous aussi, vous choisissiez vos futur·e·s collègues !

Akeneo
15/05/2020
17:05-17:45

Selon toi quelle est la plus grande difficulté, le plus grand point d’attention lors d’un recrutement ?

Un entretien dure en général à peu près 1h. Pour moi, la plus grande difficulté est d’estimer en si peu de temps si la personne qu’on rencontre correspond à nos valeurs. Est-ce que cette personne va se sentir bien chez nous, est-ce qu’elle va trouver ce qu’elle vient chercher et est-ce que nous allons bien nous entendre.

Aurais-tu des conseils à donner aux développeurs et développeuses pour leurs entretiens d’embauche ?

Mon meilleur conseil, c’est d’être honnête sur ce qu’on cherche et ce qu’on propose. Passer l’entretien pour intégrer une entreprise n’est pas l’étape la plus difficile, le plus dur c’est de rester. Et plus on est franc·he lors de l’embauche, plus on a de chances que ça colle entre nous et la nouvelle boite.

Comment imagines-tu les process de recrutement évoluer dans un futur proche ?

J’espère vraiment qu’on impliquera de plus en plus les personnes concernées dans le recrutement de leurs collègues. Dans la plupart des ESN, ce sont les RH, voire les commerciaux qui font passer les entretiens, c’est bien dommage de se passer de l’avis de ceux qui vont travailler avec ces nouveaux collègues.

Le speaker

Cécile ESPECEL
Cécile ESPECEL
Elle a découvert les méthodes agiles en 2009 alors qu'elle était développeuse. 10 ans plus tard, elle est toujours convaincue par ses vertus et elle a évolué vers le coaching agile et la facilitation. Chez Knp Labs, elle accompagne, elle soutient, elle motive leurs Happy Awesome Developers et leurs Supers Clients. Pour cela elle applique les principes du manifeste agile le plus possible et elle utilise les outils de l'intelligence collaborative.

Autres interviews

La parole est aux speakers : Kevin NADIN

Jusqu’à l’AFUP Day 2020, 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

Étudions ensemble le design pattern "Factory"

Les design patterns sont connus des développeurs et développeuses, mais étant donné qu'il y en a 23 en tout, il est compliqué de tous les connaître parfaitement.

C'est pourquoi aujourd'hui je vous propose de simplement nous concentrer à analyser le design pattern "Factory", car lors de mon expérience professionnelle c'est un de ceux que j'a été amené à utiliser le plus souvent. Nous prendrons donc le temps de voir ses applications, ses bénéfices et ses contraintes d'implémentation pour pouvoir bien comprendre son concept et être capable de le réutiliser facilement

Une fois utilisé, vous ne pourrez pas vous empêcher de l'adopter dès que la situation se présentera à vous 😉

Euratechnologies
15/05/2020
14:45-15:05

Penses-tu que les design patterns ne sont pas encore utilisés au quotidien ?

Cela dépend des design patterns en fait, et souvent nous les utilisons sans nous en rendre compte. Par exemple lorsque l’on utilise le Framework Symfony, nous utilisons régulièrement l’injection de dépendance et nous oublions généralement que c’est un design pattern. Un autre exemple serait l’utilisation du design pattern Factory lors de la création d’un formulaire avec Symfony. En fait nous utilisons des design patterns sans nous en rendre compte.
En réalité ce qui est le moins courant est d’avoir la connaissance et l’expérience pour reconnaître qu’à tel endroit du projet, dans telle situation, un design pattern pourrait être appliqué pour améliorer la fonctionnalité. C’est en réalité l’exercice le plus difficile : connaître les design patterns en théorie est une chose, mais savoir les appliquer demande plus de travail et d’expérience que connaître la simple théorie.

As-tu déjà ressenti le manque d’utilisation de design pattern dans un projet sur lequel tu as travaillé ? En quoi cela a t-il impacté son développement ?

Oui j’ai déjà pu le ressentir, et justement à propos du design pattern Factory, lorsque l’on croise à plusieurs endroits dans le projet le même « switch case » et qu’il pourrait être généralisé, il a été intéressant de reconnaître qu’une amélioration de code serait bénéfique pour la suite du projet et ainsi éviter de répéter encore de nouvelles fois le « switch case ».
En implémentant des design patterns, on se retrouve généralement à faire de la refactorisation de partie du projet, et cela permet généralement de simplifier sa compréhension pour les développeurs et développeuses. De plus un design pattern bien implémenté peut être complété et réutilisé facilement, cela devient une fonctionnalité pratique à l’intérieur du projet.

En 2017, tu donnais ta première conférence au Forum PHP, maintenant tu es sélectionné à l’AFUP Day 2020 Lille en mai. Peux-tu nous parler de ton expérience de speaker ?

2 ans déjà ! Cela passe vite 🙂
La conférence au Forum PHP 2017 était ma toute première conférence, j’avais demandé l’accompagnement à l’époque, cela a demandé du travail mais cela s’est très bien passé. Par la suite j’ai fait des conférences à des meetups, principalement à l’AFUP Paris et à l’AFSY. J’ai remarqué que je préférais présenter des sujets qui ne sont pas liés à un framework dédié mais plutôt lié à PHP et aux bonnes pratiques : j’ai par exemple fait récemment un talk sur les Values Objects. Au total, depuis le Forum PHP 2017 j’ai pu être conférencier dans 7 ou 8 meetups, j’ai pu gagner en confiance en moi et en aisance de parole. Je pense avoir à présent une bonne expérience de speaker, et j’ai hâte de pouvoir donner un talk à nouveau dans un événement de l’AFUP !

Le speaker

Kevin NADIN
Kevin NADIN
Développeur PHP depuis 2010, il cherche à se perfectionner dans la construction de projet de A à Z, de l'installation en dev jusqu'au déploiement en prod. Actif dans la communauté AFUP et AFSY parisienne, il participe et propose des talks aux meetup et aux Forum PHP régulièrement.

Autres interviews

La parole est aux speakers : Grégoire PINEAU

Jusqu’à l’AFUP Day 2020, 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

Async avec Messenger, AMQP et Mercure

Générer des PDF, des CSV, ou faire des traitements lourds lors du traitement d'une requête HTTP impacte lourdement les performances de l'application.

Pour pallier ce problème nous pouvons avoir recours à l'utilisation d'un système de asynchrone. Le composant Messenger sera un super allié pour nous faciliter cette tâche.

Cependant, comment prévenir le client que son PDF est prêt ou que son import de données est fini ? Mercure nous simplifiera la tâche pour notifier le client en temps réel.

Et si notre site est une SPA, pouvons-nous tirer partie de ces composants pour rafraîchir notre application avec seulement 3 lignes de code JS ? Venez le découvrir !

Bowlcenter
15/05/2020
09:20-10:00

Messenger, AMQP et Mercure : tous ces noms de technos, ça me fait penser à des Legos qu’on emboîte. Est-ce que c’est si simple que ça ?

AMQP est devenue une brique souvent indispensable dans une stack web. Grâce à docker il est maintenant très simple d’ajouter un serveur RabbitMQ et Mercure dans son environnement de développement. Pour la production, ce sont deux logiciels qui s’installent facilement. Et il existe aussi leurs versions managées, et même des charts pour K8S. Symfony Messenger et le client Mercure sont maintenant très stables et bénéficie d’une DX accrue. On peut donc dire que oui, c’est aussi simple que ça, ce que nous verrons lors de ma présentation

Comment situerais-tu l’écosystème autour de l’asynchrone en PHP par rapport à celui d’autres langages ?

Nous avons depuis longtemps en PHP de quoi faire de l’asynchrone. Si je me souviens bien, j’avais déjà fait une conférence en 2012 sur AMQP et RabbitMQ. Huit ans se sont écoulés depuis, et les mêmes patterns sont toujours d’actualité. Ils sont robustes et ils ont fait leurs preuves. PHP est donc très mature pour faire de l’asynchrone via AMQP ou via d’autres protocoles.

L’écosystème autour de PHP est vaste, quels conseils donnerais-tu à quelqu’un qui débute afin qu’il ne se perde pas ?

Une fois les bases de PHP acquises, je recommanderais aux débutants d’utiliser un framework – Symfony par exemple. Son utilisation évitera les pièges,permettra de structurer son code tout en gagnant en vitesse et en augmentant sans cesse la qualité du projet. Pour apprendre Symfony, sa documentation est un excellent point de départ. On pourra aussi citer SymfonyCast qui propose une très vaste collection de tutoriels vidéos.

Le speaker

Grégoire PINEAU
Grégoire PINEAU
Arrivé en 2017 dans l’équipe de JoliCode, Grégoire a toujours aimé bidouiller, comprendre et apprendre. À l’issue d’études éclectiques, il est revenu au Web en 2010, domaine dans lequel il exerce depuis avec passion. Après avoir appris à se servir du framework Symfony, il a passé sa certification, puis a commencé à contribuer timidement… Ce qui l’a mené, quelques années après, à devenir un des core contributeurs du projet ! Durant toutes ces années, il a toujours préféré le backend au frontend – même s’il apprécie React, Sass et ces autres joyeusetés, il s’amuse davantage avec Ansible, AWS ou Consul. Vous pourrez le croiser lors de meetups, ou dans des matches de volley 🙂

Autres interviews

La parole est aux speakers : Grégory Planchat

Jusqu’à l’AFUP Day 2020, 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

Synchroniser ses applications facilement, 3 ans ont passé

Lors du PHP Tour 2017 Nantes, nous avions vu la présentation du composant akeneo/batch. Revenons sur 3 ans supplémentaires d'usage, de réflexions et de refactorisation qui ont abouti à la création d'un framework spécialisé.

Dans des environnement de plus en plus interconnectés, de plus en plus hétéroclites, nous voyons apparaitre l'usage des PWA, la généralisation des API et des tâches en files d'attentes asynchrones. Là où les solutions pour interroger des petits volumes de données dans des bases distantes commencent à atteindre une certaine maturité.

Où en sommes-nous sur les synchronisations en grand volume et aux formats de données hétéroclites ?

Akeneo
15/05/2020
14:45-15:05

Tu es CTO d’une société qui se trouve au Puy-En-Velay. Aurais-tu un retour sur le recrutement de développeurs et développeuses dans cette région ? Pourrais-tu nous parler de l’écosystème tech local ?

La pénurie de développeurs se fait ressentir partout en France, nous ne faisons pas exception. Les bon·ne·s développeurs·euses sont rares où que l’on soit. Nous ne faisons par contre pas face aux mêmes enjeux de recrutement que dans des plus grandes villes. Il y a, contrairement à ailleurs, beaucoup moins de turnover entre les sociétés. Nous sommes 6 agences sur le Puy et une petite dizaine dans le département, tous avec nos spécificités. Nous avons probablement aussi moins tendance à user des arguments « babyfoot et bonbons/sodas à volonté » qui s’est bien installé nos métiers, on s’en tient au thé et café en libre service, et tout le monde quitte habituellement le bureau à 17h30.

Nos métiers nous permettent de travailler n’importe où, à condition d’avoir une connexion internet fiable. Le Puy-en-Velay est un ilôt de 60.000 habitants en plein milieu de la campagne. Nous profitons ici d’un cadre de vie exceptionnel. Les déplacements en centre-ville se font à pied, nous n’avons jamais de bouchons et encore moins de retard de bus ou de métro. Nous ne sommes qu’à 40 min de Saint-Etienne et 1h30 de Lyon ou Clermont-Ferrand, ce que certains parisiens peuvent vivre chaque soir pour rentrer chez eux. Je ne parle pas du coût de l’immobilier très abordable.

Point de vue écosystème, un pôle numérique vient d’ouvrir dans un quartier en reconstruction, proche de l’IUT du Puy où 3 agences web et un coworking y ont élu domicile. L’objectif de la ville et des institutions régionales est de faciliter les interactions entre toutes les sociétés du secteur. L’IUT a un département Métiers du Multimédia et de l’Internet et une licence pro. Un lycée technique forme des jeunes en licence Pro. Nous sommes la plus jeune des agences web du Puy, nous avons fièrement fêté nos 5 ans en janvier.

Lire la suite

La parole est aux speakers : Tony Archambeau

Jusqu’à l’AFUP Day 2020, 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

Utiliser WordPress tel un framework

Vous êtes un•e dev "puriste" ? Si oui, alors faites demi-tour. Mais si vous un développeur•euse "pragmatique" et que vos clients n'ont pas la trésorerie des entreprises du CAC40, alors je vous invite à vous intéresser à WordPress tel un framework permettant de réaliser de grands projets. Cette conférence vous expliquera le gain de temps de démarrer sur un projet sous WordPress, tout en laissant une flexibilité aux "non développeurs" de mettre en place rapidement des fonctionnalités via les 54.000 extensions en libre accès sur WordPress. Faites confiance à ce CMS qui propulse 1/3 des sites web du monde, il en a sous le capot !

Bowlcenter
15/05/2020
12:00-12:20

Tu as contribué au développement de plusieurs extensions WordPress dont « WP Sitemap Page ». Pourrais-tu nous parler de cette expériencee ? Continues-tu toujours de travailler sur celles-ci ?

Au total, au moment où j’écris ces lignes, il y a 55295 extensions disponibles au sein du répertoire officiel. Parmi ceux-ci, j’ai eu l’occasion d’en publier 4.
Dans de nombreux projets, nous avons l’habitude de piocher des extensions qui existent déjà pour ne pas avoir à recréer la roue. Ma volonté, en publiant des extensions, était de pouvoir « donner » pour contrebalancer toutes les fois où j’ai « pris ».
L’histoire de l’extension « WP Sitemap Page », la plus populaire, parmi celles sur lesquelles j’ai travaillé, a été de créer une extension une page « plan du site » le plus rapidement et simplement que possible, pour les cas d’usages les plus courants. Il y a 7 ans, lors de la création de l’extension, il n’y avait qu’une seule autre extension qui permettait de créer un plan de site facilement, mais celle-ci imposait un lien vers le site de l’auteur, ce qui n’était pas très sérieux lorsqu’il faut livrer un site à un client.
Aujourd’hui je n’ai plus besoin d’y contribuer, car comme le dit l’expression populaire : « le mieux est l’ennemi du bien ». Tout ajout de fonctionnalités ne ferait que complexifier une extension qui répond déjà à la grande majorité des usages.

Lire la suite