Blog do Andre Fonseca

Uma das coisa que me incomodam bastante no meio de informática é que muitos de nós são um tanto radicais. Canso de escutar pessoas dizerem que somente a tecnologia delas  – que elas usam – é a melhor. Em minha humilde opinião, comentários a parte (já escrevi, inclusive, sobre isso), não existe o ideal e a tecnologia mais adequada para o problema.

Como disse antes não quero me ater a discussão do porque não existe uma tecnologia legal e se devemos conhecer mais de uma pois isso, já amplamente abordado inclusive por mim.  Quero apenas rebater um poucos os fanáticos.

Atualmente temos uma clara evolução do uso de duas tecnologias principalmente: Python e Ruby. O Ruby quase exclusivamente impulsionado pelo Rails ( framework de desenvolvimento altamente produtivo de aplicativos web) e python pelo seu poder ( o famoso battery include) e também por alguns de seus frameworks ( Django, Web2Py, Zope, Plone, etc)

Uma coisa que me incomoda um pouco na galera é que por muitas vezes, o pessoal que está chegando agora, vem tomando logo formas de pensar radicais. Um exemplo disso é o discurso mais do que batido que Java é mal.

Gente, sinceramente, Java não é mal. Muito pelo contrário, foi uma grande porta, primeiro passo, para todo esse boom que temos visto. Java, embora não seja  opensource, sempre fomentou o software livre e acabou por criar uma comunidade forte em seu entorno. Essas mesmas comunidades  que são veneradas por  muitos dos que negam o java,  surgiram desse movimento graças ao Java.

O grande problema, da linguagem,  que ela parou no tempo. O que por um bom tempo, sobre somente alguns pontos de vista, ajudou a protegê-la foi o mesmo que a engessou-la. Se ela tivesse se aberto para modificação, mesmo que gradualmente, possivelmente  ainda estaria sendo usada e adorada como antes.

É certo que criar um aplicação em rails é muito mais produtivo do que criá-la em Java ( mesmo com todos os frameworks existentes).  O mesmo vale para o Python em até outros casos.  Então por que estou, aparentemente, defendendo-a? Simples, pois quero mostrar que ainda existe vida após a morte nesse nosso mundo de TI.

Java , para “competir”  com essa galera tem “renascido” com outras formas que permitem sermos mais produtivos.  Um exemplo que gosto muito é o Groovy. O Groovy, senão me engano, foi criado por 2002 ou 2003 como uma linguagem alternativa para rodar dentro da JVM (java virtual machine). Graças ao seu sucesso foi implementada a um especificação para tornar a JVM capaz de entender outras linguagens.

Groovy é um Java melhorada e evoluído para os moldes desses novos paradigmas trazidos por Ruby, Python, etc.  Trouxe uma produtividade maior. Hoje é possível fazer uma aplicação nos moldes de Rails em “Java” /groovy usando o framework Grails.

Outra faceta desse mesmo ponto de vista tem sido o JRuby. JRuby é uma implementação do interpretador do Ruby para a JVM. Assim é possível executar código escrito em Ruby a partir da JVM.

A coisa não para por aí. Basta uma simples busca no google para vermos outros exemplos desse renascimento em outras formas do Java.

E ainda tem a pŕopria linguagem que não para de evoluir e ainda tem o seu espaço. Acredito sinceramente, que existem alguns problemas (requisitos)  os quais a melhor solução seja implementar a solução em Java.

Bom com certeza ainda terão aqueles que dirão que suas linguagens tem as melhores ferramentas. Concordo plenamente. Para mim, falando por exemplo de testes – TDD e BDD,  cucumber, rspec, mocka, should-dsl, lettuce, entre outras são estado da arte. Porém, já encontrei coisas em “Java” (entenda aqui conseguir testar código java, pois tem ferramenta em Groovy por exemplo) que pelo menos chegam perto disso.

Bem a princípio era isso que gostaria de dizer, até a próxima pessoal.

A poucos dias atrás eu deu uma palestra numa PythonCampus ( foi na Estácio de Madureira) para um público de cerca de 50 a 80 pessoas.  Nessa palestra, mesmo que o tema principal tenha sido falar de como fazer grandes produtos em python, aproveitei para passar alguns pontos de vista para a galera que está começando agora.

Antes de mais nada é válido dizer que apesar que já está a um bom tempo na estrada, por várias vezes me sinto como eles: sem saber para que lado “atirar”.  Hoje, como profissionais de TI, somos bombardeados a todo momento com toneladas de post de blogs, twitters, artigos, livros, lista, etc dizendo qual será ou quais serão as próximas grandes tecnologias do momento.  Frente a esse quantidade exagerada de coisas, ficamos num “mato sem cachorro” tentando dimensionar nosso tempo para investir em algo que nos garanta um bom futuro.

Bem frente a isso, tenho um péssima notícia: não tem uma resposta pronta, somente o famoso depende. Cada caso vai pedir uma coisa meu caro e quanto mais saber mais opções terá e com isso, mais chance de acertar a escolha.

Embora o assunto seja fascinante e dê “pano para a manga”, o que gostaria aqui, hoje, de falar é quanto a reaproveita conhecimento.

Voltando ao assunto da PythonCampus, durante a apresentação aproveitei para pergunta para a galera presente, como um pequeno censo, quantos usavam determinadas linguagem. As duas que foram mais votadas foram java e .Net. Um brve parenteses antes de continuar: Ao contrário do que a maioria pensa . NET  não é uma linguagem e sim uma plataforma de desenvolvimento. Tanto que existe muitas linguagens que foram feitas para rodar dentro do .NET (C#, ASP.NET, VB.NET, IronRuby, IronPython, etc).

Dado que o mercado ainda demanda por profissionais que saibam usar essas duas tecnologias, .NET e Java, fiquei pensando como seria que uma pessoa poderia dar o passo adiante rumo a uma coisa mais produtiva e diferente.  Quando falamos com alguém que a vida toda trabalhou com Freelas (aqueles projetos pessoais que a gente cobra; aquele site do tio- entendeu?) e  que por isso usou bastante PHP, por exemplo, fica mais fácil apresentar para ele Python e Rails ; a pessoa já está acostumada com aquela natureza dinâmica e não burocrática e agora apenas aprenderá algo com mais ordem e etc.

Mas quando falamos de caras de Java, vem logo a imagem daquele moleque andando de roupa social  ou terno pelo centro do rio e trabalhando em grandes consultorias que cobram os olhos da fuça para fazer um helloworld e ainda por cima não entregam no prazo e nem perto do que o usuário queria.  Antes que me atirem pedras ou coisas afins, eu sei que nem toda a culpa é da linguagem tem muito do profissional.  Tendo essa perfil em mente, fica díficil converser aquele cara que ele deve aprender outro coisa. Ele não quer se esforçar muito mais e fica colocando defeito nas coisas para justificar sua preguiça.

Diante esse cenário caótico fiquei matutando um jeito que poderia servir de transição suave e assim, sem grandes revoluções e sim evoluções, levaria aquele cara para dentro de um mundo novo de possibilidades.

Para o caso do java, graças ao grande oraculo, aka Google, eu encontrei o Grails. o Grails é um spin off do raisl para a plataforma java usando a linguagem Groovy que roda dentro da JVM.  O GRails é uma implementação do rails em groovy. Segundo o próprio site do produto é rails melhorado pois pegar o que há de melhor e aprimorar frente as experiências da galera.

A parada é realmente boa e vale a pena baixar e testar. Com a vantagem de ainda ser Java embora a sintaxe do groovy seja muito produtiva caso resolva se lançar de cabeça. Assim como em Ruby on Rails, como muita pouca linha de código você consegue ter um site no ar.

Bem essa volta toda para dizer para a galera acordar para as coisas que estão acontecendo, para acordarem que não terão vida fácil,  não existe mais a linguagem solução e sim uma caixa de ferramenta e por aí segue.

A um tempo atrás alguém postou um comentário aqui no blog perguntando como ele poderia testar a questão do upload de arquivo usando o Selenium.

Bem, pedindo ajuda para o grande sábio Google, encontrei a página (clique aqui) com um trecho de código que reproduzo parte abaixo mostrando como fazer.

Pelo jeito ele somente irá funcionar para o IE pois os demais browser não aceitam que você digite no campo de file. (Me corrijam se eu estiver errado).

Espero que ajude:

Ultimamente, no meu emprego atual, tenho a oportunidade de usar um excelente framework de testes de aceitação brasileiríssimo que é o pycurracy . Ele é uma ferramenta feita em python que permite que você escreva suas histórias de aceitação em linguagem natural. Isso significa dizer, que você pode escreve o seu teste em português.

Não preciso dizer o quanto isso traz de vantagem. Só para citar, uma das mais imediatas, pelo menos para mim, é a questão da documentação.  Quem já está na estrada um tempo, sabe como é uma verdadeira luta manter documentações atualizadas do produto.  Tudo sempre começa bem, mas com o passar do tempo, sempre surgem outras tarefas mais urgentes e os “casos de uso”  ou histórias acabam ficando não condizentes com a realidade da aplicação.  Para muitos, isso pode soar como preciosismo porém imagine um contexto de um projeto open source… sem uma documentação bem feita, colaborar pode ficar bem difícil.

Um outro aspecto também é que desenvolvedores “não são muito amigos” de escrever documentos. Esta aí uma tarefa que vejo poucos colegas fazerem com prazer. Se puderem evitar, a grande maioria em minha humilde opinião,  evitarão fazê-lo.

Ferramentas como o pyccuracy, vem unir o “útil ao agradável”: vem possibilitar escrever testes, programando, e como resultado indireto obter uma excelente fonte para consultas.  Por permitir escrever os cenários  em linguagem natural (inglês e português) acabamos por ter um documento descrevendo o funcionamento esperado… as nossas histórias.

O pyccurace é todo feito em python usando o Selenium .  Para maiores detalhes recomendo uma visita a página do projeto.

A única coisa que tenho a dizer sobre ele é que bem que poderia ter uma implementação que usasse o WebDriver ao invés do Selenium RC. Acredito que ficaria bem mais rápido. Mas, até agora só temos versões estáveis do WebDriver para Java. A versão python está bem timida ainda.

A pouco tempo consegui um brecha com ajuda da minha colega Arlene para implantarmos no projeto que estou trabalhando teste automatizados.  Com a carta de alforria em mãos partimos para pesquisar no mercado qual seria a melhor que se encaixaria em nosso contexto de aplicação.  Para que entenda,  trabalhamos com desenvolvimento de portal usando a ferramenta Lumis (eu trabalho na Lumis!!!).  Portais são aplicações bastante difíceis de serem testadas de forma automática; devido a questão do conteúdo dinâmico e pouco previsível não existe muita margem para que busque por padrões.

Com estas limitações em mãos, acabamos nos deparando com a api WebDriver . A um tempo atrás eu já tinha mexido um pouco com o selenium e adorei. Com isso, tentei achar algo que se assemelhasse a ele mas que me facilitasse a vida em relação a portais ( não tem muito como usar ids dos elementos no html, url não fixas, etc) . O webdriver, ao contrário do selenium, não é um javascript que executa dentro de uma página simulando a navegação… o webdriver é realmente um “envelope” em cima do seu navegador.  No caso do Firefox ele é uma extensão, no caso do Internet Explorer (blargh) ele usa as chamadas de control que ele proporciona, e por ai vai. Com isso, os teste ficam mais próximos da realidade de uso do usuário, e a api para escrever  os cenários mais simples.  Veja o trecho:

Pelo exemplo acima fica fácil de ver o quão fácil é criar um teste em webdriver.  Recomendo experimentar

Se você é um leitor assíduo do meu blog, já deve ter percebido o quanto gosto de testes automatizados. Não só gosto como acredito neles e no retorno que eles proporcionam. Sempre que tenho a oportunidade procuro “vender esse peixe”. O interessante é que com isso acabei escutando alguns exageros que chegam a ser engraçados.  Um exemplo foi após uma conversa em que até rolou uma  sessão de codificação em par com a pessoa, no final, ela soltou a seguinte pérola :”Agora então não preciso mais do pessoal de teste“.  Opa! Devagar com o andor que o santo é de barro, meu amigo.

Antes que concorde com isso,  deixa eu mostra meu ponto de vista.  Teste automatizados ajudam muito e realmente tornam a vida do desenvolvedor e do cliente melhores.  Torna a vida do desenvolvedor mais fácil quando permite que ele faça seus testes rapidamente e detecte um erro o mais cedo o possível.  Para o cliente significa que a automação mais testes podem ser executados num tempo menor e com isso mais qualidade com menor custo.  Mas e a história do cara de teste, onde entra? Calma.  Para automatizar os testes devemos fazer algumas considerações e escolhas.  Para facilitar o que quero ilustrar, imagine um portal. Portais são aplicações webs muito interessantes, pois a cada acesso o seu comportamento pode mudar e isso não é necessariamente um erro.  Por isso, testes automatizados, em ambientes como estes são bem complicados de serem feitos e levam a gente a fazer algumas “adaptações”. Com isso,  os teste acabam validando parte das coisas e logo, ainda temos a necessidade de uma pessoa testando.  Entretanto, agora, essa pessoa não precisa estar testando tudo e qualquer coisa. Ele pode focar um pouco mais, realizando apenas verificações pontuais.

Outra frase que sempre escuto é a questão do recurso e gastos.  Geralmente quando converso com os gerentes sobre testes – principalmente os ditos PMI – eles quase que instantaneamente dizem que isto é inviável e trabalhoso. Bom, primeiro devemos definir o contexto:  se imaginarmos os famosos “cowboys“, rapaziada que desenvolve a culhão e não teste se o objeto que eles estão pegando é nulo, realmente testes automatizados são trabalhosos, pois não fazem nenhum.  Para aqueles que pretendem o mínimo de qualidade, dá para dizer que, realmente, NO INÍCIO,  testes automatizados demandam mais tempos, mais se olharmos ao longo da linha tempo esse custo se dilui e tende a zero. Isso porque, após todos os casos criados, o trabalho será de executá-los e mantê-los atualizados.  Fora que, imagine o custo de pessoas, máquinas, tempo,  para que a cada alteração que um desenvolvedor fizesse na aplicação, toda ela fosse retestada.

Enfim,  caso ainda não acredite em mim quando digo que ferramentas de testes são legais e estão aí para nos ajudar,  experimente e tire suas próprias conclusões. Duvido, sendo você empresário, gerente pmi, coordenador, desenvolvedor, cliente, etc no final não ficará pelo menos tentado a usar algum no seu próximo projeto.

Mais uma vez, devido a uma outra troca de e-mails,  vi um outro assunto super legal que gostaria de dividir com vocês.  A um certo tempo atrás, no blog do Calcado, li um artigo sobre o fato de objetos não serem atributos + funções. Neste artigo, o Calcado, mostra que os objetos ao invés de possuírem atributos e funções, eles na verdade possuem estados e comportamentos.  Reproduzindo um trecho do artigo :

Objetos não possuem propriedades + funções, eles possuemestado + comportamento. Você provavelmente vai usar atributos (i.e. variáveis de instancia) e funções (de instancia também) para implementar isso mas é um detalhe de implementação, não algo que deva ser exposto [sic]

Uma outra coisa que penso é que além disso que ele comentou, uma outra dificuldade que vejo no pessoal que está “montando” a arquitetura de sistemas, é definir como será a interação entre objetos.  Quem nunca ficou horas pensando onde colocar determinado método – “o método calcular preço  é da loja ou do produto?“; nome do método,  se deveria expor dados por get e set, etc .  Essa dúvidas vem da nossa visão equivocada da troca de dados entre objetos.

Se considerarmos que objetos não possuem métodos ou funções( função me parece tão modular e não OO) e sim “portas de entradas”.   Essas portas são como caixas de correio por onde enviamos e/ou recebemos mensagens com pedidos ou informações.  Para ficar mais fácil de entender,  imaginemos a situação de uma grande rede de lojas.  Esse grande rede possui diversas lojas, que possuem diversos produtos e clientes.  De cara, podemos dizer que temos 3 entidades :  Cliente, Produto e Loja.

Agora a pergunta: como você implementaria a lógica de obter preço – o cliente vai na loja, pega um produto e quer saber o preço.  Tenho certeza que alguns diriam que colocariam um método getPreco na classe de produto.  Outros fariam um PrecoControlador que pegaria o custo do produto e faria a operação de cálculo pegando a margem de lucro da loja, custo da loja e por seguiria…. Outros inventariam a classe preço que diante a loja e produto se calcularia….  De novo fazendo assim ainda estamos pensando em objetos como conjunto de funções e atributos e esquecendo da troca de mensagens.

Uma forma que vejo mais simples e mais expressiva de fazer (logo fica mais claro para entender o sistema) seria de perguntar para a loja o preço. Sendo assim, o cliente teria um produto e perguntaria a loja o preço. A loja consulta sua tabela de preço e responde.

Cliente  – pega produto —  > Produto

Cliente — informa o produto a loja –> Loja

Loja — consulta tabela –> Tabela

Loja — responde ao cliente –>

Fica bem elegante não… Mas se ainda não conseguiu ver:

class Andre  extends Cliente

…

Produto lapis = new Lapis();

double preco = lojaAbobrinha.qualEhOPreco(lapis);

..

Abobrinha extends Loja

…

double qualEhOPreco(Produto produto)

minhaTabelaPreco.qualPrecoAtual(produto);

Quem for fazer a manutenção do código,  só de ler, já começa a entender oque está acontecendo e começa deduzir as demais interações.

O site artima developer noticiou que o pessoal da  google lançou a versão 1.o da api de collection do google. Essa api visa extender a api de collection atual do java trazendo facilidades e novas funcionalidades que eles entederam necessárias.

O Google Collections Library é uma extensão do Java Collections Framework, e é destinado a tornar mais fácil trabalhar com coleções Java com muitas melhorias e tipos adicionais de collections. A base de código da versão 1.0 da biblioteca de Coleções do Google, que foi lançado na última semana, irá eventualmente ser integrada na Google Guava (biblioteca de código aberto).
Novos tipos de coleção no Google Collections inclui Multimap, permitindo-lhe associar valores múltiplos com uma única chave, Multiset, que é como  Bag, permitindo que várias ocorrências de um elemento na coleção, e BiMap, um mapa que mantém a integridade dos seus  valores e suas chaves e permite a reversão de chaves e valores.
ImmutableSet é uma aplicação mais rápida, imutável do HashSet, e há também uma subclasse ImmutableSortedSet na biblioteca. MapMaker é um construtor de ConcurrrentMaps que fornece uma interface fluida (fluent interface) para especificar muitas características do mapa. Estas são apenas algumas das muitas aulas oferecidas pela biblioteca.

leia mais clicando aqui