Редактор UML-диаграмм

В плане соотношения простоты и удобства понравился редактор диаграмм Dia (http://live.gnome.org/Dia, LGPL), есть порты под Linux, Win, OSX. Проект активно развивается, пока UML поддерживается в довольно упрощенном варианте: но в целом можно изобразить диаграммы последовательностей (хотя время жизни объекта редактируется не оч. удобно: используются 2 параметра - частота точек привязки и расстояние между ними), диаграммы развертывания, static-диаграммы, диаграммы пакетов и т.д. Поддерживает скриптинг на python, что тоже делает редактор любопытным для меня, так как это возможно понадобится для написания различного рода reverse-инструментов. Dia использует свой переносимый формат (пока глюков при переносе обнаружено не было).

Softncoffee goes mobile

Поставил себе на кпк moBlog блоггинг-клиент. Собственно это первый пост с него. По эргономике moBlog оказался вполне приемлемым. Все что потребовалось: в настройках создать профиль, выбрать блоггинг сервис из списка, задать свои логин и пароль.

Ликбез по Linux за август

Короткое резюме за август.

1. подключение общих папок под Oracle Virtual Box:

Win32 guest: net use x:\\vboxsvr\host_shared_dir

Linux guest: sudo mount -t vboxsf host_shared_dir guest_mount_point

2. монтирование IMG-файла:

sudo mount -o loop linux-0.2.img mount_point

3. ssh: для работы потребуется openssh-client и openssh-server. Соотв. на target-машине должен быть поднят openssh-server.

ssh user@11.22.33.44 - наиболее простой вариант залогиниться в target- машину.
sftp user@11.22.33.44 - удобный ftp-client поверх ssl.

4. быстрый способ получить данные по некоторому url с помощью python:

tim@epsilon:~$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib
>>> data = urllib.urlopen("http://google.com").read()
>>> print "Read data: %s"%(data)

Отличная книга по python, к тому же бесплатная - здесь.

5. получение софтовых пакетов установленных на машину:

RHEL: rpm -qa
Ubuntu: dpkg-query -l
AIX: lslpp -L all

6. grep - очень мощный инструмент для поиска и фильтрации нужной информации:

получить все строки файла somewhere, в которых содержится aword:
grep aword somewhere.txt

пример: получить все пакеты, которые имеют в названии слово python:
dpkg-query --show | grep python


У большинства менеджеров пакетов есть всякий stuff, который позволяет получить подробную информацию об установленных пакетах. А также можно задавать каталог с базами данных или root-каталог, что позволяет сканировать установленный софт на некоторых ОС, расположенных на других разделах или дисках. Полезная, на мой взгляд, шпора для админов по unix - здесь

7. общие команды:

получение справки по команде, например для rpm: man rpm
удаление каталога рекурсивно, без подтверждения: rm -r -f your_dir
создание нового каталога: mkdir your_dir
перемещение/переименование файлов: mv source target
соединение файлов с их послед. выводом в стандартный поток: cat file1 file2 file3, можно использовать для вывода одного файла, в частности: cat file1

Знакомьтесь, антипаттерн double-checked locking

На днях размышлял, как можно было бы ускорить следующую конструкцию:

Конструкция 1. Известная всем реализация ленивого синглтона.

public class Singleton 
{
   private Singleton(){}

   private static Singleton INSTANCE;
   
   public static synchronized Singleton getInstance()
   { 
      if (INSTANCE == null)
      {
          INSTANCE = new Singleton();
          //
          // ... perform an INSTANCE initialization
      }
      return INSTANCE;   
   }
}

Основным недостатком является наличие synchronized, которое по-хорошему нужно
только при инициализации экземпляра объекта singleton, а не при каждом доступе к нему.
Таким образом, сразу же напрашивается мысль, а что если попробовать использовать критическую секцию только при инициализации объекта:

Конструкция 2. Первая попытка сделать короче время доступа к INSTANCE.

public class Singleton 
{
   private Singleton(){}

   private static Singleton INSTANCE;
   
   public static Singleton getInstance()
   { 
      if (INSTANCE == null)
      {
         synchronized(Singleton.class)
         {
           INSTANCE = new Singleton();
           //
           // ... perform an INSTANCE initialization
         }
      }
      return INSTANCE;   
   }
}

Теперь инициализация объекта будет происходить при первом доступе к объекту, но, к сожалению, данная конструкция не спасает от конкурентного доступа. Так как может получиться так, что конкурирующие процессы после проверки INSTANCE на null последовательно войдут в критическую секцию и проинициализируют Singleton несколько раз. Тут же придумал workaround: поставить проверку на null после входа в критическую секцию, сказано - сделано:

Конструкция 3. Вторая попытка или double-checked locking антиппатерн.
public class Singleton 
{
   private Singleton(){}

   private static Singleton INSTANCE;
   
   public static Singleton getInstance()
   { 
      if (INSTANCE == null)
      {
         synchronized(Singleton.class)
         {
           if (INSTANCE == null)
           {
             INSTANCE = new Singleton();
             //
             // ... perform an INSTANCE initialization
           }
         }
      }
      return INSTANCE;   
   }
} 

Полученная конструкция в теории должна работать, но так ли это? Довольный своим открытием, я решил посмотреть, что пишут эксперты о такой конструкции, есть ли какие-то другие, более эффективные варианты ускорения реализации паттерна singleton. Очень быстро обнаружил, что такая конструкция действительно используется и называется она double-checked locking (в некоторых источниках такую конструкцию называют даже антипаттерном [2]). Действительно она применяется для ускорения singleton, но имеет ряд неочевидных недостатков для некоторых языков.

Недостаток первый. В некоторых языках, в т.ч. и в Java значение переменной INSTANCE может быть присвоено при выполнении конструктора до его завершения. Это связано с выделением памяти, как только выделяется память, то INSTANCE получает соотв. значение (в Java это ссылка, в других языках это, возможно, указатель на некоторую выделенную для объекта область памяти). Таким образом, есть вероятность, что пока один поток будет выполняться в критической секции, другой, выполнив проверку INSTANCE на null, в критиескую секцию уже не пойдет, а сразу вернет неинициализированную (но не равную null) переменную INSTANCE.

Недостаток второй. Запись и чтение значений переменных в многопоточных программах на некоторых языках могут зависеть от реализации конкретной исполняющей среды/компилятора. Например, в JAVA используется кеширование переменных: из соображений эффективности каждый поток может хранить свою собственную приватную копию переменной. Эта копия может синхронизироватся с основной памятью в различные моменты, например, при входе в критическую секцию и при выходе из нее [3]. Как вариант, в Java можно использовать модификатор volatile для переменной INSTANCE, которое действительно гарантирует атомарный доступ к переменной. В таком случае переменная никогда не кешируется потоками и доступ к ней осуществляется, как если бы это происходило внутри критической секции (synchronize над этой переменной). Но по сути это приводит к тому же от, чего уходили - к наличию критической секции при доступе к переменной.

Таким образом, рекомендуется использовать конструкцию 1 [2], либо использовать факт о ленивой загрузке классов [1]: т.е. что сам класс Singleton будет загружен лишь при первом обращении к нему, соотв. будут проинициализированны все static-поля и секции:

Конструкция 4. Если быть проще...
public class Singleton 
{
   private static Singleton INSTANCE = new Singleton();
   
   static 
   {
      // further INSTANCE initialization
   }

   private Singleton()
   {
      // Singleton initialization
   }
   
   public static Singleton getInstance()
   { 
      return INSTANCE;   
   }
}

Материалы.

[1] http://www.ibm.com/developerworks/java/library/j-dcl.html
[2] http://www.javamex.com/tutorials/double_checked_locking_fixing.shtml
[3] http://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml

Переменные среды в Linux

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

export JAVA_HOME=/path/to/java/jdk1.6.0_20
export PATH=$JAVA_HOME:$PATH

export M2_HOME=/path/to/java/maven
export M2=$M2_HOME/bin
export PATH=$M2:$PATH

export используется, если задается глобальная переменная. Если переменная локальная (т.е. только для данного процесса), то export не требуется.
Посмотреть значение переменной можно, например, так:

echo $PATH

Кстати, в отличие от Windows, в PATH элементы разделяются двоеточием, а не точкой с запятой.
Для того, чтобы переменные среды устанавливались при загрузке пользовательского профайла рекомендуется использовать ~/.pam_environment для того, чтобы добавить туда скрипт с заданием переменных. Общие рекомендации по установке persistent environment variables можно узнать, набрав в консоли man pam_env, либо здесь.

Как оказалось, ~/.pam_environment не является скриптовым файлом, а представляет собой лишь список переменных среды. К тому же, у меня не получилось переопределить PATH, используя упомянутый файл. Такое переопределение приводило к тому, что в машину вообще нельзя было залогиниться. Пришлось войти в консольном режиме и с помощью vim удалять строки в ~/.pam_environment, отвечающие за переопределение PATH.

В конце концов, я взял и добавил нужные строки для определения переменных среды в ~/.profile. Сработало.

Использование system properties в eclipse.ini

Понадобилась небольшая кастомизация eclipse.ini.
Потребовалось уметь создавать свои параметры из eclipse.ini и уметь читать их внутри eclipse. Первый поиск практически ничего не дал конкретного по eclipse, но нашелся другой, более общий варинт: использование системных свойств (system properties) java. Системное свойство можно определить через eclipse.ini в качестве аргумента java-машины, например:

...
-vmargs
-Dfile.encoding=UTF-8
-Dosgi.requiredJavaVersion=1.5
-DMyCustomProperty=aPropertyValue
-Xms256m
...

Теперь в коде можно получить значение свойства MyCustomProperty следующим образом:

String value = System.getProperty("MyCustomProperty");


Создание архивов с помощью VBS

Есть, на мой взгляд, красивый способ создания архивов с помощью VB-скрипта, который хочу выложить (автор скрипта не я, но в своих скриптах использую эту рутину оч. активно). Грубо, идея в том, чтобы создать файл пустого архива, а потом в него добавить средствами Shell файлики.


';===================================
';
'; Simple zipping routine:
';
'; source is folder path to be zipped (recursive zip)
'; dest is file path for output zip archive
';
'; the main idea comes from here:
';
'; http://www.codecomments.com/archive299-2006-2-295877.html
'; http://forum.script-coding.info/viewtopic.php?id=1020
';
';===================================
sub zip(source, dest)
'
' wait operation delay
'
const dt = 1000
Set fso = CreateObject("Scripting.FileSystemObject")
Set ShellApp = CreateObject("Shell.Application")

With fso.CreateTextFile(dest, True)
.Write Chr(80) & Chr(75) & Chr(5) & Chr(6) & String(18, Chr(0))
.Close
End With

ShellApp.NameSpace(dest).CopyHere source

WScript.Sleep dt
'
' waiting for acrhive creation
'
On Error Resume Next
Do
fso.OpenTextFile dest, 1, False
If Err.Number = 0 Then Exit Do
Err.Clear
WScript.Sleep dt
Loop
end sub


Некоторые скриптинговые рутины на VBS

Давно хотел выложить код на VBScript, который я использовал в скрипте для публикации проекта (под публикацией понималось выкладывание сборки в базу данных Lotus Notes и рассылка уведомлений по списку).

Работа с Lotus Notes в vbs:

sub run()
' получить сессию (COM-объект, соотв. важно,
' чтобы объект был зарегистрирован в Win-реестре)
Set nSession = CreateObject("Notes.NotesSession")
' получить базу
Set db = nSession.GetDatabase(STORAGE_DATABASE_SRV,STORAGE_DATABASE_PATH)
if not db is nothing then
' какая-то работа с базой
'...
'...
end if
' освобождеине COM-объекта
nSession = null
end sub



Сниппет с приаттачиванием файлов к документу:


const EMBED_ATTACHMENT = 1454
';================================================
';
'; Simple file attach routine
';
'; @param doc is Notes Document
'; @param itemName is RTF item name
'; @param path is path to the file to be attached
';================================================
sub attach(doc, itemName, path)
Set item = doc.getFirstItem(itemName)
if not item is nothing then
call doc.removeItem(itemName)
end if
Set rti = doc.CreateRichTextItem(ItemName)
Set object = rti.EmbedObject(EMBED_ATTACHMENT, "", path)
end sub


Запуск bin-файлов в Linux

Вот уже несколько дней живу под Ubuntu, после WinXP немного непривычно.
Скачал brand new гелиос, скачал jdk. Поставить jdk оказалось довольно просто, достаточно было только bin-файлу, в котором лежит установщик jdk присвоить атрибут x (exetuable). После WinXP для меня это было не очевидно.

Вот сниппет, где я разрешаю выполнение bin-файла, после чего я его запускаю на выполнение:

tim@epsilon:~/works/downloads$ sudo chmod +x jdk-6u20-linux-i586.bin
tim@epsilon:~/works/downloads$ ./jdk-6u20-linux-i586.bin


Было забавно запускать установку jdk через консоль, так как пришлось долго и нудно проматывать лицензионное соглашение, прочитав которое, я должен был вбить заветное yes в ответ на запрос "Do you agree to the above license terms? [yes or no]".

Настройка прокси для SVN клиента

При подключении через svn к внешнему репозиторию получил сообщение "could not connect to server (http://eclipse.gwf.svn.sourceforge)". Задал прокси в настройках клиента - все заработало.

Шаблон для задания параметров в win-реестре:


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Tigris.org\Subversion\Servers\global]
"http-proxy-host"="abcproxy"
"http-proxy-password"="pwrd"
"http-proxy-port"="8080"
"http-proxy-username"="ABCCORP\\usr"


Существует еще ряд других способов настройки конфигурации svn-клиента, о которых
можно подробно почитать в документации, гл. 7:

Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato: Version Control with Subversion For Subversion 1.5, Chapter 7. Customizing Your Subversion Experience

Перегрузка equals в Java

На днях проходил собеседование в одной компании, на котором попался вопрос про перегрузку equals в Java. Оказалось, что я был не в курсе довольно элементарного, в то же время важного правила: перегрузил equals - перегрузи и hashCode. В переводе это сводится к след. набору простых правил:

• R1. если класс перегружает equals, то класс должен перегрузить и hashCode
• R2. когда оба equals и hashCode перегружены, они должны использовать одинаковый набор свойств класса
• R3. если оба объекта equals, то и значения их hashCode должны совпадать
• R4. если объект не изменяется то hashCode является первым кандидатом на ленивую инициализацию и кеширование
• R5. существует известное заблуждение, что hashCode предоставляет уникальный идентификатор для каждого объекта. Это не так.

На stackoverflow.com нашел алгоритм для вычисления hashCode, который считается наиболее эффективным (могу только предположить, что он дает более или менее равномерный разброс значений). Почти для всех классов приемлимо разумной является реализация, предложенная в 8-м разделе книги Джоша Блоха "Эффективная Java". Также эта реализация хороша тем, что автор в своей книге приводит объяснение почему данный подход приемлем.

Сам подход описывается следующим набором правил:

A1. Создать переменную result целого типа и присвоить ей ненулевое значение.
A2. Для каждого поля, которое используется при сравнении в equals, хеш-код k вычисляется след.образом:

• если поле f имеет тип boolean, то исп.: k = f? 0:1;
• если поле f имеет тип byte, short или int: k=(int)f;
• если поле f имеет тип long, то: k = (int)(f ^ (f >>> 32)), где >>> - беззнаковый сдвиг;
• если поле f имеет тип float, то: k = Float.floatToIntBits(f);
• если поле f имеет тип double, то: Double.floatToIntBits(f), а полученное значение уже обрабатывается как long;
• если поле f - объект, используйте в качестве результата его k = hashCode(), если f == null, то k = 0;
• если поле f - массив, то рассматривается каждый объект как отдельный элемент и хеш вычисляется рекурсивно с комбинированием значений так, как показано в A3.
  

A3. Вычислить результат с использованием полученного значения k:

result = 37 * result + k;

A4. Вернуть результат. Возвращенный результат будет иметь подходящее
распределение значений хеша в большинстве случаев.

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

Прочитав книгу Эндрю Ханта и Дэвида Томаса "Программист-прагматик", я на какой-то момент стал одержим идеей использования скриптинга и использованием его в рутинных операциях. Как всегда пока сильно не хватает времени, чтобы взять и разобраться с 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.

OpenGL и MinGW

Довольно много времени убил на поиск набора библиотек и заголовочных файлов для подключения библиотеки GLUT. GLUT потребовался для написания курсача, в котором нужна графика. В качестве IDE использую Eclipse CDT, с MinGW в качестве компилятора, для которого пришлось искать соответствующие заголовочные файлы и библиотеки.

Первым рабочим оказалось решение:
http://www.ritgamedev.com/tutorials/glutEclipse/

Еще некоторые полезные ссылки вдовесок:
1. http://www.opengl.org/resources/code/samples/glut_examples/examples/examples.html
2. http://www.opengl.org/resources/code/samples/redbook/

Другие варианты использования GLUT с MinGW:
1. http://www.mingw.org/wiki/HOWTO_Use_Mark_J_Kilgards_OpenGL_Utility_Toolkit_GLUT_with_MinGW
2. http://web.cs.wpi.edu/~gogo/courses/mingw/
3. http://www.opengl.org/wiki/MinGW#GLUT_installation

Сценарный подход и BPMN

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

Рассмотрим на примере. Представим, что мы разрабатываем очередной мобильный телефон. Мы хотим создать что-то работоспособное. Итак, начнем наш сценарий. Первое и самое важное, с чего надо начать, это определение цели и формулирование названия сценария. Название «Мой сценарий 1» не самый лучший вариант, так как из названия, например, не понятно, какая цель преследуется сценарием. Название «Передача SMS-сообщения» уже лучше, так как становится ясно, какую функциональность мобильного телефона мы собираемся моделировать. Далее роли, их может быть бесконечно много, но для простоты ограничимся тремя: пользователь, телефон и сеть. Пользователь: это обычный человек, у которого вдруг появляется мобильный телефон (и мы не должны рассчитывать на то, что он уже ознакомился с документацией к телефону). Телефон: в данном сценарии мы предполагаем, что мы имеем идеальную аппаратную часть, которую может испортить лишь плохое программное обеспечение. По этой причине, под ролью телефона будем полагать его операционную систему. Далее переходим к последовательностям действий.
Попытаемся описать основные действия, это могли бы быть общие действия, такие как: «ввод сообщения», «отправка его в сеть», «получение ответа сети о передаче сообщения». Рассмотрим ввод сообщения, см. фрамент 1.

Фрамент 1. Ввод сообщения.

Пользователь: вводит сообщение в телефон, длина сообщения превышает 128 символов.
Телефон: сообщает о превышении сообшения.

Пользователь: вводит сообщение в телефон, длина сообщения меньше 128 символов. Пользователь жмет кнопку отправить. Сеть недоступна.
Телефон: сообщает о том, что сеть недоступна.

Пользователь: вводит сообщение в телефон, длина сообщения меньше 128 символов. Пользователь жмет кнопку отправить. Сеть доступна. Включен транслит.
Телефон: конвертирует сообщение в транслит. Формирует сообщение.

Пользователь: вводит сообщение в телефон, длина сообщения меньше 128 символов. Пользователь жмет кнопку отправить. Сеть доступна. Транслит выключен.
Телефон: формирует сообщение.

Думаю, становится видно, что описание множества последовательностей действий становится непростой задачей, особенно, когда нужно предусматривать наличие сбоев и ошибок, а также ветвлений. Сбои и ошибки это нестандартное поведение системы: нельзя предусмотреть все сбои и все ошибки, но самые вероятные и ожидаемые стоит заложить в сценарий, а не рассчитывать, что все будет идти гладко. Таким образом, текстовое описание последовательности действий не совсем удобно для описания сложных сценариев, так как ограничивает многовариантность развития ситуации. Применение графической нотации для моделирования бизнес-процессов (например, BPMN) решает эти проблемы. Рассмотрим основные элементы, используемые для моделирования нашего сценария, см. рис.1. Каждый сценарий начинается элементом «начало», (рис. 1з) и завершается элементом «конец» (рис. 1ж), а иногда завершается элементом «ошибка» (рис. 1и). Пользовательские действия (рис. 1б): это некоторые действия, которые выполняет некоторый человек. Системные действия (рис. 1а): это некоторые действия со стороны системы, в нашем случае это действия системы (мобильного телефона) и действия сети. Действия конечно же интересны, но еще больший интерес представляют их последовательности, по этой причине нам нужен элемент диаграммы, соответствующий переходу (рис. 1г): это прямая стрелка. Переходы объединяют действия в последовательности. В BPMN переходов может быть три: условный, безусловный и по умолчанию. Для моделирования сценариев я предлагаю использовать только условные и безусловные переходы. Условные переходы отличаются от безусловных наличием некоторого условия, по которому переход осуществляется.
Сценарий будет мало интересен, если мы не будем иметь возможности смоделировать разветвление последовательностей действий. Ветвления могут быть следствием двух основных причин: ветвление в зависимости от условия и ветвление, вызванное распараллеливанием последовательности действий. В качестве элемента ветвления можно использовать вентили (рис. 1е и рис. 1д). XOR (рис. 1е) – вентиль аналогичен оператору «если». Из этого элемента диаграммы исходят только условные переходы. Переход будет происходить по первому элементу, в котором выполнилось условие (договоримся, что условия переходов проверяются в порядке, начиная сверху на диаграмме. Т.е. условие на самом верхнем переходе проверяется в первую очередь). Распараллеливанию последовательности действий соответствует AND-вентиль (рис. 1д). Если из этого вентиля исходят несколько переходов, то на всех них будет осуществлен переход и, таким образом, получится распараллеливание последовательности действий на несколько одновременно выполняющихся веток. Рассмотрим еще один значимый элемент диаграммы – ошибку. Ошибки (рис. 1в) на диаграмме нужны для того, чтобы предусмотреть некоторые исключительные ситуации при выполнении действий (в нашем случае, например, если сеть недоступна, мы не можем отправить сообщение с мобильного телефона). Ошибка должна быть прикреплена к тому действию, которое может приводит к возникновению исключительной ситуации (когда что-то идет не так). Нужно различать завершающие и промежуточные ошибки. Завершающая ошибка - это ошибка всего сценария, т.е. когда наш сценарий завершается с ошибкой. Промежуточные ошибки (рис. 1в) мы используем для того, чтобы отобразить ошибки, которые могут возникать при выполнении действий.

Для описания и документирования сценариев необходимо использовать элементы «комментарий» (рис. 1ё). При разработке сценариев я обязательно составляю комментарий, который относится ко всему сценарию в целом. В нем я пишу название сценария, описание используемых ролей и, возможно, описание некоторых начальных условий.

Не так часто используются элементы для оформления действий, связанных логически. Логически связанные действия можно объединять в подсценарии (рис. 1й). Подсценарий представляет собой блок, включающий в себя последовательности действий. Если требуется построить сложный иерархический сценарии, тогда не обойтись без элемента «внешний сценарий» (рис. 1к). Внешний сценарий представляет собой действие, которое выполняет какой-либо другой сценарий, на который это действие ссылается.


Рис. 1. Примеры элементов диаграмм.



Рис. 2. Собирая всё вместе.



Теперь объединим всё вместе (рис.2.). Наш сценарий можно представить в виде диаграммы BPMN. Входная точка в наш сценарий – элемент «начало». Согласно сценарию предполагается, что для отправки сообщения, пользователь должен его сначала ввести. Ввод сообщения должен быть прекращен, после того, как максимальный размер отправляемого сообщения будет превышен. О превышении максимального размера сообщения необходимо сообщить пользователю. Если всё нормально и пользователь нажал кнопку отправить, то телефон транслитирирует сообщение, если включена соответствующая настройка, формирует и передает запрос в сеть. Здесь может возникнуть исключительная ситуация, так как сеть может быть недоступна. Если сеть недоступна, то об этом также следует уведомить пользователя и предложить ему отправить сообщение позже. Далее, если все идет нормально, сеть регистрирует запрос и ставит его в очередь на обработку. Когда очередь подходит, сеть выполняет запрос на отправку сообщения. При выполнении запроса сеть может внезапно обнаружить, что у пользователя нет денег, а потому она не может отправить его сообщение. В этом случае сеть возвращает код, по которому устанавливается причина невозможности отправки сообщения (нехватка денег на балансе). В случае, если денег у пользователя на балансе достаточно сеть шлет подтверждение о том, что сообщение было отправлено. Конец сценария.

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


Для дальнейшего чтения:

BPMN Method and Style: A levels-based methodology for BPM process modeling and improvement using BPMN 2.0, Cody-Cassidy Press (June 1, 2009)