Différences

Ci-dessous, les différences entre deux révisions de la page.

--- boardz:journal17022020 [2020/02/19 08:34] – [Multitenant] florence
+++ boardz:journal17022020 [2025/12/10 16:16] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
-| {{ :avignon-universite.jpg?nolink|}} | {{ :blocks:logo-apl.png?nolink&220|}} |
 | {{ :avignon-universite.jpg?nolink|}} | {{ :blocks:logo-apl.png?nolink&220|}} |
@@ Ligne 11: / Ligne 8: @@
 **Bienvenue dans le volume de documentation de conception de BoardZ Version 2.**
-====Multitenant====
+====Travaux engagés sur les séries temporelles===
-====Configuration====
-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.
-====Architecture en "trois tiers" ====
-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 :
-  - Acquisition (ou Extraction)
-  - Transformation
-  - 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.
-====Ajout de fonctions de mesure de performance====
-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 :
-  - La taille max du "lot de logs" pour une requete.
-  - 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.
-====Poursuite du travail sur les outillages de mesure (et indicateurs)====
+  * Sur la problématique des séries temporelles (données historisées) et après une solidification de la mesure du cube, on voit désormais que les sous-dimensions temporelles sont bien routées vers les bonnes parties du cube, et que les étiquettes temporelles sont correctement calculées.
+  * Les travaux en cours concernent le passage entre un résultat boardz (à minima une association d'arité 1 ou une arité supérieure) vers une série de données compatible avec les axes de temps des rendus ChartJS.
+  * En effet, le cube enregistre des dimensions dissociées (year, year + month, year + month + day) là où les axes de temps attendent des instances de Date() (Javascript).
+  * Le plus simple étant de fabriquer ces dates à partir de timestamps unix Epoch, 1 Jan 1970) un adaptateur doit permettre de réagréger les composantes de date de tout type de structure de données vers une série de données timestampée (au moins une).
+  * Les Renderers de courbes, et notamment celui des courbes temporelles.
-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)
+====Travaux à engager ====
+  * Nouveaux éléments de formulaires destinés à faciliter l'usage de l'administration. Actuellement nous en avons identifié 2 :
+  -   Un elément colorpicker pour paramétrer les couleurs des renderers (étonnamment, cet élément de formulaire existe dans les "settings" d'administration de moodle, mais pas dans les éléments des formulaires moodle)
+  -    Un élément "liste multiple à choix ordonné" pour remplacer les champs de texte où on attend une liste d'id à virgule et dans un ordre précis (par exemple, lister les widgets d'un panneau, ou lister les sous-éléments d'un indicateur multiple => pour un rendu Radar)
-====Futures préoccupations=====
+====Autres réflexions et concepts en cours ====
-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.
+  * En réfléchissant sur l'adaptabilité des renderers aux changements d'arité, il apparaîtrait souhaitable de pouvoir composer un AdaptativeRenderer comme un assemblage de renderers plus simples répondant chacun à une arité ou structure de données particulière. Cela permettrait de passer de manière fluide d'un rendu scalaire (jauge) à un rendu de série (bargraph) ou matriciel, en suivant la variabilité du contexte d'entrée :
-====Difficultés identifiées ====
+Je rappelle pour cela le résultat des travaux d'architecture sur les résultats :
+Nos travaux nous ont conduit à proposer un modèle très unifié et homogène pour utiliser un même indicateur à plusieurs niveaux de profondeur (drill-down/up) par simple variabilité des paramètres passés dans l'URL d'invocation de l'indicateur.Un indicateur génériquement matriciel (arité 2) peut donc produire des résultats d'arité 2, 1, ou même 0 si on force certaines de ses dimensions, sans avoir rien à reconfigurer ni programmer dans le boardz. Aujourd'hui, l'implémentation monte jusqu'à l'arité 2 (matrice), et dans une bonne partie des opérateurs l'arité 3 (exemple : par cours / par semaine / par utilisateur). Des possibilités de monter encore en arité supportée sont tout à fait possibles. Tout est centralisé dans la seule classe boardz\data_processing\Result.class.php
-  * 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
+A très bientôt pour continuer la mise en oeuvre.
-  * 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.
+Pour toi Amelie : il va me falloir savoir à quel niveau tu peux intervenir avec nous. Actuellement je dois me battre sur deux fronts, l'architecture et la mécanique générale, et de l'autre côté la mise en place des exemples d'indicateurs, à l'aide des outils disponibles (et l'augmentation des outils si l'indicateur coince