La fin du cycle Inheritance

Voilà, ma douce m'ayant offert le dernier tome du cycle Inheritance au mois de décembre, appelé lui-même inheritance, il a bien fallu que je me décide à terminer la série. Comme le fait remarquer son auteur, l'histoire a commencé il y a quasiment 10 ans et la patience d'attendre le tome suivant a été une épreuve quasi olympique.

Depuis le premier tome qu'il avait écrit à 15 ans à ce dernier, on apprécie la maturation des personnages et de l'auteur. Ce qui m'avait emballé au début, c'était la foison imaginative qui, il faut le dire ne devait pas trop savoir où elle allait. Cette fin au contraire, respire l'organisation, l'ordre et un gros effort pour faire rentrer toutes le briques lancées au fil des romans dans un seul et même mur.

La mission est réussie, même si du coup, l'histoire perd un peu de saveur. Je ne suis pas mécontent de quitter Eragon avec une histoire définitivement bouclée.

Réflexe pavlovien

Beaucoup de personnes qui me connaissent vous diront que j'ai tendance à douter, des fois au délà du raisonnable, de ce qu'elles me disent. Je ne pense pas être seul, car après tout, nous sommes dans la patrie de Descartes.

Si en plus la réunion est technique, là c'est carrément le mode paranoïaque qui se met en route, mais qui ne peut malheureusement empêcher toutes les erreurs. Dans ce mode, j'ai un cablage pavlovien sur certaines expressions.

Si quelqu'un commence la phrase par "en théorie" ou "en principe", j'ai les poils de la nuque qui se dressent immédiatement. On parle de technique au travail et la théorie, ça ne sert généralement qu'à expliquer pourquoi ça ne marche pas. Pour que ça marche, il faut un peu plus que des considérations éthérées.

Si la phrase commence par "a priori" ou "à première vue", la pensée réflexe qui me vient, c'est : "toi, mon gars, tu as été flemmard et tu n'as rien testé". Et tout le monde sait qu'un design fonctionne tant qu'on n'a pas essayé de l'utiliser.

Un autre cas est l'utilisation du conditionnel, ou pire un "ça devrait...", preuve d'un déli flagrant d'optimisme. Dans l'histoire du verre à moitié plein ou à moitié vide, ce qu'il faut surtout retenir c'est que le verre n'est pas plein. Peu importe son niveau de remplissage réel finalement.

Dans tous les cas, je me souviens du commentaire de O'Toole "Murphy est trop optimiste".

La civilisation atteint enfin Chambéry

Notre halle de marché couvert a subi une mutation durant les dernières années pour accueillir de nouveaux magasins et un marché couvert rajeuni. La réouverture hier du marché a amené de nombreux curieux... Hé oui, par ici, c'est un évènement ! Rendez-vous compte, on a enfin une FNAC !

Mais le clou de cette réouverture, c'est... les escalators ! Comme me dit ma seconde : ça manquait, il n'y en avait pas à Chambéry.

Après Internet et les escalators, que va-t-il nous arriver pour que notre belle région sorte de son arriération ?

Un éponyme dont on se passerait bien

Au détour de mes lectures et surf sur internet, j'ai découvert une technologie qui porte mon nom. Elle s'appelle Avila Link. Malheureusement, il n'y pas vraiment lieu de s'en réjouir, mais comme je suis joueur, avant de vous donner l'explication, je vais vous la présenter sous forme d'une devinette.

Le mot "Link" dans le nom est un intrus à deux titres. Le mot Avila n'a rien à voir avec la ville espagnole, mais avec le nom d'un province d'un autre pays de langue espagnole.

séquence nostalgie

Culture personnelle, culture d'entreprise et culture nationale

Voici une petite histoire sur le thème des petites (ou grandes) différences dans les manières de faire les choses ou d'aborder les problèmes, tirée d'une expérience récente.

Lors du démarrage d'une machine montée en partie au USA, des problèmes électroniques apparemment incompréhensibles se sont posés. Les mesures de tensions à différents points de la machine ne correspondaient pas du tout aux résultats attendus, avec des valeurs aberrantes dépassant mêmes les gammes possibles pour le signaux mesurés ! Après une recherche en long en large et en travers sur des problèmes de câbles, car le câblage avait été réalisé en France, nous en avons déduit que la carte électronique que nous avions sous les yeux ne correspondait pas aux schémas sur lesquels nous fondions nos recherches. Après encore un peu plus de temps, nous en sommes venus à la solution : les connecteurs double-rangées de cette carte, au lieu d'avoir une numérotation par ligne puis par colonne (ce qui donnait une ligne de pins paires et une ligne de pins impaires) avait été numéroté avec une priorité sur la colonne , puis sur la rangée. Aucun de nous n'avait jamais vu une telle numérotation. Spécificité américaine ?

Information prise auprès d'un collègue américain de la personne en charge du montage, cette numérotation semble spécifique à cette personne, pour des raisons qui restent mystérieuses.

Il y a un dicton d'ingénierie en anglais qui dit "Don't assume anything".  Encore une fois, vrai...

L'art et la manière de tester des idées

On en tous eu, des idées d'inventions qui auraient pu révolutionner le monde. Mais souvent, elles ont eu deux destinées : abandonnées à peine  l'idée formulée ou après mûre réfléxion, ou menées jusqu'au terme en y mettant beaucoup d'énergie et d'argent pour finalement s'apercevoir que ce n'était pas une bonne idée.... Le problème est bien sur qu'une mauvaise idée investie masque peut-être une bonne idée non réalisée, mais cela nous ne le saurons jamais. Avec une statistique générale disant que 80 % des projets sont des échecs, cela n'encourage évidemment pas à se lancer.

Chez Google, cette philosophie a laissé place à celle qu'il est obligatoire de donner à toutes les idées leur chance. Mais pour autant, le réalisme doit être de mise. Du coup, un p'tit gars de chez Google a conceptualisé l'approche qu'il appelle le pretotypage. Je vous laisse découvrir la signification de ce terme dans ce livre qui est lui-même un pretotype (ah ! la récursivité...). Une lecture très instructive que j'aurais bien aimé que son auteur mette en forme quelques années avant.

If statement considered harmful

Derrière ce titre un brin provocateur, une réflexion simple : on apprend à l'école dans les  bases de programmation le concept de flux d'exécution conditionnel. Le problème avec cette approche est qu'elle occulte le plus souvent le besoin pour une bonne architecture de logiciel, sujet qui est rarement traité dans les cours d'informatique. La faiblesse d'architecture multiplie les tests, menant le plus souvent au syndrome « code spaghetti ».

Cette situation est encore plus crispante avec les technologies objet. Le polymorphisme a pour vocation à remplacer les tests par une résolution dynamique des méthodes à appeler. L'utilisation de if avec des fonctions d'introspection de type "isInstance" sont une absurdité qui devrait frapper ceux qui l'écrivent et me hérissent au plus au point. Un polymorphisme bien pensé permet d'éliminer totalement des ensembles de "if" ou "case" en formalisant à la manière objet le fait qu'un ensemble de comportements correspondent à un cas d'utilisation et doivent donc appartenir à une même entité représentant ce cas d'utilisation. Si on ne suit pas ce précept, on ne peut pas suivre le précept objet « opened for extension, closed for modification » car il apparaît souvent qu'un test à un endroit en appelle d'autres lors des évolutions du logiciel.

Je vois cependant deux déviations majeures à cette règle : la gestion des stimuli externes à l'application et l'exécution des règles métier de l'application, ce qui peut englober en partie l'exception précédente.

Pour la première exception, je ne vois pas comment réaliser l'analyse des entrées de l'application, qui sont par nature non maîtrisées sans effectivement les tester. Cependant, ces tests devraient se cantonner à la phase d'analyse la plus proche des informations brutes d'entrée et sont déjà le plus souvent implémentés dans des bibliothèques d'interface (parseurs, gestion réseau, lecture de configuration, etc). 

Pour les règles métier, c'est après tout ce qui constitue l'objet de l'application. Pour qu'une application vérifie si une température est inférieure à un seuil donné, on doit lui faire faire le test. Avec l'application de cette règle, on peut être sur qu'un test effectué dans le code doit pouvoir être relié à une spécification de règle métier.

À part cela, comme dit la pub, pour tout le reste, il y a le polymorphisme.