MONA

Rapport IFT3150

Natacha Rivière

Plan de développement

La première réunion a eu lieu le 25 janvier et le projet se terminera en avril 2023.

Rapports d'avancement

Semaine 1

Cette semaine, nous avons eu une première réunion avec Lena. J'ai pu rencontrer les membres de l'équipe et Lena nous a présenté l'application et les objectifs. Elle nous a recommendé de nous intéresser aux travaux des étudiants qui ont travaillé par le passé sur nos parties, le serveur pour ma part.

Tout d'abbord, j'ai contacté le technicien du DIRO Raouf Bencheraiet pour obtenir l'accès au serveur de MONA. J'ai eu un peu de mal à me connecter car je ne savais pas qu'il fallait une session au DIRO, qu'on peut créer sur le site de soutien technique du diro.

J'ai commencé à créer cette page web pour les comptes rendus hebdomadaires. Je me suis aussi intéressée à Laravel et Vue.js.

J'ai voulu utiliser l'article de blog de Mathieu, que mentionnaient les anciens étudiants, mais malheuresement le lien ne fonctionnait plus, donc Lena a conatcté Mathieu pour que je puisse y avoir malgré tout accès.

Semaine 2

En réunion cette semaine, Lena et Simon m'ont expliqué que mon rôle pour le début de la session serait de finaliser la dockerisation du serveur pour faciliter la mise à jour des modifications entre le github et le serveur picasso.

Avant cela, mon premier rôle est de modifier le site web de MONA IFT3150 pour y ajouter les pages web des étudiants de l'équipe. De plus, je dois contacter les anciens élèves, à commencer par Isabel pour récupérer leurs sites web et les héberger sur le serveur pour assurer la pérénnité des liens.

Cette semaine, j'ai commencé par installer le serveur MONA en local sur ma machine. J'ai pu utiliser le blog de Mathieu que j'ai trouvé dans les archives du web. En suivant le blog, j'ai eu quelques problèmes, comme me l'avait signalé Simon, les versions de php et de mysql que j'avais n'étaient pas les bonnes pour faire fonctionner le serveur, heuresement il m'a suffit d'installer les versions mentionnées dans le composer.json pour régler ce problème.

Ensuite j'ai été bloquée lors de la création de la database car la récupération de données sur un site n'acceptait plus la version de http utilisée et la requête était refusée. J'ai donc dû remplacer cette requête par une requête curl. Je me suis ensuite retrouvée bloquée plus loin dans cette même opération : la table ne pouvait se créer car une colonne n'était pas trouvée par mysql. J'ai demandé de l'aide à Simon pour régler ce problème car je ne suis pas parvenue à en trouver la source. Finalement, j'ai parcouru les migrations et j'en ai trouvé la source, une bête incohérence dans des noms. Il m'a suffit de modifier un peu une migration pour régler ce problème.

J'ai donc une copie du serveur mona sur mon pc. J'ai importé quelques données pour pouvoir faire des tests.

J'ai voulu faire ce que m'a demandé Lena et mettre les sites des anciens élèves sur le site, j'ai trouvé les fichiers d'Isabel sur github mais je n'arrive pas à faire en sorte de l'afficher sur le site. Comme son site comporte plusieurs pages, ils sont dans un sous dossier du répertoire ift3150 et je ne sais pas comment dire au serveur de l'afficher.

J'ai voulu modifier l'interface admin pour faire en sorte que la barre de recherche attende la pression de la touche entrée ou qu'on appuie sur submit avant de chercher dans la base de données pour éviter d'avoir une recherche super longue mais j'ai eu beaucoup de mal à comprendre le fonctionnement de la page.

Semaine 3

J'ai continué à me renseigner sur le fonctionnement de Laravel, ce qui m'a permi de comprendre d'où venait mon problème pour ajouter les sites des anciens élèves, il me suffisait d'ajouter une route dans web.js. En revanche, en ajoutant une route vers les sous dossiers de ift3150, le lien vers le site de Thomas ne fonctionne plus, car il avait crée une route ift3150/bui/index, qui se fait "attraper" par ma route. Je n'ai pas encore résolu ce problème.

En réunion, nous avons parlé de la possibilité d'ajouter la possibilité de récupérer les données des utilisateurs lorsqu'ils se reconnectent depuis un nouveau téléphone. Je me suis donc interressée de plus près au fonctionnement de l'api. J'ai fait quelques tests, plus ou moins concluants, pour ajouter des routes. Je comprend assez bien comment fonctionne l'api maintenant, je continuerai mes tests la semaine prochaine et je pense que ce sera tout à fait faisable.

D'autre part, j'ai eu une nouvelle réunion avec Simon. Il m'a expliqué le concept de docker. Le but est donc en quelque sorte, de faire tourner deux machines virtuelles sur la machine host de Mona, une pour host le serveur de production et une pour le serveur de developpement. Simon m'a fait tester docker sur ma machine mais lorsque j'ai voulu déployer les dockers qu'il a fait pour Mona sur mon ordinateur, j'ai rencontré une erreur. Apparemment, c'est une erreur qu'il a déjà recontré donc il m'a dit qu'il allait mettre le github à jour pour régler ce problème avant que l'on puisse continuer.

Simon m'a envoyé un lien vers un article qu'il a utilisé pour mettre en place les dockers pour me permettre de mieux comprendre le fonctionnement.

Semaine 4

Cette semaine, j'ai continué à me pencher sur le fonctionnement actuel de l'Api pour pouvoir implémenter la fonction d'authentification permettant à un utilisateur de récupérer ses données. Il s'avère que c'est déjà possible. Lors de la connexion, le serveur renvoie un token qui permet à l'utilisateur de faire une requête pour récupérer ses photos. Le serveur renvoie un lien vers les photos de l'utilisateur.

En revanche, Yan a découvert que sur IOS, lorsqu'un utilisateur crée un compte, les données (nom d'utilisateur et mot de passe) qu'il entre ne sont jamais envoyées au serveur. A la place, l'application génère un UUID et une fausse adresse email et envoie une requête d'inscription avec le mot de passe : "password". J'ai donc consulté la base de données de MONA et ai constaté que 1772 personnes étaient concernées par ce problème. Je me suis donc attelée à la construction de deux routes, une pour modifier son mot de passe, l'autre pour modifier son nom d'utilisateur, et une dernière pour changer son mail.

Semaine 5

J'ai eu une urgence personnelle la semaine dernière et ai dû rentrer en France, je n'ai donc pas pu faire beaucoup de progrès. J'ai donc continué cette semaine à ajouter les routes pour mettre à jour le mot de passe, le mail et le nom d'utilisateur. Les routes ne sont pas encore sur le serveur, j'attend une réponse de Simon pour qu'il m'explique la manière simple de push au serveur sans avoir à passer par scp systématiquement mais elles sont sur le github.

Par ailleurs, je me suis interressée à mettre à jour la documentation. Elle est déjà très complète et documente bien tous les endpoints de l'api,j'y ai donc ajouté ceux que j'ai implémenté. A côté de cela, j'ai créé une représentation complète de la base de données sur dbdiagram.io dont j'ai ajouté le lien dans la documentation. Elle est exaustive, ce qui la rend peu lisible.

Enfin, Lena m'a demandé de créer un schéma récapitulatif des échanges de données entre les utilisateurs et le serveur, que j'ai apporté à la réunion et je vais mettre dans la documentation.

Semaine 6

Cette semaine, j'ai commencé par régler le problème de sync avec le serveur grâce à Simon. Comme j'avais copié les fichiers par scp, la synchronisation devait être faite manuellement. Maintenant je peux utiliser les hooks pour mettre mes modifications en ligne. Ensuite, Lena m'a demandé de me pencher sur le fichier de description des badges puis sur l'interface admin pour faciliter son utilisation pour la recherche.

J'ai donc complété les descriptions de badges, il fallait trouver une alternative au mot oeuvre comme c'est un type de donnée de l'application, on ne peut pas utiliser ce mot pour désigner tout, Yann a proposé le mot découverte, mais "collectionner une découverte" sonne bizarrement. J'ai aussi ajouté le bagde Laval. Ensuite j'ai exploré plus en profondeur le code de l'interface admin, comme je m'étais plutôt penché sur l'api. J'ai noté plusieurs choses que je voudrais modifier. Déjà, les pages des heritage et places est bien moins complète que celle des artworks, qui est plus ancien, et toutes les routes accessibles à artworks ne le sont pas pour les autres. Ensuite, j'ai remarqué que la dernière section des pages des artworks est un tableau sans titre; en creusant dans le code j'ai compris que c'est un tableau des oeuvres les plus proches. Je voudrais ajouter un titre et rendre les titres des oeuvres cliquables pour aller sur les pages de ces oeuvres là. J'ai voulu rajouter un titre mais j'ai découvert un problème que je n'ai pas encore su résoudre. Je n'arrive pas à faire ensorte que les modifications que je fais s'affichent dans l'interface. J'ai vu que Yuning Sun avait eu le même problème il y a deux ans, mais elle n'a pas expliqué clairement la solution.

Un autre objectif sur la page admin est de faire en sorte qu'on puisse trier les oeuvres par nombre de photo ou par nombre de commentaire, ce qui est étonnant c'est que c'est la même mécanique que pour le tri par id mais ça ne fonctionne pas. Mais avant de régler les problèmes de l'interface il faut que je trouve comment faire apparaître mes changements.

Semaine 7

J'ai continué mon travail sur l'interface admin. Simon m'a expliqué que pour mettre à jour le site après avoir fait des changements sur les fichiers vue il faut run la commande npm run dev. Ceci fonctionnant, j'ai commencé par faire en sorte que la barre de recherche dans la liste des oeuvres soit plus rapide. Désormais elle ne cherche pas les résultats pour chaque caractère tapé mais elle est lazy, c'est à dire qu'elle ne fait sa recherche qu'une fois que la barre de recherche a perdu le focus (en cliquant ailleurs, en tapant entrée).

Ensuite, je me suis assurée que les places et heritage aient les mêmes informations que artworks sur la page détaillée (artworks/6 par exemple). Il n'y avait ni la carte, ni les autres découvertes proches. J'ai aussi ajouté un titre à cette section, qui n'était pas claire. Enfin, j'ai retiré le bouton Edit des oeuvres proches et je l'ai remplacé par More qui est à mes yeux plus logique.

J'ai donc voulu mettre en ligne tous ces changements mais je me suis retrouvée face au même problème que précédemment, c'est à dire que les changements appliqués aux fichiers vue ne se reflètent pas dans le site même après avoir exécuté la commande npm run picasso sur le serveur. J'ai testé la commande npm run dev|prod et de même, aucun résultat.

J'ai réglé le problème. Comme je n'ai pas pensé à rechager la page sans le cache à chaque opération que j'ai essayé je ne suis pas sûre de la commande qui a fonctionnée mais je crois que c'est npm install. J'ai pu ensuite run npm run picasso et les changements se sont appliqués.

Update, je pense qu'il suffit de clear le cache du serveur avec php artisan cache:clear après avoir compilé pour appliquer les modifications.

J'ai fini de réparer le code qui trie les oeuvres par nombre de photos. Mais pour une raison que j'ignore, il y a des oeuvres dont l'attribut photos n'est pas un tableau (Array) mais un Objet, on ne peut donc pas juste donner la taille du tableau pour connaitre le nombre, il faut d'abbord vérifier le type, ce que je trouve bizarre.

En tous les cas, on peut désormais trier par nombre de photos et c'est cool. (Fun fact, la personne qui a collectionné le plus de heritages c'est Gaspard, on le reconnait à ses screens de The Witcher haha, mais donc malheuresement ce chiffre est faussé par ses tests)

J'ai aussi réglé le problème des photos qui ne s'affichaient pas dans le tableau dans les pages "show"/détaillées des oeuvres, un simple problème d'url incorrecte. En revanche je vais retirer le tableau des oeuvres les plus proches car cela rend le chargement des pages des oeuvres excessivement lent et par conséquent le navigateur se retrouve avec une erreur HTTP 500 Server Error.

Semaine 8

Cette semaine j'ai commencé par implémenter une page sur l'interface admin qui indice les chiffres importants de l'application comme le compte de chaque type de découverte, et le nombre de photos de chaque type. Cette page est accessible dans la barre de menu admin à l'adresse admin/chiffresCles. Cette page n'est pas belle mais je ne suis pas très douée en graphisme, je ne sais pas trop comment la présenter.

Ensuite j'ai refait une mise à jour du fichier cvs des badges en suivant les instructions de Lena. Il y a donc une description pour les badges de Laval, patrimoine, lieux et oeuvres. A côté de cela, Gaspard m'a demandé de modifier la réponse serveur pour les collections des utilisateurs, pour chaque route il avait une réponse différente, ce qui l'empêchait d'utiliser un seul code pour les trois routes. J'ai donc unifié la réponse mais apparemment il a eu un problème qu'il ne m'a pas expliqué et j'ai donc retiré cette petite amélioration.

Semaine 9

Après une semaine mouvementée avec énormément de travail la semaine dernière, j'ai pu davantage avancer. Tout d'abord, j'ai essayé d'ajouter une route à l'api qui renvoie les photos car l'application n'a pas le droit d'accéder aux photos du dossier public. Malheuresement je n'arrive pas à renvoyer correctement une image. Je réussis pour un fichier texte mais les images ne renvoient qu'un fichier incompréhensible.

J'ai commencé à implémenter les tags. Je me suis aperçue que quelqu'un auparavant avait également commencé à s'y intéresser mais les seules traces que celà à laissé sont les tables de la base de données et un Model Tag. Je trouve les tables qu'il avait créées pas pratiques, elles lient les tags aux oeuvres plutôt qu'aux photos et j'ai donc commencé à travailler sur une migration pour retirer ces tables et créer la table tag_photos. Je rencontre pas mal d'erreurs quand j'essaie de run les migrations c'est assez brouillon je crois. Je dois d'abord faire fonctionner en local avant de push sur le serveur. En revanche j'ai créé des routes et un formulaire qui sera accessible depuis le tableau des photos sur la page d'une oeuvre. Je suis en train d'écrire les classes permettant de récupérer et stocker les données dans la database. Je pense parvenir à achever le plus gros d'ici la fin de la semaine prochaine.

Semaine 10

Cette semaine j'ai continué à avancer sur les tags. Désormais la page ajouter des tags fonctionne au top ! J'ai eu pas mal de difficultés à créer des instances dans la database qui contenaient les datas que j'insérais. La fonction create a réglé mes problèmes. Maintenant pour une raison que j'ignore les tags n'ont que des id impairs, ce qui est un comportement très bizarre. En ajoutant des vérifications (si le tag qu'on veit ajouter existe déjà, ne pas en créer un nouveau mais garder celui qui existe) le problème a disparu, étrange. En somme, tout ce qu'il me reste à faire est de faire fonctionner correctement ma migration.

Avant de m'en occuper j'ai fini le travail des routes pour les photos. Pour une raison que j'ignore, mettre une condition sur l'ajout de headers "il faut que la fonction headers existe pour l'utiliser" dans le fichiers cors cassait l'identification de l'api. J'ai essayé de faire une modif, pour traiter spécialement le cas des fichiers BinaryFile. Mais il semble que l'identification entre dans cette catégorie. Comme cette identification est faite directement par Laravel, je n'ai pas insisté. J'ai trouvé (sur conseil de Gapsard) une autre approche. Au lieu de renvoyer le fichier en tant que tel, j'envoie la transcription binaire. Il faut donc que l'application reconvertisse en image derrière. De plus, vu que le type de l'image change selon l'image (PNG, JPG etc) les développeurs application doivent se souvenir du nom du fichier qui leur a été fourni par la route user/artwork pour que le système puisse lire correctement le fichier. La route demande deux arguments en query : discvorey_id et type. Ce dernier est une string parmi ['artwork', 'place', 'heritage']. Ainsi, une seule route pour les trois types de découvertes. J'ai essayé d'éviter de créer des triplets de route à chaque fois.

A côté de ça, ça m'énervait que le site de manping n'aie pas de logo, son tag img pointait vers du vide depuis que je l'ai ajouté au serveur, donc j'ai juste corrigé ça. J'ai aussi mis à jour le logo utilisé sur le site pour qu'il matche avec la couleur jaune oficielle : FADA00.

Finalement, je me sus occupée de corriger ma migration, si tout se passe bien, je vais pouvoir la run sans rien casser. J'avais des problèmes de foreign key liés à des problèmes de type inconsistent. Mais maintenant c'est ok. J'ai découvert la commande php artisan migrate --pretend qui t'indique les commandes sql qu'il s'apprête à exécuter, sans le faire, c'est une bonne sécurité pour s'assurer que je ne casse rien.

La dernière chose qu'il me reste à faire cette semaine est de checker le fichier des badges, Yan avait des questions. Je ne suis pas sûre de la cohérence générale. Ensuite il faudra que j'ajoute des chiffres à la page chiffres clés. (Nombre max de collectionnés, nombre d'oeuvres collectionnées)

Il faut que je gère sur quelle page les liens submit mènent, je ne l'ai pas géré c'est le bazar.

Eventuellement ce serait une bonne idée de supprimer les nombreuses images de test pour avoir des chiffres accurate.

Semaine 11

Cette semaine, je me suis occupée de créer un nouveau type de tags, ceux sur les oeuvres. Je me suis rendu compte en testant sur le serveur que les tags que j'ai mis ne fonctionnent pas, la page renvoie une erreur 404 not found. Je pense que ça vient peut-être des routes put car la seule autre ne fonctionne pas non plus. Je n'ai pas encore trouvé la solution.

Semaine 12

J'ai cherché longtemps la source de mon problème sur le serveur, j'ai fini par trouver, j'ai oublié d'utiliser la fonction url() qui met la bonne url avant le path que je lui fournit. C'était vraiment idiot mais comme l'url n'était pas la bonne, ça ne pouvait pas marcher.

Les tags sont opérationnels, la page addTag renvoie toujours dans les choux quand on fait submit mais au moins elle faut ce qu'on lui demande.

On a fait une séance de tests utilisateurs à la dernière réunion et après être allée voir les photos sur l'interface admin, on a constaté que seules certaines photos prises sur Android sont parties. J'ai fait pas mal de tests et il s'avère que la limite de taille par défaut est de 2Mo. J'ai donc demandé à Raouf Bencheraiet pour augmenter cette limite car c'est bloquant pour Gaspard.