Blog do Andre Fonseca

Nesses últimos tempos tenho estado distante do blog mas foi por um bom motivo acreditem.  Estou numa nova empresa, a Globo.com, e lá venho tendo diversos desafios. Dentre esses diversos desafios, um deles tem sido o uso de novos tecnologias bem longe da minha zona de conforto que é o Java.

Para os que acompanham o blog a um certo tempo pode soar como repetitivo porém é válido dizer que de um bom tempo até então tenho procurado aprender novas coisas. Confesso que tenho sentido na pele o peso do ditado “não se ensina truque novo a cachorro velho“. Não sou tão cachorro velho assim (tenho apenas 30 anos)  embora esteja na estrada a muitos anos. Com isso, ganhasse uma certa falsa tranquilidade de estabilidade. A verdade meus amigos que nada é garantido e nos dia de hoje que não estuda (constante aprendizado) está fadado a morrer num curtíssimo intervalo de tempo.

Não se ensina truque novo a cachorro velho

Bem, para não gastar energia em muitas coisa e no final não conseguir chegar a lugar nenhum, resolvi focar. Taí uma boa dica para a galera: foque.  Essa situação presente de que temos que saber de tudo, tem feito um nó na cabeça de todos. Temos que ser bons em tudo. Calma.  A maior qualidade que admiro numa pessoa é sua capacidade de aprender. Não gosto daqueles caras que chegam dizendo que sabem tudo e que vomitam um monte de sopa de letrinha. Geralmente basta que se aprofunde um pouco no assunto que eles revela a sua pouco profundidade em tudo.

Prefiro pessoas que tenham noção das coisas e  capacidade para ” se virar”, ou seja, capacidade para aprender aquela determinada tecnologia ou qualquer coisa correlata.  Mas não se esqueça de focar. Porque foco?

Infelizmente nós seres humanos não somos multithread. Sendo assim, é preciso tratar um coisa de cada vez, em fila.Querer estudar um monte de coisa ao mesmo tempo gera confusão e no final terá gasto um tempo enorme e terá apenas noção daquilo.Volto a dizer que admiro a pessoa que tenha um horizonte amplo mas precisamos ser mais “especialista em algo”.  Por isso foco.

É legal ter foco. Evitar lidar com muitas coisas ao mesmo tempo. Fazer uma coisa de cada vez até o fim

Tendo em mente isso, resolvi focar em Python. Python é uma excelente linguagem. Poderosa, permite fazer muitas coisa com um simplicidade franciscana.  Exemplos: temos excelentes ferramentas gráficas em python, Django, Web2py, e por ai segue.

Quiz a vida brincar um pouco comigo e com isso cai num projeto novo onde tudo está sendo feito em Ruby on Rails.  Confesso que foi uma loucura no início. Mas agora estou adorando, pois está sendo uma excelente oportunidade de conhecer a funda Ruby e o Rails, coisas sobre as quais sempre escutei muito.

O Ruby é um experiência nova que vai muito além do uso de um nova linguagem: é experimentar um novo forma de encarar a questão de desenvolver uma aplicação.  Tudo em Ruby – veja os códigos de coisas feitas em Ruby no github – parece ter um cuidado especial para que fique bonito. Quando falo bonito, não me refiro somente o produto final, estou falando também e inclusive do código.

São implementações que sempre primam pela legibilidade, pelo beleza (isso mesmo) do código. Tudo parece conspirar nessa direção. Veja um exemplo:

3.time verifique_saldo

Isso é tão emblemático que tem sido copiado para outras plataformas e linguagens. Um bom caso é o Grails.

Bem vou ficando por aqui pois a família me chame e reclama um pouco por minha atenção. Até a próxima.

Hoje, pela hora de almoço, estava conversando com Gabriel sobre a questão do TDD (Test Drive Development – Desenvolvimento dirigido por teste).  Conversávamos sobre o fato de hoje isso esta se tornando uma moda e muita gente dizer que está usando a técnica e na verdade não está.

Para os nerds de plantão, existe uma cena do filme Matrix, onde o Neo começa a entender a matrix e com isso controlá-la. Pode parecer que quero “forçar a barra”, porém acredito, sinceramente, que o uso TDD se processa da mesma coisa. Só vamos deslumbrar o seu poder quando passamos a acreditar no processo.  Não adianta somente usar porque agora virou moda… tem que acreditar que a coisa realmente funciona, para então aproveitar todo o poder que essa verdade libera (estou inspirado hoje).

Tem muito gente que critica o uso do TDD por justamente se basear em casos onde pessoas que não acreditam no processo e usam por motivos não muito nobres.  Nessas casos o que vejo são, na maioria das vezes, desenvolvedores subvertendo a filosofia, escrevendo testes que não são “profundos”, escrevendo os testes depois, adaptando os testes para passar ( já ouvi histórias de pessoas comentarem o teste), e por aí segue esse terror.

É preciso crer. O começo é verdadeiramente complicado e trabalhoso. Escrevemos toneladas de linhas de código, sem gerar nenhum valor “real” para nosso cliente. Por várias vezes ficamos tentados a deixar os teste de lado e partir direto para implementar por motivos diversos. Mas ao respeitarmos a formúla, o ganho vem com o tempo. Apenas para exemplificar, uma dessas vantagens é a questão de sempre estarmos focado no simples e atender estrictamente o escopo.

Quem nunca se deixou levar, ao implementar, uma aplicação, pela loucura de criar arquitecturas imensas e sem necessidade? Aquelas aplicações (Java) com um amontoado de camadas – DAOs, VOs, Services, etc – que no final vão servir apenas para um site pequeno de noticias que não terá grande modificações após ser colocar em produção.

Voltando para a questão do TDD… Escrever testes antes da implementação faz com que foquemos na necessidade: Criamos a necessidade para podermos supri-las e não contrário – criar soluções para depois ver necessidades.

Ser simples é chave. E TDD é um dos caminhos que nos levam a isso quando falamos em desenvolvimento de sistemas. Além disso, existe já as justificativas de ampla cobertura de testes e de foco na aderencia de requisitos.

Quando realmente usamos o TDD, como já disse antes, criamos a necessidade e a partir daí partimos para criar a solução que a satisfaçam.  Isso faz com que tenhamos um código amplamente testado, justo – evitasse o desperdício em criar solução para necessidades que nem existem ainda, código limpo, etc. Se extrapolarmos então para a questão da evolução de código a coisa fica mais interessante ainda: primeiro modificamos o testes, pois a necessidade é diferente,  e depois modificamos a implementação para passar nos novos cenários de teste. Isso limita nossa área de atuação e nos disciplina a fazer apenas o justo necessário. Sem firulas, sem big to front, sem complexidades adicionais para supostos futuros contextos.

Ainda sobre a vantagem, seria dizer que você, usando TDD e acreditando verdadeiramente,  você está otimizando o uso do sprint e com isso gerando mais valor agregado para o cliente. Pensem nisso na próxima vez que tive seu projeto pela frente.

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.

Muito sem tem dito, hoje, sobre a questão da gestão de projetos. Nisso, incluo a famosa atual discussão da aplicação de metodologias ágeis, que antes eram práticas aboninadas, frente aos sucessivos fracassos que as gestão waterfall (gestão de atividades em cascatas cuja a imagem mais forte são os gigantescos cronogramas em gráficos de Gantt). Embora exista, de uma certa forma, um guerra entre os padrões – ora um diz que é melhor por um motivo, ora outro diz que não é nada disso, ambos mostram casos de sucessos e erros dos outros e por ai vai – existe pontos bastante comuns  em seus discursos, como por exemplo: foco na satisfação do cliente, busca por altos rendimentos – produtos entregues mais rápido, com maior qualidade, etc.

Ninguém está errado em querer focar em agradar seu cliente, muito menos na busca por maximizar seus lucros ( vender mais e gastar menos para realizar, etc). A questão que gostaria de discutir é a mensagem vinculada que vem sendo dita por ambos que remete a querermos trabalhar sempre próximos de nossos limites (alta disponibilidade, entregas super rápidas, e outras coisas parecidas)

Não é errado quere maximizar os trabalhos. O problema está em sempre querer usar e fazer as coisas no limite ( para cima ou para baixo)

Outro dia  conversando com um amigo,falvamos da situação atual onde temos empresas onde tudo é maior, melhor, alto, etc. Empresa, que devido a uso de alguma metodologia “bala de prata” , as entregas são super rápidas,  projetos com alta tecnologias,  sistemas com as últimas novidades, e (ufa!) por ai seguem.  Tudo feito no limite, tudo é SUPER (quando digo limite falo do fato de todos terem desempenhos fora do comum). Se me permitem a brincadeira, é  verdadeiro local de trabalho de sobre humanos, pois trabalhar sempre no limite máximo é algo bem difícil para nós mortais. É como se tivéssemos “pessoas” correndo a velocidades de provas de 100m durante uma maratona. Para seres humanos comum é algo que dá para fazer nos primeiros 200m mas depois não dá… simplesmente não dá.  A gente acaba “abrindo o bico”

Não seria nenhuma surpresa se numa empresa como esta surgissem pessoas tendo crises de estresse (com variações agudas como por exemplo sindrome do pânico), pessoas com saúde comprometida, um número razoável de pessoas acima do peso, pessoas fumantes, etc. Considerando que ainda não temos super -homens por aí, ao não ser nos filmes e novelas (ehehehehe), mais cedo ou mais tarde algo deve acontecer.

Alguns pensam que podem correr um maratona mantendo a velocidade de corredores de 100 m. Simplesmente não dá e acabam que não completam todo o percurso.

Existe um preceito budista, no qual eu acredito que é : ” O melhor caminho é o do meio” . Diz alguns historiadores que Buda ( na época o princípe Siddhartha Gautama ) em seu caminho para a iluminação começou tentando seguir pelo caminha dos homens santos hindus fazendo jejuns, e se submetendo a sofrimentos como forma de purificar.  Foi quando num dia de meditação percebeu que o caminho não estava no limite e sim no meio termo.  Não podemos deixar ir sem regra alguma mas também não podemos colocar todas as restrições. Devemos buscar o equilibrio para nos tornar sustentáveis na caminhada da iluminição.

Equilibrio

Antes que comecem a dizer que estou ficando maluco e escrevendo coisas sem nexo algum, vamos traçar a correlação dos preceito budistas e trabalho.

Me assusta um pouco o fato de que atualmente, muitos tentem vender o uso de metodologias ágeis como um forma de aumentar o rendimento da empresa. Isso, num primeiro momento pode soar até inocente, mas para um empresário, isso irá soar como aumentar lucro.  A questão que quem está mostrando a idéia esquece de dizer que é verdade que melhora a qualidade e a velocidade do time de desenvolvimento (na maioria dos casos) mas isso não é para ser usado como motivo para aumentar a carga de trabalho da equipe e sim permitir um equilibrio maior. Tal equilibrio significa fazer menos horas extras, ter uma jornada de trabalho mais leve e que permita as pessoas irem para suas casa felizes e ainda com energia para conviver com suas famílias, ou então, realizarem outras atividades como esportes, estudos, etc. O mais engraçado disso que relendo o manifesto agil e alguns textos mais antigos sobre o assunto notei que, eles sempre carregam uma mensagem de foco no humano… na visão do profissional não como recurso e sim como individuo e trabalhador criativo que tem necessidades a serem atendidas.

Outra palavra chave que quero adicionar a nossa equação é : SUSTENTABILIDADE. Modelos que andam no limite não são sustentáveis… pois trabalhar sempre na modalidade de capacidade total significa maximizar também os desgastes.  A natureza mostra que devemos sempre buscar uma velocidade de cruzeiro, ou seja,  um rendimento tal que possamos andar bem mas sem tocarmos as fronteiras do recurso ou pessoa. Sustentabilidade também tem relação com pensar no futuro. Por isso, sempre querer inovar em tudo, pode acarretar em não ser sustentável no médio nem no longo prazo.  Viver trabalhando com as  últimas novidades ou com padrões, que ainda não estão totalmente difundidos no mercado, é buscar um vida dificil  para o Rh. Pois as pessoas que lá estão hoje, por gostarem de novidades, logo mudaram o foco de seu interesse para outras coisas e aquele sistema ficará, lá, legado a ninguém pois, ainda não existem profissionais disponiveis no mercado com o tal conhecimento.

Por isso, volta a frase:  ” O melhor é o caminho do meio”.  Temos sim que tentar aumentar nosso tempo de resposta a projetos, ajudar as empresas a ganhar dinheiro, entretanto é importante também garantir a sustentabilidade do processo e das pessoas.

O ato de apresentar é algo que parece que veio para ficar. Em quase todos momentos de nossas vidas profissionais nos é solicitada algum tipo apresentação por mais diversos motivos.  A questão, após a leitura do livro de Garr Reynolds – “Apresentação Zen” , que a maioria delas são de uma qualidade no minímo, para não falar pior, de qualidade questionável.

O tempo todo em nossos trabalhos somos solicitados a reportar algum status,  objetivo, mensagem, etc. Algumas dessas vezes podem ser simples  conversas, respostas as e-mails, ou então montarmos uma apresentação para uma platéia (pequena, média, grande ,etc). Muitas as pessoas que, inclusive, vivem de fazer palestras, etc.  Tais palestras,  podem ser  um congresso acadêmico onde mostra o resultado de um estudo ou pesquisa, um trabalho de faculdade, mba ou mestrado, pode ser um fechamento de um ciclo de trabalho, apresentação de uma auditorio ou consultoria feita, venda de um serviço ou produto, enfim, várias coisas. Logo, pelos exemplos citadas antes, podemos dizer que a grande maioria de quem faz apresentações não são especialistas em comunicação, ou design ou qualquer coisa correlata.

A grande parte de nossos palestrantes são pessoas comuns( administradores, engenheiros, vendedores, etc – pessoas sem grandes conhecimentos de ferramentas ou conceitos de design e/ou comunicação) e por isso, muita delas são levadas a não ter um grande cuidado com a forma que eles estão expondo a informação desejada. Bem, sobre um ponto de vista, existe preocupação sim: quase todos estudam o assunto, procuram boas fontes ou apoio de bons números ou gráficos, etc… o que não se tem é uma atenção a importancia do como essa quantidade de coisas será dispostas e apresentada.

Essa questão da falta de capricho (sei que não é o melhor termo mas não me ocorreu nenhum outro) de certa forma só agravou com o advento das  ferramentas como o Power Point – podemos dizer também slideware. Devido a motivos que ainda desconheço, essas ferramentas, fornecem um tal de Template, ou seja, um desenho padrão onde o trabalho do indivíduo fica sendo apenas de preencher as lacunas. Isso, para a grande maioria leiga não é de todo mal…  a questão que esses templates são todos baseados numa estrutura analítica que acaba tornando a apresentação, para o espectador, um verdadeiro desafio para contornar o sono que vem.

Outro dia, na empresa onde trabalho, fizeram um dia (inteiro) de palestras onde várias pessoas apresentaram diversos ppt (apresentações power point) sobre os mais variados temas. Acredito que o objetivo da jornada era de ser uma forma de vermos os objetivos do grupo, status dos projetos, como estavámos em relação as metas que foram traçadas no começo do ano, etc.  Mas, confesso, que no final, o evento foi um exercício de “luta contra o sono”.

StockVault Photo

Mas porque que não gostei das apresentações ? Os temas não me interessavam? Os assuntos tratados não tinha relação com meu dia a dia na empresa ? Por mais que tudo que havia sido dito, apesar de todos os temas serem de grande importância,  as palestras foram um verdadeira pé no saco pois ninguém se preocupou em momento algum com forma dos malditos slides. Alguns, inclusive, tiveram a cara de pau de ler os slides, ou seja, não agregam valor nenhum.  Os conteúdos, em sua grande maioria, eram cópias de trechos de planilhas do excel, numa fonte ilegível do meio da sala, com números e mais números que não nos diziam nada; gráficos com uma quantidade enorme de linhas ou elementos que os tornavam, num primeiro relance, difícil de analisá-los ou captar suas informações; slides tomados de textos e mais textos, todos arrumados lindamente (estou sendo ironico) em bullets; etc.

StockVault

Tudo isso poderia ter sido diferente, se tivessem tido o cuidado de, antes de qualquer coisa, conversado para definirem qual seria a mensagem a passar com o dia. Feito isso, como a mensagem mãe, na cabeça partir para selecionar os temas que deveriam ser abordados durante a jornado que ratificassem, ou que levassem a mensagem principal para os ouvintes.  De posse da mensagem e dos temas, partiria para definir o tom, a emoção desejada. Pode parecer loucura, num primeiro momento, mas faz sentido se analisarmos de mais perto.

Ao realizar um evento temos que nos preocupar, além dos temas, etc, com o conteúdo emocional. Conteúdo emocional seria algo como : é para mexer com o pessoal, é apenas para informar, é para motivar,  é para dar um esporro, e por ai vai.  Por mais que a mensagem seja a mesma, a escolha do tom modifica a dinamica dos fatos e o desenrolar de cada apresentação. Um aspecto que muda também é a forma da exposição oral:  vibrantes, concisa, sóbria, etc.

Tendo todos os elementos em mãos- tema, mensagem mãe e a tom emocional desejado – o próximo passo seria partir para a montagem dos slides. Sempre tendo em foco que ninguém consegue ler e ouvir ao mesmo tempo e ainda por cima reter boa parte da informação. ACho que uma boa dica é abusar das imagens e seus significados dentro do contexto. Gráfico… huumm.. desde que sejam pequenos e rápidos de serem entendidos…. Números …. poucos apenas para retradar algo que se fale… texto… evite-os ao máximo.

Esse conceito pode ser extrapolado para diversos outro tipos de materiais : post em blogs, relatórios,  monografias, e-mails, manuais, etc.  Claro que cada caso terá sua particularidade, por exemplo, não podemos querer escrever um relatório sem usar muitas palavras, mas podemos ter cuidado com os gráficos, com excesso de números, tabelas, etc.

Bom, boa parte dessas idéias não são minhas. Elas são conclusões que venho tirando de diversos materiais e livros que venho lendo como forma de melhorar a forma que divulgo conteúdo, apresentações e etc. Um em particular tem sido minha biblia : Apresentação Zen – Garr Reynolds ( citei lá cima já, mas é para reforçar)

Um outro dia estava eu e um amigo discutindo sobre linguagem e acabamos por falar sobre a questão do C# possuir o “using”. Ele é uma das coisas interessantes que o C# tem em relação a outras da mesma familia (como Java).
Para começar é preciso entender que o using tem 2 possiveis usos:

Um outro uso possível e bem util do keyword é o seguinte: Imaginemos a situação que você tem um Reader de arquivo e vai efetuar a leitura do conteudo:

Bom nesse caso, tudo funciona ok… entretanto imagine o caso da classe cliente, por exemplo, ser nula, ou seu metodo de incremment dispare uma exceção. O sistema irá sair do bloco de codigo e não vai fechar o reader. Isso pode gerar diversos problemas futuros como lock do arquivo e etc. Para resolver isso, muitos diriam – “coloca o bloco de codigo dentro de uma estrutura try catch finally”. Excelente, vamos lá:

O código acima garante a robustez, mas, pelo menos para mim, o código fica muito “poluído”. Vamos agora ver um outro uso do using:

Fazendo isso, o interpretador, ao final garantirá o close do Reader. Isso também é valido para Connections (conexão com o banco de dados por exemplo). Isso deixa o codigo bem elegante. Outra coisa que esta clasula garante que o tempo de vida da classe é somente da execução do bloco, ou seja, ele realizará o dispose do objeto assim que terminar ou sair do bloco. Isso ajuda bastante a evitar os memory leaks e deixar seu codigo super elegante e perfomante.
Aos poucos vou colocar mais tutoriais como este e sobre outras linguagens. Caso tenham duvida podem mandar email ou deixar comentário que tento responder por email ou por meio de um post.

Estava escrevendo um sistema no meu trabalho em C# (csharp) onde se conecta ao log de uma aplicação e escreve as linhas deste num panel (winform). A primeira dificuldade foi como poderia permanecer lendo o arquivo de forma continua. Resolvi com o trecho de codigo abaixo:

Bem isso funcionou bem, a questão que ao fazer isso, por padrão o sistema trava o arquivo não permitindo que outro processo possa escrever no documento. Como queria apenas ler e permitir que a aplicação continuasse a escrever seu log, a solução foi, explicitar o a abertura do arquivo, pelo metodo Open, algumas diretivas. Fica mais ou menos assim:

Isso funcionou legal e me serviu bem pois agora tenho uma ferramenta simples para ficar vendo o log da minha aplicação.