Num site em que página sim, página não vai ter código, é necessária uma forma de o apresentar convenientemente: com o espaçamento correcto, colorido, preferencialmente diferenciado por linguagem, e, já agora, com mais alguns extras, como a numeração das linhas.

A questão do espaçamento é facilmente resolvida envolvendo o código em tags <pre> </pre>. No entanto, dando de barato a questão das cores do código por enquanto, existe um problema muito maior: o espaçamento é mesmo respeitado! Se não colocarem nenhuma quebra de linha  - e a maior parte do código tem linhas bastante compridas – a caixa de código correspondente vai crescer por ali fora… E nem vale a pena fixar a largura das <pre> por CSS: o código vai simplesmente saltar fora da caixa!

Como é habitual, o Google eventualmente devolveu a solução a este problema, via blog do Tyler Longren (e uma adenda do Markku Laine). Os estilos necessários para forçar as quebras de linha dentro das <pre> é complexo, porque nem todos os browsers aceitam da mesma maneira (que surpresa…) e, precisamente por causa disso, a CSS não é standard compliant. A solução não me agradava nem um bocadinho, mas ainda a usei… durante um dia. Seja como for, porque pode dar jeito a alguém, cá vai (com os comentários traduzidos para português):

O webdeveloper que se preze enfia com o Google Analytics em tudo o que desenvolve; às vezes porque dá jeito, outras por questão de hábito. O que é certo, é que dá mil a zero ao AWStats (embora o AWStats, como corre na própria máquina que está a analisar, dê estatísticas de coisas que o Analytics não consegue – embora haja mais maneiras do gato ir ás filhozes).

Uma das coisas que sempre me fez espécie, é o facto do Google servir o Analytics descomprimido! E isto é mau por vários motivos:

1. Apesar do script, hoje em dia, estar quase sempre morno por ser usado tantas vezes, volta e meia lá calha visitarmos uma página nova ou, sobretudo os webdevelopers, com a cache limpa – quando isso acontece, pega lá 24 kB. Podem dizer que 24 kB, hoje em dia, não é nada, mas…
2. Mas esses 24 kB nem sempre vêm mal se chama! O lado mau do script ser tão conspícuo hoje em dia, é que os servidores do Google não têm mãos a medir para o servir a todos quanto o chamam e/ou os saltos que temos de dar até ao servidor estão entupidos. Não é incomum ver-se uma página bloqueada durante mais de 4 segundos à espera do Analytics, o que me leva ao terceiro ponto;
3. A maneira recomendada pelo Google de se inserir o script deve ser a pior prática de sempre, via document.write(). Como se já não bastasse a tag <script> bloquear a página, a própria instrução que a insere, document.write(), também bloqueia! No dia em que, por qualquer motivo, o script teimar em não vir, temos uma página a carregar para toda a eternidade. Já é a pensar nisso que é recomendada a inserção imediatamente antes do </body>, mas, seja como for, não é agradável ver a página em carregamento durante tanto tempo.

Agora que já bati que chegue, vamos à solução, se é que ainda não deu para perceber pelo título do tópico: alojar o script na mesma máquina do site.

Pequena colecção de perguntas que, com toda a certeza, mais cedo ou mais tarde me irão colocar. Esta lista não é estática, por isso convém passar por cá de vez em quando.

Se o facto do post ser fixo não vos diz nada, cá vai: é fortemente aconselhado lerem isto antes de se registarem, para depois não terem surpresas. Não tem nada que não apliquem no vosso dia-a-dia, mas leiam, apesar de tudo.

Siga…

Bem-vindos ao blog do DreamsInCode!

Este blog servirá de apoio ao resto do site, onde poderão encontrar explicações e exemplos sobre as outras áreas e onde poderão deixar o vosso comentário, as vossas dúvidas e as vossas críticas. Servirá também como rampa de lançamento, isto é, antes de qualquer coisa aparecer nas outras áreas, será, certamente, abordada aqui inicialmente.

Os principais temas que aqui serão abordados têm direito a um ícone específico, e são os seguintes: