Desenvolvedores de software estão sempre criando elementos que agilizem as tarefas que de desenvolvimento e dos clientes pelo qual trabalham, na maioria das vezes, tentando fazer com que suas empresas obtenham maior velocidade em suas rotinas administrativas aumentando sempre o ponto motivacional, o lucro. Muitas vezes, os clientes não conhecem a dimensão e nem a complexidade que compõe o produto que solicitou e atribui prazos horrendos para um produto simplesmente pelo fato de não conhecer as nuancias que essa atividade depende. Aí está a motivação de tornar, pelo menos, a maioria das atividade que compõe o desenvolvimento de software automáticas, simples, intuitivas e ao mesmo tempo divertidas.

A motivação para isso resulta na criação de builds automatizados, integração contínua, track lists, bug track e etc. Em muitas situações, esses elementos não são suficientes, já que, mesmo com um grande aparato para apoio na atividades, não não estão livres de erros. Erros sempre vão acontecer, suas dimensões dependerão do tamanho e complexidade do produto a ser entregue e da experiência que a equipe tem com projetos. Nessas situações pegunta-se, o que podemos fazer para aumentar a velocidade de desenvolvimento de nossas aplicações. Evangelistas responderiam freneticamente que as linguagens dinâmicas preencheriam essa lacuna e resolveriam esse problema.

• Linguagens Dinâmicas

As linguagens dinâmicas não são bem uma novidade para os desenvolvedores mais experientes. Há muito tempo tornaram-se peça chave para os desenvolvedores de software que optam por automatizar suas tarefas, adicionar funcionanlidades a conteúdos estáticos e até mesmo estar no núcleos dos software mais complexos. Entre as mais conhecidas estão JavaScript, PHP, Python e Ruby com as principais opções nesse segmento. Quando se fala em Web o que vem na ponta da língua são essas soluções. Mas, será que essas linguagens podem preencher todos os tipos de necessidades. Acredito que não. Sou completamente a favor do programador poliglota e conhecedor dos mais numerosos itens do seu canivete suíço e em conjunto com metodologias ágeis o desenvolvedor pode aflorar muitas de suas habilidades.

Ruby foi um dos principais expoentes desse movimento que cresce cada vez mais. Uma linguagem dinâmica, funcional, elegante e com um grau de orientação a objetos altíssimo vem tomando o interesse, não só dos novos desenvolvedores, mas também dos desenvolvedores experientes vindos de outras linguagens. Screencasts que ensinam a desenvolver CRUDs com uma velocidade considerável estão aos montes nos blogs e YouTube.

Com o excelente trabalho dos evangelistas na divulgação do produto, sendo ajudados pela velocidade da informação em conjunto com a difusão da substituição das linguagens tradicionais no segmento enterprise, as empresas estão notando o potencial do conjunto. O potencial é visível, mas o investimento feito nas linguagens que conhecemos hoje como também na plataforma, certamente são a principal barreira para esse fator. Barreira justificável quando se trata de desempenho, maturidade e, principalmente do apoio que teriam ao negócio.

Sabemos que recentemente a Oracle, uma das principais colaboradoras da plataforma Java, comprou a SUN Microsistem co

m o objetivo de agregar mais valor ao seu portfólio de aplicações enterprise. Muitos das peças chaves da SUN saíram em decorrência, principalmente, da filosofia acadêmica natural da universidade de Stanford que, até o momento, era uma das principais colaboradoras da empresa. Tendo em vista esse histórico, a aquisição da Sun pela Oracle teve um impacto negativo não só aos seus funcionários como também em toda comunidade ao redor dos produtos da empresa. Nesse momento, a facilidade que a linguagem Java oferecia e a questão de ser multiplataforma estava em descrédito, principalmente pelo fato das novas features adicionadas no Java 5 (Annotations, Varargs, Boxing e Generics) que os desenvolvedores torciam o nariz temendo o aumento da complexidade da linguagem.

A alternativa a outras linguagens fez com que muitos desenvolvedores voltassem os olhos para outras alternativas e, entre essas, as linguagens que hoje estão se tornando as mais populares, como:Ruby e Python. Python tem um histórico de sucesso para os desenvolvedores que utilizam o Linux. Muita coisa do Goolge foi feito com Python, elem do mais, a gigante fez com que a linguagem fosse a primeira a ter suporte no Google App Engine.

Ruby ainda não foi adotada pela Google, mas é um nome quente quando se trata de comunidade ao redor dela. Criada no Japão por Matz com o objetiva de ser melhor que Pearl, teve muita popularidade principalmente por ser mais flexível e com um nível elevado de orientação a objetos. Particularmente, gosto muito da linguagem Ruby. Acho interessante o fator escrever fazer mais com pouco código. Principalmente quando se trata do Rails.

• A linguagem/plataforma Java

Dei enfase, de forma não tanto comprativa com java, devido as circunstancias do que está acontecendo após a compra da SUN pela Oracle. Esse fato, deixou uma onda de boatos sobre a plataforma Java ao ponto de deixar qualquer cético em dúvida sobre as direções tomadas pela oracle. A saída do Gosling, Schwartz e as indefinições como o que vai acontecer com o OpenOffice e o Mysql provocou uma grande dúvida na estratégia da Oracle relacionado ao vinculo de mercado desses produtos. Notícias recentes apontam uma postura enérgica sobre o JCP que foi muito criticada pela comunidade, porém, bem aceita pelos desenvolvedores.

A questão, pode ser uma especulação, é de tornar o Java cada vez mais comercial, enterprise e profissional. Não me recordo se a Oracle obteve uma empresa com uma grande comunidade por trás de um produto como é o Java. Talvez seja uma estratégia de mercado de agrupamento de produtos em forma de pacotes comerciais. Ou o pior, o fazer o que Jobs fez quando voltou para Apple; enxugar a quantidade de produtos objetivando um único foco e com qualidade.

A questão é que: Uma linguagem, plataforma, seja o que for não morre de um dia para o outro. Existe muita coisa que foi feito sobre a plataforma que não pode ser descartada. O investimento, feito na época pela SUN, no aprimoramento e formação de profissionais certificados, não só na linguagem, mas também na plataforma SOLARIS, foi muito alto e resultou em um gerando número de pessoas que tem pelo menos uma certificação nos produtos da SUN. Acredito a poeira vai baixar e que a plataforma, pode ser que não a linguagem, serão um dos pontos fortes de investimento, não só da Oracle, mas também de outras empresas e da comunidade.

Muitos vão dizer: O pessoal da Thoughtworks publicou um artigo afirmando que não utilizarão a linguagem Java nos seus projetos daqui pra frente, pensarão em Java apenas como VM. Eles tem voz forte no mercado, ditam tendencias. Pode ser que isso se intensifique porque já está acontecendo. Java está perdendo popularidade no mundo open source, portém, no mundo corporativo ela é muito requisitada.

]]> http://www.nelsonalone.com.br/2010/11/02/como-anda-o-java/feed/ 0 http://www.nelsonalone.com.br/2010/10/29/oracle-compara-linha-por-linha-copias-feitas-pelo-google/ http://www.nelsonalone.com.br/2010/10/29/oracle-compara-linha-por-linha-copias-feitas-pelo-google/#comments Fri, 29 Oct 2010 14:31:40 +0000 nelsonsozinho http://www.nelsonalone.com.br/?p=489

(More)…]]> O Blog Beetween The Lines publicou uma nota informando em detalhes, linha por linha, sobre a cópia que a Google fez dos fontes de JVM para a plataforma Android. A informação é bem evidente.

Como é possível notar, nessa classe existe poucas diferenças como número de chaves, quantidade de parâmetros e nomes de variáveis.

Existem mais detalhes no blog do autor, inclusive os documentos redigidos pela empresa referente ao feito.

Estratégias utilizadas para obter essa flexibilidade variam dês de desenvolver templates, classes abstratas, soluções que utilizam padrões de projetos que visam a reutilização, desenvolver forks de frameworks open source para se adequarem ao modelo de desenvolvimento da empresa. Essas alternativas visam poupar tempo com situações de um cadastro simples, persistência auditada, autenticação, etc.

Estratégias como essas vieram a tona nos tempos do Struts e dos EJBs 2.*, já que era notável a necessidade de eliminar os detalhes de implementação do struts (forms, templates, actions customizadas, autenticação, acesso a recursos de serviços distribuídos, etc). Já os EJBs, mesmo em versões antigas, demonstram robustez, confiabilidade e segurança para as aplicações corporativas. Daí veio os patterns J2EE, XDoclets com a finalidade de integrá-los e diminuir, pelo menos um pouco, o grau de acoplamento entre os serviços.  Com isso, a estratégia de diminuir o tempo de desenvolvimento seria válido devido a complexidade dessas tecnologias e da grande quantidade de arquivos XML necessário para configurá-los.

Essas tecnologias sobreviveram até hoje e ainda recebem manutenção de empresas que as tem como base de seus serviços. É justificável, pois muitos recursos investidos para o aprimoramento dessas ferramentas geralmente são altos e algumas vezes são peças-chave em vários projetos. Na maioria das vezes, principalmente em projetos com particularidades específicas, as soluções desenvolvidas para o mesmo geralmente tornam-se parte do framework da empresa para, caso necessite, ser utilizada em projetos futuros, fazendo o framework “inchar”.

Vendo esses problemas agora vem uma pergunta no ar: Mas porque cargas d’água fizeram essa joça? Porque deixaram isso acontecer? Ninguém previu isso? Eu também queria a resposta para essas perguntas, porém, muitos fatores podem ter ajudado a formar essa bola de neve; falta de experiência da equipe, má vontade, individualismo, falta de visão. Quem já trabalhou ou trabalha em corporações que tem essa mentalidade sabe do que eu estou falando. É nesse ponto que a compreensão dos pilares que a empresa dispõe para o desenvolvimento de seus projetos.

Quando uma empresa estabelece um pilar sua base deve ser rígida. A rigidez significa aceitar a evolução constante do código e ao mesmo tempo das libs, frameworks e JVMs que serão utilizadas futuramente nos projetos da empresa. Caso isso não aconteça, a base do pilar não suportará a evolução do framework podendo até se quebrar. Com isso, os bugs nos projetos que utilizam uma infra-instrutora arcaica vêm a tona. Quem trabalha especificamente com Java deve ter experiência com essa abordagem.

Uma boa equipe, sendo bem gerenciada, desenvolveria um framework que fosse, no mínimo, flexível. De forma que suporta, no mínimo, atualizações de bibliotecas intermediárias assim como atualizações da JVM, já que está sempre em constante evolução e cada momento seu desempenho está sendo sempre incrementado. Acredito que medidas simples tornariam a infra-estrutural de uma empresa evoluindo corretamente e principalmente independente de framework.

Isso é possível de fazer? Sim! Existem provas? Sim e são bem claras. É possível encontrar isso constantemente em projetos open source. M uma simples lida nos changelogs é possível ver a constante atualização de bibliotecas do projeto, substituição de jars e suas adaptações conforme as mudanças. Isso é um pouco trabalhoso porem recompensável, pois a base do pilar fica cada vez mais forte.

A linguagem Java, juntamente com a JVM, está em constante evolução. Desenvolver projetos (ou frameworks) fadados a utilizar uma versão específica da JVM é desperdício de tempo. Projetos como esses dificilmente suportarão a evolução, a longo prazo, de seus elementos fundamentais (JVM e frameworks). As mudanças ficarão restritas apenas a uma versão específica de sua estrutura, portanto caso cresça muito o pilar irá se partir.

[]s

]]> http://www.nelsonalone.com.br/2009/10/07/pilar/feed/ 0