Lavando a louça do seu software

Se você, em algum momento da sua vida, ficou mais de 2 ou 3 dias sozinho em casa, ou se você mora sozinho, já deve ter passado por momentos de tensão quando viu a pia da cozinha cheia de louça suja, resultantes daquela pizza (que ainda está na geladeira, pronta para apaziguar aquela fome que surge na madrugada) e/ou daquela cervejada que rolou na noite anterior.

Dammit!!

A pia cheia não inspira vontade, ou confiança alguma, seja para limpar, lavar, guardar ou qualquer outra coisa que precise ser feita. E o pior, a montanha de pratos cria vida e cresce a cada momento.

Eu adquiri o hábito de, sempre após usar alguma louça, ir imediatamente para a pia, lavar, secar e guardar. Pronto, o trabalho não acumula, os riscos de quebrar algo também não. Poxa vida, já estou alí na pia, já estou inserido no contexto, por que deixar de lavar? Sem falar que a manutenção e a verificação da louça(se está bem limpa, por exemplo) se torna mais fácil. Ou estou enganado?

Aonde entra o software nisso? Bom, se pensarmos no processo de software como um todo, existe uma referência que, ao meu ver, se torna muito clara, principalmente na Extreme Programming. Esta, sugere que sempre devemos colocar o sistema em ambiente de produção o mais rápido possível e então lançar novas versões em um ciclo curto[1].

A manutenção, caso necessária, se torna mais fácil e pontual, o tempo de deploy e a adaptação dos usuário diminuem, o desenvolvedor se torna mais confiante para fazer alterações. Enfim, existem uma série de vantagens que apontam para os "small releases". Vale a pena dar uma conferida.

De qualquer forma, a idéia da louça surgiu quando terminei de levar 5 peças em 2 minutos. Bem lavadas, secas e guardadas e pensei que a referência cairia muito bem no contexto de software... Mas parece que existem outras pessoas que pensam de maneira similar, pelo menos quanto a parte da louça :-)

Referências:

[1] Beck, K. Extreme Programming Explained. 1st Edition. Addison-Wesley Professional.

Validando datas com Javascript e Expressões Regulares

"Ah, o Javascript, a linguagem que todos amamos odiar". Lembro desta frase em algum screencast do Peepcode, e concordo com ela. Mas deixando o choro de lado, quero aproveitar o primeiro post e falar de algo simples, porém muito interessante. Já vi muitas maneiras de se validar datas em JS, cada uma com seus prós e contras. Vou abordar aqui uma maneira de fazer esta validação utilizando Expressões Regulares (Regex). Não vou entrar em detalhes sobre regex, existem vários sites sobre este tema. Passo, inclusive, um muito bacana neste post.

Primeiro, vamos validar se o formato passado pelo usuário está correto. Para este exemplo, quero que a string esteja no formato "99/99/9999". É neste momento que recebemos a ajuda de nossa querida regex. Sem ela, teríamos que, provavelmente, varrer a string inteira utilizando indexOf , verificar se os caracteres são todos numéricos e métodos afins, algo muito chato, convenhamos. Uma ótima maneira de criar/testar expressões regulares é o site Rubular, nele você escreve e testa suas regexs em tempo real. Criei uma para nosso problema e acredito que a mesma esteja correta. Note que é possível testar os valores capturados pela expressão regular. Crie alguns casos de teste e veja se a mesma está funcionando corretamente. Lembro também que utilizo o Prototype no exemplo abaixo.

Bom, agora que já estamos acertados com a regex, vamos colocar ela para atuar junto com o javascript! Vamos ao código!


Ok, é mais simples do que parece. Primeiro eu crio uma variável contendo a regex. Para o exemplo, só testarei a data caso o valor passado para a função não esteja em branco. Em seguida verifico, utilizando o método "test", para testar se o o valor passado está no formato definido pela regex. Em caso afirmativo, crio uma nova data, através da regex. Note que temos os $2, $1 e $3. Estes são os resultados "capturados", em seqüência, quando utilizamos uma expressão regular em um valor que confere com a mesma (você deve ter visto no Rubular). Bom, você talvez esteja se perguntando porque criamos a data contendo primeiro o mês e depois o dia. Bom, isso acontece pois, por padrão, datas em javascript são criadas no formato "mm/dd/yyyy". Legal, então temos uma nova data.

Agora, vamos verificar se ela está correta. E, para isso, verificamos se os valores que o usuário passou são os mesmos da data criada. Mas como estes valores não seriam os mesmos se a data acabou de ser criada? Simples, digamos que seja criada uma data assim: "10/32/2009", ao invés de disparar um erro (já que nao temos dia 32 no mês de Outubro), será criada uma data assim "11/01/2009". Nice, uh? O javascript adiciona um dia na data, para compensar o valor maior passado. Neste caso fica fácil, o valor que foi passado na função não confere com a data criada pelo Javascript. E é justamente esta verificação que fazemos na próxima linha, comparando mês, dia e ano. Na comparação de mês, precisamos adicionar +1 pois a função getMonth() retorna o mês de Janeiro como 0(zero), então é necessário compensar este comportamento.
Se tudo ocorrer bem, a função irá retornar true, indicando que a data está correta, caso contrário, a saída será false.

Ufa! Acho que conseguimos! Apesar do post longo (acho que fui verboso demais), esta técnica é simples e eficaz (para validações deste tipo, do lado do cliente).
Espero que tenham gostado. Quaisquer dúvidas, sugestões ou críticas, por favor, utilize os comentários!

Hello World

Este é o primeiro post. Pretendo, apenas, me apresentar rapidamente!

Meu nome é Matias, tenho 22 anos e trabalho desenvolvendo soluções utilizando Ruby on Rails + PostgreSQL. Troquei o ostracismo agudo por um layout azul e pronto do Blogspot.
Talvez não seja a maneira mais original, mas é a mais eficiente.

Pretendo compartilhar as coisas que aprendo no meu dia a dia. Coisas que podem ser úteis à você, caro leitor. :-)

Até!