[:fr]La parole est aux speakers : Sébastien Le Gall[:]

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

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.

Une conférence présentée par

Sébastien LE GALL

Tech Lead Back-end @ Meetic

Autres interviews

• La parole est aux speakers: Pauline Vos
• La parole est aux speakers: Vincent Lepot
• La parole est aux speakers: Martin Supiot
• La parole est aux speakers : Nicolas Grekas
• La parole est aux speakers: Pascal Martin
• La parole est aux speakers : Derick Rethans
• La parole est aux speakers : Gina Banyard
• La parole est aux speakers : Loïc Frémont
• La parole est aux speakers : Julien Joye
• La parole est aux speakers : Alexandre Morgaut
• La parole est aux speakers : Audrey Brouard
• La parole est aux speakers : Vincent Bontems
• La parole est aux speakers : Grégoire Pineau
• La parole est aux speakers : Fabien Paitry
• La parole est aux speakers : Enrique Nerea
• La parole est aux speakers : Antoine Bluchet
• La parole est aux speakers : Kauffmann Thierry
• La parole est aux speakers : Dolbeau Olivier
• La parole est aux speakers : Charles FOL
• La parole est aux speakers : Noback Matthias
• La parole est aux speakers : Alexandre Daubois
• La parole est aux speakers : Benoit Viguier
• La parole est aux speakers : Agé Marion
• La parole est aux speakers : IATSUN Iana
• La parole est aux speakers : Vizinho Adriana
• La parole est aux speakers : EYMONOT Felix
• La parole est aux speakers : Veyron Albane
• La parole est aux speakers : Coquard Cyrille
• La parole est aux speakers : Smaïne Milianni
• La parole est aux speakers : Ambroise Rougier
• La parole est aux speakers : Lætitia Avrot
• La parole est aux speakers : Yann Jacquot et Alexis Stefanski
• La parole est aux speakers : Frederic Bouchery
• La parole est aux speakers : François Zaninotto
• La parole est aux speakers : Robin Chalas
• La parole est aux speakers : Rachid Hammaoui
• La parole est aux speakers : Valmont Pehaut-Pietri
• La parole est aux speakers : Tiphaine Perra et Anthony Demangel
• La parole est aux speakers : Florian Bogey
• La parole est aux speakers : Valentin Silvestre
• La parole est aux speakers : James Hemery
• La parole est aux speakers : Arnaud LAHAXE
• La parole est aux speakers : Kevin BALICOT
• La parole est aux speakers : Kévin DUNGLAS
• La parole est aux speakers : Arnaud Langlade
• La parole est aux speakers : Julien REDEL
• La parole est aux speakers : Alexandre Daubois
• La parole est aux speakers : Pascal Chevrel
• La parole est aux speakers : Iana Iatsun
• La parole est aux speakers : Emilien Bouard