Organizando minha pesquisa (parte 1)

Concluí meu mestrado há cinco anos; de lá para cá, continuei lendo e pesquisando jogos. Agora, fui aprovado no doutorado em design na UFPR, e já tenho uma boa quantidade de material para a minha pesquisa – anotações, referências, imagens…

Certamente este material vai aumentar muito durante os próximos anos. Por isso, decidi criar um sistema de organização de informações. Isso ajuda a evitar duplicação de esforços, a não perder ou esquecer informações, e permite ir criando os documentos (artigos, qualificação) aos poucos.

Pensando que isso pode ser útil para outros, resolvi aproveitar a reativação do meu blog para oferecer um sumário do sistema.

Definindo o objetivo e os requisitos do sistema

Como indiquei acima, quero manter organizadas as informações referentes à minha pesquisa, tanto as já existentes quanto as que vão aparecer. Assim, a organização precisa ser flexível.

Por outro lado, como minha experiência anterior mostrou, é necessário ter uma “memória” de tudo o que já esteve presente no sistema – versões anteriores de textos, capacidade de recuperar arquivos apagados, etc.

Mais um requisito: preciso ser capaz de acessar o material onde quer que eu esteja. Por um lado, isso me permite trabalhar sem a necessidade de carregar meu computador comigo; por outro, permite que o acesso ao meu material (no todo ou em parte) possa ser liberado para outras pessoas – por exemplo, meu orientador.

Claro, não existe uma maneira única de atender a estes requisitos e objetivo. Vejamos algumas alternativas mais simples, e porque não as adotei.

Alternativas mais simples

Permitir o acesso remoto tornou-se quase corriqueiro com ferramentas de software na nuvem. Depósitos de arquivos (Google Drive, Dropbox, etc.) funcionam como discos virtuais. Sistemas online de documentos (Google Docs, Office 365, Overleaf, etc.) permitem a criação e edição de documentos na nuvem.

Com estas soluções, é possível manter as informações organizadas (por pastas ou diretórios, como em um disco físico em um computador), e o acesso remoto a elas é quase que trivial.

No entanto, estas ferramentas não implementam o meu requisito de manterem a memória de momentos anteriores dos documentos. Se apago um arquivo em um destes ambientes, o arquivo pode talvez ser recuperado – mas, de forma geral, apenas na versão mais recente.

Alguns destes ambientes oferecem a possibilidade de recuperar versões anteriores dos documentos, mas de forma individual: não há uma ligação lógica entre as versões de diferentes documentos.

E esta última observação nos traz ao principal problema com estas ferramentas: assim como em um diretório em um disco físico em meu computador, o controle de versões é feito de forma inteiramente manual. Qualquer um que tenha trabalhado na criação de um documento de porte médio ou maior conhece a situação: facilmente chegamos a ter uma enfiada de arquivos com nomes como “Versão de trabalho”, “versão 3.2”, “texto final”, “texto final corrigido”, “texto final revisado”, etc. Ainda que se consiga atender – com dificuldade – ao requisito de memória de versões, isso dificulta consideravelmente a organização da informação, que é o objetivo deste exercício.

Felizmente, também existem ferramentas para este tipo de situação. A que eu passei a user, e que detalho mais adiante, chama-se git.

git

O git é um software dedicado ao controle de versões de documentos. Ele foi desenvolvido inicialmente por Linus Torvalds, criador do Linux; a maior parte dos usuários do git é formada por programadores, que mantêm seus projetos de programação em repositórios git.

O sistema git é composto de duas partes principais. Uma delas é um servidor git, que armazena os repositórios com os projetos de um ou mais usuários. A outra é um conjunto de programas, que pode ser instalado em um computador pessoal; ele serve para fazer cópias locais de um projeto, para consulta ou modificação, e permite também enviar as modificações para o repositório do projeto.

O servidor git controla automaticamente as versões de todos os arquivos que compõem o projeto. Por exemplo, se eu tenho um arquivo chamado “Trabalho da disciplina”, eu posso adotar o seguinte fluxo de trabalho:

copio o repositório do projeto (operação clone);

faço as alterações que eu quiser no arquivo;

envio as alterações de volta para o repositório (operação commit).

Até aí, nada de diferente de um GoogleDrive. A primeira diferença: se eu precisar, posso voltar facilmente a qualquer das versões anteriores do arquivo, não importa quantas alterações eu tenha feito.

Segunda diferença, bem mais importante. Digamos que eu estou trabalhando com diversos arquivos – por exemplo, uma planilha de dados, dois gráficos criados a partir da planilha, e o documento principal. Quando eu fizer um envio de novas versões para o repositório – um commit –, estas versões ficam associadas entre si. Se, mais adiante, eu precisar retornar a um commit anterior, eu posso pegar a versão anterior de apenas um dos arquivos, ou de todos os arquivos que fizeram parte daquele commit.

Para isso, eu não preciso – nem devo! – ficar mudando os nomes dos arquivos. O servidor cuida de fazer isso. O que eu preciso fazer é, a cada commit, incluir uma mensagem explicando o que aquele commit significa. Por exemplo, “inclusão dos dados da sessão de 2 de março”. Isso cria um significado lógico para aquelas versões armazenadas no servidor, e facilita muito a sua recuperação posterior.

É importante notar que este esquema é um esboço muito sumário das capacidades e comandos do git; felizmente, há muita documentação disponível sobre o git – páginas, tutoriais, vídeos, livros. Ao final deste texto, incluo links para alguns livros úteis sobre o seu uso.

Na segunda parte deste texto, vou detalhar alguns dos usos que eu adotei para o meu projeto de pesquisa.

Qual servidor?

O git cumpre o meu objetivo principal, e atende aos requisitos adicionais que eu formulei. Assim, decidi adotá-lo como principal ferramenta de organização da minha pesquisa.

Próxima decisão: qual servidor?

Os dois principais servidores git públicos são o GitHub e o GitLab. Ambos oferecem planos gratuitos e pagos para seu uso, da mesma forma que as ferramentas mencionadas acima.

Qualquer destes servidores atende perfeitamente às necessidades de um pesquisador, e ambos têm funcionalidades muito parecidas entre si. Para minha pesquisa, decidi adotar o GitLab.

Assim, se você quer experimentar as ideias que eu proponho aqui, crie uma conta em um destes servidores, e crie um projeto para suas experiências. Na segunda parte, você verá algumas ideias adicionais.