Viagens, opiniões e afins

No meu trabalho precisei realizar uma tarefa que consistia em pegar um arquivo xml e gerar um outro arquivo, também em xml,  a partir dos dados do primeiro.  A princípio pediram que fizesse “na mão” mas como sou pago para pensar e não para executar as coisas feito uma máquina, parti para criar algo que fizesse isso de forma automática.

Para fazer o trabalho criei um script em Groovy por ter uma certa intimidade com a linguagem e pela facilidade que ela oferece para manipular dados em formato xml (veja o trecho abaixo).

O script após pronto funcionou perfeitamente, porém com um problema residente no fato do arquivo de saída ter sido salvo com codificação padrão do sistema operacional (o lixo do Microsoft grava tudo em ANSI ).  No primeiro teste que fiz com os dados acusou o erro com caracteres acentuados.

O desafio foi achar uma forma, simples, de alterar o encoding do arquivo de saída para o valor que eu quero. Após muitas pesquisas no google, leituras de doc, etc… A solução extremamente elegante que achei foi (veja trecho abaixo).

Aqui você informe que ao invés do objeto file usar um writer com valor de caracter padrão, ele deve usar um que use o UTF-8. Para quem está familiarizado com padrões de projeto é um Decorator.

O ser humano por mais desbravador e aventureiro que seja seu espírito ( estamos tentando ir para todo lado, entender tudo, etc)  sempre vive um desconforto frente a possibilidade de experimentar o novo.  Que criança nunca “torceu o nariz” quando a mãe mandava provar uma comida que não tinha visto antes; que pessoa num recuou frente a um possibilidade de ir em direção a uma oportunidade nova; quem nunca sentiu insegurança quando se formou e agora terá de enfrentar um mundo novo…  O problema é quando esse desconforto virá medo paralisante e inconscientemente nos tornamos agressivos com relação aos agentes da mudança.

Temos vivido um momento muito interessante dentro do mercado de TI : todo o processo, o “como fazer”, qualidade, e muitas outras coisas, tem sido questionado, paradigmas quebrados, novos processos, novas metodologias, novas linguagens, e muitas outras que se continuasse poderia facilmente escrever páginas e mais páginas só com a lista.  Isso acaba gerando um estado de CAOS (caos não é desordem, é ausencia de ordem) , num sentido que não existe uma forma única de fazer mais nada. Isso é algo ímpar e altamente interessantes pois as possibilidades são quase que infinitas.  Por outro lado, para o pessoal menos aberto a mudanças, ou até menos preparado para oque está acontecendo, isso representa uma “escuridão” plena, na qual não é possível enxergar o terreno por onde se caminha. O medo, ou melhor, o receio não é algo ruim, nem deve ser evitado, ele é um recurso importante de nossa inteligência pois nos impede de colocar a “mão na aranha e ser picado”, mas ele não pode ser nunca paralisante.

O receio frente a mudanças deve ser tratado com serenidade e inteligência, onde um bom primeiro passo seria procurar entender melhor essa novidade. Além de entendê-la verificar se ela trará algum valor para seu trabalho ou empresa. E por fim, dar um chance, verdadeira (famoso coração aberto, mente aberta, entrega total) a proposta e vivenciando num universo controlado julgá-la. Em diversos casos relatados por colegas que tentaram trazer novidades, ou fizeram consultorias contratadas para promover algum tipo de mudança, e outras possibilidades,  sempre ouvi exemplos de reativos: pessoas que se recusavam a ouvir, entender e até mesmo tentar aquilo. Alguns partiam para atitudes agressivas, criticando de forma cega e tendo atitudes de sabotagem.

Quando o medo (receio) frente a mudança se torna agressividade – agressividade aqui diz respeito ao bloqueio e criticas mordazes -  isso acaba virando um jogo perigoso e, em minha opinião, NUNCA é (ou será) bom para nenhuma empresa.  Em muitos casos,  as coisa ficam num clima de guerra onde existe o pessoal que defende a mudança “com unhas e dentes” e outros que contrariam as mudanças “com unhas e dentes” .  Sei que existem milhares de técnicas, dinâmicas, e outras coisas, que podem miticar esse clima, mas um vez esse ambiente criado sempre existirá um desgaste que poderia ser evitado se as pessoas agissem como humanos e fossem mais desbravadoras.

Antes que confundam e passem a pensar que estou incentivando a aceitar toda e qualquer mudança, quero dizer que não sou a favor de sairmos agora experimentando tudo de novo que for divulgado ou criado.  Ainda acredito na questão da sustentabilidade – empresas que são muito vanguardistas  acabam pagando um preço de falta de profissionais e manutenabilidade no longo prazo, por exemplo – embora também penso que, profissionais principalmente de TI, devem sempre estar estudando e lendo sobre as novidades que estão surgindo até mesmo para ter uma opinião concreta sobre o assunto e um dia decidir se vale ou não a pena usar aquilo.

Como sempre digo, o caminho sempre estará no meio.   Ser fechado e averso a tudo novo e agir de forma agressiva ( criticando, trabalhando para falhar a iniciativa, defamando as pessoas, etc) é estupidez e uma tremenda burrice. Agora ser um viciado em novidades e sair usando versões noturna (nightbuilds) de tudoé loucura e inconsequência juvenil demais para um profissional.  Ponderar entre o já conhecido e sob controle e a novidade é algo que só traz benefícios e exemplos disso não faltam no mercado.

A um certo tempo atrás me deparei com alguns códigos que usavam o recurso de decorator.  Dali, curioso com tal coisa, resolvi pesquisar para entender melhor como funcionam, para que servem, e quais seriam bons cenários para usá-lo.

Para minha surpresa, achei pouco material e a maioria dos conteúdos que tratavam do assunto eram superficiais. Outros que abordavam mais a prática (ou associada a um problema único), alguns falavam de forma extremamente complexa, etc. Além de tudo isso, quase nenhum dos artigos eram em português: o tema é complicado e sem fluência no inglês a coisa tende a piorar.

Como recompensa ao esforço a determinação, achei um excelente texto (fonte altamente confiável): Bruce Eckel, no site Artima.  O artigo aborda justamente de forma abrangente o assunto, decorator do python, e dando o enfoque que procurava (funcionamento, porque usar, como usar, quando usar) .  Então, como forma de dar minha retribuição a comunidade, segue uma versão do texto dele (não é uma tradução, parte irei reproduzir, outras colocarei minha visão).

Primeira coisa que considero interessante, que o está no texto próprio original,  é que necessitamos desfazer alguns conceitos erróneos sobre Decoradores. Muita gente quando escuta decorators logo remete seu pensamento aos padrões de projeto, mais precisamente, o padrão Decorator.  Esse padrão é feito para possibilidade de forma simples adicionar  recursos, detalhes, adornos a uma classe, inclusive em tempo de execução. Aqui eles tem mais uma carinha de Macros, do que decoradores.

O objetivo das macros é de permitir alterar os elementos de uma linguagem. Isto é exatamente oque os decoradores em Python fazem – eles modificam  funções e classes inteiras (existem decorators para classes) .  Isso é porque eles usualmente provem um caminho alternativo ao uso de metaclass.

A grande parte das linguagens que suportam tal recurso (auto-modificação)  falham no quesito complexidade :  elas são tanto restritivas e requerem, em alguns casos, uma linguagem diferente. Python se faz a pergunta: porque não fazê-lo em python mesmo? Porque não permitir escrever macros ou decoradores na própria linguagem permitindo uma interação maior ? Esse é exatamente a proposta dos decoradores.

Porque usar Decorators?

Decorators permitem que se altere a execução de um método ou classe. Para que os conhecem, lembra bastante o AOP (Aspect Oriented Programming – programação orientada a aspecto) .  A diferença que não precisamos muitas coisas ou grandes conhecimentos, oque torna muito interessante e legal, mesmo que para iniciantes.

Um exemplo de uso, didático,  é escrever algo que permita fazer algo antes e depois da execução de uma função.

A clásula acima @, define a chamada ao meu decorator que irá fazer algo, quando este método for chamado. Algo semelhante a uma proxy.(veja mais sobre a sintaxe clicando aqui)