Perforce: edit, add, delete в командной строке

      Всем привет.
      Сегодня наткнулся на интересный способ для автоматического добавления файлов на редакторивание в perforce, пришлось править, и потому решил сразу написать для себя и будущих поколений небольшую подсказку-памятку.
      Задача очень простая. В депоте хранится клиент в распакованном виде, т.е. так как он будет лежать на машине у пользователей. При сборке новой версии нужно переписывать измененные файлы, добавлять новые, и, по-возможности, удалять старые.
      Как раз третий шаг у нас и не выполнялся. Итак, что было?
      Сборка шла по следующим шагам:

1. Удаление локальной версии;
2. Копирование на ее место новой, только собранной версии клиента;
3. Добавление на чекаут измененных файлов;
4. Добавление новых файлов;
5. Коммит изменений на сервер.

      Как видим удаления нет. Некоторое время это было не критично, но вот пришлось править.
      Недолго думая я решил, что после чекаута измененных файлов необходимо вставить код, который будет удалять в депоте файлы, отсутствующие локально. Вроде все просто. Добавил команду, между 3 и 4 шагами, и... обломался. Не было удалено ни одного файла, хотя пару кандидатов на примете у меня было.
      Причина оказалась банальна. На 3 шаге был вот такой вот код:
   
            p4 edit \\depot\client\...
            p4 revert -a -c
       
      Т.е. сначала на редактирование брались тупо все файлы, а потом делался реверт тех файлов, которые не были изменены. Особенность perforce (да наверное и любой другой системы контроля версий ) такова, что при реверте локальный файл восстанавливается. Другими словами, даже если в сборке и не хватало файлов, то после этой команды они восстанавливались из депота и мой шаг по удалению ничего не находил.
      Вот эту штуку и пришлось править. В perforce есть хорошая команда, которая позволяет отобрать уже только измененные файлы и взять на редактирование только их. Она же позволяет находить файлы, которые нужно удалить в депоте.
      После небольшой правки скипт стал выглядеть примерно так:

            echo "DELETE MISSED FILES"
            p4 diff -sd \\depot\client\... | p4 -x - delete
         
            echo "CHECKOUT CHANGED FILES"
            p4 diff -se \\depot\client\... | p4 -x - edit
         
            echo "ADD NEW FILES IN PERFORCE"
            cd /d D:/p4/client
            dir /b /s /a-d | p4  -x - add -f

      Все просто и наглядно.
      Ну а потом делаем коммит на сервер. Референс на все команды perforce можно глянуть тут: http://www.perforce.com/perforce/doc.current/manuals/cmdref/index.html
      Всем доброй ночи.

Анализ дня: недостаток perforce, мобильная разработка на Unity

    Всем привет.
    Сегодня снова две темы дня. И более практических, чем обычно.
    Начнем с Perforce. С этом системой я проработал больше 3-х лет и, за все время, особых нареканий у меня не было. Хотя периодически были проблемы. Так сложилось, что последний год я просидел на паре Svn, Mercurial и только месяц назад пришел на проект, где используется Perforce. База на проекте уже огромная - под сотню гигабайт. Файлы самые разные по размерам, от нескольких байт до пары гигабайт. Самое главное, что их много, очень много. Думаю за полмиллиона уже перевалили.
     Оказалось, что Perforce справляется с таким репозитарием очень туго. Тормозит, появляются ошибки. Например файл регистрируется в базе, но на сервер не попадает. И все, кто пытается обновится, получают предупреждение о том, что файл отсутствует.
     На фоне данной проблемы и вылез, как мне кажется, главный недостаток Perforce по сравнению с остальными системами - Perforce требует подключения к серверу и ответа от сервера для выполнения любой команды. Абсолютно любой.
     Во время работы программист наиболее часто выполняет 3 операции: обновление с сервера, коммит на сервер и чекаут файла. Так вот, если у вас тормозит сервер, то вы можете обновляться и коммитить файлы, пусть и со скрипом. Это не такие частые операции, пару раз в день, а у кого-то и реже. Но вот чекаут файла это жизненно необходимая операция, без нее работать чуть хуже чем никак. SVN берет эту заботу на себя и не требует подключения к серверу, Git и Mercurial вообще не требуют сервера, а вот Perforce требует ответа от сервера.
     Итог грустен: невозможность взять файл на чекаут тупо блокирует работу, срывает настрой и вдохновение.

     Вторая тема более жизнерадостная. Как я уже писал, Unity раздает лицензии на мобильные платформы бесплатно. Я воспользовался возможностью и получил свою лицензию. На выходных начал писать аж две программки для Android. Первая это порт игры Smash Aliens (линк на youtube), а вторая - это программа для тренировок, я назвал ее TrainerBoo.
     В данном случае, можно воспользоваться одним из плюсов Unity и погонять оба моих не доделанных приложения через браузер. Вот Aliens, а вот TrainerBoo.
     Собственно меня теперь волнуют два вопроса:

1. Размер финального приложения - apk файл для Aliens занимает больше 10MB, а для TrainerBoo - больше 6MB (там вообще нет моих ресурсов, только Unity) 
2. Производительность на Unity

     По ходу развития проектов поделюсь тем как ведет себя Unity.

     Всем доброй ночи. 

Kata - ежедневная мантра программиста

    Привет всем.
    Сегодня я хотел поговорить об одном приеме настроя на работу, с которым познакомился во время тренинга по ТДД.
    Я снова взялся за преподавание и неделю назад стартовали занятия в группе по программированию на С++. Еще при работе с предыдущими группами я пришел к выводу, что для начинающих программистов очень полезно писать код, поменьше учить разные паттерны и побольше практиковаться. Писать, отлаживать, снова писать. Со стартом группы я задумался над тем какое-же придумать им мучение упражнение, чтобы они писали код каждый день. Вот и вспомнил об упражнении Ката TDD.
    Что такое ката можно глянуть в вики. Вкратце это просто некий набор движений в боевых искусствах. Изучение на базе ката сводится к повторению этих движений многие тысячи раз.
    Так и здесь. Ката TDD - это задание написать StringCalculator. Выполнять его нужно в начале каждого рабочего дня. Затрачивать на ката от 15 до 30 минут, не более. Задание идет итерациями, добавляя все новые возможности в StringCalculator и здесь важно соблюдать эти итерации. Т.е. даже если вы знаете как написать самый общий код на все случаи жизни, все равно необходимо идти по шагам постепенно наращивая функционал и рефакторя код.
     Учить студентов TDD, естественно я не собираюсь, поэтому не буду и требовать написания кода в стиле TDD. Но даже само по себе это упражнение думаю будет очень полезно.
     Для тех же зубров, которые могут выполнить ката за полчаса, и, кому становиться скучно писать каждый день одно и то же, я могу предложить путь развития ката, который использует сам ее автор. Нужно ставить себе ограничители и дополнительные условия на выполнение. Например: написать ее без использования стандартных библиотек, или с использованием специфических библиотек, написать ее на языке, который хочется выучить, написать ее без использования циклов и т.д. и т.п.
     Чтобы было по-честному я вместе со студентами буду выполнять ката каждый день. Сегодня успел за полчаса сделать только до пункта 3.1. Позор на мою голову.
     На этом пожалуй все.
     Всем доброй ночи.

Анализ дня: книга Continuous Delivery

    Всем привет. После краткосрочного прогула я снова на связи.
    Пару недель назад купил книгу "Непрерывное развертывание" (Continuous Delivery на английском). Времени на чтение от корки до корки так и не нашел, пока прочитал только первую главу. Чтобы все-таки отбить деньги выложенные за книгу, решил немного по-другому к ней подойти. А именно, выписать сначала конкретные вопросы, на которые хочу найти ответы. Ну а после уже читать только те части, которые могут помочь получить ответы. Вопросов смог сформулировать 2 и третий на подходе:

1. Сейчас занимаюсь настройкой CI, поэтому нужно прочитать только соответствующую главу в книге. Глядишь что и приглянется. 
2. Сохранения и развертывание конфигураций и настроек инструментов, среды, системы. В первую очередь речь идет о различных конфигах, которые после чекаута из перфорса должны быть ручками допилены под машину каждого разработчика. 

    Раньше у меня не было проектов с таким диким количеством конфигов. Конфиги клиента, сервера (у каждого разработчика свой сервер), конфиги инструментов и т.д. В результате все это либо висит на чекауте в ченджлисте с именем "don't commit", либо правится локально после снятия флаг read only. Естественно такой подход приводит к тому, что либо конфиг забывают залить когда нужно, либо наоборот заливают когда не нужно. Изысканиями и результатами поделюсь. 

    Кстати а как вы храните конфиги и работаете с ними? 

Анализ дня: С++ и python

    Всем привет.
    Для начала немного рутинной отчетности. День прошел вполне успешно, основная задача на день была реализована.
    Теперь собственно переходим к наиболее интересному. Меня перекинули на новый проект где-то недели три назад, проект очень большой и идет уже больше года. По объективным причинам (т.е. из-за собственной лени и изворотливости) я еще не занимался программированием на проекте. Было больше задач на ресерч, менеджмент и администрирование. А вот сегодня после обеда уперся в то, что нужно садится програмить, причем на Python. Изучить новый язык не проблема. Добыл книгу Марка Лутца "Программирование на Python" и завтра же начну грызть гранит науки.
    Немного смутило меня другое. Несмотря на то, что мой блог называется "Native language C++" я перестал писать на С++ примерно в то время, когда блог был создан. Парадокс. Я помню год назад даже задумался о том, чтобы сменить название. Сейчас я еще раз пришел к той же мысли что и год назад. Не раз озвучивал уже эту идею своим студентам и просто хочу еще раз записать и проговорить ее для себя.
    Я благодарен моей программистской звезде, за то, что начал программировать именно с С++. За все время работы я стал в некоем роде универсалом. Приходилось писать проекты на C#, Java, Perl, Lua, English. Но именно основу полученную во время кодинга на  С++ я считаю залогом достаточного легкого переключения на любой язык и своего поступательного движения вперед.
    С++ действительно стал моим родным языком. Пусть я не пишу и не говорю на нем, но думаю я по прежнему на С++ и он меня еще ни разу не подвел.
    А что вы считаете залогом вашего продвижения, ваших профессиональных успехов?

    Пожалуй на этом хватит. Всем доброй ночи.

Анализ дня: мы все-таки сделали это, новые темы для статей

    Начнем с шаблонных фраз. Всех с прошедшим праздником весны. Лично я очень ждал ее прихода, капризная зима как-то не радовала в этом году.
    А теперь можно спокойно продолжать. Сегодня был замечательный день на работе. Мы отправили первый патч для нашей игры, победив всю ту магию, которая обычно проявляется в законе Мерфи. Заодно я составил диаграмму и план в Jira, которые, очень надеюсь, позволят нам избежать подобной магии в следующий раз. Осталось дело за малым - написать и отладить код. Задача сегодняшнего дня выполнена в полной мере.  
    Также заметил, что более частое написание статей и их обдумывание открывает путь и для новых тем. Казалось бы, что все должно быть наоборот, а нет. Вот и пришло в голову две темы, раскрыть которые будет полезно. И мне, чтобы обдумать их более глубоко, и надеюсь тем, кто решится все-таки прочитать эти писульки.
    Первая тема - это собственно описание нашей идеи с реализацией Continuous Delivery. Правда, если я все-же решусь написать, то будет это через неделю-другую. Утром код - вечером статья, как говориться.
    Ну а вторая тема касается mercurial. У меня появился опыт использования данной системы на реальном проекте, а не в домашних условиях. Вот можно и поделиться.
   
    На сегодня все. Ага, напоследок еще одна новость. Порадовали разработчики Unity. Они раздают бесплатно лицензии на Android и iOS версии. Я себе уже получил. Сделать это можно на их официальном сайте unity3d.com

    Всем доброй ночи

Анализ дня: парный дизайн

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

    День как специально выдался в лучших традициях релизного дня: постоянные отвлечения, срочные вопросы и прочее. Т.е. часам к 4-м я понял, что начинаю пролетать со своей задачей дня. Опять ничего не сделаю. 

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

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

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

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

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

    Всем доброй ночи.

Анализ дня: задача дня, бранчи и снова бранчи

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

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

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

1. То что стабилизировали stable_candidate, не гарантирует что stable будет рабочим после интеграции
2. Некоторые фичи и процессы просто невозможно протестировать в stable_candidate. Соответственно возвращаемся к исходной проблеме - stable ветка какое-то время все равно будет в неопределенном состоянии

    Решение пришло одновременно двоим и оно до банальности простое. Новый бранч нужно делать не до стабилизации, а после.

    Всем доброй ночи

Анализ дня: цели и условия Continuous Delivery, "аутсорсовый" подход

    Всем привет.
    Продолжаю издеваться над собой.
    Ковыряясь все над тем же CD (Continuous Delivery) ушел немного в сторону философии. Какова цель CD, в чем она выражается и как измеряется. Вроде все просто. Цель - обеспечить бесперебойную и быструю поставку фичей из головы геймдизайнера непосредственно на компьютер рядового игрока. Но если моя фича попадает раз в три недели это достаточная скорость? Или раз в год? Сроков то не оговорено.
    Идем дальше. Условия для достижения данной цели я смог придумать два:

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

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

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

    Придется убаюкивать завтра диаграммами и тоннами кода. 

    На этом мой философский выпуск завершен, пошел практиковать. 

   

    Доброй всем ночи.

Анализ дня: TeamCity, встроенные скрипты

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

• Нет возможности нормально править скрипт, просматривать можно по одному шагу, к тому же нет подсветки синтаксиса;
• Нет возможности проверить прямо в системе отдельно какие-то шаги, все нужно запускать целиком, а это занимает ну очень много времени;
• Самое главное, нет возможности быстро откатить свои изменения, если что-то пошло нет так;
• Система очень плохо расширяется, выносить и переиспользовать код нельзя.

    Вот такие вот грабли.

    P.S. Еще в свое оправдение скажу, что мы уже пару дней назад начали выносить скрипты из TeamCity и переписывать их на Python. Думаю такая система будет намного лучше поддаваться контролю, изменениям и расширениям.

    Всем доброй ночи.

Анализ дня: делай сразу, GO и Artifactory

    Весна как известно время перемен. Вот и я сегодня в честь первого дня весны решил попробовать новую для себя штуку.
    Замечаю за собой нежелание подводить итоги недели, просто анализировать прошедший день. Поэтому решил поставить эксперимент. Каждый вечер буду писать о тех новых вещах, которые узнал за день. Ну а, если ничего не узнал, значит так и пишем, а потом ставим в уме минус, пожирнее.
    Вчера слушал интервью Радислава Гандапаса и он сказал, что одной из его сильных сторон является привычка делать все сразу. Не разводить сомнения, не продумывать мега хитрые планы,  а просто действовать ибо "опыт дороже знаний". Попробовал сегодня проследить за собой. Остался недоволен. Даже на протяжении одного дня было много моментов, когда тупил, ленился, и придумывал чтобы такое сотворить, чтобы ничего не делать.
    Уже в конце дня решил прочитать-просмотреть статью о Continuous Delivery, которая висела у меня в браузере несколько дней. Глаза выхватили две тулзы, требующие более пристального внимания. Это GO - сервер для continuous integration от ThoughtWorks Studios и Artifactory от JFrog. По идее Artifactory позволяет сохранять все артефакты билд системы и потом предоставлять к ним доступ всем желающим. Поскольку я сам сейчас активно занимаюсь настройкой continuous delivery то тулзы эти нужно будет рассмотреть более пристально. Кстати сама статья вот: http://java.dzone.com/articles/continuous-delivery-using Тоже рекомендую ознакомится.
    На сегодня все.
    Всем доброй ночи.