[:fr]La parole est aux speakers : Mickaël Andrieu [:]

Publié le

[:fr]Jusqu’au Forum PHP 2019, 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

Concevoir des applications PHP résilientes en 2019

Vous souhaitez créer une architecture en micro services, ou une API REST et un joli front en React parce que c'est à la mode. Mais que se passe-t-il quand l'un de vos micro services tombe, ou si un de vos appels à votre API met un peu trop de temps à répondre ?

En gros, comment gérez-vous vous la résilience de vos applications ?

En vingt minutes, je vous montrerai comment faire : notamment à l'aide d'une librairie PHP que j'ai créée et qui est intégrée dans le projet Open Source PrestaShop.

Vous comprendrez comment fonctionne un "Circuit Breaker", comment le configurer et comment le tester.

A la fin de cette session, vous aurez les clés pour ne plus craindre les problèmes de réseau. Et vous aurez acquis un nouveau réflexe: penser au pire, pour garantir le minimum vital à vos utilisateurs.

Katherine Johnson
24/10/2019
12:10-12:30

Entre résilience et surarchitecture, as-tu quelques pistes pour trouver un équilibre qui semble juste ?

On peut mettre en place la résilience à différents niveaux, que ce soit au sein du logiciel que l’on développe ou imaginer prendre en compte les risques au niveau de l’infrastructure. La bonne nouvelle pour le développeur/se, c’est que si les design patterns liés comme le Circuit Breaker sont difficiles à concevoir, leur utilisation est simple ! Mon unique conseil, c’est de commencer : une fois le réflexe pris chaque équipe saura évaluer le degré de criticité à appliquer sur une situation donnée et un bon architecte saura décider s’il faut régler ce problème au niveau du logiciel, de l’infrastructure, voire les deux ! À ce propos, ne ratez pas la conférence de Pascal Martin !

Tu as contribué à des projets Open Source renommés, quels conseils donnerais-tu à un·e dev voulant apporter sa pierre à l’édifice pour la première fois ?

Je vais jouer l’avocat du diable pour une fois et je ne conseillerais pas de commencer par la doc. Écrire la documentation d’un logiciel est un exercice extrêmement difficile et pourtant très peu valorisé : comme si une fois le code mergé, le boulot était terminé alors qu’il ne fait que commencer…

Si vous souhaitez contribuer à un projet, c’est probablement que vous l’utilisez quotidiennement et que vous l’appréciez. Vous pouvez alors rencontrer et remonter de bons rapports de bugs : j’entends un scénario qui soit reproduisible par l’équipe de mainteneurs. Ensuite – et c’est aussi dommage que ce ne soit pas plus valorisé – vous pouvez parcourir les remontées de bug déjà existantes et les confirmer/compléter. Ce travail semble ingrat mais il est extrêmement précieux pour les mainteneurs/ses et vous permet ensuite (éventuellement) de documenter la partie améliorée/corrigée.

Tu vas bénéficier du programme d’accompagnement des speakers, avais-tu déjà entendu parler de ce programme avant la soumission de ton sujet et que t’a-t-il apporté jusqu’à présent ?

Oui j’avais entendu parler de ce programme sur les réseaux sociaux et pour partie lors d’une conférence de l’antenne bordelaise de l’AFUP. C’est extrêmement rassurant pour moi de pouvoir compter sur l’expérience et les conseils bienveillants d’un pilier de l’événement ! Pour l’instant – l’été étant propice aux vacances – je n’ai pas encore dérangé mon mentor mais il va m’aider à confirmer l’intérêt de mon plan de présentation, et il me fera des retours après une avant-première privée! Comment être inquiet après une telle préparation ?

Une conférence présentée par

Mickaël ANDRIEU
Mickaël ANDRIEU
Architecte et formateur, Mickaël est dans l'écosystème PHP et Symfony depuis 2011. Aujourd'hui, il s'intéresse essentiellement à la qualité logicielle! Il aime particulièrement le code SOLIDe et performant, les tests robustes et fiables et les outils d'analyse statique.

Autres interviews

[:]