Interview speaker

[: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

Se prémunir contre l’imprévisible : une analyse des failles les plus courantes en PHP Même avec des frameworks robustes et éprouvés, il est encore possible d’introduire des vulnérabilités dans les applications PHP.En prenant l’exemple de Symfony, et en se basant sur des cas concrets et inspirés d’histoires vraies, nous verrons qu’il est facile y compris pour des développeurs chevronnés de faire des petites erreurs aux conséquences potentiellement désastreuses. À la tête d’une équipe chargée d’aider nos 80+ développeurs à construire des applications sans failles, j’ai pu répertorier les meilleures (et les pires) pratiques pour faire du code sécurisé. Des contrôles d’accès bancals aux Cross Site Scripting involontaires, en passant par les injections DQL, nous verrons les principales vulnérabilités des applications Web peuvent s’introduire subrepticement dans une application PHP et, surtout, comment s’en prémunir. À la fin de ce talk, vous aurez les idées claires sur la surface d’attaque de votre code applicatif, et sur les manières les plus simples de se protéger efficacement contre les vulnérabilités les plus courantes. Vous aurez toutes les clefs en main pour apporter une réelle culture de sécurité aux développeurs de votre équipe.

Grace Hopper 24/10/2019 15:15-15:55

Quels sont tes premiers réflexes pour sécuriser une application PHP ?

Les premiers gestes ont lieu avant même de commencer à coder. Quand les devs conçoivent l’application, ils peuvent déjà se poser des questions comme : Quels problèmes peuvent survenir avec cette fonctionnalité ? Quel est le pire qui puisse arriver pour le métier ? Quelles données sont confidentielles ? Si j’étais un attaquant, qu’est-ce que j’aimerais réussir à faire ? En se posant ces questions, on met déjà le doigt sur des failles potentielles.

L’avantage de ces questions, c’est qu’elles ne sont pas techniques. C’est donc possible (et même essentiel) d’impliquer le métier dès le début sur ces problématiques. Cela permet d’aligner toute l’équipe sur les risques pour le produit. Et, mieux encore, l’idée que c’est important commence à germer dans l’esprit des responsables métiers, qui auront moins tendance à déprioriser des fonctionnalités liées à la sécurité ou des corrections de failles.

Il faut ensuite se fixer, en équipe, des standards de qualité, afin que tout le monde soit aligné. Comment gérer le contrôle d’accès ? Quelles restrictions s’imposer sur la construction de requêtes SQL sur mesure ? Comment gérer les erreurs ?

Pour ne rien oublier, l’équipe technique doit collaborer avec l’équipe sécurité. Mais cela ne doit pas empêcher les développeurs de faire de la veille et de chercher à savoir quelles failles ils peuvent introduire alors même qu’ils sont en train de taper sur leur clavier. C’est leur responsabilité en tant que professionnel·le·s !

(suite…)

[: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

Devenir un Lead Dev - Echecs et succès On demande beaucoup de choses à un Lead Dev/Tech Lead parfois même des choses qui sortent de son périmètre, de ses compétences. Il n'en demeure pas moins que ce rôle est crucial au bon développement d'un logiciel. Facilitateur de la communication avec les product owners, garant de l'architecture applicative, responsable du delivery, organisateur du travail, évangéliste... Les casquettes peuvent très vite être multiples et demander beaucoup de challenges pour une seule personne. Ce talk est un retour d'expérience de mon aventure en tant que Lead Dev produit chez Akeneo. Avec le recul, je ne ferai probablement pas toujours les mêmes choix. Certains étaient bons d'autres moins. L'idée est de les partager sur des exemples concrets de situation avec ce qu'il faut et ne pas faire.

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

Tu vas nous parler de ton rôle de lead dev et de ta transition vers celui-ci : as-tu quelques ressources à recommander et qui t’ont aidé dans ce changement ?

La transition a été très rapide et je me suis directement retrouvé sur un projet compliqué (je n’en dis pas plus, vous verrez ça lors du Forum PHP 2019 !). Du coup, je n’ai pas de ressources précises pour devenir Lead Dev. Je ne crois pas aux recettes magiques, il y a trop d’humain et de projets différents dans nos métiers pour que la théorie suffise. C’est justement ce qui rend le tout si intéressant.
J’ai regardé des talks et lu des articles sur les points, sur certains sujets et thématiques qui me préoccupaient ponctuellement, mais je pense que chaque situation est différente donc il faut s’adapter.
J’ai eu la chance de beaucoup échanger avec notre VP produit et les autres Lead Dev d’Akeneo. Ça m’a permis de mieux comprendre certains aspects et de travailler différemment avec tel ou tel développeur.
Histoire de donner quelques liens, il y a pas mal de conférences intéressantes sur le tech lead ici, le site de Ron Jeffries (l’un des fondateurs de l’XP), les méthodes de travail et l’agilité (en français). Actuellement, je lis pas mal de littérature autour des OKRs et sur le fait de mieux intégrer les développeurs dans la définition d’une solution puisque c’est ma problématique du moment.

(suite…)

[: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

Mercure, et PHP s'enamoure enfin du temps réel Mercure est un protocole réseau qui permet aux serveurs de « pousser » très facilement des mises à jour en temps réel. C'est un remplaçant moderne de WebSocket, qui dispose d'une caractéristique qui va particulièrement intéresser les développeurs PHP : contrairement à WebSocket, Mercure a été conçu dès l'origine pour fonctionner avec les plateformes qui ne peuvent pas maintenir de connexions persistantes, telles que PHP, ou le "serverless". Le protocole, qui a actuellement le statut d'Internet Draft, est donc très simple à utiliser avec notre langage préféré. Côté client, il est nativement supporté par tous les navigateurs modernes, sans même avoir besoin d'un SDK ou d'un paquet NPM. Mercure, contrairement à WebSocket, tire parti au maximum de HTTP/2 et de HTTP/3. Il est auto-découvrable, et a été conçu dès le départ pour être utilisé avec les API REST et GraphQL. Il dispose d’un mécanisme d’autorisation, supporte la re-connexion automatique et la récupération des messages perdus en cas de problème réseau. Depuis quelques mois, Mercure est officiellement implémenté par API Platform et Symfony. Au cours de cette présentation, nous découvrirons ce nouveau protocole et ses intégrations PHP.

Katherine Johnson 24/10/2019 16:25-17:05

Tu es l’auteur du protocole Mercure ainsi que de son implémentation de référence, qu’est-ce qui t’a donné envie de faire tout ça ?

L’idée m’est venue alors que je travaillais d’un côté sur le support de GraphQL dans API Platform et de l’autre sur un meilleur support de HTTP/2 pour Symfony (cf ma conférence de l’an passée au Forum PHP).

Côté API Platform, je cherchais un moyen de supporter les subscriptions GraphQL. Grâce aux subscriptions un client peut s’abonner aux modifications apportées aux ressources. Dès qu’une ressource surveillée est modifiée, le serveur “pousse” en temps réel la nouvelle version aux clients, qui peuvent instantanément l’afficher.

(suite…)

[: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

Symfony HttpClient vs Guzzle vs HTTPlug HttpClient est un nouveau composant publié avec Symfony 4.3. Qu'apporte-il par rapport aux solutions précédentes ? Je vous propose de le découvrir lors de cette conférence. Que pouvons-nous attendre d'un client HTTP à l'heure où la version 3 est en préparation ? Quels sont les cas d'utilisation envisageables, du plus simple aux plus ésotérique ? À travers des exemples comparés de code et des benchmarks de performance, nous allons disséquer les possibilités de chaque librairie pour vous permettre de faire le bon choix en toute connaissance de cause.

Katherine Johnson 25/10/2019 11:25-12:05

Ta conférence portera sur HttpClient, comment cette librairie se positionne t-elle vis-à-vis de PSR-18 et PSR-7 ?

HttpClient embrasse PSR-18, mais pas que. Il est ainsi très facile de l’utiliser avec une librairie qui dépend de la PSR. À dire vrai, c’est l’implémentation la plus avancée. PSR-7 est une dépendance de PSR-18, rien de particulier à ce sujet. Le paquet nyholm/psr7 est une excellente implémentation sans artifice, HttpClient l’utilise par défaut. Comme PSR-18 ne convient qu’aux requêtes HTTP les plus simples, HttpClient repose sur une autre abstraction, définie par symfony/http-client-contracts, qui couvre aussi les besoins les plus avancés. Pour découvrir sur quoi se basent ces promesses, il faudra venir voir ma conférence 🙂

(suite…)

[: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 pour des futurs souhaitables 2019 sera la dernière année qui ressemblera aux précédentes. Nous somme entré·es dans l'ère de l'Anthropocène, où nous humains sommes devenus une force géologique capable de modifier la planète, le climat et les dynamiques du vivant, et ce à nos dépens. Le design et la tech ont largement participé à l'exploitation des ressources naturelles et à l’accélération des cycles de production et de consommation. Nous actrices et acteurs des nouvelles technologies avons bien souvent perdu l’ancrage à la dimension systémique et politique de notre action. Nous avons malgré nous contribué à façonner ce monde prêt à s'effondrer... Il ne nous reste que peu de temps, c'est pourquoi nous vous proposons un moment de réflexion et d'introspection, mêlé à des voyages dans des temps futurs pour corriger nos biais négatifs sur le monde qui nous entoure et explorer ce que nous pouvons faire de mieux dès aujourd'hui. Nous vous proposons une invitation puissante à nous rassembler et nous questionner sur comment nous sculptons notre quotidien comme notre futur à travers nos métiers, au sein de notre industrie. Loin de nous l'idée de prôner la fin de la tech et de l'innovation : nous avons encore plein de cordes technologiques à notre arc que nous pouvons mobiliser différemment pour tracer les nouvelles règles d'un monde prospère, digne, résilient et circulaire. Cette intervention est le résultat de deux ans de réflexion et de recherches dont nous vous présenterons les premiers résultats pour agir dès maintenant et faire muter nos pratiques autant que nos paradigmes : des initiatives déjà existantes qui prouvent qu'on peut faire les choses autrement, des principes et heuristiques qui permettent de concevoir les bons outils pour des futurs différents, de l'inspiration pour faire muter profondément nos postures de conceptrices et concepteurs, etc.

Katherine Johnson 24/10/2019 17:10-17:40

En tant que développeurs et développeuses, quel est le plus grand changement que nous pouvons réaliser afin d’améliorer le futur ?

Thomas : Avant de vouloir améliorer le futur, peut-être faut-il tenter de comprendre le présent, l’existant. Porter un regard lucide sur celui-ci, et surtout sur l’impact que chacun•e d’entre nous a sur celui-ci pourrait être une première étape. Qu’est-ce que nous apportons au monde ? Quelles sont les conséquences de mon action sur celui-ci ? Quelles externalités je laisse derrière moi, à la charge de quelqu’un d’autre ou, pire encore, de personne. Les développeuses et développeurs, comme toutes celles et ceux travaillant dans nos industries, sont très souvent victime d’une fascination pour la technique et la technologie. Cette fascination ne se limite pas à un attrait très fort et aboutit bien souvent à un aveuglement. On en vient à confondre le progrès, comme amélioration de la vie des humains, avec une des modalités pour l’atteindre, la technologie. Les technologies que nous employons aujourd’hui sont très largement insoutenables et nous commençons à en payer le prix. Les développeurs et développeuses ont la capacité de créer des nouveaux outils, de nouvelles technologies qui puissent permettre de maintenir le niveau de progrès humain que nous connaissons, mais en respectant pleinement les limites planétaires.

Marie-Cécile : Au fil de nos recherches et de nos lectures, nous sommes de plus en plus convaincus qu’il n’existe pas UN changement plus efficace que les autres, mais une infinité d’actions, de remises en question, de réorientation de nos outils qui ont toutes leur importance à petite échelle. Améliorer notre futur est une tâche éminemment complexe et il serait malhonnête de faire croire qu’il y existe des réponses simples. C’est une belle réponse de normand, nous en avons conscience ! Par contre, il est vrai qu’une des pistes que nous proposons, c’est de commencer par le domaine que l’on a à notre portée et sur lequel nous avons le plus d’influence : nous-mêmes. Le premier changement vient de l’intérieur, nous invitons donc tout le monde à une saine introspection, notamment sur nos métiers et nos pratiques ! Dans quel imaginaire s’inscrivent-elles, quels systèmes servent-elles, quelles illusions continuons-nous d’alimenter à travers elles ? Qu’avons-nous à en tirer en tant que personnes ? Quels aspects toxiques contribuons-nous à maintenir malgré nous ? La liste est infinie 🙂

(suite…)

[: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

L'architecture progressive MVC, CRUD, ORM, SOA, DDD, CQRS, event sourcing, architecture hexagonale, micro-services… J'ai toujours couru après la solution optimale mais je n'ai encore jamais vu le projet parfait. Fini de courir. Et si la meilleure architecture ne dépendait pas de sa maintenabilité, son extensibilité ou sa testabilité, mais plutôt du contexte ? Le métier, la stratégie business, l'humain… Des variables pas toujours familières pour nous développeurs, alors qu'il existe des outils pour mieux les comprendre. L'architecture progressive se place en approche plutôt qu'en solution. Cette approche est libératrice : nous n'avons plus à opposer SQL et ORM, CRUD et DDD, façades et injection de dépendances ! Nous pouvons produire de la valeur ajoutée en mettant en face la qualité et l'effort approprié.

Katherine Johnson 25/10/2019 16:25-17:05

Taylor Otwell a récement annoncé le service en ligne Laravel Vapor, une surcouche au dessus AWS Lambda : au vu de ton travail sur ton sujet avec Bref, quel est ton avis sur ce produit ?

Quand on regarde la démo et la liste des fonctionnalités, ce que Taylor a fait est techniquement exceptionnel, surtout à l’échelle d’une/quelques personnes. Sa vision produit et UX est une source d’inspiration.
Au delà de ça, le positionnement de son produit est très ciblé et restreint, ce qui est compréhensible au niveau business. C’est un produit qui vise à faire scaler les applications Laravel. En se limitant à Laravel et en imposant des solutions sur l’architecture des utilisateurs, cela lui permet de fournir un service assez haut niveau. Parfait pour ceux qui font du Laravel et ont un problème de scaling.
Pour en avoir discuté avec des utilisateurs de Bref, les deux projets ont des publics a priori différents (Bref étant plus ouvert par nature). C’est positif je trouve, d’autant plus que cela démontre que l’orientation « serverless » arrive à maturité sur les stacks PHP.

(suite…)