Использование скриптинга для выполнения рутинных операций. Первые шаги.

Прочитав книгу Эндрю Ханта и Дэвида Томаса "Программист-прагматик", я на какой-то момент стал одержим идеей использования скриптинга и использованием его в рутинных операциях. Как всегда пока сильно не хватает времени, чтобы взять и разобраться с maven, но было сильное желание быстро сделать что-то работающее. Сборка проекта начала занимать слишком много ценного времени, помимо того, нужно эту сборку закачать в базу данных, а также сделать "снимок" среды окружения проекта (например, дизайн бд, которая используется моей программой) и разослать всем заинтересованным лицам почтовые приглашения. Сначала я написал простой батник, который выполнял нужные процедуры по перемещению файлов и запускал NSIS. Позже получилось написать vbs скрипт, который делает все остальное.
Напишу о том, что было использовано в этом батнике.
На листинге1 пример организации цикла по набору, получаемому при вызове команды
dir, которая использует параметр /AD для того, чтобы получить только список каталогов и параметр /B, который нужен для того, чтобы выводились только имена файлов и ничего лишнего. Далее вызывается код по метке :dosub, в вызов которой передается значение переменной цикла %%а. При выполнении всего цикла скрипт завершает свою работу (команда exit).

Листинг 1. Пример цикла, который получает список папок по шаблону пути "releases\cobra_*"

for /f %%a in ('dir /AD /B releases\cobra_*') do (call :dosub %%a)
exit /B
:dosub
set release=%1
... некоторый скрипт, использующий переменную release

Команды, который использовались в скрипте:

rmdir /S /Q anydir - использовал для удаления иерархии папок без подтверждения, для того, чтобы очистить каталог, в котором происходит сборка от старых и посторонних файлов.

md - создание каталога
xcopy - копирование файлов, причем xcopy в моем случае просто необходимо, так как с помощью команды xcopy можно копировать целые каталоги с подкаталогами, в отличие от
copy. Параметры:
-D:m-d-y копировать файлы новее указанной даты,
если дата не указана, то копироваться будут более новые файлы.
-E - копировать все папки и подпапки, включая пустые.
-С - продолжить, даже, если произошла ошибка
-R - перезаписывать все файлы
-K - копировать атрибуты файла (просто xcopy сбрасывает признак "read only")
-Y - подавлять запросы о перезаписи существующий файлов

Листинг 2. Очередной кусок из жуткого батника, демонстрирующий копирование файлов.

rem
rem =============================
rem copy project files
rem =============================
rem
xcopy %inputDir%\cobra.ini %outputDir%
xcopy %inputDir%\artifacts.ini %outputDir%
xcopy %inputDir%\cobra.exe %outputDir%
md %outputDir%\plugins
xcopy %inputDir%\plugins %outputDir%\plugins /D /E /C /R /I /K /Y
md %outputDir%\p2
xcopy %inputDir%\p2 %outputDir%\p2 /D /E /C /R /I /K /Y
md %outputDir%\configuration
xcopy %inputDir%\configuration %outputDir%\configuration /D /E /C /R /I /K /Y

И вот пример вызова NSIS сборщика с использованием lzma-сжатия:

"c:\program files\nsis\makensis.exe" /X"SetCompressor /FINAL lzma" %installerDir%\intpc.installer.nsi

Далее вызывается vbs-скрипт, отвечающий за "публикацию" проекта (т.е. запись сборки в спец. лотусовую базу и рассылку уведомлений по почте по некоторому списку адресов) .

CScript -S _publish.vbs D:\projects\bpm\releases\%release%.exe
rmdir releases\%release% /S /Q

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

В следующем посте постараюсь более подробно рассказать о скрипте, отвечающем за публикацию.

Весенняя школа ГУ-ВШЭ 2010 (продолжение)

Попробую вспомнить, что было дальше...

.. а дальше выступил представитель Microsoft с обстоятельным рассказам об их собственной платформе для командной работы MS Foundation Server, по моим ощущениям она тянула на систему управления проектом и включала: систему управления версиями, планировщики, проверку целостности кода, тестирование, контроль за исправлением ошибок и т.д. Потом наступил долгожданный обед, понравилась местная студенческая столовая, в которой можно перекусить по вполне вменяемым ценам.

После обеда опять все общались, после чего началось case study, которым рулил Байрам. Бай перечислил основные принципы работы в команде:
1. А как ты это делаешь? Проверка исходных предпосылок.
2. Не зная вопроса, нельзя обсуждать что-либо. По этой теме сильно запомнился ролик Comedy Club "Что? Где? Когда?".
3. Не позволяйте проблемам накапливаться. Должна быть постоянная обратная связь.

Потом Бай ознакомил нас с некоторыми феноменами, которые возникают в группах.
Феномен 1. Усиление доминантных реакций в присутствии других. Вместе простые задачи решаются проще, сложные - труднее. Статус митинги позволяют заставить отстающих понять, что они отстают.

Феномен 2. Диффузия ответственности - смешение индивидуальных вкладов при групповой работе. Чтобы справиться с этим используются: декомпозиция задач, распределяется ответственность, поддерживается прозрачность действий внутри команды.

Феномен 3. Опасение конформизма (характерно для новичков и неопытных членов группы). Люди опасаются противостоять сложившимся в команде взглядам. Для устранения феномена работают методы обезличивания: тайное голосование, planning poker, узнаются или метод Сурова: сначала узнаются мнения младших по статусу.

Феномен 4. Усиление групповых решений и суждений в результате дискуссий. Вообще, если о дискуссиях, то Байрам рекомендовал проводить definition dump, чтобы убедиться, в том, что под одними и теми же терминами подразумевается одни и те же значения (критерии и критериальные эквиваленты терминами НЛП), а также метод шести шляп.

Литература по психологии в командах, которую нам рекомендовали:
1. Chris Argyris "Organizational learning" (Double Loop Learn)
2. Рей Иммельман "Boss, Great Boss Dead Boss"
3. Скотт Беркун "Искусство управления IT-проектами"
4. Питер Друкер "Эффективный управляющий"
5. Том Демарко "Роман об управлении проектами"
6. Девид Майерс "Социальная психология"
7. Роберт Чалдини "Психология влияния"

После case study проводился практический тренниг. Нам раздали диалоги, по которым надо было поставить диагноз, определить - что не так? За тренингом нам немного поведали об элементах повседневной психологии: хорошие и плохие игры, кривые печали, вампиризм и как не стать его жертвой. Рассматривались наиболее частые паттерны, такие как:
1. не знаю, как это сделать...
2. обезьяна на спине..
3. Если бы не ты, то...

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

1. Эрик Берн "Игры, в которые играют люди"
2. Эдвард Йордан "Путь камикадзе"
3. Майстер Девид "Советник, которому доверяют"
4. Леннарт Дальгрен "Вопреки абсурду: как я покорял Россию, а она - меня" (впечатления о России директора российской IKEA)

Весенняя школа ГУ-ВШЭ 2010

Полное название мероприятия - Весенняя школа ГУ-ВШЭ Software Project Management. Было классно. Выступали люди из PeopleMind, из Empatika и Microsoft. Мероприятие открыли руководитель отделения программной инженерии Сергей Авдошин и руководитель центра компетенции PeopleMind Елена Бочарова. Первым выступал Сергей Седов, технический директор «Креатив Медиа». Началось все со слогана "Освободитесь от иллюзии сопричастности к высоким технологиям", с которым я полностью согласен. На мой взгляд, программирование, в большинстве задач никакого отношения к высоким технологиям не имеет. Сравнивались 2 методологии UP и agile. Как оказалось, agile больше подходит для зрелых команд универсалов, в то время как UP основан на четком разграничении обязанностей и использовании узкопрофильных специалистов. Много говорилось о тестировании самих требований о том, что они должны проверяться на адекватность, непротиворечивость и полноту. Звучит красиво, но на сколько реализуемо на практике? Сергей рассказал про стандартные способы оценки длительности:

• экспертная оценка
  
• декомпозиция
• оценка по аналогии
• прототипирование

Экспертная оценка как оказалось - не самый адекватный способ оценки требований, так как он строится на опыте данного конкретного эксперта, на опыте команды с которой он работал, а следовательно эта оценка плохо применима для других команд. На курсе PM в универе нам рассказывали о следующей оценке:


На докладе Сергея мне понравилась эта простая диаграмма:


Также для снижения рисков и экономии времени Сергей советовал автоматизировать процессы тестирования, сборки и выпуска релиза. Еще очень понравилась идея о том, как дисциплинировать свою команду: если кто-то опаздывал на совещание более чем на 10 минут, то он должен был положить 500 рублей, в общую копилку команды. Деньги из копилки тратятся, например, на заказ пиццы для всей команды.

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

1. внимание к себе
2. интерес, новизна (обратное - эффект привыкания)
   
3. игра
4. творчество
5. стадное чувство
6. вовлеченность
7. халява
8. обратная связь (т.е. люди всегда делая что-то, ожидают получить обр. связь)

Потом мы все попытались создать отличительные черты команды:

1. атрибутика
2. общая цель (часто это общий враг)
3. кричалки, обряды, ценности
   
4. общий язык, сленг
5. родственные связи
6. своя территория
7. совместная активность
8. наличие механизма правосудия (эффект давления команды)

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

Потом выступил Максим Дорофеев из Лаборатории Касперского.
Он раскритиковал стандартные диаграммы Ганта и предложил другой известный мне из курса PM способ:


Диаграммы Ганга малоэффективны так, как требования - объект постоянных изменений и лишь 20-30%% из них доживут до конца неизменными, еще 20-30%% изменятся, а остальные устареют. Максим предложил рассматривать поток входящих требований In(N) и поток отработанных требований Out(M) как некоторые случайные величины, которые могут быть смоделированы некоторыми законами распределения. Проще всего использовать нормальный закон, так как он легко строится и при больших N и M, любой закон распределения можно аппроксимировать нормальным законом. Используя такой подход, совмещенный с подходом с использованием трендов (см. рис. выше) можно определить наиболее вероятную итерацию, на которой проект будет завершен.

Рецепт Максима:

• итерационная разработка (как он сказал, если этот подход применяется впервые, то первые 10 итераций обычно не получается соблюдать, здесь нужно терпение)
• инкрементальная разработка (например, реализуются элементы архитектуры, но не полностью)
• постоянная готовность проекта к поставке (т.е. не должно быть состояний, в котором проект не может быть передан заказчику)
• документирование (иначе пользователи и админы очень быстро вынесут весь мозг)
• стабильная команда
• использование только относительной оценки трудозатрат (желательно в абстрактных попугаях. Как сказал Максим, можно использовать и часы, вот только нужно забыть о том, что это часы)

Встреча AgileRussia. Agile и инструменты

Вчера довольно динамично прошла вторая встреча по agile, на которой мне удалось присутствовать.
Рассказывали об инструментах. В отличие от предыдущей встречи людей было человек на 50 меньше, но тем не менее все равно было весело и интересно. Встречу открыл Курышев Женя, ведущий проекта Яндекс.МойКруг. Женя рассказал о бесценном опыте использования потолочной плитки в процессе планирования проекта. Другим must have инструментом оказался Skype (для того, чтобы в офис в Питер можно было бы передать изображение плана проекта с потолка). В настоящее время в силу разрастания компании их команда перешла на JIRA+GREENHOOPER. Понравилась возможность ассоциировать задачи и соотв. коммиты в svn. К сожалению, JIRA я пока вообще не знаю (у нас используются внутренние инструменты для управления проектами, и это пока мешает переходу на стандартные средства, в общем пока у нас бронзовый век). Что еще? Ну конечно же довольно оригинальный способ (опять-таки для меня, потому что может быть этот инструмент везде так и используют) использования Etherpad. Женя и его команда применяют данный инструмент для фиксации требований заказчиков. Т.е. за представителями заказчиков несколько человек одновременно редактируют некоторый документ, что позволяет записывать фактически каждый чих. Также были упомянуты - Wiki, planning poker, JsLint, Zabbix, PHPUnit, а также любопытный способ использования большой плазменной панели для вывода информации с PHPUnit, Jira и Zabbix. Респект Жене и его команде!

Вторым докладчиком выступил Александр Сербул (IT-директор AllSoft.ru). Он рассказал об использовании TrackStudio и svn. В svn создавалась иерархия папок для каждого типа документов (проект, требования, программный код, документация и т.д.).
Также были упомянуты redmine + svn. Также они использовали GIT - распределенная
система контроля версий, dabbleboard - доска. Была упомянута camstudio - бесплатная программа для записи изображения экрана компьютера в AVI формат с возможностью конвертации в SWF.

Третьим выступил Дмитрий Лобасов, (RapidSoft). Дмитрий в основном рассказывал о своей системе управления проектами: devprom. Эта систему можно скачать с официального сайта проекта. Есть инсталлер. Обратил внимание на скорость работы - все летает. Devprom интегрирован с svn, но Дмитрий сказал, что есть API, которое в принципе позволяет подключить другие системы контроля версий. Из того, что увидел: devprom позволяет планировать итерации, учитывать плановое и фактическое время выполнения задач, связывать задачи с svn-коммитами, поддерживает обсуждения, есть гибкая система ролей. Вообще, Devprom, судя по рассказу докладчика, умеет очень многое, поэтому в дальнейшем я попробую более детально разобраться с этой системой управления проектам.

Встреча закончилась традиционным голосованием по поводу темы следующего семинара.
Если верить голосованию, то на следующем семинаре будут рассказывать про методы планирования в agile.