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

Voici venue la revue de sprint numéro 10, qui a pour thème principal les ressources externes.

Tâches

• 18 tâches prévues
• 10 tâches effectuées
• 22 tâches au total
• plus de 46 points de complexité prévus (avec des incertitudes)
• 36,5 points de complexité résolus (avec des tâches non prévues): dans la moyenne

madec-project.github.io

J’ai créé un page pour l’organisation madec-project sur GitHub, celle qui contient tous les programmes liés au projet MADEC. GitHub offrant l’hébergement d’un site statique, nous avions déjà opté pour Hexo pour ce blog.

Pour obtenir une URL relativement courte (en tout cas plus courte que http://madec-project.github.io/blogfr), il a fallu nommer le dépôt contenant ce site madec-project.github.io, ce qui nous autorise une URL sans le nom du dépôt: http://madec-project.github.io/

Twitter

Un compte Twitter ezvis_project a aussi été créé (en ces temps de communication autour d’ezVIS, ça peut servir).

vimadec / vpmadec / puppet

Le travail avec Patrice, Martial et Philippe porte ses fruits:

• ajout d’un script d’installation d’une app ezmaster à partir de l’URL de son .tar.gz,
• mise sous surveillance du processus ezmaster afin de le relancer automatiquement quand il s’arrête (via forever),
• création d’une machine virtuelle de production vpmadec,
• création d’un accélérateur sécurisé vers cette machine virtuelle.

ezVIS

Test sous node v0.12

En utilisant nvm, nous avons lancé et testé à la main ezVIS, et tout a marché.

Il a néanmoins fallu passer par un npm rebuild pour recompiler/récupérer les modules binaires correspondant à cette version (principalement bson et kerberos)

Affichage de la version

Pour faciliter les échanges avec les utilisateurs (il y en a eu avec une personne d’Orléans, par mél), on affiche la version d’ezVIS dans le navigateur:

mais aussi lors du lancement d’une instance ezVIS:

login/password

On peut maintenant limiter l’accès à un rapport ezVIS en utilisant la clé access, contenant un login et un mot de passe soit plain, soit sha1:

1
2
3
4

"access": {
  "login": "user",
  "sha1" : "37fa265330ad83eaa879efb1e2db6380896cf639"
}

Le mot de passe sous forme plain est simplement le mot de passe en clair.
Mais comme ce n’est pas une bonne pratique, on peut remplacer son usage par celui de sha1 qui remplace un mot de passe par son empreinte SHA-1.

Ainsi, on connaît l’empreinte du mot de passe, mais pas le mot de passe lui-même.

Pour obtenir l’empreinte SHA-1 d’un mot de passe, on peut utiliser des commandes comme shasum ou sha1sum (en n’incluant pas de passage à la ligne dans le mot de passe), ou bien des sites de génération comme SHA1 online.

Accès aux ressources externes

ezref

On peut avoir besoin de ressources externes à ezvis (parce que de simples fichiers), mais avec la possibilité de remplacer ces fichiers de référence (tables de correspondance, listes, …).

Utiliser ezref, l’application pour ezMaster qui met à disposition via le protocole http des fichiers qu’ezMaster vous permet de déposer est la solution.

Pour pouvoir stocker les ressources: ezref (serveur web statique).

flyingFields

Les flyingFields sont les cousins des documentFields et des corpusFields. Ils sont un croisement, dans le sens où ils permettent l’interopérabilité des uns et des autres.

JBJ

Pour pouvoir appliquer une table de correspondance présente dans les corpusFields, on a ajouté une action mappingVar à JBJ, qui fonctionne comme mapping, mais dont les arguments sont différents.

Exemple: externaliser la table de correspondance d’une carte géographique

Pour projeter des données sur la carte du monde, jusqu’ici, on était obligé de traduire les noms des pays en codes ISO (c’est ainsi que sont identifiés les pays sur la carte):

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

"$fields.country" : {
  "label": "Pays d'affiliation",
  "path" : "content.json.Pays",
  "parseCSV": ";",
  "foreach": {
    "mapping": {
      "Albania" : "ALB",
      "Algeria" : "DZA",

      "Zaire" : "COD",
      "Zambia" : "ZMB"
    }
  }
}

Nous avons amélioré l’opérateur mapping de JBJ pour qu’il puisse traiter directement tout un tableau:

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

"$fields.country" : {
  "label": "Pays d'affiliation",
  "path" : "content.json.Pays",
  "parseCSV": ";",
  "mapping": {
    "Albania" : "ALB",
    "Algeria" : "DZA",

    "Zaire" : "COD",
    "Zambia" : "ZMB"
  }
}

Puis, nous avons créé un opérateur similaire à mapping qui, au lieu de prendre en entrée l’objet courant et en paramètre la table de correspondance, permet de mettre en paramètre deux noms de variable: l’entrée et la table.
Il s’appelle mappingVar (ou combine).

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

{
  "set": {
    "arg": {
      "a": "Aha!",
      "b": "Baby"
    },
    "input": "a"
  },
  "mappingVar": [
    "input",
    "arg"
  ]
}

Ceci renvoie "Aha!".

Donc, grâce à ezref, on peut mettre la table de correspondance sur un serveur externe, et le charger dans un corpusFields, accessible comme une variable dans les flyingFields:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

"documentFields": {
  "$fields.country" : {
    "label": "Pays d'affiliation",
    "path" : "content.json.Pays",
    "parseCSV": ";",
    "foreach": {
      "trim": true
    }
  }
},
"corpusFields": {
  "$country2iso": {
    "$?" : "http://localhost:35000/country2iso3.json",
    "parseJSON": true
  }
},
"flyingFields": {
  "$country2": {
    "$_id": {
      "combine" : ["_id", "country2iso"]
    },
    "mask": "_id,value"
  }
}

Quand on veut avoir le nombre de valeurs distinctes de fields.country, on peut utiliser l’URL http://localhost:3000/compute.json?operator=distinct&field=fields.country :

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

{

  data: [
    {
      _id: "Albania",
      value: 2
    },
    {
      _id: "Algeria",
      value: 15
    }
  ]
}

Mais en utilisant &flying=country2 en plus, on applique le JBJ correspondant à ce champ:
http://localhost:3000/compute.json?operator=distinct&field=fields.country&flying=country2

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

{

  data: [
    {
      _id: "ALB",
      value: 2
    },
    {
      _id: "DZA",
      value: 15
    }
  ]
}