Marine Dunstetter - Ingénieure web senior

Contexte

En 2023, Mainmatter lance l'Embroider Initiative qui vise à stabiliser Embroider, le nouveau système de build du framework Ember. L'objectif principal est de pouvoir builder les apps Ember avec Vite.

Suite au succès de ces travaux, Mainmatter poursuit sur sa lancée avec l'Ember Initiative, qui vise à moderniser et améliorer Ember en prenant en charge les sujets techniques critiques que la communauté peut difficilement achever sans l'aide de développeurs travaillant à temps plein.

Points clés

S'atteler à un projet tel qu'Embroider permet entre autres de mieux comprendre le fonctionnement des bundlers, comment les plugins impactent le build final, de se familiariser avec les fichiers virtuels et encore bien d'autres concepts.

La diversité des sujets liés à l'Ember Initiative élargit encore davantage le spectre des possibles. Par exemple, rien que le développement d'un script tel qu'ember-vite-codemod comporte déjà de nombreux aspects : l'implémentation en elle-même, avec des fonctionnalités liées à la manipulation d'AST, la prise de décision sur ce qui relève ou non de la responsabilité du codemod, les tests (tests unitaires, tests plus élaborés qui génèrent des apps pour vérifier les données de sortie, matrices de workflow...)

Au-delà de la technique, il s'agit aussi d'organiser des projets sur des répertoires open source importants nécessitant un alignement avec une Core Team, notamment via le processus de RFC.

Ressources publiques

• Unlocking Ember Future with the Ember Initiative, mon talk avec Chris Manson à EmberFest Bruxelles (2025)
• Mes articles sur le blog de Mainmatter
• Quelques répertoires auxquels j'ai contribué : embroider, ember-vite-codemod, ember-inspector

Contexte

En 2024, une entreprise fait appel à Mainmatter pour mettre en place son workflow de traduction côté backend. Il s'agit d'une application possédant de très nombreux modules. Les textes, alors écrits en anglais, incluent des titres de menus, des notifications ou encore des emails.

Les développeurs savent déjà qu'ils souhaitent utiliser FormatJS, une suite d'utilitaires permettant la traduction de textes au runtime, et dont le workflow prévoit la génération automatique des clés de traduction. Cette approche permet notamment deux choses: ne pas avoir à maintenir ces clés manuellement, et avoir le texte écrit directement dans le code source (plutôt que les clés) afin ques les développeurs aient une meilleure vision de la fonctionnalité à la lecture du code.

Points clés

Une grosse partie de ce type de travail est bien sûr la conception du workflow en lui-même: configurer les utilitaires de FormatJS, l'intégration continue qui assure la communication avec la plateforme de traduction (par exemple avec des ouvertures automatiques de PR), et remplacer les textes en dur du code source par un format qui suit l'API de @formatjs/intl. La documentation est une partie essentielle : l'équipe de développement doit comprendre comment le workflow fonctionne et comment rendre les textes traduisibles.

D'autres aspects moins évidents sont tout aussi importants, liés au fait que l'application a un historique ancien : il faut indiquer aux nombreux développeurs (plusieurs équipes développent sur le répertoire) qu'iels doivent désormais traduire leurs textes, et empêcher l'implémentation de nouveaux textes en dur. Ici, j'ai choisi l'écriture de plusieurs règles de lint pour le code et les templates, combinées à un suivi avec "Lint to the Future".

Enfin, la documentation doit également comporter un guide des bonnes et mauvaises pratiques. En effet, les développeurs qui raisonnent dans une seule langue et ne possèdent pas (encore) de compétence en traduction ont tendance à implémenter des optimisations qui ne sont plus exploitables lorsqu'on tente de traduire (phrases tronquées construite au fur et à mesure avec des conditions, gestion douteuse des pluriels sans utilisation du format ICU...)

Ressources publiques

• formatjs-shape, un plugin Visual Studio Code que j'ai développé et publié dans le cadre de ce projet, pour formatter facilement les textes en dur suivant l'API de FormatJS.

Contexte

En 2022, je me lance dans un projet de traduction des Ember Guides de l'anglais vers le français. Il ne s'agit pas d'ajouter une mécanique de changement de langue au site existant, mais bien d'avoir un autre site, sur un autre répertoire GitHub, qui contienne la version traduite.

Je relève un certain nombre de défis, par exemple autour de la correction d'orthographe ou de l'interface, mais l'un des plus critiques est la synchronisation des répertoires : comme le projet s'annonce long et que les Ember Guides continuent d'évoluer régulièrement, je dois trouver le moyen de mettre à jour les pages qui n'ont pas encore été traduites, mais aussi de repérer les changements à introduire dans les pages déjà en français.

Points clés

Répondre à la problématique requiert une bonne connaissance de git et GitHub, j'ai dû apprendre à exploiter ces deux outils d'une manière plus poussée que jusqu'alors ; et ce pour concevoir un workflow d'abord manuel. Je suis en effet adepte de tester les workflows manuellement pour vérifier qu'ils répondent correctement aux besoins essentiels avant d'investir plus de temps dans l'automatisation.

Ensuite, le script Node d'automatisation comporte de nombreux aspects : interprétation de paramètres d'entrée, lancement de commandes git, lecture et écriture de fichiers, utilisation de l'API de GitHub pour ouvrir automatiquement des Issues et des Pull Requests... ainsi que le côté purement visuel des sorties du terminal, car les actions scriptées sont nombreuses et nécessitent un bon niveau de clarté lorsque quelque chose ne se passe pas comme prévu.

Ressources publiques

• DazzlingFugu/ember-fr-guides-source, catchup.mjs, le script d'automatisation du workflow qui synchronise le répertoire français avec le répertoire anglais.
• The Ember Guides in French, le talk que j'ai présenté à EmberFest Madrid en 2023.
• Automating the maintenance of the Ember Guides in French, l'article qui fait suite au talk et détaille les fonctionnalités du script d'automatisation.

Contexte

En 2022 et 2023, j'intègre l'équipe de développement d'un client de Mainmatter. Je travaille alors sur des fonctionnalités et des chantiers techniques apportant le maximum de soutien. Constatant certains problèmes dans le comportement et la maintenance des notifications dites "flash" (notifications temporaires qui apparaissent dans un encart en bas de l'écran, ou dans un bandeau en haut), je propose de prendre en charge la réimplémentation ce système.

C'est une initiative de suppression de dette technique. Il n'est pas toujours possible d'anticiper la manière dont l'évolution d'un projet ou d'un framework va impacter une fonctionnalité sur le long terme. Dans le cas présent, la dette était double : non seulement le projet a évolué d'une manière rendant la maintenance des notifications difficile, mais elles étaient aussi construites sur des fonctionnalités d'Ember vouées à évoluer avec le nouveau système de build Embroider.

Points clés

La partie conception est très importante sur ce type de réimplémentation. Il s'agit d'analyser ce qui n'a pas fonctionné dans l'ancien système et de démontrer la solidité de la nouvelle proposition. L'architecture peut s'étendre à plusieurs répertoires, par exemple l'application et la librairie de design system (c'était le cas ici), donc redéfinir les responsabilités de chaque brique fait partie de ce travail.

C'est un projet qui fonctionne très bien avec une approche de prototypage en isolation. Ici, nous avons une application Ember classique complexe qui dépend de librairies internes, et nous savons qu'il faudra un jour la migrer au système de build Embroider. Pour s'assurer que la nouvelle proposition fonctionne, et fonctionnera avec Embroider, l'idéal est de prototyper les bases depuis une application vierge plutôt que directement dans l'application, afin de lever les incertitudes sur le système en lui-même et les incompatibilités.

Ressources publiques

• demo-flash-messages, les premières itérations d'un ancien prototype en isolation implémenté dans le cadre de ce projet. La dernière phase de prototypage n'est pas inclue dans ce répertoire public et consistait à remplacer un modèle de conception pour optimiser Embroider (l'emploi du built-in helper `component`).

Contexte

En 2017, je rejoins PeopleDoc et l'équipe Formidable, dont le nom est tiré du produit qu'elle développe : un constructeur de formulaire dynamique. Le produit s'adresse principalement aux employés des ressources humaines, qui peuvent créer des formulaires personnalisés pour les salariés de leur entreprise. Après quelques mois, je deviens rapidement la lead frontend du projet.

Points clés

Ayant passé plusieurs années à développer le produit Formidable, il s'agit moins d'un projet particulier que d'un poste à part entière. Ce que j'ai fait dans l'équipe correspond à ce qu'on attend d'un ingénieur web dans une entreprise qui développe des produits. Ainsi, la plupart des compétences liées à ce métier entrent en jeu : implémenter un produit en coopérant avec les autres métiers clés (produit, design, localisation, management, développement backend, QA), estimer les tâches à venir et décrire correctement la progression des tâches en cours, équilibrer le temps dédié à l'implémentation des fonctionnalités et à la maintenance de la stack technique...

Ce produit étant par nature très interactif et composable, l'accessibilité et les composants en sont un aspect important. C'est un projet idéal pour obtenir des bases solides en accessibilité et pour apprendre à travailler avec un design system, d'autant plus quand ce design system est développé par une équipe dédiée.

Côté leaderhip, il s'agit de prendre les décisions critiques sur l'architecture, de former les nouveaux membres de l'équipe, d'être capable de visualiser correctement les interdépendances entre les projets pour orchestrer le travail entre différentes équipes, ou encore d'organiser les présentations et démonstrations régulières au sein de l'organisation.

Ressources publiques

ember-slugify, une librairie développée pour ce projet et à laquelle j'ai contribué. Dans le cadre du créateur de formulaire, elle permettait de générer les identifiants HTML des champs en fonction du nom donné par les utilisateurs.