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 serait utile.
Un bref aperçu: Je suis un spécialiste des sciences sociales qui utilise R pour analyser les données des publications de recherche. Je ne produis pas actuellement 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 à l'aide de LaTeX.
En ce qui concerne le contrôle de version, il y a de nombreux avantages que j'ai lus, mais ils semblent moins pertinents pour l'analyste de données solo.
- Sauvegarde: J'ai déjà un système de sauvegarde en place.
- Fourche 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 moi-même les données, donc, je ne bénéficierais pas des 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 de manquer quelque chose. Les guides généraux sur le contrôle des versions semblent s'adresser davantage aux informaticiens qu'aux analystes de données.
Ainsi, spécifiquement par rapport aux analystes de données dans des circonstances similaires à celles énumérées ci-dessus:
- Le contrôle de version en vaut-il la peine?
- Quels sont les principaux avantages et inconvénients de l'adoption du contrôle de version?
- Quelle est la bonne stratégie pour commencer avec le contrôle de version pour l'analyse des données avec R (par exemple, des exemples, des idées de workflow, des logiciels, des liens vers des guides)?
Je pense que la réponse à votre question est un oui retentissant - 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 la pertinence de s'appuyer sur un système de sauvegarde à usage général pour suivre correctement les fichiers importants et actifs liés à votre travail. Côté performance:
- À quel intervalle votre système de sauvegarde prend-il des instantanés?
- Combien de temps faut-il pour créer un instantané?
- Doit-il imager l'intégralité de votre disque dur lors de la prise d'un instantané, ou pourrait-on facilement lui dire 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, ayez 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 en cas de problème. Cependant, il n'a tout simplement pas ce qu'il faut pour faire confiance à mon travail important:
Lors de la sauvegarde, Time Machine doit imager l'ensemble du disque dur, ce qui prend beaucoup de temps. Si je continue de travailler, il n'y a aucune garantie que mon fichier sera capturé dans l'état où il était 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, ce qui 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 divin pourrait détruire mes fichiers et données, auquel cas je ne m'en soucierais probablement pas trop de toute façon.
- Fourche 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 journaux articles 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 remboursé à lui seul 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 le faire, mais le rembobinage d'un fichier sous votre système de sauvegarde actuel a-t-il vraiment été une option indolore et faisable?
Parfois, le rapport avait simplement l'air mieux il y a 45 minutes, une heure ou deux jours.
- Collaboration: La plupart du temps, j'analyse moi-même les données, donc je ne bénéficierais pas des avantages de collaboration du contrôle de version.
Oui, mais vous apprenez un outil qui peut 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 apprendrez nécessitera d'investir le plus de temps pour passer à un autre, il suffit d'apprendre comment le nouveau système exprime les concepts clés.
Choisissez un système populaire et foncez!
- Une augmentation possible de la complexité par rapport à mon système de gestion de fichiers actuel
Avez-vous un dossier, disons Projects qui contient tous les dossiers et fichiers liés à vos activités d'analyse de données? Si c'est le cas, alors le contrôle de version est activé, cela augmentera la complexité de votre système de fichiers exactement 0. Si vos projets sont éparpillés sur votre ordinateur, 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 dossier Documents après tout.
- 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 peux 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 l'enregistrement sélectif, donc c'est à peu près un point discutable.
3 Quelle est la bonne stratégie pour commencer avec le contrôle de version pour l'analyse des données avec R (par exemple, exemples, idées de workflow, logiciels, 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 votre .Rnw fichiers et non .tex fichiers qui en sont produits. Stockez des 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.
Quant à l'apprentissage d'un système de contrôle de version, je recommande fortement Git et ce guide .
Ces sites Web contiennent également de bons conseils et astuces liés à l'exécution d'actions spécifiques avec Git:
J'ai travaillé pendant neuf ans dans une boutique d'analyse et j'ai introduit l'idée de 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 toutefois souligner les points suivants.
- Le contrôle de version peut ne pas être approprié si vous effectuez une analyse pour une éventuelle utilisation en justice. Cela ne semble pas que cela s'applique à vous, mais cela aurait rendu nos clients très nerveux de savoir que chaque version de chaque script que nous avions jamais 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 missions, mais nous n'avons pas utilisé le contrôle de version pour le code spécifique à la mission, pour cette raison.
- Nous avons constaté que le plus grand avantage du contrôle de version provenait du stockage de modules de code en conserve qui ont été réutilisés dans plusieurs projets. Par exemple, vous pourriez avoir une façon préférée particulière de traiter certains extraits de PUMS du recensement. Organisez ce code dans un répertoire et placez-le dans votre VCS. Vous pouvez ensuite le vérifier dans 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é avec ce projet, décidez de la quantité de votre code spécial à fusionner vers la branche principale.
- Ne placez pas de 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 que chaque numéro du rapport soit régénéré à partir de zéro. C'est la seule façon d'être sûr que vous n'avez pas d'anciens bogues qui vivent mystérieusement dans vos données.
- Pour vous assurer que vos résultats sont vraiment entièrement 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 qui ont été utilisés pour créer un livrable particulier.
- Quant au logiciel, j'ai eu de la chance avec Subversion. Il est facile à installer 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 forts avantages si vous travaillez seul. D'un autre côté, je ne connais aucun inconvénient à les utiliser non plus - je n'ai tout simplement pas travaillé avec eux dans un environnement d'analyse.
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 a une interface utilisateur graphique (TortoiseBZR).
Oui, le contrôle de version présente des avantages supplémentaires lorsque vous travaillez avec d'autres, mais même sur des projets solo, cela a beaucoup de sens.
Dans un souci d'exhaustivité, j'ai pensé fournir une mise à jour sur mon adoption du contrôle de version.
J'ai trouvé le contrôle de version pour les projets d'analyse de données en solo 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 l'interface de ligne de commande, bien que l'intégration avec RStudio soit assez bonne.
J'ai blogué sur mon expérience mise en place avec 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 avait de nombreux avantages secondaires dans ma façon de penser les projets d'analyse de données, y compris la clarification:
- la distinction entre fichiers source et fichiers dérivés
- la nature des dépendances:
- dépendances entre éléments de code
- dépendances entre les fichiers 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 répartition des référentiels
- la nature de l'engagement et de la documentation des changements et des jalons du projet
À 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é l'utilisation d'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 fait beaucoup mieux.
Je recommanderais toujours le contrôle de version pour un acte solo comme vous, car avoir un filet de sécurité pour détecter les erreurs peut être une bonne chose.
J'ai travaillé en solo Java, et j'utilise toujours le contrôle de code source. Si j'archive continuellement les choses, je ne peux pas perdre plus d'une heure de travail en cas de problème. I peut expérimenter et refactoriser sans souci, car si ça tourne mal, je peux toujours revenir à ma dernière version de travail.
Si c'est le cas pour vous, je vous recommande d'utiliser le contrôle de code 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 reconstruire le statut de vos scripts au moment où vous les avez produits. Disons que l'un des examinateurs découvre une erreur dans l'un de vos scripts: comment sauriez-vous quels résultats sont effectués et lesquels ne le sont pas?
En ce sens, un système de sauvegarde n'est pas suffisant car il n'est probablement effectué qu'une seule 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 l'apprentissage d'un vcs est plus simple que ce que vous pensez, si apprendre à ajouter un fichier et à valider les modifications, c'est déjà suffisant.
Reculez un peu en premier et découvrez les avantages d'écrire des packages R! Vous dites que vous avez des projets avec plusieurs milliers de lignes de code, mais qu'ils ne sont pas structurés ou documentés comme le code du package? Vous obtenez de gros gains en vous conformant aux idéaux du package, y compris la documentation pour chaque fonction, les tests pour de nombreuses erreurs habituelles difficiles à détecter, la possibilité d'écrire vos propres suites de tests, etc., 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é.
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 pourriez avoir besoin d'un ancien paragraphe que vous avez supprimé! Lorsque votre ordinateur tombe en panne ou que vous travaillez sur un nouveau, vous avez vos données à la volée.
inconvénients: vous devez faire quelques réglages.
Quelle est la bonne stratégie pour commencer avec le contrôle de version pour l'analyse des données avec R (par exemple, des exemples, des idées de workflow, des logiciels, des liens vers des guides)?
Commencez simplement à l'utiliser. J'utilise tortoise SVN sur Windows comme outil client et mon département a un serveur svn, j'y mets tout mon code et mes données (oui, vous y mettez aussi vos données!).
Je suis d'accord avec les sentiments ci-dessus et je dis que, oui, le contrôle de version est utile.
Avantages;
- garder vos recherches enregistrées ainsi que sauvegardées, (marquage)
- il vous permet d'essayer différentes idées et de revenir en arrière si elles ne fonctionnent pas (branchement)
- Vous pouvez partager votre travail avec d'autres personnes, et ils 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 certain moment, 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 inventer ces processus lorsque le contrôle de version le fait)
En termes de jeux d'outils, j'utilise Git , ainsi que StatEt et Eclipse qui fonctionne bien, bien que vous n'ayez certainement pas à utiliser Eclipse. Il y a quelques plugins Git pour Eclipse , mais j'utilise généralement les options de ligne de commande.
Je fais également du travail de script solo, et je trouve que cela simplifie les choses plutôt que de les rendre 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.
Un contrôle de version pour le développement solo (de toute nature) est vraiment intéressant pour:
- explorer l'histoire et comparer le travail en cours avec les validations passées
- branchement 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 contrôle de version de base, un simple outil de sauvegarde pourrait être tout ce dont vous avez besoin.
Si vous avez besoin de ces fonctionnalités, vous obtiendrez également une sauvegarde (avec git bundle par exemple)