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.

Effective java 2

Continuando a minha saga através do livro Effective Java de Joshua Block, vou agora comentar item 2 do Livro (Executando o singleton através de construtores privados).

Singleton é um padrão de projeto que estabelece que uma classe só poderá ter um único objeto instanciado, esse é um padrão relativamente comum, por isso, há muita polêmica em torno dele, muito acreditam que o uso do singleton descaracteriza a orientação a objeto. Eu acho que não é bem assim, o que aconteceu com o singleton foi um mal muito comum em computação, ele virou moda, e por ter se tornado moda, muita gente abusou do seu uso, isso é uma coisa legal do Effective Java, o singleton é bastante abordado, com isso podemos fazer o uso correto desse padrão de projeto.

Basicamente temos duas alternativas para o uso de construtores privados. A primeira consistiria em deixar um instância da classe definida como estática, publica e final, mantendo o construtor privado. A segunda consistiria em manter uma instância estática e privada, fornecendo um método estático e publico para o acesso a instância, evidentemente, assim como na primeira alternativa devemos deixar o construtor como privado.

A principal vantagem da primeira alternativa é clareza na implementação do singleton, pois é um pouco óbvio que uma classe que não tenha construtores e uma instância da própria classe como pública, estática e final, pois o fato desse objeto da classe ser final, de certa forma denúncia um singleton.

A principal vantagem da segunda alternativa é possibilidade de ser fazer novas coisas através do método estático e publico se obter a instância. Por exemplo, poderia se escolher um construtor diferente ou controlar o número de instâncias como em um pool de objetos.

Um aspecto que pode causar desconforto no uso do singleton é na serialização de objetos, a simples implementação da interface Serializable pode não ser suficiente, entretanto, vou deixar para tratar os pormenores desse assunto mais adiante.

Effective Java 1

Fiz esse blog para tratar dois assuntos, basicamente, Computação e Informação, quando eu digo informação, estou falando de ciência da informação, ainda não falei nada de computação, então esse será o primeiro de um série de post sobre o livro “Effective Java” de Joushua Block, pq cho que esse é um bom pretexto para falar de uma das coisas que eu mais gosto, programação de computadores.
Embora esse seja um livro de Java, ele poderia muito bem se chamar Effective SmallTalk, ou Effective Rubi ou Effetive qualquer outra linguagem da Orientação a Objetos, pois acredito que esse livro que fale muito mais de Orientação a Objetos do que qualquer outra coisa, como por exxemplo, os detalhes da sintaxe Java. O livro é divido em 57 tópicos, vou comentar cada um deles sobre meu ponto de vista. O primeiro tópico é o seguinte “Considere fornecer métodos státicos para fabricar objetos ao invés de um construtor”.
A primeira boa razão para se fazer isso é: métodos abstratos tem um nome, diferentemente dos construtores que devem ter o mesmo nome do que a classe, por exemplo, considere os dois exemplos a seguir: a classe cachorro usa um contrutor Cachorro() e a classe gato usa um método statico novoGato(), o nome do método novoGato() é muito mais intuitivo que o contrutor Cachorro(), mesmo que esse método não tivesse nenhum comentário ou JavaDoc, ficaria muito fácil de saber o que ele faz.

public class Cachorro{
public Cachorro(){
}
}

public class Gato{
public static Gato novoGato(){
return new Gato();
}
}

A Segunda razão para se usar métodos státicos para criar objetos, o invés de usar construtores é: Em um método stático vc não é obrigado a criar um objeto novo toda vez que o método é chamado. A aplicação para isso é o popular partten singleton, mas outras aplicações para isso com certeza pode sem implementas, dependendo, é claro do escopo do projeto que vc esteja trabalhando.

A terceira razão para se utilizar métodos estáticos para a criação de objetos é que eles podem retornar objetos de qualquer tipo que seja subclasse da classe em questão, isso sim, dá uma grande liberdade ao desenvolvedor, enquanto está trabalhando em seu projeto. A API de colletions nativa do Java usa e abusa dessa idéia.

Mas como tudo na vida, há desvantagens de se usar métodos estáticos para criar objetos, são elas: classes que não tenham seus construtores públicos (public) ou protegidos (protect), como é o caso da implementação do singleton, não poderão gerar sub-classes. Métodos státicos usados para criar novos objetos são iguais aos outros métodos estáticos, não há nada que os diferencie dos outros métodos státicos.

Arquisteps

Olá pessoal, hoje vou apresentar o resultado do meu trabalho de conclusão de curso no curso de bacharelado de Biblioteconomia e Documentação na Escola de Comunicações da Universidade de São Paulo e Artes, o Arquisteps.
O Arquisteps é um programa desenvolvido em Java e C, como uma função bem simples, auxiliar na elaboração do Plano de Classificação e Tabela de Temporalidade, esta é uma versão beta, com alguns bugs, por isso, não recomendo o uso comercial do programa, todavia, estou precisando de ajuda: sugestões de melhorias, relatórios de bugs e claros desenvolvimentos, serão muito bem vindos.
O programa e o manual do usuário podem ser baixados no link abaixo:

Instalador do Arquisteps

Winisis benção ou maldição?

Com o Winsis dá para construir planilhas compatíveis com o Marc, já ouvi muito bibliotecário falar que não gosta do Marc, mas pó, se vc é bibliotecário e não gosta de padrão, é melhor vc usar um sistema de locadora, pelo menos o empréstimo vai funcionar legal. A interface num é problema, dá pra custumizar, não o suficiente, pelo menos pra mim, mas dá pra customizar. Outra coisa é a confusão com os nomes, Winisis não é Microsis, Winisis não roda em linha de comando, o Microsis sim. Aliás eu gosto de linha de comando, o mysql até bem pouco tempo atrás só tinha linha de comando, mas admito usar a linha de comando com destreza é coisa de usuário avançado, tem um ponto muito bom no Winisis, o arquivo invertido, ele indexa texto muito bem, se vc pegar um sisteminha qualquer, desenvolvido com banco de dados relacionais (mysql,postgree,oracle,sqlsever) em que o cara fique usando “Select * from table where like %text%” a performace vai para a meretriz que deu a luz e os sistema vai ser uma porcaria, o cara vai ter de fazer um banco muito bem feito, com vários index, enfim, não é coisa para amador.
Por outro lado dão muita ênfase ao Winisi nos cursos de Bibliotecnomia, acho que o maior problema não é o Winsis em si, o maior problema é ter o Winisis como única opção, quando foi criado, o Winisis era uma ótima ferramenta, entretanto, existem hoje várias tecnologia como: open-url, Haverst de metadados, FRBR a até mesmo os já batidos z39.50, circulação de material e DSI são razões para não se usar o Winisis em uma biblioteca séria. Entretanto, existem algumas consultorias que fazem um bom trabalho com o Winisis e até fazem com que algumas das suas precariedades sejam relevadas, mas infelizmente, algumas vezes, chamar uma consultoria tira do Winisis um o seu maior ponto positivo, ele deixa de ser gratuito, pois vc tem de pagar pela consultoria.
Enfim, o que vc acha, o Winsis é uma benção ou maldição?