Entretien avec Tarek Ziadé, engineering manager pour Mozilla Corporation et Pythoniste

Jdh : Bonjour Tarek et merci de participer à cet entretien pour le Journal du hacker. Pour nos lecteurs qui ne te connaissent pas, peux-tu te présenter rapidement ?

Tarek : Je suis développeur depuis une quinzaine d'années et je me suis spécialisé dans le langage Python il y a un peu plus de dix ans.

Je me suis passionné pour l'open source et pour Zope en particulier et j'ai lancé un site web autour de cette techno à l'époque. Avec quelques compères du forum de Zopeur, nous avons fondé l'Afpy (Association Python Francophone).

J'ai aussi écrit trois livres sur Python dont un en Anglais.

Je bosse depuis plus de 5 ans pour Mozilla où j'anime une petite équipe qui écrit des services web.

Jdh : Tu viens d'évoquer Zope, que les anciens de la communauté Python connaissent bien. Quand et comment as-tu commencé à coder avec Python ?

Tarek : J'ai découvert Zope et Python à peu près en même temps. C'est en codant des petites fonctions dans l'admin Zope que je me suis mis à Python sérieusement, il y a plus de 10 ans.

Jdh : Et tu as apparemment pris goût à Python ! Je t'ai découvert grâce à ton excellent livre "Programmation Python - syntaxe, conception et optimisation" à l'époque. Peux-tu nous en dire un peu plus sur ce qui t'a amené à passer du statut de développeur à auteur ?

Tarek : C'est simple : je suis devenu fan de Python et j'ai eu envie de le maitriser au maximum.

Et écrire un livre est la meilleure des techniques : il faut bien maitriser chaque sujet pour pouvoir l'expliquer aux autres.

Ça a été un travail intense de 9 mois. J'y ai passé toutes mes soirées :)

Jdh : Lorsque nous nous sommes connus, tu étais très impliqué dans le développement de certains modules de la bibliothèque standard de Python, en particulier je me souviens de Distutils. Qu'en est-il aujourd'hui de ton implication dans le développement de Python ?

Tarek : J'ai beaucoup travaillé sur Disutils effectivement, car le packaging dans Python souffrait de gros problèmes et personne n'avait envie de s'y coller.

Le plus gros travail a été politique : écrire des PEP (Python Enhancement Proposals) pour faire avancer les standards en mettant tout le monde d'accord, puis un peu de code. Je me suis un peu trop impliqué pendant 2 ans sur le sujet et j'ai vécu un "burnout" le jour où mon travail sur un nouvel outil (Disutils2) qui devait être intégré à la bibliothèque standard a été retiré au dernier moment. Je l'ai mal vécu haha.

Tout ce travail a quand même porté ses fruits puisque le packaging s'améliore grandement et il y a pas mal de choses qui sont issues de mon travail. Certaines parties de Disutils2 ont été recyclées dans d'autres projets aussi.

Un conseil: ne tombez pas dans le piège de comparer le packaging de Python avec ceux très récents comme npm (node) ou cabal (haskell) ou même Debian, et de dire que "le packaging est un problème résolu depuis longtemps", Python est un papy de plus de 20 ans et tout le drame du packaging est de pouvoir difficilement faire table rase de l'existant, surtout dans un éco-système où cohabitent des communautés très différentes. Si vous parlez de packaging avec la communauté scientifique ou avec la communauté web, ce sont deux monde tellement différents qu'il est très dur de trouver des solutions universelles et respectueuses de l'existant.

Aujourd'hui je ne suis plus du tout impliqué dans le développement de Python. Ça prend trop de temps et d’énergie, que je préfère garder pour aller courir ou jouer de la trompette. Mon combat dans le code est maintenant à Mozilla :)

Jdh : La fondation Mozilla et ses projets passionnent les membres de notre communauté. Peux-tu un peu nous décrire quels sont tes projets techniques pour la fondation et ta façon de travailler chez Mozilla ? Lors de notre dernière rencontre tu vivais dans un petit village assez isolé des grands centres urbains.

Tarek : Je bosse pour Mozilla Corporation, qui est financée et dirigée à 100% par Mozilla Foundation, et qui a des salariés dans de nombreux pays. La Foundation en a aussi, distinctement de la Corporation.

Quand je suis arrivé il y a plus de 5 ans chez Mozilla, ma mission était simple : j'étais le premier développeur Python de l'équipe "Services" et mon job a consisté à porter Firefox Sync (alors en PHP) sous Python et mettre en place tout l'éco-système Python.

J'étais le seul européen de l'équipe, et je devais faire des réunions parfois à 2 heures du mat'. À l'époque Mozilla Corp. comptait autour de 350 salariés.

Tout a évolué et s'est structuré, et en 2016 on dépasse les 1000 employés avec beaucoup plus de monde en France (environ 45), et je suis maintenant "engineering manager" d'une équipe de Français dispatchés entre Rennes, Barcelone et Montpellier. Moi-même je suis dans un tout petit bled en Bourgogne (175 habitants).

On travaille en ce moment sur Kinto un service de stockage de données avec une API HTTP Json, écrite en Python avec Pyramid, Cornice et Cliquet. Je ne développe plus trop, je passe plus de temps dans des réunions et dans la gestion des projets Mozilla basés sur Kinto, et sur les échanges techniques avec les gens de mon équipe.

Bosser chez Mozilla est assez confortable en termes de moyens à notre disposition : on peut se rencontrer plusieurs fois par an pour faire des "work weeks", disposer de toutes les ressources nécessaires en ligne (serveurs virtuels etc).

Le seul regret de vivre à la campagne finalement est que ma connexion ADSL est mauvaise, ce qui est pénible pour les vidéoconférences.

Jdh : Peux-tu nous détailler un peu plus les projets sur lesquels tu as travaillé et travaille actuellement pour Mozilla ?

Tarek : En 6 ans de temps j'ai eu le temps de bosser sur beaucoup de projets à Mozilla.

Les plus intéressants :

• Firefox Sync : J'ai réecris le serveur PHP en Python, en utilisant Gevent
• Circus : Un gestionnaire de processus
• Cornice : une surcouche de Pyramid pour écrire des web services
• Loads : Un outil de load testing distribué

Et plus récemment, Kinto, un service de stockage JSON. Je ne développe quasiment pas dedans vu que j'ai changé de casquette (manager) mais je m'occupe de son intégration au sein de Mozilla pour nos différents besoins.

Kinto est maintenant utilisé par Firefox pour la mise à jour de données régulières. L'idée est de réussir à mettre à jour des informations importantes comme les révocations de certificats, sans avoir à attendre que la prochaine version de Firefox sorte.

Jdh : Firefox Sync est utilisé par le grand public et est donc un projet très visible. On a du mal à imaginer l'ampleur de l'investissement derrière. Peux-tu nous parler un peu des gens et de l'infrastructure derrière une fonctionnalité comme celle-ci ?

Tarek : La partie service web en Python est assez anecdotique, au départ j'étais tout seul à coder dessus. C'est quelques milliers de lignes tout au plus.

Le service web en Python, c'est l'arbre qui cache la forêt, 5% du temps de la requête. La difficulté de ce système est surtout liée à la base de données :

• la maintenance de plusieurs centaines de serveurs MySQL
• le sharding des utilisateurs sur toutes ces bases
• la gestion des migrations des utilisateurs etc

Il y a 6 ans nous étions déployés dans des datacenters et il fallait tout gérer nous-mêmes, par exemple le remplacement des disques durs.

Aujourd'hui tout est déployé sur des services clouds comme AWS. Et c'est le cas pour Kinto : des web heads à la demande et Postgres RDS.

En terme de tests, mon équipe est fière d'avoir un coverage de 100% partout, et nous avons des batteries de tests d’intégration qui se lancent sur Travis-CI

Nous avons un environnement de staging sur lequel nous déployons les nouvelles versions, et une équipe de QA qui se charge d'effectuer la recette le tout avant de nous donner le feu vert. L'équipe de Ops utilise Puppet pour tous nos déploiements.

Jdh : Kinto et Circus ont chacun plus de 1000 étoiles Github, avec un nombre de rapports de bugs importants, ce qui en fait des projets assez populaires. Comment se partage la journée type d'un développeur Mozilla ? Y'a-t-il une répartition du travail entre ce qui est fait pour la communauté directement et pour l'infrastructure Mozilla ? Les deux sont-ils confondus en permanence ?

Tarek : C'est une excellente question. Mon job principal justement, en tant que engineering manager, est de faire converger les besoins de Mozilla avec l'envie de développer des fonctionnalités qui sont utiles à une communauté plus large.

Le principe de base est que chaque grosse fonctionnalité que l'on ajoute dans les projets doit émaner d'un besoin réel dans l'un des projets internes - sans pour autant rendre le projet spécifique à Mozilla.

La signature des données dans Kinto est un bon exemple : nous devons signer toutes les données qui sont envoyées à Firefox pour éviter au cas où notre serveur Kinto serait piraté de servir des données corrompues. Ce serait par exemple la catastrophe pour les certificats SSL.

Cette fonctionnalité a été créée sous forme de plugin optionnel en se basant sur des standards ouverts et un système de configuration complet. En d'autres termes, on peut plugger cette option sur nos serveurs à Mozilla sans l'imposer aux autres utilisateurs de Kinto, mais si une autre organisation veut plugger le système de signature, elle pourra le faire !

L'équipe passe bien sûr un peu de temps sur des fonctionnalités 100% communautaires, qui ne sont pas utilisées à Mozilla - mais ce n'est pas la priorité - même si ce n'est jamais du temps perdu.

Le travail sur les bugfixes et push requests (PR) remontés par la communauté quant à lui, est en général fait rapidement : c'est un cadeau précieux qui nous est fait et il est important de ne pas laisser traîner ce travail - ne serait-ce que par respect pour la personne qui a passé du temps dessus.

Enfin, certains projets peuvent à un certain moment être moins utilisés chez nous, et peuvent continuer à vivre. Circus par exemple est moins utilisé qu'avant, et le projet est maintenu par des gens comme Yannick Péroux qui ne bosse pas à Mozilla, c'est génial ! C'est pour moi un exemple de réussite du modèle open source.

- Entretien réalisé par Carl Chenet pour le Journal du hacker.