Alberto Leal

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…

Dando sequência aos posts sobre GIT, aí vai mais uma dica: Como quebrar um commit e cancelar algumas alterações.

Assim como os posts anteriores, esse post foi inspirado em um problema que o meu time enfrentou semana passada.

Cenário: Foi feito o push de um commit contendo várias alterações no código. Porém, após ter sido feito o code review foi detectado que algumas mudanças não seriam mais necessárias, e/ou deveriam ser implementadas de outra forma. Claro que seria possível ir no código fonte e ir apagando todas as alterações que foram feitas. Mas, será que essa “limpeza” sairia às mil maravilhas? Será que o código voltaria a ficar da mesma forma que antes das alterações terem sido feitas? Acho difícil!

Elaborei um pequeno exemplo, apenas, para tentar ilustrar o cenário acima.

Temos os seguintes commits em nosso Projeto:

Repare que foi criado um branch para resolver um defeito, no nosso caso, foi adicionar um novo campo, País. Mas por algum motivo o registro de idade foi alterado acidentalmente.

No caso acima, é fácil ir ao arquivo e desfazer as alteração incorreta no campo “idade” antes de fazer o rebase/merge, eu sei. Mas, tente imaginar códigos reais, complexos, onde voltar ao código fonte e desfazer as alterações não seria a melhor solução =)

Uma solução para trazer todas as alterações e escolher o que vai ser efetivado para o merge/rebase é trazer o commit de volta para o stage do git para trabalhar nas alterações. Para isso, vamos utilizar o comando git format-patch para recuperar os commits. Em seguida, criaremos um novo branch para trabalharmos nas modificações e finalmente fazer o rebase com o branch master:

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

Alberto:ProjectX Alberto$ git branch
* Defect123
  master
Alberto:ProjectX Alberto$ git status
# On branch master
nothing to commit (working directory clean)
 
Alberto:ProjectX Alberto$ git log
commit ea4f2953c305b0453fd20f27b3043ebf96d541df
Author: Alberto Leal <albertonb@gmail.com>
Date:   Sat May 23 15:42:16 2009 -0300
 
    Adding new fields
 
commit 656236111360762d92f9efacb05e27b5cd067a04
Author: Alberto Leal <albertonb@gmail.com>
Date:   Sat May 23 15:41:35 2009 -0300
 
    Some new changes
 
commit 131519b37c1d1415e962d6fd23d4058c93438870
Author: Alberto Leal <albertonb@gmail.com>
Date:   Sat May 23 15:40:40 2009 -0300
 
    Initial Commit
Alberto:ProjectX Alberto$ git format-patch master
0001-Some-new-changes.patch
0002-Adding-new-fields.patch

Repare que os patches foram gerados  a partir do Defect123 em relação ao branch master, ou seja, somente as diferenças entre eles.

Para escolher quais as modificações vão entrar para fazer o merge/rebase com o master, é necessário que se crie um novo branch a partir do master - limpo, sem as modicações de Defect123 e use o comando git apply para aplicar os patches no stage.  Agora que os patches com os últimos commits já foram gerados, chegou a hora de jogá-los novamente no stage:

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

Alberto:ProjectX Alberto$ git checkout master
Switched to branch "master"
Alberto:ProjectX Alberto$ git checkout -b Defect123_Changes
Switched to a new branch "Defect123_Changes"
Alberto:ProjectX Alberto$ git apply 0001-Some-new-changes.patch
Alberto:ProjectX Alberto$ git apply 0002-Adding-new-fields.patch
Alberto:ProjectX Alberto$ git log
commit 131519b37c1d1415e962d6fd23d4058c93438870
Author: Alberto Leal <albertonb@gmail.com>
Date:   Sat May 23 15:40:40 2009 -0300
 
    Initial Commit
Alberto:ProjectX Alberto$ git status
# On branch Defect123_Changes
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   config.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       0001-Some-new-changes.patch
#       0002-Adding-new-fields.patch
no changes added to commit (use "git add" and/or "git commit -a")

Veja que o arquivo config.txt foi alterado. Agora, vamos adicionar as alterações para serem comitadas, mas para isso vamos utilizar o comando git add -p (similar ao add interativo):

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

Alberto:ProjectX Alberto$ git add -p config.txt
diff --git a/config.txt b/config.txt
index ac82771..b36405c 100644
--- a/config.txt
+++ b/config.txt
@@ -1,6 +1,8 @@
 Nome: Alberto Leal
-email: albertonb@gmail.com
-idade: 24
+Email: albertonb@gmail.com
+Idade: 2423434
 Empresa: IBM
+Telefone: 12-1234-5678
+País: Brasil
 Sexo: Masculino
 Estado civil: solteiro
Stage this hunk [y/n/a/d/s/?]? s
Split into 2 hunks.
@@ -1,4 +1,4 @@
 Nome: Alberto Leal
-email: albertonb@gmail.com
-idade: 24
+Email: albertonb@gmail.com
+Idade: 2423434
 Empresa: IBM
Stage this hunk [y/n/a/d/j/J/?]? n
@@ -4,3 +4,5 @@
 Empresa: IBM
+Telefone: 12-1234-5678
+País: Brasil
 Sexo: Masculino
 Estado civil: solteiro
Stage this hunk [y/n/a/d/K/?]? y

Utilizando o comando acima, podemos quebrar as alterações feitas no arquivo utilizando a opção “s” (split). Após, você informa se deseja adicionar os fragmentos ao stage, utilizando as opções “y”- yes e “n”- no. Todos os fragmentos que você desejar adicionar no stage para comitá-lo, utilize a opção “y”. No pequeno exemplo acima, apenas foi mantido no commit a adição dos novos campos: Telefone e País. A alteração equivocada no campo “idade”foi eliminada do commit. Só nos resta efetivar as alterações comitando as mundanças:

1
2
3
4
5
6
7
8
9
10
11
12
13

Alberto:ProjectX Alberto$ git commit -m 'Cutting branch'
Created commit 9e365a2: Cutting branch
 1 files changed, 2 insertions(+), 0 deletions(-)
Alberto:ProjectX Alberto$ git checkout config.txt
Alberto:ProjectX Alberto$ cat config.txt
Nome: Alberto Leal
email: albertonb@gmail.com
idade: 24
Empresa: IBM
Telefone: 12-1234-5678
País: Brasil
Sexo: Masculino
Estado civil: solteiro

Cuidado para não adicionar o arquivo novamente ao stage (git add config.txt). As alterações que você fez já estão lá, prontas para serem comitadass. Se você se esquecer e adicionar o arquivo novamente ao stage, você perderá todas as mudanças que você fez no add interativo. É aconselhável que, logo após o comando git commit, você execute git checkout <file>, como mostrado acima. Desse jeito, você pegará o arquivo que está no repositório atualizado.

Agora, só nos resta fazer o rebase com o branch principal:

1
2
3
4
5

Alberto:ProjectX Alberto$ git checkout master
Switched to branch "master"
Alberto:ProjectX Alberto$ git rebase Defect123_Changes
First, rewinding head to replay your work on top of it...
Fast-forwarded master to Defect123_Changes.

É isso pessoal! Espero que a técnica apresentada nesse post lhe seja útil algum dia, assim como foi para mim.

Abraços!

Foi no ano passado que comecei a utilizar o GIT como VCS padrão. Naquela ocasião, não tinha  muitos problemas de conflitos, já que o “time” era pequeno - só eu =)

Hoje, faço parte de um time de 8 desenvolvedores. Já dá para imaginar que problemas na hora de fazer o rebase/merge já começam a aparecer com uma certa frequência. É gente comitando o dia inteiro!

Quando alguém no time cria um branch remoto, e trabalha nele o dia inteiro, por exemplo, ao final do dia é possível existir uma quantidade de commits consideráveis. Mas, na hora de enviar essas alterações para o repositório - git push - pode não ser necessário enviar todo aquele histórico de commits, apenas o resultado final interessa. Mas, dá para fazer isso? A resposta é: Sim, dá!

Mas atenção, somente faça isso em commits que ainda não foram enviados para o repositório externo. Pois se isso já tiver acontecido, outro desenvolvedor pode ter feito outras alterações e os conflitos aparecerão para lhe trazer dor de cabeça.

A idéia é utilizar git rebase –interactive, ou simplesmente git rebase -i.

Imagine o seguinte cenário: Você precisa trabalhar em um defect, e para isso você cria um branch para trabalhar nele. Ao longo do seu trabalho, você vai fazendo vários commits para manter o status do seu trabalho, já que de vez enquando você precisa pular para outro branch para resolver outra coisa, ou simplesmente testar alguma funcionalidade em outro branch que seu chefe lhe pediu (E, dependendo da situação, utilizar git stash não é a solução). Na hora de fazer o push, você só precisa enviar o defect resolvido. Se você desejar juntar todos os commits em um único commit que represente aquele seu defect, siga os passos abaixo:

Veja que temos 4 commits em nosso repositório. E desejamos unir os três últimos commits. Para isso, vamos utilizar o comando que foi citado anteriormente:

git rebase -i master~3

O comando acima diz para fazer o rebase interativo de 3 commits a partir do master. Feito isso, será aberto um editor para que você faça as devidas alterações:

Marque os últimos commits que você deseja juntar com o primeiro com a palavra squash. Feito isso, salve o documento e um novo editor será aberto para que você informe a mensagem para esse novo commit.  No exemplo abaixo, eu deixei as mensagens de todos os commits, mas é permitido que você informe a mensagem que desejar.

Observe que, agora temos apenas 2 commits, ao invés de 4:

Bastante útil. Mas, use apenas se você realmente não precisar do histórico desses commits.

UPDATE 1: Execute git rebase –continue para consolidar as alterações.

Se você, assim como eu, já precisou alterar a mensagem de um commit no git, aí vai uma dica:

Antes, uma observação: se você já fez o push do commit que você deseja alterar a mensagem, não faça nenhuma alteração! Isso pode causar uma série de conflitos com os demais abaixo do seu commit.

Alterando a mensagem

Primeiro, é necessário escolher um commit abaixo daquele que será alterado. Para isso, dê um git log para listar os commits:

Feito isso, escolha o commit, o qual a partir dele os commits acima poderão ser alterados e dê um git rebase -i <commit>:

git rebase -i 24eb338

Com o editor aberto, marque com a palavra EDIT os commits que você deseja alterar. Salve o arquivo e feche o editor:

Agora, para abrir o editor e alterar os commits que você marcou como EDIT, execute git commit –amend:

Altere a mensagem do commit e está pronto!

Observe que o commit agora tem outro hash - dê git log para visualizar a alteração-, pois, essa tarefa de alterar a mensagem de um commit faz com que o GIT gere um novo commit.

Acontecerá no próximo dia 24 o Falando em Java 2009. O evento já está em sua terceira edição. Infelizmente, não pude participar dos eventos anteriores. Mas, neste ano, estarei presente.

O evento contará com boas palestras, e promete ser bem interessante. Além de que, será uma ótima oportunidade de conhecer, pessoalmente, uma galera que já venho conversando pela internet - twitter, gtalk, msn e fóruns.

Então, nos vemos lá!