Blog do Andre Fonseca

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

Uma das coisa que me incomondam bastante é toda vez que vou iniciar um projeto, e tenho que montar um ambiente de desenvolvimento, perco horas e mais horas para completar a tarefa. Tudo porque, na maioria das empresas para as quais trabalhei, trabalho e trabalharei,  nunca tem um processo automatizado e padronizado de montagem de ambiente.  Sei que isso pode soar um tanto burocrático e o pessoal que odeia qualquer coisa que possa virar papel vai dizer que isso é uma heresia, mas acredito que é um mal necessário.
Para a grande parte das pessoas que começam numa nova empresa, projeto, etc, a rotina sempre a mesma :  horas baixando instaladores,  horas instalando tudo (pior se for em windows, pois as vezes tem que dar reboot na máquina), mais um monte de outras horas para configurar, criar usuários, baixar código, entender como funciona o build, e por aí se vão dias de trabalho gerando zero de valor agregado para o cliente.  O mais esquisito, que mesmo sendo isso um mega prejuízo para o projeto – uma pessoa consumindo horas do projeto sem fazer “nada” , não existe nenhum movimento para mudar essa realidade.
Não estou falando de processos ultra-automatizados que lê mentes e pelo jeito que você diz bom dia monta a sua máquina,  estou falando de coisas simples, como padronizar, repositórios internos de instalações e bibliotecas, uso de produtos que automatizem build e tarefas repetitivas, etc.  Estou falando também de, no caso de empresa maiores,  uma imagem de ambiente (backup) padronizada para que quando um novo desenvolvedor chegue, basta comprar um novo computador, baixar a imagem e configurar.
Não faltam ferramentas, produtos e soluções no mercado que podem ajudar a qualquer um a resolver isso. Em aplicações java, temos o maven (maven.apache.org) que pode cobrir muito bem quase toda o problema:  ele pode montar o projeto, instalá-lo, baixar as bibliotecas, configurar ambiente, compilar e fazer build, etc; além dele existe a opção de escrever em ant (ant.apache.org)  diversos scripts para automatizar build de aplicação, montagem de ambiente, etc. Em Ruby,  aqui não muito minha praia, acredito que existe o gems e o rake que facilitam bem esse trabalho.  Para os passo não cobertos por essas ferramentas, existem outras.  Em última instancia, pode ser colocado como uma história do sprint ( ou uma tarefa de backlog) e assim criar um programa que faça isso (bash, bat, cmd ,etc).
A questão mais importante é que exista algo padronizado e de preferencia automatizado, fazendo que se perca o mínimo de tempo possível com tarefas que não agregam valor ao cliente que está pagando.  A ideia é exatamente de não perder tempo com coisas que não geram retorno: atividades repetitivas, processos  que podem ser automatizados e outras coisas, maximizando o foco na funcionalidade.

Ultimamente é mais do que batido famosos artigos comparando linguagens e com conclusões um tanto radicais do tipo : “A linguagem B é melhor que C pois é mais produtiva”; “A linguagem P não escala”; “A linguagem Z é mais fácil e tem tudo que é necessário já integrado”; etc.  As questões que coloco frente a essas publicações são: Existe escolha perfeita ? Será que os contextos usados são justos, ou seja, permitem uma comparação em igualdade? Dá para comparar ou isso é apenas uma discussão como “sexo dos anjos”? Recentemente a discussão ganhou mais força com uma recente divulgação, não oficial, de que os desenvolvedores da Google estão sendo desencorajados a usarem Python em novos projetos [1]  .Na troca de emails, a decisão é justificada no fato que, o senso comum dentro da empresa acredita que o Python, dado o crescimento e escala das aplicações atuais, não responderia de forma satisfatória.

Java foi inventada na década de 90 (sua primeira versão foi por volta de 1995) e sua origem é bastante interessante e pouco conhecida do público em geral.  Java, antes chamada por Grosling de OAK (Carvalho em inglês), foi criada com objetivo permitir a comunicação entre diversos equipamentos, que não somente o computador. Nesses projeto, a intenção não era de criar um nova linguagem e sim uma tecnologia de convergência. Por um capricho do destino, as empresas não gostaram tanto e não compraram a ideia.

Nesse mesmo período a internet começava a se tornar o sucesso de hoje.  Com um crescimento rápido e em pouquíssimo tempo uma grande interativa estava se formando. Era exatamente este tipo de conectividade que a equipe de Grosling propunha. A ligação foi imediata e partiram para adaptar a OAK para esse novo possível uso. Assim nascia a primeira versão de Java. Ela foi totalmente concebida dentro do objetivo de “trafegar” em ambientes heterogêneos. Seu primeiro momento de sucesso veio do uso dos Applets (aplicações java que rodavam dentro do navegador através de uso de plugin) que deu um tom dinâmico ao, até então, estático hiper texto (html).  Daí por diante a adoção e crescimento do Java foi meteórico e hoje temos esse cenário onde ela é a principal tecnologia usada por grandes empresas em seus sistemas.

O interessante dessa história, é que durante muito tempo do início da linguagem, Java era considerada ruim. Isso mesmo ruim: muitos afirmavam que sua natureza multi-plataforma, sendo interpretada, a tornava lenda e muito pesada, pois consumia muita memória dos pobres PCs da época (antigamente memória e disco eram caros). Não foram poucos artigos escritos que afirmavam que, num ambiente corporativo, Java jamais seria aplicável  pois sobrecarregava demais o equipamento e não era escalável (lembra alguma coisa não). Tais problema realmente existiam, como por exemplo, a questão das strings, do tempo de interpretação, o problema do AWT (biblioteca para aplicações desktop), etc.

A questão que várias investimentos e esforços, ao longo do tempo, foram feitos para que a linguagem fosse melhorando e se tornando mais robusta e perfomática. Primeiro foi a adoção completa do bytecode, hotspot, melhoria constantes no algoritmo de garbage collector(coletor de lixo – parte responsável por retirar da memória os objetos que não estão mais em uso), api de threads, melhorias significativas na parte Desktop, e por aí seguem as mudanças. Hoje já estamos na sua sexta versão e em breve virá a sétima. A linguagem que temos atualmente é completamente diferente daquela lançada em 1995 embora ainda guarde muita da filosofia e arquitetura.

Claro que paralelamente as sucessivas melhoras, os próprios computadores e servidores evoluíram muito também. Hoje é normal termos máquinas pessoais com mais de 2Gb de memória e discos rígidos de 500 Mb. Se pensarmos em servidores, a um custo bastante acessível é possível adquirir equipamentos de até 64 Gb de memória, 4 processadores, 64 Bits, etc. Isso logicamente tem um impacto: não tem grande relevância o uso de memória ou cpu por uma linguagem, guardando as devidas proporções, é claro.

Bem fato é que Java é usada amplamente em diversas empresas e representa um parcela significativa do mercado de desenvolvimento. Graças a sua natureza “gratuita”, porém não aberta – mais adiante isso será melhor abordado – uma grande comunidade em seu entorno se formou, facilitando a sua adoção e incrementando a experiência do desenvolvedor com bibliotecas, frameworks, ferramentas, etc.

Porém dado o seu sucesso e sua ampla adoção, parece que Java passou de herói para vilão:  as pessoas mais revolucionárias afirmam que ela é ruim, muito presa, evolui lentamente, extensiva demais, pouco produtiva, etc. Não faltam quadros comparativos de classes Java que fazem algo e outro com código da linguagem B que faz a mesma coisa com bem menos linhas.  Não faltam blogs com artigos dizendo que Java não livre e que é corporativa, que não possui uma sintaxe clara e legível. E por vão outros exemplos.

Duas “linguagens” e suas comunidades se destacam: Ruby e Python. O interessante que ambas, inclusive, surgiram antes do Java.  Seus pontes fortes são sua alta produtividade através de abstrações em alto níveis, sintaxe doce (suggar sintaxe) – um forma de escrever sem grandes amarrações (ponto-virgula, chaves, etc) e extremamente legível -  e natureza dinâmica (podemos alterar o comportamento dos objetos, funções e módulos em tempo de execução de forma ultra simples – meta classes é um exemplo). Outro aspecto relevante é o fato dela serem, realmente open source – software livre : ambas são mantidas e evoluídas pela comunidade não existindo uma entidade, diretamente, responsável por controlá-las.

A primeira questão que fica é : será possível comparar Java a Ruby ou Java a Python ? Dependo do contexto e das métricas.  Podemos dizer que, considerando a sintaxe legíveis e concisas, Java  “perde” pois tem uma escrita mais rígida, formal e menos “humana”. Exemplo

Ruby

10 times do put “Andre Fonseca” end

Java

for (int i = 0, i < 10, i++){

System.out.println(“Andre Fonseca”);

}

Porém essa “fraqueza” do Java lhe confere característica que em outro quesito a torna mais interessante escolha que as demais. Se agora considerarmos, questões como consumo de memória e recursos de máquinas, um código Java ganha com uma boa margem dos demais. Mesmo pensando em Cloud Computing, onde um aumento de demanda pode ser resolvido com acréscimo de máquina, Java parece se mostrar economicamente melhor pois precisa de menos máquina para atender a uma mesmo disponibilidade.

Sendo assim uma conclusão que podemos chegar seria que grande parte das comparações e suas conclusões são inúteis e pouco esclarecedoras. Cada um aborda no contexto que favorece a sua preferida e no final todas são melhores do que as demais, em algum aspecto que seja.

Outra coisa que é extremamente vaga é quando se afirma que “tal coisa não escala” .   O fato de um aplicação ser capaz de aguentar um crescimento de acesso ou uso está muito mais ligada a sua arquitetura do que na tecnologia usada.  Se fosse assim, todas aplicações de massa (sites, portal de jornais, twitter, etc) deveriam ser feitas em assembly pois assim seriam ultra otimizadas.  Um bom exemplo é que vários sites e/ou ferramentas de grande acesso foram feito em Ruby ou Python e funcionam perfeitamente (com alguns problemas que são normais).

A segunda pergunta é se existe uma escolha perfeita e definitiva. Diante a tudo dito até aqui, fica fácil concluir que a resposta coerente seria NÃO . Existe sim, uma escolha coerente com o contexto do desenvolvedor, usuário, recursos, etc.  Qualquer aplicação pode ser feita em Java ou Ruby ou Python, cada uma terá seus pontos fracos e fortes. Cabe ao desenvolvedor colocar tudo isso de forma ponderada e ver quem lhe trará mais lucro frente ao objetivo almejado.

De forma conclusiva e de acordo com os fatos expostos, fica claro que não existe comparação definitiva, nem justa, pois sempre dependerá do contexto e do objetivo desejado. Além disso, Java começou lenta e ruim e foi melhorando com o uso, sugestões da comunidade, entre outras coisas, nada impede que um mesmo esforço ocorra em Ruby e Python e daqui a alguns anos elas estejam tão “corporativas” quanto Java é hoje.

Bem após um tempo parado devido a diversas coisas que um dia irei explicar (e quem sabe falar sobre o resultado), consegui voltar a estudar, coisa que adoro.  Resolvi aprender uma nova linguagem, dentro dos paradigmas da moda: produtividade, DRY (don’t repeat yourself – não se repita, suggar-sintaxe -sintaxe doce, etc). Das que eu encontrei nesse contexto, resolvi escolher a linguagem Scala.  Já faz um certo tempo que ouço falar dela por alguns conhecidos… em alguns sites como o InfoQ existem artigos interessantes e no site do Artima inclusive pode encontrar uns pdf sobre o assunto (inclusive comprar o livro dos criadores da linguagem).

Acredito que todos que estão aqui lendo já tenham ouvido falar da lei de Moore.  Gordon E. Moore, em 1965, então presidente da Intel, predisse que os processadores, de um modo geral e simplista, iriam dobrar sua capacidade de processamento a cada  2 anos. Isso até então tem sido uma verdade e a Intel uma das maiores responsáveis pela realização da lei. A questão é que estamos chegando a um limite das pastilhas (os chips) : está ficando muito caro aumentar a capacidade deles… Com isso, os fabricantes de microprocessadores decidiram mudar um pouco a estratégia : ao invés de aumentar os transitores de um chip, eu vou é aumentar  número de chips, ou seja,vou trabalhar com microprocessadores de múltiplos núcleos.  Isso já é uma realidade em nossos computadores pessoais (vejam os dual cores, etc).  Com esses sanduíches de chips, os processos passam a ser processados, verdadeiramente, em paralelo ( antes tínhamos um compartilhamento por tempo da cpu : os processos eram enfileirados e cada um na sua vez usava um pouco do processador).

Embora essa realidade de equipamento já esteja disponível para qualquer um hoje, as linguagens, até onde eu sei, principalmente as mais usadas, não tem aproveitado em quase nada essa novidade das placas: fazer uma aplicação multithreading é um grande desafio! Com isso, muitas oportunidades tem se perdido por “limitações” (entenda aqui dificuldades ou um custo muito alto de tempo e recurso para fazer algo) não mais do hardware e sim do software.  Porém, algumas linguagens antigas e outras novas, muitas dessas baseadas nessas velhinhas e seus preceitos,  estão enchendo as mesas dos programadores antenados com seus manuais, livros e tutoriais.  Em sua maioria de paradigma funcional,  através de seus recurso tornam a tarefa de criar uma aplicação multhreading fácil e de baixo custo  e com isso vem ganhando um nicho esquecido e promissor que vem pela frente.

Uma das representantes dessa nova leva, é a linguagem Scala. Scala foi criada dentro da universidade por volta de 2003 e, por incrível que isso soe aos seus ouvidas, baseada na plataforma Java… isso mesmo: JAVA !  Embora ela não seja totalmente funcional – alguns puristas dizem que somente linguagens puramente funcionais serão capazes de trabalhar em paralelo  - ela não deixa nada a desejar e além disso, tenta dá uma forcinha para o JAva acrescentando alguns recursos desejados das linguagens altamente produtivas do momento (ex: Python, Ruby, etc)

Ainda temos poucos livros publicados sobre e pouco material disponível na grande rede. Mas não me assustaria se no ano que vem tivéssemos uma grande explosão em seu pois, no meu entender, ela promete.

Em desenvolvimento de sistemas uma das modas, num aspecto mais técnico, é o uso maciço de Padrões de Projeto (Design Patterns).  Chega a ser excessivo, em minha opinião e por isso, seu uso, ao invés de ajudar no projeto, atrapalha e cria verdadeiros monstros (impossíveis de entender, dar manutenção, modificar, compreensão do que está sendo feito difícil, etc). Projetos sem padrões é algo um tanto desordenado, mas projetos com uso exagerado ou de forma “incorreta” torna um sistema um elefante branco.

Por volta de 1995, o GoF (Gang of Four – Erica Gamma, Richard Helm, Ralph johnson, John Vlissides), publicou um livro intitulado : “Design Patterns – Elements of Reusable  Object-Oriented Software”.  Devido a ele, a questão dos padrões de projeto ganhou popularidade e partir de então passou a ser quase que uma obrigação a quem se aventurasse a desenvolver conhecer alguma (as vezes todas) das soluções proposta no trabalho do GoF.  Fiz várias entrevistas nas quais me perguntaram se conhecia Patterns; pediram para explicar e desenhar  algum em particular; e por ai foram.

Padrões não são ruins. Como vários sites e artigos dizem: esses padrões foram soluções de sucesso e testadas ( ou seja, comprovadamente ela funciona e tem um bom desempenho dentro do cenário que ela se propõe) que alguém fez e resolveu catalogar para que no futuro, alguém ao se deparar com um problema de mesma natureza saiba pelo menos um ponto de partida.  De forma bastante simplista, esse catálogo é uma fonte de consulta e onde podemos nos basear, entretanto, não devemos encará-lo como sendo uma verdade absoluta e que não usar o padrão proposto, sem quaisquer alterações,  é um heresia.  Todo o radicalismo independente do lado que penda é ruim. O radicalismo de alguns em dizer que patterns são besteiras e os dos que dizem somente eles devem ser usados não , na minha forma de ver as coisas, o melhor caminho para seguir se desejarmos fazer códigos de qualidade.

Eric Freeman e Elisabeth Freeman em seu livro “Head First Design Patterns ” (Em português o título do livro é : Use a Cabeça Padrões de Projeto), são um ar fresco  e trazem uma nova luz sobre o assunto. Num edição impecável e bem escrita, eles resgatam a questão do uso de padrões do radicalismo e tentam e forma simples mostrar porque devemos pelo menos conhecê-los.  O livro vai direto ao ponto e muitas de suas ideias estão de acordo como vejo o tema.

Um primeiro ponto é que para mim não existe verdade absoluta : um padrão não é e nunca será a única solução para um determinado problema. A diferença está, como já disse antes, que o catalogado é de domínio público (facilita a quem terá que entender o sistema depois), testado e já obteve sucesso em sua aplicação.  De novo, insisto, não é a única opção e pode até, dependendo do caso, não ser a melhor.  Existem diversos fatores a considerar na escolha de um padrão para usar: escopo, custo, tempo, recursos, etc. Como exemplo gosto de citar um caso onde uma pessoa deveria fazer uma aplicação web. Ela teria apenas 4 telas : uma de login, uma para fazer importar uma planilha excel, uma para visualização de dados, etc… O desenvolvedor  acabou, por pura preciosismo usando patterns em quantidades generosas… resultado: tudo ficou um lixo e colocaram a culpa do cara que sugeriu que usassem uma tecnologia de ponta (Struts e Hibernate)

Segundo ponto:  aprender padrões é aprender a se comunicar. Ao aprender os padrões você está adquirindo uma linguagem, de certa forma. Assim, quando quiser explicar a um desenvolvedor do time que poderia fazer de um jeito, sendo ele um pattern, basta que diga : “Fulano vamos usar o pattern XuxaSbrbublesIce++”.Sei que isso pode parecer radical (justo o que critiquei antes) porém se observarmos de um outro angulo a coisa realmente faz sentido

Terceiro : Em alguma parte antes disse que padrões devem ser usados como ponto de partida. O problema está que a maioria das pessoas usa como objetivo. Acredito que muitos serão os casos em que terei que usar uma implementação da forma que o livro ensina, entretanto, haverão tantos outros que terei que adaptar, misturar, usar parte, etc.

Bom agora vai minha opinião:

Conhecer design pattern é bom mesmo que seja para falar mal enquanto toma cerveja com os amigos num #horaextra. Fora isso, ao conhecê-lo você começa a abrir sua cabeça para novas possibilidades e formas de resolver problemas.

Confesso que não aguento mais, todas a vezes que me reuno com alguns amigos, participar daquelas discussões onde todos falam que tal linguagem é mal, outra boa, tal linguagem é melhor e outra pior. Isso só piora quando resolvem falar do Java. Parece que o salvador da pátria, até pouco tempo atrás, virou o vilão da história.

Me lembro bem que a quase 10 anos atrás, em quase toda empresa que ia, e propunha de fazer algo em Java, era como se tivesse cometido uma heresia. Ninguém aceitava.  Todos eram enfáticos em afirmar que  a linguagem era lenta, pesada demais,  pouco perfomante, e por ai seguiam.  Todos olhavam para o Java e acreditavam que iria morrer logo, pois não tinha como compertir com o Delphi (que dispontava na época), muito menos com o C++. Java estava quase que restrito aos ambientes acadêmicos, ou então, para aquelas empresas que se colocavam como vanguardistas da época.  Eu sou um bom exemplo disso:  meus primeiros contatos como desenvolvedor java foram para projetos acadêmicos.

Eis que então a tal da internet começou a avançar as passos largos, e o que era até então,  uma coisa timida em seu uso, foi tomando corpo.  No começo, ainda me lembro, daqueles sites “toscos”, todos em HTML, não havia nada dinâmico.  O pessoal usava o padrão cgi e codificava em C para tratar os dados que eram preenchidos nos formulários. Javascript, até onde me lembre, não tinha nada.  webmails, eram raros, maioria das coisa eram por meio de programas clientes (quem não lembra daquelas rotinas onde conectavamos, baixavamos os emails e depois lia e respondia. Ao terminar de responder, conectava novamente e enviava e sincronizava novamente).

Portal da UOL em 1996

Bem até que o pessoal da Java, fez os applets. Elas foram, na minha opinião, as verdadeiras responsáveis pelo sucesso que a linguagem tem hoje.  Graças aos applets que Java teve alguma projeção no mercado e seu crescimento não parou mais.  Tal crescimento se deve não somente pelas applets mas  por que eles nunca se contentaram em ser “cantores de uma só canção“. A equipe da Sun investiu pesado em recurso que fizessem do Java cada vez mais a melhor opção para desenvolver sistemas distribuidos, cliente-servidor.

Bom, mas porque escrevi tudo isso? Para mostrar que: primeiro que Java já foi uma tão inovadora e revolucionária, como as linguagens atuais; Java percorreu um longo caminho para ser oque é hoje;  Assim com hoje para algumas tecnologias emergentes, Java enfrentou preconceitos e barreiras ao seu uso; todos diziam que ela não iria sobreviver ao mundo corporativo e que não escalava, assim como alguns linguagens hoje; etc. Por isso, não sou muito fã de  artigos, discursos, o que mais seja, dizendo que Java é o novo Cobol.  A tecnologia conquistou o seu espaço provando ser util para muitas coisas.

Onde está o problema então? As pessoas que abandonaram o Java ou que não o querem estão malucas?

Bem, claro que não. A reclamação, ou melhor, a observação que os desenvolvedores mais revoluionário e vanguardistas tem feito são válidas.  Porém acredito que, alguma delas, são mal direcionadas. A tecnologia, ou como ela se apresenta hoje, a plataforma Java ela em si não é culpado pelo uso que lhe é dado.  Sendo assim, foram os desenvolvedores que tentaram, e ainda tentam, torná-la a bala de prata.  Que vejo hoje, é que a melhor coisa é entendermos que não precisamos somente usar a mesma “ferramenta” para resolver todos os problemas. Podemos mesclar, e usar o melhor de cada linguagem.  Podemos nos aproveitar de todos poder do Java e Python ou  Ruby, etc.

Java não é ruim.  Java não é o novo Cobol.  A questão que penso é :  Os programadores Java, alguns, querem transformar-se em consultores como era o pessoal de Cobol.  O pessoal que usa a tecnologia que está fazendo que ela seja vista de forma negativa.  São as pessoas que  forçam as situações que vemos hoje no mercado.

Além disso, a minha percepção é completamente diferente da de que Java está se fechando e querendo ser a soluçõa unica.   As informações que leio é de trabalhos por parte da Sun de fazer com que sua JVM seja poliglota, ou seja,  seja capaz de trabalhar com diversas linguagens que não somente Java.  A prova e/ou reflexo disso é o JRuby, Groovy, Jython,  Scala , Clojures, etc.

Uma outra coisa é que essas mesmas pessoas que criticam Java, podem num futuro próximo, com uma nova tecnologia ter a mesmo comportamento que criticam hoje: de achar que só a tecnologia que dominam é capaz de resolver todos os problemas.

Para finalizar, Java é bom, desde que saiba usá-lo.  E hoje mais vale ser um programador que conhece diversas tecnologias pois assim poderá escolher a melhor para resolver seu problema.