Mitos sobre geração de código

Bruno Braga on December 24th, 2009

Segue abaixo um artigo que escrevi no site do projeto SPIDER on Rails:

O termo “mito” é, por vezes, utilizado de forma pejorativa para se referir às crenças comuns.
E existe uma cresca comum que geração de código é algo ruim em projetos.

Encarnando os MythBusters vamos tentar analisar objetivamente se esse mito é válido.

A geração de código é a capacidade de gerar artefatos a partir de diagramas, templates ou até comandos.

Um fato constatável é que alguns desenvolvedores são um pouco resistentes ao termo “Geração de Código”.
As principais reclamações são:

  • O código gerado não respeita nenhuma regra de arquitetura, é simplesmente “um monte de código” de má qualidade;
  • Não é possível manter o código gerado porque ele não segue nenhum padrão e é difícil de entender, sempre é necessário regerar o código em caso de mudanças;
  • Após gerar o código a minha aplicação fica sempre depedente da ferramenta de geração, sem ela o projeto não pode ser alterado;

Dada à diversidade de ferramentas dessa área, estes pontos parecem estar corretos. É fácil encontrar esses tipos de problemas e limitações.
Indo mais além, muitos de nós já se deparou com projetos que prometiam criar um sistema por completo usando geração de código (ferramentas CASE), porém sabemos que isso não é a realidade. Não podemos substituir as pessoas, os programadores, criar regras de negócios automaticamente, prever e implementar soluções para todos os cenários somente gerando código. O computador não possui autonomia para sozinho atender aos nossos clientes exigentes =)… Muito menos foi projetado para tomar todas as decisões no lugar das pessoas.

Então o mito tem fundamento? Geração de código é realmente algo ruim? Vai gerar código que não preciso e atrapalhar o meu projeto?

Essas questões são interessantes, e para buscar uma resposta precisamos isolar os problemas e conceitos, entender o que de fato é geração de código e de onde vem todo o problema.

Ferramentas CASE e similares

Essas ferramentas criadas na década de 90 são responsáveis por boa parte das promessas de “mágica” utilizando geração de código através de modelos. Muitas dessas ferramentas prometiam criar sistema inteiros sem programar nenhuma linha de código. Foi uma estratégia que nunca deu certo e essas falsas promessas surgiram de algumas empresas e das ferramentas e não do conceito de geração de código que é utilizado até hoje (mesmo sem percebermos) em quase todos os softwares que desenvolvemos.

Geração de código

Neste tópico o objetivo é descobrir porque praticamente todo projeto usa geração de código e o que de fato é isso.

Alguns exemplos comuns a todos os projetos:

  • Um wizard da IDE para criar novos projetos é um gerador de código. A partir de dados informados pelo usuário, a ferramenta vai gerar artefatos (arquivos) que inicializem um novo projeto.
  • Por mais estranho que possa parecer, a compilação de código fonte em arquivos binários é geração de código. A partir de comandos de uma linguagem de alto nível são gerados artefatos de outra linguagem de máquina (baixo nível).

Esses exemplos podem parecer polêmicos para alguns pontos de vista, mas a verdade é que não existe uma definição precisa sobre o conceito de geração de código. Existem opiniões e interpretações diferentes que nos levar a ter um certeza – geração de código é algo muito mais amplo do que conhecemos na maioria das ferramentas e é utilizado com muito mais frequencia do que imaginamos.

Vejamos por exemplo o que diz a Wikipedia:
“Gerador de Código é aquela ferramenta que possui a capacidade de gerar código a partir de um determinado modelo de software. Inclusive, de acordo com alguns pontos de vista e a partir das características específicas do tipo de Gerador de Código, ele passa a ser conversor de códigos de linguagens distintas. Isso acontece, por exemplo, com o compilador, que transforma um código escrito através de uma linguagem de programação para código de máquina ou código objeto.”

Já Kathleen Dollard em 2004 no livro Code Generation in Microsoft .NET, foi mais genérica ainda ao definir: “Geração de código é o código que gera código”. Em 2003, Jack Herrington no livro Code Generation in Action preferiu dividir a geração de código entre passiva e ativa. Onde os wizards seriam um exemplo de geração passiva, pois não mantém responsabilidade com o código gerado – qualquer alteração depois da geração é realizada pelo desenvolvedor manualmente, e o tipo ativo que segundo ele mantém a responsabilidade – um código poderia ser gerado em ciclos e quando precisasse de alterações o desenvolvedor recorreria novamente a ferramenta de geração, forneceria novos dados e seria gerado o código de novo.

Aqui não vamos dividir a geração de código em tipos, até porque seguindo ao pé da letra as definições de Herrington, o projeto SPIDER on Rails não faz geração de código 100% ativa nem passiva, ele é orientado as necessidades do desenvolvedor, podendo se comportar das duas formas no mesmo projeto inclusive. O que temos que ter em mente é que se havia alguma dúvida, agora é fato: a Geração de Código faz parte do dia a dia dos desenvolvedores e todos a utilizam, mesmo sem perceber. Ela é extremamente importante para evitar tarefas repetitivas ou trabalhosas, já que muitas podem ser automatizadas de alguma forma para ganhar produtividade. Só devemos lembrar que em nenhum momento a geração de código tem como objetivo fazer tudo sozinha.

Conclusão

Voltando a pergunta: “Geração de código é realmente algo ruim? Vai gerar código que não preciso e atrapalhar o meu projeto?”

A resposta é não! Geração de código não é ruim, não vai atrapalhar o seu projeto e nem tem o objetivo de criar código totalmente pronto.

Existem algumas características que devem que existir para que a geração de código seja algo útil, entre elas:

  • Suporte a templates para alterar o comportamento da ferramenta;
  • Seja fácil de utilizar;
  • O projeto tem que continuar sem depender da ferramenta de geração de código;
  • Ao gerar o código novamente a ferramenta não pode apagar as customizações do desenvolvedor;
  • Não tentar fazer o projeto todo gerando código, as pessoas são importantes e elas devem tomar as maiores decisões. A ferramenta é apenas um suporte para melhorar a produtividades em alguns pontos;

São esses e outros pontos que valorizamos no projeto SPIDER on Rails.

fonte: http://www.spideronrails.org/cnf/pages/viewpage.action?pageId=5111911

Subscribe to this blog's RSS feed

Análise: Compra da SUN pela Oracle

Bruno Braga on April 20th, 2009

Como muitos já sabem, as Oracle anunciou hoje que está comprando a SUN Microsystems.

No GUJ as pessoas estão trocando opiniões com o objetivo de avaliar se isso é ou não uma boa notícia e comparando com a tentativa anterior de compra por parte da IBM.

Como postei no GUJ, sem ver as estrategias de cada empresa a médio / longo prazo não da para dizer que vai ser melhor com a Oracle, IBM ou outra companhia.
Qualquer preferencia seria chute ou opinião pessoal. Existem muitas coisas envolvidas em um negocio deste tipo.

Mas eu espero que o Java tenha uma atenção maior da nova empresa, mais investimento e que isso torne mais rápido nas decisões e implementações do JCP.

O que me preocupa no momento é que a Oracle não tem perfil Open Source como a SUN (java, solaris) / IBM (eclipse, team concert, dojo, geronimo, etc…).

O caminho para o Java crescer na minha opinião não é com a logo da Oracle ou de qualquer outra empresa. O caminho é criando / mantendo uma estrutura separada “Java Foundation” ao estilo “Eclipse Foundation” que seja mantida / gerenciada por uma grande companhia mas que ao mesmo tempo esteja aberta a contribuição de outras empresas / pessoas.
É isso que a Oracle precisa aprender a fazer e espero que comece buscando experiências dentro da SUN.

Se em algum momento da transição começarem a levar a SUN para dentro do site da Oracle como “produto / tecnologia Oracle”, já ferrou com as outras empresas. Na minha opinião, não é disso que Java precisa.

Por questão de ego/concorrência uma empresa que investia em Java pode passar a investir em PHP, outra em Ruby e ai os players podem acabar divididos em relação a linguagem.
Se isso acontecer quem vai rir é a Microsoft que vai ter mais moleza ainda com o .Net e tecnologias para desenvolvimento corporativo.

Portanto a minha “dica” é: o foco em Open Source e em uma estrutura separada é importante.
Espero que a Oracle tenha ainda comprometimento e investimento neste modelo :)

Agora é esperar para ver o que vai acontecer a médio prazo.

JMS com Spring

Bruno Braga on July 22nd, 2008

Eu estava viajando, então estive ausente do PC por alguns dias :P
De volta agora é hora de colocar o assunto em dia.

Em dois posts anteriores eu falei algo sobre JMS. Um que tratava da integração do Oracle com Java e outro da comunicação do Websphere MQ via JMS. Então para completar o assunto vou mostrar na prática como enviar e receber mensagens usando JMS e Spring.
Provavelmente esse post vai ser melhor aproveitado por quem já conhece ou utiliza o Spring, mas como é um framework popular é fácil encontrar referencias sobre suas configurações na web.

Connection Factory:

Nosso objetivo é enviar mensagens via JMS para o Websphere MQ (MQSeries), dando seqüencia ao post Websphere MQ e JMS. Para isso vamos usar o Connection Factory da IBM com.ibm.mq.jms.MQQueueConnectionFactory para gerenciar a conexão. Segue abaixo o trecho de configuração disso no Spring (arquivo applicationContext.xml):

<bean id="jmsQueueConnectionFactory" class="com.ibm.mq.jms.MQQueueConnectionFactory">
	<property name="hostName">
		<value>${mq.hostName}</value> 
	</property>
	<property name="queueManager">
		<value>${mq.queueManager}</value>
	</property>
	<property name="channel">
		<value>${mq.channel}</value>
	</property>
	<property name="port">
		<value>${mq.port}</value>
	</property>
	<property name="transportType">
		<value>1</value>
	</property>
</bean>

Esse transportType é referente ao tipo de comunicação utilizado. O valor 1 é referente a constante  com.ibm.mq.jms.JMSC.MQJMS_TP_CLIENT_MQ_TCPIP que diz que a comunicação é via TCP IP.

Configuração:

As demais configurações do Spring para JMS são simples, e similares a isso:

<bean id="jmsSpringConnectionFactory" class="org.springframework.jms.connection.SingleConnectionFactory102">
	<property name="targetConnectionFactory">
		<ref local="jmsQueueConnectionFactory" />
	</property>
</bean>
		
<bean id="jmsQueueTemplate" class="org.springframework.jms.core.JmsTemplate102">
	<property name="connectionFactory" ref="jmsSpringConnectionFactory"/>
	<property name="pubSubDomain" value="false"/> <!-- false seta para queue (point to point) -->
	<property name="receiveTimeout" value="500"/>
</bean>

Utilização:

Para usar é muito simples, basta instanciar o Spring e depois enviar e receber mensagem com praticamente uma linha de código.

Instanciando o Spring:

BeanFactoryLocator bfs = SingletonBeanFactoryLocator.getInstance("applicationContext.xml");
BeanFactoryReference bf = bfs.useBeanFactory("mqSpring");

O Spring irá instanciar as classes configuradas nos beans, e a partir dai é só usar.

Enviando mensagem:

JmsTemplate jmsTemplate = (JmsTemplate) bf.getFactory().getBean("jmsQueueTemplate");
jmsTemplate.convertAndSend("fila", "mensagem");

Recebendo mensagem:

JmsTemplate jmsTemplate = (JmsTemplate) bf.getFactory().getBean("jmsQueueTemplate");
TextMessage textMessage = (TextMessage) jmsTemplate.receive("fila");

Listener:

Uma outra opção para receber mensagens do MQ é criar um listener que fica escutando uma determinada fila e irá receber automaticamente novas mensagens.

<bean id="messageListener" class="br.com.globalvalue.exemplomq.ExemploListener" />
	
<bean id="jmsListenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
	<property name="connectionFactory" ref="jmsSpringConnectionFactory"/>
	<property name="messageListener" ref="messageListener" />
	<property name="destinationName"><value>${mq.queue.inbox}</value></property>
</bean>
public class ExemploListener implements MessageListener {
	public void onMessage(Message message) {
		if (message instanceof TextMessage) {
			try {
				System.out.println(((TextMessage) message).getText());
			}
			catch (JMSException ex) {
				throw new RuntimeException(ex);
			}
		}
		else {
			throw new IllegalArgumentException("Message must be of type TextMessage");
		}
	}
}

Para executar o código é necessário os jar`s do Spring (e dependencias) e os jar`s da IBM para o Websphere MQ. Espero que o nível de detalhes tenha sido suficientes. Vimos que se o projeto utiliza Spring é fácil enviar e receber mensagens utilizando JMS, mesmo com classes (Factory) de terceiros como no caso do nosso exemplo para Websphere MQ.

Websphere MQ e JMS

Bruno Braga on July 4th, 2008

Existem várias formas de realizar comunicação entre aplicações. Entre elas estão: troca de arquivos,  compartilhamento de banco de dados, chamada de métodos remotos (RMI, SOAP) e mensageria.

O MQ (Message Queue) é um padrão para mensageria adotado por várias empresas, entre elas a IBM que possui o produto Websphere MQ (antigamente chamado de MQSeries).

Um dos pontos fortes do MQ se comparado com outras tecnologias é a troca de mensagens assíncronas e garantia de entrega. Ou seja: conseguimos enviar uma mensagem para a fila de um aplicativo sem que este aplicativo esteja no ar e sem ficar parado esperando uma resposta (comunicação assíncrona). Temos ainda a certeza de que se a mensagem saiu da fila é porque ela foi lida (entregue).
Uma comunicação como esta é muito mais segura do que um envio de e-mail, troca de arquivos ou transferências de dados similares.

Um detalhe importante é que apesar da comunicação ser assíncrona, é possível utilizá-la de forma online – onde enviamos e recebemos a resposta em “tempo real”. Vou explicar neste post como isso funciona. Alias, já vi implementações que tentam dar essa aparência de comunicação online realizando pooling (loop) nas filas do MQ para verificar se existem novas mensagens. Mas isso não é o procedimento correto. O MQ permite que a aplicação assine uma fila e receba novas mensagens automaticamente sem perder tempo no pooling ou degradar o ambiente.

No caso do Websphere MQ podemos realizar a comunicação de duas maneiras: a primeira é utilizando o Websphere MQ Client que possui uma API para programação em C, Cobol, CPlus, .Net, Java e VB 6. E outra forma bastante útil para o pessoal de Java é utilizando JMS (Java Message Service). O produto Websphere MQ suporta JMS, e neste caso não é necessário instalar ou utilizar o Websphere MQ Client.

Como este é um blog sobre Java vamos citar alguns detalhes da comunicação usando JMS.

Olhando a arquitetura do JMS existem maneiras diferentes de realizar a interação com uma fila (queue).
A primeira é uma comunicação ponto a ponto onde a aplicação 1 envia mensagem para uma fila e somente a aplicação 2 irá ler. Vejamos a imagem abaixo:

Neste modo ponto a ponto, quando a aplicação 2 ler a mensagem via JMS o próprio protocolo irá enviar um acknowledge para a fila (comportamento padrão) e a mensagem será apagada pelo MQ (leitura ocorreu com sucesso).

Se pararmos para pensar esse modo não funcionará caso seja necessário enviar a mesma mensagem para mais de uma aplicação. Outro problema de partir do cliente a requisição de mensagens é que ele teoricamente tem que fazer pooling, verificando de tempos em tempos se existem novas mensagens na fila.

Se for necessário contornar essas limitações existe uma outra forma de comunicação, que é a Publish and Subscribe. Onde vários aplicativos podem assinar uma vila e receber as mensagens quando chegarem. A mensagem só será apagada da fila quando todos receberem.

Um detalhe interessante é que as mensagens não precisam ser necessariamente do tipo texto. O JMS suporta os seguintes tipos de dados: text, map, bytes, stream, e object. O stream é uma boa opção para mensagens muito grandes (enquanto uma ponta está enviando a mensagem a outra já pode ir recebendo), enquanto o tipo object está mais próximo de linguagens orientadas a objeto.

Bom, basicamente é assim que funciona. Nós próximos posts vou tentar mostrar alguns passos de como escrever uma aplicação que envie e receba mensagens via JMS.

Oracle vs Java

Bruno Braga on July 1st, 2008

Atualmente estou atuando em um projeto onde é necessário a integração do Oracle com Java. Ou seja: é necessário executar código Java dentro do Oracle para uma determinada funcionalidade.

Esse projeto faz parte de um treinamento/consultoria sobre Websphere MQ (antigamente chamado de MQSeries) para um cliente, e vai ser o primeiro tema / “puxão de orelha” depois da reformulação do blog.

Puxão de orelha porque alguns itens referentes a integração do Oracle com Java não são legais. Mas para entender o problema e o funcionamento da integração vamos a um rápido cenário do aplicativo:

Além do treinamento de Websphere MQ o cliente solicitou que fosse desenvolvido um conector MQ em Java para posteriormente ser utilizado pelo sistema deles. Então optamos por desenvolver o conector MQ usando JMS e abstrair toda a complexidade da comunicação. Ele iria enviar mensagens com um comando e receber mensagens com um comando a partir do aplicativo Java. Até esse ponto estava excelente.

A dificuldade começou quando o cliente solicitou que o Conector MQ fosse executado dentro do Oracle através de uma trigger já que o Oracle suportava Java. Realmente o Oracle suporta Java, mas não tão bem como era esperado.
Somente para deixar claro: classes Java simples (recursos nativos da JVM) rodam muito bem no Oracle, isso foi um ponto bem positivo. O problema é executar uma aplicação ou conector que tem vários jars como API.

Objetivamente seguem detalhes sobre pontos problemáticos do Oracle versão 10.2:

  • ele não aceita jar’s externos. Todos os jar’s devem ser carregados para o banco usando o comando loadjava.
  • o comando loadjava carrega as classes do jar mas deixa todas com status INVALID !?!?… a maneria de resolver isso é usar o comando loadjava com o parâmetro “-resolve”.
  • o problema do parâmetro “-resolve” é que ele tenta “re-compilar” todas as classes do jar (sendo que um jar já é algo pronto para utilizar). Para cada classe o Oracle solicita as dependências (classes que estão no import). Então para incluir um jar de um driver do MQ preciso de N outros jars para satisfazer as dependências de compilação;
  • uma forma de resolver o problema acima podemos até utilizar o parâmetro “-genmissing” do comando loadjava, ele vai gerar uma classe fake para cada dependência e evita problemas de compilação, mas é obvio que se a classe fake for usada em qualquer ponto do processo (direta ou indiretamente) vai dar erro (ORA-29532: Java call terminated by uncaught Java exception: java.lang.NoClassDefFoundError:
    !!!ERROR!!! generated by genmissing) – então o genmissing não é muito útil, somos obrigados a ter as dependências para compilar / resolver quase tudo usando o “-resolve”;
  • o Oracle carrega para dentro do banco a classe que queremos importar + todos os jars necessários para execução + todas as dependências. Então temos um excesso de classes desnecessariamente;

Por causa dessas limitações a integração do Oracle com Java não é tão transparente. Não acredito que isso tenha um tratamento melhor no Oracle 11. Apesar do banco Oracle não ser um Application Server, poderia pelo menos seguir a arquitetura Java e ler as libs de um CLASSPATH. A parte de ter que carregar os jar para dentro do Oracle e re-compilar matou parte do suporte a Java do banco. Esse trabalho todo não vale a pena :)

Então esse foi o puxão de orelha, e todos esses problemas foram suportados pelo suporte oficial Oracle (http://metalink.oracle.com).

Mas em tempo, o SQLJ é bastante poderoso: podemos escrever uma classe Java (usando recursos nativos) e em determinados pontos utilizar #sql() (querys) com váriaveis Java. Então considerando somente esta necessidade a utilização é válida.

J2EE Spider 1.0.0-M3

Bruno Braga on May 26th, 2008

Bom o projeto está indo bem, a cada dia novas melhorias. Está dando muiiito trabalho, mas está ficando bacana.

O curioso é que o país onde as pessoas mais interagem e sugerem as coisas é a Índia =) O pessoal lá parece ser muito ligado na área de desenvolvimento mesmo.

Fora um ou outro bug a versão 1.0.0-M3 trás 15 melhorias enquanto a 1.0.0-M2 tinha 7. E cada melhoria dessas são significativas, então essa é uma boa release. Espero ter tempo para dedicar a JSF logo e adicionar essa opção no template da ferramenta até porque meu interesse pessoal é mais por JSF por enquanto.

Como detalhamento segue o changelog:

——————————————-
Version 1.0.0-M3 (2008-05-25)

Bug
* [Template] – Acertos no template para Struts – cruds com campo date, javascripts e outros.
* [Template] – Resolvido problema na geração da pasta /jsp/velocity usada para o struts-menu.
* [Plugin - Core] – Quando algum package tinha o mesmo nome do projeto o mapping gerava as classes na pasta errada.

Improvement
* [Plugin - Core] – Distribuição do plug-in usando jar e em arquivo separado do template.
* [Plugin - Core] – Adicionada validação de compatibilidade entre o template e o plug-in.
* [Plugin - Core] – Criação de aba exclusiva para gerenciar templates.
* [Plugin - Core] – Melhoria de performance do build.
* [Plugin - Core] – Adicionado botão para selecionar todos os atributos de uma classe no CRUD.
* [Plugin - UI] – Novo wizard para abrir o SPIDER Editor.
* [Template] – Mais traduções para o i18n do projeto.
* [Template] – Criado atributos para armazenar um resumo das características de cada template.
* [Template] – Adicionado ao template a possibilidade de executar scripts ant para completar o build.
* [Template] – Utilização da feature de executar scripts ant para rodar o xdoclet-build.xml após a geração de CRUDs com Struts.
* [Template] – Alinhamento do código HTML das páginas jsp geradas.
* [Others] – Utilização do Atlassian Bamboo como software de integração contínua e do Fisheye.
* [Others] – Criado um Eclipse Update Site para instalação e atualização do plug-in.
* [Documentation] – Site: tradução de mais páginas para o idioma inglês (mais documentação).
* [Documentation] – Nova sessão “Getting Started” no site.

——————————————-

http://www.j2eespider.org

Palestra SPIDER em evento M$…

Bruno Braga on April 24th, 2008

Parece estranho mas sábado dia 26 vou pegar carona em um evento do pessoal de .Net (Microsoft) e fechá-lo com uma palestra Java sobre o projeto J2EE Spider.

Como o povo do MG-JUG está um pouco parado em relação a palestras, vai ser uma oportunidade de ter algo sobre Java por aqui.

O evento vai ser o dia todo, mas a palestra do SPIDER será na parte da tarde por volta das 15:30h.

A palestra é mais um bate papo sobre geração de código e apresentação da ferramenta.

Quem quiser chegar antes, desde as 9h tem palestras sobre tecnologias da Microsoft inclusive SilverLight que é concorrente do Java FX.

Até lá!

Nova versão do J2EE Spider

Bruno Braga on February 1st, 2008

Ontem lancei a versão 1.0.0-M1 do J2EE Spider.

Temos muitas novidades. Agora já está disponível a criação de projetos com CRUD, o layout do plugin foi revisto, tem funcionalidades novas como mapeamento e muitas outras coisas…

Deu muito trabalho, mas está ficando bacana. Para ver você mesmo assista o vídeo abaixo:

- versão windows (auto-executável)
- versão multiplataforma (visualizado no browser)

Só gostaria de fazer uma consideração importante sobre a ferramenta:

Apesar da ferramenta estar ficando bastante interessante, ou em outras palavras – fácil de criar projetos com alguns clicks, devemos lembrar mais uma vez que o objetivo não é substituir as pessoas e sair criando projetos utilizando somente o SPIDER. O objetivo é eliminar as tarefas repetitivas que temos no dia a dia, como configuração de projetos, erros na integração de frameworks ou tirar das costas do desenvolvedor a responsabilidade de codificar artefatos que não possuem regras de negocio e uma ferramenta poderia criar em determinados contextos. As pessoas (nós desenvolvedores) podemos ser mais produtivos se estivermos mais focados nas decisões tecnológicas e regras de negocio da aplicação (só para citar alguns) e menos focado em infra-estrutura do projeto.
A idéia é ir mais direto ao ponto sobre as necessidades do cliente ou dos projetos usando uma IDE fácil, intuitiva, com muitos recursos e customizável.

Para visualizar o site do projeto, acesse: http://www.j2eespider.org

Palestras J2EE Spider

Bruno Braga on October 23rd, 2007

Em agosto foi publicado no Jornal da Universidade FUMEC (na qual fiz graduação) a seguinte notícia:


fonte: http://www.fumec.br/jornal/?p=306

Além disso fui convidado e estarei realizando uma palestra sobre o projeto amanhã dia 24 a noite e dia 25 de manhã na FUMEC.

E aproveitando o embalo, dia 26 estarei na UFOP apresentando uma palestra sobre o mesmo assunto no III Workshop de Computação UFOP / UNIPAC.

Segue o link do evento:

http://www.unipacto.com.br/workshop

Aproveitando o assunto sobre o projeto, espero terminar a parte de CRUD até o fim do ano (tempo é um grande problema) e realizar mais algumas palestras em outros lugares ano que vem. Até lá… =)

Novo Artigo

Bruno Braga on May 14th, 2007

Já está nas bancas meu novo artigo na revista Mundo Java.
Dessa vez falando sobre um projeto Open Source que eu estou desenvolvendo.

O tema principal do artigo é sobre como aumentar a produtividade em projetos JEE.

Não deixem de ler. A revista (número 23) trás ainda vários assuntos interessantes ligados a detecção e eliminação de bugs.

Uma introdução sobre o tema que escrevi: “Qual desenvolvedor ou empresa não quer ganhar produtividade, eliminar as tarefas repetitivas do dia-a-dia, diminuindo custos e prazos do desenvolvimento de projetos? Não podemos dizer que são tarefas fáceis, mas também não são impossíveis. Vamos mostrar como conseguir isso neste artigo…”