*batteries not included

Mudança de rumo

Daniel F. Martins — Thu, 25 Sep 2008 03:08:38 +0000

Que fique claro: aqui é realmente o Daniel quem vos escreve. Sim, eu não morri. Pelo menos não ainda.

Estou reiterando isso pois, a julgar pela frequência com que eu atualizo este blog ou jogo conversa fora com os amigos no ~~MSN~~ GTalk, não é de se duvidar que alguém pense que eu fui dessa para melhor. Mas enfim, eu estou escrevendo este post para dar duas notícias importantes.

A primeira notícia é boa: a partir de hoje, quando eu abrir um crediário e me perguntarem a minha profissão, eu posso dizer que sou empresário. Chique, né? A empresa, batizada de Destaquenet, foi aberta em Julho e a versão inicial do site já está no ar. E antes que me perguntem, o site foi feito em Django!

Mas voltando ao assunto, isso aconteceu por vários motivos. Um desses motivos — talvez o principal deles — foi para evitar problemas com o temido Leão do imposto de renda, afinal já faz um tempinho que eu venho trabalhando como freelancer. O outro motivo é que, apesar de eu estar bem servido de trabalho pelo menos até o ano que vem, a idéia é justamente não depender de apenas uma ou duas empresas, então é uma boa já deixar a casa arrumada para que eu possa prestar serviços para outras empresas também.

A outra notícia — que é boa e ruim — é que, além de todo o trampo que eu já fazia, agora eu tenho uma empresa para tocar, o que por si só já dá um trabalhão. Por isso, eu optei por descontinuar este blog. Se tiver algum post aqui que vocês achem interessante, me avisem para que eu o coloque no blog da Destaquenet.

Provavelmente este será o último post neste blog, por isso, se tem alguém que (ainda) se interessa pelo que eu escrevo, eu recomendo que assinem o feed do blog da Destaquenet. Os posts no novo blog deverão ter o mesmo teor dos que aqui se encontram; a diferença é que tentarei manter uma certa regularidade nas postagens, coisa que não vem acontecendo por aqui a um bom tempo.

Mas é isso aí então, conto com a compreensão de vocês e espero reencontrá-los na minha nova casa.

Grande abraço a todos!

Depurando uma aplicação JavaEE no Glassfish

Daniel F. Martins — Tue, 10 Jun 2008 16:41:06 +0000

Este post, na verdade, é uma dica rápida para quem possui aplicações JavaEE rodando em servidores Glassfish e está tendo dificuldades na hora de rastrear a origem de possíveis bugs no código.

Habilitando o modo de debug

Existem duas maneiras de se habilitar o modo de debug no Glassfish: através do painel de administração ou durante a inicialização do domínio.

Para habilitar o modo de debug por padrão, através do painel de administração, basta marcar o campo Debug na tela JVM Settings e clicar em Save:

Basta reiniciar o domínio para ver que o servidor abre a porta 9009, através da qual podemos conectar um debugger:

daniel@daniel-laptop:~/Appservers/Glassfish/bin$ asadmin start-domain domain1
Starting Domain domain1, please wait.
Log redirected to …/server.log.
Redirecting output to …/server.log
Listening for transport dt_socket at address: 9009
Application server is listening at address 9009 for debugger to attach using transport dt_socket
…

A outra forma de se habilitar o modo de debug é fornecer o parâmetro --debug ao iniciar o domínio. Por exemplo:

asadmin start-domain –debug domain1

Conectando o debugger da IDE ao servidor

Agora, basta usar os recursos de debugging presentes na sua IDE Java para debugar o código. Por exemplo, se você usa o NetBeans 5.5, basta acessar o menu Run - Attach Debugger… e o configurar da seguinte forma:

Anexando debugger do Netbeans

O procedimento é semelhante em outras IDEs Java.

Pronto! Feito isso, é só colocar os breakpoints e disparar a execução do código problemático.

PyGod: Como sacanear seus amigos com Python!

Daniel F. Martins — Thu, 29 May 2008 00:36:40 +0000

Pouco tempo depois de ganhar meu primeiro computador, um super 486 DX2 com 16MB de RAM, eu já tinha uma coleção razoável de disquetes onde eu armazenava tudo que era porcaria que eu encontrasse por aí, como fotos (é, esse tipo de foto mesmo), jogos e programas.

Toda coleção de disquetes digna de respeito compartilhava pelo menos uma característica em comum: dúzias dos já infames programas inutilitários. E a lista era longa, indo desde aqueles programas que mostram a ovelha Dolly andando pela tela até aqueles que fingem formatar o HD. (que atire a primeira pedra quem nunca enviou um desses para os “amigos”!)

Mas enfim, os meus inutilitários favoritos eram aqueles programas “inteligentes”, que pareciam ter a resposta para qualquer pergunta. Já perdi a conta de quantas vezes eu ouvi a frase “mas cadê a câmera?” ao mostrar esses programas para amigos e familiares! Ah, bons tempos aqueles…

Foi tomado por esse espírito de nostalgia que eu tive a idéia de tentar implementar um programa parecido em Python. O resultado dessa brincadeira, que chamei de PyGod por razões óbvias, pode ser conferido neste post!

O programa

A mecânica por trás desse tipo de programa é super simples. Cada tecla pressionada pelo usuário pode fazer com que o programa alterne entre dois “modos”:o modo de resposta e o modo de eco. No primeiro modo, o programa imprime uma pergunta aleatória na tela enquanto lê a resposta; já o segundo modo simplesmente ecoa as teclas pressionadas pelo usuário.

Os exemplos a seguir devem ajudá-lo a compreender melhor o que acontece.

1. Modo de resposta

A tela abaixo mostra como o programa reage a um usuário que conhece o truque.

Primeiramente, eu pressionei a tecla ; para entrar no modo de resposta. Em seguida, digitei a resposta (Daniel) para a pergunta desejada. Note que, conforme a resposta é digitada, o programa imprime uma pergunta pré-definida de modo que todos pensem que é você quem está digitando aquilo! Então, depois de digitada a resposta, eu pressionei a tecla ; novamente para voltar para o modo de eco (ver abaixo) e completei a pergunta.

2. Modo de eco

Já a tela abaixo mostra como o programa reage a um usuário que não conhece o truque.

Como a resposta não foi digitada, o programa mostra uma mensagem qualquer.

Implementação

Grande parte do programa se resume a código para manipular o terminal através do módulo curses. A aplicação foi desenvolvida em Python 2.5.2 e testada no Ubuntu 8.04 LTS.

O código do programa está disponível para download na página de aplicações aqui do blog.

* PS: digite wtf e pressione ENTER para ver uma mensagem de ajuda!

Squeak By Example em pt_BR? Saiba como contribuir!

Daniel F. Martins — Fri, 25 Apr 2008 04:43:44 +0000

É isso aí! Depois de um longo tempo sem dar as caras por aqui, venho aqui anunciar minha mais nova contribuição ao mundo do código aberto: a tradução para o Português do Brasil do livro Squeak By Example. O projeto, iniciado pelo Ronaldo Ferraz, servirá para facilitar o acesso ao Squeak (e ao Smalltalk de um modo geral) por parte daqueles que não falam Inglês.

Update: O Ronaldo criou um post com algumas dicas para quem usa Mac OS X e gostaria de contribuir com o projeto.

Legal, eu gostaria de contribuir com o projeto! O que devo fazer?

Eu uso o Ubuntu na minha máquina, portanto mostrarei abaixo como fazer para configurar o ambiente necessário nesse sistema, embora as mesmas instruções devam servir para qualquer Sistema Operacional baseado no Debian.

1. Instalando os pacotes necessários

O livro Squeak By Example foi criado usando uma fantástica ferramenta que muitos já ouviram falar mas poucos de fato a usaram: TeX. Não explicarei aqui para que serve essa ferramenta; uma busca no Google é o suficiente para você ter uma boa idéia do que se trata.

Além do TeX, precisamos instalar o Git, o sistema de controle de versões usado para gerenciar as alterações nos arquivos durante o processo de tradução e revisão.

Update: Percebi que também existe um script Ruby que é executado sempre que o livro é compilado. Por esse motivo, também precisamos instalar o Ruby.

Se você usa Ubuntu, basta rodar o comando abaixo para instalar todas as ferramentas necessárias:

sudo apt-get install tetex-base tetex-bin tetex-extra lmodern git-core ruby

Agora levante e vá dar uma volta com o cachorro ou espere os mais de 200 MB em pacotes baixarem da Internet!

2. Criando uma conta no Gitorious

Apesar do projeto original em Inglês usar o Subversion, o Ronaldo optou por hospedar o projeto no Gitorious, um repositório Git para projetos de código aberto.

Criar uma conta no Gitorious é bem simples; basta acessar o site, clicar no link Register e enviar o formulário de cadastro. Após alguns minutos você receberá um e-mail com instruções para ativação do cadastro.

3. Criando um par de chaves SSH

O Gitorious usa SSH para autenticar operações realizadas em seus repositórios.

Dê uma olhada no seu diretório ~/.ssh, pois é bem provável que você já tenha um par de chaves SSH criado. Se for o caso, pule para o próximo item; se não for o caso, continue lendo.

Para criar um par de chaves SSH basta seguir o exemplo:

daniel@darkstar:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/daniel/.ssh/id_rsa): [enter]
Enter passphrase (empty for no passphrase): [sua senha]
Enter same passphrase again: [sua senha]
Your identification has been saved in /home/daniel/.ssh/id_rsa.
Your public key has been saved in /home/daniel/.ssh/id_rsa.pub.
The key fingerprint is:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

4. Importando sua chave pública no Gitorious

Precisamos agora importar no Gitorious a nossa chave pública. Para isso, acesse o link My account e depois clique no menu Add SSH key. A tela a seguir mostrará um campo de texto, no qual você deve colar o conteúdo da sua chave pública (ex: ~/.ssh/id_rsa.pub). Feito isso, basta clicar no botão save para enviar a chave.

A partir deste momento, se o Gitorious lhe pedir uma senha conforme você trabalha com o repositório, basta você digitar a senha dessa chave SSH.

5. Clonando o repositório do projeto de tradução

A princípio, o repositório principal criado pelo Ronaldo só será aberto a commits de terceiros em algum momento futuro, e somente àqueles que participarem mais ativamente do processo de tradução e/ou revisão. Portanto você deve criar um “clone” desse repositório para que você possa trabalhar em paralelo. Então, eventualmente seus avanços serão revisados e incorporados ao repositório principal.

Para clonar o repositório principal, basta acessar esta página e clicar no link Clone repository. Especifique um nome para seu “clone” e pressione o botão Clone repository.

Aguarde alguns momentos até que seu “clone” fique pronto. Depois que você conseguir acessar a página do seu clone, copie a URL de Push (ex: git@gitorious.org:squeak-by-example/xxx.git) do seu clone e a coloque no seguinte comando, no terminal:

daniel@darkstar:~$ git clone [url do seu clone]

Pegue o seu cachorro e o leve para um novo passeio enquanto o repositório é baixado da Internet.

6. Compilando o documento

Agora vem a parte fácil. Depois de baixar o repositório, basta acessar o diretório PortugueseBook e compilar o documento usando o comando make:

daniel@darkstar:~/...$ cd [seu clone]/PortugueseBook/
daniel@darkstar:~/...$ make
...

Não se preocupe se um monte de caracteres estranhos aparecerem na tela. Basta aguardar alguns segundos até que a compilação do documento seja concluída.

Para ver o resultado, basta visualizar o PDF no seu programa preferido:

daniel@darkstar:~/...$ evince SBE.pdf

7. Reservando capítulos para tradução e revisão

Entre em contato através dos comentários caso você queira realmente contribuir com o projeto. Mas não marque bobeira, pois as vagas são limitadas!

Se você tem uma conta no Google, informe também seu nome de usuário para que eu possa liberar seu acesso de edição na nossa planilha de acompanhamento.

Atenção: Vale lembrar que não precisamos somente de tradutores, mas também de revisores. Portanto, se você não sabe Inglês, mas conhece Português bem o suficiente para ajudar na correção de erros, sua ajuda é mais que bem-vinda!

TDD e Swing juntos?

Daniel F. Martins — Fri, 11 Apr 2008 03:00:37 +0000

Como prometido, deixarei aqui algumas dicas sobre como desenvolver uma aplicação Swing de conversão de temperaturas utilizando uma técnica de desenvolvimento de software conhecida como TDD (Test Driven Development). Então, se você nunca ouviu falar em TDD antes, procure dar uma estudada para saber do que se trata antes continuar lendo este texto. Garanto que, por mais esquisito que esse negócio de TDD possa parecer, é um jeito bem interessante de se desenvolver aplicações.

Não escreverei um passo-a-passo por questões de espaço, mas, basicamente, a seqüência que seguiremos no decorrer do texto será a seguinte: primeiramente, criaremos testes de unidade com o JUnit para definir a lógica para conversão de uma temperatura para outras escalas (Celsius, Kelvin e Fahrenheit). Em seguida, iremos programar essa lógica até que todos os testes passem. Depois disso, a interface com o usuário será desenhada e o seu comportamento definido, através da criação de testes JUnit + FEST-Swing, ferramenta esta muito interessante que permite automatizar testes em aplicações Swing. Por fim, programaremos a lógica da View até que todos os testes passem. E qual será o resultado dessa bagunça toda? Uma aplicação funcional.

É, eu sei… na teoria tudo parece muito bonito, mas, e na prática? Será que funciona assim mesmo? Se está curioso, então continue lendo!

Ferramentas e arquivos

Como IDE, utilizaremos o NetBeans 6.1 pela facilidade em se desenvolver aplicações desktop. Você também precisará baixar baixar a última distribuição do FEST-Swing e adicioná-la no seu NetBeans através do Library Manager.

O código-fonte completo da aplicação mostrada aqui pode ser baixado através da página de aplicações aqui do blog.

Definindo a lógica de conversão de temperatura

Vamos pensar agora em como a lógica de conversão de temperatura deve funcionar. Para tornar mais fácil a tarefa de se obter uma arquitetura limpa e “coerente”, escrevemos os testes unitários antes do código que implementa a lógica de conversão.

Isso mesmo, primeiro os testes e depois a implementação. Se você tivesse lido um pouco sobre TDD, provavelmente não teria se espantado tanto! Abaixo, um trecho do livro Extreme Programming, de Vinícios Manhães Teles:

Quando o desenvolvedor pensa no teste antes de pensar na implementação, ele é forçado a compreender melhor o problema [...]. Ao se aprofundar no problema, o desenvolvedor está fazendo uma análise mais detalhada. Portanto, neste momento, o desenvolvimento guiado por testes (TDD) atua como uma técnica de análise [...].

Quando o desenvolvedor escreve o teste, ele procura atuar como um cliente dele, se preocupando apenas com a interface externa do método, sem dar atenção à implementação. Isso é ótimo porque permite que o design do método seja o mais adequado possível para aqueles que irão utilizá-lo. [...]

Isso faz sentido para você ou não? Para mim - e para dezenas de milhares de outros desenvolvedores - faz muito sentido!

Nem preciso dizer que este livro é obrigatório para aqueles que querem aprender, de uma vez por todas, as práticas do XP. Sei que não estou ganhando nada pela propaganda, mas é que o livro é muito bom mesmo! Faço propaganda dele até de graça.

Continuando, confira abaixo os testes que servirão, ao mesmo tempo, para definir o design do código de conversão e testá-lo:

package com.danielfmartins.blog.tutorial.tdd.fest;
// imports …
public class ConversorTemperaturaImplTest {
private ConversorTemperatura conversion;
@Before
public void setUp() {
conversion = new ConversorTemperaturaImpl();
}
@Test
public void converterParaCelsius() {
assertEquals(conversion.converter(15.0, Escala.CELSIUS, Escala.CELSIUS), 15.0);
assertEquals(conversion.converter(50.0, Escala.FAHRENHEIT, Escala.CELSIUS), 10.0);
assertEquals(conversion.converter(561.5, Escala.KELVIN, Escala.CELSIUS), 288.35);
}
@Test
public void converterParaFahrenheit() {
assertEquals(conversion.converter(15.0, Escala.CELSIUS, Escala.FAHRENHEIT), 59.0);
assertEquals(conversion.converter(50.0, Escala.FAHRENHEIT, Escala.FAHRENHEIT), 50.0);
assertEquals(conversion.converter(561.5, Escala.KELVIN, Escala.FAHRENHEIT), 551.03);
}
@Test
public void converterParaKelvin() {
assertEquals(conversion.converter(15.0, Escala.CELSIUS, Escala.KELVIN), 288.15);
assertEquals(conversion.converter(50.0, Escala.FAHRENHEIT, Escala.KELVIN), 283.15);
assertEquals(conversion.converter(561.5, Escala.KELVIN, Escala.KELVIN), 561.5);
}
}

Como pôde ser visto, a classe de conversão de temperaturas deverá ser simples e eficiente para a situação proposta. Ela terá apenas um método converter() que receberá três parâmetros:

Temperatura a ser convertida;
Escala de origem (Celsius, Kelvin ou Fahrenheit); e
Escala de destino (Celsius, Kelvin ou Fahrenheit).

Neste momento o que temos é um código todo sublinhado em vermelho. Portanto, nossa tarefa agora é fazer com que eles chegem a pelo menos compilar.

Em primeiro lugar, crie o enum Escala:

package com.danielfmartins.blog.tutorial.tdd.fest;
public enum Escala {
CELSIUS, FAHRENHEIT, KELVIN
}

Depois, crie a interface ConversorTemperatura:

package com.danielfmartins.blog.tutorial.tdd.fest;
public interface ConversorTemperatura {
double converter(double valor, Escala de, Escala para);
}

Finalmente, crie a classe ConversorTemperaturaImpl:

package com.danielfmartins.blog.tutorial.tdd.fest;
public class ConversorTemperaturaImpl implements ConversorTemperatura {
@Override
public double converter(double valor, Escala de, Escala para) {
return 0.0;
}
}

Neste ponto já temos um código compilado, embora o mesmo não passe nos testes que definimos anteriormente. A tarefa agora é ir alterando este código até que todos aqueles testes passem:

package com.danielfmartins.blog.tutorial.tdd.fest;
public class ConversorTemperaturaImpl implements ConversorTemperatura {
@Override
public double converter(double valor, Escala de, Escala para) {
double result = 0.0;
/* conversão desnecessária */
if (de == para) {
return valor;
}
if (de == Escala.CELSIUS && para == Escala.FAHRENHEIT) {
result = valor * 1.8 + 32;
} else if (de == Escala.CELSIUS && para == Escala.KELVIN) {
result = valor + 273.15;
} else if (de == Escala.FAHRENHEIT && para == Escala.CELSIUS) {
result = (valor - 32) / 1.8;
} else if (de == Escala.FAHRENHEIT && para == Escala.KELVIN) {
result = (valor + 459.67) / 1.8;
} else if (de == Escala.KELVIN && para == Escala.CELSIUS) {
result = valor - 273.15;
} else if (de == Escala.KELVIN && para == Escala.FAHRENHEIT) {
result = valor * 1.8 - 459.67;
}
return result;
}
}

Ok, neste momento os testes já devem executar com sucesso, o que significa que terminamos a codificação da lógica de conversão de temperaturas. Podemos então partir para a definição da interface com o usuário.

Definindo a interface com o usuário

A melhor forma de saber como o usuário irá interagir com o sistema é criar uma representação da interface com a qual ele irá trabalhar. Isso pode ser feito de diversas formas: desde um rabisco à lápis em uma folha sulfite até através do uso de um software.

No NetBeans, essa tarefa é muito simples de ser feita, já que contamos com a ajuda do Matisse, o módulo de GUI design. Com ele, podemos criar interfaces gráficas complexas em minutos, o que torna esta ferramenta ideal para o trabalho.

Ok, depois de alguns minutos mexendo no Matisse, o resultado que obtive pode ser visto na imagem abaixo:

A interação do usuário com essa tela é bem fácil de se entender. O usuário fornecerá a temperatura a ser convertida (através da digitação do valor e escolha da escala). Em seguida, ele pressionará o botão Converter. Obviamente, o sistema deverá informar o usuário caso ele forneça uma temperatura inválida. Caso a temperatura seja válida, a aplicação faz a conversão e mostra o resultado nas três caixas de texto na parte inferior da tela. Os botões, na parte inferior da tela, explicam suas funções por si só.

Definindo o comportamento da interface com o usuário

Antes de programar a interface com o usuário, vamos aplicar uma abordagem semelhante à aplicada para definir a lógica de conversão de temperaturas, ou seja, vamos criar os testes primeiro:

package com.danielfmartins.blog.tutorial.tdd.fest;
// imports …
public class ConversorFrameTest {
private FrameFixture frame;
@Before
public void setUp() {
frame = new FrameFixture(new ConversorFrame());
frame.show();
}
@After
public void tearDown() {
frame.cleanUp();
}
@Test
public void checarValoresIniciais() {
frame.textBox("temperatura").requireText("0.0");
frame.textBox("celsius").requireText("0.0");
frame.textBox("fahrenheit").requireText("0.0");
frame.textBox("kelvin").requireText("0.0");
frame.comboBox().requireSelection(Escala.CELSIUS.toString());
}
@Test
public void converterTemperaturaVazia() {
frame.textBox("temperatura").deleteText();
frame.comboBox().selectItem(Escala.FAHRENHEIT.toString());
frame.button("converter").click();
frame.optionPane().requireErrorMessage().okButton().click();
}
@Test
public void converterTemperaturaInvalida() {
frame.textBox("temperatura").deleteText().enterText("aaa");
frame.button("converter").click();
frame.optionPane().requireErrorMessage().okButton().click();
}
@Test
public void converterDeFahrenheit() {
frame.textBox("temperatura").deleteText().enterText("50.0");
frame.comboBox().selectItem(Escala.FAHRENHEIT.toString());
frame.button("converter").click();
frame.textBox("celsius").requireText("10.0");
frame.textBox("fahrenheit").requireText("50.0");
frame.textBox("kelvin").requireText("283.15");
}
@Test
public void converterDeKelvin() {
frame.textBox("temperatura").deleteText().enterText("450.2");
frame.comboBox().selectItem(Escala.KELVIN.toString());
frame.button("converter").click();
frame.textBox("celsius").requireText("177.05");
frame.textBox("fahrenheit").requireText("350.69");
frame.textBox("kelvin").requireText("450.2");
}
@Test
public void converterDeCelsius() {
frame.textBox("temperatura").deleteText().enterText("50.5");
frame.comboBox().selectItem(Escala.CELSIUS.toString());
frame.button("converter").click();
frame.textBox("celsius").requireText("50.5");
frame.textBox("fahrenheit").requireText("122.9");
frame.textBox("kelvin").requireText("323.65");
}
@Test
public void mostrarJanelaSobre() {
frame.button("sobre").click();
frame.optionPane().requireInformationMessage().okButton().click();
}
@Test
public void fecharAplicativo() {
frame.button("sair").click();
assert !frame.component().isVisible();
}
}

Uma das características mais marcantes do FEST-Swing é o uso de interfaces fluentes na API, tornando muito simples a criação dos testes antes mesmo de criarmos a interface com o usuário.

Agora vamos dar uma olhada rápida no código. Primeiramente, antes de cada teste ser executado, o método setUp() cria um objeto FrameFixture passando uma nova instância do Frame que desejamos testar. É através desse objeto fixture que podemos realizar asserções em elementos da interface gráfica.

No nosso caso, utilizamos uma instância de FrameFixture pois estamos testando um objeto Frame. Entretanto, existem diversos outros tipos de fixtures que permitem testar outros componentes (Dialog, JOptionPane etc).

Como os métodos do objeto fixture são basicamente instruções dadas a um usuário “de mentira”, fica muito fácil adivinhar o que acontece em cada um dos testes. Perceba que todas essas instruções seguem um padrão: informamos o componente desejado, disparamos ações nesse componente e verificamos a resposta do componente controlado pela fixture.

Finalmente, o método tearDown() libera os recursos utilizados por cada teste.

Ok, você pode executar os testes agora. Não se espante quando seu teclado e mouse ganharem “vida”… é o FEST-Swing usando sua aplicação!

Implementando a lógica da interface com o usuário

Os testes falharam! Por quê? Ora, porque ainda não implementamos a lógica de interação do usuário com a aplicação! Mas, fique tranqüilo, pois é exatamente isto que iremos fazer agora.

Primeiramente, vamos configurar o Model do nosso JComboBox para que este mostre o nosso enum Escala:

new DefaultComboBoxModel(Escala.values())

Adicione um ActionListener no botão Converter com o seguinte código:

double temp = 0.0;
Escala scale = (Escala) escala.getSelectedItem();
ConversorTemperatura conversor = new ConversorTemperaturaImpl();
// Limpa os resultados anteriores
celsius.setText("0.0");
fahrenheit.setText("0.0");
kelvin.setText("0.0");
try {
temp = Double.valueOf(temperatura.getText()); // Converte para double
/* Mostra os resultados */
celsius.setText("" + conversor.converter(temp, scale, Escala.CELSIUS));
fahrenheit.setText("" + conversor.converter(temp, scale, Escala.FAHRENHEIT));
kelvin.setText("" + conversor.converter(temp, scale, Escala.KELVIN));
} catch (Exception e) {
/* Erro na obtenção da temperatura */
JOptionPane.showMessageDialog(this, "Temperatura inválida", "Erro", JOptionPane.ERROR_MESSAGE);
temperatura.requestFocus();
}

Adicione um ActionListener no botão Sobre… com o seguinte código:

JOptionPane.showMessageDialog(this,
"TDD (Test Driven Development) e Swing?\nAutor: Daniel F. Martins",
"Sobre…", JOptionPane.INFORMATION_MESSAGE);

E, finalmente, adicione um ActionListener (que novidade…) no botão Sair, com o seguinte código:

dispose();

Está pronto! Agora todos os testes devem passar, indicando que temos uma aplicação pronta para servir nossos usuários da melhor forma possível.

Conclusão

O propósito aqui não é explicar tudo sobre o TDD e suas vantagens e desvantagens, eu deixo essa tarefa para outros textos disponíveis por aí. O que eu tentei fazer aqui foi apenas ilustrar, ou simular, o desenvolvimento de uma aplicação Swing usando TDD, para provar que sim, é possível desenvolver aplicações Swing de um modo ágil.

Se você costuma ler sobre programação desktop, seja em Java ou em qualquer plataforma, você provavelmente já deve ter ouvido aquela máxima de que é “impossívell testar interfaces com o usuário”. Com o FEST-Swing isso nunca foi tão… mentira.

Foto por: Alain Bachellier

Que linguagem você aprenderá em 2008?

Daniel F. Martins — Mon, 21 Jan 2008 02:34:41 +0000

“Learn one language every year“. Não me lembro ao certo onde e quando foi a primeira vez que li isso, mas depois de pensar por alguns instantes, eu mudei aquela idéia que eu tinha — de que é melhor se especializar numa única tecnologia em detrimento das demais. Melhor um peito na mão do que dois no sutiã, concorda?

Voltando aos tempos da faculdade, embora subliminarmente, eu aprendi que Java é o que há, que C só serve para aprender algoritmos (e estruturas de dados) e que depois de trabalhar como programador eu devo virar gerente. Nada mais justo, afinal, o que esperar de um curso de Sistemas de Informação? (droga, eu devia ter feito Ciências da Computação.)

A cada nova descoberta eu me impressionava mais com as vantagens do Java. Não demorou muito para eu decidisse me “especializar” nessa tecnologia; comecei a visitar regularmente sites e fóruns sobre Java, montar pequenos programas, ler livros e estudar para certificações.

Hehehe, pela forma que esse texto vem sendo escrito, você deve estar se perguntando quando é que eu vou parar com essa babação de ovos e começar a contra-argumentar tudo o que disse. O famoso “mas”.

Mas… nada!

Felizmente, não me arrependo de nenhum programa que fiz, de nenhuma certificação que tirei e de nenhum livro que li. O simples uso do Java me ensinou coisas que eu provavelmente nunca aprenderia caso escolhesse outra linguagem. Em outras palavras, Java me ensinou uma coisa que poucos sabem (ou muitos ignoram): é difícil fazer software.

Se eu vou largar o Java? Talvez… daqui uns cinco anos. Entretanto, depois de me dedicar ao Java por todo esse tempo, eu percebi que agora é o melhor momento para desacelerar um pouco e olhar mais atentamente o que acontece ao meu redor. Não com o intuito de migrar para outra coisa, mas de ampliar meus horizontes.

Conforme o ano passado se encerrava, eu ia coletando informações aqui e ali a respeito de tecnologias que eu estudaria neste ano de 2008; tentei ver qual delas seria viável a ponto de não ser apenas mais uma diversão nas horas vagas, qual é rica em projetos e bibliotecas, qual é sustentada por uma comunidade organizada e capaz, etc. No fim das contas a única opção que me pareceu interessante foi Python.

Já comecei a ler o Learning Python, que é um livro excelente para quem, como eu, nunca viu Python na vida. Minha pouca experiência na linguagem não impediu que eu já encontrasse algumas features interessantes, dentre as quais eu destaco list comprehensions e generators.

Nos próximos meses veremos se essa foi uma boa escolha, mas, de qualquer forma, eu estou confiante. Se tudo correr bem, a comunidade Python brasileira vai ter que me engolir!

E você, vai aprender uma nova linguagem ou vai continuar nessa? Se optou pela primeira opção, qual é a linguagem e o que o motivou a escolhe-la?

Mais um…

Daniel F. Martins — Mon, 07 Jan 2008 15:50:17 +0000

English readers: please follow this link.

Vocês se lembram da minha não-tão-recente experiência com DSLs em Groovy? Pois é… para variar, eu acho que levei a idéia um pouco longe demais.

Explico. Algum tempo depois de publicar o referido post, eu comecei a procurar na Internet por outras APIs ou aplicações semelhantes à que eu havia criado (por diversão, diga-se de passagem). A não ser por uma ou outra opção, o resto se resume a programas em VB que permitem apenas rolagens de dados triviais. Afinal, são poucos os idiotas que, como eu, perdem tempo com esse tipo de coisa!

Eu aproveitei a oportunidade para tornar aquele meu pequeno protótipo — cujo propósito era mostrar algumas features de meta-programação do Groovy e nada mais — numa API completa. Por isso, eu optei por dar uma melhorada no código e liberá-lo como sendo um projeto de software livre, que batizei de Groovy Dice.

E sim, o site está todo em Inglês, mas há uma boa razão para isso. Uma coisa que me chamou a atenção foi que o post que deu origem a esse projeto foi mais bem recebido por pessoas que não falam Português. Como meu objetivo também é divulgar um pouco do que se pode fazer com o Groovy, então nada melhor do que documentar o projeto em Inglês.

Mas continuando, apesar de ser um projeto bastante simples, ainda existem algumas coisas que eu gostaria de fazer. Uma delas seria prover uma forma para que o usuário possa modificar/estender a API padrão ou até mesmo mudar o “idioma” da linguagem:

7.d10 - 1.em_cada_dado

Quem quiser dar uma olhada no código-fonte do projeto ou conferir o que já pode ser feito com ele, uma visita ao site com certeza será útil. Qualquer contribuição — seja em forma de código ou comentários — é mais que bem-vinda.

For english readers

In my previous post, I’ve shared some thoughts about writing a simple DSL in Groovy to roll dice, but I never thought I’d receive such feedback from people outside Brazil (probably it’s GroovyBlogs‘ fault). Needless to say that this blog is targeted to portuguese-speaking developers, but I felt the need to take the whole thing to the next level anyway. So, after several improvements on the previously published code, I’ve released it as a brand new open source project called Groovy Dice. But I want you to know my intent, which is to show the people the power of Groovy, hasn’t changed a bit.

Although this project is a small piece of software, it’s not finished yet. I believe the next step is to design and implement some stuff to allow the user to modify/extend the default API. In fact, my plan is to leverage the power of Groovy to turn Groovy Dice into a small but very flexible framework.

If you want to play around with Groovy Dice (or just take a look at the source code), please, be my guest! Further instructions on how to download, configure and use the API can be found at the project’s website. Any kind of contribution is appreciated.