R e controle de versão para o analista de dados solo

Muitos analistas de dados que eu respeito usam controle de versão. Por exemplo:

• http://github.com/hadley/
• Veja comentários em http://permut.wordpress.com/2010/04/21/revision-control-statistics-bleg/

No entanto, estou avaliando se vale a pena adotar um sistema de controle de versão como o git.

Uma breve visão geral: sou um cientista social que usa R para analisar dados para publicações de pesquisa. Atualmente, não produzo pacotes R. Meu código R para um projeto normalmente inclui alguns milhares de linhas de código para entrada, limpeza, manipulação, análise e geração de saída de dados. As publicações são tipicamente escritas usando o LaTeX.

No que diz respeito ao controle de versão, existem muitos benefícios sobre os quais eu li, mas eles parecem ser menos relevantes para o analista de dados solo.

• Backup: Eu já tenho um sistema de backup.
• Bifurcação e rebobinamento: nunca senti a necessidade de fazer isso, mas posso ver como isso poderia ser útil (por exemplo, você está preparando vários artigos de periódicos com base no mesmo conjunto de dados; você está preparando um relatório que é atualizado mensalmente etc.) )
• Colaboração: na maioria das vezes eu mesmo estou analisando dados, portanto, não recebia os benefícios de colaboração do controle de versão.

Também existem vários custos potenciais envolvidos na adoção do controle de versão:

• Hora de avaliar e aprender um sistema de controle de versão
• Um possível aumento de complexidade em relação ao meu sistema de gerenciamento de arquivos atual

No entanto, ainda sinto que estou perdendo alguma coisa. Guias gerais sobre controle de versão parecem ser dirigidos mais aos cientistas da computação do que aos analistas de dados.

Assim, especificamente em relação aos analistas de dados em circunstâncias semelhantes às listadas acima:

1. O controle de versão vale o esforço?
2. Quais são os principais prós e contras da adoção do controle de versão?
3. Qual é uma boa estratégia para iniciar o controle de versão para análise de dados com R (por exemplo, exemplos, idéias de fluxo de trabalho, software, links para guias)?

Eu sinto que a resposta para sua pergunta é um retumbante sim - os benefícios de gerenciar seus arquivos com um sistema de controle de versão superam os custos de implementação desse sistema.

Vou tentar responder em detalhes a alguns dos pontos que você levantou:

• Backup: Eu já tenho um sistema de backup.

Sim, e eu também. No entanto, há algumas questões a serem consideradas em relação à adequação de contar com um sistema de backup de uso geral para rastrear adequadamente arquivos importantes e ativos relacionados ao seu trabalho. No lado do desempenho:

• Em que intervalo seu sistema de backup tira instantâneos?
• Quanto tempo leva para criar um instantâneo?
• Ele precisa criar uma imagem de todo o seu disco rígido ao tirar uma foto instantânea ou pode ser dito facilmente que você faça backup de apenas dois arquivos que receberam atualizações críticas?
• O seu sistema de backup pode mostrar, com precisão exata, o que mudou nos seus arquivos de texto de um backup para o outro?

E o mais importante:

• Em quais locais os backups são salvos? Eles estão no mesmo local físico do seu computador?
• Quão fácil é restaurar uma determinada versão de um único arquivo do seu sistema de backup?

Por exemplo, tenha um Mac e use o Time Machine para fazer backup em outro disco rígido do meu computador. O Time Machine é ótimo para recuperar arquivos estranhos ou restaurar meu sistema, se tudo der errado. No entanto, simplesmente não tem o que é preciso para ser confiável com meu importante trabalho:

• Ao fazer backup, o Time Machine precisa criar uma imagem de todo o disco rígido, o que leva uma quantidade considerável de tempo. Se eu continuar trabalhando, não há garantia de que meu arquivo será capturado no estado em que estava quando iniciei o backup. Também posso chegar a outro ponto que gostaria de salvar antes da conclusão do primeiro backup.

• O disco rígido no qual meus backups do Time Machine são salvos está localizado na minha máquina - isso torna meus dados vulneráveis ​​a roubo, incêndio e outros desastres.

Com um sistema de controle de versão como o Git, posso iniciar um backup de arquivos específicos sem mais esforço do que solicitar um salvamento em um editor de texto - e o arquivo é visualizado e armazenado instantaneamente. Além disso, o Git é distribuído para que cada computador em que trabalho tenha uma cópia completa do repositório.

Isso equivale a ter meu trabalho espelhado em quatro computadores diferentes - nada menos que um ato de Deus poderia destruir meus arquivos e dados, e nesse ponto eu provavelmente não me importaria muito.

• Bifurcação e rebobinagem: nunca senti a necessidade de fazer isso, mas posso ver como isso poderia ser útil (por exemplo, você está preparando vários artigos de periódicos com base no mesmo conjunto de dados; você está preparando um relatório que é atualizado mensalmente etc.) )

Como solista, eu também não garfo tanto. No entanto, o tempo que economizei com a opção de retroceder pagou sozinho meu investimento em aprender um sistema de controle de versão muitas e muitas vezes. Você diz que nunca sentiu a necessidade de fazer isso, mas retroceder qualquer arquivo no seu sistema de backup atual foi realmente uma opção indolor e viável?

Às vezes, o relatório parecia melhor 45 minutos, uma hora ou dois dias atrás.

• Colaboração: na maioria das vezes eu mesmo estou analisando dados, portanto, não recebia os benefícios de colaboração do controle de versão.

Sim, mas você aprenderia uma ferramenta que pode ser indispensável se acabar colaborando com outras pessoas em um projeto.

• Hora de avaliar e aprender um sistema de controle de versão

Não se preocupe muito com isso. Os sistemas de controle de versão são como linguagens de programação - eles têm alguns conceitos-chave que precisam ser aprendidos e o resto é apenas açúcar sintático. Basicamente, o primeiro sistema de controle de versão que você aprender exigirá investir mais tempo para mudar para outro, apenas aprender como o novo sistema expressa os principais conceitos.

Escolha um sistema popular e vá em frente!

• Um possível aumento de complexidade em relação ao meu sistema de gerenciamento de arquivos atual

Você tem uma pasta, por exemplo, Projectsque contém todas as pastas e arquivos relacionados às suas atividades de análise de dados? Nesse caso, aplicar um controle de versão aumentará exatamente a complexidade do seu sistema de arquivos 0. Se seus projetos estão espalhados pelo seu computador - você deve centralizá-los antes de aplicar o controle de versão e isso acabará diminuindo a complexidade do gerenciamento de seus arquivos - é por isso que temos uma Documentspasta, afinal.

1. O controle de versão vale o esforço?

Sim! Ele oferece um enorme botão de desfazer e permite transferir facilmente o trabalho de uma máquina para outra sem se preocupar com coisas como perder a unidade USB.

2 Quais são os principais prós e contras da adoção do controle de versão?

O único truque que consigo pensar é um ligeiro aumento no tamanho do arquivo - mas os modernos sistemas de controle de versão podem fazer coisas absolutamente incríveis com compactação e economia seletiva, portanto esse é um ponto discutível.

3 Qual é uma boa estratégia para iniciar o controle de versão para análise de dados com R (por exemplo, exemplos, idéias de fluxo de trabalho, software, links para guias)?

Mantenha os arquivos que geram dados ou relatórios sob controle de versão, seja seletivo. Se você estiver usando algo parecido Sweave, armazene seus .Rnwarquivos e não os .texarquivos que são produzidos a partir deles. Armazene dados brutos se for difícil recuperar novamente. Se possível, escreva e armazene um script que adquira seus dados e outro que os limpe ou modifique, em vez de armazenar alterações nos dados brutos.

Quanto à aprendizagem de um sistema de controle de versão, eu recomendo o Git e este guia .

Esses sites também têm dicas e truques interessantes relacionados à execução de ações específicas com o Git:

• http://www.gitready.com/

• http://progit.org/blog.html

Trabalhei nove anos em uma loja de análise e introduzi a ideia de controle de versão para nossos projetos de análise nessa loja. Eu acredito muito no controle de versão, obviamente. Gostaria de fazer os seguintes pontos, no entanto.

1. O controle de versão pode não ser apropriado se você estiver fazendo uma análise para possível uso em tribunal. Não parece que isso se aplique a você, mas teria deixado nossos clientes muito nervosos ao saber que todas as versões de todos os scripts que produzimos foram potencialmente descobertas. Usamos o controle de versão para módulos de código que foram reutilizados em vários compromissos, mas não usamos o controle de versão para código específico do compromisso, por esse motivo.
2. Descobrimos que o maior benefício para o controle de versão veio do armazenamento de módulos de código enlatados que foram reutilizados em vários projetos. Por exemplo, você pode ter uma maneira favorita específica de processar certas extrações de Censo PUMS. Organize esse código em um diretório e coloque-o no seu VCS. Você pode conferir em cada novo projeto sempre que precisar. Pode até ser útil criar ramificações específicas de determinado código para determinado projeto, se você estiver executando um processamento especial de um conjunto de dados comum específico para esse projeto. Em seguida, quando terminar o projeto, decida quanto do seu código especial será mesclado novamente à ramificação principal.
3. Não coloque dados processados ​​no controle de versão. Somente código. Nosso objetivo era sempre ter um conjunto completo de scripts para que pudéssemos excluir todos os dados processados ​​internamente, pressionar um botão e ter todos os números do relatório regenerados do zero. Essa é a única maneira de garantir que você não tenha bugs antigos vivendo misteriosamente em seus dados.
4. Para garantir que seus resultados sejam realmente completamente reproduzíveis, não basta apenas manter seu código em um VCS. É fundamental manter um controle cuidadoso de qual versão de quais módulos foram usados ​​para criar qualquer entrega específica.
5. Quanto ao software, tive boa sorte com o Subversion. É fácil de configurar e administrar. Reconheço o apelo dos VCSs distribuídos, como git e mercurial, mas não tenho certeza de que haja fortes vantagens se você estiver trabalhando sozinho. Por outro lado, também não conheço pontos negativos em usá-los - simplesmente não trabalhei com eles em um ambiente de análise.

Por uma questão de integridade, pensei em fornecer uma atualização sobre minha adoção do controle de versão.

Eu achei o controle de versão para projetos de análise de dados solo muito úteis.

Adotei o git como minha principal ferramenta de controle de versão. Comecei usando Egit no Eclipse com StatET. Agora, geralmente, apenas uso a interface da linha de comandos, embora a integração com o RStudio seja bastante boa.

Eu escrevi sobre minha experiência em configurar o controle de versão da perspectiva dos projetos de análise de dados.

Conforme declarado no post, descobri que a adoção do controle de versão teve muitos benefícios secundários na maneira como penso nos projetos de análise de dados, incluindo esclarecimentos:

• a distinção entre arquivos de origem e derivados
• a natureza das dependências:
  • dependências entre elementos do código
  • dependências entre arquivos dentro de um projeto
  • e dependências com arquivos e programas externos ao repositório
• a natureza de um repositório e como os repositórios devem ser divididos
• a natureza de confirmar e documentar alterações e marcos do projeto

Faço pesquisas econômicas usando R e LaTeX e sempre coloco meu trabalho sob controle de versão. É como ter desfazer ilimitado. Experimente o Bazaar, é um dos mais simples de aprender e usar, e se você estiver no Windows, ele possui uma interface gráfica do usuário (TortoiseBZR).

Sim, existem benefícios adicionais ao controle de versão ao trabalhar com outras pessoas, mas mesmo em projetos solo, faz muito sentido.

No momento, você provavelmente pensa em seu trabalho como desenvolvimento de código que fará o que você deseja que ele faça. Depois de adotar o uso de um sistema de controle de revisão, você pensará no seu trabalho como anotando seu legado no repositório e fazendo alterações incrementais brilhantes nele. Parece muito melhor.

Eu ainda recomendaria o controle de versão para um ato solo como você, porque ter uma rede de segurança para detectar erros pode ser uma ótima coisa.

Eu trabalhei como desenvolvedor Java solo e ainda uso o controle de origem. Se eu estiver verificando as coisas continuamente, não posso perder mais de uma hora de trabalho se algo der errado. Posso experimentar e refatorar sem me preocupar, porque, se der errado, sempre posso voltar à minha última versão de trabalho.

Se esse for o seu caso, recomendo o uso do controle de origem. Não é difícil de aprender.

Você precisa usar um software de controle de versão, caso contrário, sua análise não será perfeitamente reproduzível.

Se você deseja publicar seus resultados em algum lugar, sempre deve poder reconstruir o status de seus scripts no momento em que os produziu. Digamos que um dos revisores descubra um erro em um de seus scripts: como você saberia quais resultados foram afetados ou não?

Nesse sentido, um sistema de backup não é suficiente, porque provavelmente é feito apenas uma vez por dia e não aplica rótulos aos diferentes backups; portanto, você não sabe quais versões correspondem a quais resultados. E aprender um vcs é mais simples do que você pensa, se aprender como adicionar um arquivo e como confirmar alterações, já é suficiente.

O controle de versão vale o esforço?

um grande SIM.

Quais são os principais prós e contras da adoção do controle de versão?

Prós: você pode acompanhar o que fez antes. Especialmente útil para o látex, pois você pode precisar de um parágrafo antigo que foi excluído por você! Quando o computador trava ou você trabalha em um novo, você tem seus dados de volta em tempo real.

contras: você precisa fazer algumas configurações.

Qual é uma boa estratégia para iniciar o controle de versão para análise de dados com R (por exemplo, exemplos, idéias de fluxo de trabalho, software, links para guias)?

Basta começar a usá-lo. Eu uso o SVN da tartaruga no Windows como uma ferramenta cliente e meu departamento tem um servidor svn, coloquei todo o meu código e dados (sim, você também colocou seus dados lá!) Lá.

Recue um pouco primeiro e aprenda as vantagens de escrever pacotes R! Você diz que possui projetos com vários milhares de linhas de código, mas essas não são estruturadas ou documentadas como o código do pacote? Você obtém grandes vitórias em conformidade com os ideais do pacote, incluindo documentação para todas as funções, testes para muitos dos erros difíceis de detectar, a facilidade de escrever seus próprios conjuntos de testes, etc.

Se você não tem disciplina para produzir um pacote, não tenho certeza se você tem a disciplina para fazer o controle de revisão adequado.

Concordo com os sentimentos acima e digo que, sim, o controle de versão é útil.

Vantagens;

• mantenha sua pesquisa registrada e com backup (marcação)
• permite experimentar idéias diferentes e voltar se elas não funcionarem (ramificação)
• Você pode compartilhar seu trabalho com outras pessoas e elas podem compartilhar suas alterações com você (eu sei que você não especificou isso, mas é ótimo)
• A maioria dos sistemas de controle de versão facilita a criação de um pacote compactado para todos os arquivos sob controle em um determinado momento; por exemplo, no momento em que você envia um artigo para publicação, isso pode ajudar quando outras pessoas revisam seus artigos. (você pode fazer isso manualmente, mas por que criar esses processos quando o controle de versão apenas faz isso)

Em termos de conjuntos de ferramentas, eu uso o Git , juntamente com o StatEt e o Eclipse, que funcionam bem, embora você certamente não precise usar o Eclipse. Existem alguns plugins Git para Eclipse , mas geralmente uso as opções de linha de comando.

Um controle de versão para desenvolvimento solo (de qualquer tipo) é realmente interessante para:

• explorar a história e comparar o trabalho atual com confirmações passadas
• ramificando e tentando versões diferentes para um mesmo conjunto de arquivos

Se você não se encontrar executando um desses dois recursos básicos de controle de versão, uma simples ferramenta de backup pode ser tudo o que você precisa.
Se você precisar desses recursos, também receberá backup ( git bundlepor exemplo)

Também faço trabalhos de script solo e acho que isso mantém as coisas mais simples, em vez de torná-las mais complexas. O backup é integrado ao fluxo de trabalho de codificação e não requer um conjunto separado de procedimentos do sistema de arquivos. O tempo necessário para aprender o básico de qualquer sistema de controle de versão seria definitivamente um tempo bem gasto.

O Dropbox possui um controle de versão "ppor man" que leva você a parte do caminho por pouco esforço e com muitos benefícios extras.