Instalando o Ruby, no Windows, sem o One-click Installer

Estava procurando reproduzir o ambiente Ruby, que eu tenho no Ubuntu, em uma estação Windows. Só que o instalador disponibilizado, é recheado de plugins. Por isso resolvi tentar a versão zipada.

Para minha surpresa, a instalação do pacote zipado é bem tranqüila e, quase, dispensa o One-Click Installer.

Abaixo, a lista de passos que eu segui para ter o ambiente funcionando redondo:

1. Baixe o Ruby 1.8.6 Binary;
2. Descompacte o arquivo em uma pasta: C:\ruby, por exemplo;
3. Adicione a pasta C:\ruby\bin na sua variável de ambiente Path.

Instalando o RubyGems:

1. Baixe o Rubygems;
2. Descompacte o arquivo e execute o setup que existe na pasta bin.

Perfeito agora você tem um ambiente sem um mundo de plugins que o One-click Installer coloca no ambiente Windows.

UPDATE:

Para instalar gems basta usar o comando:

 gem install nome_do _gem.

Caso você esteja tentando instalar um gem atrás de um proxy com autenticação, defina a variável de ambiente HTTP_PROXY com a url para o proxy da sua rede:

set HTTP_PROXY=http://nome_de_usuario:senha_do_proxy@url_ou_ip_do_proxy:porta_do_proxy

Avaliando o Bazaar

Como já explicado, o Bazaar é um sistema de controle de versão distribuído, que eu estou usando em um projeto no trabalho. Neste texto irei listar os motivos para usá-lo e uma breve comparação com os seus concorrentes mais interessante: Mercurial e Git.

Por que usar o Bazaar?

• Possui suporte a renomear e mover arquivos e pastas;
• Possui suporte a migração de repositórios Subversion;
• É multi-plataforma, incluindo Windows e Linux. Na verdade qualquer coisa que rode Python;
• É suportado por uma empresa, Canonical, que mantém programadores dedicados ao projeto;
• Possui suporte comercial, opcional;
• É usado em projetos grandes;
• É livre e gratuito;

Problemas que me incomodam

• É, visivelmente, mais lento do que os concorrentes: Mercurial e Git;
• Falta um cliente que não seja em linha de comando que esteja no mesmo nivel do TortoiseCVS ou SmartCVS. O TortoiseBzr está sendo distribuído com a versão 1.6. Eu concordo que não doí usar a interface por linha de comando, mas tem desenvolvedor que esta acostumado com o Windows. E nada o convence de que há casos em que linha de comando é mais produtivo;
• O plugin do Bazaar para o Eclipse ainda deixa a desejar, se comparado, por exemplo, ao Subversive para o Subversion;
• O TortoiseBzr ainda está no começo, mas parece promissor.

As funcionalidade que sinto falta no plugin para o Eclipse são:

• Diff visual para o arquivo modificado;
• Selecionar a versão o arquivo, para a qual eu desejo reverter as alterações;
• View com os arquivos alterados, de forma que eu possa selecionar o que vai ser “commitado”.
• Assistente visual para merge.

Fontes de consulta

• Texto sobre as principais características dos sistemas de controle de versão distribuidos
• Avaliação do Bazaar, feita pela equipe do OpenSolaris;
  
• JavaWorld sobre qual VCS escolher
  
• Importancia da distribuição nos VCSs. Neste blog também tem outros textos interessantes sobre o assunto.

Concorrentes

Git

Criado por Linus Torvalds para substituir o BitKeeper, usando as lições aprendidas com o uso diário deste. O Git é usado para suportar o processo de desenvolvimento do kernel Linux.

Suas principais características são:

• Suporta os requisitos de Linus Torvalds, para o Linux.
• É, absurdamente, rápido;
• Possui desenvolvedores de altíssimo nível;
• É muito rápido, mesmo;
• Suporta renomear e mover arquivos e pastas;
• Tem uma ferramenta de merge muito boa. Ele inclusive consegue, sob certas circunstâncias, acompanhar que um método saiu de um arquivo para outro.
• Já falei que ele é rápido?

Infelizmente nem tudo são flores…

• Ele não tem um suporte decente para Windows. Mesmo assim tem um projeto no Google Code, Git on MSys, que parece interessante se for levado adiante.

Mercurial – Hg

O pessoal da Mozilla e do OpenSolaris gostou dele.

É muito rápido, se comparado com o Bazaar.

Ele tem recebido boas criticas. Inclusive, o pessoal da Mozilla o comparou com o Bazaar, mas com uma versão beeem antiga:

• Avaliação do Mercurial, feita pela equipe do OpenSolaris;
• Comparação entre VCSs feita pela equipe Mozilla;
• Bazaar needs to step it up, Look at Mercurial.

Além disso, já possui uma boa ferramenta: TortoiseHg.

Ainda assim, sinto falta de “alguém de peso” suportando o desenvolvimento. Quando eu digo suportando, eu me refiro a forma que a Canonical está fazendo com o Bazaar.

Na verdade, esta falta, é apenas porque acredito que o Hg poderá ser superado pelo Bazaar, da mesma forma que o Ubuntu vem fazendo com as distribuições mais antigas.

Críticas, dúvidas e sugestões serão muito bem vindas. Para isso é só comentar aqui embaixo…

Tutorial do Bazaar

Dando continuidade ao texto de apresentação do Bazaar, segue agora o guia de consulta rápida para o Bazaar.

O Bazaar funciona mais ou menos como o nome dele sugere:

Ao entrar no estabelecimento, apresente-se ao funcionário

Antes de executar a primeira operação, tenha certeza que o bzr sabe quem você é:

 bzr whoami "AC de Souza <seu_email@seudominio.com>"

Pegar o cesto de compras, ou como criar o repositório?

Agora que já nos apresentamos, é interessante você criar um repositório bzr no seu projeto. Para iniciar um repositório bzr no diretório corrente:

 bzr init .

Onde o “.” identifica que é o diretório corrente.

Aqui é o momento em que você deve criar o esqueleto do projeto que será posto no Bazaar.

Os dados do seu repositório ficaram em uma pasta, .bzr, na raiz do seu projeto. Acho isso melhor do que um mundo pastas “.svn” expalhadas pelo projeto.

Coloque no cesto, apenas, o que você vai querer… Ou, como ignorar artefatos?

Nem tudo deve ser incluído no repositório; como as classes compiladas, por exemplo. Para isso serve a opção ignore.
Nas configurações dos meus projetos, as classes compiladas vão para a pasta target para não incluí-lo no bzr faremos:

bzr ignore target

Além de pastas e arquivos, a opção ignore, pode ser usada para grupos de arquivos, ou pasta. Vou aproveitar e excluir a pasta logs e os arquivos de build gerados pelo Eclipse:

bzr ignore *-build.xml logs

Enchendo o cesto com os artigos de sua necessidade…

Uma vez que o projeto já tenha alguma coisa para ser controlado, use o comando abaixo para adicionar os artefatos criados no repositório:

 bzr add

Passando no caixa… Ou, como confirmar as modificações

Para commitar as alterações no projeto use:

 bzr commit -m "Mensagem de commit"

Arrumando as compras na despensa de casa… Como publicar o repositório?

O repositório centralizado tem uma funcionalidade muito boa, que é saber onde encontrar os fontes mais atuais. Este problema é resolvido com os sistemas distribuídos usando o conceito de publicação. Consiste, basicamente, em exportar os dados do seu repositório em um local “público” como um servidor FTP, SFTP, NFS ou uma pasta compartilhada do Windows(opção desaconselhada pelos desenvolvedores do Bazaar). Mas se você está usando o Windows, é a forma mais rápida de testar esta funcionalidade.

Quem vai te ajudar aqui é o push. Ele é o responsável pela publicação do repositório:

 bzr push --create-prefix --use-existing-dir file://NomeDoComputadorNaRedeWindows/nome_da_pasta_compartilhada

Claro que se você usa Linux(Ok! Se você está procurando sobre um sistema de controle de versão distribuido, também ja entendeu), já entendeu que o “file:” está fazendo ali. É o protocolo usado para acessar o local de publicação.

Pegando os biscoitos na despensa, a.k.a., baixar o projeto de um repositório

Para acessar um projeto publicado por outra pessoa, você cria um branch do repositório:

 bzr branch file://NomeDoComputadorNaRedeWindows/nome_da_pasta_compartilhada

Repondo a baixa do pacote de biscoitos… Ou, como sincronizar suas alterações com o que já foi publicado?

A comparação, aqui, não ficou muito legal uma vez que quando se baixa um repositório ele não é apagado, como no caso do pacote de biscoitos.

Para atualizar o repositório público com as suas alterações:

 bzr pull

Com isso, dá para entender como usar as funções mais comuns do dia-a-dia de um usuário. Mais informações sobre o Bazaar, podem ser encontradas nos tutoriais e manuais presentes na página do projeto.

Na área de comentários as dúvidas, críticas ou sugestões são sempre bem-vindas… ;-)

Software de controle de versão sem um servidor

Você está procurando um software de controle de versão, ou de código-fonte, que não precise de um servidor? Um software de controle de versão que rode no Windows, Linux ou MacOS?

Provavelmente você está procurando um sistema de controle de versão distribuído. Atualmente eu estou usando um chamado Bazaar.

Desde que o Linus Torvalds deixou de usar o BitKeeper e criou o Git, que os sistemas de controle de versão começaram a adotar a característica de descentralizar a localização do repositório.

É claro que já existiam outros antes disso, o próprio BitKeeper, mas dá uma olhada na adoção destas ferramentas por empresas, no Brasil, e projetos open-source. O_o

O fato de descentralizar o repositório muda a forma como você trabalha com Gerência de Código-Fonte, SCM em inglês:

• O desempenho é maior, uma vez que todas as operações são realizadas localmente. Sem depender da rede;
• O backup do repositório é feito naturalmente, uma vez que cada desenvolvedor representa um backup remoto dos fontes;
• Não depende de configuração, ou mesmo existência de um servidor. Sabe a arquitetura P2P? Pois é, essa é a idéia;
• Não precisa dar permissão, para realizar o commit, a nenhum dos desenvolvedores do projeto. Basta que uma pessoa ou grupo tenha essa permissão. E, mesmo assim os colaboradores poderão controlar as alteração que ele vem fazendo;
• Dada a característica de que tudo é um branch, os sistemas de controle de versão distribuídos possuem um suporte a merges, muito superior aos seus concorrentes centralizados;
• Quem resolve os conflitos gerados por mudanças no código é a pessoa que fez as mudanças e não você, quem está baixando as atualizações.
• Você pode dar mais commits, sem quebrar o código de outro desenvolvedor, e se beneficiar mais da funcionalidade de revert.

Isso são características destas ferramentas, mas não necessariamente vantagens, ou desvantagens, apenas características.

Por exemplo, ter vários backups remotos dificulta saber qual o mais recente. Esse controle passa a ser feito pelo processo adotado pela equipe. Mas por outro lado, dificulta termos backups corrompidos, afinal de contas eles estão sendo usados.

O paper de Ian Clatworthy, desenvolvedor do Bazaar, sobre sistemas de controle de versão distribuídos procura demonstrar as vantagens de se adotar este modelo e dá sugestões sobre como escolher uma ferramenta, dentre as opções existentes. Há também, uma explicação sobre DVCS no site BetterExplained, versão ilustrada.

Eu estou testando, em um projeto no trabalho, o Bazaar-VCS. Ferramenta apoiada pela Canonical – já ouviu falar na empresa sim. É a mesma que mantem o Ubuntu Linux e o emprego do Ian, o cara do paper ali de cima.

Também darei uma olhada no Mercurial que vejo como principal concorrente dele. Uma vez que suas características são semelhantes.
Minha escolha, para teste do Bazaar, foi feita pensando em seu suporte a renomear e mover arquivos e pastas.

Críticas, dúvidas e sugestões serão muito bem vindas. Para isso é só comentar aqui embaixo…

Eclipse RCP e Visual Editor

Estou avaliando a utilização do Eclipse RCP no trabalho. Em outro momento eu explico mais sobre isso.

Esse post é para me lembrar de que para usar as funcionalidades do Visual Editor, na criação de um EditorPart, é necessário colocar, como dependência do projeto, os plugins:

• org.eclipse.ui.form;
• com.ibm.icu.

Sem o com.ibm.icu o VE não consegue renderizar o form quando você preenche o atributo text – o título do form.

Decobri isso ao mandar o Eclipse executar a Visual Class. Ele dava o seguinte erro:

 Exception in thread “main” java.lang.NoClassDefFoundError: com/ibm/icu/text/BreakIterator

Uma olhada mais atenta ao pacote, e uma pesquisa nos plugins disponíveis na tela de adição de dependências, me fez incluir o plugin com.ibm.icu, o que resolveu o problema.