Trataremos agora da API de shortcodes do WordPress, que permite que usemos, no conteúdo de artigos e páginas, um conjunto de códigos macro delimitados por parênteses rectos ([]) e inspirados pela linguagem de formatação BBCode. No momento da apresentação ao visitante do site, estes macros são substituídos pelo resultado da função que abstraem.

O WordPress inclui de origem alguns destes shortcodes. Por exemplo, o shortcode [gallery] é substituído por uma galeria de fotografias com todas as imagens que estiverem anexadas ao artigo ou página onde se encontra. Um shortcode é descrito de forma muito semelhante a uma vulgar tag HTML, permitindo atributos e tags de abertura e fecho. Por exemplo, [gallery id="3"] ou [block]Lorem ipsum[/block].

Para além dos shortcodes oferecidos pelo WordPress, tanto temas como plugins podem criar novos códigos. É o que iremos descobrir neste artigo.

O meu primeiro shortcode

Como nos artigos anteriores, concentraremos as nossas modificações no ficheiro functions.php do tema, situado em /wp-content/themes/pasta do tema/functions.php, e só mais tarde aplicaremos o conhecimento adquirido ao desenvolvimento de uma nova extensão.

Para criar um novo shortcode em código basta, muito simplesmente, declarar uma função que o implemente e associá-la ao nome pretendido com add_shortcode(). A forma de o fazer é semelhante ao que já fazíamos para os hooks:

function tutorial_hello_world_shortcode ( $atts, $content = null ) {
    return 'Olá, mundo!';
}

add_shortcode( 'hello', 'tutorial_hello_world_shortcode' );

E pronto! Experimente inserir o shortcode [hello] no conteúdo de qualquer página ou artigo, e este será substituído pela expressão “Olá, mundo!” aquando da visualização.

Atributos do shortcode

Como já demos a entender, é possível passar atributos a um shortcode, à semelhança do que acontece em BBCode ou em HTML. Os mais atentos terão reparado que a função tutorial_hello_world_shortcode() aceita um parâmetro $atts, que recebe precisamente um array de parâmetros passados no shortcode.

Não é preciso fazer nada de especial para obter estes parâmetros, já que a API do WordPress abstrai o processo de análise da string para recolha dos parâmetros. Um shortcode com o seguinte formato:

[hello name="Luís Rodrigues" other="Outro atributo"]

irá invocar a nossa função tutorial_hello_world_shortcode() com o seguinte array passado por parâmetro:

Array
(
    [name] => Luís Rodrigues
    [other] => Outro atributo
)

Isto significa que podemos modificar a nossa função para lhe dar um toque mais pessoal:

function tutorial_hello_world_shortcode ( $atts, $content = null ) {
    if (empty( $atts['name'] ))
        return 'Olá, mundo!';
    else
        return 'Olá, ' . $atts['name'] . '!';
}

add_shortcode( 'hello', 'tutorial_hello_world_shortcode' );

Assim, podemos escrever o shortcode

[hello name="Luís Rodrigues"]

e obter

Olá, Luís Rodrigues!

Conteúdo do shortcode

O shortcode acima limita-se a substituir todo o código pelo retorno da função associada. Contudo, também é possível usar shortcodes para filtrar blocos de conteúdo sem o substituir por completo.

Aqui entra em palco o segundo parâmetro da nossa função, $content, que guarda todo o conteúdo existente entre a abertura e fecho de um shortcode.

function tutorial_hello_world_shortcode ( $atts, $content = null ) {
    $name = empty( $atts['name'] ) ? 'mundo' : $atts['name'];
    $output = "<strong>Olá, $name!</strong> ";
    if (!is_null( $content )) {
        $output .= $content;
        $output .= " <strong>Adeus, $name!</strong>";
    }
    return $output;
}

add_shortcode( 'hello', 'tutorial_hello_world_shortcode' );

A inserção do shortcode revisto no nosso artigo ou página poderia ter o formato

[hello name="Luís Rodrigues"]Lorem ipsum dolor sit amet...[/hello]

resultando em

Olá, Luís Rodrigues! Lorem ipsum dolor sit amet… Adeus, Luís Rodrigues!

A invocação anterior, contendo apenas um código [hello] simples, com o sem atributo, continuaria a funcionar da mesma forma, já que o código da nossa função verifica a existência ou não-existência do atributo name e do conteúdo.

Valores por omissão

No código do nosso exemplo anterior, ocorre uma verificação prévia do atributo name e a atribuição do valor por omissão "mundo" caso este não se encontre definido.

Há, no entanto, uma forma mais elegante e recomendada de indicar os valores por omissão e extrair os valores de um conjunto de atributos. Assim, em vez de

$name = empty( $atts['name'] ) ? 'mundo' : $atts['name'];

podemos escrever

extract( shortcode_atts( array(
    'name' => 'mundo',
    'other' => 'XPTO' // Valor por omissão para outro atributo
), $atts ) );

Exemplo útil

Os shortcodes têm inúmeras aplicações práticas, uma das quais sendo a possibilidade de limitar a visualização de conteúdos tendo em conta um conjunto de condições.

Por exemplo, podemos criar um novo shortcode [access] que limite o acesso de utilizadores não-autenticados aos conteúdos delimitados pelo shortcode.

function shortcode_access_control ( $atts, $content = null ) {
    extract( shortcode_atts( array(
        'capability' => 'read',
        'error' => 'Este conteúdo está reservado a utilizadores autenticados.',
    ), $atts ) );
    if (current_user_can( $capability ) && !is_null( $content ))
        return $content;
    else
        return $error;
}

add_shortcode( 'access', 'shortcode_access_control' );

O shortcode pode ser invocado digitando o seguinte texto algures no conteúdo de uma página ou artigo:

[access]TOP SECRET![/access]

Um utilizador autenticado verá o seguinte:

TOP SECRET!

Todos os restantes verão antes a mensagem:

Este conteúdo está reservado a utilizadores autenticados.

Por omissão, esta função verifica se o utilizador tem a autorização read (ou a capacidade que for indicada no parâmetro capability). Se a autorização tiver sido concedida, é apresentado o conteúdo, caso contrário mostramos a mensagem de erro (ou a que for indicada no atributo message).

Dado que este novo shortcode permite parametrizar a capacidade requerida do utilizador e a mensagem de erro, temos alguma flexibilidade nas opções de validação e apresentação. Por exemplo:

[access capability="admin" error="Este conteúdo só pode ser visto por administradores."]TOP SECRET![/access]

Precauções

Apesar de poderosa, a API de shortcodes apresenta algumas limitações a ter em consideração.

Uma destas particularidades tem a ver com o facto de a função que interpreta os shortcodes varrer o conteúdo dos artigos e das páginas uma única vez. Isto significa que incluir shortcodes dentro uns dos outros pode não surtir os efeitos desejados. Por exemplo:

[access]
    O meu primeiro shortcode: [hello]
[/access]

Não funciona, apresentando aos utilizadores autenticados apenas o texto “O meu primeiro shortcode: [hello]”, sem substituir o fragmento “[hello]” como seria de esperar.

Uma forma de contornar esta limitação é passar o $content do shortcode pela função do_shortcode() antes de o devolver. Feita a alteração, a função terá o seguinte aspecto:

function shortcode_access_control ( $atts, $content = null ) {
    extract( shortcode_atts( array(
        'capability' => 'read',
        'error' => 'Este conteúdo está reservado a utilizadores autenticados.',
    ), $atts ) );
    if (current_user_can( $capability ) && !is_null( $content ))
        return do_shortcode( $content ); // Processamento de sub-shortcodes
    else
        return $error;
}

add_shortcode( 'access', 'shortcode_access_control' );

Aqui, a função do_shortcode() obriga o WordPress a interpretar recursivamente o conteúdo em busca de novos shortcodes para substituir.

Mais problemático é o facto do interpretador do WordPress não reconhecer duas ou mais ocorrências do mesmo shortcode encadeadas. Por exemplo:

[shortcode]
    [shortcode][/shortcode]
[/shortcode]

Não irá funcionar, mesmo usando a função do_shortcode(), dado que a função que interpreta os shortcodes privilegia a velocidade de processamento e não a correcta interpretação de estruturas complexas destes códigos.

Deve-se evitar usar hífens no nome do shortcode, pois estes não são correctamente reconhecidos pelo interpretador devido a um bug nas actuais versões do WordPress. Prefere-se aqui o uso do carácter _ (underscore). Também não são aceites parênteses rectos no valor de um atributo: algo como [shortcode atributo="[valor]"] irá falhar.

No próximo artigo, iremos explicar o processo de desenvolvimento de novas widgets para apresentação nos temas. Até lá, aguardamos questões e sugestões dos nossos leitores na nossa página no Facebook.

Filtros

Vimos também no primeiro artigo que existe uma segunda classe de hooks, chamados filtros, sobre os quais nos iremos agora debruçar. Estes são em tudo semelhantes às acções, com uma diferença de nota: todas as funções de filtro recebem pelo menos um parâmetro e retornam, transformado ou não, o primeiro desses parâmetros recebidos.

Por esse motivo, e como o próprio nome indica, são perfeitos para transformação e processamento de informação, ou para aplicar em validações da mesma, antes de a escrever na base de dados ou a mostrar ao visitante do site. Neste texto iremos experimentar alguns exemplos.

O meu primeiro filtro

Como antes, concentraremos as nossas modificações no ficheiro functions.php do tema, situado em /wp-content/themes/pasta do tema/functions.php, e só mais tarde aplicaremos o conhecimento adquirido ao desenvolvimento de uma nova extensão.

O procedimento para criação e registo de um filtro é semelhante ao das acções, sendo necessário escrever a função de filtragem em PHP e associá-la a um filtro do WordPress usando add_filter().

Para o nosso primeiro exemplo, iremos personalizar a apresentação das nossas listagens, transformando o texto da hiperligação “Continuar a ler” dos artigos separados por um More… com algo um pouco mais elaborado.

Figura 1: O que pretendemos modificar.

function tutorial_the_content_more_link ( $output, $more_link_text ) {
    $more_link_url = get_permalink() . '#more-' . get_the_ID();
    $new_more_link_text = "Continue a ler, modificado pelo meu primeiro filtro →";
    $output = ' <a href="' . $more_link_url . '" class="more-link">' . $new_more_link_text . '</a>';
    return $output;
}

Tal como com as acções, é imperativo registar o filtro. Vamos usar a função add_filter() para associar a nossa função ao filtro excerpt_more:

add_filter( 'the_content_more_link', 'tutorial_the_content_more_link', 10, 2 );

Por partes, então.

Primeiro que tudo, o filtro a que a vamos associar (the_content_more_link), recebe dois parâmetros: sendo o primeiro a hiperligação já construída, e o segundo o texto simples dessa hiperligação. O 2 na linha do add_filter() indica isso mesmo, à semelhança do que já acontecia com as acções. O 10 indica a prioridade do filtro, mais uma vez em tudo semelhante ao que vimos antes. Quanto maior, mais tarde na sequência de filtros do the_content_more_link há-de correr.

Neste caso, interessa-nos reconstruir por completo a hiperligação, não preservando o que vem de trás. Para tal, precisamos de construir o endereço de destino à custa das funções get_permalink() e get_the_ID(), guardando-o na variável $more_link_url.

No final, redefinimos a variável $output com o HTML da hiperligação que pretendemos apresentar e retornamos esse valor. Se não for modificado por mais nenhum filtro, este será o HTML a apresentar ao visitante do site.

Figura 2: A hiperligação modificada.

É claro que a nossa função tutorial_the_content_more_link() pode conter código mais sofisticado para, por exemplo, apresentar o total de palavras no artigo.

function tutorial_the_content_more_link_wordcount( $output, $more_link_text ) {
    global $post;
    $word_count = str_word_count( strip_tags( $post->post_content ) );
    $more_link_text = "Continue a ler ($word_count palavras) →";
    $more_link_url = get_permalink() . '#more-' . get_the_ID();
    $output = ' <a href="' . $more_link_url . '" class="more-link">' . $more_link_text . '</a>';
    return $output;
}

add_filter( 'the_content_more_link', 'tutorial_the_content_more_link_wordcount', 20, 2 );

Aqui, vamos precisar de obter dados do artigo em questão que não são passados por parâmetro à nossa função. Para isso declaramos a variável global $post na nossa função, de forma a podermos aceder ao valor de $post->get_content, que contém todo o texto do artigo.

Com o texto completo do artigo na nossa posse, podemos finalmente contabilizar o total de palavras com str_word_count, tendo o cuidado primeiro de limpar o HTML existente no artigo usando strip_tags. O resto é semelhante à primeira função que vimos, com a diferença de agora imprimirmos o total de palavras.

Figura 3: A hiperligação com contador de palavras.

Encadeamento de filtros

Em certos casos poderá ser necessário associar várias funções ao mesmo filtro. Não há qualquer problema: tal como as acções, os filtros são executados em sequência, segundo a prioridade definida (como nas acções, mais uma vez) e a ordem em que foram registados.

Para exemplificar este mecanismo, vamos alterar a apresentação do título do artigo com o filtro the_title para, mais uma vez, mostrar o contador de palavras, e também acrescentar uma tag HTML em torno do texto.

function tutorial_the_title_em ( $title, $id ) {
    return "<em>$title</em>";
}

function tutorial_the_title_wordcount ( $title, $id ) {
    if ($id) {
        $post = &get_post( $id );
        $word_count = str_word_count( strip_tags( $post->post_content ) );
        return $title . " ($word_count palavras)";
    } else {
        return $title;
    }
}

add_filter( 'the_title', 'tutorial_the_title_em', 10, 2 );        // Prioridade 10
add_filter( 'the_title', 'tutorial_the_title_wordcount', 20, 2 ); // Prioridade 20

Dado que o filtro the_title aceita entre os seus parâmetros o identificador do artigo, e não havendo garantias de que a função vai correr dentro do loop de apresentação de posts do WordPress, teremos de obter o conteúdo do artigo sem recorrer à variável global $post. Usamos por isso a função get_post() do WordPress para conseguir o mesmo efeito.

Figura 4: Título com itálico aplicado primeiro e total de palavras acrescentado depois.

Na sequência de filtros acima, o título é colocado em itálico primeiro e depois é-lhe acrescentado o total de palavras. Contudo, se invertermos a prioridade…

add_filter( 'the_title', 'tutorial_the_title_em', 20, 2 );        // Prioridade 20
add_filter( 'the_title', 'tutorial_the_title_wordcount', 10, 2 ); // Prioridade 10

…então é aplicado o contador primeiro e depois é tudo posto a itálico.

Figura 5: Título com total de palavras acrescentado primeiro e itálico aplicado depois.

the_title e the_content_more_link são apenas dois de uma imensa variedade de filtros. Existe no Codex uma lista de todos os filtros suportados pelo WordPress, sendo também possível criar novos filtros e, claro, usar os filtros criados por outros temas e plugins. Nunca é demais recomendar a WordPress Hook Database de Adam Brown, contendo informação mais pormenorizada sobre todos os hooks suportados pelo WordPress em cada uma das suas versões.

Eliminar filtros

Da mesma forma que associamos funções a filtros, também podemos eliminar essa associação. Vimos no primeiro artigo que esse processo era levado a cabo pela função remove_action().

Aqui, passa-se exactamente o mesmo, a única diferença é a função chamar-se remove_filter(). Por exemplo, a seguinte invocação impediria a execução da função tutorial_the_title_wordcount() previamente associada ao filtro the_title.

// Retira o filtro com prioridade 10 apenas:
remove_filter( 'the_title', 'tutorial_the_title_wordcount', 10 );
// Retira o filtro com prioridade 20 apenas:
remove_filter( 'the_title', 'tutorial_the_title_wordcount', 20 );

Já a função remove_all_filters() impede a execução de todas as funções associadas a um dado filtro. Por exemplo, todos os fitros the_title declarados antes desta linha deixarão de ser executados:

remove_all_filters( 'the_title' );

// Mas este, associado depois da limpeza, já corre:
add_filter( 'the_title', 'tutorial_the_title_em', 10, 2 );

Novos filtros

À semelhança do do_action() apresentado na sessão anterior, que invoca uma acção (nova ou existente), existe uma função análoga para os filtros chamada apply_filters().

Podemos, por exemplo, aplicar os filtros de título do WordPress (incluindo os acima declarados) a uma cadeia arbitrária de caracteres fazendo:

// Associar a função a um novo filtro:
add_filter( 'custom_the_title', 'tutorial_the_title_em', 10, 2 );

// Invocar o novo filtro...
$filtered_title = apply_filters( 'custom_the_title', 'Hello, world!', 0 )
echo $filtered_title;

// ...ou mesmo um filtro que já exista.
$filtered_title = apply_filters( 'the_title', 'Hello, world!', 0 )
echo $filtered_title;

No próximo artigo, abordaremos a API de shortcodes do WordPress, um mecanismo com tags especiais que podem ser incluídas no conteúdo dos artigos com funcionalidade de apresentação difícil ou mesmo impossível de reproduzir através do editor visual.

Para este evento foram escolhidas as talks:

• xRTML da Framework Realtime, por Sérgio Costa
• As novidades do CSS3, por Beatriz Olveira
• JScramble, por Rui Ribeiro

O evento é gratuito e aberto a todos, mas os lugares são limitados.

Mais informações aqui: http://lanyrd.com/2012/html5pt/

Um dos elementos mais ignorados para um Webdesign de excelência tem sido a arte da tipografia. Uma grande parte desta falta de atenção deriva do ainda relativo pouco suporte que existe nos browsers.

Escolher o tipo de fonte apropriado para complementar o design tornou-se uma tarefa bastante difícil com a variedade de tipos de fonte que os browsers suportam actualmente.

Até há pouco tempo, utilizar fontes que não estavam por norma instaladas nos computadores, implicava recorrer a imagens, Flash, ou a qualquer outro truque. Mas com a implementação nos browsers mais recentes da propriedade @font-face, permitiu aos designers uma maior criatividade na composição dos seus designs.

Consequências na escolha da fonte

Algumas das fontes das quais ganhámos acesso nunca foram feitas para ser utilizada num ecrã, quer seja por serem esteticamente inadequadas ou porque simplesmente são inelegíveis.

Também existem problemas técnicos relativos à renderização das fontes. Existem diversas inconsistências entre os browsers. O tamanho dos ficheiros das fontes, pode fazer com que as páginas passem a pesar para cima da centena de Kb.

Robert Bringhurst, um conhecido tipógrafo disse que:

A tipografia existe para honrar o conteúdo

Legibilidade

O aspecto mais importante a ter em conta quando escolhemos um tipo de fonte é a sua legibilidade.

Muitos designers não gostam muito da ideia de usar unicamente as fontes que são usadas por defeito pelos browsers – algo que é compreensível – mas que tem uma razão de ser, é que essas fontes tornam o conteúdo de fácil leitura.

Quando se escolhe uma fonte para a nossa página, devemos optar por uma que seja simples. Devemos manter o aspecto simples e não enveredar por um tipo de fonte muito complexa.

Devemos ainda deixar a parte criativa para outros elementos como os cabeçalhos, mas devemos manter o conteúdo o mais simples e legível possível. Uma fonte com um peso médio que tem serifas simples ou idealmente sem serifas é a melhor escolha.

Diferenças entre fontes serif e sans serif

O contraste deve ser elevado, e nunca devemos utilizar fontes abaixo dos 13px. Também não é boa ideia reduzir o espaçamento entre linhas, pelo contrário, muitas vezes é aconselhável aumentar este espaço.

Um último aspecto importante para manter a legibilidade, é, não ter mais do que três tipos de fontes na mesma página.

Escolher as melhores Fontes

Escolher a fonte para utilizar num site é uma das chaves para o sucesso do design que muitas vezes é menosprezada. Ao escolhermos a família de fontes a utilizar devemos assegurar que estas são legíveis nos diferentes tamanhos utilizados no design do site.

A escolha do tipo de fonte deve ir de encontro ao objetivo do site

Não vale a pena termos bom conteúdo no site se depois este não é legível. Também é importante escolher um tipo de fonte que vá de encontro ao “espírito” do site. Por exemplo uma fonte de estilo Gothic não seria a mais apropriada para um site infantil, mas talvez servisse para um site de um espetáculo Draconiano.

Definir o Contraste

O contraste é também ele um aspecto importante quando trabalhamos com tipografia.

O contraste entre o texto e o fundo ajuda na leitura do conteúdo

Um texto a vermelho pálido sobre um fundo verde pálido, pode funcionar bem, por exemplo estampado numa t-shirt, mas nunca será muito legível.

O texto existe para ser lido e compreendido, o contraste deve ser suficiente para assegurar que o texto é legível. Se não tivermos certeza de que o contraste é suficiente, podemos fazer um screenshot da página, abrir num editor de imagem e transformar a imagem em tons de cinza. Conseguimos ter a percepção se o contraste é suficiente.

Escolher o Tamanho

Quando surgiu o conceito da Web 2.0 notou-se o surgimento de uma estranha tendência, a utilização de fontes de reduzida dimensão passou a ser moda. Alguns designers diziam que se adaptava ao estilo minimalista do design adoptado. Como a maioria dos utilizadores não possui uma visão raio-x, ou uma acuidade 10/10, o tamanho reduzido das fontes não serve o propósito de legibilidade.

O tamanho do texto é muito importante para a legibilidade

Não devemos definir o texto abaixo dos 13px, devemos pelo contrário, optar por tamanhos superiores. Por exemplo o tamanho da fonte no site da I Love Typography está definido para 16px.

No entanto temos também de ter em conta que uma fonte demasiado grande força os utilizadores a fazerem demasiado scroll para conseguirem ler todo o conteúdo. Encontrar o equílibrio é normalmente possível escolhendo uma fonte de tamanho médio, outra opção, talvez mais correcta é fazer com que o tamanho da fonte se ajuste às preferências de cada utilizador.

Hierarquia

Variar o tamanho da fonte é a melhor forma de diferenciar o conteúdo. A utilização constante e consistente de diferentes tamanhos de fontes ao longo da página reforçam a importância de cada elemento para os utilizadores.

Uma boa hierarquia ajuda na identificação dos blocos de texto

Também serve para os utilizadores poderem fazer uma leitura de varrimento e captar as principais ideias que pretendemos comunicar — o que poderá servir para captar a atenção e levá-los a permanecer mais tempo no nosso site.

Cada elemento na página deve guiar progressivamente o utilizador pelo conteúdo que o site pretendo transmitir. A forma como a página é apresentada pode reforçar a hierarquia através da utilização de diferentes tamanhos, negritos, sublinhados, etc. A mistura entre fontes com e sem serifas também pode servir para criar um efeito harmonioso.

Usar uma escala para definir os diferentes tamanhos pode conseguir uma boa hierarquização. Por exemplo, a escala pode ser de 14px para o corpo de texto, e ir aumentando de tamanho, 16, 18, 21, 24, 36, 48, 60 até 72 px para os maiores cabeçalhos.

Podemos utilizar os nossos próprios padrões, tendo sempre em atenção a consistência entre as páginas.

Espaço Branco

O espaço branco é o espaço negativo que existe entre os diferentes blocos que compõem uma página, não necessariamente branco, mas os “espaços” que permitem que o conteúdo respire. Devemos deixar o texto respirar. O espaço branco deve ser algo sempre presente nas páginas. Este espaço ajuda a que a nossa atenção se focalize no conteúdo, e se é o texto que deve falar mais alto, então devemos “ouvi-lo”. Devemos deixar espaço branco nas margens, nos cabeçalhos e nos rodapés.

Podemos usar propriedades das CSS para conseguir este espaço, como o line-height, este deve ser pelo menos 140% do tamanho do texto.

Os tipógrafos costumam passar horas a trabalhar no “micro espaço” que existe entre cada caracter. Passam muito tempo a tentar encontrar a melhor harmonia entre o negro do caracter e o espaço branco que o rodeia. Cabe aos web designers, pensar no espaço macro, nos “buracos” que existem entre os blocos de texto das páginas.

Alinhamento

Uma grelha bem planeada é sempre uma boa base para um design sólido. As páginas devem ser divididas num sistema de colunas, linhas, cabeçalhos, barras laterais e rodapés, de modo a conduzir o olhar do utilizador para o conteúdo mais importante.

Deve-se usar sempre o texto alinhado à esquerda

Na web não é boa ideia usar um alinhamento justificado. Vai separar as palavras de uma maneira pouco natural, dificultando a leitura. No exemplo utilizado podemos ver que na primeira linha as palavras estão muito mais “arrumadas” que nas linhas 2 e 3, em que a separação das palavras é enorme.

Limitar o número de fontes

Não devem ser usadas mais do que três tipos de fontes no design de uma página, e preferencialmente devemos usar apenas duas. Com duas fontes é possível criar muitas variações que servem o nosso propósito. Se forem necessárias três fontes, esta última deve ser usada com decoro de forma a que não acrescente confusão ao design.

Outras dicas úteis para uma melhor tipografia

1. Não utilizar aspas verticais. As aspas verticais (também conhecidas como ambidestras), foram concebidas para reduzir o número de teclas num teclado, basta apenas uma tecla para abrir e fechar as citação. Para contornarmos esta limitação, devemos usar as aspas normais, para isso devemos colocar do lado esquerdo da citação: “, e do lado direito ”, o browser irá reproduzir assim: “O meu pequeno pónei”.
2. Utilizar um traço em vez de dois hífens. Dois hífens consecutivos (–) parece algo descuidado e na realidade interrompe o fluxo natural da mensagem. O leitor, fica preso no meio dos dois hífens a tentando perceber o significado. Para contornar este atentado ao sistema cognitivo do leitor, devemos usar, um traço N ou um traço M.O primeiro tem o comprimento de um N maiúsculo e deve ser usado para:- Intervalos de valores (1–10)- Relações e conexões (Benfica ganha ao Sporting, 3–0)- Adjetivos compostos (MS–DOS)

   Escrevemos um traço N (En Dash) no html com: –

   Um traço M tem o comprimento de um M maiúsculo e é usado para indicar uma mudança temporária no raciocínio, quer no meio quer no final de uma frase. Escrevemos um traço M (Em Dash) no html com: —

3. Ajustar o espaçamento das letras, palavras, e espaço entre linhas nos cabeçalhos. Podemos, com recurso às CSS, ajustar o espaçamento dos cabeçalhos. Por defeito existe muito espaço branco entre cada letra, palavra e linha se o tamanho da letra for maior que 16. Quanto maior for o tamanho da fonte, mais parece que as letras se separam umas das outras. Devemos ajustar esta fragmentação com letras mais estreitas, palavras mais juntas e um espaçamento de linha mais reduzido.
4. Usar a unidade EM para redimensionar o texto. Dimensionar o texto na Web não é uma tarefa fácil. Na web os utilizadores tem a hipótese de redimensionar o texto de forma a que se adapte melhor às suas necessidades.Se estamos a usar pixeis (px) estamos a usar uma medida que é estática, e desta forma a retirar a oportunidade para os utilizadores redimensionarem o texto.Se usarmos EM, que é uma medida relativa, o site irá adaptar-se à medida que o utilizador usar o zoom para aumentar ou diminuir o texto.
5. Adicionar espaço extra entre as linhas. Um espaço entre linhas generoso irá tornar a leitura mais fácil. Como medida padrão para um bom espaçamento é definir a altura de cada linha para 150% do tamanho do texto. Exemplo: line-height: 1.5em
6. Usar as reticências corretamente em vez de três pontos Quando terminamos uma frase com reticências, normalmente usamos três pontos para indicar uma interrupção. Devido ao comprimento do ponto final, três pontos, não parecem uma interrupção. O símbolo correcto a usar é uma elipse. Para usar uma elipse usamos … que fica assim: …

Fontes

• I Love Typography (http://ilovetypography.com/)
• 8 Faces (http://8faces.com/)

Artigos

• On Web Typography (http://www.alistapart.com/articles/on-web-typography/)
• Typography Guidelines And References (http://www.smashingmagazine.com/typography-guidelines-and-references/)
• “What Font Should I Use?%rdquo;: Five Principles for Choosing and Using Typefaces (http://www.smashingmagazine.com/2010/12/14/what-font-should-i-use-five-principles-for-choosing-and-using-typefaces/)

Tutoriais

• CSS Typography: The Basics (http://sixrevisions.com/css/css-typography-01/)
• 10 Web Typography Rules Every Designer Should Know (http://www.webdesignerdepot.com/2009/02/10-web-typography-rules-every-designer-should-know-2/)
• 22 Advanced CSS Text Effects And Web Typography Tips (http://www.1stwebdesigner.com/css/advanced-css-text-effects-web-typography-tips/)
• 10 Best Web Typography Tutorials (http://idesignow.com/css/10-best-web-typography-tutorials.html)

Figura 1: Localização do functions.php no tema Twenty Eleven.

Num artigo futuro abordaremos o desenvolvimento de plugins, mas por agora vamos limitar-nos a criar funcionalidade usando o ficheiro functions.php, mais conveniente para as nossas pequenas experiências. Este ficheiro, que existe na raíz de cada tema WordPress, em /wp-content/themes/(pasta do tema)/functions.php (figura 1), permite a execução de código auxiliar que não faz sentido aplicar transversalmente num plugin.

Importa salientar que o functions.php é específico ao seu tema, e por isso só corre quando o tema está activo, deixando de ter efeito quando se escolhe um diferente.

Vamos, pois, abrir o functions.php no nosso editor de código predilecto (à falta de melhor, um editor de texto básico como o Notepad serve perfeitamente), e prepararmo-nos para dar os primeiros passos por entre as engrenagens do WordPress.

Hooks

A interface de desenvolvimento (ou API) do WordPress assenta maioritariamente no conceito de “hooks”, ou ganchos. Estes hooks dizem respeito a uma série de eventos que podem ocorrer no ciclo de vida da plataforma, e nos quais podemos “pendurar” as nossas próprias funções, alterando o comportamento do WordPress em resposta aos mesmos.

A maior vantagem deste mecanismo de hooks é permitir modificar a plataforma sem mexer no código fonte do próprio WordPress, nem nos temas e plugins de terceiros. As alterações introduzidas através de hooks são modulares e aglomeráveis com as de outros plugins ou temas.

Existem hooks de dois tipos: acções e filtros.

As acções são comportamentos despoletados por uma situação específica, tal como a apresentação do cabeçalho ou rodapé das páginas, a publicação de um artigo, ou a criação de uma nova taxonomia.

Os filtros são semelhantes, com a diferença de terem a capacidade de receber dados, transformá-los, e passá-los à frente. Destes falaremos no próximo artigo.

A minha primeira acção

Para construirmos a nossa primeira acção, precisaremos de criar uma função que a implemente. No final do ficheiro functions.php vamos teclar o seguinte código que escreve uma tag HTML:

function tutorial_meta_greeting () {
    echo '<meta name="greeting" content="Olá, mundo!">';
}

A função tutorial_meta_greeting, só por si, ainda não faz nada. É preciso associá-la a um hook do WordPress que a possa invocar, acrescentando a seguinte linha:

add_action( 'wp_head', 'tutorial_meta_greeting', 10, 0 );

Esta linha diz ao WordPress para executar a nossa função sempre que ocorra um evento com a etiqueta wp_head, um hook que é despoletado aquando da geração do cabeçalho de uma página. Estamos, assim, a escrever uma tag <meta> nos cabeçalhos das nossas páginas. O resultado é visível consultando o HTML de qualquer página do site:

Figura 2: O resultado da nossa primeira experiência.

Podemos associar as funções que quisermos ao mesmo hook. Por vezes, no entanto, é preciso garantir que certas funções têm precedência sobre outras. Aqui entra o terceiro parâmetro da função add_action, que diz respeito à prioridade de execução. O parâmetro é opcional, mas no nosso exemplo explicitámos ser 10. Outra função associada a wp_head mas com um nível de prioridade mais baixo correria antes da nossa função. Com um valor mais alto, correria depois. Por exemplo:

function tutorial_meta_before () {
    echo '<meta name="before" content="Antes da saudação.">';
}

function tutorial_meta_after () {
    echo '<meta name="after" content="Depois da saudação.">';
}

add_action( 'wp_head', 'tutorial_meta_before', 5, 0 );
add_action( 'wp_head', 'tutorial_meta_after', 20, 0 );

O quarto parâmetro, que é opcional, indica o número de argumentos que o hook passa à função. No caso do wp_head, não são passados parâmetros.

wp_head é apenas uma de muitas acções. Existe no Codex uma lista de todas as acções suportadas pelo WordPress, sendo também possível criar novas acções e, claro, responder a outras oferecidas por temas e plugins. Também muito útil é o serviço WordPress Hook Database de Adam Brown, que contém uma referência mais técnica de todos os hooks suportados pelo WordPress em cada uma das suas versões.

Mais e melhor

As acções podem servir-se de muitos dados da plataforma, não estando limitadas ao que recebem como argumento. Por exemplo, podemos alterar a nossa função tutorial_meta_greeting para apresentar uma mensagem mais amigável:

function tutorial_meta_greeting ()
{
    global $current_user;
    if (is_user_logged_in()) {
        echo '<meta name="greeting" content="Olá, ' . $current_user->display_name . '!">';
    } else {
        echo '<meta name="greeting" content="Olá, mundo!">';
    }
}

A função acima verifica que o visitante está autenticado usando a função is_user_logged_in do WordPress, e tendo obtido a variável global $current_user, que contém os dados do utilizador, apresenta uma saudação personalizada. Os restantes receberão uma mensagem mais genérica na tag <meta>.

Figura 3: Saudação personalizada.

Inserir uma simples tag <meta> no cabeçalho pode não parecer das coisas mais úteis, mas é um exercício simples para explicar a essência do funcionamento dos hooks do WordPress.

Podemos aplicar este conhecimento num exercício mais prático, como adicionar o bloco HTML do Google Analytics ao rodapé das nossas páginas:

function tutorial_add_google_analytics () {
    $tracking_code = 'UA-XXXXX-X'; // Não se esqueça de me definir
    echo '<script src="http://www.google-analytics.com/ga.js" type="text/javascript"></script>';
    echo '<script type="text/javascript">';
    echo 'var pageTracker = _gat._getTracker("' . $tracking_code . '");';
    echo 'pageTracker._trackPageview();';
    echo '</script>';
}
add_action( 'wp_footer', 'tutorial_add_google_analytics' );

Outras utilizações práticas das acções contemplam, por exemplo:

• Envio de emails sempre que um novo artigo é publicado;
• Registo das autenticações feitas pelos utilizadores num ficheiro de log ou em base de dados;
• Inicializar ou preparar dados no início de um pedido de página.

Remover acções

Tal como associamos funções a hooks, também temos a possíbilidade de as retirar com a função remove_action. Suponhamos que apenas nos interessam estatísticas de utilização de visitantes autenticados, e que por isso devemos ignorar a função tutorial_add_google_analytics para os restantes.

if (!is_user_logged_in())
    remove_action( 'wp_footer', 'tutorial_add_google_analytics' );

Mais uma vez, usámos is_user_logged_in para determinar se o visitante está autenticado, e se não estiver retiramos a função tutorial_add_google_analytics do rol de acções a executar no hook wp_footer. À semelhança do add_action, podemos indicar a prioridade e o número de argumentos se quisermos apenas retirar ocorrências específicas de uma função.

Uma aplicação simples e muito prática de remove_action consiste em eliminar algumas das tags HTML que denunciam versões antigas e potencialmente inseguras a visitantes mal-intencionados. Como esta:

<meta name="generator" content="WordPress 3.3">

Para ocultar estes dados, inseridos no cabeçalho pela função interna do WordPress wp_generator, é preciso acrescentar o seguinte ao functions.php:

remove_action( 'wp_head', 'wp_generator' );

Novas acções

Definir novas acções personalizadas é tão simples quando invocá-las em qualquer parte do nosso código usando do_action. Acrescentando ao final do functions.php o seguinte:

do_action( 'tutorial_new_action' );                             // Sem argumentos
do_action( 'tutorial_new_action', $arg1 );                      // Com 1 argumento
do_action( 'tutorial_new_action', $arg1, $arg2 );               // Com 2 argumentos
do_action( 'tutorial_new_action', $arg1, $arg2, ..., $argN );   // Com N argumentos

Esta linha irá activar todas as funções que estejam associadas ao hook tutorial_new_action, podendo passar-lhes zero ou mais argumentos.

No próximo artigo, irei debruçar-me sobre a segunda classe de hooks, os filtros, onde aprenderemos a criar funções para transformar a apresentação de conteúdos do WordPress.

Até lá teremos muito gosto em receber feedback e ouvir as questões dos leitores na nossa página no Facebook.

O efeito Parallax ou parallax scrolling no web design é uma técnica que envolve várias camadas (layers) de elementos (imagens de fundo, caixas de texto, etc.) com velocidades e perspetivas diferentes, criando uma ilusão de 3D.

Atualmente com o recurso a um interface bem definido, a bibliotecas de JavaScript (jQuery) e às CSS3, podemos criar sites que pareçam mais reais e criativos, sem ter que recorrer ao Flash ou ao Video.

Usabilidade

Quando surgiram os primeiros sites a recorrer a esta técnica, muitos designers apressaram-se a adotá-la para os seus próprios sites, muitas vezes sem um planeamento adequado.

É sempre bom experimentar novas técnicas, mas quando começamos a planear os projectos à volta de uma técnica, corremos o risco de o projeto não servir os propósitos iniciais.

Utilizar uma técnica apenas porque é novidade, não é uma boa prática e pode levar a que um projeto acarrete inúmeros problemas de usabilidade.

Se acedermos a alguns sites que utilizam esta técnica, ficamos com a sensação que alguns funcionariam melhor se os elementos que a compõem permanecessem imóveis.

Considerações a ter em conta ao usar Parallax

Ao desenharmos um site que recorra ao efeito parallax devemos ter em conta alguns dos seguintes fatores:

• Carregar previamente todos os elementos gráficos: se o design contêm muitos elementos gráficos devemos, antes de disponibilizar informação ao utilizador, carregar todos os elementos gráficos. Com isto iremos proporcionar uma experiência de utilização mais agradável.
• Dispositivos móveis: devemos ter uma atenção redobrada com o dispositivos móveis, pois os utilizadores poderão não ter a mesma experiência de utilização como têm nos browsers dos computadores.
• Tamanhos dos ecrãs: testar o design em diferentes ecrãs, com diferentes resoluções e garantir que em todos temos a mesma experiência de utilização.

Potenciais problemas inerentes à utilização

Os sites que fazem uso desta técnica, como o site da Nike Better World, numa primeira impressão aparentam funcionar perfeitamente, mas algumas questões se levantam.

O primeiro problema é o facto de esta técnica ainda ser bastante recente, e por isso mesmo ser encarada como novidade. Se recuarmos um pouco no tempo, até aos anos 90, proliferou o uso massivo de .gifs animados, que também na altura eram novidade. Era impressionante ver num site não só todo o conteúdo estático mas também por exemplo um gato que dançava!!

Como nos recordamos, a novidade dos .gifs animados, passou rapidamente da experiência de vermos alguma animação nas páginas para algo que criava ruído e distraía os utilizadores.

Outro problema relacionado com esta técnica é a ainda falta de suporte nos browsers dos tablets. Ainda é difícil recriar toda a experiência de utilização nestes dispositivos.

Com o cada vez maior número de dispositivos móveis, e enquanto o suporte não melhora, temos de pensar se vale a pena criar um site que utiliza esta técnica apenas para os browsers que correm nos computadores pessoais.

Usar ou não usar Parallax

Depende sempre do objetivo do projeto.

Para percebermos se devemos ou não adoptar esta técnica num dos nossos projetos precisamos de saber quais os objetivos que pretendemos atingir. Se o conceito que o parallax oferece é o ponto central do projeto e dos seus objetivos então podemos utilizar – se não, o mais provável é estarmos a usar esta técnica apenas por ser novidade, e provavelmente o projecto irá deparar-se com maiores problemas de usabilidade.

Exemplos

Os exemplos que se seguem contêm sites que utilizam o efeito do parallax da melhor forma, a começar pelo exemplo mais popular Nike Better World. Como podemos reparar a maioria dos sites inspira-se neste exemplo.

Nike Better WOrld

Smart USA

Mario Kart Wii

Beetle

Activate Drinks

Tutoriais

• Recreate NikeBetterWorld Parallax
• Behind the Scenes of NikeBetterWorld
• Parallax Scrolling jQuery Plugin

No entanto, nem sempre é praticável investir num upgrade das máquinas, ou alterar o motor de armazenamento, a estrutura da base de dados ou sequer a política de indexação das tabelas. Seguem-se algumas técnicas de optimização de expressões SQL que programadores podem adoptar unilateralmente no sentido de melhorar o desempenho das suas consultas. Tudo sem ser preciso aborrecer os administradores da base de dados.

O MySQL explica

O primeiro passo de qualquer optimização de expressões SQL, uma vez determinada a sua necessidade, é compreender o funcionamento interno dos pedidos que fazemos à base de dados.

O statement EXPLAIN deve ser a arma de eleição para este combate. Até ao MySQL 5.6.3, servia “apenas” para avaliar expressões do tipo SELECT, mas nas versões mais recentes pode ser aplicado a todas as operações, sejam de leitura, inserção, actualização ou eliminação. Para fazer uso desta funcionalidade basta prefaciar qualquer instrução SQL com a palavra EXPLAIN.

A principal utilidade do EXPLAIN está em revelar o mecanismo de indexação usado para obter os resultados de um pedido. A indexação das colunas de uma tabela permite pesquisas mais rápidas, da mesma forma que o índice de capítulos de um livro ou a arrumação alfabética de uma lista telefónica ou enciclopédia nos facilita a consulta e leitura. A troco de algum espaço em disco e velocidade de escrita, o sistema gestor da base de dados que use índices pode encontrar o que procura directamente em vez de o fazer percorrendo as tabelas registo a registo.

Olhando para o resultado de uma chamada ao EXPLAIN, em especial para as colunas possible_keys (contendo os candidatos a índice a utilizar) e key (o índice realmente usado), obtemos informação crucial para identificar se uma tabela precisa que determinada coluna esteja indexada ou se, pelo contrário, a coluna tem índices que não se usam porque as expressões de consulta se encontram indevidamente construídas. Este artigo irá debruçar-se sobre algumas destas, e oferecer alternativas práticas.

Outras indicações do EXPLAIN a ter em conta são as colunas Extra (onde qualquer referência a índices é perfeita) e type (onde a palavra index significa full index scan, o que é péssimo para o desempenho).

Contra relógio

A função BENCHMARK(), que permite executar uma expressão SQL repetidas vezes e retornar o tempo de resposta, é outra ferramenta relativamente útil, principalmente quando é preciso testar expressões aritméticas ou com parâmetros constantes.

Embora possa ser usada para avaliar expressões do tipo SELECT, importa realçar que a execução de um pedido SELECT BENCHMARK(N, SELECT ...) irá resultar na reutilização de estruturas de memória e outros mecanismos de optimização automática do MySQL, pelo que os tempos reportados irão certamente parecer mais optimistas do que na realidade. A função BENCHMARK() também nos diz pouco sobre o tempo consumido pelo servidor, sendo por vezes necessário calcular a média de múltiplos benchmarks para nos aproximarmos de um valor real.

O que não vale a pena fazer

Felizmente, o optimizador interno do MySQL tem inteligência para melhorar, de forma transparente, determinadas expressões. De entre as melhorias automáticas que o MySQL faz contam-se:

• Eliminação de parênteses desnecessários;
• Substituição de variáveis por constantes que lhes estejam atribuídas;
• Junção das condições em WHERE e HAVING quando não existem funções de agregação ou GROUP BY;
• Ordenação ideal das tabelas num INNER JOIN.

Atacar estas situações no código pode melhorar a legibilidade do mesmo, mas não terá efeitos práticos sobre o desempenho das pesquisas.

A união faz a força

A junção de condições com o operador OR, no MySQL e noutros sistemas de bases de dados, é puro veneno.

Isto porque, quando confrontado com um OR, o sistema de base de dados ignora a indexação de muitas das colunas, uma vez que esta deixa de ser limitativa para os resultados a apresentar. Embora alguns sistemas consigam optimizar sequências de condições OR mais simples, é má ideia confiar numa optimização automática que não está garantida.

A boa notícia é que há uma solução para contornar este problema. A má notícia é que a solução é feia.

Adoptemos o seguinte exemplo, muito simples, que pesquisa a tabela de artigos de um blogue e retorna todos os registos cujo título comece por A ou tenha um artigo-pai cujo título comece por A:

SELECT p.ID
    FROM wp_posts p, wp_posts pai
    WHERE p.post_title LIKE 'A%'
        OR (p.post_parent = pai.ID AND pai.post_title LIKE 'A%')

Esta expressão pode ser reescrita à custa de múltiplos SELECTs cujos resultados são depois agregados usando a palavra-chave UNION (ou UNION ALL, que é ainda mais eficiente, mas só no caso de não ser preciso limpar registos duplicados).

SELECT p.ID
    FROM wp_posts p
    WHERE p.post_title LIKE 'A%'
UNION
SELECT p.ID
    FROM wp_posts p, wp_posts pai
    WHERE p.post_parent = pai.ID AND pai.post_title LIKE 'A%'

Embora a vantagem de reescrever a expressão desta forma não pareça nada intuitiva, o que acontece é que várias pesquisas feitas recorrendo a índices são consideravelmente mais rápidas do que uma única pesquisa feita sem essa ajuda. Esta diferença torna-se bastante perceptível com o aumento do tamanho da tabela a consultar, podendo a optimização traduzir-se numa redução do tempo de pesquisa de várias horas para poucos minutos.

Aplicando o EXPLAIN às duas expressões da consulta, torna-se evidente, olhando para o campo key, qual delas não está a usar os índices que tem à disposição.

> EXPLAIN SELECT p.ID, p.post_title FROM wp_posts p, wp_posts pai WHERE (p.post_parent = pai.ID AND pai.post_title LIKE 'A%') OR p.post_title LIKE 'A%';
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | p     | ALL  | post_parent   | NULL | NULL    | NULL | 2412 |             |
|  1 | SIMPLE      | pai   | ALL  | PRIMARY       | NULL | NULL    | NULL | 2412 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
2 rows in set (0.00 sec)

Se, contudo, pedirmos ao MySQL para “explicar” a expressão com UNION, detectamos que a chave PRIMARY é usada para relacionar o pai de um artigo através do seu identificador, o que não acontecia antes, e por conseguinte reduzindo o número de linhas (em rows) que é preciso considerar.

> EXPLAIN SELECT p.ID, p.post_title FROM wp_posts p, wp_posts pai WHERE p.post_parent = pp.ID AND pai.post_title LIKE 'A%' UNION SELECT p.ID, p.post_title FROM wp_posts p WHERE p.post_title LIKE 'A%';
+----+--------------+------------+--------+---------------+---------+---------+--------------------+------+-------------+
| id | select_type  | table      | type   | possible_keys | key     | key_len | ref                | rows | Extra       |
+----+--------------+------------+--------+---------------+---------+---------+--------------------+------+-------------+
|  1 | PRIMARY      | p          | ALL    | post_parent   | NULL    | NULL    | NULL               | 2412 |             |
|  1 | PRIMARY      | pai        | eq_ref | PRIMARY       | PRIMARY | 8       | blog.p.post_parent |    1 | Using where |
|  2 | UNION        | p          | ALL    | NULL          | NULL    | NULL    | NULL               | 2412 | Using where |
|NULL| UNION RESULT | <union1,2> | ALL    | NULL          | NULL    | NULL    | NULL               | NULL |             |
+----+--------------+------------+--------+---------------+---------+---------+--------------------+------+-------------+
4 rows in set (0.00 sec)

Felizmente para quem tem de ler e entender o código, a utilização do UNION nem sempre é necessária. Quando basta escolher de entre um leque de valores constantes para uma coluna, como no exemplo abaixo, estes podem ser refeitos usando a comparação IN.

SELECT p.ID
FROM wp_posts p
WHERE p.ID = 1
    OR p.ID = 2
    OR p.ID = 3
    OR p.ID = 5
    OR p.ID = 8
    OR p.ID = 13

Isto pode ser transformado em:

SELECT p.ID
FROM wp_posts p
WHERE p.ID IN (1, 2, 3, 5, 8, 13)

A comparação IN verifica a presença de uma variável numa lista de valores e é extremamente eficiente quando a lista é pequena e composta apenas por constantes. (É importante reforçar esta condição porque muito embora IN (constante1, constante2, ...) seja eficiente, IN (SELECT ...) já não é.)

Encadeamento de consultas

Outro deslize comum em que a facilidade de escrita e leitura choca com a optimização das consultas é no caso dos SELECTs encadeados, que ocorrem quando o programador está a pensar em termos procedimentais e não nos dados e nas suas relações. Por exemplo:

SELECT
    c.id,
    c.nome,
    (SELECT SUM(horas)
        FROM relatorio
        WHERE colaborador_id = c.id) AS total_horas
FROM colaboradores c

Esta expressão não é a ideal porque o segundo SELECT (dentro do SELECT principal) obriga a um esforço suplementar do sistema da base de dados, que é pago em tempo de resposta e ocupação de memória. Embora haja situações em que o uso de pedidos encadeados é inevitável, neste caso a expressão pode ser facilmente refeita através de um INNER JOIN muito mais eficiente.

SELECT
    c.id,
    c.nome,
    SUM(h.horas) AS total_horas
FROM colaboradores c
INNER JOIN horas h
    ON h.colaborador_id = c.id

Funções e os pedidos que funcionam mal

Outra atenção a tomar reside na aplicação de funções a comparações com campos indexados. Estas situações atrapalham a cache de pedidos e reduzem (tal como acima) o desempenho da base de dados. Deve-se pesar a necessidade de ter estas funções na consulta versus a possibilidade de passar parâmetros condicionais pré-processados ou de obter um conjunto de dados maior e aplicar posteriormente uma rotina de filtragem.

Dois em um

Programadores que desconhecem as palavras mágicas ON DUPLICATE KEY UPDATE tendem a incorrer noutro erro comum: o de fazer um SELECT para verificar a existência de determinado registo, seguido por uma instrução de INSERT para o criar caso não exista ou então UPDATE caso esteja presente.

Não só a estrutura de decisão envolvida neste processo complica desnecessariamente o código, como obriga a duas ligações à base de dados: uma para o SELECT inicial, e outra para o pedido de inserção ou actualização. A solução mais prática é fazer um único INSERT ... ON DUPLICATE KEY UPDATE, matando estes dois coelhos com uma cajadada só.

Mas há mais!

Embora este artigo esteja centrado no desenvolvimento sobre MySQL, os cuidados e recomendações são aplicáveis a muitos outros sistemas de gestão de bases de dados, como Oracle ou Microsoft SQL Server, bastando adaptar a sintaxe SQL.

As possíveis optimizações ao SQL das consultas também não se esgotam aqui, pelo que não termino o artigo sem recomendar um conjunto de recursos online úteis para quem pretenda alargar os seus horizontes neste capítulo do desenvolvimento sobre bases de dados.

• Optimizing SQL Statements
• MySQL Performance Tuning and Optimization Resources
• MySQL Performance Blog, de Peter Zaitsev
• Big DBA Head, de Matthew Yonkovit
• Top 20+ MySQL Best Practices, por Burak Guzel

Responsive Design utilizado em diferentes dispositivos

Existe um novo conceito entre os web designers intitulado Responsive Design. A primeira pessoa que fez menção a este termo foi Ethan Marcotte num artigo intitulado Responsive Design que escreveu para o blog A List Apart.

No artigo o Ethan descreve o processo de como utilizar layouts dinâmicos juntamente com as media queries para redimencionar os layouts dos sites de forma a que estes se ajustem a qualquer tamanho de ecrã.

Mas afinal o que é o Responsive Design? Como refere Nick Pettit, a questão não é tanto o que é, mas sim os problemas que este pode resolver. Como sabemos os computadores já não são os únicos dispositivos que podem aceder à Web. Os smartphones e tablets evoluiram e com isso o panorama da Web para dispositivos móveis.

As pessoas esperam poder aceder à Web nos seus smartphones tão facilmente como o fazem nos seus computadores. Em resposta a esta necessidade começou-se a criar versões móveis dos sites. Cada site passou a ter a versão “normal” e uma bónus, a versão “móvel”.

O espectro de tamanhos de ecrã e resoluções está a aumentar a cada dia, e criar uma versão diferente do site para cada dispositivo é praticamente impossível. Este é um problema que o Responsive Design vem tentar resolver.

O termo Responsive Design, é a forma de, utilizando grelhas fluídas, layouts fluídos e as @media queries conseguir adaptar o site ao manancial de dispositivos com diferentes tamanhos de ecrã que existem hoje.

Desta forma um utilizador que esteja a ver o site num smartphone, num tablet, ou num pc de secretária, verá o site adaptar-se automaticamente ao tamanho do ecrã de cada um dos dispositivos.

Com o advento dos dispositivos móveis, o Responsive Design torna-se ainda mais apelativo, como refere Luke Wroblewski num artigo intitulado Designing for Mobile First.

Nesse artigo o Luke aconselha-nos a começar a desenhar o site no ecrã mais pequeno. Desta forma asseguramos que teremos um excelente site para dispositivos móveis, o que força os designers a focar-se no que realmente interessa aos utilizadores.

Qual a melhor forma de construir um site que seja “Responsive”? Depende sempre do site em questão, mas existe uma série de normas que começam a emergir como boas práticas.

Aqui ficam 9 dicas para implementar Responsive Web Design:

1. Utilizar as @media queries para redimensionar o layout para qualquer tamanho de ecrã, tendo sempre em atenção que só isto não o transforma num site responsive.
2. Utilizar layouts fluídos que consigam adaptar-se a qualquer tamanho de ecrã. Não devemos desenhar um layout para os iPhone/Android, outro para os tablets e outro para os computadores. Devemos sempre mantê-lo fluído, para o caso de aparecer um novo dispositivo com um tamanho de ecrã diferente.
3. Criar as grelhas do site baseadas no conteúdo do site. As grelhas que existem raramente servem o propósito do site, uma vez que elas são feitas para diferentes tipos de conteúdo e raramente se encaixam no tipo de conteúdo que o site vai ter. Os layouts devem ser criados a partir do conteúdo.
4. Começar com o tamanho mais pequeno. Devemos começar com o tamanho de ecrã mais pequeno, utilizando as @media queries para ajustar os elementos. Começar com uma coluna, para os smartphones e ir aumentando o tamanho do layout para ecrãs maiores, em vez de fazermos ao contrário.
5. Utilizar as bibliotecas de JavaScript para as Media Queries de forma a dar suporte aos browsers mais antigos que de outra forma não sabem o que fazer. Ao começarmos do tamanho mais pequeno para o maior os browsers dos computadores necessitam de lidar com as @media queries, precisamos de garantir que os browsers mais antigos funcionam, utilizando estas bibliotecas de Javascript.
6. Não utilizar o Photoshop/Fireworks. Devemos desenhar os nossos componentes no browser. É praticamente impossível desenhar um layout fluído no Photoshop. Começar no browser desde o primeiro instante é uma muito boa prática.
7. Redimensionar as imagens utilizando a propriedade img { max-width: 100%; }. Para imagens muito grandes devemos considerar utilizar um plugin de Javascript como o Responsive Images que permite fazer apenas o download das imagens para o dispositivo que estejamos a utilizar. Se estivermos num smartphone só faz o download das imagens utilizadas para esse layout permitindo desta forma poupar no tráfego de dados.
8. Carregar o conteúdo essencial primeiro. Pode haver elementos no site, que sirvam como conteúdo auxiliar. Devemos carregar esses elementos depois do conteúdo principal recorrendo ao JavaScript.
9. Não se preocupar com a perfeição. Haverá sempre utilizadores que não vão conseguir aceder ao site da melhor forma, seja por terem browsers demasiado antigos, ou por terem o JavaScript desativado. Esses utilizadores são cada vez mais raros. Se eles virem o layout para smartphones no computador, não é o fim do mundo. O site continua a ser perfeitamente usável.

“3 dias. 24 horas por dia. 800 participantes.”

A V edição do SAPO Codebits decorre nos próximos dias 10, 11 e 12 de Novembro, no Pavilhão Atlântico em Lisboa, e junta programadores, geeks, criativos e entusiastas de tecnologia.

Para além das conferências com oradores nacionais e internacionais, existem também workshops, concursos de programação, quizzes, karaoke, jogos de vídeo, LEGO, comida e bebida.

Uma experiência inesquecível a que log não poderia faltar!

Mais informações aqui: http://codebits.eu

Este evento irá decorrer em Lisboa, nos próximos dias 17 e 18 de Novembro, e contará com a presença de oradores como Paul Kedrosky da Kauffman Foundation, Patrick Vlaskovits da Lean Startup, Tony Fernandes da UE Group User Experience, Raymond Nasr ex-Google, Philip Rosedale criador do Second Life, Daniel Kraft da Stanford/Singularity, Peter Cohan do Babson College, Sean Ammirati da ReadWriteWeb, Bill Burnett da d.school Stanford, André Ribeirinho fundador do Adegga.com, entre outros.

Mais informações aqui: http://www.svc2lx.com/.