dimanche 2 mai 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 Digital 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.

mercredi 28 avril 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.

jeudi 25 mars 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.

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 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, et ce 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

jeudi 21 mai 2020

Le sparadrap, outil disruptif des coders

En ces années où les coders (i.e. ceux qui s'intéressent au code, les plombiers 2.0 en quelque sorte) ont remplacé les informaticiens (i.e. ceux qui s'intéressent à l'information), l'heure n'est plus à la propreté. J'en profite donc pour mettre ici le bout de code qui permet de corriger la recherche et la page peu avenante qui s'affiche quand un des deux pauvres hères qui laissent des commentaires ici agissent (qu'ils en soient remercié de visiter activement ce cimetière). Telle la justice aveugle je désigne PHP-FPM comme coupable, mais en vérité ça n'est qu'un préjugé. Ceci est à mettre dans votre inc/config.php sous DotClear 2 si vous pensez avoir le même problème.

if(isset($_SERVER['PATH_INFO'])) {
    $off = strpos($_SERVER['PATH_INFO'], '?');
    if($off !== false) {
        $_SERVER['PATH_INFO'] = substr($_SERVER['PATH_INFO'], 0, $off);
    }
}

dimanche 17 mai 2020

Tout cela est bien binaire

L’objectif est de proposer un outil numérique permettant de réduire la pénibilité lors de la rédaction des réponses aux amendements soumis par les député·e·s et/ou sénateur·ice·s de la part du gouvernement afin de préparer le débat législatif au sein des instances parlementaires.

2020, l'horizon épicène n'étant toujours pas passé de mode, nous sommes ici gratifiés d'une double syntaxe communautariste : d'abord celle des binaristes genrés, puis celle des binaristes informaticiens. Comment résoudre cet épineux problème d'expression, qui rend cette phrase moche ? Oui, moche est un qualificatif très rationnel. On aurait pu dire "soumis par les parlementaires", simple, concis, efficace, explicite, beaucoup de qualités pour la lisibilité. Mais était-ce un des objectifs recherchés ? C'est peu souvent le cas dans la communauté des binaristes genrés qui mettent le militantisme grammatical en première intention, comme on a pu le voir l'an dernier avec les #NoFakeScience. Alors que faire ? Quand le binariste informaticien voit une telle phrase, une émotion saisissante jaillit instantanément dans son esprit : la joie de pouvoir dessiner une table de vérité. Et on sait que la vérité est un principe important dans toute action militante, comme chez les binaristes genrés.

Accordons-nous donc ce plaisir coupable (la première colonne ne peut bien évidemment pas être 'homme', vu que le premier sens de ce mot en français n'est pas mâle, ni malle, ni mal, bien au contraire) :

femmesénatassemblée
nationale
résultat
0000
0011
0101
0111
1000
1011
1101
1111

Ce qui est merveilleux avec cette table est que, pour les amateurs de Boole, l'équivalence avec la proposition "parlementaires" saute aux yeux. Pourquoi aller chercher la beauté dans la nature quand elle est si évidente à l'écran ?

dimanche 3 mai 2020

Le remplissage facile avec le Web disruptif de la révolution digitale

Ce blog est mort, je le sais, vous le savez, tout le monde le sait. Cela ne signifie pas que j'ai disparu de la surface d'Internet, et encore moins du Web, et encore moins du GAFAnet (à prononcer en vomissant, c'est un machin qui prétend être le Web mais qui n'est qu'une perversion basée sur "des apps" (à prononcer "dézap" (fin des parenthèses))). Comment donner un aspect un peu moins cadavérique à cet espace, que dis-je, à mon espace ? C'est simple, on prend du contenu déjà public, à savoir "mon Insta", et on reposte ici. Quatre-cent quatre-vingt onze articles gratuits (et pas "blogs gratuits" comme diraient les développeurs) : pas cher, mais pour l'instant c'est juste un travail à froid, avec débogage de l'extension importExport de Dotclear inclus. Reste à faire la synchronisation au fil de l'eau de la chose, et pour ça, sortie de l'artillerie lourde en cours : Huginn.

vendredi 1 mai 2020

Insta' du 1er mai

IPN, angles droits, raccords, tout évoque le réel, le terrain, à l'opposé du planifié, de la froide conception. Le transformateur planté au milieu de la rue est l'incarnation de l'accès permanent et immédiat au confort électrique, la chair de la modernité, le début de la paresse, le spleen comme angle de vie de l'être sans activité.

Insta' du 1er mai

Et là que voilà la tant attendue (pas du tout) série sur les transformateurs urbains. Un mythe s'est développé comme quoi mes photos de vacances étaient constituées essentiellement d'engins de cet acabit. C'est faux. Je ne sais pas ce que j'ai fait au monde pour mériter que de tels on-dit soient répandus ainsi.

jeudi 30 avril 2020

Insta' du 30 avril

Toujours en train de trier pour la prochaine série. En attendant, voici une ombre.

mercredi 29 avril 2020

Insta' du 29 avril

Canard attaquant son voyage vers l'ouest adéquatement acompagné.

- page 1 de 104