Linguagens de programação e frameworks de desenvolvimento surgem aos montes no ambiente web. De uma maneira ou outra, nossas velhas ferramentas acabam se tornando obsoletas. Por mais que tenhamos domínio sobre elas, o rendimento não se equipara a novas ferramentas, seja em produtividade, desempenho, facilidade de uso ou qualquer outro fator. Será que é hora de abandonar nossa velha forma de desenvolver para dar lugar a novas ferramentas?

As ferramentas com as quais estamos acostumados, como o PHP, por exemplo, foram criadas para resolver os problemas que tínhamos à época em que foram criadas, baseando-se nos métodos dessa época. Elas têm nos servido muito bem, e provavelmente ainda poderão servir por algum tempo mais. Mas a web muda, e as exigências quanto ao desenvolvimento nesse ambiente também. Não basta mais resolver um problema, esse problema deve ser resolvido de forma rápida e eficiente. Com a correria de hoje em dia, só PHP não basta mais.

Com o tempo, além de recriamos soluções para velhos problemas, novos problemas vão surgindo. A web não é mais um ambiente minúsculo como era há alguns anos atrás. Ela cresceu. Cresceu muito. A demanda por serviços, e por serviços cada vez mais rápidos é muito maior do que antes. Criamos novos problemas e precisamos de soluções para eles. Nossas antigas ferramentas não estão preparadas para tanto.

De uma forma ou outra, precisamos ser ágeis. Os frameworks estão aí para ficar. Como o capitalismo nos obriga a produzir em velocidade insalubre, somente uma boa linguagem de programação também não basta. Precisamos ser rápidos, muito, muito rápidos. Mesmo para linguagens não tão recentes, já existem soluções ótimas. Há vida além do Rails e Django!

Embora essas novas tecnologias sejam fascinantes, há um pequeno problema. Uma nova ferramenta leva a uma curva de aprendizado. Isso toma tempo, “tempo de processamento”, enfim, nos tirar de nossa zona de conforto. A questão é: devo eu partir pra outra? A minha resposta é: depende.

Tudo é relativo, e não há uma resposta pronta para esse tipo de pergunta. Você pode se sentir realmente confortável com certa linguagem, e conseguir ser extremamente produtivo com ela, ao passo que, mesmo conhecendo bem outras ferramentas, não consegue manter o mesmo ritmo. Nesse caso, sempre existem os frameworks. Não é necessário “reaprender a programar”, e ganha-se o benefício de um desenvolvimento mais rápido. Nesse caso, mudar de ares não é algo sensato a se fazer, principalmente se você tem um tempo escasso.

Já se você consegue ser produtivo em várias linguagens, opte por aquela mais moderna e robusta, ou continue buscando algo novo. Assim tem-se o benefício da versatilidade: não importa a ferramenta, importa saber fazer.

Meu caso é um pouco diferente. Apesar de trabalhar diariamente com PHP, nunca gostei da linguagem. Parece-me mais uma biblioteca de funções do que uma linguagem bem estruturada. Quando fui apresentado ao Ruby, me rendi. Apesar de não ter me aventurado muito ainda, é o que pretendo seguir. Não tanto por produtividade, nem tanto por “moda”, mas por gosto. Não deixa de ser um motivo válido…

Tenho certeza que esse assunto dá uma boa discussão. Qual sua opinião? Fixar-se em uma ferramenta e especializar-se nela, ou procurar algo diferente que melhore sua forma de trabalhar?

A Mootools é realmente surpreendente, tem de tudo mesmo. É hora de conhecer o componente Slider, para fazermos barras de rolagem com JavaScript.

O Slider

Antes de começarmos a brincar com os controles de rolagem postos em nossas páginas, devemos antes criar a estrutura do HTML. Precisamos de dois elementos: um slider (o container) e um knob (o controle). Vamos usar duas divs aninhadas:

<div id="slider">
  <div id="knob"></div>
</div>

Logicamente, também devemos estilizar esses elementos, para que eles se pareçam, mesmo que remotamente, com um slider. Eu optei pela configuração mais simples possível:

#slider{
  background: #000;
  width: 200px;
}
#knob {
  background: #f00;
  width: 20px;
}

Pronto! Ele já está lá, não se movendo de jeito algum, mas está lá.

Movendo o Controle

Para que possamos mover o dito cujo, vamos instanciar a classe Slider, que faz todo o trabalho sujo para nós. Essa classe recebe três parâmetros: o container, o controle e as opções para o slider. Como queremos um simples slider comum e sem graça (por enquanto), vamos omitir o terceiro parâmetro.

var slider = new Slider("slider", "knob")

Difícil, não? Já temos um slider funcional! Aliás, quase funcional, ele não faz mais nada além de se mover. De que adianta um slider que só se move, e não retorna sua posição? Calma, chegaremos lá.

Adicionando Funcionalidade

Através da opção onChange, podemos fazer algo com a posição do slider. Pode-se atualizar um campo com a posição atual, mudar o tamanho/posição de alguma coisa na tela, enfim, não sou muito criativo, você pode ir bem mais longe que isso.

Para essa opção, devemos passar uma função que receberá como parâmetro a posição atual do slider. A partir disso, podemos fazer qualquer coisa com ele. Veja:

var slider = new Slider("slider", "knob", {
  "onChange": function(pos) {
    $("div-qualquer").setHTML("Posição do Slider: " + pos)
  }
})

É lógico que esse é o uso mais simplório possível. Fiz algo nem tão sem graça assim, veja nos exemplos. Aumenta fonte, diminui fonte… Dá pra fazer mais que isso sim, e muito.

Outras Opções

A Mootools também nos deixa mais algumas opções para incrementarmos nosso slider. São elas:

• steps: Indica o número de “steps” que o slider terá. Por padrão é setado como 100.
• mode: “vertical” ou “horizontal”. Define o modo do slider.
• offset: Recuo do controle em relação ao container.
• onComplete: função a ser executada quando o controle for soltado. Não recebe parâmetros, então é necessário usar o método getPos caso seja necessário utilizar a posição.

Ficou feio?

Aqui apliquei somente o estilo básico para o slider funcionar. Você pode se divertir com CSS, e torná-lo muito mais atraente. Nos exemplos mostrei meus estupendos talentos em design e criei algo mais interessante aos olhos do usuário.

Vou ficando por aqui, até mais!

De longe, um dos maiores problemas no uso de Ajax é a acessibilidade. A facilidade em atualizar apenas uma parte da página tornou os desenvolvedores menos preocupados com a acessibilidade de seus projetos. Sem JavaScript, sites inteiros tornam-se completamente inacessíveis. Então, qual a solução para esse problema?

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?

Centenas de projetos nascem todos os dias, idéias não páram de surgir. São vários começos que se acreditam extremamente promissores, mas na realidade são poucos os projetos que sobrevivem ao entusiasmo inicial e duram algum tempo, e mais raros ainda aqueles que chegam ao sucesso desejado. Por que tantos projetos “morrem” tão cedo, sem ao menos perseverar?

Começar é fácil…

Não é difícil começar um novo projeto, todos sabem. Basta uma boa idéia e algum tempo de dedicação e voilá, temos um projeto. Movidos a entusiasmo inicial e projeções de futuro, os desenvolvedores avançam rapidamente em um curto espaço de tempo. Geralmente a comunidade ao redor apóia, comenta, vibra com as conquistas. Todo projeto começa assim, ou pelo menos parecido.

E se o tempo encurta?

O projeto vai muito bem, até que o tempo dos desenvolvedores começar a encurtar. Acredito eu que esse seja um dos maiores fatores que auxiliam a desistência de um projeto. É impossível levar adiante algo que atrapalha em outras tarefas mais essenciais. Eu sofro um pouco com isso, não sou um dos melhores administradores de tempo que existe por aí.

Mais interessante, melhor!

Outro problema comum é o aparecimento de outros projetos mais interessantes. Pode ser por uma simples mudança de interesses, ou então o desenvolvedor enjôa de seu querido projeto. E também, por que não, simplesmente quer abandoná-lo. Como o Pedro Simonetti disse, desenvolvedores são criteriosos, e tendem a migrar de um projeto para outro quando lhes dá na telha.

A Comunidade

Apesar de todas as dificuldades, há algo que pode salvar um projeto, avançar seu desenvolvimento, levá-lo ao sucesso. E a falta desse “algo” pode levá-lo ao total fracasso. A comunidade sempre está presente quando o projeto é lançado, mas não são tantos que a mantém por perto mais tarde. “Sem usuários, não há projeto que resista”, ainda mais quando se trata de um projeto que depende do social, como todo bom serviço web 2.0. Os usuários e seu interesse pelo projeto são seu combustível, injetando entusiasmo nos desenvolvedores. Quando a comunidade some, não há motivo para continuar algo que certamente será esquecido, dependendo da força de vontade dos mantenedores. Em compensação, uma comunidade presente e ativa pode salvar e transformar um projeto em um sucesso.

A Salvação

Existem duas maneiras de manter um projeto ativo: muita força de vontade ou uma comunidade ao redor. O primeiro depende única e exclusivamente do desenvolvedor. A segunda, varia… A idéia é manter a comunidade por perto a qualquer custo, e aumentá-la o quanto possível. Não que seja algo fácil, mas algumas dicas que considero importantes:

• Inove. Pessoas gostam de algo novo. Se você ficar apresentando sempre a mesma coisa, perderá a graça, e o pessoal irá embora. Uma nova funcionalidade, um novo visual, algum membro novo na equipe (principalmente se for alguma autoridade no assunto), qualquer coisa para manter a atenção no que você faz.
• Qualidade. Não adianta apresentar algo novo se o que já existia não funciona. Bugs, defeitos ou incosistências, acabe com eles assim que possível!
• Ouça! Você não precisa se tornar um escravo de seus usuários, mas ouça suas sugestões. Mesmo que você nem cogite aceitá-la, explique o porquê. Também não negue todos os pedidos, pois os usuários devem ser os beneficiados.
• Use! Você precisa mostrar que está usando seu próprio projeto. Parece óbvio, mas nem sempre acontece. Lembre-se: você deve dar o exemplo!
• Seja citado. Convide pessoas conhecidas no meio para usar seu projeto. Provavelmente ele receberá uma citação. Isso é extremamente positivo. Se você for indicado por outras referências na área, quer dizer que algo de bom seu projeto tem.

E você, já deixou algum projeto morrer? Ou conseguiu salvá-lo da obscuridade? Conte seus métodos! Até mais!

Saiu! O CodeCast #4 finalmente saiu! Atrasado, mas saiu. Apedrejado pelos mais standardistas, amado pelo pessoal que gosta de interatividade, o Adobe Flash foi o assunto dessa edição.

Falamos um pouco sobre sua história, ActionScript, dos seus prós e contras, um pouco sobre o Flex e o flash-killer da Microsoft, o Silverlight. E é claro, nossa mais recente experiência com o bichinho que, diga-se de passagem, está sendo muito divertida e proveitosa.

Pra quem ainda não conhece, e pra todos que quiserem ouvir, é só acessar o site do CodeCast e baixar. São só 30 minutos, em 14MB. Até mais!