Bienvenue à l'AFUP Day 2020 Lyon !

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.

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!

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 !

Le partage d'informations au sein des entreprises est souvent peu voire non existant. Et c'est bien dommage !

La bonne nouvelle, c'est qu'il existe des remèdes à cela. La mise en place de conférences internes permet, par exemple, de partager les connaissances entre tous les employés, transmettre la connaissance de l'activité et les expertises de l'entreprise... Mais pas seulement...

La mise en place de ce type d'activité demande du changement et de l'implication au sein d'une entreprise, ce qui peut être difficile à appréhender. Je souhaiterais partager avec vous mon retour d'expérience sur l'organisation de conférences internes, cela n'a pas été de tout repos. Mais je vous assure que ces efforts en valent la chandelle.

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.

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.

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.

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).

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 !

On se donne rendez-vous l'année prochaine ?