AFUP Forum PHP 2018 Baromètre Planète PHP

La parole est aux speakers : Sébastien Le Gall

Jusqu’au Forum PHP 2017, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils aborderont lors de leur conférence !

La conférence

19 millions de recherches par jour @ Meetic

Un moteur d’indexation au pays des événements et des microservices. Comment maintenir à jour un index Elasticsearch quand le ownership des données à indexer est distribué à travers de multiples micro-services? Comment requêter un index sur la base de paramètres qui sont, eux aussi, fournis par d'autres services? Comment faire quand l’ordre de réception des messages de mise à jour de l’index n’est pas forcément l’ordre d’insertion logique des données? Pour répondre à ces questions, je raconterai l’histoire de Jon et Ygritte en suivant un ensemble de parcours utilisateurs emprunté par des millions de personnes tous les jours sur nos plateformes. Nous verrons comment orchestrer Kafka, Symfony et ElasticSearch pour répondre à une volonté de découplage des micro-services et à une problématique de maintenance en temps réel d'un index. A chaque étape, je présenterai les différentes options envisagées, nos contraintes (traffic, performance, robustesse) et les choix que nous avons fait dans une logique agile de développement itératif.

Salle Katherine Johnson
27/10/2017
10:15-10:55

PHP est-il ton language de prédilection ? Tu as écrit des projets en GO, peux tu nous parler un peu de ce langage ?

J’ai commencé le développement avant les études supérieures, PHP est le premier langage que j’ai maîtrisé car c’est un bon outil pour se former et aujourd’hui je l’utilise au quotidien. Lorsque je suis rentré sur le marché de l’emploi, le NodeJS n’était pas aussi répandu qu’aujourd’hui. Mes premiers projets étaient donc basés sur des frameworks PHP. Avec l’expérience, j’ai cherché à travailler dans un environnement plus mature, sur des produits web plus développés et surtout dans une entreprise dont le business est centré sur son propre produit. Or, aujourd’hui, PHP est emblématique de ce type de produits. Quand on regarde les entreprises françaises du web qui réussissent – je ne parle pas de start-up aux 4 millions d’utilisateurs sans aucun revenu – ; lesquelles ne font pas de PHP? Blablacar, Deezer, Meetic, Dailymotion, etc. toutes ces entreprises ont mis en place et maintiennent du PHP au coeur de leurs systèmes.

Il faut être réaliste sur les forces et les faiblesses de PHP, et de façon générale sur tous les langages de scripting et/ou stateless. Je suis convaincu que PHP accompagné d’un bon framework – bien utilisé – est un choix judicieux pour développer un site web ou un web service, même aujourd’hui. Slack a d’ailleurs très bien su l’expliquer et je le vois au quotidien chez Meetic. Néanmoins, à l’heure de l’Agile et des équipes pluridisciplinaires orientées feature, il faut savoir laisser de côté le PHP et utiliser les bons outils pour les bons usages. Il m’est déjà arrivé de développer un worker (un consumer amqp) en PHP. Avec le recul… c’était l’horreur. Dans des cas comme ceux-ci, il faut se poser la question de l’outil.

Le développement ne se résume plus à écrire des lignes de codes sans prendre part à la conception et au contexte business du produit. Un développeur – d’ailleurs appelé « software engineer » dans les pays anglo-saxon – doit savoir « construire » un produit. Cela nécessite de développer des web services, mais aussi toute une gamme d’outils permettant de faciliter le développement, l’intégration continue, le déploiement, etc. Cette composante du développement logiciel se rapprochant du domaine de l’ops ne peut pas être satisfaite par des outils comme le PHP et relève pourtant de la responsabilité du développeur.

L’Agilité a mis en lumière l’intérêt des équipes pluridisciplinaires où chacun prend part dans toute la chaine de conception d’un produit. Cela ne fait plus sens d’être « développeur PHP » ou « développeur Java ». On est développeur tout court. Le choix de la technologie dépend de l’usage. À chaque use case le bon outil. C’est là que le Go entre en scène, pour ma part.

Comme tout autre langage, Go ne peut pas répondre à tous les problèmes. Mais, la nature même de ce langage le rend très adapté à beaucoup d’utilisations. La tendance montre néanmoins que Go est très utilisé pour développer des outils systèmes et/ou distribués. Une alternative pourrait être le python, mais au moins 3 raisons expliquent l’essor du Go dans ce domaine :
Sa syntaxe très proche des langages de scripting le rend très facile à écrire.
La cross-compilation permet des générer des binaires utilisables sur n’importe quel OS et contenant le runtime. (Ce qui a pour effet indésirable de produire des binaires très gros).
La gestion de processus concurrent extrêmement simplifiée permet de développer des outils très performants en quelques lignes seulement.
Par ailleurs, je m’intéresse de près à la logique de containérisation des applications. Docker ainsi que tous les outils permettant de distribuer des containers sont écrit en Go. Comprendre ce langage est un bon moyen de suivre les évolutions de ces technologies.

Néanmoins, si on me posait la question, je ne choisirais pas Go pour réécrire l’ensemble des microservices chez Meetic. À mon sens, il y a deux principales raisons qui expliquent pourquoi Go est surtout utilisé chez les « cadors ». La première concerne le système de gestion de dépendance : les outils existants sont bien moins matures que Composer. L’autre est liée aux designs pattern et à l’organisation du code : la communauté Go n’est probablement pas encore assez mature et de ce fait, aucune organisation de code ni aucun design pattern ne se sont vraiment imposés. Autant le code de Symfony et le code de Guzzle sont très proches, autant le code de Kubernetes et le code de Revel (framework full-strack en Go) n’ont rien à voir.

En attendant, je pense que Go est un bon choix pour développer des APIs REST servant à piloter des outils systèmes, des outils distribués ou bien encore des microservices effectuant une tâche simple comme cropper des photos en masse. »

Tu es Tech Lead à Meetic : quel est ton rôle ? Comment se passent tes journées ?

La définition de Tech Lead chez Meetic n’est pas vraiment arrêtée. Cela correspond à un degré de maturité plus qu’un rôle ou une fonction. Si je devais choisir une expression caractérisant mon quotidien ce serait « getting real », le titre du premier livre publié par 37Signals.

J’essaye de faire en sorte que notre produit fonctionne, apporte de la valeur à l’utilisateur, et continuera à le faire. Cela peut paraître flou pour certains, habitués à travailler dans des systèmes organisationnels plus classiques mais, si l’on se place du point de vue d’un « software engineer » cette définition prend plus de sens.

Mon but, comme chaque développeur, est d’apporter de la valeur aux utilisateurs. Cela signifie développer un produit de qualité et, en même temps, apporter des nouveautés et des évolutions à ce produit le plus rapidement possible. Mon rôle est donc de mettre de l’huile technique un peu partout dans les rouages des équipes. Quand un Product Manager n’a pas envisagé tous les cas possibles pour une feature (souvent dû à la complexité technique sous-jacente), mon rôle est d’organiser un workshop pour lever les loups. Quand, sur une feature, je pressens un problème de scalabilité ou de maintenabilité, mon rôle est d’inclure un architecte dans la réflexion. Quand le ratio valeur apportée à l’utilisateur / complexité technique n’est pas satisfaisant, mon rôle est de lever une alerte ou de trouver une meilleure solution technique. Cela peut se faire en prenant des raccourcis assumés – en mettant en place des gardes fous – , ou en challengeant la technologie utilisée, les designs patterns etc. Enfin, bien sûr, mon rôle est de développer le produit Meetic.

Le job de Tech Lead back-end n’est pas différent du travail de développeur. C’est l’expérience, la capacité à anticiper, la maturité et l’esprit d’initiative qui font le leadership bien plus qu’un titre sur un contrat de travail.

Chacun a ses domaines de prédilections. Pour ma part, je m’intéresse beaucoup à l’aspect tooling. C’est à dire à la fois faciliter la création et la maintenance d’un environnement de développement, d’une chaine d’intégration continue mais aussi une chaine de déploiement en production. Je suis aussi relativement attentif à l’aspect testing. D’autres Tech Leads sont plus focalisés sur l’organisation du code et/ou les designs patterns.

En cela, mes journées ne sont pas tellement différentes de celles de mes collègues. Le SCRUM a ses rituels et les équipes chez Meetic n’y dérogent pas. Je participe sans doute à plus de réunions en amont pour aider à borner techniquement les projets, mais j’essaye d’en limiter le nombre. Le reste du temps, je fais des dessins sur un tableau blanc, je relis du code, je teste un développement et challenge les solutions techniques. Au début j’essayais de dégager un maximum de temps pour travailler en autonomie sur des features. Mais, aujourd’hui, j’essaye de passer plus de temps à fluidifier le travail de tout le monde. Le développement des features, je le fais plus souvent en pair programming.

En parallèle de mon travail chez Meetic, je fais beaucoup de veille. Je lis, je lance de nombreux side projects indirectement liés à Meetic ; souvent ils n’aboutissent pas, ou de façon éphémère, mais ce n’est pas le but recherché car ils me servent à tester des idées, à approfondir une lecture ou simplement à comprendre une technologie. »

Tu te revendiques utilisateur d’EMACS, ce qui est courageux ! Qu’est-ce qui t’a séduit dans EMACS ? 🙂

Oui, je revendique l’utilisation d’Emacs. Mais, pour être honnête, je ne l’utilise plus pour développer en PHP. Je ne suis pas non plus un dogmatique d’Emacs contre Vi. Les deux sont de très bons éditeurs.

J’ai découvert Emacs en m’intéressant aux logiciels libres et en particulier à Richard Stallman, à l’âge de 16 ans environ. Plus tard, j’ai fait un stage de Terminale dans l’équipe R&D de Talend où travaillait mon cousin. Lui n’utilisait qu’Emacs, y compris pour lire ses mails et chatter sur IRC ! Cela m’a donné envie d’approfondir.

Avec les années, j’ai appris à m’en servir pour faire un peu tout. Avec le recul, je suis persuadé que l’apprentissage d’un éditeur non graphique comme Emacs ou Vi est un pré-requis pour être vraiment efficace.

De mon point de vue, un développeur doit maîtriser son environnement de développement. Quand on fait du PHP en particulier, il faut savoir jongler avec des outils comme Vagrant, Docker, PHP, Nginx etc. Cette maîtrise permet de mieux comprendre les comportements inattendus en production. Tous ces outils sont des outils système dont la configuration se fait par des fichiers de configurations ou des scripts qu’on ouvre plus facilement dans un terminal. Utiliser un éditeur non graphique est un gain de temps. Cela sert aussi de savoir utiliser correctement un bon éditeur pour tester du code directement sur un serveur distant.

Les éditeurs non-graphiques sont de vrais boosters de productivité. Emacs et Vi ont été développés dans les années 70, à l’époque la souris n’existait même pas. Avec le temps, les enrichissements apportés ont fait de ces éditeurs des bêtes de courses sur-puissantes. Dans Emacs, notamment, les commandes clavier ont été pensées pour aller le plus vite possible.

Je vois très – trop? – souvent de jeunes développeurs utiliser des IDEs colossaux sur des Intel i3 avec 4Go de RAM, la main sur la souris en permanence. Pour moi qui ai pris l’habitude de tout faire au clavier… tout parait prendre infiniment plus de temps en les regardant. Et, de fait, il faut beaucoup plus de temps pour déplacer la main sur la souris, trouver le curseur, déplacer la souris, cliquer sur l’arborescence de fichier et ouvrir le bon fichier qu’en utilisant une commande clavier d’auto-complétion du nom du fichier. Utiliser un éditeur non-graphique nous oblige à réfléchir. Et, bien que les éditeurs modernes proposent leurs lots de raccourcis, prendre l’habitude de n’utiliser que le clavier, au début au moins, est une bonne chose.

Un dernier argument à l’utilisation d’Emacs est son incroyable capacité à tout faire, une fois bien configuré. Un exemple concerne les clients REST : aujourd’hui, Postman s’est imposé comme la référence, mais Emacs propose aussi un client REST avec lequel il est beaucoup plus facile de manipuler le JSON de retour. Sans parler de la recherche d’expression régulière dans un fichier d’1Go… aucun autre éditeur n’est capable de faire cela.

Pendant plusieurs années de ma vie professionnelle j’ai donc utilisé Emacs pour tout faire. J’ai créé ma propre configuration adaptée au framework Symfony, mes propres raccourcis, etc. Seulement, contrairement à Go, PHP n’a pas d’outil permettant de naviguer dans le code facilement : d’aller de l’utilisation à la déclaration, de naviguer entre les classes, etc. JetBrains a gagné le monopole en intégrant à PhpStorm son système de découverte du code. J’ai réussi à reproduire un comportement s’approchant de cela dans Emacs, en me basant sur les e-tags et en stockant les tags dans des fichiers d’index à la racine du projet. Mais… c’était trop difficile à maintenir.

Aujourd’hui j’utilise donc PhpStorm pour travailler sur des projets PHP (et IntelliJ pour Java/Scala). Pour tout le reste… lorsque que je travaillais encore sous Linux je n’utilisais qu’Emacs. Mais depuis un an, j’ai migré sous Mac et, il faut le dire, l’intégration d’Emacs n’est vraiment pas simple. J’utilise donc Visual Studio Code ou Vi, qui est beaucoup plus facile à utiliser sous OS X.

Le speaker

Sébastien LE GALL
Sébastien LE GALL
Tech Lead Back-end @ Meetic

Autres interviews

En poursuivant votre navigation sur ce site, vous acceptez l’utilisation des cookies pour améliorer votre navigation. plus d'infos

1. Qu’est-ce qu’un cookie?

Un Cookie est un petit fichier texte enregistré sur votre terminal (ordinateur, tablette, smartphone, etc.), à l’occasion de la consultation d’un service en ligne grâce à votre logiciel de navigation. Il permet à son émetteur d’identifier le terminal dans lequel il est enregistré, pendant la durée de validité ou d’enregistrement du Cookie. Lors de la consultation de notre site Internet, des informations relatives à la navigation de votre terminal sont susceptibles d'être enregistrées dans ces fichiers dits "Cookies". Ces derniers sont installés sur votre terminal, sous réserve des choix que vous auriez exprimés concernant les Cookies et que vous pouvez modifier à tout moment.

2. A quoi servent les cookies émis sur notre site ?

Seul l’émetteur d’un cookie est susceptible de lire ou de modifier les informations qui y sont contenues.
Les cookies utilisés sur notre site permettent :

3. Vos choix concernant les cookies

Vous disposez de différents moyens pour gérer les cookies. Tout paramétrage que vous pouvez entreprendre sera susceptible de modifier votre navigation sur notre site et sur Internet en général et vos conditions d'accès à certains services de notre site nécessitant l'utilisation de cookies. Vous pouvez à tout moment exprimer et modifier vos souhaits en matière de cookies, par les moyens décrits ci-dessous. L'accord sur les cookies L'enregistrement d'un cookie dans un terminal est essentiellement subordonné à la volonté de l'utilisateur du terminal, que celui-ci peut exprimer et modifier à tout moment et gratuitement à travers les choix qui lui sont offerts par son logiciel de navigation. Si vous avez accepté dans votre logiciel de navigation l'enregistrement de cookies dans votre terminal, les cookies intégrés dans les pages et contenus que vous avez consultés pourront être stockés temporairement dans un espace dédié de votre terminal. Ils y seront lisibles uniquement par leur émetteur.

Le refus des cookies Si vous refusez l'enregistrement de cookies dans votre terminal, ou si vous supprimez ceux qui y sont enregistrés, vous ne pourrez plus bénéficier d'un certain nombre de fonctionnalités qui sont néanmoins nécessaires pour naviguer dans certains espaces de notre site. Tel serait le cas si vous tentiez d'accéder à votre compte ou à votre abonnement qui nécessite de vous identifier. Tel serait également le cas lorsque nous, ou nos prestataires, ne pourrions pas reconnaître, à des fins de compatibilité technique, le type de navigateur utilisé par votre terminal, ses paramètres de langue et d'affichage ou le pays depuis lequel votre terminal semble connecté à Internet. Le cas échéant, nous déclinons toute responsabilité pour les conséquences liées au fonctionnement dégradé de nos services résultant de l'impossibilité pour nous d'enregistrer ou de consulter les cookies nécessaires à leur fonctionnement et que vous auriez refusés ou supprimés. Les choix offerts par votre logiciel de navigation Vous pouvez configurer votre logiciel de navigation de manière à ce que des cookies soient enregistrés dans votre terminal ou, au contraire, qu'ils soient rejetés, soit systématiquement, soit selon leur émetteur. Vous pouvez également configurer votre logiciel de navigation de manière à ce que l'acceptation ou le refus des cookies vous soient proposés ponctuellement, avant qu'un cookie soit susceptible d'être enregistré dans votre terminal. Pour la gestion des cookies et de vos choix, la configuration de chaque navigateur est différente. Elle est décrite dans le menu d'aide de votre navigateur, qui vous permettra de savoir de quelle manière modifier vos souhaits en matière de cookies. Selon votre navigateur, consultez le lien ci-dessous pour configurer votre navigateur et refuser les cookies :