Eduardo Rebola - Tech Blog

Sun Tech Days 2009

2009-12-10T22:09:00.005-02:00

Olá amigos!

Faz tempo hein! Tanta coisa passou desde meu último post que eu nem sei por onde começar. Bom, acho mais fácil começar pelo mais recente e marcante fato que ocorreu nessa semana: Sun Tech Days 2009, dias 8 e 9/12 em São Paulo.

Depois de muitos anos lamentando a falta de condições para poder participar, finalmente consegui estar presente. Não quis esperar a euforia passar e resolvi retomar imediatamente o blog em grande estilo, comentando e recomendando o evento.

Pra começar, lá estava ele, James Gosling, ao vivo e a cores. Cor na verdade ele só tem duas: branca e vermelha. Praticamente um urso polar (sim, ele é grande) e aquele vozeirão que muitos já devem ter ouvido na internet. Simpatia pura, infelizmente pouco acessível p/ o público geral. Não consegui tirar uma foto com ele, ao contrário dos meus ex-colegas de Insula Edson Yanaga e Marcelo H Felipe, que não perderam tempo p/ ficar tirando sarro da minha cara

Nesta edição, o evento foi organizado em 4 tracks: Enterprise Computing, Client-Side Computing, OpenSolaris e Hands-on Lab. Eu procurei priorizar as apresentações sobre Java EE 6, porém felizmente consegui participar de um hands-on sobre Ajax Push (Comet) e assistir uma introdução ao OpenSolaris. Confesso não perder 1 minuto sequer com JavaFX, tecnologia bastante presente no evento, pois acredito que não irá fazer parte da minha vida por um bom tempo.

Sobre os palestrantes, eu achei o Sang Shin disparado o mais competente. As apresentações mais requisitados eram dele, sempre conduzidas com muita didática, organização e clareza. Apesar de ser chinês, seu inglês é fluente e de fácil compreensão. Muito simpático, me deu uma camiseta do evento em mãos (sim, eu pedi na cara dura). Saca só a foto que tirei com ele:

Um aviso ao pessoal de Maringá: Não percam de forma alguma a edição local do Sun Tech Days dia 11/12! O Sang Shin em pessoa estará aí falando sobre Java EE 6. Se você não pôde ir pra São Paulo, não perca essa oportunidade única!

Por enquanto é isso pessoal. Vou tentar manter o blog atualizado com mais frequência e trazer sempre assuntos interessantes para vocês. 2010 promete, novos ares (pra quem não sabe ainda, estou trabalhando em Brasília) e novos projetos.

Um grande abraço, e até a próxima!

Thread.sleep(2 * 30 * 24 * 60 * 60 * 1000L)

2009-04-04T12:22:00.006-03:00

Para aqueles que acompanham meu blog (mas não comentam, ;), devem estar se perguntando o motivo do jejum de posts. Não, eu não desisti do blog. O que aconteceu, ou melhor, está acontecendo, é uma dedicação 110% no trabalho. Peço um pouco de paciência e compreensão a todos. Assim que puder, estarei de volta com novas postagens.

Abraços!

PS: Pra quem não entendeu o título deste post, significa "hibernar" o blog por 2 meses, que é justamente o que aconteceu em março e vai se repetir em abril :(

Spring Framework: Você sabia? Parte I - Validando parâmetros

2009-03-01T09:37:00.006-03:00

Pra começar essa série de posts sobre o lado "oculto" do Spring, vamos conhecer algumas classes utilitárias que podem evitar (drasticamente) a repetição de código para validação de parâmetros. Por exemplo, quantas vezes você já validou Strings dessa forma?


public void setNome(String nome) {
  if (nome == null || "".equals(nome)) {
    throw new IllegalArgumentException("Nome requerido!");
  }
}

Algumas vezes? Muitas vezes? Pois é, eu perdi a conta. Mas isso foi ANTES de fuçar na API do Spring:


import org.springframework.util.Assert;
...
public void setNome(String nome) {
  Assert.hasLength(nome, "Nome requerido!");
}
...

As vezes pequenos detalhes passam despercebidos e perdemos horas revirando código atrás de um problema. E se o argumento nome for uma String não vazia contendo somente espaços em branco, por exemplo, " " ? Se não for permitido, o código precisa de reparos:


public void setNome(String nome) {
  Assert.hasText(nome, "Nome requerido!");
}

As vezes a coisa pode tão simples quanto um null-check:


public void setValorObrigatorio(Object obj) {
  if (obj == null) {
    throw new IllegalArgumentException("Valor obrigatório!");
  }
}

Não tem desculpa. Antes 1 linha do que 3:


public void setValorObrigatorio(Object obj) {
  Assert.notNull(obj, "Valor obrigatório!");
}

As vezes a coisa pode ser mais complicada. Por exemplo, Arrays ou Collections que não podem ser vazios:


public void setArrayNaoVazio(Object[] array) {
  if (array == null || array.length == 0) {
    throw new IllegalArgumentException("Array não pode ser vazio!");
  }
}

public void setCollectionNaoVazia(Collection collection) {
  if (collection == null || collection.isEmpty() == 0) {
    throw new IllegalArgumentException("Collection não pode ser vazia!");
  }
}

Com certeza não precisamos fazer isso...


public void setArrayNaoVazio(Object[] array) {
  Assert.notEmpty(array, "Array não pode ser vazio!");
}

public void setCollectionNaoVazia(Collection collection) {
  Assert.notEmpty(collection, "Collection não pode ser vazia!");
}

E assim encerro a parte 1 desta série. Não deixem de conferir a classe Assert por completo através da documentação online. Há outros métodos não abordados não menos úteis do que os apresentados neste post. Vá mais longe, explore o código-fonte dela. Eu particularmente acho o Spring Framework o open source melhor documentado da atualidade.

Abraço!

Spring Framework: Você sabia? (prelúdio)

2009-02-24T22:22:00.005-03:00

Lembro como se fosse ontem quando visitei pela primeira vez o site do Spring Framework. Naquela época eu tinha acabado de entrar no mercado de trabalho e já me deparava com projetos JSP + Servlets estruturados de forma assustadora. Tinha JDBC dentro de Servlet, de JSP, objetos duplicados sem necessidade, factories pra todo lado... Dói só de lembrar.

Confesso que quando li a definição de IoC pela primeira vez, simplesmente não entendi NADA. "Esse Martin Fowler tá viajando geral"! Mas não desisti e comecei a avançar na documentação (que diga-se de passagem sempre foi ÓTIMA). Não demorou muito para concluir que aquilo era algo simplesmente genial e essencial para minha vida profissional. E foi, ou melhor, está sendo.

Isso foi em meados de 2005. Spring estava na versão 1.2.x. Época de muitos XMLs (Spring, Hibernate, etc). Era preciso muita organização e convenções pra não se perder no meio de tantos beans, SpringIDE não existia.

Assim que adquiri meu primeiro cartão de crédito internacional, entrei no site da Amazon e comprei 2 livros de Spring: Pro Spring e Professional Java Development with the Spring Framework. Outros vieram depois, mas as 2 semanas que passei lendo o Pro Spring foram essenciais para as decisões que tomei logo em sequência.

Mas afinal do que se trata esse post? Vou explicar. Esse post é apenas um prelúdio da minha experiência com o Spring. Nos próximos que virão, estarei abordando recursos e funcionalidades não tão divulgados pelo framework. Não vou perder tempo mostrando as 1001 formas de fazer injeção de dependência, ou como integrar com Hibernate de forma mais robusta e produtiva. Isso você acha aos montes por aí. O foco será explorar as ferramentas menos populares desse verdadeiro canivete suíço virtual.

Fiquem na escuta. Parte 1 tá no forno!

Lazy Objects em ação!

2009-02-22T12:03:00.011-03:00

A discussão é antiga: Lazy Loading (ou Lazy Instantiation). Antes de mais nada atenção: não estou me referindo aos problemas de Lazy Loading do Hibernate (LazyInitializationException). Me refiro a inicialização tardia de objetos complexos para fins de otimização de memória.

Ao invés de longas explicações, vamos ao código:


import java.io.BufferedWriter;
import java.io.FileWriter;
import java.io.IOException;

public class LogFile { 
  private BufferedWriter writer;
 
  public LogFile() {
    openFile();
  }

  private void openFile() {
    try {
      writer = new BufferedWriter(new FileWriter("logFile.log", true));
    } catch (IOException e) {
      throw new RuntimeException(e);
    }
  }

  public void debug(String message) {
    try {
      writer.write("DEBUG: " + message);
    } catch (IOException e) {
      throw new RuntimeException(e);
    }
  }
}

Somente analisando a classe acima fica difícil assumir que haja algo de errado com ela, certo? Então vou adicionar um requisito: O arquivo de log deverá ser inicializado somente quando necessário, ou seja, na primeira invocação do método debug. Adaptar o código não chega a ser uma tarefa complicada:


// imports omitidos

public class LogFile { 
  private BufferedWriter writer;
 
  public LogFile() {
    // openFile();
  }

  // método renomeado p/ deixar claro seu funcionamento
  private void openFileIfNecessary() {
    if (writer == null) {
      try {
        writer = new BufferedWriter(new FileWriter("logFile.log", true));
      } catch (IOException e) {
        throw new RuntimeException(e);
      }
    }
  }

  public void debug(String message) {
    try {
      openFileIfNecessary();writer.write("DEBUG: " + message);
    } catch (IOException e) {
      throw new RuntimeException(e);
    }
  }
}

Problema resolvido, certo? Sim e não. Caso esta classe seja utilizada em um ambiente single thread (ex. GWT), sim. Caso contrário, precisamos consertar o método openFileIfNecessary para deixar a classe thread-safe. Aplicando o conceito double-checked locking:


// imports omitidos

public class LogFile { 
  private volatile BufferedWriter writer;
 
  public LogFile() {
  }

  private void openFileIfNecessary() {
    if (writer == null) {
      synchronized (this) {
        if (writer == null) {
          try {
            writer = new BufferedWriter(new FileWriter("logFile.log", true));
          } catch (IOException e) {
            throw new RuntimeException(e);
          }
        }
      }
    }
  }

  public void debug(String message) {
    try {
      openFileIfNecessary();
      writer.write("DEBUG: " + message);
    } catch (IOException e) {
      throw new RuntimeException(e);
    }
  }
}

Apesar do exemplo não ser tão ilustrativo como eu esperava, experimente repetir esse comportamento com outros atributos "pesados". O trabalho se torna repetitivo e você acabará: 1) se conformando; 2) criando uma classe de suporte. Comigo acontenceu a opção 2, a qual compartilho abaixo:


package com.blogspot.eduardorebola.lazyobject;

public abstract class LazyObject<T> {
  private volatile T lazyObject;

  protected abstract T createObject();

  public T get() {
    return get(true);
  }

  public T get(boolean createIfNecessary) {
    if (createIfNecessary && lazyObject == null) {
      synchronized (this) {
        if (lazyObject == null) {
          lazyObject = createObject();
        }
      }
    }
    return lazyObject;
  }

  public final boolean isLoaded() {
    if (lazyObject == null) {
      synchronized (this) {
        return lazyObject != null;
      }
    }
    return true;
  }
}

Perceba como a classe controla a criação do objeto e garante que ele se comporte como um singleton. Todos os pontos discutidos até o momento (inicialização tardia, thread-safe) estão implementados numa classe só, agora basta estendê-la com o tipo desejado e implementar a lógica de construção do objeto.

Infelizmente há algumas limitações nesta implementação vinculadas ao construtor do objeto encapsulado: 1) Não é possível passar parâmetros; 2) Não se pode lançar checked exceptions. Há mais uma limitação referente ao double-checked locking: Só funciona a partir do Java 5.

Adaptando o exemplo anterior, temos o seguinte resultado:


package com.blogspot.eduardorebola.lazyobject;

import java.io.BufferedWriter;
import java.io.FileWriter;
import java.io.IOException;

public class LogFile { 
  private LazyObject<BufferedWriter> writer;
 
  public LogFile() {
    writer = new LazyObject<BufferedWriter>() {
      protected BufferedWriter createObject() {
        try {
          writer = new BufferedWriter(new FileWriter("logFile.log", true));
        } catch (IOException e) {
          throw new RuntimeException(e);
        }
      }
    };
  }

  public void debug(String message) {
    try {
      writer.get().write("DEBUG: " + message);
    } catch (IOException e) {
      throw new RuntimeException(e);
    }
  }
}

Dúvidas, sugestões, melhorias? Deixe seu comentário. A comunidade agradece! Até a próximo!

Rebola.

Por que decidi montar um blog?

2009-02-19T21:57:00.005-03:00

Hello World!

Blog é algo revolucionário. Me lembra muito a idéia de um diário, porém sem se preocupar em escondê-lo. Nele nós desabafamos, escrevemos coisas que deram certo e coisas que ainda nos incomodam. Após cada postagens, ficamos ansiosos na espera de um comentário, seja bom ou ruim, pois só vai valer a pena se alguém do outro lado dizer o que pensa a respeito.

Minha idéia nesse espaço é estar expondo minhas experiências profissionais. Como desenvolvedor de sistemas, cada dia me deparo com um novo problema, um velho problema ou um futuro problema. Estamos constantemente tomando decisões de projeto, de implementação, de gerência, etc. O que for possível publicar, publicarei. Convido todos meus colegas de profissão a dividirem suas experiências com os demais leitores deste blog.

Se não criei um blog antes foi por saber que não estava preparado para mantê-lo. Se for para postar mensalmente, não vale a pena. Blog é compromisso. Todo dia você vive algo novo, presencia uma situação diferente. Sempre há algo para dividir.

Meu muito obrigado a você que chegou até essa última linha. Até mais ver!

Rebola.