\documentclass[12pt, a4paper]{article}

\setlength{\parskip}{1em}

\usepackage[T1]{fontenc}
\usepackage[a4paper, margin=0.7in]{geometry}
\usepackage[french]{babel}
\usepackage{xspace} % From https://tex.stackexchange.com/questions/150640/missing-space-after-guillemets
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{mathtools}
\usepackage{mathabx}
\usepackage{listings}
\usepackage[many]{tcolorbox}
\usepackage{xcolor}
\usepackage{float}
\usepackage{cite}
\usepackage{subcaption}
\usepackage{wrapfig}
\usepackage{svg}
\usepackage{ragged2e}
\usepackage[nottoc,numbib]{tocbibind}
\usepackage{array}
\usepackage{booktabs}
\usepackage{stmaryrd}
\usepackage{dsfont}

\usepackage{hyperref}
\hypersetup{
  colorlinks=true,
  linkcolor=blue,
  urlcolor=blue,
  citecolor=red,
  pdftitle={Adrien Burgun - Rapport de stage ST40 - A2022}
}

% From https://github.com/pinam45/utbm-latex-internship-report-covers
% Requires xelatex to run (or maybe also lualatex)
\usepackage{utbmcovers}

\setmonofont[Contextuals={Alternate}]{Fira Code}
\newfontfamily{\FiraCode}[Contextuals={Alternate}]{Fira Code}
\IfFontExistsTF{Fira Code SemiBold}{
  \newfontfamily{\FiraCodeSB}[UprightFont={* SemiBold}]{Fira Code}
}{
  \IfFontExistsTF{Fira Code Semi-Bold}{
    \newfontfamily{\FiraCodeSB}[UprightFont={* Semi-Bold}]{Fira Code}
  }{
    \newfontfamily{\FiraCodeSB}[UprightFont={* Semibold}]{Fira Code}
  }
}


\definecolor{kwColor}{rgb}{0.15,0.21,0.87}

% From https://tex.stackexchange.com/questions/89574/language-option-supported-in-listings
\lstdefinelanguage{JavaScript}{
  keywords={
    typeof, new,
    abstract, class, interface, type, function, return,
    async, await,
    try, catch, finally,
    switch, case, break,
    var, let, const,
    if, else,
    for, while, in, of, do,
    true, false, null, undefined
  },
  keywordstyle=\color{kwColor}\FiraCodeSB,
  ndkeywords={
    export, implements, import, this,
    private, public, readonly, constructor,
    @Inject, @Injectable, @Controller, @Module
  },
  ndkeywordstyle=\color{darkgray}\FiraCodeSB,
  identifierstyle=\color{black},
  sensitive=false,
  comment=[l]{//},
  morecomment=[s]{/*}{*/},
  commentstyle=\color{purple}\ttfamily,
  stringstyle=\color{red}\ttfamily,
  morestring=[b]',
  morestring=[b]"
}

\lstdefinelanguage{hbs}{
  % morecomment=[s]{\{\{!}{!\}\}},
  morecomment=[s]{<!--}{-->},
  commentstyle=\color{purple}\ttfamily,
  stringstyle=\color{red}\ttfamily,
  morestring=[s]{\{\{}{\}\}},
}

\definecolor{bgColor}{rgb}{0.95,0.94,0.92}
\lstset{
  % backgroundcolor=\color{bgColor},
  commentstyle=\color{gray},
  keywordstyle=\color{magenta},
  numberstyle=\tiny\color{gray},
  stringstyle=\color{purple},
  basicstyle=\footnotesize,
  breakatwhitespace=false,
  breaklines=true,
  captionpos=b,
  keepspaces=true,
  numbers=left,
  numbersep=5pt,
  showspaces=false,
  showstringspaces=false,
  showtabs=false,
  tabsize=2,
}
\tcolorboxenvironment{lstlisting}{
  spartan,
  frame empty,
  boxsep=0mm,
  left=1mm,right=1mm,top=-1mm,bottom=-1mm,
  colback=bgColor,
}

\graphicspath{{build/figures/}{images/}}

\newfontfamily{\Tahoma}{Tahoma}
\newfontfamily{\SourceSans}{Source Sans Pro}
% Looks like the font from google fonts has a different case,
% so I'm stuck with scanning for existing fonts
\IfFontExistsTF{Source Sans Pro SemiBold}{
  \newfontfamily{\SourceSansSB}[UprightFont={* SemiBold}]{Source Sans Pro}
}{
  \IfFontExistsTF{Source Sans Pro Semi-Bold}{
    \newfontfamily{\SourceSansSB}[UprightFont={* Semi-Bold}]{Source Sans Pro}
  }{
    \newfontfamily{\SourceSansSB}[UprightFont={* Semibold}]{Source Sans Pro}
  }
}
\setmainfont{Source Sans Pro}
% \newfontfamily{\ossb}[UprightFont={* Semibold}]{Open Sans}
\newcommand{\entity}[1]{{\SourceSansSB #1}}
\newcommand{\entityb}[1]{#1}
\newcommand{\person}[2]{#1 #2}
\newcommand{\term}[1]{\textit{#1}}
\newcommand{\figref}[1]{[Figure~\ref{#1}]}
\newcommand{\inputfig}[1]{\input{figures/#1}}

\title{Rapport de stage ST40 - A2022}
\author{Adrien Burgun}
\date{Automne 2022}


\setutbmfrontillustration{assets/priscilla-du-preez-BjhUu6BpUZA-unsplash}
\setutbmtitle{Stage développeur full stack}
\setutbmsubtitle{Rapport de stage ST40 - A2022}
\setutbmstudent{BURGUN Adrien}
\setutbmstudentdepartment{Département Informatique}
\setutbmstudentpathway{}
\setutbmcompany{Moment - T\&M}
\setutbmcompanyaddress{3 boulevard Richard Lenoir\\75011 Paris}
\setutbmcompanywebsite{\href{https://moment.tech/}{moment.tech}}
\setutbmcompanytutor{PERRIN Pierre}
\setutbmschooltutor{HOLWECK Frederic}
% From https://moodle.utbm.fr/pluginfile.php/117803/mod_book/chapter/595/CARNET-A22-20220711.pdf
\setutbmkeywords{Télécommunications - Informatique - Développement logiciel - Logiciel de gestion - Logiciel de réseaux}
\setutbmabstract{
  J'ai effectué mon stage ST40 au sein du département de développement full-stack de l'entreprise \entity{Moment},
  une start-up française basée à Paris et fondée en 2013.
  \newline

  Moment propose à ses clients des offres de divertissement pour l'aviation, le secteur maritime, le secteur ferroviaire et
  plus récemment le domaine de la santé. Leur offre principale, la \og Flymingo Box \fg, est une solution tout-en-un qui permet
  aux passagers de directement accéder à une librairie de divertissement depuis leurs appareils mobiles.
  \newline

  J'ai pu contribuer au développement de fonctionnalités pour la nouvelle offre déployée dans les cliniques de santé,
  à l'optimisation de l'application tournant sur des télévisions connectées et au maintien du code front-end.
}

\begin{document}
% \maketitle
\makeutbmfrontcover{}
{
  \Tahoma
  \tableofcontents
}
\newpage

\section{Présentation}

\subsection{Présentation de l'entreprise}

\entity{Moment} est une entreprise fondée en 2013, avec pour but de rendre l'expérience des voyageurs plus simple,
plus plaisante et plus connectée \cite{momenttech}.
Pour y parvenir, \entity{Moment} propose une plateforme digitale déployée dans les avions, les trains, les bateaux
de croisière et plus récemment les cliniques de santé.
Cette plateforme permet aux voyageurs de se connecter à un réseau wifi avec leurs propres appareils, et de profiter
de divertissements directement sur ceux-ci.

À ce jour, \entityb{Moment} s'apprête à compter 10 ans de travail dans ce domaine, et possède une trentaine d'employés.
\entityb{Moment} a lancé plus de 60 projets dans plus de 15 pays, et ses produits sont utilisés par plus de 10 millions
de passagers par jour.

\entityb{Moment} fournit ses services aujourd'hui à \entity{TGV InOui}, \entity{Air Belgium}, \entity{Brittany Ferries} et \entity{Air Senegal}.
\entityb{Moment} a aussi dans le passé fourni ses services à \entity{Air France} et \entity{l'Aéroport de Paris}.

Après avoir déployé déjà 500 serveurs, l'entreprise \entityb{Moment} a lancé en 2021 une filiale nommée \entity{Moment Care},
qui se spécialise dans le divertissement dans le domaine de la santé:
\entity{Moment Care} souhaite révolutionner le contenu des offres de divertissement dans les établissements
de santé, et la manière d'y accéder \cite{momentcare}.

\subsection{Présentation du lieu de stage}

Lors de mon stage, les locaux de \entityb{Moment} se trouvaient à Paris, près de la place de la Bastille.
Ces bureaux sont partagés par la grande majorité des employés de \entityb{Moment}, qui sont organisés en
différents pôles:

\begin{description}
  \item[Développement full-stack:] C'est au sein de cette équipe que mon stage s'est déroulé,
    sous la supervision de son chef d'équipe, Pierre Perrin.

  \item[Marketing \& Design:] Ce pôle s'occupe de l'image de l'entreprise et des produits, à la fois sur
    les réseaux sociaux et auprès des clients présents et futurs.
    Cette équipe décide notamment du design des différentes applications, qui est envoyé à l'équipe
    \entity{Fullstack R\&D} pour implémentation.

  \item[PMO (Project Management Office):] Ce pôle est constitué de chefs de projets, qui gèrent les demandes
    des clients, les dates limites, les statistiques à relayer aux clients et les difficultés techniques.

  \item[Contenu:] L'équipe contenu s'occupe de maintenir la base de contenus disponibles sur les
    différentes plateformes déployées. Elle négocie auprès des distributeurs de films, de séries
    et de magazines, et elle maintient à jour le \term{Content Management System} (CMS).

  \item[Business Developers:] Cette équipe est en contact avec nos clients actuels et de potentiels clients
    futurs. Elle met en place le business plan, amène à l'entreprise de nouvelles opportunités
    de partenariat et négocie les prix lors de la vente des produits de l'entreprise.

  \item[Moment Care:] Une équipe est dédiée à la filiale \entity{Moment Care}.
    Cette équipe s'occupe de vendre les produits de \entity{Moment Care},
    de suivre leur développement et de déployer les produits de \entityb{Moment Care} chez les clients.

  \item[Administratif:] Ce pôle est constitué du directeur des resources humaines,
    qui s'assure que l'entreprise a les employés nécessaires pour travailler.
    Ce pôle s'occupe aussi de la finance et du budget de l'entreprise.

  \item[Tech:] Le pôle technologie se divise en deux grandes équipes, les \entity{DevOps} et les \entity{Dev Full-Stack},
    ainsi qu'une nouvelle équipe qui mène le développement du hardware pour la seconde génération de serveurs que l'entreprise souhaite bientôt proposer.

  \item[DevOps:] L'équipe \entity{DevOps} développe des outils,
    méthodes et processus pour automatiser les différents besoins des applications à déployer.
    L'équipe gère entre autres le déploiement des applications sur les serveurs envoyés dans les avions,
    la configuration du système d'exploitation de ces serveurs.

  \item[Full Stack:] L'équipe \entity{Full Stack} développe les différentes applications front-end et back-end que \entity{Moment} propose.
    Ces applications s'étendent du serveur de streaming de médias aux applications web et aux applications mobiles.
    C'est également l'équipe que j'ai rejoint durant ce stage.
\end{description}

\begin{figure}[H]
  \includegraphics[width=\textwidth]{poles}
  \caption{Diagramme des pôles de l'entreprise}
\end{figure}

\newpage
\subsection{Produits de Moment}

\subsubsection{Mood}

% TODO: crop images
\begin{wrapfigure}{r}{0.25\textwidth}
  \centering
  \includegraphics[width=0.25\textwidth]{flymingo-box}
  \caption*{Flymingo Box}
  \includegraphics[width=0.25\textwidth]{mood-digital}
  \caption*{Mood Digital}
\end{wrapfigure}

\textbf{Mood} (auparavant appelé \entity{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 compagnies 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.

Ce produit est composé d'un serveur, nommé \entity{Flymingo Box}, qui émet son propre réseau wifi,
sur lequel les passagers peuvent se connecter pour profiter des divertissements.

Différentes applications sont développées autour de la \entity{Flymingo Box}:

\begin{description}
  \item[Mood Entertainment] aussi appelé \entity{Mood Digital}, est une application web,
  sur laquelle les passagers se connectent pour regarder des films,
  lire de la presse ou jouer à des jeux dans le navigateur.
  L'application peut être utilisée sur les téléphones, tablettes et ordinateurs.
  \\
  L'application peut aussi être adaptée aux besoins des clients, pour être en accord avec le langage visuel de leur marque
  ou pour supporter différents services comme l'achat en ligne, les informations de voyage, etc.
\end{description}

\begin{description}
  \item[Mood TV] est une application tournant sur les télévisions connectées et permettant de profiter du contenu directement sur une télévision.
    Ces télévisions sont surtout utilisées sur les bateaux de croisière.
\end{description}

\begin{description}
  \item[Content API et Media API] sont deux \term{API} (interfaces de programmation) qui gèrent les films et autres médias stockées sur la box,
    ainsi que leurs informations (titres, durée, etc.).
\end{description}

\begin{description}
  \item[La \og Crew App \fg] est une application sur \entity{iOS} pour les membres de l'équippage,
    qui permet de mettre en pause la lecture des médias pour faire des annonces aux passagers,
    accéder aux informations des achats faits sur l'application \entity{Mood Digital}.
\end{description}

\subsubsection{Mint}

\begin{wrapfigure}{r}{0.25\textwidth}
  \centering
  \includegraphics[width=0.25\textwidth]{mint-digital}
  \caption*{Mint Digital}
\end{wrapfigure}

\textbf{Mint} est la plateforme que \entityb{Moment} développe et déploie en ce moment dans les cliniques de santé.
Elle vise à permettre aux patients des cliniques de profiter de divertissements de qualité tout le long de leur séjour.

Les applications développées autour de cette plateforme sont:

\begin{description}
  \item[Mint Admin,] qui est une application web permettant aux clinique de fixer les prix
    pour les offres que celles-ci souhaite mettre à disposition, ainsi que de gérer l'attribution des différents
    appareils (comme les télévisions et les tablettes) aux chambres, des différents patients à ces chambres,
    et des offres aux patients.
\end{description}

\begin{description}
  \item[Mint Digital,] qui est une application web que les patients des cliniques utilisent
    pour se connecter, acheter des offres en ligne, regarder des films, documentaires, magazines et écouter de la musique.
\end{description}

\begin{description}
  \item[Mint Service,] qui est le back-end avec lequel \entity{Mint Admin} et \entity{Mint Digital} communiquent.
    \entity{Mint Service} expose une API permettant à \entity{Mint Admin} de faire des modifications aux offres et aux patients,
    et à \entity{Mint Digital} de permettre aux utilisateurs de se connecter et d'acheter des offres en ligne.
\end{description}

\begin{description}
  \item[Mint Tab,] qui est une application pour tablettes \term{iPad}, qui permet aux patients des cliniques
    d'accéder au même contenu que sur \entity{Mint Digital}, sans avoir besoin d'utiliser leurs propres appareils.
\end{description}

\begin{description}
  \item[Mint TV,] qui sera une application tournant sur les télévisions connectées, qui permet aux patients des
    cliniques d'accéder au même contenu que sur \entity{Mint Digital}, en plus de pouvoir regarder les flux de la télévision.
\end{description}

\subsection{Présentation de l'équipe Développement R\&D}

\subsubsection{Méthode de travail}

L'équipe \entity{Développement Full-Stack} fonctionne avec la 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 statut 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 statut de la tâche de \textit{À faire} à \textit{En cours}. \figref{jira}
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 statut \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 termes de qualité de code sont remplies.

Si la \term{review} relève des problèmes, alors ceux-ci 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é.

\begin{figure}[H]
  \includegraphics[width=\textwidth]{jira}
  \caption{Exemple de tâche inscrite sur Jira; cette tâche est \textit{En Cours}}
  \label{jira}
\end{figure}

\subsubsection{Outils utilisés}

Nous utilisons une diversité d'outils pour développer du code,
allant de l'éditeur de texte jusqu'aux outils automatisant le test du code affecté par un changement.

\newcommand{\logowidth}{0.15\textwidth}

\textbf{Git} \cite{git} est utilisé pour gérer le versionnage du code: cet outil permet de stocker les modifications
  apportées au code sous forme de \og commits \fg, et de facilement rassembler et gérer les modifications faites par plusieurs personnes.

% wrapfigure does not work with my \entity :(
\begin{wrapfigure}{r}{\logowidth}
  \centering
  \includesvg[width=\logowidth]{gitlab_logo.svg}
  \caption*{GitLab \cite{gitlabsvgs}}
\end{wrapfigure}

\textbf{GitLab} \cite{gitlab} est utilisé pour stocker les repositories de l'entreprise en ligne,
pour stocker en ligne les paquets \entity{npm} \cite{npm} et pour lancer automatiquement les tâches de \term{Continuous Integration}.

\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 e-mails 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 plusieurs 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.

\begin{wrapfigure}{r}{\logowidth}
  \centering
  \includesvg[width=\logowidth]{ts-logo-128.svg}
  \caption*{TypeScript \cite{typescriptlogo}}
\end{wrapfigure}

\textbf{Typescript} \cite{typescript} est une extension au langage JavaScript, qui ajoute un système de vérification de types.
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.

\textbf{React} \cite{react} est une librairie JavaScript qui permet de facilement construire des interfaces graphiques fortement intéractives.
React permet d'encapsuler l'affichage et la gestion d'évènements dans des \og composants \fg, qui peuvent être réutilisés de manière modulaire.
React propose aussi une extension de JavaScript, qui permet d'écrire du code HTML directement dans le code JavaScript,
ainsi que d'insérer des composants avec la même syntaxe.

\textbf{Next.JS} \cite{nextjs} est un framework simplifiant l'utilisation de React pour des plus grandes applications:
NextJS permet de séparer l'application en différentes pages,
et de naviguer de manière ininterrompue entre ces pages.
NextJS a également pour but d'optimiser la vitesse de chargement de ces pages, en faisant un maximum du rendu de ces pages côté serveur.

\textbf{Nest.JS} \cite{nestjs} est un framework simplifiant la création d'applications back-end.
NestJS utilise l'injection de dépendance pour permettre de plus facilement faire grandir une application back-end,
et propose de nombreux outils pour gérer les requêtes, les bases de données et la documentation.

\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 exé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.

    Executer 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 consistance
    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éceler des problèmes qui n'auraient pas été trouvés pendant le développement.

  \item[Semantic versioning] Nous utilisons le versionnage sémantique pour nos projets et pour les dépendance des projets.
    Le versionnage 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 versionnage 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.
    \end{itemize}
\end{description}


\section{Organisation du stage}

% Durant ce stage, j'ai rejoint l'équipe \entity{Développement Full-Stack - Recherche \& Développement},
% afin de contribuer au développement des applications front-end et back-end de l'entreprise,
% à l'assurance de qualité de ces applications et aux choix techniques faits pour ces applications.

\subsection{Thèmes définis avant le stage}

% Note: commencé avec 9 personnes, puis est passé à 7 personnes
Durant mes échanges avec mon tuteur de stage et le directeur des ressources humaines de \entity{Moment},
nous nous étions convenus que j'allais intégrer l'équipe \entity{Développement Full-Stack - Recherche \& Développement} en tant que développeur.

Mes tâches au sein de cette équipe seraient de:

% https://utbm.jobteaser.com/en/job-offers/8878261-moment-developpeur-se-web-fullstack-stage-ou-alternance
% TODO: clarifier qu'est ce qui constitue un projet R&D
\begin{itemize}
  \item Développer de nouvelles fonctionnalités (notamment de nouvelles \term{API} (interfaces de programmation) et de leur intégration côté client)
  \item Documenter le code (sous forme de commentaires et sous forme de documentation technique)
  \item Participer aux choix fonctionnels (quelles technologies utiliser, comment organiser des librairies, etc.),
    et participation à leur implémentation
  \item Participer à la définition de la roadmap technique, et au suivi de cette roadmap
  \item Aider à améliorer les solutions déjà existantes (amélioration de performances, de maintenabilité, etc.)
  \item Participation aux projets Recherche \& Développement
\end{itemize}

Au moment de mes entretiens pour ma candidature de stage,
les thèmes principaux sur lesquels l'équipe travaillaient étaient le développement de \entity{Mood Digital}
et de \entity{Mood TV}, ainsi qu'un peu de développement pour \entity{Mint}.

J'ai aussi pu apprendre que l'équipe utilise la librairie \entity{React} et le framework \entity{Next.JS} pour ses applications front-end,
et le moteur javascript \entity{Node.JS} avec le framework \entity{Nest.JS} pour ses applications back-end.

J'espérais avant le stage pouvoir surtout travailler sur la partie back-end,
car j'avais jusqu'à ce moment-là peu d'expérience avec \entity{React},
et le peu d'expérience que j'avais ne m'inspirait pas confiance en cette technologie.

J'ai néanmoins décidé d'apprendre en amont du stage la librairie \entity{Solid.JS} \cite{solidjs},
car je n'avais jusqu'à maintenant que fait du développement front-end \og vanilla \fg (sans librairie ou framework).
\entity{Solid.JS} se veut être une librairie de développement front-end plus simple, plus réactive et plus efficace que \entity{React},
et l'apprendre m'a permis d'avoir une première expérience avec la programmation réactive.

\subsection{Premiers jours de stage}

À mon arrivée au stage, j'ai récupéré l'ordinateur portable qui m'a été préparé avec une installation d'Ubuntu,
puis j'ai installé un environnement de développement d'applications dessus (différents outils en ligne de commande,
un éditeur de texte et un gestionnaire de fenêtre avec lequel je suis plus à l'aise).

J'ai aussi reçu la documentation d'\og onboarding \fg,
qui contient une liste de documentations avec lesquelles je devais me familiariser afin de pouvoir travailler efficacement.
J'ai parcouru ces documentations et ai testé certaines des fonctionnalités décrites dans celles-ci dans un mini-projet de test.

L'équipe se réunit chaque matin pour discuter des nouveautés et du travail de la veille,
et pour annoncer sur quoi chaqu'un prévoit de travailler ce jour-ci.
J'ai participé à ces réunions dès mon premier jour,
ce qui m'a permis de rapidement construire une compréhension des problématiques récurrente et de la dynamique des différentes applications.

Nous sommes encouragés dans l'équipe à travailler en programmer en paire,
et en général à collaborer ensemble.
Ma première contribution au code a été faite en programmation en paire,
après avoir remarqué que la logique pour la complexité des mots de passe dans \entity{Mint Admin} était fausse.
Faire cette contribution en pair programming m'a permis d'être guidé dans le processus d'envoi et de vérification de contributions,
ainsi que d'être guidé dans l'organisation de la repository.

\subsection{Planning}

Durant ce stage, j'ai surtout travaillé sur le développement de nouvelles fonctionnalités et la correction de bugs sur les applications suivantes:

\begin{itemize}
  \item \entity{Mint Service}: développement de nouvelles fonctionnalités, sécurisation de l'API
  \item \entity{Mood TV}: optimisation des performances, correction de bugs, refactors
  \item \entity{Mint Admin}: correction de bugs
  \item \entity{Mint Digital}: correction de bugs, développement de la fonctionnalité pour gérer l'accès à internet
\end{itemize}

Comme notre équipe travaille en mode Agile, les sujets et priorités étaient définis semaine par semaine.
Tout de moins, mon stage peut être découpé en trois périodes:

\begin{itemize}
  \item Au début du stage, la priorité était de préparer \entity{Mint Service} et \entity{Mint Admin}
    pour une première version à envoyer au premier client de \entity{Moment Care} (semaines 1-7).
  \item Puis, une fois cette version déployée,
    nous avons travaillé sur l'implémentation des fonctionnalités manquantes dans cette première version (semaines 8-16).
  \item Enfin, nous avons repris le projet \entity{Mood TV},
    qui avait alors vu très peu de modifications (à part mes optimisations) depuis plusieurs mois,
    afin de le refactor pour préparer l'implémentation de \entity{Mint TV}, qui réutilisera la majorité du code de \entity{Mood TV} (semaines 18-23).
\end{itemize}

Comme mon stage commençait le 1$^{\text{er}}$ Septembre 2022 (un jeudi),
j'ai décidé de numéroter le sommaire suivant de telle manière à ce que la semaine du 5 Septembre soit la semaine 1.

\inputfig{timeline}

\section{Travail réalisé sur Mint Service}

Mint Service est une application construite avec \entity{NestJS}.
NestJS est un framework permettant de construire des applications côté serveur en JavaScript,
et de s'assurer que ces applications soient à la fois sûres, efficaces et flexibles \cite{nestjs}.

\subsection{NestJS et organisation du code}

% TODO: hiérarchiser l'argumentaire

NestJS emploie à son coeur les principes de \term{modularité} et d'\term{inversion de contrôle} (\term{IoC}):
\\
L'application est séparée en différents modules, qui eux-mêmes contiennent des \term{services} et des \term{contrôleurs}. \figref{nestjs3}

\begin{description}
  \item[Les services] (aussi appelés \term{providers}) contiennent l'implémentation de la logique nécessaire
    pour répondre aux besoins de l'application: contacter une base de donnée, traiter l'information, faire des
    requêtes réseau, etc.

  \item[Les contrôleurs] sont responsables d'accepter les requêtes des \entity{clients}, de les transformer, de vérifier
    leur légitimité et d'appeler les méthodes des \entity{services} avant de transformer la réponse à envoyer au \entity{client}.
    \\
    NestJS fournit un ensemble d'outils simplifiant l'implémentation des contrôleurs.

  \item[Les modules] s'occupent de gérer la configuration des \entity{services} et des \entity{contrôleurs}:
    chaque \entity{module} indique à NestJS quels \entity{services} et \entity{contrôleurs} il contient,
    ainsi que comment NestJS doit construire ces services dans les cas plus complexes.
    \\
    Les modules peuvent exporter un sous-ensemble de leurs services, ce qui permet de rapidement
    réutiliser des services en important le module leur étant associé. \figref{nestjs2}
\end{description}

\begin{figure}[H]
  \centering
  \includegraphics{nestjs3}
  \caption{Organisation d'un module NestJS typique}
  \label{nestjs3}
\end{figure}


La séparation entre contrôleurs et services permet d'avoir une claire \term{séparation des préoccupations}:

\begin{itemize}
  \item Les contrôleurs s'occupent de gérer, valider et répondre aux requêtes faites par un client;
  \item Les services s'occupent de l'implémentation de la logique permettant de satisfaire la requête;
  \item Les modules s'occupent de configurer les services et les contrôleurs, et permettent la modularisation du code.
\end{itemize}

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 contrôleurs,
d'une manière similaire au framework \entity{Spring} en \entity{Java}. \figref{nestjs1}

% TODO: trouver une source
% Separation of concerns
% https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=0fd24fa8ac2a77c4709103eb8a179fec38311fe8
% "On the importance of the separation-of-concerns principle in secure software engineering"
Il devient ainsi plus simple avec ce système de modifier différentes parties du code sans accidentellement casser une autre partie du code.
Il est aussi plus simple de tester du code organisé de la manière suivante, car les services et les contrôleurs peuvent
être placés dans un environnement isolé et testés individuellement ou collectivement.


\subsection{Système d'envoi de mail}

\subsubsection{Analyse et prototype}

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'e-mails sans devoir faire de grands changements du côté des utilisateurs de la librairie.
  \item Il doit pouvoir envoyer des e-mails qui s'affichent de la manière voulue sur la majorités des boîtes mail.
  \item Il doit pouvoir envoyer des e-mails contenant des informations sur l'utilisateur; cette étape devra être faite avec le service de \term{templates} d'e-mail sur \entity{Amazon SES} \cite{amazonses} \cite{amazonsestemplate}
  \item Il doit permettre de décrire le contenu des e-mails d'une manière facilement maintenable et réutilisable.
\end{itemize}

Mon travail a commencé par l'analyse de différentes solutions permettant d'adresser les deux dernières conditions.

Par le passé, l'entreprise avait déjà utilisé le moteur \entity{Handlebars} \cite{handlebars},
une librairie de recherche et de remplacement de texte, qui permet d'avoir des formes simples de logique,
comme des conditions ou des boucles.

Bien que \entity{Handlebars} fonctionne bien pour insérer les informations de l'utilisateur dans les mails,
il ne permet pas de facilement réutiliser du code, qui est souvent complexe afin d'assurer un bon affiche sur les
différents programmes de boîte mail.

J'ai donc cherché à avoir un système de \og composants \fg dans la solution choisie, afin de pouvoir construire des couches
d'abstraction et de réutiliser facilement le code. Ces composants doivent, plus spécifiquement:

\begin{itemize}
  \item Pouvoir être appelés avec différentes valeurs en arguments
  \item Pouvoir appeler d'autres composants
\end{itemize}

J'ai sélectionné 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 e-mail 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 e-mails sous format texte et HTML en même temps,
permettant d'avoir des e-mails 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}.
Cette première implémentation devait faire l'envoi de mail en deux étapes:

\begin{enumerate}
  \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 dirigeant à \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 e-mails depuis un dossier donné
  \item Transformer ceux-ci avec \texttt{handlebars-generator} en HTML et en texte
  \item Mettre en ligne des \term{templates} pour utiliser le service d'envoi d'e-mails personalisés d'\entity{Amazon}
  \item Envoyer les \term{templates} avec les informations de l'utilisateur dedans avec \entity{Amazon SES}
\end{itemize}

Afin de pouvoir tester le fonctionnement de la librairie \texttt{mailing-nest},
j'ai également créé une petite application Nest.JS qui affiche dans le navigateur les e-mails en format HTML et en format texte.
Cette application permet aussi de développer rapidement les e-mails sans devoir passer par Amazon pour tester
les modifications.

Enfin, j'ai implémenté un module Nest.JS dans l'application \entity{Mint Service},
qui charge le module de \texttt{mailing-nest} avec en paramètre le chemin des e-mails pour \entity{Mint}.
Ce module est importé à plusieurs endroits dans le code, et expose des méthodes dans son service permettant
de convertir les entités de \entity{Mint Service} au format attendu par les e-mails.

\begin{figure}[H]
  \includegraphics[width=\textwidth]{mailingnest}
  \caption{Organisation initiale du système d'envoi de mail dans Mint-Service}
\end{figure}

Avec le système de mail en place, j'ai pu implémenter la première template d'e-mail, qui était celle pour l'envoi d'identifiants au patients.
Très rapidement, j'ai pu voir sur \url{canie-mail.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 e-mails pour pouvoir supporter \entity{Microsoft Outlook},
qui est à ce jour le 3ème client e-mail 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}:

\inputfig{email}

\subsection{Rétrospective sur le système d'envoi de mails}

% - [x] parler des désavantages de cette méthode
% - [x] parler de ce qu'on prévoyait de faire
% - [~] parler de comment on l'a fait (pour showcase l'avantage du monorepo), et des étapes prises
% - [x] parler des améliorations futures qui pourront être faites
%   (ajouter plus de providers, simplifier la logique pour choisir les providers, react.e-mail, svelte, etc.)
% - [ ] Comparer la maintenabilité

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'e-mails 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'e-mails.
  \\
  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}

  \item Le choix de faire le rendu final des e-mails avec les templates d'\entity{Amazon SES} rend l'écriture des e-mails plus compliquée
  (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{e-mailsrchbs}).
  \\
  Ce choix rend aussi le débogage de toute erreur lors du deuxième rendu très compliqué,
  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 e-mails 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'e-mails
  \item Dépréciation des méthodes d'envoi d'e-mail via les templates SES (\texttt{sendTemplatedEmail}), et ajout des méthodes pour l'envoi pur d'e-mails (\texttt{sendEmail})
  \item Modification des templates pour ne plus utiliser les balises secondaires
  \item Modification de l'application d'apperçu des e-mails 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 e-mails 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 e-mails.

À 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.e-mail/}{React Email} ou \href{https://astro.build/}{Astro} pour écrire les templates en Javascript, ce qui permettrait 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}
\end{figure}

\section{Travail sur Mood TV}

\subsection{Introduction}

\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.

% Présentation de la plateforme, des télés (chrome 53 hehe), mentionner procentric
% Parler de l'hydration, du rendu, etc.

\subsection{Analyse des performances}

La première étape avant de pouvoir optimiser les performances de l'application est de mesurer ses performances.
Il faut pour cela mesurer de manière précise le temps moyen de chargement,
et il faut pouvoir avoir un aperçu de quelles opérations prennent le plus de temps.

J'ai tout d'abords activé le mode de débogage sur la télévision,
qui peut être fait via l'API propriétaire de contrôle de la télévision.
Avec ce mode de débogage, on peut se connecter depuis une interface web aux outils de développeur du navigateur tournant sur la télévision.

J'ai ensuite pu prendre plusieurs profils de performance pour observer quelles opérations prenait le plus de temps:

\begin{figure}[H]
  \includegraphics[width=\textwidth]{mood-tv-before.png}
  \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'\term{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-ci.
\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:

\begin{align*}
  \mu^{\star}_n &= \frac{\sum_{i=1}^{n} \omega_i}{n} \\
  (\sigma^{\star}_n)^2 = S_{n-1}^2 &= \frac{\sum_{i=1}^{n} (\omega_i - \mu^{\star}_n)^2}{n-1} \\
  &= \frac{(\mu^{\star}_n)^2}{n-1} - \frac{\sum_{i=1}^{n} \omega_i^2}{n(n-1)} \\ \\
  \mu^{\star}_n \xrightarrow{n\rightarrow\infty} \mu & \quad \quad \quad \sigma^{\star}_n \xrightarrow{n\rightarrow\infty} \sigma
\end{align*}

Afin de pouvoir comparer différents ensembles de valeurs,
je fais l'hypothèse que les valeurs suivent une distribution normale ($X \hookrightarrow \mathcal{N}(\mu, \sigma^2)$).

J'ai décidé d'utiliser dans mon programme de statistique un test rudimentaire de normalité,
également présent dans la librairie populaire de benchmark pour le langage \entity{Rust} nommée \entity{Criterion}, \cite{criterion}
qui m'a permis de détecter une erreur dans la mesure de donnée (celle-ci mesurait la même donnée plusieurs fois).

Ce test de normalité vérifie simplement que plus de 95\% des valeurs mesurée tombent dans l'intervalle
$\mu^{\star} \pm \sigma \cdot z_{0.975}$.
Comme $\sigma$ n'est pas connu, je majore $\sigma^{\star}$ par la valeur haute de l'approximation \cite{tapprox} de son intervalle de confiance. \figref{normalitytest}

Enfin, on peut utiliser le t-test sur les mesures pour estimer si deux variables aléatoires différentes $X$ et $Y$ diffèrent bien de moyenne. \cite{ttest}
Avec ce test, il est alors possible de déterminer si les performances se sont améliorées ou non.

Pour \entity{Mood TV}, les valeurs mesurées sont les suivantes, en millisecondes:

\begin{itemize}
  \item Le temps jusqu'au début de l'hydration: \textbf{hydration}
  \item Le temps jusqu'à la première exécution des \texttt{useEffect}: \textbf{mount}
  \item Le temps jusqu'à ce que l'entièreté des requêtes pour charger les informations des films soient finies: \textbf{ready}
\end{itemize}

\inputfig{perf1}

% Screenshot du panel des performances sur mood tv (avant et après)
% Parler de la loi du milieu, du Z-test, du test de normalité, de comment récupérer ces données

\subsection{Optimisation du temps de chargement}

% - [x] Optimisation du nombre de requêtes faites (avec un dessin? ~ plus tard)
% - [x] Optimisation de la taille du bundle
% - [x] Optimisation du parsing des requêtes
% - [x] Avoir de jolis nombres
% - [ ] tableau final avec toutes les mesures

\subsubsection{Optimisation du nombre de requêtes}

La première optimisation a été d'éviter que les requêtes pour récupérer les informations sur les films ne soient envoyées plusieurs fois.
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'exécuter à nouveau,
et de nouvelles requêtes sont envoyées en conséquence. \figref{fromeffectloop}

Pour résoudre ce problème, j'ai créé une nouvelle fonction qui récupère l'entièreté des informations des films,
et qui seulement une fois que toutes les requêtes soient finies stoque ces informations dans le cache.

\inputfig{perf2}

\subsubsection{Optimisation de la taille du bundle}

Ensuite, j'ai optimisé la taille du bundle javascript, pour passer de $350$ kilooctets à $243$ kilooctets,
en enlèvant les librairies qu'on n'utilisait peu et qui prenaient beaucoup de place, comme \texttt{browserify-crypto}.

Réduire la taille du bundle permet de réduire le temps passé à télécharger le code javascript de la page,
et le temps passé à compiler ce code et à charger les différents modules avec \entity{webpack}.

\inputfig{perf3}

\subsubsection{Optimisation du traitement des réponses}

Enfin, j'ai optimisé la logique de traitement des réponses des requêtes pour récupérer les informations sur les films.
Ce traitement, jusqu'à ce moment, se faisait grâce à la librairie \texttt{class-transformer} \cite{classtransformer},
qui permet de facilement transformer des objets ordinaires en instances de classe.

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'exécution 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}

\begin{figure}
  \includegraphics[width=\textwidth]{mood-tv-after.png}
  \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'évènements 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, intervalle de confiance)
\end{itemize}

% TODO: a section about
% https://gitlab.com/interactive-mobility/front-end/web/moment-entertainment-portal/-/merge_requests/1007
% https://gitlab.com/interactive-mobility/moment-care/moment-care-web/-/merge_requests/1115/commits
% https://gitlab.com/interactive-mobility/front-end/web/moment-entertainment-portal/-/merge_requests/1008/commits

\section{Conclusion}

\subsection{Synthèse des résultats}

J'ai été globalement satisfait du travail que j'ai pu fournir durant ce stage:
les résultats attendus étaient obtenus (le système d'envoi de mail marche encore au moment où j'écris ce rapport, la télévision charge de manière consistante en moins de 5 secondes, etc.)
et j'ai pu écrire des tests unitaires pour une bonne partie de mon code, ce qui permettra de maintenir sa fonctionnalité dans les années à venir.

\subsection{Appréciation des technologies utilisées}

J'ai eu durant ce stage des sentiments partagés \entity{React}:

D'un côté, je trouve que la programmation avec React souffre de la décision de React à être à mi-chemin entre de la programmation réactive \og fine \fg \cite{reactivity}
et de la gestion manuelle de mise à jour.
J'ai rencontré beaucoup de bugs causés par des effets de bord du système de React,
dont certains qui ne pouvaient qu'être résolus en changeant en profondeur l'organisation de plusieurs composants.

De l'autre côté, le refactor de \entity{Mood TV} pour extraire ses composants et les placer dans une librairie était très agréable,
car j'avais le contrôle sur l'organisation que ces composants allaient avoir, et le résultat était très satisfaisant une fois ces composants agencés ensemble.

J'ai apprécié la programmation autour de \entity{Nest.JS}:
le principe d'inversion de contrôle permet d'écrire du code facilement vérifiable et réutilisable,
ce qui rend la base de code plus agréable à naviguer et utiliser.

J'ai enfin été agréablement surpris par \entity{TypeScript}:
si on active l'ensemble des vérifications du code, alors il y a très peu de chances d'avoir des erreurs de type au runtime.
Le système de type est assez avancé pour pouvoir concevoir des types qui garantissent des invariantes qui auraient été difficiles à garantir dans d'autres langages typés.
Écrire des types avancés en TypeScript est presque un art. \figref{types}

\subsection{Estimation du gain apporté}

Pour donner une estimation du gain que mon travail a apporté à l'entreprise,
j'estime que j'ai contribué à 10\% du code sur l'ensemble des applications dévelopées pour \entity{Moment Care}.
Si on estime ensuite que notre équipe contribue à la moitié de la valeur ajoutée par \entity{Moment Care},
et que \entity{Moment Care} génère environ 200,000€ par an (les bénéfices de l'année 2022 de \entity{Moment Care} étaient de 183,000€),
alors on obtient une fourchette basse du gain que j'ai apporté, qui s'élève à 10,000€/an pour les quelques années à suivre.

Naturellement, ma part de contribution va diminuer, via du code écrit par d'autres personnes dans le futur, et via des refactors de mon code.
Une rapide analyse du code sur la monorepository indique que la demi-vie du code est de 6 mois; \figref{halflife}
ceci donne environ 2.9 années d'espérance à mon code, soit une fourchette basse de 30,000€ de gain sur les années à venir.


\newpage

\begingroup
\raggedright
\bibliographystyle{plain}
\bibliography{references}{}
\endgroup

\newpage
\section{Annexes}

\inputfig{nestjs1}
\inputfig{nestjs2}
\inputfig{email-src-hbs}
\inputfig{email-src-mjml}
% \inputfig{ttest}
\inputfig{fromeffectloop}
\inputfig{normalitytest}

\begin{figure}[H]
  \includegraphics[width=\textwidth]{survival_plot}
  \caption{Graphique de survivabilité du code sur la monorepository}
  \label{halflife}
\end{figure}

\inputfig{types}

\newpage
\makeutbmbackcover{}

\end{document}