Mind... - Tag - Devel

Afficher des discussions

Florent Bruneau — Thu, 01 Nov 2007 17:24:00 +0100

Lorsqu'un logiciel a pour vocation d'afficher des discussions, on attend de sa part qu'il nous permette de voir simplement qui répond à qui, dans quel contexte... Ce n'est pas toujours ce qui est le mieux fait. Par exemple, les programmes de fora en ligne à la mode (phpBB par exemple) affiche les discussion comme une succession de rectangles juxtaposés et seul le contenu du message permet de voir qu'il en cite un autre. D'autres logiciels comme Mail.app ont ce défaut et parfois la fâcheuse manie de ne pas vouloir corriger ce problème.

L'affichage de l'arborescence dans Banana est une des fonctionnalités clés... et elle va beaucoup changer dans la prochaine version.

Une ligne par entrée

La solution habituelle pour afficher l'arborescence est d'utiliser un message par ligne de telle, des + ou - pour ouvrir ou fermer les noeuds. C'est la solution actuelle de banana.

Avec cette solution, on perd très rapidement en lisibilité : dès que la discussion dépasse une vingtaine de messages, l'arborescence devient très haute et plus ça va, plus le titre dérive vers la droite rendant parfois le lien inaccessible. Lorsqu'il y a un troll, il est de fait très courant que certains nouveaux messages se trouvent perdus plusieurs pages en arrière dans l'arborescence, ou que sur certains navigateurs, il soit difficile d'y accéder. De plus l'interface se trouve souvent surchargée, à la limite de la lisibilité : c'est dur de faire tenir un maximum d'informations en un minimum de place en gardant la lisibilité de l'ensemble.

Une solution plus visuelle

Je ne sais pas combien de personnes connaissent MacSoup. Il s'agit d'un petit client NNTP pour MacOS, qui en soit n'a pas beaucoup d'intérêt (il est payant et est relativement limité). Le principal atout de MacSoup est son interface de visualisation des threads (les utilisateurs diront qu'il y a bien plus que l'interface graphique, mais également l'interface clavier etc...). On trouve sur internet quelques captures d'écran en cherchant dans les moteurs de recherche d'image :

Cette interface est compacte, visuelle et permet d'accéder rapidement à n'importe quel message du thread. Pour la prochaine version de Banana, je me suis fortement inspiré de cette interface pour réécrire de 0 l'affichage de l'arborescence. Ceci donne :

Il s'agit de la même discussion que précédemment. On voit donc ici facilement l'arborescence. Lorsqu'un message est non lu, la branche à laquelle il est attaché est noire au lieu de grise ce qui permet de l'identifier du premier coup d'oeil. Les couleurs de fond des noeuds (une idée de Falco) sont obtenue à partir d'un hash quelconque sur l'émetteur et permettent donc d'identifier les messages envoyés par la même personne. Lorsqu'on laisse la souris sur un noeud, le nom de l'expéditeur et l'heure du post s'affichent (malheureusement le pointeur de la souris n'apparaît pas sur la capture d'écran)... et bien sûr quand on clique sur un noeud, on va sur le message correspondant.

Lorsqu'on est sur un message, on garde également la vue du thread ce qui permet de toujours savoir où on est dans la discussion :

Il y a encore un peu de travail à faire pour améliorer les performances de la génération des arbres et pour augmenter sa compacité (éviter les branches qui descendent très bas alors qu'elles auraient pu trouver leur place dans le l'espace vide disponible).

Compter les fichiers

Florent Bruneau — Thu, 30 Aug 2007 23:12:00 +0200

C'est un peu la suite de mon post "Outils pratiques" où je donnais deux scripts permettant de rendre les commandes SVN plus conviviales. Encore une fois, je réinvente sans doute la roue (des outils équivalents doivent déjà exister... sans doute en mieux), mais je pense que chercher ce genre d'outils sur internet m'aurait pris plus de temps que ce qu'il m'a fallu pour le développer.

En ce moment je manipule des fichiers, beaucoup de fichiers (et même, beaucoup de gros fichiers), que j'ouvre, rouvre, et ferme et puis referme. Et à force d'ouvrir, on oublie parfois de refermer, et là, c'est comme une fuite de mémoire, sauf que le nombre limite de fichiers ouverts est beaucoup plus rapidement atteinte que la limite de mémoire... dans la configuration de base sur un linux, un programme n'a le droit qu'à 1024 descripteurs de fichiers. D'où mon problème : comment traquer les "file-handle leaks" ?

Pour le faire, je me suis fait rapidement un petit script qui permet d'analyser les données issues d'un strace. strace est, pour ceux qui ne le savent pas, un programme très pratique qui permet de lister les appels systèmes. Dans mon cas présents, surveiller les ouvertures fermetures de fichiers revient à traquer les commandes open (ouverture d'un fichier), et les commandes close. Donc, je récupère simplement la liste des appels à open et close :

[bash]
strace -f -e trace=open,close mon programme 2> /quelque/part

Et ainsi, le fichier /quelque/part contient la liste complète des appels à open et close effectués par mon programme (et ses processus fils). Il ne reste plus alors qu'à analyser le contenu de /quelque/part. Pour ceci, il suffit de peu de lignes de code (en perl pour ma part, mais d'autres auraient fait la même chose en shell, python... ou n'importe quel langage de scripting) :

[perl]
#!/usr/bin/perl 
 
my %files; 
my %modes; 
my %lines; 
 
my $lineNb = 0; 
my $maxOpened = 0; 
my $currentOpened = 0; 
my $totalOpened = 0; 
 
for $line (<STDIN>) { 
  if ($line =~ /open\\("([^""]+)", ([^\\)]+)\\)\\s*=\\s*(\\d+)/) { 
    $files{$3} = $1; 
    $modes{$3} = $2; 
    $lines{$3} = $lineNb; 
    $totalOpened++; 
    $currentOpened++; 
    if ($currentOpened > $maxOpened) { 
      $maxOpened = $currentOpened; 
    } 
  } 
  if ($line =~ /close\\((\\d+)\\)/ && $files{$1} ne '') { 
    $files{$1} = ''; 
    $currentOpened--; 
  } 
  $lineNb++; 
} 
 
print "$totalOpened files opened, max. $maxOpened at the same time
"; 
print "$currentOpened files not closed
"; 
for $id (keys %files) { 
  local $file = $files{$id}; 
  local $mode = $modes{$id}; 
  local $line = $lines{$id}; 
 
  if ($file ne '') { 
    print "[line $line] id=$id, open $file with mode $mode
"; 
  } 
}

Pour simplifier le tout, on rajoute une fonction dans le zshrc pour wrapper tout ça, et ça donne (attention, ceci ne fonctionne que sous linux, mktemp n'a pas la même syntaxe sur MacOS, et surtout, strace n'est pas disponible sur Mac

[bash]
function checkFiles() { 
  TEMPFILE=`mktemp` 
  strace -f -e trace=open,close $* 2> $TEMPFILE 
  cat $TEMPFILE | ~/.zsh/trackFiles.pl 
  rm $TEMPFILE 
}

Avec, ça, il ne me répond :

% checkFiles cp test test2
12 files opened, max. 2 at the same time
0 files not closed

Si maintenant, je fais un programme minimaliste qui oublie de fermer un fichier :

[c]
#include <stdio.h> 
 
int main() { 
  FILE* file = fopen("test", "r"); 
  return file != NULL ? 0 : 1; 
}

% gcc test.c -o tester
% checkFiles ./tester
3 files opened, max. 1 at the same time
1 files not closed
[line 4] id=3, open test with mode O_RDONLY

Voilà, maintenant je sais que mon programme oublie de fermer un fichier, que ce fichier s'appelle "test", et qu'il est ouvert en read-only. La ligne "4" est la ligne dans la sortie de strace, et n'a aucun rapport avec la ligne 4 du fichier source (contrairement aux apparences).

Templates en C

Florent Bruneau — Thu, 16 Aug 2007 22:53:00 +0200

En C++, il existe un mécanisme extrêmement pratique pour généré du code générique : les templates. Une fonction templatée est une fonction dont le code comporte un trou qui sera remplacé à la compilation par le nom d'un type, ou une valeur... Par exemple :

template <class T> 
T read(const char *buffer) 
{
    T val;
    memcpy(&val, buffer, sizeof(T));
    return val;
}

Cette fonction lit un objet de type T sur un buffer. L'intérêt de cette fonction est très compréhensible : quel que soit le type qu'on fournit à la fonction, elle va fonctionner, en adaptant la taille à lire au type. C'est donc beaucoup plus rapide que d'écrire une fonction pour chaque type... et l'utilisation est également très simple :

read<int>(const char* buffer) // lit un entier sur le buffer
read<double>(const char* buffer) // lit un double sur le buffer
read<MaClass>(const char* buffer) // lit un objet de type "MaClass"

Mais cette syntaxe n'est qu'un sucre syntaxique, car en fait, on peut également faire des templates en C...

Comment fonctionne les templates ?

En fait un template est, comme son nom l'indique, qu'un modèle de fonction. Lors de la compilation d'un programme qui utilise des templates, le compilateur regarde la liste des instances de cette fonction qui sont utilisées et les génère. Plus explicitement, si j'appelle read<double>(), le compilateur va générer cette fonction :

[cpp]
double read<double>(const char *buffer) 
{
    double val;
    memcpy(&val, buffer, sizeof(double));
    return val;
}

Ainsi, l'appel à read<double> devient un appel de fonction classique.

Jeu de préprocesseur

Le préprocesseur en C possède des outils sympathique... Nous nous attarderons particulièrement sur le ##. Il s'agit tout simplement d'un opérateur de concaténation. Donc :

[c]
#define Truc(Machin) Truc ## Machin

Truc(Bidule) /* génère TrucBidule */

C'est donc très pratique. On peut facilement par exemple, imaginer une petite macro du genre :

[c]
#define maFonction(Type) maFonction_ ## Type

Si dans ce cas, on défini par exemple maFonction_int, maFonction_double, maFonction_MaStruct (oui, les classes n'existent pas en C), on pourra faire

[c]
maFonction(int)(args); /* appelle maFonction_int */
maFonction(double)(args); /* appelle maFonction_double */
maFonction(MaStruct)(args); /* appelle maFonction_MaStruct */

Maintenant, il ne reste plus qu'à générer les fonctions... sans avoir à toutes les écrire une à une. Pour ceci, nous allons encore une fois profiter de la présence du préprocesseur.

[c]
#define maFonctionBuild(Type) \\
  Type maFonction_ ## Type(const char* buffer) { \\
    Type val; \\
    memcpy(&val, buffer, sizeof(Type)); \\
    return val; \\
  } 

maFonctionBuild(int) /* génère maFonction_int */
maFonctionBuild(double) /* génère maFonction_double */
maFonctionBuild(MaStruct) /* génère maFonction_MaStruct */

Il ne reste donc qu'à appeler maFonctionBuild(Type) sur chacun des types pour lesquels nous avons besoin d'instancier la fonction, et d'appeler maFonction(Type) chaque fois qu'on veut appeler maFonction pour le type en question. D'une certaine manière on peut dès lors dire que les fonctions sont :

[c]
Type maFonction(Type)(const char* buffer);

Et voilà !

Nous avons donc une implémentation générique grâce au préprocesseur associé à un appel typé. Ce n'est évidemment qu'une astuce de préprocesseur, mais cela donne une souplesse syntaxique agréalble : "J'appelle maFonction appliquée sur les entiers avec les arguments args".

Tout ceci est certes, moins souple que les templates C++ :

il n'y a pas d'auto-instanciation par le compilateur : il faut "manuellement" instancier la fonction pour tous les types pour lesquels ont l'appelle
il n'y a pas de "type check" : les seules limites sont celle de la compilation
le correction des erreurs de compilation est fastidieuse car toutes les erreurs apparaissent comme étant à la ligne d'appel à maFonctionBuild
il est rapidement fastidieux de rajouter l'antislash à la fin de chaque ligne de la définition de la fonction

Comme on le voit dans les choix de l'exemple, pour les entrées/sorties, ça permet d'avoir une seule fonction à écrire tout en gardant la flexibilité d'une fonction par type de données.

Comprendre du code

Florent Bruneau — Wed, 15 Aug 2007 01:28:00 +0200

J'ai tenté cet après-midi une petite expérience sur IRC. J'ai posté 3 lignes de code en demandant "que font ces trois lignes". Après quelques minutes (sans doute trop peu), j'ai donné la solution car personne n'avait vraiment trouvé. En effet, même si on réussi facilement à lire le code et à reconstituer la suite d'opération qu'il génère, il est très difficile de vraiment comprendre ce qu'il fait, d'imaginer son application dans un contexte et d'en déduire son usage.

Juste pour continuer à m'amuser, et pour amuser ceux qui se perdraient ici, voici le code en question.

[c]
do {
  ++(*pos);
} while (*(pos++) == 0);

Vous pouvez remarquer dès à présent que ce code n'est pas volontairement rendu illisible (il serait facile de supprimer des parenthèses et de changer le test de nullité en une négation. Le but est donc de comprendre la suite d'instruction, de dire ce qu'elle fait et ensuite de comprendre dans quel contexte elle est utilisable. La question est aussi de savoir en combien de temps vous allez trouver la solution.

Cliquer ici pour afficher la répondre

Fonctionnement

Si on lit le code, on voit qu'il fait la suite d'opération suivante :

on incrémente la valeur pointée par pos
on regarde si la valeur obtenue est nulle
on incrémente le pointeur pos
si le test 2 est vrai, on retourne en 1, sinon, on quitte la boucle

Il s'agit donc d'une petite boucle qui incrémente des objets successifs jusqu'à ce qu'elle en trouve un qui, une fois incrémenté, n'est pas nul.

Voilà donc la solution du pauvre au problème, celle qu'on peut trouver en lisant le code, sans chercher à le comprendre.

Interprétation

Mais en fait, ce code va plus loin. Imaginons maintenant la zone mémoire sur laquelle pos pointe initialement :

 oct1 oct2 oct3 oct4
  ^
 pos

L'octet 1 à une certaine valeur. Je l'incrémente et je m'aperçois que sa nouvelle valeur est 0. Quand un octet incrémenté peut-il retomber à 0 ? Quand il fait un overflow. On a donc fait déborder le premier octet... et quand cet octet déborde on incrémente le suivant :

    _+1__
   |     |
 oct1 oct2 oct3 oct4
       ^
      pos

Il s'agit donc ni plus ni moins que d'une retenue (comme quand on apprend à faire les additions ou les multiplications) : quand je fais déborder un octet, je déplace le surplus vers le suivant. Finalement, ces 3 lignes de code ne sont que l'implémentation d'une incrémentation, mais sur plusieurs octets... et même sur un nombre non défini d'octets (puisqu'il n'y a pas de limite explicitée sur le nombre d'étapes autorisées).

Pour être plus précis, il s'agit d'un incrémenteur d'entier stocké en Little Endian sur un nombre illimité d'octets.

Encore ?

Bon, pour ceux qui tiennent vraiment à s'assurer que ce n'est pas du code illisible, voici une version vraiment illisible de la même machine :

[c]
for(++*pos;!*pos++;++*pos);

(Merci Falco)

Tout ceci n'était bien sûr qu'un exemple. Il est toujours très dur de comprendre du code, alors pour éviter de passer dix minutes sur 3 lignes lors de la prochaine relecture il suffit de documenter ce qu'on écrit.

Khtml2png 2.6.5 est sorti

Florent Bruneau — Tue, 05 Jun 2007 22:31:00 +0200

Après 3 mois d'un travail pas très intensif, une nouvelle version de khtml2png est disponible. Cette version est partie du fait que les versions précédentes du programme ont parfois du mal à gérer les grandes captures d'écran (en fait, des bugs peuvent apparaître dès que la taille de la zone à capturer est plus grande que la taille affichable).

Donc, rapidement après la sortie de la 2.6.0, j'avais envoyé un correctif (en fait une réécriture du moteur de rendu) au développeur de khtml2png. Malheureusement, ce correctif ne fonctionnait pas correctement chez lui. Donc, pendant 3 mois, j'ai fait du débuggage à distance : j'envoie une version modifiée (1 ou 2 lignes à chaque fois), j'attends 2 ou 3 semaine une réponse, etc... Du développement efficace !

Bon, toujours est-il que maintenant, la version 2.6.5 fonctionne à la fois chez moi (à la fois Debian + xvnc et sur MacOS X), et chez Hauke (sur Debian également, mais avec des réglages différents).

Le Changelog annonce :

fix: Now produces screenshots on my Debian Etch system under KDE 3.5.5 without glitches.
fix: Maybe better working on other systems too. Please test.

J'aimerais y rajouter quelques points :

meilleur moteur de rendu (qui ne scroll plus, mais déplace la fenêtre pour s'affranchir de certains bugs de KDE et/ou Qt)
meilleure détection de la taille de la capture à réaliser
possibilité de choisir le comportement de khtml2png face aux redirections, au javascript, au java, au flash... via la ligne de commande
la détection automatique de la dimension par un id devient compatible avec le format utilisé dans les version <= 2.5

Comme d'habitude, vous pouvez télécharger ma dernière version du programme.

Et si on oubliait les bases ?

Florent Bruneau — Sat, 26 May 2007 11:40:00 +0200

MacOS X est un Unix... compatible POSIX. Voilà ce qu'un certain nombre de personnes semblent oublier assez fréquemment. C'est assez dommage quand ces personnes programment pour MacOS, on se retrouve parfois avec du code complexe pour réécrire des fonctions POSIX (en moins bien ?).

En fait si je parle de ça, c'est parce que je viens de rencontrer le problème dans le cadre du développement de VirtueDesktops. Il se trouve qu'en parcourant le tracker du projet je suis tombé sur le ticket 115 qui s'intitule :

Patch to check group id of 'procmod' group

C'est intéressant... jusqu'à maintenant Virtue suppose que le gid du groupe procmod est celui par défaut de MacOS (c'est à dire qu'il vaut 9)... et le problème est donc que si un utilisateur a un procmod différent (ou si Apple décide un jour de changer le gid du groupe), le code actuel peut avoir des résultats inattendus, il faut donc faire un code plus portable qui recherche le gid de procmod au lieu de le stocker en dur. Ce n'est clairement pas une mauvaise idée ! Seul problème, le patch soumis est le suivant (au cas où certain voudrait réutiliser ce code, je tiens à signaler que c'est une mauvaise idée !) :

[c]
#define NI_DOMAIN	"."
#define NI_PATH		"/name=groups/name=procmod"
#define NI_KEY		"gid"

// Sucked from netinfo-369.5/tools/niutil/niutil.c
ni_status ni_read_single_prop(char **property)
{
	const char *args[] = {NI_DOMAIN, NI_PATH, NI_KEY};
	
	char myname[] = "ni_read_single_prop";
	const bool opt_tag = false;
	const int timeout = 30;
	
	ni_namelist nl;
	void *domain;
	ni_id dir;	
	ni_status ret;

	if ((ret = do_open(myname, args[0], &domain, opt_tag, timeout, NULL, NULL)) != 0) return ret;

	/* args[1] should be a directory specification */
	ret = ni2_pathsearch(domain, &dir, args[1]);
	if (ret != NI_OK) {
		fprintf(stderr, "%s: can't open directory %s: %s
", myname, args[1], ni_error(ret));
		ni_free(domain);
		return ret;
	}

	/* get the property values for args[2] */
	NI_INIT(&nl);
	ret = ni_lookupprop(domain, &dir, args[2], &nl);
	if (ret != NI_OK) {
		fprintf(stderr, "%s: can't get property %s in directory %s: %s
", myname, args[2], args[1], ni_error(ret));
		ni_free(domain);
		return ret;
	}
	
	
	if (nl.ni_namelist_len != 1) {
		fprintf(stderr, "%s: expected length = 1, found length = %d
", myname, nl.ni_namelist_len);
		return NI_FAILED;
	}
	
	*property = (char*)calloc(strlen(nl.ni_namelist_val[0]) + 1, sizeof(char));
	strcpy(*property, nl.ni_namelist_val[0]);
	
	ni_namelist_free(&nl);
	ni_free(domain);
	
	return NI_OK;
}

Donc que fait cette fonction ? C'est assez simple : elle utilise l'utilitaire NetInfo d'Apple pour lire les informations relatives au chemin /groups/procmod. Une fois là dedans elle copie la valeur stockée à la clé gid et renvoie cette chaîne dans le pointeur passé en argument.

Il n'y a pas à dire... c'est une solution qui devrait fonctionner (enfin j'ai même un doute, car je ne vois pas le groupe procmod apparaître quand je regarde dans NetInfo). Seulement cette solution montre clairement que la personne qui l'a écrite savait que MacOS utilise un système de groupes, mais avait oublié qu'en fait c'est avant tout un système POSIX. Et là, ce qui est intéressant c'est que sous MacOS X on a accès à l'API POSIX... en particulier à la fonction getgrnam qui retourne les informations sur un groupe à partir de son nom.

Donc, pas besoin de dépendance vers NetInfo, pas besoin d'une recherche dans une arborescence abstraite : NetInfo n'est qu'une abstraction de la couche Unix pour simplifier l'accès aux données par les utilisateurs... mais ça ne doit pas être un framework d'abstraction de l'API POSIX ce qui entraîne nécessairement du code moins portable (et surtout, moins lisible dans le cas présent), moins rapide et plus lourd.

Ici, le code est utilisé dans un programme en C qui est chargé de mettre un objet dans le groupe procmod pour autoriser Virtue à effectuer certaines actions qui nécessitent un accès privilégié au serveur graphique... ce programme ne fait que changer les permissions. Pourquoi utiliser une API lourde et spécifique à MacOS alors que ce type de programme pourrait clairement être utilisé sur n'importe quel Unix ?

Voici donc une solution qui fait la même chose que la fonction ci-dessus, en mieux et surtout en beaucoup moins de lignes :

[c]
#include <grp.h>

static int getProcmodGid()
{
    struct group* groupDesc; 
    int gid = -1; 
    groupDesc = getgrnam("procmod"); 
    if (groupDesc) {
        gid = groupDesc->gr_gid; 
        free(groupDesc); 
    } 
    return gid; 
}

Pourquoi cette solution est-elle meilleure ?

elle retourne un entier... on a donc pas besoin de faire une conversion a posteriori
elle utilise l'API POSIX et est donc utilisable sur n'importe quel OS POSIX (donc quasiment tous... à l'exception de Windows)
elle évite toute manipulation inutile de chaîne de caractères
elle est ne nécessite pas de charger une bibliothèque supplémentaire : getgrnam est dans la libc
elle est drôlement plus courte non ?

VirtueDesktops revient...

Florent Bruneau — Fri, 18 May 2007 12:25:00 +0200

Voici plus ou moins trois mois que j'ai découvert synergy, c'est vraiment très agréable de pouvoir contrôler les deux ordinateurs sans changer de clavier/souris continuellement. Seul problème, c'est que sur la machine qui héberge le serveur synergy, VirtueDesktops, un excellent gestionnaire de bureaux virtuels pour MacOS, n'arrête pas de crasher. J'avais donc posté un bugreport sur le trac de Virtue... malheureusement pour diverses raisons, Tony Arnold a décidé peu après de stopper le développement de Virtue.

J'ai donc pris mon courage à 2 mains, et je me suis doucement plongé dans le code de VirtueDesktops (c'est vraiment bien les applications OpenSource). Il y a maintenant deux semaines, j'ai soumis le patch permettant de corriger le crash dont je souffrais. Depuis, ce patch a été publié ce qui a conduit la release de la bêta 3 de Virtue 0.54.

Je me suis relancé dans le développement cette semaine en me fixant comme objectif de corriger plusieurs comportements énervants de Virtue. Par exemple, si je dis que Mail.app doit être sur le bureau Mail, je veux que toutes les fenêtres de Mail.app aillent forcément sur ce bureau. Seul problème, c'est que lorsque je reçois une notification de l'arrivée d'un nouveau mail et que je clique sur cette notification, une fenêtre avec le message s'ouvre sur le bureau courant, et Virtue tourne pour atteindre le bureau de Mail.app... résultat : j'ai changé de bureau mais je n'ai pas accès à la fenêtre que je voulais voir. J'ai corrigé ce comportement, désormais, la fenêtre est automatiquement déplacée sur le bureau de Mail.app lors de son ouverture.

Autres corrections diverses :

lorsqu'on ferme une application Virtue reste sur le bureau courant (sauf si il n'y a plus rien sur le bureau courant)
lorsqu'on choisi de changer de bureau, Virtue active désormais la dernière application active connue pour le nouveau bureau
lorsqu'on restaure une fenêtre qui était dans le Dock, soit l'application a le droit d'être sur le bureau courant et la fenêtre est affichée sur ce bureau sans chercher à changer de bureau, soit l'application est attribuée à un bureau et dans ce cas la fenêtre est restaurée sur le bureau de l'application et Virtue change de bureau
...

Ces changements ont abouti à la bêta 4 et se résument à :

Changing to desktops when you launch, activate, deactivate, minimise, restore or quit an application should be much more consistent;
Window ordering when changing desktops should be much more consistent;

La Banane et l'escargot

Florent Bruneau — Mon, 07 May 2007 17:44:00 +0200

La release de Banana 1.6 en même temps que celle de plat/al 0.9.14 a mis en évidence un certain nombre de faiblesses dans Banana. En particuliers la génération du spool (mise en cache de l'arborescence des messages) et des flux RSS s'est révélé extrêmement lourde pour plusieurs raisons :

l'accès aux mbox des Mailing-Lists nécessite d'appel du mbox-helper, et donc un fork... opération lourde, qui répétée plusieurs fois par mbox devient rapidement très lourde lorsqu'on a plusieurs dizaines de Mailing-Lists.
le traitement des données par PHP est loin d'être immédiats... et il y a clairement des goulots d'étranglement dans le code.

C'est pour ces raisons que j'ai passé Banana au profiler, c'est à dire que j'ai analysé l'exécution de Banana à l'aide d'un outil qui permet de tracer l'exécution du programme et mettant un accent particuliers sur le temps d'exécution de chaque fonction. L'outil que j'ai trouvé pour faire ça est xdebug, utilisé conjointement à KCacheGrind.

Forks

Je dois avouer que lorsque j'avais fait mes tests, je n'avais pas plusieurs centaines de Mailing-Lists à traiter... et je ne m'attendais pas à ce qu'une fois passée en production le script de mise à jour des flux RSS puisse prendre toutes les ressources de la machine pendant plusieurs minutes. Il a donc fallu sérieusement restructurer la gestion des accès aux Mailing-Lists pour restreindre au maximum le nombre d'accès au mbox-helper (un petit programme écrit en C qui se charge de tous les accès aux mbox), et, en cas d'accès, limiter au maximum le temps passer sur le mbox-helper.

Donc désormais le mbox-helper n'est plus appelé que si la mbox a changé depuis le dernier passage (le changement étant détecté par la taille du fichier). Ce qui permet donc de supprimer le lancement d'environ 500 mbox-helper lors des rafraîchissements des spools (en effet, un nombre négligeable de Mailing-List aura des nouveaux messages lors du passage du script toutes les 5, 10 ou 20 minutes). Ajouté à cela la correction d'un bug qui faisait que l'appel au mbox-helper oubliait de spécifier l'offset où chercher le message à traiter et qui forçait donc le mbox-helper à relire la totalité de la mbox, on peut se permettre de supposer que la prochaine version de Banana sera plus efficace pour la gestion des mbox.

Array_shift

Piles

Il est souvent extrêment pratique d'utiliser une pile de données. Cela permet de traiter les informations dans l'ordre de la pile sans excès de mémoire puisque chaque élément est dépilé avant d'être traité. C'est une technique que j'aime particulièrement lorsque j'ai une suite de lignes à traiter : je prend un tableau contenant une ligne par entrée et je le parcours avec array_shift qui permet de dépiler le premier élément du tableau. On obtient ainsi un code de la forme

[php]
while (!is_null($line = array_shift($lines))) {
    do_something($line);
}
do_something($lines);

Un foreach peut très bien faire la même chose, mais on perd les avantages de la piles. Avec cette structure, pour avoir le même comportement que la boucle précédente, il faut ajouter un unset() :

[php]
foreach ($lines as $key=>&$value) {
    do_something($line);
    unset($lines[$key]);
}
do_something($lines);

Certes le foreach sera sensiblement plus rapide que le while/array_shift() car il comprend un appel de fonction à chaque itération, mais on peut s'attendre raisonnablement à ce que cet appel soit en O(1), et ait donc un coût négligeable.

Profiler

Là où il y a un problème c'est que le profiler m'indique que array_shift prend 57% du temps d'exécution de Banana. Ces 57% sont partagés entre 80000 appels à la fonction, mais le plus marquant c'est que parmi ces 80000 appels, ce ne sont que 24000 d'entre eux qui prennent la quasi-totalité du temps. Pourquoi ces appels particuliers sont-ils si lourd alors que les 60000 autres ont un coût parfaitement négligeable.

La seule différence entre ces deux cas d'appels c'est que les lourds traitent un énorme tableau de 24000 lignes, alors que les légers traitent un grand nombre de petits tableaux de quelques dizaines de lignes chacun. Il est donc extrêmement clair que array_shift n'est pas une fonction en O(1)... J'ai donc changé la structure de code qui reflétait la structure de données par une simple boucle qui perd en lisibilité dans ce patch. Après ce changement, les 60000 array_shift restant ne prennent que 0.16% du temps d'exécution de Banana...

0.9.14 en ligne !

Florent Bruneau — Sun, 29 Apr 2007 19:09:00 +0200

Ca y est, comme annoncé dans mon billet de fin mars, la version 0.9.14 de plat/al est en ligne depuis vendredi soir. Comme expliqué précédemment, cette version apporte un grand nombre d'innovations comme le flux RSS pour les Mailing-Lists et les Fora, la recherche par proximité sonore améliorée et généralisée, un système d'annonces retravaillé pour offrir un approche plus conviviale, et bien sûr, le passage en UTF-8.

Mais de tout cela, j'en ai déjà parlé... je tiens par contre à m'étendre sur les quelques fonctionnalités qui ont été développées durant le dernier mois (en fait, durant les dernières deux semaines de développement, le reste du temps ayant été consacré aux tests).

Recherche interactive

Caribou a réalisé un énorme travail sur la mise en place d'un remplissage automatique (auto-completion pour les geeks) sur la recherche avancée. Ainsi, lorsqu'on tape quelques caractères dans un champ, une liste de propositions apparaît avec pour chaque proposition le nombre de camarades correspondant à la requête. Ce qui donne par exemple :

Par contre, là où cela devient très intéressant, c'est que l'interface reste flexible : si vous préférez choisir dans une liste des valeurs possibles plutôt que d'utiliser l'auto-completion, ce qui est envisageable, il suffit, si c'est disponible pour le champ correspondant, de cliquer sur la petite icône représentant une liste en fin de ligne... Ainsi, pour les pays, cela donne :

Il s'agit du même champ dont le <input type="text"> a été remplacé par une <select>.

Sondages

Les sondages étaient la seule fonctionnalité du site qui avait été perdue lors du passage à plat/al il y a maintenant 2 ans et demi. C'est maintenant réparé grâce au travail de pika. Cette fonctionnalité étant de fait encore jeune, on peut s'attendre à ce que l'interface soit retravaillée fortement dans les prochaines versions du site pour s'adapter aux attentes des utilisateurs. Néanmoins, il est à noter que l'édition des sondages a été travaillée de telle sorte qu'un sondage soit facilement éditable : l'utilisateur qui crée un sondage peut aisément ajouter, supprimer ou modifier des questions, et les administrateurs ont accès exactement aux mêmes fonctionnalités pour la maintenance des sondages.

Nous attendons maintenant l'utilisation de cette fonctionnalité pour avoir des retours de la part de nos utilisateurs. Si l'expérience se révèle concluante, les sondages seront intégrés à Polytechnique.net pour que les animateurs les aient à leur disposition directement depuis l'interface de gestion des groupes.

Ensemble d'utilisateurs

Il s'agit de la partie sur laquelle j'ai travaillé, et donc celle que je connais le mieux, mais c'est aussi la partie la plus abstraite. Pour l'utilisateur, ça ne change quasiment rien, par contre au niveau du moteur du site, c'est à mon sens un pas en avant important vers des interfaces plus adaptées aux besoins des utilisateurs. C'est pour cette raison que cette partie risque d'être un poil technique.

Ce dont je parlais au paragraphe précédent est la gestion des ensembles d'utilisateurs... mais qu'est-ce donc ? un ensemble d'utilisateur est tout simplement une sélection d'utilisateurs dans l'annuaire, ça peut être les membres d'une Mailing-List, les contacts d'un utilisateur, les membres d'un groupe, les camarades correspondant à une recherche...

Le problème est que je voudrais que dès que sélectionne un ensemble d'utilisateur, je puisse séparer totalement la représentation de ces utilisateurs de la sélection qui est faite : ainsi si je choisi mes contacts, je veux pouvoir afficher mes contacts sur un planisphère, voir le trombinoscope de mes contacts, mais aussi voir leurs fiches... mais je voudrais avoir les mêmes outils pour toute autre sélection d'utilisateur.

La résolution propre de ce problème (c'est-à-dire, sans tout recoder à chaque cas possible d'utilisation) est l'utilisation d'un outil orienté Model/View :

le modèle gère la parti sélection des utilisateurs en fonction de la page
l'afficheur sélectionne les données à afficher pour les utilisateurs et génère ce que l'utilisateur verra

Dans plat/al, le Model s'appelle PlSet (duquel hérite un UserSet spécialisé dans les ensembles d'utilisateurs), et le View s'appelle PlView. De cette manière, l'affichage des contacts se fait en 5 lignes de code :

[php]
$view = new UserSet("INNER JOIN contacts AS c2 ON (u.user_id = c2.contact)", " c2.uid = $uid ");
$view->addMod('minifiche', 'Mini-Fiches', true); 
$view->addMod('trombi', 'Trombinoscope', false, array('with_admin' => false, 'with_promo' => true)); 
$view->addMod('geoloc', 'Planisphère'); 
$view->apply('carnet/contacts', $page, $action, $subaction);

On crée le UserSet en lui donnant les critères de sélection des utilisateurs à afficher, puis on ajoute les Views à utiliser, enfin on gère l'affichage (en fonction des arguments passés à l'affichage de la page). C'est le type d'abstraction qui font vraiment plaisir car finalement on se rapproche du slogan de Qt : Code less, Do more.

Bien sûr, il faut développer tout le background, mais le temps de développement est négligeable comparé à celui qu'on aurait passé à dupliquer ce code, voire justement à ne pas le dupliquer en raison de la complexité de certains cas. Un autre exemple d'utilisation est sur l'annuaire des groupes sur Polytechnique.net :

[php]
$view = new UserSet(); 
$view->addMod('trombi', 'Trombinoscope'); 
$view->addMod('geoloc', 'Planisphère'); 
$view->apply('annuaire', $page, $action, $subaction);

Dans ce cas, comme UserSet sait que s'il est appelé dans le cadre d'un groupe-X sur Polytechnique.net, il ne doit pas sélectionner d'utilisateurs hors de l'annuaire de ce groupe, il n'y a aucune restriction à lui indiquer : tout l'annuaire du groupe est sélectionné. On ajoute les deux modules de représentation qu'on désire utiliser : trombinoscope et Planispère, et applique à la page... en 4 lignes c'est fait.

Je m'extasie devant ce travail parce que je suis content du résultat, mais il n'est pas pour autant parfait. Son problème actuel est dû au background basé sur SQL : chaque élément (PlSet ou PlView) apporte des bribes d'une requête SQL permettant de finalement obtenir toutes les informations à afficher (PlView) pour les utilisateurs sélectionnés (PlSet), mais il peut arriver qu'une même donnée soit utilisée pour la sélection et pour l'affichage. Dans ce cas, la solution la plus simple est de dupliquer les jointures dans la requête, mais c'est une solution qui peut sérieusement alourdir et ralentir la requête.

L'implémentation actuelle gère la duplication au cas par cas : les PlView peuvent contenir tester s'il faut sélectionner un champ ou non en testant la classe du PlSet utilisé. Cette solution n'est pas particulièrement propre. La meilleure solution envisageable est d'utiliser une abstraction des champs SQL : chaque élément ne donnerait plus une bribe de requête SQL mais des informations sur "comment sélectionner la donnée"... ensuite la génération de la requête consiste à comparer toutes ces informations et à les assembler. Plat/al possède déjà les outils nécessaires pour réaliser ce jeu d'assemblage... ce sera très probablement pour la prochaine release.

Stats

Florent Bruneau — Sat, 21 Apr 2007 00:59:00 +0200

Depuis le début, j'ai installé awstats pour avoir des statistiques sur l'utilisation de mon serveur web.

J'ai choisi awstats un peu par hasard :

on avait utilisé webalizer au BR et je n'étais pas spécialement convaincu par le résultat obtenu : beaucoup de chiffres, graphiquement peu attirant et d'ergonomie d'utilisation assez mauvaise.
à Polytechnique.org par contre, on utilise awstats, même si je n'ai pas fait le bilant complet des fonctionnalités, il a au moins l'avantage d'être lisible et agréable à l'oeil.

Donc je l'ai installé, personnalisé... en particuliers j'ai ajouté des browsers (principalement des syndicateurs) et robots, amélioré les spécifications de certains OS, et j'avais également ajouté à l'outil de configuration le support de MAMP. J'ai envoyé le patch au mainteneur du projet. Aujourd'hui je fais un cvs up sur mon installation du projet et je vois :

P docs/awstats_faq.html
RCS file: /cvsroot/awstats/awstats/tools/awstats_configure.pl,v
retrieving revision 1.6
retrieving revision 1.7
Merging differences between 1.6 and 1.7 into awstats_configure.pl
M tools/awstats_configure.pl
M wwwroot/cgi-bin/awstats.model.conf
RCS file: /cvsroot/awstats/awstats/wwwroot/cgi-bin/lib/browsers.pm,v
retrieving revision 1.54
retrieving revision 1.55
Merging differences between 1.54 and 1.55 into browsers.pm
M wwwroot/cgi-bin/lib/browsers.pm
RCS file: /cvsroot/awstats/awstats/wwwroot/cgi-bin/lib/operating_systems.pm,v
retrieving revision 1.20
retrieving revision 1.21
Merging differences between 1.20 and 1.21 into operating_systems.pm
M wwwroot/cgi-bin/lib/operating_systems.pm
RCS file: /cvsroot/awstats/awstats/wwwroot/cgi-bin/lib/robots.pm,v
retrieving revision 1.44
retrieving revision 1.45
Merging differences between 1.44 and 1.45 into robots.pm
M wwwroot/cgi-bin/lib/robots.pm

Bizarrement, tous les fichiers que j'ai modifié ont été modifié également sur la CVS... donc je suis allé faire un tour sur le webvc du projet, et sur les fichiers correspondants, il y a le commentaire Patch florent bruneau.

Voilà, une bonne surprise ! Je suis juste un peu déçu de l'avoir vu uniquement sur un update de cvs.

Un aperçu de la version 0.9.14 de plat/al

Florent Bruneau — Fri, 30 Mar 2007 11:39:00 +0200

Le site de Polytechnique.org est prévu pour être mis à jour régulièrement, de l'ordre d'une fois tous les deux mois. Ainsi, les mises à jours sont suffisamment substantielles pour créer un effet d'annonce autour des améliorations apportées au site, sans pour autant laisser traîner les correctifs de bugs trop longtemps dans la branche de développement sans en faire profiter les utilisateurs.

La version 0.9.13 est sortie fin janvier, un peu plus d'un mois après la 0.9.12. La 0.9.14 sortira probablement fin avril (en tout cas, ce sera après le passage de etch en stable chez debian). Néanmoins, vue la masse de changement de cette nouvelle version, nous avons décidé de lancer les tests plus tôt qu'à l'accoutumée. Voici donc un aperçu des nouveautés (seulement un aperçu car le développement de cette version n'est pas freezé).

Comme à l'accoutumée, la liste exhaustive des changements se trouve dans le ChangeLog.

Passage en UTF8

C'est le changement le moins visible... mais le plus douloureux. En fait pour l'utilisateur a priori, rien ne change... mais en background toutes les pages, sans exception, sont affectées et donc potentiellement buggées. La plupart du temps un bug d'UTF8 (dans le sens latin1 interprété comme de l'UTF8) entraîne l'affichage d'une page vide ou blanche, ce qui est beaucoup plus douloureux que dans l'autre sens (UTF8 interprété comme du latin1).

Le passage en UTF8 s'accompagne d'un passage de MySQL 4.0 à MySQL 5... a priori la plupart des incompatibilités SQL sont corrigées mais on ne sait jamais. Pour l'instant nous n'utilisons pas vraiment les nouveautés de MySQL 5 (en fait un MySQL 4.1 aurait suffi pour l'usage qu'on en fait). Mais ce changement permet de prévoir à l'avenir un changement de la structure de la base SQL que nous utilisons, ce qui sera sans doute nécessaire lors de la fusion des annuaires.

Syntaxe Wiki généralisée

Autre nouveauté majeure, mais cette fois dont l'utilisateur bénéficiera directement : une syntaxe wiki généralisée est désormais mise en place sur la grande majorité des textes que l'utilisateur peut entrer sur le site. La syntaxe utilisée est celle de PmWiki, le moteur wiki que nous utilisons déjà pour les pages de documentation du site. Malheureusement la structure de PmWiki interdisant son utilisation comme une bibliothèque (en gros il ne fournit pas de fonction wikiToHtml, comme le fait par exemple Dotclear), il a fallu réimplémenter un nouveau moteur wiki léger.

Cette syntaxe wiki permet la plupart des formatages attendus : gras, italique, couleur, soulignement, listes, titres et tailles, liens hypertextes. On conserve également un url-catcher qui permet à l'utilisateur qui n'a pas envie de prendre le temps de formater son annonce d'avoir tout de même les URL transformées en lien.

La syntaxe wiki est utilisable :

pour le formulaire d'envoi de mail
pour les champs "freetext" de la fiche (CV et Commentaires)
pour l'édition d'annonces (pour la page d'accueil et pour la lettre mensuelle)
...

Amélioration des annonces

Comme indiqué dans le paragraphe précédent, les annonces bénéficieront d'une syntaxe wiki qui permet de formater l'annonce (ce qui n'était jusqu'à présent faisable que par les administrateurs du site, en éditant directement le code HTML de l'annonce). Mais ce n'est pas la seule amélioration. L'amélioration du système d'annonce de Polytechnique.org était un des points les plus importants que j'avais annoncés dans un précédent billet.

Classement des annonces

Au lieu d'avoir toutes les annonces dans un ordre incompréhensible qui ne permet pas de distinguer les nouvelles des anciennes, les annonces seront désormais classées selon leur date d'arrivée, leur date de péremption et leur importance. Ce classement est 'très' fortement inspiré du classement utilisé sur Frankiz (le portail des élèves de l'X). L'ordre de traitement (en first-match) est le suivant :

si une annonce est marquée comme importante, elle va dans la catégorie du même nom.
si une annonce a été validée (et non postée) il y a moins de 48 heures, elle est dans "Nouvelles annonces"
si une annonce périme dans moins de 48 heures, elle est dans "Bientôt fini"
toutes les autres annonces sont dans "Mais encore..."

Une image par annonce...

Les annonces autorisent désormais l'ajout d'une image qui illustre l'annonce ou le groupe qui a posté l'annonce. Pour le design, nous sommes cette fois plus proche de ce qui est fait sur le site de l'AX : l'image est placée sur le côté de l'annonce, ce qui permet de limiter l'espace inutilisé. Moins il y a de vide, plus on a de chance que les utilisateurs aillent lire le contenu sans trop "scroller", ce qui est à mon avis mieux pour la lisibilité des annonces.

Discussion

Enfin la dernière grande nouveauté est l'ajout de la notion de discussion. Lorsqu'une annonce est validée, elle est automatiquement postée sur un newsgroup (grâce à banana et l'annonce elle-même contient un lien vers ce post. Je suis curieux de voir à quel point cela va fonctionner (j'ai tendance à penser que ce sera encore une fonctionnalité inutilisée... en tout cas pendant les premiers mois) mais en tout cas c'est avant tout un début vers une meilleure interactivité entre les utilisateurs.

Recherche par proximité sonore généralisée

Une autre nouveauté dont j'ai déjà parlé dans un billet précédent. Alors qu'auparant la recherche par proximité sonore était limitée à la recherche avancée et n'était pas toujours correcte, la nouvelle étant la possibilité à la recherche rapide (selon le choix de l'utilisateur évidemment) et devrait être (je l'espère) plus efficace qu'auparavant grâce au nouvel algorithme de soundex conçu pour mieux s'adapter à la langue française.

Le seul moyen de se faire une idée est de tester sur le site ou de tester l'algorithme.

Les forums et les Mailing-Lists en RSS

La prochaine version de plat/al intégrera Banana 1.6 dont l'innovation majeure est l'ajout de flux RSS pour les forums. Je ne m'étendrais pas sur le sujet étant donné qu'il y a déjà un billet à ce sujet. Mais les forums ne sont pas les seuls à se doter d'un flux RSS avec cette nouvelle version, c'est également le cas des pages de documentation. Ainsi il sera possible de suivre les modifications de la documentation (ce qui sera principalement utile pour les administrateurs du site).

Mais aussi... en vrac

Les versions précédentes du site offraient la possibilité d'ajouter l'annuaire de Polytechnique.org aux moteurs de recherche de Firefox. Désormais ce sera aussi possible de le faire dans Internet Explorer 7 et dans tous les navigateurs qui supportent le format OpenSearch.

L'ajout d'un nouveau module pour faire des sondages. Ce module est encore en développement et n'est pas actuellement accessible sur le site de développement, mais il devrait être intégré à la prochaine version du site. Les sondages étaient la seule fonctionnalité du site perdue en octobre 2004 lorsque la première version de plat/al avait replacé l'ancienne version du site. C'est un outil très attendu que nous sommes heureux de retrouver grâce au travail de pika.

Et il y a encore d'autres nouveautés, ainsi qu'un grand nombre de corrections de bugs.

Venez tester !

N'hésitez donc pas à venir nous aider à tester toutes ces nouvelles fonctionnalités. Pour ceci il suffit d'avoir un compte sur Polytechnique.org (donc d'être un X) et d'aller sur :

Le site de test de Polytechnique.org pour tester le site principal
le site de test de Polytechnique.net pour tester le site des groupes

La liste de diffusion des testeurs est également ouverte à toutes les bonnes volontés et permet de discuter simplement les bugs et de l'avancement des corrections.

Deux approches...

Florent Bruneau — Wed, 28 Mar 2007 00:52:00 +0200

Les deux APIs avec lesquelles j'ai eu le plus la chance de travailler sont celle de Qt et celle de PHP... il n'y a pas à dire, entre ces deux bibliothèques, c'est comme le jour et la nuit.

L'API de Qt est intuitive et est conçue pour l'être. Si je veux avoir l'âge du capitaine, je ferais toujours capitaine->age(), et si je veux définir son âge, ce sera capitaine->setAge(42). Cette API est tellement prévisible qu'au bout de quelques jours d'utilisation, on n'utilise la documentation que pour chercher de nouvelles fonctionnalités, mais très rarement pour chercher des fonctions courantes. En plus, ce qui est remarquable, c'est qu'au fur et à mesure des versions de Qt, l'accent est mis sur la simplification de l'API... Qt 4 est bien plus intuitive que Qt 3 qui est pourtant déjà très facile à utiliser.

La qualité de la documentation de Qt y est également pour quelque chose : toutes les méthodes sont documentées, avec la plupart du temps un exemple. Le tout étant très facilement accessible grâce à l'assistant, un petit programme qui permet de consulter la documentation en intégrant des outils pour naviguer simplement entre les pages.

Par contre, je ne sais pas pourquoi, mais en PHP, l'API est incohérente... l'exemple le plus simple est sans doute celui du remplacement et de la recherche dans une variable. Si, par exemple, je veux rechercher un élément :

[php]
//Dans une chaîne de caractères :
strpos($string, $findme);
//Dans un tableau, c'est l'inverse :
in_array($findme, $array);
array_search($findme, $array);

Si je veux faire un remplacement dans une chaîne de caractères :

[php]
strtr($string, $search, $replace);
str_replace($search, $replace, $string);
preg_replace($search, $replace, $string);

Chic ! Grâce à ça, même si je connais le nom de la fonction à utiliser, je suis quasiment forcé à chaque fois d'aller regarder dans la documentation de PHP (ce que j'ai fait pour écrire ce paragraphe, sinon j'aurais 'forcément' inversé les arguments)... heureusement que celle-ci est bien faite et permet de trouver rapidement les fonctions dont on connaît le nom.

Quand est-ce que PHP se décidera à revoir son API pour qu'elle soit aussi intuitive que celle de Qt ? Malheureusement, sans doute jamais : il faut garder (autant que possible) la compatibilité avec les versions précédentes de PHP. Dommage, parce qu'à mon avis, si PHP continue à étoffer son API sans la rendre cohérente, sa popularité va diminuer progressivement dans les années qui viennent.

Joie ! (bis)

Florent Bruneau — Wed, 21 Mar 2007 20:19:00 +0100

Voilà, la nouvelle version de khtmld vient d'être releasée...

Vous pouvez consulter la page principale du projet.

Soundex Français

Florent Bruneau — Thu, 15 Mar 2007 18:06:00 +0100

Pour faire une recherche phonétique, on utilise souvent ce qu'on appelle une transcription soundex des mots. C'est une réécriture du mot, dans un alphabet restreint et sur un nombre de caractères restreint également. La plupart des algorithmes qu'on peut trouver sur internet sont conçus uniquement à la langue anglaise. Pour utiliser la recherche phonétique en français, il faut donc adapter cet algorithme.

L'implémentation française la plus courante utilise l'algorithme décrit par Frédéric Brouard. Malheureusement cet algorithme ne me satisfait pas vraiment, car il n'est finalement pas très adapté à langue française.

En effet cet algorithme a pas mal de défauts :

il est très aléatoire dans le cas de dédoublement de consonnes. Par exemple, il ne permet de trouver que bananne (soundex BNN) est une approximation de banane (soundex BN)
il est très peu sélectif sur les voyelles. Par exemple poulpe et palpa ont le même soundex (PLP) alors que pour moi, poulpe et palpa sont deux mots éloignés, malgré leur consonnes communes. Par contre, il ne reconnaîtra pas Aymeric (soundex AYMR) comme étant un homophone de Emeric (soundex EMRC)...
il n'est pas vraiment capable de distinguer les conjugaisons. Par exemple palper (soundex PLPR) et palpé (soundex PLP) sont éloignés l'un de l'autre.

J'ai donc réalisé une nouvelle implémentation de soundex qui est plus adaptée (à mon sens) à la langue française. Je n'ai évidemment pas pour ambition de réaliser une solution parfaite (ce qui est impossible à faire à partir d'un système automatisé sans dictionnaire).

Algorithme

Mon algorithme, comme je l'ai déjà dit, est une adaptation de celui de Frédéric Brouard. Il se compose de 2 étapes principales :

le préformatage, qui consiste à transformer le chaîne de caractère brute, en une chaîne analysable.
l'analyse de la chaîne, et la recherche de entités phoniques élémentaires qui la composent

Préformatage

Le préformatage est extrêmement simple :

On converti la chaîne en majuscule
On converti chaque caractère accentué vers son caractère non-accentué correspondant
On filtre pour ne conserver que les lettres (de A à Z)

Ainsi après ce premier filtrage, Mac-Cartney devient MACCARTNEY et palpé sera PALPE

Traitement des données

Le traitement des données consiste à reconnaître les sonorités. Pour ceci on utilise la table de conversion suivante qui associe à chaque sonorité complexe un caractère :

Combinaison	Caractère
G (prononcé GUE), C (prononcé Q), CK, K, QU, Q	K
CH, SH, SCH	9
ST	T
PF (en début de mot), PH	F
Z (en fin de mot)	ZE
Z, ZZ, C (prononcé SE)	S
G (prononcé JE)	J
EAU, AU	O
IN, UN, AIN, EIN (proncés UN)	1
AON, AOM, EN, AN (prononcés EN)	A
EY, EI, AY, AI, OE, OEU, EU, ER	E
OI	O
ILLE, I	Y
OU, OW	U
ON, OM	O
KN (en début de mot)	N

Une fois qu'on a cette table de correspondances (elle n'est peut-être pas exhaustive... je n'hésiterais pas à l'améliorer), on applique toutes les modifications, on supprime les lettres qui sont présentes en doublon et finalement on supprime les H restants. Il faut également supprimer les caractères muets en fin de mot. En français, ce seront les X, T, D, S (et le L qui les précède si il existe) ou les E.

Ensuite, il faut faire un nettoyage sur la chaîne de caractère. Ce nettoyage consiste à rechercher les phonèmes importants et à supprimer les caractères muets ou peu audibles : on veut identifier ce qui fait la particularité d'une syllabe. Frédéric Brouard considère que toutes les voyelles (exceptés les Y précédés d'une voyelle) placées autre part qu'en début de mot sont insignifiantes... ça me paraît le gros point faible de sa méthode. Personnellement j'ai essayé d'identifier une liste de sonorité dominantes. Voici celles que j'ai actuellement :

Sonorité	Informations
K, T, P	Ce sont les consonnes qui sont très marquées, qui rythment le mot
A, U, O, 1	Ce sont les son qu'on entend le mieux, contrairement aux I ou aux E qui mettent plus en avant les consonnes. Le A est à mon avis particulier, car il est faible mais suffisamment marquant pour effacer des consonnes comme le R
Y	Y n'est marquant que lorsqu'il a un rôle de consonne : quand il permet de lier deux parties du mot, comme dans ''voyelle'', où il lie le ''vo'' et le ''elle''. Il est donc important lorsqu'il est encadré par une ou des voyelles. Dans les autres cas, c'est une voyelle faible
L	Contrairement aux K, T et P, le L permet d'adoucir le mot, en particulier lorsqu'il sert de liaison entre une consonne et une voyelle. Il est donc important de le conserver

Ces choix sont relativement arbitraires. Le comportement de l'algorithme est alors simple :

Si une voyelle est liée à une consonne de liaison (qui fait le lien entre la voyelle et une autre consonne, c'est souvent le cas du L ou du R, on exclut de ce cas les consommes fortes)
Si en plus il s'agit d'une voyelle forte
- alors, on supprime la consonne de liaison et on garde la voyelle

Ensuite, on supprime les voyelles faibles (sauf si elles commencent le mot). Pour cette suppression, on considère le A comme une voyelle faible.

Pour terminer on coupe la chaîne obtenue à 4 caractères (mais il est parfaitement envisageable de prendre un soundex sur plus (ou moins) de caractères. Simplement, dans la plupart des cas, 4 caractères suffisent amplement à avoir un mot significatif.

Implémentation

Mon implémentation en PHP est téléchargeable ici. Elle est testable plus bas dans cette même page. Voici le code de la fonction soundex_fr (je ne garantis pas que le code disponible sur cette page reste constamment à jour, contrairement au lien de téléchargement) :^[1]

[php]
function soundex_fr($sIn) 
{ 
    static $convVIn, $convVOut, $convGuIn, $convGuOut, $accents; 
    if (!isset($convGuIn)) { 
        $accents = array('É' => 'E', 'È' => 'E', 'Ë' => 'E', 'Ê' => 'E', 
                    'Á' => 'A', 'À' => 'A', 'Ä' => 'A', 'Â' => 'A', 'Å' => 'A', 'Ã' => 'A', 
                    'Ï' => 'I', 'Î' => 'I', 'Ì' => 'I', 'Í' => 'I', 
                    'Ô' => 'O', 'Ö' => 'O', 'Ò' => 'O', 'Ó' => 'O', 'Õ' => 'O', 'Ø' => 'O', 
                    'Ú' => 'U', 'Ù' => 'U', 'Û' => 'U', 'Ü' => 'U', 
                    'Ç' => 'C', 'Ñ' => 'N', 'Ç' => 'S', '¿' => 'E', 
                    'é' => 'e', 'è' => 'e', 'ë' => 'e', 'ê' => 'e', 
                    'á' => 'a', 'à' => 'a', 'ä' => 'a', 'â' => 'a', 'å' => 'a', 'ã' => 'a', 
                    'ï' => 'i', 'î' => 'i', 'ì' => 'i', 'í' => 'i', 
                    'ô' => 'o', 'ö' => 'o', 'ò' => 'o', 'ó' => 'o', 'õ' => 'o', 'ø' => 'o', 
                    'ú' => 'u', 'ù' => 'u', 'û' => 'u', 'ü' => 'u', 
                    'ç' => 'c', 'ñ' => 'n'); 
        $convGuIn  = array( 'GUI', 'GUE', 'GA', 'GO', 'GU', 'SCI', 'SCE', 'SC', 'CA', 'CO', 
                            'CU', 'QU', 'Q', 'CC', 'CK', 'G', 'ST', 'PH'); 
        $convGuOut = array( 'KI', 'KE', 'KA', 'KO', 'K', 'SI', 'SE', 'SK', 'KA', 'KO', 
                            'KU', 'K', 'K', 'K', 'K', 'J', 'T', 'F'); 
        $convVIn   = array( '/E?(AU)/', '/([EA])?[UI]([NM])([^EAIOUY]|$)/', '/[AE]O?[NM]([^AEIOUY]|$)/', 
                            '/[EA][IY]([NM]?[^NM]|$)/', '/(^|[^OEUIA])(OEU|OE|EU)([^OEUIA]|$)/', '/OI/', 
                            '/(ILLE?|I)/', '/O(U|W)/', '/O[NM]($|[^EAOUIY])/', '/(SC|S|C)H/', 
                            '/([^AEIOUY1])[^AEIOUYLKTPNR]([UAO])([^AEIOUY])/', '/([^AEIOUY]|^)([AUO])[^AEIOUYLKTP]([^AEIOUY1])/', '/^KN/', 
                            '/^PF/', '/C([^AEIOUY]|$)/',  '/E(Z|R)$/', 
                            '/C/', '/Z$/', '/(?<!^)Z+/', '/H/', '/W/'); 
        $convVOut  = array( 'O', '1\\3', 'A\\1', 
                            'E\\1', '\\1E\\3', 'O', 
                            'Y', 'U', 'O\\1', '9',- 
                            '\\1\\2\\3', '\\1\\2\\3', 'N', 
                            'F', 'K\\1', 'E', 
                            'S', 'SE', 'S', '', 'V'); 
    } 
    // Si il n'y a pas de mot, on sort immédiatement
    if ( $sIn === '' ) return '    '; 
    // On supprime les accents- 
    $sIn = strtr( $sIn, $accents); 
    // On met tout en minuscule- 
    $sIn = strtoupper( $sIn ); 
    // On supprime tout ce qui n'est pas une lettre
    $sIn = preg_replace( '`[^A-Z]`', '', $sIn ); 
    // Si la chaîne ne fait qu'un seul caractère, on sort avec.
    if ( strlen( $sIn ) === 1 ) return $sIn . '   '; 
    // on remplace les consonnances primaires
    $sIn = str_replace( $convGuIn, $convGuOut, $sIn ); 
    // on supprime les lettres répétitives 
    $sIn = preg_replace( '`(.)\\1`', '$1', $sIn ); 
    // on réinterprète les voyelles 
    $sIn = preg_replace( $convVIn, $convVOut, $sIn); 
 
    // on supprime les terminaisons T, D, S, X (et le L qui précède si existe)
    $sIn = preg_replace( '`L?[TDX]?S?$`', '', $sIn ); 
    // on supprime les E, A et Y qui ne sont pas en première position 
    $sIn = preg_replace( '`(?!^)Y([^AEOU]|$)`', '\\1', $sIn); 
    $sIn = preg_replace( '`(?!^)[EA]`', '', $sIn); 
    return substr( $sIn . '    ', 0, 4); 
}

Tests

Avec cette implémentation, on a par exemple :

Mot	Soundex	Mot	Soundex
Aymeric	EMRK	Emeric	EMRK
Banane	BNN	Bananne	BNN
Palper	PLP	Palpé	PLP
Palpa	PLP	Poulpe	PULP
Mario	MRYO	Marion	MRYO

On a par contre des résultats moyens lorsque des H séparent des voyelles faibles : par exemple Mouahaha donne MU (contre M avec la version précédente).

N'hésitez pas à faire des tests et à me faire part des résultats qui semblent anormaux.

Conclusion

Cette version est loin d'être parfaite, mais elle est plus adaptée au français que celle de Frédéric Brouard. Elle n'est d'ailleurs pas terminée et risque d'évoluer dans un futur proche, en particuliers pour ce qui est des tables de transcriptions et de prédominances.

Notes

[1] L'algorithme prend en compte les modifications fournies par les lecteurs et dont vous retrouverez le détail dans les commentaires. Merci donc aux commentateurs, et particulièrement à David

Démon pour khtml2png

Florent Bruneau — Wed, 14 Mar 2007 18:24:00 +0100

Une fois qu'on a un outils pour faire les vignettes de site, il devient utile de pouvoir automatiser le travail. Pour ceci, il existe un démon pour khtml2png. Malheureusement (encore une fois), cet outil ne correspondait pas exactement à mes besoins. Donc je l'ai partiellement réécrit (mais rien d'extraordinaire).

Ce démon qui s'appelle khtmld fonctionne simplement : il lit une file et à chaque entrée dans cette file, il lance khtml2png. Donc, il y a deux étapes.

La première consiste à lancer le démon. Pour ceci, j'ai développé un script d'init... qui sera donc probablement lancé par l'utilisateur root. Il suffit de modifier ce script pour régler les variables en fonction de son installation, puis dans lancer la commande :

[bash]
./init-script.sh start

Ensuite il n'y a plus qu'à donner au démon la liste des actions à réaliser sous la forme^[1] :

[bash]
echo "url fichier" >> /tmp/khtmld.spool

Le principal développement que j'ai réalisé sur khtmld permet de donner au processus de khtml2png les droits d'un utilisateur du choix de la personne qui a lancé le démon (certes rien d'extraordinaire, mais ça manquait au programme).

Voilà, donc un système pour automatiser la réalisation de vignettes même si il reste quelques points sur lesquels il faut réfléchir :

on ne veut pas un service ouvert (faire un screenshot est une opération lourde)
on ne peut pas mettre ce service sur un serveur de prod (il est hors de question de lancer un X en production)

Donc il faut s'orienter sur la réalisation d'un serveur de screenshot avec authentification et modération... non-trivial.

Pour ceux qui voudraient récupérer ma version, elle est disponible dans les téléchargements.

Notes

[1] Attention à ne pas mettre d'espace dans le nom du fichier et dans l'url.

Outils pratiques

Florent Bruneau — Tue, 13 Mar 2007 19:21:00 +0100

Etant donné que je travaille énormément avec SVN. C'est un outils très addictif... à tel point que je l'utilise dès que je travaille sur un projet (seul ou à plusieurs), je crée un reposoire pour le projet (c'est un excellent moyen de ne pas perdre son travail suite à une fausse manoeuvre). Comme en plus je ne supporte pas les front-end pour SVN, je travaille toujours en ligne de commandes...

Pour pouvoir améliorer la sortie des commandes SVN dans mes consoles, j'ai fait surchargé la commande svn par une fonction zsh :

[bash]
function svn() {
    if [[ $1 == "ci" || $1 == "commit" || $1 == "propedit" || $1 == "propset" || $1 == "help" ]]; then
        /usr/local/bin/svn $*
    elif [[ $1 == "preci" || $1 == "precommit" ]]; then
        /usr/local/bin/svn status | grep -v '?' | ~/.zsh/zshcolorsvn
    else
        /usr/local/bin/svn $* | ~/.zsh/zshcolorsvn
    fi
}

Cette fonction est donc très simple :

si la commande nécessite un interaction de l'utilisateur, on appel directement le programme svn (le cas de help permet de ne pas casser la tab-completion de zsh)
sinon on envoi la sortie de svn dans un script qui réalise sa coloration syntaxique

Ceci donne un résultat de la forme suivante :

C'est donc extrêmement pratique ; ça permet de distinguer facilement les modifications, ça permet aussi de voir d'un seul coup d'oeil les conflits et la liste des fichiers modifiés. En plus ça fonctionne également avec des commandes comme cvs ou diff :

[bash]
# SVN
function svn() {
    if [[ $1 == "ci" || $1 == "commit" || $1 == "propedit" || $1 == "propset" || $1 == "help" ]]; then
        /usr/local/bin/svn $*
    elif [[ $1 == "preci" || $1 == "precommit" ]]; then
        /usr/local/bin/svn status | grep -v '?' | ~/.zsh/zshcolorsvn
    else
        /usr/local/bin/svn $* | ~/.zsh/zshcolorsvn
    fi; fi
}

# SVN avec conversion de la sortie en latin1
function svn_utf8() {
    if [[ $1 == "ci" || $1 == "commit" ]]; then
        svn $*
    else
        svn $* | iconv -f utf8 -t iso-8859-1
    fi
}

function cvs() {
    if [[ $1 == "diff" ]]; then
        shift 1
        /usr/bin/cvs diff -ubN $* 2> /dev/null | ~/.zsh/zshcolorsvn
    elif [[ $1 == "ci" || $1 == "commit" || $1 == "propedit" || $1 == "propset" || $1 == "help" ]]; then
        /usr/bin/cvs $*
    else
        /usr/bin/cvs $* 2> /dev/null | ~/.zsh/zshcolorsvn
    fi;
}

function diff() { /usr/bin/diff -u $* | ~/.zsh/zshcolordiff }

Les scripts nécessaires sont disponibles : zshcolorsvn et zshcolordiff

Seul défaut : pour pouvoir utiliser les commandes sans coloration... il faut taper chemin complet.

Joie !

Florent Bruneau — Tue, 13 Mar 2007 12:41:00 +0100

Mon travail sur khtml2png vient d'être releasé (version 2.6.0) par Hauke (le programmeur principal du projet). Cette version corrige tous les bugs dont j'ai pu parler dans mes précédents billets :

Des failles de sécurité
Problème de bandes grises si X n'est pas assez grand
Blocage du programme en cas de popup

Elle supprime la dépendance à ImageMagick (ce qui permet au passage de simplifier le code). Ainsi, mon code permettait de passer de 600 lignes à 320 lignes, avec le travail de Hauke au dessus (principalement de l'alignement de code), le fichier source fait 390 lignes...

A croire que certains le font exprès !

Florent Bruneau — Sat, 10 Mar 2007 19:57:00 +0100

Depuis trois jours, je travaille sur la mise ne place d'un outil permettant de faire des aperçus graphiques de site web (des vignettes façon Exalead par exemple). C'est une fonctionnalité très à la mode... et c'est aussi un bon moyen d'avoir un aperçu d'un site. Donc dans ce cadre, j'ai commencé à travailler sur khtml2png. Malheureusement, comme il ne correspondait pas exactement à mes besoins, j'ai commencé à en modifier le code source... et j'ai eu quelques surprises !

Strings

Ma première (mauvaise) surprise a été de constater que le code était loin d'être propre. Il s'agit d'un programme écrit avec la bibliothèque Qt (KHTML oblige), et pourtant la gestion des chaînes de caractère est faite pour moitié avec QString, pour moitié avec l'API C... sans vérification de la taille des buffers.

Par exemple :

[cpp]
QString filename = "/tmp/khtml2png.png";
int g = sprintf(nrStr,"_x%iy%i",xNr,yNr);
nrStr[g]='\\0';
filename+=QString(nrStr);

Quitte à utiliser l'API C autant le faire proprement, en vérifiant la taille du buffer (dans le cas présent, le buffer nrStr avait une taille de 10)... mais en plus pourquoi faire ça de cette manière alors que Qt fournit l'API suffisant pour coder ces 4 lignes sans le moindre risque de buffer overflow ?

// cpp QString filename = QString( "/tmp/khtml2png.png_x%1y%2").arg(xNr).arg(yNr); //

Ensuite (toujours dans la gestion des chaînes de caractères), la méthode pour éviter le buffer overflow était le "Je fais un gros buffer, au moins je suis sûr que ça ne débordera pas"... mais le problème, c'est que ça peut déborder !

[cpp]
char 	[5000], //command line string

memset(cmd,0,sizeof(cmd));

//append the row images from top to bottom to one image
strcpy(cmd,"convert ");

for (int y=0; y < yNr; y++)
    sprintf(cmd,"%s /tmp/khtml2png.png_r%i",cmd,y);
		
sprintf(cmd,"%s -append %s",cmd,args->arg(1));
system(cmd);

Dans ce cas précis, args->arg(1) est contrôlé par l'utilisateur (c'est en fait le fichier destination de la capture demandée... le sprintf est donc une erreur impardonnable... sans compter qu'en plus cet argument qui est passé à un exécutable externe sans le moindre check sur le contenu de la chaîne. On risque non seulement le buffer overflow, mais également l'injection de code dans le system (par exemple, je peux appeler mon fichier fichier;sh, ça me lancera un shell avec les droits de l'utilisateur qui a lancé le programme.

Une solution (non testée) pourrait être :

[cpp]
QProcess process("convert");
for (int y=0 ; y < yNr ; y++) {
    process.addArgument(QString("/tmp/khtml2png.png_r%i").arg(y);
}
process.addArgument("-append");
process.addArgument(args->arg(1));
process.start();
while (process.isRunning()) {
    wait(10); // nombre choisi aléatoirement
}

Cette solution a le mérite :

d'être safe car elle ne permet pas d'injecter des commandes dans notre code
d'être safe car elle ne permet pas de buffer overflow

Bien sûr ceci repose sur la confiance qu'on peut avoir en Qt...

Images

Pour générer le screenshot, khtml2png fait plusieurs captures dans une fenêtre en scrollant à l'intérieur de manière à recouvrir une zone aillant la taille demandée par l'utilisateur. C'est très bien... malheureusement, encore une fois je me demande quel est l'intérêt d'utiliser Qt dans le cas présent. La technique de khtml2png (version 2.5.0) est de faire une capture d'écran à chaque fois... puis de la stocker dans un fichier temporaire indexé avec le numéro du morceau en X et en Y.

Une fois tous les morceaux obtenus, le programme utilise convert de ImageMagick pour coller les morceaux de chaque ligne, puis une deuxième fois (enfin, ce n'est pas la deuxième fois, mais la deuxième boucle) pour coller les différentes lignes et convertir dans le format voulu (c'est en fait le dernier morceau de code que j'ai collé ci-dessus).

Pourquoi faire si compliqué ?

On ne peut pas lancer deux fois khtml2png en même temps (le programme utilisant toujours le même nom pour les fichiers temporaires)
Qt aussi est capable d'enregistrer les fichiers dans différents formats... pas besoin de ImageMagick pour ça
khtml2png dépend d'un programme extérieur qu'il n'est pas certain de trouver sur les machines des utilisateurs...

Ma technique est beaucoup plus simple, ne nécessite de lancer aucun programme externe... et en plus se révèle plus légère en quantité de mémoire (parce que j'utilise des pointeurs au lieu de recopier les images dans tous les sens en en créant plusieurs instances à chaque fois)

tout d'abord je crée une image vierge de la taille voulue par l'utilisateur
je fais les captures du site et au lieu de les stockers dans un fichier, je les colle au bon endroit dans mon image
j'utilise Qt pour enregistrer l'image au format désiré par l'utilisateur (en fonction de l'extension)...

Ainsi, j'ai supprimé la totalité du code qui utilisait des traitements de chaînes de caractères (qui n'étaient autres que les appels à convert), ce qui supprime toutes les failles dont j'ai parlé ci-dessus... en gardant les mêmes fonctionnalités que la version publique du programme.

Besoins particuliers

J'ai également rencontré un besoin qui a mon avis n'était pas prévu par les développeurs du programme : étant donné que je le fais tourner dans un environnement graphique inaccessible (en fait dans un vncserver), je ne vois pas ce qu'il se passe. Or, KHTML déclenche automatiquement une boîte de dialogue modale dès qu'il rencontre un objet d'un type mime inconnu... dans mon cas il s'agissait d'un applet active-x qui traîne sur le site de l'Ecole Polytechnique.

J'ai donc cherché pendant 2 jours comment contourner le programme : il me faut pouvoir avoir accès à la boîte de dialogue créée, et la supprimer puisque l'API de KHML ne permet pas de désactiver ces intrusions directement depuis le programme.

Tout d'abord j'ai cru qu'en réimplémentant la méthode showError ça marcherait... mais en fait non, elle n'est pas appelée dans le cas présent, c'est uniquement généré à l'intérieur du moteur KHTML... la classe KHTMLPart n'est jamais notifiée de l'apparition de cette boîte de dialogue.

J'ai donc cherché qui pouvait bien être le père de ce QMessageBox... et en fait, c'est le KHTMLPart::view(). N'ayant pas vraiment la possibilité de substituer à cet objet, un objet de mon choix, j'ai ajouté un eventFilter qui filtre les messages reçus par la fenêtre de rendu... et lorsque apparaît un QDialog (classe mère de QMessageBox), je me charge directement de le rendre non modal, de le découpler du view et de le détruire)... et là, victoire !!!

Je comprends parfaitement que les développeurs n'aient pas pensé que ces boîtes de dialogues puissent être gênantes car ils doivent travailler dans un environnement graphique et les voir... moi non ! Mais en fait, ce que je comprends moins bien c'est qu'ils ont clairement déjà rencontré le problème dans le cadre de la réalisation du screenshot. En effet, on y trouve le code (pour sélectionner les fenêtres-filles qui méritent d'apparaître dans le screenshot) :

[cpp]
if ( child->isWidgetType() &&
    ((QWidget *)child)->geometry().intersects( w->rect() ) &&
    ! child->inherits( "QDialog" ) ) {

Les développeurs ont donc déjà rencontré des QDialog... pourquoi ne pas déjà les avoir désactivés ?

Conclusion

J'ai donc maintenant un khtml2png adapté à mes besoins. Je vais soumettre mon code aux développeurs du projet.

À savoir qu'à l'heure actuelle (et je n'ai pas fini le nettoyage), mon code fait 80 lignes de moins que le code dont je suis parti... et ce malgré l'ajout de fonctionnalités.

Télécharger la dernière version

Polytechnique.org en retard ?

Florent Bruneau — Thu, 01 Mar 2007 16:28:00 +0100

Polytechnique.org est, comme l'indique le nom du logiciel OpenSource sur lequel le site repose (plat/al), une plateforme pour les anciens élèves de l'École... c'est à dire que Polytechnique.org devrait :

apporter de la vie dans la communauté
faciliter les mises en relation entre les membres
offrir des services à la communauté

Polytechnique.org offre ces trois services... mais pourtant moins d'un utilisateur sur 5 se connecte régulièrement au site (une fois par semaine - et le plus souvent c'est pour accéder à des sites qui utilisent l'authentification de Polytechnique.org), environ un sur 3 se connecte une fois par mois, et un sur 3 ne se connecte tout bonnement jamais. Face à cela, on dénombre un grand nombre d'utilisateurs qui sont intéressés par un groupe Polytechnique sur des outils comme Linked-In... pourquoi ? parce que le rôle de Polytechnique.org n'est rempli qu'à moitié et ce pour plusieurs raisons :

Ergonomie

La catastrophe sur Polytechnique.org c'est l'ergonomie... ce n'est certes pas la fin du monde (on peut encore s'y retrouver), mais le site ne donne pas envie de s'y arrêter. Je vais essayer de détailler les divers problèmes :

Le menu

Le menu de Polytechnique.org témoigne de la richesse du site : il est long. Comme tout menu, il a fallu choisir l'ordre des entrées. Le choix de cet ordonnancement laisse clairement à désirer. Par exemple : où chercher un lien vers l'annuaire ? Dans Services ou Communauté X ? Etant un utilisateur du site depuis longtemps, je mets toujours autant de temps avant de trouver ce que je cherche dans le menu.

Peut-être devrions-nous revoir tout bonnement l'organisation du menu, par exemple avec des catégories plus parlantes, par exemple un premier jet pourrait donner (mais ça mérite d'être travaillé) :

Mes emails
- Mes redirections
- Mes abonnements
- Antispam
Annuaire
- Rechercher
- Mon profil
Communauté
- Annonces
- Lettre mensuelle
- Discussions
Emploi

Deux sites séparés

Polytechnique.org c'est aussi Polytechnique.net : le site des groupes. Le fait d'avoir 2 sites totalement séparés pose un grand nombre de problème, depuis le partage de l'authentification, jusqu'à la cohérence des données.

Il faut clairement envisager de fusionner les deux sites dans un avenir plus ou moins proche si on veut que les utilisateurs s'y retrouvent. De la même manière qu'on peut réorganiser le menu, on peut réorganiser l'accès général au site... Par exemple, on pourrait envisager de créer un menu tabulé : dans chaque tab, on retrouve un menu spécifique. Par exemple, on pourrait, au lieu d'avoir un menu à deux niveaux, des tabs (Mes emails, Annuaire, Annonces...) et dans chaque tabs un menu spécifique donnant accès aux fonctionnalités correspondantes.

Avantages : On aurait ainsi un proprement rangé... le site étant modulaire, chaque module pourrait lui même générer ses entrées dans les menus/tabs, l'intégration des Polytechnique.net à Polytechnique.org ne serait que l'ajout d'un tab "Mes groupes X"
Défauts : On a pas d'accès facile à l'ensemble des fonctionnalités... c'est le seul défaut (pas des moindres) que je vois.

C'est une solution qui mérite qu'on s'y intéresse... le choix de la meilleur ergonomie possible nécessitera de toute façon des tests.

Dinosaure

Toutes les skins de Polytechnique.org sont carrées... En particulier la skin par défaut a très mal vieilli. Les polices y sont énormes, toutes les informations sont dans des boîtes carrées. Le site à sérieusement besoin d'une petite cure de jouvence pour retrouver un design aguichant.

Web 2.0

Dire que son site est Web 2.0 est à la mode... Polytechnique.org ne l'est pas vraiment, et ceci pour diverses raisons.

La pointe de la technologie

Tout d'abord le site est trop statique. Quand la page d'accueil est chargée, elle est chargée... à la rigueur on peut fermer quelques boites mais c'est tout. Le site est statique... Le Web actuel s'ouvre vers des pages vivantes avec lesquels l'utilisateur peut interagir... Le plus souvent cela repose sur des technologies du type Ajax. Polytechnique.org utilise un peu Ajax, mais on va dire que c'est artisanal... il y a un gros boulot à faire de ce côté si on veut que le site devienne un outil convivial pour l'utilisateur.

Une autre technologie qui fait le succès du web est l'édition dynamique de contenu. Polytechnique.org utilise du wiki pour l'édition de sa documentation... mais, en grande majorité, ceci se limite à la simplification du travail d'administration du site. Par contre pour tous les contenus dynamiques, nous n'offrons que du texte brut à nos utilisateurs. Là où se trouve le vrai problème, c'est sur l'outil d'hébergement que nous offrons aux groupes : Diogenes.

Diogenes a mal vieilli parce que sont apparus face à lui des outils plus simples à utiliser. Aujourd'hui Diogenes mérite un gros décrassage si on veut pouvoir continuer à l'utiliser.

Vie sociale

Là où Polytechnique.org est le plus en retard, c'est sur les outils qui permettent de donner vie à la communauté. Certes nous avons nos forums, mais ils ne sont pas vraiment mis en avant sur le site... Nous n'avons en effet nulle part des liens qui permettent aux utilisateurs de commenter l'actualité de la communauté. Pour améliorer ça, nous pourrions par exemple associer à chaque annonce une discussion sur un forum dédié (discussion qui serait initiée par la publication de l'annonce en question sur le forum en plus de la page d'accueil).

Conclusion

Voilà, tout ceci un peu en vrac pour dire que nous avons des outils, de très bons outils même, largement en avance sur l'utilisation qu'en font les utilisateurs. Malheureusement nous souffrons d'un manque d'adaptation à l'utilisateur : l'utilisateur recherche avant tout un site facile à utiliser sur lequel il puisse faire ce qu'il cherche le plus rapidement possible.

Il est nécessaire de réorienter fortement le développement vers l'ergonomie dans les mois qui viennent : à terme il faudrait que les utilisateurs puissent utiliser Polytechnique.org comme une page d'accueil conviviale offrant des services tels qu'on en trouve couramment sur les principaux portails (recherche Internet, outils de gestion PIM...) tout en offrant les services de base d'une plateforme pour alumnis.

Un client RSS pour lire les Forums NNTP et les Mailing-Lists...

Florent Bruneau — Sun, 25 Feb 2007 19:05:00 +0100

Si il y a un bout de code dont je suis content au sein de Polytechnique.org, c'est Banana. Banana est à l'origine un client Web pour le protocole NNTP (c'est à dire le protocole utilisé par Usenet). Depuis sa dernière version (la 1.5), Banana est capable d'utiliser n'importe quel protocole comme source (les protocoles actuellement implémentés étant le NNTP et la lecture de MBox, mais on pourrait envisager d'ajouter le support des Maildir ou d'IMAP sans problème), ainsi, à Polytechnique.org, nous utilisons Banana pour offrir une plateforme Web vers nos forums et pour mettre en ligne les archives des Mailing-Lists que nous hébergeons.

Banana est à mon avis un bon outils : il permet un rendu plus que correct de la plupart des mails HTML (même ceux dont le formatage est défini dans une feuille de style), il affiche les discussions proprement et rapidement (grâce à un système de cache du côté serveur). C'est donc un gros plus en comparaison des interfaces habituelles de consultation d'archives de Mailing-List qu'on peut trouver sur Internet... et puis, ce n'est pas un forum php, pas de fioritures à la phpbb : Banana est clair, lisible et rapide... et facile à installer. Pour s'en convaincre, il suffit de regarder la fichier d'exemple qui fournit un banana totalement fonctionnel (à chacun ensuite d'y ajouter sa couche d'authentification si nécessaire).

La grande nouveauté de la prochaine version de Banana est l'intégration de flux RSS... ainsi il sera possible de lire les forums sans se connecter au site et sans client news, ou de suivre les discussions des mailing-lists sans relever son courrier (le premier des 2 cas étant certainement le plus intéressant). Pour les utilisateurs de Polytechnique.org, la fonctionnalité est d'ores et déjà disponible sur ma version de développement. Deux types de flux son disponibles : soit un flux par groupe, soit un flux regroupant tous les groupes auxquels on est abonné.