FlavioGranero.com

Diante de tanta polêmica sobre o possível problema de escalabilidade do Rails, que seria a causa da instabilidade do Twitter, na RailsConf 2008 aconteceram várias apresentações tentando desmistificar o fato, mostrando maneiras de projetar aplicações que suportem milhares ou até milhões de requisições por dia.

Nada melhor que demonstrar isso e mais uma série de vantagens do Rails com um caso de uso real. Foi o que fez John Straw, arquiteto de software chefe da YellowPages.com, com a apresentação “Sobrevivendo a uma grande reescrita - Movendo YellowPages.com para Rails“. A minha intenção com este post é fazer uma tradução livre e resumida de seus tópicos.

Para quem não conhece, a YellowPages.com é o site das “páginas amarelas” dos Estados Unidos. O equivalente a Telelistas.net só que, acredito eu, com números mais expressivos: 23 milhões de visitantes por mês, 2 milhões de buscas por dia, mais de 48 milhões de requisições por dia, sendo mais de 1500 por segundo.

A chamada “Grande reescrita” começou no final de 2006. O sistema existente era escrito em Java, com 125.000 linhas de código, e mantido por consultores externos. Em apenas três meses de desenvolvimento, uma equipe de 20 pessoas (sendo apenas 5 desenvolvedores) portou o sistema para Rails, resultando em apenas 20.000 linhas código. O que impressiona é que a equipe havia estimado o prazo de 1 ano para a tarefa.

Mas por que decidiram reescrever o sistema?

O sistema do YellowPages já estava sem mudanças de design desde 2003 e, de acordo com testes de usabilidade, a experiência que o usuário tinha ao navegar não era satisfatória.

Além do design, a plataforma era difícil de manter, de aplicar técnicas de SEO e a implementação de sessões tornava o sistema difícil de escalar horizontalmente. O código estava cheio de remendos e não havia testes, fazendo da tarefa de adicionar novas funcionalidades algo muito trabalhoso.

Para resolver esses problemas e ainda criar uma arquitetura orientada a serviços, decidiram pelo RubyOnRails, usado em 90% da nova estrutura.

O que os levou a escolher Rails?

Um dos requisitos principais para a nova aplicação era proporcionar controle sobre a estrutura de URLs, principalmente para uso de SEO. Avaliando frameworks Java, nenhum apresentou um controle satisfatório. Logo, a escolha ficou entre Rails e Django.

Rails acabou levando a melhor sobre Django por que:

• Possuía uma melhor integração com testes automatizados;
• Era uma plataforma mais madura;
• Existia um caminho claro para C, caso necessitassem de mais performance;
• Os desenvolvedores se sentiam mais confortáveis e experientes.

Como ficou a arquitetura da aplicação?

Arquitetura da aplicação (clique para ampliar)

A figura acima mostra como ficou o design da aplicação, dividida em três camadas: web, serviço e busca, cada uma delas separada por um hardware de balanceamento de carga F5. O Apache também foi usado no gerenciamento dos processos mongrel, espalhados pela camada web e camada de serviço. Vejamos outras características da arquitetura:

• Comunicação HTTP em todos os níveis sem salvamento de estado (Stateless)
• A camada de serviço responde a REST e no formato JSON
• Memcached foi usado extensivamente na camada de serviço
• Ambiente de produção: 25 servidores para a aplicação + 2 servidores para banco de dados Oracle em cada data center.

Conseguiram a performance desejada?

Algumas metas de performance foram estabelecidas: A média de carregamento da página inicial deveria estar abaixo de 1 segundo, para páginas de busca a resposta deveria estar em menos de 4 segundos e suportar todo o tráfego sem quedas. Para isso, foram necessárias otimizações:

• Consideraram o uso de balanceamento de carga por hardware: F5 vs. HAProxy vs. Swiftiply vs. Localhost;
• Utilizaram mongrel_handlers para direcionar requisições da camada web para a de serviços sem passar pelo Rails;
• Desenvolveram uma biblioteca em C para organizar as respostas do cluster de buscas;
• Utilizaram Erubis para acelerar a renderização das views da camada web;
• Minimizaram o tamanho do JavaScript e mudaram de Prototype para jQuery.

A reescrita foi considerada um sucesso!

Depois de todo o trabalho, o novo sistema apresentou melhor desempenho que o sistema antigo em Java, com a vantagem de ser feito em Rails e dirigido por testes, o que o torna fácil de manter e de estender.

Para concluir a apresentação, John Straw destacou alguns itens considerados chaves para o sucesso do projeto:

• Equipe de desenvolvimento pequena e talentosa;
• Avaliação cuidadosa da tecnologia e escolha da plataforma compatível com a aplicação;
• Fácil comunicação entre os membros da equipe com diversos pontos de vista permitiu uma captura de requisitos sem formalismo;
• A regra “Não altere coisas que não são simples de decidir” preveniu a tomada de decisões que paralisavam o projeto;
• A criação de um site “beta” constantemente atualizado possibilitou uma visualização clara de progresso e direcionamento.

Veja mais detalhes sobre todo o processo de reescrita no PFD da apresentação de John Straw, disponível em http://en.oreilly.com/rails2008/public/asset/attachment/2765.

Fontes:  RailsOnWave e BuildingWebApps.

Quando comecei a aprender Rails a mais de um ano atrás, percebi logo de cara que ali estava a oportunidade de colocar algumas idéias em prática. Em Rails é muito fácil prototipar uma aplicação ou colocá-la em produção rapidamente. Decidi pegar uma de minhas idéias de sistemas web, que anoto em meu caderno de idéias sempre que tenho aquela lâmpada acessa sobre a cabeça, e usar o tempo investido em aprender Ruby e Rails para criar algo funcional, algo que eu pudesse chamar de empreendimento. Inspirado em outras aventuras da web brasileira em Rails (Brasigo, Just-remind.Us, Mapia), surgiu o sismiko.com.

Foram alguns meses de estudo e implementações feitas somente nas horas vagas, que não tenho como calcular a quantidade, já que em alguns desses meses não consegui escrever nenhuma linha de código nova, devido a acontecimentos imprevistos. Só sei que foram raros os dias que pude dedicar mais de 3 horas. Além disso, tive que me desdobrar para ser programador Rails, designer e construtor de HTML e CSS ao mesmo tempo.

Segui as premissas do livro “Caindo na Real” e fiz uma versão totalmente enxuta, apenas com as funcionalidades básicas, indo direto ao ponto. A função principal do sismiko é ser um catálogo de eventos, onde o usuário pode ver quais os eventos que irão acontecer na sua cidade e criar uma agenda própria com aqueles em que gostaria de comparecer. Quando eu digo eventos, me refiro a festas, baladas, feiras, cursos, peças de teatro, ou qualquer coisa que seja um encontro de pessoas com uma data definida. O sismiko é também um ranking dos melhores eventos, já que eles são sempre ordenados pelo número de pessoas que agendaram o acontecimento. O usuário pode ver qual o evento mais agendado para sua cidade, para seu estado, ou ainda, para o país (por enquanto só existe suporte ao Brasil). Leia mais no post de lançamento.

Não é uma idéia nova, já que sites como o upcoming.org fazem isso há algum tempo, mas o sismiko tem o propósito de oferecer um serviço voltado ao público brasileiro e com diferenciais que apresentarei em versões futuras. Acompanhe o blog do sismiko para ficar sabendo das novas funcionalidades.

Quanto à parte técnica, o sistema está rodando sobre o Rails 1.2.6 e hospedado em um servidor shared no RailsPlayground.com, com fastcgi apenas. Utilizo os seguintes plugins do Rails:

• atachment_fu: para o envio de imagens, com redimensionamento feito pela gem Rmagick;
• exception_notification: Para ser avisado por e-mail sobre erros na aplicação;
• restful_authentication: Para criar contas de usuário de uma maneira REST;
• acts_as_fulltextable: Para implementar um sistema de busca simples em eventos e locais;
• geokit: Para mostrar eventos próximos à uma determinada localização geográfica e para tentar (nem sempre funciona) localizar a cidade de onde o usuário está acessando o site;
• will_paginate: Para paginar os resultados de busca, eventos e locais.

O sismiko foi desenvolvido de forma REST, mas nesta primeira versão os resursos respondem apenas ao formato HTML. As páginas possuem HTML e CSS validados em XHTML Strict 1.0 e CSS 2.1 respectivamente, com os eventos sendo apresentados através do microformato hCalendar. Existem alguns javascripts obstrusivos dentro do HTML, o que invalida algumas páginas, mas que logo serão substituídos utilizando o JQuery. Os ícones eu emprestei do http://www.famfamfam.com/

Pretendo manter o sistema em constante desenvolvimento, por isso aceito de bom grado sugestões de funcionalidades, de melhorias do layout e informações sobre erros. Na fila de novidades estão comentários nos eventos e locais, feeds de todas as listas, widgets para a agenda ser colocada em blogs e sites e algumas funções em javascript, como a ação “agendar” e a listagem de estados e cidades na barra de localização.

Espero que gostem!

Encontrei um erro ao paginar os resultados de buscas com o plugin acts_as_fulltextable utilizando will_paginate. O acts_as_fulltextable passa uma série de opções para que o método paginate execute a query com MATCH()…AGAINST dentro da chave :SELECT, como foi explicado no post anterior. O Will_paginate por sua vez, não trata esse tipo de select complexo quando requer o número total de registros ao banco, utilizado em SELECT COUNT(…), que retorna um erro de má formação de SQL.

Corrigi esse problema adicionando uma linha ao código do Will_paginate, no método method_missing_with_paginate que o faz rejeitar opções da chave :select, fazendo sempre um count(*) no banco. Esse método se encontra no arquivo finder.rb que está no diretório will_paginate\lib\will_paginate\, na pasta de plugins do seu projeto. Veja o trecho alterado:

def method_missing_with_paginate(method, *args, &block)
        # ....
        # :total_entries and :count are mutually exclusive!
        total_entries = unless options[:total_entries]
          unless args.first.is_a? Array
        # count expects (almost) the same options as find

count_options = options.reject { |key, value| key == :count or key == :order }

#***aqui removo as opções de select também, que causam erro de SQL ***

count_options = count_options.reject { |key, value| key == :select }

# merge the hash found in :count
# this allows you to specify :select, :order, or anything else just for the count query

count_options.update(options.delete(:count)) if options[:count]
# thanks to active record for making us duplicate this code

count_options[:conditions] ||= wp_extract_finder_conditions(finder, args)

count = count(count_options)

count.respond_to?(:length) ? count.length : count
           #....
        end
      end

Depois de alterar o código, é necessário reiniciar o servidor.

Disponibilizei o arquivo com o código alterado: http://www.mediafire.com/?5n1icgnxwy5

Quando desenvolvemos sistemas web, é bem comum que já no levantamento de histórias da primeira iteração, alguém grite lá no fundo:

“Não esqueçam que o sistema deve ter um mecanismo de busca”

Não importa se estamos fazendo um grande indexador de blogs ou um pequeno sistema de locadora, a funcionalidade de busca é extremamente comum. Mecanismos de buscas trazem segurança ao usuário, é uma questão de usabilidade ter sempre uma caixa com essa finalidade no canto superior direito do site.
Como estamos desenvolvendo em RubyOnRails, teríamos algumas possibilidades de implementação um tanto quando sofisticadas, com criação de arquivos de índices e resultados ordenados por relevância, para citar algumas funções. Tudo isso com a simplicidade de instalar uma gem e um plugin. Ferret e Sphinx são bons exemplos desse tipo de gem. Ambas têm atrativos a performance e a escalabilidade.

Decidi pelo Ferret em meu projeto e comecei a vivenciar alguns problemas, como a falta suporte a UTF-8 no Windows, problemas na busca por palavras no plural, acentuadas, ou com case diferente do indexado e principalmente, a necessidade de um processo exclusivo para a atualização dos índices, pois ocorrem erros se vários processos tentarem escrever no índice, o que atrapalha muito quando se usa uma hospedagem compartilhada. Encontrei desenvolvedores na internet dizendo para deixar o Ferret e usar o Sphinx, devido a sua instabilidade em ambiente de produção. Diante da inevitável mudança e retrabalho, me fiz a seguinte pergunta:

Eu realmente preciso de todas essas funcionalidades e de toda essa performance?

Como sabemos quanto mais funcionalidades, mais complicado fica o sistema de manter e de alterar (vide a lei “Menos Massa” do livro Caindo na Real). Ainda seguindo as práticas do “caindo na real”, fiquei convencido de que o melhor a fazer era deixar meu sistema começar pequeno, em uma hospedagem compatilhada e rodando em fastcgi ou em mod_rails. Este é um conceito que gosto bastante, escalabilidade só deve ser um problema quando a aplicação tiver número de usuários suficiente para tal.
Passei a procurar uma solução mais simples que me atendesse e encontrei o plugin acts_as_fulltextable, que não usa nenhuma gem extra.

Mas apenas um plugin para realizar buscas? Sem gems? Deve ficar extremamente lento…

Para minha surpresa a solução se mostrou extremamente eficaz. O plugin faz uso de uma funcionalidade do MySQL chamada Full-Text Search. Trata-se de um tipo especial de índice de banco que pode ser aplicado a tabelas MyISAM em campos CHAR,VARCHAR e TEXT. Assim, as buscas passam a ser feitas diretamente pelo MySQL, através de instrução MATCH() … AGAINST, como pode ser entendido lendo-se a documentação. O que o plugin faz é criar uma tabela extra, com os campos escolhidos em cada Model e aplicar esse tipo de índice. Vamos ao passos para usá-lo.

Instalando o acts_as_fulltextable:

 script/plugin install http://wonsys.googlecode.com/svn/plugins/acts_as_fulltextable/

Para adicionar atributos dos models ao índice, é necessário que a linha abaixo esteja no código da classe Model (arquivo Model.rb):

acts_as_fulltextable :atributo1, :atributo2, :atributo3

Depois, cria-se uma migration através do gerador que acompanha o plugin, passando os models com campos indexados:

script/generate fulltext_rows model1 model2 model3 ...

Atualizamos a estrutura do banco:

rake db:migrate

E pronto, magicamente podemos chamar os métodos em nossos controllers

Model.find_fulltext('string de busca', :limit => 10, :offset => 0)

Para buscar em um Model específico, limitando o número de respostas em 10, ou ainda

FulltextRow.search('string de busca', :only => [:model1, :model2, :model3], :limit => 10, :offset => 0)

Para procurar em todos os models indexados, ou naqueles indicados em :only.

Acabei de criar um novo Model, como adiciono na tabela de índice?

Simples, basta colocar a seguinte linha na sua migration, substituindo NewModel pelo seu Model:

NewModel.find(:all).each {|i| i.create_fulltext_record}

Quero paginar o resultado da busca com will_paginate. Tem como?

A versão que está no repositório dos desenvolvedores já suporta will_paginate. Existe um código que verifica se o will_paginate está instalado e mostra o resultado através do seu método paginate. Logo, pode-se trocar os parâmetros :limit e :offset por :page normalmente:

FulltextRow.search('string de busca', :only => [:model1, :model2, :model3], :page => params[:page])

[update]Existe um erro nesta integração entre os dois plugins, veja aqui como corrigir[/update]

Se você está com problemas em implementar uma busca em seus site que seja case-insensitive e que ignore acentuação automaticamente, aceitando caracteres UFT-8, além de ser fácil de instalar e configurar, o acts_as_fulltextable foi feito pra você.

Assinar o blog de Tom Richmond é uma ótima maneira de acompanhar o que acontece no mercado americano de ilustração, e ainda se deliciar com muitas caricaturas e tutoriais. Ele é ilustrador da revista MAD (aquela que está voltando a ser publicada no Brasil), sempre cheia de humor e desenhos.

Para quem não acompanha, são várias as contribuições de Tom com textos bem detalhados e ilustrados sobre técnicas que ele utiliza em suas criações. Sua mais recente série apresenta o tema “Como desenhar caricaturas”, sendo dividida em três partes:

Parte 1 - Teoria básica e as cinco formas: Nesta primeira parte temos a definição de caricatura e algumas características que as distinguem de outros tipos de desenhos. Para Richmond, quem vê uma caricatura deve se lembrar da pessoa retratada, o desenho deve usar o exagero para destacar seus traços e ainda, deve dizer algo sobre a vítima pessoa, como representar uma atitude ou fato acorrido. O ilustrador deve aprender a observar detalhes em seus modelos que os fazem únicos e facilmente reconhecíveis.

Após a introdução, é apresentada a teoria das cinco formas, onde se destaca o relacionamento entre o formato da cabeça, do olho esquerdo e do direto, do nariz e da boca na criação do desenho. Alguns exemplos com pessoas famosas servem de representação da teoria.

Parte 2 - Relacionando características: Esta segunda parte é muito bem resumida pela frase utilizada pelo próprio Tom (tradução livre):

Desenhar caricaturas não é apenas escolher uma característica e torná-la grande, mas sim mostrar todas as características e como elas se relacionam.

Para que esse relacionamento seja entendido, apresenta-se a proporção clássica do rosto de uma pessoa, a fim de facilitar a identificação de traços pessoais do assunto pelo ilustrador.

Parte 3 - A importância do formato da cabeça: Aqui, Tom explica porque o desenho da cabeça é a parte mais importante da caricatura, e ainda ensina truques de observação de seus formatos. O objetivo é tornar tudo simples, traçando a linha dos olhos e encontrando proporções e pontos de referência, ao até mesmo associando o formato com objetos conhecidos (cabeça de melão, por exemplo =D).

Para finalizar, temos diferentes maneiras de “exagerar” no formato da cabeça, com a mudança nas proporções normais e o uso da lei da massa constante, que previne exageros não convincentes (a lei diz que quando você aumenta uma parte da cabeça, como o tamanho do queixo, deve-se diminuir o tamanho do topo, mantendo assim a massa constante).

Depois desses ótimos tutoriais é só mirar em um alvo e sair desenhando, ou será exagerando…

Precisa de mais inspiração? Tem muitos artistas brasileiros com blogs ou fotologs recheados de caricaturas, citando alguns: Baptistão, Calos Muller, Mário Alberto e Tiago Hoisel.

Ser bombardeado diariamente com novidades tecnológicas foi o que sempre me atraiu no mercado de desenvolvimento de software. Justamente por isso que há algum tempo não acredito mais que exista uma tecnologia que possa resolver todos os problemas, mas que cada uma tem suas vantagens de acordo com o tipo do projeto.Há pouco mais de um ano eu escrevia uma monografia para o curso de pós-graduação com o que era de mais avançado em termos de arquitetura distribuída através de webservices. Seu título? “Estudo do MDA e SOA“, tratando de como é possível projetar um sistema em uma arquitetura orientada a serviços com diagramas UML e, com a mágica de uma ferramenta CASE, gerar o código e as interfaces de serviços facilmente. As descrições de serviços eram feitas em WSDL e o protocolo para comunicação, SOAP.

Algum tempo depois, estudando Ruby e Ruby On Rails deslumbrei-me com um novo conceito de arquitetura. Chamava-se ROA, ou arquitetura orientada a recursos.

E qual a diferença entre SOA e ROA?

Em SOA, o desenvolvedor descreve serviços, representados por verbos. Para obter uma lista de eventos cadastrados no sistema teríamos um método publicado com o nome GetEvents, por exemplo. A comunicação com os serviços pode ser feita através de vários protocolos, entre eles SOAP, CORBA, DCOM, etc.

Já ROA pode ser vista como uma especialidade de SOA, onde ao invés de serviços, publicam-se recursos, ou seja, entidades. Para o mesmo exemplo da lista de eventos, bastaria ter um recurso em nosso sistema acessível pelo nome Events que provesse essa funcionalidade. Cada recurso pode prover uma série de funcionalidades, cada uma comparável a um serviço. Cabe ao protocolo de comunicação informar ao recurso qual a função desejada pelo cliente.

Se em arquiteturas SOA eu uso o protocolo SOAP, então em ROA usarei REST?

Essa é uma confusão freqüente. Tratar REST como um protocolo. REST, sigla de Representational State Transfer, na verdade é um padrão para a construção de webservices que farão uso unicamente do protocolo HTTP para a comunicação.

Mas o protocolo SOAP também pode usar HTTP!

Na maioria dos casos, os dados empacotados em SOAP são transferidos usando o protocolo HTTP. Neste caso, HTTP é utilizado apenas para transporte, já que ambos os lados (cliente e servidor) precisam conhecer SOAP para desempacotar e utilizar os dados.

Em sistemas construídos da maneira REST (RESTful), nenhum outro protocolo é necessário além do HTTP, o mesmo usado pelos navegadores para obter páginas na internet. Dessa forma vemos claramente que em REST, serviços são tratados como Websites.

Muito se discute sobre as vantagens da abordagem REST em relação à SOAP, mas como escrevi no inicio do texto, cada tecnologia pode trazer um melhor resultado dependendo do projeto e da maneira como é aplicada. Agora uma coisa é certa, REST traz simplicidade ao desenvolvimento de webservices, tanto na construção do servidor quanto na implementação de clientes.

Em breve farei um texto mais detalhado sobre como definir um serviço REST. Até lá.

Aprenda mais sobre REST em:

• Livro RESTful Web Services;
• Descrição da implementação REST no Del.icio.us;
• Dissertação que originou o conceito REST
• Artigo mostrando quando usar REST e quando usar SOAP.

Faz alguns anos que ouvi falar de microformats pela primeira vez. Estava eu aprendendo sobre padrões web (que na época conhecia apenas como tableless), lendo o blog do Henrique, que escrevia sobre css, webdesign e acessibilidade com bastante freqüência. Certo dia (8 de dezembro de 2005 para ser exato, faz um tempão já), ele publicou um texto com um título até então desconhecido para muitos. Fui apresentado aos Microformats. Vamos às definições:

O que são Microformats ou microformatos?

De uma forma simplista, é uma maneira de informar para robôs que lêem páginas HTML qual o significado de determinado conteúdo, sem interferir na maneira como este mesmo conteúdo é apresentado para entendimento humano. Isso é feito padronizando-se quais tags e atributos de tags devem ser usadas para destacar uma informação dentro do conteúdo total do site. Quer um exemplo?

No meu caso, estou desenvolvendo uma aplicação web para catalogar eventos (ainda não está on-line, quando estiver publico o link). Cada evento possui informações como nome, descrição, data de início, data de fim e local onde será realizado. Quando um sistema de busca encontrar a página do evento, ele não saberá o que esses dados querem dizer, e eles serão catalogados como informações comuns do site, sem distinção.

Agora, se eu utilizar certa padronização na formatação dos dados, e se esse padrão for conhecido pelo sistema de busca, os dados podem ser tratados de forma especial, certo?

Especificamente para a padronização de informação sobre eventos existe o microformato chamado hCalendar. Vamos a um exemplo de código:

<div class="vevent">
<h3 class="summary">Campus Party Brasil</h3>
<p class="description">Campus Party é considerado o maior evento de entretenimento eletrônico em rede do mundo.
Um encontro anual realizado desde 1997, que reúne, durante sete dias, milhares de participantes
com seus computadores procedentes de toda a Espanha e de outras nações, com a finalidade de compartilhar curiosidades,
trocar experiências e realizar todo o tipo de atividades relacionadas a computadores, às comunicações e às novas tecnologias*.</p>
<p>Será realizado de <abbr class="dtstart" title="2008-02-11">11</abbr>
a <abbr class="dtend" title="2008-02-17">17 de fevereiro de 2008</abbr></p>
<p>Local: <span class="location">Bienal, São Paulo, SP</span></p>
<a class="url" href="http://www.campus-party.com.br/">http://www.campus-party.com.br/</a>
</div>

Então só preciso colocar as classes corretas nas tags de conteúdo do HTML?

Basicamente, mas não apenas isso. Observe que ao atribuir a classe “description” à tag <p>, eu rotulo a informação da tag, deixando claro que seu conteúdo é a descrição do evento. Logicamente essa classe só tem valor semântico se estiver dentro de uma tag com a classe “vevent”.

Além do atributo classe, o atributo “title” também é usado para informar conteúdo, como acontece com “dtstart”. Note que em “title” o formato da data está em ISSO 8601, que é um formato de fácil leitura para um robô de busca. Já o conteúdo da tag apresenta um valor humanizado, que será apresentado pelo navegador.

Posso utilizar outras tags, mantendo os valores da propriedade “class”?

Esta é uma dúvida antiga minha. Para descobrir, fiz vários testes utilizando a extensão Operator do Firefox, que reconhece microformats como o hCalendar e ainda possibilita a exportação para o formato iCal, ou ainda para serviços web, como o Google calendar.

Cheguei às conclusões:

• Em tags onde apenas o atributo “class” é levado em consideração para distinção semântica, como em “vevent”,”summary”,”description”, a troca de tag pode ser realizada.
• Em tags onde outros atributos além de “class” formam o valor semântico, a troca não é possível. Isso ocorre em “dtstart”, “dtend” e “url”. Isso é bem compreensível, já que apenas a tag <a> possui o atributo “href” em uma página XHTML válida.
• Web semântica significa usar tags que façam sentido para seu conteúdo, como <p> para a descrição do evento. Poderíamos usar uma lista de definições <dl> por exemplo. Funcionaria, mas não estaríamos utilizando a tag mais adequada.

Qual a vantagem de se utilizar esses padrões?

Aplicando microformatos, os dados de seu site passam a ter significado, o que permite buscas mais elaboradas. O Yahoo anunciou recentemente que seu mecanismo de busca passou a indexar semanticamente o conteúdo, trazendo à tona discussões sobre as possibilidades que isso traz. Breve, poderemos encontrar eventos em determinadas datas ou locais diretamente através desse tipo de mecanismo, pois os resultados serão mostrados de acordo com sua relevância e de forma diferenciada baseado nos microformatos.

Mostrei aqui apenas um exemplo de aplicação do hCalendar. Existem vários microformatos prontos com outras funções, como identificar dados para contato (hCard) e licenças de publicações (rel-license), além de alguns em desenvolvimento, como o padrão para indicar coordenadas geográficas (geo) e análises de produtos e serviços (hReview). A disseminação desses padrões permitirá buscas por publicações em Criative Commons mais facilmente, ou ainda, pesquisas apenas em sites que foram escritos por alguém próximo da cidade onde moramos.

A web semântica está cada vez mais próxima de se tornar realidade. Alguns dizem que sua implementação e utilização será o marco do início da Web 3.0.

Aprenda mais sobre microformatos em:

• Blog Oficial sobre microformatos
• Lista completa de microformatos
• Artigo sobre microformatos do Revolução.etc
• Cheat Sheets para consulta de microformatos comuns