Tagged Interview speaker

La parole est aux speakers : Martin Supiot

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

Your job is not to write code

Ne faites surtout pas ce que vous demande votre client ! C'est un brin provocateur mais si le client est roi, vous êtes à son service pour l'écouter ! Vous n'êtes pas juste un robot payé à la ligne pour écrire du code. Vos qualités humaines, vos conseils et le bon sens vous permettent d'aller plus loin et de rendre votre travail plus épanouissant et plus gratifiant.

Voyons comment rendre la meilleure copie possible pour votre client en l'accompagnant, de l'expression du besoin jusqu'au développement.

En ligne
03/07/2020
10:05-10:45

Ta conférence, intitulée « Your job is not to write code », peut-elle donner des pistes pour des personnes « non techniques » ?

Oui bien sûr, c’est aussi très formateur pour un chef de projet ou un commercial, ils doivent eux aussi savoir guider un client dans sa demande afin d’y répondre au mieux.

Ce sujet est-il lié à ton expérience avec des clients ?

C’est lié à 20 ans d’expériences, d’échanges avec des clients, des partenaires… Souvent le client ne sait pas exprimer son besoin, et sa demande n’est pas adaptée à ses besoins réels.

Tu soutiens l’AFUP depuis plusieurs années sous différents rôles, peux-tu nous en dire plus ?

L’AFUP a beaucoup apporté au début de ma carrière et j’aime échanger : il était donc important de consacrer du temps à organiser des évènements pour que d’autres en profitent et au vu du succès des dernières éditions, c’est un vrai plaisir de voir que l’association est vivante et évolue avec ses membres !

Le speaker

Martin SUPIOT
Martin SUPIOT
Architecte PHP, Martin est passionné par le web et l'open-source depuis le siècle dernier. Impliqué au sein de l'AFUP et de l'antenne Nantaise ces dernières années il ne rate pas une occasion d'échanger sur ces sujets, autour d'une bière belge de préférence !

Autres interviews

La parole est aux speakers : Sofia LESCANO

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

DevOps ? Je n'ai jamais voulu faire ça, et pourtant …

Développeuse junior : première semaine. Mes collègues m'ont forcée à déployer ma première feature sur 6play ! Malgré un petit frisson, tout s'est bien passé, grâce aux outils et bonnes pratiques qui nous guident.

Ce n'était que le début ! Depuis, je gère l'infrastructure de mon projet. Je choisis mes bases de données, caches, mécanismes de stockage, ressources… En prenant en compte leur coût, les modes de backups ou les compétences dans nos équipes. Et je suis libre d'expérimenter avec n'importe quel service que je voudrais tester.

En un an, je suis passée de "simple développeuse" à quelqu'un qui a conscience de sa plateforme, qui monitore son code et est responsable de sa production. Comment ai-je vécu cette transition ? Comment ai-je grandi en tant que développeuse ?

Vous aussi, profitez de votre nouvelle liberté : devenez DevOps !

En ligne
24/06/2020
11:15-11:55

Devops : est-ce un métier, une méthodologie ou une façon de travailler ensemble ?

Je dirais … demandez à Pascal Martin ha ha ! Blagues à part, je dirais que c’est un peu des trois, mais pour moi le plus important est que c’est une façon de travailler ensemble. Avant les devs et le ops étaient quelque part cloisonnés dans leur périmètre de travail. En devenant devops on prend en main et on se responsabilise sur notre infrastructure tout en se faisant accompagner par des experts sur le sujet. Les ops peuvent alors mieux comprendre notre besoin et nous, leurs propositions. On travaille ainsi main dans la main pour construire nos applications.

Est-ce que le devops a changé quelque chose dans ta manière d’architecturer ton code au quotidien ?

Je ne sais pas si cela a changé ma façon d’architecturer le code au quotidien en tant que tel mais cela a sans doute changé mon rapport au code et aux environnements de staging et production. Je me sens aujourd’hui beaucoup plus responsable de mon code et de son fonctionnement, tant en dev qu’en staging et en prod, environnements auxquels je n’avais pas forcément accès auparavant.

Est-ce que ce nouveau rôle devops était « imposé » par le mode de fonctionnement de ton équipe/entreprise ou est-ce un choix personnel qui t’a orienté vers tous ces nouveaux aspects ?

C’était un rôle imposé au moment où j’ai intégré l’équipe, mais aujourd’hui ce serait un choix personnel. C’est d’ailleurs le cœur de ma conférence et c’est ce que j’ai envie de partager.

Le speaker

Sofia LESCANO
Sofia LESCANO
Passionnée de mathématiques et de logique, Sofia a rejoint la communauté PHP il y a deux ans, après avoir travaillé sur des systèmes embarqués et développé des applications mobiles. Toujours à la recherche de nouveaux défis, elle developpe aujourd'hui des applications dans le cloud au sein de Code Rhapsodie.

Autres interviews

La parole est aux speakers : Benoit VIGUIER

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

6play_API-v2-Final(1).doc

Votre API est confrontée à des contraintes techniques mais elle doit surtout répondre à vos problématiques métier qui ne cessent d'évoluer. Nous avons souvent vécu cette situation pour 6play (service de Replay du Groupe M6), et il nous a fallu plusieurs générations d'API avant d'arriver à une version adaptée à nos besoins. Micro-services, Rest/GraphQL, Developer eXperience… Un récit et des conseils pragmatiques pour concevoir et maintenir votre API.

En ligne
24/06/2020
14:30-15:10

Tu es l’un des conférenciers les plus réguliers des évènements AFUP et nous t’en remercions ! Qu’est-ce qui continue d’animer ce sens du partage auprès de la communauté après toutes ces années ?

Lorsqu’on a un sujet à présenter qui nous tient à cœur c’est toujours un plaisir de le partager, surtout dans le cadre des évènements AFUP ! Je suis très content d’avoir pu être présent ces dernières années, mais cette régularité est aussi dûe à la chance : trouver un sujet qui m’intéresse, susceptible d’intéresser aussi les autres, de savoir comment le mettre en forme pour susciter l’attention du comité de sélection… Ça représente beaucoup de travail, de remises en question, qui finissent souvent par la déception de ne pas être retenu. Alors quand toutes les planètes sont alignées et qu’on a enfin l’opportunité d’aller jusqu’au bout, c’est une vraie satisfaction de pouvoir échanger avec les gens de la communauté qui ont les mêmes problèmes (ou les mêmes solutions). Et du coup on retente sa chance l’année d’après 🙂

Est-ce que le versionning des APIs permet d’être plus serein·e lorsqu’on conçoit une évolution, étant donné que cela peut autoriser plus facilement des ruptures et changements de comportements tout en limitant les effets de bords ?

De la manière dont je le pratique, le versionning d’API n’est rien de plus qu’une facilité de nommage pour éviter d’avoir à trouver un nouveau nom de domaine. En général on fait évoluer chaque API au maximum de ses capacités : on ajoute des routes, des nouveaux champs, parfois quelques nouveaux concepts, mais sans jamais casser nos contrats d’interface. Le jour où l’on se retrouve bloqué, où les évolutions deviennent trop coûteuses, ou que le besoin fonctionnel a divergé des motivations initiales, alors on réfléchit à une évolution majeure. C’est seulement à ce moment qu’on se pose la question philosophique (mais importante) de savoir s’il vaut mieux incrémenter le numéro de version, ou choisir un nouveau nom d’hôte pour API. Cette dernière solution est privilégiée quand le périmètre fonctionnel évolue de manière significative. La vraie difficulté, c’est de réussir à éteindre les vieilles versions pour de bon, car elles deviennent difficiles/coûteuses à maintenir et il est souvent difficile d’imposer ça aux utilisateurs. Le meilleur moyen reste de proposer une nouvelle API avec une vraie valeur ajoutée (plus de fonctionnalités, plus facile à utiliser, plus performante…) et de bien communiquer sur ces atouts. Pour l’anecdote, nous n’avons encore jamais dépassé la version 3 sur notre dizaine d’API, et nous avons réussi à éteindre une seule version 1.

Interface graphique, programmation asynchrone, tes différents retours montrent qu’on peut sortir des chemins balisés. Peux-tu donner un conseil, une méthode à une personne souhaitant utiliser un de ces outils de manière « non conventionnelle »?

Partir d’un besoin concret, qu’il soit professionnel ou personnel.
Regarder ce qui existe dans d’autres langages, faire de la veille, être curieux·se.
Avoir une bonne raison de le faire en PHP : c’est à partir de là qu’on prend des risques, surtout pour un projet professionnel. Si tout le monde utilise un marteau pour enfoncer des clous, pourquoi essayer avec autre chose? Il peut y avoir de vraies raisons, c’est au cas par cas… Mais j’avoue que pour mes projets personnels, je n’ai aucun remords à utiliser PHP à outrance juste pour le plaisir de faire tomber des préjugés !
Être prêt à être tout·e seul·e… C’est très rigolo d’être le·la premier·e à marcher dans la neige, mais si vous tombez sur un obstacle il n’y aura pas grand monde pour vous montrer le chemin. Dans mon cas, j’aime bien cette sensation que tout est à construire/imaginer, ça oblige à sortir de sa zone de confort et à revoir tout ce qu’on considère comme acquis sous un autre angle.
Proposer une conférence à l’AFUP bien sûr !

Le speaker

Benoit VIGUIER
Benoit VIGUIER
Lead Développeur Backend sur 6play, chez M6 Distribution. Initialement développeur 3D pour le jeu vidéo ou la CAO, mais reconverti dans le Web depuis 6 ans. Qu'importent les technologies, pourvu qu’on ait l'ivresse.

Autres interviews

La parole est aux speakers : Kévin Dunglas

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

Sauvons le Web : décentralisons !

Sauvons le Web : décentralisons !

Le Web a été conçu pour servir l’humanité, pour permettre le partage de connaissances, pour l’amitié entre les peuples. Seulement la centralisation des données et des services par les géants de la Silicon Valley l’ont totalement dénaturé et font peser des menaces immenses sur notre société : surveillance de masse, censure, trucage des élections, arrestations des opposants, fichage étatique et publicitaire.

La situation est telle que les pères fondateurs du Web, parmi lesquels son créateur Tim Berners Lee, multiplient les appels pour le sauver.

La solution : le décentraliser à nouveau, rendre aux utilisateurs le contrôle sur leurs données, lutter contre les monopoles des GAFAM, reconstruire un web indépendant et non-commercial en s’appuyant sur le logiciel libre. Développeurs, journalistes, juristes, artistes et activistes s’organisent pour faire émerger le « Dweb », le web (à nouveau) décentralisé. Le Dweb, c’est un corpus de standards (généralement portés par le W3C) tels que ActivityPub, JSON-LD, RDF ou HTTP ainsi que d’outils dont Solid, Mastodon, PeerTube ou Mobilizon qui visent à remettre le Web au service du bien commun. En tant que développeurs et développeuses web, c’est de notre responsabilité de le construire et de le promouvoir. La bonne nouvelle c’est que l’écosystème PHP dispose déjà des outils nécessaires pour créer des applications web décentralisées basées sur ces standards. Au cours de cette conférence, nous découvrirons pourquoi le Dweb est un enjeu crucial pour l’avenir de nos sociétés, comment ça marche techniquement, et comment on l’implémente avec API Platform, Vulcain, Mercure et autres outils du monde PHP qui le supportent déjà !

En ligne
26/06/2020
10:05-10:45

« Sauvons le Web : décentralisons ! » est une conférence qui sera assez différente de celles que tu donnes habituellement. Comment as-tu eu cette idée de sujet ?

Cela fait longtemps maintenant que je travaille sur le sujet du web en général, et du web des données en particulier. Déjà bien avant API Platform, j’avais longuement étudié et expérimenté avec RDF, les microformats, les ontologies ouvertes et de manière générale toutes les tentatives de pouvoir utiliser le web comme une immense base de données ouverte et interopérable.
Quand j’ai commencé à travailler sur API Platform, l’un de mes objectifs était de permettre aux développeurs·euses web de tirer partie de ces standards du web pour créer très facilement des API “Linked Data”. C’est pour ça que – par défaut – API Platform expose une API supportant JSON-LD, Hydra/LDF et Schema.org (les fondations modernes du web ouvert et décentralisé). Voir à ce sujet la conférence que j’ai donnée à SemWeb.pro il y a 2 ans.

Le web a été conçu dès le départ comme un outil décentralisé et distribué qui doit servir des objectifs politiques : le partage de connaissance, la compréhension mutuelle et l’amitié entre les peuples, l’avancée de la science et de la démocratie (réelle), la liberté d’expression et de communication. Tim Berners Lee, l’inventeur du web, décrit très bien l’utilité et les espoirs que son outil porte : “le web a donné aux groupes marginalisés une voix”.

Malheureusement, le web, et par la même occasion les données personnelles et la liberté d’expression de milliards d’utilisateurs·trices, sont désormais pris en otage par quelques multinationales de la technologie.
Il y a encore quelques années, tout le monde pouvait créer facilement son propre espace sur la toile à l’aide de HTML et des logiciels libres Linux, Apache, PHP et MySQL. Le logiciel libre et décentralisé WordPress permettait à tout un chacun de s’exprimer publiquement et de toucher une audience large sans craindre la censure, il popularisait même les rudiments du web des données. Le web libérait une énergie incroyable, permettait aux “groupes marginalisés” d’enfin toucher un public beaucoup plus large en court-circuitant les très verrouillés canaux médiatiques traditionnels. Le web c’était un foisonnement d’idées et de pratiques nouvelles (ou retrouvées), d’expérimentations techniques, organisationnelles, sociétales ou artistiques, une véritable contre-culture de masse. C’était un réseau maintenu et animé par des milliers de personnes, d’associations, de collectifs et d’entreprises.

Il était alors inimaginables que les géants Google, Apple, Facebook et Microsoft (et quelques autres) en prennent le contrôle quasi-complet, pratiquent la surveillance de masse de ce qui s’y dit, monétisent les données personnelles des internautes et censurent sans aucun contrôle. C’est pourtant ce qui est arrivé.

PHP: Hypertext Preprocessor, c’est LE langage de programmation du web. Et sauver le web, le décentraliser à nouveau, combattre la censure et surveillance de masse que ces multinationales et les États mettent en place, c’est aussi la responsabilité des développeurs et des développeuses. Des solutions techniques existent pour ça, et notre langage permet de les mettre en place relativement facilement, il est donc temps de les populariser. Voilà comment m’est venue l’idée de cette conférence.

Il s’agit d’un sujet plus politique que technique. Penses-tu que ce genre de sujet devrait davantage avoir sa place dans un événement comme l’AFUP Day ?

En l’occurrence, ce sujet sera à la fois politique et technique. D’abord je présenterai le contexte et les enjeux de la centralisation, et de la décentralisation nécessaire du web. Ensuite je présenterai les solutions techniques qui permettent d’y parvenir, et comment on les implémente en PHP.

Je présenterai le format ouvert ActivityPub, un standard du web basé sur JSON-LD et publié par le W3C qui permet de créer des réseaux sociaux décentralisés (Mastodon mais aussi PeerTube et Mobilizon de Framasoft utilisent ce format) puis le projet Solid, de Tim Berners Lee, qui vise à redonner aux utilisateurs·trices le contrôle de leurs données personnelles grâce au web de données.

La technologie en général et le web en particulier sont des sujets éminemment politiques. À l’heure de l’intelligence artificielle, de l’exploitation optimisée par les algorithmes de ceux qui subissent le “digital labor”, de la surveillance de masse à base de reconnaissance faciale et de la censure généralisée, il est plus que temps que les devs se rendent compte que le code qu’ils produisent a des conséquences. Nous avons une responsabilité importante et un pouvoir qu’il est grand temps de comprendre et d’assumer.
Multiplier ce type de sujets, rappeler l’esprit libertaire dans lesquels ont été créés le web et le logiciel libre, dénoncer et lutter contre les utilisations malfaisantes de la technologie me semble aujourd’hui complètement indispensable.

Après API Platform, Mercure, Vulcain… Quel(s) projet(s) nous prépares-tu pour 2020 ?

J’ai quelques projets dans les cartons. En particulier une petite bibliothèque JavaScript (désolé 😅) sur laquelle je bosse avec Thomas Colin qui va permettre de tirer partie au maximum de Mercure et de Vulcain côté client, et l’amélioration des mécanismes d’authentification et d’autorisation de Symfony et d’API Platform sur laquelle nous planchons avec Robin Chalas.

Peut-être aussi quelques outils aidant à décentraliser à nouveau le web, qui sait 😉.

Chez Les-Tilleuls.coop, tu donnes des formations en plus de développer tes projets. Comment arrives-tu à jongler entre ta propre montée en compétences et la transmission de tes connaissances à tes collègues et clients ?

C’est un peu lié. Je passe beaucoup de temps à faire de la veille, à tester les nouveautés des langages de programmation, des bibliothèques et des outils d’autres écosystèmes (Go, JavaScript, Kubernetes…), à lire les nouvelles (ou anciennes) spécifications ou papiers de recherche qui sortent. Ça me permet d’apprendre, et aussi de transmettre ce qui me semble intéressant, parfois juste en partageant les liens, parfois en écrivant des prototypes ou en préparant des formations pour trier ce qui est intéressant de ce qui l’est moins.

Le speaker

Kévin DUNGLAS
Kévin DUNGLAS
Kévin est le fondateur de la société autogérée Les-Tilleuls.coop. Il est membre de la core team Symfony, a créé le framework API Platform, les protocoles Vulcain et Mercure. Il est également contributeur à plus d’une centaine de projets Open Source.

Autres interviews

La parole est aux speakers : Julien SOLEILHAVOUP

em>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

A developer always pays his debts

Une conférence peu orientée vers la technique mais plus sur l'humain et sa relation au monde du travail. Va y avoir du drama ! De plus en plus de personnes sont exposées au burn-out, syndrome d'anxiété chronique au travail et les métiers de la tech ne font pas exception. Peut être même sommes-nous un peu des pionniers, alors c'est pas tout ça mais si on prenait un peu soin de nous ? Quelles sont les bonnes pratiques pour accompagner un jeune diplômé au sein d'une entreprise ? Pourquoi il est important d'accorder du temps à la résolution des dettes techniques ? Comment ne pas se "bruler les ailes" sur des projets ultra stimulants ? On parlera donc de bonnes pratiques de travail, de l'importance des temps de R&D mais aussi de gestion d'équipe, de cohésion de groupe et des bonnes adresses pour boire des bières entre collègues (en schématisant).

En ligne
24/06/2020
15:40-16:20

Donc ta conférence va nous indiquer comment éviter de détruire une ville avec un dragon sur un coup de tête, c’est cela ?

C’est à peu de chose près l’idée oui. En tout cas si on considère qu’un•e dév en burnout fera une partie de jeu de rôles pendant cette période et qu’iel décidera de passer ses nerfs et son anxiété sur des personnages fictifs et innocents.
Plus sérieusement, et parce que je pense que le sujet du burnout est extrêmement sérieux, faire cette conférence me tient à coeur depuis que j’ai fait moi-même un burnout et que je me répétais que c’était « ma faute », que j’étais pas assez bon, pas assez pointu et avancé dans ma pratique du code. J’ai réussi à m’en sortir et à retrouver du goût à mon métier en me rendant compte que je n’étais pas seul dans ce cas et que même des personnes qui, pour moi, sont des références, sont passées par là et pour les mêmes raisons.

Tu nous parleras de dette technique pendant cette conférence. Mais est-ce qu’une partie de la dette « technique » de nos projets n’est pas avant-tout une dette « fonctionnelle » ? Est-ce que savoir supprimer des fonctionnalités ne serait pas aussi une solution à bien des problèmes ?

Je pense que les solutions sont plurielles et qu’il y a une vraie problématique sur le désir d’usine à gaz que certains clients formulent. Donc oui, en effet réduire le scope des fonctionnalités dans un projet peut être une manière d’améliorer voir de ralentir le burn-in mais ça n’est pas une condition suffisante pour désamorcer ça. On va parler considération, challenge technique, salaire, sens du travail, valeurs… ça va être un peu dur de faire tenir ça en 40 petites minutes.

L’éco-conception numérique permet de mieux qualifier le besoin utilisateur pour le coder plus sobrement. Connais-tu cette méthodologie et penses-tu qu’elle peut permettre de réduire la dette technique de nos projets ?

J’avoue que je m’y suis fortement intéressé sans jamais avoir eu l’occasion de la mettre en pratique complètement. En tout cas avoir un code sobre, efficace et surtout maîtrisé permet sans aucun doute de réduire l’impression qu’on se bat contre des montagnes de bugs quand on est dev.

As-tu quelques conseils à donner pour mesurer et recueillir les retours autour du bien être au travail ?

Tes devs parlent de leurs projets en conférences avec enthousiasme ? C’est un signe de bien être.
Iels sont volontaires pour présenter des solutions techniques ? C’est un signe de bien être.
Mais pour ça il faut les envoyer en conférence et les laisser proposer des solutions techniques, après tout l’équipe technique est là pour ça.
Laisser les devs développer et faire leur travail et vous aurez du bien être au sein de l’équipe technique.

Le speaker

Julien SOLEILHAVOUP
Julien SOLEILHAVOUP
Développeur depuis 8 ans, passionné de veille technique et d'imagerie numérique mais pas que. Militant attaché aux questions d'accessibilité, d'inclusion et d'éthique dans le travail, il accorde une importance énorme à cet aspect dans son rôle de lead dev tout récent.

Autres interviews

La parole est aux speakers : Alexandre BALMES

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

La programmation défensive ou l'art de ne pas se faire confiance

Douze années d'expérience dans les métiers du développement PHP : beaucoup de ressenti, des succès, des échecs. Des projets internes, pour des tiers, des audits, de la formation, seul, (dans|au dessus|a coté) d'une équipe. Bref, un lot d'aventures qui forgent le caractère.

Tout cela a profondément marqué ma façon d'écrire des lignes de code, ajusté mon critère "qualité" et plus généralement, ma façon de concevoir des applications PHP. Comment est-ce que j'en suis arrivé à ne plus faire confiances aux autres (moi compris) et pourquoi ? Qu'est-ce que je cherche à garantir au travers de cette approche du développement ?

Nous verrons ensemble comment utiliser les règles de la programmation défensive et comment "protéger son code" dans le but d'en assurer la pérénnité tout en garantissant les objectifs suivants : un niveau de qualité sur le long terme, la possibilité de faire des évolutions simplement et un code sur lequel on aime intervenir.

En ligne
24/06/2020
09:20-10:00

Concernant ta conférence, est-ce qu’à l’image des tests, il est challengeant de trouver le juste milieu entre ne rien faire et surprotéger un code ?

Il y a nécessairement un juste milieu et c’est forcément sympa de réussir à le déterminer/trouver. Lorsque l’on aborde le sujet de la programmation défensive (et qu’on l’embrasse pleinement) on aborde surtout des sujets de conception, de qualité et donc de schémas directeurs.
Alors oui, si on fait un parallèle direct avec les tests, on peut prendre un cas d’école avec la validation d’un argument de type array : est-ce que l’on doit valider que l’argument est un array ? Que l’array doit contenir N clés ? Que chacune des clés attendues s’y trouve, etc. Malgré tout, le fait est que ce n’est qu’une petite partie du scope couvert par la programmation défensive parce que le problème n’est peut-être pas le contenu de l’array mais le simple fait d’utiliser un argument d’entrée qui est un array et à ce moment on parle de conception.
Ce qui est certain c’est que l’évolution naturelle de PHP et de sa communauté tendent vers la qualité. Toutes les pratiques sont donc naturellement plus défensives qu’avant. Ne rien faire sous-entend donc qu’on ne développe absolument pas suivant l’état de l’art et là on touche un autre problème.

Tu as indiqué passer régulièrement du temps à lire la documentation de frameworks à des fins de veille technologique. As-tu des recommandations de ressources concernant la programmation défensive afin de connaître l’état de l’art sur le sujet ?

Étrangement non. Il n’y a pas vraiment de littérature précise sur ce sujet, il n’y a rien qui me vient immédiatement à l’esprit. Il faut aller voir dans les ouvrages sur les tests, sur la qualité, sur le « clean »… pour tomber sur des chapitres où l’on vous explique tout simplement que faire son métier correctement, c’est aussi être « défensif » parce qu’être défensif c’est écrire des tests, de la documentation, un code SOLID, abstraire/composer… Et ne pas faire confiance aux développeurs·euses/aux données entrantes.
Je le disais dans la présentation de la conférence, mais il faut bien comprendre que pour arriver au niveau de conclusion qui m’amène à ce que je fais actuellement : c’est 5 à 6 projets par an, pendant presque 15 ans, en collaboration avec des équipes différentes à tout point de vue, et ça forge le caractère.
Spoiler publicitaire : les formations arrivent chez Vanoix cette année alors viens, on s’amusera bien ensemble à parler de conception, d’architecture et de programmation défensive. Ca fera une très bonne ressource sur le sujet 😜.

Tu nous proposes régulièrement des sujets lors de nos CFP. Cette année est la bonne ! Quelle est la recette selon toi pour un bon sujet ?

Alors là pour le coup… Je n’ai pas réussi à caser une conférence pendant un moment et pourtant j’ai essayé plusieurs fois 🙃.
En l’occurrence pour l’AFUP Day 2020 :
– J’ai fait relire le texte que j’ai proposé à trois personnes différentes en rectifiant ma copie à chaque retour ;
– Il n’y avait pas de thème, mais je demande toujours s’il y en a un pour me donner des chances supplémentaires ;
– Plus le temps passe, plus je pense que la légitimité est importante pour aborder certains sujets donc j’ai mis quelques sujets qui me tiennent à cœur (décentralisation et éthique par exemple) de côté plutôt que de chercher à tout prix à les caser.

Le speaker

Alexandre BALMES
Alexandre BALMES
Amoureux du web, cofondateur de Vanoix : un regroupement d’experts PHP “mais pas que”. Alexandre travaille sur des projets legacy dont les autres devs ne veulent pas. Conséquence directe, il possède un certain caractère, n'est pas toujours d'accord avec tout le monde mais globalement, on l’aime bien (même quand il dit des bêtises).

Autres interviews

La parole est aux speakers : Baptiste LEDUC

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

Avec Jane, simplifiez-vous la consommation d'API… et bien plus !

Chez JoliCode, tous nos projets utilisent Jane. Pourquoi ? Parce que tous nos projets utilisent soit API Platform, soit des DTOs, soit au moins une API externe.

Jane nous aide sur plusieurs parties des développements. Nous verrons ensemble, à base de cas réels, différents exemples d'utilisation de cette librairie qui est un véritable couteau suisse. Utiliser des modèles, denormalizers, client d'api deviendra facile et quasiment automatique à partir d'une simple documentation OpenAPI.

En ligne
03/07/2020
15:35-16:15

Tu vas nous parler du projet Jane utilisé pour appeller des API. D’où vient le nom de ce projet ?

À l’origine, Joël a crée Jane pour permettre l’exploitation de la Docker engine API. Il avait besoin d’une librairie pour générer un client API PHP à partir d’une spécification OpenAPI, et c’est ainsi que naquit Jane ! Jane c’est la contraction de « Janerator », qui lui-même vient de JoliCode -l’entreprise qui a sponsorisé le développement de cette librairie- et Generator.

Quel est ton regard sur l’écosystème d’outils des API en PHP ?

Aujourd’hui nous avons beaucoup d’outils en PHP tant bien pour consommer que pour créer des API. Du côté de Jane, on ne génère actuellement qu’un Client pour consommer ces API. Le seul réel équivalent est OpenAPI Tools qui propose son OpenAPI Generator. Mais leur Normalizer est propre à cette librairie : ils n’utilisent pas de contrat d’une autre librairie ou framework, ce qui, je trouve, le rends moins interopérable. Un des avantages de Jane est de se baser sur le contrat du Serializer de Symfony, ce qui lui permet de s’intégrer avec le framework de façon très simple. Côté génération serveur, on peut noter API Platform comme outil notable pour créer des endpoints sur nos entités. Il permet d’ailleurs de générer une spécification OpenAPI, ce qui permet ensuite de générer le client API via Jane 😉

J’ai lu sur le Github « Open Source time sponsored by JoliCode ». Qu’est-ce que ça signifie ?

Nous apportons beaucoup d’importance à l’open-source chez JoliCode et du coup, nous pouvons demander des jours dédiés au projet de notre choix. Jane a été crée et amélioré grâce à ces journées offertes par JoliCode. Nous avons d’autres projets du genre tels que Docker Starter ou encore JoliNotif.

Le speaker

Baptiste LEDUC
Baptiste LEDUC
En 2011, Baptiste débute sa vie professionnelle en écrivant des lignes de C++. C’est à cette période qu’il découvre le développement Web et notamment le PHP, language qu’il affectionne particulièrement depuis. Durant les années suivantes, il surf dans cet univers allant de framework en framework et de librairie en librairie, pour tenter d’étancher sa soif de connaissance. Il est maintenant chez JoliCode depuis 2018 pour des projets Web avec de fortes compétences sur la plateforme Symfony (et l’écosystème PHP en général). Vous pouvez facilement le croiser aux meetups parisien, il organise d’ailleurs les meetups de l’AFUP Paris. N’hésitez pas à venir lui parler de PHP, de serveurs, …

Autres interviews

La parole est aux speakers : Lucien BILL

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

Les devs viennent de Mars et les testeurs·euses de Vénus

Je suis testeur (il faut de tout pour faire un monde). Mais avant de passer du côté obscur de la force, j'étais développeur ! J’ai souvent assisté à des débats animés entre ces deux clans : les arguments rationnels sont vites éclipsés par des "vous codez avec les pieds" répondant à des "vous ne savez pas vous servir du programme" ! Dans un monde idéal, on se comprendrait tous et on travaillerait en harmonie. Et si, justement, on essayait de comprendre comment fonctionne un testeur ?

En ligne
03/07/2020
17:30-17:50

Ta conférence est intitulée « Les devs viennent de Mars et les testeurs·euses de Vénus ». Viens-tu de Mars ou de Vénus ? As-tu changé de planète ?

Je viens de Pluton : ce n’est ni Mars, ni Vénus, et ce n’est même pas une planète ! Quand j’étais lycéen, j’étais déjà un geek et je bidouillais des trucs sur les ordinateurs pour m’amuser, mais j’avais peur de travailler dans l’informatique : j’étais persuadé que si j’avais les yeux rivés sur un écran toute la journée, j’allais me lasser et ne pourrais plus profiter des jeux vidéo (spoiler : non, ce raisonnement ne tient pas la route). J’ai donc étudié afin de devenir ingénieur en mécanique, et j’ai découvert plusieurs choses :

1. les informaticien·ne·s ne sont pas les seuls à utiliser un écran toute la journée.
2. je travaille beaucoup mieux sur des sujets qui me passionnent
3. faire les calculs de résistance des matériaux pour dimensionner une poutre m’ennuie… Mais coder quelque chose qui le fait à ma place m’amuse beaucoup plus !

Quand j’ai cherché un emploi après l’obtention de mon diplôme, j’ai également prêté attention aux offres de reconversion dans l’informatique, et j’ai commencé ma carrière en tant que codeur pour un progiciel bancaire utilisant un langage propriétaire obscur. J’ai rencontré un mentor qui m’a appris à devenir développeur : mon travail alimentaire est devenu quelque chose dont j’étais fier. Le hasard a ensuite voulu qu’une place me soit proposée sur un projet de test : j’ai commencé à découvrir un nouveau métier. En bref : de bidouilleur, je suis devenu codeur, puis développeur, puis développeur testant de manière particulièrement rigoureuse ses portions de code, puis testeur codant des script pour automatiser certaines tâches.

Tu fais donc maintenant des tests : ton ancien poste de développeur ne te manque-t-il pas ?

Pas du tout ! Mais cela a plus un rapport avec le contexte social qu’avec le métier : pour beaucoup de raisons, je suis plus heureux à mon poste actuel de testeur. Je me sens également plus utile en tant que testeur et je travaille avec des outils plus modernes que quand je touchais à un progiciel dans un langage propriétaire ayant une communauté très restreinte. Et surtout, je triche : je me suis spécialisé dans les tests automatisés, donc je continue de coder !

Penses-tu que l’on donne suffisamment de place aux tests dans les projets informatiques actuels ?

Pour reprendre un ami normand, je répondrai « peut-être bien que oui, peut-être bien que non ». À la JFTL (Journée Française des Tests Logiciels) 2019, j’ai par exemple découvert comment SmartBear utilisait des pratiques de « Test Driven Developement » pour améliorer la qualité de ses produits. C’était très intelligemment fait, et le test était un outil vraiment bien exploité, au service de la qualité logicielle. J’ai également vu certains projets lutter pour tenter d’obtenir un niveau de qualité acceptable car tous les efforts étaient concentrés sur la production de nouvelles fonctionnalités, et le cycle de vie d’une évolution était « le développeur code et passe sur autre chose, quelqu’un teste pour vérifier que c’est bon, puis on livre ». Trouver une anomalie dans ce contexte équivalait à perturber tout le planning du développeur. Certains testeurs faisaient sciemment semblant de ne pas voir certaines anomalies, car ils étaient moins embêtés en laissant aller des bugs aller jusqu’en production et être détectés par le client, plutôt qu’en les signalant pour qu’ils soient corrigés avant livraison.
Se poser la question « pense-t-on suffisamment aux tests » est la première étape pour améliorer la qualité des applications.

Le speaker

Lucien BILL
Lucien BILL
Il était développeur, et il est progressivement devenu testeur. Vérifier la qualité d'un produit est très important, mais tout tester manuellement est compliqué, long, et peut vite le rendre fou : il s'est donc spécialisé dans les tests automatisés.

Autres interviews

La parole est aux speakers : Vincent BEAUVIVRE

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

L’amour en héritage !

Ah ! le code «legacy», comme on l’aime ! Ce moment merveilleux où l’on vous présente le projet avec un petit sourire en coin : «bon ça n’est pas basé sur la dernière techno à la mode, mais ça marche !». Alors on commence à prendre «ça» par un bout et on réalise le désastre :

  • Pas de versionning
  • Fichiers de plus de 3000 lignes que même les anciens n’osent plus toucher
  • Code tiers inclus dans le projet
  • Framework qui fait de la magie noire
  • Code mort J’en passe, et des meilleures !

J’ai moi-même connu ce type d’aventure en boulot et en perso, et j’aimerais partager avec vous quelques bonnes idées, et des mauvaises à éviter. On va parler de refactoring, de transition douce, d’amélioration continue, d’arbitrages techniques… Et c’est l’occasion de prendre un peu de recul aussi, pour penser global, mais agir local ! Pas pour la planète, mais pour le projet !

En ligne
19/06/2020
15:10-15:50

Cela fait plus de 20 ans que tu développes autour de PHP : comment as-tu vécu ces différentes années et traversé les évolutions du langage ?

Ouhla ! Je me considère vraiment comme un enfant de la communauté PHP : je suis arrivé au développement PHP par curiosité, sans aucun background, et j’ai grandi dans mon métier par mes rencontres et mes découvertes. Toutes ces années, c’était palpitant de suivre l’évolution du langage. À mon avis, PHP a trouvé une belle maturité de son système d’évolution, basé sur les RFC. Je me souviens aussi des flottements, comme PHP6 … Avec PHP7, la communauté est parvenu à un bon équilibre entre : retro-compatibilité, évolution fonctionnelle (ce qu’il fait), évolution technique (comment il le fait) et innovations. Ce qui me rend très optimiste quant à son avenir, surtout au vue des orientations de PHP8.
J’ajoute que j’aime beaucoup partager sur des problématiques typiques avec des développeurs d’autres langages, et découvrir d’autres solutions, ou d’autres problèmes 🙂

S’il ne fallait en retenir qu’une, y aurait-il une pratique que tu conseillerais pour limiter le code legacy ?

Aïe ! Mes amis ! Je crois bien que c’est peine perdue ! Votre meilleur code d’aujourd’hui sera vraisemblablement un boulet pour quelqu’un d’autre, ou pour vous même 😛
Gardez cela en tête ! Ça permet de garder du recul, un point de vue extérieur, pour épargner quelques cheveux blancs à vos successeurs. Arrêtez-vous parfois pour considérer l’ensemble du tableau. Peut-être que les meilleures bourdes ou les pires couplements vous sauteront aux yeux.

Comment as-tu fait pour obtenir du temps pour supprimer du code legacy ?

Ça fait parti du job. En général, je «vends» le refactoring avec des évolutions. Je défends l’idée de devoir faire une transition en me basant sur des problèmes récurrents de perf ou des difficultés de maintenance. Un socle de base de cohabitation entre ancien et nouveau système est mis en place. Puis on s’engage dans une voie dans laquelle, à chaque modification d’une partie de ce code (évolution ou debug important), cette partie sera simultanément transposée dans un «nouveau système». La pédagogie n’est pas de trop pour expliquer ce qu’est la dette technique et quel est son enjeu. Et parfois, je l’avoue, il est plus efficace de passer ces idées discrètement 😛

Le speaker

Vincent BEAUVIVRE
Vincent BEAUVIVRE
Vincent est un autodidacte qui a grandi et mûri depuis 20 ans au même rythme que PHP. Depuis le ```echo date('d/m/Y');``` en php 4, jusqu’aux designs patterns d’aujourd’hui, et en passant par le code spaghetti, le mvc, composer, les orms, le tdd puis le ddd. Rien ne lui a été épargné ! Pas même phpnuke, joomla, wordpress, prestashop, ou magento. Pourtant il en redemande encore 🙂

Autres interviews

La parole est aux speakers : Lætitia AVROT

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

Le I de ACID

Depuis les années 70, les bases de données relationnelles ont évolué, mais leur base théorique, elle, n'a pas évolué: ACID. Atomicité, Consistance, Isolation et Durabilité. L'isolation des transactions est bien souvent mal comprise alors qu'elle est presque toujours ajustable et permettrait de résoudre beaucoup de problème des développeurs et développeuses.

Après une description des différents niveaux d'isolation, nous verrons quelles anomalies peuvent survenir et quand utiliser quel niveau d'isolation. Votre base de données relationnelle peut faire beaucoup de choses que vous ignorez, changer le niveau d'isolation de certaines requêtes en fait certainement partie!

En ligne
24/06/2020
10:05-10:45

Les visiteurs et visiteuses de l’AFUP Day 2019 Lyon ont eu la chance d’assister à une de tes confs. Tu réédites l’exercice cette année. Quels retours as-tu eus suite à cette journée et as-tu des attentes à propos de l’édition 2020 ?

Avant de postuler pour AFUP Day 2019, j’étais morte de peur à l’idée d’aller parler dans une conférence de développeurs. Les conférences auxquelles je participe sont très orientées bases de données et, comme à chaque fois qu’on sort de sa zone de confort, la peur est là.
Les retours ont été très positifs dans le sens où j’avais visé juste: ces trésors du SQL étaient bien méconnus de la plupart des participant·e·s, mais je me suis aussi rendue compte que cette conférence aurait gagné à aborder moins de points mais plus en détails. J’ai tenu compte de cet aspect lorsque j’ai redonné cette conférence.
Cette année, la conférence qui a été choisie va se concentrer sur un des fondamentaux des SGBD relationnels: l’Isolation, le fameux I des propriétés ACID.

Peux-tu nous citer les différents niveaux d’isolation possibles afin de nous mettre l’eau à la bouche ?

Il existe dans la norme SQL 4 niveaux d’isolation des transactions: le READ UNCOMMITTED, le READ COMMITTED, le REPEATABLE READ et le SERIALIZABLE. Pour la plupart des SGBDR, le niveau par défaut est READ COMMITTED, qui est un bon compromis entre la performance et l’interaction entre les transactions, mais cela implique des conséquences pas toujours connues qui peuvent poser problème. Le niveau d’isolation peut être changé pour une transaction seulement et peut vraiment éviter d’ajouter des sur-couches aux applications.

Tu vas nous parler d’un concept établi il y a près de 40 ans et qui est pourtant mal connu ou mal utilisé. Penses-tu qu’il s’agit d’un défaut de formation, d’outillage parmi les développeurs·euses ou tout simplement que c’est lié au décalage de métier entre un·e développeur·euse et un·e administrateur·trice de base de données ?

Je pense qu’effectivement les formations se concentrent un peu trop sur les langages de développement alors que l’informatique est beaucoup plus riche que ça ! Il n’y a pas (en France ou dans le monde) de formation initiale d’administrateur•trice de bases de données, c’est un métier qu’on apprend directement en production avec les risques que cela implique… Il y a aussi toute une génération de développeurs·euses qui se reposent sur l’ORM pour écrire leurs requêtes (voire pour modéliser les bases de données). Je pense que c’est une mauvaise pratique qui engendre des gros soucis de performance ou d’intégrité des données, mais d’un autre côté, je ne suis appelée par les clients que lorsque ça va mal !

Le speaker

Lætitia AVROT
Lætitia AVROT
Lætitia Avrot est experte PostgreSQL chez EnterpriseDB. Elle est co-fondatrice du mouvement Postgres Women, membre du Postgres Advocacy Group et membre du Postgres Funds Group. Elle a aussi été pendant un an membre du comité du Code de Conduite de la communauté PostgreSQL. Elle a écrit plusieurs patchs pour le projet PostgreSQL et donne régulièrement des conférences dans des événements communautaires.

Autres interviews