Quelques outils :
http://skaya.enix.org/webs/systeme/
max.* : fichier de test "barbare" (croissance extrêmement rapide)
- max.lif : au format "lif" (utilisé par pas mal de programmes disponibles sur le Net)
- max.bin : au format "binaire" demandé par le projet
- max.asc : au format "ascii" demandé par le projet
Outils de conversion (travaillent sur stdin/stdout) :
- ascii2bin.py : petit programme Python convertissant du format ascii vers le format binaire
- lif2ascii.py : petit programme Python convertissant du format lif vers le format ascii
(il y a pas mal d'exemples au format "lif" disponibles sur le Net)
Ce que je propose, c'est de remplir une petite fiche pour chaque projet en évaluant selon les critères suivants (sans mettre de points) ; ensuite on reprendra tout et on établira le barème précis.
Points à vérifier :
Administratif
- login de l'étudiant
- si c'est un binôme "qui rend le projet" : indiquer le login de l'autre binôme (visible dans le rapport normalement)
- si c'est un binôme "qui ne rend pas le projet" (qui pointe vers un autre binôme) : juste indiquer le login de l'autre binôme et passer au projet suivant
- indiquer le timestamp de rendu tel quel (1112345678 par exemple)
Partie 1 (algo)
- noter le type de structure de données utilisé (tableau, champ de bits, liste, ...) ; par exemple : "liste de lignes, chaque ligne est un champ de bits, utilisation de deux structures séparées pour étape N et N+1"
- laisser tourner avec "max", essayer de noter à partir de quel moment le programme n'arrive plus à faire 1 itération par seconde ; par exemple "plante au bout de 50 itérations", ou encore "impossible de faire plus d'une itération par seconde, passe 300 itérations (je n'ai pas été plus loin, trop long)"
- noter si le rapport fait une analyse (même sommaire) de la complexité temps et/ou mémoire ; par exemple : "petite analyse de la complexité : O(VC) en temps, O(C) en mémoire, où V est le nombre moyen de voisins et C le nombre de cellules", ou encore "pas d'analyse de complexité"
- s'il n'y a pas d'analyse de complexité, évaluer très grossièrement la complexité ; par exemple : "algorithme très naïf, fait 8 parcours complets d'une liste de longueur C pour chaque cellule!!!"
- noter si le rapport fait état d'une justification de la technique utilisée
- noter s'il y a quelquechose de particulier ; par exemple : "passe d'une liste chaînée de cellules à une liste chaînée de blocs au delà d'une certaine densité, sur des zones de 10x10 cellules"
Partie 2 (interface)
- indiquer le type d'interface (texte, "ascii art", gtk, etc)
- indiquer si l'interface est pratique à utiliser : prise en main immédiate / nécessite de lire rapidement la doc ou l'aide intégrée / nécessite de nombreux tests car pas clair / ...
- indiquer s'il y a des bonnes idées : tooltips, utilisation de la roulette de la souris pour zoomer ou changer la vitesse, possibilité de n'afficher qu'une itération sur N (pour accélérer l'algo), etc.
- indiquer s'il y a des bugs lorsqu'on pousse un peu l'interface (dessiner pendant les itérations, redimensionnement sauvage, ...)
- mentionner les remarques éventuelles figurant dans le rapport
Partie 3 (gestion de fichiers)
- indiquer ce qui a été implémenté (en vérifiant) : binaire, ascii, chargement "overlay" a des coordonnées précises
- si le binaire ne marche pas, c'est peut-être un problème d'endianness ; vérifier avec "hexdump -C" pour en avoir le coeur net, sur un fichier simpliste (avec une ou deux cellules proches des coordonnées 0)
- tester la sauvegarde du "max" obtenu précédemment, son rechargement ...
Partie 4 (réseau)
- indiquer ce qui est censé marcher
- tester (il y a beaucoup de choses implémentables ici ; donc il suffit de résumer ce qui marche en indiquant les bugs ; par exemple "possibilité d'éditer deux plateaux à la fois, mais le jeu se gèle pendant une seconde lorsqu'on ajoute une cellule d'un côté ou de l'autre")
- indiquer le protocole utilisé (par exemple : "transmet la liste des naissances puis la liste des morts, 8 octets par naissance/mort")
- vérifier que lorsqu'on charge un ficher d'un côté, ça le transmet bien de l'autre côté
Rapport
- indiquer si l'orthographe et le soin général (ponctuation, lisibilité) est OK / bof / nul
- indiquer si le rapport est joli ou pas :-)
- indiquer la "technologie" utilisée pour faire le rapport (par exemple : latex+latex2html, ou openoffice, ou ...)
Code
- indiquer si la compilation s'est bien passé (y a-t-il un makefile ? y a-t-il eu des warnings ?)
- indiquer le langage utilisé
- jeter un oeil au code, chercher les appels système (read, write, pipe, fork) et voir s'il y a bien un test d'erreur et ce qui est fait dans ce cas (chercher 2 ou 3 appels pour vérifier qu'il ne s'agit pas d'un cas isolé)
- (si c'est un langage que vous ne connaissez pas, indiquez-le et je m'en occuperai)
- indiquer si le code est bien séparé en plusieurs fichiers
- indiquer le style de commentaires ; par exemple "gros cartouche bien détaillé avant chaque fonction" ou encore "peu de commentaires, mais chaque algo ou section importante a une petite explication adéquate"
- indiquer s'il y a des choses positives ou négatives qui sautent aux yeux lorsqu'on survole le code (exemple : "nommage complètement aléatoire, un coup en anglais, un coup en français, un coup en mixedcase, un coup avec des underscore", ou encore "code court et efficace, mais pas toujours compréhensible" ou encore "quelques grosses maladresses avec les pointeurs : char *c = malloc(42) ; c = toto ;")
Appréciation générale
- tout commentaire qui n'aurait pas eu sa place ailleurs.