Como este blog é feito

Como um artigo nasce

A esteira separa pesquisa, redação, execução e decisões humanas. O status mostrado na página corresponde ao que realmente aconteceu — sem inventar revisão ou teste.

1. A pauta vem de uma lacuna real de busca. Nenhum artigo nasce de "vamos falar sobre X". Partimos do que as pessoas de fato digitam — mensagens de erro coladas inteiras, dúvidas de sintaxe, comparações entre duas ferramentas — e olhamos o que já existe em português. Se as primeiras respostas do Google já resolvem bem o problema, não escrevemos a quarta versão da mesma coisa. Escrevemos onde a resposta em português está ausente, rasa ou desatualizada.
2. A pesquisa é ancorada em documentação oficial. A fonte primária é a documentação da linguagem, do framework ou do provedor na versão vigente, somada ao changelog e às issues quando o comportamento é ambíguo. Post de terceiro serve para achar o problema, nunca para afirmar o comportamento. O que sustenta uma afirmação vai listado no fim do artigo, com link.
3. A redação é assistida por IA. A partir da pesquisa, de um roteiro e do guia de estilo da casa, um primeiro texto é rascunhado com modelos de linguagem. Isso acelera estrutura e volume — e é exatamente aí que entra o resto do processo, porque velocidade sem verificação produz texto plausível e errado.
4. A revisão técnica, quando declarada, é humana. Uma segunda pessoa lê o artigo inteiro atrás do que a IA erra bem: método que não existe, opção que mudou de nome entre versões, explicação convincente e falsa, exemplo que só funcionava há três anos. O campo de revisão e o dado estruturado reviewedBy só aparecem depois dessa pessoa concluir e aprovar o trabalho.
5. O código roda antes de o texto sair. Os blocos são executados num ambiente limpo, com a versão do runtime fixada, e o que aparece como saída na página é o que saiu do terminal. Código que não roda não vai ao ar — salvo quando o erroé o assunto do artigo, e aí ele aparece identificado como tal, com o stack trace real. Exemplo que não dá para executar assim existe, e o artigo diz isso claramente: fica sem o selo da etapa seguinte.
6. A revisão de estilo fecha. Última passada, sobre a leitura: título e descrição que prometem o que o texto entrega, exemplo antes de teoria, jargão explicado na primeira aparição, nada de parágrafo de aquecimento antes da resposta.

Como o Método DevClub transforma assunto técnico em entendimento

Simples não significa impreciso. Nós usamos o nome correto — estado, middleware, transação, índice, contexto — e traduzimos esse nome antes de cobrar que você o memorize. O leitor conhece a peça técnica e, ao mesmo tempo, entende qual problema ela resolve.

Cada explicação segue um ciclo curto e observável:

1. começa pelo resultado que a pessoa quer enxergar na tela ou no terminal;
2. dá nome à peça técnica e a traduz com palavras comuns;
3. usa uma comparação do cotidiano — uma cozinha, uma fila, uma gaveta — deixando claro onde a comparação termina;
4. volta ao mecanismo real, com código pequeno e saída visível;
5. muda uma coisa por vez, para o leitor prever o resultado antes de rodar;
6. fecha com uma missão que obriga a fazer, testar e explicar.

A comparação é uma ponte, não a explicação inteira. Dizer que uma variável parece uma gaveta ajuda a começar; mostrar escopo, reatribuição e o valor impresso no console é o que faz a pessoa programar. Por isso nenhum artigo termina na analogia e nenhum bloco de código aparece como decoração.

Onde a IA entra — e onde ela não entra

Na prática, isso delimita quatro coisas que a IA não faz por aqui:

• não escolhe a pauta sozinha — a decisão de escrever é editorial e humana;
• não decide se um código funciona — quem decide é a execução, e a execução é automática e registrada;
• não produz dado original: número de benchmark, medição de tempo e resultado de teste vêm de execução própria, nunca de estimativa do modelo;
• não recebe autoria nem revisão fictícias — nomes de pessoas só aparecem em papéis que elas realmente assumiram e aprovaram.

O selo de código testado

Quando um artigo aparece com o selo código testado no topo, três coisas são verdade ao mesmo tempo: o código foi executado exatamente como está na página, sem trecho omitido; a saída impressa depois de cada bloco é a daquela execução, copiada e não redigida; e a versão exata do runtime vem escrita no cabeçalho do artigo. A versão pode variar entre um LTS usado em produção e uma versão atual reproduzida para testar uma mudança — o selo sempre declara qual delas foi usada.

Exemplo que depende de chave de API, de rede instável ou de uma máquina específica não recebe o selo, e o artigo diz por quê. O selo é uma promessa estreita e verificável: é justamente por não valer para tudo que ele vale para alguma coisa.

Quando erramos

Erramos. Uma API muda, um número envelhece, uma frase sai ambígua. Quando é erro de fato — código que não roda, informação incorreta, recomendação que hoje seria outra — corrigimos o artigo, atualizamos a data de modificação e, se a correção muda a conclusão de quem já leu, deixamos uma nota de correção visível no fim do texto. Não apagamos o rastro. Quando é só clareza, reescrevemos sem alarde.

Achou um erro, um exemplo que não roda ou uma explicação que não bate com a documentação? Fale com a gente noInstagram ou nos comentários do canal no YouTube. Mande o link do artigo e o trecho: com os dois em mãos, a correção entra na frente da fila de publicação.

Política de atualização

Artigo de sintaxe, conceito ou erro comum é conteúdo permanente, e conteúdo permanente apodrece em silêncio. Por isso cada um entra em uma fila de revisão periódica, por área. Na revisão verificamos três pontos: se o código ainda roda na versão atual do runtime, se a documentação oficial mudou desde a última passada, e se a recomendação do texto ainda é a que daríamos hoje.

A data de modificação só muda quando o conteúdo muda. Uma revisão que não encontrou nada para corrigir não altera data nenhuma. Não tocamos a data para simular frescor — é essa disciplina que faz a data de modificação declarada nos nossos sitemaps significar alguma coisa, para o leitor e para o buscador.