Pessoal a muito tempo estou devendo a publicação dos slides que eu fiz no FISL 2010. Bom, menos uma pendência em meu back log. Segue abaixo a apresentação. Espero que gostem.
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.
Uma das coisa que escutei e sempre repeti por realmente acreditar que faça sentido é que, existe a ferramenta certa para cada tipo de trabalho. Não adianta acreditar que aquela “paradinha” maneira que você conhece de “traz para frente” vai ser a melhor solução para todos os seu problemas, pois simplesmente como uma verdade absolut, ela não será e quem a criou sabe disso. Note que eu disse – “não será a melhor opção”- e não = “não resolverá ou não fará”.
Acredito que todas a novas linguagens são capazes de resolver a grande maioria de nossos problemas computacionais atuais. Em raríssimos casos poderemos apenas usar uma determinada linguagem…muito mais por requisitos de processamento, velocidade e etc do que capacidade daquela linguagem. Falo isso, pois cansei de ouvir gente dizer que a linguagem B não é capaz de fazer o que a linguagem C faz. Ela faz sim, só que de uma forma mais complexa ou mais verbosa, por exemplo.
Sei que tocar nesse assunto é meio “chover no molhado” por ser este um tema muito falado e batido, porém, gostaria de dar uma visão real disso. Imagine você numa situação em que precisar fazer um sistema. Este sistema possui várias facetas: uma parte para cliente, outra que ficará com um processamento em batch (background), etc. Já tive requisitos como estes em diversas oportunidades e em cada uma delas foi uma solução adotada. Posso dizer que o pior dos casos foi quando tentamos usar a mesma “estrutura” para tudo.
Imagine que agora você comece a aplicação para os requisitos acima e faça tudo dentro de um servidor de aplicação. Aquela típica solução Java, onde um dentro do JBoss ou outro esteja tudo… Ali estão a lógica do sistema web, os processamentos em batch agendados via Quartz, etc. Imagine também que isso tudo estará dentro de um servidor Linux (qualquer distribuição que seja) - coisa bem factivel. Dái começo a colocar algumas perguntas: se todo sistemas linux tem um Cron (serviço de agendamento) por que usar algo feito em java para fazer a mesma coisa? Se argumentarem que é para garantir a independencia de plataforma, pergunto qual são as reais possibilidades de mudar a plataforma (SO, etc) ? Com certeza que bastante remotas.
Esse tipo de coisa pode ser ainda mais extrapolado. Imagina agora que dentro do seu sistema é preciso processar diversos conteúdos de arquivos e importar seus dados para a base de dados do sistema. Muito fariam uma classe para que você fizessem um upload e processar. Mas não seria mais interessante deixar que alguém carregue via ftp e um processo agendado trate-o depois. Esse processo poderia ser algo escrito em bash mesmo pois será ultra rápido em comparação a uma aplicativo java. Mais uma vez aqueles xiitas diriam que seria para manter a questão da independencia de plataforma, mas quantas vezes sua web app mudou de servidor (SO, hardware, etc) nos últimos anos?
Se ousarmos um pouco mais, dada as recente evoluções da JVM (Java Virtual Machine) as possibilidades vão além de usar o sistema operacional. Hoje é possível escolher em qual linguagem irá escrever cada parte de seu sistemas e estas coexistirem sem nenhum problema. Antes que pensem que isso é um discurso de incentivo ao uso de Java, linguagem da qual gosto, estou usando esse ela como exemplo por ser um bom exemplo de como isso funciona e tem sido alvo de investimento.
Famosos produtos tem usado uma “tecnologia” para fazer a parte de integração com usuário e outra para fazer toda a parte de Kernel do sistema. Acredito que o Twitter seja um exemplo disso, pois sua parte de interna foi toda reescrita em Scala (nova linguagem objeto- funcional da JVM) .
Voltando a parte prática da coisa, um exemplo de que é bom conhecer diversas ferramentas e saber empregá-las, é um caso num empresa que era preciso fazer medições de audiência em páginas. A solução inicial era de conteúdo dinamico em todas as páginas que quando acessadas iriam no servidor e gravavam um dado no banco de dados. Essa solução embora resolvesse o problema, ela acabava por onerar por demais o processamento pois tal parte não poderia ser posta em cache e a cada acesso, haveria uma requisição no servidor e um acesso ao banco de dados. O pessoal então passou para algo mais hibrido e pouco ortodoxo para época: fez uma modificação para que o servidor colocasse no arquivo de log os dados de quem estava acessando e construiram um programa em shell para analisar esses logs. Com isso, embora não tivessemos um “tempo real” dos acessos, para os nosso requisitos de estatísticas serviu perfeitamente e reduziu a carga e o processamento, deixando para uma outra tecnologia que lida melhor com busca via regex fazer o trabalho dela.
Essa solução não sei se funciona ainda, acredito que com saida da terceirizada que fez da empresa tenha sido tirado, mas foi uma marca para me mostrar que existem outras possibilidades além daquela que eu sabia na época. É isso que conta. E num mundo cada vez mais competitivo é importante ter mais de uma “carta na manga”.
Bem até a próxima pessoal.
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.