Pour ceux qui vivent déjà dans une société de censure dystopique, c'est un débat qui arrive bien trop tard.

 

Hum, il me semblait qu’en golang,
sarama était davantage privilégié..
Les clients Kafka sont en fait plus complexes qu’on ne le pense, surtout en cas de panne du broker ou d’exception,
alors couvrir tous les cas..

 

J’avais déjà écrit plus en détail sur le début de l’affaire :

Le point de départ de l’affaire remonte à 1999, lorsque le gouvernement britannique a décidé de ne pas abandonner un système de versement des pensions et allocations que la Poste avait écarté en raison de doutes sur sa fiabilité, et de l’utiliser pour moderniser le système existant de la Poste, qui enregistrait encore les transactions sur papier.

Ce terminal de point de vente électronique (electronic point-of-sale system), appelé Horizon, a connu de nombreux problèmes dès le départ. Des écarts ont été constatés entre les montants en espèces enregistrés dans Horizon et les liquidités réellement détenues, et les responsables de bureaux de poste, désemparés, auraient commencé à appeler le centre d’assistance Horizon.

L’erreur « Dalmellington » figeait l’écran lorsqu’un utilisateur essayait de confirmer la réception d’espèces ; dans cette situation, chaque pression sur Entrée enregistrait la réception d’espèces sans aucune indication à l’écran.

L’erreur « Calendar Square » provoquait des transactions en double en raison d’un dysfonctionnement de la base de données sous-jacente du système...

Quelle en était la cause ? Il y en avait sans doute plusieurs, mais trois ressortent : 1) le manque de personnel, 2) une confiance aveugle dans l’infaillibilité du logiciel, 3) la bureaucratie.

  1. Manque de personnel

Selon David McDonnell, qui a participé au développement, « L’équipe de développement comptait huit personnes : deux étaient très compétentes, deux étaient moyennes mais avec lesquelles on pouvait travailler, et les trois ou quatre restantes n’avaient pas la capacité de produire du code de niveau professionnel, si bien qu’elles n’étaient pas en mesure de faire correctement le travail. »

https://x.com/KayKiwoongKim/status/1825209040575873330

 

Au fond, le problème tient au fait qu’on force la création d’un web de type application à l’intérieur du protocole HTTP, qui repose à la base sur des « documents » web.
L’idée était donc que, si des fonctions de niveau applicatif sont nécessaires pour résoudre cela, pourquoi ne pas créer un nouveau protocole et un nouveau framework pensés pour les applications ?
De la même manière que, sur smartphone, ce ne sont pas des programmes purement natifs qui s’exécutent mais des applications fonctionnant dans une sorte de sandbox, la structure consisterait ici à les faire tourner au niveau du navigateur.
Bien sûr, il faudrait d’abord garantir l’ouverture et la standardisation pour éviter que cela ne tourne à l’ActiveX.

 

Les réactions autour de « ennuyeux » sont amusantes haha. Si on voulait le remplacer par un autre mot, qu’est-ce qui irait bien ? Banal, courant ?

 

N’est-ce pas une tout autre histoire que celle dont vous parlez ?

 

Je ne comprends pas très bien ce que vous voulez dire dans la dernière partie, quand vous parlez d'une plateforme idéale.

Au final, on parle de l'époque où il fallait télécharger un programme natif et y utiliser ActiveX.

 

Traduire boring par « ennuyeux » ne rend pas du tout son sens d’origine. La boringness fait partie de la philosophie de conception de Go.

 

Encore se faire avoir~

 

Ce n’est pas si simple à utiliser confortablement en quelques clics.

 

Tout est bien, mais si vous utilisez ça, le système ne peut pas contrôler WireGuard. Si vous voulez l’utiliser séparément des tunnels, il faut le déployer dans une VM distincte.

 

Même pour un web de type application, je pense qu’il faut viser quelque chose de proche de la conclusion présentée. Si on utilise beaucoup de JavaScript, cela devient lourd côté client.

En pratique, ce n’est pas comme s’il n’existait aucun framework permettant de l’implémenter ainsi. Rien qu’avec Next.js, si l’on réduit au minimum l’usage des composants client en ne les utilisant que lorsque c’est nécessaire, c’est globalement possible. Et dans l’écosystème Rails mentionné par un autre intervenant, Hotwire (https://hotwired.dev/) propose justement un ensemble de frameworks prenant en charge un web de type application (Turbo, Stimulus, etc.) qui permet d’approcher de très près la conclusion avancée par l’auteur.

 

À cause de l’acquisition par OpenAI, Claude a cessé de fournir la licence de la dernière version, donc pour utiliser les modèles Claude 4.x sur Windsurf il faut acheter directement l’API à un prix élevé ; est-ce que Claude va revenir ?

 

Contrairement à la culture de développement coréenne, où le travail descend de la direction vers les planificateurs puis vers les développeurs, en Occident il n’existe pas vraiment d’équivalent au concept coréen de « planificateur », et les développeurs participent activement à la planification produit, entre autres. Les PM occidentaux, par exemple, ne correspondent pas parfaitement aux planificateurs coréens, tout comme une cover letter ne correspond pas exactement à une lettre d’auto-présentation coréenne. Bien sûr, pour les jeux, où la dimension de projet créatif est forte et où le fun et la jouabilité sont essentiels, l’Occident est lui aussi plus horizontal que l’Asie, mais le travail y descend tout de même du directeur vers les développeurs.

 

Les philosophies de développement poursuivies sont extrêmement variées, donc.........

 

Visiblement, même l’IA n’est pas impartiale.

 

C’est trop effrayant.
L’idée que des données enregistrées de manière malveillante puissent l’emporter sur la mémoire et l’expérience, devenir des preuves
et servir à nous menacer.

 

Il n’existe pas tant de navigateurs que ça, alors pourquoi y a-t-il autant de frameworks ? Le mieux ne serait-il pas que les entreprises qui gèrent les navigateurs créent un framework optimal et l’entretiennent elles-mêmes ? Jusqu’à quand allons-nous répéter ce cercle vicieux ?