Semaine 1 & Audit des tests sur la monorepository contenant \entity{Mint Service}, \entity{Mint Admin} et \entity{Mood TV}\\
Semaines 2-4 & Développement du système d'envoi de mails pour \entity{Mint Service}\\
Semaine 5 & Correction de bugs sur \entity{Mint Admin}\\
Semaine 6 & Correction de bugs sur \entity{Mint Admin}, écriture de tests pour \entity{Mint Service},
mise en place de sécurités sur \entity{Mint Service}\\
Semaine 7 & Correction de bugs sur \entity{Mint Admin}, correction d'un bug sur la transformation de donnée avant l'envoi de mails \\
Semaines 8-9 & Correction de bugs sur \entity{Mint Admin}, implémentation d'un système de payement pour \entity{Mint Service}. \\
Semaine 10 & Mise en place de l'email pour la confirmation d'un achat,
correction d'un bug dans \entity{Mint Service}, % causant les mots de passes des utilisateurs à être hashés à nouveau,
extension du système de sécurisation des routes de \entity{Mint Service}\\
Semaines 11-13 & Intégration du système de payement dans \entity{Mint Service}\\
Semaine 14 & Optimisation du nombre de requêtes faites par \entity{Flymingo Digital}, gestion d'erreur dans la page de payement sur \entity{Flymingo Digital}\\
Semaine 15 & Correction de bugs sur \entity{Flymingo Digital},
empêcher les routes sur \entity{Mint Service} d'envoyer ou d'accepter un mot de passe. \\
Semaine 16 & Refactor du système pour automatiquement créer des routes pour les relations entre entités dans \entity{Mint Service}\\
Semaine 18 & Implémentation de la partie front-end du système de gestion d'accès à internet sur \entity{Mint Digital}\\
Semaine 19-21 & Migration et refactor des composants de \entity{Mood TV} vers des librairies \\
Semaine 22 & Migration de composants de \entity{Mood TV} vers des librairies \\
Semaine 23 & Correction d'un bug dans \entity{Mood TV} et le portail admin de \entityb{Mood TV} qui empêchait les télévisions d'éxecuter les tâches envoyées par le portail admin \\
\textit{Semaine 24}&\textit{Documentation de mes connaissances sur le projet pour une passation de savoir}\\
Ce produit est composé d'un serveur, nommé \entity{Flymingo Box}, sur lequel tournent plusieures applications:
\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.
\begin{itemize}
Ce produit est composé d'un serveur, nommé \entity{Flymingo Box}, qui émet son propre réseau wifi,
\item Une application web, \entity{Flymingo Digital}, sur laquelle les passagers peuvent se connecter.
sur lequel les passagers peuvent se connecter pour profiter des divertissements.
\item La \entity{Content API}, qui est une API pour accéder aux informations sur les différents divertissements
disponibles sur le serveur. Cette API permet aux clients d'avoir un certain degré de customabilité.
\begin{wrapfigure}{r}{0.25\textwidth}
Cette API sert également les différents contenus (vidéo, musique, magazines).
\entity{Mint} est le produit que \entityb{Moment} développe et déploie en ce moment dans les cliniques de santé:
\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}
\begin{description}
\item[Mint Admin] est une application web permettant aux clinique de fixer les prix
\item[Mint Admin,] qui est une application web permettant aux clinique de fixer les prix
pour les offres que celles-cis souhaite mettre à disposition, ainsi que de gérer l'assignement des différents
pour les offres que celles-cis souhaite mettre à disposition, ainsi que de gérer l'assignement des différents
appareils (comme les télévisions et les tablettes) aux chambres, des différents patients à ces chambres,
appareils (comme les télévisions et les tablettes) aux chambres, des différents patients à ces chambres,
et des offres aux patients.
et des offres aux patients.
\item[Mint Digital] est une application web que les patients des cliniques utilisent
\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.
pour se connecter, acheter des offres en ligne, regarder des films, documentaires, magazines et écouter de la musique.
\item[Mint Service] est le back-end avec lequel \entity{Mint Admin} et \entity{Mint Digital} communiquent.
\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,
\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.
et à \entity{Mint Digital} de permettre aux utilisateurs de se connecter et d'acheter des offres en ligne.
\item[Mint Tab] 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}.
\item[Mint TV] est 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}.
\end{description}
\end{description}
Durant ce stage, j'ai surtout travaillé sur les applications suivantes:
\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{itemize}
\begin{description}
\item Mint Service
\item[Mint TV,] qui est une application tournant sur les télévisions connectées, qui permet aux patients des
\item Mint Admin
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.
\item Mint Digital
\end{description}
\item Mint TV et Mood TV
\end{itemize}
\section{Organisation du stage}
\section{Organisation du stage}
@ -415,13 +468,113 @@ et propose de nombreux outils pour gérer les requêtes, les bases de données e
% Agile, poker planning
% Agile, poker planning
% Backlog, recettes, versioning
% Backlog, recettes, versioning
\subsubsection{Méthode de travail}
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.
\end{itemize}
\end{description}
\subsection{Planning}
\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:
% Afin de pouvoir développer \entity{Mint TV} sans duplication de code,
\begin{itemize}
% nous avons décidé de prendre l'ensemble des composants de \entity{Mood TV},
\item\entity{Mint Service}: développement de nouvelles fonctionnalités, sécurisation de l'API
% de les nettoyer et des les mettre dans une librairie au sein de la monorepository.
\item\entity{Mood TV}: optimisation des performances, correction de bugs, réfactors
\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}
\section{Travail réalisé sur Mint Service}
@ -627,7 +780,7 @@ Malgré \entity{MJML} et le système de composants, écrire des templates d'emai
HTML lui a une structure plus flexible,
HTML lui a une structure plus flexible,
permettant d'imbriquer la pluspart des éléments disponibles dans un ordre arbitraire. \cite{mdncontentcategories}
permettant d'imbriquer la pluspart des éléments disponibles dans un ordre arbitraire. \cite{mdncontentcategories}
\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 emails avec 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ébogage 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é,
@ -681,7 +834,7 @@ je pense qu'il est encore possible d'améliorer de différentes manières ce sys
\section{Travail sur Mood TV}
\section{Travail sur Mood TV}
\subsection{Introduction?}
\subsection{Introduction}
\entity{Mood TV} est une application tournant sur les télévisions \og intelligentes \fg produites par \entity{LG}.
\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}.
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}.
@ -862,6 +1015,12 @@ Faire ce travail m'a permis d'avoir une compréhension plus profonde sur différ
\item L'analyse de données de performances (z-test, t-test, intervale de confiance)
\item L'analyse de données de performances (z-test, t-test, intervale de confiance)
Adrien Burgun
2 years ago