Wednesday, December 11, 2013

Movember 13: итоги

Несколько запоздалый пост о том, как для меня прошел этот Усабрь.

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

За месяц мною было собрано 65 $ в поддержку исследований рака простаты и яичка и некоторое количество лайков на Фейсбуке :). Не слишком много, но я почти взял поставленную себе в начале месяца планку. Не хватило буквально нескольких баксов.

В конце месяца мы провели скромную вечеринку. Спасибо моему коллеге Кириллу и моему другу Паше за компанию. Остальным не спасибо за то, что спрыгнули :).

Усы я решил продолжать растить, по крайней мере, еще некоторое время.

Movember 13 wrap-up

Wednesday, October 30, 2013

Movember 13

Movember 13

Сегодня будет пост на отвлеченную тему.

В этом году я намерен принять участие в Movember и приглашаю всех присоединиться. Movember - это благотворительная акция, которая длится весь ноябрь. Ее цель - привлечь внимание к проблемам мужского здоровья. А именно, к таким заболеваниям, как рак простаты, рак яичка, и к нарушениям психического здоровья среди мужчин.

Суть проста: 1 ноября мужчины, участвующие в акции - Mo Bros, - гладко бреются и потом в течение всего ноября растят и ухаживают за своими усами (moustache + November = Movember). Женщины тоже могут участвовать в акции, но растить усы от них не требуется. Подробности и правила есть на официальном сайте акции (несколько больше информации в американской версии). Достаточно просто носить целый месяц усы и распространять информацию о кампании, но те, кто готов пойти немного дальше, регистрируются на сайте и собирают пожервования в фонд Movember. В случае нашей страны действует программа Movember Worldwide, и о том, куда пойдут собранные средства, можно почитать на соответствующей страничке.

Так что милости прошу всех присоединяться хотя бы растить усы. Буду безмерно благодарен, если вы пожертвуете через мой профиль хоть какие-нибудь средства, но даже простой репост, лайк или комментарий уже будут значительным вкладом. Я же начал с того, что пожертвовал сам себе 15 $. Ну а если кто-то готов поддержать меня в нелегком деле выращивания усов, я буду особенно этому рад. Я не нашел никакой информации о том, участвует ли кто-то еще в Минске в Movember, пишите напрямую мне. Попробуем собрать компанию, чтобы вместе хвастаться своими усами, а в конце месяца отметить окончание Movember вечеринкой, как того требует традиция.

Change the face of men's health with Mo.

Wednesday, October 16, 2013

Материалы выступления на Rolling Scopes #5

Возможно, кто-то еще помнит, что 2 октября я выступал на митапе Rolling Scopes #5. Отчетный пост несколько задержался, потому что некоторое время пришлось ждать, пока будет готово видео, и только сегодня я понял, что оно уже четыре дня как доступно на YouTube-канале сообщества.

Темой доклада были жизненный цикл директив в AngularJS и работа с ними на этапе создания. Помимо видео и слайдов есть и примеры на Гитхабе. Примеры очень простые, но они наглядно пошагово демонстрируют, как можно создавать директивы.

Ссылки

Слайды

Видео

Wednesday, September 25, 2013

Анонс выступления на The Rolling Scopes #5

2 октября я буду рассказывать на The Rolling Scopes о жизненном цикле директивы в AngularJS. Приходите послушать.

Monday, September 23, 2013

Почему "камбан", или краткое введение в японскую письменность


В своих постах я употребляю название известной техники управления в форме "камбан", с буквой "м" в середине слова. Несколько человек задали мне вопрос, почему же "камбан", если мы привыкли писать и говорить "канбан", и я подумал, что было бы не лишним пояснить.

Слоговая азбука японского языка

Как многим известно, японское письмо - иероглифическое, оно имеет название "кандзи", и в нем один символ, как правило, соответствует целому слову (или, по крайней мере, лексической единице). Однако, помимо иероглифов в японском есть и азбука, которая называется "кана" и, в отличие от привычных нам кириллицы и латиницы, является слоговой. Это значит, что каждый знак (буква) в ней соответствует не отдельному звуку, а целому слогу. Примеры: ва - две буквы, два звука - [в] и [а], соединенные в слог [ва]; ワ - тот же самый слог [ва], те же два звука [в] и [а], но изображается одним знаком.

Это уже кажется довольно странным, но японцы на этом не остановились. Кана существует в двух видах: катакана и хирагана. Они отличаются только написанием знаков и ситуациями, в которых используются, и больше ничем. Первая используется в основном для записи иностранных и заимствованных слов. Вторая - для записи изменяемых частей слов. Вдобавок к этому хираганой пользуются те, кто плохо знает кандзи, а именно дети, безграмотные и иностранцы. Кана нам поможет понять, откуда взялся камбан.

Системы транслитерации

Слово "камбан" имеет в японском два смысла. В первоначальном значении - это магазинная вывеска, шильда, и в этом случае оно записывается с помощью кандзи (как на картинке вверху). Привычный нам камбан из сферы управления проектами японцами всегда записывается катаканой: カンバン. Этим подчеркивается, что значение слова отличается от первоначального. Кстати говоря, работники Тойоты записывают слово исключительно хираганой: かんばん, и никогда такое написание не применяется за пределами компании. Ниже я буду обращаться к варианту с катаканой.

Давайте внимательно посмотрим на само слово. Буква ン в нем повторяется дважды. Лингвисты называют ее "мораическое н" (не спрашивайте у меня, что это значит), и это единственный слог каны, который состоит из одного согласного звука. В большинстве ситуаций он похож на наш звук [н]. Выходит, что "канбан" - правильный вариант, а я просто себе что-то придумал? Не совсем так. Да, в большинстве ситуаций ン действительно звучит как [н], но не во всех.  Дело в том, что перед согласными [б] и [п] эта буква произносится как [м]. Если вы занимались японскими боевыми единоборствами, вам должно быть знакомо слово "сэмпай", в котором присутствует та же самая буква ン. На Ютубе есть видео, в котором японец объясняет произношение слова "камбан", и слышно, что он произносит слово именно через [м].

Возникает логичный вопрос, откуда же взялся "канбан"? Во всем виноваты системы транслитерации. Существует несколько вариантов транслитерации японского латинским алфавитом, самый популярный из которых - система Хэпберна. Он встречается повсеместно, даже в Японии, хотя и не является стандартом. Именно по системе Хэпберна слово "камбан", записанное латиницей, будет выглядеть как "kanban".

Что же в русском?

В русском языке существует официально принятая система Поливанова. Согласно этой системе верно было бы писать "камбан". Однако, под влиянием того, что в последнее время подавляющее большинство японских слов попадают к нам через Америку, и того, что подавляющее большинство людей не утруждают себя тем, чтобы говорить грамотно (включая профессиональных журналистов), в русском языке появляются "суши" и "митсубиши". По сути, имеет место попытка прочтения японского слова, записанного по-английски, согласно английским правилам чтения, т.е. его искаженного английской фонетикой варианта. Получается этакий испорченный телефон произношения.

К слову сказать, подавляющее распространение системы Хэпберна, вызвано, скорее, историческими причинами (оккупацией Японии Штатами после Второй Мировой), нежели лингвистическими. Поэтому я бы не рекомендовал на нее ориентироваться вообще.

Так как будет правильно?

В русском языке есть огромное количество японских слов. Многие из них пришли к нам довольно давно. Например, ниндзя, дзюдо, Хиросима. Никому в голову не придет сказать "нинджа" или "джудо". В моем детстве никто не говорил "митсубиши", говорили "мицубиси". Видимо, из-за того, что в те времена гораздо меньше людей знали английский, а потому вынуждены были говорить по-русски. Однако, вместе с тем есть слова - среди них чаще недавние заимствования - которые прочно закрепились в языке в их английском произношении: суши, джиу-джитсу, гейша. И если суси еще можно встретить в употреблении, то если я скажу "дзюдзюцу" или "гэйся", меня никто не поймет.

С другой стороны, в том же русском есть слова, которые традиционно не подчиняются официальному правилу: Киото (должно быть Кёто), Токио (Токё), Иокогама (Ёкохама). Поэтому я придерживаюсь следующей точки зрения.

Я буду продолжать говорить и писать камбан и суси, пока это соответствует правилу, тем более, что такой вариант фонетически ближе к оригиналу. Однако мы говорим все-таки на русском, а не на японском, и если традиционно в русском прижились канбан и суши, в том, чтобы их использовать, нет ничего криминального. Главное - не искажать слова, которые уже существовали в языке (как "Мицубиси") и грамотно произносить незнакомые.

Monday, September 16, 2013

Личное планирование с помощью камбана, Скрама и Trello

Вопрос личной продуктивности волнует многих

Мне всегда казалось странным, что для эффективного планирования собственного времени нужно прочесть учебник или посетить тренинг. В основе известных мне техник планирования лежат разумные идеи, но многим из них свойственна неоправданная громоздкость. Тут тебе и разбиение задач на 100500 типов, и ведение кучи списков на все случаи жизни... Планирование превращается в процесс, который требует отдельного планирования. Я придумал для себя достаточно простую, на мой взгляд, систему, которой и хочу с вами поделиться.

Основные принципы

Идея системы возникла благодаря Trello - сервису "организации всего". В основе сервиса лежит обыкновенная доска-камбан. На доске можно создавать сколько угодно списков (столбцов), а контроль процесса сводится к перетаскиванию карточек из одного списка в другой или вверх-вниз по списку (удобный drag-n-drop прилагается). Сервис похож на многие другие инструменты планирования, но с той лишь разницей, что он не перегружен излишней функциональностью. Предельно просто и крайне удобно. Вдобавок, он доступен на любой платформе, включая мобильные, и бесплатен (платные функции вам точно не понадобятся, они ориентированы на корпоративное использование).

Я сформулировал для себя несколько ключевых правил, которые позаимствовал из некоторых известных техник Agile:
  1. Единый бэклог для всех задач. Размер, тип или важность не имеют значения.
  2. В начале дня задачи на текущий день переносятся в список "Сегодня".
  3. В конце дня все незавершенные задачи отправляются обратно в бэклог, все завершенные попадают в "Done".
  4. Любые идеи, которые могут стать задачами, фиксируются тут же на доске. Для это существует специальный список "Котел".
И добавил несколько исключений:
  1. Только задачи, которые растягиваются на несколько дней, могут оставаться в "Сегодня" в конце дня, тем самым напоминая мне, что я над ними активно работаю. Их, как правило, не больше одной одновременно.
  2. Для долгосрочных проектов по мере необходимости создаются отдельные задачи наподобие "Работа над проектом, 3 часа".
  3. Для выходных удобно иметь дополнительный список "Завтра". Он упрощает планирование сразу на оба дня, которые можно рассматривать как единый интервал времени. 

Доска для личного планирования
Пример доски для личного планирования

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

Замечания

Пожалуй, стоит вкратце пояснить, почему система оказалась для меня достаточно эффективной.

Удобный интерфейс побуждает к использованию

Удобство интерфейса и доступность Trello сыграли не последнюю роль в создании моего способа планирования. Раньше я пытался использовать для этих целей Evernote, OneNote, Outlook и Гуглокалендарь. У каждого из них были свои существенные недостатки. Бумажный блокнот я даже не рассматривал: я практически никогда не заглядываю в свои записи второй раз.
Бэклог продукта © www.informit.com
Бэклог продукта © www.informit.com

Бэклог

Все задания лежат в одном общем большом списке. Эту идею я почерпнул из Скрама. Большой список позволяет масштабировать видимость задач: важное и срочное находится вверху и легко заметно, менее важное внизу, и чтобы его увидеть, нужно пролистать список. Чтобы поддерживать бэклог в актуальном состоянии, его время от времени нужно просматривать и расставлять задачам приоритеты, что заключается простом в перетаскивание карточек снизу вверх. Это достаточно тривиальное задание, учитывая, что нет необходимости планировать временные рамки: задачи берутся сверху списка по мере необходимости.

Сегодня

По сути, это бэклог спринта длинной в день. Вечером я перетаскиваю задачи из бэклога в To do, примерно прикидывая, что я успею сделать завтра.

Done

Все, что сделано, тут же попадает в Done. Что не сделано, в конце дня отправляется в бэклог, за некоторыми исключениями, которые я описал выше. Это позволяет мне концентрироваться на том, сколько я сделал, а не на том, сколько я не успел (как было бы со списками дел на день-неделю-месяц), что довольно неплохо мотивирует. Перед тем, как планировать следующий день, Done очищается (т.е. все карточки в списке архивируются).

Долгосрочные задачи

Мне нужен был простой подход в рамках моей системы, поэтому для долгосрочных задач я начал выставлять крайний срок (Trello позволяет это сделать). В какой-то момент при пересмотре приоритетов я просто перевожу их вверх бэклога. Таким образом регулируется срочность задач.

Крупные проекты

Здесь тоже все максимально просто. Когда я считаю, что пора уделить проекту внимание, я просто создаю задачу в духе "Работа над проектом, 3 часа" и добавляю ее в бэклог на общих основаниях. Когда я берусь за эту задачу, я включаюсь в проект, и если для него ведется отдельное планирование, пользуюсь уже им.

Все в одном месте и под рукой

Пожалуй, это единственное правило в дополнение к идее ничего не держать в голове, которое я почерпнул из известных методик личного планирования. Логика предельно проста: когда списков больше одного или когда до них сложно добраться, достаточно скоро просто перестаешь в них заглядывать.

Все без исключения

Я добавляю в бэклог абсолютно все: бытовые дела, рабочие вопросы, личные проекты - все, что требует хоть малейшего усилия воли, чтобы начать это делать. Отчасти, я делаю так из-за предыдущего пункта. Отчасти, потому что я пришел к выводу, что гораздо проще и эффективнее приоретизировать общий список, не разбивая его на части. А отчасти, потому что на силу воли полагаться нельзя вообще ни в чем. Более того, когда я вижу в конце дня в Done список из 5-6 задач, пускай даже некоторые из них были не особенно важны, это помогает мне формировать привычку воспринимать себя как человека, способного к действию.

Saturday, August 31, 2013

Скрам: "это не то, что ты думаешь!"

Поводом к написанию поста стал недавний спор с коллегой о том, отличаются ли доски в Скраме от камбана. Для коллеги оказалось сюрпризом, что в Скраме нет ничего про доски.

Цена простоты

Жрец синто и актер играют в го
Когда простота может быть сложной
Agile вошел в моду, можно сказать, стал мейнстримом. Сегодня даже статистика на стороне гибких подходов, и все хотят себе в проект волшебный Скрам. Это привело к тому, что вокруг него сложилась странная ситуация: простота и, как следствие, популярность играют с ним злую шутку. Скрам продемонстрировал, как простыми методами можно решать сложные задачи. В этом его очевидная заслуга. С другой стороны,  появились "специалисты", которые восприняли это как право заявлять "я все знаю", всего лишь прочитав пару статей в Интернетах (многие из которых написаны такими же "специалистами"). Очень часто я слышу, как люди обсуждают Agile, путая его со Скрамом, при этом и о том, и о другом имеют весьма туманное представление.

Скрам очень прост по своей сути, но простые правила не всегда означают простой процесс. И чтобы получать от процесса максимум, нужно досконально знать правила. Безусловно, гибкость должна быть гибкой, но я настаиваю, что доскональное знание правил не имеет ничего общего с бюрократией. Всегда нужно понимать границы собственной компетентности. В процессе обучения мы проходим три стадии совершенствования (о чем говорит горячо любимый Алистэром Коуберном принцип сюхари). Попытки стартовать сразу с третьего уровня почти всегда приводят к плачевным последствиям. Некий небезызвестный манифест фактически постулирует, что нет никаких правил кроме здравого смысла, и это одно из самых ценных его утверждений, но здравый смысл возможен только там, где существует понимание границ собственной компетентности, что, судя по всему, встречается нечасто.

От философии к реальности

Гид по Скраму содержит всего 18 страниц. Это неприлично мало для подобного документа, и именно поэтому важно его знать и ему следовать. Эти 18 страниц - ядро, содержащее только самое необходмиое, ключевые принципы, благодаря которым Скрам работает в реальности. Парадокс в том, что большинство вещей, по которым идентифицируется Скрам, к Скраму не имеют отношения, и появление многих из них со Скрамом вообще не связано. К примеру, доски с карточками - изобретение канбана, которое просто удобно использовать во многих ситуациях, не только на скрам-борде.

Как камбановские карточки, зачастую подобные вещи - это некие заимствованые практики, которые глупо было бы игнорировать, но без которых вполне можно справиться, если найти им  равноценную замену. Практики можно и нужно изменять под свои нужды. Ядро изменять нельзя (конечно, только пока вы не достигли "ри", как Коуберн), потому что это основа процесса, его фундамент. Если не следовать принципам, описанным в ядре, бессмысленно говорить о применении Скрама, и в этом случае никто не сможет ответить на вопрос, почему что-то пошло не так, когда что-то пойдет не так. Покупателя, который залазит внутрь изделия, производитель закономерно лишает гарантии, потому что покупатель делает это на свой страх и риск и теперь только он знает, в каком состоянии находится изделие.

Важно понимать, что Скрам - это инструмент, который выполняет определенный круг задач (менее широкий, кстати, чем многие себе представляют). Непонимание того, что является ключевым для работы Скрама, и что выходит за рамки сферы его ответственности, приводит к формированию завышенных ожиданий, а завышенные ожидания - это верный путь к неудовлетворенности. В конечном итоге, Скрам - это каркас, фреймворк, и это особенно подчеркивают его авторы. Скрам призаван помочь команде быть продуктивной и создать здоровую рабочую атмосферу, но работать в конечном итоге все равно придется людям.

Myth Busted

Поэтому, чтобы не попасть в ловушку ложных представлений, важно понимать следующее.

Скрам - каркас, а не полновсеная методология.

Все об этом слышали, но мало кто действительно осознает, что это значит. Скрам задает каркас для процесса, и процесс придется найти себе самим путем проб и ошибок. Зато это будет ваш родной процесс, который лучше всего подходит именно вам. Вся суть Скрама именно в том, чтобы заставить команду найти свой собственный путь и дать ей для этого необходимые средства.

Скрам содержит только самое важное.

Josse Basso #8
Ничего лишнего
Авторы методично убрали из Скрама всю шелуху, оставив только действительно самое важное, эффективное и простое для понимаиня. Имейте четкое осознание, что когда вы от чего-то отказываетесь, вы отказываетесь от ключевого, потому что не ключевое уже было исключено. Если за вашими плечами двадцатилетний успешный опыт, вероятно, вы достигли уровня, когда лучше других знаете, что вам нужно (впрочем, гарантий нет), и сможете эффективно менять даже эту ключевую часть. Но до тех пор - забудьте. Положитесь на опыт Швабера и Сазерленда - ребята не дураки.

Цель Скрама - продуктивность и прозрачность

Основная задача Скрама - создание продуктивной открытой атмосферы, когда каждый на своем месте и делает, что у него выходит лучше всего: PO разрабатывает стратегию, команда производит продукт, а скрам-мастер делает жизнь людей вокруг лучше, и все при этом работают ради достижения общей цели. Помогая решить этот вопрос, Скрам открывает команде возможности для совершенствования во всех остальных областях деятельности, и это становится ответственностью самой команды. В частности, Скрам не говорит, как писать хороший код или как поддерживать качество продукта - не ждите от него этого. Скрам не содержит встроенных средств для решения проблем, только средства для идентификации (что, впрочем, уже немало). Понимайте, что вы получите от Скрама из коробки, а что придется понять и сделать самостоятельно.

Самое известное о Скраме вообще не Скрам

В Скраме нет стори-поинтов, нет берндаун-чартов, нет досок с колонками и прочих подобных прелестей. Все это - популярные практики, которые хорошо показали себя в работе, но они никогда не были частью Скрама. Они пришли из других методологий либо возникли как инструмент сами по себе, поэтому не стоит думать, что если вы завели скрам-борд в Джире, то таким образом автоматически делаете Скрам. Скрам про открытую коммуникацию, продуктивную атмосферу и доверие - отнюдь не про доски и эстимейты. Мы настолько привыкли видеть все эти понятия рядом, что они нам кажутся неотъемлемой частью Скрама, но это не так. Если в этом есть смысл, можно найти свои методы для всех этих задач, и Скрам только призывает к поиску. Впрочем, глупо было бы отказываться от накопленного годами опыта.

В заключение

К чему этот долгий разговор о том, чего Скрам не может? Я хочу, чтобы вы четко представляли, что молоток - это не швейцарский армейски нож: шуруп им не закрутишь и бутылку вина не откупоришь. Ошибки по причине невежеста - худшие в этом мире и не заслуживают снисхождения. Не будьте невеждами: начните с прочтения скрам-гайда - там немного. Избегайте необоснованных ожиданий. Имейте понимание того, что такое Скрам, каковы его возможности, и где их граница, чтобы представлять, где понадобится "помощь со стороны".

Напоследок, в поддержку моего мнения то же самое, но более кратко, словами Алистэра Коуберна.

Sunday, July 28, 2013

Миграция из TFS в SVN

Зачем?

Те, кто хочет побыстрее приступить к делу, могут перейти сразу к пункту «Процесс миграции».
Недавно пришлось заниматься такой странной вещью, как миграция репозитория из TFS в SVN. На то были веские причины: начиная от Микрософстовского лицензирования®, которое ограничивало нас в возможности настроить CI на проекте, и заканчивая неприятными особенностями, которые просто жутко бесят в повседневной работе. Например, тем, что TFS самостоятельно навешивает на каждый файл флаг Read Only, что усложняет процесс сохранения в некоторых редакторах. Или тем, что клиент требует постоянного подключения к серверу. Вероятно, переход на Git обрадовал бы меня еще больше, но корпоративные особенности ограничивали выбор. При этом стояла задача сохранить всю историю изменений старого репозитория.

Инструменты

В Интернете достаточно много статей о том, как мигрировать из TFS в SVN. В некоторых предлагаются рабочие способы, в других – достаточно странные. Чаще всего можно найти упоминание о tfs2svn. Его я и попробовал первым. К сожалению, оказалось, что эта утилита довольно древняя, построена на базе старого клиента, и с новым SVN работать отказывается. К тому же, судя по отзывам, она не вполне стабильна, любит вылететь с ошибкой на середине миграции, поэтому пришлось поискать другой способ.
Описание другого способа я нашел в одном блоге, и заключался он в миграции через Git. Этот способ оказался достаточно простым и сработал как часы, но в процессе я наткнулся на несколько подводных камней, которые заставили меня, как не особенно опытного пользователя Git, немного попотеть. Поэтому я и решил подробно описать весь процесс и те трудности, с которыми пришлось столкнуться.

Процесс миграции

Идея миграции состоит в том, чтобы сначала клонировать репозиторий из TFS со всей историей в локальный Git, потом создать в нем репозиторий SVN, сделать rebase ветки master на trunk и результат залить в SVN. История при этом сохраняется полностью.
Есть, правда, у этого способа одна особенность: все изменения в SVN будут зафиксированы от имени единственного пользователя, который непосредственно будет производить коммит в SVN (т.е. от вашего имени). Я в этом не вижу никакой проблемы, хотя некоторые считают, что для кого-то это может стать препятствием.
Итак, сам процесс по шагам выглядит примерно так.
  1. Установка Git-TF В качестве моста с SVN подойдет стандартный git-svn. Для работы с TFS понадобится установить стороннее средство. Предлагалось воспользоваться git-tfs, но оказалось, что он не работает с сервером TFS 2012. Вместо него, однако, нашелся Git-TF, который мало того, что рекомендуется Микрософтом, но и не требует установленного Team Explorer. Насколько я могу судить, он должен нормально работать и с более старыми серверами: 2007 или 2010.
  2. Клонирование TFS в локальный Git. Здесь важно выполнить команду с параметром --deep, иначе клонируется только последний changeset, а нам нужна вся история. Пример команды выглядит так:
$ git tf clone http://tfs.server.com:8080 "$/Path/To/Your/project" ./tfs-migration --deep

Connecting to TFS...
Username: username
Password:
Cloning $/Path/To/Your/project into D:\Projects\temp\tfs-migration: 100%, done.
Cloned 446 changesets. Cloned last changeset 794995 as d147076
  1. Инициализация SVN в локальном репозитории. Следующим шагом нужно инициализировать в только что созданном клоне рабочую копию SVN. Не забудьте перейти в нужную папку:
$ cd tfs-migration/
$ git svn init -s https://svn.server.com/svn/target_repo/

  1. Обновление. Прежде чем приступить непосредственному перемещению изменений, нужно привести в актуальное состояние рабочую копию. Делается это с помощью команды fetch. Она обновить локальную папку и выведет в консоль хэши всех скачанных ревизий.
$ git svn fetch

r1 = 4862c0c6fd9b392e66595f8bb6f8b742106596ba (refs/remotes/trunk)
r2 = fdaaffc0568606b9bccd135d44ed42d1e703951a (refs/remotes/trunk)

  1. Сам ритуал! Теперь нужно произвести rebase из основной ветки нашего гита, куда TFS сложил все свое добро, в trunk. Это команда, как мы знаем, последовательно применит все изменения из одной ветки к другой ветке, начиная  с указанной ревизии. Указать правильную ревизию – важный момент в этом шаге. Я потратил достаточно много времени, пытаясь понять, почему вместо необходимой операции Git чистит мне репозиторий. rebase нужно делать на последнюю доступную ревизию. Хэш проще всего получить из вывода предыдущей команды – взять тот, который был выведен в списке последним (значение r2 в данном случае).
$ git rebase --onto trunk fdaaffc master

First, rewinding head to replay your work on top of it...
Applying: Initial check-in of the project
Applying: Added launch config
Applying: Separated RootController from deprecated / removed base class
Applying:
Applying: updated collection set rank options - they were out of sync
...

  1. Заключительный шаг – коммит. Осталось только отправить изменения на сервер. Этот этап занимает наиболее значительную часть времени и у меня на небольшом проекте длился несколько часов. К счастью, он не требует постоянного контроля, и даже если процесс прервется (например, отвалится соединение с сервером, как это произошло у меня), команду можно будет повторить.
$ git svn dcommit

Committing to https://sami.cdt.int.thomsonreuters.com/svn/nt_newsroom/trunk ...
        A       .tpignore
        A       pom.xml
        A       src/main/java/META-INF/webapp/WEB-INF/css/main.css
...
Committed r446
        M       src/main/java/META-INF/webapp/WEB-INF/js/core.js
r446 = 25b8eea5e33d5b1c25a2c44e3035470cc51716da (refs/remotes/trunk)
No changes between d7aff0968e1def1234215622581db9df35d7e528 and refs/remotes/trunk

Resetting to the latest refs/remotes/trunk

Вот и все. Теперь можно наслаждаться SVN со всей историей проекта.

Saturday, July 27, 2013

Starting off, explaining things

Идея этого блога родилась в те далекие времена, когда в первичном бульоне, подогреваемом в космическом котле дыханием вечного дракона времени, в соответствии с божественным планом формировались первые сложные аминокислоты...
В реальности все было несколько проще: однажды я понял, что опыта и знаний, которыми можно поделиться с миром, у меня уже достаточно, поэтому вот он – результат – перед вашими глазами.
Я долго думал, вести ли блог на русском или английском. С одной стороны, большинство моих потенциальных читателей говорят по-русски, с другой – люди редко ищут в Интернете что-то полезное не по-английски. Определиться я так и не смог, поэтому решил, что языков будет два – под настроение.
Как следует из описания блога, в основном я собираюсь писать о разработке ПО и об Agile, т.е. о том, что мне особенно интересно. С тех пор, как я впервые начал работать в отрасли, я успел побывать в роли разработчика на C#, Java и даже инженера техподдержки (и это, скажу вам, был довольный позновательный опыт, которого недостает многим программистам). Сегодня я работаю на JavaScript, по совместительству являюсь скрам-мастером, а на досуге интересуюсь Ruby.
В общем, жду всех в гости: читайте и комментируйте. Будет интересно.