Leonardo Bighi

Tem coisas na vida que vemos em tantos lugares que acabamos aceitando aquilo como se fosse algo normal, ou até o certo. Apenas recentemente abri o olho pra algo muito comum em muitos formulários de registro de usuários, mas que já não sei se é mesmo necessário: o campo de confirmação de e-mail.

Em boa parte dos formulários é comum encontrarmos dois campos de confirmação: um para confirmar o e-mail, e outro para confirmar a senha. Para que serve esta confirmação? Fazemos o usuário inserir duas vezes a mesma informação, para garantir que o campo foi preenchido com a informação correta.

A confirmação de senha é mesmo algo necessário. Por segurança, a senha não é exibida no campo enquanto o usuário preenche, e não há qualquer garantia de que ele não pressionou uma tecla incorretamente. Fazendo ele inserir a senha duas vezes, temos a garantia de que estaremos recebendo a senha correta.

Mas o problema é o campo de e-mail. Enquanto preenche, o usuário pode ver claramente o que está digitando, e qualquer erro de digitação pode ser detectado na mesma hora. Mais ainda, e-mails geralmente são grandes. Eu que digito rápido já acho cansativo ter que digitar meu e-mail duas vezes, imagina para um usuário comum que ainda não é um amigo de longa data de um teclado de computador.

Acontece que estamos tão acostumados a ver a confirmação de e-mail que começos a tomá-la por algo normal e que deve ser feito sempre, e acabamos colocando esse campo também ao criarmos novos sites. Mas parem pra pensar. Será que é mesmo necessário? Será que seu usuário é incapaz de olhar para o campo que ele está preenchendo e detectar um erro? Ou podemos deixar esta confirmação de fora, tendo assim formulários mais práticos?

Gostou do artigo? Para saber mais, compre um livro de Usabilidade!

A internet, essa grande ferramenta feita pra facilitar nossas vidas, nem sempre é tão fácil ou prática quanto poderia. Um bom exemplo são os sites que exibem formulários enormes para que o visitante se registre, tornando-se um usuário. E eu me pergunto se isso tudo é mesmo necessário.

De todas as páginas do seu site, uma das mais importantes é o formulário de registro. É neste momento que você e o usuário partilharão um momento único, é quando ele estará mostrando que confia no site e gostaria de ter acesso ao conteúdo ou serviço oferecido. Seu visitante está iniciando um relacionamento com você, e este momento deveria ser o menos traumático possível.

É estressante para este visitante ter que preencher 10 ou 15 campos antes mesmo deste relacionamento ter começado. Mais estressante ainda se ele acreditar que alguns dos dados pedidos não são necessários. Será que seu site precisa mesmo saber a cidade e o estado em que o usuário mora? Será que precisa saber a data que ele nasceu? E será que esta é mesmo a melhor hora pra pedir a ele para descrever a si mesmo?

O melhor, para ambos os lados, é que você faça com que o momento acabe logo. Seu usuário provavelmente já tem registros em 10, 20 ou 30 sites diferentes e está cansado de preencher formulários de registros. Ele só quer acabar com aquilo o mais rápido possível, e quanto mais rápido for o processo, menor são as chances dele acabar desistindo no meio.

E uma vez que ele tenha se registrado, o relacionamento estará firmado e o usuário conseguirá o que deseja: ter acesso ao conteúdo do site.

Como um fórum, por exemplo. Deixe o usuário se registrar apenas com seu nome, e-mail e senha. Se ele gostar do que você oferece, se quiser aproveitar melhor o site, ele vai fornecer outros dados pessoais por vontade própria, seja preenchendo dados de um perfil, ou dando seu número do cartão de crédito.

Gostou do artigo? Para saber mais, compre um livro de Usabilidade! 

Um dos princípios por trás do Ruby On Rails é o DRY (Don’t Repeat Yourself), ou seja, não se repita. Ele nos fornece muitos meios de se evitar repetições, e o que mais uso pra esse propósito são os filtros.

Filtros, no Rails, definem um método que será executado antes e/ou depois de cada página daquela classe. Então, nos nossos controllers, podemos usar os filtros para executar as mesmas tarefas rotineiras em todas as páginas sem ter que repetir aquele código dentro de cada action.

Definindo um filtro

Nós temos 3 tipos de filtro à disposição: before_filter, after_filter, e around_filter. O before_filter define um método que será executado antes de carregar cada página da nossa aplicação. O after_filter define um método que será executado depois de cada página da aplicação. E, por último, o around_filter define um método que será executado antes e depois de cada página.

Vejamos um exemplo de um controller simples que usa um filtro.

class ShoppingController < ActionController::Base

  before_filter :nosso_metodo  #imagine aqui várias actions da aplicação

private

  def nosso_metodo

    @mensagem = "Esta é uma mensagem"

  end

end

No exemplo acima, temos o controller Shopping, e antes de cada página deste controller o método nosso_metodo é chamado, por ter sido definido no before_filter. O método, então, define uma mensagem qualquer que usamos apenas de exemplo.

Leia todo o texto »

Se tem uma coisa que nós (brasileiros) sabemos fazer muito bem são protestos inúteis. Protestos silenciosos, protestos onde todos vestem uma mesma cor de roupa, e por aí vai. Pois proponho agora que façamos um protesto pelo fim do Internet Explorer.

Qualquer pessoa que entenda pelo menos um pouco de informática e web design sabe que o Internet Explorer é um grande vilão, um atraso para toda a web. Não suporta os padrões, não dá suporte completo ao CSS2 que já existe há anos, ele interpreta o javascript como bem entende…

E aí qualquer pessoa que está fazendo um site tem dois trabalhos: fazer o site do jeito certo, e então usar truques para que o IE também consiga entender. Muitas empresas, para poupar tempo, fazem o site apenas do jeito errado, ou seja, o jeito do IE. E então pessoas leigas vêem que o site está funcionando no internet explorer, mas não está funcionando no firefox, e concluem que o erro está no firefox.

E esta é a verdadeira proposta da Microsoft, claro. Fazer com que as pessoas tenham que adotar o seu estilo de site, já que o navegador tem boa parcela do mercado, em vez de programar do jeito certo. Esta prática levará a dois grandes problemas em breve na web, quando chegarem o CSS3 e o HTML5. Ambos trarão grandes mudanças e avanços nos sites, mas o internet explorer demorará muito para suportá-los. E se o internet explorer não suporta nova tecnologia, é como se ela não existisse, pois não podemos fazer sites que apenas 15 ou 20% das pessoas irão acessar.

Minha proposta de protesto é que todos fiquem em silêncio às 3:49 da manhã do dia 17 de outubro. O que tem no dia 17 de outubro, Bighi? Nada! Mas mesmo assim ficaremos em silêncio por um minuto inteiro. Vamos fazer a Microsoft sentir nosso poder! Vamos mostrar que é que manda! Queremos o fim do internet explorer já!

Tenho mantido vários projetos diferentes ao mesmo tempo, e um deles é o site emprestei.com. O propósito dele é fornecer um meio simples de anotar as coisas que você emprestou para as outras pessoas, pra não esquecer com quem está aquele seu livro favorito ou o seu DVD de Heroes.

No pouco tempo que me sobra pra passar em casa eu tenho trabalhado em algumas novidades para o site, e a principal delas se refere ao ato de adicionar um novo empréstimo. A partir deste final de semana, novos empréstimos serão adicionados através de uma interface em ajax, atualizando a lista sem precisar recarregar a tela.

Eu queria já ter colocado isso antes, mas parece que a cada dia que passa o tempo que me sobra é menor. Mas para os poucos que já começaram a usar o Emprestei, novidades virão!

PS: Tenho pensado em fazer um tutorial prático de como montar uma aplicação em Rails, usando o Emprestei como exemplo. Será que daria certo?

Queria aproveitar pra comentar hoje sobre dois artigos interessantes envolvendo Ruby On Rails, um bem diferente do outro. O que ambos tem em comum é que foram escritos por programadores que trabalham com rails há 2 anos.

Dicas de Desenvolvimento Ruby

O site Nuby On Rails publicou um artigo com uma lista massiva de dicas de desenvolvimento com ruby on rails, vindas de um programador experiente.

O artigo nos trás ótimas dicas, como “mantenha seus controllers e views bem magros” e “teste sua aplicação”. Vale a pena dar uma lida nas suas dicas mesmo que você já tenha experiência com ruby on rails. Nunca se sabe o que você pode aprender.

O’Reilly dando um péssimo exemplo

Derek Sivers, no blog oficial de ruby no O’Reilly Net, publicou um artigo polêmico chamado 7 razões porque voltei pro PHP depois de 2 anos de Ruby.

E não concordo com o artigo dele. Não estou dizendo que o ruby serve pra todos e ninguém deveria ficar com o PHP, mas não concordo com os motivos que ele usou para ter feito tal coisa.

O principal e primeiro motivo citado por ele foi de que o PHP faz tudo que o Ruby on Rails faz. Como se isso significasse alguma coisa. Este é um argumento válido pra praticamente qualquer linguagem, e não diz muita coisa. A principal vantagem do ruby não é o que ele faz, e sim como ele faz.

Um outro argumento usado é que ele não quer mais do que precisa, e por isso voltou para o PHP. Agora… qual dos dois oferece mais opções diferentes do que alguém precisa? E não é um dos charmes do ruby o fato de ter reduzido o número de opções em prol da agilidade e praticidade?

Este é um artigo que recomendo que leiam, mas não sigam. Existem bons motivos pra se usar PHP ao invés de Ruby em um site, mas “eu gosto mais de sql” definitivamente não é um deles.

PS: Concordo com apenas uma coisa que ele falou. Programar em ruby acaba te fazendo programar melhor em outras linguagens.

Se interessou? Compre agora mesmo um livro de Ruby on Rails com o menor preço!

Como trabalhador em uma faculdade pública onde a gestão do atual reitor está perto de acabar, todo o meu departamento foi obrigado a entregar uma documentação inteira de tudo que foi feito no ano todo, e ainda uma explicação de todos os processos e páginas de todos os sites que temos. Resultado: dois dias inteiros de trabalho perdido.

Esta prática de documentar bem o software vem do início da tecnologia da informação, onde o cara programava com cartões perfurados e o software então levava o dia inteiro compilando. Documentar bem o software era essencial para não perder dias de trabalho compilando algo que não funcionaria bem.

Com o tempo, a velocidade dos computadores aumentaram bastante, e podemos ver o resultado do nosso código de forma quase instântanea. Ao mesmo tempo, a complexidade dos softwares foi aumentando mais e mais. A documentação começou a não dar mais conta de tudo, e não era mais uma solução eficiente.

Para resolver isso, foram decidindo que a solução para isso era fazer mais e mais documentação. Criar mais e mais papel que ninguém vai ler. E isso não resolve problema algum.

Veja nosso caso, aqui na UERJ. Perdemos cerca de dois dias sem que uma única linha de código fosse produzido, porque toda a equipe estava produzindo a documentação. E aposto que o reitor não lerá nem um quinto das mais de 100 páginas.

Eu diria que um código limpo e claro, com comentários nas partes necessárias, vale muito mais do que uma documentação. Um código que fale por si, sem gambiarras, sem algoritmos bizarros. Isso sim vale muito mais do que uma documentação (que fica desatualizada em uma semana) e ainda desperdiça menos o tempo dos programadores.

Por estar fazendo faculdade de informática e trabalhando com pessoas que ainda são bem iniciantes na programação web, posso ver quais são as principais dificuldades dessas pessoas. E uma das principais coisas que vejo é que eles já vão logo aprendendo PHP e pulam direto pelo HTML.

O HTML (e neste categoria estou inserindo o XHTML) é a base de todo e qualquer site na internet, e os programadores web deveriam dominar o HTML como um escritor domina a língua em que ele escreve. Mas muitos só vão se dar conta disso muito depois.

Eu diria que um dos maiores culpados é o Dreamweaver. Que fique claro que eu adoro o dreamweaver e não sou desses usuários que só fala mal dele. Mas é que a facilidade que ele nos dá para criar sites faz com que os programadores iniciantes acreditem que não precisam aprender a base do que estão fazendo, deixando para o dreamweaver o trabalho de montar seus sites.

E aí, por culpa disso, acabo vendo um monte de sites cheios de <font> e <align>, estilos inteiros em CSS montados dentro da própria página em vez de usar um arquivo separado, e muita, mas muita duplicação desnecessária de código.

O mais engraçado é que não vejo nas faculdades um trabalho de conscientização dos alunos, uma explicação de que precisam aprender e dominar o HTML, entendê-lo. E aí, só quando estiverem dominando o HTML como dominam a suas próprias pernas é que deveriam começar a aprender algo mais avançado, como o PHP, ASP ou o lindo Ruby.