Les aventures de Mokona au pays des chonchons

Le site change d'adresse, cette adresse disparaîtra d'ici peu, pensez à mettre vos liens à jour. Rendez-vous sur la nouvelle adresse.

Suite à ma panne de portable, je me retrouve à lire mes news sur mon PDA. Il n'est pas tout récent, il tourne sous WinCE, mais au moins, il a le Wifi et je peux consulter deux trois trucs. Deux trois trucs, mais pas plus. En effet, si à chaque fois que j'ai entendu par le passé « mais tout le monde a au minimum 800 (ou plus récemment 1024) pixels en largeur ! » quand il s'agissait de faire le design d'un site web, je restais dubitatif, je paye en ce moment les frais de ce genre d'assertions à l'emporte-pièce qui tient plus à du « je ne vais pas m'embêter » qu'à une quelconque réflexion.

Car, c'est certain, avec mon PDA, je n'ai pas 800 pixels de largeur. Loin de là. On pourrait bien sûr croire que je suis un peu le seul à surfer avec un appareil à l'écran aussi petit, mais ça serait une erreur. D'après les services Google, dont certains, comme le mail ou le lecteur de news, sont amis avec les petits écrans, je suis sur un « téléphone ». Oui, des utilisateurs surfent avec leur téléphone, dont certains ont plus de puissance que mon PDA, mais pas plus d'espace à l'écran.

Pensez-y la prochaine fois que vous travaillerez votre site web. Il est vraiment très agréable d'arriver sur les très rares sites qui repèrent que l'on y accède avec un petit écran et adaptent leur affichage à ces appareils.

Il y a quelques jours, j'écrivais que je voulais installer Ubuntu sur un iBook pour lui donner une nouvelle jeunesse.

Malheureusement, cet iBook d'âge très correct et m'ayant suivi dans mes déplacements sans broncher vient d'êe victime d'une panne assez classique sur ce modèle et à laquelle j'avais jusqu'ici échappé : problème du connecteur d'écran. Du moins d'après mon premier diagnostic.

Du coup, me voici coupé dans mon élan et avec une tentative de réparation à effectuer.

Un an après le décès de son co-auteur sur Donjons & Dragons, c'est Dave Arneson qui quitte la scène.

Bien moins visible que son collègue, c'est de lui que vient l'idée initiale : celle de jouer des personnages dans la longueur, de les faire évoluer de partie en partie.

Demain soir, partie de Donjon pour moi, elle lui sera dédiée.

L'arrivée prochaine de la nouvelle version d'Ubuntu m'a donné envie, en fin de semaine dernière, de regarder un peu à quoi cela allait ressemblait. Je suis alors tombé sur la version UNR (Ubuntu Netbook Remix), adaptée aux netbooks. Et de fil en aiguille, je me suis posée la question, à nouveau, d'un passage de mon iBook G3 sous Linux.

En effet, si j'avais été agréablement surpris par les versions de MacOS-X qui ne laissaient pas tomber cette architecture mais qui, non seulement continuaient son support, amélioraient ses capacités, je suis de plus en plus gêné par le fait que les développeurs d'applications, eux, ne pense pas forcément à ces petites machines, quand ils ne prennent tout simplement pas la peine de compiler pour cette ancienne architecture.

Me voici donc parti dans une consultation de la page de Debian sur le support du PowerPC puis d'Ubuntu, sur lequel je tombe après quelques recherches. Je n'avais pas regardé en premier lieu une version PowerPC d'Ubuntu car lors de ma dernière tentation de migration, elle n'existait plus (en fait, elle devait exister dans un coin du net, mais je ne l'avais pas trouvée). Donc, ça ne traine pas, je charge et grave une version LiveCD de kubuntu (en me doutant bien que sur mon portable, ça va être laborieux) et de xubuntu (en imaginant bien que je partirai plutôt sur cette base).

Je boote kubuntu. C'est long (LiveCD oblige) mais ça fonctionne, à part un petit bug graphique gênant qui, je le constate par une petite recherche, peut être corrigé (après tout, c'est une Beta non officielle sur une architecture ancienne, ça commence à faire quelques écueils)

J'utilise un peu. Difficile de beaucoup bouger lorsque le RAM Disk nécessaire à lancer le LiveCD prend 50% de la RAM, qui n'est pas bien grande. Mais ça fonctionne et c'est encourageant. Je ne peux pas tester la mise en veille (pas assez de RAM). Le son, le wifi, les touches de fonctions du clavier, tout à l'air ok.

Je boote ensuite xubuntu, que j'utiliserai pendant le reste de la journée. Un soucis de connexion à mon réseau wifi (pour une raison ou une autre, mon portable voulait absolument se connecter sur le HotSpot Neuf qui traine près de chez moi), mais à part ça, ça tourne bien.

Je suis vraiment tenté par la migration, mais je pene que je vais laisser un multi-boot Ubuntu/MacOS dans un premier temps, le temps de vérifier que l'énergie est bien gêrée sous Ubuntu et que l'on peut correctement lire un DVD (pratique pour occuper son fils lors d'une fin de long voyage en train).

Je continue mon petit tour des jeux auxquels je joue avec les Aventuriers du Rail, un jeu d'Alan R. Moon édité par Days of Wonder.

Lire la suite

Tout comme certains de mes compères de jeux, je me décide à publier ici autour des jeux de sociétés / figurines / plateau / tout ça. Cela s'appelle l'émulation.

Lire la suite

Suite au démarrage de la campagne contre les retards de la RATP, la SNCF, sur le réseau Francilien, s'y est mis aussi.

Ainsi, un matin sur le quai, j'entends un message qui dit en substance : bloquer les portes au moment du départ, c'est peut-être aider une personne, mais c'est en retarder des milliers. Je préfère nettement le ton de cette annonce à ceux assénés par la RATP qui ont le goût de lois absolument et universelles (comme : "retenir les portes, c'est retenir le train", "1 seconde de retard pour le train = du retard sur toute la ligne").

De même, j'aime assez l'affiche de la SNCF montrant une silhouette stylisée retenant les portes et le message : "vous aimez les trains à l'heure ? Ne les mettez pas en retard."

Le ton est bien différent. La phrase s'adresse à l'usager sur le ton de l'explication. Peut-être tout simplement que l'ajout de verbes dans les phrases SNCF les rendent moins sèches, moins irrespectueuses du destinataire du message.

Mais avoir des phrases plus sympathiques n'empêche pas les soucis d'une ligne. Ainsi le matin où je découvrais cette phrase, répétée trois fois le temps que mon train arrive et ré-entendue lorsque l'on repartait d'une gare un peu plus loin, la rame dans laquelle j'étais s'est arrêtée... une minute... deux minutes.

Message du conducteur rappelant que descendre sur les voies était une mauvaise idée et qu'il ne savait pas vraiment pourquoi nous étions arrêté mais qu'il nous le ferait savoir. Un peu plus tard, le train redémarre. Le conducteur nous annonce qu'un signal d'alarme avait été tiré. Ah ! Les fameux usagers. On leur explique, mais ils mettent en retard les trains quand même.

Puis, deux stations plus loin, le train s'arrête à nouveau. Le conducteur (un autre) nous informe qu'il y a un problème technique sur le train qui nous précède. Ah ! Les fameux usagers. Ah non, pas là.

Le soir, au retour, à nouveau un problème technique.

Bizarrement, les jours suivants, le message répété en zone SNCF à propos du blocage des portes n'était plus diffusé. Mais toujours pas de message qui dirait quelque chose comme "La SNCF et la RATP s'efforcent chaque jour et conjointement de garder en état le matériel pour éviter les problèmes techniques. Merci de votre patience et de votre compréhension".

Avant hier, en montant dans mon RER, je constate l'apparition sur les portes de bulles façon bande dessinée. Opération post-festival d'Angoulême ? Je lis. Non, visiblement, campagne de la RATP sur le thème de l'utilisation correct d'un train. Du moins le pensais-je.

En fait, il s'agit d'une partie de [campagne sur la ponctualité]. Malheureusement, je ne l'ai compris qu'en lisant cet article qui pointe vers le précédent. Il semblerait que plusieurs actions soient entreprises, et c'est une bonne chose.

L'erreur, c'est que de tout cet affichage et ces expositions, la seule action qui dépasse, celle qu'on ne peut manquer car affichée en gros caractères sur les portes des trains, c'est celle qui informe le passager que si les trains sont en retard, c'est de sa faute.

Ce ne dit pas qu'il est en partie responsable, ça ne joue pas sur la responsabilité, ça énonce sous forme d'axiomes (1 seconde perdue en gare, c'est du retard sur toute la ligne par exemple) que si l'usagé ne faisaient pas de bêtise, il n'y aurait pas de problème.

Si le thème est compréhensible, la forme est malvenue. Nulle part n'est fait référence à la campagne dans son ensemble sur cet affichage. Et j'ai pu voir, depuis mon train, les couleurs de l'affiche sur un quai, à un endroit peu mis en avant et certainement invisible à ceux qui s'élancent depuis les escalators pour se jeter in-extremis dans le train qui leur fait face.

J'en ai parlé un peu autour de moi, et ça ne loupe pas : la campagne est mal perçue. Allez, ça ne fait que deux jours, il est temps de rectifier le tir.

---

Je réalise du coup que l'annonce qui a fait sourire les passagers lundi soir s'inscrivaient dans cette campagne. L'annonce ? En stationnement, le conducteur nous a gentiment averti que le départ du train était prévu pour dans une minute vingt secondes.

Dommage, le lendemain au même endroit, le conducteur annonçait qu'il attendait son remplaçant qui était dans le train venant dans l'autre sens et qui avait... vingt minutes de retard. On n'a pas eu droit à la précision à la seconde. Ni à l'explication du message puisque notre train est parti peu de temps après.

---

Il y a des efforts dans la communication, c'est indéniable et je les salue, ce n'est pas encore tout à fait ça.

Si « complètement » est utilisé généralement dans sa version adverbe (« d'une manière complète »), il existe aussi sous une forme moins connue des informaticiens : le substantif masculin.

Sa définition : « action de compléter ».

Je note d'ailleurs que lorsque je parle d'« auto-complètement », mes interlocuteurs me comprennent parfaitement. Ce qui n'empêche pas la grande majorité de continuer à parler d'« auto-complétion ».

Ayant complètement oublié de laisser un petit message le premier janvier, j'en laisse un le deux février... Bonne année !

Il est là, le bug, celui que tout le monde redoutais. Il se cache, il arrive parfois, pas tout le temps. Entre les programmeurs, la suspicion s'installe : c'est certainement dans le code d'untel !

Les pistes sont explorées une à une, parfois plusieurs fois. Il est 23h et la version livrable doit l'être absolument demain à 10h. Les machines de compilation sont silencieuses, elles attendent l'archivage salvateur pour démarrer leur production.

Et soudain, ça y est ! Bidule à trouvé. Bidule a corrigé un bug et le crash n'apparaît plus. Enfin, il est possible qu'il n'apparaisse plus car, forcément, la nature de celui-ci étant aléatoire, le doute subsiste. Mais la correction semble un bon candidat.

L'erreur ? Oh, une broutille. Une méthode qui, dans le cas d'un paramètre nul et pour éviter une division par zéro n'effectue pas la division et laisse le résultat indéterminé ^[1]

Le bug est-il vraiment corrigé ? Peut-être, peut-être pas. Peut-être était-ce un effet de bord. Les plus sceptiques vont se coucher avec un doute subsistant. Est-ce que ce module là a bien été testé ? Oui, machin l'a faut. Enfin je crois. Ah ! Pourvu que la version tienne !

---

Dans cette petite histoire, vécue par de nombreux programmeurs, le premier problème est le doute, le manque de confiance. Est-ce que les collaborateurs ont bien fait leur boulot ? Est-ce que le programme fait ce qu'on lui demande ? Est-ce que la correction de bug est la bonne ?

J'avais déjà parlé précédemment d'une manière de passer des contrats avec votre programme (les assertions). C'est une manière d'être certain qu'au moment de l'exécution, certaines conditions sont respectées. Les assertions statiques peuvent aussi vérifier certaines conditions au moment de la compilation.

Les assertions sont intéressantes et utiles. Mais elles présentent un défaut : elles ne vérifient la condition que si le code est exécuté et il n'est pas dit qu'elles ne se déclenchent pas dans certaines situations. C'est même ce qu'on attend d'elle : leur déclenchement en cas de situations malvenues.

C'est un premier pas dans la confiance dans son code : en passant un contrat, on écarte des cas.

Mais est-ce qu'on ne pourrait pas aller un cran plus loin et s'assurer que tout le code est exécuté à un moment où à un autre ? On peut imaginer un programme qui s'assure que tous les cas du programme à tester sont executés. L'ennui est que les programmes sont généralement complexes et les entrées innombrables.

Tests Unitaires

Une idée est alors de considérer qu'un programmme auquel on peut faire confiance est avant tout un programme basé sur des composants auxquels ont peut faire confiance.

C'est ici qu'interviennent les tests unitaires. Les tests unitaires, comme leur nom l'indique, sont des tests qui testent une chose à la fois. En couvrant chaque « chose » du programme indépendamment en s'assurant que les sorties sont conformes à ce à quoi on s'attend en fonction des entrées, on a une bonne base de confiance.

Besoin d'un exemple ? Prenons une classe qui maintient une liste de valeurs et est capable de donner certaines statistiques sur ces valeurs. La valeur maximum et la moyenne par exemple.

Les tests unitaires couvrant cette classe pourraient vérifier ces choses ^[2] :

• à la création, la méthode getNumberOfValue() renvoie 0 ;
• à la création, la méthode getAverage() provoque une exception ;
• à la création, la méthode getMax() renvoie la valeur minimale possible pour le domaine des valeurs ;
• à la création, après avoir ajouté une valeur, getNumberOfValue() renvoie 1 ;
• à la création, après avoir ajouté une valeur, getMax() renvoie cette valeur ;
• à la création, après avoir ajouté une valeur, getAverage() renvoie cette valeur ;

Etc...

Ici, certains prennent peur. N'y a-t-il pas plus de code à écrire pour tester que dans la classe elle-même ? Oui. Dans ce cas exemple, c'est vrai. Et c'est vrai aussi dans la pratique dans un certain nombre de cas. Mais est-ce un mal ? Quelqu'un sans gros passif peut le penser. Quelqu'un qui a passé des nuits entières sur un bug idiot comprend vite que le temps passé à écrire les tests est gagné sur du temps qu'on ne passe pas plus tard à la recherche des bugs.

Ce n'est pas forcément évident à accepter car le temps qui n'est pas passé dans le debug est difficilement quantifiable.

Avec quoi tester ?

Il existe des frameworks de tests unitaires dans à peu près tous les langages de programmation. Pour le C++, vous pouvez en trouver quelques-uns que j'avais testé dans cet article. Pour Java, le plus connu est JUnit. Pour C#, NUnit.

Les frameworks sont généralement dotés de fonctions qui vérifient des résultats et d'une manière de signaler que du code est du code de test. Lorsque les tests sont lancés, chaque test est exécuté et une erreur lors d'une vérification provoque un message contenant des informations de ligne et un message indiquant l'erreur.

Par exemple, une erreur pourrait ressembler à cela :

testclass.cpp: 130 ; Test failed "TestGetMax" , expected 3 but got 1.

Tester pour développer

Tester a posteriori est intéressant. Et si l'on testait avant d'implémentation ? Idée étrange de prime abord, c'est une étape supplémentaire pas bête du tout. En anglais, le "test driven development" consiste donc à commencer par écrire le code de test avant ce que l'on test.

Forcément, lors des premiers lancements de tests, il y aura beaucoup d'erreurs. Mais pourvu que les tests soient bien écrits, on s'assure que lorsque tous les tests passent, l'implémentation testée fait ce qui lui a été demandée.

Un savoir faire

Tester ses implémentation ou encore tester avant d'implémenter ne sont pas des choses naturelles en programmation lorsque l'on débute. Ce ne sont pas non plus des choses, à ce que j'en sais, qui sont enseignées ou tout du moins appliquées après avoir été enseignées.

La plupart de temps, il faut avoir été confronté aux problèmes que ces méthodes règlent (ou tout du moins adoucissent) pour comprendre leur intérêt.

C'est aussi un savoir faire. Quoi tester, comment tester, comment bien isoler la classe à tester dans un langage objet, tester efficacement et complètement,... Mais c'est un outil qui se révèlera utile. En d'autres mots : ça vaut le coup de s'y lancer.

Un graal ?

Je n'ai pas mis les tests unitaires et le « test driven development » (TDD) dans ma série « Ceci n'est pas le Graal ». Je ne pense pas que le TDD ait suivi le processus par lequel je définis un faux graal. Peut-être parce que ce n'est pas tant utilisé que ça. Peut-être parce que les utilisateurs de TDD sont convaincus et n'ont pas été forcés d'en faire. Peut-être parce qu'il n'y a pas eu un énorme buzz autour de cette méthode de développement.

Ou peut-être parce que la promesse est tenue et n'est pas sur-évaluée. Le test permet une chose : une confiance accrue dans le code. C'est le sujet de l'article. En surveillant qu'une modification ne provoque pas des régressions. En s'assurant que ce qui a été programmé fait bien ce à quoi on s'attend.

Cette confiance permet même d'oser plus. Qui n'a pas en tête le moment où un sous-système d'un programme est arrivé à un point où l'on voudrait le changer, mais où l'on n'ose pas, de peur de tout casser. Ou alors il faudra tester manuellement, mais sans vraiment être sûr de tous les cas. Ou alors il sera temps d'ajouter des tests unitaires, mais les faire a posteriori et bien après l'implémentation entraine le risque d'oublier des cas. Avoir développé en TDD assure que les tests sont déjà là lorsqu'on en a besoin.

Le TDD est vraiment quelque chose que je conseille d'essayer. Je conseille aussi de commencer petit, avec des petites classes ou fonction que l'on a déjà implémentée, que l'on connait bien et donc pour lesquelles on a une bonne idée de ce qu'il y a à tester. Puis d'aller un peu plus loin à chaque fois.

Ce matin, dans le train m'amenant au boulot, un jeune homme se met en face de moi puis, quelques instants après, sort un cahier de croquis. Cette activité pour un voyageur ne fait pas partie des plus courantes, je lève donc un sourcil curieux. Quelques mots sont jetés sur une des pages que je ne cherche pas à lire. L'autre page est vierge.

Je retourne à mon livre.

Une station plus tard, je jette, tout en tournant une page, un regard vers le cahier. Celui-ci est à présent parcouru par un feutre qui, d'après les mouvements, est en train de faire un croquis. Je me recale un peu, façon peu discrète pour jeter un coup d'oeil. C'est encore très brouillon et je ne distingue rien, d'autant plus que le dessinateur relève légèrement le cahier ; façon peu discrète de cacher ce que l'on fait.

J'esquisse un sourire : si ça se trouve, je suis le sujet du croquis.

Je replonge dans mon livre.

Entre les paragraphes, je jette un regard. Les formes se précises et je reconnais le front dégarni, les cheveux en arrière sur le dessus de la tête, la tête penché qui mettent les yeux au dessus des verres des lunettes et surtout, cette position du bras qui fait que le poing remonte la joue.

En effet, c'est moi. Dans la position de lecture appuyé contre la fenêtre, lorsque le croqueur a pris place dans la rame quelques stations plus tôt. Je ne peux juger à l'envers de la ressemblance exact, mais la pose, l'allure général y est.

L'homme referme le cahier et sort.

Sentiment étrange que d'être couché sur papier, spontanément et sans permission par un inconnu. Mais demander la permission, si cela avait été plus poli, aurait fait perdre à ma pose cette spontanéité. L'inconnu lui-même savait qu'il pouvait gêner, sa volonté de toujours mettre son travail hors de mes yeux le trahissait.

Mais au final, je ne suis pas mécontent. J'aurais été agacé si j'avais été pris en photo. Ici, le croquis me représente sans être exactement moi. Et cette façon de croquer spontanément est un exercice chez le dessinateur que j'admire un peu.

Un collègue m'avait, il y a quelques années, dessiné de profil en quelques traits. Une évocation de ma personne devant son ordinateur. Je ne sais pas si j'ai encore le dessin, mais j'avais trouvé cela amusant.

Si un jour par un hasard extraordinaire, l'inconnu croqueur venait à passer par cette page, j'aimerais qu'il contente ma part narcissique et m'envoie une copie du dessin.

Qu'arrive-t-il lorsqu'on a un appareil réglé en « tout automatique » dans la poche, et bébé dans les bras et que l'on entend au loin la sonnerie d'un passage à niveau qui se ferme ?

Poser le bébé par terre pour prendre le temps de régler l'appareil n'est pas une option.

Qu'est-ce que cela donne quand en plus, au moment de viser, on s'aperçoit qu'on a le soleil dans les yeux ?

Ça :

Il y a un tout juste deux mois maintenant, je parlais de la sortie de Donjons et Dragons 4ième édition. Un mois plus tard, les livres lus, les forums parcourus et le jeu joué, voici ma revue de la bête.

Lire la suite