Voltei!!! Andei meio sumido, mas aqui estou de volta, e prometo ficar (tá, agora é pra valer mesmo). Fiquei meio enrolado com o FrameWorX, e acabei desistindo dele por um tempo, deixa ele descansar. Cortando o papo furado, vamos ao assunto de hoje: Validação. Será ela tão importante?

Quando os padrões “apareceram” aqui no Brasil, e ganharam uma certa forcinha, acredito que a maioria dos desenvolvedores conscientes correu para o validador da W3C, para ver os trabalhos validados e colocar aqueles selinhos de validação. Se não validasse, tudo de novo, até estar 100% validado. Isso leva, várias vezes, em um bom tempo ajustando em todos os navegadores, para que fique igualzinho ou pelo menos apresentável.

Creio que hoje essa “mania” passou. Claro que temos vários sites validados, mas é realmente necessário todo esse trabalho? Essa é mais uma questão filosófica, e discutiremos aqui.

Como todo mundo sabe, o validador do W3C (seja ele (X)HTML ou CSS) verifica apenas se o código está bem escrito, avisando sobre tags não fechadas, erros de código e etc. Ele não diz se o site está apresentável em todos os navegadores, não verifica semântica, não mede desempenho, nada. Então, “ser ou não ser” validado?

Analisemos a nossa situação. Temos um documento não validado, e pra ajudar um browser horrível (não quero citar o nome IE para não constranger), mas nosso documento funciona perfeitamente nele e em outros browsers decentes. Existe apenas um único erro de código, que serve exatamente para nosso querido amigo azul. Ahh! Temos um prazo também, e só existe uma solução para corrigir o tal bug, mas a solução é enorme, e demoraria séculos para terminar. Temos as seguintes opções:

• Suicidar-se
• Começar a chorar
• Apelar pra tudo quanto é santo
• Perder o emprego
• Entregar o trabalho não validado

Tempo… E aí, já decidiu? Considere que as três primeiras opções não são de grande ajuda. Sobram-nos duas. Perder o emprego também não é bom…

Os nossos browsers de hoje em dia não conferem nossa marcação. Se está errado, e funcionando, tudo certo. É lógico que um trabalho validado é uma conquista, mas quando se tem um prazo pequeno não vale a pena perder boa parte do tempo para consertar um bug.

Em um futuro muito distante, os browsers lerão tudo como XML. Aí sim precisaremos de marcações impecáveis. Mas se você serve seus documentos como “text/html”, não há problema (muito).

Cortando toda minha enrolação, resuminho pra vocês: não perca tempo para consertar um bug, se está tudo certo deixe assim. Mas é lógico que se você tiver um tempinho de sobra, faça o possível para validar tudinho. Tempo = dinheiro. Validação = menos tempo. Validação + tempo extra = tudo validado. Captou? Até!

Hoje estava navegando pelo BlogBlogs e me deparei com um banner no canto da tela: “Ofereça seu feed COMPLETO!”. Curioso que sou, cliquei. O resultado foi um post de Rafael Arcanjo: Disponibilize seu Feed COMPLETO!. O post se trata de uma campanha para que os blogueiros brasileiros disponibilizem seus feeds (RSS/Atom) completos, e não somente o sumário, definidos como “martírio”.

Sem nem mesmo pensar muito, apenas na usabilidade, estou aderindo à campanha, e distribuo a a partir de hoje meus feeds COMPLETOS. Sem sumários.

O próprio Rafael coloca no site alguns banners para você colocar em seu blog. O meu já está lá, depois do banner do MDC (recém colocado também): 80×15: Feed Completo. Sim, banners retirados… Agora já passou.

Gostei de ver. Iniciativa muito boa. A análise também. Parabéns, Rafael. Ajude você também, junte-se à essa campanha.

Mas por quê?

Não sou nenhum técnico em usabilidade, mas ouça o que digo: mesmo o seu leitor não visitando seu site toda vez que você disponibilizar um novo post, ele vai le-lo completo, e não o sumário. Como diz o autor da campanha, você não vai perder nenhum leitor, mas sim ganha-los, estreitando a relação entre você e ele. Ele não lerá seu artigo apenas se o sumário for bom.

Não, eu não estou louco, e também não estou dizendo que vou sair por aí beijando todo mundo. Esse KISS que falo é um acrônimo para “Keep It Simple, Stupid”, equivalente a “Mantenha Simples, Estúpido”, em português.

Também não estou chamando ninguém aqui de estúpido, não me entendam mal. Estava programando exaustivamente há horas, e resolvi dar uma passeada pela Internet. Lá pelas tantas, cheguei a um blog através das tags do WordPress, e encontrei esse acrônimo. O significado lá era o mesmo que dei aqui, mas vou dar umas dicas para KISS.

Comente seu Código

Por mais simples que seja seu código, comente-o. Acredite, na maioria das vezes vale a pena.

Há muito tempo você escreveu uma função, digamos, para ler XML e mostra-lo na tela (você anda bem experiente mesmo, neh?). Ou qualquer outra função. Aí você deixa ela paradinha lá na sua pasta de códigos por um bom tempo. Por acaso do destino, você volta a precisar daquela função, que não tem nenhum único comentário. E você também não lembra que tipo de técnica utilizou, e acabou adquirindo mais conhecimento para fazer diferente, e esqueceu de erros que cometia.

Isso seria um desastre. Você perderia vários minutos (ou horas, dependendo do tamanho e complexidade do código) tentando entender o código, para depois começar a trabalhar nele (ou com ele).

A coisa piora quando não é você que mexerá nesse código, o pesadelo duplica, triplica, quatriplica de tamanho. Imagine só.

Comentar um código não o simplifica, mas ajuda no processo. Sabe quando você vai comentar uma parte um tanto confusa? Resumindo: comentários, além de ajudar na compreensão de um código, são detectores de tolices, complexidade extra, excesso de código ou de pura e simples falta de simplicidade.

É claro que em funções simples isso não é necessário. É totalmente contraproducente.

Elimine Linhas de Código

Como tudo na Internet, e em qualquer computador, um caractere ocupa seu espaço. Uma linha também. Uma linha com caracteres então…

Linhas em branco e tabulações são importantes, mas há lugares em que são desnecessários. Não pule muitas linhas entre um bloco de código e outro, duas ou três é o suficiente.

Mas não é exatamente sobre essas linhas que falo. Vamos tomar como exemplo o nosso querido JavaScript. Podemos resumir blocos de código, como IF ELSE:

// "Errado"
if( condition ) { umaUnicaLinha(); }
else { outraLinha(); }
// Certo
if( condition ) umaUnicaLinha();
else outraLinha();
// Mais Certo Ainda - Expressão ternária
condition ? umaUnicaLinha() : outraLinha();

Entendeu? Viu quantos caracteres economizamos? Esses blocos podem ser resumidos se tiverem apenas uma linha, dispensado as chaves. E condições ternárias podem ser mais resumidas ainda.

Outra maneira de economizar código é diminuir tarefas repetitivas. Se você já fez um curso mais avançado de MS Word ou Excel, sabe disso (macros). Por exemplo, várias condições devem ser testadas várias vezes da mesma maneira. Em vez de colocar o teste por inteiro, criamos funções! Lógico, não? Isso deve vir desde o planejamento do script.

Em suma, aproveite todos os recursos da linguagem em que você programa para torna-la mais rápida, compacta e simples. Estude bem o que você programa.

Use Indentações

Com o código que economizamos ali acima, podemos usa-lo para tornar o código mais legível.

As indentações servem para identificar em que nível alguma instrução se encontra. Não precisam ser indentações muito grandes, dois espaços são o suficiente. Um só dificulta a compreensão de muitos níveis, e tabulações (tecla TAB), em caso de muitos níveis, tornam difícil de ler, pois tiram o código mais indentado do campo de visão do editor.

Indentar é extremamente simples, mas se torna chato às vezes. Por isso, um bom editor ajuda, mantendo as indentações no lugar depois de um Enter.

Se você já viu o código padrão do Invision PB, deve saber do que falo. Aquilo é incompreensível. Tudo fica na mesma linha, no mesmo nível. Faça o possível para tornar seu código, acima de tudo, legível para você, depois para os outros, e depois para as máquinas. Acredite, facilita bastante.

Nomeie Corretamente

Essa parte foge um pouco do tema principal, mas já que estou dando umas dicas…

Procure dar nomes intuitivos às suas funções, atributos, blocos de código, enfim… O Diego Eis, do Tableless, escreveu um artigo muito interessante sobre nomear classes corretamente. Esse artigo pode também ser aplicado a qualquer coisa, que já citei a pouco.

Dê nomes intuitivos para tudo que criar. Esses nomes devem ter algo a ver com o que você criou, e não onde está posicionada ou o que faz apenas, e somente apenas no que resulta em uma única condição (por exemplo: uma função Ajax complexa que retorna XML e texto, ser chamada de AjaxText, isso é errado).

Poderiam ser citados vários outros pontos, mas eles fugiriam um pouco mais do que quero aqui. Em resumo, o que vale é a simplicidade, legibilidade e total e completa compreensão por humanos, pessoas, gente, nós, enfim…

Esse é outro daqueles assuntos simplíssimos e que pouca gente se dá conta. Eu mesmo não me dei conta até prestar bem atenção no site do JSON e apenas um título de um artigo: “Validando seu JSON”, que nem cheguei a ver o autor.

Validar JSON? Existe isso? Tecnicamente sim. Não existe nenhum validador para ele, e também não provoca erros se ele não estiver validado (ainda não provoca, é como XHTML servido como text/html). Há uma grande probabilidade de você nunca ter ouvido falar nisso aí.

No JSON in JavaScript, existe um pequeno exemplo, que aqui transcrevo:

var myJSONObject = {"bindings": [
		{"ircEvent": "PRIVMSG", "method": "newURI", "regex": "^http://.*"},
		{"ircEvent": "PRIVMSG", "method": "deleteURI", "regex": "^delete.*"},
		{"ircEvent": "PRIVMSG", "method": "randomURI", "regex": "^random.*"},
	]
};

Preste atenção nos nomes dos membros. Eu mesmo fazia certo no início, mas depois de ver em algumas aplicações maiores, que não usavam um certo recurso, comecei a fazer errado, achando que poupava mais código (e realmente poupa, mas fica errado, POG, com certeza).

Tente descobrir esse “certo recurso”. As aspas duplas. Nos valores elas são obrigatórias (quando se tratam de strings, lógico), mas nos nomes dos membros não. Apesar de ficar errado, não acontece nada de errado, pelo menos que eu já tenha visto. Não são aspas simples, não são “aspas invisíveis”, são aspas duplas!

Não sei exatamente qual a lógica disso. JSON no PHP, eis a resposta! Sabendo ou não qual a lógica, está errado sem as aspas duplas! Aí vai do bom senso do programador: ser ou não ser? E aí fica a questão…

Nos últimos tempos, com a iminente web 2.0, fala-se muito em acessibilidade: motores de busca, deficientes, equipamentos precários ou dispositivos móveis, e uma infinidade de outras coisas.

Por incrível que possa parecer, a grande parte dos desenvolvedores torna suas aplicações utilizando Ajax completamente (ou quase completamente) inacessíveis, principalmente para os motores de busca.

Como os motores de busca não lêem JavaScript, como eles encontrarão o conteúdo de seu site, se ele for feito completamente em Ajax? E os seus usuários, como irão “favoritar” algum artigo que gostaram, se não há links?

Como já disseram, e eu repito, use ajax com moderação. Mas se você ainda deseja utiliza-lo ao extremo, seja por modismo, necessidade ou mesmo para se mostrar para os amigos, vamos tornar isso tudo acessível.

Antes de Tudo…

Como o Micox já disse em seu artigo, você deve planejar todo seu site como se Ajax não existisse. E eu estendo um pouco: planeje seu site como se nem o JavaScript existisse. Mais acessibilidade ainda? Planeje seu site como se CSS não existisse. Não, não estou louco. É possível, bem difícil, mas é possível. Essa é a grande sacada do desenvolvimento em camadas: primeiro o conteúdo, depois a apresentação e por último o comportamento.

Tá certo que hoje em dia são poucos os navegadores que não suportam CSS, mas nunca se sabe. Já o JavaScript é bem complicado mesmo.

Links

Primeiro de tudo: Ajax não veio para reinventar o link. O link é a alma da web. Mas podemos incrementa-lo, lógico. Utilizando o conceito de que você deve pensar em sua página como se JavaScript não existisse, o href não pode ser deixado de lado. Trocar o href de uma página por “javascript:” é suicídio. E pior ainda: trocar por “#alguma-coisa”. Se o usuário não tiver o JavaScript ativo, adeus pra seu site.

Então, como fazemos? Deixe o href como o link verdadeiro para suas páginas, sem ajax, sem javascript. E aí, no onclick, use:

ajax.request(...); return false;

Com o tempo a gente acaba descobrindo coisas interessantes: onclick não é a melhor maneira para capturar links. Leia: Hijax: Ajax Acessível

Isso fará com que, depois de clicado, o link apenas ative o JavaScript desejado, retornando false, para que não aconteça mais nada.

E quanto ao nosso querido hash? Sim, há lugar para ele também. Depois de toda a ação do JavaScript, antes de terminar sua função, inclua: top.location.hash = .... Simples, rápido e indolor.

Costume dos Usuários

Convenhamos: a tecnologia chega, mas nem todos estão preparados para ela. A maioria dos usuários está acostumado a esperar o “loading” do browser, e não dentro da página. Isso é um problema. Se você esquecer do seu “Carregando…”, o usuário pensará que a página travou, parou de funcionar, deu tilt, já era, babaus, enfim. Uma imagem que se mexe ajuda a dar a impressão que algo vai acontecer.

Outro costume dos usuários é o famoso botão voltar. Já postei aqui no blog uma solução para histórico. Não esqueça dela, torne-a melhor, se for o caso.

Várias requisições ao mesmo tempo

Nem todos sabem, mas os que já sabem se irritam bastate. Quando se clica em um link e, instantaneamente, se muda de idéia e clica em outro, a página vai para o último link clicado. Em ajax isso costuma não acontecer. Só a primeira requisição é carregada (nem sempre, claro). Já tive essa desagradável experiência. Coloque uma “fila de espera” para as requisições, para ocorrerem em ordem, ou para requisitar apenas o último clique. Cada uma das soluções se aplica a um caso em particular, não é uma receita específica para todos os tipos de bolo.

Bem, existem vários outros problemas relacionados a acessibilidade, mas já solucionamos os mais “críticos” (outras idéias podem ser encontradas aqui). Vai do bom senso de cada um tornar seu site compatível e acessível. Contribua para o verdadeiro espírito da Web 2.0!