Thursday 28 December 2023

Balade au pays des voyeurs : les Observables

Tout commence par la découverte du code d'un programme utilisant Angular, et en particulier NgRx. Je me retrouve propulsé plus de 20 ans en arrière, avec une approche intégralement en callbacks, et pour s'y retrouver dans ce magma de fonctions : des noms, des noms, des noms. Une explosion de noms. Une addition ? Un nom. L'affectation à une variable ? Un nom. Cette pratique antédiluvienne de nommer tous ces petits fragments de code avait normalement disparue quand on a arrêté de faire de l'assembleur. Et pourtant, NgRx est à la mode. Et ça parce que NgRx est au pinacle de la modernité, un croisement entre Redux, la programmation réactive et Angular : en cumulant trois biens, comment peut-on être autrement qu'exceptionnel ?

Revenons sur ces noms : on parle de magasin, d'action, de réducteur, d'observable et d'effet, avec des liaisons sémantiques souvent parachutées. La lecture de la documentation est surprenante, on la croirait écrite par un ChatTouPT : la grammaire est correcte, les mots existent, des phrases font sens, et tout d'un coup, le vide, l'absence de logique, l'absence de sens... Au milieu de cette forêt je repère le mot observable, répété régulièrement par des collègues, qui me rappelle naïvement le modèle de conception observateur du GoF. J'aborde donc le sujet avec dans l'idée qu'un observable est celui qui est observé par un observateur (ou observer). Mais ça ne fonctionne pas. On pourrait dire que les effets et les réducteurs sont des sortes d'observateurs, mais un observateur est normalement notifié selon une interface qui a du sens pour la quantité de données et les changements poussés par l'observé. Ici rien de tout ça, l'observateur doit avant tout faire attention à... la gestion des erreurs d'une part, et à la notion de complétion d'autre part.

Côté GoF, la gestion des erreurs ne fait pas partie de Observateur, elle est réalisée à travers les mécanismes standards en POO, c'est-à-dire avec des exceptions. Et pour la notion de complétion, celle-ci se matérialise par la mise en place d'un gestionnaire de changement ou ChangeManager si cette notion est importante à gérer, ce qui n'est pas le cas de base de Observateur. D'autres choses font tiquer, comme le fait de créer un observable avec une simple valeur, qu'on change ensuite à la main, sans aucune notion d'extériorité. On trouve aussi dans la documentation un observable qui ne change pas, et donc qui n'a pas besoin d'être observé, vu que le patron de conception Observateur n'est là que pour ça : le changement.

Quelque chose n'allait donc pas dans la compréhension de NgRx par l'angle du patron de conception Observateur. Je reprends mes pérégrinations, je retombe sur la documentation officielle de NgRx, et tout me paraît soudainement moins confus, plus explicite, et même cohérent. Ça parle beaucoup moins de ces actions qui ne suivent pas le patron de conception Commande du GoF mais qui sont juste des encapsulations de paramètres avec un nom. Ça ne parle pas plus non plus de ces fameux réducteurs, qui dans Commande sont la partie active de l'action. Jusqu'à ce que quelqu'un me signale que ce n'était pas la documentation de NgRx mais de RxJS !

Sur cette documentation on apprend d'autres choses, comme par exemple qu'il est logique de recevoir des événements alors que la souscription n'est pas terminée, voire qu'il est normal qu'il n'y ait plus rien à observer une fois la souscription faite, tout se passant pendant la souscription. Là on est à l'opposé complet d'Observateur, où on a quasiment la garantie que rien ne va se passer pendant la souscription. En continuant un peu dans la partie glossaire, on va découvrir l'observable froid et l'observable chaud. L'observable froid, c'est celui qui crée un producteur pour chaque souscripteur au moment de la souscription. Et là nous sommes passés complètement au-delà du patron de conception Observateur, dans lequel on n'a pas besoin de notions séparées de producteur et de consommateur. Le sujet produit, l'observateur... ne consomme pas : en effet, quand quelque chose est consommé, il n'est plus disponible pour quelqu'un d'autre, et dans le patron de conception Observateur, tous les observateurs reçoivent une notification à la base identique.

Alors pourquoi introduire cette notion de consommateur, c'est étrange ! Continuons sur le glossaire RxJS, avec l'observable qui est défini comme un gabarit pour connecter un observateur en tant que consommateur à un producteur via une action souscrire, résultant en une souscription. RxJS définit donc que l'observable n'est pas observé, c'est le producteur qui l'est, parce que l'observateur n'est rien de plus qu'un consommateur. On ne trouve pas dans ce même glossaire la notion de sujet, elle n'est pas suffisamment importante, mais elle est quand même présente dans la documentation. Étant donné que le mot est directement copié depuis le patron de conception Observateur, dont RxJS se réclame en tant que... ReactiveX ? Diantre, encore un nouveau terme. Bref, étant donné que RxJS se réclame de Observateur, alors on devrait trouver une très forte similarité sous l'intitulé sujet.

RxJS présente sujet comme ceci : un sujet est un type spécial d'observable qui permet aux valeurs d'être envoyées à plusieurs observateurs. Deux remarques : dans Observateur, tous les observateurs reçoivent la même notification, néanmoins, une notification dans Observer n'est de base pas sous la forme d'une valeur, mais d'un signal. Un observable standard n'est donc définitivement par un sujet dans Observer, il n'en a pas du tout les mêmes caractéristiques. RxJS met aussi en avant la caractéristique suivante : tout sujet est un observateur ; c'est un objet possédant les méthodes de l'observateur. A ce stade, il est temps d'aller ouvrir les fenêtres, taper deux ou trois tapis, et passer un coup d'aspirateur. Cette récursivité n'a aucune existence dans le patron de conception Observateur : il n'y a aucune raison pour le sujet d'être un observateur, absolument aucune. Parce que ce patron de conception suit un des principes de bases de l'informatique : la séparation des préoccupations. Juge et partie. Créancier et endetté. Surveillant et prisonnier. Sujet et observateur.

Puisque ce mot ReactiveX est apparu au-dessus, allons voir si cette notion est différente de ce côté-ci. La présentation commence comme suit : un Sujet est une sorte de pont ou de mandataire disponible dans certaines implémentations de ReactiveX, qui agit à la fois comme observateur et comme Observable. La finalité est inversée par rapport à RxJS. Dans un cas on dit que le principe est de pouvoir être utilisé comme Sujet au sens de Observateur (sans le désigner), de l'autre on se décorrèle de Observateur et on le définit directement par un autre patron de conception, uniquement sous un enjeu technique. Et dans les deux documentations, il est très clair qu'aucun pont direct avec le patron de conception Observateur n'est écrit. En tout cas, la page Sujet côté ReactiveX est abondamment alimentée à l'aide de diagrammes, dits diagrammes de billes, parfaits pour illustrer la stratégie d'architecture tuyaux et filtres (pipes and filters), décrit dans Pattern-Oriented Software Architecture (plus connu sous le petit nom de POSA).

Du côté de notre documentaliste préféré de patrons en tout genre, oui, je parle de Martin Fowler, l'approche de ReactiveX est catégorisée comme patron de programmation, sous le nom pipeline pour les collections (Collection Pipeline), qu'il définit comme étant une spécialisation de tuyaux et filtres. Bien sûr, aucun de ces termes n'est référencé dans la documentation de ReactiveX. Au final, cette partie Observateur, mise en avant extrêmement fortement par ReactiveX et ses dérivés, ne participe pas vraiment à la compréhension de ce qu'est ReactiveX et Observable. C'est à la limite dommageable pour ceux qui connaissent bien ce patron de conception, les emmenant sur des fausses pistes logiques.


Une note humoristique pour conclure : le terme observable avait été utilisé dans InterViews de Mark A. Linton et al. Un des des co-auteurs du GoF avait travaillé sur InterViews, le GoF étant un travail postérieur. L'observable de InterViews est identique au sujet du GoF. C'est comique non ?


Petite anecdote : côté Java, depuis plus d'un quart de siècle, la classe représentant le Sujet s'appelle java.util.Observable.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Tuesday 25 July 2023

Comprendre l'informatique avec l'héraldique

Parti : écartelé en sautoir ; au premier, d'azur chargé d'un écusson d'or à la croix de sable ; au deuxième, d'or à l'écureuil assis de gueules ; au troisième, aussi d'or au pin coupé de sinople au tronc de sable ; au quatrième, d'azur à la nef équipée et habillée d'argent voguant sur une mer du même mouvant de la pointe.

Cette description textuelle ne vous parle sans doute pas, par contre elle est normalement évocatrice d'images pour la personne pratiquant l'héraldique. On parlera volontiers pour ces vocabulaires et structures spécialisés de langage cryptique, cryptique, crypté, le premier parallèle ? Pas encore. Cryptique, qui est caché, qui n'est pas immédiatement compréhensible, déchiffrable ou identifiable. Déchiffrable, qui peut être traduit en clair, le plus souvent parce que la source à été chiffrée, transcrite en chiffres, ou en digits comme disent les anglophones. Pourtant pas de chiffres au sens propre ici, seulement un langage inconnu, pour lequel on se doute que chaque tournure, chaque mot, signifie quelque chose pour celui qui en a la connaissance, et va lui permettre de se construire une représentation, une image.

Les vocabulaires spécialisés ne datent pas de l'informatique, et s'ils suscitent généralement le mépris de la foule intelligente qui hurle à l'élitisme dès qu'un de ceux-ci est utilisé, il n'empêche qu'ils pavent nos domaines scientifiques : anatomie, botanique, génie militaire, génie civil, architecture, métiers de bouche, menuiserie... Pensez à n'importe quel domaine où la rapidité et la précision de la communication sont de mise, et vous aurez un vocabulaire spécifique. Le consulting ne fait évidemment pas parti de ces domaines : il ne faut pas confondre vocabulaire spécifique et enfumage à base d'anglicismes. Et n'oublions pas que l'informatique au sens de la French Tech est plus proche du consulting qu'autre chose. Revenons-en à nos moutons électroniques et à leurs rêves. Si ces vocabulaires spécifiques sont utilisés, c'est qu'ils sont utilisables et qu'ils améliorent le travail de leurs locuteurs. C'est un truisme certes, mais dans un monde éveillé à la post-vérité, il est important de ne pas passer à côté des choses simples.

On pourrait disserter à loisir sur la construction de ces vocabulaires, par analogie physique, par proximité sémantique, rarement par purs néologismes déracinés. Au fond peu importe la construction du mot à partir du moment où il devient un symbole mémorisable : les docteurs en médecine sont-ils vraiment versés en latin ? les programmeurs sont-ils vraiment connaisseurs des techniques de charpente et de tissage ? Vraisemblablement pas suffisamment pour reconstruire ces vocabulaires : c'est heureux, leur intérêt réside dans leur stabilité, pas dans la déconstruction permanente. Cette stabilité est matérialisée par ces symboles, qui ne sont pas directement porteur de sens, mais qui permettent de ne pas se perdre dans une narration ou un raisonnement ; ces symboles sont des marqueurs, des points de repère.

Que peut-on faire une fois qu'on s'est mis d'accord sur un vocabulaire spécifique, ou encore plus simplement sur une symbolique ? Énormément de choses. Par exemple en mathématiques on peut passer de l'arithmétique au calcul formel. En logique on peut passer à la logique symbolique (dont un des initiateurs est George Boole, bien connu des informaticiens, et pas que les amateurs de pétanque). Et si les calculateurs programmables dont on dispose nous permettaient d'aller au-delà des nombres et de travailler avec des symboles ? Ne pourrait-on pas dépasser la simple tenue d'un livre de comptes ? C'est ce qu'on fait Newell, Simon and Shaw en 1956 en écrivant le programme Logic Theorist, qui avait pour but de démontrer des théorèmes mathématiques par exploration d'arbres de raisonnement.

Pour faire cela, on utilise le calculateur pour manipuler des symboles, ce qui se fait assez simplement en affectant des noms à des nombres particuliers. Si je vous parle du nombre 65, ça n'évoquera sans doute rien de spécial pour vous ; pourtant, depuis une soixantaine d'années, c'est le nombre couramment associé au symbole "A majuscule". Les lettres ne sont rien de spécial pour un ordinateur, et encore moins la différence majuscule / minuscule, ça n'intéresse que les humains. Pourtant l'ordinateur permet de manipuler du texte, il permet d'effectuer des calculs sur des nombres placés dans des cases mémoires, et de temps en temps ces nombres sont transmis à des périphériques. Dans ces périphériques on trouve l'écran, un dispositif électronique qui nous restitue quelque chose que visuellement nous identifions comme un A, l'ordinateur pendant ce temps n'a manipulé qu'un nombre, le 65.

Par établissement de cartes de correspondance entre ces symboles et des nombres, puis par réutilisation de ces symboles pour créer d'autres symboles, on rentre dans le monde du numérique : tout est chiffre, même si nous avons l'impression de manipuler des concepts ou du texte. Le monde du numérique est infiniment plus profond que ce que le barbarisme digitalisation laisse entendre : il ne s'agit pas en effet d'introduire ses doigts on ne sait où, mais de profiter de ces strates cartographiques de symboles pour que ce qui fait sens pour l'humain puisse être accompagné par l'informatique. Ou bien l'inverse ?

L'informatique peut être définie comme la science du traitement logique et automatique du support des connaissances et des communications humaines, à savoir : l'information. Pour cela l'ordinateur, notre plus grande aide matérielle dans cette tâche, n'a pas besoin d'avoir la connaissance, ni de savoir réellement ce qu'est une communication : ces deux termes s'appliquent à l'humain, pas à la machine. De même l'informaticien n'a pas réellement besoin des connaissances manipulées, sinon les programmes de comptabilité n'existeraient pas, car comme on le sait, la comptabilité relève plus de l'ésotérisme que de la logique. Par contre, l'informaticien a besoin de connaître les symboles et la logique associés au domaine qu'il souhaite traiter, quitte à participer à une création de ceux-ci s'il n'y en a pas suffisamment de pré-existant. Sans ces éléments, on ne peut aboutir à l'heure actuelle à automatiser les traitements, c'est-à-dire à fournir à travers diverses couches symboliques des séries de chiffres à faire manipuler par les différents processeurs.

A l'avenir qu'en sera-t-il ? Pour l'instant les intelligences artificielles se contentent de s'appuyer sur une symbologie pré-existante, mais permettent dans une certaine mesure à ne pas avoir à décrire la logique associée. Ce sont les mécanismes d'entraînement qui vont permettre de capturer un comportement à travers des centaines, milliers, milliards d'exemples comportementaux. Ceci en espérant que la symbologie fournie est cohérente par rapport aux comportements que l'ont cherche à faire reproduire par ces modèles entraînés. Il arrivera sans doute le moment où l'on se contentera de lancer un entraînement général, duquel sortiront des couches de symbologie et des comportements associés, mais pour l'instant nous ne sommes pas arrivés à l'efficacité énergétique du corps humain et en particulier de son cerveau dans cet exercice. Mais le jour où ceci arrivera, seront nous capables d'appréhender ces symbologies inhumaines ?

Parti : écartelé en sautoir ; au premier, d'azur chargé d'un écusson d'or à la croix de sable ; au deuxième, d'or à l'écureuil assis de gueules ; au troisième, aussi d'or au pin coupé de sinople au tronc de sable ; au quatrième, d'azur à la nef équipée et habillée d'argent voguant sur une mer du même mouvant de la pointe.

Sunday 16 July 2023

Affordance trompeuse : le design

Ici nous parlerons de l'anglicisme qui a récemment bouleversé l'organisation de nos projets informatiques, et pas le fameux germanisme du dit Sein. Pas besoin de philosopher sur l'être pour savoir dans le cas présent qu'on est passé à côté de quelque chose. Surtout qu'à la place de cet être, on se rapproche du néant. Mais trêve d’existentialisme, le design est aujourd'hui synonyme de conception, on peut tout designer, tout concevoir, il suffit de faire appel aux bons designers, dont l'arme principale va être la facilitation graphique, ou le maquettage visuel. Ceci est doublé d'un autre mouvement, celui de la mise en avant de l'apparence, car dans le monde moderne, peu importe le fond, si la forme n'est pas séduisante, l'autre ne découvrira pas le contenu. Même si c'est le travail de l'autre de découvrir et d'acquérir le dit contenu. De là à dire que le professionnel moderne se comporte en amateur ? C'est une question que l'on va laisser pudiquement en suspens. Le designer est donc devenu la personne incontournable de toutes les étapes préalables à la réalisation, voire même selon certains indispensable à l'étape de l'assurance qualité, car qui d'autre qu'un designer peut être capable de contrôler la mise en œuvre d'un design ? Mais laissons cette fantaisie reposer tranquillement en prenant un pas en arrière.

Qu'est-ce que la conception ? Pourquoi avons-nous besoin de concevoir ? D'analyser ? Est-ce que ne ça ne ferait pas partie des notions que l'Agile a rendu caduque ? Le principe de la conception est de travailler au niveau du concept, de l'idée, de la représentation mentale d'une chose. Imaginer quelque chose c'est d'abord concevoir l'image de cette chose. Difficile de collaborer directement sur une représentation mentale, il faut en effet pouvoir la communiquer aux autres. La conception est aussi par extension le résultat de la transmission de cette représentation mentale, par des mots, par des schémas, par des sons... par tout ce qui peut susciter la recréation de cette représentation mentale.

Au mot design on associe traditionnellement la notion de visuel, souvent non fonctionnel, c'est-à-dire qui ne participe pas directement au fonctionnement de la chose. Est-on dans le vrai ou ne serait-ce qu'une déformation ? Demandons à la businessophonie : premier recensement en 1350–1400 ; de l'anglais moyen designen, du latin dēsignāre “marquer (d'une manière distinctive) / représenter / dessiner”. Si le verbe anglais to design a en effet dérivé vers l'activité de conception, voire de planification, il n'en est pas de même du verbe passé de mode to conceive, qui lui a gardé sa proximité avec to imagine. Ce rapprochement avec la planification et cet éloignement avec les représentations mentales font que ce design moderne est plus proche du dessin en tant que tel que comme vecteur de concepts. Si tout dans les phases amont à la réalisation se réduit au design, à des piles de dessins anonymes sans idées ou fonctions sous-jacentes, alors il n'y a plus de conception.

Peux-t-on concevoir sans représentation graphique, sans dessin ? C'est tellement difficile que les débats sur la schématisation dans l'informatique, souvent pour exprimer les concepts sous forme de modèles, sont permanents ces (au moins) soixante dernières années. Et il faut constater qu'arriver à un bon schéma demande très souvent un peu de compétences en design.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Sunday 4 June 2023

Affordance trompeuse : la refactorisation

Une affordance trompeuse assez légère, presque anecdotique, mais qui faisait parti de la liste d'origine de cette série.

Parlons refactorisation, ou plutôt parlons de l'abus de l'usage du terme. De nos jours, toute modification de code sans perspective d'évolution fonctionnelle est régulièrement appelée refactorisation, parce qu'il est connu qu'il y a eu une écriture initiale en des temps immémoriaux, et qu'il n'advient subséquemment qu'une suite sans fin de refactorisations pour l'amener vers la fameuse qualité. D'ailleurs Ward Cunningham n'a-t-il pas parlé lui-même de la refactorisation comme outil de remboursement de la dette technique ? Il le fait, a raison, parce que c'est Ward, il en a le droit.

Faisons un petit tour par l'origine du terme factorisation : il nous vient des mathématiques, plus précisément de l'algèbre, et il signifie l'opposé du terme développement. Coïncidence ? Beauté d'un vocabulaire spécifique à un domaine ? Poésie de l'informatique ? Sans rentrer dans les détails de la distributivité, on peut donner quelques exemples accessibles : 35 + 45 = 5 x (7 + 9), le 5 a été mis en facteur ; 18 + 24 = 3 × (6 + 8) = 6 × (3 + 4) = 2 × (9 + 12). Toutes ces formes sont strictement équivalentes, elles représentent le même nombre. Cela fonctionne aussi en l'exprimant sous la forme d'un dérivé de l'algèbre nouvelle : (a + b)² = a² + b² + 2 × a × b, cette forme factorisée à gauche, et développée à droite, est tellement remarquable qu'elle fait partie de la famille des identités remarquables. Remarquable non ? Bref, l'intérêt du principe de factorisation c'est que cela fonctionne, quelles que soient les valeurs auxquelles ont l'applique, car c'est le principe même de mise en facteur qui est rigoureusement prouvé.

Les anglophones sont donc partis sur cette thématique d'effectuer une nouvelle mise en facteur du code, d'abord afin de le compacifier et d'éviter les doublons, puis pour désigner toute opération de restructuration que l'on n'a pas vraiment besoin de tester pour savoir qu'elle ne changera pas le comportement du logiciel. Et il leur ont donné le nom de refactoring, non pas en référence à l'usine factory, encore moins à la fabrication to manufacture et à l'usinage to machine, mais bien à la mise en facteur to factor. Mais ça, les québecois sont complètement passés à côté en proposant réusinage, sans doute pour se caler sur les français proposant le cache.

Les techniques de refactorisation, qui par nature garantissent l'absence de modification du comportement, ne peuvent donc être que très précisément définies et en nombre relativement restreint. Et pourtant le terme est devenu synoyme avec le temps de n'importe quelle opération de retravail du code. Qui va s'en plaindre me direz-vous, à part quelques puristes sycophantes comme moi-même ? Dans ce cas précis, c'est une personne que nous avons déjà rencontré dans cette série sur les affordances trompeuses, en la personne de Martin Fowler. Le livre Refactoring : improving the design of existing code écrit par celui-ci est sorti en 1999, et a grandement contribué à faire connaître ces techniques, et est considéré par certains comme la bible sur la refactorisation. Oui, le même Martin Fowler qui a détruit toute la valeur de la métaphore de la dette technique, se plaint du mésusage du terme refactoring dans cet article de 2004. On peut y lire :

Je réalise que je suis sans doute en train de mener un combat perdu d'avance, mais je veux préserver la précision de la définition de la refactorisation. Il peut y avoir d'autres bonnes techniques pour restructurer, mais elles sont différentes. J'aimerais que nous soyons tous au clair sur ce que cela signifie quand nous utilisons ce mot.

Ah Martin, si seulement tu savais !


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Sunday 30 April 2023

Vingt ans

Ce blog a vingt ans, j'ai laissé passer la date, depuis plusieurs mois déjà. En même temps la forme du blog est elle-même dépassée. Y'avait-il véritablement quelque chose à fêter, après tant d'années d'abandon, et une timide résurrection à travers les affordances trompeuses qui n'ont de public que celui que je force à aller lire. Ce matin lors du footing hebdomadaire dans un petit bois avec mon comparse de perte de poids s'est échafaudée une stratégie : et si pour masquer cet oubli, je me contentais de fêter les vingt ans du premier article significatif ? Hélas, trois fois hélas. A la relecture de Building the infosphere, portals should revive du 27 novembre 2002, j'estime que cette stratégie est vouée à l'échec. Cet article, aussi imparfait soit-il, est le parfait représentant de ce blog : une fin qui ne correspond pas au début, un sujet technique qui n'intéresse que moi, et qui est toujours d'actualité. Pour le dernier argument ça ne s'applique pas forcément à tout ce que j'écris, certes.

Néanmoins, un des points clef de cet article est en quoi l'hypermédia est le cœur battant du Web : ce point est toujours brûlant d'actualité. A chaque fois qu'un "développeur Web" prononce les mots "REST API" ou "RESTful", il assassine un peu plus le Web. L'article se conclut sur une note d'espérance vers l'introduction d'un peu de sémantique, avec RDF. On sait tous ce qu'il en est advenu, avec le WHAT WG qui a mené a bien la transformation du navigateur Web en un successeur de l'IBM 3270, avant que son principal sponsor, Google, ne le replateformise en une grosse machine virtuelle JavaScript, sans arriver à se débarrasser du DOM, son échec le plus flagrant. La question générale de cette infosphère est elle aussi toujours d'actualité, dans le sens où elle est pour l'instant toujours intemporelle, et ce ne sont pas les quelques encyclopédies en ligne, et encore moins les ChatGPT et autres IA génératives dont le facteur wow n'égale que le manque de confiance qu'on devrait leur accorder, qui viennent y apporter une réponse.

Vingt ans et incapable d'être au rendez-vous. Vingt ans à radoter sur les mêmes sujets. Je ne suis plus le jeune vieux con qui soûlait ses collègues, un mot a été gagné, 6 octets économisés pour la planète. Mais n'ayez crainte, tant qu'il n'y aura personne pour subir librement ma logorrhée, je continuerai d'écrire et de forcer des gens à lire.

Sunday 9 April 2023

Affordance trompeuse : les bonnes pratiques

À travers la porte-fenêtre je vois le ciel bleu et le Soleil briller ; et pourtant, le terrain est glissant. Les bonnes pratiques sont devenues en effet une coquille d'abalone, un outil chamanique nécessaire, et jugé souvent suffisant, qui va magiquement mettre de l'ordre dans votre vie professionnelle. Qui n'a jamais vu ces petits prospectus promettant l'argent, la chance, le bonheur, les bonnes pratiques et le retour de l'être aimé ?

Dans l'imaginaire des entreprises il existe deux catégories : le bon professionel et le mauvais professionel. Le mauvais professionel pratique son métier, alors que le bon professionel pratique son métier, mais bien, parce qu'il a les bonnes pratiques. C'est la différence primaire entre les deux catégories, et, quelque part, c'est l'évidence même. Qui souhaite réellement être mauvais ? Qui ne veut pas bien exercer son métier ? Personne ! L'avidité de bonnes pratiques devient une démonstration de professionalisme, un marqueur du rayonnement de sa posture par rapport au fameux état de l'art. On ne peut blâmer les gens pour leur bonne pratique volonté, et il doit y avoir quand même quelque chose derrière ces mots, de moins magique, moins incantatoire.

Dave Snowden a créé en 1999 le cadre conceptuel Cynefin sur les épaules des géants, c'est-à-dire en suivant les bonnes pratiques de la recherche de ces domaines scientifiques. Dans ce cadre conceptuel, il définit cinq contextes décisionnels : clair, compliqué, complexe, chaotique et... confus. Le contexte décisionnel clair est caractérisé par une situation stable, et des relations de cause à effet simples ; dans un tel cadre, on peut déterminer quelles sont les meilleures pratiques. Pas les bonnes pratiques, les meilleures. Parce qu'entre deux façons de faire, deux façons d'agir, deux façons de modifier le contexte, comme les relations de cause à effet sont connues, alors ont peut déterminer quelle est la meilleure des deux. Dans le contexte décisionnel compliqué, la situation est connue, mais les relations de cause à effet ne sont pas immédiatement accessibles : il n'y a pas une bonne réponse immédiate, et encore moins une meilleure. On peut néanmoins dans un tel contexte décisionnel analyser plus finement la situation, avoir une évaluation prospective des prises de décision possible, et éventuellement arriver à cataloguer un certain nombre de prises de décisions types en fonction de l'analyse affinée : on entre ici dans le domaine des bonnes pratiques. Ce ne sont pas les meilleures pratiques dans le sens où l'on n'a pas la certitude de ne pas avoir mieux quelque part (sinon on serait dans le domaine clair), mais néanmoins le domaine est suffisamment connu pour dire que dans ce contexte, c'est pas pire (bitte comme disent les germains) de faire de comme ça mon petit bonhomme.

La foule qui est arrivée jusqu'ici s'exclamera que les bonnes pratiques existent donc bien et que je pinaille. Bien sur que non, aucune foule n'étant arrivée jusque là. Le problème ne se situe pas dans l'existence des bonnes pratiques, mais dans la croyance que d'en recevoir une liste va nous faire entrer dans le cénacle de l'expertise. Une bonne pratique a des conditions d'applicabilité, des limitations, des effets secondaires. Une bonne pratique s'active après une phase de diagnostic. Une bonne pratique c'est un médicament intellectuel.

Une bonne pratique, ça n'est pas automatique.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Saturday 4 March 2023

Affordance trompeuse : informaticien

 Ingénieur informaticien, je suis ingénieur informaticien, j'aime les ordinateurs, Windows 98 

Cette comptine a peut-être bercé vos jeunes années, et construit chez vous cette image de l'informaticien, si proche de la machine qu'il en est à la limite des troubles du spectre autistique. Il est souvent vu comme un codeur ou pire, comme la personne qui sait y faire avec ces choses-là, désignant par cette expression ce nouvel espace ésotérique de la cyberfantasy, qui va vraisemblablement dominer le monde avec ses IA, un monde résolument incompréhensible et qui fait peur... enfin tous les machins avec de l'électricité et des boutons en somme.

L'informaticien ne serait là-dedans qu'un vague initié, gravissant les premières marches le rapprochant sans jamais pouvoir l'atteindre du prochain GADLU ? Comme nous l'avions vu dans LA DATA, normalement non, il n'y a pas de magie dans l'informatique, mais tentons un autre prisme que cette définition institutionnelle. Prenons par exemple l'excellent Que sais-je sobrement intitulé  L'informatique  par Pierre Mathelot de 1969. Année éro... intéressante dans le sens où elle nous a laissé le temps de nous éloigner de la mécanographie pour vraiment entrer dans l'ère de l'ordinateur. Que nous dit Pierre ?

L'informatique peut être définie comme la science du traitement logique et automatique du support des connaissances et des communications humaines, à savoir : l'information. Ce qui veut dire que l'informatique comprend tout à la fois et de manière indissociable, les moyens du traitement et leur fonctionnement, les méthodes de traitement, et l'étude des domaines d'application.

Puis plus loin.

Les machines ont conduit à la création de nouvelles catégories de professionels. On peut distinguer cinq catégories : 

  • les perforateurs et les opérateurs (niveaux voisins de celui de l'ouvrier spécialisé) qui assurent la perforation des cartes et des bandes et le fonctionnement des divers organes de la machine ;
  • les programmeurs (niveau voisin de celui de l'étudiant en propédeutique) qui, comme leur nom l'indique, écrivent les programmes ;
  • les analystes et les chercheurs (niveaux voisins de celui des étudiants diplômés des universités et des grandes écoles) qui pour mission de concevoir les organigrammes et d'élaborer et maintenir les outils de base que sont les systèmes et les langages.

A la vérité, le métier d'informaticien (pour utiliser une dénomination plus générale) s'introduit de façon complémentaire dans tous les domaines où des hommes, aujourd'hui, doivent penser leurs problèmes, en les confrontant aux méthodes et aux moyens nouveaux qui leur sont offerts, et dont nous avons parlé au chapitre précédent.

Si le mot  information  n'apparaît pas en tant que tel dans  analystes et chercheurs , la trame sous-jacente est bien là, tellement évidente qu'elle n'est pas rappelée : l'informaticien travaille sur tout le spectre de l'information qui va de la conception jusqu'au matériel ; l'information support de la connaissance et des communications. Ce point étant éclairci, il reste comme d'habitude des problèmes aux interfaces, aux frontières : le DATA ANALYST est-il avant l'information, et ne serait donc pas un informaticien ? Ou ne pourrait-on pas considérer que le DATA ANALYST d'aujourd'hui ne travaille déjà plus sur des données mais directement sur de l'information ?


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Tuesday 27 December 2022

Affordance trompeuse : la Cyber

Notre monde est complètement cyber : cybermafia, cyberporn, cybersécurité, cybertrafic de drogue, cyberécologie, cybermarchands d'arme ; il était donc logique que les ESN et autres cabinets de conseil (ce qui n'a rien à voir avec la petite bibliothèque dans vos toilettes) s'engouffrent dans la brèche.

D'où vient ce mot à consonnance anglophone, qu'on prononcera d'ailleurs volontiers saille-beurre ? La première réponse est que cela vient de cybernétique, et tout de suite, cela sonne moins anglophone. La première vie de ce mot vient de Ampère, oui, le même que celui de l'intensité du courant électrique. Ampère écrivait dans la seconde partie de son Essai sur la philosophie des sciences :

Les relations de peuple à peuple, étudiées dans les deux sciences précédentes, ne sont que la moindre partie des objets sur lesquels doit veiller un bon gouvernement ; le maintien de l'ordre public, l'exécution des lois, la juste répartition des impôts, le choix des hommes qu'il doit employer, et tout ce qui peut contribuer à l'amélioration de l'ordre social, réclament à chaque instant son attention. Sans cesse il a à choisir entre diverses mesures celle qui est la plus propre à atteindre le but ; et ce n'est que par l'étude approfondie et comparée des divers éléments que lui fournit, pour ce choix, la connaissance de tout ce qui est relatif à la nation qu'il régit, à son caractère, ses mœurs, ses opinions, son histoire, sa religion, ses moyens d'existence et de prospérité, son organisation et ses lois, qu'il peut se faire des règles générales de conduite, qui le guident dans chaque cas particulier. Ce n'est donc qu'après toutes les sciences qui s'occupent de ces divers objets qu'on doit placer ici celle dont il est question et que je nomme Cybernétique, du mot χυϐερνετιχή, qui, pris d'abord, dans une acceptation restreinte, pour l'art de gouverner un vaisseau, reçut, chez les grecs même, la signification, tout autrement étendue, de l'art de gouverner en général.

En deuxième lettre de ce χυϐερνετιχή on reconnaît bien sûr un upsilon, qui en majuscule s'écrit ϒ, et qui en fonction du contexte se prononcera u ou y, ou v. Ou f. C'est important le contexte. Le kappa initial a pour translitération la lettre k, mais, il est arrivé pour le grec ancien d'avoir la lettre c à la place : "cyber", "kuber", c'est du pareil au même, juste une histoire de cartographie entre alphabets.

Plus tard et de manière indépendante apparaît dans les années 40 le mot cybernetics dans Cybernetics: or Control and Communication in the Animal and the Machine de Norbert Wiener :

Nous avons décidé d'appeler l'ensemble du domaine de la théorie du contrôle et de la communication, que ce soit chez la machine ou chez l'animal, par le nom de "Cybernétique", que nous formons du grec "χυβερνήτης" ou "timonier". En choisissant ce terme, nous souhaitons reconnaître que le premier article significatif sur les mécanismes de rétroaction est un article sur les gouverneurs, qui a été publié par Clerk Maxwell en 1868, et que "gouverneur" est dérivé d'une corruption latine de χυβερνήτης. Nous souhaitons également faire référence au fait que les moteurs d'assistance de direction d'un navire sont en effet l'une des formes les plus anciennes et les mieux développées de mécanismes de rétroaction.

We have decided to call the entire field of control and communication theory, whether in the machine or in the animal, by the name "Cybernetics", which we form from the Greek "χυβερνήτης" or "steersman". In choosing this term, we wish to recognize that the first significant paper on feedback mechanisms is an article on governors, which was published by Clerk Maxwell in 1868, and that "governor" is derived from a Latin corruption of χυβερνήτης. We also wish to refer to the fact that the steering engines of a ship are indeed one of the earliest and best-developed forms of feedback mechanisms.

C'est le retour du fameux Kubernetes ou timonier / pilote ; et le passage par le latin nous apprend que kuber- et gouver- c'est le même combat. On voit donc que dans le monde scientifique, le cyber / kuber c'est une question de gouvernance, voire de pilotage. Pour une entreprise de conseil, la cyber devrait donc s'incarner dans les prestations de conseil opérationnel et de gestion du changement. La cybersécurité, quel rapport avec la choucroute ?

Arrive 1982 et la nouvelle Burning Chrome par William Gibson.

That meant we were clearing fiberoptic lines with the cybernetic equivalent of a fire siren, but in the simulation matrix we seemed to rush straight for Chrome's data base.

L'équivalent cybernétique d'une alarme à incendie ? C'est ce qu'on appelle un signal tout simplement, rien de bien compliqué. Sauf si "cybernetic" est utilisé de façon trompeuse, ou que l'auteur utilise son droit d'artiste à jeter des mots au hasard. Mais est-ce vraiment un hasard ? Qu'en dit l'auteur ? Il s'est justement exprimé à ce sujet en 2013, et on peut voir l'extrait significatif ici, où il parle de son arène, du monde dans lequel allaient se passer ses histoires de science-fiction, à une époque où on délaissait le "space opera".

J'ai commencé à entendre parler de personnes qui connectaient des ordinateurs à distance avec des téléphones et parce que, heureusement, je ne connaissais absolument rien aux ordinateurs, j'ai été capable de mélanger tout ça et d'avoir cette vague vision de mon arène pour laquelle j'avais alors besoin d'un nom qui claque. Dataspace ça n'allait pas marcher et Infospace non plus mais Cyberspace... ça sonnait comme si cela signifiait quelque chose ou que cela pourrait signifier quelque chose... mais alors que je le regardais écrit au feutre rouge sur mon bloc-notes, tout mon plaisir était de savoir que cela ne signifiait absolument rien.

I started hearing about people who connected home computers distantly via telephones and because fortunately I knew absolutely nothing about computers I was able to sort of mush that all together and get this vague vision of my arena which I then needed a really hot name for. Dataspace wouldn't work and Infospace wouldn't work but Cyberspace... it sounded like it meant something or it might mean something but as I stared at it in red sharpie on a yellow legal pad my whole delight was that I knew it meant absolutely nothing.

Nous voilà rassuré, la Cyber, dérivée de la popularité du cyberespace de Gibson, vient donc d'une ignorance totale à la fois du monde du numérique mais aussi de la racine cyber- / kuber-. On peut parler d'ignorance², et remercier les cyberdivinités d'avoir échappé au Dataspace.

L'utilisation courante de la Cyber dans les ESN et autres cabinets de conseil est donc très "sale" (ou "commerciale" si vous ne parlez pas le "French for entrepreneurs") et dérivée non pas du produit des sciences concernées vendues par ces entreprises, mais du renouveau de la science-fiction des années 80 aux states.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Friday 11 February 2022

La stratégie du didjeridou

Une question se pose régulièrement dans nos entreprises de services, rongées par la peur de ne plus rien avoir à proposer : comment faire durer les projets le plus longtemps possible ? Nous ne sommes pas seuls dans cette interrogation : nous accompagnons le client, lui-même dans une expectative. En effet, que faire après l'accomplissement ? Comment passer à autre chose ? Comment envisager le beyond ?

C'est ainsi que nous avons des stratégies, forgées sur des décennies de pratique. L'une d'entre elles est la stratégie du didjeridou, cet instrument de musique aborigène, qui grâce à la respiration circulaire permet de s'évader sans heurt dans le confort ouaté de la stase. Le confort, c'est important, voire primordial. C'est ce qui a causé la perte de la stratégie précédemment en vogue, celle dite de "l'effet tunnel", qui a la même finalité mais avec des conséquences proche de la gueule de bois : rien de tout ça avec le didjeridou, qui est vraiment doux.

Quels sont les principes fondateurs de cette stratégie ? Comment arriver à cette douceur ? Un schéma valant mieux qu'un long discours, voici la boussole de l'ignorance qui va vous permettre de vous orienter dans sa mise en œuvre.

Quelques explications pour combler l'aridité d'une telle représentation, bien que cela aille avec une certaine représentation de l'Australie. A part pour quelques projets conduits sur le principe de la cascade (ou Waterfall en français de La Tech)(ce que je n'ai jamais vu en vingt ans de carrière), un projet se déroule généralement en une succession cyclique de quatre étapes :

  1. la conception : où l'on définit précisément ce que l'on souhaite faire
  2. la réalisation : où l'on fait ce qui a été défini
  3. la réception : où le commanditaire peut profiter de ce qu'il a commandé (ce qui a déclenché la conception)
  4. la rétrospective : où l'on regarde ce qui s'est passé depuis le début du cycle dans une démarche de progrès

A chaque étape est associée une forme de contrôle, dont les noms varient avec le temps et les modes :

  1. DoR : Definition of Ready, un ensemble de règles à appliquer qui permettent de s'assurer que la conception est suffisamment aboutie pour qu'on puisse partir en réalisation
  2. DoD : Definition of Done, un ensemble de règles à appliquer qui permettent de s'assurer que ce qui a été réalisé est suffisamment abouti pour être livré
  3. AQ : l'assurance qualité à la réception, où l'on s'assure de la qualité, c'est-à-dire des caractéristiques, de ce qui a été livré
  4. REX : le Retour d'EXpérience, qui permet de cristalliser les points marquants du cycle, et en particulier de dégager un plan d'actions pour s'améliorer lors du cycle suivant

Avec toutes ces étapes de contrôle, comment peut-on atteindre notre objectif initial d'inachèvement ? C'est la qu'intervient la stratégie du didjeridou, qui est basée sur une gestion de la connaissance centrée sur l'ignorance. Contrairement au Fashion Driven Programming qui est basé sur l'oubli, nous sommes ici sur une gestion douce et consensuelle de la connaissance acquise. On sait que la conception n'est pas suffisamment aboutie ? Poubelle, on passe à la réalisation. On a contrôlé que la réalisation n'était pas finalisée ? Poubelle, on livre quand même. Le commanditaire a vérifié que c'était parti de travers ? Poubelle, de toute façon on aime bien travailler ensemble. On est tous d'accord pour dire que si on ignore les résultats des contrôles on ne pourra pas finir le projet ? Poubelle, est-on seulement ici réellement pour le finir !

Et c'est ainsi que dans une grande respiration circulaire de projet, on peut, sans heurt, sans animosité, sans hard feeling (comme on dit en français de LaTeX), faire durer un projet à l'infini.

Respiration circulaire

Wednesday 29 December 2021

Déclencher une réaction

S'expliquer, toujours. J'ai écrit la précédente entrée "l'anglais est universel" dans la série des affordances trompeuses alors que ça n'était absolument pas prévu, ni même envisagé. Pour que cela soit arrivé, il eut fallu un déclencheur fort, et celui-ci est un magazine que je lis régulièrement depuis plusieurs années maintenant : Hackable, édité par les éditions Diamond, qui arborent fièrement le logo de l'Alsace dans l'ours, et précisent qu'ils sont imprimés en Allemagne. Je me demande ce que signifie le mot "diamond" en alsacien... ou en allemand. Est-il besoin de préciser que j'apprécie beaucoup ce magazine ? Dans l'internet moderne oui. Et après cette précision, sur laquelle s'arrêteront les internautes modernes qui sont limités à 500 signes, discutons de ce déclencheur.

Hackable est un magazine annoncé pour "découvrir et progresser dans les domaines de l’électronique numérique et de l’embarqué", et c'est la réalité. Une deuxième réalité est qu'Hackable est là pour dire combien les utilisateurs de Linux sont plus intelligents parce qu'ils ont choisi Linux, combien Microsoft c'est le mal, combien les utilisateurs de Windows n'ont pas vu la lumière mais qu'ils peuvent arriver à se débrouiller tout seuls, et combien les utilisateurs de Linux sont au final stupides vu qu'on leur donne toutes les instructions à la virgule près. Tant que le premier objectif est rempli, on peut passer outre les débordements engendrés par le deuxième.

Arrive donc le n° 39, et un article intitulé "Pilotez un moniteur VGA avec un devkit ESP32", titre qui n'est pas trompeur, et même si on aurait aimé plus d'ESP32 et moins de Linux, c'est une très belle ouverture. Et dedans, on tombe sur cette digression :

Oui, les messages sont en anglais, ce qui est non seulement ma préférence générale puisque l'anglais est la langue de l'informatique, n'en déplaise à certains « toubonistes » (référence pour les vieux), mais ici cela évite d'obtenir n'importe quoi à l'écran étant donné que l'IDE Arduino utilise UTF8 et ne permet pas de choisir son encodage (contrairement à VSCode).

Beaucoup de choses à dire ici :

  • je suis vieux
  • la sélection de l'encodage dans VSCode n'a pas suivi un chemin tranquille
  • "obtenir à l'écran" quand on parle de manipulation de terminal et plus loin de polices de caractères, c'est-à-dire quand on est en plein dans le sujet de la notion d'encodage, c'est truculent
  • si l'anglais est devenu la langue des codeurs doux-heurt mais cœur, ça ne peut pas être la langue de l'informatique (cf. article déclenché)
  • quel est le problème de plaire ou de ne pas plaire aux "toubonistes", le but n'est-il pas de transmettre une connaissance ? Ce but est-il atteint ?

Derrière cette phrase, on sent l'énervement bien compréhensible du rédacteur technique qui n'a pas envie de retoucher au code mis en forme en période de bouclage. Concentrons-nous donc sur l'essentiel : à quoi ressemblent ces messages ?

Enable get Wifi. Rebooting...

HA (vous êtes ici invités à chercher le méme animé qui vous sied à base de Dieuni). Ce message est destiné aux personnes qui regardent l'écran piloté par l'ESP32. Tentons la traduction en français avec Gogole pour essayer d'y voir clair, vu que je ne maîtrise pas cette grammaire : "Activer obtenir le wifi. Redémarrage..." Étrange, rien dans le programme ne permet d'activer ou de désactiver le Wi-Fi (avec un tiret et des majuscules, comme la marque). Lisons le programme (ce que l'utilisateur n'est pas censé faire) : sans doute une petite faute typographique, avec un E à la place d'un U pour Enable. Gogolisons une nouvelle fois : "Impossible d'obtenir le wifi. Redémarrage..." C'est un peu plus logique, mais pas complètement convaincant : pour avoir le Wi-Fi, il suffit d'avoir la puce adéquate, or il n'est pas possible en pratique d'enlever matériellement la partie Wi-Fi sur un ESP32. Continuons à lire le programme pour voir ce qu'il s'y passe quand on réussit à avoir une connexion au réseau par le Wi-Fi.

WiFi connected

HA (yada yada). Diantre.

Le message initial aurait-il été correct et compréhensible, aux accents près, eut-il été écrit en français ? Mon opinion est que cela est très vraisemblable. Hic jacet causa (en latin de Gogole).

Affordance trompeuse : l'anglais est universel

Dans certains domaines, et en particulier celui du logiciel (on ne parle pas ici d'informatique, cf. LA DATA), l'impérialisme anglais a fait son chemin. La croyance répandue est qu'en écrivant le code et les commentaires intégralement en anglais, non seulement ceux-ci deviendraient universellement compréhensibles par tous les codeurs, mais le résultat obtenu serait intrinsèquement meilleur, car non pollué par les affres de sa langue maternelle qui est plus éloignée des langages de programmation.

Cette foi en l'anglais comme seule langue de communication est une partie du credo de ceux qui ont élevé le codage à un niveau religieux, et, forcément, qui rentrent dans l'évangélisation. Ceci n'est pas un problème en tant que tel, le monde du logiciel (et encore plus côté matériel) est peuplé de fanatiques qui s'entrecroisent et s'invectivent au nom d'une rationalité qui a été foulée des doigts boudinés depuis bien longtemps, et remplacée le plus souvent par du FUD (qui n'est malheureusement pas une affordance trompeuse). Revenons au sujet.

Un programme informatique est une œuvre littéraire triple : elle parle d'un sujet dit "métier" à une double audience, d'un côté des programmeurs et de l'autre des interpréteurs de code (qu'ils soient compilateurs ou machines virtuelles)(et, ce, sans aller jusqu'à la programmation lettrée au sens de Knuth). On peut sortir de la réflexion les interpréteurs de code : ils ont leur propre langage (C, BASIC, Logo, Java, JavaScript, Brainfuck, Ladder, SCXML... : à chaque jour son langage), qui n'est pas l'anglais.

Rentrons dans le sujet par le "métier". Imaginons l'écriture d'un programme pour l'assistance à l'arbitrage de l'escrime : le français est la langue officielle au niveau international, et au niveau national, on utilise une langue locale. Prenons le judo : le japonais est la langue officielle au niveau international et très souvent au niveau national, en utilisant une transcription romane pour l'écrit. Prenons une autre discipline sportive : le droit. En France, le droit n'est ni de type romano-germanique ni de type common law. Dans ce petit éventail d'exemples, il n'y a rien de naturel, rien d'évident à imposer une traduction vers l'anglais. Celle-ci pénalise deux publics : ceux qui connaissent le "métier" n'auront de cesse de chercher le terme d'origine, et ceux le connaissant peu se verront freinés dans leur acquisition de connaissance par cet intermédiaire qui les coupe des références. On peut d'ailleurs considérer que ces traductions du "métier" sont un facteur primaire de dette technique.

Venons-en à la communication entre programmeurs : on se plait volontiers à penser un ensemble homogène de coders / doers / makers où tout le monde va se comprendre intuitivement parce que c'est de l'informatique ma bonne dame. Comment imaginer une homogénéité dans une population qui ne cesse de rejeter l'informatique au profit du codage et des guerres de clocher (cf. supra) ? Une population qui refuse de conceptualiser et ne veut voir que des outils ?

En supposant que l'on souhaite réellement transmettre de la connaissance à ses collègues codeurs, et pas juste les laisser avec du code destiné aux machines, que fait-on quand on n'a pas la certitude que l'autre est sur la même longueur d'onde ? Va-t-on chercher à être plus explicite, ou au contraire, va-t-on rajouter une surcouche sur le message que l'on souhaite passer ? Dans une langue que l'on va moins maîtriser ? Dans les faits, c'est le deuxième cas qui se produit le plus souvent. Dans combien de programmes dont aucun non-francophone ne lira jamais le code, ces écrits ne sont compréhensibles que par une traduction mot à mot ? Et quand bien même, quand les codeurs ne font pas la différence entre une stack et un heap, entre une layer et un module, entre un service et une API, quand les mots sont vidés de leur sens pour ne plus être que les étiquettes composant la folksonomie d'une chapelle, alors cet anglais forcé n'est plus que le clou fermant le cercueil de la transmission de connaissance.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Friday 24 December 2021

Inférences

Tout a commencé par Benzaie, qui utilisa en fond sonore une musique qui a capté mon attention, musique qui était un remix :

Puis il y a eu la découverte de la musique originale, et d'un passage télé "dans l'air du temps" :

Quelques années plus tard, vint l'Eurovision, et la surprenante prestation des islandais :

Et par un hasard extrême, je me suis retrouvé à visionner la prestation de Maya pour de Lait de Coco sur FR3... avec la musique de Daði og Gagnamagnið en fond. Et ça collait. Enfin par moment ça collait. Qui l'eut cru que ce rythme, cette ambiance, cette chaleur, seraient si proches ? Il fallait en faire quelque chose. Partir à la recherche de logiciels de montage vidéo. Se rendre compte qu'ils étaient déjà installés : un montage autour d'une photo amusante de Jill et John, dont la diffusion était restreinte. On pourrait se dire que la passer sur ce bloug, public, va augmenter sa diffusion, mais il n'en est rien.

Alea jacta est, le sort est jeté, le travail commence, long, répétitif, ardu. Et on abandonne en cours de route, sans atteindre la perfection souhaitée, mais en ayant atteint un point d'étape significatif, qui restera vraisemblablement le point final.

Saturday 25 September 2021

Affordance trompeuse : API

Une API est une interface (i.e. la frontière entre deux choses) utilisée dans l'action de programmer des applications. On décrit la liste des opérations disponibles, avec pour chacune ce dont on a besoin, et ce qu'on aura en retour. Pour les informaticiens et en version longue, ça se passe du côté de C'est le printemps, bientôt les API vont éclore, sinon restez ici.

Analogie dans le monde du spectacle :

  • L'opération "donner un concert" demande des artistes et des instruments, et permet d'obtenir en retour un concert
  • L'opération "donner un encore" demande des artistes en tenue décontractée et des instruments, et permet d'obtenir en retour un encore

La tromperie est dans le fait d'utiliser le terme API pour désigner l'exécution de l'opération. En langage courant :

  • "Je suis allé à donner un concert hier soir, c'était génial ! On était très près de la scène pour le donner un encore, un grand moment de communion !"
  • "Venez tous à la pendaison de crémaillère pour fêter l'emménagement dans notre nouvelle signature d'un acte de vente !"

Ou en faisant la confusion dans l'autre sens :

  • "J'ai été déçu par cette interprétation à la Philarmonie, trop de fausses notes dans la partition."
  • "On a une grosse fuite d'eau, c'est un vice caché du schéma de plomberie"

Pour les informaticiens utilisant API en ce sens, allez leur demander la différence entre GPL et LGPL, la tromperie deviendra limpide. Ils ne pourront pas se baser sur Wikipedia étant donné que les pages françaises et anglaises sur la LGPL font l'impasse sur le terme "interface", qui est la clef de voûte de cette différence.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Sunday 2 May 2021

Affordance trompeuse : dette technique

Depuis quelques années, le vocable "dette technique" est à la mode. Dans le langage commun du développeur, ce terme est synonyme de tout ce qui ne lui plaît pas dans le code, et que le méchant management ne lui laisse pas changer. Les causes d'insatisfactions sont nombreuses, ceci allant du non-respect des "bonnes pratiques" jusqu'au #cépamoderne en passant par la volonté de faire de la compta en virgule flottante. Pourquoi ce nom de dette technique ? On se verra répondre que si on ne le fait pas (sous-entendu, le bien), alors on le paiera plus tard. Soit. Mais selon quelles modalités ? Est-ce grave de payer plus tard si cela est sans frais ? La modernité dans la tech ayant une durée de vie de six mois, est-ce qu'il ne vaudrait pas mieux attendre ? Devant une telle définition de la dette technique, on est effectivement tenté de répondre avec une locution à peu près aussi définie : un tiens vaut mieux que deux tu l'auras.

On peut se demander si cette expression est arrivée à être diffusée uniquement sur sa proposition de "boîte à contrariétés". La réponse est évidemment non, sinon on ne serait pas dans la série des affordances trompeuses. Presque vingt ans après avoir créé cette métaphore, Ward Cunningham l'explique très bien dans cette courte vidéo. Celle-ci n'ayant pas de sous-titres français, et devant l'absurdité de regarder une image mouvante pour ce qui tient en quelques lignes, je vous en propose ici une transcription traduite.

J'ai commencé à m'intéresser à la façon dont les métaphores influencent notre façon de penser après la lecture de "Metaphors We Live By" de George Lakoff et Mark Johnson. Une idée importante est que nous raisonnons par analogie avec les métaphores qui sont entrées dans notre langage.

 

J'ai inventé la métaphore de la dette pour expliquer la refactorisation que nous faisions sur le produit WyCash. C'était un produit développé en Digitalk Smalltalk et il était important pour moi que nous reflétions les connaissances acquises à propos de l'application au cours du temps, en modifiant le programme pour qu'il ait l'air d'avoir été écrit comme si nous avions eu cette connaissance depuis le début, et comme si c'était la façon naturelle de le faire en Smalltalk.

 

L'explication que j'ai donné à mon chef, et on parle de logiciel dans le domaine de la finance, était une analogie financière que j'ai appelée la métaphore de la dette, qui dit que si l'on échoue à aligner notre programme avec ce que l'on a compris de la bonne façon de penser nos objets financiers, alors nous allions continuellement buter sur cette divergence, et que cela nous ralentirait de la même manière que de payer les intérêts d'un emprunt.

 

En empruntant de l'argent vous pouvez faire des choses plus vite que sans, mais jusqu'au remboursement complet, vous payez des intérêts. Je pensais qu'emprunter de l'argent était une bonne idée. Je pensais que se dépêcher de sortir le logiciel pour avoir de l'expérience avec était une bonne idée mais, évidemment, vous devez finalement revenir en arrière et, à mesure que vous apprenez des choses sur ce logiciel, vous allez rembourser cette dette en refactorisant le programme pour refléter cette expérience acquise.

 

Je pense que dans de nombreux cas les gens se dépêchent de sortir le logiciel et n'y réintègrent pas cet apprentissage, et par analogie, ont emprunté de l'argent sans avoir l'intention de le rembourser. Il va sans dire que si vous faites ça avec votre carte de crédit, à la fin toutes vos rentrées d'argent partent dans les intérêts, et votre pouvoir d'achat est nul.

 

Dans le même ordre d'idées, si vous développez un programme pendant longtemps en ne faisant qu'ajouter des fonctionnalités, et que jamais vous ne le réorganisez pour refléter votre compréhension de ces fonctionnalités, alors il arrivera un moment où il n'y aura plus de cohésion dans le programme, les efforts pour travailler dessus prendront de plus en plus de temps. En d'autres termes, les intérêts occuperont toutes vos rentrées et vous ne progresserez plus.

 

Beaucoup de personnes, tout du moins de bloggueurs, ont expliqué la métaphore de la dette en, je pense, la confondant avec l'idée que l'on peut écrire vite-fait du code avec l'intention de faire mieux plus tard, et que ceci était la première cause d'endettement. Je ne suis jamais pour écrire du code vite-fait, je suis pour écrire du code qui reflète votre compréhension présente d'un problème, même si cette compréhension est incomplète.

 

Si vous souhaitez vous endetter en développant un logiciel que vous ne comprenez pas complètement, alors il est sage de faire un logiciel qui reflète au mieux votre compréhension. Quand le temps de la refactorisation arrive, cela permet de voir clairement ce que vous pensiez alors et ainsi de rendre plus facile la transformation en ce que vous pensez désormais.

 

En d'autres termes, cette métaphore de la dette, ou de la capacité à rembourser la dette, pour qu'elle puisse fonctionner pour vous, dépend de votre capacité à écrire du code suffisamment propre pour pouvoir être refactorisé une fois que vous aurez compris le problème.

 

Je pense que c'est une bonne méthodologie qui est au cœur de l'eXtreme Programming. La métaphore de la dette est une des nombreuses explications au fait que l'eXtreme Programming fonctionne.

La dette technique actuelle est donc une version allégée, fade et sans réel intérêt, de la métaphore de la dette de Cunningham, qui est, elle, une justification de l'amélioration continue appliquée au développement logiciel, en partant du principe que si l'on n'a pas la compréhension nécessaire pour finir la conception, on peut quand même développer le logiciel (en s'endettant), à condition de revenir sur cette conception une fois que cette compréhension est acquise (remboursement de la dette). La métaphore de la dette est une question de gestion de la connaissance.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Wednesday 28 April 2021

Affordance trompeuse : la qualité

La "qualité" est un grand mème des programmeurs, qui n'est jamais trop loin de son compagnon "modernité". Les grincheux me reprocheront ici normalement d'ergoter sans raison, parce que la qualité c'est le bien, et le bien doit être encouragé. C'est justement là que se situe la tromperie.

Comme il nous est rappelé dans le TLFi, la qualité est premièrement une caractéristique de nature, bonne ou mauvaise, d'une chose ou d'une personne. Bonne ou mauvaise. Parler de qualité n'est pas parler ni du bien ni du mal, parler de qualité n'est pas parler de moralité d'une chose, mais de sa caractérisation par rapport à sa nature, à son être.

Le travail de programmation n'implique d'ailleurs qu'à la marge ce travail de caractérisation. Par contre, il est important pour le programmeur d'arriver à produire quelque chose de conforme à la caractérisation attendue, aux qualités attendues. Ceci est l'activité d'assurance qualité. Et quand cette assurance qualité conclut à un résultat positif, alors on peut dire qu'on est en face d'un logiciel "de qualité", c'est-à-dire qu'il se comporte comme on le souhaite, ou plus précisément, conformément aux souhaits exprimés. Dans la pratique, cela revient à démontrer que l'on répond aux exigences, soit par une preuve formelle, soit par des tests. Bon, ne nous voilons pas la face, ça fait bien longtemps que l'industrie a fait une croix sur les preuves formelles, ça demande beaucoup trop de travail et personne n'a trouvé de belles photos dans les banques d'images pour mettre ça en diapositives dans des conférences inspirantes.

Est-ce que le fait que Facebook continue de me bombarder de photos de chats, après dix ans d'expression continue de mon désintérêt voire mon aversion envers cette pratique cruelle de garder en captivité des OGM carnivores, en fait un logiciel de mauvaise qualité ? On ne peut répondre correctement à cette question qu'en ayant connaissance du comportement attendu par ses concepteurs. Contrairement à l'utilisation courante du terme, la qualité en informatique est pensée, décidée, en un mot, conçue : ça n'est pas une projection de valeurs morales sur le produit ou le service.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Thursday 25 March 2021

C’est le printemps, bientôt les API vont éclore

La disruption joyeuse

Les gros titres fleurissent : « Les API : clef de voûte de l’open banking », « Les API au cœur de la transformation digitale », « De l’économie des applications vers une économie des API : une révolution est bien en marche ! ».

Mais, que sont ces fameuses API, les bolcheviks d’une nouvelle révolution heureuse, à la fois structure, moteur et objectif ?

Que sont ces êtres nouveaux et disruptifs, portés par les hérauts du transformisme ?

Une partie nous vient de la révolution numérique, avec l’explosion des capacités de calcul. Barbara Liskov (autrice du fameux principe de substitution) écrivait à ce sujet en 1979 dans Primitives for Distributed Computing :

Auparavant, des considérations économiques favorisaient le partage d’un unique ordinateur entre de nombreux utilisateurs et le travail du système d’exploitation concernait le support et le contrôle d’un tel partage. Cependant, la nécessité de partager une ressource unique et coûteuse est désormais moindre. Les avancées dans les technologies matérielles ont amenées de grandes économies de coût pour les processeurs et la mémoire. Une conséquence possible de réduction des coûts est une nouvelle organisation logicielle, où des sous-parties d’un programme résident et sont exécutées sur différents ordinateurs connectés en réseau. Nous appellerons de tels programmes des programmes distribués.

Une des premières raisons pour lesquelles les programmes distribués sont souhaitables est que les organisations utilisant ces programmes sont elles-mêmes distribuées. Par exemple, une affaire est divisée en plusieurs sous-divisions. Chaque division a ses propres responsabilités, et met en œuvre des procédures internes sur ses données internes. Cependant, ces divisions fournissent des services pour les autres, de telle sorte qu’il est nécessaire d’avoir de la communications entre elles. Ces divisions peuvent être proches physiquement, ou au contraire dispersées géographiquement.

Une vrai révolution

Cette révolution de la programmation distribuée consiste donc en la mise à disposition de services à d’autres sous-parties d’un programme, et par programme on ne parle pas d’une unité d’exécution mais l’ensemble logique de tous les traitements. Pour s’organiser dans le programme, il va falloir matérialiser quelque part la description de la structure d’échange avec ces services, quel formalisme nous a été apporté dans cette révolution ? Continuons la lecture pour le savoir : l’article prend pour exemple une application de réservation de vols ; la notion de gardien (guardian) utilisée désigne le protecteur du sous-ensemble applicatif qui expose des services :

Notre solution est d’envoyer les messages à des ports. Un port est une passerelle monodirectionnelle vers un gardien. Il peut y avoir plusieurs ports pour un seul gardien ; chaque port appartient à un gardien, et seuls les processus à l’intérieur du gardien peuvent recevoir des messages de celui-ci.

Les ports sont les seules entités ayant un nom global. Quand un gardien est créé, il fournit un ou plusieurs ports ; les noms de ces ports sont communiqués au processus qui les a créé. Les noms de ces ports peuvent aussi être envoyés dans des messages ; ceci implique que les messages peuvent être envoyés à ces ports depuis plusieurs sources différentes. Il est attendu que les ports fournissent une forme de zone tampon pour que les messages puissent être mis en file d’attente si nécessaire.


Les ports sont décrits par la description des messages qui peuvent leur être envoyés. Par exemple, un port pour l’un des gardiens régionaux peut être décrit comme suit :
port_régional = port[réserve(numéro_vol, id_passager, date)
      replies (ok, plein, liste_d_attente, pre_réserve, vol_inconnu),
   annule (numéro_vol, id_passager, date)
      replies (ok, non_réservé, vol_inconnu),
   liste_passagers (numéro_vol, date)
      replies (info (liste_passagers), vol_inconnu)]

Notez que chaque message de requête est appairé avec un message de réponse attendu. Ces parties replies sont en fait une description d’un argument additionnel du message : un port qui peut recevoir les réponses attendues. Cette syntaxe met tout simplement en valeur la nature requête-réponse de la relation. La partie replies est omise si le message n’a pas de réponse attendue.

L’entête d’une définition de gardien liste un ou plusieurs ports qui peuvent être utilisés avec une instance de gardien, par exemple :
gérant_régional = guardiandef() provides p: port_régional
    % définition d’un programme séquentiel à exécuter
    % quand une instance de gérant_régional est créée.
    % p est une variable locale à ce programme
    end gérant_régional

[…]
Les types de port et les entêtes de gardien permettent la vérification au moment de la compilation de tous les messages échangés.

Ici nous avons traduit le terme anglais « port » par le terme français « port ». L’étymologie de ce terme est assez intéressante, les dictionnaires Oxford nous disent : « Old English (in the sense ‘gateway’), from Latin porta ‘gate’; reinforced in Middle English by Old French porte. The later sense ‘opening in the side of a ship’ led to the general sense ‘aperture’. » Ce terme anglais de « port » a été retranscris dans le cadre informatique par « port » comme anglicisme, alors que nous aurions dû utiliser « porte », car c’est bien l’esprit de la porte qui transpire par ce « port ». Néanmoins, on voit que dans ce terme on trouve aussi le sens de passerelle (gateway), ce qui montre qu’on n’a pas juste l’idée d’un contrôle ponctuel, mais bien un passage.

Dépasser la résistance au changement

Et là le pékin moyen se demandera quelles sont donc les différences fondamentales entre les API Gateway d’aujourd’hui et ces notions de ports d’hier. Ne faisons pas durer le suspense inutilement, la réponse est très simple : il n’y en a pas. Cela mérite néanmoins quelques éclaircissements au milieu de la nuageuse tourbe conceptuelle issue du Web deux point zéro. Le terme API, pour Application Program Interface ou interface pour logiciel applicatif (qui a dérivé en Application Programming Interface ou interface pour programmation logicielle), est un terme assez récent, apparu selon les recherches de Joshua Bloch en 1968 dans Data structures and techniques for remote computer graphics par Ira W. Cotton :

Normalement, on désire que l’interface entre les logiciels applicatifs et le système soit réalisée à travers des appels de sous-routines de type FORTRAN.

Le système a été conçu pour être, pour l’essentiel, indépendant du matériel dans le sens où l’implémentation […] pourrait être recodée pour un matériel différent ou amélioré, tout en maintenant la même interface l’un envers l’autre et avec le logiciel applicatif

Le mot français « interface » est tiré directement du mot anglais « interface » qui signifie : « surface à la frontière entre deux parties de matière ou d’espace » ; par cette définition, une interface est immatérielle, elle est à la frontière entre deux réalisations.

Même si le titre de l’article contient le mot remote, nous ne sommes pas ici dans une logique de programmation distribuée : ce terme fait référence à l’accès distant à travers une interface graphique (un terminal) à une ressource centralisée. L’API est le nom que l’on donne au moyen logique pour utiliser un sous-programme, et l’on souhaite que cette API reste la même dans le temps, y compris dans le cas où le sous-programme est recodé, quitte à effectuer une nouvelle compilation (en particulier lors d’un changement de matériel). L’intérêt de cette notion d’API est celui de la contractualisation, l’API et sa documentation associée décrivent la sous-routine appelée, les paramètres entrant et sortant, et permettre d’avoir la garantie de la régularité de l’invocation de cette sous-routine dès la compilation.

Vers l’infini et au-delà

On voit donc que l’API est une notion liée à l’organisation de l’écriture des programmes, et pas une notion liée à leur exécution. En conséquence, le terme API Gateway ne peut désigner qu’une passerelle menant à… des éléments d’organisation de sous-programmes ? Une telle irrationalité, bien que commune dans le monde du fashionable IT (qui n’a jamais entendu d’absurdités telles que « architecture Web MVC », « API REST » / « API Rest », « l’architecture hexagonale est liée à l’inversion de dépendance », ou encore pire « REST avec JSON » ?), pose quand même question : quelle agence de communication a pu penser à un tel nom ? Force est de constater que trouver la réponse à cette question est difficile, à tel point que Wikipedia ne donne aucune origine à ce terme, sans doute issu par génération spontanée autour d’un vide Gartnerien. Ceci aurait pu être compréhensible pour un mot issu d’une langue morte, mais pour une expression plus récente que l’encyclopédie elle-même, c’est un peu déconcertant, et le reste des explications des pages considérées sont à l’avenant. Tout au plus peut-on subodorer que c’est une conséquence du lobbying anti-XML qui ne nous aura décidément pas donné une belle image de la probité intellectuelle dans le monde de l’informatique.

Comme tous les termes saccagés par les révolutionnaires de la disruption collective, API est destiné à rester en tant que mauvais synonyme de « service et une de ses API associée ». Pour sa santé mentale, il suffit de garder à l’esprit qu’une API Gateway est une passerelle vers des services et pas vers une API, et que l’API Management ne sert pas à gérer des API mais à inventorier des points d’entrée vers des services en y associant un contrat d’interface, tout en y mêlant des notions de politiques d’accès. Et pour la vérification à la compilation ? Ça n’a pas de sens dans le monde merveilleux des API : un programme n’a pas à être stable, il doit s’adapter à ces API qui changent en permanence, parce que « aujourd’hui le monde va plus vite qu’hier, mais moins que demain ». Décidément, le monde des API est en contradiction avec celui des API.

Note : cet article a été initialement publié sur le défunt blog tech.

Sunday 24 January 2021

Affordance trompeuse : le data center

Après quelques aller-retours ces 40 ou 50 dernières années, le data center est à nouveau à la mode, en particulier parce qu'il se doit d'être vert. Le data center est en effet aujourd'hui le lieu où se matérialise le cloud computing. Data ? Computing ? Cela vous rappelle évidemment l'affordance trompeuse LA DATA ! Autant LA DATA est trompeur en français, autant data center l'est dans sa langue d'origine, et on peut légitimement se demander si cela a toujours été le cas. Le Web est (comme souvent) assez pauvre sur l'origine des termes informatiques, mais en cherchant un peu, on arrive relativement vite sur le cas des World Data Center créés en 1957. L'histoire de leur établissement peut être découverte dans The Origins and Principles of the World Data Center System, dont provient l'extrait ci-dessous :

At its decisive meeting in Brussels in 1955, when the Soviet Union officially unveiled its IGY programs, CSAGI set up a special Committee on the Availability of Data. This Committee recommended that data centers be set up in different countries as depositories and dissemination points for IGY data. The data would be collected and made available to any scientists without condition except for the cost of reproduction and mailing. The Committee recommended that CSAGI publish guides to the depositories and the types of data available from each. These World Data Centers would be more than passive depositories. They would actively supply data and provide the necessary facilities for data analysis.

Lors de sa réunion décisive à Bruxelles en 1955, lorsque l'Union soviétique dévoila officiellement ses programmes pour l'Année Géophysique Internationale (IGY), le Comité Spécial de l’Année Géophysique Internationale (CSAGI) a mis en place un comité spécial sur la disponibilité des données. Ce comité a recommandé que des centres de données soient créés dans différents pays en tant que dépositaires et points de diffusion des données de l'IGY. Les données seraient collectées et mises à la disposition de tous les scientifiques sans condition, à l'exception des frais de reproduction et d'envoi. Le comité a recommandé que le CSAGI publie des guides sur les dépositaires et les types de données disponibles pour chacun. Ces centres mondiaux de données seraient plus que des dépositaires passifs. Ils fourniraient activement des données et fourniraient les installations nécessaires pour l'analyse des données.

Ne nous méprenons pas, on parle déjà à l'époque d'automatisation du traitement des données, et de données numériques (sur cartes perforées), voire des premiers computer facilities : nous étions toujours en plein dans l'ère de la mécanographie. Le terme de data center est très probablement arrivé avant, mais à la fin des années 50, il paraît assez clair que quand on parle de ces data center, c'est pour désigner une stratégie proactive de centralisation des données dans un dépôt défini et géré par des sachant, afin de pouvoir les mettre en valeur. Le premier sujet tourne autour de la non-perte des données et de leur partage, un but proéminent après le succès relatif de la deuxième Année Polaire Internationale (API).

Rien de cela dans le data center d'aujourd'hui, qui n'est plus qu'un bâtiment connecté à Internet, bien refroidi, et rempli de serveurs, quelles que soient leurs utilisations.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Friday 8 January 2021

Affordance trompeuse : le cache

Selon un usage entériné par la commission d’enrichissement de la langue française dans le journal officiel en 2007, nous sommes censés parler du cache quand on évoque cet espace mémoire temporaire.

Le terme anglais est apparu avec le System/360 d’IBM pour le Model 85 commercialisé en 1968 (un modèle très flower power donc), soit la même année que CICS. Voici ce qu’on pouvait trouver dans Structural Aspects of the System/360 Model 85 II: The Cache pour cette année vraiment révolutionnaire à tout point de vue :

The storage hierarchy consists of a 1.04-microsecond main storage and a small, fast store called a cache, which is integrated into the CPU. The cache is not addressable by a program, but rather is used to hold the contents of those portions of main storage that are currently being used.

The term cache is synonymous with high-speed buffer, as used in other Model 85 documentation.

Ce terme cache est donc utilisé pour désigner un lieu où l’on peut mettre de l’information, et ce lieu n’est pas visible par tous. En français, cela s’appelle une cache ou une cachette. A contrario, un cache est quelque chose qui va masquer, et certainement pas un contenant.

L'utilisation du masculin pour cache va donc à l'encontre du sens français de cache. Et d'ailleurs, d'où vient ce mot anglais cache ? Selon Lexico, du verbe français cacher, verbe qu'on peut appliquer à la cache, ou au cache : balle au centre :-)


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Cet article a déjà été publié sous une autre forme ici.

Saturday 2 January 2021

Affordance trompeuse : GitOps

Dans la lignée de la revalorisation du travail des opérateurs est née la mouvance GitOps, à savoir les relations particulières entre les opérateurs et les connards (traduction littérale de git). En fait pas vraiment, comme le disent les créateurs de GitOps (Weaveworks) dans leur article de 2017, GitOps consiste en la mise en œuvre d'une approche déclarative pour décrire ce que l'on souhaite dans son système, puis de détecter les changements, et d'agir en conséquence en fonction des changements demandés. Vous aurez bien évidemment reconnu l'approche CFEngine de 1993, en un peu moins puissant, dans le sens où en GitOps les différences sont évaluées cible par cible, et pas de manière systémique ; ici on parle de cible d'outillage de déploiement et pas cible finale.

Est-ce que Git est important là-dedans ? L'article nous dit que oui, dans le sens où Git permet d'avoir gratuitement la revue de code, les commentaires dans les fichiers de configuration, de lier les engagements (commit) aux tickets et de gérer les demandes de récupérations d'engagements (pull request). La réponse est donc non, dans le sens où aucune de ces choses n'est spécifique à Git en particulier, les quatre premiers points étant standards à tous les gestionnaires de versions, et le cinquième étant indépendant du gestionnaire de version mais facile à mettre en œuvre dans les gestionnaires distribués de versions.

Ce qui compte donc dans GitOps n'est donc pas Git, mais l'approche déclarative et versionnée, celle qu'on tente de mettre en œuvre depuis plus de vingt ans, et qui est cassée à chaque fois qu'un produit devient à la mode et qui ne sait être configuré qu'en mode impératif (ou pour parler en termes d'affordances trompeuses, par API). Il se trouve que les créateurs sont partis du gestionnaire de source du moment, sans chercher à utiliser ses spécificités, on prend celui utilisé par les développeurs. Et pour Ops… les opérateurs sont des anonymes, tout va bien de ce côté, on peut le rajouter dans n'importe terme :-)

Certains rétorqueront que l'article séminal a été mis à jour, et que si, Git est bien indispensable. Mais ce que cette mise à jour fait vraiment est de montrer en quoi le modèle actuel du Continuous Deployment (ou CD, pas le disque optique) basé sur un enchaînement de scripts impératifs n'est pas réconciliable avec l'approche déclarative, qui elle travaille à deux niveaux : l'expression du changement dans l'exigence, et la mesure de l'écart entre l'exigence et ce qui est en place. L'approche CD traditionnelle (dite du pipeline, ou en Français de la Tech, du pipeline) s'arrête au moment où l'on propage le changement demandé, et ne comporte pas la boucle de rétroaction qui vient après la mesure de l'écart (qui n'est d'ailleurs pas systématiquement faite). On reste donc bien sur les principes de CFEngine, et Git dans l'affaire n'est qu'un accessoire à ces principes, même s'il se trouve techniquement au milieu de cette mise en œuvre particulière.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

Wednesday 30 December 2020

Affordance trompeuse : API as a Product

En Français de la Tech, l'expression API as a Product est appelée un worst of : elle représente tout ce que l'on souhaite éviter en termes de communication technique.

Pour API c'est assez simple, le terme est apparu à la fin des années 60 pour désigner un contrat d'interface stable et documenté afin de pouvoir utiliser des routines communes. L'acronyme se décompose en Application Program Interface puis a dérivé en Application Programming Interface, soulignant l'importance de la documentation dans l'API. Les deux destinataires d'une API étant le programmeur, pour qu'il puisse écrire du code utilisant les routines communes, et le compilateur qui va vérifier le respect du contrat et écrire le code machine permettant l'appel aux routines. D'autres interfaces existent évidemment, les ABI, SPI, etc… la spécificité des API étant dans le AP, le programmeur d'applications, l'humain qui va être le premier consommateur de cette nourriture.

Pour Product c'est assez simple aussi : en informatique, produit s'oppose directement à service distribué. Le produit c'est ce que l'on installe sur ses propres ressources de calcul, et qu'on utilise sans avoir besoin de la présence d'un tiers (avec le bémol des contrôles de licence à distance).

API as a Product devrait donc être en toute logique… un contrat d'interface permettant de construire un produit ? Un produit permettant de construire et documenter des contrats d'interface ? Que nenni. API as a Product est en fait un raccourci de treating API as a Product c'est-à-dire, pour les fournisseurs de services distribués, de ne pas considérer l'API comme l'interface exposée une fois qu'on a mis en place le service, mais de traiter l'API comme si c'était un produit, en y apportant la même démarche d'analyse, de conception et de commercialisation. Est-ce que cela signifie que l'API devient de ce fait un produit ? Absolument pas, on se situe dans une reformulation de l'approche top-down, selon laquelle on commence par regarder ce que l'on souhaite exposer, pour finir par regarder comment on va le mettre en œuvre, et qui s'oppose à la démarche bottom-up qui est, elle, purement technique.

Jusqu'ici, à part pour l'omission en apparence dérisoire de treating, nous ne sommes pas en présence d'une affordance trompeuse. Pourtant, entre l'apparition du terme fin 2015 et son utilisation aujourd'hui, cette omission s'est avérée fatale : on parle aujourd'hui de boutiques d'API (vu que ce sont des produits), de places de marché d'API (vu que ce sont des produits), de documentation d'API (et plus de la partie documentation de l'API), de rentabilité d'API (vu que ce sont des produits), des données de l'API (vu que l'API n'est plus une interface). Le raccourci de treating API as a Product en API as a Product a fait que le message qui est diffusé est qu'on ne vend plus l'accès à un service distribué, mais à un contrat d'interface, contrat qui par définition n'a qu'une valeur secondaire, celle de faciliter le travail du programmeur pour accéder à ce qui apporte la valeur primaire : la routine mise en commun. C'est dans la perte de ce petit mot treating que l'on est entré dans la tromperie.


Vous pouvez trouver le reste de la série sous l'article d'introduction.

- page 1 of 105