Pessoal,

Está sendo organizado, através do twitter,  um Happy Hour Ágil que acontecerá em Campinas/SP.  Será no dia 19/08 às 19:30 no Giovannetti da Rua Padre Vieira, 1277 - Cambuí - Campinas, ao lado da Prefeitura.

Para acompanhar o que estamos falando sobre este Happy Hour lá no twitter, procure pela tag #HHA

Nos encontramos lá =D

Eu estava trabalhando normalmente no Ubuntu, quando precisei reiniciar e abrir uma aplicação à partir do Windows. Quando eu voltei para o Ubuntu, o som parou de funcionar. Tudo estava instalado, o único problema era que o som não saia na caixa de som.

Eis a solução:

“2.1 If you are in Windows unplug the AC cable and plug it back after you logged into Ubuntu.

2.2 If you are already on Linux after a Windows session and you didn’t follow point 1.1estat, Unplug the AC cable, then SHUTDOWN , not restart the computer. Start it again manually and plug the cable back after you logged into Ubuntu ”

http://ubuntuforums.org/showthread.php?t=455147

Achei legal compartilhar isso aqui antes que alguém se mate re-compilando os drivers do alsa e assim por diante =D

Neste último final de semana eu gravei um screencast de como criar um branch vazio no Git.

Espero que vocês gostem:

Creating an empty branch on Git from Alberto Leal on Vimeo.

Abraços.

Mas hoje eu não vim aqui para publicar algo técnico. Dei uma passada rápida para dar um recado aos leitores do blog.

Aconteceu algo nesta semana que gostaria de compartilhar com vocês.

Leiam o email abaixo:

Ei Alberto, boa tarde.

Obrigada pelo retorno.

Sou editora do iMasters e cheguei até você através de um de nossos desenvolvedores. Ele viu seu artigo [http://albertoleal.eti.br/2009/06/git-o-rebase-pode-te-assustar/] e me repassou, com ótimos comentários.

Gostaria de saber se você tem interesse de publicar o artigo no iMasters. E não só ele, como outros também, sendo nosso articulista.

Se você topar, preciso apenas que faça cadastro no site, como usuário, e me envie uma foto (rosto) e um texto curto para o seu perfil. Com isso em mãos, farei o agendamento desse artigo e, então, você poderá publicar semanalmente - intervalo mínimo.

O que me diz?

Aguardo sua resposta.
Atenciosamente,
Rina Noronha
Editora - Redação iMasters

Fiquei muito contente com o convite feito pela Rina, editora do iMasters. Pois, meu primeiro contato com o iMasters foi há muitos anos atrás, logo no início da carreira hobby.  E, nunca imaginei que um dia eu pudesse vir a me tornar um colunista do site.

Inicialmente, os artigos publicados por lá serão sobre Git.

Por que? Quando eu iniciei minha série de posts sobre este assunto, eu recebi um ótimo feedback através de emails e twitter, com isso, espero poder ajudar ainda mais pessoas, já que o público do iMasters é N vezes maior do que o meu humilde blog =)

Eu pretendo escrever artigos exclusivos para serem publicados no iMasters, mas isso somente acontecerá no próximo ano.

O primeiro artigo já foi publicado:  “Git: o rebase pode te assustar”

Boa leitura!

Resolvi chamá-lo de “ReportHelper“. Como o próprio nome já diz, um helper para ajudar na criação de relatórios =)

Desde a sua criação, outro desenvolvedor - Carlos Spineli - resolveu dar umas tapas no código para melhorá-lo. Resolvi compartilhar com a comunidade este helper. Ele já está disponível na minha páginal pessoal no Github, e você consegue acessá-lo aqui. Lá você encontrará o código, bem como uma aplicação exemplo que eu criei no screencast que você pode conferir aí embaixo:

ReportHelper - CakePHP from Alberto on Vimeo.

Mandem suas críticas e sugestões.

E, colaborem =)

1
2
3
4
5
6
7
8
9

$ touch abc.txt
$ vim abc.txt
$ git add abc.txt
$ git commmit -m 'Abc file'
$ vim abc.txt
$ git add abc.txt
$ git commmit -m 'Some changes'
$ cat abc.txt
$ git checkout HEAD^1 -- abc.txt

O comando é ‘git checkout HEAD^1 — abc.txt’,  onde o número 1 representa a quantidade de commits abaixo, a partir do HEAD, e abc.txt representa o nome do arquivo que você deseja recuperar.

Simples e bastante útil!

Photo: http://static.howstuffworks.com/gif/teen-bedroom-decorating-ideas-2.jpg

O último livro que terminei de ler era sobre Design Pattern. Então, resolvi fazer alguns posts contendo algumas implementações. O padrão de projeto da vez é o Decorator.

——–

O poder da composição

Têm quem ame, e têm quem odeie herança. Existem casos que não há como fugir da herança, mas, sempre que possível, prefira composição a herança. Quando utilizamos herança em uma parte da nossa aplicação, e alguns comportamentos são herdados, estes  são definidos estaticamente em tempo de compilação. Por outro lado, se você estender o comportamento de um objeto por meio de composição, você consegue fazer isso dinamicamente, ou seja, consegue compôr os objetos de forma dinâmica. Com isso, se torna fácil adicionar novas funcionalidades escrevendo um código novo ao invés de alterar o código existente. Isso é bacana, pois o comportamento anterior não é modificado, assim as chances de introdução de erros no código que já estava funcionando é menor. Se algo der errado, basta remover a nova classe que foi criada, por exemplo. Resumindo, mantenha as classes abertas para extensão e fechadas para alteração.

O padrão de projeto decorator anexa novas responsabilidades em um objeto dinamicamente, utilizando  do poder da composição.

Vamos ver como isso funciona na prática. O exemplo que lhe será apresentado é a construção de uma pizza. No momento do pedido, o cliente poderá pedir ao Pizzaiolo que adicione  novos ingredientes na pizza, tais como: orégano e tomate. Exemplo simples e direto, apenas para ilustrar.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

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

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

package br.eti.albertoleal.decorator;
 
public class Cheese extends Pizza {
 
	public Cheese(){
		setDescription("Cheese Pizza")
	}
 
	@Override
	public double cost() {
		return 19.90;
	}
 
}

As classes decorator devem ser espelhos das classes que elas vão decorar. Vamos utilizar da herança em nossos objetos do tipo CondimentDecorator. O motivo de se usar herança na classe Decorator é  pelo simples fato de se ter o mesmo tipo dos objetos que vão ser decorados. O uso de herança é justamente para atingir  essa correspondência de tipo.

1
2
3
4
5

package br.eti.albertoleal.decorator;
 
public abstract class CondimentDecorator extends Pizza {
 
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package br.eti.albertoleal.decorator;
 
public class Oregano extends CondimentDecorator {
	Pizza pizza;
 
	public Oregano(Pizza pz) {
		pizza = pz;
	}
 
	@Override
	public String getDescription() {
		return pizza.getDescription() + ", Oregano";
	}
 
	@Override
	public double cost() {
		return .50 + pizza.cost();
	}
 
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package br.eti.albertoleal.decorator;
 
public class Tomato extends CondimentDecorator {
	Pizza pizza;
 
	public Tomato(Pizza pz){
		pizza = pz;
	}
 
	@Override
	public String getDescription() {
		return pizza.getDescription() + ", Tomato ";
	}
 
	@Override
	public double cost() {
		return .10 + pizza.cost();
	}
 
}

Se você estava atento reparou que a cada condimento que é adicionado na pizza um valor correspondente ao condimento é somado ao valor da pizza. Essa é a idéia do decorator. Estou decorando um objeto pizza com diversos outros componentes. Um outro exemplo, bastante comum de se encontrar pela internet, são as janelas gráficas. O ato de decorar uma janela gráfica com diversos componentes de apresentação, tais como: barra de rolagem, campos de texto e por aí vai.

Chegou a hora de testarmos o nosso código, criar uma pizza e adicionar alguns condimentos a ela e constatar se a nossa “decoração” funciona:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package br.eti.albertoleal.decorator;
 
public class Pizzaiolo {
 
	public static void main(String[] args) {
 
		Pizza pz = new Cheese();
 
		pz = new Tomato(pz);
		pz = new Tomato(pz);
		pz = new Oregano(pz);
		pz = new Tomato(pz);
		pz = new Oregano(pz);
		pz = new Tomato(pz);
 
		System.out.println(pz.getDescription());		
 
	}
 
}

Concluindo:

• A herança é uma maneira de estender comportamentos, mas não é a melhor maneira de obter flexibilidade;
• Composição e delegação são boas maneiras de se adicionar funcionalidades em tempo de execução;
• A utilização de um componente decorator é simplesmente decorar um objeto, e o objeto decorado não precisa conhecer os decoradores;
• É muito importante que os objetos decoradores sejam espelhos do objeto que vão decorar, justamente para ter uma correspondência de tipo.

Cenário: Você está em uma reunião participando de um code review, quando algum desenvolvedor vira e fala: “Quem comentou a linha 12? Eu fiz esse código e aquele fragmento era importante!”. Pergunta: O culpado aparece rápido? Pode ser que sim. Mas, caso não apareça  ninguém para assumir a culpa, utilize o comando ‘git blame’ para descobrir quem fez cada modificação.

Exemplo:

$ git blame workspace/ProjectXPTO/WebContent/file.jsp -L 10,18
73e51f4f (Desenvolvedor A 2009-03-10 09:07:53 -0400 10)
73e51f4f (Desenvolvedor A 2009-03-10 09:07:53 -0400 11)  <script>
73e51f4f (Desenvolvedor A 2009-03-10 09:07:53 -0400 12)         // var windowName;
7ue8d049 (Desenvolvedor B 2009-06-18 16:42:48 -0400 13)
7ue8d049 (Desenvolvedor B 2009-06-18 16:42:48 -0400 14) function cleanUpVariable(variable){
7ue8d049 (Desenvolvedor B 2009-06-18 16:42:48 -0400 15)  var = j;
7ue8d049 (Desenvolvedor B 2009-06-18 16:42:48 -0400 16)  j = variable.replace(/[^0-9A-Za-z]+/g, "");
7ue8d049 (Desenvolvedor B 2009-06-18 16:42:48 -0400 17)  return j;
7ue8d049 (Desenvolvedor B 2009-06-18 16:42:48 -0400 18) }

Se você não passar o parâmetro -L serão exibidas todas as linhas do seu arquivo.  No caso acima deu para perceber que o responsável por comentar a variável “windowName” foi o “Desenvolvedor A”.

Agora você já sabe como descobrir quem faz cada besteira nos seus arquivos.

Acredito que o título desse post diz muito por si só. Mas, vou tentar expandí-lo um pouco mais. Só para constar, fui impulsionado a escrever esse post devido a algumas mensagens que acompanhei pelo twitter.

–

Existem diversos controladores de versão no mercado, tais como: Harvest, CVS, SVN, Clear Quest e por aí vai. Porém, o Git possui uma idéia, filosofia diferente destes que acabei de citar. Git é um SCM distribuído. Não vou entrar em detalhes sobre as diferenças agora, vamos deixar para uma outra ocasião.

A mensagem que quero passar é a seguinte:
Git é difícil?  Não.
Uso SVN/CVS na minha empresa há muitos anos, posso mudar tudo de uma vez para o GIT - já que Git não é difícil? Não aconselho.

Usar um controlador de versão não envolve apenas adicionar arquivos e comitá-los. Existem diversas tarefas que, às vezes, temos que fazer, como por exemplo: Quebrando um commit e cancelando algumas alterações. Pode ser que você já saiba fazê-lo no outro SCM que você vem utilizando, mas ainda não sabe fazê-lo no Git.

Se você, simplesmente, mudar de SCM de uma hora para a outra fatalmente terá problemas e terá que recorrer ao grande amigo Google. Alguns problemas triviais não lhe tomará muito tempo, por outro lado, outros não serão tão triviais quanto possam parecer e tomarão mais tempo do que você gostaria.

Minha sugestão é a seguinte, comece utilizando Git em um projeto antes de migrar todos os outros. Desse jeito você perceberá como o Git trabalha e como tirar o maior proveito dele. Além de se deparar com os mais diversos tipos de problemas.

Até a próxima!