Ir para o conteúdo

Blogue ·

Uma data futura não é um calendário

Vinte e quatro artigos publicados afirmavam ainda não ter saído. A solução não foi um agendador mas uma compilação que recusa esse tipo de datas.

Por Provibr

Cada artigo deste sítio leva uma data de publicação no seu cabeçalho. Aparece sob o título, entra nos dados estruturados que um motor de busca lê, e é a única data que o mapa do sítio alguma vez imprime. Devia ser um facto.

Durante algum tempo, vinte e quatro delas não eram. Levavam datas distribuídas pelos seis dias seguintes, porque quem as escreveu tinha em mente um ritmo de publicação e pô-lo no ficheiro. Nove línguas cada um, ou seja duzentos e dezasseis ficheiros. Cada uma dessas páginas estava publicada, era rastreável e estava indexada, e cada uma contava a um rastreador, em forma legível por máquina, que tinha saído num dia que ainda não tinha acontecido.

Não havia nada a vermelho. A compilação estava verde, os testes estavam verdes, as páginas eram servidas. A única coisa capaz de ver a contradição era uma máquina a ler a página, e as máquinas não abrem ocorrências.

O que dizia o historial

A primeira coisa a estabelecer era qual das duas datas era verdadeira. Isso é um comando: perguntar ao git quando cada ficheiro foi acrescentado pela primeira vez. Os vinte e quatro foram acrescentados no mesmo dia, em três entregas, por três rondas do mesmo trabalho noturno. Não houve lançamento ao longo de seis dias. A dispersão era uma intenção escrita num campo reservado a observações.

Essa distinção é o artigo inteiro. Um campo que regista o que aconteceu não pode exprimir também o que se planeia, porque um leitor não consegue distinguir as duas coisas e um rastreador também não.

Porque não construímos o agendador

A reparação óbvia é tornar as datas verdadeiras fazendo com que o sítio as respeite: esconder um artigo até chegar a sua data. Aqui é a reparação errada por duas razões independentes, e vale a pena escrever ambas porque a primeira escapa com facilidade.

Este sítio é gerado de forma estática. As páginas são compostas uma vez, durante a compilação, e servidas como ficheiro. Um portão sobre a data é portanto avaliado no momento da compilação e nunca mais. À meia-noite não aparece nada; aparece quando alguém compila. Um portão de data não produz assim um calendário de publicação, mas um conjunto de páginas ausentes até calhar correr um lançamento sem relação nenhuma.

A segunda razão é pior. Aqueles duzentos e dezasseis endereços já tinham sido rastreados. Escondê-los até à sua data nominal significa servir um 404 durante até seis dias em páginas que um motor de busca já viu e indexou. Um 404 num endereço já indexado não é um «volte mais tarde», é um sinal de remoção, e recuperar disso custa muito mais do que a inexatidão corrigida.

As datas foram por isso corrigidas para o dia em que o trabalho aterrou mesmo, tocando apenas nessa linha em cada um dos duzentos e dezasseis ficheiros, e em vez disso foi retirada a possibilidade de escrever uma data futura.

O portão está na origem e não tem saída de emergência

A compilação de conteúdos recusa agora qualquer data de cabeçalho posterior ao dia em que compila. Não um aviso: uma compilação falhada, com o nome do ficheiro e ambas as datas na mensagem.

Duas pequenas decisões lá dentro merecem nome. Compara com o hoje no fuso horário do próprio projeto e não com UTC, porque um artigo publicado aqui à meia-noite e meia leva a data daqui, e uma comparação com UTC recusaria um ficheiro no próprio dia da sua publicação. E não há de propósito qualquer exceção: nem variável de ambiente nem opção. Uma saída de emergência numa regra destas usa-se uma vez por bom motivo e depois de forma permanente, e um calendário pertence a uma lista de tarefas e não ao cabeçalho de um ficheiro já entregue.

Há um segundo portão mais adiante, no registo que compõe os artigos publicados, e deixa de fora todo o artigo cuja data de publicação ainda esteja no futuro. É uma rede para os caminhos que não passam pela compilação: um ficheiro editado à mão, uma fusão que mistura duas gerações, uma cópia reposta. Só controla a data de publicação e não a de alteração, porque uma gralha num campo de data não deve fazer desaparecer uma página já indexada.

E esse segundo portão é avaliado uma vez, ao carregar o módulo durante a compilação. Está escrito num comentário ao lado, porque quem supuser outra coisa acaba por escrever o agendador contra o qual esta secção argumenta.

Uma data que não se consegue deduzir é melhor omitir

A mesma ronda teve de decidir que data, se alguma, cabe às páginas de documentação, que não têm cabeçalho nenhum. Apresentaram-se três candidatas, e as três são falsas.

CandidataPorque está errada
A data git do componente de páginaMuda quando muda um nome de classe e não muda quando o texto passa para um ficheiro de tradução
A data git do catálogo de traduçãoUm ficheiro contém milhares de textos sem relação e muda por isso a toda a hora por motivos alheios a esta página
A data de compilaçãoDiz todos os dias que cada página foi escrita hoje

As páginas de documentação não levam portanto data de publicação nos seus dados estruturados. Nada é melhor do que um número plausível, porque um número plausível é aquele que ninguém verifica.

O mesmo raciocínio já governava o mapa do sítio. As rotas fixas não levam qualquer data de alteração, e a razão não é preguiça: o seu conteúdo é código e o seu texto vive em nove catálogos de tradução, pelo que qualquer data calculável seguiria algo diferente do que o leitor vê. Um motor que busca três vezes uma página «alterada» e a encontra igual aprende a ignorar o campo, e então o campo é pior do que ausente nas páginas onde é real. Os artigos levam uma, porque está no cabeçalho ao lado do título, onde quem reescreve o texto a vê mesmo.

Depois deste trabalho a cobertura não mudou nada: os endereços de artigo levam data de alteração, tudo o resto não leva, tal como antes. O que mudou é que duzentas e dezasseis dessas datas estavam no futuro, e agora nenhuma está.

Mais uma contradição, resolvida com identidade

Ao rever os dados estruturados apareceu uma versão menor do mesmo problema: nalgumas páginas o autor e o editor eram duas entidades separadas sem relação declarada. Lidas à letra, essas páginas afirmavam que o artigo tinha sido escrito por uma empresa e publicado por outra. Ambos apontam agora para o mesmo identificador. Ninguém se teria queixado, e continuava a ser uma afirmação nossa que não era verdadeira.

O que deixaríamos escrito

  1. Nunca ponha uma intenção num campo que regista uma observação. Um leitor não as consegue separar, e uma máquina também não.
  2. Confronte a afirmação com o historial. Um comando sobre o historial dos ficheiros decidiu qual das duas datas era a verdadeira, e contrariava os vinte e quatro ficheiros.
  3. Um portão de data num sítio gerado de forma estática não é um calendário. À meia-noite não aparece nada; aparece na compilação seguinte.
  4. Não esconda endereços já indexados. Um 404 numa página rastreada é um sinal de remoção, e a cura custa mais do que a doença.
  5. Ponha o portão onde o erro se comete, faça a compilação falhar, e não acrescente exceções. Ponha um segundo portão mais adiante para os caminhos que saltam o primeiro.
  6. Omita uma data que não consegue deduzir com honestidade. Três fontes plausíveis, erradas as três, significa que a saída honesta é nenhuma.

Para que fique claro o que isto é: isto é manutenção de um sítio público, não uma funcionalidade de produto, e não mudou nenhum comportamento pelo qual alguém pague. Uma parte fica por provar. Os dados estruturados foram validados contra o seu próprio esquema e relidos à mão, não por um rastreador real nem por um cartão de pré-visualização real. Nada disto foi medido contra o índice de um motor de busca, porque essa medição demora semanas e ninguém deve esperar por ela antes de retirar uma inexatidão.

Do trabalho no sítio da Provibr. O que custa manter dezasseis mil textos corretos em nove línguas está em dezasseis mil chaves, nove idiomas, e como uma colisão de números de campo num protocolo passou despercebida está em duas rondas, um número de campo.

Comece com um host e um agente

Crie uma conta, instale o agente com um único comando e ligue o seu primeiro host Proxmox. O período experimental dura 14 dias e não pede quaisquer dados de pagamento.