Sérgio Souza

Eu aderi a Campanha “Atualize seu Navegador”.

A cada dia que passa fico cada vez mais fã do jQuery e seus plugins. O mais novo plugin que descobri foi o “jQuery Validation Engine“, que no onBlur de cada campo do formulário faz a validação. As regras de validação são definidas no class do campo, como por exemplo:

<input type=”text” id=”nome” class=”validate[required,custom[noSpecialCaracters],length[0,20]]”/>

Traduzindo, validate[required,custom[noSpecialCaracters],length[0,20]] quer dizer:

• required = campo obrigatório
• custom[noSpecialCaracters] = aceita apenas caracteres alfanuméricos (excetos caracteres acentuados)
• length[0,20] = mínimo e máximo de caracteres permitidos

As mensagens de validação são exibidas em caixas de texto como mostra a imagem abaixo:

Recomendo a leitura do artigo “Why Good Programmers Are Lazy and Dumb”. E buscando maiores informações no Google achei uma tradução comentada, no WTF-Brasil, que reflete o meu pensamento.

Lendo o artigo “5 dicas para criar bons códigos todos os dias, ou como se tornar um bom desenvolvedor de software” encontrei algumas dicas de coisas que já faço no meu dia-a-dia, e de outras que estou tentando por em prática. São elas:

• Prepare sua própria lista de afazeres do dia. Divida as atividades complexas em atividades simples. O que ajuda a: 1) ter uma melhor compreensão das atividades; 2) ter metas focadas para o dia; 3) melhorar a habilidade de quanto tempo se gasta por atividade em um dia.

• Faça uma coisa de cada vez. É mais produtivo se concentrar em apenas uma tarefa do que fazer várias ao mesmo tempo. A técnica pomodoro, por exemplo, ajuda a gerir o tempo.

• Faça direito. Como meu pai diz: “Se não quer fazer de novo, faça bem feito”.

• Não finalize alguma coisa até que tenha completado tudo. Algo só está 100% certo quando se tem a certeza de que não haverá modificações, a não ser que os requisitos mudem.

• Antes tarde do que arrependido, PORÉM antes arrependido do que nunca. Se tiver tempo para testar algum código ou fazer um rafactor em uma classe que está ilegível, faça, pois isso será um investimento para o tempo futuro. Porém, se estiver muito atrasado em um projeto, talvez, encontrar a solução mais fácil seja a melhor alternativa, mas desde que essa solução possa ser inclusa em um documento de riscos e possa ser revista no futuro.

Ao final de tudo concluo que:

Tudo é uma questão de disciplina.

[youtube=http://www.youtube.com/watch?v=V-cyaXVmNUQ]

FONTE: Youtube, http://www.youtube.com/watch?v=V-cyaXVmNUQ

[youtube=http://www.youtube.com/watch?v=m711mKI54iI]

FONTE: Youtube, http://www.youtube.com/watch?v=m711mKI54iI

69%How Addicted to Blogging Are You?

Neste post estou apresentando algumas dicas de como podemos programar melhor.

Pare e pense antes de começar a fazer o código, mesmo que não possua um bom conhecimento, ou que o cliente/empregador esteja desesperado. Se começar a construir uma casa pelo telhado e não pelo alicerce, com certeza a casa cai. E outra coisa, não utilize no processo o modelo em cascata, onde, a grosso modo, só se dar um passo depois que o anterior foi concluído, mais ou menos como um engenheiro/pedreiro que não revisa as fundações de uma casa depois que ela foi erguida. Porém, não se esqueça de incluir no planejamento, meios para correções de erros das etapas iniciais.

Aprenda com os exemplos de outros programadores, até porque, em termos gerais, a humanidade chegou a esse estágio de desenvolvimento por compartilhar seu conhecimento e descoberta. A leitura de um código pode te levar a descobrir soluções que você nunca imaginou, como também pode te ensinar o como “não fazer”, por exemplo: 1) falta de tabulação; 2) loops infinitos; 3) criação de variáveis sem tanta necessidade; 4) teste de verificação de lista não nula. Todavia, sabemos que a leitura de código feito por outras pessoas é difícil. Mas nunca critique o código, pois cada um segue uma linha de raciocínio. Resolver problemas é algo muito pessoal, independe do design patterns ou do padrão de codificação utilizado, até porque quanto mais experiência se possui, melhor fica a codificação. Se você olhar para um código que você desenvolveu a 5 ou 10 anos atrás, com certeza irá sentir vergonha.

Programe fazendo testes automatizados, mesmo que não seja garantido que terá um sistema “sem” bugs, mas é certo que terá muito menos bugs do que programar sem testes automatizados. E, peça sempre para outras pessoas testarem, porque como estamos tão inseridos no contexto do desenvolvimento, conhecemos todos os pontos e vírgulas, que muitas vezes deixamos passar pequenos erros. É como respirar. Não pensamos nisso, o processo é mecânico.

Descanse sempre que possível, ou faça ser possível. Programar é uma atividade exaustiva, e quase sempre não se tem as melhores condições ergonômicas para exercê-la. E com o passar do tempo as queixas sempre aparecem. Então sempre der uma pausa no trabalho para relaxar o corpo. Nada demorado, nem com muita freqüência. Ah! Não faça projetos em horários estranhos, nem venda seu trabalho com muita facilidade, ou seja, evite se “prostituir”.

E por fim, esteja sempre aberto para receber novas informações. A humildade vai te levar a novos aprendizados.

Tenho utilizado bastante o jQuery em minhas aplicações pessoais, visto que o jQuery é uma poderosa biblioteca JavaScript que simplifica a criação de efeitos visuais, e que tira toda a preocupação do desenvolvedor em compatibilizar um aplicação para os diversos navegadores.

Hoje, fazendo um CRUD, precisei informar ao usuário o sucesso ou não de uma ação que ele havia realizado, como por exemplo: “Cadastro realizado com sucesso!”. Para um melhor efeito visual não podia de hipótese alguma utilizar o alert(“…”) do JS. Então criei um pequeno plugin para o jQuery, que simplesmente adiciona, exibe (slideDown) e oculta (slideUp) uma div na tela. Para utilizar o plugin, basta efetuar a chamada à função exibirNotificacao, passando uma mensagem, como por exemplo: exibirNotificacao(“Exclusão realizada com sucesso!”)

Certa vez, buscando uma forma de manipular arquivos de formato do Microsoft Word, encontrei com alguns colegas o docx4j. O docx4j é uma “biblioteca Java open source para manipulação de documentos OpenXML WordprocessingML”. A intenção seria utilizar um arquivo .docx, onde teriamos um arquivo de template, e nesse arquivo iríamos fazer search & replace. Conseguimos fazer, porém quando tentamos abrir o arquivo gerado, especificamente o .docx, no IE, o arquivo era exibido como .zip. No Firefox e no Chrome funcionava muito bem. Uma boa curiosidade encontrada, foi que o arquivo .docx nada mais é do que um monte de pasta e arquivos .xml compactados, então o IE só conseguia entender isso: ‘.zip’. A solução utilizada para resolver esse problema foi o mapeamento do MIME Type no conf\web.xml do Tomcat, adicionando: