% 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}
\subsubsection{Méthode de travail}
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{Flymingo Digital}
et de \entity{Mood TV}, ainsi qu'un peu de développement pour \entity{Mint}.
L'équipe \entity{Développement Full-Stack} fonctionne avec la méthode Scrum, qui est une méthode Agile. \cite{cohen2004introduction}
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.
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.
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.
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.
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.
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.
\subsection{Premiers jours de stage}
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.
À 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).
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.
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-cis dans un mini-projet de test.
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}.
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.
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é.
Nous sommes encouragés dans l'équipe à travailler en \og pair programming \fg,
et en général à collaborer ensemble.
Ma première contribution au code a été faite en pair programming,
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.
\subsubsection{Outils utilisés}
\subsection{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}
@ -463,44 +459,6 @@ NextJS a également pour but d'optimiser la vitesse de chargement de ces pages,
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.
\subsection{Organisation de l'équipe}
% Agile, poker planning
% 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:
@ -514,6 +472,7 @@ L'équipe a plusieurs outils en place pour assurer la qualité du code et des ap
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.
@ -547,6 +506,71 @@ L'équipe a plusieurs outils en place pour assurer la qualité du code et des ap
\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.
z_a \;&\text{est tel que}\int_{-\infty}^{z_a}{\frac{e^{-\frac{(x-\mu)^2}{2\sigma^2}}}{\sigma\sqrt{2\pi}}}=a
\end{align*}
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 plusieures fois).
Ce test de normalité vérifie simplement que plus de 95\% des valeurs mesurée tombent dans l'intervale
$\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 intervale de confiance. \figref{normalitytest}
Enfin, on peut utiliser le t-test pour estimer si deux valeurs différentes $X$ et $Y$ diffèrent bien de moyenne. \cite{ttest}
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:
@ -1042,6 +1067,6 @@ Faire ce travail m'a permis d'avoir une compréhension plus profonde sur différ
