Desenvolvimento e-commerce: nehrebeccy.pl

#Um pedido assíncrono custa o mesmo que uma página inteira

Vale a pena começar por um detalhe de funcionamento do WordPress, porque explica boa parte das decisões deste projeto. Filtrar os artistas por categoria e carregar as porções seguintes da lista acontece por AJAX, e isso significa um mecanismo concreto: o pedido chega ao ponto de entrada partilhado do WordPress para chamadas assíncronas. Cada um desses pedidos arranca o WordPress inteiro, com todas as extensões, portanto custa aproximadamente o mesmo que gerar uma página completa, ainda que na resposta viaje apenas um fragmento de lista.

Quem desenha um filtro sem saber disto assume que o custo é proporcional ao que aparece no ecrã. Não é. Numa sessão em que alguém alterna filtros meia dúzia de vezes enquanto procura um nome, o servidor fez meia dúzia de arranques completos. É essa a razão pela qual a lista se mantém curta, o filtro estreita o conjunto dentro da consulta e não no navegador, e o resultado de uma combinação de filtros pode ficar em cache.

A alternativa é tentadora e aparece em quase todos os projetos deste feitio: trazer todos os artistas de uma vez e peneirá-los no navegador. O código sai mais simples, a interface responde sem latência, e a solução deixa de funcionar exatamente quando o conjunto cresce o suficiente para que enviá-lo por inteiro custe mais do que os pedidos adicionais. O ponto de viragem não é visível em testes com dados de demonstração, o que é precisamente o problema.

#O cliente: uma agência de Gdynia

A R&K Nehrebeccy é uma agência artística de Gdynia, dirigida por Renata e Krystian Nehrebecki, em atividade ininterrupta desde 1994. Cria e assegura eventos artísticos: encontros com figuras conhecidas, concertos, espetáculos, inaugurações solenes, aniversários e jubileus, desde a ideia e o guião até à contratação dos artistas, à cenografia e às projeções. Uma parte reconhecível da oferta são as noites literárias construídas em torno de encontros com autores de livros. O meio é a Tricidade: clubes, casas de cultura, bibliotecas.

Do outro lado de um pedido de informação não está um consumidor. Está a coordenação de programação de uma casa de cultura ou de uma biblioteca, ou a pessoa de uma empresa a quem calhou o jubileu. Essa pessoa chega com um nome na cabeça, verifica se a agência já trabalhou com esse nome e só depois escreve ou telefona. A navegação tinha portanto de ir de um nome para um evento e de um evento de volta para um nome, e não da página inicial para um separador de serviços.

#Principais funcionalidades do site

O portefólio de artistas é a vista principal. Cada perfil reúne fotografias, uma descrição do percurso e o histórico de colaboração, e a ordem da informação tem uma única tarefa: permitir avaliar em poucos segundos se aquela pessoa serve para a noite que alguém está a planear. Daí a fotografia e a descrição curta ficarem acima da biografia completa, e a lista de participações estar visível sem descer até ao fim.

O calendário e o arquivo são os mesmos dados vistos de dois lados. Os eventos futuros são informação para o público, os passados são prova para quem contrata. Um evento não desaparece quando a data passa, muda de vista.

A edição decorre no painel normal do WordPress, com campos ajustados aos tipos de conteúdo. Não existe aqui, de propósito, um construtor visual de páginas. Quem introduz um evento entre dois encontros com autores deve preencher campos e não desenhar uma maquete, porque desenhar uma maquete em cada entrada é o caminho mais curto para um site cujas vinte subpáginas parecem vinte sites diferentes.

A partilha nas redes sociais conta aqui como funcionalidade e não como adorno. A notícia de um encontro com um autor circula pelos perfis de quem participa e pelas páginas das instituições que acolhem, por isso cada entrada precisa de metadados de partilha corretos: título, descrição e uma imagem que não seja um recorte casual do fundo.

#O modelo de conteúdo

A implementação corre sobre WordPress e a primeira decisão foi o que é um artista na base de dados e o que é um evento. O caminho aparentemente mais barato, descrever ambos como entradas vulgares ou, pior, como páginas, poupa uma tarde durante a construção e cobra-se em cada alteração posterior. Uma entrada comum não tem onde guardar a data do evento, o local, nem o papel que um artista concreto teve naquela noite concreta. Tudo isso acaba dentro do texto, ou seja, num único campo do qual nada se consegue ler de forma programática.

Por isso artista e evento são aqui tipos de conteúdo distintos, ligados por uma relação. Um evento tem vários participantes, um participante tem muitos eventos, e é essa estrutura que permite gerar duas vistas a partir do mesmo conjunto de dados: o perfil do artista com a lista das suas participações e a página do evento com a lista de quem interveio. Se essas listas fossem escritas à mão dos dois lados, cada alteração exigiria edição em dois sítios, e ao fim de um ano metade delas teria divergido em silêncio.

As taxonomias organizam o mesmo por uma terceira direção. Separar os participantes em escritores, atores e jornalistas, e os eventos em concerto, encontro com autor, inauguração e jubileu, produz listagens que ninguém precisa de manter. Uma entrada nova atribuída à sua categoria aparece sozinha na listagem certa. Parece um pormenor até se lembrar que o site é conduzido por duas pessoas ao lado do seu trabalho verdadeiro, onde a diferença entre uma lista gerada e uma lista mantida à mão decide se o site ainda é verdadeiro três anos depois.

#O arquivo é o argumento comercial

Na maioria dos sites com calendário, um evento passado é resíduo. Aqui a relação é inversa, e essa inversão determina como a data tem de ser guardada.

Uma agência artística não vende um produto que o comprador possa inspecionar antes de pagar. Vende uma noite que ainda não existe. A única prova ao alcance de quem decide é a lista de noites que já aconteceram e os nomes que nelas participaram. Uma página que diz o que a agência sabe fazer é mais fraca do que uma página que mostra o que já fez.

O reflexo natural é pendurar a data na entrada como campo adicional. No WordPress esse campo vai parar à tabela de metadados, onde os valores estão guardados como texto e não como data. Uma consulta por eventos futuros deixa então de ser uma comparação de datas e passa a ser uma comparação de cadeias de caracteres, que produz disparates assim que um formato com o dia à frente atravessa a mudança de mês. Além disso, cada consulta dessas acrescenta uma junção à tabela de metadados, e filtrar e ordenar pelo mesmo campo acrescenta mais.

Há duas saídas limpas e ambas exigem uma decisão no início e não ao fim de um ano. Ou a data se escreve num formato que ordena corretamente como texto, ano primeiro e sem separadores, ou a própria data de publicação da entrada transporta a data do evento e ajusta-se o tratamento das entradas com data futura, o que move toda a seleção para uma coluna indexada da tabela de entradas. A diferença é invisível com cinquenta entradas e muito visível quando o arquivo cresce durante uma década, que é exatamente aquilo para que o arquivo existe.

A segunda armadilha diz respeito aos endereços. A página de um evento de há uns anos costuma estar ligada a partir da biblioteca ou da casa de cultura que o acolheu. Se o endereço for construído em torno de o evento ser futuro ou passado, atravessar a data muda o endereço e todas essas ligações partem. O endereço tem de descrever o que o evento é, nunca em que separador está a ser mostrado neste momento.

#Imagens, o ficheiro mais pesado do site

Uma agência documenta cada noite com fotografias, e essas fotografias chegam tal como saem da máquina. Não são ilustrações decorativas que se possam cortar a qualquer tamanho, são a prova de que o ato aconteceu, por isso ninguém aceita publicá-las degradadas. Daí o trabalho de desempenho estar dividido em duas frentes resolvidas com duas ferramentas diferentes.

A cache de objetos em memória encurta o trabalho da base de dados para tudo o que tem de passar por PHP de qualquer maneira: conjuntos de entradas, termos de taxonomia, opções. A rede de distribuição assume os ficheiros, ou seja, as fotografias e as gravações, e é daí que vem a maior parte da diferença percetível neste projeto. Vale a pena dizê-lo sem rodeios, porque as duas camadas são confundidas com frequência: uma cache de objetos não acelera a transferência de uma imagem, e uma rede de fronteira não encurta uma consulta à base de dados.

Falta uma terceira frente que nenhuma das duas resolve. Uma noite deixa imagens numa quantidade que ninguém vê de uma assentada, e carregar todos os ficheiros ao construir a página faz a visitante pagar por fotografias a que nunca chega. A galeria entrega primeiro as miniaturas e só traz as versões grandes quando alguém as abre. Hoje isso soa evidente, mas à data da construção o carregamento adiado era código próprio e não um atributo do elemento de imagem que o navegador respeita por si.

#Desafios e soluções de programação

O desafio da maquetação responsiva é anterior às ferramentas que hoje o tornam trivial. Quando o site foi construído, os navegadores ainda não tinham forma de escolher a variante de imagem do lado do cliente, e o WordPress só ganhou essa capacidade anos depois. A decisão sobre que versão de uma fotografia enviar era tomada no servidor, a partir dos tamanhos registados. Uma galeria carregada diretamente da máquina do fotógrafo precisava por isso de tamanhos intermédios definidos de antemão, caso contrário um telemóvel descarregava o ficheiro preparado para um ecrã de secretária.

O pré-processador de folhas de estilo não era nessa situação um enfeite, mas a ferramenta que mantinha os pontos de rutura num único sítio. Sem ele, os limiares de largura espalham-se por toda a folha e qualquer alteração à grelha obriga a tocar em uma dúzia de sítios ao mesmo tempo. A maquetação é também anterior às grelhas nativas nos navegadores, portanto as colunas assentavam em elementos flutuantes e larguras percentuais, o que exige cuidado quando uma galeria tem um número variável de elementos e as linhas têm de fechar limpas.

A facilidade de atualização foi o desafio seguinte, e a resposta é organizativa antes de ser técnica: campos em vez de conteúdo livre, listas geradas a partir de relações em vez de escritas, e tamanhos de imagem definidos em vez de uma decisão em cada carregamento. Um site em que a pessoa que edita tem de se lembrar de três regras para não partir a maquetação é um site que parte na primeira semana depois da entrega.

O último desafio foi poder desfazer. Conteúdo, configuração e código estão em camadas separadas, e essa propriedade só se torna visível na primeira alteração que corre mal depois do arranque. Se o aspeto de uma secção depender do que alguém escreveu no corpo de uma entrada, então uma correção visual é uma edição de conteúdo e não se reverte sem deitar fora trabalho editorial. Mantidos separados, reverter move uma das camadas e não as três.

#Suporte e manutenção do site

O acompanhamento cobre atualizações do núcleo e do tema, revisão dos registos e cópias de segurança. A ordem importa: uma cópia que ninguém restaurou nunca não é uma cópia, é um ficheiro. Verificar o restauro faz parte do trabalho e não é um acrescento.

As atualizações trazem um risco próprio num site construído sobre relações entre tipos de conteúdo. Quando a ligação entre um artista e um evento é mantida por uma camada intermédia, uma alteração aí pode mudar a forma como essas ligações ficam guardadas, e a vista de listagem parece correta até ao momento em que alguém cria uma entrada nova. Por isso as atualizações vão primeiro para uma cópia, e a verificação consiste em criar uma ligação nova, não em olhar para a página inicial.

Pequenas alterações visuais e funcionais feitas durante a manutenção seguem a mesma regra da construção: uma alteração entra na camada a que pertence. Um novo tipo de evento é um termo de taxonomia, não um modelo novo. Outras proporções na galeria são uma alteração dos tamanhos de imagem registados e a sua regeneração, não uma regra de estilo colada a uma subpágina.

#Como decorreu a implementação

O conjunto levou cerca de seis semanas, desde a definição do âmbito até à publicação. A maquetação e a disposição dos elementos vieram do cliente, portanto a fase que noutros projetos consome mais calendário aqui não existiu. O tempo foi para o modelo de conteúdo e para as partes que uma maquete não mostra: a relação entre artista e evento, a forma de guardar a data, os tamanhos de imagem e o comportamento das listagens ao filtrar.

Os casos limite foram testados contra uma cópia de produção e não contra uma instalação vazia. Num site com esta forma a diferença é concreta: uma instalação vazia não tem uma entrada com oitenta fotografias numa galeria, nem um artista ligado a eventos espalhados por vários anos, nem entradas com o campo de data preenchido de forma inconsistente porque alguém o escreveu à mão noutro formato. Os três casos só aparecem com dados reais, e cada um consegue derrubar uma vista de listagem.

Depois do arranque o site passou a manutenção conduzida do lado da agência, com o nosso apoio nas atualizações e nas alterações que vão além da edição de conteúdo.

#Resumo

nehrebeccy.pl é o site de uma agência artística construído em torno de duas entidades, o artista e o evento, e da relação entre ambas. Dessa estrutura saem todas as vistas: o perfil com as suas participações, a página do evento com os seus participantes, as listagens por categoria e o arquivo, que neste ofício é um ativo e não um lastro.

Do lado técnico a implementação assenta em WordPress, numa cache de objetos em memória, numa rede de distribuição para os conteúdos multimédia e numa maquetação responsiva feita quando a responsividade ainda significava trabalho manual em cada variante de imagem. Do lado organizativo assenta em algo mais simples: um site conduzido por duas pessoas ao lado do seu trabalho verdadeiro tem de sobreviver a que ninguém se lembre das regras da entrega.