Outro dia, um grande amigo me perguntou como fazia para automatizar o teste do Javascript desenvolvido em vários browsers. Para ser bem sincero, eu não utilizo nada além de vários browsers diferentes instalados em cada uma das minhas máquinas (virtuais ou não), cada uma com um sistema operacional diferente  (Ubuntu 10.10 e 11.04 , Windows XP, Vista e 7 e carente de um Mac por enquanto…).

Realmente, mesmo usando o Synergy e uma boa configuração de rede local, ainda fica um pouco trabalhoso… Então resolvi pesquisar algumas ferramentas que poderiam ajudar nessa árdua tarefa, e creio que muitos vão agradecer pelas dicas e até colaborar com dezenas de outras nos comentários. Nem todas visam automatizar o teste em escala, mas todas vão facilitar alguma fase dos testes para que seus projetos tenham um excelente resultado

BrowserShots

Essa ferramenta vai mostrar pra você como seu site irá “renderizar” em diversos browsers diferentes, sem que você os tenha instalado, permitindo que você identifique problemas de compatibilidade mais rapidamente (principalmente se você se valeu de javascript para trabalhar estilos/css)

ScriptCover

Recém-lançado pelo Google, essa ferramenta fornece estatísticas de cobertura de código linha-a-linha, permitindo que você analise (em tempo real até) quantas vezes uma determinada instrução foi executada durante o uso da página. Essa extensão do Chrome funciona desde o instante inicial de carregamento da página e continua enquanto o site vai sendo utilizado, sem atrapalhar o usuário. Excelente  também para debugar códigos complexos, que porventura venham a falhar misteriosamente em algum browser específico (para não dizer logo I.E.).

js-test-driver

Esse framework permitirá que você trabalhe na filosofia TDD (Test Driven Development), integrando-o a sua IDE (Eclipse, por exemplo) para automatizar a execução dos testes tão logo você modifique os arquivos do projeto. Exige uma preparação dos cases de teste, mas já que estamos falando de TDD, isso não será o problema. Confira nesse post a apresentação na época de lançamento onde é demonstrada a praticidade do mesmo.

QUnit, a filosofia jQuery também nos testes

QUnit é um poderoso framework de Unit Test que o ajuda a depurar o código. É escrito por membros da equipe de jQuery, e é o conjunto de testes oficial para este famoso framework. Ele é também o suficiente para testar qualquer código JavaScript regular, e é ainda capaz de testar Javascript server-side, através de algum mecanismo de JavaScript como Rhino ou V8.

Jasmine

Não, você não vai contratar uma estagiária chamada Jasmine para fazer o le-rê-le-rê de abrir páginas e págians em todas as máquinas do seu escritório. É um framework BDD, Behaviour Driven Development, ou seja, desenvolvimento orientado a comportamento. Para quem acha o TDD coisa do passado.

W3C Validator

Não menospreze-o. Alguns acham cafona, outros, nem sequer ouviram falar. Mas pense: se o código está de acordo com Standards, a chance de renderizar igual na maior parte dos browsers também é maior! E também, pode ser um excelente atalho para encontrar algum problema misterioso que não consta nos consoles.

Firebug

Apesar de usar o Chrome a maior parte do tempo, ainda acho a versão Firefox da extensão de desenvolvimento web mais prática e rápida para ajudar no debug, teste e inclusive no desenvolvimento (quem nunca desenvolveu uma linha de código javascript direto no console pra depois copiar e colar no código-fonte que atire o primeiro mouse!)

E você, usa alguma outar ferramenta para facilitar o testes Javascript? Por favor, ajude-nos!

1. Python: A linguagem mestre, sempre liderando qualquer projeto. Curiosamente, até em projetos onde o Python não é a linguagem principal, ele exerce sua influência: estou sempre pensando “Pythonicamente” para resolver problemas, aplicando o Zen que a comunidade e linguagem prega. Não é apenas linguagem: é Filosofia!
2. Django: Nem todos projetos são Web, ou 100% Web. Mas os que atendem a esse requisito, sempre tem esse maravilhoso framework direcionando os trabalhos.
3. Javascript: Para muitos, é algo bizarro. Para mim, que trabalho a maior parte com interfaces e interação do usuário com os sistemas, é a arma. E como já disse para muitos amigos de trabalho: “Para mim, Javascript é o Python rodando diretamente no Browser.
4. jQuery: Muitas vezes esse framework chega a se sobrepôr a própria linguagem. Em muitos projetos, dá até pra dizer que temos “mais linhas jQuery do que Javascript puro”. Mas o que isso quer dizer? Que Web sem jQuery realmente é muito mais difícil e demorado! Gosto tanto do framework que criei até uns plugins
5. Firebug: Se eu tiver de nomear um dos items como minha Shuriken, o Firebug seria sem dúvida! Muito prático, rápido e a ferramenta ideal para “prototipar” qualquer interface. Ainda mais se o cliente estiver do seu lado, esperando uma resposta sua: Você abre o console, algumas linhas e opções depois, você mostra pra ele como pode resolver  o problema… e negócio mais próximo de estar fechado!
6. Mercurial-HG: Devo confessar, antes usava SVN, e quando a vida me exigiu mudar para Mercurial, tive um pouco de resistência. Mas hoje, alguns meses depois, só vejo vantagens, principalmente  após usar os excelentes recursos do Bitbucket e saber que várias boas ferramentas que utilizo, inclusive o próprio Python, tem seu código armazenado por lá, e também que Mercurial é uma ferramenta escrita em Python.
7. Eclipse: Não vou morrer se o Eclipse não abrir… mas vou ganhar várias horas de lazer com algumas praticidades que ele traz: com essa IDE, eu centralizo diversas outras ferramentas, libraries, automatizo alguns procedimentos, debugs, vários ambientes de execução e depuração customizados com fácil acesso… enfim, um verdadeiro Canivete Suíço! Claro, ele tem que estar turbinado com alguns plugins, tais como: Aptana, PyDev, Mercurial, etc.

E assim como outros fizeram, vamos às menções honrosas de outras ferramentas que fazer uma pontinha no ambiente com menos frequência. Percebam que muitas ferramentas são claramente feitas para rodar em Windows, geralmente para suprir necessidades que são padrão no Linux

1. Ubuntu: Companheiro de cada dia! Geralmente uso Windows por conveniência (sempre compro notebooks com Windows original pré-instalado, e dá uma preguiça de instalar e configurar um novo sistema… apesar de que nas últimas versões de Ubuntu esse processo estar facílimo!). Certas coisas na vida de um desenvolvedor só são possíveis num sistema Linux, e Ubuntu é o mestre nesse aspecto. Um exemplo é um projeto recente que estou trabalhando que envolve processamento de vídeo, usando FFMpeg e PyFFMpeg. Praticamente impossível de rodar em Windows… porém, no Linux, é mamão-com-açúcar…
2. Google App Engine SDK: Ferramenta essencial para projetos dentro da plataforma do Google. Quando usando com Eclipse, basta integrar no ambiente ou no projeto e o Eclipse/Pydev faz toda a interface pra você.
3. Putty: Quando não no Linux, uma ferramenta essencial para conectar-se a sistemas remotos.
4. iPython: Mão na roda para agilizar alguns comandos experimentais e em testes (Experimentando o DreamPie também)
5. XAMPP: Outra ferramenta indispensável quando desenvolvendo fora do Linux
6. phpMyAdmin: Muita gente torce o nariz, mas essa ferramenta é muito boa e prática. Só não é melhor por não ser em Python, .
7. Skype: Para conversar com a equipe, clientes, e até fazer pequenos treinamentos
8. DropBox: Backup e compartilhamento entre máquinas remotas. Uso principalmente como backup automatizado do meu ambiente de desenvolvimento remoto e até apaga alguns
9. VMWare Player: Para rodar mais de um sistema de uma vez, permitindo testes (compatibilidade e usabilidade) mais rápidos e práticos
10. VNC / Win2VNC: Também para rodar mais de um sistema de uma vez, mas aqui, para controlar mais de uma máquina com um único teclado e mouse, não para visualização remota (inclusive, acho horrível…)
11. Pencil (Firefox Add-on): Para fazer Wireframes

Para dar continuidade, convido os amigos para seguir nesse trend:

@mauriciosl
@jeanwainer
@ergalassi
@marcelohonorio
@odranoel
@Ericgoes
@marcosriso

E porque não compartilhar esse script para todos aqueles programadores que também fizeram suas apostas?

É bem simples de usar:

$ python megadavirada.py 1245 jogos.txt

Acho que dá pra perceber a sintaxe do comando: 1245 é o argumento que representa o numero do concurso que você quer conferir, o ‘jogos.txt’ o nome do arquivo com suas apostas, seguindo a estrutura:

jose
9,14,16,24,38,45
maria
3,10,32,41,57,60
6,10,21,34,48,52
8,18,19,36,41,58
joazinho
7,13,28,31,43,59

Se você chamar o script sem argumentos, ele vai buscar o concurso 1245 e o arquivo jogos.txt, no mesmo diretório onde está o script. Faça o download através desse link, e aproveite!!! O script tem apenas um pré-requisito, além do Python: a Biblioteca BeautifulSoup. Para instalá-la no Ubuntu/Debian, utilize o seguinte comando:

$ sudo apt-get install python-beautifulsoup

No Windows, basta entrar no site oficial da linguagem e baixar o pacote para instalação. P.S.: Se ganhar, pode fazer uma doação pra mim também! Brincadeiras a parte, quero deixar aqui um Feliz Ano Novo, com mais de 200 milhões de motivos para abraçar cada um dos amigos nessa vida! Saúde e Paz, o resto a gente corre atrás!!!

corMVC é um framework MVC para Javascript, baseado em jQuery. Voltado para aplicações web de uma página só, onde você executa todas suas operações em estilo Ajax, na própria página. Segundo os criadores, é execelente como ponto de entrada para aprendizado da arquitetura de ‘single-page application’ (aplicação de página única, como mencionado anteriormente).

É simples de começar a usar, não necessita de nenhum linha de comando, basta extrair tudo numa pasta e abrir no browser. Estou testando aqui e em breve posto meus comentários a respeito.

Confiram mais detalhes no Artigo, no iMasters.

Nos últimos dias, temos brigado muito por coisas muito pequenas, as vezes passageiras. Cada migalha desperdiçada é motivo para um nova discussão que acaba mudando o rumo das coisas… Calma gente, não estou tendo problemas de relacionamento não, são apenas discussões sadias de trabalho para se melhorar os níveis de performance nos aplicativos.

Quando se atinge um certo número de usuários de uma única aplicação, devemos tomar certos cuidados. Muitas vezes, ignoramos alguns pontos que podemos melhorar, deixando 1KByte, 2KB mais leves, pois afinal, para um usuário parece tão pouco, mas quanto representa 2KB multiplicado por 100 mil usuários? 195 MB. É, assusta, e as cifras só tendem a aumentar.

Com o advento da computação em nuvem, alguns perceberam que realmente deveriam otimizar suas aplicações, pois cada KB gasto vai representar algum valor que será, com certeza, debitado num cartão de crédito futuramente. Enquanto antigamente, bastava planejar a compra de uma máquina muito além das necessidades e ter um custo fixo, agora, a briga é para sempre diminuir a conta no fim do mês, como numa economia doméstica (certa vez, ouvi que toda economia é de migalhas. Concordo).

Mas muitas vezes, desenvolvedores de aplicações esquecem de alguns detalhes como por exemplo, o peso dos arquivos da camada de apresentação de suas aplicações. Na Web, isso também deve entrar na conta: tamanho do HTML, CSS, JS e imagens. E hoje em dia, são relativamente conhecidas técnicas para aprimorar esses estáticos para uma melhor experiência do usuário. Digo relativamente porque ainda me deparo com muitos websites, sistemas e gadgets por aí sem nenhuma otimização nesse sentido. No Brasil ainda temos muitos usuários que não dispõe de banda larga, e eles agradecem cada byte salvo.

Primeiro passo: Limpeza

Um arquivo limpo de tudo que não é necessário é muito melhor, sem dúvida. Elimine dos arquivos aquelas linhas velhas, cheias de comentários inúteis, atributos desnecessários, funções que não são usadas, variáveis zumbis (que estão ali apenas para … nada). Em minha última façanha do tipo, deu pra economizar cerca de 10KB. Como vamos usar uma ferramenta mais pra frente, não precisa deletar nada do arquivo ainda, a não ser que queira ver o quanto você ganhou com esse processo. Comentários podem ser mantidos, e métodos “depreciados” podem ser mantidos comentados também (eu faço isso para armazenar código que venha a ser útil ou que queira manter no histórico para referência rápida).

Reavaliação

Depois desse passo, é a hora de fazer uma certa mágica. Esse passo depende de experiência do usuário, e que tenha um bom conhecimento de lógica e da linguagem em si: reavaliar seu código, diminuindo estruturas de código sem aumentar a quantidade de cálculos, quando não diminuindo o custo computacional (análise assintótica). Isso pode envolver uma análise mais  matemática do código, estimando o número máximo de comparações e operações que ele pode executar. Por isso demanda um profissional graduado. Mas lembre-se: não sacrifique o processamento em troca de tamanho de código! Diversas vezes um código maior e mais específico pode rodar muitas vezes mais rápido. Também, outras vezes, uma simples instrução a mais pode representar um laço a menos.

Comprimindo o código: YUI Compressor

Esse compactador transforma seus arquivos JS e CSS em versões minificadas: com sintaxe reduzida, sem quebras e espaços desnecessários, sem comentários, tudo numa única linha. Isso pode reduzir drasticamente o tamanho do arquivo sem alterar seu conteúdo (eu consegui em minha última utilização a marca de reduzir um .js de 135KB para 84KB!!!), o que é o que buscamos (afinal, quem quer codificar duas vezes a mesma coisa? Otimizar tempo também é muito importante! O YUI Compressor é muito prático e rápido para essa tarefa.

Apenas para exemplificar: ele também altera as assinaturas das suas funções/classes:

function xyz(value_1, value_2) {
    this.param_1 = value_1;
    this.param_2 = value_2;
    ....

Ficará assim, num primeiro momento, assim:

function xyz(f, g) {
    this.param_1 = f;
    this.param_2 = g;
    ....

E depois, assim:

function xyz(f,g){this.param_1=f;this.param_2=g;....

Não se preocupe! Tudo vai funcionar normalmente. Mas podemos perceber que esse compressor realmente vai diminuir seus arquivos. Na tabela abaixo, pode ver o que esses três métodos podem fazer com o peso da sua aplicação:

Um ganho de ~50% no peso total da aplicação, apenas na parte de storage e fileserv.

A União faz a Força Velocidade

Se possível, junto todos os arquivos num único. Tem vários .js? Faça apenas um. O mesmo para os CSS. No protocolo HTTP/1.1, temos uma definição que recomenda não ter maiss de duas requisições sendo processadas ao mesmo tempo para o mesmo servidor. Alguns browsers, como o I.E., seguem isso a risca. Logo, quanto mais arquivos tiver para carregar, pior: mais conexões serão necessárias para atender a demanda, e como o browser só fará duas ao mesmo  tempo, o usuário vai ter que esperar. Aposto que você até teve aquele momento “lâmpada sobre a cabeça” agora, imaginando se poderia fazer isso também para as imagens… e poderá! Veja a seguir no próximo tópico. Uma outra dica para sanar esse problema das conexões simultâneas é manter arquivos em vários servers diferentes.

Sprites

Essa já é mais complicada (principalmente para os desenvolvedores não designers, pelo skill necessário), mas pode significar um gadget/site muito mais rápido para o usuário final. Assim, imagine você carregando vários arquivos .png, os ícones da sua aplicação, por exemplo. Seguindo esse conceito, eles vão ser carregados apenas 2 a 2, mesmo que o usuário tenha uma banda larga suficiente e seu servidor um canhão para carregar muito mais do que isso (falando em tamanho).

Para sanar essa deficiência indireta, uma técnica utilizada são os sprites: você coloca todas as imagens num único arquivo .png (pode ser outra extensão, se aplicável, mas eu recomendo essa), e com os comandos CSS, você seleciona apenas a parte que deseja. Assim será possível usar todo o potencial da banda disponível para trazer todos seus ícones numa única conexão com o servidor, enquanto a segunda concorrente pode ser uma fonte de dados essencial para seu funcionamento.

Nesse tutorial do A List Apart você encontra uma extensa referencia sobre a técnica de sprites.

Concluindo

Bom, com estas ações simples, aposto que sua aplicação será bem melhor carregada, economizará até alguns $$$ para poder me pagar uma cerveja. Sendo assim, deixe seus comentários e dicas nos comentários, caso eu tenha deixado passar alguma! Em breve, um artigo sobre otimização de banco de dados e de fluxo de aplicações.

• Facebook facilitando a autenticação de aplicações – Um tutorial ensinando a integrar sua aplicação PHP com o Facebook Connect.
• E lá vem o CSS3, que venha logo! – Você cansou de brigar com layout em monitores widescreen?
• Confira algumas listas interessantes no Twitter
• Cursos Gratuitos Online na FGV – Diversos, desde técnicos até gerenciais
• THLopes e o comércio eletrônico
• VEJA Meus Livros: Faça sua Biblioteca Virtual no Orkut, divulgue para seus amigos e confira o que eles estão lendo agora
• Learn Something Everyday – Pra você que  gosta de aprender um pouquinho todo dia.
• GuanaCast com Paulino Michelazzo – Empreender com Software Livre, no GuanaBara Cast
• Beautiful Souped Up – Uma ferramenta GUI para testar queries Beautiful Soup
• Convites do novo Orkut – Alguém quer?

Objeto esperado
linha: X
caractere: 1

Você apenas pensa, como boa parte dos filósofos: “está nos detalhes”. Aquela revisâo de código não lhe trouxe o erro? “No Firefox funciona bem…” – não é a resposta que seu cliente vai querer ouvir quando for testar no internet explorer. Ele quer ver a coisa funcionar oras! Nessa hora seus cabelos já estarão querendo tirar férias na mesa ou no teclado, pois sua cabeça estará muito quente… E você pergunta pra si mesmo: “Caramba, mas o jQuery não funciona bem no IE também?”. Calma. Veja só: provavelmente você esqueceu uma simples vírgula num objeto Javascript:

obj = {
prop: value,
prop2: value2,
prop3: value3,
}

Opa, viu só? Aquela damn virgula no value3 está quebrando o código no ie, porém o firefox nem chia. Uma forma de evitar esse ‘descuido’, é colocar as virgulas antes da chave/propriedade do objeto:

obj = {
prop: value
,prop2: value2
,prop3: value3
}

Assim vc pode copiar a linha toda e não haverão virgulas intrometidas no seu código.