Num mini-projecto que estou a preparar em HTML5 e CSS3, estou a usar cantos redondos feitos por CSS. O código para os fazer (ainda) é com os prefixos dos vários browsers e é muito simples:

/* standards */
border-radius: 1em 0.25em 2em 2em;
/* para o Firefox */
-moz-border-radius: 1em 0.25em 2em 2em;
/* para o Safari e Chrome */
-webkit-border-radius: 1em 0.25em 2em 2em;
/* para o Opera */
-o-border-radius: 1em 0.25em 2em 2em;

Nem preciso dizer que nenhuma versão corrente do Internet Explorer suporta isto, certo?

Só para que vejam o efeito, aqui fica uma bonita (cof, cof) caixa com este estilo aplicado:

Ainda a propósito do Codebits 2010, estava sentado numa mesa com o Pedro Cavaco, que estava a participar na competição de programação com um jogo para smartphones: Android e iPhone.

Estávamos a conversar sobre isso e eu não estava a ver uma forma fácil de fazer isso para duas plataformas ao mesmo tempo, o que se devia apenas a nunca ter tomado muita atenção a essa área...

O Pedro estava a usar uma ferramenta que compila para as duas plataformas ao mesmo tempo, usando a linguagem Lua. Posteriormente, não consegui encontrar essa framework, mas encontrei várias outras para o mesmo efeito.

A maior parte delas suporta apenas duas plataformas (Android e iPhone) e através do uso de um componente web view. Qualquer um dos factores isolados já é mau, mas seria suportável. Em conjunto, não serve para mim.

Acabei por ficar com, apenas, duas das frameworks que encontrei, a Rhomobile Rhodes e a Appcelerator Titanium, para testar.

Esta posta é pouco mais que um repositório, mais para mim do que para o mundo. Posto isto…

Apresentações com conteúdos que quero explorar em mais profundidade, com aplicações práticas para o meu trabalho ou para projectos pessoais:

• Collecting and Visualizing Data – Apresentado por Brian Suda, vídeo, apresentação e exemplos;
• Making burgers with JavaScript – Apresentado por Diogo Antunes, vídeo, apresentação e exemplos;
• We're not designing Posters, here! – Apresentado por André Luís, vídeo e apresentação;
• Advanced SQL Injection: attacks and defenses – Apresentado por Nuno Loureiro e Tiago Mendo, vídeo;
• Wireless communication with ZigBee – Apresentado por Filipe Valpereiro, vídeo;
• Event Driven Architecture – Apresentado por Lourens Naudé, vídeo e apresentação;
• Deep Dive into HTML5 – Apresentado por Giorgio Sardo, vídeo e apresentação [on hold].

Para além das acima, a apresentação How to build your own Quadrocopter (vídeo e apresentação), por Lenz Grimmer, não me ensinou nada de novo, mas é um projecto que comecei no final do verão, para se ir fazendo.

Finalmente, a Dr. © - How I Learned to Stop Worrying and Love Fair-Use Licensing (vídeo e apresentação), pelo já acima nomeado André Luís, reflecte a minha posição em relação a licenciamento (é só visitar a licença aqui do DreamsInCode).

Na sequência deste post, ainda não tinha ficado plenamente satisfeito com a tipografia do DreamsInCode — o tamanho da letra parecia-me exageradamente pequeno e as linhas demasiado compridas para a leitura ser confortável.

Este era, aliás, um dos meus maiores dilemas, e já não é de agora. Sempre fui um grande combatente da causa dos designs líquidos: parece-me extremamente ineficiente termos todo o espaço de um monitor de 19, 20 ou 22 polegadas, com até 1920 pixels, e aproveitar apenas uma magra fatia de cerca de 950... No entanto, o que parece ser uma boa ideia na generalidade — mais espaço para passar a mensagem — falha redondamente na prática; como tão bem sabem os tipógrafos, há um limite de conforto para os tamanhos das linhas, onde os olhos conseguem mudar de linha sem perder o fio à meada.

Posto isto, tinha mesmo de abandonar o meu adorado design líquido e passar para um design fixo, e aumentar de novo o tipo de letra. Já que estava com o malho quente, resolvi também redesenhar o site inteiro. Ainda há por aí um ou outro pormenor por afinar mas, de um modo geral, estou satisfeito com o resultado. O maior tamanho de letra deu mais ar ao design, o bokeh lateral e as datas bonitas (de que falarei qualquer dia) até pode levar a pensar que eu sou um designer razoável (coisa que qualquer pessoa que conheça minimamente o meu trabalho poderá desmentir) e até os separadores ficam mais leves com o abandono do pontilhado escuro.

Havia duas frameworks, uma de JavaScript e outra de CSS, que eu queria experimentar há muito, e que tinham vindo a ser adiadas porque não tinha tempo nem paciência para andar a trocar tudo; com a alteração no design, já que tinha que passar pelos templates quase todos,  atirei-me às duas ao mesmo tempo (o que, e vendo o tempo que demorei, na volta, foi idiota — ou então não, assim ficou já despachado).

Do lado do JavaScript, o jQuery (e o jQueryUI) andava-me a fazer água na boca há que tempos; o motor de selectores (o Sizzle) era bastante mais rápido do que o do Prototype (aparentemente, a próxima versão também irá usar o Sizzle), a forma como a execução inicial era deferida até a DOM estar completamente disponível (via ready), a integração com o jQueryUI mais suave do que a que o Prototype tem com o Scriptaculous, o ThemeRoller, que é fantástico para se mudar o design do pé para a mão, enfim, um monte de pormenores.

De entre as coisas que mais me impressionaram, destaca-se a forma como é possível criar botões a partir de qualquer tag HTML. Os botões na zona de login, ali em cima, foram feitos assim. Uma consulta à documentação oficial explica a facilidade da coisa, mas qualquer dia também coloco um post sobre isso.

Do lado das CSS, nunca tinha usado frameworks; a minha primeira experiência foi relativamente recente, com a YUI 3 CSS, e a maneira como estas frameworks ultrapassam as inconsistências inter-browser agarrou-me à primeira vista. No entanto, esta em particular, metia-me alguma confusão, com as suas classes com nomes bizarríssimos (o que é que faz a classe yui3-b?).

Outra que tinha andado a namorar tinha sido a Blueprint CSS, mas tinha abandonado a ideia porque, lá está, não suportava designs líquidos. Como a teoria tipográfica me veio dar dois milhos nas beiças, não havia nada que me impedisse de a usar. Com o seu sistema de grelha com nomes de gente, a facilidade com que se implementa um protótipo funcional é fantástica. Um design básico com cabeçalho, duas colunas e rodapé faz-se com cinco div e zero CSS costumizada. Os nomes intuitivos, como span-5, prepend-2 e por aí fora ajudam bastante.

Uma nota adicional sobre a Blueprint CSS: quando fui buscar o link para colocar aqui, dei conta que, desde que comecei o redesign do DreamsInCode, foi lançada uma nova versão. Eu até estava com algum receio que fosse abandonware, visto que a última versão estável tinha sido há mais de um ano... Como tal, por aqui ainda se usa a versão anterior, mas vou fazer uns testes para ver se não rebento com nada e hei-de actualizar.

Já agora, que falo de frameworks, eu uso um misto de framework/CMS PHP meu (da empresa, vá, embora esta versão do DreamsInCode já esteja bastante remexida — é onde normalmente faço testes antes de fazer alterações em sites críticos) com algumas coisas do PEAR, outras da ZF, para além do motor Wordpress que alimenta o blog. Até há bem pouco tempo, não me sentia confortável em usar outra framework, já para não falar noutra CMS. No entanto, experimentei recentemente a Yii Framework e fiquei muito fã. Embora continue a desaconselhar o uso de CMS pré-feitas (como a nódoa do Joomla), a minha posição em relação às frameworks, em particular esta Yii, está bastante mais suavizada, e é provável que haja mais novidades nos próximos tempos neste campo.

Mesmo nesta era de banda larga massificada, não há nada que me irrite mais, como utilizador, do que esperar dois ou três segundos que um site abra. Sobretudo, quando o que falta vir é o CSS da página, por exemplo, ou imagens sem tamanho definido que rebentam com o layout.

Como tal, dedico bastante tempo a melhorar a performance dos sites que desenvolvo. Na realidade, já não dedico assim tanto tempo, visto que entretanto o processo foi agilizado de tal forma que apenas dois ou três parâmetros têm que ser ajustados caso a caso.

As duas ferramentas absolutamente imprescindíveis para este trabalho são extensões para a extensão Firebug do Firefox (sim, extensões para a extensão), o YSlow da Yahoo e o Page Speed da Google. A maioria das regras são comuns a ambos, algumas novas, outras com parâmetros de avaliação diferentes. O ideal é obter uma pontuação o mais próxima de 100 possível. Os resultados do DreamsInCode são os seguintes:

Ha! Se pensavam que ia falar da (lamentável) comunicação de Sua Excelência, o Presidente da República, enganaram-se bem enganados. Mas provavelmente não pensavam. Até porque de integração teve muito pouco. Esqueçam…

Hoje foi dia de integrar o DreamsInCode. E integrar onde? Em todo o lado. Desde as doações do PayPal aí ao lado (please, donate…), até aos links de partilha social, ao fundo das postas.

Aproveito para partilhar um pequeno truque: já devem ter reparado, quem usa o Facebook, bem entendido, que alguns links partilhados no dito têm uma pequena imagem associada. O Facebook até faz um bom esforço para tentar encontrar imagens que possa usar para essa miniatura. Por uma questão de identidade, eu gostava que a imagem fosse sempre a mesma, e que o Facebook não se deitasse a adivinhar entre as várias imagens que possam existir numa página.

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.