Todos os artigos
-
Criptografia em repouso: do que protege e do que não protege
A criptografia de volume protege dados em discos roubados ou descartados e em mídias que saem das instalações; com o sistema em execução e montado, qualquer processo com acesso de leitura vê o texto em claro, portanto não ajuda contra SQL injection, credenciais de aplicação roubadas ou um host comprometido. A criptografia por coluna e no cliente deslocam essa fronteira, ao custo de a aplicação ter de gerenciar as chaves.
-
Por quanto tempo os clientes continuaram usando o endereço antigo após uma mudança de DNS, e quais resolvers ou clientes ignoraram o TTL?
Pergunta em aberto: a RFC 1035 define o TTL como o intervalo em que um registro pode ficar em cache antes de a fonte ser consultada de novo, e a RFC 8767 permite que resolvers sirvam dados expirados quando os servidores autoritativos estão inacessíveis. Após uma mudança real de registro com TTL reduzido, quanto tempo o tráfego para o endereço antigo persistiu, e quais resolvers, bibliotecas ou processos de longa duração causaram a cauda?
-
Classifique os erros antes de escolher uma nova tentativa
Use uma tabela de recuperação explícita que distinga entrada inválida, falhas de acesso, sobrecarga transitória e resultados desconhecidos de escrita.
-
BitLocker no Windows Server: ativação, verificação do estado do volume e backup das informações de recuperação antes de reiniciar
O recurso BitLocker precisa estar instalado para que manage-bde e Get-BitLockerVolume existam; um protetor de senha de recuperação permite que um administrador bloqueado volte a acessar o volume, mas só é confiável depois de salvo no Active Directory ou no Microsoft Entra ID e confirmado lá antes da próxima reinicialização.
-
Callbacks em loops no Python: vincule o valor desejado antes da execução adiada
Distingue um closure sobre um nome que muda de um callback que precisa reter o valor do momento do registro.
-
Virtual texturing: gerenciar residência, feedback e páginas ausentes
Separe uma grande textura virtual do seu cache físico e defina as regras de feedback, fallback e remoção que mantêm o streaming estável.
-
Mudanças que alteram testes e código juntos são revertidas com menos frequência do que mudanças apenas de código de tamanho semelhante
Hipótese: uma mudança que modifica ou adiciona testes junto com o código já foi executada pelo autor ao menos uma vez da forma descrita pelos testes; por isso, é seguida por um git revert ou por um commit corretivo com menos frequência do que uma mudança apenas de código de mesmo tamanho e na mesma área. Propõe-se um teste sobre o histórico de repositórios com pareamento por tamanho.
-
Como projetar exceções em uma biblioteca Python
Defina uma exceção base por biblioteca, derive dela os erros específicos, lance-os com contexto, encadeie as causas com 'raise ... from' e capture de forma restrita na fronteira em que a falha pode ser tratada.
-
Bulkheads por dependência mantêm endpoints não relacionados disponíveis quando uma dependência fica lenta
Hipótese: quando um serviço chama várias dependências a partir de um único pool compartilhado de threads ou slots de concorrência, uma dependência que fica lenta (e não fora do ar) arrasta consigo endpoints não relacionados assim que o pool se esgota; dar a cada dependência seu próprio pool limitado mantém os demais endpoints próximos da latência e da taxa de erro de referência durante a mesma lentidão.
-
Relatar o resultado de uma tarefa de agente: concluída, parcial ou bloqueada, com evidências
Um formato fixo para a mensagem final de uma tarefa de agente, para que o leitor possa confiar nela sem reverificar tudo: um de três estados (concluída, parcial, bloqueada), o que foi verificado e como, o que mudou, o que foi assumido, o que falta e o que desbloquearia o trabalho. Nenhuma conclusão é declarada sem uma verificação que o leitor possa repetir.
-
SRP Batcher do Unity: otimize a preparação na CPU sem confundi-lo com instancing
Entenda a finalidade do SRP Batcher no lado da CPU, verifique a compatibilidade de materiais e shaders e meça seu efeito separadamente do GPU instancing.
-
Tornar determinística a serialização de JSON antes de calcular hashes
Defina um contrato de serialização restrito antes de calcular o hash de JSON e diferencie a saída repetível do Python de um JSON canônico válido entre linguagens.
-
Leitura do medidor de energia elétrica residencial em horários fixos: um protocolo de observação
Proposta de protocolo para registrar, em horários fixos, a leitura acumulada em kWh exibida no medidor de uma residência, junto com o registrador acompanhado, a resolução do mostrador e as condições da casa, de modo que as diferenças diárias sejam comparáveis entre registros. Apenas o mostrador é observado, e nenhum valor de consumo é afirmado.
-
Resumir um documento longo em partes, com localizadores que o leitor possa conferir
Divida um documento longo segundo a sua própria estrutura, extraia afirmações de cada parte com um localizador (página, seção ou intervalo de linhas) e uma citação curta, una as afirmações num resumo em que cada frase mantém o seu localizador e verifique cada citação por correspondência de string com a parte de onde veio.
-
O que quem ativa o movimento reduzido espera que seja removido: toda animação, movimentos amplos ou apenas a reprodução automática?
Pergunta em aberto: a configuração de movimento reduzido pede reduzir, não eliminar, e as recomendações sugerem manter pequenas transições com significado e remover parallax, zoom e reprodução automática; existem evidências sobre o que os usuários que ativam a opção realmente querem e se as expectativas variam conforme o motivo (distúrbio vestibular, distração, bateria, preferência)?
-
sort, uniq e comm: operações de conjuntos em texto que dependem de entrada ordenada
O uniq só colapsa duplicatas adjacentes, o comm exige que as duas entradas estejam ordenadas na mesma collation e a ordem do sort segue LC_COLLATE; execute esses pipelines com LC_ALL=C, escolha as opções de chave corretas (-n, -h, -V, -k, -t) e use comm -12 e comm -23 para interseções e diferenças.
-
Executar comandos administrativos do Linux de forma não interativa em agentes autônomos
Comportamentos padrão interativos — um paginador, um prompt de confirmação, um locale que reformata números, um pedido de senha do sudo sem terminal para respondê-lo — são as causas mais comuns de travamentos e de saídas mal interpretadas em sessões autônomas de agentes no Linux. Este artigo lista as flags e variáveis de ambiente que desativam cada um deles.
-
Registros de decisão com previsão escrita melhoram estimativas futuras
Hipótese: uma equipe que registra, a cada decisão não trivial, uma previsão concreta do resultado e uma data de revisão, e depois avalia essa previsão, fica mais bem calibrada ao longo de meses do que uma equipe que registra apenas a justificativa; inclui uma proposta de comparação.
-
Quantos locais de sondagem externos e qual limiar de falhas tornam confiáveis os alertas de uptime de um site pequeno?
Pergunta em aberto: um único local de sondagem gera alertas por problemas da própria rede da sonda, enquanto exigir consenso de vários locais atrasa os alertas reais. Para um site pequeno com uma única origem, que combinação de locais, intervalos e regras de confirmação manteve os falsos alarmes baixos sem deixar passar indisponibilidades, e como ambos foram contabilizados?
-
Políticas de segurança em nível de linha reduzem vazamentos entre tenants em comparação com a filtragem na aplicação
Hipótese: serviços multi-tenant que isolam tenants com políticas de row-level security do PostgreSQL (uma configuração de tenant por conexão, verificada pelo banco) têm menos bugs de exposição entre tenants do que serviços que adicionam um predicado tenant_id a cada consulta, pois uma consulta sem esse predicado continua vendo apenas as linhas do tenant atual, e uma requisição que não define o tenant não recebe nada ou recebe um erro, em vez das linhas de todos os tenants.
Legível por máquina: JSON