Quando falamos em tabelas podemos estar nos referindo à tabelas propriamente ditas, ou a todo o ritual de desenvolvimento de páginas em HTML da década passada. Tabelas às vezes são sinônimo de toda aquela prática antiquada, GIFs transparentes, tags <font> e tudo mais. Bom, tabelas ao pé da letra são somente tabelas.

Ok, isso é óbvio, eu sei! Mas é importante introduzir isso pra quebrar um grande tabu: o mito de nunca usar tabelas pro layout. Se formos pensar exclusivamente nas tabelas (sem levar em conta tags <font> e outras práticas ruins), não existe hoje em dia argumento forte à favor do Tableless (ao pé da letra).

Para criar um layout simples líquido com três colunas, é necessário usar um monte de hacks CSS. É um inferno que uma tabelinha (só uma, pra ajeitar as colunas) resolveria direitinho. As tabelas sempre vão se comportar daquela maneira, os hacks não, podem sofrer com futuras atualizações dos navegadores.

O problema de usar tabelas é principalmente semântico, a tabela não tem carga de significado pra exibir colunas de layout. Se levarmos em conta que hoje em dia há pouca utilização da semântica na internet, existem poucos sistemas que indexam as páginas, talvez seja desperdício usar hacks ao invés de tabelas, em alguns casos.

Além do mais, o cenário mudou. A semântica hoje é vista por máquinas mais inteligentes do que quando foi idealizada. Uma máquina ideal na época da criação do HTML não poderia identificar uma tabela de layout e ignorá-la, hoje pode. Aliás, é mais difícil pra uma máquina ignorar um div mal utilizado do que uma tabela mal utilizada.

Em outras palavras, eu priorizo os padrões, e na minha concepção um hack css é menos padrão do que uma tabela pra layout.

Durante muito tempo eu fiquei com uma dúvida que surgiu lá nos tempos de iniciação no HTML: Como criar tags <meta>?

Conforme eu ia fuçando nos outros sites, ia encontrando a cada dia mais tags <meta> diferentes e novas, e me senti um pouco incomodado por não existir um padrão definido para elas.

Não que sejam extremamente importantes para os sistemas de busca (como parecem ser), mas são legais e úteis para demais mecanismos de indexação.

O Dublin Core Metadata Initiative é uma iniciativa para padronizar metainformação e os vocabulários na internet. Não é algo exclusivo para criação de tags <meta>, vai muito além, mas servem direitinho para termos uma boa diretriz para criá-las.

Vale a pena dar uma conferida na lista básica dos termos DCMI. Uma lista mais completa em inglês também está disponível. Para usar um desses elementos como tag <meta> basta seguir o exemplo (retirado do código-fonte do site do Dublin Core):

HTML
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<meta name="DC.title" content="Dublin Core Metadata Initiative (DCMI) Home Page" />
<meta name="DC.description" content="The Dublin Core Metadata Initiative is an open forum engaged in the development of interoperable online metadata standards that support a broad range of purposes and business models. DCMI's activities include consensus-driven working groups, global conferences and workshops, standards liaison, and educational efforts to promote widespread acceptance of metadata standards and practices." />
<meta name="DC.date" content="2007-06-04" />
<meta name="DC.format" content="text/html" />
<meta name="DC.contributor" content="Dublin Core Metadata Initiative" />
<meta name="DC.language" content="en" />

É importante não esquecer de colocar o elemento <link> antes das tags <meta> contendo a informação sobre o esquema “DC” (que é correspondente ao DCMI). Nesse exemplo apenas alguns elementos são utilizados, embora você possa usar todos os contidos na lista, da maneira como quiser.

Nos últimos anos ficou claro que a tendência de surgirem aplicações que rodam no navegador está cada vez mais forte, embora essas tecnologias ainda sejam “obra de Frankenstein”.

Uma solução rápida, padronizada e eficiente de scripting no cliente em código livre, adotada por todos os fabricantes de navegadores. É isso que falta.

Esse UniversalScript tem uma grande chance de ser o JavaScript que conhecemos, desde que em certo momento surja um parser realmente eficiente para substituir todos os atuais.

Atualmente cada navegador implementa o JavaScript a seu bel-prazer, incluindo sintaxe proprietária e sem preocupações com performance.

Apesar de eu não gostar de Flash, admiro muitas de suas qualidades, e uma delas é a excelente solução de script que ele possui, o ActionScript.

No Linux talvez não, mas no Windows a performance do Flash é magnífica em qualquer navegador, bastante superior ao JavaScript.

Isso se deve ao fato do ActionScript trabalhar diretamente com os objetos do Flash e não com outros modelos, como o DOM. Eu acredito que o fato do JavaScript ter que trabalhar com DOM leva ele a ser menos eficiente, justamente porque o próprio DOM não está bem implementado nos navegadores. Nessa bola de neve, acabamos caindo numa sequência de falta de padrões desde o HTML, passando pelo CSS até o JavaScript, que por fim não consegue atingir uma boa performance de qualquer maneira.

O Flash não tem esse problema porque não trabalha dessa forma, ele criou seu próprio padrão e não precisa ser interoperante com outras tecnologias.

É por esse motivo que ninguém previa o estouro do AJAX. O Flash era a única alternativa pra construir aplicações eficientes na internet, a Macromedia já tinha feito toda a propaganda do conceito de RIA e o barco estava navegando suave. E de fato, o Flash ainda é a melhor solução pra esse tipo de aplicação, só não é politicamente correto

Descaso? Desânimo? Preguiça pra atualizar o Acorda pra Web!? Ainda não!

Essa poderia ser uma mensagem de “Ei, estou vivo e voltarei a postar diariamente” qualquer, mas não é! É um retrato de um programador enrolado que gosta de torturar a si mesmo.

Resumindo tudo, adotei um projeto com prazo de 30 dias pra conclusão e comecei a colocar a mão na massa faltando 5 dias pro limite. Em breve, coloco algumas experiências que encarei com o projeto, e algumas soluções que encontrei, entre elas:

• Cálculo de Frete do SEDEX via PHP, sem frescura e sem file(url) (que hosts como o Dreamhost não suportam)
• Experiências práticas com integração de pagamentos digitais em lojas virtuais
• O Desespero de ter milhares de idéias para postar no blog, anotar centenas delas e no final não lembrar de quase nada

Também pretendo falar mais um pouco sobre minha vida de programador de última hora, que não trabalha durante 4 semanas pra compensar tudo trabalhando 15h por dia durante 4 ou 5 dias. Seria todo programador assim? É irresponsabilidade trabalhar dessa maneira?

Há um bom tempo estou tentando me livrar do Photoshop para construir sites. Além de ser pago e caro, o que faz com que eu me torne dependente do computador do serviço, é pesado.

Tentei o GIMP, que é mundialmente conhecido como o Linux Photoshop. Péssimo, aquela interface é um suicídio pra quem já acostumou com outro programa. Além do mais, softwares que trabalham com bitmaps não são os mais recomendados para design de páginas na internet.

Após muito pesquisar e resistir, resolvi que seria melhor adotar um programa que trabalha com imagens vetoriais, não bitmaps. Descobri o Inkscape e me encantei.

Além de ser extremamente simples (o que eu adoro), o Inkscape trabalha com SVG, um padrão da web que já comentei por aqui.

Ao abrir o programa pela primeira vez, fiz algo que nunca havia feito antes: usei o tutorial nativo dele e posso afirmar, é excelente! Além desse tutorial nativo, bastante material em vídeo pode ser encontrado no youtube.

Sem dúvida o tutorial que me fez mudar definitivamente para o Inkscape foi o de fatiamento de imagens, que me permite exportar as imagens do layout separadamente de maneira muito fácil

Obviamente, nessas primeiras semanas, tudo foi só experimentação. Sinto falta de algumas coisas que o Photoshop fazia automaticamente, como sombras e texturas direto na camada. Aliás, trabalhar com camadas no Inkscape é possível, mas é desencorajador (pelo menos até o momento).

Ainda estou brigando com meu hardware para conseguir manter um Linux perfeito, enquanto isso eu brinco com o Inkscape do Windows mesmo, já que ele pode ser instalado em ambos.

Para quem busca mais opções além do Inkscape pra trabalhar com design de páginas no Linux, pode conferir um artigo do Marcus que fala sobre isso também.

O que me preocupa, talvez até assusta, é que não conheço nenhuma página com design excepcional que foi declarada como construída no Linux. Será que dará certo?

Meu celular é um jurássico Siemens A52. Ele não possui nada sem fio, não tem tela colorida, não tem calendário, não tira fotos e não toca MP3, mas escreve mensagens de texto que é uma beleza! Juro que se fosse mais fino, ficaria com ele para sempre.

Escolhi minha operadora, a Claro, unicamente por um de seus serviços, exclusivos. O Claro Torpedo Email permite que meu celular receba mensagens SMS através de um endereço de email, gratuitamente. Mais detalhes sobre o serviço no Corporação Web.

O Google Calendar possui uma função para envio de mensagens SMS, mas ela funciona somente com a operadora TIM no Brasil e cobra por mensagens enviadas, o que não me agrada nem um pouco.

Em um dia de tédio vi que era possível fazer com que o Google Calendar me enviasse lembretes via email, dez minutos antes de qualquer evento registrado. O problema era que os emails enviados vão para um endereço fixo, aquele da sua Google Account, portanto não haveria como configurar diretamente o envio para o email do ClaroTorpedo.

Pra contornar isso, decidi manter o envio de emails para minha caixa padrão. Tenho o costume de centralizar tudo em uma única caixa de email e trabalhar com filtros no GMail.

Configurei um filtro que encaminha todas as mensagens de calendar-notification@google.com para meu endereço no ClaroTorpedo e logo em seguida as arquiva. Mudei também o adiantamento de dez minutos padrão do Google Calendar para quinze minutos, visando cobrir uma possível lentidão com tantos encaminhamentos encadeados.

Depois de uma semana de testes, posso afirmar que funcionou perfeitamente. Aliás, arrisco dizer que chega a ser mais prático do que manter calendários nativos de celulares, já que tenho toda liberdade pra utilizar o potencial do Google Calendar.

Fico limitado, obviamente, a não poder adicionar eventos direto do meu celular, mas isso meus amigos, é questão de tempo! Estou desenvolvendo uma simples script em PHP que permitirá adicionar eventos via email através do celular. Infelizmente a operadora Claro cobra o envio de emails através do celular.

Bom, é isso. Minha pequena dica para conseguir algo extremamente úti com ferramentas muito simples e sem gastar um centavo!

Frases similares a “Melhor visualizado no Internet Explorer” viraram alvo dos defensores dos padrões da web. Qualquer página que ouse incluir essa pequena orientação é fortemente criticada com argumentos como:

• E os usuários de Linux? Como ficam?
• Eu não gosto do Internet Explorer, qual o preconceito contra os outros navegadores?
• Internet Explorer é um lixo satânico do inferno, queima, queima.

Bom, atualmente os usuários de Linux podem utilizar o Internet Explorer, e os usuários de Mac OS também. Talvez você não goste do Internet Explorer, mas não pode afirmar que é completamente inacessível pra um usuário de outros navegadores.

Usei o Internet Explorer dos 12 aos 18 anos e gostava bastante, eu confesso. Hoje critico-o pela falta de suporte aos padrões e toda ladainha que os desenvolvedores falam sobre isso.

Aonde quero chegar? Por que estou defendendo quem coloca um aviso “Melhor visualizado no Internet Explorer”? Porque esses são honestos, isso mesmo.

Nos meus testes com uma máquina modesta, fiz comparações entre aplicações como GMail, Meebo, Netvibes e WordPress. Em todas o desempenho dessas aplicações no Internet Explorer foi classificado como inviável.

Tanto no Meebo quanto no Netvibes o navegador travou e não respondeu mais, exigindo que eu reiniciasse o meu velho AMD K6-II com magníficos 128MB de memória. O GMail após muito pensar ofereceu uma versão simplificada, que é completamente sem graça e o WordPress demorou séculos pra carregar as páginas de administração.

No Firefox todas as aplicações funcionaram normalmente com meu velho PC. No Opera, tanto no computador novo quanto no velho não foi possível carregar tanto o Meebo quanto o Netvibes corretamente.

A conclusão que cheguei? Talvez fosse melhor colocar um aviso “Melhor visualizado no Mozilla Firefox” em aplicações assim. De fato elas funcionam no Internet Explorer, mas o desempenho exige uma máquina boa e ainda sim, deixa a desejar.

Quando é que vamos aprender?

Eu concordo que sou um standardxiita, termo que acabo de cunhar. Standardxiitas são os desenvolvedores fissurados por padronização.

Um programador PHP Standardxiita respeita cada espaço da identação, desenvolve em modo E_ALL e a qualquer sinal de código sujo, exclui a classe inteira e escreve denovo. Desenvolvedores HTML e CSS standardxiitas seguem os padrões à risca, com código válido e completamente semântico.

Desenvolver nos padrões da web como um standardxiita pode trazer uma série de vantagens:

• Código semântico e validado tem mais chances de resistir mais tempo à revoluções tecnológicas
• Maior interoperabilidade. Funciona em qualquer lugar que também siga o padrão
• Rapidez no desenvolvimento. Os padrões foram feitos para facilitar nossa vida
• Projetos mais sólidos, sem redundâncias e código inútil
• Os mitos se tornam verdade

Além de standardxiita, eu sou extremamente perfeccionista e preguiçoso (embora essas afirmações sejam meio contraditórias). Costumo buscar plena adoção aos padrões em um projeto, mas quando o tempo aperta e surgem contratempos (sejam de hospedagem, navegadores, clientes) acabo fazendo do jeito antigo.

O Acorda pra Web é um dos projetos que surgiu em apenas uma noite. Minha intenção era publicá-lo com um sistema próprio e totalmente nos padrões, depois voltei atrás e utilizei o WordPress. Nesse caso a preguiça falou mais alto do que o perfeccionismo, e os padrões (no nível standardxiita) não fizeram tanta diferença.

O WordPress usa padrões, claro. Mas um standardxiita como eu sempre acha erros, e no meu caso não fizeram tanta diferença.

Desde o meu post sobre o Ubuntu, coloquei algo em mente: Vou passar a usar somente aplicativos na internet. Quero gerar uma prova do conceito, uma prova de que a internet pode suprir as necessidades de um usuário típico de escritório.

Inicialmente enfrento meu primeiro problema, o sistema operacional que escolherei. Quero migrar totalmente pra internet e ter uma vantagem nisso, não simplesmente instalar apenas o Firefox no meu computador atual.

Tenho duas ambições. A primeira é poder usar um sistema operacional que caiba no meu pendrive, assim poderei levá-lo onde eu quiser. A segunda é criar um sistema tão pequeno que possa ser baixado e configurado rapidamente em um CD ou outro pendrive. Essas seriam as duas principais vantagens do sistema, muita portabilidade.

Na minha primeira tentativa, optei pelo Slax. Sou completamente leigo e acabei corrompendo o sistema de arquivos do pendrive, e não tenho habilidade para recuperá-lo e tentar novamente outra instalação. Decidi adiar o projeto até resolver isso.

Basicamente, farei tudo girar em torno da internet e dispositivos móveis:

• Pendrive – Coração do meu método, conterá um sistema operacional equipado apenas com um Firefox minimalista, apenas com o Google Gears como extensão. Adicionalmente carregará arquivos.
• CDcard – Um daqueles pequenos cds em formato de cartão, conterá uma versão livecd do sistema operacional.
• Notebook – Não terá sistema operacional nativo, rodará o sistema pelo pendrive ou CDcard. Armazenaráarquivos se necessário.
• Celular – Será utilizado o recebimento de mensagens SMS e o envio de emails para integração com sistemas online.
• Servidor – Online ficarão os serviços, documentos, emails e a maioria dos arquivos.
• HD Externo – Vídeos, músicas e fotos de qualidade precisam de espaço e banda que a internet ainda não possui.

Provisoriamente, terei um Windows rodando no notebook também. Ainda preciso do Photoshop e de um editor decente de códigos. Esses dois softwares não são exatamente de escritório, portanto não fazem parte da regra do conceito.

Assim que eu conseguir algum progresso com o pendrive, coloco mais detalhes. Aliás, alguém tem alguma dica de como formatar pendrives com sistema de arquivos não identificado? Qualquer outra dica quanto ao conceito também é muito bem vinda!

Quando o Apollo foi lançado, me senti muito empolgado, principalmente pelo anúncio de que ele suportaria JavaScript e HTML, o que não exigiria uma curva de aprendizagem muito grande. Depois de muito desânimo com o Apollo tentando fazer o alpha funcionar em um Windows em português, desisti.

Agora pouco vi o Google Gears e me animei bastante. É uma tecnologia que torna os próprios navegadores capazes de trabalhar com aplicações offline. Antes que surja o mal entendido, ele não torna qualquer aplicação online offline.

Durante aproximadamente um ano trabalhei para a Prefeitura de São Paulo em um projeto na área de saúde. Em cada unidade de saúde de São Paulo foram instalados computadores que tinham acesso à um sistema online.No sistema online da prefeitura eram feitos os cadastros de pacientes, controle de estoque e agendamento de consultas. Os computadores não tinham nada além do Firefox, e as aplicações todas eram páginas da internet. O nosso maior problema era quando a conexão de internet caía ou o servidor enfrentava problemas.

Esse problema de quedas de conexão e servidor com problemas era crucial na alteração de estoque de medicamentos da unidade e cadastro de pacientes. Tinhamos que voltar à era do papel e anotar tudo, depois transferir para o computador. Se houvesse uma solução baseada no Google Gears as baixas no estoque e cadastros de pacientes poderiam ser continuados mesmo com interrupção da conexão.

O Google Gears é um plugin que funciona nos principais navegadores e sistemas operacionais, adicionando um servidor local, um sistema de bancos de dados e um sistema interessante para tornar aplicações mais rápidas.

Toda linguagem utilizada para desenvolver para o Google Gears é JavaScript, o que o torna complacente aos padrões web! O sistema de bancos de dados é o SQLite, com mínimas modificações, o que eu considero uma excelente escolha.

Para evitar um problema comum em páginas da internet, o Google Gears pode executar código fora do navegador, no que eles chamam de Worker Pool. Isso evita que o navegador trave e pare de responder em consultas complexas, afinal, até os bancos de dados estão ligados ao JavaScript no Google Gears.

Basicamente a coisa toda funciona armazenando páginas em HTML e scripts em JavaScript interagindo com o banco de dados do Google Gears offline. Quando o usuário fica online, os dados entre o servidor e a parcela offline da aplicação são sincronizados.

Além de melhorar a performance de trabalhos offline, o Worker Pool do Google Gears permitirá que aplicações online trabalhem mais rápido em background, quando o plugin estiver instalado no navegador. Para isso o site terá que ser construído para aproveitar dessa técnica, claro.

O Apollo traz coisas interessantes. Ele pode interagir com a máquina, com o sistema de arquivos local, mas deixa a desejar no quesito web. Uma aplicação em Apollo tem que ser baixada e executada, o que é meio traumatizante (nós da web gostamos de links e endereços, viu).

Não duvido nada se o Apollo começar a seguir os passos do Google Gears, mudando magicamente. Dou um doce virtual pra quem me mostrar por que não dará certo.