Mind... - Polytechnique.org

Polytechnique.org lance son blog

Florent Bruneau — Tue, 03 Jun 2008 23:33:00 +0200

Voilà... cela fait assez longtemps que nous recevons des demandes d'utilisateurs pour la mise en place de blog via Polytechnique.org. Afin de préparer la mise en place de ce service, Polytechnique.org lance son blog. Cela permettra à la fois :

de tester l'outil d'intégration de l'authentification de Polytechnique.org dans Dotclear.
d'offrir une nouvelle plateforme souple et conviviale pour informer nos utilisateurs.

Je ne vais pas m'étendre davantage vu que ce ne serait que recopier le post d'Aymeric

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).

15 000

Florent Bruneau — Sun, 07 Oct 2007 22:32:00 +0200

Ca y est... 15 000 inscrits à Polytechnique.org.

Si l'ascension continue, nous devrions atteindre les 16 000 l'année prochaine.

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.

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.

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.

Vignette de site

Florent Bruneau — Mon, 12 Mar 2007 10:40:00 +0100

Pour continuer sur le sujet de mon billet précédent, voici une solution simple pour réaliser des vignettes de site web.

Technique

Pour faire une vignette d'un site web la solution est simple :

on lance un navigateur (c'est à dire un moteur de rendu) et on ouvre la page dont on eut le screenshot
on fait un screenshot, c'est à dire qu'on copie la fenêtre d'affichage dans une image
on fait du post-traitement sur l'image obtenue pour l'adapter à nos besoins

Donc, rien de bien compliqué... le problème est maintenant le faire de manière automatisée...

Il existe divers outils pour le faire... la plupart des sites qui fournissent des services de screenshot sur Internet font leur captures avec Internet Explorer (IE6 la plupart de temps), Exalead le fait avec un moteur KHTML, il existe des outils libres qui le font avec Gecko, avec WebKit ou KHTML.

Personnellement j'ai travaillé avec khtml2png.

Mise en place

Que ce soit la solution qui utilise Gecko, ou celle qui utilise KHTML, il est nécessaire de faire fonctionner le programme dans un serveur X, car il faut réaliser le rendu dans une fenêtre avant d'en faire une capture. Quand on a un serveur X déjà en place, ça ne pose pas de problème... mais quand on veut faire tourner ça sur un serveur, ça devient plus casse-pied. La solution la plus courante est d'utiliser un vncserver.

Le lancement du vncserver nécessite de respecter quelques contraintes :

il faut que le rendu se fasse en couleur vraies... VNC offre deux modes : 8bits et 32bits, il faut donc choisir 32bits (qui n'est pas le mode par défaut)
plus la résolution du serveur X est grande, plus on pourra faire des captures de grande taille (ou faire moins de capture si on fait du pavage). De plus, khtml2png contient un bug qui entraîne des bandes grises dans la capture si celle-ci est trop grande (par exemple, avec un serveur de 1280x960, je ne peux pas faire de capture 1024x768). C'est un problème sur lequel je vais travailler durant la semaine.^[1]

Ainsi, j'utilise la commande suivante pour lancer mon vncserver :

[bash]
vncserver :60 -geometry 1280x960 -depth 32

Ensuite, il suffit de faire tourner notre outils dans l'environnement graphique qu'on vient d'obtenir. Avec khtml2png, cela donne :

[bash]
./khtml2png2 --display :60 --nocrashhandler --width 840 --height 600 http://fruneau.rznc.net/ /tmp/test-fru.png

Les différentes options données sont :

display est une option Qt qui spécifie le serveur X sur lequel il faut faire tourner le programme. En mettant DISPLAY=":60.0" comme variable d'environnement, on devrait (je n'ai pas testé) obtenir le même résultat
nocrashhandler est une option KDE qui indique qu'on ne veut pas que KDE lance le KDE-Crash Handler en cas de plantage... celui-ci irait encombrer le serveur graphique. Etant donné qu'on a pas accès à ce serveur graphique, autant éviter de le remplir de fenêtre inutiles
width et height donne la taille du screenshot
ensuite on donne l'URL et le nom du fichier (le format est deviné à partir de l'extension)

La ligne précédente donne le résultat suivant :

Attention tout de même, la version 2.5.0 (et sans doute les précédentes) de khtml2png est bloquante dans le cas où elle rencontre un type mime non supporté par l'installation actuelle de KDE. Il vaut mieux utiliser ma dernière version qui corrige ce bug. Dans tous les cas, en installant les modules adaptés (comme flash), on obtient un meilleur rendu.

Notes

[1] Edit 12 mars à 23h40 : Ce problème est corrigé dans la toute dernière version. On peut de fait envisager d'utiliser un serveur X plus petit sans bug, le rendu reste plus rapide lorsque le serveur X est suffisamment grand.

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 premier bilan sur la sécurité...

Florent Bruneau — Tue, 27 Feb 2007 16:47:00 +0100

Sans entrer dans les détails du fonctionnement des filtres de protection de Polytechnique.org (je laisse ce plaisir à ceux qui auront le courage de lire le code de plat/al), nous avons ces derniers mois fortement amélioré les outils de surveillance. Alors qu'il y a encore un an, nous ne détections que quelques usurpations par an, nous sommes actuellement à environ une usurpation détectée par semaine.

De quoi s'inquiéter ?

Certes la fréquence des usurpations est plus importante que nous pensions mais plus on a d'outils de protection, plus on a d'usurpations... non seulement parce qu'on en détecte plus, mais aussi parce que d'une certaine manière, on provoque les usurpations. En effet, lorsque nous détectons une usurpation, nous fermons le compte. Lorsque l'usurpateur se rend compte qu'il a perdu l'accès, il usurpe (ou tout au moins tente d'usurper) un autre compte.

Ainsi, nous avions détecté un usurpateur mi-janvier. Suite à celà il s'est réinscrit une fois. Nous l'avons trouvé et nous avons redésactivé le compte... il s'est de nouveau réinscrit, mais pour une raison que je ne comprends pas, nous avons manqué cette inscription... mais finalement, il a oublié son compte, et hier il a retenté de se connecter. Mais cette fois-ci son IP était bannie, et c'est donc 2 comptes qu'il a tenté d'usurper tour à tour.

C'est donc 5 comptes pour une personne... pas mal non ? Nous n'aurions pas détecté la première de ces usurpations, il en serait resté à une seule.

De plus, la plus grande majorité des comptes usurpés sont abandonnés par leur usurpateur dans le mois qui suit l'inscription. Nous détectons donc majoritairement des comptes abandonnés. Les usurpations sont donc gênantes, mais certainement pas inquiétantes. A force de tests, nous épurons petit-à-petit la base.

Donc, je ne pense pas qu'il y ait de quoi s'inquiéter de la fréquence des usurpations et la proportion de comptes usurpés de notre base.

Sécuriser une inscription peu sélective

La faille de Polytechnique.org est la faible sélectivité de son système d'inscription. Le problème est que nous avons une base des alumnis et qu'il faut faire correspondre chaque entrée à la bonne personne physique. Il est quasiment trivial pour n'importe qui de trouver les informations nécessaire pour remplir le formulaire d'inscription... comment s'assurer que finalement il s'agit bien de la bonne personne ?

Nous avons donc plusieurs niveaux de filtrages :

Le premier consiste à vérifier autant que possible la crédibilité des informations données dans le formulaire d'inscription
Le deuxième consiste à réaliser un filtrage "humain"... il suffit de vérifier pour chaque inscription les informations de chaque inscription
Traitement comportemental. C'est le filtrage qu'il nous faut améliorer actuellement
La vérification de cohérence de la base de donnée (à partir d'idées données de temps en temps, on défini un critère d'usurpation probable, et on check)

Là où nous avons fait beaucoup de progrès, c'est sur le points 1 et 2 : nous sommes désormais en mesure de contrer la plupart des usurpations dès l'inscription alors qu'il y a quelques mois, nous n'avions que le point 4... c'est à dire des vérifications éparses.

Nos points faibles... et nos évolutions

Tout d'abord, si je me permets d'écire ce billet, c'est que je pense que nous sommes suffisamment sécurisés pour contrer les petits plaisantins qui en lisant ce texte voudraient tenter une usurpation... ce n'est pas de la provocation, mais un bilan.

Nos points faibles sont actuellement dans l'analyse de la base établie avant la mise en place de nos filtres. Il s'agit donc d'améliorer les points 3 et 4 indiqués précédemment. Le 3 repose principalement sur un facteur humain : non seulement personne n'est parfait, et l'usurpateur fera quasiment toujours une erreur, mais en plus il sera en contact avec d'autres utilisateurs et c'est au travers de ses échanges (que ce soit via une fiche de l'annuaire ou via des discussions par mail ou sur un forum) que nous pourrons envisager de le cerner.

La vérification de la base de données nécessite des idées... mais également des informations : nous pouvons vérifier la cohérence de notre base sur le fondement de quelques idées, mais rien ne vaut la comparaison avec des informations que nous savons exactes. Obtenir ces informations est le point bloquant... et là encore il y a un facteur humain.

Nous ne pouvons donc qu'espérer que la prochaine fusion de notre annuaire avec celui de l'AX, qui est vérifié par des secrétaires qui ont les moyens matériels et temporels de le faire, sera le meilleur moyen de nettoyer notre annuaire.

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é.

Pourquoi faire propre quand on peut faire sale ?

Florent Bruneau — Fri, 23 Feb 2007 23:08:00 +0100

Il y a quelques jours, mYk est venu me voir pour me dire qu'il avait réussi à se débrouiller pour que IE6 fasse un rendu correct de son site web perso... c'est à dire que le site (XHTML avec une CSS non triviale) ressemble à quelque chose sur IE6.

Il m'explique alors que IE6 a 2 modes de fonctionnement pour le rendu :

Le premier, qu'il appelle "mode normal" fait un rendu correct (pas parfait, mais correct)
Le second, (dont je ne me souviens plus le nom à dormir debout), a quant à lui un rendu "tout pourri"... par exemple, le margin: auto; de CSS ne fonctionne pas, le margin est à l'intérieur des boîtes et une partie de la CSS n'est tout bonnement pas pris en compte.

Mais alors, comment passer d'un mode à l'autre ? Un des facteur, toujours d'après mYk est la présence d'un tag <?xml ...> en en-tête du fichier, comme par exemple :

[html4strict]
<?xml version="1.0" encoding="iso-8859-15"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
  </head>
...

Donc, j'ai testé sur plat/al, le site web de Polytechnique.org : le résultat est impressionnant !

Tout d'abord, voici l'état actuel de le prod de Polytechnique.org sous IE6 :

Le corps du site n'est pas centré, le menu est mal formaté, les polices sont énormes, les backgrounds ne sont pas tous respectés... donc clairement c'est IE6 dans toute sa grandeur. Maintenant, en supprimant le <?xml version="1.0" encoding="iso-8859-15"?> du code (il faut faire abstraction du bandeau de développement) :

Cette fois-ci la mise en page est correcte, le menu qui est dans un tableau bicolore est vraiment bicolore... on a là un site rendu quasiment aussi bien que sur les navigateurs récents, et en particuliers, le rendu d'IE6 dans ces conditions est quasiment celui d'IE7 (en tout cas, ils ont les mêmes bugs sur les fieldset/legend en particuliers).

Donc, il semblerait qu'IE7 n'a pas un moteur de rendu si révolutionnaire... au moins, les utilisateurs d'IE6 retrouveront enfin un site agréable à utiliser lors de la prochaine release de plat/al... d'ici un gros mois sans doute.

Edit du 21 mars 2007 : pour plus de détail sur les modes de fonctionnement des navigateurs, vous pouvez regarder sur cette page.