Não tenho a menor dúvida de que liderança é algo que possa ser adquirido através de um processo de aprendizagem, o que me faz constatar, que por mais que existam pessoas que tenham alguns aspectos de liderança mais bem desenvolvidos de forma natural, que é possível ainda assim desenvolver ainda mais esses aspectos. Ou seja, sempre podemos ser melhores líderes. Acredito também, que as melhores maneiras de evoluirmos é observando outros líderes e também dando atenção as pessoas com que trabalhamos.

Baseado no assunto liderança, preparei uma lista com quase 40 tópicos que tem sido de suma importância no meu dia-a-dia como líder de projeto. Esses tópicos foram pensados baseados em erros e acertos que tenho cometido como líder de projetos de software, por isso existem tópicos focados no aspecto de software, entretanto a maioria é voltada para líderes de maneira geral.

1 – Defina, focado no seu problema, os artefatos técnicos a serem usados no seu projeto e certifique-se de que a probabilidade dos mesmos mudarem é pouco provável

2 – Tenha um plano de comunicação bem definido com a sua equipe

3 – Desenvolva ou escolha uma metodologia de desenvolvimento e tenha certeza de que as pessoas da sua equipe a entenderam e acharam a mesma útil

4 – Se preocupe com o seu modelo de dados

5 – Se possível, tenha sempre o layout em mãos antes do desenvolvimento

6 – Não exija respeito, conquiste

7 – Tenha bom humor

8 – Passe segurança a sua equipe, tenha certeza que ela confie em você, um líder precisa, acima de tudo, inspirar confiança

9 – Tente não demonstrar desespero, euforia e nem pessimismo

10 – Saiba cobrar, mas sem pressionar

11 – Contextualize as pessoas sobre o que elas estão fazendo

12 – Posicione as pessoas sobre o andamento e o status atual do projeto em que elas estão participando

13 – Identifique, antes de tudo, os pontos fortes e fracos de cada um e use isso a seu favor

14 – Promova treinamentos e palestras para pontos em que mais de uma pessoa possua dúvida

15 – Cobre uma documentação do cliente que agregue ao seu time

16 – Converse com o seu cliente

17 – Caso necessário, crie uma documentação própria e simplificada, baseada na documentação original do seu cliente

18 – Defina e detalhe bem as tarefas de cada membro da sua equipe

19 – Faça com que as pessoas da sua equipe entendam da aplicação, entendam do negócio, pois só assim elas podem sugerir melhorias

20 – Tente não ficar dependente de uma mesma pessoas para um ponto específico

21 – Dê feedback constante

22 – Ouça a sua equipe

23 – Reuna sua equipe semanamlmente para discutir como foi a última semana e planejar como será a próxima

24 – Tenha preferência em trabalhar com equipes enxutas a equipe com muitas pessoas

25 – Dê atenção as pessoas novas e explique sobre o que ela fará, aprensente ela a equipe, mostre a empresa

26 – Estime prazos reais para o seu cliente, e não prazos que ele gostaria de ouvir

27 – Promova ações para estimular a união da sua equipe, como almoços mensais, por exemplo

28 – Enumere todas as principais funcionalidades do seu sistema, se possível criando uma hierarquia entre elas, isso ajudara você, a equipe e o cliente a terem uma visão macro do projeto

29 – Crie políticas para o bom de uso de controles de versão, ferramentas de gerenciamento, integração contínua, etc

30 – Faça uma auto-avaliação periodicamente

31 – Evite que as pessoas tenham que trabalhar finais de semana, feriados e fazerem hora extra constantemente

32 – Tenha cuidado em elogiar alguém publicamente. Jamais critique alguém publicamente

33 – Anote tudo o que você deseja fazer, mesmo que não seja prioridade

34 – Mostre e deixe claro a importância de cada membro da equipe

35 – Não fale mal da sua equipe para outras pessoas

36 – Trabalhe e se esforçe mais do que todo mundo, você é o exemplo

37 – Sua equipe precisa te admirar e se espelhar em você

38 – Saiba dizer não, demarque seu limite

39 – Em caso de fracasso, a culpa é do líder, em caso de sucesso, o mérito é de todos

Alguns desses pontos são de cunho mais técnico, outros de cunho gerencial e outras focam no relacionamento inter-pessoal entre você e os membros da sua equipe e entre os membros da sua equipe com eles mesmo. Não se esqueça, que antes de qualquer coisa, nós trabalhamos com humanos e humanos são passíveis a cometerem erros, humanos tem dias bons e ruins, humanos tem expectativas, humanos necessitam de comunicação.

Um recurso que tem me ajudado a ter esses pontos de maneira mais clara é o mapa mental, pois dessa maneira consigo ter todos esses pontos listados e interligados, proporcionando uma organização lógica aos mesmos.

Para finalizar, sempre se questione com a seguinte pergunta: eu seria liderado por mim mesmo?

Antes de mais nada, vamos citar alguns conceitos importantes de BDD.

Estórias e Cenários

BDD é baseado em estórias e cenários, e para criarmos ambos, vamos seguir alguns padrões pré-definidos por autores de BDD. Uma vez que BDD é focado em comportamento e sequência, as estórias e cenários devem ter um formato rígido para que as ferramentas consigam entendê-los e interpretá-los.

As estórias, possuem o seguinte formato:

As I [X]
I want [Y]
so that [Z]

E os cenários possuem o seguinte formato:

Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.

Ou seja, isso quer dizer que devemos pensar em nossos requisitos de maneira que possam ser escritos baseados nessa convenção.

O JBehave é originalmente escrito para entender estórias em inglês, entretanto como BDD é focado em pessoas (stakeholders) e na descrição de situações reais, faz muito mais sentido semanticamente que as estórias e cenários sejam escritos em português e para resolver isso, usei uma contribuição do Emerson Macedo para que os cenários possam ser escritos e entendidos em português pelo JBehave.

Começando com o JBehave

O primeiro passo para utilização do JBehave, é fazer download do JAR do projeto e incluí-lo no classpath do seu projeto.

O próximo passo é escrever a estória juntamente com o cenário e para tal resolvi criar um exemplo simples para que o entendimento do conceito possa ser casado através do código a ser desenvolvido.

O exemplo escolhido é baseado no requisito: Compra de produtos em promoção com aviso por email. E é isso que nosso cenário BDD deve descrever.

Por questão de organização, resolvi quebrar a estória em 3 cenários diferentes, onde a primeira parte representa a verificação de produtos em promoção, a segunda representa a compra desses produtos e o terceiro é a finalização da compra e o envio de email. Então, a estória e os cenários ficaram assim:

Compra de produtos em promoção com aviso por email
 
Narrativa:
Como um usuário
Eu quero comprar produtos em promoção
E então receber um email de confirmação
 
Cenário: Verificar produtos em promoção
Dado Que uma loja possui 10 produtos
E Que 5 estão em promoção
Quando Eu verifico quais estão em promoção
Então Preencho minha sacola apenas com produtos em promoção
 
Cenário: Comprar produtos em promoção
Dado Que minha sacola de compras está preenchida com 5 produtos em promoção
Quando Eu verifico o somatório de produtos
Então Devo ter somente um total de 500 reais em produtos
 
Cenário: Enviar email
Dado Que minha sacola está preenchida de produtos
Quando Enviar um email de confirmação
Então Devo receber o status do envio "true"

A primeira linha do arquivo texto representa o título da nossa estória, o requisito de fato. A narrativa é um resumo do que essa estória deve cumprir e a seguir vem os três cenários, que no caso são as três etapas da estória.

É importante notar, que as palavras chaves em inglês (Given, When, Then, And) foram substituídas por palavras em português (Dado, Quando, Então, E).

Esse arquivo texto deve ser salvo com a extensão *.cenario e o seu nome está diretamente ligado a classe que irei criar no passo a seguir, que no caso é a classe que representa a estória e a associação com os cenários.

Criando a classe que irá comportar os cenários

Nesse passo irei criar a classe que irá apontar os cenários que compõe a estória e essa classe deve extender a classe Scenario do JBehave. Dessa forma, a classe ficaria assim:

PrecoPromocaoTeste.java

package scenario1;
 
import scenario1.steps.CompraSteps;
import scenario1.steps.EmailSteps;
import scenario1.steps.PromocaoSteps;
import scenario1.util.PtBRScenario;
 
public class PrecoPromocaoTeste extends PtBRScenario {
	public PrecoPromocaoTeste() {
           addSteps(new PromocaoSteps());
           addSteps(new CompraSteps());
           addSteps(new EmailSteps());
	}
}

No exemplo acima, estou extendo a classe PtBRScenario só para que a estória e o cenário sejam escritos em português, mas essa classa herda a classe Scenario como descrito anteriormente.

No construtor da classe, inclui os passos que a estória deve seguir para ser satisfeita e como quebrei a estória em três pedaços, precisei incluir três passos sequenciados.

Criando os passos da estória

Como a estória foi quebrada em três partes, se faz por necessário a criação de 3 classes que irão representar os passos da estória e todas essas classes devem herdar a classe Steps do JBehave.

Pela ordem definida na nossa classe de cenário, vamos aos passos:

PromocaoSteps.java

package scenario1.steps;
 
import java.util.List;
 
import junit.framework.Assert;
 
import org.jbehave.scenario.annotations.Given;
import org.jbehave.scenario.annotations.Then;
import org.jbehave.scenario.annotations.When;
 
import scenario1.entity.Loja;
import scenario1.entity.Produto;
import scenario1.util.PtBRSteps;
import scenario1.vo.Sacola;
 
public class PromocaoSteps extends PtBRSteps {	
	Loja loja 		= new Loja();
	Sacola sacola 	= new Sacola();
	List<Produto> listaProdutoPromocao;
	int quantidadeProdutoPromocao;
 
	@Given("Que uma loja possui $quant produtos")
	public void populaLoja(Integer quantidade) {
		loja.inicializaProdutos(quantidade);
	}	
 
	@Given("Que $quant estão em promoção")
	public void informaProdutosPromocao(Integer quantidade) {
		loja.colocaProdutosPromocao(quantidade);
		quantidadeProdutoPromocao = quantidade;
	}	
 
	@When("Eu verifico quais estão em promoção")
	public void verificaProdutosPromocao() {		
		listaProdutoPromocao = loja.retornaProdutosPromocao();
	}
 
	@Then("Preencho minha sacola apenas com produtos em promoção")
	public void populaSacola() {
		sacola.populaSacola(listaProdutoPromocao);
 
		Assert.assertEquals(listaProdutoPromocao.size(), quantidadeProdutoPromocao);
	}
}

CompraSteps.java

package scenario1.steps;
 
import java.util.ArrayList;
import java.util.List;
 
import junit.framework.Assert;
 
import org.jbehave.scenario.annotations.Given;
import org.jbehave.scenario.annotations.Then;
import org.jbehave.scenario.annotations.When;
 
import scenario1.entity.Produto;
import scenario1.util.PtBRSteps;
import scenario1.vo.Sacola;
 
public class CompraSteps extends PtBRSteps {
	Sacola sacola 				= new Sacola();
	double somatorioProdutos 	= 0d;
 
	@Given("Que minha sacola de compras está preenchida com $quant produtos em promoção")
	public void verificaSacola(Integer quantidade) {
		List<Produto> listaProduto = new ArrayList<Produto>();
 
		for (int i=1; i<=quantidade; i++) {
			Produto produto 	= new Produto();
			produto.preco 		= Math.round(Math.random()*100);
			produto.emPromocao 	= true;
 
			listaProduto.add(produto);
		}
 
		sacola.populaSacola(listaProduto);
	}
 
	@When("Eu verifico o somatório de produtos")
	public void verificaTotalProdutosSacola() {
		for ( Produto produto : sacola.retornaProdutos() ) {
			somatorioProdutos = produto.preco + somatorioProdutos;
		}
	}
 
	@Then("Devo ter somente um total de R$ $total reais em produtos")
	public void validaSacola(double totalProduto) {		
		if ( somatorioProdutos > totalProduto )
			Assert.fail("Total de produtos é acima de R$ 500");
	}
}

EmailSteps.java

package scenario1.steps;
 
import static org.jbehave.Ensure.ensureThat;
 
import org.jbehave.scenario.annotations.Given;
import org.jbehave.scenario.annotations.Then;
import org.jbehave.scenario.annotations.When;
 
import scenario1.util.PtBRSteps;
import scenario1.vo.Sacola;
 
import com.guilhermechapiewski.fluentmail.email.EmailMessage;
import com.guilhermechapiewski.fluentmail.transport.EmailTransportConfiguration;
 
public class EmailSteps extends PtBRSteps {
	Sacola sacola 		= new Sacola();
	Boolean statusEnvio = false;
 
	@Given("Que minha sacola está preenchida de produtos")
	public void verificaSacola() {
		System.out.println("Lista cheia..");
	}
 
	@When("Enviar um email de confirmação")
	public void enviaEmail() {
		EmailTransportConfiguration.configure("localhost", false, false, "", "");
 
		new EmailMessage()
	    	.from("eusou@marcuscavalcanti.net")
	    	.to("eusou@marcuscavalcanti.net")
	    	.withSubject("Testando BDD")
	    	.withBody("Testando terceiro cenário e o final da estória.")
	    	.send();
 
		statusEnvio = true;
	}
 
	@Then("Devo receber o status do envio \"$retorno\"")
	public void recebeStatusEnvio(String retorno) {	
		ensureThat(statusEnvio.toString().equals(retorno));
	}
}

Nos exemplos acima, que representam os passos de um cenário, é importante notar que os métodos seguem a ordem definida no arquivo texto, assim como todos são anotados com as palavras chaves correspondentes, no caso Given, When, And, Then. As anotações recebem como parâmetro as frases descritas no arquivo texto, excluindo apenas as palavras chaves no começo da frase, que estão devidamente representadas pelas anotações.

Os parâmetros são identificados com o formato $variavel, e uma vez que usamos esses parâmetros, devemos também colocá-los na assinatura dos métodos. Esses parâmetros são automaticamente capturados pelo JBehave através do uso de expressões regulares.

Executando o exemplo

Para executar o exemplo deve-se executar a classe que extende a classe Scenario do JBehave, nesse caso seria a classe PrecoPromocaoTeste.java, e para acompanhar os resultados, eu utilizo a integração do Eclipse com o JUnit, através de uma view própria da IDE.

No exemplo, usei ainda algumas classes auxiliares criadas especificamente para o exemplo, mas que não irei mostrar aqui os seus códigos para não tornar o tópico extenso demais. De qualquer forma, ao final desse tópico botarei um link para download do projeto no Eclipse que contém todos os códigos.

Observações finais

Um dos problemas que eu notei no JBehave é em relação a parametrização de alguns valores no arquivo texto para o código Java, em alguns casos isso pode se tornar um trabalho sacal e pouco produtivo, mas acredito que com a evolução do framework esse problema será resolvido.

Algumas pessoas utilizam alternativas variadas para resolver esse problema, como por exemplo criar o valor dos parâmetros diretamente como atributos nas classes que representam os passos. Eu particularmente não gosto dessa abordagem, pois acredito que isso faz com que os arquivos que descrevem os cenários percam seu valor e esses arquivos são essencial para utilização e sentido do BDD.

No exemplo citado, usei ainda algumas bibliotecas como FluentMailApi, Mail e Activation da JavaMail e Hamcrest. Essas bibliotecas servem basicamente para o envio de email e uso mais aperfeiçoado de expressões regulares por parte do JBehave.

Para finalizar, é importante citar que as classes do meu negócio (Sacola, Usuario, Loja, etc) foram construídas baseadas no meu requesito, no meu cenário, que foi a primeira etapa a ser elaborada na construção do exemplo.

Download

Para download do projeto completo no Eclipse, basta clicar aqui.

BDD ajuda você, BDD ajuda seu cliente

Um ponto que pude observar, é que usando BDD a possibilidade de um cliente participar de um projeto é imensa, mesmo que você não use alguma metodologia ágil (falarei sobre isso a seguir). E por que ele pode participar? É simples, pois é ele quem pode escrever os testes. Se ainda assim não for o seu cliente o responsável por escrever os testes, será ele quem irá validá-los, ou seja, você pode escrever os testes e pedir para que ele aprove ou não. Isso é muito importante, pois nesse caso os testes em BDD seriam o contrato entre você o seu cliente, entre o que você está entregando e o que ele está esperando.

BDD favorece o sucesso do uso de metodologias ágeis

Sem dúvida nenhuma um dos pontos fortes do uso de BDD é que suas características se encaixam muito bem em equipes que fazem o uso de metodologia ágil. E são vários pontos que favorecem.

Uma delas é a já citada participação do cliente, pois um dos requisitos para o sucesso do uso de metodologias ágeis é a participação e contribuição efetiva do cliente e no caso do uso de BDD ele pode participar diretamente, uma vez que é ele quem é o responsável (PO) por criar as estórias (ítens do backlog) e criar os testes de aceitação para as mesmas, onde tudo isso é usado no BDD.

Os artefatos que constituem BDD são muito, mais muito semelhantes aos artefatos presentes em ágil.

Em BDD se usa estórias e testes de aceitação, além de BDD favorecer a construção de aplicativos de forma evolutiva (sprints) e tudo isso casa perfeitamente com os requisitos das metodologias ágeis.

Favorece a escrita de testes antes da implementação

Uma boa prática na criação de testes, independente se você usa BDD ou TDD, é que os testes sejam criados antes de tudo. Ok, eu concordo, mas devo dizer que com TDD isso não é muito nítido, pois na maioria dos casos, principalmente no começo, as pessoas tendem a implementar os códigos e depois escreverem os testes para validá-los. Já com BDD, a primeira coisa que você precisa ter em mãos antes de implementar os testes são as estórias e os cenários, não tem como fugir disso, o que torna muito mais nítido que em primeiro lugar vem os testes e depois as implementações.

Torna mais nítido o que sua aplicação deve fazer

Com BDD é muito mais fácil isolar as funcionalidade da sua aplicação, já que o que é testado é exatamente isso, dessa forma fica fácil identificar os componentes que envolvem determinada funcionalidade, torna mais nítido qual é o papel daquela funcionalidade, além do que consegue dar um sentido melhor para a sua aplicação de maneira geral.

Com BDD, você consegue ainda uma visão de workflow da sua aplicação, ou seja, uma visão macro, o que favorece dar manutenção a mesma. Percebo também, que BDD favorece um bom design de código, evitando assim problemas de desenvolvimento como códigos com alto-acoplamento.

Torna os testes mais humanos

A essência do BDD são os cenários e não parte isoladas da aplicação e essa maneira de lidar com testes favorece o entendimento por parte de nós, humanos.

Testes de interface com o Selenium, tornam-se mais compreensíveis num contexto que envolva BDD, como em um teste de login, por exemplo.

Conclusão

Na minha opinião, está mais do que clara a vantagem no uso de BDD, entretanto ele não substitui o uso de TDD, pois a abordagem de ambas são diferentes e complementares.

No próximo tópico, irei mostrar um cenário de testes com o framework JBehave, um framework BDD para Java.

Mais sobre o assunto

The truth about DDD

The difference between TDD and BDD

As frases são tiradas de um contexto específico, mas podem tranquilamente ser usadas de maneira isolada para reflexão, aprendizado e até para fixar uma idéia.

Nessa “primeira edição”, vou me ater a frases que envolvam SOA e BPM.

Eis as frases:

“The first of those milestones has come to pass: process is not simply the way business operates itself, but manages itself.”
Phil Gilbert

“It’s been said, “If you can’t measure it, you can’t manage it.” It’s also been said, “Opinions are like a*******, everybody’s got one.” The ability to manage by fact (measurement), rather than opinion, is what sets the rare professional manager from the masses of loudmouth, intimidating, egotists who’ve been given the title Manager. Leaders, on the other hand, earn that title. And one of the most effective ways of earning that title is to learn to mange objectively, not subjectively. Objective management starts with identifying objective performance measurements.”
Jim Reardan

“Service Decomposition splits service, not function.”
Thomas Erl

“IT realizes the burden is not on them anymore. The business has to be the responsible party.”
Peter Woodhull

“Often when we look at business processes and SOA we ignore the information aspect and focus on the technology aspect. What’s important is that you have some vision of sets of services that you need now and then over time to meet your business requirements.”
Mike Rosen

“Unless you use SOA in the context of what you’re trying to do with the business, you can end up with just the new spaghetti to replace the old spaghetti.”
Marc Smith

“…often sees a team of business experts thinking in purely business terms and a team of developers thinking only in terms of what code they’ll need to write. But SOA is not the sort of architecture that one builds by throwing code at it. It is, at its core, very conceptual.”
Sandy Kemsley

“Using SOA as we do – as an architecture and business modeling approach – helps bridge the gap between traditional business process modeling and technology delivery.”
Steve Jones

“SOA is simply the technology architecture that defines how any technology is designed and deployed. BPM, on the other hand, represents how you link business strategy to business implementation… with [SOA-based] technology being a part of that implementation.”
Phil Gilbert

Outra utilidades do Maven é o gerenciamento de dependências da aplicação, pois uma vez que sua aplicação use outras bibliotecas, não se faz por necessário incluir os devidos JARs no repositório da aplicação, basta apenas informar isso no Maven e deixar que ele se encarregue de encontrar essas bibliotecas e baixar para sua máquina.

No caso do ALBPM (Aqualogic BPM), temos um cenário um pouco diferente, pois no final das contas tudo que é gerado são arquivos XML com as informações dos seus processos, então nesse caso usamos o Maven apenas para geração de pacotes. No ALBPM, um pacote nada mais é que o diretório da aplicação compactado (zipado) com uma extensão específica, no caso *.exp, deve-se considerar ainda a exclusão de alguns diretórios na geração do pacote, pois esses diretórios são gerados em tempo de compilação pela engine do ALBPM. Baseado nisso, criei uma configuração do Maven que será responsável pela geração de pacote de um projeto no ALBPM.

Usei ainda uma integração do Maven com o Ant, através de um plugin específico do Maven, onde o Ant será responsável por realizar algumas rotinas bem específicas, como renomear o arquivo gerado e apagar diretórios que não serão usados.

Vale ressaltar que eu testei essa rotina apenas para o ALBPM na versão 6.*, no caso da versão 5.*, acho que não deve mudar muita coisa, mas a extensão do pacote gerada é diferente, portanto será necessário algumas adaptações para que essa rotina funcione também nessa versão. No caso das versões já com a Oracle como responsável pelo produto (OracleBPM), essa rotina também deverá funcionar sem problemas.

Criando o POM do Maven

Como nosso projeto do ALBPM possui apenas um único módulo, será necessário a criação apenas de um único arquivo *.pom, que no caso será o responsável por incluir os plugins que serão usados, além de chamar um arquivo com algumas tasks do Ant. Dessa forma, o arquivo POM fica assim:

<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
 
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.b2w</groupId>
	<artifactId>ControleOrcamento</artifactId>
	<packaging>pom</packaging>
	<version>1.0</version>
	<name>ControleOrcamento Project</name>	
 
	<properties>
		<packageName>ControleOrcamento</packageName>
		<packageDirectory>package</packageDirectory>
		<packageExtension>exp</packageExtension>		
	</properties>
 
	<build>
	   	<plugins>
	   		<plugin>
				<artifactId>maven-assembly-plugin</artifactId>
				<executions>
					<execution>
						<id>assemble-zip</id>
						<phase>install</phase>
						<goals>
							<goal>attached</goal>
						</goals>
					</execution>
				</executions>
				<configuration>
                                       <appendAssemblyId>false</appendAssemblyId>   
					<finalName>${packageName}</finalName>                 
					<descriptors>
						<descriptor>assembly-descriptor.xml</descriptor>
					</descriptors>
				</configuration>
			</plugin>
      		<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-antrun-plugin</artifactId>
				<executions>									
					<execution>
						<id>rename-package</id>
						<phase>install</phase>
						<configuration>
							<tasks>
								<property name="package_name" value="${packageName}"></property>
								<property name="package_extension" value="${packageExtension}"></property>
								<property name="package_directory" value="${packageDirectory}"></property>
								<ant antfile="maven-setup.xml" ></ant>
							</tasks>							
						</configuration>
						<goals>
							<goal>run</goal>
						</goals>
					</execution>					
				</executions>
			</plugin>
	    </plugins>
	</build>  	
 
	<repositories>
		<repository>
			<id>default</id>
			<name>Internal</name>
			<url>http://intranet/archiva/repository/internal</url>
		</repository>
		<repository>
			<id>ideais</id>
			<name>Ideais</name>
			<url>http://intranet/archiva/repository/ideais</url>
		</repository>
		<repository>
			<id>thirdparty</id>
			<name>Thirdparty Artifacts</name>
			<url>http://intranet/archiva/repository/thirdparty</url>
		</repository>	
	</repositories>
 
</project>

A idéia aqui não estar explicando o que é um POM, sua estrutura, como funciona, etc, a idéia é apenas mostrar como criar um POM com o intuito de gerar pacotes do ALBPM.

Explicando o POM utilizado

No começo do nosso POM temos algumas informações obrigatórias que o Maven exige, portanto acho que não vale a pena citá-las, dessa forma partindo para a declaração das propriedades ( ), nós temos:

packageName – Nome do diretório da aplicação
packageDirectory – Diretório onde deverá ser gerado o pacote
packageExtension – Extensão do pacote a ser gerado

Na parte da declaração de plugins, nós declaramos os dois plugins que utilizaremos: maven-assembly-plugin (será o responsável por gerar o arquivo compactado, excluir os diretórios não desejados, etc) e maven-antrun-plugin (será o responsável por fazer algumas tarefas pontuais como renomear o arquivo compactado e deletar os diretórios não utilizados e que são gerados pelo plugin anterior).

No caso do plugin maven-assembly-plugin, associamos ainda um descriptor, que é um arquivo XML que contém todas as rotinas que esse plugin deverá executar e que possui o seguinte conteúdo:

<assembly>
	<formats>
		<format>zip</format>
	</formats>
	<includeBaseDirectory>false</includeBaseDirectory>	
	<fileSets>
		<fileSet>
			<directory>${basedir}/${packageName}</directory>		  			  	
			<filtered>true</filtered>			
		  	<excludes>		  		
				<exclude>**/.svn/**</exclude>
				<exclude>**/fuego.portal.jar/**</exclude>
				<exclude>**/build/**</exclude>
				<exclude>**/system/**</exclude>
		  	</excludes>		  	
		</fileSet>
	</fileSets>	
</assembly>

No conteúdo acima, especificamos no elemento
o formato do arquivo a ser gerado, no caso um zip. No elemento informamos ao plugin que não queremos que ele inclua o diretório base no arquivo zip a ser gerado. No elemento definimos uma série de regras que o arquivo a ser zipado deverá obedecer: no primeiro elemento () informamos qual diretório deverá ser zipado, repare que nesse caso usamos os valores das propriedades definido no arquivo POM do Maven. No segundo elemento, no caso , informamos que NÃO queremos que o plugin inclua os diretórios que não possuem arquivos, ou seja, não queremos diretórios em branco. No terceiro elemento (), informamos ao plugin quais são os diretórios e arquivos que NÃO devem ser incluídos no arquivo zip a ser gerado, nesse caso não queremos incluir nenhum diretório/arquivo do SVN, não queremos incluir o JAR fuego.portal, assim como não queremos incluir os diretórios build e system, pois eles são gerados pela IDE em tempo de compilação e não são necessários para nosso pacote.

Explicando o arquivo Ant

No nosso POM, declaramos o plugin maven-antrun-plugin, que será o plugin responsável por executar tasks do Ant.

Ainda no arquivo POM, definimos algumas propriedades que o arquivo Ant deverá conhecer, ou seja, ele irá herdar as propriedades que definimos no POM, bem como definimos qual é o arquivo XML que conterá as taks do Ant a serem executadas, no nosso caso esse arquivo é o maven-setup.xml.

O arquivo maven-setup.xml conterá duas rotinas: uma que é renomear o zip gerado, para ao invés de possuir a extensão .zip, possuir a extensão .exp (propriedade definida no POM e herdada no arquivo Ant), e outra rotina deverá ser remover o diretório target, que é gerado pelo maven-assembly-plugin e que no nosso caso não teria nenhuma utilidade. Dessa forma o conteúdo do nosso arquivo Ant ficou assim:

<?xml version="1.0" encoding="UTF-8"?>
<project name="mavensetup" default="setup">
	<target name="setup">
			<echo level="info">Renomeando o pacote para ${package_name}.${package_extension}</echo>
		  	<move file="target/${package_name}.zip" tofile="${package_directory}/${package_name}.${package_extension}"></move>
		  	<echo level="info">Apagando o diretorio /target</echo>
		  	<delete dir="target"></delete>
  	</target>
</project>

Repare, que no arquivo Ant usamos as propriedades definidas no nosso POM do Maven e usamos ainda o elemento para termos informação do que o Ant está fazendo.

Resumindo

Usando apenas 3 arquivos (pom.xml, assembly-descriptor.xml, maven-setup.xml) nós temos nosso pacote do ALBPM sendo gerado pelo Maven e pronto para ser deployado na versão enterprise do ALBPM.

Agora basta apenas um mvn install na linha de comando para geração do pacote.

Mais informações

Começando com o Maven

Maven Assembly Plugin

Maven AntRun Plugin

Maven Lifecycle

Domínio

Quando trabalhamos em um ambiente de desenvolvimento, basicamente o que temos que nos preocupar é referente a criação de um domínio. Um domínio nada mais é que um conjunto de recursos e serviços que fisicamente são mantidos através de arquivos.

A parte principal de um domínio chama-se Administration Server, que é uma instância de um Weblogic Server responsável por manter e configurar seus recursos. Todo esse gerenciamento do Adminstration Server é feito através do Admin Console, que por sua vez é uma aplicação que é deployada no seu Administration Server e que será responsável por fornecer uma interface gráfica para que você possa gerenciar seu domínio, ou seja, toda a configuração feita pelo Admin Console é baseada em XML e é ele quem gerencia esses arquivos.

É através do Administration Server que você faz o deploy/undeploy das suas aplicações, porém em um ambiente de produção, ou até mesmo de homologação, o mais indicado é que tenhamos nossas aplicações em um servidor a parte, que são chamados de Managed Servers.

Managed Servers

Uma instância de um Weblogic Server, que não é uma instância do Administration Server, é chamada de Managed Server, é no Managed Server onde suas aplicações e recursos serão deployados de fato, deixando para o Administration Server apenas a responsabilidade de gerenciá-los.

São os Managed Servers que hospedam todos os componentes e recursos que constituem uma aplicação, e toda vez que um Managed Server é inicializado, ele se conecta com o Administration Server para obter informações de configuração e deployment.

Cluster. O quê é e por quê usar?

Em ambientes de produção é normal que existam certas preocupações que não ocorrem com ambientes de desenvolvimento, como alta disponibilidade das aplicações e balanceamento de carga.

Imagine que ocorra qualquer problema na máquina onde a sua aplicação está deployada? O quê fazer? Para não ficar a mercê desse tipo de problema, o correto é pensar em uma estrutura em que sua aplicação possa ser replicada em N instância de servidores em máquinas diferentes, onde caso uma máquina dê problema, a outra assume e assim sucessivamente.

Outro problema comum é a sobrecarga de uma aplicação. Um cenário normal em aplicações web é o acesso de muitos usuários e consequentemente o processamento a exaustão das máquinas onde essas aplicações estão deployadas, isso por muitas vezes pode ocasionar um estouro de processamento ou até mesmo um tempo de resposta maior para o usuário. E como fazer para resolver esse problema? A resposta é através do balanceamento de carga.

Para resolver esses tipos de problemas foi criada uma estrutura cuja o nome é Cluster. Um Cluster é um conjuto de computadores que trabalham de forma conjunta cujo objetivo é fazer com que todo o processamento da aplicação seja distribuído a N computadores, mas de forma que pareça com que eles sejam um computador só.

Cluster e Managed Servers

Um Cluster de Weblogic Server corresponde a múltiplas instância de Weblogic Server que estão trabalhando e rodando simultaneamente com o objetivo de prover escalabilidade e disponibilidade.

Ou seja, um Cluster é um conjunto de Managed Servers, e cada Managed Server representa um nó de um cluster.

Quando se pensa em uma arquitetura usando Clusters, é normal que se pense em mais de uma máquina, afinal não faz muito sentido ter um Cluster com uma máquina, pois caso essa máquina pare de funcionar, todas as aplicações também irão parar.

A relação Managed Servers, Machines e Domínio

Partindo do princípio que um Cluster deve necessariamente ter mais de uma máquina, chegamos ao conceito de “Machines” do Weblogic Server.

Uma “machine” é exatamente uma máquina, um computador físico, e essa máquina pode ter mais de um managed server, ou seja, pode ter mais de uma instância do Weblogic Server rodando ao mesmo tempo. É óbvio que nesse caso teríamos que ter essas duas instâncias rodando em portas diferentes.

Dessa forma, chegamos a seguinte associação: Domínio -> Administration Server -> Cluster -> Machine -> Managed Server.

Node Manager

Quando falamos a nível de máquina (machine), devemos falar também dos Node Managers. Um Node Manager não está associado a um domínio, está associado a uma máquina, já que uma máquina pode ter mais de um Managed Server.

Um Node Manager é uma aplicação standalone responsável por gerenciar Managed Servers em uma máquina (machine) remota. Através do Node Manager é possível inicializar, parar e re-startar instâncias do Administration Server e dos Managed Servers de uma máquina remota.

Multi-cast Address

Em um ambiente clusterizado, precisamos ter N computadores trabalhando de forma conjunta de forma que isso seja transparente, mas quando usamos recursos como sessões, ou até mesmo conexões distribuídas, precisamos que isso também seja feito de forma distribuída, sem que seja necessário por exemplo criar uma sessão para cada Managed Server.

Isso é feito através do multi-cast address, que é um IP associado a um cluster, que por sua vez irá informar esse IP para seus Managed Servers para que os mesmos possam usar um único IP para fazer esse tipo de compartilhamento.

Juntando tudo

Para dar uma visão mais clara de toda essa arquitetura e quem está associado a o que, resolvi criar um diagrama que mostra todos os elementos citados acima e associação/relação entre eles.

No exemplo usei ainda o Apache como Servidor Web, que será a porta de entrada de tudo, será ele que irá receber as requisições HTTP, fazer o balanceamento de carga e delegar as responsabilidades para os Managed Servers. Será o Apache ainda o responsável por identificar e servir conteúdo estático sem que seja necessário passar pelo Cluster.

Diagrama

clique para ampliar

Mais Informações

Weblogic Server
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/admin.html

Understanding Cluster Configuration
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/cluster/config.html

Understanding Weblogic Server Clustering
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/cluster/overview.html

Setting Up Weblogic Cluster
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/cluster/setup.html

Using Node Manager
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/server_start/nodemgr.html

Node Manager Architecture
http://download.oracle.com/docs/cd/E13222_01/wls/docs81b/adminguide/nodemgr.html

Configure Apache HTTP Server
http://download.oracle.com/docs/cd/E15051_01/wls/docs103/plugins/apache.html

Um domínio Weblogic pode ser corrompido por diversos motivos, como: domínio ser encerrado de forma forçada ( com um kill -9, por exemplo), máquina ser desligada de forma repentina, falta de luz, etc. Quando isso acontece, seu domínio que estava rodando pode ser corrompido, e com isso a seguinte mensagem é retornada ao tentar iniciá-lo novamente:

Server cannot be started.   The server process cannot be started, or terminated abruptly. Check the start script.

Para resolver isso é muito simples, basta remover todas as pastas build pré-existentes (são geradas automaticamente pela seu Workshop, quando a aplicação é compilada) e em seguida basta fazer um start do seu domínio novamente.

Outra dica, é que antes de tentar fazer o deploy das aplicações em cima desse domínio novamente, que antes faça um undeploy (usando o console) das mesmas, pois se o domínio foi encerrado de forma forçada, as aplicações ainda estarão lá deployadas e caso você tente novamente, provavelmente não conseguirá.

Procurei sobre isso nos forums da Oracle e não achei nada, então fica aí a dica, pois isso evita que você tenha que re-criar e configurar seu domínio novamente.

BPM pode muito bem existir sem SOA, já que BPM é uma modalidade que foca na aplicação de práticas e conceitos para melhoria e absorção de processos de negócios por parte de uma organização, mas e SOA, pode existir sem BPM?

SOA é um modelo arquitetural de construção de software que possui alguns pilares, dentre eles:

• Interoperabilidade
• Flexibilidade e agilidade a mudanças
• Alinhamento entre TI e negócio
• Redução de custos
• Exposição no formato de serviços das principais atividades/operações da empresa
• Reutilização e re-aproveitamento
• Baixo acoplamento

Dentre os pilares citados acima, é fácil perceber que SOA gera valores semelhantes ao que aplicação adequada de uma solução BPM geraria, entretanto BPM não é uma maneira de se construir software, BPM está muito além disso, está no topo, mas deve atuar lado-a-lado a SOA para produzir resultados mais duráveis, que gerem mais valor ao negócio, que sejam mais fáceis de manterem e de darem manutenção. E o somatório disso tudo proporciona resultados mais efetivos.

Certa vez li uma analogia sobre uso de SOA sem BPM e que de certa forma ajuda a esclarecer a importância da aplicação de BPM junto a SOA. Era mais ou menos assim: “Usar SOA sem BPM seria como um malabarista com uma mão atada atrás das costas. Ele poderia ainda fazer alguns malabarismos, mas não seria tão eficaz e nem tão rápido como poderia ser”.

E na prática como BPM complementa SOA?

Um dos pilares citados em uma arquitetura SOA é a possibilidade do alinhamento entre TI e negócio, e BPM ajudaria isso de forma efetiva através de uma notação para mapeamento de processos, no caso BPMN. Existe forma mais efetiva do que representar ações no formato de desenhos e diagramas? Dessa forma analistas de negócio e analistas de processos conseguem trabalhar juntos com times de TI na implantação e implementação de uma arquitetura SOA, onde através do mapeamento dos processos de negócio, conseguiriam identificar serviços que agreguem e tenham importância para o negócio de uma organização, identificando assim a necessidade de implementá-los.

Em relação a possibilidade de mudanças, BPM oferece todo suporte e facilidade para mudanças através da visão holística que o mapeamento de um processo de negócio proporciona, dando a possibilidade de visualização de papéis, atividades, setores, departamentos e parceiros de uma organização, ou seja, todos os stakeholders, além do conhecimento de todo fluxo da informação.

Do ponto de vista da automatização de processos de negócio, através dos softwares BPMS, BPM oferece adaptadores e conectores para realizar a integração entre sistemas legados através da exposição de serviços e atuando na composição e orquestração desses serviços, BPM proporciona uma “API visual” de toda as integrações e uma facilidade maior de manutenção e mudança.

BPM no topo de uma arquitetura SOA

BPM deve atuar no topo de uma arquitetura orientada a serviços, pois uma arquitetura SOA deve focar de ponta-a-ponta no negócio, e dessa forma BPM atuaria do ínicio ao fim em uma arquitetura SOA.

BPM proporciona o melhor uso de serviços de negócio oferecidos por SOA gerenciando a relação entre eles sob o ponto de vista de processos de negócio.

BPM ajuda na Governança de SOA

Numa arquitetura SOA, consumidores e fornecedores de serviço são executados em diferentes processos de negócio, são desenvolvidos e gerenciados por diferentes departamentos e exigem um grande número de coordenação para trabalhar juntos com sucesso.

Para SOA ter êxito, múltiplas aplicações precisam compartilhar serviços comuns, o que significa que eles precisam ser coordenados para tornarem estes serviços comuns e reutilizáveis (olha o BPM aí!). Estes são os problemas de governança e eles são muito mais complexos do que problemas de aplicações monolíticas ou mesmo problemas de componentes e códigos reutilizáveis.

Exemplo real

Fiz um rascunho simples de uma arquitetura em camadas que utiliza BPM, SOA e BPEL e que estará exemplificada logo abaixo. O processo é para um banco e o intuito é fornecer o empréstimo de uma quantia em dinheiro para um cliente, que no caso é quem faz essa solicitação. Tudo começa e termina no BPM, que atua como um orquestrador de serviços.

Nesse exemplo temos serviços em um nível mais baixo, que no caso são serviços expostos por sistemas de terceiros, módulos de ERP, CRM, etc. Temos nível intermediário com um processo de negócio BPEL que faz a composição de alguns serviços presentes no nível mais baixo e no topo de tudo temos o BPM orquestrando todos os serviços e controlando todo o processo.

clique para ampliar

Ou seja, é muito importante sabermos que essa API existe e principalmente sabermos como usá-la. Existem duas maneiras de usá-la: externa e internamente. Externamente isso pode ser feito usando o PAPI-WS, que são serviços expostos pelo próprio ALBPM para que se possa usar o PAPI, porém um pouco limitado. Outra opção é usando a JAVA API, que é mais completa. Dentro do ALBPM usamos diretamente a Java API através do Catálogo de API’s da ferramenta.

Criando e Recuperando Instâncias de Processos

Fiz um exemplo de código bem simples no ALBPM para poder apresentar como criar instâncias e recuperar instâncias de processos. Seguem os dois exemplos com os respectivos comentários:

Criando Instâncias
Para criar instâncias é muito simples, basta usarmos o método create da API ProcessInstance, passando como parâmetros o ID do processo (sempre com “/” na frente), os argumentos de incialização (caso existam), e o nome do método de inicialização, que pode ser visto através da opção “argument mapping” do evento de inicialização. Segue o código:

String processCreateResult = create(processId : "/Teste", arguments : null, argumentsSetName : "BeginIn");

Recuperando Instâncias
Para recuperar instâncias também é muito simples, mas devemos ter atenção com a autenticação no DirectoryService onde o projeto correspondente a instância a ser recuperada está deployado.

Esse passo é necessário, pois para recuperar instâncias é usada outra API, no caso a API ProcessService e para tal precisamos autenticar no DirectoryService antes de tentar recuperar a instância de fato.

Para autenticação no DirectoryService, usamos o método connectTo da API ProcessService, e esse método espera 3 parâmetros: A URL do DirectoryService (pode-se usar as constantes como no exemplo abaixo), o usuário e a senha. O usuário e a senha devem possuir a role onde a atividade de criação da instância está associada.

(ProcessService).connectTo(url : Fuego.Server.directoryURL, user : "tester", password : "tester");
businessProcess = (ProcessService).getProcess(process : "/Teste");

Agora para visualizar o resultado, basta o seguinte código:

logMessage("-------------------------------------------------------------------");
logMessage("Instância do Processo Criado: "+processCreateResult);
logMessage("Referência da Instância Recuperada: "+businessProcess);
logMessage("-------------------------------------------------------------------");

Na minha opinião, para uma pessoa ser considerada um bom profissional ela precisa ter principalmente 3 características, são elas: estudo, experiência e o famoso pensamento “out of the box“.

É claro, que existem outros fatores não menos importantes, como: bom relacionamento inter-pessoal, ambição, humildade, caráter, etc, mas que não citei, pois acredito que isso já deveria ser parte do cidadão, da pessoa e se não somos bons cidadãos, boas pessoas, dificilmente seremos um bom profissional.

Voltando aos 3 tópicos citados acima, irei falar um pouco da minha percepção sobre cada um desses ítens e consequentemente o porque de eu considerá-los os mais valiosos.

Estudo

Desde que eu me entendo por gente, escuto que para “ser alguém na vida” eu deveria estudar muito, já que o mercado profissional é muito concorrido e blá blá blá.. aquele papo de sempre, chato, mas que não deixa de ser uma enorme verdade. Só que além de termos o desejo de ser um “profissional bem posicionado no mercado”, acredito ser mais importante estudarmos para entendermos o porque das coisas, para nos questionarmos, para questionarmos outras pessoas, para darmos outras idéias e consequentemente sairmos da inércia de um padrão estabelecido.

Estudar não significa só ir para escola e passar com nota boa, como também não significa só ir para faculdade e ter o melhor CR da turma, é óbvio que isso tudo é importante, mas há muitas coisas além disso.

Estudar significa ter interesse pelo que estamos lendo e pesquisando, significa termos curiosidade sobre o motivo de como as coisas funcionam, significa termos sempre aquela anseio por novos conhecimentos para irmos além. Estudar está diretamente ligado a nossa aptidão e gosto por determinado assunto, pois no meu modo de ver é impossível estudar e se interessar por algo em que não se tenha prazer. Quem nunca viu uma penca de pessoas estudando para um concurso durante anos e não sendo aprovada? Quem não conhece pessoas que foram muito mal na escola e que hoje são bons profissionais? Quem não conhece pessoas que não fizeram faculdade e hoje são bons profissionais? E finalmente, quem não conhece pessoas que são formadas em outra área e hoje são bons profissionais em outras? Eu já vi pessoas que se enquadram em todas essas situações.

Estudar também, nesse caso, é o contrário de acomodação, afinal quem estuda, lê e se informa, nunca está acomodado, está sempre por dentro das novidades, está sempre trocando e compartilhando conhecimento e consequemente desempenhando melhor a sua atividade profissional.

Experiência

Esse é um fator determinante para nos tornamos um bom profissional, quanto mais bagagem tivermos, mais fácil será prever alguns problemas, mais fácil será identificar problemas e mais fácil será criar soluções para os problemas.

Uma pessoa que está começando agora, com talento, interessada e esforçada, pode ser uma pessoa muito boa de se trabalhar, de fazer parte da sua equipe, mas ela só será considerada como um profissional completo (completo != topo), quando ela adquirir determinada experiência em sua área de atuação profissional. Por exemplo: existem bons médicos recém-formados, que estudaram, se especializaram e que lêem bastante, mas que provavelmente demorariam mais a associar alguns sintomas a determinada patalogia, que um médico, com as mesmas virtudes, mas com mais experiência, talvez identificasse mais rápido. Isso se chama experiência, bagagem.

Sendo específico no mercado de desenvolvimento de software: quem nunca viu aquele cara que trocou a versão de uma API usada em um projeto (que funcionava!) e passou a ter enormes problemas na aplicação? A intenção desse cara foi boa, com toda certeza, mas nesse caso lhe faltou experiência para saber que a nova versão da API pode impactar diretamente questões de ambiente e infra-estrutura. Provavelmente um profissional mais experiente, não mudaria a versão de uma API que já funcionava e era estável, por uma versão mais atual, só porque é mais atual, ele faria isso caso houvesse um BOM motivo.

Não tem jeito, se existem dois profissionais com o mesmo nível de estudo e de habilidade e técnica, o que tem mais experiência vai acabar se sobressaindo, pois esse saberá lhe dar com situações mais críticas, situações que exigem um tempo de resposta mais rápido e situações que exigem uma análise mais profunda para detecção do problema ou para bolar uma solução.

Pensamento “out of the box“

Pensar de uma maneira “out of the box“, significa pensar em uma maneira de fazer algo fora dos padrões pré-estabelecidos, que poucas ou nenhuma pessoa pensaria da mesma forma, é ser criativo e imaginativo para criar e enxergar uma solução para um problema existente, é conseguir enxergar pra frente e pros lados.

Existem determinadas situações onde um problema requer uma solução “out of the box”, na indústria de software existem muitos casos em que uma solução “out of the box” foi usada para resolver determinado problema ou para criar determinado produto. Certa vez assisti a uma palestra do Guilherme Chapiewski onde ele (se eu não me engano) havia pensado em uma maneira de diminuir o tráfego (requests/responses) de comunicação do Twitter usando o protocolo XMPP, ao invés de apenas a sua API REST. Isso é pensar out of the box.

Não faltam exemplos sobre pensamentos “fora da caixa”, inclusive vários fora da indústria de software. Recentemente assisti um vídeo muito interessante sobre um projeto para o metrô de uma determinada cidade onde o trem não pararia. Esse vídeo pode ser visto aqui.

Por que eu estou dizendo isso tudo?

A idéia de publicar algo sobre o assunto surgiu essa semana, quando eu estava tentando resolver um problema pouco convencional reportado por um cliente.

Estamos dando suporte a algumas aplicações desenvolvidas por terceiros, portanto tudo fica mais difícil, e o erro reportado pelo cliente não conseguia ser reproduzido no meu ambiente de desenvolvimento, mas ao gerar um pacote para fazer o deploy no nosso ambiente de homologação interno, o mesmo erro que ocorria com o cliente, passou a ocorrer conosco.

O mais curioso é que o erro só acontecia em determinadas situações bem específicas MESMO, então toda possibilidade de identificação do erro ia por água baixo, pois não conseguiamos associar um erro ao outro, e a cada mudança nos valores das variáveis usadas para input no sistema, o erro não conseguia ser simulado novamente.

Até que um companheiro de trabalho começou a fazer perguntas que demonstravam toda sua experiência e um pensamento “out of the box” para enxergar o problema, eis o diálogo que tivemos:

- Qual arquitetura do SO do ambiente de desenvolvimento?
- 32 bits
- E de homologação?
- 32 também
- Qual JVM você tá usando em desenvolvimento?
- A da Sun
- E do ambiente de homologação é a da Sun também?
- Humm, não, é JRockit
- Experimenta mudar a do ambiente de homologação para Sun

Resumindo, mudei o ambiente de homologação para usar a JVM da Sun e o erro esquisito parou de ocorrer, a partir disso, conseguimos identificar que o problema estava ao realizar cálculos utilizando o tipo float, que não é o mais adequado para cálculos, mas que o código que já estava feito estava usando. O problema era no arredondamento do resultado do cálculo e de acordo com a arquitetura da JVM utilizada esse valor variava. Mudamos os tipos para BigDecimal e tiro e queda, problema resolvido, mesmo tendo JVM diferentes em ambientes diferentes.

O que se conclui é que o meu amigo teve uma sacada diferente para esse problema, conseguiu pensar de uma maneira “out of the box” e achar uma solução para o problema. Isso tudo baseado na sua experiência com linguagens de baixo nível, que sem dúvida lhe deu embasamento para pensar na razão da problema. Sem estudar, ele também não conseguiria ter essa percepção do problema.

E para você, quais são as principais características que determinam um bom profissional?

Recentemente recebi duas dúvidas de uma analista de processos confusa com os termos comuns usados dentro dessa área de processos e também em relação a adoção de processos negócio servindo como orquestrador de sistemas legados.

Eis as perguntas e as minhas respostas:

1) Qual é a diferença básica entre o BPMS e um Workflow?

Os softwares BPMS se assemelham com Workflow de diversas maneiras, a principal delas é que ambos servem como apoio para gestão de processos de negócio, onde você consegue fazer o mapeamento, modelagem e desenho desses processo de negócio. Entretanto os BPMS, por serem uma suite, oferecem mais opções que um Workflow. Com ambos, tanto BPMS e Workflow, você consegue fazer a modelagem dos processos, mas no geral os BPMS são mais usados para execução, monitoração e automação de processos de negócio. Já o foco principal dos Workflow é servir como um “tradutor” de processos de negócios (e todos seus usuários, regras e cenários) para uma notação visual, que irá servir como uma espécie de documentação para uma visão macro (ou até mesmo mais detalhada, dependendo do caso) do processo de negócio.

Apesar de ser possível executar e automatizar processos de negócio com a tecnologia Workflow, OS BPMS possuem alguns recursos como BAM, BRM, facilidade de integração entre sistemas através de adaptadores, padrão de notação visual (BPMN), facilidade para orquestração de serviços (BPEL), que por exemplo um Workflow não possui.

Processos de negócio mais complexos são melhores atentidos com uma solução BPMS do que com Workflow.

Abaixo, dois bons links como complementação de leitura para esse tópico:

Workflow? BPM? I’m So Confused!

Comparing BPA and BPMS is like comparing apples and oranges

2) Posso utilizar um BPMS apenas para controle do processo? E continuar utilizando meus sistemas legados normalmente, sem mudar o trabalho dos usuários?

Quanto aos sistemas legados, como eu disse anteriormente, os BPMS oferecem ótimos recursos para integração com sistemas legados, seja através de Web Services, Banco de Dados, Filas JMS, dentre outros. Por isso não há a necessidade de que esses sistemas legados deixem de existir, eles podem muito bem ser orquestrados no seu processo de negócio utilizando uma solução BPMS, mas o que é muito importante e nunca deve ser esquecido é o real motivo da existência desse processo: por que ele existe? Para que ele existe? Qual seu foco? Essas são perguntas que não podem deixar de ser respondidas.

Com o HermesJMS é possível publicar mensagens, remover, ver o conteúdo das mensagens publicadas, a quantidade, dentre outras funcionalidades. Eu diria que o HermesJMS está para JMS como o soapUI está pra Web Services.

Só que existe um pequeno probleminha de incompatibilidade entre o HermesJMS e o Weblogic 10.2. O HermesJMS foi construído com a JVM 1.6 e o Weblogic 10.2 roda com a JVM 1.5, portanto quando tentamos acessar resources JMS configurados em um servidor Weblogic temos um probleminha com o ClassLoader, segundo bug relatado nesse link.

Geralmente para resolução desse problema, quando eu ia usar o Hermes, eu mudava a minha váriavel ambiente JAVA_HOME para apontar para o JDK 1.5, para agilizar esse processo pode ser feito um Shell Script que seta essa varíavel de ambiente apontando para o JDK 1.5 e abrindo o HermesJMS logo em seguida, mas existe uma solução melhor e mais limpa para isso, que é setando uma propriedade na inicialização do HermesJMS, seguem os passos necessários:

1) Entrar no diretório de instalação do HermesJMS, no meu caso é /opt/HermesJMS
2) Editar o arquivo hermes.sh que fica dentro do diretório bin
3) Ir para a última linha desse arquivo e adicionar a propriedade: -Dsun.lang.ClassLoader.allowArraySyntax=true

Dessa forma, a última linha do arquivo /bin/hermes.sh ficaria assim:

"$JAVACMD" -XX:NewSize=256m -Xmx1024m -Dsun.lang.ClassLoader.allowArraySyntax=true $HERMES_OPTS -Dhermes.home=$HERMES_HOME -Dhermes=$HERMES_CFG -Dhermes.libs=$HERMES_LIB_PROPERTY -classpath $LOCALCLASSPATH hermes.browser.HermesBrowser

Esse pequeno workaround corrige esse probleminha de incompatibilidade entre o HermesJMS e o Weblogic 10.2 e nos permite usar o HermesJMS com o JDK 1.6.

O problema

Em um projeto pessoal recente precisei fazer a integração entre três sistemas distintos, na verdade os sistemas são distintos, mas não deveriam ser. Trata-se de um site e o que ocorre é que esse mesmo site possui três módulos (sistemas) que estão em plataformas, linguagens e lugares diferentes. Conclui-se que é um projeto que foi crescendo desordenadamente e que em nenhum momento ninguém pensou em uma maneira de organizar melhor os módulos e realizar as integrações. Como esses módulos foram feitos em linguagens e plataformas diferentes, o requisito número um do cliente era que esses módulos se comunicassem e que essa comunicação fosse transparente pra ele e para quem fosse administrar o sistema.

Cenário atual

O site é um pequeno site de e-commerce e dos três módulos existentes, um diz respeito ao frontend/backend do site e é feito com .NET/SQL Server, o outro módulo é o backend de vendas e é feito com PHP/MySQL e o último módulo é o de newsletter (mailing) que também está em PHP/MySQL. O módulo de vendas foi o último a ser desenvolvido e deveria ser mantido, o problema é que o administrador do sistema precisa “inputar” todas as vendas na mão, isso mesmo, na mão! Atualmente, quando um cliente tem interesse em algum produto do site, ele envia um email ao administrador informando qual(is) o(s) produto(s) ele tem interesse e os seus dados pessoais, e por sua vez o administrador entra no módulo de vendas, cadastra esse novo cliente, cria um pedido de venda, gera um login/senha para esse cliente e envia por email para que ele possa se autenticar no módulo de venda, concluir a compra e efetuar o pagamento.

Além de ser algo totalmente mecânico e nada prático, não há nenhuma relação entre os módulos do site e o administrador precisa reproduzir os dados do produto, que já existe em um módulo, em outro. Eram esses problemas que deveriam ser remediados.

Requisitos do cliente

Um dos requisitos do cliente, era de que o site (frontend e backend) deveria ser construído novamente, pois o atual além de ter sido construído em uma plataforma que ele não tinha mais interesse em manter, também estava incompleto e apresentando problemas, portanto o primeiro requisito era refazer todo o site com PHP/MySQL.

O segundo requisito era que o processo compra de produtos deveria ser todo feito através do site, pelo cliente, e não da forma arcaica como é atualmente e que foi descrita acima.

O terceiro requisito era que o módulo de vendas deveria ser mantido, pois ele atendia o que o cliente precisava, sendo assim o sistema que eu iria desenvolver deveria alimentar diretamente esse módulo de vendas.

Estrutura do módulo de vendas

Felizmente o módulo de vendas estava construído de uma maneira que facilitou o meu trabalho, quem o desenvolveu se preocupou em criar classes de modelo, uma camada de persistência e uma camada de negócio, portanto pude pensar em uma arquitetura simples em funcional muito em função disso.

Arquitetura pensada

Tentei pensar em algo que não criasse uma dependência entre os sistemas e que me fizesse mexer o minímo possível, ou nada, no módulo de vendas que seria mantido. Outros fatores que levei em consideração era que eu queria algo fácil de implementar, de dar manutenção e que de certa forma fosse rápido de desenvolver.

Conclui o desenvolvimento do (frontend/backend) e parti para pensar em uma arquitetura que me permitisse fazer tudo o que citei acima e que além disso me permitisse utilizar a boa estrutura que eu encontrei no módulo de vendas.

Para construir o site utilizei o Code Igniter, que é um framework que tenho prática, e também é leve e rápido de desenvolver, mas o que vale ressaltar é que arquitetura é algo que é independente de framework, portanto se eu tivesse utilizado qualquer outro framework, ou até mesmo se eu não tivesse utilizado nenhum framework, não faria a mínima diferença. Nesse caso os frameworks escolhidos só entram como facilitadores na implantação da arquitetura.

Mas voltando ao foco inicial, que é explicar a arquitetura, o que eu pensei foi em criar um Web Service com as operações específicas para tudo o que eu precisaria fazer no módulo de vendas, ou seja, eu precisaria identificar todas as ações que eu precisaria realizar para fazer essa integração e alimentar esse módulo. Na verdade, além de alimentar eu também precisaria recuperar algumas informações do módulo de vendas. Como os módulos (site, vendas, newsletter) ficariam provavelmente em servidores diferentes, em bancos diferentes e em estruturas diferentes essa era a forma mais limpa de realizar a integração sem causar dependência entre esses módulos e com isso dar manutenção seria bem mais fácil.

Como já estava definido que eu iria utilizar Web Service, eu optei por utilizar o formato RESTful, pois eles se encaixava perfeitamente na minha necessidade: me trazia simplicidade, praticidade, facilidade, além do que no meu caso a aplicabilidade de ROA, que é o conceito que Web Services RESTful utilizam, era muito mais evidente do que a abordagem de serviços.

O próximo passo era identificar os recursos necessários e criar as URI que eu utilizaria nos requests do meu Web Service REST, então ficou dessa forma:

• user/new
• user/retrieve/email
• user/retrieve/cpf
• order/new
• order/save/products
• order/retrieve/last
• shipping/calculate

Para desenvolver esse Web Service RESTful resolvi utilizar o Zend Framework, pois ele possui alguns componentes que me ajudariam a desenvolver esse Web Service mais rápido, como o suporte a Web Services RESTful, por exemplo, o ZF também tem uma API para trabalhar com JSON muito boa, então esse foi outro componente do ZF que eu resolvi utilizar.

Como no módulo de vendas já existiam classes de modelo que representavam as entidades do meu domínio, o que eu fiz foi criar uma estrutura JSON semelhante as essas entidades e que representaria os requests/responses do meu Web Service RESTful. Paralelo a isso criei algumas classes de apoio que serviriam como os Marshallers e Unmarshallers do Spring. Marshallers e unmarshallers são como data mappers, e no meu caso servem para eu mapear um objeto JSON para um objeto PHP (classes modelo) e também realizar o inverso.

Dessa forma com objetos JSON convertidos para objetos PHP que representavam as minhas classes modelo eu poderia usar a camada de persistência existente na aplicação para persistir todo objeto, então no caso de salvar um novo usuário, ficou assim:

function saveUser($user) {	
	$userObject = Unmarshaller::user(Zend_Json::decode($user));	
	$conn 	    = DB::getConnectionHandler();
 
	$result 	= $conn->user->save($userObject);	
 
	if ( $result )
		return array('status' => TRUE, 'response' => 'Usuário cadastrado com sucesso.');	
	else
		return array('status' => FALSE, 'response' => $conn->ErrorMsg());	 
 
}

Bem simples, né? No exemplo acima, criei algumas classes estáticas (utilitárias), a primeira me retorna um objeto de conexão com o banco de dados e a segunda classe representa o unmarshaller para transformar um Objeto JSON em uma classe de modelo que representa um usuário, após isso foi só persistir o usuário e retornar as mensagens correspondentes para quem está acessando recurso.

Visão geral

No fluxo de salvar um novo usuário, teríamos:

1) Site (módulo site) deseja salvar um novo usuário;
2) Site monta um objeto JSON com os dados que representam o novo usuário;
3) Site acessa o Web Service RESTful do módulo de venda através do recurso user/new;
4) No módulo de venda, o método mapeado para o recurso user/new, faz unmarshaller do objeto JSON mapeando os valores desse objeto JSON para uma classe de modelo;
5) O usuário é persistido através do objeto que foi mapeado no passo anterior;
6) O Web Service RESTful retorna a mensagem correspondente para o site.

Quando se fala em arquitetura é comum pensarmos em algo complexo, cheio de tecnologias, frameworks e etc, mas o foco de arquitetura não deve ser esse, o foco de arquitetura deve ser pensar em uma estrutura que prime pela organização, relacionamento e reuso dos componentes de softwares envolvidos em um sistema, onde o intuito deve ser facilitar e não complicar.

Para apresentação, criei um projeto piloto “empréstimo bancário” onde é possível mostrar os conceitos mais básicos do ALBPM. Como imagino existirem mais pessoas com tal necessidade, irei disponibilizar o download do projeto, bem como o script SQL necessário para criação da tabela usada no projeto.

Os tópicos abordados na apresentação foram:

- O que é BPM e BPMS?

- SVN

Download do projeto.

Download do script SQL.

PS: O projeto não disponibiliza todos os tópicos abordados e citados acima, mas quase todos.

Segue a chamada do Evento:

A ELO Group e o GPI/UFRJ estão promovendo o evento internacional ‘Elaboração e Implantação de Estratégias de Sucesso em BPM’, com a participação do Prof. Michael Rosemann, uma referência mundial no assunto. O evento será realizado nos dias 01, 06 e 07 de outubro de 2009, nas cidades de Brasília, Rio de Janeiro e São Paulo, respectivamente. INSCRIÇÕES ABERTAS!

Uma das organizadoras do evento será a ELO Group, que vem tendo algumas iniciativas legais de BPM em prol da disseminação do conhecimento, duas dessas iniciativas são a publicação BPM 360 e também Webinars gratuitos.

Estávamos usando o jQuery até então, que é uma biblioteca JS, que contém inúmeros plugins, além de vários facilitadores para construção de aplicações mais interativas. Acho bacana terem surgidos várias bibliotecas JS, onde o jQuery talvez seja a principal dessas, pois com isso o nível de interatividade entre o usuário e as aplicações aumentaram consideravelmente e isso trás (ou pelo menos deveria) outros prós, como: facilidade de navegação e usabilidade mais intuitiva nas interfaces que fazem o bom uso desses recursos. Para os desenvolvedores sem dúvidas também foi algo positivo, pois é bem tranquilo hoje fazer uma requisição ajax com uma linha de script, além de termos também um código mais organizado e estruturado.

Só que eu sempre tive um certo receio em relação a essas bibliotecas, não com as bibliotecas em si, mas da forma que alguns desenvolvedores as usam, principalmente em caso de aplicações para um grande número de acessos em um ambiente mais “pesado”, já vi alguns casos em que o uso dessas bibliotecas atrapalhou mais do que ajudou e recentemente isso aconteceu comigo.

Utilizei um plugin do jQuery pronto para criar wizards de formulário, ou formulário no formato de wizard, como preferir. Esse plugin, além de ser pouco flexível, causou um problema na minha aplicação justamente no wizard que possui vários inputs. O problema é que ao entrar nesse wizard, o browser simplesmente para durante uns 3s, respira, e depois mostra o wizard, e vamos combinar que isso é muito esquisito, não é um comportamento normal. Para ser sincero não consegui identificar a causa principal, mas desconfio de várias coisas, primeiro é que no geral essas bibliotecas são muito pesadas, só para esse wizard de form eram mais de 50kb de arquivo, algo desnecessário, ainda mais considerando um ambiente com MUITO VOLUME de acessos, pois isso acaba causando um overhead. O segundo é em relação ao código da função para geração do wizard, achei o mesmo extenso demais para fazer algo que funciona, mas que é pouco flexível. O terceiro é que essas bibliotecas JS já são uma abstração de N componentes nativos do JS e por mais que seja ínfimo, isso também pode ajudar a causar um overhead.

Mediante a esses percalços e também a falta de flexibilidade do script que eu utilizei, resolvi criar o meu próprio script para fazer o wizard do formulário, esse script é bem simples, não utiliza nenhuma biblioteca JS, é bem fácil de entender e extender, além de ser flexível. Falando assim parece até uma maravilha do mundo moderno hehe, mas realmente o script resolveu meus problemas de performance e me deu a flexibilidade que eu queria. Testei o mesmo no Firefox 3, Opera 9 e IE 7 e funcionou perfeitamente e da mesma maneira em ambos.

Para visualizar o script funcionando, basta clicar aqui, para fazer o download do mesmo, é só clicar aqui.

Se surgirem dúvidas ou problemas, sugiro criar um comentário que responderei somente por aqui, até porque caso outras pessoas que venham a utilizar o script tenham a mesma dúvida, já fico mais fácil de achar e procurar.

A especificação do protocolo HTTP diz, que o mesmo possui 8 métodos, porém os métodos geralmente mais usados são GET e POST. Quando aprendemos a desenvolver para Web, é comum lermos ou sermos informados, que o método POST deve ser usado em formulários e que o método GET deve ser usado através de links. Isso é uma inverdade.

Tanto o método GET, como o método POST, podem ser usados de várias maneiras, contudo existem boas práticas que indicam as melhores maneiras de fazer o uso desses métodos, a seguir explicarei melhor quais são essas maneiras.

Explicando GET e POST

O método GET faz a passagem de parâmetros para o servidor HTTP através de uma URL, enquanto o método POST envia um documento ao servidor HTTP com o conteúdo contido nesse documento (message body).

Quando usar GET e quando usar POST?

O método GET deve ser usado para acessar recursos, ou seja, para recuperar informações (dados), enquanto o método POST deve ser usado em ações que modifiquem essas informações.

Sendo mais claro, o método POST é usado em ações destrutivas, como: inscrição em algum serviço, modificação do estado de algum recurso no banco de dados, etc. Enquanto o método GET é usado em ações não destrutivas, como: buscas, listagens, etc.

Na prática

GET deve ser usado em operações seguras, justamente por ser indicado em ações que não modifiquem o estado de um recurso, pois imagine que você tenha em sua aplicação um link (GET) que leve a remoção de um determinado ítem, o que poderia acontecer no caso desse link ser indexado por algum web crawler? Pois bem, esse é um dos casos no qual o método POST seria indicado (operações não-seguras).

Exemplos reais

GET: query, buscas, filtros, listagem.

POST: inscrição em serviços (newsletter, por exemplo), alteração/edição/remoção de recursos em banco de dados, envio de email.

Referências

Architecture of the World Wide Web

The fundamental differences between “GET” and “POST”

URIs, Addressability, and the use of HTTP GET and POST

Form Submission

Web Services são componentes que permitem que duas aplicações troquem informações entre si utilizando um canal de comunicação (network), na maioria das vezes o protocolo HTTP. Existem alguns tipos de Web Services, mas os mais conhecidos e usados hoje em dia são: RPC, WS-* (WSDL/SOAP) e REST.

Dos padrões citados, provavelmente o formato mais conhecido e usado hoje em dia é o WS-*, que define que um serviço deve receber/responder mensagens no formato XML (SOAP) e deve possuir um contrato que defina os seus serviços (WSDL). Só que esse formato, principalmente depois da popularização do REST, vem sofrendo pesadas críticas de toda comunidade de desenvolvimento, que alega que esse formato é burocrático e complicado, enquanto o REST é um formato mais simples e objetivo.

Minha opinião é que tanto o padrão WS-* como o padrão REST não se substituem, pelo menos não por enquanto, e que tentar fazer essa comparação ainda não agrega, pois existem casos específicos onde REST é muito bem-vindo, assim como existem casos onde o padrão WS-* é muito bem-vindo.

WS-* – Vantagens e desvantagens

Uma das principais reclamações em relação a esse formato é que o mesmo possui N especificações e que isso o torna complexo e burocrático, e de certa forma eu concordo. Só para se ter uma idéia existem mais de 15 especificações para esse formato e conhecer todas é humanamente impossível e inviável.

Outra reclamação é em relação ao overhead que a troca de mensagens de um serviço no padrão WS-* pode causar, pois todas as mensagens precisam ser envelopadas dentro de um pacote SOAP, que nada mais é que um XML padronizado. Esse overhead é causado, pois dentro de um envelope SOAP, o que é usado é a menor parte do conteúdo que está ali contido, dessa forma há muito “lixo”.

Essas duas reclamações citadas acima, são as maiores reclamações dos desenvolvedores em relação a serviços WS-*, contudo no meu modo de ver existem também muitas vantagens no uso do formato WS-*, principalmente no que diz respeito a integração entre aplicações corporativas e também em relação a SOA.

Por exemplo, eu trabalho em um ambiente onde existem muitos serviços, muitos mesmos, e esses serviços são desenvolvidos por N fornecedores, em N plataformas distintas e são usados por N por aplicações. É um cenário bem complexo e eu não imaginaria esse cenário sem o uso do formato WS-*. E por quê? Em primeiro lugar porque ter um contrato formal desses serviços é totalmente necessário, afinal eu preciso saber o nome desses serviços, preciso saber o que eles estão esperando receber, o que eles irão me responder e como serão esses dados. Imagine se um serviço desses mudar o caos que seria?

Outro fator muito importante são as ferramentas de apoio, afinal elas além de facilitar o trabalho, trazem também produtividade. Existem N ferramentas que ajudam na simulação, testes, geração de Mock’s, teste de carga, debug e tantas outras atividades necessárias no desenvolvimento/acesso a esses serviços. A principal ferramenta free usada hoje em dia é o soapUI.

Em relação a SOA, o formato WS-* também se mostra a melhor opção. SOA é uma maneira de se construir softwares baseado no conceito de serviços, onde esses serviços devem possuir um contrato formal, devem ser independentes (possuir baixo acoplamento) e devem ser reutilizáveis. Outro princípio de SOA diz que esses serviços devem ter a capacidade de serem descobertos e nesse ponto o WS-* mais uma vez sai na frente, pois o mesmo possui o protocolo UDDI, que é um método utilizado para publicar e descobrir diretórios de serviço em uma arquitetura SOA.

REST – O que é, vantagens e desvantagens

REST é o acrônimo de Representational State Transfer, que é um modelo de arquitetura baseado no protocolo HTTP e que utiliza URI para identificação dos seus serviços. REST é uma maneira de construir serviços usando o protocolo HTTP como ele foi concebido, ou seja, usando: POST, GET, DELETE e PUT.

Serviços RESTful (serviços REST) partem do princípio que o protocolo HTTP é rico o suficiente para que seja criada uma abstração – no caso WS-* seria uma abstração – para construção de serviços.

Uma das vantagens em utilizar serviços REST sem dúvida nenhuma é a simplicidade, afinal criar serviços REST é usar de maneira parecida o protocolo HTTP como usamos atualmente no desenvolvimento de aplicações Web, ou seja, se você usa o método POST em um formulário, você consequentemente está usando REST, a única diferença é que o submit desse formulário devolveria um conteúdo HTML, quando que em um serviço RESTful o indicado seria devolver uma estrutura mais padronizada, no caso um XML ou um JSON, por exemplo.

Outra vantagem no uso de serviços REST é a performance, pois os seus request/response são infinitamente menores se comparados com os do formato WS-*, e são menores, porque não precisam ser envelopados dentro de um pacote SOAP, serviços REST apenas recebem o que precisam e consequentemente respondem o que é necessário.

Serviços construídos no formato REST também são mais humanos, ou seja, são mais compreensíveis que serviços WS-*. Isso se deve ao fato de que para construir um serviço REST não é necessário conhecer N especificações, não é necessário saber o que é WSDL, assim como também não é necessário conhecer um pacote SOAP. São mais humanos também, pois são identificados através de URI’s.

Dentre outras vantagens de serviços RESTful destaco a possibilidade de fazer cache das operações, possibilidade de criar camadas intermediárias (proxy, gateway, cache servers) com o intuito de aumentar a performance ou segurança e possibilidade de usar HTTPS nativamente.

Pensando em um ambiente corporativo, em aplicações enterprise e em arquitetura SOA, começam a surgir alguns problemas em relação a adoção de serviços REST, a começar pelo fato de que REST não possui um padrão oficial para descrição dos seus serviços, até existe uma frente interessada em criar esse padrão utilizando WADL, mas ainda não existe nada oficial, portanto essa é uma grande desvantagem.

Serviços REST também não possuem estado, são stateless, ao contrário de serviços WS-*, pois os mesmos podem possuir estado entre uma chamada e outra. Serviços REST também não permitem requisições assíncronas e utilizando o formato WS-* é possível fazer requisições sem que seja necessário esperar uma resposta.

Pensando em SOA, REST não é a melhor opção, afinal, conforme citado anteriormente, REST não possui um contrato formal para definir a interface dos seus serviços, assim como também não possui uma maneira para que esses serviços possam ser publicados e descobertos.

Outra desvantagem no meu modo de ver, é que para construção de um processo BPEL, se faz por necessário que os serviços possuam uma interface que os descreva (WSDL), nesse caso serviços REST não seriam os mais indicados para serem usados dentro de um processo BPEL, contudo existem algumas maneiras de realizar esse workaround para usar serviços REST dentro de um processo BPEL. Dependendo da ferramenta escolhida, algumas fornecem soluções como a criação de Partner Links HTTP, ou seja, são Partner Links próprios para serviços REST, ou então, algumas outras ferramentas fornecem maneiras um pouco mais trabalhosas como a criação de um WSDL que descreva o serviço HTTP (REST).

Afinal, qual devo usar?

Sinto lhe frustrar, mas a resposta para essa pergunta é: depende, cada caso é um caso.

Não é inteligente ignorar uma ou outra opção, ou ser cego a ponto de desconsiderar os benefícios e vantagens de cada uma. Na minha opinião, fomentar essa discussão é cair no mesmo de discutir “qual linguagem é melhor”, afinal cada uma tem seu propósito.

Os fanáticos por REST costumam dizer que o formato WS-* só existe, pois os grandes players do mercado (Oracle, IBM, Microsoft, etc) estão envolvidos, já que esses grandes players desenvolvem ferramentas específicas para facilitar a criação e a manutenção a serviços construídos dessa maneira. Quem faz essa afirmação está completamente equivocado, pois por mais burocrático que serviços WS-* possam ser, eles ainda possuem uma enorme utilidade que serviços REST ainda não satisfazem.

Agora, no caso de serviços para celulares, PDA’s, e outros dispositivos móveis, onde cada dado enviado/recebido tem um custo alto, utilizar serviços REST é sem dúvida a melhor opção. Da mesma maneira que para prover serviços de aplicativos web, como mashups, REST também é a melhor opção, a maior prova disso é que em serviços como Twitter, Facebook, Amazon e até mesmo o Google, estão usando REST em larga escala.

Mas também existe o outro lado da moeda, pois pensando em um ambiente complexo, com muitos serviços, repositórios, ainda não dá para pensar em outro formato que não seja WS-*.

Enfim, mais uma vez volto ao ponto de que devemos conhecer as opções para tomar a decisão de escolher o que é mais adequado, REST não substitui WS-* e vice-versa, insistir nessa rixa não agrega e quem não enxerga dessa maneira, precisa rever seus conceitos, ou então estudar mais.

Aproveito para deixar o link para download de uma apresentação sobre REST, que fiz no meio do ano passado, na empresa que eu trabalho: clique para fazer download.

O que é o Yii Framework?

O Yii é um framework que está sendo mantido e desenvolvido pelo criador do framework Prado, que é um famoso framework PHP baseado no conceito de event-driven programming, que a grosso modo seria um framework em que o seu fluxo é determinado por eventos.

Comparação com outros frameworks

Quando digo que o Yii não é mais um framework MVC, digo, pois ele parece ser muito mais maduro, estável, flexível e bem projetado que o restante, além do que ele é focado em performance, ou seja, foi desenvolvido pensando em aplicações Web “parrudas” e que precisam ser escaláveis.

Tenho alguma experiência com frameworks em PHP, já desenvolvi projetos que estão em produção usando o Kohana, Code Igniter e o Drupal (também é um framework!), além de já ter desenvolvido aplicações dummy usando o Zend Framework, Akelos e Cake, e por isso posso afirmar que o Yii é diferenciado. Por exemplo, o Code Igniter eu gosto bastante, mas ele é muito lightweight e não é PHP 5, o Zend Framework é sólido, mas na verdade é mais um conjunto de componentes do que um framework, o Kohana, que é um fork do CI, é interessante, mas ainda precisa comer muito feijão com arroz, o Cake sinceramente não me agrada e o Akelos é bem interessante, mas tem pouca comunidade e documentação. Nenhum desses, com exceção do ZF, me parece ser um projeto a longo prazo como o Yii.

O Yii é baseado em várias idéias do queridinho Ruby on Rails, e assim como o RoR possui geradores de código para gerar: controllers, models, scaffoldings apenas usando linha de comando. Ainda não me acostumei muito com essas idéias de geradores de código hehe, sou um pouco conservador em relação a isso, e muita “mágica” as vezes me preocupa, mas de qualquer maneira esses geradores trazem uma agilidade absurda e no final das contas se houver um equilíbrio entre agilidade e controle do que está sendo gerado, acho que vale muito a pena.

Principais atrativos

Além de ser bem projetado, com uma arquitetura bem definida, uso de design patterns e facilidade de ser extendido, o que me atraiu no Yii foi algumas features mais avançadas e que outros frameworks não possuem nativamente, como: sistema de cache em camadas (usando memcached e apc), suporte a web services (WS-*), internacionalização de verdade, sistema de autenticação/permissão usando RBAC, integração nativa com jQuery, acesso a dados usando DAO, ORM + ActiveRecord (com lazy loading, inclusive), etc.

Outro ponto que me convenceu foi a documentação, que é bem completa, clara e objetiva, possuindo manuais, tutorias, screencasts, fóruns e API.

O framework também é todo modularizado, permitindo que componentes sejam desenvolvidos para serem totalmente desacoplados da aplicação.

Aprendizado

A curva de aprendizado do Yii é muito mais alta que a do CI ou do Kohana, por exemplo, apesar de no site do framework dizer o contrário. Mesmo com o framework tendo uma documentação extensa, skeletons para construção da aplicação e geradores de código, entender como funciona o framework e sua arquitetura não é tão simples como os outros frameworks citados anteriormente, mas isso não quer dizer que o código seja ilegível, ou difícil de entender, muito pelo contrário, como a tendência dos frameworks hoje em dia é descomplicar e humanizar, acredito que o Yii tenho seguido essa linha, apenas acho que para um desenvolvedor inexperiente será mais árduo aprender o Yii do que o CI.

O que pode melhorar

Como é um framework recente, mesmo tendo muitas funcionalidades mais avançadas, algumas outras ainda senti falta. Por exemplo, o framework ainda não tem um suporte para testes, seja BDD ou TDD e isso hoje em dia é inaceitável. O RoR, por exemplo, é um framework que tem a parte de testes muito forte dentro do framework e toda sua comunidade também é assim, em PHP isso é um pouco diferente, portanto seria interessante que o Yii começasse a fornecer mecanismos para realização de testes, porém nada impede que se integre o SimpleTest ou PHPUnit com o Yii.

Outra coisa que senti falta também foi suporte para serviços REST, o framework apesar de oferecer suporte a Webservices, só oferece suporte para Webservices no padrão SOAP/WSDL, REST seria muito interessante, até mesmo porque um dos pilares do framework é performance.

Conclusão

Estou animado com esse novo framework, apesar de ter pouco contato, senti seriedade no trabalho, mas só posso afirmar tudo que eu disse depois que eu tiver uma experiência real com o framework.

No momento estou participando de um job novo, em que estou definindo o que será usado como framework web, na verdade, não gosto e não costumo usar tecnologias que não tenho experiência em projetos que estou a frente, mas como esse projeto não é crítico e nem complexo, possa ser que eu use o Yii para ter uma opinião formada sobre o mesmo, e caso eu opte realmente por essa opção, irei comunicando o progresso.

Na aplicação web do projeto que estou trabalhando, nós fazemos o uso da API Commons Logging do Apache para poder fazer logging da aplicação, só que para o log aparecer corretamente no console existe um pequeno “macete”, que por incrivel que pareça não diz com mais detalhes na documentação do Weblogic.

O probleminha era, que por mais que eu fizesse o seguinte:

public class SovWS {
 
	private static Log log =  LogFactory.getLog("SOV-"+SovWS.class);
 
	@WebMethod
	public SaveMetaResponseDocument saveMeta(SaveMetaRequestDocument request) {		
		log.info(this.getClass() + " iniciando a nova meta");
               ....
        }
}

Eu não conseguia fazer com que a mensagem de log aparecesse no console do Workshop, ainda que tudo estivesse correto.

Para resolver é muito simples, basta ir nas propriedades do projeto, ir nos facets do projeto e verificar se a extensão Weblogic Integrated Commons Logging está como um facet do projeto, se não estiver, está aí o problema e para resolver basta adicionar esse novo facet.

Para ter certeza que está tudo certinho, sugiro abrir o arquivo weblogic-application.xml e verificar se a seguinte configuração está presente:

<wls:library-ref>
    <wls:library-name>wls-commonslogging-bridge</wls:library-name>
    <wls:specification-version>1.0</wls:specification-version>
    <wls:exact-match>true</wls:exact-match>
</wls:library-ref>

Se a seguinte configuração estiver presente, pronto, tudo ok! Agora o log deverá aparecer no console sem problemas.

PS: Só para ressaltar que essa dica é válida para ambiente de desenvolvimento.

Usando JSP, um novo leque de opções passou a existir e uma dessas opções passou a ser a possibilidade de usar Ajax. Ajax, para quem nunca ouviu falar, não é uma linguagem, uma API, tão pouco um framework, Ajax é o acrônimo de Asynchronous Javascript And XML e nada mais é que um conjunto de técnicas usadas para criar aplicações web interativas (RIA). Um dos pilares do Ajax é permitir comunicação assíncrona entre cliente e servidor utilizando requisições HTTP.

O Oracle BPM oferece uma maneira bem interessante de usar Ajax nas páginas JSP, mesmo não sendo nativa e também não tendo nada a respeito dizendo na documentação, é possível fazer a integração da camada de apresentação de um processo BPM com o próprio processo de uma maneira bem tranquila.

Para exemplificar isso melhor, criei um projeto bem simples no Oracle BPM, que na verdade só serve para mostrar como funciona essa integração entre páginas JSP e métodos dentro de um BPM Object através de Ajax.

Primeiros passos

Para começar, criei um BPM Object bem simples, que possui 3 atributos: name (String), mail (String), documents (String[]). Os dois primeiros atributos, que representam o nome e o email de alguém, são do tipo String e o terceiro atributo, que no caso representa os documentos de uma pessoa, é do tipo Array de String. Chamei esse objeto de: BpmObject.

Nesse mesmo objeto (BpmObject), criei ainda um método, esse método será responsável por retornar os documentos de um usuário. Na verdade esse é o método que irei chamar via requisição Ajax através de uma página JSP. O nome desse método ficou definido como getDocuments().

No futuro precisarei alterar esse objeto, mas eu explico depois.

Criando a página JSP

No Oracle BPM, para informar que a apresentação de determinado BPM Object deva se dar por meio de uma página JSP, se faz por necessário a utilização de Screenflows. Screenflow é um fluxo semelhante ao de um processo normal, mas a principal diferença é que o mesmo é executado por um participante único, ou seja, dentro de um Screenflow não existem lanes.

Após ter criado um processo normal, apenas com uma atividade do tipo Global Creation (para criar uma instância do processo) e também com uma Interactive Activity (para apontar para o Screenflow), parti para criação do Screenflow de fato. O Screenflow em questão, será tão simples quanto o processo no qual ele está associado, no caso contará apenas com uma única atividade do tipo Interactive Component Call, que será a responsável por “chamar” uma página JSP associando-a ao BPM Object criado no passo anterior.

Para chamar uma página JSP, se faz por necessária associar um BPM Object a mesma, então nesse caso criei um váriavel de instância do tipo BpmObject (o mesmo criado no primeiro passo) e dei o seu nome de bpmObject. Após isso, criei uma página JSP dentro de: /projetoBPM/webRoot/customJSP/ajaxPage.jsp.

O nome da página em questão é ajaxPage.jsp, e por enquanto ela irá possuir o seguinte código:

<%@ page session="true"%>
<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c"%>
<%@ taglib uri="http://fuego.com/jsp/ftl" prefix="f"%>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>Teste Ajax/title>        
        <script type="text/javascript" src="<f:webResources relativePath='js/prototype-1.6.0.3.js'/>"></script>
    </head>
    <body leftmargin="0" topmargin="0">
 
    Teste Ajax
    <br/><br/>
    Nome: <c:out value="${bpmObject.nome}" /> 
    <br/><br/>
 
    <div id="teste"></div>
 
    </body>
 
</html>

Então, relembrando os passos até aqui:

1) Criação de BPM Object com 3 atributos e um método;
2) Criação de processo com uma atividade do tipo Global Creation e outra do tipo Interactive Activity;
3) Criação de Screenflow;
4) Associação (Implementation Type) da Interactive Activity do processo ao Screenflow criado;
5) Criação de atividade do tipo Interactive Component Call no Screenflow;
6) Criação de váriavel de instância no Screenflow com o tipo sendo o mesmo do BPM Object que foi criado no primeiro passo;
7) Definição do Implementation Type da Interactive Component Call como BPM Object Interactive Call;
8) Associação do BPM Object criado como váriavel de instância da Interactive Component Call do Screenflow;
9) Definição da página ajaxPage.jsp como JSP Presentation da Interactive Component Call do Screenflow.

Feito os passos acima, a estrutura do processo está pronta para criação da página JSP que irá fazer a requisição via Ajax a um método do BPM Object que foi criado no primeiro passo.

Fazendo a requisição Ajax e explicando alguns components da taglib do Oracle BPM

Para criação do mecanismo que irá fazer a requisição Ajax, se faz por necessário a utilização da taglib do Oracle BPM, sem ela não seria possível usar Ajax, ou então seria bastante árduo fazer tal integração.

Por exemplo, para incluir a biblioteca Prototype, que no caso será a responsável por fazer o “trabalho sujo” e criar o objeto XMLHttpRequest para fazer a requisição assíncrona, utilizei a tag f:webResources (linha 10). Esta tag inclui os resources inclusos no projeto BPM, sem que seja necessário informar explicitamente o context path da aplicação para inclusão de imagens, CSS ou Javascripts.

Outra tag importante é a f:invokeUrl, que no caso irá gerar a URL para execução de um método dentro de um BPM Object. Dessa forma, a página JSP precisa ser alterada, pois agora irá contar com uma função Javascript que irá fazer a chamada via Ajax ao método getDocuments() do BPM Object criado no primeiro passo, retornando o output do método para div teste.

Página JSP alterada:

<%@ page session="true"%>
<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c"%>
<%@ taglib uri="http://fuego.com/jsp/ftl" prefix="f"%>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>Teste Ajax/title>        
        <script type="text/javascript" src="<f:webResources relativePath='js/prototype-1.6.0.3.js'/>"></script>
        <script>
        function callAjaxMethod () {
		var bpmUrl	='<f:invokeUrl var="bpmObject" methodName="getDocuments" />';		
		return bpmUrl;
	}        
 
	new Ajax.Updater('teste', callAjaxMethod());
        </script>
    </head>
    <body leftmargin="0" topmargin="0">
 
    Teste Ajax
    <br/><br/>
    Nome: <c:out value="${bpmObject.nome}" /> 
    <br/><br/>
 
    <div id="teste"></div>
 
    </body>
 
</html>

Repare que foi criada a função JS callAjaxMethod. Abaixo dessa função existe ainda a função JS Ajax.Updater, que no caso é uma função da biblioteca Prototype que irá fazer a chamada ao método do BPM Object, retornando seu output para a div teste.

Criando um output para o método getDocuments do BPM Object

Finalmente essa é a última parte desse pequeno tutorial. Agora a única coisa que falta é criar um output para o método do BPM Object que irá ser chamado via requisição Ajax.

Antes de mais nada, preciso dizer algo a respeito da tag f:invokeUrl, pois para ela funcionar corretamente existem algumas peculiariades.

Para um método de um BPM Object ser reconhecido por esta tag, ele deve ter uma das quatro assinaturas abaixo:

• methodName(Fuego.Net.HttpRequest request, Fuego.Net.HttpResponse response)
• methodName(java.util.Map requestParameters, java.util.Map requestHeaders)
• methodName(java.util.Map requestParameters)
• methodName()

No caso, eu optei por utilizar a primeira opção, pois para usar a função Ajax.Updater da Prototype, eu preciso escrever diretamente no output do método, ao invés de setar as informações necessárias através dos seus atributos.

Em virtude disso, o método getDocuments do objeto BpmObject agora passará a ter a seguinte assinatura:

getDocuments(Fuego.Net.HttpRequest request, Fuego.Net.HttpResponse response)

Agora, finalmente o código do método getDocuments, que ficará da seguinte maneira:

for (String doc : documents) {
    response.bodyTextContent(arg1 : doc);
}

No código acima, estou percorrendo o atributo documents (array) e imprimindo no output todos os documentos definidos para aquele atributo, dessa forma, quando a função callAjaxMethod é chamada na página JSP, ela automaticamente chama (assincronamente) este método contido dentro do BPM Object, imprimindo todos os documentos definidos para dentro da div com o ID teste.

Conclusão

Utilizando os recursos corretos do Oracle BPM, como sua taglib e seus componentes, não é muito difícil fazer uma tela de apresentação mais interativa usando Ajax. No exemplo acima, foi criado um projeto bem simples, apenas para ilustrar, com o intuito de mostrar a atualização do conteúdo de uma div feita assincronamente através de uma requisição Ajax.

Linguagens de programação tendem a ser parecidas com religião ou com times de futebol, a pessoa simplesmente escolhe uma e defende aquilo com todas as forças, geralmente de forma cega. Eu particularmente acredito que, para defender ou criticar algo, se faz por necessário conhecer profundamente aquilo que você defende ou critica, pois só assim você terá argumentos para apontar falhas ou reconhecer méritos. Sou, ainda, a favor da filosofia “cabeça aberta”, que em poucas palavras quer dizer: não tenha medo, muito menos preconceito, de conhecer algo novo, conheça para a partir disso você ter uma opinião formada se aquilo te agrada, ou não.

É comum acontecer em fóruns e em listas de discussão debates sobre “qual linguagem é melhor”, na maioria das vezes as pessoas atacam uma linguagem, ou defendem outra, simplesmente baseadas em sua opinião pessoal, ou melhor, baseados na falta de conhecimento. As pessoas não conseguem enxergar que todas têm seus prós e contras, como tudo na vida, e que a partir de uma situação real que é possível avaliar a melhor opção.

Eu comecei a programar através do PHP e hoje em dia trabalho basicamente só com Java. Programadores Java tendem a achar PHP um lixo, na maioria das vezes com embasamentos e teorias totalmente furadas, que demonstram tremenda falta de conhecimento. Eu concordo que o PHP tem uma má fama devido a linguagem ter demorado a amadurecer, como também concordo que o nível dos programadores em PHP no geral é baixo, é duro admitir, mas no geral é assim, provavelmente pela facilidade que a linguagem proporciona e também por sua curva de aprendizado ser bem mais baixa que a do Java, por exemplo. Mas isso quer dizer que o PHP é ruim? Eu poderia enumerar uma série de vantagens que o PHP tem em relação ao Java, da mesma forma que o Java tem uma série de outras vantagens em relação ao PHP, mas esse não é o foco do tópico, o foco é justamente o contrário.

Uma “nova” era

E para acabar, ou pelo menos ajudar bastante, surge o famoso framework Ruby on Rails, o hype do momento tratando-se de linguagem de programação! Ruby on Rails é um framework de desenvolvimento web que prega o conceito de que algo deve ser simples, prático e prazeroso de fazer, dessa forma inúmeros benefícios são alcançados, como: códigos com mais qualidade, tempo de desenvolvimento mais curto e comunidade participativa. Ruby on Rails não é uma linguagem de programação, é um framework, que foi desenvolvido em cima da linguagem Ruby, que é uma linguagem de programação criada por um japonês em 1995 baseada nos pontos fortes de várias linguagens da época. Reparou no trecho “…que havia de melhor em outras linguagens…”? Ou seja, o próprio criador da linguagem era (ou é) totalmente desprovido de preconceitos, e com isso conseguiu identificar os pontos fortes e fracos de várias linguagens com o intuito de criar uma, que no seu modo de ver, seria mais eficiente.

Complexidade não é sinal de qualidade

Uma linguagem de programação, um framework ou uma API, tem como principal objetivo (pelo menos deveria) fornecer uma maior praticidade aos desenvolvedores em solucionar problemas. Essa deveria ser a premissa básica para que uma determinada linguagem ou plataforma fosse adotada em um projeto, entretanto nada impede que N linguagens ou plataformas trabalhem de forma conjunta, desde que proporcionem alternativas para descomplicar o problema.

Só para esclarecer: simplicidade, praticidade, produtividade e facilidade nesse caso são sinônimos!

Outro ponto a ser observado é que a engenharia de software é um assunto relativamente novo, principalmente se formos comparar as outras engenharias, como a civil, e por isso é tão comum observarmos novas metodologias, padrões e linguagens surgindo a todo momento. Mas o que elas tem em comum é que todas tem como objetivo resolver os problemas da maneira “menos complexa” que for possível, é claro que outros fatores são levados em consideração, entretanto se paramos para pensar a simplicidade é sempre a prioridade.

E é por isso que o RoR está na crista da onda, pois talvez nenhum framework descomplique tanto as coisas como ele, e o melhor é que isso é contagioso, pois a todo momento surgem mais e mais frameworks “RoR like“, em PHP existe uma penca deles, como: Akelos, Code Igniter, Cake, Kohana. Até o sempre conservador Java se rendeu ao RoR e lançou o Groovy (JSR 241) e consequentemente o Grails, que é um framework web baseado em quem? No Rails!

Maçãs são maçãs e bananas são bananas!

O título acima parece estranho, mas ele serve para deixar claro o seguinte: comparar linguagens não é algo inteligente, ao invés disso, procure conhecê-las e tirar proveito do melhor de cada uma. PHP é PHP, Java é Java, Python é Python! Assim como maçãs são maçãs e bananas são bananas, portanto não cabem comparações. Parece óbvio, e na verdade é, mas mesmo assim existem pessoas que ainda insistem em levar essa discussão adiante, onde dificilmente é tirado algum proveito.

Só para deixar claro, eu nunca desenvolvi uma aplicação sequer usando o RoR, já usei alguns frameworks “RoR like” e tive ótimas experiências, entretanto não acho que o RoR substitui o Java, o PHP, ou até mesmo o .NET, como eu já disse, cada um tem o seu propósito e por isso deve haver um equilíbrio na tomada de decisões sobre “o que escolher?”, fatores como: experiência com determinada linguagem, documentação, maturidade, infra-estrutura, segurança não podem ser esquecidos de forma alguma, pois no final é a sinergia entre vários fatores que determina as opções a serem escolhidas.

É normal, e de certa forma até compreensível, nos deixarmos levar pela emoção de conhecer um novo mundo e com isso embarcamos no erro de que a partir daquele momento tudo será feito “daquela forma”, com “aquela nova linguagem”, e isso é um erro, dos graves! Nesse ponto, a experiência, o conhecimento e o equilíbrio fazem toda a diferença na tomada de decisão mais acertada.

Só para finalizar, gostaria de ressaltar que nada impede que existam linguagens e frameworks ruins, é claro que eles existem, mas mais uma vez, para termos essa certeza é preciso conhecer. Da mesma forma que, não é só porque devemos abrir a nossa cabeça e olharmos para os lados, ao invés de olharmos só para frente, que devemos deixar de considerar nossas preferências e aquilo com que temos mais facilidade. Preferência e preconceito não são sinônimos.

Como podem perceber, atualizei esse Blog recentemente, pois estava a procura de uma interface mais clean e ampla, além de querer dar uma ênfase maior a busca.

Durante a atualização desse Blog, utilizei um recurso muito interessante e simples, que é o famoso arquivo .htaccess ou hypertext access. Esse arquivo é um arquivo do Apache que permite a descentralização do controle de um diretório Web pelo Apache. Os arquivos .htaccess permitem reescrever URL’s, definir autenticações para um diretório, customizar mensagens de erro, ter controle sobre mecanismos de cache e etc.

Através desse arquivo eu criei uma regra para que todos os usuários que acessassem o meu Blog visualizassem uma página de manutenção, com exceção ao meu IP, pois eu deveria ver todo o site normalmente já que precisaria ajustá-lo e configurá-lo.

A regra é bem simples, segue abaixo:

Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REQUEST_URI} !/manutencao.html$
RewriteCond %{REMOTE_ADDR} !^200\.239\.200\.121$
 
RewriteRule $ /manutencao.html [R=302,L] 

Na configuração acima existe a opção de definir o IP (200.239.200.121) que deverá ser excluído da regra e a regra nada mais é que um redirecionamento para uma página específica de manutenção do site (manutencao.html).

Simples, porém útil.

Para mais informações sobre o .htaccess indico acessar a sua documentação oficial.

O que ocorre é que muito provavelmente o Flash não usa o PulseAudio, e com isso acaba travando o som do sistema até que o Firefox seja fechado. Nenhum outro programa consegue tocar som até que o Firefox seja fechado.

Para resolver isso é muito simples, basta baixar o pacote libflashsupport que força o Flash a usar o sistema PulseAudio. É possível baixar usando o Synaptic, ou então por linha de comando da seguinte maneira:

sudo apt-get install libflashsupport

Feito o passo acima, basta reiniciar o Firefox e o problema estará resolvido.

Obs: A minha versão do Ubuntu é a 8.04 (Hardy Heron), mas pesquisando no Google observei pessoas que utilizam versões anteriores com o mesmo problema. Não sei, se dá versão 8.10 em diante o problema foi resolvido.

Há cerca de 1 ano e meio, talvez um pouco mais, resolvi ceder a pressão e dar uma chance ao Pinguim, mas fiz isso usando dual boot. Por experiência própria, afirmo com convicção, que quem acaba optando por essa tática de transição, quase sempre acaba ficando com Windows, o negócio tem que ser na marra mesmo hehehe. O mesmo serve para máquinas virtuais, se você tiver como SO base o Windows e instalar em uma VM uma distribuição Linux, fatalmente você cairá no mesmo problema.

Não sou daqueles que ficam malhando o Windows/Microsoft a torto e a direito, acho que a dupla tem os seus méritos, que por sinal são muitos, mas tratando-se de liberdade, flexibilidade e segurança, fica muito difícil comparar um SO baseado em Unix, como o Linux e o Mac OS X, com o Windows. Sem contar que hoje em dia, algumas distribuições como o Ubuntu, por exemplo, estão quase tão fáceis de usar como o Windows.

Uma das coisas mais fantásticas dos sistemas operacionais baseados em Unix são sua linha de comando poderosíssima, pois através dela é possível fazer N operações com velocidade, flexibilidade, alcançe e combinando-as. A linha de comando de um SO baseado em Unix é, por exemplo, muito mais avançada que a linha de comando do Windows (MS-DOS), que sinceramente é muito fraca.

Se você é usuário Windows, não quer instalar o Linux em uma VM e não quer deixar o seu computador dual boot, então ainda existe uma alternativa derradeira: é o Cygwin. Cygwin é um programinha que você instala como outro qualquer no Windows e que te proporciona todo o poder da linha de comando, inclusive já o usei em uma das minhas várias tentativas de transição “windows->linux”.

Separei uma coleção de comandos úteis, que me ajudam bastante nas tarefas do meu dia-a-dia, seja como desenvolvedor ou também como usuário, se alguém quiser contribuir com essa listinha, está convidado :)

Vamos lá:

Permissão (de tudo) a partir de um diretório recursivamente (forçada)

$ chmod -Rf 7777 /diretorio

Mostra/controla as network interfaces (conexões wireless e com fio, por exemplo)

$ ifconfig

Alterar o owner e o grupo de usuário de um arquivo

$ chown user:group arquivo.txt

Criação de Link Simbólico (se você não sabe o que é, clique aqui, é muito útil!)

$ ln -s /diretorio/que/sera/criado/o/link /diretorio/de/destino

Remover todos os arquivos com determinada extensão a partir do diretório atual recursivamente

$ find ./ -name ".svn" | xargs rm -Rf

Alterar encoding de arquivo de ISO-8859-1 para UTF-8

$ iconv -f ISO-8859-1 -t UTF-8 nome_arquivo_original.php > nome_arquivo_alterado.php

Listar periféricos (hardware)

$ lspci

Listar periféricos USB

$ lsusb

Verificar se determinada porta (8685) está aberta

$ netstat -an | grep "8685"

Redirecionar porta. Nesse caso redireciona da 80 para 7001, se a porta não estiver aberta, o comando abre

$ redir --lport=80 --cport=7001 &

Procurar por nome de arquivo a partir do diretório atual recursivamente

$ find ./ -name nome_do_arquivo

Procurar por diretório recursivamente a partir do atual

$ find . -type d -name diretorio

Procurar por conteúdo (texto) dentro do arquivo, recursivamente, a partir do diretorio especificado mostrando apenas o nome dos arquivos onde foram encontrados o texto buscado (case-insensitive)

$ find /diretorio -exec grep -il "TEXTO" {} ;

Procurar por conteúdo (texto) dentro de arquivos apenas com a extensão “.log” (case-insensitive), recursivamente, a partir do diretório especificado, mostrando o nome dos arquivos que foram encontrados o texto buscado

$ find /directory -iname "*.log" -exec grep -il "TEXTO" {} ;

Informar onde estão os arquivos binários de um programa

$ whereis php

Incluir um caminho (path) no path do SO

$ export PATH=$PATH:/opt/lampp/bin

Listar os processos correntes do SO

$ ps aux

Listar os processos correntes do SO filtrando por determinada string

$ ps aux | grep "apache"

Encerrar (cancela) um processo ou grupo de processo a partir do seu ID (pid), nesse caso “78452″

$ kill -9 78452

Copiar por SSH um arquivo de uma máquina remota para a máquina local

$ scp user@192.168.1.100:/home/usuario_remoto/Desktop/file.txt /home/meu_usuario/Desktop/file.txt

Mostrar as últimas linhas de um arquivo (atualizado dinamicamente conforme um novo conteúdo é inserido)

$ tail -f nome_do_arquivo.log

Lembrando que alguns dos comandos acima, para serem executados, necessitam de privilégios de um super-usuário, como o usuário root por exemplo.

Existem ainda uma infinidade de outros comandos úteis, mas que eu tenha lembrado, os que mais uso são esses. Os comandos mais básicos e simples, como: man, wget, ls, cd, cp, cat, rm, mv, etc.. não vou mostrar, pois não tem muito mistério, mas no Google é possível encontrar milhares de boas referências.

Hope this helps!

Há cerca de um mês atrás eu havia falado sobre isso, lembra? Resumidamente o que eu havia dito é que apesar de saber que a versão no cliente ainda era a 6.04, eu havia tomado a decisão de usar a versão nova do Oracle BPM Studio, pois em relação a ferramenta pouca coisa havia mudado e o que havia mudado não impactaria no arquivo gerado a ser deployado nas distribuições enterprise. Inclusive o pessoal da Oracle havia me confirmado isso em um workshop que eu havia ido.

Como o cluster lá do meu trabalho onde está (estava) rodando a versão 6.04 da distribuição enterprise estava muito instável, resolvi fazer a instalação em outra máquina. Foi aí que começou a minha própria Via Crucis. Um detalhe importante é que eu nunca havia feito a instalação da distribuição enterprise, portanto era uma experiência totalmente nova para mim.

A distribuição enterprise do ALBPM possui alguns conceitos um pouco diferentes da versão usada para desenvolvimento (Studio), a começar pelo conceito de directory service e pelas outras aplicações que vem agregadas juntas a instalação. Dentre as aplicações que me interessavam estavam apenas o process administrator, workspace e process engine. Tinha ainda o PAPI Web Services, que pode ser muito importante dentro de um projeto BPM, mas como eu não precisaria integrar outros projetos com o meu projeto BPM, então o PAPI-WS nesse caso não seria necessário, pelo menos não naquele directory service atual. Directory Service é onde ficam guardadas as informações referentes a usuários, roles, grupos, resources externos e outras informações que fazem parte de um projeto no BPM, além também dessas aplicações já citadas. Não necessariamente cada projeto deve ter o seu próprio directory service, na verdade N projetos podem compartilhar o mesmo. Outro ponto importante diz respeito a process execution engine, pois cada directory service possui a sua própria engine, ou até mesmo mais de uma, mas apenas uma engine cadastrada pode estar “rodando”. Uma engine está associada a um servidor de aplicações e no meu caso está associada a uma instância do weblogic, pois foi essa a versão que eu havia escolhido no ato do download.

Sinceramente, apesar de já ter escutado comentários de que a distribuição enterprise (<= 6.*) era um pouco irregular e que possuia algumas peculiaridades, eu não sabia que seria tão árdua a sua instalação. O primeiro problema que eu encontrei foi na criação de um directory service, nesse ponto, através de uma tela do tipo wizard, a instalação solicita as informações do banco de dados onde serão gravadas as informações do directory service, no meu caso eu escolhi como banco de dados o Oracle (Oracle-XE). Nessa mesma tela, a configuração solicita qual o nome do Schema onde serão criadas as tabelas e eu aconselho fortemente deixar essa opção em branco, pois além dela ser opcional, o negócio só funcionou depois que eu a deixei em branco. Em uma das minhas tentativas mal sucedidas eu até havia criado o schema “na mão”, mas mesmo assim não funcionou. Primeiro problema resolvido, nome dos schemas deixados em branco e tudo ok.

O segundo problema talvez tenha sido o pior de resolver. Depois de informar todos os dados necessários para a configuração viria a tela de progresso e conclusão da criação do directory service, nesse momento só resta aguardar até que a ferramenta termine o processo de criação. Mas para o meu azar o processo nunca conseguia ser concluído, pois sempre antes de chegar em 100% o processo me mostrava a mensagem: failed! Tentei mais algumas vezes e após tantos insucessos resolvi verificar os logs e ver qual era o erro. O log nesse caso ajudou e não ajudou, pois no log a informação principal do erro é que uma exceção havia sido disparada quando o JAR de algum EJB estava tentando ser gerado pela instalação. Pesquisei, pesquisei, pesquisei e nada… resolvi então falar com um amigo de trabalho que tinha comentado que a instalação da distribuição enterprise era meio caótica. Ele pediu para eu ver o stack-trace todo da exceção. Após reparar bem o stack-trace percebi que o mesmo continha uma frase que terminava com “too many open files” e informei sobre a mensagem para esse amigo, ele então me disse que esse problema não tinha relação com o JAR do EJB, na verdade o problema estava ocorrendo, pois o SO (Ubuntu) estava tentando abrir mais de 1024 arquivos ao mesmo tempo durante a instalação e que eu precisaria mudar algumas configurações padrões do SO (file descriptor) para resolver esse problema, isso no caso seria um OS tuning. Mudanças feitas e não deu outra: o diretório foi criado com sucesso!

O próximo problema ocorria ao tentar startar a process execution engine. Sempre que eu tentava inicializar a engine a mensagem de status nunca se modificava, não informava nem que estava inicializada e nem que estava parada. Após bater bastante cabeça com isso, fui até o manual de instalação e verifiquei que um dos pré-requisitos era que a versão do Weblogic fosse a 9.2 e no meu caso eu estava usando a 10.0 ou 10.3. Na verdade esse problema ocorreu mais em razão de um vacilo meu do que qualquer outra coisa. Instalei a versão 9.2, criei outro diretório novamente e agora eu conseguia startar a engine sem problemas.

Acho que tive também alguns problemas de versão de JVM, no caso JRockit, mas isso foi tranquilo de resolver, porque o erro era bem evidente.

Instalação concluída, fui tentar finalmente fazer o deploy de um projeto e… mais problemas! Fazer o deploy eu até conseguia, mas ao tentar executar os processos um erro estranho ocorria e verificando o log percebi que alguns arquivos do projeto não estavam sendo encontrados. Para mim nada poderia explicar aquilo a não ser problemas de versão, pois como eu já citei, a versão de desenvolvimento que eu estava usando era diferente da versão da distribuição enterprise. Resolvi então tentar abrir o projeto em uma versão de ambiente de desenvolvimento igual a da distribuição enterprise com o intuito de gerar o arquivo a ser deployado em versões iguais. Ao abrir o projeto em uma versão mais antiga não tive nenhum problema, o ALBPM Studio conseguiu detectar todos os processos, screenflows, resources e etc, mas ao tentar executar o processo comecei a ter alguns problemas. Após alguns debugs, percebi que alguns métodos da API de Java (Component Catalog) simplesmente não existiam, ou, não funcionavam nessa versão mais antiga (ALBPM Studio 6.04) e que provavelmente esse poderia ser o mesmo problema que ocorria na distribuição enterprise. Isso de certa forma fazia com que a minha teoria de que não haviam mudanças consideráveis entre as versões ALBPM e OracleBPM caísse por terra.

Fiz os ajustes no projeto na versão mais antiga da ferramenta, gerei um arquivo de deploy novo e fui novamente tentar rodar o projeto na distribuição enterprise. Mesmo problema! A essa hora minha paciência estava esvaindo-se, mas eu precisava conseguir deployar o projeto de qualquer jeito. Resolvi, só por desencargo de consciência, baixar a distribuição enterprise em sua versão mais atual, no caso já como Oracle BPM Enterprise 10g3. Baixei, fiz a instalação – que por sinal foi muito mais tranquila – e tentei fazer o deploy do projeto e executá-lo. Para minha surpresa (ou não) foi de primeira! Consegui executar o projeto direitinho na versão nova da distribuição enterprise, o que me faz concluir que a versão 6.04 (ou <) é realmente problemática ou então o impacto entre versões Oracle (Oracle BPM) x BEA (Aqualogic BPM) é realmente considerável.

Dicas Finais

• Caso use a distribuição enterprise na versão 6 (ou <) use o Weblogic 9.2 e não 10.0 (ou >);
• Não esqueça de mudar as configurações (file descriptor) do seu SO para permitir que ele consiga abrir mais de 1024 arquivos simultaneamente;
• Na criação de um directory service, deixei que a ferramente crie um schema para você no banco de dados, portanto deixe a opção em branco;
• Verificar possíveis incompatibilidades entre versões de JVM;
• É necessário sempre inicializar a instância do Weblogic antes de inicializar o Admin Center do BPM;
• Caso não consiga startar a sua engine e tudo pareça estar correto, tente acessar o console do weblogic e dar unlock no usuário FuegoWeblogicDeployer, pois quando uma engine tenta ser inicializada várias vezes e não consegue, esse usuário fica travado;
• Caso algum erro ocorra no Process Administrator ou então no Workspace, tente ver o código fonte da página HTML, pois em muitas vezes o erro (detalhado) fica oculto dentro de comentários.

No final rolou uma rodada de perguntas, onde foram questionados assuntos como BDD, programação defensiva, contract by domain, dentre outras metodologias e padrões. Nesse ponto da apresentação, a maioria das pessoas que estavam presentes ficaram meio perdidas com as milhares de buzzwords associadas com as perguntas que foram feitas. O pessoal mais antigo ficou mais perdido ainda e até brincaram sobre a questão do “estamos ficando velho”.

Paralelamente a isso, começei a ler essa semana um livro do Tadeu Cruz sobre BPM e BPMS, onde no primeiro capítulo ele fala sobre a questão da desorganização informacional, muitas vezes causadas pelo excesso de informação e as novas ondas de TI que surgem a todo momento. Outra coisa que o autor do livro cita e crítica é que existem muitos casos de determinadas organizações, que forçam o uso de determinado software sem obter o real benenfício que esse software deveria oferecer, na maioria dos casos, por questões comerciais ou de interesse próprio dessas organizações. Questões como: para que determinada tecnologia foi criada, como deveria ser corretamente usada, como efetivamente está sendo usada, quais deveriam ser os resultados esperados do seu uso e quais são os resultados que estão sendo obtidos com sua utilização, orientariam de forma efetiva o profissional ou a organização com o intuito de medir se a adoção de determinada tecnologia está realmente sendo benéfica. Esse tipo de situação tem ocorrido muito com BPM, que é o novo hype do momento tratando-se de TI.

O que as duas histórias tem em comum e onde estou querendo chegar?

O que eu quero dizer é o seguinte: até onde vale apena conhecer N conceitos diferentes e até onde não vale a pena? Nos casos citados acima tem um pouco das duas coisas, bem como suas respostas. No caso específico do TDD, deveríamos considerar que o melhor a ser feito seria debater sobre as buzzwords que o assunto levantou, ou o melhor seria não conhecer muitos desses novos padrões e metodologias? Eu fico com a primeira opção, mas a segunda opção pode contradizer a primeira. Explico logo abaixo.

Vale a pena usar TDD e BDD em um projeto sem conhecer seus benefícios, o resultado a ser esperado e os possíveis obstáculos a serem vencidos? Não. Pois nesse caso tudo de positivo que TDD traria sendo usada da forma correta, traria inversamente em dobro no caso do seu mal uso, pois nesse caso o projeto acabaria tendo novos percalços (além dos já conhecidos), como: prazos atrasados, código mal estruturado, equipe perdida e etc. E isso acontece em larga escala em TI, não apenas no caso específico do TDD, já que o mais se vê são empresas gastando milhões em “soluções” de TI (CRM, ERP, BI, etc) – muitas vezes empurradas pelos ótimos vendedores dos grandes players do mercado – sem obter benefício algum sobre aquilo (ou até mesmo desconhecendo o porquê do seu uso). Na verdade muito pelo contrário, pois como muito desses processos são feitos sem estruturação alguma e demoram meses, anos… no final das contas a dor de cabeça e o custo envolvido não atingem nem de perto o custo x benefício esperado sobre aquele investimento.

Outro fênomeno interessante a ser observado e que de certa maneira ligam as duas histórias é a infobia. Infobia é uma palavra que o Tadeu Cruz usa para definir o medo por informação, ou seja, em determinado momento, com a enxurrada de tantas buzzwords, as pessoas acabam ficando reativas em absorver novas tecnologias e entender o seu significado, com isso de certa forma ficam estagnadas, pois deixam de absorver novos conhecimentos. Mas em compensação não adianta em nada conhecer várias palavrinhas mágicas superficialmente só para dizer que “domina” aquela tecnologia do momento. Por isso, acredito que dependendo do contexto, é válido ou não conhecer uma nova tecnologia. Esta aí mais um caso do paradoxo de TI. De certa forma, mas sem generalizar, a infobia consegue explicar a frase “estamos ficando velho”.

Devemos considerar que TI não irá salvar o mundo, TI pode ajudar de forma efetiva qualquer negócio de qualquer natureza, desde que seja aplicada da forma correta, e aplicar de forma correta envolve antes de mais nada: estruturação, disciplina, educação, mudança e planejamento. Ao mesmo tempo que sabemos de diversos casos onde TI trouxe um real benefício as organizações, sabemos de tantos outros onde TI acabou com negócios, projetos e sonhos. A bolha da internet talvez seja o melhor exemplo que ilustra essa situação das ondas de TI.

Muitas vezes as ondas de TI trazem a tona novas tecnologias que surgem apenas com o objetivo de remediar uma tecnologia já existente. O que as vezes é considerado como inovação, nada mais é que uma evolução de algo que tenha tido insucesso no passado, dessa forma uma tecnologia X surge apenas com o intuito de servir como “curativo” da tecnologia Y, que prometeu maravilhas e na verdade devido ao seu mal uso (ou não) só trouxe dores de cabeça.

Em busca de alternativas, achei três serviços interessantes. Um muito semelhante ao assembla, mas com um poucos menos de funcionalidades, outro bem mais simples e um que não cheguei a usar, só vi alguns usuários indicando em algum fórum open-source.

Vamos aos serviços:

Unfuddle
Serviço semelhante ao assembla, contudo com menos funcionalidades. Mesmo assim ele possui alguns recursos interessantes como: número infinito de repositórios, tickets e um dashboard bem interessante, apesar de simples. O único porém desse serviço é que na versão free só é possível ter um projeto por vez, mas ainda assim é possível criar N repositórios sem necessariamente ter que associá-los a um projeto.

OpenSVN
Esse é bem mais simples, a idéia é só fornecer um repositório SVN mesmo, onde no caso não contém os recursos do serviço citado acima. Como se propõe em ser só um serviço de SVN, funciona muito bem.

Berlios
Não cheguei a usar, mas oferece além de repositórios SVN, repositórios CVS, GIT, Mercurial. Possui outros recursos como gerenciador de tarefas, calendário, forums e gerenciador de arquivos.

Project Locker
Repositório para até 5 usuários com 500mb de espaço

Outras Alternativas

Existem ainda outras alternativas, algumas possuem restrições como: expor o código para qualquer usuário, ser específico para uma plataforma ou ser comercial. Alguns eu realmente não cheguei a usar, por isso coloquei como “outras alternativas”.

Google Code
Como é um serviço Google, dispensa comentários, sua única limitação, se é que isso pode ser chamado de limitação, é que qualquer projeto está automaticamente aberto para qualquer um, ou seja, qualquer um pode fazer um svn checkout. Como a proposta do serviço é ser um host de projetos open-source, então nada mais justo.

SourceForge
Talvez esse seja o mais antigo dos serviços de hospedagem de código. Serviço confiável, estável e talvez seu único “problema” é o mesmo do Google Code (citado acima).

Beanstalk
Possui uma versão free, mas não sei maiores detalhes, seu foco é comercial. Dentre as suas principais características está o fato de tudo ser feito por interface gráfica (web) e possuir integração com outros serviços.

DevjaVu
Além de repositórios de controle de versão, possui também outras ferramentas de gerenciamento.

CodePlex
Hosting de projetos open-source da Microsoft.

XP-Dev
Repositório SVN de até 1.5gb free e também com project tracking.

Assembla
Talvez a ferramenta mais completa de todas, era totalmente free até o começo de fevereiro. Agora cobra uma taxa por projeto e por participante associado.

Após incluir a prototype e testar a página, percebi que um erro de JavaScript estava ocorrendo, no começo achei que a causa do erro era em razão de uma função – usando a prototype – que eu tinha acabado de fazer, mas depois usando o bem dito firebug e fazendo alguns debugs, percebi que o erro era mesmo em um conflito entre a jQuery e a prototype.

O problema ocorre, pois as duas bibliotecas fazem o uso da função “$()” para acessar as suas funções, o que acaba gerando o conflito.

A biblioteca jQuery fornece algumas maneiras de resolver isso, mas todas giram em torno da função jQuery.noConflict(). A solução que oferece o maior custo x benefício na minha opinião, é a que eu não preciso alterar os meus métodos já existentes, ou seja, não precisaria ter que fazer isso:

var $j = jQuery.noConflict();
$j("div").hide();

No caso acima, se eu já tivesse N funções usando jQuery, eu precisaria fazer uma refatoração do meu código para mudar o método “chamador” das minhas funções de $() para $j(), isso geraria algum tempo perdido com muitas mudanças e muitos testes. A solução que encontrei pede apenas para que as funções fiquem dentro da document ready area da jQuery, então ficaria mais ou menos assim:

<script src="prototype.js"></script>
   <script src="jquery.js"></script>
   <script>
     jQuery.noConflict();
 
     // Put all your code in your document ready area
     jQuery(document).ready(function($){
       // Do jQuery stuff using $
       $("div").hide();
     });
 
     // Use Prototype with $(...), etc.
     $('someid').hide();
 </script>

Da maneira acima eu não precisaria mudar nenhuma função já existente, bastaria apenas incluí-las dentro do bloco indicado.

Segundo a documentação, essa seria a solução mais adequada na maioria dos casos.

No primeiro momento fiquei meio ressabiado, pois como ele é usuário de Windows, fiquei temoroso de não existir uma versão para Linux, ledo engano… além de existir versões para Linux, existem versões específicas para Ubuntu e ainda por cima para distribuições 64 bits! Existem ainda versões para usuários de Mac. Fantástico!

Resolvi testar o serviço de nome Dropbox. Após baixar a versão para Ubuntu 8.04 x86_64, apenas precisei reiniciar o nautilus com o comando “sudo killall nautilus” e finalmente testar.

Na primeira vez que o programa é iniciado ele pergunta se você já possui uma conta no serviço, caso não possua, através da própria interface de instalação ele dá todo suporte para criação de uma nova conta, após a conta ter sido criada o próximo passo é definir onde ficará o diretório no seu computador que será responsável pelo backup/sincronização dos arquivos. Deixei o padrão do Dropbox, onde nesse caso é criado um diretório em “/home/$user/Dropbox“, a partir disso, qualquer arquivo ou diretório que estiver dentro de “/home/$user/Dropbox” terá automaticamente um backup feito no caso de um arquivo novo, ou a sincronização realizada em caso de um arquivo já existente e modificado. Muito fácil!

Como ele se integra com o Nautilus, ao clicar com o botão direito sobre qualquer arquivo ou diretório, automaticamente aparece uma nova opção com opções do Dropbox.

Pulo do Gato

Para quem é desenvolvedor, sabe que fica complicado ficar movendo um diretório para dentro de outro. Por dois motivos: o primeiro é que fica muito trabalhoso mover qualquer alteração para um novo diretório e o segundo é que o contexto da aplicação e o apontamento para endereços físicos dos arquivos de configuração deixam de funcionar. Para resolver isso resolvi fazer um teste, o que eu fiz foi criar um diretório fora do meu diretório /Dropbox e criar um link simbólico desse diretório apontando para /Dropbox. O negócio simplesmente funcionou! Genial! Agora posso apontar os meus diretórios de “origem” para dentro do /Dropbox sem precisar movê-los.

Parte Ruim

Como nem tudo são flores, a parte ruim é que o o Dropbox é free até 2gb de uso, após isso custa cerca de 10 dólares por mês ou 99 dólares por ano. Mas ainda assim acho que vale muito, nós brasileiros não temos hábito de pagar por serviços online, mas esquecemos que tudo tem um custo. No caso do Dropbox eu imagino que o custo para manter sua estrutura seja caro.

Outras features interessantes

Compartilhamento – É possível compartilhar um diretório entre N contas de usuário. Digamos que eu tenha um diretório /musicas, então outro amigo meu pode ter acesso a esse mesmo diretório e ainda mais: se tanto eu quanto ele atualizarmos esse diretório, os dois conseguem visualizar as atualizações.

Interface Web – O Dropbox possui uma interface web onde é possível acompanhar todos os arquivos já indexados, bem como os últimos arquivos modificados e download dos mesmos.

Revisões – É possível ter um histórico de revisões de um arquivo, ou seja, todas as alterações que aquele arquivo sofreu, bem parecido com controles de versão.

Resumo

Não conhecia o serviço, mas após usar por alguns minutos o indico fortemente, ainda não tenho reclamações a fazer, até mesmo porque ainda não subi uma grande quantidade de arquivos, mas se eu tiver novidades, tanto positivas quanto negativas, volto a atualizar esse espaço.

Na parte de apresentação no BPM existem duas opções: presentations e JSP. Em ambos os casos é necessário sempre utilizar um BPM Object para fazer a representação dos dados. Um BPM Object é puramente um objeto e com isso contém atributos e métodos específicos.

No meu caso, tenho trabalhado com JSP para a camada de visualização, já que preciso ir um pouco além do que simplesmente exibir dados. As telas do meu processo precisam um alto nível de customização e também possuem bastantes regras de validação e fluxo no lado do cliente usando Java Script. É também comum no meu processo a utilização de serviços externos, e com isso se faz por necessário apresentar os dados retornados por esses serviços nas minhas páginas JSP. Conforme dito anteriormente, para mostrar esses dados preciso de um BPM Object e para não criar um BPM Object redudante, ou seja, um BPM Object com a estrutura idêntica do XML Object – que já está cadastrado no meu projeto – o que eu fiz foi criar um atributo nesse BPM Object que encapsula um XML Object, dessa forma poderia usar os atributos do XML Object como atributos dentro do meu BPM Object. Algo como um atributo do tipo de uma lista genérica em um objeto java.

Mas qual foi a minha surpresa ao iterar sobre esse atributo do tipo XML Object no meu JSP? Simplesmente não funciona, ou melhor, funciona pela metade! hehe .. deixa eu explicar.

Se eu tenho um BPM Object com a seguinte estrutura:

MyBPMObject
- name (string)
- email (string)
- address (XMLObject)
 
Address (XMLObject)
- zipcode (int)
- city (string)
- state (string)

E no JSP tentar acessar o atributo da seguinte forma:

Nome: <c:out value="${bpmObject.name}"/>
<br/>
Estado: <c:out value="${bpmObject.address.state}"/>

Funciona!

Agora, se o meu XMLObject fosse do tipo array, ou seja, uma lista, não funciona! Vejamos o meu BPMObject alterado para suportar uma lista de endereços (address):

MyBPMObject
- name (string)
- email (string)
- address[] (XMLObject)

No JSP:

Nome: <c:out value="${bpmObject.name}"/>
<br/>
Estado: <c:out value="${bpmObject.address[0].state}"/>

O exemplo acima não funciona, é como se o atributo “address” não existisse! Bizarro! Tentei inclusive usando a própria taglib do BPM e nada!

O que eu tive que fazer? Tcharammm.. criar um BPM Object idêntico ao meu XMLObject e criar um método dentro desse BPM Object que recebe como parâmetro um XML Object, o que ele faz é mapear os valores desse XML Object para os seus próprios atributos… totalmente POG! Mas foi o jeito…

Se alguém souber de algum “pulo do gato”, por favor me informe que eu publico aqui, mas eu sinceramente acho difícil ter alguma mágica, por mais óbvio que seja, não funciona. O mais bizarro ainda, é que se no Screenflow que antecede o JSP eu der um output do objeto da mesma forma que eu estou dando no JSP, funciona, só não funciona mesmo no JSP :(

Fica a dica: não usem XML Object para apresentar dados!

O início

Ao iniciar o projeto que estou atualmente, confesso que fiquei no impasse de “qual versão usar?”, pois o BPM Server (enterprise) de produção ainda é o 6, ou seja, Aqualogic. Paralelo a isso, comecei a ter alguns problemas com a versão 6.03 do Aqualogic BPM Studio na minha máquina, pois como tenho dois localhost (alias) apontando para o mesmo IP local (127.0.0.1), ao subir a engine um erro com a mensagem “server has exited” começou a ocorrer e com isso não conseguia “startar” a ferramenta. Pesquisando no Google, vi no falecido fórum da BEA, uma thread dizendo que para resolver esse problema bastaria eu comentar uma das linhas que apontam para o meu IP local no arquivo de hosts do meu SO. Fiz o procedimento e… nada! Ainda nessa mesma thread, havia outro comentário informando que na versão nova (Oracle) a engine estava mais esperta e resolvia esses tipos de problemas, foi a partir disso que resolvi usar a nova versão, ainda meio que ressabiado.

O problema e a segurança

Mas aí surge um novo problema: a incompatibilidade entre versões. Meu ambiente de desenvolvimento usa a versão nova e o meu ambiente de produção usa a versão mais antiga, será que com isso terei problemas em fazer deploy? A princípio não deveria ocorrer problema algum, pois na verdade o que mudou foi basicamente a skin da ferramenta, o workspace (skin também) e a engine que ficou mais esperta. Nesse meio tempo, por coinciência, tive um treinamento de BPM aqui no RJ com o pessoal da Oracle e ao perguntar pra eles se esse problema poderia se concretizar, fui respondido que não, apesar de nunca terem feito esse teste. Confirmaram ainda, que realmente quase nada havia mudado de uma versão para outra. Foi o suficiente para eu ter segurança na minha decisão.

A realidade

Mas no decorrer do projeto, tenho percebido que o buraco é um pouco mais embaixo hehe, nada que comprometa o desenvolvimento, mas alguns cuidados precisam ser tomados e como estou passando pela experiência, acho válido relatar para quem possar vir a passar pelas mesmas situações que eu. Só gostaria de ressaltar, que os testes que tenho feito não são os ideais, pois o que estou testando é o projeto sendo executado no Studio BPM na versão Oracle (nova) e também no Aqualogic (antiga), mas ainda não tentei fazer deploy em uma versão enterprise, pois ainda estou sem ambiente para isso, quando tiver esses testes, atualizo esse post.

Abaixo irei enumerar as diferenças que notei até agora com suas devidas observações.

Controle de Versão
Na versão 6.03 (Aqualogic), a ferramenta ainda não possuia um controle de versão embutido para SVN, se fazia por necessário instalar um plugin (Subversive) para ter essa funcionalidade, agora isso já vem de graça! Essa sem dúvida foi uma melhoria muito positiva na qual não tive problema algum entre as versões.

Connectors
O BPM Studio, em ambas as versões, tem uma coisa muito legal chamada connectors. Com os connectors é possível criar um atalho para determinada atividade sem ter que puxar uma transition para a mesma, isso é muito bom para ajudar na organização do processo, pois com isso evita-se que um monte de transitions fiquem entrelaçadas deixando o processo uma verdadeira zona.

Com connectors comecei a ter alguns problemas, pois processos que possuiam connectors na versão nova simplesmente não funcionavam na versão antiga. Pior do que isso, processos com connectors na versão nova não abrim na versão antiga! Não consegui descobrir o motivo, a única conclusão que cheguei é que geralmente o problema ocorria com connectors que linkavam para uma atividade final (End) do processo.

Conclusão: não uso mais.

Instanciar Variáveis
Esse foi um comportamento que eu sinceramente prefiro da versão antiga, pois acho mais correto.

O que ocorre é que algumas variáveis de instância eu não preciso instanciar, então em um array de BPMObject eu consigo ter algo do tipo:

bpmObject[i].nome = "Marcus Cavalcanti";

Ou seja, não precisei instanciar aquele índice corrente do array. Já na versão antiga isso não funciona, obviamente ocorre um NullPointerException, então para resolver isso eu preciso fazer:

bpmObject[i] = new MeuBpmObject();
bpmObject[i].nome = "Marcus Cavalcanti";

Eu prefiro a segunda opção, mais conservadora. Sinceramente não sei como e porque a primeira opção funciona na versão nova, pois não deveria.

Activity x Transitions
Uma mudança simples, mas muito significativa ocorreu nessa nova versão. Toda vez que uma atividade é adicionada ou removida, automaticamente o layout se ajusta e na maioria das vezes bagunçando as transitions entre uma atividade e outra. Agora na nova versão existe a possibilidade de habilitar/desabilitar esse “recurso”. É muito simples, basta ir em:

Window > BPM Preferences > Activity > General

Seguido os passos acima, basta apenas desmarcar o último checkbox. Fichinha!

Gráficos e Skin
Nossa… esse foi um avanço e tanto! Na versão para Linux os ícones ficavam horrorosos! Ficavam sem transparência por causa do PNG, então ficava aquele fundo preto e era horrível, além do mais os ícones agora estão bem mais trabalhados e bonitinhos :)

O Workspace foi outra coisa que mudou, achei a nova skin bem melhor e funcional, parece que cabem mais informações.

Conclusão

Conforme dito no começo, mudanças em relação a features não existem de uma versão para outra, mas percebi algumas pequenas mudanças ao executar o mesmo projeto em versões diferentes, o que pode trazer pequenos problemas.

Acredito que a principal questão seja em relação a diferença entre versões de desenvolvimento e enterprise, mas esses testes ainda não possuo e assim que possuir atualizo esse post. Da mesma forma, se surgirem novas diferenças entre as “versões Studio”, esse espaço será atualizado.

PS: se alguém tiver percebido mais algum comportamento estranho, fique a vontade para compartilhar, os comentários estão aí pra isso!

Ao passar dos anos aprendi que um “bom desenvolvedor” deve se preocupar com questões além do código, como por exemplo:

• SEO (no caso de websites, claro);
• Segurança (sql injection, xss, etc);
• Arquitetura da Informação;
• Performance;
• Organização do Projeto;
Sistemas Operacionais e Servidores;
• Metodologias de Desenvolvimento;
• Ter bom convívio social.

Os assuntos acima são apenas alguns dentre uma gama de assuntos, que podem ser citados como de interesse de um “bom desenvolvedor”. Não estou afirmando que o tal “bom desenvolvedor” deve ser um expert em tudo, mas ele deve ter o mínimo de conhecimento em N assuntos para saber os prós e contras que aquilo trará para o seu projeto. Entretanto isso não é uma tarefa das mais fáceis, já que para deter conhecimento de uma gama de assuntos, esse “bom desenvolvedor” deve dedicar um considerável espaço de tempo para leituras e pesquisas, sejam em livros propriamente ditos, como em blogs, artigos ou revistas.

Todos os “bons desenvolvedores” que conheço e que hoje em dia tem um cargo de maior responsabilidade, como líderes de projeto ou coordenadores de área, possuem uma certa habilidade para lhe dar com assuntos variados, bem como uma certa facilidade em absorver novos conhecimentos. É muito diferente, por exemplo, desenvolver um site que tenha centenas de acessos diários, para um e-commerce que tenha cerca de 1000 compras por hora, pois nesse último caso tudo deve ser pensado de forma diferente: desde a arquitetura, otimizações de banco de dados, resources (javascript) de terceiros, acesso concorrente até privacidade das informações e volume do tráfego de dados… enfim, não é pouca coisa.

Infelizmente o mercado global de TI aponta que a quantidade dos “desenvolvedores” – aqueles que não queremos ser – ainda é maior do que as dos “bons desenvolvedores”, e isso não sou eu que digo, pesquisas de institutos respeitados (aqui, aqui, aqui e aqui) apontam para uma escassez de mão-de-obra qualificada no mercado. Eu ainda diria mais: acredito que no Brasil a disparidade deva ser ainda maior.

Certamente você que está lendo esse post pode achar que não se enquadra nesse perfil citado acima, mas será que realmente não? Se você tem essa certeza, é um bom caminho, mas procure não se acomodar. É como diz aquela famosa e sábia frase de Sócrates: “Quanto mais se aprende mais se tem a certeza de que nada se sabe”. Agora, se você ficou na dúvida, não se desespere! Basta apenas começar a pesquisar e estudar mais, sem botar a carroça na frente dos bois. Uma dica que dou, é de que é preciso ter um foco, devemos nos conhecer melhor, saber o que gostamos de fazer e tentar imaginar onde e como gostaríamos de estar trabalhando daqui há alguns anos, a partir disso, acredito ser possível saber suas aptidões e o que pesquisar/estudar, pois de nada adianta conhecer mil coisas superficialmente e não ter foco em nada, definitivamente não é isso que o mercado procura.

Outro ponto que não posso esquecer, são as famosas empresas que querem aquele cara “ninja”. Um ninja deve ser o cara que sabe de tudo e mais um pouco. Muitas vezes essas empresas pagam pelo “ninja” um salário de estagiário e exigem do “ninja” um desempenho de sênior, já que quando o “ninja” foi contratado não foi levado em conta o seu nível de experiência e conhecimento. Essas empresas, apenas colaboram de forma efetiva para degradação do mercado e pela escassez de bons profissionais.

Devemos saber dividir as coisas: uma coisa é um bom profissional, que tem um foco bem definido, mas que possui conhecimento sobre outros assuntos, outra coisa é um profissional que sabe assobiar, chupar cana e cantar ao mesmo tempo, mas que na verdade não faz nenhum dos três bem. Quando surgir uma empresa ou profissional com esse perfil, desconfie.

PS: Como são sinônimos, eu diria que o termo “programador” causa o mesmo efeito.

Pensando nas situações descritas acima e também baseado em necessidades reais do meu dia-a-dia, criei uma função muito simples que converte um objeto em array.

Imagine um objeto com a seguinte estrutura:

TableEditor Object
(
    [db] => Resource id #82
    [pk] => id_idioma_afiliado
    [table] => idioma_afiliado
    [fields] => Array
        (
            [id_idioma_afiliado] => Array
                (
                    [display] => id_idioma_afiliado
                    [input] => text
                    [values] =>
                    [default] =>
                )
 
            [afiliado_id] => Array
                (
                    [display] => afiliado_id
                    [input] => text
                    [values] =>
                    [default] =>
                )
 
            [idioma_id] => Array
                (
                    [display] => idioma_id
                    [input] => text
                    [values] =>
                    [default] =>
                )
 
            [tx_descricao_afiliado] => Array
                (
                    [display] => tx_descricao_afiliado
                    [input] => textarea
                    [values] =>
                    [default] =>
                )
 
            [tx_transfer] => Array
                (
                    [display] => tx_transfer
                    [input] => textarea
                    [values] =>
                    [default] =>
                )
 
            [tx_informacao_afiliado] => Array
                (
                    [display] => tx_informacao_afiliado
                    [input] => textarea
                    [values] =>
                    [default] =>
                )
 
            [tx_apresentacao_afiliado] => Array
                (
                    [display] => tx_apresentacao_afiliado
                    [input] => textarea
                    [values] =>
                    [default] =>
                )
 
        )
)

Se quiséssemos ordená-lo, por exemplo, apesar de não ser difícil, demandaria tempo.
Mas e se ao invés de um objeto, tivéssemos um array? Algo como:

Array
(
    [db] => Resource id #82
    [pk] => id_idioma_afiliado
    [table] => idioma_afiliado
    [fields] => Array
        (
            [id_idioma_afiliado] => Array
                (
                    [display] => id_idioma_afiliado
                    [input] => text
                    [values] =>
                    [default] =>
                )
 
            [afiliado_id] => Array
                (
                    [display] => afiliado_id
                    [input] => text
                    [values] =>
                    [default] =>
                )
 
            [idioma_id] => Array
                (
                    [display] => idioma_id
                    [input] => text
                    [values] =>
                    [default] =>
                )
 
            [tx_descricao_afiliado] => Array
                (
                    [display] => tx_descricao_afiliado
                    [input] => textarea
                    [values] =>
                    [default] =>
                )
 
            [tx_transfer] => Array
                (
                    [display] => tx_transfer
                    [input] => textarea
                    [values] =>
                    [default] =>
                )
 
            [tx_informacao_afiliado] => Array
                (
                    [display] => tx_informacao_afiliado
                    [input] => textarea
                    [values] =>
                    [default] =>
                )
 
            [tx_apresentacao_afiliado] => Array
                (
                    [display] => tx_apresentacao_afiliado
                    [input] => textarea
                    [values] =>
                    [default] =>
                )
 
        )
)

Ficaria muito mais fácil, não?!

Para obter esse resultado, basta jogar a funçãozinha abaixo como um helper no seu projeto ou criar um método estático em sua classe utilitária. Segue:

function objectToArray ($object) {
	if ( count($object) > 1 ) {
		$arr = array();
		for ( $i = 0; $i < count($object); $i++ ) {
			$arr[] = get_object_vars($object[$i]);
		}
 
    	        return $arr;
 
	} else {
		return get_object_vars($object);
	}
}

Para utilizar, é simples:

// $object é o seu objeto
echo "<pre>";
print_r(objectToArray($object));
echo "</pre>";

A boa notícia é que esta função preserva toda hierarquia dos seus objetos criando dimensões dentro desse array, no caso uma matriz. O exemplo que eu usei foi bem simples, apenas para poder ilustrar o uso da função, mas caso tivéssemos um objeto mais “complexo” toda sua estrutura seria mantida sem problemas.

Uma dica bem simples, mas espero que seja de grande utilidade! :)

BPM

BPM é o acrônimo de Business Process Management, que traduzindo para o português seria Gerenciamento de Processos de Negócio.

Definir o termo BPM não é uma tarefa trivial, pois como se trata de um assunto amplo e recente, cabem mil definições, algumas não tão boas, de cunho mais comercial e outras mais simples. Porém acredito que as explicações mais simples, não conseguem dar um overview sobre BPM para uma pessoa leiga no assunto, portanto tentarei usar exemplos e conceitos para tentar passar melhor esse significado.

BPM tem a ver com processos, e BPMS com processos e software. Sendo prático, eu diria que BPM é uma metodologia, um conjunto de boas práticas, com o o intuito de mapear e gerenciar processos de negócio, onde são (ou não) envolvidos clientes, usuários, fornecedores e atividades automáticas (informatizadas), onde o principal objetivo do BPM seria obter uma melhoria desse processo.

Se ainda não ficou muito claro, para facilitar as coisas, darei um exemplo real. Imagine o seguinte cenário:

• Departamento comercial da empresa X identifica que o produto Y é um produto com forte potencial de venda;
• Departamento comercial solicita ao departamento de compra/venda o produto Y;
• Departamento de compra/venda vai em busca de fornecedores fazendo cotação de preços em busca do melhor custo x benefício;
• Departamento de compra/venda define o fornecedor Z como escolhido e esse fica de fazer a entrega dos produtos em 15 dias;
• Na data estipulada, o setor de logística da empresa X, recebe o produto do fornecedor Z e assim comunica ao departamento comercial que este está disponível para venda;
• Departamento comercial da empresa X, então comunica ao departamento de marketing, que nesse caso irá bolar um campanha de divulgação desse novo produto;
• Campanha criada, produto finalmente é lançado.

Repare no fluxo acima e perceba que isso é um processo de negócio, pois ele possui um começo, envolve pessoas, pode envolver outros recursos, tem um objetivo bem definido e provavelmente ocorre com certa frequência. Esse processo pode ser melhorado, se tornar mais eficiente? É provável que sim e é nesse ponto que entram o BPM e o BPMS. O BPM seria uma forma de mapear esse processo, identificar gargalos, pontos falhos afim de melhorá-lo e para isso a ajuda de um (bom) software BPMS é muito importante.

BPMS

BPMS (Bussiness Process Management Software) seria o braço direito do BPM na melhoria do processo exemplificado acima, através do BPMS seria possível modelar esse processo visualmente e com recursos específicos de uma ferramenta BPMS é possível ter métricas e controles de todo fluxo do processo, dessa forma seria possível, por exemplo, simular esse processo de diversas maneiras, criar mecanismos de automação e fornecer relatórios específicos para tomadas de decisão. Tudo isso com o objetivo único e exclusivo da melhoria desse processo.

É difícil falar sobre BPM sem ser um pouco repetitivo, sem deixar a leitura cansativa, pois trata-se de um assunto muito teórico e abstrato, mas a melhor forma de falar sobre BPM é com exemplos, portanto, com o assunto introduzido, no próximo post mostrarei um cenário de um processo real em que estou trabalhando atualmente e a necessidade do uso de uma ferramenta BPMS.

Só para finalizar, BPM hoje em dia é um dos “componentes” que fazem parte de uma arquitetura SOA completa, o que não significa que para ter uma solução SOA eu tenha que fazer o uso do BPM, porém se usados juntos da forma correta, tornam-se uma poderosa dupla na gestão, automatização e melhoria de processos de negócios.

Hoje em dia vejo muitas aplicações que cometem esse mesmo equívoco que eu cometia há alguns anos atrás, fazem o uso do recurso (que nesse caso passaria a não ser um recurso) sem saber a razão, isso me remete até ao meu primeiro post.

Essa questão sobre o uso de getters e setters tem muito a ver como as coisas são feitas hoje em dia em relação ao desenvolvimento de software, principalmente em desenvolvimento para web, eu diria. Perdeu-se o seu principal foco, razões e objetivos e com isso surgem casos como o uso desenfreado dos getters e setters.

Getters e setters devem ser originalmente usados para encapsular seus atributos, evitando assim que eles sejam acessados diretamente. Dessa forma podemos aplicar determinada regra de negócio antes de atribuir valor a um atributo. Não é necessário, por exemplo, usar getters e setters em alguns objetos que serão imutáveis, ou então, apenas em objetos que servem para receber valor, nesses casos os getters e setters tornariam-se desnecessários.

Hoje em dia só faço o uso dessa dupla, quando realmente sinto essa necessidade, quando sei que meu atributo poderá vir a ter uma regra de negócio específica ou por algum motivo muito peculiar (ver mais abaixo), caso contrário, não uso. Em muitos casos passar os valores para o objeto utilizando o método construtor já resolveria o problema de forma simplória.

Deve-se considerar também, a possibilidade do seu software ser uma API aberta, usada e modificada por outros desenvolvedores, onde talvez você não tenha necessidade de um getter/setter, mas provavelmente para fornecer uma maior flexibilidade do código – considerando a possibilidade dele ser extendido – talvez seja interessante disponibilizar os tais pares. Da mesma forma que para debugar um código, talvez seja interessante fazer o uso de getters e setters para saber o valor que está sendo atribuído a uma variável, ao invés de espalhar milhões de breakpoint pelo código.

Links Interessantes
Fowler e Getters
Getter Erradictor
Why getter and setter methods are evil
Como não aprender Java e orientação a objetos

Dando uma fuxicada no Google, percebi que várias pessoas estavam com esse mesmo problema, inclusive usuários de Windows.

Para resolver o problema é muito simples, basta instalar o pacote “msn-pecan” com o comando:

sudo apt-get install msn-pecan

E depois é só mudar o protocolo da sua conta para “WML” ao invés de “MSN”.

Feito os dois passos acima, o problema estará resolvido.

A idéia foi criar um problema simples e a partir disso coletar as implementações nas mais diversas linguagens, das mais loucas as mais famosas.

Eu dei a minha colaboração na implementação para PHP 5.

Reparem na “facilidade” que seria resolver o problema usando SED, que na verdade não é considerada uma linguagem de programação.

É a famosa discussão da melhor linguagem. Para mim não existe a melhor linguagem, cada uma tem sua finalidade e consequentemente seus pontos fortes e fracos. Nada impede que um sistema tenha várias linguagens e plataformas, não é mesmo? Aliás, felizardo são aqueles que tem essa visão e know-how de mixar tecnologias. Vide Google, que dentre outras usa Python, Java e C++.

Acompanhando a discussão e até participando, refleti sobre alguns pontos e percebi um detalhe que até então estava passando desapercebido por mim: frameworks só deveriam ser usados por quem consegue e tem responsailidade ao usá-los.

A frase acima parece meio ambígua e talvez até agressiva, concordo, mas posso explicar melhor.

Tenho visto constantemente em fóruns de discussão, listas e etc, pessoas com dúvida sobre o framework X, só que grande parte dessas dúvidas não são em função de uma limitação do framework X e sim uma limitação do desenvolvedor. Vejo que por exemplo, com essa explosão dos frameworks WEB/MVC, que muitos desenvolvedores fazem o uso do framework X de forma famigerada ferindo todos os conceitos de MVC, conseguem simplesmente esquecer que o framework foi construído dentro desse padrão e que o ideal é que ele permaneça dessa forma. Quando digo isso, não digo isso porque o framework X deve ser imutável, na verdade a grande maioria dos frameworks oferece flexibilidade o suficiente para ser extendido e até alterado (que na maiora das vezes não é a melhor decisão), mas de forma que seja respeitado a sua arquitetura e ‘boas práticas’ de design de uma aplicação.

Quase todos esses frameworks foram construídos usando OO, mas mesmo assim a maioria dos desenvolvedores que usam esses frameworks não conhecem os principais (básicos) conceitos de OO e com isso acabam tomando decisões que no futuro irá prejudicar o projeto como um todo e consequentemente irão ter o seu filme queimado. Em muitos casos a aplicação correta dos conceitos de OO resolveriam de forma elegante e reutilizável aquele problema que outros optam por resolver de forma bisonha.

Onde eu quero chegar com tudo isso?

O que eu quero dizer é que todos deveríamos nos preocupar em entender como as coisas funcionam antes mesmo de usá-las, aprendi isso há bastante tempo atrás com um amigo meu na época em que agia da mesma forma que estou citando aqui, portanto compreendo perfeitamente algumas pessoas ainda agirem dessa forma, principalmente as mais inexperientes, por isso resolvi ter a iniciativa de escrever esse post e talvez gerar uma reflexão. Não sou o dono da verdade, não construo os melhores softwares do mundo, mas procuro sempre saber e entender o que eu estou usando e o que estou fazendo, pois com isso evito problemas para mim e para o meu projeto. E o principal é que evoluo.

Dicas

Antes de usar algo, procure se perguntar:

- O que eu preciso?

- Como “x” funciona?

- Usar “x” resolve o meu problema?

- “x” vai me ajudar ou atrapalhar?

- Quais são as outras alternativas a “x”?

Acredito que com respostas para as questões acima é possível ter uma resposta que satisfaça a necessidade real do problema e que principalmente nos deixe com a sensação de que o melhor possível foi feito, pelo menos pensado foi. E se mesmo assim algo der errado, como conhecemos o problema e a solução que fracassou, fica mais fácil (ou menos difícil?) de identificar e resolver.

Ver um “Olá, Mundo” impresso na tela sempre foi algo que gerou alegria, satisfação e que principalmente representou uma nova etapa quando falamos especificamente sobre programação, tecnologias, etc, quem é da área sabe o que estou falando.

Há algum tempo estava com a idéia de tocar um blog, seja para compartilhar conhecimento, conhecer gente, ser xingado, ser elogiado ou para quebrar a rotina, e após ter instalado o wordpress há algum tempo, aproveitei o começo do ano, que é sempre um bom motivo para iniciar algo e resolvi de vez criar o primeiro post e dar forma a “criança”.

Acho que o principal desafio desse blog será manter um foco, mas quando digo foco, não é falar sobre um assunto MUITO específico, pretendo falar sim sobre um assunto, mas um assunto em que eu tenha uma gama de outros assuntos para dar o meu pitaco, então que assim seja.

É agora ou nunca!