Как Вы комбинируете “Управление версиями” с “Рабочим процессом” для R?
Я не забываю сталкиваться с пользователями R, пишущими, что они используют "Управление версиями" (например: "Управление исходным кодом"), и мне любопытно знать: Как Вы комбинируете "Управление версиями" со своим рабочим процессом статистического анализа?
Два (очень) интересных обсуждения говорят о том, как иметь дело с рабочим процессом. Но ни один из них не обращается к элементу управления версиями:
Долгое Обновление Вопроса: После некоторых ответов людей, и вопрос Dirk в комментарии, я хотел бы направить свой вопрос немного больше.
После чтения статьи Wiki об "управлении версиями" (с которым я был ранее не знаком), мне было ясно, что при использовании управления версиями, что каждый делает, должен создать структуру разработки его кода. Эта структура или приводит к "конечному продукту" или к нескольким ответвлениям.
При создании чего-то как, скажем, веб-сайт. Обычно существует один конечный продукт, которого Вы работаете для (веб-сайт) с некоторыми прототипами по пути.
Но при выполнении статистического анализа, работа (к моему представлению) отличается. Иногда Вы знаете, где Вы хотите добраться до. Но чаще, Вы исследуете. Исследуйте очистку набора данных. Исследуйте различные методы для статистического анализа и задайте различные вопросы своих данных (и я пишу это, зная, как Frank Harrell и другие статистики опыта чувствуют о выемке грунта Данных).
Именно поэтому вопросом о рабочем процессе со статистическим программированием является (по моему мнению), серьезный и глубокий вопрос, поднимая много вопросов, более простые являются техническими:
- Какое программное обеспечение управления версиями Вы используете (и почему)?
- Который IDE Вы используете (и почему)? Более интересный вопрос о процессе работы:
- Как Вы структурируете свои файлы?
- Что Вы сохраняете как отдельный файл и что как пересмотр? или спрашивая по-другому - Каково должно быть "ответвление" и каков должен быть "подпроект" в Вашем коде? Например: начиная исследовать Ваши данные, график должен создавать и затем стертый, потому что это не привело никого, где (но сохраненный как пересмотр) или должен там быть файл резервной копии того пути?
То, как Вы решаете эту силу, было моим начальным любопытством. Второй вопрос, "что я мог бы пропускать?". За какими правилами (ползунка) нужно следовать так для предотвращения распространенных ошибок, делающих статистическое программирование с управлением версиями?
В моей интуиции я чувствую, что статистическое программирование по сути отличается затем разработка программного обеспечения (я пишу это, не будучи настоящим экспертом в статистическом программировании, и еще меньше в разработке программного обеспечения). Это - способ, которым я не уверен, какой из уроков я считал здесь об управлении версиями, было бы применимо.
Большое спасибо, Tal
5 ответов
Мой рабочий процесс ничем не отличается от рабочего процесса Бернда. Обычно у меня есть главный каталог, куда я помещаю все свои файлы кода * .R. Как только у меня в текстовом файле больше 5 строк, я запускаю контроль версий, в моем случае git. Большая часть моей работы не связана с командным контекстом, что означает, что я единственный, кто меняет свой код. Как только я вношу существенное изменение (да, это субъективно), я проверяю его. Я согласен с Дирком в том, что этот процесс ортогонален рабочему процессу.
Я использую Eclipse + StatET, и хотя в Eclipse есть плагин для git ( EGit и, возможно, другие), я его не использую. Я в Windows и просто использую git-gui для Windows. Вот еще несколько вариантов .
В управлении версиями есть много места для личных идиосинкразии, но я рекомендую этот совет как лучшую практику: если вы сообщаете о результатах другим (например, журнальная статья, ваша команда, руководство вашей фирмы) ВСЕГДА выполняет проверку контроля версий прямо перед запуском результатов, которые будут отправлены другим пользователям. Неизменно через 3 месяца кто-нибудь посмотрит на ваши результаты и задаст какой-нибудь вопрос о коде, на который вы не сможете ответить, если не знаете ТОЧНОЕ состояние кода, когда вы получили эти результаты. Так что сделайте это практикой и добавьте в комментарии «это версия кода, которую я использовал для отчетности за 4-й квартал» или как бы там ни было.
Также имейте в виду, что контроль версий не заменяет хороший план резервного копирования. Мой девиз: «3 экземпляра. 2 географии. 1 ум в мире."
РЕДАКТИРОВАТЬ (24 февраля 2010 г.): Джоэл Спольски, один из основателей Stack Overflow, только что выпустил очень наглядное и очень интересное вступление к Mercurial . Одно только это руководство может быть причиной принять Mercurial, если вы еще не выбрали систему контроля версий. Я думаю, что когда дело доходит до Git и Mercurial, самый важный совет - выбрать одну и использовать ее. Возможно, используйте то, что используют ваши друзья / коллеги, или используйте ту, что с лучший учебник. Но просто используйте его уже!;)
Я использую git для контроля версий. Моя типичная структура каталогов (например, для статей) выглядит следующим образом.
.
..
.git
README
README.html
ana
dat
doc
org
Большинство каталогов / файлов (ana, doc, org) находятся под контролем версий. Конечно, большие двоичные наборы данных исключены из контроля версий (через .gitignore). README - это файл Emacs в организационном режиме.
Вместо того, чтобы сосредоточиться на контроле версий в частности, похоже, вы действительно задаете более серьезный вопрос о том, как статистический анализ сравнивается с разработкой программного обеспечения. Это интересный вопрос. Вот некоторые мысли:
Анализ данных может быть больше похожим на искусство, чем на науку.В некотором смысле вы можете больше искать вдохновения в процессе, которому будет следовать автор при написании книги, чем в процессе, которому будет следовать разработчик программного обеспечения. С другой стороны, мне еще не приходилось сталкиваться с программным проектом, который шел бы по прямой линии. И даже на теоретическом уровне существует большое количество различий в методологиях разработки программного обеспечения . Из них, учитывая, что статистический анализ может быть процессом открытия (то есть тем, который нельзя полностью спланировать заранее), имеет смысл следовать чему-то вроде гибкой методологии (тем более, что что-то как методология водопада). Другими словами, вам нужно спланировать, чтобы ваш анализ был повторяющимся и саморефлексивным.
Тем не менее, я думаю, что представление о том, что статистический анализ является чисто исследовательским, без какой-либо цели, потенциально проблематично. Это может привести к тому, что вы пройдете 5 шагов после момента эврики и не сможете вернуться к нему. Всегда есть какая-то цель, даже если сама цель меняется. Более того, если цели нет, как вы узнаете, что достигли ее конца?
Один из подходов - начать с одного R-файла при запуске проекта (или набора файлов, как в Джоша и Бернд примеры) и постепенно добавляйте к нему (чтобы он увеличивался в размерах) по мере того, как вы делаете открытия. Это также особенно верно, когда у вас есть данные, которые необходимо сохранить как часть анализа. Этот файл следует регулярно проверять версиями, чтобы вы всегда могли отступить, если сделаете ошибки (что позволяет получить дополнительный выигрыш).Системы контроля версий чрезвычайно полезны при разработке не только потому, что они гарантируют, что вы ничего не потеряете, но и потому, что они предоставляют вам временную шкалу. И отметьте свои чекины, чтобы вы сразу знали, что в них происходит, и отметьте основные этапы. Мне нравится замечание JD о проверке перед отправкой чего-либо.
После того, как вы пришли к окончательному набору выводов, часто лучше всего создать окончательную версию вашего файла, которая суммирует ваш анализ от начала до конца. Вы можете даже подумать о том, чтобы поместить это в документ Sweave, чтобы он был полностью автономным и грамотным.
Вам также следует серьезно подумать о том, что делают другие вокруг вас. Ничто не заставляет меня содрогаться больше, чем видеть, как люди изобретают колесо, особенно когда это означает дополнительную работу для всей группы, с которой нужно интегрироваться.
Ваши решения о том, какую систему управления версиями использовать, какую IDE и т. Д. (Проблемы реализации), в конечном итоге крайне не важны по отношению к общему управлению проектом. Просто используйте любой один из них должным образом, и вы уже пройдете 95% пути, и разница между ними невелика по сравнению с альтернативой ничего не использовать.
Наконец, если вы используете что-то вроде github, google code или R-forge, вы заметите нечто общее: набор инструментов, выходящий за рамки простой системы контроля версий. А именно, вам следует подумать об использовании таких вещей, как система отслеживания проблем и вики, для документирования прогресса и регистрации открытых проблем / задач.Чем более организован ваш анализ, тем выше вероятность успеха.
Я сам использую git. Локальные репозитории, хранящиеся в том же каталоге, что и проект R. Таким образом, если я удалю проект в будущем, репозиторий уйдет вместе с ним; Могу работать в автономном режиме; и у меня нет проблем с IRB, FERPA, HIPPA.
Если мне нужно добавить гарантию резервного копирования, я могу перейти в удаленный (защищенный!) Репозиторий.
-Wil
Если разбить диапазон индекса на неперекрывающиеся диапазоны, как вы предлагали, то при условии, что массив создается в общей памяти (т.е. не каждым потоком), блокировки не требуются.
Реализации -121--4746196-MPI не проверяют и не интерпретируют фактическое содержимое сообщения. При условии, что вы знаете размер структуры данных, вы можете представить этот размер в некотором числе символов или int. Реализация MPI не будет знать или заботиться о фактических внутренних деталях данных.
Есть несколько предостережений... отправитель и получатель должны согласовать интерпретацию содержимого сообщения, и буфер, который вы предоставляете на стороне отправки и получения, должен поместиться в определенное количество символов или int.
-121--4817526-После прочтения обновления вам кажется, что выбор и использование системы управления версиями диктуют структуру репозитория и поток операций . По моему мнению, контроль версий больше похож на страховой полис , поскольку он предоставляет следующие услуги:
Резервное копирование. Если что-то случайно удаляется или капризы судьбы обжаривают ваш жесткий диск, вашу работу можно восстановить из хранилища. С распределенным контролем версий, не что иное, как апокалипсис, может привести к тому, что вы потеряете работу, и в этом случае вам, вероятно, придется беспокоиться о других вещах.
Мать всех кнопок отмены. Анализ выглядел лучше час назад? сутки назад? неделю назад? Управление версиями обеспечивает кнопку перемотки, которая позволяет перемещаться назад во времени.
Если вы единственный человек, работающий над проектом, в двух приведенных выше пунктах, вероятно, указано, как системы управления версиями повлияют на вашу работу.
Другая сторона систем управления версиями заключается в том, что они способствуют совместным усилиям, позволяя людям экспериментировать над изолированной копией или "ветвью" материала проекта, а затем "объединять" любые положительные изменения обратно в главную копию.
Например, я держу все учебные курсы колледжа под контролем версии в репозитории Subversion . Я единственный, кто работает с этим хранилищем, поэтому я никогда не ветвлюсь и не объединяю источник - я просто принимаю и иногда перематываю. Способность перемотать назад мою работу снижает риск попробовать какой-то новый анализ - я просто делаю это. Если через два часа кажется, что это была не такая хорошая идея, я просто возвращаю файлы проекта и пробую что-то другое.
В отличие от этого, большая часть моей разработки пакетов/программ, не связанных с курсами, размещается в git . В этом виде настройки я часто хочу экспериментировать на ветви при наличии стабильной главной копии. Я использую git , а не Subversion в этих ситуациях, потому что git делает ветвление и слияние задачей без усилий.
Важным пунктом является то, что в обоих случаях структура моего репозитория и поток операций , которые я использую, не решаются моей системой управления версиями - они решаются мной. Единственное влияние, которое контроль версий оказывает на мой рабочий процесс, это то, что он освобождает меня от беспокойства о попытке что-то новое, решая, что мне это не нравится, а затем приходится отменять все изменения, чтобы вернуться к тому, с чего я начал. Поскольку я использую контроль версий, я могу следовать совету Йоги Берры:
Когда вы придете на развилку в дороге, возьмите его.
Потому что я всегда могу вернуться и пойти в другой путь.