15 KiB
Retours sur deux ans à Mozilla
Ça fait un bail que j'ai cet article en cours de rédaction, et je me dis que je dois le poster maintenant, sinon je ne le ferais jamais (saloperie de perfectionnisme ?)
Il y à deux ans et demi, en décembre, je commençais à travailler chez Mozilla, dans l'équipe "Cloud Services".
Depuis, énormément de choses ont évoluées, tant en ce qui concerne les objectifs de Mozilla (avec l'arrivée de FirefoxOS) que le travail que j'effectue au jour le jour. Pour autant, mes objectifs personnels restent intacts.
Deux ans ça parait énorme, c'est le temps le plus long que j'ai passé à travailler sur un projet, avec quasiment les mêmes personnes. Si vous suivez un peu ces carnets, vous savez surement que j'ai beaucoup travaillé avec Tarek par exemple.
Ça a été (et c'est toujours) un réel plaisir de bosser avec la personne dont j'avais lu les livres pour apprendre le python, merci !
Services
Le principal de mon travail a été de construire des outils. Je suis le mainteneur de Cornice, un utilitaire qui vient se greffer par dessus le framework python pyramid pour vous simplifier la vie et créer des services web; J'ai travaillé un peu sur un outil de gestion des processus nommé Circus, et également sur un outil de montée en charge dénommé Loads
Au tout début, j'ai travaillé sur un concept de serveur de tokens. L'idée était de désolidariser l'authentification des services web des services eux mêmes.
L'idée est (je pense) bonne mais le service n'a pas été utilisé durant plus de deux ans. La raison étant principalement que Sync, pour lequel le serveur de tokens a été écrit, a subi des changements majeurs (qui sont rentrés en production il y a quelques semaines)
Circus est né de besoins découverts via le token server, et il m'a personnellement beaucoup appris. Le token server est finalement utilisé dans la nouvelle version de Sync qui est rentrée en production il y a peu.
Marketplace ("chouette, on va casser du serveur")
Après 6 mois à travailler à Services, Tarek et moi avons commencé à rejoindre l'équipe du Marketplace pour faire un travail d'"audit de performance".
L'idée était de prêter main forte à l'équipe du marketplace, mais les détails étaient alors assez flous. Le code est assez indigeste au premier abord, ce qui m'avait alors pas mal refroidi. La raison principale étant que le code est utilisé à la fois par addons.mozilla.org et par marketplace.firefox.com, rendant les choses souvent un peu plus compliquées qu'il ne faudrait.
Cet "audit" a été l'occasion de travailler sur des outils de montée en charge assez sympa, qui ont donné naissance à un projet qu'on utilise assez souvent maintenant, Loads.
Énormément d'efforts sont fait pour aller dans la bonne direction et faire en sorte que le code soit plus facile à maintenir et que le projet soit plus facile à aborder. D'ailleurs, pas mal de copains djangonautes français travaillent dessus (salut Mathieu, Yohan, David et Mathieu Agopian!)
Une partie de notre plan a été de sortir certaines fonctionnalités du code actuel, pour en faire quelque chose de plus facile à maintenir et de moins imbriqué.
La Communauté
Circus et Cornice sont deux outils qui semblent utiles à la communauté. J'ai eu des retours très positifs sur Cornice, et j'essaye de le faire évoluer dans la direction qui me semble propice.
D'ailleurs, Cornice est utilisé (par Mathieu L. — encore un —, Rémy et moi) actuellement pour coder Daybed un service de validation de formulaires, mais ça sera l'objet d'un futur billet.
Circus commence à recevoir des contributions de plus en plus intéressantes, et à être utilisé en interne chez nous et chez d'autres, donc c'est une extrêmement bonne nouvelle.
Talkilla / Loop
Après quelques temps, j'avais envie d'apprendre de nouveau. Python c'est génial mais c'était devenu ma "zone de confort". J'adore découvrir des choses, donc c'était le moment de faire en sorte que ça continue!
C'était aussi l'occasion de travailler avec Nicolas et Romain. Je suivais le projet Talkilla de plus ou moins loin depuis quelques mois, c'était donc l'occasion à ne pas manquer.
En rentrant dans cette équipe, je cherchais principalement à avoir un projet visible pour les utilisateurs finaux. Refaire un peu de frontend, apprendre à faire du JavaScript propre et découvrir de nouvelles personnes.
J'y ai aussi récupéré une équipe qui essaye de suivre les principes de l'agilité et qui est sur mon fuseau horaire (pour la plupart). Le rêve.
L'idée derrière Talkilla est d'utiliser la technologie de communication pair à pair dans les navigateurs (WebRTC) pour faire des appels audio / vidéo. En d'autres termes, c'est un peu transformer votre firefox en téléphone, sauf que personne ne peut espionner ce qui se passe entre vous et l'autre bout du fil.
A peine arrivé dans le projet (peut-être un mois et quelques après mon débarquement) le choix a été fait de tout réécrire depuis zéro, dans un projet qui se nomme actuellement "Loop", qui veut proposer la même chose, mais inclus directement dans Firefox.
C'est en bonne voie, on a quelque chose qui fonctionne dans nightly, et le code du serveur fonctionne pas mal. Le code du serveur est ici: https://github.com/mozilla-services/loop-server.
Un client est en train d'être implémenté dans Firefox et un autre en tant qu'application pour FirefoxOS. Le boulot ne s'arrête pas de pleuvoir, mais je pense qu'on va dans une direction intéressante.
Pour être complètement terminé, il faudrait qu'on soit capable de se passer complètement de notre provider, TokBox (que l'on utilise en tant que relai média), pour que n'importe qui puisse choisir d'utiliser son propre serveur STUN / TURN et installe son serveur loop chez lui.
Le travail à distance
Quand j'ai commencé à travailler à Mozilla, j'ai décidé de venir m'installer à Paris. La plupart des personnes de mon entourage ont d'ailleurs fait des gros yeux, parce qu'ils connaissaient mon avis sur la ville en question, mais casser des préjugés n'est jamais une mauvaise chose.
Après deux ans passés à Paris, j'ai décidé de partir m'installer à Rennes, puisque de toute manière, la plupart de mon travail s'effectue au jour le jour à distance. En d'autres termes, la plupart de mon équipe n'est pas à coté de moi quand je travaille, ce qui veut dire que je peux travailler depuis n'importe où.
Ce qui fonctionne pour moi, c'est de ne quasiment jamais travailler depuis la maison. J'utilise un espace de coworking qui est un moyen de garder ma vie perso séparée de ma vie privée et de rencontrer des gens passionnés par ce qu'ils font.
Depuis que je suis arrivé à Rennes, Rémy a commencé à travailler avec moi, et c'est un réel bonheur que de pouvoir partager des journées de travail. On "pair-prog" énormément et j'ai l'impression d'avoir un boost dans ma productivité quotidienne.
Enseignements
Mozilla est ma première expérience professionnelle, et par conséquent, je manque nécessairement de recul sur ce qui est acceptable et ce qui ne l'est pas. D'une manière générale, avoir un environnement de travail basé sur la confiance est réellement appréciable (La première réaction des gens quand je dis que je peux travailler à distance, c'est de me demander comment ils font pour être sur que je travaille. Et la réponse est… il n'y en a pas).
J'ai encore un peu de mal à savoir quels indicateurs utiliser pour savoir si je suis "productif" ou non, mais j'ai globalement l'impression que je manque de concentration et de discipline: beaucoup d'interruptions n'aident pas à se concentrer.
La motivation fluctue aussi énormément: un jour on est super motivé, un autre c'est juste impossible de la trouver. Après quelques expérimentations, le mieux (pour moi) est d'avoir des horaires fixes, pour pouvoir séparer le travail du reste, de ne pas hésiter à faire des pauses et d'écouter un peu ses envies et son corps (si je suis crevé, ça ne sert à rien de se lever pour aller travailler, il vaut mieux se reposer un peu pour être plus efficace ensuite, par exemple).
J'ai essayé de tirer quelques enseignements de ces deux années:
Malheureusement, le code n'est pas propre
Je me rends compte que bien souvent je suis assez déçu de la qualité du code que je regarde. Principalement parce que je ne suis pas capable de le comprendre rapidement. Spécifiquement, ça m'est arrivé avec certaines parties de Zamboni, le code du Marketplace dont je parlais plus haut, avec certaines parties de Talkilla ou alors le code de Firefox lui même.
C'était extrêmement frustrant pour moi de découvrir que le code écrit à Mozilla n'était pas exemplaire. Tout le code qui est ajouté à l'heure actuelle est revu, corrigé et validé par des pairs, mais un certain nombre de projets ont un historique assez lourd qui rends leur structure complexe.
Je réalise donc que mon travail n'est pas uniquement de savoir écrire du code propre, mais également de réussir à comprendre du code que je considère comme "sale" (quitte à l'améliorer au passage !).
Et c'est pas du gâteau; je m'attendais à réussir à comprendre des projets complexes facilement, mais aucun miracle de ce coté là. Il faut réussir à rester concentré pendant suffisamment longtemps pour pouvoir tirer tous les fils et commencer à démêler… Pas facile !
Apprendre est un processus actif
Il est facile de passer à coté de l'apprentissage. Être entouré de gens talentueux ne suffit pas pour continuer à apprendre.
Savoir reconnaitre un échec est nécessaire. Dire que l'on comprends pour éviter de passer pour un idiot est un biais qui se prends assez rapidement, et qu'il faut éviter à tout prix.
Surtout au début, c'était une erreur que je faisais énormément, une question d'égo probablement.
Il y a une espèce de honte de ne pas savoir, alors que tout le monde autour sait ou en tout cas semble savoir. Bien souvent, les gens autour ne savent pas non plus, ce qui mène à des discussions de comptoir, sans trop savoir pourquoi.
Connaître ses limites techniques est un bon début pour pouvoir les surpasser. Chercher à les rencontrer est un processus actif.
Le manque de temps m'empêche bien souvent de pouvoir prendre un livre technique et de pouvoir l'apprécier. Je ne sais pas exactement pourquoi, peut être par sur-dose, mais je n'ai ouvert que quelques rares livres techniques durant ces deux années. Et j'aimerais bien que ça change !
"Assez bien" est suffisant
La culture de l'excellence se mets parfois au milieu du chemin. On oublie souvent que "le mieux est l'ennemi du bien".
Rien ne sert de faire des commits parfaits tout le temps. Quand j'ai besoin de "hacker" sur un projet, je ne voulais d'abord pas tout péter, par peur de ne plus m'y retrouver.
Mon approche actuelle est bien différente: on mets les mains dans le cambouis jusqu'à ce que ça marche, et ensuite on répare les dégâts. Enfin… dans une certaine mesure hein !
Écrire des boites à outils et non pas des frameworks
Écrire des frameworks force les utilisateurs à les utiliser, et à les connaitre dans les moindres recoins. Heureusement, il existe déjà énormément de frameworks qui pour la plupart font très bien leur travail. Ce qui nous manque ce n'est pas plus de frameworks, mais bel et bien plus de boites à outils.
Une boite à outil prends un problème bien défini et propose une solution pour ce problème. Une boite à outils est, en mon sens, ce qu'on appelle une bibliothèque. Pas besoin de réécrire tout votre projet pour utiliser ma nouvelle bibliothèque afin de profiter des fonctionnalités qu'elle apporte (alors que c'est le cas avec un framework, justement).
Être le moteur de son propre changement
Facile à dire, héhé ! D'une manière générale, je me rends compte qu'il est facile de se plaindre sans pour autant être moteur du changement que l'on souhaite voir arriver.
Ça vaut le coup de se donner la peine de faire changer les choses, surtout à Mozilla, parce que le changement n'est pas seulement vu d'un mauvais œil.
Pour que les choses évoluent, il faut être force de proposition. Se plaindre n'a jamais servi à rien si ce n'est pas suivi d'actes ;)
Je dis de temps en temps que Mozilla est une "do-o-cratie" (celui qui fait à raison), et je le pense de plus en plus. Quand j'ai envie que quelque chose soit fait, et bah… il faut le faire !
Ne pas chercher à avoir raison
Peu importe qui a raison, l'important n'est pas de chercher à montrer que tu sais, mais de trouver ce qui est juste. Ça parait peut être évident, mais bien souvent on cherche à se mettre en avant, au détriment du projet… Allez, gardons nos égos de coté ;)
Arrêter le négativisme
Il est très facile de se laisser embarquer dans le négativisme. Il y a toujours des choses qui ne vont pas, et probablement il y en aura toujours. Ce ne sont pas des raisons suffisantes pour perdre le moral. Identifier les points faibles est important est permet de savoir ce qu'il est nécessaire d'améliorer, mais regarder les choses du coté positif (et il y en a nécessairement un !) est indispensable !
À plusieurs reprises je me suis retrouvé dans des crises de négativisme, pour un tas de raisons différentes. La meilleure manière de s'en sortir: en causer et trouver des solutions, prendre le problème à bras le corps, et ne pas considérer que c'est un problème sur lequel on a aucune prise possible.
La suite ?
Je n'ai aucune idée d'à quoi va ressembler la suite, et c'est justement ce que j'apprécie et qui m'effraie en même temps…
Je fais actuellement énormément de Javascript et je travaille sur des projets qui semblent avoir plus de sens qu'avant (même si je vois déjà des choses que je souhaiterais améliorer, mais chaque chose en son temps). Donc techniquement j'apprends et dans ma quête de faire des produits qui touchent un utilisateur.
Depuis quelques semaines, je peux travailler une journée par semaine sur un projet qui me tiens vraiment à cœur: daybed (http://daybed.rtfd.org). L'objectif est de faire en sorte que le projet avance et soit utilisé au sein de mozilla.
Avant toute autre chose, il faudra faire des changements de "pitch" pour qu'il soit plus simple d'expliquer ce que Daybed souhaite faire, mais… c'est une autre histoire.