Sectio Aurea

Bitmask

Diogo Dauster Pontual — Fri, 06 Jan 2012 12:50:00 +0000

Introdução

Um dos recursos mais utilizados por programadores em todos os tempos, extremamente rápido, eficiente e prático, chama-se bitmask.

Infelizmente tem sido consolidada a visão de que tudo que exige o conhecimento mínimo de programação é ruim, porque diminui a clareza do código. Em “diminui a clareza do código” leia: torna o código ilegível para programadores que não sabem programar… mas tudo bem. O coitado do bitmask sofreu com isso.

Trata-se de uma ferramenta muito legal para armazenar e comunicar estados compostos por n condições.

Em uma variável tipo byte (em java), você armazena até 7 informações de estado diferentes. Em um short são 15 informações. Sem quaisquer necessidades de computações mirabolantes adicionais.

Aliás se Java tivesse tipos numéricos sem sinais, poderíamos usar os 8 bits de cada byte. Mas isso é outra discussão.

A Mágica

Vamos imaginar que estamos vistoriando um carro, e queremos armazenar em uma variável byte as seguintes informações:

O carro está com todos os 4 pneus em condições de uso;
O carro possui combustível;
O carro possui óleo de freio;
O carro possui óleo de motor;

Atribua uma potência de 2 a cada informação que deseja armazenar, assim:

2ˆ0 = 1 -> O carro está com todos os 4 pneus em condições de uso;
2ˆ1 = 2 -> O carro possui combustível;
2ˆ2 = 4 -> O carro possui óleo de freio;
2ˆ3 = 8 -> O carro possui óleo de motor;

Crie uma variável “estadoDoCarro” e atribua a ela a soma das condições que correspondem a realidade do carro:

2ˆ0 = 1 -> O carro está com todos os 4 pneus em condições de uso;
2ˆ1 = 2 -> O carro possui combustível;
2ˆ2 = 4 -> O carro possui óleo de freio;

RESULTADO DA SOMA = 7

byte estadoDoCarro = 7;

Para verificar quais as condições satisfeitas basta utilizar o operador ‘&’:

byte b = 11;
if ((b & 1) != 0)
   System.out.println("O carro está com todos os 4 pneus em condições de uso;");
if ((b & 2) != 0)
   System.out.println("O carro possui combustível;");
if ((b & 4) != 0)
   System.out.println("O carro possui óleo de freio;");
if ((b & 8 ) != 0)
   System.out.println("O carro possui óleo de motor;");

Qual é o truque?

Utilizando as potências de 2 estamos “ligando/desligando” cada um dos bits, e “concatenando” booleans. Veja:

Decimal	Binário
0	0
1	1
2	10
4	100
8	1000
16	10000

Observações

Em Java existe a classe java.util.BitSet que pode ser bastante útil para essas representações de estado;
Outros operadores como o ‘|’ são úteis para esse tipo de técnica, e devem ser dominados por qualquer programador;
Aqueles ifs acima podem ser facilmente substituidos por um loop;
Cada um dos componentes (as potências de dois), normalmente deve ser armazenada em uma constante.

Considerações sobre Strings

Diogo Dauster Pontual — Wed, 04 Jan 2012 22:00:24 +0000

Talvez a classe String seja uma das 2 ou 3 mais utilizadas da API Java, mas mesmo assim é comum que programados saiam criando “blah,blah,blah”, sem ter idéia do que está acontecendo por baixo dos panos, e consequentemente sem poder tomar as melhores decisões com relação à segurança e performance.

Seguem algumas considerações sobre Strings em Java, cujos conhecimentos são importantes para que programadores tomem suas decisões:

Uma String é uma cadeia de caracteres. Caracteres em Java são representações no formato UTF-16;
No código-fonte, uma literal do tipo String é composta por zero ou mais caracteres delimitados por aspas duplas;
Uma literal do tipo String é sempre compilada como um objeto da classe String;
Strings com o mesmo conteúdo são na verdade o mesmo objeto. Observe
```
String a = "Teste", b = "Teste";
System.out.println(a == b);
```
Irá imprimir “true”, porque a e b são referências ao mesmo objeto;
Objetos do tipo String são imutáveis. Sempre que uma instrução altera o conteúdo de uma String, ela está na verdade mudando a referência para um objeto recém-criado, ou um reaproveitado (caso o mesmo valor já exista na memória);
Concatenações entre Strings cujos resultados possam ser inferidos em tempo de compilação são feitas na compilação (entre literais, por exemplo);
Concatenações entre Strings cujos valores não possam ser conhecidos na compilação, implicam na criação de uma nova instância da classe String;
A classe java.lang.StringBuilder, é uma sequência de caracteres desenvolvida para ser utilizada por uma única thread;
A classe java.lang.StringBuffer, é uma sequência de caracteres desenvolvida para que suas instâncias possam ser acessadas e modificadas por várias threads de forma segura.

Leituras interessantes:

http://pt.wikipedia.org/wiki/UTF-16
http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.5
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.3.3
http://docs.oracle.com/javase/6/docs/api/java/lang/StringBuilder.html
http://docs.oracle.com/javase/6/docs/api/java/lang/StringBuffer.html

Existem outras coisas importantes para se saber sobre Strings em Java, mas esse é, na minha opinião o pacote básico.

Modificador volatile

Diogo Dauster Pontual — Wed, 04 Jan 2012 15:28:30 +0000

Contexto

Para que se entenda a utilidade e o funcionamento do modificador volatile, é necessário conhecer um pouquinho sobre como programas em Java armazenam e acessam variáveis nas diversas memórias disponíveis em um computador.

Tenha em mente as seguintes assertivas (bastante simplificadas):

O programa acessa e manipula alguns tipos de memória diferentes: registradores, cache, ram;
As diferentes memórias possuem performances diferentes;
Registrador é um tipo de memória muito cara, que fica dentro do próprio processador e por isso tem velocidade excelente;
Memória cache é um tipo de memória que fica próxima ao processador e normalmente pertence a um dos seguintes 3 grupos: L1 (pequena e rápida, uma por processador), L2 (maior e menos rápida, uma por processador), l3 (bem maior e menos rápida, compartilhada entre processadores);
Alguns computadores não possuem L2 e ou L3, por questões econômicas;
Memória RAM é a memória principal do computador, e a maior entre as que foram citadas. Com a tecnologia atual, ela é sempre muito mais lenta que o processador, e por isso as outras formas de memória são necessárias.

Além disso é importante saber que o compilador pode fazer algumas alterações na ordem das instruções do programa, para otimizar o processamento e o acesso à memória, veja o código:

public class Test{
   int a,b;
   public void escrever(){
      a = 1;
      b = 1;
   }
   public void ler(){
      int lidoA = a;
      int lidoB = b;
      System.out.print(a);
      System.out.println(b);
   }
}

O compilador e a JVM não provêem qualquer garantia de que as instruções serão executadas na ordem em que foram escritas pelo programador, caso eles entendam que as instruções são independentes. Então, no exemplo acima, caso uma thread chame o método escrever, e outra chame o método ler, o resultado pode ser 00,01,11 ou 10, sem que o programador possa prevê-lo inequívocamente.

Então: Para melhorar a performance, o compilador, a JVM e os processadores armazenam “cópias locais” das variáveis em locais de acesso mais fácil (cache), fazendo com que threads diferentes possam ter acesso à versões diferentes das mesmas variáveis. Além disso eles reordenam as instruções de forma a otimizar o acesso e a escrita nas diferentes memórias. Quando há um tempinho disponível as diferentes memórias são sincronizadas, mas não há como prever e garantir quando isso será feito.

Em função de tudo isso, uma determinada thread pode trabalhar sobre um conjunto de dados obsoleto (stale data),

Era necessário haver um mecanismo que garantisse que todas as threads vissem determinadas variáveis com o mesmo valor, o tempo todo.

Volatile

O modificador volatile é usado para garantir a consistência do estado de variáveis entre diferentes threads. Cada leitura a uma variável volatile irá retornar o último valor atribuído a ela por qualquer thread. Para garantir isso as seguintes regras são válidas:

O processador e a JVM não podem armazenar variáveis volatile nos registradores;
Escritas em variáveis volatile são imediatamente enviadas dos caches para a memória principal do computador;
Imediatamente antes de retornar o valor de uma variável volatile, o cache correspondente é invalidado, fazendo com que o valor retornado seja aquele presente na memória principal do computador.

Além disso, instruções que envolvem variáveis volatile não podem ser reordenadas entre si, e existem grandes restrições quanto à forma como elas podem ser reordenadas com instruções relacionadas às variáveis não-volatile. De fato, instruções que operam sobre variáveis volatile funcionam como entradas e saídas de blocos synchronized, visto que elas provocam a sincronização entre o cache utilizado pela thread e a memória principal do computador.

Naturalmente variáveis volatile, implicam em perda de performance, visto que diminuem a capacidade do compilador otimizar o código, e obrigam o acesso mais frequente e não otimizado a memória principal. Então use com moderação.

Observações Finais

Esse artigo é praticamente todo válido para JVM’s anteriores à 5 e completamente válido para a JVM 5 ou as posteriores.

A JVM 5 implementou a JSR-133 que especifica o “Java Memory Model“, que nasceu da percepção de que haviam vários “buracos” na forma como programas multi-thread escritos em Java lidavam com a memória, resultando em inconsistências e baixa performance.

Leituras Importantes

http://informatica.hsw.uol.com.br/memoria-do-computador.htm
http://en.wikipedia.org/wiki/Java_Memory_Model
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html

Testes unitários em classes que abrem sockets

Diogo Dauster Pontual — Wed, 04 Jan 2012 01:34:41 +0000

Ao desenvolver uma aplicação que se conecta com alguns servidores através de sockets, tive dificuldades para identificar uma forma prática e confiável de testar o código responsável pela comunicação com o servidor.

Pesquisei bastante pela Internet e a maioria das referências que encontrei indicavam o uso de Mocks para simular a conexão.

Eu não fiquei satisfeito com isso, pois queria testar a camada de rede sob condições no mínimo realistas. Então escrevi uma classe EchoServer que levanta um servidor em uma determinada porta, recebe textos dos clientes e os envia de volta.

Essa abordagem deve resolver as dificuldades de testes, e gerar testes confiáveis para a grande maioria das aplicações que abrem sockets para trocar textos com servidores.

Apesar de a classe não ter nada demais, e ser praticamente igual às que devem ser encontradas em qualquer livro sobre java.nio, ela está disponível neste artigo para aqueles que a quiserem.

Arquivo para download

Method Chaining

Diogo Dauster Pontual — Tue, 03 Jan 2012 19:35:49 +0000

Estamos tão acostumados com o padrão Javabean: gets, sets e propriedades privadas, que é comum não refletirmos sobre algumas decisões que tomamos ao definir as interfaces de nossas classes.

Uma técnica relativamente comum é o Method Chaining. Trocando em miúdos, bem miúdos, consiste em fazer os seus métodos set retornarem 'this'. Algumas classes da API Java funcionam assim, veja a documentação de StringBuffer, por exemplo.

E o que eu ganho com isso?

Concisão, legibilidade, clareza, praticidade…

Um código que poderia ser assim:

stringBuffer.mark();
stringBuffer.position(8);
stringBuffer.reset();

fica assim:

stringBuffeer.mark().position(8).reset();

Bem melhor não?

Como fazer?

Simples, substitua isso:

public void setName(String name){
   this.name = name;
}
public void setEmail(String email){
   this.email = email;
}

por isso:

public User name(String name){
   this.name = name;
   return this;
}
public User email(String email){
   this.email = email;
   return this;
}

E use assim:

User u = new User().name("Fulaninho").email("fulaninho@gmail.com");

E seja feliz.

UMLet

Diogo Dauster Pontual — Tue, 03 Jan 2012 18:15:09 +0000

Frequentemente temos que criar diagramas UML para conseguirmos comunicar nossas intenções. Seja para clientes, seja para colegas, seja para colar em um artigo.

Eu experimentei um milhão de ferramentas desenvolvidas para esse fim e, sinceramente, nunca havia gostado de nenhuma. Tenho a impressão de que os criadores dessas ferramentas, acham que vão resolver todos os problemas do mundo com um software para criar diagramas, e saem enfiando funções, menus contextuais, drags-and-drops mirabolantes, e criam ferramentas extremamente complicadas, cujos custos com tarefas burocráticas são maiores do que os benefícios adquiridos com os diagramas… Essa é a minha impressão.

Mas os meus problemas acabaram. Conheci o UMLet, uma programinha feito em Java, extremamente simples, que suporta diversos diagramas e quase não exige que o “desenhista” fique pulando com a mão do mouse para o teclado e vice-versa.

O link é: http://www.umlet.com .

Fica a dica…