Les aventures de Mokona au pays des chonchons

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.

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

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

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.

Les Design Patterns (abréviation DP) sont présentes dans l'industrie, ont droit à des articles innombrables, des pour, des contre, suscitent l'excitation des débutants... Voilà encore un bon candidat pour les faux Graals.

Lire la suite

J'avais chargé la version d'installation ^[1] d'Ubuntu 8.04 à sa sortie, mais je n'avais pas encore pris le temps de regarder. Puis je me méfie toujours un peu des mises à jours, surtout que je n'avais pas de raison particulière d'effectuer celle-ci si ce n'est d'être... à jour.

J'avais aussi laissé passé la déclaration des impôts sur le revenu. Il vaut mieux éviter d'avoir une machine en panne juste à ce moment là, même s'il est toujours possible de faire migrer le certificat sur une autre machine, ça reste un petit stress pas vraiment nécessaire.

Il m'était aussi revenu quelques expériences négatives sur cette mise à jour. Renseignements pris, c'étaient souvent une première expérience de mise à jour complète du système et les problèmes étaient minimes et résolus rapidement.

Donc, samedi, j'appuie sur le bouton magique : mise à jour vers version 8.04.

Cela va être très rapide : le programme me signal qu'il n'a pas assez de placer sur le disque pour charger les paquets d'installation. Je regarde... oui, pas faux. Bon, dommage mais j'ai autre chose à faire.

Le lendemain dimanche, je jette un coup d'œil dans le gestionnaire de paquets à la rubrique des paquets détectés comme obsolètes et pouvant être effacés sans risque. J'y trouve effectivement 4 ou 5 version d'anciens noyaux Linux, de vieux splash screens. Je n'ai vraiment fait de ménage depuis ma première installation d'Ubuntu, la 5.04, il y a donc 3 ans. Le ménage libère 500 Mo. Ah quand même.

Je relance la mise à jour et là, ça ne râle plus. Seul petit soucis, du a une bidouille : j'ai monté l'iso d'installation sur un répertoire locale et je l'ai déclarée à apt. Mais visiblement par comme il faut, car l'installation me demande d'insérer le CD dans le lecteur CD-Rom. Pas grave, je remonte l'image sur le chemin du CD-Rom et le programme d'installation n'y voie que du feu.

Le programme m'annonce alors qu'il doit charger près d'1 Go de fichiers. Je le laisse tranquille et je vais faire autre chose.

Deux heures plus tard, la mise à jour en elle-même démarre. Il y a moins de questions que d'habitude, et c'est tant mieux. La configuration des packages est toujours la partie un peu pénible car il faut rester dans le coin pour accepter (ou refuser) quelques modification des configurations. Il y a peut-être moyen de faire ça automatiquement et d'un coup, mais je ne connais pas ce moyen.

Les surprises au redémarrage :

• le driver de ma carte graphique a été remis sur un driver libre. La surprise, c'est que le DRI est tout de même activé, alors que ce n'était pas le cas auparavant. Ubuntu me propose néanmoins de charger le driver propriétaire nVidia. Je n'ai rien contre, j'accepte. Petit désagrément, cela nécessite un redémarrage de la machine. Au retour, tout fonctionne bien graphiquement.
• le pavé numérique ne fonctionne pas. Très étrange. En fait, il faut aller dans les options du clavier et désactiver le contrôle de la souris au clavier. Je n'ai pas cherché le pourquoi de cette option qui apparait sur cette version.

Voilà, je n'ai pas eu d'autres surprises et cette mise à jour est donc un succès.

En programmation, il arrive parfois que quelque chose « tombe en marche ». Rien ne fonctionnait ou fonctionnait mal et soudain, après une manipulation incertaine, un petit changement, ça marche. À ce point, certains crient victoire et annoncent que le problème est résolu, d'autres, plus prudents, se mettent une petite note dans un coin et restent discret. Mais dans les deux cas, ce qui a été trouvé est un contournement, pas une solution.

Lire la suite

« je ne fais pas de test car il est impossible que le pointeur soit NULL », « je pourrais vérifier que la valeur est positive avant de faire ma racine carrée, mais ça ferait perdre du temps »,... Une fois encore, je pars de phrases vues et entendues, que ce soit dans l'univers amateur ou professionnel, pour aborder un sujet en programmation.

Lire la suite

Je reviens sur une partie vue très brièvement dans l'article précédent lorsque je citais le classique « Cette application exporte en XML » au rang de arguments bien placés dans la liste des possibilités d'une application.

Lire la suite

« Cette application exporte en XML », « les données sont stockées dans un fichier XML », « pour ton programme, je te conseille d'utiliser XML ». Visiblement, XML est un bon Buzzword. Il sert d'argument commercial autant qu'il semble être la solution miracle dans des discussions de développeurs. Une solution miracle ? Voici un bon candidat au Graal. Examinons donc ce qu'est XML.

Lire la suite

Pour ce deuxième épisode, je prends a nouveau une abréviation se terminant en L. Après la STL, voici venir l'UML. Ces deux abréviations n'ont pas même la signification de leur L en commun.

Lire la suite

La STL (Standard Template Library) forme une composante essentielle du C++. Parties de recherches sur la programmation generique independantes du C++, elles se sont greffées à celui-ci jusqu'à en devenir une partie du standard.

Lire la suite

Le Graal, objet mystérieux dont personne ne connait les effets exacts ni la forme ; mais objet de quêtes.

En informatique, la recherche du Graal est constante. Parfois, on croit l'avoir trouvé ; souvent, il ne s'agit que d'un bon outil. Dans cette série d'article, dont le premier en est aujourd'hui l'introduction, je vais passer en revu des outils informatiques qui, s'ils sont de bons outils, ne sont pas des Graals. Si je les associe à ce symbole, c'est qu'ils ont été, ou sont encore, pris pour tels.

Lire la suite