devlog

Link: https://www.drproject.org/

Apesar da recente popularização de sistemas de controles de versão distribuídos como o git ou o mercurial, o svn ainda é a ferramenta mais popular para controle de versões. E junto com ele, quase sempre está o trac, que adiciona ao repositório um wiki, tickets e outras ferramentas para gerenciar o desenvolvimento.

Porém, a maior questão dos usuários com o trac é ter de subir uma instalação do trac para cada repositório. Não é uma tarefa muito difícil, mas convenhamos, podia ser mais fácil.

Pensando nisso, a Universidade de Toronto fez um fork do trac, adicionando a capacidade de múltiplos projetos. Entre as facilidades oferecidas, podemos citar, por exemplo, que criar um projeto no DrProject já cria o respectivo repositório.

Comparação

O DrProject era originalmente um fork do portal open source leve chamado Trac. Essa é a comparação dos dois hoje:

Segundo Jeff Balogh, o trunk dele é estável, com o desenvolvimento feito nos branches.

O projeto foi originalmente desenvolvido para uso no ensino. Numa troca de e-mail rápida com os desenvolvedores, perguntei no que isso se fazia presente no projeto. David Wolever me disse que o sistema de permissões é um reflexo disso, já que num projeto open source o acesso ao código não precisa ser restrito. Greg Wilson me falou a respeito das listas de e-mail integradas, e das operações em lote, como criar vários projetos com nomes sequenciais - que são úteis dentro de um ambiente de ensino.

A instalação do projeto foi parecida com a do trac, com a exceção que o DrProject espera que os repositórios estejam dentro dele, já que ele os administra. Numa tentativa de atualização, o meu banco de dados (sqlite) teve algum problema, mas logo depois o problema desapareceu. Sinais de que o projeto ainda tem muito o que andar, mas é uma boa pedida pra adicionar na lista de coisas a testar.

Se tem uma coisa que me irrita, é quando as pessoas dão nomes as coisas de uma forma não condizente.

Por exemplo, trabalhando com o Plone e categorização de objetos. Você já imagina que para procurar objetos por categorias você irá esbarrar em categories, category, até um possível tag. Mas dentro do Plone, você busca por Subject.

Mas em um outro caso, é o Plone que me salva. Se você vai adicionar uma informação geográfica a um objeto, você logo pensa em location. Ao menos é o que a tela de edição do Plone mostra. E é o que o Dublin Core chama de coverage.

Vocês podem achar que eu estou sendo excessivamente chato com isso, mas lembre-se que você sempre terá de gastar alguns segundos para associar a palavra ao seu significado específico dentro daquele contexto onde ela tem um significado alienígena

Link: http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html

É o nome do mais novo projeto do google disponibilizado para a comunidade do código livre.

Segundo a descrição no anúncio do projeto, ele nasceu da necessidade de serializar dados e trocar esses dados serializados pela rede de forma eficiente. Já nasceu com versões para Java, C++, ou Python.

Você define uma descrição de um objeto, um arquivo .proto, e o compilador gera o código necessário para acesso na linguagem que você escolher, dentre as três suportadas.

Segundo a documentação: "Protocol buffers are now Google's lingua franca for data – at time of writing, there are 48,162 different message types defined in the Google code tree across 12,183 .proto files. They're used both in RPC systems and for persistent storage of data in a variety of storage systems."