четверг, 22 марта 2012 г.

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
      Всем доброй ночи.

понедельник, 19 марта 2012 г.

Анализ дня: недостаток 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.

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

суббота, 17 марта 2012 г.

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

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