J'ai testé 7 !

J'ai été obligé d'installer et de tester 7 (c'est dingue, mais ça me fait systématiquement penser au film homonyme) pour mon boulot. Et, comment dire ? C'est... ce n'est pas... enfin... c'est Windows, quoi ! Je ne comprends pas trop tout le bruit qu'on fait autour de cette version. C'est toujours Windows. Les fans seront sûrement conquis, ceux qui n'aiment pas n'aimeront toujours pas, et les indécis se le verront imposé avec leur nouvelle machine. Pas de révolution, pas de réelle inovation, comme d'hab'. Tous les gadgets qui sont censés nous épater existent depuis des années. Quant à la simplicité, si cela correspond au fait de pouvoir cacher les menus dans lesquels on passe notre temps à se perdre, ou à une énième refonte du menu démarrer je ne vois pas trop non plus ce que ça apporte.

Bref, n'attendez pas un test complet ici. Juste le point de vue tout à fait subjectif d'un utilisateur de linux converti au Mac. 7 n'est que Windows. Même Microsoft n'y croit pas, si on en juge par la campagne de publicité la plus pourrie qu'on ait jamais vue pour un produit de cette firme. Même les vendeurs de lessive font mieux.

Oui, je sais, un article pour pas grand chose. Juste envie de donner mon sentiment. Surtout qu'il va falloir que j'aille plus loin avec ce nouveau venu. Alors il y aura peut-être une suite...

Parce que ça commence à m'énerver !

Extraits du cours de technologie de mon fils aîné en 6ème :

• Où range t'on les programmes ? Dans le dossier Program Files
• Qu'est-ce qui permet de parcourir l'arborescence des fichiers ? L'explorateur Windows

Je passe sur les imprécisions et inexactitudes (en particulier la distinction faite entre fichier et programme). Pas un mot sur de possibles alternatives, sur, par exemple le Finder (et je ne parle même pas de citer Nautilus, Gnome et autre KDE). Cela fait partie de ce qu'ils appellent, en gros, le brevet d'aptitude en informatique.

Ce n'est pas la peine de faire passer des lois anti-monopole, de sanctionner Microsoft : nos enfants sont préparés à l'utilisation de leurs produits. Je ne dis pas qu'il faut banir cette marque de nos écoles (je n'en demande pas tant !). J'aimerais tellement qu'on explique des principes à nos enfants et que l'utilisation d'un système ou d'un autre ne soit qu'une application, un travail pratique.

Imaginez juste 2 secondes un énoncé de problème du genre :

"Jean prend sa Grenault et parcourt 800Km. Sachant que sa voiture consomme 8l au 100, et que son réservoir contient 40l, combien de fois devra t'il s'arrêter dans des stations Potal pour faire le plein ?"

Je vois déjà les réactions indignées des parents, des associations de consommateurs, et de je ne sais qui encore.

Oui, je sais, je simplifie. Mais pas forcément plus que ceux qui estiment que tout ça est normal.

Un peu de lecture

Je viens de finir Propaganda : Comment manipuler l'opinion en démocratie de Edward Bernays et Normand Baillargeon. Un livre fort intéressant qui, malgré qu'il ait été écrit en 1928, reste fortement d'actualité. On est assez surpris d'y découvrir que la propagande, bien qu'elle ait acquis une bien triste réputation sous de nombreux régimes totalitaires, est bien née en démocratie.

À vrai dire, la propagande décrite dans cet ouvrage est ce que l'on qualifie aujourd'hui de "Relations publiques". Mais ne nous y trompons pas : les relations publiques utilisent bien des techniques de la propagande. Et je pense que nous le savons tous. Mais la lecture de ce livre ouvre une nouvelle perspective, une autre façon de voir le fonctionnement de nos démocraties.

Bref, je vous le conseille. En plus, ça se lit plutôt vite et bien. On aurait tort de se priver !

Bon, maintenant, j'attaque le Petit cours d'autodéfense intellectuelle de Normand Baillargeon (qui a préfacé Propaganda) et Charb. Je vous tiens au courant.

10 jours avec un MacBook

10 jours déjà, et la première impression tend à se confirmer : c'est une très bonne machine, confortable malgré sa petite taille, endurante, avec un bon système, même s'il demande de s'y habituer.

Le touchpad multi-point, en particulier, est un vrai plaisir. J'en suis à ne pas vraiment avoir envie de brancher une souris et je me surprend à vouloir utiliser le PC du boulot de la même manière.

J'ai un peu plus de mal avec la disposition du clavier Apple, qui est un peu déroutante quand on vient du monde du PC. Question d'habitude, je suppose.

Je trouve qu'il manque également un témoin d'activité de disque. Cela me perturbe de ne pas pouvoir savoir d'un coup d'œil si ma machine travaille ou pas lorsque le temps de réponse est un peu long. Mais là encore, il ne s'agit que d'un défaut mineur.

Donc, côté matériel et même logiciel, je suis vraiment satisfait de mon choix. En revanche, j'ai été très déçu par le projet MacPorts. Je pensais avoir au bout des doigts un équivalent du système de ports BSD, et je me retrouve avec un projet inachevé, avec de nombreux paquets qui ne peuvent s'installer. Au premier échec d'installation, on se dit qu'on va essayer de contribuer au projet en essayer d'apporter une correction. Mais on se rend rapidement compte que, finalement, il y en a beaucoup. C'est vraiment dommage. Je n'ai pas vraiment le temps de me consacrer à ce type de projet, et j'ai donc abandonné MacPorts au profit de Fink.

Fink est une sorte d'apt, mais en plus ouvert. Les principes sont globalement les mêmes : des dépôts de paquets et un système simple et centralisé pour les installer, supprimer et mettre à jour. Je viens de l'installer et je ne l'ai pas encore vraiment testé, mais les premières impressions sont bonnes.

En résumé, si vous cherchez à acheter un portable et que vous avez le budget, n'hésitez pas : ces portables sont vraiment excellents. (Bon, maintenant, je vais négocier avec Apple combien ils vont me filer pour ce coup de pub :-) )

Des manchots aux pommes

Jusqu'à présent, j'étais plutôt adepte des PCs sous Linux. Depuis peu, cela est en train de changer grâce à l'acquisition d'un MacBook.

J'ai toujours considéré les Mac comme des machines de qualité, mais trop chères pour ce qu'elles étaient, malgré tout. La dernière gamme de MacBook est venue à bout de cette idée : ce sont d'excellentes machines pour un excellent rapport qualité/prix. Et qui fonctionne sous Unix. N'oublions pas que le cœur de Mac OS est un Free BSD, remanié par Apple, mais la base est là. Vous avez toujours accès au terminal, avec l'ensemble des commandes Unix. X11 est là, lui aussi. Il y a quelques années de ça, un ami avait acheté l'iMac Tournesol. Un des arguments qu'il avait donné pour expliquer son choix était, entre autres : "je peux lancer un terminal et utiliser vi". Je le comprends très bien aujourd'hui et le rejoins complètement. C'est un peu le meilleur des deux mondes.

Et les logiciels libres dans tout ça ? Le projet Macports mets plus de 6300 paquets logiciels à disposition, façon apt sous Debian ou Ubuntu ou plutôt à la manière des ports sous BSD.

Voici donc le début de mes aventures sur les ordinateurs à la pomme. Je ne renie pas pour autant les manchots et, d'ailleurs, si je ne suis pas totalement satisfait, je reviendrai vers Linux qui reste, pour moi, une valeur sûre.

Cachez cette erreur que je ne saurais voir !

Qu'y a-t-il de plus agaçant qu'une application qui plante lamentablement sans le moindre message ? Qu'y a-t-il de plus compliqué pour le développeur à déboguer que ce type d'application ?

Ça fait assez longtemps que j'observe cette tendance qu'il y a chez de nombreux développeurs (y compris moi-même à une certaine époque) à cacher les erreurs, les exceptions, à tout faire pour que l'application ne quitte pas inopinément, au risque de mettre en péril la fiabilité des résultats obtenus. On essaie de faire croire à l'utilisateur/client qu'il n'y a jamais de problème. Mais tout développeur sait que cela est illusoire. Une sorte Graal qu'il est impossible d'atteindre. On a beau utiliser des tests unitaires, essayer de prévoir tous les cas d'erreurs, il y a toujours une situation qu'on n'a pas anticipée et qui plante notre application qu'on croyait pourtant si robuste.

J'ai pu également observer qu'on a l'air beaucoup plus crédible et professionnel lorsqu'on a une trace ou un code d'erreur lorsqu'il y a plantage. L'idéal est de pouvoir produire une image de la pile dans un fichier au moment de l'erreur, et de la demander au client : vous gagnez en crédibilité car vous avez envisagé l'improbable. De plus, vous récupérez des informations précieuses qui vous permettent de comprendre et de corriger rapidement le bug. Un code d'erreur est souvent suffisant.

Les assertions (assert), par exemple, peuvent être un outil précieux. Lorsque je débutais, on m'a appris, comme une sorte de dogme, que les assertions ne devaient être utilisées que dans du code compilé en version debug, mais ne devaient pas apparaître dans la version compilée en release. Je me rends compte maintenant, pour avoir violé cette règle, combien cela est une erreur. Une assertion sur un pointeur NULL à un endroit où on ne s'y attend pas et qu'on ne sait pas rattraper, par exemple, évite une erreur anonyme. Un assert indique la ligne de code et la condition qui a provoqué l'arrêt. Une information des plus précieuse pour corriger rapidement une erreur grave.

À mon sens, le plus important est la maîtrise de l'erreur. Avoir le contrôle et le montrer, pour gagner la confiance du client ou de l'utilisateur. Bien entendu, aucune erreur, c'est mieux !

Le code jetable

On a tous eu un jour à écrire un bout de programme pour tester une idée, une librairie, un concept ou pour faire une "maquette". En général, on se dit que, de toutes manières, on ne gardera pas ce qu'on est en train d'écrire. Alors on met de côté la qualité.

Avez-vous remarqué que ce code destiné à être oublié finit très souvent en production ? La maquette évolue pour devenir le produit final. La partie utile du petit programme de test est intégrée telle quelle dans une application. Avec un impact sensible sur la qualité de l'ensemble.

Et lorsque ce code n'est pas directement utilisé, il sert souvent d'exemple, voire de documentation pour les nouveaux arrivants ou les collègues. Et il est pénible de passer beaucoup plus de temps qu'il n'en faut sur un exemple parce qu'il est incompréhensible ou qu'il est impossible de le faire fonctionner.

Ce qui m'amène à la pensée du jour : lorsque vous écrivez un bout de programme, essayez d'imaginer ce qui se passera lorsque vous devrez le reprendre dans 1 mois, 3 mois, 6 mois, 5 ans.