Контроль R та версій для аналітика сольних даних

Багато аналітиків даних, які я поважаю, використовують контроль версій. Наприклад:

• http://github.com/hadley/
• Дивіться коментарі на http://permut.wordpress.com/2010/04/21/revision-control-statistics-bleg/

Однак я оцінюю, чи варто застосовувати систему контролю версій, наприклад git.

Короткий огляд: Я соціальний вчений, який використовує R для аналізу даних для наукових публікацій. В даний час я не виробляю пакети R. Мій код R для проекту, як правило, включає кілька тисяч рядків коду для введення даних, очищення, маніпуляцій, аналізів та генерування результатів. Публікації, як правило, пишуться за допомогою LaTeX.

Що стосується контролю версій, то я читав багато переваг, але вони, мабуть, є менш актуальними для аналітика сольних даних.

• Резервне копіювання: У мене вже створена система резервного копіювання.
• Формування та перемотування: я ніколи не відчував необхідності цього робити, але я бачу, як це може бути корисним (наприклад, ви готуєте кілька статей журналу на основі одного і того ж набору даних; ви готуєте звіт, що оновлюється щомісяця тощо) )
• Співпраця: Більшу частину часу я сам аналізую дані, таким чином, я не отримаю переваг щодо контролю версій щодо співпраці.

Існує також кілька потенційних витрат, пов’язаних із прийняттям контролю версій:

• Час оцінювати та вивчати систему контролю версій
• Можливе збільшення складності в порівнянні з моєю поточною системою управління файлами

Однак у мене все ще є відчуття, що я чогось пропускаю. Загальні посібники щодо контролю версій, схоже, адресовані більше до комп'ютерних науковців, ніж до аналітиків даних.

Таким чином, конкретно стосовно аналітиків даних в обставинах, подібних до перелічених вище:

1. Чи варто контролювати версії, докладаючи зусиль?
2. Які основні плюси та мінуси прийняття контролю над версіями?
3. Яка хороша стратегія для початку роботи з контролем версій для аналізу даних з R (наприклад, приклади, ідеї робочого процесу, програмне забезпечення, посилання на посібники)?

Я вважаю, що відповідь на ваше запитання є надзвичайним так - переваги керування файлами за допомогою системи контролю версій значно перевищують витрати на впровадження такої системи.

Я спробую детально відповісти на деякі моменти, які ви порушили:

• Резервне копіювання: У мене вже створена система резервного копіювання.

Так, так і я. Однак, слід враховувати деякі питання щодо доцільності використання системи резервного копіювання загального призначення для адекватного відстеження важливих та активних файлів, що стосуються вашої роботи. З боку продуктивності:

• З якого інтервалу ваша система резервного копіювання робить знімки?
• Скільки часу потрібно для створення знімка?
• Чи повинен він зображати весь ваш жорсткий диск під час зйомки, чи можна було легко сказати створити резервну копію двох файлів, які щойно отримали критичні оновлення?
• Чи може ваша система резервного копіювання з точністю показати вам, що змінилося у ваших текстових файлах від однієї резервної копії до іншої?

І найголовніше:

• У скільки локацій збережено резервне копіювання? Вони перебувають у тому самому фізичному місці, що і ваш комп’ютер?
• Наскільки легко відновити задану версію одного файлу із системи резервного копіювання?

Наприклад, мати Mac та використовувати Time Machine для резервного копіювання на інший жорсткий диск у моєму комп’ютері. Time Machine чудово підходить для відновлення непарного файлу або відновлення моєї системи, якщо все зіпсується. Однак у мене просто немає того, що потрібно довіряти моїй важливій роботі:

• Під час створення резервної копії Time Machine повинен зображати весь жорсткий диск, який займає значну кількість часу. Якщо я продовжую працювати, немає гарантії, що мій файл буде захоплений у тому стані, який він був, коли я ініціював резервну копію. Я також можу досягти іншої точки, яку я хотів би зберегти до завершення першого резервного копіювання.

• Жорсткий диск, на якому зберігаються резервні копії Time Machine, знаходиться в моїй машині - це робить мої дані вразливими до крадіжок, пожеж та інших катастроф.

У такій системі управління версіями, як Git, я не можу ініціювати створення резервної копії певних файлів, не вимагаючи збереження в текстовому редакторі, а файл знімається та зберігається миттєво. Крім того, Git розподілений таким чином, що кожен комп'ютер, на якому я працюю, має повну копію сховища.

Це означає, що моя робота віддзеркалена на чотирьох різних комп’ютерах - нічого, крім божого вчинку, не могло б знищити мої файли та дані, і тоді я, мабуть, все одно не надто переймався б.

• Формування та перемотування: я ніколи не відчував необхідності цього робити, але я бачу, як це може бути корисним (наприклад, ви готуєте кілька статей журналу на основі одного і того ж набору даних; ви готуєте звіт, що оновлюється щомісяця тощо) )

Як соліст, я так і не роздрібнююся. Однак час, який я заощадив, маючи можливість перемотати назад, одноразово окупив мої інвестиції у вивчення системи контролю версій багато-багато разів. Ви кажете, що ніколи не відчували необхідності цього робити, але перемотування будь-якого файлу у вашій поточній системі резервного копіювання справді було безболісним, здійсненним варіантом?

Іноді звіт виглядав краще 45 хвилин, годину чи два дні тому.

• Співпраця: Більшу частину часу я сам аналізую дані, таким чином, я не отримаю переваг щодо контролю версій щодо співпраці.

Так, але ви дізнаєтесь про інструмент, який може виявитися незамінним, якщо ви в кінцевому підсумку співпрацюєте з іншими над проектом.

• Час оцінювати та вивчати систему контролю версій

Не надто хвилюйтеся з цього приводу. Системи контролю версій схожі на мови програмування - у них є кілька ключових понять, яких потрібно вивчити, а решта - це лише синтаксичний цукор. По суті, перша система управління версіями, яку ви вивчаєте, потребує вкладення найбільшого часу, для переходу на іншу потрібно просто вивчити, як нова система виражає ключові поняття.

Виберіть популярну систему та вирушайте до неї!

• Можливе збільшення складності в порівнянні з моєю поточною системою управління файлами

Чи є у вас одна папка, скажімо, Projectsщо містить усі папки та файли, пов’язані з вашою діяльністю з аналізу даних? Якщо так, то плескання контролю версій на ньому точно збільшить складність вашої файлової системи 0. Якщо ваші проекти розкидані про вашому Computer- , то ви повинні централізувати їх перед застосуванням контролю версій , і це в кінцевому підсумку зменшуючи складність управління вашої Files-, тому у нас є Documentsпапка врешті-решт.

1. Чи варто контролювати версії, докладаючи зусиль?

Так! Це дає вам величезну кнопку скасування і дозволяє легко переносити роботу з машини на машину, не турбуючись про такі речі, як втрата USB-накопичувача.

2 Які основні плюси та мінуси прийняття контролю над версіями?

Єдине, про що я можу подумати - це незначне збільшення розміру файлів, але сучасні системи управління версіями можуть робити абсолютно дивовижні речі при стисненні та вибірковому збереженні, так що це майже суперечка.

3 Яка хороша стратегія початку роботи з контролем версій для аналізу даних з R (наприклад, приклади, ідеї робочого процесу, програмне забезпечення, посилання на посібники)?

Тримайте файли, які генерують дані чи звіти під контролем версій, будьте вибіркові. Якщо ви використовуєте щось подібне Sweave, зберігайте свої .Rnwфайли, а не .texфайли, які отримуються з них. Зберігайте необроблені дані, якщо повторно придбати це буде болем. Якщо можливо, напишіть і зберігайте сценарій, який отримує ваші дані, та інший, який очищає або модифікує їх, а не зберігає зміни в необроблених даних.

Що стосується вивчення системи контролю версій, я настійно рекомендую Git та це керівництво по ньому.

На цих веб-сайтах також є кілька корисних порад та рекомендацій щодо виконання конкретних дій з Git:

• http://www.gitready.com/

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

Я працював дев'ять років у аналітичному магазині і представив ідею контролю версій для наших проектів аналізу. Я, очевидно, дуже вірую в контроль версій. Я хотів би зазначити наступні моменти.

1. Контроль версій може виявитися недоцільним, якщо ви робите аналіз для можливого використання в суді. Це не здається, що це стосується вас, але це зробило б наших клієнтів дуже нервуючими, щоб знати, що кожна версія кожного сценарію, яку ми коли-небудь розробляли, є потенційно відкритою. Ми використовували контроль версій для модулів коду, які були повторно використані в декількох взаємодіях, але не використовували контроль версій для конкретного коду з цієї причини.
2. Ми виявили, що найбільша перевага для контролю версій припала на зберігання консервованих модулів коду, які повторно використовувались у кількох проектах. Наприклад, у вас може бути особливий улюблений спосіб обробки певних виписок PUMS Census. Організуйте цей код у каталог та вставте його у свій VCS. Потім ви можете перевіряти це у кожному новому проекті кожного разу, коли вам це потрібно. Можливо, навіть буде корисно створити конкретні гілки певного коду для певного проекту, якщо ви робите спеціальну обробку певного загального набору даних для цього проекту. Потім, коли ви закінчите з цим проектом, вирішіть, яка частина вашого спеціального коду буде об'єднана назад до основної гілки.
3. Не вкладайте оброблені дані в контроль версій. Тільки код. Нашою метою було завжди мати повний набір сценаріїв, щоб ми могли видалити всі наші внутрішньо оброблені дані, натиснути кнопку та регенерувати кожен номер звіту з нуля. Це єдиний спосіб бути впевненим, що у ваших даних таємничо не живуть старі помилки.
4. Щоб переконатися, що ваші результати справді повністю відтворені, недостатньо лише зберегти свій код у ДКС. Важливо уважно слідкувати за тим, яка версія модулів використовувалася для створення конкретних результатів.
5. Що стосується програмного забезпечення, то мені пощастило із Subversion. Налаштування та адміністрування легко. Я визнаю привабливість новомодних розподілених ДКС, таких як git та mercurial, але я не впевнений, що є сильні переваги, якщо ви працюєте самостійно. З іншого боку, я не знаю жодних негативів щодо їх використання - я просто не працював з ними в середовищі аналізу.

Для повноти, я думав, що надам оновлення щодо прийняття контролю над версіями.

Я вважаю, що контроль над версіями для проектів аналізу сольних даних є дуже корисним.

Я прийняв git як свій головний інструмент контролю версій. Я вперше почав використовувати Egit в Eclipse зі StatET. Зараз я просто використовую інтерфейс командного рядка, хоча інтеграція з RStudio є досить хорошою.

Я розповів про свій досвід налаштування контролю над версіями з точки зору проектів аналізу даних.

Як зазначається у публікації, я виявив, що прийняття контролю за версіями мало багато вторинних переваг у тому, як я думаю про проекти аналізу даних, включаючи уточнення:

• відмінність між вихідними та похідними файлами
• характер залежностей:
  • залежності між елементами коду
  • залежності між файлами в рамках проекту
  • і залежності з файлами та програмами, що знаходяться поза сховищем
• характер сховища та спосіб поділу сховищ
• характер вчинення та документування змін та важливих етапів проекту

Я займаюся економічними дослідженнями, використовуючи R та LaTeX, і я завжди ставлю свою роботу під контроль версій. Це як би необмежено скасувати. Спробуйте Bazaar, це один з найпростіших у навчанні та використанні, і якщо ви працюєте в Windows, він має графічний інтерфейс користувача (TortoiseBZR).

Так, є додаткові переваги щодо контролю версій під час роботи з іншими, але навіть у сольних проектах це має багато сенсу.

Зараз ви, мабуть, вважаєте свою роботу як розробку коду, який буде робити те, що ви хочете. Після того, як ви приймете використання системи контролю за версією, ви вважатимете свою роботу про те, як записати спадщину у сховище та внести в неї блискучі додаткові зміни. Це відчуває себе краще.

Я б все-таки рекомендував керувати версіями для сольного вчинку, як ви, тому що мати мережу безпеки для лову помилок може бути чудовою справою.

Я працював як сольний розробник Java, і досі використовую керування джерелами. Якщо я постійно перевіряю речі, я не можу втратити більше години роботи, якщо щось піде не так. Я можу експериментувати і рефактор, не хвилюючись, тому що, якщо це піде не так, я завжди можу повернутись до моєї останньої робочої версії.

Якщо це стосується вас, я рекомендую використовувати джерело управління. Це не важко навчитися.

Ви повинні використовувати програмне забезпечення для управління версіями, інакше ваш аналіз не буде повністю відтворюваним.

Якщо ви хочете десь опублікувати свої результати, ви завжди повинні мати можливість реконструювати стан своїх сценаріїв у той момент, коли ви їх створили. Скажімо, один з рецензентів виявляє помилку в одному зі своїх сценаріїв: як би ви дізналися, які результати виконані, а які - ні?

У цьому сенсі системи резервного копіювання недостатньо, оскільки вона, ймовірно, робиться лише один раз на день, і вона не застосовує мітки до різних резервних копій, тому ви не знаєте, які версії відповідають результатам. І вивчити vcs простіше, ніж ви думаєте, якщо навчитися додавати файл і як здійснювати зміни, то вже достатньо.

Чи варто контролювати версії, докладаючи зусиль?

великий ТАК.

Які основні плюси та мінуси прийняття контролю над версіями?

плюси: ви можете відстежувати, що ви робили раніше. Особливо корисно для латексу, оскільки вам може знадобитися старий абзац, який ви видалили! Коли у вас виходять з ладу комп'ютер або ви працюєте на новому, ваші дані повертаються на льоту.

мінуси: вам потрібно зробити деякі налаштування.

Яка хороша стратегія для початку роботи з контролем версій для аналізу даних з R (наприклад, приклади, ідеї робочого процесу, програмне забезпечення, посилання на посібники)?

Просто почніть його використовувати. Я використовую SVN для черепах у Windows як клієнтський інструмент, і в моєму відділі є сервер svn, я весь свій код і дані я кладу туди (так, ви також туди вводите свої дані!).

Спочатку відступимо трохи раніше та дізнаємося переваги написання пакетів R! Ви кажете, що у вас є проекти з декількома тисячами рядків коду, але вони не структуровані та не задокументовані, як пакетний код? Ви отримуєте великі виграші, відповідаючи ідеалам пакету, включаючи документацію для кожної функції, тести на багато звичайних важких помилок, можливість написання власних тестових наборів тощо.

Якщо у вас немає дисципліни для виготовлення пакету, я не впевнений, що у вас є дисципліна, щоб зробити належний контроль перегляду.

Я погоджуюся з настроями вище і кажу, що так, контроль версій є корисним.

Переваги;

• зберігайте свої дослідження, а також створюйте резервні копії, (маркування)
• це дозволяє вам спробувати різні ідеї і повернутися назад, якщо вони не працюють (розгалуження)
• Ви можете поділитися своєю роботою з іншими людьми, і вони можуть поділитися своїми змінами з вами (я знаю, ви цього не вказали, але це здорово)
• Більшість систем управління версіями спрощують створення стислих пакетів для всіх файлів, які перебувають під контролем у певний момент, наприклад, у точці, коли ви подаєте статтю для публікації, це може допомогти, коли інші переглядають ваші статті. (це можна зробити вручну, але навіщо складати ці процеси, коли управління версіями просто робить це)

Що стосується наборів інструментів, я використовую Git , а також StatEt та Eclipse, які добре працюють, хоча вам, звичайно, не доведеться використовувати Eclipse. Є кілька плагінів Git для Eclipse , але я зазвичай використовую параметри командного рядка.

Версія Контроль для сольної розробки (будь-якого виду) справді цікава для:

• вивчаючи історію та порівнюйте поточну роботу з минулими комітетами
• розгалуження та спробу різних версій для одного і того ж набору файлів

Якщо ви не бачите, що ви робите одну з цих двох основних функцій контролю версій, простий інструмент резервного копіювання може бути всього, що вам потрібно.
Якщо у вас є необхідність у цих функціях, ви також отримаєте резервну копію ( git bundleнаприклад,)

Я також займаюся сольними сценаріями, і я вважаю, що це робить речі простішими, а не робить їх складнішими. Резервне копіювання інтегровано в робочий процес кодування і не вимагає окремого набору процедур файлової системи. Час, необхідний для вивчення основ будь-якої системи управління версіями, безумовно, буде добре витраченим часом.

Dropbox має "версію для чоловіків", що забезпечує вам частину шляху до невеликих зусиль з великою кількістю додаткових переваг.