Todos os artigos
-
Após quantos soft bounces, em que período, um remetente deve parar de enviar e-mails para um endereço?
Pergunta em aberto: os códigos de status avançados separam falhas permanentes (5.X.X) de falhas transitórias persistentes (4.X.X), mas o padrão deixa o caso transitório a cargo da política do remetente; que limites os remetentes já usaram e o que aconteceu com as taxas de recuperação e com a reputação?
-
Tempo decorrido em Go: a serialização perde o componente do relógio monotônico
Mantenha a medição local de duração separada dos timestamps persistidos e das políticas de prazo entre processos.
-
Nomes e capitalização consistentes nos campos JSON
Escolha uma única convenção de capitalização para os nomes de propriedades e aplique-a em toda parte: o guia de estilo JSON do Google e o ProtoJSON usam lowerCamelCase, e muitas APIs usam snake_case. Além da capitalização, use nomes significativos, enums como strings, timestamps como strings RFC 3339 e inteiros de 64 bits como strings.
-
Gerar, criticar, revisar: quando um ciclo de autoverificação compensa
Um ciclo em que o modelo critica e revisa a própria saída melhora os resultados quando a crítica dispõe de um sinal externo (testes, um validador, uma fonte) e de um critério fixo; sem isso, resultados publicados mostram que pode piorar as respostas, e cada rodada acrescenta pelo menos duas chamadas cuja entrada cresce com o rascunho.
-
A especificação Standard Webhooks versus o cabeçalho HMAC da Shopify e o token de segredo compartilhado do GitLab
A especificação Standard Webhooks define os cabeçalhos webhook-id, webhook-timestamp e webhook-signature, um segredo em base64 com prefixo whsec_ cujos bytes decodificados são a chave HMAC e uma assinatura v1,<base64> sobre "{id}.{timestamp}.{payload}"; os tokens de assinatura do GitLab (GitLab 19.0, disponibilidade geral na 19.1) seguem exatamente esse modelo. A Shopify, por sua vez, envia em X-Shopify-Hmac-SHA256 um HMAC em base64 do corpo bruto, e o X-Gitlab-Token mais antigo do GitLab é apenas um segredo compartilhado, sem HMAC algum.
-
Modelo de hipótese
Um esquema para formular uma hipótese explícita e testável, em vez de um fato estabelecido.
-
Transformar o escopo de uma avaliação autorizada em condições de parada executáveis
Ajuda um agente de avaliação a parar no limite acordado, mesmo quando a próxima ação sugerida parece tecnicamente conveniente. O método converte o escopo aprovado pelo operador em decisões testáveis antes de qualquer interação com o alvo.
-
Unity Addressables: como projetar tempos de vida explícitos de carregamento e liberação
Atribua a cada carregamento assíncrono um responsável claro, mantenha o handle durante todo o período de uso e defina a limpeza para requisições que falham ou ficam obsoletas.
-
Armazenar dados derivados no PostgreSQL: colunas geradas ou views materializadas
Uma coluna gerada deriva um valor por linha apenas a partir dessa mesma linha, podendo ser virtual (calculada na leitura) ou armazenada (calculada na escrita), e aceita só expressões imutáveis; uma view materializada guarda o resultado de qualquer consulta e só está tão atualizada quanto o último REFRESH. Use colunas geradas armazenadas para normalização por linha que deva ser indexada, views materializadas para agregações caras que podem ficar defasadas e uma tabela de resumo mantida quando nenhuma das duas serve.
-
Testar que atualizações de perfil não conseguem atribuir campos privilegiados da conta
Crie uma regressão específica para atualizações que aceitam dados comuns de perfil junto com campos que o chamador não pode controlar. O método propõe definir explicitamente a quem pertence cada campo, em vez de usar uma checklist genérica de validação de entrada.
-
Armazenamento no navegador: comparação entre cookies, Web Storage e IndexedDB
Os cookies viajam em cada requisição e têm tamanho reduzido por especificação; localStorage e sessionStorage são armazenamentos síncronos de strings com poucos MiB por origem; o IndexedDB é assíncrono, transacional e usa a cota ampla da origem. Todo armazenamento no navegador é best-effort, a menos que a persistência seja concedida, e é delimitado por origem.
-
Campos packed em Rust: evite criar uma referência desalinhada antes de converter para ponteiro bruto
Entenda por que uma referência temporária já pode violar os requisitos de alinhamento e prefira, sempre que possível, a decodificação explícita de bytes.
-
Como escrever um teste unitário em JUnit 5 e xUnit.net: anotações, ciclo de vida e casos parametrizados lado a lado
O JUnit Jupiter marca testes com @Test, executa @BeforeEach e @AfterEach em torno de cada um, por padrão numa instância nova, e conduz casos baseados em dados com @ParameterizedTest mais uma anotação de fonte. O xUnit.net usa [Fact], o construtor e IDisposable para a preparação por teste numa instância nova, [Theory] com [InlineData] para os casos e fixtures para contexto compartilhado e caro. Escrever testes com a mesma estrutura nos dois mantém alinhadas as convenções de uma equipe poliglota.
-
Verificação de pacotes RPM instalados contra adulteração com rpm -V
O `rpm -V` compara os arquivos instalados com os checksums, permissões e proprietários registrados na instalação do pacote, e os códigos de uma letra na saída indicam exatamente o que mudou. Esta metodologia explica como ler essa saída e quais são seus limites como verificação de integridade.
-
A Same-Origin Policy: o que é uma origem e o que ela isola
Uma origem é o conjunto formado por esquema, host e porta de uma URL. Scripts podem ler e modificar documentos, armazenamento e respostas da mesma origem; leituras entre origens são bloqueadas por padrão, enquanto escritas (como envio de formulários) e incorporações (como imagens e scripts) costumam ser permitidas. O CORS flexibiliza as leituras; as defesas contra CSRF continuam necessárias.
-
VACUUM, autovacuum e bloat de tabelas
O MVCC do PostgreSQL deixa versões mortas de linhas após updates e deletes; o VACUUM as recupera, mantém as estatísticas e protege contra o wraparound de IDs de transação. O autovacuum deve permanecer ativo e ser ajustado para tabelas com muito movimento.
-
O que um cluster Raft garante: maiorias, um único líder e leituras linearizáveis
Sistemas de consenso como o etcd (Raft) permitem que uma maioria de servidores concorde sobre um log ordenado; permanecem corretos diante de qualquer número de falhas, mas só avançam enquanto uma maioria estiver acessível. Leituras linearizáveis passam pelo consenso e custam latência; leituras serializáveis são atendidas localmente e podem estar desatualizadas.
-
Tornar um site legível para agentes: robots.txt, sitemaps e llms.txt
Agentes e crawlers encontram conteúdo por meio de poucas convenções: robots.txt para regras de acesso e a localização do sitemap, um sitemap XML com datas de modificação reais e o llms.txt como guia curto e selecionado; nenhuma delas substitui a autenticação.
-
Após a chegada de um relatório de vulnerabilidade: confirmar, avaliar, corrigir em privado e divulgar
Quando um relatório chega ao contato de segurança do projeto, o trabalho segue uma sequência com datas: confirmar o recebimento rapidamente, classificar (comportamento esperado, bug, pedido de funcionalidade ou vulnerabilidade), combinar um embargo com quem reportou, desenvolver a correção em privado, obter um identificador CVE e então lançar a versão e publicar um aviso que indique as versões afetadas e corrigidas e dê crédito a quem reportou. O guia de mantenedores da OpenSSF e as orientações de divulgação do GitHub descrevem esse processo; este artigo o resume para projetos com um a cinco mantenedores.
-
Atas de reunião com uma seção separada de decisões reduzem a reabertura de decisões
Hipótese: equipes cujas atas listam cada decisão em separado (enunciado, opções rejeitadas, responsável, data) e a copiam para um log de decisões duradouro reabrem questões já resolvidas com menos frequência do que equipes com atas narrativas, porque uma decisão que pode ser encontrada e citada tem menos chance de ser rediscutida do zero.
Legível por máquina: JSON