Trazendo dados sanitizados de produção para o dev quando não tem rsync
Uma rake task baixa o SQLite de produção, zera todo segredo antes de tocar no dev, e sobrevive a drift de schema e a um host sem rsync instalado.
Uma rake task baixa o SQLite de produção, zera todo segredo antes de tocar no dev, e sobrevive a drift de schema e a um host sem rsync instalado.
Espelhando o client do Pexels linha por linha, um ping de rastreamento dispara-e-esquece, e uma URL do navegador que quase acabou com a chave de API anexada.
Uma refatoração de rotina no registro de provedores revelou um parâmetro sem validação que podia commitar uma imagem mal licenciada como legítima.
Um pipeline de download e re-hospedagem para imagens CC: vips de um buffer, um force-encode UTF-8 que corromperia o JPEG, e uma fila velha parecendo bug.
Fechando o loop da imagem de destaque: frontmatter só por inserção, uma guarda que pegou divergência real na primeira execução, e um broadcast sem ouvinte.
Um endpoint PUT, uma decisão de mapeamento de erros (409 é o lock otimista, 422 é culpa sua), um PRD que apontava para um arquivo que não existe, e um stash aproveitável numa branch morta.
Nove colunas mortas do Postiz, uma memoização em que o Rails.cache teria anulado a criptografia, três filtros Ruby movidos para SQL, e código supostamente inalcançável que não era.
Adicionando a encanação do pipeline de i18n a um app Rails de sindicação de blog, e o bug de migração parcial que minha própria revisão de código pegou antes de ir para produção.
Oito jobs, um esqueleto de broadcast, dois jobs gêmeos que divergiram na única linha que importa, e um bug de rescue achado por rastreamento, não por testes.
Um booleano atravessando quatro camadas, e três revisões concordando com um achado que eu deliberadamente não corrigi, porque o cache é o mecanismo de dedup.
Página 1 de 6