Este post é direcionado aos puros de coração que jamais (ou quase nunca) viram HTML e vejamos então porque considero que HTML5 não é apenas HTML5.

Esta linguagem é um conjunto de marcações criado a partir da antiga SGML (Standard Generalized Markup Language), uma distinta senhora que deu à luz nossa conhecida XML. Ou seja, a SGML (que Deus a tenha em um bom lugar) e sua cria XML (eXtensible Markup Language) foram concebidas na intenção de se estruturar textos de modo que uma máquina conseguisse conversar com a outra apenas entendendo o formato.

Isso sempre existiu, mas o interessante foi utilizar um formato humanamente legível. Hein? É o seguinte, eu escrevo um texto e salvo em um arquivo com algumas marcações de início e fim do conteúdo:

<dados>
<noticia id=”1″>
<titulo>HTML5 não é apenas HTML5<titulo>
<data>2012-05-14 17:40:10</data>
<chamada>Ei, tu, vem ler esse post “massa” aqui</chamada>
</noticia>
</dados>

Embora eu tenha usado um formato (vou chamar de sintaxe a partir de agora) estranho para um veterinário ornitólogo, certamente ele é capaz de entender (talvez até seus pacientes sejam capazes de entender).

É essa tal de sintaxe que padroniza as coisas. Assim, um documento XML válido é um mero arquivo de texto que segue as regras dessa sintaxe para expor qualquer conteúdo, em qualquer dialeto. Basta que sigamos seus mandamentos:

- O conteúdo é demarcado por tags, também chamadas nós, que são esses nomezinhos cercados por sinais de menor e maior que.

- Toda marcação é encerrada com o  mesmo nome da tag precedido por uma barra. <tag>Conteudo. Também chamado de corpo</tag>

- As tags são fechadas na ordem inversa de abertura. Não deve haver tag interna fechando depois da externa.

- Tudo deve vir contido em uma tag (nó) raiz, conhecida por document element.

- Tags não precisam ter corpo. Quando não têm, usamos uma barra no fim para indicar isso: <tagsemcorpo />

Existem ainda algumas regrinhas 10 centavos menos simples que eu não tô a fim de citar agora.

Pois bem, o HTML é um dialeto oriundo desse conjunto de regras. Quem escreve um documento HTML escreve (ou deveria escrever), em uma sintaxe válida (documento XML bem formado), um conteúdo dentro de tags que os browsers entendem (ou deveriam entender).

O W3C é o consórcio que nasceu no intuito de por ordem na já existente guerra de navegadores na época de Cabral, Colombo, Netscape e Internet Explorer. #FAIL. O W3C nunca conseguiu a utopia de criar um padrão totalmente aceito e devidamente implementado, e por muito tempo, sequer inovou algo neste padrão. Eu gosto de dividir essa história em 4 etapas:

1. Web Conteudeozóica

Nessa era, os browsers eram meros visualizadores de arquivos HTML sem muita preocupação estética. Eu nasci há 10 mil anos atrás e pude presenciar que nesse tempo cunhou-se o termo página, uma vez que o protocolo HTTP havia sido criado para servir uma “folha” de documento por vez. Naquele tempo, a tag <p> significava parágrafo. Simples assim. <p> não siginificava necessariamente que  haveria uma separação de X pixels do parágrafo atual para o próximo conteúdo da página, apenas que era um parágrafo. O uso de tags sem sentido semântico era muito baixo.

2. Parnasianismo Webial

Nessa era, surgiram os ditos “profissionais” de Web. Eram seres bizarros só preocupados em como o tal conteúdo seria exibido no browser (quem disser que eu era um deles está enganado, eu nego tudo com veemência Malufiana).

O formato valia mais do que o conteúdo. Quem se importava com os cegos? Todo mundo enchia as páginas de imagens (como o famigerado spacer.gif) e outros elementos inacessíveis a buscadores.

Esses alquimistas faziam páginas lindas. A partir do mais tosco e grotesco código-fonte saiam as mais finas flores do campo. Reza a lenda que as páginas eram até cheirosas, embora paradas, estáticas … natureza morta.

A fim de tornar as coisas mais vivas, foram adotados novos (nem tanto) artifícios denominados CSS (cascade stylesheet) e Javascript (aluno meu que chamar de Java leva um potó no olho esquerdo). O primeiro com o intuito de aplicar a estética e o segundo para responder a estímulos do usuário e programar algumas pirotecnias e validações de campos de formulários.

Quando o trio foi devidamente apresentado às sociedades da época, o HTML passou a ser chamado de DHTML (Dynamic HTML) e foi aí que começou todo o problema que quero relatar aqui. O HTML sem Javascript ou CSS não tinha cheiro nem sabor, mas juntando tudo, a trinca passou a se chamar DHTML. Estudar DHTML significava estudar as três irmãs metralha.

2.1 Dinastia Explórica

Após o ataque do Alaska a Vladvostok, os exércitos Azuis da Microsoft deram início ao maior império Web de todos os tempos. O Netscape, então absoluto nos tempos românticos da Web conteudozoicamente acadêmica, aqui definhava até o couro e o osso.

Nessa era parnasianamente esteticóidica, o Rei William (Tio Biu para os chegados) ditava as regras e nós, meros trabalhadores havíamos virado escravos de ferramentas esquisitas como o Macromedia Dreamweaver (brincadeirinha… toda brincadeira tem um fundo de verdade, já dizia minha avó) ou o monstro MS Front-Page, este último é melhor falar baixo pra não invocá-lo das trevas.

Cheguei a usar também Adobe Image Ready e até hoje sofro de problemas psicológicos e alucinações com slices.

Era rowspan=25 (isso, sem aspas mesmo) pra lá, bgcolor pra cá e <font> pra todo lado. Tag <b> (”bold”, negrito em aramaico) que abria em uma célula de uma tabela e nem precisava fechar, bastava fechar a célula da tabela que o IE pegava. O Netscape antigo sequer era capaz de renderizar a tabela se esta não estivesse bem montada.

2.2 O fim de uma era sinistra

Todo montador (nós éramos chamados assim pela sociedade da época … puro bulling) usava tag <td> (”t” de table, “d” de célula … isso mesmo, deve ser por causa do aramaico) pra tudo. Layouts eram sempre feitos com tabelas.

Nessa época, a fundação Mozilla trouxe do jogo do Sonic uma raposa que comeu logo 10% do market-share do IE. O Firefox veio para ser um browser rápido (um dia ele foi o mais rápido sim, pode acreditar), com idéias novas (algumas dizem que foram copiadas do Opera, mas tudo bem, foi por uma nobre causa) e capaz de entender algumas das bizarrices explóricas. Paralelo a isso, os montadores ao redor do mundo se organizavam em guetos e planejavam passeatas em defesa do triunvirato: HTML para conteúdo, CSS para estética e Javascript para programação das funcionalidades. Juntos eles formavam o Capitão Planeta.

3. Modernismo HTEmiélico

Finalmente o conteúdo passou a ser mais importante do que a forma. Os cegos começaram timidamente a enxergar a Web e o Google capitaneou uma revolução silenciosa em busca do melhor uso das tags semânticas como <h1>, <h2>, <p>, <th>, <ul>, <ol>, etc.

3.1 A promiscuidade dos browsers

A guerra desenfreada de browsers já havia os transformado em máquinas trituradoras de arquivos bem ou até mal formados.

Chrome e Safari foram dois bólidos montados a partir do mesmo layout engine, o WebKit. Layout Engines, ou simplesmente engenhos são o coração do interpretador HTML do browser. Por exemplo, IE-Trident, Firefox-Gecko, Opera-Presto são como RedBull-Renault ou McLaren-Mercedes da Fórmula 1. O Chrome e o Safari são fabricados até hoje com o mesmo motor WebKit embora com pequenos ajustes pra cada lado.

Diga-se de passagem, a história dos layout engines merecia um capítulo à parte. A assinatura de um Chrome hoje é praticamente o nome de D. Pedro I.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/535.19 (KHTML, like Gecko)Chrome/18.0.1025.168 Safari/535.19 é o nome do Chrome 18 no Mac. Veja nas palavras em negrito a quantidade de menções aos concorrentes.

3.2 A ditadura do W3C

O W3C, tão ovacionado por todos nós até então, resolveu pôr as manguinhas de fora e mostrar que nem era assim tão santo. Acabou com a HTML e seu pseudônimo DHTML e decretou que os browsers a partir dali deviam suportar a XHTML (XML + HTML). O que é isso companheiro? A HTML já não era um dialeto escrito em XML? Todo documento HTML já não seria um documento XML bem formado? A resposta é quase.

O W3C lançou um pacote de austeridade econômica denominado Web Standards. Nele, toda tag de cunho estético foi banida da HTML. O mesmo para certos atributos das tags preexistentes como os cellpadding e cellspacing das tabelas. Aliás, muita gente indevidamente achou que deveria matar as tabelas também, o termo tableless virou cool e muito conteúdo tabular por aí passou a ser montado sobre dezenas de divs. Pura arte cubista que fez os sites precisarem ser testados exaustivamente nos 5 browsers mais populares.

O plano do W3C foi perverso. Todas as furiosas regras XML recaíram sobre incautos documentos HTML. Tags que não possuíam corpo precisavam da barra final. Ex.: <br> deveria ser <br />. Todo atributo deveria ser escrito como nome=”valor entre aspas”, etc. Todo XHTML precisava definir uma marcação inicial denominada DOCTYPE. No XML, DOCTYPEs servem documento validadores do dialeto usado no seu documento XML.

Como diria Virgulino: “Se eu entendi, eu cegue!”

Ora, XMLs são documentos com quaisquer tags, basta que o escritor e o leitor conheçam o dialeto (quais tags podem vir onde e quando) para se dar a comunicação. DOCTYPEs são declarações que apontam para documentos de definição (DTDs). Estes por sua vez dizem: “…essa tag vem aqui, dentro dela só pode ter essa ou essa, primeiro vem aquela, etc e tal…”.

Leitores XML sempre se valeram dos DTDs (mais modernosamente dos XML Schemas) para validar o documento antes de tentar ler. Eles servem de garantia de grafia do documento. Acontece que os escritores dos HTMLs sempre fomos nós e os leitores HTML sempre foram os browsers. As tags sempre foram praticamente as mesmas. Nenhum browser seria maluco de executar uma rotina de validação antes de começar a interpretar nossos documentos para não perder tempo.

No entanto, por um lado, o plano W3Cêico deu certo. O Google agradeceu a melhor organização média das páginas Web que seguiram os Web Standards e os browsers começaram a ser mais rígidos e padronizados. Eles utilizaram os DOCTYPEs não para validar mas para definir seu nível de comportamento. Ou seja, “se um documento vier sem DOCTYPE eu vou ler como eu sempre o li, se ele vier com o DOCTYPE XHTML Transitional eu vou passar a exigir algumas regras de boa formatação, se for XHTML Strict eu vou ligar minha rigorosidade no talo”.

3.3 RIA W3C RIA

Apesar da melhora desta fase da Web, todo mundo estava incomodado com a pobreza dos Web Standards. A DHTML havia trazido mais riqueza em sua época, mas a XHTML focou apenas em rigidez sintática e melhor aplicação semântica das marcações existentes.

Enquanto o W3C dormia em berço esplêndido, o mundo já discutia as novas mágicas Javascrípticas como a AJAX, requisições que os browsers faziam aos servidores Web se atualizar a página. Aliás, o próprio termo página ficou defasado. Os projetos Web agora são programas. O mundo viu emergir os softwares como serviço e a HTML naturalmente deveria ser a linguagem padrão dessa evolução.

O termo RIA (Rich Internet Application) foi exaltado pela Adobe para aplicativos Web que usavam Flash, mas passou também a abranger a trinca XHTML+CSS+Javascript.

Bibliotecas como a jQuery, YUI e ExtJS surgiram e se fortaleceram para simplificar o trabalho muitas vezes tedioso de se constuir RIA usando Javascript. O CSS até que evoluiu e muita coisa melhorou em sua versão 3.

Mesmo assim, dois gigantes ainda hibernavam, o próprio W3C que não inovou praticamente nada e a Microsoft.

Isso mesmo, a Microsoft. Há duas teorias para fato do Internet Explorer ter se tornado o ser mais odiado do planeta. A primeira mais realista é de pura falta de feeling da empresa líder do mercado que achou que nada abalaria seu belo produto. A segunda mais fantasiosa fala até que a Microsoft não queria a evolução da RIA e do software como serviço, pois pense bem, se todo programa rodasse na Web, ela seria a plataforma necessária e não mais o Windows.

4. Semântica pós-moderna

Conspirações à parte, a Mozilla (Gepeto do Firefox), a Opera, a Apple e a Google se cansaram do W3C e fundaram uma sociedade maçônica denominada WhatWG para dominar o mundo. Eles queriam obviamente aumentar seu market-share, fatiando o mercado do IE, mas principalmente, queriam que a Web evoluísse.

As marcações deveriam ser mais semânticas. Ou seja, queremos saber se no meio do conteúdo tem um telefone, um endereço de uma empresa e não apenas que ali é um parágrafo. Isso é muito genérico. Movimentos como os do RDFa e Microformats foram absorvidos no novo Microdata e diversas novas tags surgiram.

4.1 HTML em sua versão 5 e a HTML5

A XHTML não trouxe a semântica almejada, mas sim uma carga de rigidez que tornou os projetos Web mais enfadonhos. Seria interessante diminuir esse rigor. A WhatWG propôs então a ressurreição da HTML. Esta havia morrido na versão 4 para dar lugar à XHTML, então naturalmente sua versão foi chamada de 5.

Ela trouxe novas tags estruturais como <header>, <section>, <article>, <footer>, novas marcações semânticas como <progress>, <meter> e <figure>, suporte sem plugins a áudio e vídeo, suporte a imagens inline vetorias (<svg>) e bitmaps (<canvas>), novos atributos para simplificar tarefas corriqueiras como o placeholder.

Enfim, a HTML em sua versão 5 foi uma revolução HTEmiélica de conteúdo Web.

No entanto, é necessário contextualizar que há muitas gerações que ninguém trabalha apenas com HTML, mas com a tríplice coroa HTML+CSS+Javascript. Como as novidades não vieram apenas na HTML, a CSS já estava em fase avançada de adoção de sua versão 3 pelos browsers e a Javascript há muito que ninguém sabia mais qual a versão exata dela, todo o conjunto de novidades ficou sob o guarda-chuva HTML5.

Em outras palavras, tanto a CSS3 quanto gigantesca melhoria no Javascript (Web Workers, Websockets, geolocation, Session storage, manipulações do canvas, do audio e do vídeo, etc, etc, etc, etc e bote etc nisso) ficaram dentro do assunto HTML5.

Toda essa história foi para dizer que a HTML5 virou padrão W3C, um padrão que deverá ser oficializado em 2014 mas que já é amplamente suportado pelos browsers (até pelo IE, embora ainda estejamos ansiosos para ver o IE 10, uma vez que o 9 deixou muito a desejar).

A nomenclatura HTML5 é hoje dada ao trio e não apenas ao conteúdo HTML.

O aluno que me fez escrever esse texto até as 4:27 da manhã havia me falado sobre um comentário reverberado no encontro Pernambuco.js que ocorreu no mês passado (que infelizmente não pude prestigiar): “Ninguém pode dizer que sabe HTML5 sem saber Javascript”.

Dependendo do ponto de vista, concordo plenamente com a frase, mas isso até atrapalhou esse que então ainda não era meu aluno e o fez pensar em estudar Javascript antes de estudar HTML.

Portanto lembre-se HTML5 não é apenas HTML em sua versão 5.

Ao atingir 500 milhões de usuários o FaceBook prova que o PHP é um sistema sólido, leve e seguro. Afinal, como disse a equipe do FaceBook ao Alemão Sebastian Bergmann, que faz parte da equipe do PHPUnit, um bug que atinja 1% dos usuários do FB (FaceBook), atinge na verdade 5 milhões de pessoas. Então o FB é a prova viva de que podemos sim, ter um sistema seguro, robusto, leve e acessível em PHP.

Fomos a primeira empresa no Brasil a preparar para a certificação oficial Zend, na época para o PHP 4. Nossos módulos anteriores certamente somam um dos melhores e mais completos cursos de  PHP do nosso país. Em Recife simplesmente não há comparação.

Mas o que era bom não poderia ficar obsoleto. Após esses 5 anos de sucesso absoluto, tivemos a ousadia de atualizar seu formato para atender às necessidades atuais e contemplar melhor os novos recursos da linguagem.

Clique abaixo e confira todas as novidades.

Iniciamos nossos treinamentos em meados de 2005, exatamente com uma turma do então curso PHP Avançado. Logo criamos a suíte de cursos que contava com os módulos PHP Programmer (básico), PHP Developer (avançado) e PHP Certified Engineer (preparatório para a Zend Certified Engineer – PHP 4 Certification). Após a atualização da prova para contemplar a versão 5, ajustamos nosso módulo preparatório e pouco depois percebemos que seria interessante criar o módulo PHP Expert antes dele.

Seguimos uma filosofia que vem dando muito certo e podemos dizer que o PHP foi o laboratório deste formato também adotado em outros cursos preparatórios como Java e LPI. Primeiro ensinamos em módulos práticos, voltados ao dia-a-dia do profissional. Neles, todo o assunto da prova é abordado, além de assuntos que são importantes mas não são requisitados por ela. Só então o aluno ingressa no preparatório para certificação, com certamente muito mais confiança em seus conhecimentos.

Hoje, contamos com um Grupo de Estudos de altíssimo nível com alunos, ex-alunos, professores e demais interessados na linguagem.

Confira abaixo o que mudou em cada módulo:

PHP Programmer

Sem dúvida é difícil mexer em um dos cursos mais importantes que temos. Aqui, não tratávamos de orientação a objetos, mas percebemos que ela já se faz presente em praticamente todas as empresas que desenvolvem softwares em PHP. Além disso, desde o PHP 5.0, toda e qualquer nova API é escrita orientada a objetos.

Resolvemos aumentar a carga-horária para antecipar conceitos como o que são objetos, classes, atributos, métodos e como é interessante usufruir de recursos OO como o PHPMailer para envio de emails, PDO para abstração de SGBDs.

Duração: 45 horas.

PHP Developer

Neste módulo, ensinamos como modelar um sistema orientado a objetos e trouxemos muita coisa do Expert. Chegamos a desenvolver um framework MVC simples montado sobre funcionalidades como reescritas de URLs via .htaccess com ModRewrite, expressões regulares, internacionalização, reflection e muito mais.

Abordamos o Doctrine 2.0, um fantástico sistema de mapeamento objeto relacional. Discutimos padrões de projeto e arquitetura.

No final, o clássico projeto da nossa Loja Virtual ganhou um roupagem nova e resolvemos abordar geração de boletos bancários.

Duração: 48 horas

PHP Expert

Esse é o nosso laboratório de novas funcionalidades. Foi aqui que primeiramente citamos novas funcionalidades do PHP 5.3 como namespaces e closures (hoje assuntos de módulos anteriores). Focamos no estudo de Web Services, apresentando primeiro como funcionam os Sockets TCP e como trabalhar com documentos XML. Utilizamos Web Services para buscar serviços conhecidos de redes sociais como o Twitter e o Facebook.

Introduzimos e discutimos como o PHP se integra com interfaces ricas Flex e Ajax. Tudo bem, deixamos o gostinho para que quem quiser se aprofundar em nossos cursos específicos. Vemos ainda a geração de binários como imagens, documentos PDF e a alimentação de documentos XML utilizados pela biblioteca de relatório gráfico em flash Fusion Charts.

Duração: 48 horas

PHP Certified Engineer

Para este módulo, elaboramos questões no nível da prova e realizamos simulados do decorrer das aulas. Também foi ampliado para melhor atender.

Duração: 40 horas

Fizemos tudo isso, pensando em lhe oferecer o que há de melhor em cursos de PHP. Mas, se você tem alguma critica ou sugestão de formato, pode descer a lenha nos comentários abaixo.

Confira tudo sobre os novos cursos aqui.

Com a constante sugestão de alguns frameworks MVC populares em usar outros engenhos de templates em detrimento do padrão JSP, como Velocity ou FreeMarker, e ainda, desde o Java EE 5.0, com a inserção do JSF, que nunca se deu muito bem com JSP, a pergunta foi, será que o JSP ficou obsoleto? Agora no Java EE 6.0, o Facelets virou padrão e a própria documentação oficial que saiu agora em Junho quase esqueceu de falar de JSP. Seria JSP Já Se Phoi? (E se foi com pê-agá).

Clica aí no leia mais pra gente discutir esse assunto.

No princípio era o verbo, digo: o socket. Em nossas turmas de Java Developer, falamos sobre esse fundamento da programação distribuída. Como duas máquinas conseguem se comunicar em uma rede, preferencialmente via TCP/IP. Sempre acreditei que isso fosse interessante para quem ainda vai estudar Java para Web, porque podemos criar um exemplo construindo o browser e o servidor Web. Claro que o foco não é a reinvenção da roda, mas a discussão sobre a necessidade de um protocolo de comunicação que diga quem escreve e quem lê e qual o formato da escrita para que a comunicação se dê plenamente.

No Java Enterprise, existe a figura do servidor Web, como o nosso conhecido Apache Tomcat. A função dele é responder à onipresente outra figura que não necessariamente é escrita em Java, o browser, conhecendo plenamente o protocolo HTTP (obviamente que bem mais aprofundado do que no nosso curso Java Developer) e já entendendo que deve criar um objeto Java e chamar um método específico seu de acordo com a URL da requisição. Para os que já sabem disso, é aquela história do arquivo web.xml mapear um <url-pattern> para alguma <servlet> e a chamada ao método service() da servlet, que se for subclasse de HttpServlet, vai direcionar a requisição para um método como doGet(), doPost(), etc, de acordo com o método de requisição.

Para quem vem dessa linha, ou seja, quem aprendeu a programar em Java standalone, depois em rede, em rede com respostas concorrentes e finalmente caiu na Web, as Servlets são algo bem simples e interessante. No entanto, para quem aprendeu primeiro o HTML para criação de páginas estáticas, sabe como navegar na Internet e pretende tornar seu site mais dinâmico, ter que aprender Servlet pode não ser a coisa mais instigante da face da Terra.

O JSP entra justamente nessa lacuna. Fornecendo a capacidade de se escrever uma página HTML onde o programador (ou mesmo o designer) pode adicionar tags  <% e %> (e algumas variações que não vou entrar no mérito) e inserir assim conteúdo dinâmico à página. O problema é que mesmo quem nunca viu uma Servlet mais gorda na vida, vai acabar querendo escrever códigos de programação mais densos dentro dessas tags, conhecidas como scriptlets. O que vai acabar construindo um código que fora é HTML, dentro é Java. E esse Java acessa banco de dados, aplica regras de negócio, controla navegação, itera sobre resultados, enfim, faz tudo junto e misturado. Daí o termo código macarrônico.

Surgiram então soluções como JSP EL e JSTL que, juntas, dão mais cara de HTML e menos de Java aos códigos JSP e resolvendo detalhes como não precisar chamar get/sets dos objetos e misturar os escopos dos atributos setados na requisição, na sessão e na aplicação (engraçado, isso em PHP é visto como algo ruim, vai entender …).

O problema é que o JSP não se adequa muito bem ao mecanismo de alguns frameworks MVC e foi preterido pelos Struts I e II, por exemplo. Com JSF, a coisa foi ainda pior. O JSP não se encaixa no ciclo de vida de um componente JSF, o que torna as coisas mais lentas quando não dão erro. Um exemplo de erro é quando usamos a tag <c:forEach> do JSTL com tags JSF dentro. Se no interior dela inserirmos alguma tag com o atributo Id, a página não será renderizada quando houver mais de uma iteração da coleção varrida pelo <c:forEach>. No código abaixo:

<c:forEach items="#{meuBean.itens}" var="meuItem">
    <h:inputText id="elemento" value="#{meuItem.nome}"/>
</c:forEach>

Quando itens, uma coleção de qualquer coisa de meuBean tiver mais de um item adicionado, a página vai dar erro. Isso ocorre porque o JSP é processado antes. Quando chegar a fase JSF de renderização da página, o JSP terá sido executado e gerado duas linhas inputText com o mesmo id.

Já no código abaixo:

<h:dataTable value="#{meuBean.itens}" var="meuItem">
    <h:column>
        <h:inputText id="elemento" value="#{meuItem.nome}" />
    <h:column>
</h:dataTable>

Refizemos a mesma coisa usando apenas tags JSF. Aqui, tudo é executado no mesmo momento, chegando apenas um id elemento.

Na nova documentação oficial do Java EE 6.0, há uma passagem no mínimo curiosa:

“JSP is considered as a deprecated presentation technology for JavaServer Faces 2.0.”

Claro, não estou negando o fato de que nem sempre você vai precisar do JSF. Nesses momentos o JSP pode lhe atender. Enfim, o que acho estranho é o fato de depois de grandes investimentos sobre o JSP ele estar sendo resumido a pequenos códigos uma vez que se vende o JSF para aplicações corporativas. Fica a dúvida sobre o que fazer quando utilizarmos JSP em um projeto mais simples que depois se torne um grande sistema. Devemos trocar todo o legado por JSF+Facelets, manter o JSP mesmo que menos integrado com o background corporativo gerando um custo de manutenção mais elevado ou misturar os dois e investir em uma combinação considerada oficialmente obsoleta?

Posso mudar de opinião amanhã, mas pra mim JSP Já Se Phoi.

O que são transações?

Transações são conjuntos de instruções enviadas ao banco de dados que devem ser tratadas com uma única operação. Ou o servidor realiza tudo ou não realiza nada. O exemplo clássico usado em 110% dos cursos de bancos de dados é a famosa transação financeira de transferência de fundos. Imagine que Mônica deseje transferir 100,00 reais para a conta de Cebolinha. Esta operação na realidade se divide em duas. Um débito na conta de Mônica e um crédito de mesmo valor na conta de Cebolinha (a ordem não interfere). Agora, se logo após o débito na primeira conta, o servidor sair do ar antes de que possa executar a segunda. Para onde foram os 100,00 reais?

Existem quatro características que os SGBDs devem garantir se pretendem lidar com transações com segurança. O conjunto dessas características é conhecido como ACID (atomicity, consistency, isolation, durability). Vejamos o que significam:

Atomicidade

É o ponto chave. É quem determina o tudo-ou-nada. A comunidade científica por longos anos acreditou que um átomo seria a unidade mínima da matéria, sólido e indivisível. Já se sabe em simples aulas de química que essa idéia caiu há séculos. No entanto, este conceito serve de analogia para ocasiões onde deve se considerar a impossibilidade de dividir algo em unidades menores.

Sendo assim, a atomicidade é a característica que torna um conjunto de operações um agrupamento indivisível executado por completo ou nada feito.

Consistência

Esta característica determina que o SGBD deve iniciar uma transação em um estado consistente e terminá-la deixando os dados em outro estado consistente. Caso alguma ação dentro de uma transação dê problemas e fira alguma regra de consistência de dados (como uma falha de escrita em disco, por exemplo), toda a transação deve ser completamente abortada, deixando os dados em seu estado consistente imediatamente anterior. O ato de abortar e voltar ao ponto inicial é conhecido como ROLLBACK.

Inconsistências não se resumem a problemas físicos de dados. É possível encarar uma situação fisicamente consistente como logicamente inconsistente. No exemplo dos desaparecimento dos 100,00 reais, o banco ficou em um estado inconsistente uma vez que se somarmos os saldos nas duas contas, independentemente do valor transferido os resultados pré e pós transferência deveria dar consistentemente o mesmo.

Isolamento

Esta característica remete a acessos concorrentes. Caso apenas uma transação seja executada no SGBD em determinado intervalo de tempo, o isolamento não vai lhe acrescentar nada. No entanto, como sabemos que SGBDs, na maioria dos casos, são usados por sistemas concorrentes, esta característica entra para garantir que informações de uma transação não se misturem com de outras.

Esta é a única característica relativa das quatro. Ou seja, é a única que não necessariamente é ruim quando infringida de alguma forma. Por um lado, seria ruim dados de uma transação estarem visíveis a outras como no problema clássico conhecido como Dirty Read que ocorre quando uma transação tx1 modifica alguns registros, uma transação tx2 ao selecionar alguns dados, visualiza esses registros alterados por tx1, mas esta primeira é abortada por alguma razão. Em resumo, tx2 leu dados errados, uma vez que eles nunca deveriam ter sido alterados.

Por outro lado, a capacidade de trabalhar com múltiplas transações ao mesmo tempo pode garantir o bom desempenho em sistemas muito acessados, uma vez que uma não fica esperando pela conclusão da outra. Elas são implementadas em ambientes multi-processos ou multi-threads e podem explorar melhor o pontencial multi-core dos hardwares atuais.

Durabilidade

Toda transação é encerrada com a execução da ação COMMIT. Esta característica é a garantia dada pelo SGBD que quando retornar um sinal COMMIT, os dados já devem estar gravados no meio persistente e ele deve ser capaz de recuperar esses dados em transações posteriores. Caso haja algum problema, a transação deve ser abortada. Conforme a regra da consistência, caso não haja problemas, o banco está jurando de pés juntos que gravou e você vai poder ler depois.

Como tratado no capítulo 1, o PostgreSQL escreve em disco registros de log WAL e assim que estejam completamente escritos, retorna o sinal COMMIT. Já no capítulo 2, tratamos das diretivas do postgresql.conf fsync e wal_sync_method. Para recapitular, a primeira faz com que o SGBD após a execução do comando de escrita do segmento WAL realize consultas ao sistema operacional a fim de obter a garantia de que o valor escrito está completamente descarregado no disco. Já a segunda determina o método adotado nesta pesquisa. Desligar a diretiva fsync pode proporcionar um maior desempenho, mas o risco da falta de durabilidade de uma transação “commitada” em geral não faz valer a pena esse tuning desesperado.

O método de sincronização com o disco de segmentos WAL (wal_sync_method) padrão do Linux é o fdatasync. O método fsync aguarda o sistema operacional descarregar em disco toda a pilha do buffer de I/O e atualizar o inode do sistema de arquivos com a informação de última alteração do arquivo escrito. O fdatasync não espera pela atualização deste metadado. Ele se preocupa apenas com o que mais importa que é a atualização propriamente dita dos dados.

Transações e Write-ahead Logging

Ao confirmar cada transação, o servidor não registra em disco as páginas de dados (aqueles 8Kb que ficam na memória). É bem menos custoso registrar neste momento (e esperar pelo fsync), um registro de segmento WAL uma vez que ele é linear (alterações na base real podem envolver dados que não necessariamente estejam na mesma página de dados) e por isso realizam movimentos menores da controladora de disco, além de não requerer pesquisa por espaço livre (FSM).

Por outro lado, a manipulação das páginas de memória compartilhada que são carregadas do e para o disco é bem mais vantajoso do que sair vasculhando registros de log de operações a fim de obter os dados necessários nas consultas.

Sendo assim, o PostgreSQL precisa realizar essa tradução do que é salvo em log para as páginas de dados de tempos em tempos. Este processo de escrita em background (bgwriter) é denominado CHECKPOINT. No PostgreSQL, checkpoints não têm ligação direta com o COMMIT de uma transação, mas achei interessante ilustrar o que deve ocorrer com algumas transações confirmadas entre um checkpoint e um provável crash da base.

O vídeo abaixo mostra o que ocorre com 5 transações considerando que em um momento distinto haverá uma ação de checkpoint e posteriormente haverá um crash do servidor, provocando sua queda inesperada. Caso você não consiga ver o vídeo, clique para baixá-lo em Ogv (theora) ou MP4 (H.264).

Problemas de isolamento

Transações já são interessantes mesmo em cenário standalone, uma vez que é possível desfazer todo um bloco de procedimentos apenas com um simples Rollback. Mas é em sistemas concorrentes que o bicho pega. Caso o isolamento não seja garantido alguns problemas podem ocorrer.

Dirty read

O primeiro deles já foi apontado. Dirty Read ou leitura suja acontece quando uma transação lê algum dado alterado por outra que acaba não confirmando suas alterações. É um problema extremo que de fato não é comum que bancos de dados permitam que ocorra. O PostgreSQL não permite. Confira no exercício abaixo. Primeiramente, vamos criar a base para os testes:

postgres=# CREATE DATABASE exercicio;
CREATE DATABASE
postgres=# \c exercicio
You are now connected to database "exercicio".
exercicio=# create table aluno (id serial primary key, nome varchar(50));
NOTICE:  CREATE TABLE will create implicit sequence "aluno_id_seq" for serial column "aluno.id"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "aluno_pkey" for table "aluno"
CREATE TABLE
exercicio=# INSERT into aluno (nome) values ('Huguinho'), ('Zezinho'), ('Luisinho'), ('Juquinha'), ('Joaozinho');
INSERT 0 5

Criamos 5 alunos (só peça boa =) em uma nova base. Agora vamos ao primeiro cenário. Para isto será necessário que você abra duas instâncias do psql ou qualquer outra ferramenta cliente (que certamente não será tão limpa e cheirosa quanto o psql).

Inicie uma transação em cada uma executando em ambas a instrução:

exercicio=# begin;
BEGIN

Na primeira, execute o seguinte comando:

exercicio=# UPDATE aluno set nome = 'Jose da Silva' where id = 2;
UPDATE 1

exercicio=# select * from aluno;
id |     nome
----+---------------
1 | Huguinho
3 | Luisinho
4 | Juquinha
5 | Joaozinho
2 | Jose da Silva
(5 rows)

Veja que o nome de Zezinho agora é Jose da Silva.

Realize a mesma consulta na segunda instância do psql:

exercicio=# select * from aluno;
id |   nome
----+-----------
1 | Huguinho
2 | Zezinho
3 | Luisinho
4 | Juquinha
5 | Joaozinho
(5 rows)

Como você atentou, os alunos continuam com seus nomes intactos. O que a primeira transação modificou não foi sentido pela segunda. O motivo é que se a primeira voltar atrás, a segunda já teria lido e tomado suas próprias decisões baseando-se em dados inconsistentes. Confira como faríamos para reverter (execute na primeira transação):

exercicio=# ROLLBACK ;
ROLLBACK
exercicio=# select * from aluno;
id |   nome
----+-----------
1 | Huguinho
2 | Zezinho
3 | Luisinho
4 | Juquinha
5 | Joaozinho
(5 rows)

Nossa base voltou ao estágio em que estava no momento do BEGIN.

Unrepeatable Reads

Leituras não repetíveis acontecem quando uma transação lê algum dado em determinado momento, posteriormente outra transação altera ou deleta e executa o COMMIT. A primeira volta a ler os mesmos dados e constata que eles não estão mais como antes. Este não chega a ser um problema em muitos sistemas, a ponto do PostgreSQL, em seu nível de isolamento padrão, permitir que ocorra. Vejamos:

PSQL1: Iniciamos uma nova transação (aquela anterior foi desfeita com ROLLBACK) e atualizamos novamente o nome de Zezinho.

exercicio=# BEGIN ;
BEGIN
exercicio=# UPDATE aluno set nome = 'Jose da Silva' where id = 2;
UPDATE 1

PSQL2: Como visto antes, nada foi percebido pela outra transação.

exercicio=# select * from aluno;
id |   nome
---+-----------
1 | Huguinho
2 | Zezinho
3 | Luisinho
4 | Juquinha
5 | Joaozinho
(5 rows)

PSQL1: Confirmamos a alteração

exercicio=# COMMIT ;
COMMIT

PSQL2: Agora a alteração foi sentida

exercicio=# select * from aluno;
id |     nome
---+---------------
1 | Huguinho
3 | Luisinho
4 | Juquinha
5 | Joaozinho
2 | Jose da Silva
(5 rows)

Phantom Read

O problema das leituras fantasmas é parecido com o das leituras não repetíveis, o que muda é que uma das transações em vez de alterar o conjunto de dados, insere um dado novo.

Vamos refazer a dinâmica. Primeiramente, encerre as transações das duas instâncias do psql. Neste momento, tanto faz encerrar com COMMIT ou com ROLLBACK. Se a transação não estiver em curso, você receberá uma mensagem como esta:

WARNING:  there is no transaction in progress

PSQL1: Inicie a transação e insira duas novas alunas

# begin;
BEGIN
exercicio=# INSERT INTO aluno (nome) values ('Chiquinha'), ('Mariazinha');
INSERT 0 2

PSQL2: Inicie a transação e consulte a lista de alunos

# begin;
BEGIN
exercicio=# select * from aluno;
id |     nome
----+---------------
1 | Huguinho
3 | Luisinho
4 | Juquinha
5 | Joaozinho
2 | Jose da Silva
(5 rows)

Ninguém novo até agora.

PSQL1: Confirme sua transação com um COMMIT

exercicio=# COMMIT ;
COMMIT

PSQL2: Veja que as novas alunas agora estão presentes

exercicio=# select * from aluno;
id |     nome
----+---------------
1 | Huguinho
3 | Luisinho
4 | Juquinha
5 | Joaozinho
2 | Jose da Silva
6 | Chiquinha
7 | Mariazinha
(7 rows)

Níveis de isolamento

Existem quatro níveis de isolamento segundo o padrão SQL:

READ UNCOMMITED

Nível menos isolado. Aqui, todos os problemas citados podem ocorrer, inclusive as porcas dirty reads. É muito difícil um SGBD permitir que o DBA mesmo que deliberadamente configure o nível de isolamento para READ UNCOMMITED. Em resumo, é um nível acadêmico, apenas para você dizer que conhece.

READ COMMITED

Nível padrão do PostgreSQL. Aqui dirty reads estão barradas, mas, como verificamos nos exercícios anteriores, unrepeatable reads e phantom reads podem ocorrer.

REPEATABLE READ

Neste nível, apenas as phantom reads podem ocorrer. Os SGBDs fazem bloqueio (lock) do conjunto de dados lidos em uma transação, o que evita que as leituras posteriores apresentem resultados modificados ou deletados confirmados por outra transação. No entanto, não há como fazer lock de um registro que ainda não existia na primeira leitura. Este é o motivo pelo qual as leituras fantasmas podem assombrar por aqui.

SERIALIZABLE

Esse é o nível que leva o isolamento ao máximo. Aqui, nenhum desses problemas podem ocorrer.

Em resumo:

A tabela abaixo mostra os níveis de isolamento em relação aos problemas que podem ou não provocar.

Para modificar o nível de isolamento da transação corrente, existe o comando SET TRANSACTION que deve ser executado logo após o BEGIN e antes de qualquer consulta SELECT, INSERT, DELETE, UPDATE, FETCH ou COPY. Este comando possui o seguinte formato:

SET TRANSACTION [ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED } ]  [ {READ WRITE | READ ONLY} ]

Com ele, é possível determinar o nível de isolamento, escrevendo ISOLATION LEVEL seguido por algum dos níveis já apresentados e/ou informar as opções READ WRITE (padrão) ou READ ONLY. Transações READ ONLY (somente leitura) não podem alterar nenhuma tabela que não seja temporária.

Vamos a um exemplo:

exercicio=# begin;
BEGIN
exercicio=# set transaction read only;
SET
exercicio=# UPDATE aluno SET nome = 'teste';
ERROR:  cannot execute UPDATE in a read-only transaction
exercicio=# select * from aluno;
ERROR:  current transaction is aborted, commands ignored until end of transaction block
exercicio=# rollback;
ROLLBACK

Após o BEGIN, determinamos que nossa transação seria somente leitura. Logo após, tentamos infringir o determinado em SET TRANSACTION executando um UPDATE qualquer. Confira o erro resultante. Segui adiante para mostrar algo que ainda não havia falado, mas ocorre sempre que uma instrução retorna erro dentro de uma transação. Qualquer nova instrução retorna o erro informando que a transação foi abortada. Cabe-nos apenas executar o ROLLBACK para encerrar a transação problemática.

O nível de isolamento REPEATABLE READ no PostgreSQL é encarado como um SERIALIZABLE, ou seja, não permite leituras fantasmas. Vejamos:

PSQL1: Determinando o nível de isolamento para REPEATABLE READ, que no PostgreSQL funciona como um SERIALIZABLE

exercicio=# BEGIN ;
BEGIN
exercicio=# SET transaction ISOLATION LEVEL REPEATABLE READ ;
SET
exercicio=# select * from aluno;
 id |     nome
----+---------------
 1 | Huguinho
 3 | Luisinho
 4 | Juquinha
 5 | Joaozinho
 2 | Jose da Silva
 6 | Chiquinha
 7 | Mariazinha
(7 rows)

PSQL2: Inserindo um novo aluno e confirmando a transação

exercicio=# BEGIN ;
BEGIN
exercicio=# INSERT INTO aluno (nome) values ('Maradona');
INSERT 0 1
exercicio=# COMMIT ;

PSQL1: Olha aí que Maradona ainda não foi inserido e não é porque ele é argentino. Após a confirmação deste transação, ele vai aparecer. Só espero que não estrague a festa.

exercicio=# select * from aluno;
 id |     nome
----+---------------
 1 | Huguinho
 3 | Luisinho
 4 | Juquinha
 5 | Joaozinho
 2 | Jose da Silva
 6 | Chiquinha
 7 | Mariazinha
(7 rows)

exercicio=# COMMIT ;
COMMIT
exercicio=# select * from aluno;
 id |     nome
----+---------------
 1 | Huguinho
 3 | Luisinho
 4 | Juquinha
 5 | Joaozinho
 2 | Jose da Silva
 6 | Chiquinha
 7 | Mariazinha
 8 | Maradona
(8 rows)

O nível de isolamento READ UNCOMMITED é encarado como um READ COMMITED (o padão). Assim, leituras sujas jamais são permitidas, no PostgreSQL.

Controle de versão

Ao contrário de alguns bancos de dados, o PostgreSQL por padrão trabalha com controle de versão ao invés de bloqueio de dados na manipulação de transações. Este mecanismo, conhecido como MVCC (multi-version concurrency control) costuma ser bem mais eficiente em termos de desempenho em comparação aos bloqueios de registros que já são bem melhores do que os bloqueios de tabelas. Além do PostgreSQL, bancos como Oracle, Firebird, HiperSonic, SyBase, ZODB, entre outros também se baseiam no MVCC para controle de isolamento de transações.

Para cada registro de cada tabela sempre existem dois campos utilizados no controle de transações. O campo xmin informa o id (auto-sequenciado) da transação que gerou este registro. Já xmax determina o id da transação que a deletou ou alterou seu conteúdo, gerando um novo registro com xmin atualizado. Para ilustrar como funciona o controle, vejamos o exemplo:

PSQL1:

exercicio=# BEGIN ;
BEGIN
exercicio=# select *, xmin, xmax from aluno;
id |     nome      | xmin | xmax
---+---------------+------+------
 1 | Huguinho      |  664 |    0
 3 | Luisinho      |  664 |    0
 4 | Juquinha      |  664 |    0
 5 | Joaozinho     |  664 |    0
 2 | Jose da Silva |  668 |    0
 6 | Chiquinha     |  669 |    0
 7 | Mariazinha    |  669 |    0
 8 | Maradona      |  670 |    0
(8 rows)

exercicio=# DELETE FROM aluno WHERE nome = 'Maradona';
DELETE 1
exercicio=# select *, xmin, xmax from aluno;
 id |     nome      | xmin | xmax
----+---------------+------+------
 1 | Huguinho      |  664 |    0
 3 | Luisinho      |  664 |    0
 4 | Juquinha      |  664 |    0
 5 | Joaozinho     |  664 |    0
 2 | Jose da Silva |  668 |    0
 6 | Chiquinha     |  669 |    0
 7 | Mariazinha    |  669 |    0
(7 rows)
exercicio=# UPDATE aluno SET nome = 'Zezinho' where id = 2;
UPDATE 1
exercicio=# select *, xmin, xmax from aluno;
 id |    nome    | xmin | xmax
----+------------+------+------
 1 | Huguinho   |  664 |    0
 3 | Luisinho   |  664 |    0
 4 | Juquinha   |  664 |    0
 5 | Joaozinho  |  664 |    0
 6 | Chiquinha  |  669 |    0
 7 | Mariazinha |  669 |    0
 2 | Zezinho    |  671 |    0
(7 rows)

No primeiro SELECT, podemos visualizar o xmin de cada registro. Perceba que Jose da Silva possui um xmin maior do que os outros alunos que foram inseridos no mesmo momento. Isto se deve aos UPDATEs que executamos nos exemplos posteriores ao primeiro INSERT.

Realizamos um DELETE para excluir Maradona de onde ele não foi chamado. O SELECT posterior não tem como vê-lo uma vez que o xmax é justamente o id da transação atual. Após um UPDATE para voltarmos com o nome Zezinho do aluno 2, e eis que surgiu um registro no fim da fila com id de transação maior do que todos. O registro com Jose da Silva também não está mais visível aqui.

Agora vamos a uma outra transação antes de confirmação as alterações na atual.

PSQL2: Selecionando os registros em outra transação antes do COMMIT da anterior

exercicio=# SELECT *, xmin, xmax FROM aluno;
 id |     nome      | xmin | xmax
----+---------------+------+------
 1 | Huguinho      |  664 |    0
 3 | Luisinho      |  664 |    0
 4 | Juquinha      |  664 |    0
 5 | Joaozinho     |  664 |    0
 2 | Jose da Silva |  668 |  671
 6 | Chiquinha     |  669 |    0
 7 | Mariazinha    |  669 |    0
 8 | Maradona      |  670 |  671
(8 rows)

Nela, é possível visualizar os xmax de Jose da Silva e Maradona com o valor da transação em PSQL1. Como a primeira ainda não confirmou a transação, ainda não estamos vendo os novos valores aqui (só veríamos se o nível de isolamento fosse READ UNCOMMITED, que permite dirty reads e não é suportado pelo PostgreSQL).

Vamos confirmar e visualizar o resultado final:

PSQL1: Confirmação e visualização do resultado

exercicio=# COMMIT ;
COMMIT
exercicio=# select *, xmin, xmax from aluno;
 id |    nome    | xmin | xmax
----+------------+------+------
 1 | Huguinho   |  664 |    0
 3 | Luisinho   |  664 |    0
 4 | Juquinha   |  664 |    0
 5 | Joaozinho  |  664 |    0
 6 | Chiquinha  |  669 |    0
 7 | Mariazinha |  669 |    0
 2 | Zezinho    |  671 |    0
(7 rows)

PSQL2: Visualização atualizada. Se estivesse no nível de isolamento SERIALIZABLE ou REPEATABLE READ, não seria possível ver os registros atualizados e deletados.

exercicio=# SELECT *, xmin, xmax FROM aluno;
id |    nome    | xmin | xmax
----+------------+------+------
1 | Huguinho   |  664 |    0
3 | Luisinho   |  664 |    0
4 | Juquinha   |  664 |    0
5 | Joaozinho  |  664 |    0
6 | Chiquinha  |  669 |    0
7 | Mariazinha |  669 |    0
2 | Zezinho    |  671 |    0
(7 rows)

MVCC e a necessidade de Vacuum

O MVCC traz uma série de benefícios sobre os bloqueios:

• Processos de leitura não bloqueiam processos de escrita e vice-versa
• Praticamente elimina a incidência de contenções de transações
• Reduz drasticamente o risco de DEAD LOCK
• Possui um desempenho bem superior

Mas também é possível detectar um ponto fraco no MVCC. Os registros alterados e excluídos não ficam mais acessíveis mas não são imediatamente riscados do mapa. Ou seja, continuam inchando o disco. Para evitar que o banco tome proporções além do aceitável (este aceitável é bem relativo), execute regularmente (este regularmente é mais relativo ainda) a instrução VACUUM, que além de apagar os registros (VACUUM FULL) ou simplesmente apontando nas páginas de dados como área disponível para ser sobrescrita (VACUUM simples), também atualiza o ID das transações para evitar estouro e consequente reinício automático dos IDs de transações, o que poderia proporcionar resultados catrastróficos (como uma espécie de bug do milênio).

Como os IDs das transações são inteiros de 32 bits, a cada 4 bilhões lá vai fumaça de transações, isto poderá ocorrer. Voltaremos a este assunto em uma seção específica para o comando VACUUM, nos policiando para não realizar mais de 4 bilhões de exemplos daqui até lá.

Bloqueios e deadlocks

Provavelmente, você não irá precisar trabalhar com bloqueios explícitos no PostgreSQL, mas existem situações onde podem ser úteis. A prova é que o PostgreSQL implicitamente trabalha com bloqueios em algumas instruções. Pra variar, vamos a um exemplo:

PSQL1: Atualizando o nome de Mariazinha

exercicio=# BEGIN ;
BEGIN
exercicio=# UPDATE aluno SET nome = 'Maria Francisca' where id = 7;
UPDATE 1

PSQL2: Atualizando os nomes de Chiquinha e Mariazinha em outra transação

exercicio=# BEGIN ;
BEGIN
exercicio=# UPDATE aluno SET nome = 'Francisca' where id = 6;
UPDATE 1

exercicio=# UPDATE aluno SET nome = 'Maria Joaquina' where id = 7;

Até o primeiro UPDATE, fora o dilúvio que se abateu sobre Recife e o temporal do lado de fora da janela, estava tudo normal. No segundo, a chuva até que diminuiu, mas a alteração do nome de Mariazinha ficou congelada (bloqueada) até que o PSQL1 confirme a sua alteração. Caso não ficasse, a transação que encerrasse primeiro teria suas alterações perdidas devido a outra que encerrasse depois, independentemente de quem realizou o UPDATE primeiro. Isto resultaria em um outro problema de isolamento conhecido por Lost Update, que pode ainda ser mais grave se uma transação precisar dos dados da outra para atualizar os seus, como eles não estarão disponíveis até o COMMIT, o estado final potencialmente deverá ferir o princípio da consistência.

Agora vamos voltar à primeira transação não para confirmar a alteração e liberar o UPDATE na segunda, mas para pôr mais lenha na fogueira e também esperar pela segunda devido a alteração do nome de Chiquinha.

PSQL1: Atualizando um registro já modificado pela outra transação

exercicio=# UPDATE aluno SET nome = 'Chica' where id = 6;

ERROR:  deadlock detected
DETAIL:  Process 9019 waits for ShareLock on transaction 674; blocked by process 8919.
Process 8919 waits for ShareLock on transaction 676; blocked by process 9019.
Process 9019: UPDATE aluno SET nome = 'Maria Joaquina' where id = 7;
Process 8919: UPDATE aluno SET nome = 'Chica' where id = 6;
HINT:  See server log for query details.

Booom, DEAD LOCK. Game over. Façamos um breve parênteses para a mensagem de erro do PostgreSQL que não é uma simples mensagem, é uma aula sobre o assunto. Como sei que você é uma pessoa bastante atenta, posso apostar que percebeu o termo ShareLock da mensagem de erro acima. Ela significa bloqueio compartilhado.

Antes de seguir adiante, façamos mais uma dinâmica a fim de colher informações do PostgreSQL acerca dos bloqueios realizados implícita ou explicitamente em determinado momento. A view de catálogo pg_locks recupera os locks gerenciados no momento pelo pelo servidor. Unindo ela com as tabelas de catálogo pg_class e pg_database podemos ter uma informação bem interessante:

PSQL1: Iniciando uma inofensiva transação para mais uma vez alterar o nome de Chiquinha e consultando o bloqueio gerado

exercicio=# BEGIN ;
BEGIN
exercicio=# UPDATE aluno SET nome = 'Chica' where id = 6;
UPDATE 1

exercicio=# select l.locktype, l.mode, l.pid, d.datname, c.relname from pg_locks l inner join pg_database d on l.database = d.oid inner join pg_class c on l.relation = c.oid where c.relkind = 'r' and relname not like 'pg_%';
locktype |       mode       | pid  |  datname  | relname
----------+------------------+------+-----------+---------
relation | RowExclusiveLock | 8919 | exercicio | aluno
(1 row)

O PostgreSQL reconhece oito tipos de bloqueios: ACCESS SHARE, ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE.

É possível solicitar explicitamente um bloqueio sobre tabelas ou mesmo registros através do comando Lock:

exercicio=# \h LOCK
Command:     LOCK
Description: lock a table
Syntax:
LOCK [ TABLE ] [ ONLY ] name [, ...] [ IN lockmode MODE ] [ NOWAIT ]

where lockmode is one of:

ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE
| SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE

Access Share

Bloqueio requerido apenas por instruções SELECT e ANALYZE são simples leitura em geral permitidas, a menos que alguma outra transação tenha requerido Access Exclusive.

Row Share

A instrução SELECT com a cláusula FOR UPDATE obtém este nível de bloqueio. Ele conflita apenas com os níveis mais retritos Exclusive e Access Exclusive.

Row Exclusive

Bloqueio solicitado automaticamente por instruções INSERT, UPDATE, DELETE. Conflita com quem precisar além de Access Exclusive e Exclusive, também com Share Row Exclusive e Share.

Share Update Exclusive

Bloqueio padrão do comando VACUUM sem a opção FULL. Conflita com todos os próximos níveis de bloqueio e com ele próprio. Bloqueia a tabela inteira.

Share

A partir deste nível de bloqueio, já vimos com quem cada um conflita. Bloqueia toda a tabela e é requerido por instruções CREATE INDEX.

Share Row Exclusive

Similar ao Exclusive, mas apenas no nível de linha. Não há instrução SQL que automaticamente solicite este nível de bloqueio.

Exclusive

Este só não conflita com Access Share. É requerido automaticamente apenas em tabelas de catálogo em determinadas operações.

Access Exclusive

Conflita com todo mundo. Ou seja, nenhuma outra transação pode operar na mesma tabela bloqueada por alguma transação que solicitou Access Exclusive. Instruções ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX, CLUSTER e VACUUM FULL necessitam deste modo de bloqueio.

Conclusão

Percebeu como é denso e fundamental o assunto transações? Elas são provavelmente o mais frequente motivo para desenvolvedores optarem por trabalhar com SGBDs em vez de persistirem dados diretamente em arquivos.

Acredito que tanto DBAs quanto desenvolvedores precisam conhecer bem como o SGBD escolhido lida com elas e optar pelo PostgreSQL é optar pelo que há de mais avançado no mercado sobre o assunto.

postgres=# CREATE DATABASE exercicio;
CREATE DATABASE
postgres=# \c exercicio
You are now connected to database "exercicio".
exercicio=# create table aluno (id serial primary key, nome varchar(50));
NOTICE:  CREATE TABLE will create implicit sequence "aluno_id_seq" for serial column "aluno.id"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "aluno_pkey" for table "aluno"
CREATE TABLE
exercicio=# INSERT into aluno (nome) values ('Huguinho'), ('Zezinho'), ('Luisinho'), ('Juquinha'), ('Joaozinho');
INSERT 0 5

exercicio=# begin;
BEGIN

exercicio=# UPDATE aluno set nome = 'Jose da Silva' where id = 2;
UPDATE 1

exercicio=# select * from aluno;
id |     nome
----+---------------
1 | Huguinho
3 | Luisinho
4 | Juquinha
5 | Joaozinho
2 | Jose da Silva
(5 rows)

exercicio=# select * from aluno;
id |   nome
----+-----------
1 | Huguinho
2 | Zezinho
3 | Luisinho
4 | Juquinha
5 | Joaozinho
(5 rows)

exercicio=# ROLLBACK ;
ROLLBACK
exercicio=# select * from aluno;
id |   nome
----+-----------
1 | Huguinho
2 | Zezinho
3 | Luisinho
4 | Juquinha
5 | Joaozinho
(5 rows)

exercicio=# BEGIN ;
BEGIN
exercicio=# UPDATE aluno set nome = 'Jose da Silva' where id = 2;
UPDATE 1

exercicio=# select * from aluno;
id |   nome
---+-----------
1 | Huguinho
2 | Zezinho
3 | Luisinho
4 | Juquinha
5 | Joaozinho
(5 rows)

exercicio=# COMMIT ;
COMMIT

exercicio=# select * from aluno;
id |     nome
---+---------------
1 | Huguinho
3 | Luisinho
4 | Juquinha
5 | Joaozinho
2 | Jose da Silva
(5 rows)

WARNING:  there is no transaction in progress

# begin;
BEGIN
exercicio=# INSERT INTO aluno (nome) values ('Chiquinha'), ('Mariazinha');
INSERT 0 2

# begin;
BEGIN
exercicio=# select * from aluno;
id |     nome
---+---------------
1 | Huguinho
3 | Luisinho
4 | Juquinha
5 | Joaozinho
2 | Jose da Silva
(5 rows)

exercicio=# COMMIT ;
COMMIT

exercicio=# select * from aluno;
id |     nome
---+---------------
1 | Huguinho
3 | Luisinho
4 | Juquinha
5 | Joaozinho
2 | Jose da Silva
6 | Chiquinha
7 | Mariazinha
(7 rows)

exercicio=# begin;
BEGIN
exercicio=# set transaction read only;
SET
exercicio=# UPDATE aluno SET nome = 'teste';
ERROR:  cannot execute UPDATE in a read-only transaction
exercicio=# select * from aluno;
ERROR:  current transaction is aborted, commands ignored until end of transaction block
exercicio=# rollback;
ROLLBACK

exercicio=# BEGIN ;
BEGIN
exercicio=# SET transaction ISOLATION LEVEL REPEATABLE READ ;
SET
exercicio=# select * from aluno;
 id |     nome
---+---------------
 1 | Huguinho
 3 | Luisinho
 4 | Juquinha
 5 | Joaozinho
 2 | Jose da Silva
 6 | Chiquinha
 7 | Mariazinha
(7 rows)

exercicio=# BEGIN ;
BEGIN
exercicio=# INSERT INTO aluno (nome) values ('Maradona');
INSERT 0 1
exercicio=# COMMIT ;

exercicio=# select * from aluno;
 id |     nome
---+---------------
 1 | Huguinho
 3 | Luisinho
 4 | Juquinha
 5 | Joaozinho
 2 | Jose da Silva
 6 | Chiquinha
 7 | Mariazinha
(7 rows)

exercicio=# COMMIT ;
COMMIT
exercicio=# select * from aluno;
 id |     nome
---+---------------
 1 | Huguinho
 3 | Luisinho
 4 | Juquinha
 5 | Joaozinho
 2 | Jose da Silva
 6 | Chiquinha
 7 | Mariazinha
 8 | Maradona
(8 rows)

exercicio=# BEGIN ;
BEGIN
exercicio=# select *, xmin, xmax from aluno;
 id |     nome      | xmin | xmax
---+---------------+------+------
 1 | Huguinho      |  664 |    0
 3 | Luisinho      |  664 |    0
 4 | Juquinha      |  664 |    0
 5 | Joaozinho     |  664 |    0
 2 | Jose da Silva |  668 |    0
 6 | Chiquinha     |  669 |    0
 7 | Mariazinha    |  669 |    0
 8 | Maradona      |  670 |    0
(8 rows)

exercicio=# DELETE FROM aluno WHERE nome = 'Maradona';
DELETE 1
exercicio=# select *, xmin, xmax from aluno;
 id |     nome      | xmin | xmax
---+---------------+------+------
 1 | Huguinho      |  664 |    0
 3 | Luisinho      |  664 |    0
 4 | Juquinha      |  664 |    0
 5 | Joaozinho     |  664 |    0
 2 | Jose da Silva |  668 |    0
 6 | Chiquinha     |  669 |    0
 7 | Mariazinha    |  669 |    0
(7 rows)
exercicio=# UPDATE aluno SET nome = 'Zezinho' where id = 2;
UPDATE 1
exercicio=# select *, xmin, xmax from aluno;
 id |    nome    | xmin | xmax
---+------------+------+------
 1 | Huguinho   |  664 |    0
 3 | Luisinho   |  664 |    0
 4 | Juquinha   |  664 |    0
 5 | Joaozinho  |  664 |    0
 6 | Chiquinha  |  669 |    0
 7 | Mariazinha |  669 |    0
 2 | Zezinho    |  671 |    0
(7 rows)

exercicio=#
SELECT *, xmin, xmax FROM aluno;
 id |     nome      | xmin | xmax
---+---------------+------+------
 1 | Huguinho      |  664 |    0
 3 | Luisinho      |  664 |    0
 4 | Juquinha      |  664 |    0
 5 | Joaozinho     |  664 |    0
 2 | Jose da Silva |  668 |  671
 6 | Chiquinha     |  669 |    0
 7 | Mariazinha    |  669 |    0
 8 | Maradona      |  670 |  671
(8 rows)

exercicio=# COMMIT ;
COMMIT
exercicio=# select *, xmin, xmax from aluno;
 id |    nome    | xmin | xmax
---+------------+------+------
 1 | Huguinho   |  664 |    0
 3 | Luisinho   |  664 |    0
 4 | Juquinha   |  664 |    0
 5 | Joaozinho  |  664 |    0
 6 | Chiquinha  |  669 |    0
 7 | Mariazinha |  669 |    0
 2 | Zezinho    |  671 |    0
(7 rows)

Na semana passada, tivemos um susto enorme após a notícia do problema de saúde de nosso professor Aercio Ramoa. Ele sofreu um infarto e passou alguns dias na UTI, mas felizmente, se recupera bem, já está na enfermaria e até já demonstrou sua peculiar preocupação com seus alunos querendo saber o que vimos na aula em que eu o substitui. Acreditamos que após a pausa do feriado de São João, já estaremos com Aercio firme e forte. Boa sorte, amigo.

No entanto, este post não será tão alegre até o final. Infelizmente, o filho de nosso grande amigo Habner Carlos faleceu. Habner foi nosso aluno de PHP. Determinado, enfrentou e venceu a prova de certificação da Zend mesmo antes de concluir as aulas. Profissional e interessado, também nos provou que teria plenas condições de ser professor e em cada turma que ministrou, só ouvi elogios à sua competência, didática e amizade com os alunos. Quem o acompanhou nesses últimos meses, sabe o quanto ele estava vibrando com a primeira gravidez de sua esposa. Como se espera de um homem de Deus e de um perfeito futuro pai, fez planos e não via a hora de poder abraçar seu filho.

Após o parto, seu filho teve algumas complicações e ficou internado batalhando pela vida até que não resistiu e descansou.

O sentimento de pesar é extremamente desconfortante para que eu consiga encontrar as palavras certas que lhe dêem apoio nesta hora, mas Hábner, gostaria de dizer a você, à sua esposa, parentes e amigos que tenham muita força. Vocês não estão sozinhos. Todos nós da Especializa partilhamos deste sentimento de dor e principalmente de esperança na superação de vocês.

Saiba, meu amigo, que seu filho não se foi. Prefira encarar que Deus sentiu saudades e o chamou de volta, mas não será para sempre. Muito em breve, Ele o plantará novamente no ventre de sua esposa e vocês três poderão curtir uma vida longa e alegre juntos. A vantagem é que serão muito mais fortes e unidos que qualquer outra família.

Um grande abraço.

Como não poderia deixar de ser, nós da Especializa acompanhamos sem piscar os olhos e já estamos preparando nossos cursos para tão logo possamos considerar as novidades definitivas.

Vejamos o que virá de tão bom a ponto da versão haver mudado de número (inicialmente, seria 8.5).

A versão 8 do PostgreSQL foi um marco histórico bastante importante para este SGBD. Talvez a principal razão tenha sido o tão esperado suporte nativo a sistemas de arquivos NTFS e, consequentemente, a capacidade de rodar em ambientes Windows.

Apesar do mundo Unix dominar largamente os servidores que rodam o PostgreSQL, mesmo após a oitava versão, suportar nativamente o Windows, foi um passo importante na busca pela popularização de um banco sempre considerado robusto, mas pouco atraente em termos de facilidade de administração.

O raciocínio é óbvio. Mais gente utilizando traz naturalmente mais gente disposta a desenvolver ferramentas para melhorar o dia-a-dia de quem utiliza.

Após quatro rodadas de atualizações da versão 8, que apesar de minor realeases (incremento do número após o ponto, 8.1, 8.2, 8.3 e 8.4), evoluíram consideravelmente o PostgreSQL em diversas áreas, estava claro que lançar uma versão 9 certamente significaria uma responsabilidade muito grande. Mesmo assim, a comunidade open source achou que o que eles estavam trabalhando não poderia ser apenas um 8.5.

Acredito que estamos tratando de um SGBD maduro que provavelmente será difícil encontrar alguma new feature que por si só já o transporte a uma nova versão. O motivo para chamar o PostgreSQL de 9.0 agora foi a quantidade de melhorias implementadas pela comunidade. Só para se ter uma idéia, foram catalogados 84 desenvolvedores produzindo mais de 200 melhorias e correções nesta versão.

Um ponto positivo para o PostgreSQL é a descentralização de desenvolvedores, sendo possível notar que muitos dos principais colaboradores do núcleo do sistema trabalham numa gama bem variada de empresas. Isto de certa forma potencializa a garantia de que os planos não serão mudados de uma hora pra outra.

É, estou sim me referindo à celeuma envolvendo o MySQL quando a Oracle adquiriu a Sun e provocou dissidências como o MariaDB e algumas incertezas quanto ao seu futuro. Ingenuamente, podemos pensar “ah, o MySQL não é open source? Então se a Oracle quiser matá-lo a comunidade vem e cria um fork dele” (calma que não foi bem isso que ela anunciou que faria).

Tudo bem, existem diversos exemplos de forks na comunidade que alcançaram sucesso igual ou maior que seu progenitor (sem ir muito longe, o próprio Firebird nasceu da abertura do fonte do Interbase da Borland). Mas a realidade não é tão simples. Muitas vezes, optar por um concorrente próximo quando seu produto open source favorito parece um tanto “sem futuro” é a solução mais rápida e indolor. E aí, quando a comunidade amadurecer o fork recém nascido, já era! A própria comunidade talvez já tenha abandonado a criança.

Por outro lado, essa pulverização de empresas e profissionais contribuidores pode refletir em uma falta de personalidade própria, se é que posso chamar assim. Em outras palavras, um gestor de TI ao refletir sobre utilizar ou não o PostgreSQL em seus servidores pode se questionar: Quem está por trás dele? Quem garante que ele vai atender às minhas necessidades? E quem é a pessoa mais indicada para me informar qual a maneira ideal de adaptar o PostgreSQL à minha realidade? Neste momento, os “quens” certamente serão preenchidos por empresas que talvez ele nunca tenha ouvido falar.

Por isso, o fortalecimento de empresas como a EnterpriseDB (praticamente o Quem por trás hoje), a Command Prompt e a própria PostgreSQL Experts encabeçada por Josh Berkus pode ser saudável. Some a elas as presenças de gigantes como Sun (Oracle), Red Hat e Google, todas estas com major contributors focados no PostgreSQL, para garantir de que se a EnterpriseDB um dia for comprada pela Microsoft (só para dar um exemplo mais dramático) ela não terá como simplesmente matar o PostgreSQL.

O nosso ponto de partida no estudo das novidades é o Wiki oficial, mais especificamente no endereço:

http://wiki.postgresql.org/wiki/Development_information. Lá você encontrará diversas informações e links interessantes como a Feature Matrix apresentando o que vem sendo implentando desde a versão 7.4

Robert Treat, da OmniTI e major contributor do PostgreSQL, elenca em sua palestra melhorias em performance, administração, desenvolvimento e procedimentos. Podemos destacar:

• Ordered aggregates

Dados podem ser previamente ordenados antes de serem fornecido a alguma função de agregação. Este link trata do assunto usando array_agg().

• Window functions

Na verdade elas já existiam desde o PostgreSQL 8.4 (você pode conferir na Feature Matrix), mas agora novas funcionalidades para elas foram criadas. Este link introduz o assunto, abordando as cláusulas PARTITION e WINDOW. Já este link faz um comparativo do suporte a essa funcionalidade, parte do padrão ANSI SQL 2003, no PostgreSQL 8.4 com o SQL Server 2008, Oracle e DB2.

Aqui, você pode encontrar algo sobre o que há de novo no 9.0 dentro deste assunto.

• Join removal

O planejador de consultas do PostgreSQL pode excluir do plano tabelas que não são necessárias para obtenção dos dados resultantes. Leia mais, aqui.

• Explain buffers

O comando explain agora exibe também as páginas de dados envolvidas em consultas. Buffers são unidades normalmente de 8kb que armazenam os dados de fato.

• Grant em esquema

Comandos Grant e Revoke podem ser aplicados  a esquemas. Confira.

• Suporte a Windows de 64 bits

• Initdb chamado via pg_ctl

O executável postgres já era chamado via pg_ctl, agora o initdb também poderá ser.

• Triggers condicionais

Triggers agora contam com a cláusula WHEN para avaliar uma expressão boleana e decidir se devem ou não ser disparada.

• PL/pgSQL

A linguagem procedural mais utilizada no PostgreSQL já vem instalada nativamente. Claro que você poderia realizar um CREATE LANGUAGE plpgsql; em template1 que tava tudo resolvido.  Também houve melhorias na sintaxe da linguagem.

• Hot Standby

O tão esperado recurso de replicação que viria no 8.4, agora veio.

• Streaming replication

Mais um recurso interessante para replicações. Confira mais aqui.

• pg_upgrade

Ferramenta para facilitar o processo de upgrade de versão de um cluster PostgreSQL.

Há ainda diversas outras melhorias.

Fica a promessa aqui de escrever algum tutorial explicando algumas delas.

CREATE LANGUAGE plpgsql;

A edição deste mês destaca seu comparativo Android x iPhone, vale a pena conferir.

Parabéns Glauber! Este é apenas o reconhecimento da mídia especializa de sua competência e dedicação.

Ah, será que vale deixar um spoiler da edição 31? Provavelmente, ele estará lá de novo e desta vez mau acompanhado. =)

Desculpem a propaganda forçada no parágrafo anterior. Ser professor da Especializa é um mero e imperceptível detalhe no currículo do cara. Renato é especialista em TI com alma de cientista. Maluco? Não importa. O fato é que (segundo seu próprio blog):

Em Março de 2010, Carlos recebeu a notícia de sua aprovação no Graduate Studies Program 2010 da Singularity University (SU), um programa de estudos oferecido a estudantes de pós-graduação com demonstrada capacidade de liderança e conhecimentos avançados em suas respectivas áreas de pesquisa.

Nero, como vocês podem chamar, lançou o blog Você no Futuro, onde deve discutir uma série de tecnologias emergentes como inteligência artificial, robótica, ciências espaciais, neurociência, bioengenharia, bioinformática, energia & meio ambiente, nanotecnologia, invação & empreendedorismos, ética, filosofia … ufa. Por lá você vai encontrar notícias, entrevistas, vídeos e podcasts, além de acompanhar toda a saga de Renato de Recife ao Campus da NASA.

Ele estará por lá de 19 de Junho a 28 de Agosto e deverá “topar” com um pessoal bem fraquinho como Bob Metcalfe (pai do Ethernet) e Vint Cerf (pai do TCP/IP), além de poder brincar no quintal da Google e do Facebook. Enfim, pra quem é nerd, cada post dele vai ser muito melhor do que qualquer episódio do The Big Bang Theory.

Se você é como a gente e se interessou em ajudar, vale dizer que Renato, a princípio, se sente constrangido em colocar algo do tipo “clique aqui para fazer uma doação”. Não que ele seja rico e já tenha como se bancar, muito pelo contrário, cientista e professor da Especializa infelizmente “ainda” não é o perfil de uma pessoa que possa passear na California. Mas Nero pretende recorrer a autoridades e diretores de empresas para que o ajudem no custeio, em troca de ceder um pequeno espaço para publicação de quem o está patrocinando.

O que nos cabe é prestigiar o blog do nosso nobre conterrâneo, espalhando até para os cachorros dos amigos dos tios dos vizinhos dos nossos primos. Mas, claro, se você quer ajudar com alguma quantia, basta enviar um email pra ele.

Há tempos que venho interessado em comentar algo sobre o suporte a multimidia na Web. Sou do tempo em que a Web não era lugar para sons, muito menos video. A gente tinha que se aventurar em plugins ou componentes ActiveX para obter .mid no Netscape ou até mesmo MP3 no Internet Explorer, respectivamente. Mas o troço era tão ruim que as pessoas até se assustavam se um site resolvesse tocar aquelas  “musiquinhas” que já foram febre nos celulares paleozóicos.

Vamos discutir aqui sobre a evolução dessas coisas, mas não tenho interesse em apresentar verdades absolutas. Se você tiver interesse em discutir a respeito e tiver uma idéia mais esclarecida do que a minha, eu lhe peço por favor, clique em “leia o resto deste post” e me ajude com as próximas linhas.

Lá vamos nós …

Eis que veio o Flash. Tá, quem me conhece sabe que nunca fui o maior defensor da tecnologia, mas justiça seja feita, a Web evoluiu com ele.

Por que nunca fui fã? Vamos lá: No início, os sites apresentavam aquelas infames apresentações iniciais. A sorte era quando havia um “pular introdução”. Nada mais amador do que aquelas apresentações. Depois alguns webdesigners se aventuraram em fazer sites completamente em Flash. O visual era bacana, mas a acessibilidade era dantesca. Imorais aquelas barras de rolagem estilizadas que sempre davam lag no browser e não funcionavam ao scroll do mouse. A Macromedia, que havia comprado a Future Splash (criadora do Flash) e aposentado seu produto concorrente Shockwave Director, foi comprada pela Adobe, esta sim, uma referência de qualidade em seus produtos: Postscript, Acrobat e talvez o mais famoso deles, Photoshop, são só alguns exemplos de fantásticas tecnlogias da Adobe. As coisas melhoraram bastante, mas infelizmente, a esta época eu, que já era fã incondicional do software livre e usuário, digamos, full-time, do Linux, continuei a sofrer com o famigerado Flash-plugin-non-free. Isso para não falar que meu amigo e professor da Especializa, Rafael Manzella, engenheiro de posicionamento há anos, realizador de campanhas de SEO para várias grandes empresas enquanto morava na Espanha, sempre me disse é FREUD fazer posicionamento de sites em Flash.

Por que acho que evoluiu? Porque estes mesmos designers descobriram que era possível usar o flash para interfaces ricas e foi difícil tornar o termo RIA (Rich Internet Application), sugerido pela Macromedia, mais amplo e abranger outras técnicas como o Ajax/Comet, Silverlight ou JavaFX. Outra razão foi o suporte a streaming de audio e video. As notícias ficaram mais vivas e avançamos à era do broadcast yourself.

No auge das discussões sobre o HTML5, o padrão para adoção dessas midias parece que ainda vai dar o que falar. Para isso, mais uma vez vou precisar enrolar beeeem muito: No período das grandes navegações na Web, Cristóvão Colombo descobriu o MP3. O problema é que o MP3, ou MPEG-1 Audio Layer 3 (MPEG = Moving Picture Experts Group) é propriedade de um instituto de pesquisa alemão e da empresa Thomson Consumer Electronics e, desde 1998, quem fabrica player MP3 comercial precisa pagar royalties pros caras.

A comunidade de software livre resolveu criar um padrão de mídia como patrimônio da humanidade. A este padrão deram o nome de Ogg, mantido pela fundação Xiph.org. Só que o Ogg é um guarda-chuva de padrões multimídia. O codec de audio foi denominado Ogg Vorbis. Este sim, o candidato da comunidade open source a substituto do MP3.

Com relação a video o desafio foi ainda maior. A empresa On2 Technologies, liberou o código de seu codec VP3 e a comunidade lançou seu produto Ogg Theora, comparável ao padrão MPEG-4.

Paralelo a isso, a Apple vem trabalhando em um codec de vídeo derivado de seu Quicktime, para uns conhecido como MPEG-4 parte 10 ou MPEG-4 AVC, mas que vem sendo chamado no mercado pelo seu código mesmo H.264 (exato, veio depois do H.263). Sites como o Youtube e o ITunes disponibilizam vídeos em H.264 e dispositivos como tocadores blu-ray, IPhones, ITabs, Androids, Blackberries e Maemos possuem suporte a decodificação diretamente no chip, sem uso de software, o que economiza energia. Saiba que este foi um dos motivos técnicos que fizeram Steve Jobs condenar o uso do Flash.

A Google adquiriu a On2 Technologies e entregou mais uma versão de seu codec à comunidade. O VP8 vem despontando como um concorrente de peso ao cargo de codec padrão de vídeos HTML5. Aliando-o ao codec de audio Ogg Vorbis, nosso MP3 realmente livre, empresas como a fundação Mozilla, a Opera Software, A Google e … a Adobe criaram o projeto WebM com o objetivo de unir forças em prol da ubiquidade destes padrões.

Se tio Steve levanta motivos para não usar o Flash e se une à Google e à comunidade de software livre para preencher com HTML5 as lacunas dos padrões abertos das interfaces ricas na Web, é pau pra comer sabão. Se a Adobe se une também ao Google e à comunidade de software livre para promover o VP8, suportando este codec nos flash players, em detrimento do H.264 da Apple, é pau pra saber que sabão não se come.

Nessa história toda, a Google posa de boa moça, parceira dos padrões abertos e paladina na luta contra o draconian future, mas é a comunidade de software livre que sai vencedora. Seus padrões estão enfim conquistando o mundo e é o mundo quem se beneficia com isso.