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.

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

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

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

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

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

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

Анализ дня: 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 Тоже рекомендую ознакомится.
    На сегодня все.
    Всем доброй ночи.

Система юнит тестов - логический компилятор вашего приложения

"A unit test is almost always written using a unit-testing framework" Roy Osherove, The Art of Unit Testing.

Всем привет.

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

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

Но что я вынес для себя и почему выбрал именно такой заголовок статьи, а не другой?
За свои скромные несколько лет работы я вынес одну банальную вещь - программисты народ ленивый, менеджерам всегда не хватает времени, поэтому хватит экспериментов, делайте как работает и не ерзайте. Соответственно, если вы хотите ввести какую-то полезную практику у себя на проекте, то в первую очередь позабодтесь об удобных инструментах для работы. Будь-то ревью кода, continuos integration, continous delivery.

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

Инструменты следующие, очень советую посмотреть всем кто пишет на C#:

• xUnit (NUnit) - фреймворки для юнит тестов
• NSubstitude - фреймворм для создания моков(заглушек, пустышек для тестов)
• Test Driven.NET - плагин, который позволяет запускать тесты под разными тулзами, и под дебагом в том числе
• NCrunch - плагин, который в фоне запускает тесты и выдает вам красивый результат в картинках, визуально показывает покрыт ли ваш код тестами

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

Также отдельно постараюсь написать о тестах и инструментах в С++. Все-таки это мой родной язык и жаль, что ситуация там немного хуже. Очень буду рад пообщаться на тему реального, практического использования TDD и юнит тестов в С++. Какие инструменты вы применяли и как настроили воркфлоу?

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