Commit f6f78533 authored by Skia's avatar Skia 🤘
Browse files

Almost finish the report

parent 2d808e07
......@@ -68,7 +68,7 @@ Lo-J (Guillaume Renaud)}
\chapter{Introduction}
\par Après le développement de la base du nouveau site de l'AE, le projet \textsc{Sith}, au Printemps 2016, la mise en
\par Après le développement de la base du nouveau site de l'AE, le projet \emph{Sith}, au Printemps 2016, la mise en
production a pu avoir lieu avec succès fin Août 2016.
\par Mais le site était encore très incomplet, et il était nécessaire d'y ajouter un grand nombre de fonctionnalités
......@@ -147,7 +147,17 @@ rarement, mais il faudrait tout de même arriver à le résoudre un jour.
\subsection{Gestion des fichiers}
\label{sub:gestion_des_fichiers}
\par
\par L'envoie en grande quantité de photos nécéssite une gestion des fichiers solide, en même temps qu'un formulaire
d'envoie efficace, capable d'envoyer plusieurs dizaines de photos en une seule action de l'utilisateur.
\par L'envoie est donc fait à l'aide de requêtes AJAX pour envoyer les photos une par une et éviter alors le timeout.
\par Concernant les fichiers une fois envoyé, ils sont en réalité traités par la classe \verb#SithFile# qui gère tous
les fichiers du site. Cela ne fait qu'une seule classe à développer, de même qu'un seul système de fichier avec une
seule arborescence, ce qui est beaucoup plus robuste.
\par La difficulté a aussi été de permettre le déplacement des fichiers, par couper-coller, tout en faisant de même dans
le système de fichier réel, afin d'avoir une arborescence cohérente même en cas de perte de la base de données.
\subsection{Optimisation des pages}
\label{sub:optimisation_des_pages}
......@@ -161,13 +171,13 @@ photos, mais ce temps à pu être réduit à moins de 3 secondes.
traitement que nécessaire, afin de mettre en "cache" une grande partie des actions, comme par exemple la génération des
miniatures des albums.
\par Une autre technique pour gagner du temps est de mettre en cache certaines requêtes en forcant les \textsc{QuerySet}
à s'évaluer dans une \textsc{list} \textbf{Python} que l'on stocke afin d'obtenir sa longueur, au lieu de lancer d'abord
un \textsc{count}, puis une itération des résultats, qui en utilisant directement l'ORM, conduit à réaliser deux
\par Une autre technique pour gagner du temps est de mettre en cache certaines requêtes en forcant les \emph{QuerySet}
à s'évaluer dans une \emph{list} \textbf{Python} que l'on stocke afin d'obtenir sa longueur, au lieu de lancer d'abord
un \emph{count}, puis une itération des résultats, qui en utilisant directement l'ORM, conduit à réaliser deux
requêtes SQL.
\par Enfin, le passage à \textbf{HTTP/2} permettrait d'améliorer encore les performances côté utilisateur puisqu'il n'y
aurait plus qu'un seul \textsc{socket} d'ouvert pour transférer toutes les photos d'une page par exemple, sans avoir
aurait plus qu'un seul \emph{socket} d'ouvert pour transférer toutes les photos d'une page par exemple, sans avoir
pour autant à toucher au code.
......@@ -192,15 +202,37 @@ pour autant à toucher au code.
\subsection{Automatisation d'un widget particulier pour les formulaires}
\label{sub:automatisation_d_un_widget_particulier_pour_les_formulaires}
\par La demande est venue du \textbf{BdF} qui a voulu autoriser pour certains poste un nombre de vote supérieur à 1.
Cela signifie que l'on passe d'un choix simple, type \verb#radio# à un choix multiple, type \verb#checkbox#, tout cela
étant paramètrable dans l'élection.
\par Ce genre de choix n'étant pas disponible dans \textbf{Django} de base, il a fallut développer le \emph{widget} à
utiliser dans le formulaire qui permette cette configuration tout en validant bien les données reçues par rapport au
modèle, et éviter ainsi de pouvoir "tricher" en envoyant des requêtes erronées.
\subsection{Revue du code d'un autre développeur}
\label{sub:revue_du_code_d_un_autre_developpeur}
\par \emph{Sli} étant le principal développeur de cette application, un gros travail de revue de code a dû être
effectuer afin de garantir une certaine cohérence avec le reste du projet.
\par C'est un travail très long et fastidieux, car il faut bien revérifier chaque ligne, sur chaque fichier, tout en
faisant des commentaire lorsque quelque chose ne va pas. \textbf{Gitlab} a, à ce niveau, grandement facilité la tâche, à
l'aide de ses outils de \emph{merge request} assez avancés.
\par En plus du code en lui-même, il a fallut porter une attention particulière aux migrations. Ces fichiers générés
automatiquement par \textbf{Django} sont responsables du maintient d'une base de donnée cohérente malgré les évolutions
des modèles. Même si le code parait donc valide, il est impératif de surveiller que la chaîne de dépendance des dites
migrations ne soit pas cassée, au risque de problèmes potentiels au moment de la mise en production, ce qui entraînent à
coup sûr un \emph{downtime}.
\chapter{Les stocks}
\label{sub:les_stocks}
\par Développeur principal: Lo-J
\par Cette application s’occupe de la gestion des stocks des comptoirs de type « BAR ». Elle permet de suivre les quantités restantes afin de pouvoir déterminer de manière automatisée quels sont les produits qu’il faut acheter et en quelle quantité.
\vskip 2em
\par Cette application s’occupe de la gestion des stocks des comptoirs de type « BAR ». Elle permet de suivre les
quantités restantes afin de pouvoir déterminer de manière automatisée quels sont les produits qu’il faut acheter et en
quelle quantité.
\section{Liste des modèles}
\label{sec:liste_des_modeles}
......@@ -209,52 +241,90 @@ pour autant à toucher au code.
\par Un Stock possède un nom et est lié à la classe Counter. Ainsi, chaque Comptoir peut avoir son propre Stock.
\subsection{StockItem}
\par Un StockItem possède un nom, une quantité unitaire, une quantité effective, une quantité minimale et est lié à la classe Stock ainsi qu’à la classe ProductType. De cette manière, chaque élément appartient à un Stock et il est catégorisé de la même manière que les Products (qui sont les objets utilisés pour la vente dans les comptoirs).
\par Un StockItem possède un nom, une quantité unitaire, une quantité effective, une quantité minimale et est lié à la
classe Stock ainsi qu’à la classe ProductType. De cette manière, chaque élément appartient à un Stock et il est
catégorisé de la même manière que les Products (qui sont les objets utilisés pour la vente dans les comptoirs).
\subsection{ShoppingList}
\par Une ShoppingList possède un nom, une date, un booléen (fait ou à faire), un commentaire et est liée à un Stock. Chaque ShoppingList est donc liée à un Stock ce qui permet d’avoir des listes de courses spécifique à chaque comptoir.
\par Une ShoppingList possède un nom, une date, un booléen (fait ou à faire), un commentaire et est liée à un Stock.
Chaque ShoppingList est donc liée à un Stock ce qui permet d’avoir des listes de courses spécifique à chaque comptoir.
\subsection{ShoppingListItem}
\par Un ShoppingListItem possède un nom, une quantité demandée, une quantité achetée et est lié à la classe StockItem, à la classe ShoppingList et à la classe ProductType. Cela permet de pouvoir faire plusieurs listes de courses différentes en même temps et d’en garder un historique.
\par Un ShoppingListItem possède un nom, une quantité demandée, une quantité achetée et est lié à la classe StockItem, à
la classe ShoppingList et à la classe ProductType. Cela permet de pouvoir faire plusieurs listes de courses différentes
en même temps et d’en garder un historique.
\section{Fonctionnement}
\label{sec:fonctionnement}
\par Au départ, si le comptoir de type « BAR » n’a pas de stock, la seule chose qu’il est possible de faire est d’en créer un. Ensuite, il va falloir créer les objets StockItem en indiquant pour chacun les quantités qu’il y a dans le stock.
\par De plus, la personne (généralement le Responsable du lieu de vie) qui aura la responsabilité d’informatiser les stocks devra aussi définir la quantité unitaire, effective et minimale.
\par Par exemple, les Cheeseburger vendus aux différents comptoirs sont achetés par boite de 6, la quantité unitaire sera donc 6, la quantité effective correspondra au nombre de boites restantes dans le stock (c’est à dire dans la réserve du lieu de vie, une boite sortie du stock est considérée comme consommée) et enfin, la quantité minimale servira de valeur seuil.
\par Une fois l’état de la réserve retranscrit dans le site, il reste encore gérer les stocks de manière quotidienne. Pour ce faire, l’application se décompose en 3 parties :
\par Au départ, si le comptoir de type « BAR » n’a pas de stock, la seule chose qu’il est possible de faire est d’en
créer un. Ensuite, il va falloir créer les objets StockItem en indiquant pour chacun les quantités qu’il y a dans le
stock.
\par De plus, la personne (généralement le Responsable du lieu de vie) qui aura la responsabilité d’informatiser les
stocks devra aussi définir la quantité unitaire, effective et minimale.
\par Par exemple, les Cheeseburger vendus aux différents comptoirs sont achetés par boite de 6, la quantité unitaire
sera donc 6, la quantité effective correspondra au nombre de boites restantes dans le stock (c’est à dire dans la
réserve du lieu de vie, une boite sortie du stock est considérée comme consommée) et enfin, la quantité minimale servira
de valeur seuil.
\par Une fois l’état de la réserve retranscrit dans le site, il reste encore gérer les stocks de manière quotidienne.
Pour ce faire, l’application se décompose en 3 parties :
\begin{itemize}
\item Création automatique des listes de courses
\item Approvisionnement du stock
\item Prise d’éléments dans le stock
\end{itemize}
\par Lorsque l’on accède à la partie qui s’occupe de la gestion des listes de courses, il y a un bouton permettant de créer une liste de courses en fonction de l’état des stocks à cet instant, puis un premier tableau contenant les listes de courses qu’il faut faire et enfin un second tableau servant d’historique des listes de courses déjà effectuées.
\par Pour chaque liste de course ainsi créée, qu’elle soit « faite » ou « à faire », il est possible de cliquer sur son nom pour voir le détail de ce qu’elle comprend.
\par Lorsque l’on accède à la partie qui s’occupe de la gestion des listes de courses, il y a un bouton permettant de
créer une liste de courses en fonction de l’état des stocks à cet instant, puis un premier tableau contenant les listes
de courses qu’il faut faire et enfin un second tableau servant d’historique des listes de courses déjà effectuées.
\par Pour chaque liste de course ainsi créée, qu’elle soit « faite » ou « à faire », il est possible de cliquer sur son
nom pour voir le détail de ce qu’elle comprend.
\subsection{Création automatique des listes de courses}
\par En cliquant sur le bouton permettant de créer une nouvelle liste de courses, il faut remplir un formulaire. Les informations à donner dans ce formulaire sont le nom de la liste de course (par exemple, une liste spéciale pour Leclerc), ensuite, apparaissent tous les StockItem ayant une quantité effective inférieure au seuil fixé par leur quantité minimale. Il faut donc donner pour chacun de ces éléments une quantité à acheter. Enfin, un dernier champ de commentaire peut être compléter, il sert à demander l’achat d’éléments qui n’apparaissent pas dans le Stock, par exemple, des couteaux, fourchettes ou encore tasses …
\par Lors de la validation de ce formulaire, la liste de courses est créée et est ajoutée au tableau contenant les listes de courses à faire.
\par En cliquant sur le bouton permettant de créer une nouvelle liste de courses, il faut remplir un formulaire. Les
informations à donner dans ce formulaire sont le nom de la liste de course (par exemple, une liste spéciale pour
Leclerc), ensuite, apparaissent tous les StockItem ayant une quantité effective inférieure au seuil fixé par leur
quantité minimale. Il faut donc donner pour chacun de ces éléments une quantité à acheter. Enfin, un dernier champ de
commentaire peut être compléter, il sert à demander l’achat d’éléments qui n’apparaissent pas dans le Stock, par
exemple, des couteaux, fourchettes ou encore tasses...
\par Lors de la validation de ce formulaire, la liste de courses est créée et est ajoutée au tableau contenant les
listes de courses à faire.
\subsection{Approvisionnement du stock}
\par Au retour des courses, il faut ranger les produits achetés dans la réserve. À ce moment-là, il faut aussi mettre à jour le stock. Une opération « Mettre à jour le stock » est disponible pour chaque liste de courses du tableau « À faire ».
\par En effectuant cette action, il va falloir indiquer les quantités effectivement achetées. En effet, les quantités demandées ne sont pas forcément celles achetées, c’est donc les quantités effectives qu’il faut ajouter au stock. Une fois ce formulaire validé, la liste de couses passera de l’état « à faire » à l’état « faite ».
\par Au retour des courses, il faut ranger les produits achetés dans la réserve. À ce moment-là, il faut aussi mettre à
jour le stock. Une opération « Mettre à jour le stock » est disponible pour chaque liste de courses du tableau « À
faire ».
\par En effectuant cette action, il va falloir indiquer les quantités effectivement achetées. En effet, les quantités
demandées ne sont pas forcément celles achetées, c’est donc les quantités effectives qu’il faut ajouter au stock. Une
fois ce formulaire validé, la liste de couses passera de l’état « à faire » à l’état « faite ».
\subsection{Prise d’éléments dans le stock}
\par La réserve étant accessible aux barmen afin qu’ils puissent réapprovisionner les réfrigérateurs à tout moment, l’interface permettant de prendre des éléments dans le stock a été ajoutée dans les onglets de l’interface des ventes (là où le barman inscrit le code du compte du client qui souhaite commander quelque chose). Ainsi, en revenant de la réserve, le barman doit indiquer le nombre de chaque produit qu’il a rapporté.
\par Dans un souci de simplicité pour le gérant du lieu de vie, ce formulaire de prise des éléments dans le stock est aussi accessible depuis son interface de gestion.
\par La réserve étant accessible aux barmen afin qu’ils puissent réapprovisionner les réfrigérateurs à tout moment,
l’interface permettant de prendre des éléments dans le stock a été ajoutée dans les onglets de l’interface des ventes
(là où le barman inscrit le code du compte du client qui souhaite commander quelque chose). Ainsi, en revenant de la
réserve, le barman doit indiquer le nombre de chaque produit qu’il a rapporté.
\par Dans un souci de simplicité pour le gérant du lieu de vie, ce formulaire de prise des éléments dans le stock est
aussi accessible depuis son interface de gestion.
\section{Améliorations à apporter}
\label{sec:amelioration_a_apporter}
\begin{itemize}
\item Il n’est pas encore possible de modifier les quantités demandées pour un ou plusieurs des produits d’une liste de course. Il faudrait rendre cela possible car actuellement, il faut supprimer la liste de courses et la refaire en changeant les quantités souhaitées.
\item Il faudrait améliorer la manière dont on ajoute les éléments non définis en tant que StockItem dans la liste de course. Un objet ShoppingListItem avec une référence « Null » vers la classe StockItem pourrait être créé à la place de compléter le champ de commentaires.
\item Dans les améliorations sur le long terme, il faudrait que la décrémentation des quantités de chaque élément dans le stock soit automatique. En repensant une partie de l’architecture de l’application, on pourrait faire en sorte que chaque vente faite au comptoir face diminuer les quantités restantes (cela remplacerait le formulaire de « Prise d’éléments dans le stock », mais cela ne serait pas applicable à tous les produits mis en vente. Par exemple, pour les cacahuètes que nous vendons au bol et non par paquet)
\item Avec le système de notifications qui a été mis en place sur le site, on pourrait faire en sorte que le ou les responsables des lieux de vie reçoivent une notification lorsque la liste de courses contient plus de 5 éléments
\item Il n’est pas encore possible de modifier les quantités demandées pour un ou plusieurs des produits d’une liste
de course. Il faudrait rendre cela possible car actuellement, il faut supprimer la liste de courses et la
refaire en changeant les quantités souhaitées.
\item Il faudrait améliorer la manière dont on ajoute les éléments non définis en tant que StockItem dans la liste
de course. Un objet ShoppingListItem avec une référence « Null » vers la classe StockItem pourrait être créé à
la place de compléter le champ de commentaires.
\item Dans les améliorations sur le long terme, il faudrait que la décrémentation des quantités de chaque élément
dans le stock soit automatique. En repensant une partie de l’architecture de l’application, on pourrait faire en
sorte que chaque vente faite au comptoir face diminuer les quantités restantes (cela remplacerait le formulaire
de « Prise d’éléments dans le stock », mais cela ne serait pas applicable à tous les produits mis en vente. Par
exemple, pour les cacahuètes que nous vendons au bol et non par paquet)
\item Avec le système de notifications qui a été mis en place sur le site, on pourrait faire en sorte que le ou les
responsables des lieux de vie reçoivent une notification lorsque la liste de courses contient plus de 5 éléments
\end{itemize}
......@@ -278,9 +348,27 @@ pour autant à toucher au code.
\subsection{Génération de plannings}
\label{sub:generation_de_plannings}
\par Il y a là beaucoup de cas à prendre en compte. Lorsque que quelqu'un veut réserver directement un "Lavage +
Séchage", un simple "Lavage", ou un simple "Séchage", il faut toujours vérifier la disponibilité des créneaux en
fonction du nombre de machine de chaque type présent dans la laverie en question \footnote{Belfort ou Sevenans, en
l'occurrence}, et cela représente vite un grand nombre de combinaisons à vérifier.
\par De plus, la réservation doit rester ergonomique, et s'afficher dans un format le plus lisible possible pour un
humain. Là dessus, un tableau est le plus approprié, avec chaque jour représenté par une colonne, et chaque créneau par
une ligne.\\
Mais cela ne représente malheureusement pas la temporalité, et la génération du tableau devient alors plutôt compliquée,
et d'autant plus si l'on veut qu'il soit sémantiquement correct en HTML.
\subsection{Gestion des timezones}
\label{sub:gestion_des_timezones}
\par La gestion et le stockage des crénaux implique l'utilisation de champs de type \verb#DateTime#. \textbf{Django} les
gère très bien, particulièrement au niveau des \emph{timezones}, où ce dernier n'hésite pas à lancer un warning lorsque
l'objet \emph{date} passé ne contient pas d'information de fuseau horaire.
\par Mais avec notre décalage d'une heure par rapport au temps UTC, tous les horaires se retrouvent décalés, et gérer
cela convenablement sans sortir d'avertissement a été plutôt compliqué. La solution a été de forcer un peu partout la
\emph{timezone} à UTC, afin de ne pas créer de décalage, mais en conservant tout de même l'information de fuseau
horaire, et sans tout casser lors du passage à l'heure d'hiver.
\chapter{La communication}
......@@ -302,9 +390,37 @@ pour autant à toucher au code.
\subsection{Envoie de mails}
\label{sub:envoie_de_mails}
\par Un outil de \emph{newsletter} nécessite l'envoie de mail. C'est là quelque chose de relativement compliqué à
tester, d'autant plus lorsqu'il s'agit de mailing-list contenant l'intégralité des étudiants de l'UTBM.
\par \textbf{Django} fournit toutefois un outil très pratique: il contient plusieurs \emph{backend} d'emails, dont entre
autre un \emph{SMTP}, et un \emph{console}. Le \emph{SMTP} est bien évidemment utilisé en production pour envoyer
effectivement les mails, mais il est compliqué à utiliser en développement, car il suppose que le développeur a à sa
disposition un serveur de ce type. On utilise alors le backend \emph{console}, qui affiche simplement dans le thread
d'execution de \textbf{Django} une version texte de l'email envoyé, avec d'une part les entêtes, d'autre part le corps
de message.
\par Mais autant pour tester l'envoie d'un mail unique à une adresse unique, cela fonctionne parfaitement bien, ce n'est
toutefois pas suffisant pour tester un envoie massif à plusieurs mailings, avec en plus encore d'autres adresses en
\emph{Bcc} pour les gens ne faisant pas partie des mailings "classiques", mais souhaitant quand même recevoir le
\textbf{Weekmail}.
\subsection{Amélioration de l'outil de recherche}
\label{sub:amelioration_de_l_outil_de_recherche}
\par Pour la gestion de l'AE, il est nécessaire de pouvoir rechercher et trouver efficacement n'importe quel membre, en
tapant au choix son nom, prénom, ou surnom, voire une combinaison de ces trois champs.
\par Mais une fonction de recherche aussi complexe est très difficile a mettre en place efficacement sans un traitement
préalable, d'où la nécessité d'indexer les entrées à chercher. Un indexeur étant très complexe, mais également très
courant, il n'a pas été difficile de trouver une application déjà existante fournissant ces fonctionnalités.
\par Le choix s'est porté sur \textbf{Haystack}, en l'utilisant avec l'indexeur \textbf{Whoosh}, plutôt efficace pour
des bases raisonnables, et surtout écrit en pure \textbf{Python}, donc ne nécessitant pas d'installation compliqué en
parallèle du site.
\par Le résultat est plutôt satisfaisant, mais il faudrait encore améliorer les résultats en utilisant les fonctions de
\emph{boost} pour certains champs. De plus, une certaine lenteur se fait encore sentir avec certaines recherches trop
communes ou générales.
\chapter{Conclusions personnelles}
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment