\textbf{Flymingo} est la suite de produits principale de \entityb{Moment}, qui est aujourd'hui déployée dans plus de 200 avions, 30 bateaux et 300 trains.
La plateforme \entity{Flymingo} permet aux companies de transport de proposer du divertissement à ses passagers,
avec une installation et une gestion simplifiée et sans le besoin d'installer des tablettes dans les sièges des passagers.
\textbf{VSCode}\cite{vscode} est un éditeur de texte utilisé par presque toute l'équipe pour modifier ou naviguer le code.
\textbf{Slack}\cite{slack} est une plateforme de messagerie instantanée,
que l'entreprise préfère aux emails pour la communication indirecte.
\textbf{Jira}\cite{jira} est un logiciel de gestion et de suivi de tickets,
que notre équipe utilise pour suivre les tâches à faire durant la semaine,
quelles tâches sont en cours de développement, prêtes à être revues ou finies,
ainsi que pour garder un \term{backlog} des tâches à faible priorité.
\textbf{Confluence}\cite{confluence} est un logiciel qui permet à l'équipe de regrouper des documentations qui n'ont pas de place claire au sein du code.
\textbf{NX}\cite{nx} est un outil simplifiant la gestion de \og monorepositories \fg (des repositories contenant plusieures applications et librairies).
\textbf{NX} est utilisé pour la repository de l'équipe qui contient Mint Service, Mint Admin et Mood TV.
L'objectif au long terme et de migrer l'ensemble des projets de l'équipe sur cette repository,
car elle permet de facilement réutiliser du code entre les projets et de synchroniser des modifications entre projets.
Typescript permet d'éviter une classe de bugs causés par des valeurs passées à des fonctions attendant un certain type en entrée.
\\
Typescript existe aujourd'hui en tant que langage qui doit être transpilé en javascript avant de pouvoir être utilisé dans Node.JS ou dans un navigateur,
mais certains interpréteurs (comme \textbf{Bun}\cite{bun}) supportent le typescript,
et il existe une initiative pour standardiser un système permettant d'ajouter des types en javascript sans devoir le traduire.
L'équipe \entity{Développement Full-Stack} fonctionne avec une méthode Scrum, qui est une méthode Agile. \cite{cohen2004introduction}
Notre chef d'équipe reçoit les spécifications des projets, les retours de recettes et les bugs des équipes \entity{PMO} et \entity{Design}.
En chaque début de semaine, sur la base de ces demandes et retours, nous définissions les thèmes,
tâches et priorités pour la semaine durant la réunion \og weekly \fg.
Chaque matin, nous faisons aussi une réunion \og daily \fg,
où chaqu'un présente le travail qu'iel a fait la veille, ainsi que ce qu'iel prévoit de faire ce jour.
Les tâches de la semaine sont inscrites sur \entity{Jira} dans un \term{Sprint} pour la semaine,
où elles seront facilement visibles et leur status sera facilement suivable.
L'attribution des tâches se fait en majorité sur la base du volontariat, avec les tâches à haute priorité à faire en premier:
lorsqu'il y a une tâche disponible que l'on souhaite faire,
on s'assigne à celle-ci sur \entity{Jira}, et on passe le status de la tâche de \textit{À faire} à \textit{En cours}.
On crée alors une \term{Merge Request} sur \entity{GitLab} (l'équivalent des \term{Pull Request} sur \entity{GitHub})
pour accueillir les changements à faire pour cette tâche.
Une fois que la tâche est implémentée,
on marque la \term{Merge Request} en mode \og Ready \fg et on passe la tâche sur \entity{Jira} au status \textit{Prêt à review}.
Un autre membre de l'équipe doit alors \term{review} les modifications au code,
pour s'assurer que les attentes en terms de qualité de code sont remplies.
Si la \term{review} relève des problèmes, alors ceux-cis doivent être adressés.
Dans le cas contraire, les changements de la \term{Merge Request} sont incorporés dans la branche \texttt{develop} et la tâche sur \entity{Jira} marquée comme \textit{Faite}.
Les tâches qui ne sont pas faites pendant un \term{sprint} sont gardées dans un \term{Backlog},
afin de pouvoir les intégrer au sprint de la semaine d'après,
ou pour les faire un jour où les taches d'un Sprint sont finies avant la fin de la semaine,
en fonction de leur priorité.
\subsubsection{Contrôle et assurance de qualité}
L'équipe a plusieurs outils en place pour assurer la qualité du code et des applications tout au long du développement:
\begin{description}
\item[Tests unitaires et tests d'intégration] Des tests unitaires sont écrits en parallèle de code \og métier \fg,
afin de tester de manière automatique et isolée le bon fonctionnement d'un composant en particulier.
Des tests d'intégration sont aussi écrits, qui testent de manière automatique une librairie ou une application entière,
afin de vérifier le bon fonctionnement de cette librairie ou de l'application.
Ces tests sont éxécutés sur nos machines,
afin de pouvoir rapidement corriger tout morceau de code qui aurait été accidentellement cassé lors d'une modification.
% TODO: citation for CI
\item[Continuous Integration] En plus de tester le code localement,
le code est aussi compilé et testé sur un serveur via les outils de \entity{GitLab} pour l'intégration continue.
Éxecuter ces tests sur un serveur permet de valider le comportement de l'application à tout moment du projet par rapport à une base commune,
et de s'assurer qu'une combinaison de modifications ne mène pas à un problème.
\item[Linting et formatting] Nous utilisons des outils comme \entity{ESLint} et \entity{Prettier} pour vérifier la consistence
de la forme du code dans les différents projets.
\entity{ESLint} nous permet de mettre en place des règles vérifiées automatiquement,
et qui lorsqu'elles sont suivies diminuent le risque d'avoir du comportement inattendu dans l'application.
\item[Merge Reviews] Avant qu'une modification ne soit incorporée dans la branche commune,
elle doit être vérifiée et validée par un humain.
Cette étape complète celle d'\entity{ESLint}, car certaines règles de style ne peuvent pas être appliquées automatiquement.
La vérification des modifications par un humain permet aussi d'éviter des potentiels bugs ou points de confusion.
\item[Recettes] Pour valider les produits, un serveur de test, le \og lab \fg,
est à disposition pour déployer et tester localement les différents projets.
Cette version déployée localement est ensuite testée par les chefs de projet et d'autres personnes de l'entreprise pour déceller des problèmes qui n'auraient pas été trouvés pendant le développement.
\item[Semantic versioning] Nous utilisons le versionage sémantique pour nos projets et pour les dépendance des projets.
Le versionage sémantique permet d'encoder dans le numéro de version du programme quel type de mise à jour il y a entre deux versions.
Le format du versionage sémantique est \;\texttt{major.minor.patch}, où:
\begin{itemize}
\item Si seulement \texttt{patch} change, alors la mise à jour ne modifie pas la fonctionnalité, mais corrige uniquement des bugs.
\item Si \texttt{minor} ou \texttt{patch} changent, alors la mise à jour ajoute uniquement de la fonctionnalité; faire la mise à jour ne devrait pas casser du code utilisant la librairie en question.
\item Si \texttt{major} change, alors la mise à jour introduit des changements cassants: il faudra alors faire des changements au code utilisant la librairie.
Pour limiter le couplage entre les services, et pour simplifier la réutilisation des services,
NestJS permet de faire de l'\term{injection de dépendances} par \term{constructeur sans défaut}\cite{yang2008empirical} dans les services et dans les controleurs,
On m'a donné en début de stage la tâche d'implémenter un système d'envoi de mail pour \entity{Mint Service}.
Ce système prend la forme de plusieurs librairies, qui doit remplir les conditions suivantes:
\begin{itemize}
\item Il doit être facilement réutilisable dans d'autres projets.
\item Il doit permettre de changer de fournisseur de service pour l'envoi d'emails sans devoir faire de grands changements du côté des utilisateurs de la librairie.
\item Il doit pouvoir envoyer des emails qui s'affichent de la manière voulue sur la majorités des boîtes mail.
\item Il doit pouvoir envoyer des emails contenant des informations sur l'utilisateur; cette étape devra être faite avec le service de \term{templates} d'email sur \entity{Amazon SES}\cite{amazonses}\cite{amazonsestemplate}
J'ai selectionné deux moteurs de recherche et de remplacement de texte (\term{Search and Replace}): \entity{Handlebars}\cite{handlebars} et \entity{Mustache}\cite{mustache}.
Ces deux moteurs opèrent de manière similaire: ils lisent le code source,
et lorsqu'une variable indiquée par les balises \texttt{\{\{} et \texttt{\}\}} est rencontrée,
celle-ci est subtituée par la valeur assignée au nom de cette variable.
\entity{Handlebars} et \entity{Mustache} peuvent tous les deux être utilisés pour implémenter le système de composants voulu,
car ils permettent de définir des variables spéciales, que les deux moteurs appelent \term{partials},
qui peuvent appeler du code javascript arbitraire.
J'ai enfin fait un prototype en \entity{Typescript},
qui transforme un email décrit à partir de composants \entity{Handlebars} ou \entity{Mustache} en du HTML.
Après avoir montré ce prototype à mon chef de projet, nous étions tous les deux d'accord que le moteur \entity{Handlebars}
remplissait mieux nos attentes, en grande partie parce que \entity{Handlebars} permet de passer du code en tant qu'\og enfants \fg,
tandis que \entity{Mustache} requiet de passer par deux composants (un avant et un après le code \og enfant \fg). \figref{hbs1}
\inputfig{hbs1}
Pour le premier projet sur lequel \entity{Mint Service} allait être déployé,
\entity{Amazon SES}\cite{amazonses} allait être utilisé pour faire l'envoi de mails.
\entity{Amazon SES} permet d'envoyer les emails sous format texte et HTML en même temps,
permettant d'avoir des emails facilement lisibles par un lecteur d'écran
ou sur une messagerie configurée pour afficher les mails sans leur mise en forme.
La partie \entity{Handlebars} a donc été étendue pour permettre d'annoter quels parties du code doivent être
placés dans la version texte du mail. [Figures~\ref{hbs2a} et \ref{hbs2b}]
\inputfig{hbs2}
\subsubsection{Implémentation initiale dans Mint-Service}
Une fois que le prototype me donnait des résultats satisfaisants,
j'ai pu passer à l'implémentation au propre du système d'envoi de mails dans \entity{Mint Service}.
\item Les mails sont chargés et sont rendus, puis sont mises en lignes sur \entity{Amazon SES} en tant que \og templates \fg\cite{amazonsestemplate}
\item Les mails sont ensuite envoyés en instructant à \entity{Amazon SES} de faire le rendu et l'envoi d'une des \term{templates} à l'adresse mail voulue, avec les données voulues
\end{enumerate}
J'ai d'abords créé et implémenté une librairie permettant de compiler du code \entity{Handlebars}
ainsi que des composants en format HTML et en format texte, nommée \texttt{handlebars-generator}. Cette librairie ne s'occupe pas du
chargement des fichiers, ni de l'envoi des mails, et est implémentée sans framework,
ce qui permet de la réutiliser dans le futur pour d'autres projets.
Puis, j'ai créé et implémenté une librairie Nest.JS nommée \texttt{mailing-nest} qui s'occupe de:
\begin{itemize}
\item Charger les composants et les emails depuis un dossier donné
\item Transformer ceux-cis avec \texttt{handlebars-generator} en HTML et en texte
\item Mettre en ligne des \term{templates} pour utiliser le service d'envoi d'emails personalisés d'\entity{Amazon}
Avec le système de mail en place, j'ai pu implémenter la première template d'email, qui était celle pour l'envoi d'identifiants au patients.
Très rapidement, j'ai pu voir sur \url{caniemail.com} que la quasi-totalités des fonctionnalités HTML5 modernes n'étaient pas supportés par \entity{Microsoft Outlook},
ce qui nous forcerait à utiliser des \texttt{<table>} dans l'entièreté des emails pour pouvoir supporter \entity{Microsoft Outlook},
qui est à ce jour le 3ème client email le plus utilisé du monde \cite{oberloemailclients}.
Une solution à ce problème est d'utiliser une librairie assurant la compatibilité avec \entity{Outlook}.
J'ai choisi la librairie \entity{MJML}\cite{mjml}, qui utilise un langage ressemblant au html, qui est ensuite compilé en HTML compatible avec \entity{Outlook}:
Après avoir fini l'implémentation du système de mail, j'ai pu l'observer alors qu'il est passé par la vérification de qualité,
des déploiements et recettes sur un serveur local, et enfin des déploiements chez les clients.
Les deux librairies ont vu peu de changements, et ont fonctionné comme voulu.
L'organisation du code au sein de \entity{Mint Service} a pris deux essais pour arriver à un format satisfaisant:
le premier essai plaçait l'envoi des mails dans un service dédié à la gestion des utilisateurs (\texttt{GuestModule}),
mais il s'averrait qu'il fallait assez de code pour préparer les informations des mails qu'il était préférable de déplacer la logique d'envoi des mails dans un module à part, \texttt{MintMailingModule}.
Malgré \entity{MJML} et le système de composants, écrire des templates d'emails reste plus compliqué à écrire que du code React:
\begin{itemize}
\item La différence de format entre les templates Handlebars/MJML et les composants React fait qu'il est difficile d'appliquer les intuitions valables pour le React lorsqu'on écrit ou réécrit des templates d'emails.
\\
Ceci est en grande partie dû au fonctionnement de MJML,
qui requiet une structure stricte dans le code (\texttt{mj-body}$\rightarrow$\texttt{mj-section}$\rightarrow$\texttt{mj-column}$\rightarrow$ texte).
\\
HTML lui a une structure plus flexible,
permettant d'imbriquer la pluspart des éléments disponibles dans un ordre arbitraire. \cite{mdncontentcategories}
(il faut mixer ensemble deux différents formats handlebars, l'un étant interprété de notre côté, et l'autre étant interprété du côté d'\entityb{Amazon SES}\figref{emailsrchbs}).
car le seul moyen pour accéder aux erreurs d'envoi de mails sur \entityb{Amason SES} est de mettre en place un système
de transfert de messages, puis de l'activer en envoyant les mails avec un paramètre précis.
\end{itemize}
Pour palier à la deuxième difficulté, j'ai décidé vers la fin de mon stage de modifier l'implémentation du système d'envoi de mails,
afin de faire l'entièreté du rendu de notre côté, et d'uniquement utiliser \entity{Amazon SES} pour l'envoi pur des mails.
J'avais également comme but secondaire de rendre ce système plus robuste,
en permettant notamment l'insertion de code pour vérifier la validité des données insérées dans les emails lorsqu'on est dans un environnement de développement.
Les modifications ont été faites dans l'ordre suivant, qui permettait de progressivement appliquer les changements nécessaires:
\begin{enumerate}
\item Suppression de la transformation des balises secondaires (\texttt{[[} et \texttt{]]}) et des options associées
\item Marquage de différents types comme dépréciés, et ajout de types pour l'envoi pur d'emails
\item Dépréciation des méthodes d'envoi d'email via les templates SES (\texttt{sendTemplatedEmail}), et ajout des méthodes pour l'envoi pur d'emails (\texttt{sendEmail})
\item Modification des templates pour ne plus utiliser les balises secondaires
\item Modification de l'application de prévisionage des emails pour utiliser le nouveau format des informations substituées dans les mails
\item Modification de \entity{Mint Service} pour utiliser \texttt{sendEmail} au lieu de \texttt{sendTemplatedEmail}
\item Suppression de \texttt{UploadModule} et de \texttt{sendTemplatedEmail}
\item Suppression des types inutilisés
\end{enumerate}
À la suite de ces modifications, les emails s'affichent de la même manière qu'avant,
et le système d'envoi de mails est désormais plus simple à utiliser
et plus simple à étendre avec différents services d'envoi de mail.
Je n'ai pas pu implémenter le système de validation des données, par soucis de difficulté d'implémentation:
il aurait fallu étendre le système de chargement de composants pour également charger du code Javascript,
et transformer le format des données utilisé par Handlebars en un format facilement vérifiable.
\\
Il est par contre maintenant possible d'écrire dans \entityb{Mint Service} des tests pour s'assurer que la logique de transformation des données reste compatible avec les emails.
À la suite de cette modification,
je pense qu'il est encore possible d'améliorer de différentes manières ce système d'envoi de mails:
\begin{itemize}
\item En ajoutant plus de tests automatisés dans le système, notamment des tests d'intégration
\item En rendant les différents modules plus simples d'utilisation
\item En permettant d'utiliser une syntaxe plus proche de celle de React pour appeler des composants (\texttt{<Composant>} au lieu de \texttt{\{\{>Composant\}\}})
\item En utilisant un système comme \href{https://react.email/}{React Email} ou \href{https://astro.build/}{Astro} pour écrire les templates en Javascript, ce qui permetterait aussi de faire de la vérification des données et des types.
\end{itemize}
\begin{figure}[H]
\includegraphics[width=\textwidth]{mailingnest-2}
\caption{Organisation finale du système d'envoi de mail dans Mint-Service}
\entity{Mood TV} est une application tournant sur les télévisions \og intelligentes \fg produites par \entity{LG}.
Ces télévisions font tourner le système d'exploitation \entity{WebOS}, et la version pour laquelle nous visons l'application utilise \entity{Chrome 53}.
Comme ces télévisions utilisent chrome, notre application peut être programmée entièrement en React,
à condition de s'assurer que le code javascript soit compatible avec cette version de chrome.
Mon travail sur \entity{Mood TV} a été d'optimiser le temps de chargement de la page:
avant, celle-ci prenait environ 10 secondes à charger,
et j'ai été laissé en autonomie pour trouver pourquoi le temps de chargement est si haut et comment le baisser.
\caption{Profil du chargement de la page, avant toute optimisation; annoté}
\label{moodtvbefore}
\end{figure}
On peut séparer le temps de chargement en différentes étapes:
\begin{enumerate}
\item Le chargement initial (en bleu), qui est le moment durant lequel le navigateur télécharge le code javascript,
et durant lequel \entity{webpack} prépare ce code pour reproduire un environnement modulaire moderne.
\item L'hydration \cite{hydration}, qui est une étape du rendu avec React: cette étape du chargement permet à React d'attacher
son arborescence d'état au HTML existant, permettant d'intéragir dans le code React avec les éléments du DOM.
\item La réception des \og catégories \fg, qui consiste au traitement de deux requêtes faites à l'API sur laquelle se trouve le \term{Content Management System}
\item L'envoi de requêtes pour récupérer les informations des films présents dans ces catégories
\\
On peut déjà observer sur cette capture d'écran que cet envoi est en triple, alors qu'il ne devrait n'y avoir qu'une vague.
\item La réception des informations de films, et le traitement du résultat de ces requêtes.
\end{enumerate}
Ensuite, il me fallait un moyen de mesurer de manière précise les performances avant de pouvoir faire des changements.
La solution que j'ai trouvé a été de créer et d'implémenter un protocole d'envoi et de réception de performances: \figref{moodtvperf}
\begin{itemize}
\item La télévision mesure les performances avec l'API javascript \texttt{Performance}\cite{performanceapi},
puis envoie ces valeurs via une requête sur un petit serveur sur mon ordinateur.
\item Ce serveur stoque ensuite toutes les valeurs reçues dans un fichier,
et peut relire de ce fichier si jamais il faut reprendre la mesure de performance.
\item Un programme lit les valeurs du fichier, puis calcule la moyenne, l'écart standard de ces valeurs.
Ce programme peut aussi lire deux fichiers, et comparer les performances entre ceux-cis.
\end{itemize}
\begin{figure}[H]
\includegraphics[width=\textwidth]{moodtvperf}
\caption{Protocole d'envoi et de réception de performances}
\label{moodtvperf}
\end{figure}
Les valeurs obtenues sont sous la forme de listes de nombres, une liste par métrique mesurée.
Soit $(\omega_1, \omega_2, ..., \omega_n)$ une telle liste.
Si on suppose que ces valeurs correspondent à différents résultats d'une même expérience $X$,
alors on peut calculer la moyenne empirique ($\mu^{\star}_n$) et la variance ($(\sigma^{\star}_n)^2$) empirique de ces valeurs de la manière suivante:
La fonction pour faire la requête pour une catégorie (\texttt{getItems}) utilisait un \texttt{useCallback} et un cache gêré par React,
ce qui faisait que dès que les informations d'un film était récupéré et stocké dans le cache, React assignait une nouvelle référence à \texttt{getItems},
causant le \texttt{useEffect} responsable pour charger l'ensemble des informations des films à s'éxecuter à nouveau,
et de nouvelles requêtes sont envoyées en conséquence. \figref{fromeffectloop}
Cette librairie est utilisée pour transformer les résultats des requêtes, qui sont sous forme d'objets ordinaires,
en instances de classes proposant des fonctions pour facilement traiter les informations contenues dedans.
Malheureusement, \texttt{class-transformer} ajoute beaucoup de temps de calcul, qui sur le hardware de la télévision connectée,
se traduit en secondes de chargement en plus. \cite{classtransformerbenchmark}
J'ai donc remplacé \texttt{class-transformer} par une transformation manuelle pour les listes de films,
qui copie manuellement les données des films et des catégories en instances de classe.
Avant de faire ce changement, j'ai d'abords écrit des tests unitaires pour vérifier le comportement du système déjà en place.
Puis, j'ai progressivement modifié les fonctions de traitement de requête affectées pour utiliser ma transformation manuelle à la place.
% Les seuls tests présents auparavant étaient des tests d'intégration, qui avaient cassé au fil des mois et qui ne fonctionnent plus ajourd'hui.
% J'ai donc dû nettoyer les tests d'intégration existants pour les faire tourner séparemment des tests unitaires.
\inputfig{perf4}
\subsection{Résultats et rétrospective}
Avec ces optimisations, la page prend désormais entre 4 et 6 secondes pour charger, contre 10 à 15 secondes auparavant.
Le temps d'éxecution sur le processeur de la télévision n'est aussi plus un engorgement,
et on peut voir sur le profil des performances qu'une bonne partie du temps est passé à attendre que les différentes requêtes se finissent. \figref{moodtvafter}
\caption{Profil du chargement de la page, après les optimisations; annoté}
\label{moodtvafter}
\end{figure}
Faire ce travail m'a permis d'avoir une compréhension plus profonde sur différents sujets:
\begin{itemize}
\item Les techniques d'optimisation logicielle (profilage, benchmarking)
\item Le modèle de propagation de mises à jour de React (\texttt{useEffect}, les boucles d'évenements infinies \figref{fromeffectloop})
\item L'optimisation de la taille des bundle javascript
\item L'extraction de données de performances depuis le navigateur (web vitals \cite{webvitals}, \texttt{reportWebVitals} sur Next.JS \cite{nextjsvitals})
\item L'analyse de données de performances (z-test, t-test, intervale de confiance)
