Alberto Leal

Pessoal,

antes de iniciar o post, gostaria de agradecer à todos que estão me mandando emails, mensagens via twitter, via chat, agradecendo a série de dicas sobre Git. Para mim está sendo bastante prazeroso escrever sobre esse assunto.

Visando melhorar a série, estou adicionando um arquivo para download com o conteúdo desse post formatado. Não sei ao certo se isso vai ser bacana, para isso, preciso do feedback de vocês. O que vocês acham dessa opção de download do artigo formatado?

Obrigado, e boa leitura..

Cenário: Você vêm trabalhando há um bom tempo em um branch. Mas, para facilitar o seu trabalho na hora de fazer o merge no repositório central, visando diminuir a quantidade expressiva de conflitos a serem resolvidos de uma única vez ao final do desenvolvimento, você faz diariamente um rebase com o repositório principal.

O projeto: O projeto em que estou trabalhando é um projeto Java. Estou fazendo algumas implementações de padrões de projeto utilizando a linguagem Java. A estrutura do projeto é a seguinte:

O pacote contendo o padrão decorator está aberto, pois utilizaremos ele como exemplo.
Executando o comando git log, você verá todos os commits já realizados:

$ git log
commit d2e78a824c98c98a0eec6d083533f36dc35a7bfa
Author: Alberto Leal <albertonb@gmail.com>
Date:   Mon Jun 8 20:48:00 2009 -0300
 
Adding Factory Method
 
commit be3a2a8d22536d427098eaa8bd474f7cb8944bcc
Author: Alberto Leal <albertonb@gmail.com>
Date:   Mon Jun 8 20:47:46 2009 -0300
 
Adding Command
 
commit a0e3a5e1fe3f4c31a3bc3f20283b58ed0d16fc7b
Author: Alberto Leal <albertonb@gmail.com>
Date:   Mon Jun 8 20:47:38 2009 -0300
 
Adding Decorator
 
commit a33c008642c24028477a9c1e7e7d5fca6661c7c9
Author: Alberto Leal <albertonb@gmail.com>
Date:   Mon Jun 8 20:47:26 2009 -0300
 
Adding Abstract Factory
 
commit 52e4505b66ab91f2a8e8511b79ace49aa407e333
Author: Alberto Leal <albertonb@gmail.com>
Date:   Mon Jun 8 20:47:10 2009 -0300
 
Adding Observer

Repare que o padrão decorator foi o terceiro a ser implementado e comitado no git. Como estamos no último commit, conseguimos visualizar normalmente todas as alterações/inserções que nele se encontram.

Até o momento, estamos no branch principal, no master. Mas, foi solicitado a adição de um novo atributo na classe Pizza, chamado “size” que dirá se pizza é “pequena, média ou grande”.  Para realizar tal tarefa, cria-se um novo branch chamado “Ticket123”:

$ git checkout -b Ticket123

Agora que já estamos no branch relacionado ao ticket, fazemos a adição do novo atributo na classe Pizza. Eis o código da classe Pizza após a alteração:

package br.eti.albertoleal.decorator;
 
public abstract class Pizza {
 
private String description = "Unknown Pizza";
private String size;
 
public String getSize() {
return size;
}
 
public void setSize(String size) {
this.size = size;
}
 
public void setDescription(String desc) {
description = desc;
}
 
public String getDescription(){
return description;
}
 
public abstract double cost();
 
}

Imagine que durante 1(uma) semana você ficou trabalhando em uma série de alterações no código acima, ou até mesmo em outros. E como citado no cenário, ao final do dia você sempre faz um rebase com o projeto original para poder pegar as

alterações de outros desenvolvedores e manter o seu branch atualizado, consequentemente com uma quantidade menor de conflitos a serem resolvidos quando você for fazer a entrega do seu branch.

Para ficar mais evidente o que eu quero mostrar, crie um novo arquivo ou simplesmente faça alguma outra alteração em um código já existente, e depois faça o commit.  Aqui, eu vou criar um arquivo chamado “TestAprendendoGit.java”

Assim como você, existem outros desenvolvedores criando branch a partir do master e fazendo merge no mesmo.

Após um longo dia de trabalho, chegou a hora de fazer o rebase:

$ git rebase master
 
First, rewinding head to replay your work on top of it...
Applying: Adding a new field in the Pizza
error: patch failed: src/br/eti/albertoleal/decorator/Pizza.java:3
error: src/br/eti/albertoleal/decorator/Pizza.java: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging src/br/eti/albertoleal/decorator/Pizza.java
CONFLICT (content): Merge conflict in src/br/eti/albertoleal/decorator/Pizza.java
Failed to merge in the changes.
Patch failed at 0001 Adding a new field in the Pizza
 
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort"

Oooops, conflito! Algum desenvolvedor fez alguma alteração na classe Pizza também.

Agora que vem o susto! Cadê o tal arquivo “TestAprendendoGit.java” que foi criado?

Quando você começa a fazer um rebase você não está em nenhum branch, você se encontra em uma área “neutra”, vamos por assim dizer. Não acredita em mim?! Agora que você já iniciou o seu rebase e obteve os conflitos, execute o comando:

git branch
* (no branch)
Ticket123
master

Viu só? =)

Quando eu falei que o git pode te assustar, o que eu queria dizer é o seguinte: Para aqueles que não estão acostumados com a forma que o Git trabalha, levará um baita susto ao ver que os arquivos e/ou alterações que ele criou, depois do commit que deu o conflito, “sumiram”. Não sumiu nada! Eles estão lá apenas aguardando você resolver todos os conflitos e executar todos os comandos “git rebase –continue” até chegar no último commit, o qual possui o estado final do seu código. Agora que terminou de resolver todos os conflitos e o rebase, olha o arquivo aí de novo (TestAprendendoGit.java):

Tentado exemplificar  um pouco mais…

Como o rebase funciona?
O rebase analisa commit a commit. Ou seja, ele pega todo o seu histórico de commits e analisa um a um, do primeiro até o último!

Como um rebase pode te assustar?
Vamos supor que você tenha 5 commits. Você fez uma mudança específica no último commit, ok? Enquanto o rebase estava sendo executado, foi constatado um conflito no 2º commit. Então, para continuar com o rebase você deve fixar o(s) conflito(s).
Com isso, como o rebase se encontra no 2º commit, você não é capaz de ver as mudanças realizadas nos commits posteriores. Se você tentar encontrar aquelas alterações feitas nos commits acima, você não conseguirá visualizá-las.

Há algum tempo eu ganhei de presente da minha noiva um cubo mágico. Sim, um cubo mágico, ou cubo de Rubik se preferir. Há tempos eu  estava procurando por um, até que ela encontrou em São Paulo e me deu de presente. Desde então eu venho “desperdiçando” algumas horas diárias para tentar resolvê-lo.

Alguns amigos comentaram que existem diversos macetes, tutoriais de como resolver um cubo, bastava eu procurar no Google. Não tive interesse em lê-los, mas sim tentar por mim mesmo entendê-lo e resolvê-lo.

O meu cubo mágico é um dos mais tradicionais, de 6 (seis) lados.

Mas, o que um cubo mágico tem haver com a nossa área de desenvolvimento de software?

Após resolver um dos lados do cubo, não teve como não fazer uma analogia com a nossa área. Nela, lidamos com diversos lados áreas, tais como: infra-estrutura. desenvolvedores, arquitetos, designers, clientes, entre outros. Todos sabemos o quão difícil é manter a perfeita harmonia entre essas áreas. O mais importante é a  comunicação utilizada por elas, de modo a manter a perfeita integração, a sincronia entre os times.

Algumas vezes, cada lado área tem seu próprio interesse, pensam em resolver do seu jeito, mesmo que esse não seja a melhor opção para o negócio do cliente. Tentam de qualquer maneira vender a própria solução para o cliente, só por achá-la mais conveniente, rápida e prática de se implementar. E repito, mesmo sabendo que essa não seria a melhor solução para o negócio do cliente. Isso existe sim, e somos obrigados a lidar com esse cenário, muitas vezes.

Mesmo que já exista uma solução “genérica” que atenda apenas alguns requisitos do cliente, não tente empurrá-la goela abaixo em seu cliente. Se essa solução, realmente, tiver como ser customizada com os requisitos que o cliente deseja, e retirar aqueles que o cliente não irá utilizar, facilmente, aí sim. Pois, desse modo você estará utilizando essa solução “genérica” como um ponto de partida.

Voltando ao nosso cubo mágico….

Não adianta resolver, apenas, um lado de um cubo mágico. Esse não é o objetivo, e sim resolver todos os lados. E para atingir esse objetivo, dificilmente você conseguirá resolver cada lado isoladamente, isto é, você não conseguirá resolver o lado branco, depois resolver o lado azul, em seguida o vermelho e assim por diante. Todos os lados devem ser movidos em conjunto até chegar o momento em que todos os lados estarão resolvidos.

Assim como ocorre com o cubo mágico, no desenvolvimento de software não adianta apenas resolver uma lado área. Mesmo que cada lado área tenha o seu próprio objetivo para atingir, todas devem trabalhar em conjunto para que o objetivo maior seja atingido, que é: Resolver o problema do cliente da melhor forma possível.

Vamos tentar imaginar o que acontece quando cada lado área resolve o seu objetivo isoladamente. De que adianta o Designer fazer uma bela arte para a parte visual, e os desenvolvedores não fazerem o “dever de casa”, isto é, integrar a aplicação com a arte feita pelo Designer? De que adianta o Designer fazer o “dever de casa”, o desenvolvedor idem, mas a equipe de infra-estrutura não disponibilizar um ambiente de produção para a aplicação? Acho que já deu para perceber o quanto uma lado área depende uma das outras, e como todas devem caminhar em conjunto.

Concluindo:

• Mantenha os seus times sólidos, integrados, coesos;
• Utilize dos mais diversos tipos de comunicação entre eles, estimule sempre o trabalho em equipe entre os times, não somente dentro dos times;
• Dê sempre ouvidos ao seu cliente.  Coloque-o em primeiro lugar. Falando assim é bonito, soa bem. Mas nem sempre isso acontece. Você só coloca o seu cliente em primeiro lugar a partir do momento o qual você, ou sua empresa, começa a olhá-lo como pessoa, ao invés de olhá-lo apenas como o cara que vai colocar a mão do bolso e pagar as contas da sua empresa.

Cenário: Seu cliente utiliza um outro SCM, por exemplo, o Harvest, no projeto o qual você trabalha. Mas, você e sua equipe resolvem utilizar o Git. Eis que você faz uma série de scripts de automação para pegar o seu release no Git e entregá-lo ao Harvest. Bacana, não? Para que isso funcione perfeitamente, você deve passar para o sistema de automação o nome dos arquivos que foram alterados, desse jeito, não será necessário enviar arquivos que sequer sofreram modificações, o que é bem interessante, diga-se de passagem.

Legal, existe o comando git whatchanged. Você pode passa como parâmetro o total de commits que você deseja analisar, utilizando a opção -n. Se você omití-lo, todas as modificações serão exibidas. (Se você informar o parâmetro -p, serão exibidas as modificações dentro dos arquivos).

Vamos dar uma olhada na saída desse comando:

$ git whatchanged -n 3
commit 8d726556aec75e1d6ef5ae477532fcc11770ac01
Author: Alberto Leal
Date:   Wed Jun 3 16:04:23 2009 -0400
 
Message 3
 
:100755 000000 0615380... 0000000... D  workspace/xxx/yyy/cfgXPTO.jnlp
:100755 000000 37076cc... 0000000... D  workspace/xxx/yyy/packageXYZ.jar
 
commit 3ab3a5e95fa031d8eb93154d161bfba228bc5f86
Author: Alberto Leal
Date:   Wed Jun 3 15:38:00 2009 -0400
 
Message 2
 
:100755 100755 849dc69... 1e7ef9d... M  workspace/xxx/src/com/xxx/yyy/ModelXYZ.java
:100755 100755 9828364... d85e5ee... M  workspace/xxx/WebContent/WEB-INF/jsp/viewXYZ.jsp
:000000 100755 0000000... d034c28... A  workspace/xxx/WebContent/htmlXPTO.html
 
commit 7e076b5130340f28e57526cf71ce96d7cc279538
Author: Alberto Leal
Date:   Wed Jun 3 10:04:56 2009 -0400
 
Message 1
 
:100755 100755 9c322de... 9828364... M  workspace/xxx/WebContent/WEB-INF/jsp/anotherXTPO.jsp

Repare que se você quiser pegar os arquivos modificados, você terá que copiar um a um. Trabalhoso, não? Existem diversas maneiras de se recuperar apenas os nomes dos arquivos. Uma sugestão seria:

def files_changed(commits, last_commit)
  File.open(commits, "r") do |infile|
  infile.each_line do |line|
    if line.include? last_commit
      break
    else
      er = line.match(/workspace(.*)/)
      puts er unless er.nil?
    end
  end
  end
end
 
files_changed(ARGV[0], ARGV[1])

Execute o seguinte comando no seu terminal para obter o resultado desejado:

$ git whatchanged > files.txt && ruby files_changed.rb files.txt 7e076b513

Se você quiser, simplesmente, pegar todos os arquivos modificado, você pode executar o comando abaixo:

$ git whatchanged | grep workspace | awk '{print($6)}'

Fica aí mais uma dica. Afinal, seria bem chato ter que copiar arquivo por arquivo =)

Olá Pessoal,

Quando você utilizava o SVN ou CVS, provavelmente, você já utilizou ou ouviu falar do Tortoise. Agora, você já pode utilizá-lo junto com o Git.

Sua equipe utiliza Git na empresa? Você quer ver quem anda comitando mais?

Algumas pessoas me perguntaram como fazer para obter tal resultado. Há algum tempo eu twittei sobre isso.

Para aqueles que acompanham o meu blog, mas não me acompanham no twitter, aí vai a dica. A maneira de ver o total de commits de cada commiter em um projeto que utiliza o Git, como controlador de versão, é:

1

git shortlog -s -n --all

(O tweet está aqui.)

Ok. Mas agora você quer ver o total de commits apenas nos repositórios remotos? O comando é:

1

git rev-list --remotes --pretty=short

(O tweet está aqui.)

Cenário: Você trabalhou durante dias em um branch. Fez vários commits nele. E…., após algumas discussões, ficou decidido que algumas das suas modificações não entrarão na próxima build. A idéia das mensagens ao se fazer um commit é ajudar na identificação daquele commit específico.  Você pode analisar estas mensagens e remover alguns commits com base em tais mensagens. Mas, às vezes, só isso não basta para você. Você quer analisar antes alguns commits para ter certeza de que somente as alterações desejáveis, sejam adicionadas na build. Comando: git whatchanged Ps: As mensagens foram alteradas propositalmente. Utilize mensagens significativas em seus commits.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

commit d9a472455d9f91c75465af9778f5271baf532813
Author: Alberto Alvine <albertonb@gmail.com>
Date:   Thu May 28 14:14:39 2009 -0400
 
    Message 7
 
commit 6251f4b532d0c602e41742ab6399b637b14596c8
Author: Alberto Alvine <albertonb@gmail.com>
Date:   Wed May 27 15:51:56 2009 -0400
 
    Message 6
 
commit e71160c9fc1f676e94c4fe732f169e153731bf4c
Author: Alberto Alvine <albertonb@gmail.com>
Date:   Tue May 26 13:18:03 2009 -0400
 
    Message 5
 
commit e91d5a2171f8a4edcb60004967bad847339046d8
Author: Alberto Alvine <albertonb@gmail.com>
Date:   Thu May 21 15:31:49 2009 -0400
 
    Message 4
 
commit b514e967f01f579faab27f84017897d017810038
Author: Alberto Alvine <albertonb@gmail.com>
Date:   Thu May 21 10:23:50 2009 -0400
 
    Message 3
 
commit c59d02c18bfeff297f91fc2f06247e82ff77b741
Author: Alberto Alvine <albertonb@gmail.com>
Date:   Tue May 19 09:18:37 2009 -0400
 
    Message 2
 
commit 48b5d388ad78dbc260a3afd164c6b46cca7b9e51
Author: Alberto Alvine <albertonb@gmail.com>
Date:   Wed May 13 09:46:28 2009 -0400
 
    Message 1

Para visualizar quais foram as alterações em todos commits, execute git whatchanged -p. Esse comando mostrará os diffs de todos os arquivos que foram alterados. Se for desejável apenas visualizar os arquivos que sofreram alterações, execute apenas git whatchanged, sem parâmetro. Este comando foi útil para mim. Fica aí mais uma dica =) UPDATE 1: Esqueci de mencionar: Na hora de executar o git revert, você deve executá-lo de forma inversa, isto é,  vamos imaginar que você deseja desfazer os 2 últimos commits, o primeiro revert vai ser para o último commit, e o segundo revert para o penúltimo commit.

Photo by acranmer (http://www.flickr.com/photos/acranmer/2557035443/)

Esse post estava há algum tempo na minha lista de Draft, chegou a hora dele sair de lá..

Não pretendia escrever sobre o assunto.  Mas, depois de ler várias opiniões de pessoas bem conhecidas falando sobre o assunto aqui, aqui e aqui, e os respectivos comentários da comunidade , refleti durante alguns minutos e senti vontade de  contribuir, de certa forma, com o meu ponto de vista sobre os assuntos: Faculdade, diplomas, certificações e afins.

Esse assunto é muito difícil de se debater. Toda vez que alguém toca nele, logo surge um flame war. Afinal, cada um tem seu ponto de vista, e muitos querem, de alguma maneira, impor a sua opinião como verdade absoluta. Uma coisa é fato: Não existe verdade absoluta para esse assunto. Ninguém está mais certo ou mais errado. Existem empresas que exigem profissionais certificados, graduados, com inglês, espanhol, alemão, enfim. Não podemos generalizar e falar que empresas como esse perfil estão seguindo o caminho errado, pois, muitas vezes, são os próprios clientes que exigem isso.

Diplomas, certificações, faculdade, isso tudo é sinônimo de qualidade no processo, qualidade do software no momento da entrega? resposta é simples: Não. Mas, então, por que será que alguns clientes exigem isso dos contratados?

Nossa área está repleta de picaretas. Pessoas que vendem gato por lebre. Todos nós estamos carecas de saber disso. Não fiz nenhum teste de campo para tentar provar o que vou dizer agora. São apenas minhas próprias opiniões, coisas que acredito que levam alguns clientes a pensarem/exigirem profissionais com diplomas/certificações.

Começando pelas faculdades. Todos sabemos que não é fácil ficar 4 anos dentro de uma faculdade. Ainda mais quando é necessário conciliar trabalho e estudos. Apesar de serem 4 anos, não quer dizer que os alunos sairão lá de dentro altamente capazes de desempenhar atividades na área. A faculdade é apenas um ponto de partida para aqueles que desejam ter uma visão geral das áreas e identificar lá dentro aquela que melhor lhe agrada, aquela que lhe desperte paixão em se trabalhar nos próximos anos de sua vida. Até mesmo porque existem pessoas que saem da faculdade e sequer trabalham na área. Durante a faculdade você vê muita coisa superficialmente, e se você desejar aprender realmente algum assunto você deve estudar e correr por fora - blogs, livros, fóruns, são bons exemplos. Faculdade é um bom lugar para se conhece pessoas, também.

Certificações, assim como diploma, não quer dizer que o profissional é “O Cara”. Não quer dizer que ele sabe tudo. Ele apenas se deu o trabalho de estudar o que caia na prova e foi lá e fez. Simples assim. Então, por que algumas empresas exigem profissionais com certificados? Meu ponto de vista é o seguinte: Certificações não mostram o quanto você sabe, não fazem de você um cara melhor do que o cara que não tem nenhuma certificação. Elas, apenas, mostram o seu interesse em estudar a fundo sobre o determinado assunto e fazer uma prova para, simplesmente, testá-lo. Elas refletem o seu esforço! Desde cedo somos obrigados a fazer testes, provas. Quem não se lembra da frase: “Teste é para testar e prova é para provar”, rs. Lá atrás, quando ainda estávamos no CA, 1ª série, já fazíamos exames na escola. E, foi assim durante grande parte da vida de muitos. Depois da escola, vestibular, e em seguida, provas dentro da faculdade.

Por que fizemos provas durante a escola, faculdade? Essas provas garantiam que você sabia alguma coisa? Tais provas eram suficientes para você colar na testa um atestado de “Sou Foda em Cálculo”? Só porque você foi bem sucedido em qualquer exame durante a sua vida, não quer dizer que você sabe tudo. Ás vezes você deu sorte, pois o professor selecionou questões que você mandava bem, daí você foi lá e arrebentou!

O que quero dizer é o seguinte: Não olhe para profissionais com certificações e diplomas como se eles soubessem mais do que você. Ele apenas se deu o trabalho de estudar o conteúdo e fazer uma prova. Mas, também não olhe para seus diplomas e certificações como se não valessem de nada. Pois você pode estar dando um tiro no próprio pé, já que você fez coisas semelhantes durante boa parte da sua vida! Não esqueça que para passar de ano/vestibular você fez provas. Talvez esses métodos de avaliação não seja o melhor, mas não quero entrar nesse mérito aqui.

Agora, sem hipocrisia. Existem profissionais que tentam N vezes passar em 1 prova de certificação, e depois tiram outras 10 certificações e apóiam o movimento “Certificação não vale nada”. Pra quê investir tanto dinheiro e tempo para fazer provas de certificação, falar que as detêm e sair por aí a fora cantando de arquiteto de software ou sei lá mais o quê?! Primeiramente, devemos ser honestos conosco mesmo. Um cara não se torna arquiteto só porque ele têm XPTO certificações, todas tiradas em 2, 3 anos de estudos e provas. Alguém se torna um bom arquiteto de software com a experiência, com o tempo, enfrentando os mais diversos problemas no dia a dia. Já perdi as contas de quantas vezes eu já escutei algo do tipo: “Ah, o professor Y não é muito bom. Ele não conhece o mercado de trabalho, se conhecesse não estaria ensinando essa teoria. As coisas não funcionam desse jeito aí.”. É praticamente impossível viver só de teoria na nossa área, por isso, afirmo que um bom profissional se faz com o tempo. O tempo e os desafios são os responsáveis por lapidar um bom profissional. Lógico que, para isso uma boa base teórica faz toda a diferença, mas não devemos ficar presos, somente, a ela.

Outro assunto bastante delicado é a regulamentação da profissão. Não sou a favor dessa regulamentação. Acho isso a coisa mais idiota que existe! Existem profissionais no mercado que sequer possuem qualquer documento e são melhores do que outros que são formados e possuem 10,15,20 certificações. Existem pontos fora curva, com certeza! Pessoas sem faculdade, sem certificações, sem quaisquer papel que possa comprovar seu esforço nos estudos perante o mercado. Mas se pessoas com esse perfil quiserem se fazer percebidas, devem mostrar a cara. Contribuir com projetos open source, ajudar a comunidade em fóruns, dar palestras. Do contrário, acho que o caminho será mais árduo. O que não quer dizer que é impossível.

Como foi citado, não existe o dono da verdade quando tocamos nesse assunto. Cada um tem o seu ponto de vista, e , esse foi o meu!

Falando em Java 2009: O que falar do evento desse ano de 2009? Sem sombra de dúvidas, o evento foi adorado por todos da comunidade, por todos aqueles que estavam presentes.

Confesso  que o evento superou as minhas expectativas. Esperava um bom evento, como pude constatar pelos comentários em blogs e fóruns de discussão relacionados aos anos anteriores. Mas, em minha opinião, o evento foi ótimo! Extremamente profissional, palestras de altíssimo nível, além de uma ótima organização. Acredito que todo o esforço por parte da Caelum não foi em vão, afinal, o evento teve uma boa aceitação por parte da comunidade.

Nesse ano, o evento contaria com duas palestras internacionais: A primeira com Jim Webber da Thoughtworks e Bill Burke. Porém,  Bill Burke não pôde marcar presença no evento devido a problemas com visto. Mas, nem por isso deixamos de ter uma excelente palestra sobre web services. Jim Webber deu conta do recado e conduziu a palestra no lugar de Bill Burke. Muito simpático e bem-humorado (a galera se divertiu de montão com suas piadas), Jim Webber nos presenteou com duas ótimas palestras: a primeira “Guerrilha SOA” e a segunda “Web services Rest”.

As demais palestras foram comandadas, basicamente, pelos integrantes do time da Caelum. Paulo Silveira e Rafael Cosentino mandaram ver na palestra “O profissional Java Efetivo”. Foram bastante felizes com os exemplos apresentados. Além de divertidos, prenderam facilmente a atenção do pessoal. Falaram, dentre diversas coisas,  quais as melhores técnicas para se fazer a integração entre sistemas, onde se deve analisar cada necessidade e escolher a técnica que  melhor se aplica.

A palestra de Alessandro Lazarotti e Ricardo Nakamura, “JBoss Seam e WebBeans”, contou com exemplos práticos, codificados ali mesmo, na hora. Onde a dupla apresentou como JBoss Seam trabalha com DI -Dependency Injection.

A palestra de Felipe Sabella e Guilherme Silveira sobre a nova versão do “VRaptor3 foi bem interessante. Ambos apresentaram as novas melhorias que estarão disponíveis no framework. Melhorias estas retiradas do trabalho do dia a dia. Fábio Kung também falou um pouco. Falou que um dos frameworks que inspirou algumas mudanças, como roadmap, foi o Rails. Existe, também, a possibilidade de se escolher o que será retornado para o usuário: xml, atom, html..Bem rails-like.

Guilherme Moreira e Sergio Lopes apresentaram a palestra “Arquitetura para aplicações Java de médio porte”. Apresentaram diversos erros comuns que desenvolvedores cometem quando estão trabalhando com Hibernate. Além de mostrar exemplos com cluster, load balance.

Para onde vai a Plataforma Java? Linguagens dinâmicas, JavaTV, JavaFX e além!” Essa palestra foi maestrosamente apresentada por Anderson Leite e Fabio Kung. Impressionante a forma como a dupla apresentou as novas mudanças que surgirão na plataforma Java. Uma frase de Fábio que me chamou bastante atenção foi: “[ ...]a idéia é tornar a plataforma Java  uma casa melhor para as linguagens dinâmicas[...]“.

O evento foi palco de muitas novidades. Uma delas foi que o pessoal da Caelum está escrevendo um livro com o seguinte título: “Arquitetura e Design de Software”. Sem dúvidas, este livro será de altíssimo nível. Não tenho o hábito de ler livros em português. O que me impulsou a ter essa postura foi a má qualidade das traduções. Mas esse livro será, com certeza, um dos melhores livros sobre arquitetura e design escrito em português. Basta acompanhar o que essa galera faz pela comunidade em geral para ter certeza disso. Assim que sair, quero garantir o meu! Para maiores informações, acesse: http://www.arquiteturajava.com.br/

Com certeza estarei presente nos próximos anos! E, espero poder re-encontrar toda a galera do CEJUG, ESJUG, Gujeiros e twitteros. Até lá, pessoal…