BoardZ Moodle Stat Project

Bienvenue dans le volume de documentation de conception de BoardZ Version 2.

Boardz est désormais fonctionnellement multi-tenant. (Hypothèse de faire fonctionner 2 instances de site totalement séparées dans un seul moteur).

Les configurations ont été reprises et corrigées pour assurer une intégration correcte de ces sites. Cela passe par :

• Le passage vers des écritures JSON plutot que XML. C'est moins verbeux, plus léger à décoder, et pemet une expresison plus simple de configurations “objet” plus complexes.
• La mise en place de deux modèles complets de configuration. Les configurations doivent permettre à terme de “charger” un boardz vide avec un certain nombre d'objets minimaux au fonctionnement d'un site. Un principe de backup/restore sera déduit de ces techniques.

Pas au sens application Web, mais bien au sens de la structure d'une “machine de calcul” se dessine de mieux en mieux, les 3 tiers de calcul étant :

1. Acquisition (ou Extraction)
2. Transformation
3. Restitution, de quoi forger une variante de l'acronyme ETL en le remplaçant pas ETR. (Extract/Tranform and Render).

Les scripts de lancement des process ont été révisés pour assurer l'indépendance de ces trois tiers au regard de l'architecture technique, de manière à avoir toutes les armes de scalabilité horizontale et verticale.

La première mesure était d'obtenir la vitesse d'intégration des logs, afin de savoir dans quelle mesure le Boardz sait “digérer” une volumétrie existante.

Les mesures ont donné : entre 250 et 360 logs / seconde, soit entre 900k et 1,3M logs par heure (en régime continu). Les tâches d'alimentation prévoient deux paramètres :

1. La taille max du “lot de logs” pour une requete.
2. Un “temps de refroidissement” de l'alimenteur,, temps d'attente entre deux salves d'alimentation. Le but est de maîtriser la “charge continue ajoutée” à un moodle en production pour aspirer les logs.

Le plugin moodle d'extraction des logs (report_etl) a du être légèrement corigé, d'ailleurs, pour éviter des pertes marginales d'échantillons entre deux requêtes successives.

Le principe de sélection par composant/action (ex : forum / created_post) est très probablement trop simpliste, dans le cas de mesures qui portent sur une sélection d'actions multiples particulières. Dans le premier modèle, on ne peut faire qu'un choix d'une action unique, ou au mieux de “outiller les actions” d'un certain composant. C'est visiblement trop réductieur, lorsqu'il faut, par exemple associer deux événements particuliers des forums (created_discussion ET created_post) pour balayer l'espace “d'intervention participative” des utilisateurs.

Le modèle est en cours d'extension, afin de pouvoir choisir des combinaisons plus “riches” de composants/actions (par expression régulière). Le besoin adresse de toutes façons l'indicateur suivant à produire sur les divers “rendus”, puisqu'il faut aller chercher des actions précises dans plusieurs composants (devoir, base de données, quiz, forums évalués etc)

Voir comment remonter les métadonnées relatives aux activations de demande d'achèvement. Certains indicateurs en parlent, il va donc falloir aménager une remontée de certaines données pour le prendre en compte.

• Ergonomique : Comment mieux contrôler et vérouiler les interfaces (formulaires) pour éviter les “erreurs de configuration”, dans un système de configuration qui reste complexe
• Testabilité : Même en ayant ajouté un autre site de nos clients, les données qu enous avons chez nous sont plutôt liées à un usage “formation continue”. Nous manquons pour l'instant de donées liées à une pratique “académique” pour valider le comportement de certains indicateurs. Par exemple, dans aucune de nos plates-formes se révèlent un usage “étudiant” significatif des forums.

Un travail sur une copie de vos données devrait permettre de “voir” mieux.

Sommaire du journal - Revenir au sommaire général