Pour ce quinzième et dernier sprint, nous devions terminer, polir, affiner, régler, en un mot peaufiner l’application ezVIS.

Tâches

• 19 tâches prévues
• 17 tâches terminées
• plus de 43 points de complexité prévus
• 30 points de complexité effectués

D’une manière générale, nous nous sommes concentrés sur la stabilité de l’application, et donc sur la réduction de la dette technique.

Nous avons aussi rencontré des problèmes sur ezMaster, qui ne pouvaient apparaître qu’après suffisamment d’utilisation, et résolu un bug dont la présence était aléatoire.

Dette technique

La dette technique est la distance à parcourir, en termes de développement, pour parvenir au programme le plus cohérent et le plus à facile maintenir.

Les actions suivantes ont réduit cette dette.

Correction de connexionURI en connectionURI

Le programme et ses options étant intégralement en anglais, il nous semblait incohérent de laisser une option avec une orthographe française: connexionURI.

GitHub : #79

Préparer ezvis à une évolution de castor-core

Le cœur d’ezVIS est un module nommé castor-core dont nous savons qu’il va évoluer (notamment les URL utilisés par ezVIS). Les routes (ou URL) fournies par castor-core version 2 seront encore disponibles dans sa version 3, mais préfixées par /-/v2.
Nous avons donc changé tous les appels à ces URL dans ezVIS.

GitHub : #81

Figer les dépendances ou pas?

Pour éviter des surprises lors des futures installations d’ezVIS, au cas où un des modules dont il dépend ne respecterait pas le semantic versioning, nous avons pensé qu’il serait utile de figer les numéros de version de ces dépendances.

Il existe justement une commande du gestionnaire de modules de node qui le permet: npm shrinkwrap.
Malheureusement, celle-ci ne distingue pas encore les modules optionnels des modules obligatoires, et il se trouve qu’un module optionnel n’est pas utile ailleurs que sur Mac, mais que de plus il ne s’y installe pas, cassant ainsi l’installation d’ezvis dès qu’on utilise shrinkwrap (le rendant ainsi obligatoire).
La feuille de route de npm laisse à penser que d’ici un an, ce problème n’existera plus. D’ici là, nous compterons sur la gestion sémantique de version des modules. S’ils la pratiquaient tous, moins de problèmes seraient à craindre.

GitHub : #82 #85

Interface

Icones enlevées

Plusieurs icones étaient présentes dans l’entête d’ezVIS: celle des alertes (qui avertissait quand une synchronisation avait eu lieu, mais nous nous sommes aperçus que personne ne s’en servait), et celle de l’utilisateur (qui n’a jamais été fonctionnelle).

Nous avons donc supprimé ces icones de la page.

GitHub : #69

Couleur des graphes superposés

Jusqu’à présent, le graphe superposé avait une couleur fixe : le jaune.

Si cette couleur convient la plupart du temps, nous avons souhaité donner le choix au gestionnaire en ajoutant l’option color à la partie overlay de la configuration :

1
2
3
4
5

"overlay": {
  "label": "Taux de citation normalisé",
  "flying": ["normalizeCitationRatio"],
  "color": "red"
},

GitHub : #73

Corriger l’authentification derrière un reverse proxy

ezVIS peut être configuré pour n’autoriser l’accès qu’à un utilisateur particulier.
Dans notre établissement, les instances d’ezVIS sont derrière un reverse proxy (ou proxy inverse) dont le comportement n’a pas été cohérent: l’adresse IP du visiteur était soit l’adresse de ce proxy (comportement attendu), soit une adresse locale (127.0.0.1), autorisant alors l’accès à l’instance.
Nous avons donc corrigé ezVIS pour qu’il tienne compte de l’entête HTTP x-forwarded-for qui, elle, contient bien l’adresse IP du visiteur (pas celle du proxy).

GitHub : cd94d07

Installation automatique avec SCCM sous Windows

Nous voulions pouvoir installer automatiquement, via le logiciel SCCM, ezVIS sur plusieurs postes Windows à la fois, dans les services de notre établissement.
Malheureusement, SCCM prenant l’identité de l’administrateur de la machine pour installer, il n’a pas de répertoire utilisateur. Ce répertoire utilisateur étant indispensable à l’installeur Windows de node pour fonctionner, nous avons dû renoncer à ce projet.

Malgré tout, l’installation manuelle de node est très simple, nous avons donc opté pour un compromis en automatisant uniquement l’installation de MongoDB, ce qui simplifie tout de même la procédure d’installation à l’INIST.

ezMaster

Remplacement de SlickGrid par un tableau HTML

En dépassant 13 instances dans ezMaster, nous avons rencontré une limite: l’ascenseur disparait au-delà de 13 instances, empêchant toute action sur les dernières (configuration, ajout de données, suppression, …) :

La technologie utilisée, SlickGrid, est complexe et inutile pour le nombre d’instances que nous gérons: nous l’avons remplacée par un simple tableau HTML sans pagination, ni filtre, ni tri.

GitHub : ezmaster#2

Remplacer le _ par un - dans l’URL publique

Jusqu’à présent, le nom technique d’une instance est composé du nom du projet, de l’étude, et optionnellement d’une version, le tout séparé par des soulignés.
Dorénavant, et pour mieux satisfaire les normes sur les URL, ces séparateurs seront des tirets.

GitHub : #80

Profitez!

Pour profiter des améliorations présentées:

1

$ npm install --production -g ezvis

Introduction

Pour créer un rapport web avec ezVIS, il faut configurer l’application. Il y a 3 volets:

1. connexion avec la base de données
2. intégration des données
3. ajout de graphiques

Ils sont tous gérables dans le fichier de configuration du rapport, qui est au format JSON (JavaScript Object Notation). Son extension est .jsonet son préfixe est obligatoirement le même que le nom du répertoire dans lequel se trouvent les fichiers de données.
Nous prendrons l’exemple d’un fichier data.json placé au même niveau que le répertoire data, qui contient un fichier au format CSV dont nous reparlerons plus tard.

Connexion avec la base de données

Le système de gestion de base de données utilisé par ezVIS est mongoDB, et une connexion par défaut est utilisée, qui permet de retrouver les données liées au rapport dans la database appelée castor.
Si vous voulez changer cet emplacement, modifiez la clé connexionURIdu fichier data.json (valeur par défaut: mongodb://localhost:27017/castor/).

À l’intérieur de castor, mongo range ses données dans des collections. Sans indication supplémentaire, ezVIS nomme la collection avec une clé de hachage calculée à partir du chemin du répertoire data. Cela donne un nom illisible pour un humain, mais quasi-unique en fonction du chemin.
Si vous avez l’intention de manipuler les données dans mongoDB (par exemple, simplement pour réinitialiser les données, avec castor-clean), il est prudent de renseigner la clé collectionName, dans notre cas avec la valeur "data"par exemple:

1

"collectionName": "data",

Tant que vous y êtes, il est prudent de renseigner aussi les clés titleet description, pour vous y retrouver quand vous relirez ce fichier dans quelques mois…

1
2
3

"title": "Rapport d'exemple de configuration",
"description": "D'après l'article \"Configuration d'ezVIS / minimum\"",
"collectionName": "data",

title sera utilisé pour le titre du rapport (la fenêtre du navigateur) et description sera beaucoup plus discrètement placée dans les métadonnées HTML du rapport (visible surtout des moteurs de recherche).

À condition d’avoir déjà installé ezvis, vous pouvez d’ores et déjà le lancer avec:

1

ezvis data

Intégration des données

Après avoir lancé ezVIS, un rapport vide devrait être consultable à l’URL http://localhost:3000/ (3000 étant le port par défaut, on peut le changer via la clé port).

Le menu gauche doit donner accès au dashboard et aux documents.

Seul un message signalant qu’aucune configuration n’existe encore apparaît sur ces deux pages.

Nous allons commencer par configurer simplement la liste des documents. Elle se présente sous la forme d’une table affichant, dans l’ordre où ils sont déclarés dans le fichier data.json, tous les champs déclarés visibles.

Prenons un exemple simple, un fichier data.csv qui sera placé dans le répertoire data:

1

year,person
1912,Alan Turing
1927,Marvin Minsky

C’est un fichier CSV (Comma Separated Values) qui aurait pu être exporté d’un tableur, comme Excel ou LibreOffice.
Pour que ces données soient affichées dans la page http://localhost:3000/documents.html, il faut que nous déclarions les champs yearet person (qui sont automatiquement placés dans une clé content.json de chaque document dans la base, au démarrage d’ezVIS).
Le premier document sera placé dans la base sous forme d’un document JSON, et la partie qui nous intéresse aura cette forme:

1
2
3
4
5
6
7
8

{
  "content": {
    "json": {
      "year": "1912",
      "person": "Marvin Minsky"
    }
  }
}

Pour déclarer les champs, nous utiliserons la clé documentFields (qui au passage créera une copie du contenu des champs mais directement à la racine du document):

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{
  "documentFields": {
    "$year": {
	  "get": "content.json.year",
	  "visible": true,
	  "label": "Année"
    },
    "$person": {
      "get": "content.json.person",
      "visible": true,
      "label": "Nom"
    }
  }
}

Cette déclaration modifiera le document précédent pour donner ceci:

1
2
3
4
5
6
7
8
9
10

{
  "content": {
    "json": {
      "year": "1912",
      "person": "Marvin Minsky"
    }
  },
  "year": "1912",
  "person": "Marvin Minsky"
}

Cela peut paraître inutile pour l’instant, mais l’intérêt de cette redondance deviendra évident avec la manipulation de champs multivalués, par exemple.

Le fait d’avoir déclaré une clé visible avec une valeur true implique que le champ sera visible dans la table des documents.

La partie label de la déclaration donne le nom la colonne correspondante dans la table des documents.

Ajout de graphique

Pour ajouter un graphique, il suffit de sélectionner un type parmi:

1. histogramme histogram
2. barres horizontales horizontalbars
3. camembert pie
4. carte géographique map
5. réseau network

et d’y associer un champ (calculé ou non).

Le plus simple est un histogramme.

Tous les graphiques sont inclus dans le dashboard (tableau de bord), c’est-à-dire la page d’accueil d’ezVIS.