Effective Java 6.

A melhor forma de não errar ao sobrescrever os métodos equals é não sobrescrevê-lo, e acredite, essa será a melhor opção quando: Cada instância da classe herda de unique, você não se importa com o teste para verificar se duas instancias são igual, uma outra classe sobrescreve o método equals e esse comportamento é adequado e herdado pela nova classe e uma classe privada ou privada em um pacote sendo que o método equals nunca será usado.
Ok, agora que já sabemos quando não devemos sobrescrever o e pergunta óbvia é , quando sobrescrevê-lo então? Bem, devemos sobrescrever o método com equals quando a nossa classe tiver um comportamento específico de comparação e nenhum de suas superclasses tenha implementado esse comportamento.
Agora que vimos quando implementar e quando não implementar o método equals, devemos ter conhecimento do contrato estabelecido para esse método, resumidamente, o método equals deve:
Ser reflexivo: Para qualquer valor de x, a sentença x.equals(x) deve retornar verdadeiro sempre. Ser simétrico: Para qualquer valores de x e de y, a sentença x.equals(y) deve retornar verdadeiro, se e somente se, y.equals(x) retornar verdadeiro. Ser transitivo: Para qualquer valores de x,y e z, se x.equals(y) retornar verdadeiro e y.equals(z) retornar verdadeiro, x.equals(z) dever retornar verdadeiro.Ser consistente: Para qualquer valor de x e de z, caso x.equals(z) retorne verdadeiro ou falso para chamadas o método equals deve retornar verdadeiro ou falso consitentemente. Para qualquer valor de x, a sentença x.equals(null) deve retornar falso sempre.
Então quando for sobrescrever o método equals, faça as seguintes perguntas a si mesmo: A minha implementação do método equals é simétrica? É transitiva? É consistente? As outras duas cláusulas, normalmente tomam conta de si mesmas.
Para finalizar considere as seguintes afirmações: Sempre que sobrescrever o método equals, também sobrescreva o método hasCode, Não escreve métodos equals that relies on unrealiable resourses e não substitua a classe Object por outra classe na assinatura do método equals.

Effective Java 5.

Em algumas lingugens como Pascal, C++ e C, vc pode fazer o gerencimento de memória manualmente, mas em Java temos o Garbage Colletion e podemos não ligar para isso, certo? Não errado, seu programas em Java podem perfeitmente estorar memória do mesmo jeito que os programas em C o fazem quando esquecemos de usar o free para liberar a memória.
Imaginemos que estamos querendo implementar uma classe com o java.util.ArrayList, é rasoável supor que teremos de implementar uma rotinar para retirar elementos do nosso aray, algo como o código pop abaixo:

public Object pop(){
if (size == 0)
throw new EmptyStackException();
return elements[ --size];
}

Na muito exepcional, esse código compilaria e rodaria sem problemas, passaria em muitos teste, mas de vez em quando poderia causar degradação da performace e em casos extermos um OutOfMemoryError, isso porque o array elements pode ficar cheio de referências não utilizados. Um jeito de corrigir isso seria algo como o código abaixo:

public Object pop(){
if (size == 0)
throw new EmptyStackException();
elements[size] = null;
return elements[ --size];
}

Agora o elemento eliminado do array elements é elegível ao processo de eliminação do Garbage Colletion e não teremos os problemas apresentados no código anterior.

Effective Java 4

Proibir a duplicação de objetos, isso faz um tremendo sentido, se vc já tem um objeto da classe pessoa instanciado por que diabos vc vai instanciar um outro objeto da classe pessoa com os mesmo valores, é só vc usar o objeto já instanciado, vc vai economizar tempo, recursos de S.O e máquina, no caso de ter poucos objetos isso não fará muita diferença, mas se vc tiver dezenas ou centenas de objetos instanciados isso pode vai te economizar muitos recursos de S.O e máquina.
Bloch no seu livro, cita como exemplo o classe String, a classe String usa um pools, ou seja, um conjunto de String que ao invés de forçar vc a instanciar uma String nova para valores idênticos vc pode simplesmente usar uma String já instanciada anteriormente, entretanto, mesmo com o recurso do pools vc pode duplicar um objeto String caso vc chame no seu código o construtor da classe String ( String valor = new String(“Valor”);) ao invés de usar a sobre carga do operador ‘=’ para a classe String ( String valor = “Valor”; ).
Sendo assim lembre-se Java é uma boa linguagem, mas não é aprova de estupidez, use (String valor = “Valor”;) no lugar de (String valor = “Valor”;)

Canal da Library of Congress no Youtube

Sou um cara com opiniões controversas a respeito de quase tudo, uma delas é sobre web 2, na minha singela opinião web 2 é só um nome, bem admito, um bom nome se for usado para alertar as pessoas das novas possibilidades de interações oferecidas pela web, mas mesmo assim é só um nome, mas já entendi que bons nomes e marketing fazem toda diferença no mercado de TI, se não fosse isso, todo mundo usaria Linux ao invés de Windows. Agora uma biblioteca gigante resolveu cair dentro da onda Web2, a Library of Congress lançou seu canal no Youtube, confira no endereço: http://www.youtube.com/user/LibraryOfCongress

Em busca de uma ferramenta de Wiki para biblioteca

Quem já tentou fazer uma wiki page para sua biblioteca sempre encontra um problema que muitas vezes parece intransponível, qual ferramente escolher? Disponibilidade, backup e pessoal de TI que conheçam a ferramenta são aspectos difíceis de transpor, entretanto, por isso, resolvi lançar uma nova série de artigos nesse blog, "em busca de uma ferramenta de Wiki para biblioteca".
Nesta série de artigos pretendo analisar as ferramentas de Wiki presentes no site WikiEngines . Já analisei algumas, não encontrei nenhuma bacana, mas vou postar os resultados das minhas aventuras wiki.

Effective java 3

Voltando a minha jornada pelo Effective Java de Joshua Bloch, vou tratar de um tópico MUITO polêmico, trata-se de como garantir a que as classes não sejam instanciadas.
Isso é um tremendo caroço, no seu livro Bloch diz que isso pode ser usado de maneira sensata, por exemplo: para agrupar métodos sobre valores primitivos ou Arrays, agrupar em objetos que implementam determinada interface, principalmente java.util.collection. Entretanto, uma crítica muito comum a esse tipo de prática é que ela subverte a programação Orientada a Objetos, opinião que cá entre nós é a minha também.
Sobre o como garantir que suas classes não sejam instanciadas através da prática de tornar privados seu construtores (mesmo com os construtores privados dá para usar reflection, mas vamos deixar isso de lado por enquanto), mas Bloch deixa bem claro, tornar um classe abstract não garante que essa classe não será instanciada, uma classe abstract pode ser instanciada através de uma sub-classe, talvez se classe fosse abstract e final?

Gerenciamento de projetos com PMBOK.

Gerenciamento de projetos é um tópico muito importante na administração, qualquer que seja a sua área, quando se atua no nível gerencial, mas cedo ou mais tarde, você se verá na eminência de implementação de um projeto. O gerenciamento de projeto é algo complexo, gerenciar o seu projeto de forma intuitiva é algo muito arriscado, pois muitas complicações podem aparecer durante a implementação de um projeto.
O PMBOK (Project Management Body of Knowledge) é um metodologia desenvolvida pelo Project Management Institute para o gerenciamento de projetos. O PMBOK é baseado em processos, a quantidade de processos existentes variam conforme a versão do PMBOK, ma esses processos estão agrupados em cinco grupos essenciais:

Iniciação – aqui estão os processos necessários ao início do projeto.
Planejamento – aqui estão os processos ligado ao planejamento do projeto.
Execução – processos ligados as ações relativas ao processo
Monitoramento e controle – processos ligados ao controle e verificações do projeto.
Encerramento – aqui estão os processos necessários ao término do projeto.

Além desses grupos os processos podem estar relacionados com nove área dos conhecimento, sendo elas:

Integração – Área do conhecimento que se faz a harmonização entre as outras áreas do conhecimento
Escopo – Área do conhecimento relacionada coma abrangência do projeto.
Tempo – Área do conhecimento relacionada com o tempo necessário para execução do projeto.
Custo – Área do conhecimento relacionada aos recursos financeiros destinados ao projeto.
Qualidade – Área do conhecimento relacionada com os objetivos do projeto.
Recursos humanos – Área do conhecimento relacionada com os recursos humanos empregados no projeto, inclusive abordando aspectos de capacitação.
Comunicações – Área do conhecimento relacionada as comunicações relacionadas as pessoas envolvidas no projeto (dentro e fora da equipe).
Riscos – Área do conhecimento que é crítica para a finalização do projeto.
Aquisições – Área do conhecimento relacionada a aquisição de insumos necessários aos projetos.