[:fr]La parole est aux sponsors : Klaxoon[:]

[:fr]Nous avons le plaisir d’accueillir Klaxoon en tant que sponsor du Forum PHP 2019, l’occasion pour nous d’en savoir un peu plus à leur sujet au travers de cette interview. Pierre Pagadoy, Directeur R&D chez Klaxoon, répond à nos questions.

Klaxoon veut révolutionner le travail collaboratif à travers des outils innovants. Utilisez-vous également des outils innovants pour mener à bien vos développements et si oui, lesquels ?

La mission de Klaxoon, c’est de faire en sorte que les gens collaborent plus efficacement, et depuis 2015 nous développons une gamme complète de produits collaboratifs. À la fois Hardware et Software, nos outils ont été adoptés par des millions d’équipes dans le monde afin d’améliorer leur efficacité en réunion, ateliers, formation, dans toutes leurs sessions de travail. Jusqu’à maintenant, les outils existants pour faciliter la collaboration s’étaient concentrés autour de l’axe communication, mais à l’époque du multi-site, du multi-équipe, du multi-projet, Klaxoon offre aux équipes une nouvelle manière de se synchroniser.
Au quotidien chez Klaxoon, ce sont plus de 230 personnes qui développent et accompagnent notre communauté d’utilisateurs dans la transformation de leurs pratiques. Nous sommes devenus l’un des plus grands laboratoires de technologies collaboratives au monde. Nos produits innovants ont été primés à de multiples reprises en France et à l’international. Nous-même sommes de grands utilisateurs de nos outils ! Dans chacun de nos bureaux les équipes disposent de MeetingBoard, un écran tactile géant que l’on peut déplacer dans l’espace de travail au rythme de l’équipe et bien sûr, dans le quotidien Klaxoon est la plateforme que nous utilisons pour piloter les projets, les sprints, les daily et les rétrospectives. On gagne du temps, on peut travailler efficacement avec les équipes qui sont en remote, c’est notre reflex efficacité.

(suite…)

[:fr]La parole est aux sponsors : Eleven Labs[:]

[:fr]Nous avons le plaisir d’accueillir Eleven Labs en tant que sponsor national du Forum PHP 2019, l’occasion pour nous d’en savoir un peu plus à leur sujet au travers de cette interview. Elsa Berry, Directrice Culture et Organisation chez Eleven Labs, répond à nos questions.

Cela fait plusieurs années que vous nous accompagnez sur nos événements et nous vous en remercions ! Nous avons également l’habitude de vos animations originales, en avez-vous prévu pour ce Forum ?

Oui, c’est vrai qu’Eleven Labs a un attachement tout particulier au Forum PHP, on y revient chaque année avec toujours autant de plaisir !
Pour cette année, on a prévu de faire sauter Félix Baumgartner depuis la stratosphère, afin qu’il atterrisse sur le stand en parachute, le tout déguisé en Wilson. On est encore en pourparlers avec le service de sécurité.

(suite…)

[:fr]La parole est aux speakers : Paul Molin[:]

[: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]La parole est aux sponsors : Blackfire[:]

[:fr]Nous avons le plaisir d’accueillir Blackfire en tant que sponsor national du Forum PHP 2019, l’occasion pour nous d’en savoir un peu plus à leur sujet au travers de cette interview. Christophe Dujarric, Chief Product Officer chez Blackfire, répond à nos questions.

Blackfire est un outil pouvant être utilisé aussi bien en production qu’en test/staging et développement : Pouvez-vous nous en dire plus ?

Blackfire est un outil de mesure de consommation de ressources par le code PHP.

Il est clé de pouvoir utiliser un tel outil sur une machine de développement, car cela permet à un développeur de travailler rapidement, d’essayer de nouvelles idées pour optimiser son code tout en les validant via la comparaison de profils.

Et il est aussi clé de pouvoir effectuer des mesures directement en production. C’est là qu’il y a les vraies machines, la vraie configuration, DB, etc… Le point est d’éviter d’en rester à « ça marche sur mon poste ». Un des avantages techniques de Blackfire est qu’il est possible de générer des profils sans le moindre impact (overhead) pour les utilisateurs finaux : l’instrumentation du code, qui permet de collecter les métriques de consommation, se fait uniquement pour les requêtes déclenchées à des fins de profiling. Pas d’instrumentation des requêtes d’utilisateurs finaux, pas d’overhead.

La cerise sur le gâteau est d’utiliser Blackfire dans tout pipeline de test/staging. Blackfire offre de multiples possibilités d’automatiser le profiling (notamment via le Blackfire Player), ainsi que d’écrire des tests de performance, très similaires aux test d’intégration ou tests unitaires. Ces tests peuvent d’ailleurs aussi être exécutés directement en production. Le bénéfice est double : automatisation complète du profiling (plus qu’à attendre les résultats) et statut rouge/vert des tests (identification rapide des goulots d’étranglement).

(suite…)

[:fr]La parole est aux speakers : Romain Monceau[:]

[: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]La parole est aux speakers : Kévin Dunglas[:]

[: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]La parole est aux speakers : Nicolas Grekas[:]

[: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]La parole est aux speakers : Marie-Cécile Godwin et Thomas di Luccio[:]

[: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]La parole est aux speakers : Matthieu Napoli[:]

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