Les adresses sont des chaînes aléatoires associées dynamiquement à des pages. Chaque adresse est ainsi son propre mot de passe, et on peut facilement donner accès à une page d'administration à plusieurs personnes ou inviter un groupe d'étudiants dans un salon.
Chaque page est chargée une seule fois, et se compose d'onglets pour ses différentes tâches. Un paramètre passé en queryString permet de spécifier une action à réaliser dans le contexte de la page courante. On réduira ainsi le nombre d'échanges client-serveur, en vue d'économiser des éventuels frais d'hébergement.
Les données de premier rang sont des variables globales du serveur. Lors de son démarrage, elles sont chargées à partir d'une base de données clés-valeurs simple. Ensuite chaque modification d'une donnée résulte en l'enregistrement en base pour la clé correspondante.
- acces_ouverts - dictionnaire indexé par l'adresse de chaque page
- page - nom de la page pour redirection (
admin
,enseignant
,apprenant
ouexpiree
) - salon - indice du salon pour enseignant et apprenant
- page - nom de la page pour redirection (
- salons - liste des informations sur chaque salon
- nom_salon - chaîne telle qu'affichée dans chaque interface
- apprenants - dictionnaire indexé par l'identifiant de chaque apprenant
- present - booléen indiquant si l'étudiant n'a pas quitté le salon
- code - texte contenant le dernier programme obtenu
- console - texte affiché dans la console de l'apprenant (à passer dans un sanitizer côté client mosaïque)
- dernier_envoi - timestamp de la dernière mise à jour du code ou console
- activite - liste d'évènements triée par timestamp
- timestamp - moment de réception de l'évènement
- action -
entree
,sortie
,envoi_code
,demande_assistance
,annulation_assitance
- liste_assistances - liste ordonnée des apprenants ayant demandé assistance
Tâches à gérer :
- examiner les adresses ouvertes et leurs pages associées, les supprimer, les renommer
- Créer une page d'enseignant et lui attribuer une adresse aléatoire, ou modifier une page existante (ex. pour augmenter des quotas ou réattribuer une adresse)
Le statut de demande d'assistance de chaque cellule en mosaïque est une machine à 3 états (stockés comme classe de chaque cellule) :
- ∅ - pas de demande en cours
- checked - l'apprenant de la cellule est sur liste d'attente d'assistance
- unchecking - l'assistance est terminée, tant que l'état est actif on inclut l'apprenant dans la liste
fin_assistance
envoyée à chaque mise à jour de la mosaïque
Les transitions sont :
- ∅ → checked sur présence du champ position_assistance pour l'apprenant
- checked → ∅ sur absence du champ position_assistance pour l'apprenant
- checked → unchecking par clic sur le bouton de fin d'assistance
- unchecking → ∅ sur absence du champ position_assistance pour l'apprenant
Tâches à gérer :
- fournir ou modifier la liste des identifiants apprenants et les informations associées
- réinitialiser les présences des étudiants
- afficher une mosaïque des apprenants et un panel d'actions sur les vignettes
- lire le code d'un étudiant, l'exécuter et éventuellement augmenter son avancement dans les tests
- examiner la progression dans le temps de chaque apprenant
- visualiser un résumé des activités durant les N dernières minutes
- afficher pour chaque page un bouton/raccourci d'overlay avec la documentation intégrée
- télécharger les données du salon en fichiers CSV dans un ZIP
Le bouton d'assistance côté apprenant est une machine à 4 états (stockés comme classe du bouton) :
- ∅ - pas de demande d'assistance en cours
- checking - on ajoute
demande_assistance: true
à chaque requête au serveur pour demander l'ajout en liste d'attente - checked - l'apprenant est en attente d'assistance, on envoie l'état du code et de la console à chaque requête au serveur tant que cet état est actif
- unchecking - on ajoute
demande_assistance: false
à chaque requête au serveur pour demander le retrait de la liste d'attente d'assistance
Les transitions sont :
- ∅ → checking par clic sur le bouton
- ∅ → checked si le champ position_assistance est présent dans une réponse du serveur
- checking → checked si le champ position_assistance est présent dans une réponse du serveur
- checking → ∅ par clic sur le bouton
- checked → unchecking par clic sur le bouton
- checked → ∅ si le champ position_assistance est absent d'une réponse du serveur
- unchecking → checked par clic sur le bouton
- unchecking → ∅ si le champ position_assistance est absent d'une réponse du serveur
Tâches à gérer :
- afficher un onglet pour paramétrer l'éditeur et l'interface (et décrire les paramètres avec du texte).
- associer un fichier natif Python au texte de l'éditeur (si permis par le navigateur), tel que chaque modification extérieure du fichier mette à jour l'éditeur, et chaque enregistrement depuis l'éditeur modifie le fichier.
- envoyer le code au serveur, soit automatiquement lors de l'enregistrement, soit lors de chaque demande de revue de code.
- exécuter le script courant dans un onglet de terminal Python avec coloration des différents types de messages (stdout, stderr, exceptions, informations)
- écrire dans la console stdin (sous le terminal Python) ou y charger le contenu d'un fichier, le texte n'étant pas supprimé après chaque exécution du script.
- afficher un onglet de bienvenue avec une présentation brève de l'outil
- réinitialiser son idenfiant courant pour se reconnecter
Notes :
- L'apparence visuelle (onglet actif, position du séparateur central, ...) doit être conservée à chaque rechargement de page.
- Si le fichier lié est modifié en dehors de l'éditeur et que l'éditeur contient des modifications non enregistrées, le fichier est dissocié de l'éditeur avec message d'alerte.
- Le contexte d'exécution doit être réinitialisé à chaque nouvelle exécution, pour correspondre au modèle mental de la conception d'un programme.