Ninguém está livre de um desastre. A qualquer momento seu HD pode queimar, seus arquivos podem ser infectados por algum vírus, algum raio pode cair em cima de seu computador, ou até mesmo o seu servidor de hospedagem pode explodir (pergunta, vai!). Esse é o tipo de coisa que ninguém espera, e não há como dizer “hoje vou perder todos meus arquivos, é bom fazer uma cópia”. O destino é cruel e impiedoso, principalmente com os descuidados.

A maneira mais eficaz, e também mais sensata, é sempre manter um backup de seus dados importantes. É bom sempre fazer isso com uma certa regularidade. Backups diários podem ser custosos e até impraticáveis em certos casos, então realizá-lo uma vez por semana já parece suficiente. Por pior que seja a catástrofe, você sempre terá para onde correr.

Mantendo cópias regulares, com certeza em pouco tempo você terá uma quantidade enorme de dados armazenados. Aí o jeito é organizar! Manter uma lista dos arquivos copiados, data de gravação, enfim. Não adianta TER os dados e não saber onde encontrá-los. Pode acreditar, essa sensação é ainda pior.

Por que esse texto estilo sermão? Eu explico. Semana retrasada, uma explosão no data center H1 do The Planet derrubou uma montanha de servidores (e três paredes, segundo me consta), e eu estava em um deles. Antes que eu ficasse sabendo de mais informações, se abateu o pânico: eu não tinha um backup. Por sorte não houve perda de dados, mas já foi o suficiente para abrir o olho, e ser um pouco mais cauteloso. Nem mesmo armazenados remotamente nossos dados estão seguros.

Um pequeno esforço que pode salvar muito retrabalho, e até sua vida, dependendo de quão dependente ela seja de seu trabalho. E você, mantém um backup? Nem que seja mensal, apenas de trabalhos correntes, ou o que quer que seja importante para você guardar?

Posts Relacionados

• PC formatado, e agora?
• Tragédia
• A Aplicação Ajax Perfeita
• Comodismo vs. Inovação
• 7 coisas que todo desenvolvedor web deveria saber

Para evitar que o caos venha a este mundo, surge outra palavrinha: Hijax. Mas primeiro vamos voltar a algumas premissas do desenvolvimento web: aprimoramento progressivo (progressive enhancement) e degradação elegante (graceful degradation), e me desculpem se errei a tradução dos termos…

Aprimoramento Progressivo – Primeiro o Conteúdo

Ninguém começa (ou pelo menos não deveria começar) a desenvolver uma aplicação primeiro pela camada de comportamento, isso vai completamente contra a filosofia de desenvolvimento em camadas (primeiro o conteúdo, depois a apresentação e, por último, o comportamento).

A idéia é começar o desenvolvimento de baixo. Em outras palavras, desenvolva da maneira antiga, usando links como sempre se usou desde que a Internet é Internet, devolvendo páginas inteiras como resposta. Depois, somente depois, comece a adicionar funcionalidades que melhorem a experiência do usuário (nada de frescuras que o usuário só vai achar bonito, pra que reinventar o link?).

Degradação Elegante – Útil sem perder a elegância

“Degradação elegante” significa perder alguns recursos sem perder suas funcionalidades. Pode-se perder algumas animações e outros fru-frus, mas perder acesso ao conteúdo é inadmissível. CSS não é tão importante quanto as informações que queremos mostrar. Nunca ouviu a frase “mais ajuda quem não atrapalha”? A idéia é a mesma.

O desenvolvimento progressivo e em camadas é o caminho mais rápido para a degradação elegante. Mesmo utilizando Ajax, o conteúdo ainda deve continuar acessível através de um link comum. É aí onde Hijax entra.

Hijax – Seqüestrando os Links

O próprio termo explica bem o uso da técnica. Hijax, do inglês hijack (“seqüestrar”), quer dizer seqüestrar os links comuns, e transformá-los em links Ajax. Simples assim.

“Simples assim”? Bem, nem tanto, eu confesso. Seus scripts server-side precisam estar preparados para decidir se enviam o “pacote completo” ou a “versão básica” da página, se for uma requisição normal ou uma requisição assíncrona, respectivamente. Uma breve dica: header X-Requested-With. Duas versões do site? Nunca mais, isso morreu junto com o Netscape, há muito tempo.

Vale lembrar que somente o uso de Hijax não faz uma aplicação completamente acessível, usável e rica. Há muito mais a se pensar. Já falei sobre alguns aspectos para uma boa aplicação Ajax, mas tenho absoluta certeza que não passei nem perto de tudo que é necessário. Mas tudo isso já é uma boa base a ser levada em consideração, e com isso já é possível criar algo melhor que muita coisa que existe por aí, tenha certeza. E você, tem feito seu dever de casa e seguido princípios para tornar sua aplicação disponível a todos?

Posts Relacionados

• Ajax vs. Acessibilidade
• Ajax vs. Moda vs. Performance
• A Aplicação Ajax Perfeita
• Fila de Requisições em Ajax
• Ajax com a Mootools

Não que essa idéia fosse “a aplicação ajax perfeita”, mas sim a ideal. Demoraria muito a ser feita, mas eu consideraria uma obra de arte.

Padronização

Essa parte é a parte fácil, que todo mundo sempre deveria se dar ao trabalho de fazer: manter seu trabalho dentro dos web standards.

Validar sua marcação, seus CSSs, isso todo mundo faz (ou deveria). Mas às vezes um certo item é deixado de lado: seus XMLs, que não causariam muito problema, a não ser um XML em especial: os feeds. Ou seja, valide tudo que possa ser validado.

Manutenção

Código bom é código comentado. Disso ninguém discorda. Sempre comente seus códigos, tanto para seu uso em futuras manutenções e atualizaçãoes, quanto para seus visitantes que querem descobrir o segredo daquela técnica inovadora que você implementou. JavaScript ninguém esconde, e uma técnica nova deveria poder chegar a todos que quisessem, mesmo que seja investigando seu código. Melhor ainda se ele estiver comentado, mesmo que seja somente em partes mais obscuras.

E o tamanho do código não aumentaria? Sim, mas você só precisará comentar partes essenciais, aquelas mais complicadas que você sabe que irá esquecer com o tempo. Além do mais, se você esquecer de seu código, perderá muito tempo até lembrar o que cada parte faz.

Compatibilidade

Outra parte facílima, mas indispensável. Se tudo for seguido, nem tanto, mas ainda assim se torna muito mais agradável usar uma aplicação que funcione como deveria funcionar.

Com todas as opções de browsers existentes hoje, sempre haverá aquele que terá problemas (geralmente o azulzinho que todo mundo já conhece). Mas existem maneiras de amenizar o problema. Isso não só com Ajax, mas qualquer “defeito” de JavaScript e CSS que possa atrapalhar a experiência do usuário.

Essa parte pode, sem problemas, ser deixada para os frameworks já existentes, que fazem seu trabalho muito bem. A compatibilidade vem sendo muito focada por essas bibliotecas, facilitando, e muito, seu trabalho.

Controle de readyStates

Agora começa a parte divertida. Tudo que está logo acima qualquer um faz. Vamos começar adicionando nossos diferenciais.

Geralmente, costuma-se cuidar de apenas dois readyStates: 1 e 4 (aberto e carregado), que resultam no clássico “Carregando…” e a requisição completa. Não que seja necessário, mas um controle completo de estados poderia ser bom.

O usuário saber que sua requisição está sendo processada ajuda, já que não pensaria que a requisição travou (isso acontece bastante quando a requisição demora demais).

Coloquei os readyStates, o que significam e uma sugestão para o texto de carregamento. Os readyStates 0 e 4 não precisam disso, já que 0 não tem muito uso, e 4 terá sua própria função.

• Não Inicializado (0)
• Aberto (1): “Abrindo Requisição” ou “Iniciando Requisição”
• Enviado (2): “Enviando Dados”
• Recebendo (3): “Carregando” ou “Recebendo Dados”
• Completo (4)

Não que seja necessário, mas também seria válido cuidar dos status da requisição também, pelo menos 200 (OK), 404, 500, e os outros erros mais comuns.

Histórico

Esse é o maior problema das aplicações Ajax. Já faz tempo que as primeiras soluções para histórico apareceram, e outras melhoradas, e ainda há centenas de aplicações que não se dão ao trabalho de implementar qualquer das soluções.

O histórico sempre deve ser implementado, mesmo que sua aplicação não queira dominar o mundo.

Cache

O cache, considerado uma praga por muitos, pode ser de uma grande ajuda para sua aplicação. Sempre que se faz uma requisição estática (que não muda em pouco tempo), deve-se usar o cache, pois quando refizermos essa requisição, ela terminará mais rápido.

Além do mais, usando o histórico, podemos guardar requisições “cacheadas” no próprio JavaScript. Assim, mais rápido ainda.

É claro que, em requisições dinâmicas, não devemos usar essa técnica. Ela pode prejudicar o usuário, pois não há maneira de atualizar a página através do F5.

Filas de Requisição

Todos sabem que se quando uma requisição estiver em andamento, e outra for iniciada, a primeira será cancelada.

Assim como o histórico, já existem milhares de soluções diferentes para fila de requisições. Esse recurso deve também ser usado sempre que possível (ou seja, sempre). Isso pode evitar aborrecimentos ao usuário.

Inobstrusividade

Essa é a questão mais polêmica. Sua aplicação não deve usar JavaScript obstrusivo (ou usar o menos possível), fazendo-a de maneira que funcione corretamente em qualquer browser.

E o Ajax sem JavaScript, como fica? Também tive idéias mirabolantes quanto a isso. Você deve usar o mesmo script server-side tanto para requisições assíncronas (Ajax) quanto para as síncronas (me refiro àquelas via browser). Para isso, usamos aquele header X-Requested-With, que seu server-side deve identificar.

Dessa maneira, não “trancamos” o conteúdo nem ao usuário nem aos buscadores e afins. Benefícios ao usuário e a você (e ao seu bolso, se for o caso).

Lembre-se de tornar o conteúdo Ajax-less atrativo aos olhos do usuário também, usando o mesmo layout do resto da aplicação (ou a mesma estrutura, caso seja XML).

Desempenho

O desempenho é outra característica muito essencial. Em tráfego de dados muito grande, devemos tomar cuidado com o JavaScript. Muito XML gera muitas chamadas ao DOM, e isso leva tempo. Aí o JSON entra em cena.

O Profiler do Firebug pode ser muito útil, já que ele monitora o tempo de execução da sua aplicação e das requisições que ela faz.

Bem, é isso. Quem sabe um dia veremos uma aplicação destas. Estou trabalhando em uma função que faça boa parte disso, espero que consiga terminar. Fui!

Posts Relacionados

• Hijax: Ajax Acessível
• Ajax vs. Acessibilidade
• Fila de Requisições em Ajax
• Ajax vs. Moda vs. Performance
• Ajax: Requisições HEAD

E foi assim que tudo aconteceu… Lá estava eu, feliz da vida, recuperando o backup no meu pen-drive 0km. Terminei tudo e desliguei o PC. Normal, quem não desliga o PC de vez em quando? O problema aconteceu quando eu voltei.

Após todo o desespero, chutes nas paredes, palavrões e outras coisas que geralmente não se costuma fazer, o PC foi pra chave de fenda. Uma semana (e um dia) depois, o PC estava de volta. Procura daqui, procura dali e nada do DVD de backup (que já era antigo, não iria ajudar muito). Não era nem pelos dados, eles já estavam no HD, a meu pedido. O problema foi com os programas: apesar de pirateados (eu sei, eu sei), não tinha o CD de alguns.

Crianças, sempre mantenham um backup atualizado. Até agora estou correndo pra arrumar uma cópia emprestada (tá bom, já sei, já sei) de alguns programas.

Mas como todo feliz usuário de HD com Windows zero bala, eu tive meus benefícios. Apesar de ter instalado o Windows XP SP2 (antes eu usava o SP1), tudo está rodando mais rápido que de costume, e não apresenta aqueles erros comuns do Windows “mais passado”.

Mas o melhor de tudo, no meu caso, são as atualizações. Como uma atualização gera uma enorme dor de cabeça, eu não costumo fazê-la. Mas minha <sarcasmo>querida</sarcasmo> assistência técnica fez o trabalho sujo por mim. Tudo novinho em folha. O único problema foi com Apache+PHP+BD, já que eu nunca acerto a instalação de primeira, mas dessa vez foi culpa do auto-instalador.

Fechando o balanço, odeio formatar o PC. Mesmo com os benefícios. Os efeitos prolongam-se por muito tempo (sempre tem aquela hora que você vai tentar abrir um arquivo que não está associado…). Mas aprendi a lição (aliás, duas, antes que me torrem a paciência): compre programas originais, aí você se obriga a guardar os CDs, e mantenha sempre um backup atualizado. Tá certo que sai caro comprar um DVD todos os dias, mas duas vezes por mês já serve pra salvar sua pele.

Agora, voltamos com nossa programação normal.

Posts Relacionados

• Não validou. E agora?
• Backup: Um Salvador de Vidas
• Tragédia
• Pra quem você escreve?
• Codificação de Caracteres

Vamos à uma discussão rapidinha. Pense: vale a pena escrever uma montanha de código JavaScript, correndo o risco de ficar completamente inacessível para alguns browsers, quebrar a cabeça, fazer algo bonitinho que demora o dobro pra carregar, sabendo que você podia escrever uma (uma só, nada mais, sem exagero) única linha? É o caso do pessoal que faz todos os links usando Ajax.

E não é só isso. Há muita coisa que poderia ser evitada. Carregar páginas quase inteiras, pequenos textos estáticos (babem…), outras coisinhas irritantes que pulam na tela… Quer que eu prove que não melhora a performance? XML HTTP Performance and Caching. Creio que posso te convencer.

Descartando a acessibilidade por enquanto. Um site que use Ajax, pra ser mais útil e mais rápido, precisa de muito planejamento. Um ótimo exemplo de planejamento é o Gmail e Google Reader. Inclua a acessibilidade: ainda temos o Google na frente (Gmail sem Ajax também existe). Uma boa discussão sobre isso também rolou lá no Ajax Online.

Apesar de tudo, ainda acredito que já evoluímos muito, e estamos evoluindo. O Ajax no Brasil já amadureceu bastante (até o Ajax Online abandonou a versão 100% Ajax, evolução). Ainda temos muito a progredir, e vai demorar, eu sei, mas não podemos parar. Graças a muita gente já temos trabalhos bons. Agora queremos trabalhos ótimos, basta amadurecer a idéia.

Esta é a minha opinião, não tomem como certa. Apenas pense sobre isso, concorde ou não. Até!

Também já havia falado sobre essas algumas questões relacionadas a Ajax em Ajax vs. Acessibilidade. Também falei sobre A Aplicação Ajax Perfeita, que pode colocar algumas minhocas em sua cabeça…

Posts Relacionados

• Hijax: Ajax Acessível
• Ajax vs. Acessibilidade
• A Aplicação Ajax Perfeita
• Fila de Requisições em Ajax
• Ajax: Requisições HEAD

Preparação

A fila de requisições baseia-se em uma variável (lógico). Usaremos um simples array:

var fila = new Array();

Precisaremos também de duas funções, uma que coloca a requisição na fila, e outra que executa a fila em ordem.

Colocando na Fila

Para colocarmos um item na fila, usaremos a função queueAjax, descrita abaixo.

var queueAjax = function(id, url) {
  // Usando o id, você pode colocar um carregando:
  document.getElementById(id).innerHTML = "Carregando...";
  // Adicionando nossa requisição:
  fila.push([id, url]);
  // Não tendo requisições pendentes, lançamos outra função
  if(fila.length > 1) executeQueue();
}

Analisando: colocamos id e url na fila, de uma forma ou outra. Se não houverem mais que uma requisição na fila, executamos a função executeQueue() (sem argumentos mesmo). Ela se encarregará de todo o resto.

Executando cada Requisição…

Não precisaremos executar cada requisição manualmente (lógico, a fila é pra isso). Usaremos a função executeQueue() pra isso. Neste momento, estou assumindo que você tem a variável xmlhttp configurada como um objeto XMLHttpRequest.

var executeQueue = function() {
  var current = fila.shift(); // Retiramos o primeiro membro do array
  xmlhttp.open("GET", current[1], true);
  xmlhttp.onreadystatechange = function() {
    // Aqui você cuida dos readyStates
    // Quando for 4: (não coloquei o código, poupando espaço)
    document.getElementById(current[0]).innerHTML = xmlhttp.responseText;
    // Tá pronto, e passamos ao próximo item, se houver
    if(fila.length > 0) setTimeout(executeQueue, 100);
  }
  xmlhttp.send(null);
}

Analisando de novo: fazemos nossa requisição como sempre (poupei código, também pra prevenir Ctrl + C e V). Note que tiramos o primeiro item do array, e colocamos em uma variável.
Quando a nossa requisição atual estiver prontinha, e o resultado no lugar, podemos executar a próxima (se houver), sem que precisemos fazer nada.

Usando tudo isso

Pra usar você só vai precisar chamar uma função: queueAjax(id, url), pra cada requisição que você quiser fazer. Nada mais.
Você também pode estender muito mais esse script, colocando opções, tratamento para as saídas… Dê asas a sua criatividade.

Posts Relacionados

• Ajax: Requisições HEAD
• Utilizando o Método POST em Ajax
• Ajax com a Mootools
• Ajax vs. Acessibilidade
• A Aplicação Ajax Perfeita

Em JavaScript existe um objeto chamado Error, que é obviamente uma mensagem de erro. Essa mensagem pode conter também um número. Veja:

var comNumero = new Error(0, "Erro Desconhecido");
var semNumero = new Error("Erro sem número");

Tá certo, isso não faz sentido. Geralmente eu começo explicando assim, é um vício. Mas as coisas começarão a ficar claras.
Quando criamos nossos scripts (para nosso próprio uso), dificilmente eles funcionarão com erros, pois nós sabemos (ou devíamos) o que o script faz e os erros que podem acontecer se não fizermos. Portanto, não fazemos um controle de erros por que não é necessário. Já se criarmos um script para ser distribuído, o usuário pode não saber exatamente o que acontece, e isso fatalmente resultará em um erro, que poderá ser fatal, fatalmente acabando com os planos do pobre coitado. Talvez o usuário não entenda exatamente o que quer dizer os erros do console, resultando em um pequeno problema.
É pra isso que usamos esse controle de erros. Ele pode prevenir uma entrada de dados errada, uma função com algum parâmetro faltando, essas coisas, fazendo com que o script gere um erro antes, com a mensagem que você deseja, tornando tudo mais claro.

Só que há uma situação atenuante: criando um erro não quer dizer que ele aconteceu. Entretanto podemos fazer isso através da palavra-chave throw.

var erro = new Error("Erro Desconhecido");
throw erro;

Isso, no console do Firefox, resultaria: “Erro Desconhecido [nova linha]throw erro;”, ou coisa parecida. Se tivermos um número de erro, a coisa seria assim: “0 [nova linha]Erro Desconhecido”, onde “0″ é o número do erro.
E como testamos se alguma coisa aconteceu errado? Com if, seria o mais lógico. Mas se quisermos saber quando uma função retornou um erro:

try { funcErro(); }
catch(e) { alert("O erro foi " + e); }

try é o que tentamos. catch é quando dá algo errado, usando geralmente e como erro retornado. Também há o finally, que é executado de qualquer maneira no final disso tudo aí.
Como estava sem nada mais interessante pra fazer, criei o código abaixo para criação e retorno de erros, pra deixar o negócio mais abreviado.

var JsError = {
  "Throw": function() {
    this.message = arguments[0] || "Erro Desconhecido";
	this.number = arguments[1] || 0;
	this.error = new Error(this.number, this.message);
	throw this.error;
  },
  "Create": function() {
    this.message = arguments[0] || "Erro Desconhecido";
	this.number = arguments[1] || 0;
	this.error = new Error(this.number, this.message);
  	return this.error;
  }
}

Observação: o número da linha retornado pelo erro é onde o erro foi criado (new Error), e não no throw (pelo menos no Firefox).

Posts Relacionados

• JavaScript Orientado a Objetos – Parte 3
• POO na Vida Real
• JavaScript Orientado a Objetos – Parte 1
• JSON Válido
• Fila de Requisições em Ajax

Seguinte: você entra em um site, como um catálogo (o exemplo usado foi o iStockPhoto). Aí você clica em vários links, lógico. Quando vai voltar para algum, vê algo assim:

Isso é realmente irritante. Você vai procurar, daqui a pouco ou amanhã mesmo em seus históricos, e só vai encontrar o título da página e o nome do site. Chato pra caramba.

A sugestão foi a seguinte: utilizar Title of this page < Section of the Website < Name of the Website. Bem mais útil.

Explicando: não posso mudar aqui, antes que me chamem de chato que não cumpre o que diz. Esse WP não permite, é versão MU. Nesse caso, me guentem até poder pagar um servidor pago… Até!

Posts Relacionados

• Disponibilize seus feeds completos
• Ajax vs. Acessibilidade
• Ajax vs. Moda vs. Performance
• A Aplicação Ajax Perfeita
• Hijax: Ajax Acessível

Um texto muito interessante, onde ele fala que “O blog é meu, faço como eu quero” (mais ou menos assim). Concordo em partes com ele…

Também do Bloglines: Pra quem você escreve?. É um resumo do que eu acho sobre o assunto, mesmo que não tenha sido eu que escrevi…

Minha idéia é a seguinte: sim, você manda no seu blog. É ditadura mesmo, faz o que quiser. Mas o seu site é para os outros (geralmente), e não apenas para você mesmo. Se for para você mesmo, faça exatamente como quiser. O problema é que você escreve para outras pessoas, e não para si mesmo. Nesse caso, por mais abobrinha que seja seu blog, você deve pensar no melhor para o visitante, seja feed completo ou parcial (isso interessa aqui?).

Então, o que você tem a dizer? É pra você ou pro mundo? Fico por aqui, e até a semana que vem, já que vou estar viajando e não vai dar pra postar até 2ª feira.

Posts Relacionados

• Digg pra quê?
• Qual curso devo fazer pra me tornar um desenvolvedor web?
• Qual editor você usa?
• Você sabe Webstandards?
• O que você faz em 4Kb?

A solução? Disponibilizar dois feeds: um resumido, um completo. Infelizmente, se depender do WordPress, vou ficar fora dessa. Estou dando uma olhada no FeedBurner agora, pra ver se a situação se resolve. Se alguém tiver uma idéia, me passe. Já está funcionando o feed parcial também: JulioGreff Parcial.

Na minha opinião, é bem legal essas idéias que surgem. E até concordo com a Bia. Visitei meu blog ontem pelo celular. Levou um tempinho pra carregar, mas estava lá. Meio desconfigurado, mas gostei. E espero que mais gente experimente os dispositivos móveis (eu só pude experimentar mesmo, não tenho dinheiro suficiente para grande tráfego de dados mesmo).

Enfim, está dada a largada para mais uma corrida de acessibilidade! E lá vou eu ver o que posso fazer…

Posts Relacionados

• Disponibilize seus feeds completos
• Meus Feeds Favoritos
• Tag: Objetivos para 2007
• Ajax vs. Acessibilidade
• Estatísticas para Navegação via JavaScript