Esse erro acontece que nas libs do JBoss já existe a mesma biblioteca. Quando é feito o deploy, ou executado standalone, esse erro acontece. Não adianta remover a lib do classpath da aplicação. Pode ater dar certo mas, se sua aplicação depende dela, talvez os testes automatizados não sejam executados corretamente.

Para solucionar esse problema em uma aplicação web simples, é necessário informar ao JBoss que essa lib é necessária para o projeto. Para isso, é só incluir a linha abaixo no arquivo MANIFEST.MF: Dependencies: org.dom4j. No momento do deploy o JBoss ler esse arquivo para tentar encontrar diretivas utilizadas para gerenciar o ClassLoader da aplicação e gerenciar a dependência de módulos.

Espero ter ajudado.

Nesse caso, a melhor ferramenta é a nossa cachola. Encontrei nesse blog um número repleto de dicas para solucionar os problemas de Anti-Pattern que utilizamos no dia-dia. Desde dicas de performance até soluções para determinados problemas. Vale a pena dar uma olhada. Odi’s Blog.

Recentemente, foi disponibilizada a relase 2 do versão 7 do AS, porem, a questão a ser tratada é a reformulação da estrutura do produto em comparação com as versões anteriores. O time de desenvolvimento praticamente refez todo o core do servidor, modificando desde a estrutura de carregamento das classes (classe loadin) até a forma de gerenciamento de dependência.

A interface de administração, apesar de não ser o forte deles, está mais limpa e direta. Através dele é possível ter total informação do que está instalado no servidor, datasources, módulos, dependências,  web services, etc. Lembro que no JBoss 5/6 havia uma interface que mostrava os webservices que estavam disponíveis na aplicação. Nessa versão, esse tipo de informação está disponível na própria interface de administração.

- VELOCIDADE AO SUBIR

Alguns pontos que se destacaram logo a primeira vista, entre esses, o mais perceptível é a velocidade que o JBoss é iniciado. Ao verificar os detalhes, me deparei na principal mudança ocorrida no núcleo do servidor. Ele está trabalhando inteiramente com OSGI, ou seja, no momento do boot o servidor sobe apenas os módulos necessários para tal. Esses elementos são lidos no arquivo de configuração domain.xml ou standalone.xml respectivamente.

Isso justifica o fator da velocidade de carregamento. Porém, quando for necessário incluir mais um módulo que sua aplicação necessite, um REST ou um Web Service tradicional por exemplo, será necessário editar o arquivo de configuração para que o módulo seja incluso.

- OS MÓDULOS

Essa informação está bem explícitas nos arquivos de configuração das instâncias, logo na primeira sessão está presente as extensões necessárias para o funcionamento da instância. Mais embaixo, quase no fim do documento, estão os módulos.

Os drivers de conexão JDBC são também tratados como módulos. Portanto, para utilizar um driver de conexão com um determinado banco de dados, será necessário incluí-lo como um módulo e importa-lo do projeto. Isso é feito criando uma hierarquia de diretórios, adicionar o jar do driver no diretório main, conforme o padrão, e criar um documento de descrição do módulo em questão, como o exemplo abaixo:

- INSTÂNCIA

A versão 7 suporta uma característica muito útil que para organizar as aplicações. O conceito de instância. Quem já trabalhou com o Oralce Application Server (hoje em dia Web Ligic) e com o WebSphere sentia bastante falta desse conceito no JBoss para efetuar configurações específicas de uma aplicação específica.

No primeiro momento, a opção por executar o jboss no modo standalone, mesmo em ambiente de produção, torna-se a melhor opção pelo fato da facilidade, ou melhor, ser um processo parecido como o que tinha nas versões anteriores.  Isso não quer dizer que não funcione, pelo contrário, funciona perfeitamente, tanto que temos aplicações rodando com essa configuração.

Acredito que, além da quantidade de recursos existentes nessa nova versão, uma outra característica que vem implícita com o servidor de aplicação, mesmo nas versões anteriores, é a simplicidade. A curva de aprendizado para configurar e disponibilizar um servidor de aplicação JBoss é bem baixa.

O JBoss apresentou um servidor de aplicação robusto e simples de utilizar. Acredito que com essa ultima versão deixou muito dos seus usuários otimistas, mesmo com as mudanças drásticas realizadas em sua estrutura.

]]> http://www.nelsonalone.com.br/2012/01/22/jboss-7-reformulacao-completa/feed/ 0 http://www.nelsonalone.com.br/2011/09/26/twitter-storm-no-github/ http://www.nelsonalone.com.br/2011/09/26/twitter-storm-no-github/#comments Mon, 26 Sep 2011 15:08:18 +0000 nelsonsozinho http://www.nelsonalone.com.br/?p=595

(More)…]]> A equipe de desenvolvimento do Twitter disponibilizou nessa segunda a ultima versão do storm. Pra quem não conhece, assim como eu a duas horas atrás, é uma API do Twitter, desenvolvida pela BackType, utilizada para solucionar problemas de processamento em tempo real com tolerância a falhas.

Referências abaixo:

Artigo na Infoq: Link

Repositório no GitHub: Link

Wiki: Link

No desenho tradicional do GOF ele aparece como um elemento agregado do Builder, possibilitando a criação na forma separada. Mas o padrão Builder cumpre um papel importante no “jeitão” das libs contidas na JVM. Um exemplo disso é o fato de Utilizar o tradicional System.out.println() ou o System.gc() que são processos de iniciação estáticos.

De acordo com o item 2 do Effective Java 2nd Edicition do Joshua Bloch, “Static factories and constructors share a limitation: they do not scale well to large numbers of optional parameters”. Segundo Bloch, a solução para isso está na construção de métodos státicos associados aos tipos genéricos para construir os objetos de forma elegante como abaixo:

Rectangle rec = new Rectangle.Builder().opacity(5.0).height(1.2).build();

Quando se faz muitos testes unitários, a maioria das vezes torna-se necessário construir objetos, ou mocks, que representam um estado fictício para a execução dos demais testes. E frequentemente utilizamos o método tradicional, com os construtores:

Usuario usuario = new Usuario("Nelson","Alone",new Date(),"alone","alone",new Departamento(),new Filial());

É uma forma tediosa de iniciar objetos quando temos vários atributos que precisamos preencher para utilizá-lo no procedimento de teste. Portanto, o Builder pode agilizar esse processo da seguinte forma

Para exemplificar a utilização do Builder com métodos genéricos e de classes internas, inicialmente vamos preparar a construção de duas classes tradicionais, Rectangle e Chape. Utilizaremos classes internas para a construção dos objetos internamente. Isso faz com qua a instancia da classes possa ser feita através da classes interna e do método builder para finalização do processo:

public class Shape {

	private final double opacity;

	protected static abstract class Init<T extends Init<T>> {
		private double opacity;
		protected abstract T self();

		public T opacity(double opacity) {
			this.opacity = opacity;
			return self();
		}
	}

	public static class Builder extends Init<Builder> {
		protected Builder self() {
			return this;
		}
	}

	protected Shape(Init<?> init) {
		this.opacity = init.opacity;
	}

}

public class Rectangle extends Shape {
	private final double height;

	protected static abstract class Init<T extends Init<T>> extends Shape.Init<T> {

		private double height;

		public T height(double height) {
			this.height = height;
			return self();
		}

		public Rectangle build() {
			return new Rectangle(this);
		}

	}

	public static class Builder extends Init<Builder> {
		protected Builder self() {
			return this;
		}
	}

	protected Rectangle(Init<?> init) {
		super(init);
		this.height = init.height;
	}

}

Exemplo para construção:

Rectangle rec = new Rectangle.Builder().opacity(5.0).height(1.2).build();

Já ajudou bastante. A cada atributo incluso é retornado uma instância do construtor para a inclusão posterior, sendo finalizado pelo método build(). Porém, é necessário o acoplamento da classes interna para a preparação do Builder ara a sua utilização. Essa solução pode solucionar o problema, mas vamos fazer diferente.

Agora, temos um jeito mais elegante de construer objetos sem o auxílio direto da classe interna Builder. Utilizaremos o método estático builder para auxiliar no processo, como abaixo:

public class Shape {

	private final double opacity;

	public static abstract class Builder<T extends Builder<T>> {
		private double opacity;

		protected abstract T self();

		public T opacity(double opacity) {
			this.opacity = opacity;
			return self();
		}

		public Shape build() {
			return new Shape(this);
		}
	}

	public static class Builder2 extends Builder<Builder2> {
		public Builder2 self() {
			return this;
		}
	}

	public static Builder<?> builder() {
		return new Builder2();
	}

	protected Shape(Builder<?> builder) {
		this.opacity = builder.opacity;
	}

}

public class Rectangle extends Shape {
	private final double height;

	protected static abstract class Builder<T extends Builder<T>> extends Shape.Builder<T> {

		private double height;

		public T height(double height) {
			this.height = height;
			return self();
		}

		public Rectangle build() {
			return new Rectangle(this);
		}

	}

	public static class Builder2 extends Builder<Builder2> {
		protected Builder2 self() {
			return this;
		}
	}

	public static Builder<?> builder() {
		return new Builder2();
	}

	protected Rectangle(Builder<?> init) {
		super(init);
		this.height = init.height;
	}

}

Exemplo para construção:

Rectangle rec = Rectangle.builder().opacity(14.45).height(478.41).build();

Ficou mais aceitável e, ao mesmo tempo, menos acoplável. Internamente, temos mais código, mas facilita bastante a construção do objeto caso tenha um número grande de parâmetros.

Faça download dos fontes,  execute os teste e veja como fica em uma solução mais complexa.

[]s

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.

Participei de projetos onde precisava-mos fazer constantes deploys a cada instante, inclusive no servidor de integração contínua que rodava constantemente. Para isso, utiliza-mos a task contida nas libs do apache que permitia fazer deploys remotos no apache através da interface de administração do servidor. Com isso, criamos targets que utilizava essa task para efetuar. Não é complicado, ao contrário, é muito simples, apenas precisa configurar o ligin, password e o caminho da aplicação. Segue abaixo um exemplo.

<property value="CAMINHO_DO_TOMCAT" />

<fileset id="tomcat.lib" dir="${tomcat.home}/lib">
    <include name="**/*.jar" />
</fileset>

<path id="path.lib">
     <fileset refid="tomcat.lib" />
</path>

<taskdef name="deploy" classname="org.apache.catalina.ant.DeployTask" classpathref="path.lib"/>

<target name="deploy-tomcat" depends="war">
      <echo message="Deploying application"/>
<deploy url="http://localhost:8080/manager"
            username="LOGIN_ADMIN"
            password="SENHA_ADMIN"
            path="/APP"
            war="file:${dir.build}/APP.war"
            update="true"/>
</target>

Existem recursos que viabilizam o desempenho em aplicações Web de forma aceitável para o usuário final. Entre elas, na minha opinião, o mais adequado é o Ajax. Existem outras alternativas como o Flex, porém, dependendo da aplicação desenvolvido pode haver demora no carregamento e processamento das requisições, mesmo sendo carregada uma única vez. Com base nisso, a utilização do Flex sobre uma intranet é uma excelente opção. Como o contexto é a internet, soluções Ajax levam vantagem pelo fato do conteúdo ser apresentado em HTML/XHTML e pelo fato de não utilizar nenhum plugin para os navegadores. Porém, quando se trata de JavaScript, muitos desenvolvedores tentam evitar por ser mais uma linguagem necessária para o aprendizado para desenvolver uma aplicação. Ironicamente, um desenvolvedor web necessita saber no mínimo três linguagens para desenvolver uma aplicação utilizável.

Em alguns casos, a utilização do javascript em alguns projetos torna-se complicada devido a dificuldade, principalmente quando projetos são feitos utilizado AJAX. Isso encorajou a criação de inúmeros frameworks e componentes que tentam tornar o desenvolvimento de aplicações que utilizam AJAX mais simples e fáceis de manter.

JQuery é um framework que tenta facilitar ao máximo a utilização de JavaScript nas páginas, sendo que, é a ferramenta mais utilizada quando se trata de recursos para a linguagem. O que chama mais atenção são os efeitos e a facilidade para desenvolver com essa ferramenta.

A comunidade Java é privilegiada com inúmeros frameworks e APIs que facilitam o desenvolvimento resolvendo problemas de vários segmentos, principalmente WEB. Acredito que, devido a dificuldade de desenvolver aplicações WEB apenas com JSP, Servlets, Filters, TagLibs, etc., os desenvolvedores tentaram diminuir essa dificuldade com frameworks, tai então a explicação da grande quantidade de frameworks WEB para Java.

Em Java, atualmente, o frameworks WEB mais utilizado, depois do Struts (legado) , é o JSF. Talvez devido ao fato de ser um produto da Sun e estar coberto por uma especificação. Não cheguei a ver detalhes da especificação 2.0, mas nas versões anteriores o desenvolvimento ainda é maçante e chato, onde existem situações que necessitam cada vez da habilidade do desenvolvedor. Porém, muito foi feito para tentar corrigir os problemas e ao mesmo tempo agregar valor ao framework com as extensões repletas de componentes para ser utilizados nos projetos, uma dessas extensões é o RichFaces. Atualmente encontra-se na versão 3.3 e vem uma série de componentes que podem funcionar sobre uma camada AJAX. A facilidade é tanta que a forma de desenvolver é a quase a mesma que desenvolver com JSF puro. Com isso, está a disposição do desenvolvedor recursos de Drag’nDrop, calendários bem elaborados, efeitos, e uma série de componentes bem desenvolvidos que funcionam sobre AJAX.  A configuração do RichFaces também é simples, basta adicionar alguns filtros, escolher o template, ou desenvolver um, configurar um ou dois XMLs e adicionar algumas taglibs no projeto e pronto, seu projeto já está configurado.

O objetivo desse artigo não é de escrever um tutorial e nem comparar as ferramentas, é de alertar sobre a má utilização dos recursos AJAX na aplicação com o RichFaces. O framework utiliza JQuery para fazer os efeitos e manipular do DOM HTML/XHTML, com isso, o conteúdo do framework vai junto com o projeto. A infra-instrutora de um projeto AJAX é repleta de JavaScript e quando projetos se tornam  complexos, conseqüentemente, a complexidades de manter os script se eleva. Com isso, existe uma estrutura de arquivos javascript pronta para suportar a arvore JSF gerada a cada requisição tornando a estrutura pesada ao ponto de ser desvantagem desenvolver a aplicação baseada em requests sobre toda a página.

Destrinchando o conteúdo carregado pelo browser, existe um tipo de arquivo que representa a chamada de sua URL que é respondida a cada requisição, é configurada no web.xml na definição da chamada para a execução do servlet. Nesses arquivos contem o emaranhado do Javascript que o servidor envia a cada requisição. No meu caso, esses arquivos ficaram em torno de 933Kb, é um tamanho considerável quando se trata de requisições. Isso pode deixar sua aplicação uma carroça quando sua aplicação for pro ar.

Nessa situação, a solução para esse problema é aplicar ao máximo os recursos AJAX na aplicação, fazendo com que apenas um trecho da página possa ser renderizada e não todo a cada requisição. Isso diminui bastante o tráfego na rede tornando a aplicação um pouco mais leve. Nas primeiras solicitações a aplicação fica muito lenta, mas quando o conteúdo está no cache o desempenho fica razoável.

Para comprovar, fiz um teste desenvolvendo uma página simples com um CSS pequeno e sem nenhum arquivo JavaScript amais. Fiz as configurações dos pacotes JSF e do RichFaces descritas em seus devidos manuais respectivamente. Fiz com que a primeira página utilizasse um apenas um <a4j:region > contendo alguns componentes, como; <a4j:form> e  um <a4j:commandLink>. Isso é suficiente para habilitar o suporte AJAX do framework, ou seja, carregando todos os JavaScript responsáveis por essa funcionalidade.

Na documentação do framework não existem tópicos que auxiliem a diminuir o tamanho do conteúdo, isso encoraja a utilização massiva dos recursos em todas as páginas e evitando request desnecessários. Não quero dizer que o framework seja ruim, pelo contrário, é uma ótima ferramenta, porém, deve ser utilizada com cuidado. A utilização de AJAX puro é uma excelente opção.

[]s.

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