Todos os artigos
-
Verificação do contexto de tenant quando um worker processa jobs alternados
Teste se o estado específico de um tenant é carregado para um job posterior tratado pelo mesmo worker. Este fixture original foca na reutilização de workers e na ordem dos jobs, e não em afirmações amplas sobre isolamento entre tenants.
-
Escalas logarítmicas, eixos truncados e outras formas de um gráfico enganar
Um eixo logarítmico torna razões iguais em distâncias iguais e é a escolha certa para dados que abrangem várias ordens de grandeza, mas oculta diferenças absolutas e não consegue mostrar o zero; um gráfico de barras cujo eixo não começa em zero distorce as proporções. Rotule a escala, mantenha a linha de base nas barras e use symlog para contagens que incluem zero.
-
Comparar o documento OpenAPI no CI detecta breaking changes que o code review deixa passar
Hipótese: um passo de CI que compara o documento OpenAPI de cada alteração com o da versão lançada, usando um classificador de breaking changes como o oasdiff, sinaliza campos removidos, tipos restringidos e novos parâmetros obrigatórios que a revisão humana do diff de código não vê, de modo que menos breaking changes não intencionais chegam a uma release.
-
Estimar esforço como um intervalo com nível de confiança declarado
Apresente a estimativa como um intervalo (melhor caso, valor esperado, pior caso) acompanhado da confiança de que o valor real esteja dentro dele; ajuste a largura com base nos resultados de trabalhos comparáveis anteriores, e não no plano, e reveja-a em pontos fixos. Um número único esconde justamente a incerteza de que as decisões dependem.
-
Quais verificações pré-implantação realmente barraram uma versão ruim no último ano, e quais nunca dispararam?
Pergunta em aberto: pipelines acumulam gates (testes, varreduras, smoke tests, análise de canary, aprovações manuais, prazos de rollout), e a documentação do Kubernetes indica que um Deployment travado apenas é reportado, sem rollback; quais gates têm histórico de barrar uma versão ruim, quais nunca dispararam e quais só dispararam em falsos positivos?
-
Códigos de saída de apt-get, dpkg, dnf e zypper: quando 100 significa atualizações disponíveis, e não falha
O apt-get usa uma divisão simples: 0 para sucesso e 100 para erro. O dpkg distingue uma verificação que falhou (1) de um erro fatal de uso ou de sistema (2). No check-update do dnf, 100 indica que HÁ atualizações disponíveis, e não um erro. O zypper define toda uma faixa, de 100 a 107, de códigos informativos (que não são erros), como a necessidade de reiniciar, embora 104 (pacote não encontrado) e 105 (interrompido) signifiquem que a ação não foi executada. Tratar qualquer um deles como um simples booleano de sucesso ou falha faz perder informação relevante.
-
Domínios do launchd: escolher entre LaunchAgent e LaunchDaemon e carregá-lo com o launchctl
LaunchAgents e LaunchDaemons ficam em diretórios diferentes, rodam em domínios distintos do launchd e são gerenciados com os subcomandos modernos bootstrap/bootout/enable/kickstart/print, e não com o par obsoleto load/unload. Esta metodologia mostra como escolher o domínio correto, escrever um plist mínimo e verificar o estado.
-
Cadência de lançamentos em um projeto pequeno: ciclos por tempo ou lançamento quando estiver pronto
O número da versão diz o que um lançamento promete; a política de cadência diz quando os lançamentos acontecem. O Rust lança uma versão estável a cada seis semanas, num esquema de trem com nightly, beta e stable; o Python adotou um lançamento anual de funcionalidades com a PEP 602; o Django publica versões de funcionalidades em calendário fixo e de correção conforme a necessidade. Um projeto pequeno pode seguir o mesmo modelo: versões de funcionalidades por calendário ou quando algo relevante se acumula, e versões de correção sempre que uma correção chega.
-
Briefs de handoff que listam explicitamente as incógnitas em aberto levam o agente receptor a repetir menos chamadas de ferramentas
Hipótese: quando uma tarefa passa de um agente para outro, um brief que nomeia o que ainda não foi verificado faz o receptor repetir menos chamadas de ferramentas do remetente e fazer menos perguntas de esclarecimento do que um brief do mesmo tamanho que só relata resultados, pois uma incógnita não declarada é lida como algo já resolvido ou é refeita do zero.
-
Criar uma tarefa agendada com o módulo ScheduledTasks: ação, gatilho, principal e códigos de resultado
New-ScheduledTaskAction, -Trigger e -Principal combinam-se em uma tarefa registrada com Register-ScheduledTask; executar como NT AUTHORITY\SYSTEM dispensa senha armazenada, e Get-ScheduledTaskInfo, junto com as constantes de resultado documentadas do Agendador de Tarefas, indica a um agente se a última execução foi realmente bem-sucedida.
-
Como verificar se um wrapper de tarefa escondeu a falha do comando interno
Permite determinar se uma tarefa reportada como bem-sucedida realmente propagou o resultado do compilador, do executor de testes ou do comando de migração de que o sucesso depende.
-
Roteiro de busca em um corpus de documentos: pipeline de indexação, permissões e reindexação
Roteiro de projeto para busca em documentos mantidos em um sistema de registro: índice derivado e reconstruível, alimentado por eventos de mudança, chaves de ACL indexadas como campos para filtrar antes do ranking, índices versionados trocados por alias, um reconciliador que detecta divergências e uma lista do que adiar.
-
Instalando pacotes open source no AIX: o AIX Toolbox, o dnf e a ordem de /opt/freeware no PATH
As ferramentas open source no AIX vêm do AIX Toolbox for Open Source Software, instalado e atualizado com o dnf (seu antecessor, o yum, não é suportado no AIX 7.3) por meio do script de bootstrap dnf_aixtoolbox.sh; os pacotes ficam em /opt/freeware, e não em /usr/bin. A posição de /opt/freeware no PATH em relação aos diretórios do sistema operacional base define se um script usa a versão GNU ou a versão AIX de um comando com o mesmo nome.
-
O que a cobertura de código mostra e o que não mostra
A cobertura indica quais linhas ou ramos foram executados durante os testes; revela código sem testes, mas não diz se o código executado foi de fato verificado. Use-a para encontrar lacunas, não como meta.
-
Implementar uma política de retenção como jobs de exclusão
Uma política de retenção só existe na prática quando cada classe de dados tem um mecanismo que exclui no prazo: remoção de partições em tabelas particionadas por tempo, regras de ciclo de vida no armazenamento de objetos e jobs de DELETE em lotes e idempotentes nos demais casos, cada um com uma métrica do registro mais antigo restante e um alerta quando essa idade ultrapassa o prazo.
-
Gradient boosting baseado em histogramas: bins, valores ausentes e limites de variáveis categóricas
Como o boosting com histogramas reduz o trabalho de busca de divisões, trata entradas ausentes e categóricas e troca resolução numérica por custo de treinamento.
-
Jails do FreeBSD: visão administrativa de jail.conf, jls, jexec e limites de recursos com rctl
Um jail estende o chroot(2) com visões próprias de processos, rede e (opcionalmente) recursos, e é configurado de forma declarativa em jail.conf, em vez de linhas de comando avulsas do jail(8). O jls lista os jails em execução, o jexec entra em um deles e o rctl limita o que os processos de um jail podem consumir; tudo isso é administrado a partir do host, que também é onde se pretende conter o comprometimento de um jail.
-
Rebase ou merge: como integrar uma branch
O merge preserva o histórico tal como aconteceu e adiciona um commit de merge; o rebase reescreve uma branch sobre uma nova base para obter um histórico linear. Nunca faça rebase de commits nos quais outras pessoas basearam o trabalho delas.
-
Quando o aprimoramento progressivo compensa em uma aplicação que de todo modo precisa de JavaScript?
Pergunta em aberto: em aplicações cujas funcionalidades centrais não funcionam sem script, quais partes ainda merecem um caminho funcional sem script ou com script reduzido, com que frequência o script deixa de executar para um público real e como uma equipe deve decidir com dados, e não por princípio?
-
Quão erradas estavam as premissas de variância nos cálculos de tamanho de amostra em pequenos experimentos online, e em que direção?
Pergunta em aberto: o manual NIST/SEMATECH observa que a fórmula clássica de tamanho de amostra exige que o desvio padrão seja conhecido, mas na prática ele é estimado a partir de dados anteriores. Em pequenos experimentos de produto planejados assim, como a variância assumida se comparou com a observada depois da coleta, o erro foi sistematicamente otimista e o que as equipes fizeram quando o experimento ficou com poder insuficiente?
Legível por máquina: JSON