Aucun chien n’a été blessé pendant la création de cette application

 (shmck.substack.com)
1 points par GN⁺ 2023-11-04 | 1 commentaires | Partager sur WhatsApp
  • En 2016, la fonctionnalité d’upload de photos géolocalisées d’une app mobile React Native échouait uniquement dans la bêta Android, sans pouvoir être reproduite en local sur Android ni sur iOS, et le problème a été traqué pendant une semaine
  • La bêta Android ne renvoyait aucun retour d’erreur malgré l’échec de l’upload d’image, et chaque nouveau build envoyé sur le Play Store prenait environ 1 heure, ce qui ralentissait la validation des hypothèses
  • Comparé à des cas en embarqué, en matériel, en chimie ou en médecine vétérinaire, le débogage logiciel apparaît bien plus rapide et bien plus observable
  • La cause réelle était une différence d’une seule lettre : le type MIME de l’image était écrit "jpg", alors que l’extension du fichier pouvait être .jpg, mais que le type MIME devait être "jpeg"
  • Un environnement de développement où l’on peut utiliser facilement des logs, l’observation en temps réel, un débogueur et des expériences répétées à faible coût relève presque d’un grand privilège au regard des boucles de retour d’autres métiers

Upload de photo qui échoue uniquement dans la bêta Android

  • La fonctionnalité de photos géolocalisées d’une app mobile React Native semblait prête pour une sortie le lundi, mais après le déploiement de la bêta Android, les images ne s’uploadent pas
  • Les tests Android en local et la bêta iOS fonctionnaient normalement, ce qui ne permettait pas d’identifier immédiatement l’origine de l’échec
  • Même après avoir renvoyé une version améliorant la gestion des erreurs, l’échec de l’upload se produisait toujours sans aucun retour
  • Envoyer une nouvelle itération sur le Play Store prenait environ 1 heure, et il fallait attendre la mise à disposition du build tout en préparant l’hypothèse suivante

Des boucles de retour plus longues dans d’autres métiers

  • Un ingénieur en embarqué déploie une mise à jour de firmware sur des équipements distants, puis se retrouve avec des nœuds qui ne répondent plus
    • Pour comprendre la cause, il faut récupérer le matériel et l’analyser
    • Dans certains cas, il faut des mois pour découvrir ce qui s’est mal passé
  • Un ingénieur hardware constate qu’un nouveau matériel déployé à distance peut ne révéler un défaut de conception qu’après avoir traversé plusieurs saisons
    • Il reçoit les anciens équipements par courrier et intègre les correctifs à la génération suivante du produit
    • Il existe un cas où l’ajout d’aérations pour réduire la chaleur a créé un bug encore pire, parce que les ouvertures étaient assez grandes pour que des frelons y fassent leur nid
    • Des tests en laboratoire sont possibles, mais la validation finale se fait malgré tout sur le terrain

La manière d’accepter l’échec

  • Le CEO se souvient qu’à l’époque où il était chimiste en préparation de thèse, il menait des expériences grâce à un important financement destiné à des produits chimiques coûteux, mais qu’au bout de plusieurs semaines, le résultat semblait avoir échoué à cause d’une erreur expérimentale
  • Il n’a pas réussi à comprendre ce qui s’était mal passé, ni à répondre à la question de ce qu’il ferait différemment pour éviter de répéter la même erreur
  • Malgré cela, il a obtenu un second financement, et cette expérience est devenue un exemple de leadership empathique qui aide quelqu’un à se relever après un échec

Le cas vétérinaire montre un risque bien plus élevé

  • Une amie vétérinaire examine un chien âgé et malade et recommande une radiographie au propriétaire, qui la refuse à cause du coût
  • Sans radiographie, le mieux qu’elle puisse faire est de palper l’abdomen du chien depuis l’extérieur, et elle sent un gros objet
  • Ce qui a été retiré par chirurgie était un épi de maïs, mais faute de radiographie, il n’était pas possible de savoir avec certitude si c’était l’unique problème
  • Le lendemain, le chien est mort, et contrairement aux problèmes de lancement d’une app mobile, les échecs dans d’autres métiers peuvent réellement engager la vie ou la mort

Le bug d’une lettre et le privilège des outils de débogage

  • Le vendredi matin, une incohérence entre la documentation Android et la base de code est apparue, et la cause du problème qui durait depuis une semaine était un seul caractère
  • Le type MIME de l’image était défini sur "jpg", alors qu’en réalité il devait être "jpeg", même si le fichier était enregistré en .jpg
  • Les développeurs logiciels peuvent regarder en profondeur des processus complexes, surveiller le fonctionnement en temps réel, produire des logs, arrêter l’exécution avec un débogueur et examiner ce qui se passe
  • Ces capacités sont peu coûteuses et rapides, et permettent de répéter des expériences plusieurs fois par jour en quelques clics
  • Le logiciel peut être aussi important et avoir autant d’impact que d’autres métiers, mais les développeurs travaillent dans un environnement où ils ont de bonnes raisons d’être reconnaissants pour les outils de débogage dont ils disposent

À lire aussi

1 commentaires

 
GN⁺ 2023-11-04
Avis de Hacker News

  • Une histoire presque allégorique sur ce qui distingue le génie logiciel des autres métiers — ou, pour le dire en plaisantant, des « vrais » métiers.
    J’aime aussi cette version plus courte et spirituelle : un ingénieur logiciel, un ingénieur matériel et un chef de service se rendent à une conférence en Suisse quand, sur une route de montagne escarpée, les freins lâchent, la voiture percute la glissière en descendant et s’arrête miraculeusement.
    Le chef de service propose de tenir une réunion pour définir une vision, une mission et des objectifs, puis de résoudre le problème central par l’amélioration continue ; l’ingénieur matériel propose de démonter les freins avec un couteau suisse pour les réparer.
    L’ingénieur logiciel dit : « Avant de faire quoi que ce soit, repoussons la voiture en haut et voyons si ça se reproduit. »

    • Le grand avantage du génie logiciel, c’est qu’il traite des abstractions. C’est un peu comme construire des châteaux sur des nuages : on peut remodeler absolument tout, jusqu’aux fondations.
      En même temps, le grand inconvénient du génie logiciel, c’est aussi qu’il traite des abstractions. Tout bouge, jusqu’aux fondations.
      http://thecodelesscode.com/case/154
    • La morale de cette histoire, c’est simplement que l’ingénieur matériel a raison ?
    • Ingénieur mécanicien ici.
    • Et si, en appuyant sur « relancer », la voiture réapparaissait miraculeusement en haut de la colline, que la même chose se reproduisait, et qu’au moment où les freins lâchent, on pouvait arrêter le temps puis démonter toutes les pièces de la voiture pour voir exactement où est le problème, en temps réel, au ralenti et en marche arrière ?
      Le fait d’avoir ce pouvoir ne rend pas l’ingénieur logiciel ridicule ou irréaliste.
      L’ingénierie de l’espace numérique donne des capacités de débogage qui relèveraient du miracle dans les domaines physiques. Si vous voulez fabriquer 10 exemplaires du même objet et les tester de 10 façons différentes, c’est littéralement CTRL+C, CTRL+V. J’aimerais voir un mécanicien faire ça.
    • Seuls les freins ne marchent pas, le moteur va bien. Pourquoi faudrait-il pousser la voiture en haut de la colline ?
    • Je fermerais toutes les fenêtres et je redémarrerais.

  • J’en ai vraiment assez des plaintes du genre : les ingénieurs logiciels ne sont pas de « vrais ingénieurs », et il suffirait de faire beaucoup plus de grandes réunions de conception en amont et énormément de planification.
    Si les autres disciplines d’ingénierie travaillent ainsi, ce n’est pas parce qu’elles sont beaucoup plus professionnelles que nous, ni parce que cette méthode est meilleure, mais parce qu’elles n’ont pas d’autre choix. Une fois un hôtel terminé, on ne se rend pas compte qu’il faut relever le plafond de 15 cm pour tout démolir et reconstruire.
    Si l’on pouvait exécuter ceilingHeight += 6, cliquer sur « Rebuild », voir l’hôtel se reconstruire pendant que des tests unitaires automatisés vérifient aussi l’accessibilité, le tout pour un coût total de 2,82 dollars, ils le feraient évidemment eux aussi.
    Il faut arrêter avec le complexe d’infériorité. Nous faisons de l’ingénierie avec des outils dont les ingénieurs civils et mécaniciens du monde réel ne peuvent même pas rêver, et il est normal que les processus en soient profondément différents.
    Bien sûr, il arrive que l’on n’applique pas assez de processus à un problème. Mais si vous pensez que c’est un problème propre à la programmation, je vous prescrirais volontiers quelques heures de https://www.imdb.com/title/tt4788946/.

    • Je pense que vous passez à côté de l’essentiel. La planification préalable et les réunions ne sont pas le fond du sujet ; elles sont la conséquence des critères précédents. L’ingénierie, c’est résoudre scientifiquement des problèmes pratiques, avec comme exigences non négociables la sécurité, la reproductibilité et la compréhension des principes de la solution ; la personne qui résout le problème doit être qualifiée comme ingénieur sur le plan de l’éthique et de la rigueur scientifique, et, du fait de cette qualification, elle assume une responsabilité dont elle ne peut se décharger si la solution qu’elle a validée échoue.
      Ce n’est pas une question de supériorité : si l’un de ces critères manque, vous ne faites pas de l’ingénierie. D’après mon expérience, la plupart du développement logiciel ne remplit aucun des quatre. Ce n’est pas forcément une mauvaise chose, mais la plupart du développement logiciel n’est pas de l’ingénierie.
      Cela ne veut absolument pas dire que l’ingénierie est supérieure au développement.
    • Tout à fait d’accord. Chaque médium a ses processus et techniques optimisés.
      C’est comme la différence entre sculpter l’argile et sculpter le marbre. Si vous faites une erreur dans l’argile, il suffit de la retravailler rapidement ; si vous retirez du marbre une partie qu’il ne fallait pas enlever, il faut commander un nouveau bloc.
      Importer les méthodes de la sculpture sur marbre dans le monde de l’argile ne ferait de vous qu’un très mauvais sculpteur d’argile, ou au minimum un sculpteur très inefficace.
      Il n’y a pas non plus grand intérêt à déterminer laquelle, entre l’argile et le marbre, produit une sculpture plus précieuse. Les deux ont leur place dans la société.
    • Digression complète, mais l’une des raisons pour lesquelles l’impression 3D est formidable, c’est qu’elle offre l’expérience la plus proche de ceilingHeight += 6 dans le monde réel.
      Aujourd’hui encore, j’ai modélisé et imprimé un objet, puis je me suis rendu compte qu’une partie aurait gagné à être plus épaisse d’environ 1 mm. Trente secondes plus tard, la version 2 partait vers l’imprimante.
      C’est vraiment incroyable. J’ai hâte que ce genre de chose soit aussi répandu que les imprimantes papier.
    • Les gens qui pensent que le génie logiciel n’est pas de la vraie ingénierie seraient sans doute surpris d’apprendre qu’une bonne partie de la « vraie » ingénierie consiste simplement à entrer des nombres dans un logiciel.
    • Quand on regarde les avions et les jets conçus avant la CAO, on voit que la conception d’ingénierie pouvait aussi être largement ajustée sur le terrain. Tout était fabriqué pour s’emboîter parfaitement, avec le savoir-faire logé dans la tête de ceux qui avaient conçu et de ceux qui avaient corrigé.
      https://www.youtube.com/watch?v=NPVT2lvMvOk

  • Au cours de ma carrière, il est arrivé plusieurs fois qu’une erreur se produise, mais dans un silence total, et que tout le monde se retrouve bloqué. Pas de sortie d’erreur, rien.
    Dans bon nombre de ces cas, la cause était une bibliothèque tierce de bas niveau qui faisait catch (e) {}. Le premier cas que j’ai rencontré au début de ma carrière m’a servi de bonne leçon, et désormais je ne laisse jamais passer une erreur comme si de rien n’était. Au minimum, je la journalise.
    Le logiciel que vous écrivez aujourd’hui pourra être utilisé dans cinq ans, dans un environnement que vous n’imaginez absolument pas.

    • « Cette fonction est tellement claire pour toute l’équipe qu’elle n’a pas besoin de commentaire. »
      Trente ans plus tard :
      /* X systems I modul body I 14.09.1990 */
      void xxvcda(int *addr, int sizeof)
    • Tellement vrai. Dans le code que je regarde en ce moment, un auteur passé brièvement auparavant avale les exceptions d’une bibliothèque sous-jacente, puis lance à la place une exception complètement inutile.
      Il ne connaissait même pas la fonctionnalité du langage qui permet de relancer une nouvelle exception à partir de l’ancienne pour préserver le contexte de la trace de pile. C’est amusant. Au moins, ce n’est pas du code de mon travail principal ; mais mon travail principal a aussi ses propres sources d’amusement.
    • J’ai eu quelque chose de similaire récemment avec DRF et JWT. À cause d’un problème de timing intermittent, le JWT n’était pas valide et il était impossible de se connecter.
      DRF avalait l’erreur de validation et ne renvoyait qu’une erreur générique, sans aucun indice ; au final, j’ai dû descendre moi-même dans les couches et ajouter du logging pour comprendre ce qui se passait.

  • Un ami physicien citait souvent Rutherford : « toute science est soit de la physique, soit de la philatélie »
    Ce qu’il voulait dire, c’est que la physique, contrairement aux mathématiques ou à l’informatique, a une manière d’être vérifiée par la réalité physique
    Son domaine était celui des champs magnétiques extrêmes : on fabriquait d’immenses bobines de cuivre, on y faisait passer assez de courant pour les faire fondre, puis on déclenchait des explosifs autour de la bobine afin de rendre, pendant un très bref instant, le champ magnétique central plus intense que tout ce que l’humanité avait jamais produit, avant que des milliers de degrés de cuivre liquide ne soient projetés et que tout l’appareil soit détruit
    Dans ce genre d’environnement de travail, une erreur ou une erreur de calcul signifie que des gens peuvent mourir très vite et de façon atroce. Il n’était donc pas d’accord quand des doctorants en mathématiques, dont le pire dommage possible était d’avoir de la poussière de craie sur leur pull, se qualifiaient eux-mêmes de scientifiques

    • C’est une interprétation assez singulière de cette citation. D’après plusieurs livres, elle signifie que la science est soit mathématique et quantitative, soit descriptive
      Autrement dit, soit elle cherche à comprendre la dynamique de son objet, soit elle se contente de collecter des faits intéressants et de nommer les objets d’intérêt
    • Les générateurs à compression de flux magnétique pompés par explosif[1], c’est amusant
      Pour ceux qui s’intéressent à une carrière de super-vilain mais ne savent pas par où commencer : c’est comme ça qu’on fabrique un vrai EMP
      [1] https://en.m.wikipedia.org/wiki/Explosively_pumped_flux_comp...
    • Je me demandais pourquoi Dijkstra était aussi arrogant, puis j’ai compris quand j’ai appris qu’il avait étudié la physique théorique
    • Je n’ai pas vraiment vu de mathématiciens se qualifier eux-mêmes de scientifiques. Au contraire, ils se vantent plutôt en général de ne pas être des scientifiques et de ne pas être limités par de triviales réalités
    • En bon physicien, il a mal interprété cette citation

  • Après ce genre d’incident, j’aimerais toujours qu’il y ait une action corrective en amont. Avec une journalisation et un reporting d’erreurs appropriés, il n’aurait pas fallu une semaine pour corriger ça
    La bibliothèque qui a reçu le type MIME incorrect image/jpg aurait dû lever une exception, crasher ou au moins écrire un gros message dans les logs. Je me demande si l’auteur original a signalé un bug à cette bibliothèque

    • À la fin de l’article, je me suis demandé dans quel environnement travaillait Shawn pour que le diagnostic prenne autant de temps
      Avait-il les accès permettant de confirmer ou d’infirmer que les uploads d’images arrivaient réellement côté serveur ? Pourquoi l’upload fonctionnait-il dans l’environnement de test mais pas dans la version publiée de l’app ? Qu’est-ce qui était différent dans l’environnement de test ?
      En théorie, Shawn aurait dû avoir assez d’accès, soit pour faire tourner lui-même le serveur, soit pour demander de l’aide à quelqu’un capable de diagnostiquer pourquoi l’upload échouait silencieusement, afin de répondre assez vite à la question : « l’upload réussit, alors pourquoi l’image n’apparaît-elle pas ? »
      À mon avis, la leçon bien plus importante que « le type MIME de l’image était jpg alors qu’il fallait jpeg », c’est pourquoi ça marchait en test mais pas en production. Plus que le bug lui-même, le vrai sujet est de savoir pourquoi l’environnement rendait ce bug difficile à trouver
      Dans mon cas, une appli desktop dysfonctionnait gravement sans que l’erreur soit inscrite dans les logs. Ce n’est qu’au bout de quelques jours que j’ai découvert que les descripteurs de fichiers étaient épuisés, et que log4net ne pouvait pas non plus écrire de logs s’il n’arrivait pas à obtenir un descripteur de fichier. La solution consistant à annuler une petite correction de bug était simple, mais la vraie correction a été de personnaliser log4net pour qu’il garde toujours le fichier de log ouvert. Ainsi, même si l’application épuise tous les descripteurs de fichiers, les erreurs sont quand même enregistrées
    • Le paragraphe correspondant de l’article me dérange un peu : « J’ai remis en ligne une version avec une meilleure gestion des erreurs, mais l’upload d’images échouait sans aucun retour. D’habitude, le code hurle ses erreurs en rouge, et le silence est l’objectif. Ici, le silence était le problème. »
      Le silence n’est pas l’objectif. Trop de développeurs pensent que le silence est l’objectif, mais le véritable objectif est l’exactitude. S’il n’y a pas d’erreur, il faut être silencieux ; mais s’il y a une erreur qui affecte l’utilisateur, il doit y avoir une grosse boîte d’alerte rouge
      Je pense que les développeurs devraient apprendre à aimer les messages d’erreur. Un message d’erreur bien rédigé révèle rapidement la cause et fait gagner beaucoup de temps à tout le monde
      Si ce développeur a appris à afficher plus souvent des messages d’erreur à l’avenir, c’est un très bon résultat

  • Ça me rappelle un ancien collègue qui disait souvent : « On n’est pas en train de construire un système de contrôle aérien. » Il voulait dire que les erreurs ne mettaient pas des vies en jeu
    À l’époque, nous faisions des jeux, mais cette phrase s’appliquait aussi à presque toutes les applis CRUD que j’ai écrites
    À part ça, je demande souvent à d’autres responsables techniques seniors, surtout des Director, VP et CTO : « Quelle est l’erreur la plus coûteuse que vous ayez commise ? » Si vous êtes ingénieur junior, c’est quelque chose qu’il faut absolument faire un jour
    Beaucoup de dirigeants techniques de haut niveau peuvent raconter des histoires à 100 000 à 1 million de dollars. J’ai même vu quelqu’un faire perdre plusieurs millions de dollars sur un projet et être promu juste après. Il est important de comprendre pourquoi c’est possible, et même pourquoi cela peut être une bonne chose

    • Je ne suis pas d’accord. Un échec ne mène peut-être pas à une mort dans une boule de feu, mais il peut quand même causer du tort. Même de petits dommages s’accumulent à grande échelle
      La frustration provoquée par un jeu buggé peut se traduire dans la vraie vie par de la violence au volant ou des disputes à cris. Des gens se sont suicidés parce qu’un ordinateur leur avait envoyé une facture erronée. Des entreprises ont coulé parce qu’un logiciel avait perdu des données précieuses
      Des gens ont aussi été assassinés à cause d’applications de réseaux sociaux qui semblaient anodines, et des incitations au massacre ont été organisées sur Twitter. Certaines personnes ont été victimes de harcèlement et d’agressions à cause d’informations révélées par Pokemon Go
      Le logiciel a un pouvoir réel. Sinon, il n’y aurait aucune raison d’en écrire
    • L’attitude « On n’est pas en train de construire un système de contrôle aérien » me met aussi mal à l’aise
      J’ai déjà travaillé sur des logiciels capables de faire perdre des données précieuses, et je travaille maintenant sur un logiciel qui pourrait provoquer une inondation en cas de dysfonctionnement
      Il faut avoir un peu plus de fierté dans son travail

  • En tant qu’ingénieur logiciel, j’ai plutôt aimé le débogage. Parce que cela me faisait utiliser des compétences et une façon de penser différentes de celles nécessaires pour concevoir et implémenter
    Bien sûr, cela ne veut pas dire que le débogage n’est pas stressant. Quand je développais le logiciel du commutateur téléphonique 5ESS d’AT&T, on avait une démo, et dans le labo de test il n’y avait qu’une seule ligne téléphonique configurée pour notre fonctionnalité
    Après plusieurs tentatives, le logiciel ne fonctionnait toujours pas, et j’étais stressé à vérifier tout ce qui était possible, tout en étant convaincu que le logiciel était correct. Au final, j’ai demandé au technicien du labo de vérifier la ligne, et il s’est avéré que la seule ligne configurée était, d’une manière ou d’une autre, déconnectée. Un stupide problème matériel

    • Pareil pour moi. J’ai toujours apprécié le défi du débogage, surtout dans les systèmes complexes
    • Déboguer avec des outils, c’est agréable, mais beaucoup moins quand, à cause de certains choix, tout se retrouve trop éloigné, au sens figuré comme au sens propre
      Déboguer des systèmes distribués dans le cloud est exponentiellement plus horrible que quand on peut lancer tous les services en local, et même ce système distribué local est largement pire que lorsqu’on peut déboguer le problème dans un seul programme
      Un vrai débogueur rend aussi le débogage bien meilleur. Je n’ai jamais compris les gens qui s’en tiennent exclusivement au débogage à coups de printf ou à un vrai débogueur. Utiliser les deux apporte un gain énorme. De bonnes fonctions de traçage méritent aussi d’être soulignées ici, car quand elles sont disponibles, elles sont bien meilleures que le débogage au printf
      À mes débuts en programmation, j’associais beaucoup trop d’émotion inutile au fait de ne pas savoir pourquoi quelque chose se produisait, puis j’ai fini par accepter la boucle « attends, pourquoi ça fait ça ? Je ne sais pas… ah, attends… waouh, la raison pour laquelle ça ne marchait pas est vraiment logique ! », et par intégrer le fait qu’arrivé au bout, on se sent bien
      Désormais, l’état d’ignorance en lui-même ne peut être gâché que par les attentes et les comportements des autres. Avec le temps, j’ai appris qu’il faut gérer très fermement les choix de langage, d’architecture, etc., pour rendre ce processus simple et rapide
      À ce stade de ma carrière, il est beaucoup plus facile de convaincre en amont qu’AWS Lambda est un mauvais choix en matière de performances, de coût total, de débogabilité et de vitesse de développement, que de convaincre plus tard qu’il y a une bonne raison pour laquelle « corriger ce seul problème » prend autant de temps

  • La fin m’a fait rire. Pas plus tard qu’hier, j’ai résolu un problème qui nous empoisonnait depuis trois ans dans l’entreprise, et chez nous la cause était la lettre A
    Pendant ces trois dernières années, quelqu’un effectuait une correction manuelle en ajoutant et retirant des données, et c’était devenu une partie de son travail. Il avait même mis un événement récurrent dans son calendrier pour faire le ménage régulièrement. Des millions de clients dépendaient de cette seule personne pour que le bon forfait data soit appliqué à leur ligne mobile
    On peut imaginer le chaos s’il oubliait ou partait en congé
    Au final, la cause était if $line->status == STATUS_ACTIVE : d’un côté c’était Active, de l’autre active. Aucun chien n’a été blessé, mais une quantité incalculable d’argent a disparu au fil des années

    • Si cela avait été une affaire juridique, la blague aurait été : « Mais qu’est-ce que tu as fait ? Tu viens de résoudre l’affaire qui aurait payé la fac de droit à toute ma famille ! »
      Ce pauvre type n’est plus indispensable. C’est à moitié une blague. Le logiciel est censé rendre le travail plus efficace, mais j’ai tendance à aussi regarder les motivations humaines
    • J’ai déjà vu des cas piégeux où des caractères invisibles, comme des espaces ou des retours à la ligne, causaient des dégâts
      J’ai particulièrement souffert en remplissant des champs HL7 sur Mac. Il me semble que le caractère ’ saisi sur un clavier Mac n’était pas compatible avec toutes les versions de HL7, ou ne convenait pas à la destination à laquelle HL7 était transmis
      C’est un vieux souvenir, mais une différence entre des mots comme o’clock et o′clock avait cassé la distribution de rapports de radiologie. Cela a duré des années avant d’être repéré
      HN affiche le ’ différemment de ce que j’ai saisi, mais c’est toujours le même caractère. C’est assez drôle, puisque la moitié du problème était justement qu’on ne voyait pas la différence pendant le débogage
    • Est-ce que STATUS_ACTIVE était mal défini dans une partie du code ?
      Il y a toujours le risque que quelqu’un corrige « gentiment » la faute referer en referrer dans HttpHeader::REFERRER. Mais cette faute est figée dans le standard HTTP, donc faire ça casse complètement le logiciel. C’est la faute de Phillip Hallam-Baker, à l’époque du CERN

  • L’anecdote du nid de guêpes me parle beaucoup
    Le propriétaire de notre immeuble de bureaux a installé à l’extérieur du bâtiment une interface à écran tactile permettant d’appeler les différents accueils et de déverrouiller la porte. Il a fait ça parce qu’il n’y avait pas de réceptionniste pouvant voir la porte
    L’appareil a tenu six mois avant de commencer à très mal fonctionner. La cause était qu’ils avaient installé sur la façade est du bâtiment cette interface qui était, en pratique, une grosse tablette Android noire
    À partir du milieu du printemps, elle recevait chaque jour assez de soleil pour surchauffer, ce qui a endommagé l’électronique tactile et une partie du matériel de l’écran
    Dans le type de logiciel que je produis, je n’ai pas à me soucier de la charge thermique

    • Cela me rappelle l’histoire du soleil qui arrête les trains. D’après Southeastern, le trafic à Lewisham, dans le sud-est de Londres, avait été retardé à cause de l’angle du « soleil bas d’hiver »
      La compagnie ferroviaire avait publié sur Twitter : « Il y a eu une forte congestion sur la ligne passant par Lewisham en raison de problèmes de départ causés par une forte lumière du soleil »
      Elle avait aussi expliqué que le soleil bas d’hiver éclairait les moniteurs de départ, empêchant les conducteurs de les voir

  • Le message « J’ai enfin trouvé. C’était à cause de la lettre “E” » est amusant
    Les bogues les plus simples et les plus petits sont souvent les plus difficiles à trouver. Ce matin encore, j’ai perdu une heure ou deux à traquer une erreur off-by-one
    La cause était un index + 1 que j’avais oublié de modifier pendant un refactoring

    • Comme on dit souvent, il y a deux problèmes difficiles en informatique : l’invalidation de cache, le nommage, et les erreurs off-by-one