29 de abril de 2010

Testador online de regexp

Quem nunca se enrolou com expressões regulares?

Eu sempre me enrolo.

Vai aí uma dica, o Regular Expression Tool.

Ele faz a validação da sua regexp on-the-fly, sem precisar submeter o formulário.

Ele valida e gera o código em PHP para os padrões PCRE, POSIX e também para Javascript.

28 de abril de 2010

Outras informações que o Google mostra

Se você não usa o Google como oráculo de informação, pode parar de ler esse post.

Assim como eu, a grande maioria dos brasileiros simplesmente buscam no Google o que precisam. Meu filho, por exemplo, não entra em um site digitando a url na barra de endereços do navegador. Ele procura pelo nome do site no Google e clica no link mostrado.

Aí a gente para e pensa: "mas por que eu uso o Google, se o Bing me dá os resultados parecidos?" Bem, primeiro porque o Google traz coisas mais relevantes. Segundo, porque ele tem uns recursos legais. Quer ver?
  1. Faça cálculos: Digite "20*2" (sem as aspas) na caixa de busca do Google e veja o resultado.
  2. Saiba o horário de outra cidade: Digite "time in londres" (sem as aspas). Obs.: pode digitar qualquer cidade do mundo.
  3. Veja a taxa de câmbio: Digite "1 dollar in real" (sem as aspas) e veja o que ele consegue fazer.
É por essas e outras que a maioria dos seus conhecidos usam o Google, não é mesmo?
E tudo muito rápido e simples.

Velocidade é a característica mais importante

Foi postado no blog Signal vs. Noise uma citação que, traduzindo as 2 frases iniciais, fica assim:
"Velocidade é a característica mais importante. Se sua aplicação é lenta, as pessoas não irão usá-la."

Leia o post original (em inglês).

27 de abril de 2010

Destrua sua lista de backlog

Lendo o artigo Kill Your To-Do List do blog Zen Habits, me lembrei sobre backlog de sistemas.

Algumas pessoas defendem que não vale a pena manter uma lista de backlog, porque ninguém vai esquecer de fazer as tarefas realmente importantes. Se ninguém lembrar de determinada coisa, certamente não era importante.

Você já deve ter-se deparado com uma lista crescente de tarefas antigas. A cada hora aparece um item mais importante, que vai furando a fila, não é? Passado algum tempo, você acaba cansando daqueles itens históricos, que já estão quase fazendo aniversário. Então vem a dúvida: "tiro esse item da lista ou mantenho-o ali?"

Na minha opinião, tire-o imediatamente. Aliás, nem sei o que ele ainda está fazendo nessa lista.

Siga meu raciocínio. Se você tem uma tarefa "importante" que fica ali sempre deixada para depois, é porque ela não era importante. Talvez você achou que fosse ou talvez alguém tenha pedido para você fazê-la. Mas, na realidade, ela não é importante. Talvez ela seja legal, interessante, útil, mas não importante. Porque o que é importante precisa ser feito e, por isso, priorizado.

Isso faz todo o sentido quando você resolve desenvolver aplicativos que contenham apenas a parte importante, que o cliente vai realmente usar. Estamos cansados de ouvir que praticamente 60% das funcionalidades dos nossos aplicativos não são usados. Isso significa dinheiro e tempo desperdiçados, propensão a defeitos e dúvidas.

Quando você trabalha em um ambiente de equipe, as pessoas estão engajadas e vão ajudar-se mutuamente. Daí vai chegar a hora de escolher o quê implantar. Então elas se lembrarão dos itens importantes e a lista de backlog não tem utilidade.

Se mesmo assim você achar conveniente manter uma lista de backlog, então deixe ali somente coisas que serão feitas. Jogue os itens com mais de 2 meses para um arquivo morto. Mantenha uma lista ativa de coisas a serem feitas, não de coisas que nunca serão tocadas.

Simplifique a administração de suas atividades. Destrua sua lista de backlog.

26 de abril de 2010

Rápido é melhor mesmo

Durante algum tempo tenho vivido uma experiência nova ao participar de um projeto que usa bastante JQuery em algumas funcionalidades. Fiquei admirado com o que se pode fazer com esse bichinho estranho pra mim, chamado JavaScript. Eu sei, estou atrasado, mas antes tarde do que nunca para aprender coisa nova, né? Esse aplicativo que estamos desenvolvendo tem uma característica "peculiar" que deveria ser padrão em tudo o que desenvolvemos: tem que  responder rápido.

Tenho pensado muito em desempenho de sites e encontrei algumas boas referências sobre o assunto. A primeira, que foi quem me encaminhou às outras, foi o post Webcast: como melhorar a performance do meu site?, em um dos blogs da Locaweb.

O Yahoo! escreveu suas Best Practices for Speeding Up Your Web Site. Vale também a visita à página de referência Exceptional Performance. Na seção Research você pode aprender coisas legais, como a surpresa do impacto real dos caches dos browsers. Como diz o ditado, "na prática, a teoria é outra".

Se você é um "server sider" como eu, recomendo fortemente assistir aos vídeos da seção Videos About High Performance Web Pages, principalmente os introdutórios de JavaScript.
Tem material riquíssimo ali.

Como não poderia deixar de ser, o Google também tem ótimas fontes de consulta Aliás, seus aplicativos são conhecidos também por terem um excelente tempo de resposta. Então, vamos ao Google Speed. que é um centro de informações a respeito de como tornar seus aplicativos web mais rápidos. Ali tem um link para o post Let's make the web faster, que dá uma boa introdução sobre o assunto. Para aprender o "como fazer", visite a página de artigos do Google Speed.

Fazendo um resumo (resumão mesmo) bem objetivo, seguem 3 dicas que, de acordo com os especialistas, trazem resultado mais rápido, que são sentidas imediatamente pelos usuários e que deveriam ser tentadas primeiro:
  1. Faça menos requisições http: Quanto menos objetos externos sua página html solicitar, melhor. Por isso, diminua a quantidade de imagens e de CSS/JavaScripts externos.
  2. Comprima suas imagens: Salve-as para visualização na web. Em monitores, a resolução não passa de 72 dpi. Portanto, ajuste a paleta de cores para essa realidade. Diminua sempre.
  3. Comprima seus HTML, CSS e JavaScript: aqui a história pode ficar complicada, mas vou dar uma dica de programador: retire espaços em branco desnecessários e use nomes de classe e de variáveis pequenos, mas que façam sentido. Só com isso a coisa já vai melhorar muito. Seria boa prática usar um compressor de código antes de colocá-lo em produção. Procure por "javascript compressor" ou "html compressor" ou "css compressor" para encontrar alternativas.
Antes de sair mudando linhas de códigos server side, sugiro a leitura dos resultados das pesquisas do Yahoo! e do Google e analisar os resultados do YSlow e do Google Page Speed. Normalmente (mas nem sempre) o gargalo de desempenho está no client side.

Dependendo da estrutura de seu banco de dados, o SQL também pode trazer um bom gargalo de desempenho. Normalizar é preciso, mas responder rápido, também.

Se você tiver alguma dica geral para melhorar desempenho de sites ou aplicativos web, colabore nos comentários. Toda ajuda é bem-vinda.

Update em 26/04/2010 às 12:07: Ranking do Google agora considera velocidade de carregamento do site.
Update em 11/09/2011 às 02:33: [QCon 2011] Por uma web mais rápida: técnicas de otimização de Sites - por @sergio_caelum