Rapport IFT3150
Simon Janssen
Énoncé
La tâche consistera d'abord à instaurer un système de gestion de versions pour l'ensemble des fichiers du serveur du MONA.
Ensuite, il faudra modifier l'API de données existant afin d'enrichir les données du serveur avec des métadonnées comme leur lieu de provenance, des mots clés, et les dates des modifications qui leur seront portées. Il faudra aussi nettoyer les données en omettant ou en corrigeant les fausses et en fusionnant les doubles. Enfin, il faudra inclure des nouvelles sources de données desquelles l'API pourra mettre à jour les données du serveur.
De plus, il faudra créer deux nouvelles API: une pour servir les "badges" qui enrichiront l'application, et une autre pour servir l'oeuvre du jour.
À la toute fin, il faudra évaluer des moyens d'ajouter ou de modifier les données du serveur à partir de l'interface web des administrateurs ou d'autres sources crédibles.
Description détaillée
Système de gestion de versions pour le serveur
La façon utilisée en ce moment pour déployer des mises à jour au serveur est simplement de copier et envoyer par protocol ssh les changements au serveur. Cette façon de faire doit être remplacé par une méthode plus robuste.
La méthode plus robuste que j'implémenterai sera d'initialiser un dépot de référence git sur le serveur (upstream branch) afin de pouvoir y charger les changements lors du déploiement avec une simple command git push. Un post-receive hook dans le dépot de référence enverra par la suite les changements dans les dossiers appropriés du serveur.
Amélioration de l'API de données
Afin d'améliorer l'API, il faudra d'abords enrichir les données avec trois types de métadonnées. Je créerai des "Synonyms", la forme que prend les metadonnées dans MariaDB, pour accomplir cette tâche.
Le premier type de ces métadonnées est la provenance des données. Pour l'instant, les provenances sont les portails de données ouvertes des villes où le MONA opère. Dans le futur, j'ajouterai d'autres sources comme des groupes d'art ou les chercheurs utilisant le MONA.
Le deuxième type de métadonnées prends la forme de mots-clés ou tags. Ceux-ci seront ajoutés par les chercheurs utilisant le MONA.
Le troisième type de métadonnées est la date de modifications des données. Les dates assureront qu'une donnée provenant de plusieurs sources soit à jour.
De plus, pour améliorer l'API il faudra corriger les mauvaises données. Il faudra analyser les données et les modifier s'il y a des erreurs. Les deux façons qui seront utilisées pour ce faire seront l'omission de données clairement fausses et la fusion de doublons. Lors de la mise à jour des données, ces deux fonctions seront appliquées. Les fonctions pourront aussi être appelées manuellement au cas où la detection automatique des erreurs ne trouve rien. Par contre, il faudra faire attention pour ne pas "corriger" une donnée correcte.
La première des deux fonctions de correction, l'omission, se fera sur les données détectées comme étant clairement fausses. Cette détection se fera avec un filtre pour les erreurs courrantes.
La deuxième des deux fonctions de correction, la fusion, se fera sur les doublons détectés. Cette détection se fera en analysant la distance entre les oeuvres ou les lieux.
Une fois que les améliorations précédentes à l'API seront faites, il faudra ajouter les nouvelles sources de données.
API des badges
En utilisant les routes et les controlleurs de Laravel, il faudra créer un nouvel API pour les badges. Ces badges auront plusieurs propriétés qui devront être accesssibles à partir de l'application mobile. Ces propriétés seront enregistrées dans une table de MariaDB et elle seront définies par les administrateurs du MONA.
API de l'oeuvre du jour
L'API de l'oeuvre du jour se fera avec les mêmes outils que l'API des badges. Par contre, là où les badges sont définies par les administrateurs du MONA, l'oeuvre du jour sera choisie au hasard. Il pourrait y avoir plusieurs oeuvre du jour. Il sera possible de modifier manuellement l'oeuvre du jour.
Modification des données depuis l'interface web admin.
J'implémenterai des méthodes qui permettront aux utilisateurs de l'interface admin de modifier les données erronnées qu'ils trouvent.
Plan de développement
Le projet commencera le 13 janvier 2021 et terminera en avril.
Il faudra d'abords établir un environnement de développement, obtenir un accès au serveur et au code, puis compléter ce site de rapport. Les compléter prendra autour d'une semaine.
Une fois l'initialisation complétée, la première tâche à accomplir est l'ajout du protocole git pour le déploiement au serveur. Ceci pourra se faire en une ou deux journées.
Rapports d'avancement
Points accomplis par semaine
Points restants par semaine
| Tâche | Complétée | Points | Date de complétion |
|---|---|---|---|
| 4 | 20-01-2021 | ||
| 2 | 20-01-2021 | ||
| 1 | 20-01-2021 | ||
| 1 | 20-01-2021 | ||
| 16 | 09-03-2021 | ||
| Installation de GIT sur la machine | 1 | 21-01-2021 | |
| Création du upstream-branch + post-receive hook | 3 | 21-01-2021 | |
| Rammener le serveur en ligne | 4 | 22-01-2021 | |
| Backup automatiques avant tous déploiements | 2 | 09-03-2021 | |
| Corriger erreur de la page admin | 6 | 14-02-2021 | |
| Parité entre développement et production | 2 | 15-02-2021 | |
| 3 | 22-02-2021 | ||
| 27 | |||
| Établir structure du badge | 1 | 01-03-2021 | |
| Création de la route et du controlleur | 4 | 03-03-2021 | |
| Création d'une nouvelle table dans la base de données | 3 | 02-03-2021 | |
| Correction à la base de données pour ajouter multilinguisme des badges. | 3 | 14-03-2021 | |
| Correction à la base de données, bogue de enums. | 4 | 17-03-2021 | |
| Correction du controlleur et de la resource des badges | 3 | 02-04-2021 | |
| Création d'une job pour populer les données | 3 | 12-04-2021 | |
| Correction des bogues dans la job | 2 | ||
| Transformer la structure de l'objet JSON des badges comme la demandé les devs androide | 2 | ||
| Création d'un nouveau fichier .CSV contenant les données de badges. | 2 | 20-04-2021 |
Semaine 1
Pour commencer, j'ai créé cette page HTML pour enregistrer le progrès que je ferai en travaillant. Je voulais éviter d'utiliser des dépendances comme jQuery ou Bootstrap, ce qui a causé quelques difficultés. Au final, il suffisait d'implémenter les éléments de la page et de passer du temps par la suite à les raffiner.
J'ai ensuite installer un environnement de développement local à l'aide de Mathieu Perron et de son excellent article de blogue qui explique étape par étape comment procéder. Là où j'ai divergé par rapport à son article est quand j'ai rajouter les commandes composer require doctrin/dbal et sudo apt install php7.2-mysql. J'ai rencontré une première erreur 404 d'une source de données non trouvée après avoir essayer de populer ma base de données locale.
Quelques jours avant que je commence sur ce projet, l'API des données ouverte de Montréal a changé. Les liens qui fonctionnaient avant pour accéder aux informations sur les oeuvres et les sites culturels ne fonctionnaient plus. J'ai envoyer mon premier push au dépot git suite à la correction d'un lien fautif qui servait à receuillir des données de localisation.
La dernière chose que j'ai accomplie cette semaine était de contacter le technicien du DIRO Raouf Bencheraiet pour qu'il me donne accès au serveur de production du MONA via le protocole SSH.
Semaine 2
Pour cette semaine, j'ai décidé de commencer par l'ajout du protocole git pour le déploiement vers le serveur. Je pensais que ça allais se faire sans trop de difficulté mais ce ne fut pas le cas. L'ajout fonctionne en créant un dépot de référence sur le serveur. Attaché à ce dépot il y a un script qui écoute pour des git push et qui copie les changements dans le dossier de production lorsqu'il en détecte. Pour en savoir plus, veuillez consulter ce document explicatif détaillé.
J'ai testé le script sur mon serveur personnel et j'ai vérifier qu'il fonctionne comme il est supposé. Les push git sont envoyés par SSH au dépot de référence. J'avais un doute par rapport au fonctionnement des push si la configuration SSH du diro était utilisée. J'avais l'intention de copier les fichiers dans un dossier test pour le vérifier, mais lorsque j'avais modifié le script auparavant la destination des fichiers à été mise à l'emplacement du dossier de production. Suite au git push, l'état du projet comme il est sur github a écrasé celui qui était sur le serveur.
Ceci a fait planter le serveur. L'api fonctionnait toujours ainsi que Apache qui continuait à essayer de déservir les requêtes. Mathieu Perron a investigué avec moi le serveur pour diagnostiquer le.s problème.s: Sur la machine, il n'y avait pas une version de node qui était installée. Il semblait aussi y avoir des problèmes quant aux permissions des fichiers. Raouf Bencheraiet nous a grandement aider pour la réparation de ces problèmes en installant node et en modifiant la configuration de Apache pour qu'il déserve les document php avec les bonnes permissions. Le serveur Apache utilise maintenant FPM pour les fichiers php.
Après tout ça, le serveur fonctionnait comme avant sauf quant à l'interface administrative.
Semaine 3
Afin de résoudre l'erreur de la page admin du serveur non-fonctinnelle, j'ai d'abord vérifié qu'il ne s'agissait pas d'un autre problème de permissions sur le serveur. Raouf m'a confirmé que ce n'est certainement pas le cas. Dans les logs de laravel, il y avait une erreur de variable non définie pour la page admin. Pourtant, le fichier existe et, de plus, est accessible sur la version locale de développement du projet. J'ai vérifié si l'erreur était causé par un problème avec le système d'authentification, et ce n'était pas le cas, tout fonctionnait quant à ça. Sur les forums de laravel, on dit que l'erreur pourrait être dûe à un token non valide. J'ai vérifié si c'était le cas en faisant des appels manuels au serveur. Le token d'authentification a bien été reçu et fonctionnait. J'ai ensuite vérifier les versions de laravel et composer. Les versions de laravel étaient les mêmes sur le serveur et sur la version locale. Composer, quant à lui, n'était pas installé sur le serveur. J'ai contacté Raouf pour lui demander de l'installer. Au final, j'ai installer composer.phar en local dans le dossier de MONA-LAST.
Pendant ce temps, j'ai terminé l'implémentation du déploiement avec GIT. Il ne reste plus qu'à le tester.
Semaine 4
J'ai découvert que la version de composer sur le serveur était plus vieille que celle que nous utilisions en local, je l'ai donc mise à jour. Il faut noter que la version de composer doit être la plus récente de composer 1 et non de composer en général. L'erreur à été résolue après que j'ai supprimer le cache de laravel et de composer.
J'ai ensuite copié les nouveaux fichiers du serveur sur la version locale afin de créer une parité entre les versions.
J'ai aussi porté quelques corrections à la page d'acceuil du projet.
Semaine 5
Yuning Sun et moi avons mis à jour les jobs qui récupèrent les données des sources afin qu'ils rajoutent au données leur provenance. Nous avons en même temps changer les noms des jobs pour qu'ils soient plus descriptifs et exacts.
Nous avons découvert qu'une de nos sources n'est plus accessible sous le même format. On l'obtenait en format JSON antérieurement et maintenant nous ne pouvons que l'avoir en CSV. Il est plus difficile de manipuler les CSV. Yuning a bien converti la job pour traiter le nouveau format.
Semaine 6
J'ai rencontré l'équipe de développement d'androide pour établir une structure pour les données de badges que nous allons utiliser. Nous avons décidé de composer les badges avec une sorte de structure de commande UNIX. Le type de badge est envoyé avec des arguments qui précisent son comportement.
Au cours de la semaine, j'ai créé une nouvelle table dans la base de données pour contenir les badges avec une migration laravel. J'ai ensuite rajouter une route et un controlleur qui permet l'accès à ces badges via l'API.
Semaine 7
Après avoir inséré quelques badges tests dans la BD, j'ai envoyé le résultat de l'appel de l'API à l'équipe de développement Androide afin qu'ils puissent continuer les badges de leur bord.
J'ai testé le déploiement au serveur avec GIT et tout semble fonctionner incluant la création d'une copie des dossiers avant la mise à jour. Ceci offrira une version backup du dossier de production auquel on pourra rollback si un changement est problématique.
Semaine 8
J'ai encore rencontré l'équipe de développement androide et ils m'ont demandé de faire quelques changements à la structure des badges. Ils m'ont aussi informé qu'il manquait la version anglaise des descriptions des badges.
J'ai ajouter une nouvelle migration à la base de données pour avoir des colonnes pour la version anglaise du nom du badge et de sa description.
Semaine 9
Le changement de la semaine passé a fait planter la base de données sur ma version locale. Il y a un bogue dans mariadb et laravel, lorsqu'on essaie de faire des modifications sur des colonnes qui contiennent des valeurs de enums. Dans notre cas, le fait que les badges peuvent prendre la valeur de publique ou privée pour sa visibilité cause problème.
Avec plusieurs migrations (une qui enlève la colonne enum, une qui fait les modifications, et une qui remet la colonne enum) j'ai contourné ce bogue de laravel et mariadb. Selon les forums, corriger ce bogue n'est pas une priorité de l'équipe de développement de laravel.
Semaine 10
Cette semaine j'ai été plutôt improductif. J'ai essayer de d'implémenter un des changements que voulait les développeurs androide: celui qui consiste à retourner seulement les badges modifiés après une certaine date. J'ai créé une nouvelle route et j'ai copié les fonctions pour les oeuvres, mais les appels à l'API des badges ne fonctionnaient plus après le changement. J'ai donc revert pour le moment.
Semaine 11
Les données de badges envoyées par l'API ne contenaient pas les nouvelles données de langue que j'ai ajoutées. J'ai donc modifier la resource de badge de laravel pour que l'objet contienne tous les données pertinentes. Puis j'ai corrigé le contrôleur pour qu'il envoit ces nouvelles données via l'API.
Semaine 12
Les examens finaux ont commencés cette semaine.
J'ai créé la job laravel qui permettera de transférer les badges d'un fichier .CSV à la base de données. J'ai commencé à parse le .CSV dérivé du google sheet que Lena m'a envoyé.
Aussi, Philippe et Théo m'ont appris que l'API des oeuvres qui renvoient seulement les oeuvres après une certaine date ne fonctionne plus. L'URL retourne tous les oeuvres malgré le fait que le code est inchangé.
Semaine 13
Encore en examens, je n'ai pas eu autant de temps pour travailler.
J'ai tout de même continué à écrire un job qui pourrait prendre les données du google sheets et de remplir la base de données de badges avec. Théo avait besoin de badges tout de suite, alors j'ai rempli dans la base de données quelques exemples manuellement.
Extraire les données du google sheet semble impossible, j'ai donc créé un tout nouveau fichier .CSV avec les données structurées de façon idéal pour que le job laravel les utilise.
Semaine 14
Cette semaine, je me suis concentré sur la préparation de mon projet final et la structure de mon rapport final. Je n'ai pas eu le temps de porter des modifications au code.
J'ai eu une rencontre avec Yuning et Théo pour discuter du rapport final. J'ai pu pratiquer ma présentation avec eux et j'ai reçu du feedback essentiel.