MongoDB: Instalação no Linux

Há algum tempo atrás me interessei pelo MongoDB e resolvi estudá-lo um pouco mais. Fiz um treinamento gratuito disponível no próprio site do fornecedor, e tenho desenvolvido algumas coisas com ele desde então.

Para quem decidir estudar e desenvolver com o MongoDB eu recomendo fortemente, pois apesar de ser uma abordagem totalmente diferente da relacional, à qual estamos mais acostumados, é muito simples de entender e bem satisfatório de usar.

A intenção deste post não é fazer uma introdução ao MongoDB (sugiro, para quem se vira um pouco com o inglês, fazer o curso oferecido pelo site oficial do produto), mas deixar um rápido passo-a-passo de como instalar o MongoDB em um sistema Linux e instalar os driver para algumas linguagens.

Os comandos de instalação abaixo foram os que utilizei com sucesso em minha distribuição Linux (Mint 17.3).

 

Instalação do MongoDB

 

1) Importar a chave pública usada pelo sistema gerenciador de pacotes:

$ sudo apt-key adv –keyserver hkp://keyserver.ubuntu.com:80 –recv EA312927

2) Criar um list file para o MongoDB:

$ echo “deb http://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.2 multiverse” | sudo tee /etc/apt/sources.list.d/mongodb-org-3.2.list

3) Atualizar informações dos pacotes:

$ sudo apt-get update

4) Instalar o MongoDB

$ sudo apt-get install -y mongodb-org

Depois de finalizada a instalação, execute o comando abaixo para verificar a versão do MongoDB instalada:

$ mongo –version

img-1

Para inicializar o MongoDB, execute o comando abaixo:

$ sudo service mongod start

img-2

A instância do MongoDB armazena seus arquivos de dados no diretório /var/lib/mongodb, e seus arquivos de logs no diretório /var/log/mongodb por padrão, e executa com a conta de usuário mongodb. Se necessário é possível alterar os diretórios de log e dados no arquivo /etc/mongod.conf.

A verificação de que o processo mongod iniciou com sucesso pode ser feita através do arquivo de log /var/log/mongodb/mongod.log, com uma linha como esta:

[initandlisten] waiting for connections on port <port> (where <port> is the port configured in /etc/mongod.conf, 27017 by default)

Para parar ou reiniciar o serviço do MongoDB use os comandos abaixo:

$ sudo service mongod stop

img-3

$ sudo service mongod restart

img-4

Para iniciar o console do MongoDB digite o comando abaixo:

$ mongo

img-5.png

> show dbs

img-6

Para sair do console do MongoDB basta digitar CTRL+C.

Para a instalação em outras distribuições ou sistemas operacionais, você pode consultar as instruções no site do projeto.

 

Instalação do Driver para Python

A instalação do driver do MongoDB para Python pode ser feita através do pip, com o comando abaixo:

$ sudo pip install pymongo

Caso não tenha ainda o pip instalado, execute o comando abaixo para instalá-lo:

$ sudo apt-get install python-pip

 

Instalação do Driver para PHP

A instalação do driver do MongoDB para PHP pode ser feita através do pecl, com o comando abaixo:

$ sudo pecl install mongo

Caso não tenha o pecl instalado, execute os comandos abaixo para a instalação:

$ sudo apt-get install php5-dev

$ sudo apt-get install php-pear

Depois de instalado o driver é necessário habilitar a extensão do MongoDB para o PHP, incluindo no arquivo php.ini a seguinte linha, na seção de extensões:

extension=mongo.so

O arquivo php.ini costuma estar no seguinte local:

/etc/php5/apache2/php.ini

Depois de salvar a alteração, reinicie o apache:

sudo /etc/init.d/apache2 restart

Depois disso você pode criar um arquivo chamado info.php com o conteúdo abaixo, e incluí-lo no seu diretório de publicação do apache:

<?php phpinfo(); ?>

Depois, ao acessar o arquivo, deve ser possível encontrar uma seção relacionada ao MongoDB:

img-10.png

 

Instalação do Driver para Java

Para o desenvolvimento em Java, supondo que você esteja usando o Maven, basta adicionar a dependência ao seu pom.xml:

img-9

 

Por hora é isto!

Em breve pretendo publicar posts com exemplos de utilização do MongoDB nestas linguagens, e algumas outras dicas conforme os estudos avançarem.

 

Abraços!

 

 

 

 

WeaverFX – Um concorrente para o Apache Pivot?

Esta semana, participando de um post do GUJ, fiquei sabendo da existência de uma plataforma RIA que muito se assemelha ao Apache Pivot.

O WeaverFX tem a mesma proposta: uma plataforma que permita a criação de aplicações ricas que possam rodar tanto no desktop quanto na web, na forma de applets.

Só hoje tirei um tempo para olhar o site, e ver alguns exemplos. Minha opinião pessoal? Não gostei.

Tenho que admitir que não me dei ao trabalho de criar uma aplicação de exemplo, me contentando apenas com os exemplos apresentados no site do projeto, mas isso foi devido à primeira impressão que tive.

Primeiramente há o fato de que é necessário instalar uma runtime específica para que se possa executar as aplicações. Uma vez que o Apache Pivot não me exige isto, já conto um ponto negativo para o WeaverFX em relação ao Apache Pivot.

 

 

Outra coisa que definitivamente não me agradou foi o “acabamento” dos componentes, e do resultado final das aplicações.

 

 

 

 

 

Apenas para efeito comparativo, eis uma imagem de uma aplicação que fiz em Pivot:

 

 

Ok, o post é tendencioso, admito que prefiro o Apache Pivot, mas também não me coloco na obrigação de ser imparcial =)

Há pessoas que gostaram do WeaverFX, e acredito que realmente é uma questão de escolha. Eu já fiz a minha =)

 

Para quem quiser saber mais sobre o projeto, acessem o site: http://www.weaverfx.com/

Dica: Prototipação com Balsamiq

Esta é uma dica rápida, de uma ferramenta que veio ao encontro de minhas necessidades, e pode ser o que você também procura.

Há algum tempo deixei de usar o iPlotz, e hoje uma colega de trabalho me indicou o Balsamiq.

Não vou explicar muito, apenas colocar uma imagem de uma tela e deixar o link para quem tiver interesse.

 

 

A instalação é fácil, mas é preciso ter instalada a plataforma AIR da Adobe (o que também é fácil conseguir – há um link na página de instalação para se chegar na instalação do AIR).

Eis a página do projeto: http://balsamiq.com/

 

Está dada a dica!

Boas Práticas na Utilização de Controle de Versão

Controle de versões representa a possibilidade de compartilhar arquivos, armazenar todas alterações e resolver os conflitos de edição. A sua utilização é fundamental durante todo o ciclo de desenvolvimento, armazenando artefatos de especificações até o código fonte.

Com o controle de versão é possível que diversos desenvolvedores editem o mesmo documento e todas alterações sejam armazenadas para que o histórico seja mantido e conflitos nas edições solucionados. Outra função muito importante do controle de versões é armazenar todas alterações que um documento sofreu e permitir a recuperação de qualquer uma das versões anteriores.

Embora a utilização de controle de versões possa facilitar a vida dos desenvolvedoes, a falta de organização e padronização pode levar a mais problemas do que soluções.

A seguir serão apresentadas algumas boas práticas referentes a utilização de ferramentas de controle de versão, mais especificamente o Subversion, retiradas de algumas das referências citadas ao final do documento.

Usar um layout de repositório adequado

Há alguns pontos a considerar quando se está configurando um repositório do Subversion. O primeiro deles é se será criado um único repositório para vários projetos, ou um repositório para cada projeto, ou então alguma forma de combinação das duas opções. Há prós e contras em cada uma das opções.

Há benefícios ao se utilizar um único repositório para vários projetos, e o mais óbvio deles é evitar a duplicidade de manutenção:

  • Um único backup a ser feito periodicamente;
  • Um único ponto a exportar e carregar quando há uma nova versão do Subversion que é imcompatível com as anteriores;
  • Facilidade para mover dados entre projetos, e sem perder o histórico destes dados (mover dados entre repositórios diferentes causa a perda do histórico dos dados).

A contrapartida de se utilizar um único repositório para vários projetos é que:

Diferentes projetos podem ter diferentes requisitos de autorização e autenticação;
O Subversion utiliza números de revisão que são globais no repositório; isso faz com que mudanças em projetos distintos aumentem o número de revisão de projetos não relacionados.

O meio termo seria ter alguns repositórios criados, e cada um deles conter projetos relacionados. Desta forma, os projetos relacionados podem compartilhar dados facilmente, e caso novas revisões sejam criadas no repositório, elas estarão relacionadas a projetos que estão, de alguma forma, também relacionados.

Além da organização dos repositórios em si, há ainda a questão da organização dentro dos repositórios. Há várias maneiras de organizar o repositório de um projeto, pois cada divisão existente não é nada mais do que um diretório, e o Subversion não impede a criação de diretórios. Embora exista esta flexibilidade, o projeto Subversion recomenda, oficialmente, a idéia de um “projeto raiz“ que representa o ponto principal de um projeto. Um repositório pode conter um ou mais “projetos raiz“, e o “projeto raiz“ possui exatamente três subdiretórios:

/trunk –  o diretório onde o desenvolvimento principal do projeto ocorre, ou seja, onde sempre está a versão mais recente dos artefatos oficiais;
/branches – o diretório onde pode-se criar ramificações da linha principal de desenvolvimento (trunk);
/tags – o diretório onde se pode armazenar ramificações da linha principal que são criadas, e talvez destruídas, mas nunca modificadas.

Um repositório poderia se parecer com o seguinte:


calc/
----trunk/
----tags/
----branches/
calendar/
----trunk/
----tags/
----branches/
spreadsheet/
----trunk/
----tags/
----branches/

Se há múltiplos projetos em um mesmo repositório, é possível organizá-los em grupos dentro do repositório, colocando projetos com objetivos similares em subdiretórios, como a seguir:

</p>
utils/
----calc/
--------trunk/
--------tags/
--------branches/
----calendar/
--------trunk/
--------tags/
--------branches/
…
office/
----spreadsheet/
--------trunk/
--------tags/
--------branches/

Faça o commit de conjuntos lógicos de mudanças

É importante ficar bem claro que o objetivo principal de um sistema de controle de versão não é o de realizar backup dos dados versionados, mas manter o controle de versões lógicas de modificações feitas nos artefatos.

Sendo assim, realizar um commit apenas ao final do dia, com a idéia de que se está salvando o trabalho feito não é nada bom se este trabalho não estiver logicamente completo. Agindo assim só se está realizando um backup diário do trabalho.

Uma operação de commit deve ter um significado maior: ela deve refletir um trabalho completo para corrigir um erro, a incorporação completa de uma nova funcionalidade ao sistema, ou alguma tarefa particular, mas sempre por completo. Uma operação de commit irá gerar um identificador globalmente reconhecido dentro do repositório, que identifica este trabalho por completo, como se fosse um nome. Este identificador poderá ser utilizado, posteriormente, para identificar uma correção em uma ferramenta de acompanhamento de solicitações,  ou então ser passado como parâmetros a comandos do Subversion quando se deseja desfazer uma mudança, ou então copiá-la de um branch a outro.

Utilizar ferramentas de acompanhamento de solicitações de maneira adequada

Ao utilizar ferramentas de acompanhamento de solicitações (correção de bugs, novas funcionalidades, etc…) faça links cruzados entre o número da solicitação aberta e do commit, ou commits que a atendem.

Uma maneira de fazer isso é incluir o número da solicitação que se está atendendo no comentário do commit, e adicionando o número da revisão, resultante do commit, nos comentários que se faz em uma solicitação, para explicar seu andamento ou seu encerramento.

Acompanhar operações de merge manualmente

Ao realizar um commit depois de uma operação de merge, escreva uma mensagem descritiva explicando o que foi integrado, como por exemplo:

Realização da integração das versões 3490:4120 do /branches/algumbranch para /trunk.

Saber quando criar branches

O debate sobre quando criar branches, ou não, é um detabe antigo, e realmente não há uma palavra final sobre isso, pois cada equipe ou projeto pode assumir uma política diferente. A seguir são descritas as três políticas mais comuns de criação de branches:

Nunca criar branches

Eesta é a política utilizada por projetos que acabaram de nascer, e que ainda não têm código executável.
Os usuários realizam o commit das mudanças diárias diretamente no /trunk.

Eventualmente o /trunk pode parar de funcionar (não compila, não passa em testes unitários), quando alguém realiza o commit de mudanças complexas.

Prós:
* É uma política fácil de seguir.
* Novos desenvolvedores têm uma barreira menor para iniciar.
* Ninguém precisa saber como criar branches e realizar integrações (merge).
Contras:
* Desenvolvimento caótico.
* O código pode se tornar instável a qualquer momento.

Sempre utilizar branches

Esta é a política utilizada por projetos que favorecem um forte gerenciamento e supervisão.
Cada usuário cria e trabalha em um branch privado para cada tarefa de codificação.

Quando a codificação está completa, alguém (o autor original do código, um colega ou o gerente) revisa todas as modificações no branch as integra ao /trunk.

Prós:
* Há a garantia de que o /trunk sempre estará consistente e estável.
* Nenhum desenvolvedor precisa manter em sua máquina, por muito tempo, modificações incompatíveis com o /trunk.
Contras:
* Os desenvolvedores ficam artificialmente isolados uns dos outros, possivelmente criando mais conflitos de integração que o necessário. Requer que os desenvolvedores façam integrações com maior frequência, para diminuir os conflitos.

Criar branches quando necessário

Esta é a prática utilizada pelo projeto Subversion.

Os usuários realizam o commit das mudanças diárias diretamente no /trunk.

Regra #1: o /trunk tem que compilar e passar nos testes de regressão sempre!
Regra #2: uma operação de commit de um conjunto de modificações não pode ser tão grande a ponto de desencorajar a revisão por parte de um colega.
Regra #3: se as regras #1 e #2 entrarem em conflito (exemplo: é impossível realizar uma série de commits sem corromper o /trunk) então o desenvolvedor deve criar um /branch e realizar uma série de commits de pequenos conjuntos de modificações lá. Isso permite que seja feita a revisão por parte de um colega, sem desestabilizar o /trunk.

Pros:
* Tem-se a garantia de que o /trunk está estável todo o tempo.
Contras:
* Adiciona algumas obrigações ao trabalho diário dos usuários: eles devem compilar e testar o código antes de cada commit realizado.

Tenha cuidado ao realizar a atualização de sua área de trabalho

Alguns cuidados, apesar de muito básicos, são ignorados por quem está começando a utilizar um sistema de controle de versão. Vejo constantemente amigos reclamando de estagiários que fazem uma verdadeira bagunça no código versionado, sobrescrevendo atualizações de colegas, criando com isso muitos problemas.

Ao invés de realizar um commit direto em algum artefato, é adequado verificar se há atualizações pendentes para o mesmo. Plugins dificilmente permitem que se realize um commit em um código que possui uma versão mais nova no servidor, mas ainda assim é uma boa prática.

Quando não há conflitos nos arquivos é difícil fazer alguma besteira. Os problemas surgem com eles.

Os plugins das IDEs permitem que se faça a verificação dos conflitos, e a solução deles, passo-a-passo. Ainda assim muitas pessoas (acreditem) ignoram os conflitos e simplesmente forçam um commit de suas atualizações, “matando” as modificações de seus colegas. Acredite, se você não quer ter sua mãe escumungada pelos seus colegas, seja cauteloso. Ao solucionar conflitos, tenha paciência e copie para sua versão as atualizações pertinentes feitas pelos seus colegas. Quando o trecho em conflito refletir uma mesma mudança feita por você e outra pessoa, verifique com a pessoa o que ela acha melhor manter na versão, principalmente se você não conseguir entender a codificação dela.

Só faça o commit quando você tiver certeza de que as mudanças feitas pelos outros colegas de trabalho foram contempladas em sua versão. Se você não conseguir resolver os conflitos, chame uma pessoa mais experiente.

Quando você não tiver uma pessoa disponível para lhe ajudar a resolver os conflitos, é preferível copiar seu código para um arquivo de backup, aceitar todas as atualizações do servidor (sobrescrevendo as suas) e depois realizar novamente as suas alterações sobre a nova versão. Isso porque você certamente entenderá melhor as suas modificações do que a de seus colegas. Esta é uma prática que eu uso às vezes (quando há conflitos demais), e vários colegas me dizem também usar a mesma prática. Pelo menos se garante que nenhum trabalho alheio será estragado.

Quando tiver novas dicas para este post eu o atualizarei.

Está dada a dica!

Referências

http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html

http://svnbook.red-bean.com/

http://www.iovene.com/21

Dicas de Boas Práticas de Codificação

Este post não traz nenhuma novidade para quem já desenvolve há algum tempo, e a intenção é atingir aqueles que estão começando a programar em Java.

Resolvi juntar algumas dicas de padrões de codificação e melhores práticas para códigos a serem aplicados no desenvolvimento de aplicações Java.

São abordados padrões de nomes de arquivos, organização de código, endentação, comentários, declarações, sentenças, espaços em branco, convenção de nomes, práticas de programação e exemplos de código.

Estes padrões são baseados em princípios de engenharia de software que produzem códigos fáceis de entender, fáceis de manter e escaláveis. As convenções aqui adotadas foram fortemente baseadas no documento de Convenção de Codificação para a Linguagem de Programação Java, da Sun Microsystems.

Algumas constatações reforçam a necessidade de se adotar uma padronização durante do desenvolvimento:

  • 80% dos custos de um software é referente à manutenção.
  • Dificilmente qualquer software é mantido durante toda sua vida útil pelo autor original.
  • Convenções de código aumentam a legibilidade do software, permitindo que os desenvolvedores entendam novos códigos mais rapidamente e completamente.

No desenvolvimento de sistemas o uso de padrões de codificação promove o aumento da consistência do código e da produtividade da equipe. A seguir são descritas as principais instruções para a codificação de um código Java com padronizado e com qualidade.

Convenção de Nomes

Mantenha o tamanho dos nomes grande o bastante para transmitir o que eles representam. Exemplo: primeiroNome, sobrenome, ordemServico, etc.

Nomes de Classes e Interfaces

Os nomes de classe devem ser substantivos e, em caso de nomes compostos, utilize nomes com a primeira letra de cada palavra interna maiúscula. Use palavras inteiras evitando acrônimos e abreviaturas. Exemplo: Cliente ou ContaCliente.

Nomes de Métodos

Os nomes dos métodos devem ser verbos, em casos compostos com o primeiro nome minúsculo, e com a primeira letra de cada palavra interna em maiúsculo. Exemplo:

calcularPagamento().

Nomes de Variáveis

Os nomes de variáveis devem estar com uma primeira letra minúscula e, em caso de nomes compostos, com a primeira letra de cada palavra interna em maiúsculo. Exemplo: contraPeso, primeiroNome, etc.

Use abreviações consistentemente. Exemplo: numPedido, numChamado. Neste caso, num representa Numero.
Evite os nomes que são similares. Exemplo: o numCliente e numcliente.

Use nomes no plural para representar coleções tais como uma disposição ou um vetor. Exemplo: CustomerPK[] clientes ou Vector politicasDeAcesso.

Nomes de Constantes

Os nomes de constantes para tipos de dados ordinais devem ter todas as letras em maiúsculo, separadas por underscore. Exemplo:

public static final int MAX_POLICY_AMOUNT; ou
public static final char PROCESS_INFO_COMMAND;

Documente com Comentários

Adicione comentários para facilitar a compreensão do código. Mantenha o comentário simples e separe-os de tal forma o código fique limpo e legível. Escreva também os comentários onde alguma explanação é necessária. Não escreva comentários para as coisas óbvias. Forneça documentação de acordo com a especificação do javadoc, tal que os arquivos do Java código podem ser usados para produzir a documentação externa das classes.

Documentação de Classes

Para documentar classes forneça comentários imediatamente antes de sua definição, especificando a finalidade e histórico de desenvolvimento.

Documentação de Interfaces

Para documentar interfaces especifique a finalidade nos comentários da documentação, imediatamente antes de sua definição. Para cada método siga os padrões da documentação de métodos de membro.

Documentação de Pacotes

Forneça documentação que especifique o relacionamento de um pacote com suas classes e Interfaces.

Use Linhas em Branco

Forneça linhas em branco entre as seções do código para melhorar a legibilidade. Use uma linha em branco nas seguintes circunstâncias:

  • Para separar as definições de classes das definições de métodos;
  • Para separar as variáveis locais de um método;
  • Para separar blocos de código; e
  • Para separar comentários das seções lógicas do código.

Espaços em Branco e Tabulação

Use o espaço em branco para melhorar a legibilidade do código nas seguintes circunstâncias: Entre uma palavra-chave e um parêntese. Exemplo:

while (condicao) {
}

Após vírgulas na lista entre parênteses. Exemplo:


operacao(param1, param2, param3);

Entre um operador binário e seu operando. Exemplos:


x += y + z;
a = (a + b) / (c * d);

Entre expressões em uma declaração “for”. Exemplo:


for (expr1; expr2; expr3)

Na utilização de casts.


umMetodo((byte) num, (Object) x);

Variáveis Locais

Declare uma variável local por linha do código e adicione um comentário que identifique a variável. Exemplo:

int contador = 0; // contador para número de referências

Declare todas as variáveis locais no começo dos blocos. Isto facilitará a localização das definições variáveis pelo programador. Exemplo:


private void calcularProcessosPendentes() {
boolean processoEncerrado = false; // indica término do processamento
}

Use cada variável local para uma finalidade específica.
Inicialize todas as variáveis locais onde elas são declaradas. A única razão para não inicializar uma variável no local onde ela é declarada é quando o valor inicial da variável depende de um processamento que ocorrerá posteriormente.


int contador = 0; // contador para número de referências
int maxReferencias; // o número máximo de referências a serem processadas
…
maxReferencias = getMaxRefencias(…, …);

Evite as declarações locais que sobreponham declarações em níveis superiores. Exemplo:


int contador = 0; //…
…
metodo() {
    if (condicao) {
        int contador = 0;
        …
    }
    …
}

Atributos de Membro

Para declarar atributos de membro utilize os seguintes padrões:

Finalidade: Documente a finalidade do atributo;
Visibilidade: Mantenha a visibilidade tão baixo quanto possível;
Iniciação: Certifique-se de que todos os atributos estão inicializados antes que sejam alcançados. Inicialize todos os atributos no momento da criação do objeto. A inicialização posterior pode ser usada para os campos que não são acessados regularmente.

Métodos de Membro

Para declarar métodos de membro utilize os seguintes padrões:

Nomenclatura: use get/set como um prefixo do nome do campo para todos os métodos de ascensão, a menos que forem do tipo booleano. Use o prefixo “is” para nomes de métodos que referenciem campos booleanos. Utilize também a primeira palavra do nome do método de membro como um verbo forte, ativo. Exemplo:


getPotenciaMotor(), setPotenciaMotor(), isAutomatico(), reduzirMarcha().

Visibilidade: Mantenha a visibilidade de funções de membro tão restritiva quanto possível para minimizar o acoplamento entre as classes;
Documentação: Inclua um cabeçalho para especificar as seguintes informações da função de membro:

  • O propósito da função;
  • Seu valor de retorno;
  • Os parâmetros;
  • As mudanças nas versões do código.

Parâmetros

Evite nomear parâmetros com o mesmo nome que as variáveis de membro. Isto evitará referenciar cada variável de membro utilizando o operador “this”, dificultando a localização de erros. Documente os parâmetros de uma função de membro no header usando a tag @param do javadoc. A documentação deve ser obrigatória para descrever todas as limitações ou pré-condições.

Declarações ou Comandos

Cada linha deve conter no máximo um comando. Exemplo:

contador++; x = y; // EVITE ISSO!

Chaves ou Blocos

Siga um esquema consistente para a abertura e fechamento de chaves. Alinhe a abertura e fechamento das chaves verticalmente. Isto facilitará a identificação do começo e término dos blocos. Exemplo:

class Cliente
{
    public void operacaoParaCliente()
    {
        if(condicao)
        {
        }
    }
}

Alternativamente, ponha a chave da abertura na extremidade da linha que começa o bloco. A chave de fechamento deve começar uma nova linha e ser posicionada no começo do comando de bloco. Exemplo:


class Cliente {
    public void operacaoParaCliente() {
        if(condicao) {
        }
    }
}

Ordem dos Membros

Declare membros de acordo com a ordem de visibilidade, do mais visível para menos visível, conforme modelo abaixo:

construtores (constructors)
public member functions
protected member functions
private member functions

Minimize a utilização do modificador de acessos public e protected. Isto reduz o acoplamento e deixa o código mais compreensível. Evite usar nomes de objetos para acessar membros estáticos (static members), em vez disto, use o nome da classe preferivelmente.

Concatenação de Strings

Evite realizar a concatenação de Strings com o operador “+“. Strings são objetos imutáveis, e por esta razão, a cada vez que uma concatenação é realizada, novos objetos são criados na memória:

String a = “Evite“;
a = a + “realizar a concatenação“;
a = a + “de Strings assim!“;

Para concatenação, procure utilizar as classes StringBuilder ou StringBuffer:


StringBuilder a = new StringBuilder(“Procure“);
a.append(“realizar a concatenação“);
a.append(“de Strings assim!“);

Cuidados na Manipulação de Objetos que Podem Estar Nulos

Ao realizar a chamada de métodos em objetos que poderiam estar nulos, tenha sempre o cuidado de testá-lo antes, a menos que tenha a certeza de que o objeto não estará nulo.
Um exemplo útil, no caso de comparação de Strings:

Ao invés de realizar a comparação desta maneira:


if(umaString.equals(““)){
…

Faça o seguinte, chamando o método equals no valor literal:


if(““.equals(umaString)){
...

Remover Imports Desnecessários

É importante, por uma questão de economia de memória, manter nas classes e interfaces somente as definições de imports que são utilizadas.
Uma outra prática importante, que já é reforçada pelas IDE’s, é fazer o import classe a classe, ao invés de importar todos as classes de um determinado pacote.

Utilize Parênteses Sempre que Puder

Não economize na utilização de parênteses quando estes puderem deixar uma expressão mais clara.

Atribuição de Variáveis

Evite fazer múltiplas atribuições a uma mesma variável em uma única linha:

fooBar.fChar = barFoo.lchar = 'c'; // EVITE ISSO!

Referência a Atributos e Métodos Estáticos

Sempre referencie membros estáticos (atributos e métodos) através da classe, e não de uma instância da mesma:


UmaClasse.metodoEstatico(); // OK
instanciaDeUmaClasse.metodoEstatico(); // EVITE ISSO!

Utilize Chaves Sempre!

Sempre utilize chaves para delimitar blocos de comandos, mesmo que estes tenham apenas uma instrução:

if(determinadaCondicao) // EVITE ISSO!
    realizaOperacao();

if(determinadaCondicao){ // OK
    realizaOperacao();
}

Bom, definitivamente não há nada de novo aqui para quem já desenvolve há algum tempo, com uma ou outra adaptação.

O importante é definir quais práticas se adequam à sua realidade/equipe/projeto e seguí-la.

Está dada a dica!

Referência

http://www.oracle.com/technetwork/java/codeconv-138413.html

Metrics for Eclipse

Revisando edições antigas da Java Magazine encontrei, na edição 55, um artigo muito interessante sobre o plugin Metrics for Eclipse, escrito por Leonardo da Silva Mota, Thamine Chaves L. de Abreu e Marco Antônio Pereira Araújo.

Esta edição da revista é voltada à qualidade, e vale muito a pena a leitura.

Na página do projeto é possível encontrar maiores detalhes, e o plugin pode ser instalado no Eclipse através do update site http://metrics.sourceforge.net/update. Instalei tranquilamente o plugin no Eclipse Galileo (32bit e 64bit).

Como usar?

Para utilizá-lo é preciso estar na perspectiva  “Java” do Eclipse. Vá até as propriedades do projeto e, selecionando no menu esquerdo a opção Metrics, habilite as métricas para o projeto:

Depois de habilitar as métricas, dê um build no projeto.

Vá ao menu Window > Show View e selecione a opção Metrics. Dentro desta opção existem quatro opções de visualização. Selecione a opção Metrics View.

É possível visualizar várias métricas calculadas pelo plugin:

A métrica McCabe Cyclomatic Complexity, por exemplo, é uma métrica de software que proporciona uma medida quantitativa da complexidade de um algoritmo.

Gráfico de Dependência

É possível ainda visualizar um gráfico de dependência entre classes e pacotes:

Personalização

É possível ainda personalizar esta ferramenta, através do menu Window > Preferences > Metrics Preferences.

Dentre as personalizações possíveis, podemos ajustar os intervalos de valores para cada métrica, e habilitar a emissão de avisos, caso estes valores atinjam níveis indesejados.

Para maiores detalhes, recomendo a leitura do artigo.

Está dada a dica!

Referências

http://sourceforge.net/projects/metrics/

http://en.wikipedia.org/wiki/Cyclomatic_complexity

http://eclipse-metrics.sourceforge.net/descriptions/CyclomaticComplexity.html

http://developer.spikesource.com/wiki/index.php/Measuring_Code_Complexity_Metrics

Aumentando o limite de conexões no IIS (Win XP Pro)

Esta é uma dica rápida para quem precisa utilizar, por qualquer que seja o motivo, o IIS do Win XP Pro.

O post no qual encontrei esta dica foi este: http://weblogs.asp.net/cazzu/archive/2003/10/10/31476.aspx.

Há uma limitação da quantidade de conexões ao servidor, de no máximo 10, por padrão.

Há uma maneira de aumentar esta quantidade, mas para no máximo 40.

Para isso, vá até o diretório c:\inetpub\AdminScripts. Lá deve haver um script chamado adsutil.vbs.  Através da linha de comando vá até este diretório e execute o comando:

adsutil set w3svc/MaxConnections 40

E está feito!