AviBlog

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.

Papaaaa ! Comment on fait les appareils électroniques ?

Et bien, tu vois...  Hum, regarde ça

Émuler un PC dans son browser

Fabrice Bellard l'a fait. Il faut firefox 4 ou chromium.

petit graphique d'information sur les doses de radiation

Plutôt visuel

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.

Google s'amuse

à ouvrir dans chrome ou chromium une recheche qui parle d'elle-même