[prog.sobjectizer] Неожиданный сценарий использования mchain-ов.

Механизм mchain-ов (сокращение от message chain), появившийся в версии 5.5.13, внезапно оказался полезным в качестве счетчика событий.

[prog.c++11] Первый релиз-кандидат SObjectizer-5.5.15

Зафиксирован первый релиз-кандидат версии 5.5.15 проекта SObjectizer. В этой версии реализована возможность представления агента в виде иерархического конечного автомата с такими возможностями как: композитные состояния, shallow- и deep-history для состояний, обработчики входа/выхода в/из состояния, проброс события для обработки в другое состояние (что-то вроде defer).

Взять 5.5.15-rc1 можно из репозитория (либо Svn на SourceForge, либо Git на GitHub).

Особой документации пока нет. Только Doxygen-комментарии к соответствующим сущностям и пара новых примеров в каталоге samples/so_5 (примеры state_deep_history и intercom_statechart). Как раз подготовкой документации и буду заниматься в ближайшие дни. Если по ходу написания документации всплывут какие-нибудь косяки, буду вносить правки и делать следующие релиз-кандидаты.

Соответственно, если у кого-то будут замечания/предложения по текущей реализации, то не стесняемся, высказываем. Есть возможность вносить изменения до релиза. После релиза будет сложнее, т.к. сохранение совместимости между версиями внутри ветки 5.5 -- это одна и важных целей.

[prog.sobjectizer] Состояния конечного автомата с историей -- это прикольно

Конечные автоматы с состояниями, у которых есть история -- это прикольная штука. Пока с этим не сталкиваешься, то думаешь: "Ну а что в этом такого?" А вот когда сталкиваешься... Тогда думаешь, что получить такой же эффект какими-то другими средствами было бы, наверное, совсем не просто.

[business] Наглядный пример того, почему программистам нельзя доверять маркетинг

У себя в G+ ленте уже размещал ссылку на тему сбора средств на развитие проекта Robomongo. Суть в том, что разработчик из Минска пару лет делал OpenSource-проект Robomongo, затем понял, что разрываться между основной работой и проектом уже не может, захотел собрать средств дабы оплачивать работу нескольких человек над проектом в течении года.

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

[prog.sobjectizer] Адекватность связки time_limit/drop_time_limit для состояний агентов

В новой версии SO-5.5.15 реализуется поддержка иерархических конечных автоматов (об этом уже писалось). В процессе реализации оказалось, что для нормальных ИКА нужно практически все, что было описано David Harel в его основополагающей работе "Statecharts: A Visual Formalism For Complex Systems" и затем перекочевало в диаграммы состояний UML. Например: композитные состояния, обработчики входа-выхода, состояния с историями. И, среди прочего, автоматическая смена состояния после прошествия указанного времени.

В SO-5.5.15 поддержка автоматической смены состояния агента после указанного тайм-аута реализуется посредством метода time_limit для состояния агента.

[prog.work] Любопытная статья "Don't Call Yourself A Programmer"

Наткнулся на статью "Don't Call Yourself A Programmer, And Other Career Advice". Статья не новая, от 2011-го года, но раньше ее не читал.

Как по мне, так статья хорошая. Программистам, особенно тем, кто еще не приобрел достаточного жизненного опыта и находится в плену розовых иллюзий, прочесть стоит. Даже не смотря на то, что она на английском и довольно объемная (впрочем, какой же ты нонче программист, если не можешь в английский?).

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