Mot-clé - affordancetrompeuse

Fil des billets - Fil des commentaires

dimanche 24 janvier 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 refroidit, et rempli de serveurs, quelles que soient leurs utilisations.


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

vendredi 8 janvier 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.

samedi 2 janvier 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.

mercredi 30 décembre 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.

mardi 29 décembre 2020

Affordance trompeuse : REST API, RESTful

Les noms REST API et RESTful invitent au voyage dans le monde des architectures post-Web. Roy Fielding, le seul créateur de REST le dit d'ailleurs explicitement : REST est un style d'architecture qui n'a de sens que dans un système hypermédia distribué. Sans ressources capables de référencer d'autres ressource (hypermédia), sans système qui implique d'avoir de multiples unités de calculs distinctes (distribué), l'architecture retenue pour construire une application ne peut pas suivre un style qui correspond à REST. Et dans ces deux aspects, hypermédia et distribué, étant donné que l'aspect distribué a été traité ad nauseam pendant un demi-siècle, le facteur discriminant est en conséquence l'hypermédia.

L'approche RESTful se concentre sur la mise en place des REST API, et considère que la prise en compte de l'hypermédia est quelque chose d'optionnel, car difficile à mettre en œuvre pour le besoin réel. Comme REST impose l'hypermédia en tant que sujet primaire de réflexion, justement parce que c'est le sujet difficile qui permet de répondre à des besoins auxquels les autres styles d'architecture ne répondent pas, alors on peut en déduire que les termes REST API et RESTful sont représentatifs d'une mouvance NoREST. On trouve un marqueur fort chez les partisans du NoREST : la mise en avant d'un seul format d'échange de données, format qui n'est pas hypermédia, le JSON.


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

lundi 28 décembre 2020

Affordance trompeuse : codeur

Le monde de l'informatique s'est créé quand la machine électronique est devenue programmable, quand on pouvait changer son fonctionnement sans passer par une nouvelle étape de fabrication matérielle. Très logiquement, les personnes maîtrisant la création de ces programmes (activité qui nécessite de passer par des étapes d'architecture logicielle, d'analyse, de conception et d'écriture de code) ont été appelées programmers. A contrario, des termes péjoratifs sont apparus pour désigner ceux qui ne méritaient pas cette appellation, comme code grinder (moulin à code), ou code monkey (pisseur de code). La différence entre les deux est que le terme programmer garde dans tous ses usages la notion de travail intellectuel, alors que quand il s'agit de réduire la chose à un simple travail mécanique, ce sont code et coder qui sont utilisés.

Quand, afin de transmettre ses principes, l'informatique pioche son vocabulaire dans les arts mécaniques devenus traditionnels , c'est une bonne idée. Quand les programmeurs réduisent leur travail au codage, ça n'en est plus une.


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

samedi 26 décembre 2020

Affordance trompeuse : les frameworks Web MVC

À la fin des années 70, Trygve Reenskaug fait face au problème de la gestion d'un nombre important de données dans une application, et cherche un modèle de programmation qui rende l'application maintenable. On parlera de la maintenabilité dans un autre article, c'est une autre affordance trompeuse. Il arrive après plusieurs itérations et en collaboration au Model View Controller. Rétrospectivement il regrette ce nom de Controller qui n'est pas assez expressif pour le rôle joué.

Le MVC est organisé en une hiérarchie de couples Vue (ce que voit l'utilisateur) - Contrôleur (ce qui reçoit les entrées de l'utilisateur), avec des Modèles sous-jacent (le monde manipulé), la communication entre les Modèles et les Vues se fait dans une approche Observateur / Observé. Si vous enlevez un de ces éléments, vous n'avez plus de MVC. Et pourtant, un article paru sur InfoWorld en 1999 a réussi à populariser le fait que le Model 2 de Sun Microsystems pour Java EE (à l'époque J2EE) était une approche MVC pour le Web : pas de couples Vue - Contrôleur, pas d'organisation hiérarchique ni des Vues ni des Contrôleurs, pas communication Observateur / Observé, pas de support de l'hypermédia, le Model 2 n'était en fait ni MVC ni vraiment Web.

Le MVC se retrouvait réduit à l'état d'une triade vidée de sa substance, un vague Separation of Concerns sans objectif ni raison d'être, et c'est cette vision qui a perduré et a été reprise par la suite dans les frameworks dits Web (Struts, Spring MVC, Django, Symfony, etc…). Cette affordance trompeuse nous suit depuis bien longtemps, voir cet article de 2006 sur la partie dite Web, ou cet article de 2004 où comment cette fausse interprétation du MVC vient polluer la compréhension des vrais frameworks MVC.


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

jeudi 24 décembre 2020

Affordance trompeuse : LA DATA

En 1874 Émile Baudot crée un code sur 5 bits pour la télétransmission afin d'être plus efficace que le code Morse. Ce codage permet de représenter les lettres majuscules, les chiffres, la ponctuation… c'est le début du monde de LA DATA. Un point fascinant du monde de LA DATA est ce besoin de REVENIR A DES MAJUSCULES SANS ACCENTS POUR S'EXPRIMER. Le monde de LA DATA EST UN MONDE BRUYANT.

La mode autour de ce vocabulaire est très intéressante, car elle montre deux points de vue différents entre la francophonie et les outres (outre-Manche, outre-Atlantique). L'idée principale convoyée par les dénominations anglaises est toujours celle du calcul : dans computing science, le premier mot a la même racine latine que le mot français computer, c'est-à-dire computare, calculer. Dans software engineering, le premier mot a été créé en opposition au hardware, au matériel : on continue de parler de l'outil, toujours pas de des données.

En vocabulaire anglais, il est donc nécessaire de remettre en avant la donnée, ou comme on dit en Français de la Tech, de remettre en avant LA DATA. En vocabulaire français par contre, on va parler d'informatique depuis le début de la diffusion des ordinateur dans les années 60 (qui ne sont que des calculateurs pour le coup), c'est-à-dire de la science du traitement rationnel, notamment par machines automatiques, de l'information considérée comme le support des connaissances humaines et des communications dans les domaines technique, économique et social.

Cela fait donc plus d'un demi-siècle qu'en vocabulaire français on a considéré que LA DATA était la partie fondamentale de notre activité, et qu'en deuxième position arrivait la problématique du calcul automatisé. L'utilisation sans réserve de LA DATA dans nos contrées est donc un indicateur fort de l'inculture informatique de nos entreprises, en particulier dans la French Tech.


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

Affordance trompeuse : JSON

JSON est un format de texte bien connu, et format privilégié des amateurs de l'approche NoREST. Ce format, très simple, est défini dans la RFC 8259 de l'IETF ou encore ECMA-404 de l'ECMA, qui spécifie que l'acronyme signifie "JavaScript Object Notation". On pourrait donc s'attendre à ce qu'on puisse décrire en JSON un objet au sens JavaScript, à savoir quelque chose avec un état et un comportement, des propriétés et des méthodes. Juste après, la spécification précise que JSON est un format d'échange de données, on comprend donc que la partie "comportement" ne fera pas partie de JSON. On pourrait du coup s'attendre à ce que les types de données scalaires JavaScript standards soient supportés dans JSON. Ce n'est pourtant pas le cas, seuls les nombres et les chaînes de caractères sont décrits et, par le tour de passe-passe d'utilisation de mots-clefs, on ajoute les booléens. Au final, le JavaScript dans JSON est l'équivalent de Git dans GitOps : un tube néon qui va mettre en valeur le nom.


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

Affordance et programmeurs, une histoire de noms

Affordance est un néologisme créé par le psychologue James J. Gibson dans les années 60 pour désigner ce que l'environnement a à nous offrir. A la fin des années 80, ce terme prend un sens complémentaire, avec la notion de perception de cette offre. Par exemple avec l'iPhone, Apple a introduit la possibilité de zoomer avec un mouvement de pincement effectué digitalement (c'est-à-dire avec les doigts) sur l'écran : dans la désignation des années 60, cette possibilité est une affordance, dans celle des années 80, c'est une affordance cachée. On parlait aussi de fausses affordances, comme par exemple quand un bouton est présent mais rien n'est câblé derrière. Dans les années 2010, une nouvelle utilisation du terme est apparue, au singulier cette fois, où l'affordance de quelque chose est sa qualité à proposer des affordances visibles.

Cette notion est clef dans les interactions homme-machine, spécialement pendant la phase de découverte de l'interface, de la surface qui sépare l'humain de l'informatique. Une fois l'interface connue, assimilée, la personne travaille par raccourcis, par accélérateurs et ce besoin d'affordances visibles diminue. On pourrait donc penser que ce concept d'affordance va être clef pour les informaticiens, qui vont avoir à cœur de le mettre en pratique dans l'organisation de leur travail. C'est un peu le cas, mais avec une subtilité : les informaticiens aiment aller au-delà de l'affordance, ni affordance visible, ni affordance cachée, ni fausse affordance, mais avec l'affordance trompeuse, celle qui donne à croire qu'on a une certaine affordance, mais qui propose en fait tout autre chose.

Ceci se pratique essentiellement à travers la démarche de dénomination, élément essentiel de toute communication. Certains diront que le vocabulaire est nécessairement mouvant dans le temps, et que le nom des choses est ce que la masse en fait. Il n'en reste pas moins que ceux qui connaissent le sens d'origine du vocabulaire ne peuvent que se sentir attaqués et trahis, dans une démarche certes victimaire, mais pour laquelle on peut ressentir une certaine empathie en toute bienveillance. Et passé ce point de détail, dans toute démarche scientifique, et l'informatique aspire à s'en approcher, il est important de ne pas effacer le passé en se servant du vocabulaire comme d'un palimpseste.


Cet article sert de point d'entrée à la série "Affordances trompeuses", il sera mis à jour au fur et à mesure avec les différentes entrées.

  1. JSON
  2. LA DATA
  3. Les frameworks Web MVC
  4. Codeur
  5. REST API, RESTful
  6. API as a Product
  7. GitOps
  8. Dette technique
  9. La qualité
  10. Les bonnes pratiques
  11. La refactorisation
  12. Le cache
  13. Le data center