@ -501,7 +503,7 @@ Ce système prend la forme de plusieurs librairies, qui doit remplir les conditi
\item Il doit être facilement réutilisable dans d'autres projets.
\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 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 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.
\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}
\item Il doit permettre de décrire le contenu des emails d'une manière facilement maintenable et réutilisable.
\item Il doit permettre de décrire le contenu des emails d'une manière facilement maintenable et réutilisable.
\end{itemize}
\end{itemize}
@ -607,10 +609,10 @@ J'ai choisi la librairie \entity{MJML} \cite{mjml}, qui utilise un langage resse
\subsection{Rétrospective sur le système d'envoi de mails}
\subsection{Rétrospective sur le système d'envoi de mails}
% - [] parler des désavantages de cette méthode
% - [x] parler des désavantages de cette méthode
% - [] parler de ce qu'on prévoyait de faire
% - [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
% - [~] parler de comment on l'a fait (pour showcase l'avantage du monorepo), et des étapes prises
% - [] parler des améliorations futures qui pourront être faites
% - [x] parler des améliorations futures qui pourront être faites
% (ajouter plus de providers, simplifier la logique pour choisir les providers, react.email, svelte, etc.)
% (ajouter plus de providers, simplifier la logique pour choisir les providers, react.email, svelte, etc.)
% - [ ] Comparer la maintenabilité
% - [ ] Comparer la maintenabilité
@ -636,7 +638,7 @@ Malgré \entity{MJML} et le système de composants, écrire des templates d'emai
\item Le choix de faire le rendu final des templates via les templates d'\entity{Amazon SES} rend l'écriture des emails plus compliquée
\item Le choix de faire le rendu final des templates via les templates d'\entity{Amazon SES} rend l'écriture des emails 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{emailsrchbs}).
(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}).
\\
\\
Ce choix rend aussi le débuggage de toute erreur lors du deuxième rendu très compliqué,
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
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.
de transfert de messages, puis de l'activer en envoyant les mails avec un paramètre précis.
\end{itemize}
\end{itemize}
@ -689,21 +691,129 @@ je pense qu'il est encore possible d'améliorer de différentes manières ce sys
\subsection{Introduction?}
\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
% Présentation de la plateforme, des télés (chrome 53 hehe), mentionner procentric
% Parler de l'hydration, du rendu, etc.
% Parler de l'hydration, du rendu, etc.
\subsection{Analyse des performances}
\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 celà 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:
\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: