R et contrôle de version pour l'analyste de données solo

De nombreux analystes de données que je respecte utilisent le contrôle de version. Par exemple:

• http://github.com/hadley/
• Voir les commentaires sur http://permut.wordpress.com/2010/04/21/revision-control-statistics-bleg/

Cependant, j'évalue si l'adoption d'un système de contrôle de version tel que git en vaudrait la peine.

Un bref aperçu: je suis un spécialiste des sciences sociales qui utilise R pour analyser des données pour des publications de recherche. Je ne produit actuellement pas de packages R. Mon code R pour un projet comprend généralement quelques milliers de lignes de code pour l'entrée de données, le nettoyage, la manipulation, les analyses et la génération de sortie. Les publications sont généralement écrites en utilisant LaTeX.

En ce qui concerne le contrôle de version, j'ai lu de nombreux avantages, mais ils semblent moins pertinents pour l'analyste de données en solo.

• Sauvegarde: j'ai un système de sauvegarde déjà en place.
• Forking et rembobinage: je n'ai jamais ressenti le besoin de le faire, mais je peux voir comment cela pourrait être utile (par exemple, vous préparez plusieurs articles de revue basés sur le même ensemble de données; vous préparez un rapport qui est mis à jour mensuellement, etc. )
• Collaboration: la plupart du temps, j'analyse les données moi-même, donc je n'obtiendrais pas les avantages de collaboration du contrôle de version.

L'adoption du contrôle de version comporte également plusieurs coûts potentiels:

• Il est temps d'évaluer et d'apprendre un système de contrôle de version
• Une augmentation possible de la complexité par rapport à mon système de gestion de fichiers actuel

Cependant, j'ai toujours le sentiment qu'il me manque quelque chose. Les guides généraux sur le contrôle de version semblent s'adresser davantage aux informaticiens qu'aux analystes de données.

Ainsi, spécifiquement en ce qui concerne les analystes de données dans des circonstances similaires à celles énumérées ci-dessus:

1. Le contrôle de version en vaut-il la peine?
2. Quels sont les principaux avantages et inconvénients de l'adoption du contrôle de version?
3. Quelle est une bonne stratégie pour démarrer avec le contrôle de version pour l'analyse des données avec R (par exemple, des exemples, des idées de flux de travail, des logiciels, des liens vers des guides)?

Je pense que la réponse à votre question est un oui catégorique - les avantages de la gestion de vos fichiers avec un système de contrôle de version dépassent de loin les coûts de mise en œuvre d'un tel système.

Je vais essayer de répondre en détail à certains des points que vous avez soulevés:

• Sauvegarde: j'ai un système de sauvegarde déjà en place.

Oui, et moi aussi. Cependant, il y a quelques questions à considérer concernant l'opportunité de s'appuyer sur un système de sauvegarde à usage général pour suivre adéquatement les fichiers importants et actifs relatifs à votre travail. Côté performances:

• À quel intervalle votre système de sauvegarde prend-il des instantanés?
• Combien de temps faut-il pour créer un instantané?
• Doit-il créer une image de l'ensemble de votre disque dur lors de la prise d'un instantané, ou pourrait-il être facilement dit de simplement sauvegarder deux fichiers qui viennent de recevoir des mises à jour critiques?
• Votre système de sauvegarde peut-il vous montrer, avec une précision extrême, ce qui a changé dans vos fichiers texte d'une sauvegarde à l'autre?

Et, surtout:

• Dans combien d'emplacements les sauvegardes sont-elles enregistrées? Se trouvent-ils au même emplacement physique que votre ordinateur?
• Est-il facile de restaurer une version donnée d'un seul fichier à partir de votre système de sauvegarde?

Par exemple, possédez un Mac et utilisez Time Machine pour sauvegarder sur un autre disque dur de mon ordinateur. Time Machine est idéal pour récupérer le fichier impair ou restaurer mon système si les choses se gâtent. Cependant, il n'a tout simplement pas ce qu'il faut pour faire confiance à mon travail important:

• Lors de la sauvegarde, Time Machine doit créer une image de l'ensemble du disque dur, ce qui prend un temps considérable. Si je continue à travailler, rien ne garantit que mon fichier sera capturé dans l'état où il se trouvait lorsque j'ai lancé la sauvegarde. Je peux également atteindre un autre point que je voudrais enregistrer avant la fin de la première sauvegarde.

• Le disque dur sur lequel mes sauvegardes Time Machine sont enregistrées se trouve dans ma machine - cela rend mes données vulnérables au vol, au feu et à d'autres catastrophes.

Avec un système de contrôle de version comme Git, je peux lancer une sauvegarde de fichiers spécifiques sans plus d'effort que de demander une sauvegarde dans un éditeur de texte - et le fichier est imagé et stocké instantanément. De plus, Git est distribué afin que chaque ordinateur sur lequel je travaille ait une copie complète du référentiel.

Cela revient à avoir mon travail en miroir sur quatre ordinateurs différents - rien de moins qu'un acte de Dieu ne pourrait détruire mes fichiers et mes données, auquel cas je ne m'en soucierais probablement pas trop de toute façon.

• Forking et rembobinage: je n'ai jamais ressenti le besoin de le faire, mais je peux voir comment cela pourrait être utile (par exemple, vous préparez plusieurs articles de revue basés sur le même ensemble de données; vous préparez un rapport qui est mis à jour mensuellement, etc. )

En tant que soliste, je ne fourche pas beaucoup non plus. Cependant, le temps que j'ai gagné en ayant la possibilité de rembobiner a à lui seul remboursé mon investissement dans l'apprentissage d'un système de contrôle de version à de nombreuses reprises. Vous dites que vous n'avez jamais ressenti le besoin de faire cela, mais le rembobinage d'un fichier sous votre système de sauvegarde actuel a-t-il vraiment été une option réalisable et indolore?

Parfois, le rapport avait une meilleure apparence il y a 45 minutes, une heure ou deux jours.

• Collaboration: la plupart du temps, j'analyse les données moi-même, donc je n'obtiendrais pas les avantages de collaboration du contrôle de version.

Oui, mais vous apprendriez un outil qui pourrait s'avérer indispensable si vous finissez par collaborer avec d'autres sur un projet.

• Il est temps d'évaluer et d'apprendre un système de contrôle de version

Ne vous en faites pas trop. Les systèmes de contrôle de version sont comme des langages de programmation - ils ont quelques concepts clés à apprendre et le reste n'est que du sucre syntaxique. Fondamentalement, le premier système de contrôle de version que vous apprenez nécessitera d'investir le plus de temps - le passage à un autre nécessite simplement d'apprendre comment le nouveau système exprime les concepts clés.

Choisissez un système populaire et lancez-vous!

• Une augmentation possible de la complexité par rapport à mon système de gestion de fichiers actuel

Avez-vous un dossier, par exemple, Projectsqui contient tous les dossiers et fichiers liés à vos activités d'analyse de données? Si tel est le cas, appliquer le contrôle de version augmentera exactement la complexité de votre système de fichiers 0. Si vos projets sont éparpillés sur votre ordinateur - alors vous devez les centraliser avant d'appliquer le contrôle de version et cela finira par diminuer la complexité de la gestion de vos fichiers - c'est pourquoi nous avons un Documentsdossier après tout.

1. Le contrôle de version en vaut-il la peine?

Oui! Il vous donne un énorme bouton d'annulation et vous permet de transférer facilement le travail d'une machine à l'autre sans vous soucier de choses comme la perte de votre clé USB.

2 Quels sont les principaux avantages et inconvénients de l'adoption du contrôle de version?

Le seul inconvénient auquel je puisse penser est une légère augmentation de la taille du fichier - mais les systèmes de contrôle de version modernes peuvent faire des choses absolument incroyables avec la compression et la sauvegarde sélective, donc c'est à peu près un point discutable.

3 Quelle est une bonne stratégie pour démarrer avec le contrôle de version pour l'analyse des données avec R (par exemple, des exemples, des idées de flux de travail, des logiciels, des liens vers des guides)?

Gardez les fichiers qui génèrent des données ou des rapports sous contrôle de version, soyez sélectif. Si vous utilisez quelque chose comme Sweave, stockez vos .Rnwfichiers et non les .texfichiers qui en sont produits. Stockez les données brutes s'il serait difficile de les réacquérir. Si possible, écrivez et stockez un script qui acquiert vos données et un autre qui les nettoie ou les modifie plutôt que de stocker les modifications apportées aux données brutes.

En ce qui concerne l'apprentissage d'un système de contrôle de version, je recommande vivement Git et ce guide .

Ces sites Web proposent également de bons conseils et astuces liés à l'exécution d'actions spécifiques avec Git:

• http://www.gitready.com/

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

J'ai travaillé pendant neuf ans dans une boutique d'analyse et j'ai introduit l'idée du contrôle de version pour nos projets d'analyse dans cette boutique. Je suis un grand partisan du contrôle de version, évidemment. Je voudrais cependant faire les remarques suivantes.

1. Le contrôle de version peut ne pas être approprié si vous effectuez une analyse en vue d'une utilisation éventuelle au tribunal. Cela ne semble pas s'appliquer à vous, mais cela aurait rendu nos clients très nerveux de savoir que chaque version de chaque script que nous avions produit était potentiellement découvrable. Nous avons utilisé le contrôle de version pour les modules de code qui ont été réutilisés dans plusieurs engagements, mais nous n'avons pas utilisé le contrôle de version pour le code spécifique à l'engagement, pour cette raison.
2. Nous avons constaté que le plus grand avantage du contrôle de version provenait du stockage de modules de code prédéfinis qui étaient réutilisés dans plusieurs projets. Par exemple, vous pourriez avoir une façon préférée de traiter certains extraits PUMS du recensement. Organisez ce code dans un répertoire et placez-le dans votre VCS. Vous pouvez ensuite l'intégrer à chaque nouveau projet à chaque fois que vous en avez besoin. Il peut même être utile de créer des branches spécifiques de certains codes pour certains projets, si vous effectuez un traitement spécial d'un ensemble de données commun particulier pour ce projet. Ensuite, lorsque vous avez terminé ce projet, décidez de la quantité de code spécial à fusionner dans la branche principale.
3. Ne mettez pas les données traitées dans le contrôle de version. Seul le code. Notre objectif était toujours d'avoir un ensemble complet de scripts afin que nous puissions supprimer toutes nos données traitées en interne, appuyer sur un bouton et avoir chaque numéro du rapport régénéré à partir de zéro. C'est le seul moyen de s'assurer que vous n'avez pas de vieux bogues vivant mystérieusement dans vos données.
4. Pour vous assurer que vos résultats sont vraiment complètement reproductibles, il ne suffit pas de conserver votre code dans un VCS. Il est essentiel de garder une trace précise de la version des modules utilisés pour créer un livrable particulier.
5. En ce qui concerne les logiciels, j'ai eu de la chance avec Subversion. Il est facile à configurer et à administrer. Je reconnais l'attrait des nouveaux VCS distribués, comme git et mercurial, mais je ne suis pas sûr qu'il y ait de gros avantages si vous travaillez seul. D'un autre côté, je ne connais pas non plus d'inconvénients à les utiliser - je n'ai tout simplement pas travaillé avec eux dans un environnement d'analyse.

Par souci d'exhaustivité, j'ai pensé fournir une mise à jour sur mon adoption du contrôle de version.

J'ai trouvé que le contrôle de version pour les projets d'analyse de données en solo était très utile.

J'ai adopté git comme principal outil de contrôle de version. J'ai commencé par utiliser Egit dans Eclipse avec StatET. Maintenant, j'utilise généralement simplement l'interface de ligne de commande, bien que l'intégration avec RStudio soit assez bonne.

J'ai blogué sur mon expérience de la configuration du contrôle de version du point de vue des projets d'analyse de données.

Comme indiqué dans l'article, j'ai trouvé que l'adoption du contrôle de version a eu de nombreux avantages secondaires dans la façon dont je pense aux projets d'analyse de données, notamment en clarifiant:

• la distinction entre les fichiers source et dérivés
• la nature des dépendances:
  • dépendances entre éléments de code
  • dépendances entre fichiers au sein d'un projet
  • et dépendances avec des fichiers et des programmes externes au référentiel
• la nature d'un référentiel et la manière dont les référentiels doivent être divisés
• la nature de la validation et de la documentation des changements et des jalons du projet

Je fais des recherches économiques en utilisant R et LaTeX, et je mets toujours mon travail sous contrôle de version. C'est comme avoir une annulation illimitée. Essayez Bazaar, c'est l'un des plus simples à apprendre et à utiliser, et si vous êtes sous Windows, il dispose d'une interface utilisateur graphique (TortoiseBZR).

Oui, le contrôle de version présente des avantages supplémentaires lorsque vous travaillez avec d'autres personnes, mais même sur des projets solo, cela a beaucoup de sens.

À l'heure actuelle, vous pensez probablement que votre travail consiste à développer du code qui fera ce que vous voulez qu'il fasse. Après avoir adopté un système de contrôle des révisions, vous penserez que votre travail consiste à écrire votre héritage dans le référentiel et à y apporter de brillantes modifications incrémentielles. Ça va mieux.

Je recommanderais toujours le contrôle de version pour un acte solo comme vous, car avoir un filet de sécurité pour attraper les erreurs peut être une bonne chose à avoir.

J'ai travaillé en tant que développeur Java solo et j'utilise toujours le contrôle de source. Si je vérifie les choses en permanence, je ne peux pas perdre plus d'une heure de travail si quelque chose ne va pas. Je peux expérimenter et refactoriser sans me soucier, car si ça tourne mal, je peux toujours revenir à ma dernière version de travail.

Si tel est le cas pour vous, je vous recommande d'utiliser le contrôle de source. Ce n'est pas difficile à apprendre.

Vous devez utiliser un logiciel de contrôle de version, sinon votre analyse ne sera pas parfaitement reproductible.

Si vous souhaitez publier vos résultats quelque part, vous devriez toujours être en mesure de reconstituer le statut de vos scripts au moment où vous les avez produits. Disons que l'un des relecteurs découvre une erreur dans l'un de vos scripts: comment sauriez-vous quels résultats sont affectés et lesquels ne le sont pas?

En ce sens, un système de sauvegarde n'est pas suffisant car il n'est probablement fait qu'une fois par jour, et il n'applique pas d'étiquettes aux différentes sauvegardes, vous ne savez donc pas quelles versions correspondent à quels résultats. Et apprendre un vcs est plus simple que ce que vous pensez, si vous apprenez à ajouter un fichier et à valider des modifications, c'est déjà suffisant.

Le contrôle de version en vaut-il la peine?

un grand OUI.

Quels sont les principaux avantages et inconvénients de l'adoption du contrôle de version?

avantages: vous pouvez suivre ce que vous avez fait auparavant. Particulièrement utile pour le latex, car vous aurez peut-être besoin d'un ancien paragraphe que vous avez supprimé! Lorsque votre ordinateur tombe en panne ou que vous travaillez sur un nouveau, vous récupérez vos données à la volée.

inconvénients: vous devez faire quelques réglages.

Quelle est une bonne stratégie pour démarrer avec le contrôle de version pour l'analyse des données avec R (par exemple, des exemples, des idées de flux de travail, des logiciels, des liens vers des guides)?

Commencez simplement à l'utiliser. J'utilise tortoise SVN sur Windows comme outil client et mon service dispose d'un serveur svn, j'y mets tout mon code et mes données (oui, vous y mettez aussi vos données!).

Prenez un peu de recul et découvrez les avantages de l'écriture de packages R! Vous dites que vous avez des projets avec plusieurs milliers de lignes de code, mais ceux-ci ne sont pas structurés ou documentés comme le code de package? Vous obtenez de gros gains en vous conformant aux idéaux du paquet, y compris la documentation pour chaque fonction, des tests pour de nombreuses erreurs difficiles à attraper, la possibilité d'écrire vos propres suites de tests, etc.

Si vous n'avez pas la discipline pour produire un package, alors je ne suis pas sûr que vous ayez la discipline pour faire un contrôle de révision approprié.

Je suis d'accord avec les sentiments ci-dessus et je dirais que, oui, le contrôle de version est utile.

Avantages;

• conservez vos recherches enregistrées et sauvegardées, (marquage)
• cela vous permet d'essayer différentes idées et de revenir en arrière si elles ne fonctionnent pas (ramification)
• Vous pouvez partager votre travail avec d'autres personnes, et elles peuvent partager leurs modifications avec vous (je sais que vous ne l'avez pas spécifié, mais c'est génial)
• La plupart des systèmes de contrôle de version facilitent la création d'un ensemble compressé pour tous les fichiers sous contrôle à un moment donné, par exemple au moment où vous soumettez un article pour publication, cela peut aider lorsque d'autres révisent vos articles. (vous pouvez le faire manuellement, mais pourquoi créer ces processus alors que le contrôle de version le fait simplement)

En termes de jeux d'outils, j'utilise Git , avec StatEt et Eclipse qui fonctionne bien, bien que vous n'ayez certainement pas à utiliser Eclipse. Il existe quelques plugins Git pour Eclipse , mais j'utilise généralement les options de ligne de commande.

Un contrôle de version pour le développement solo (de tout type) est vraiment intéressant pour:

• explorer l'histoire et comparer le travail actuel avec les engagements passés
• créer des branches et essayer différentes versions pour un même ensemble de fichiers

Si vous ne vous voyez pas faire l'une de ces deux fonctionnalités de base de contrôle de version, un simple outil de sauvegarde peut suffire.
Si vous avez besoin de ces fonctionnalités, vous obtiendrez également une sauvegarde (avec git bundlepar exemple)

Je fais aussi du travail de scénarisation en solo, et je trouve que cela simplifie les choses plutôt que les rend plus complexes. La sauvegarde est intégrée au flux de travail de codage et ne nécessite pas un ensemble distinct de procédures de système de fichiers. Le temps qu'il faut pour apprendre les bases de tout système de contrôle de version serait certainement du temps bien dépensé.

Dropbox a un contrôle de version "ppor man" qui vous permet de faire une partie du chemin pour peu d'effort avec beaucoup d'avantages supplémentaires.