TBPD: Tasks-based Business-Processes Definition

Ну, в общем, тут, видимо, этой штуке и место.
Общая идея в том, чтобы автоматизировать бизнес-процессы не на базе Activities, а на базе Задач.
Итак:

Суть:

• Все бизнес-процессы (т.е. последовательности действий) есть последовательности Задач: одно действие - один тип Задач;
• Задача может зависеть от других Задач - как начало Задачи, так и её завершение;
• Задача не может быть удалена или изменена - только завершена с тем или иным исходом;
• Задача может "включать" другие Задачи путем установления зависимостей. Вариант "включения" - когда подзадача активируется при активации надзадачи, а надзадача может быть завершена при завершении подзадачи.

Особенности:

• Любая Задача имеет как минимум автора, дату/время создания, исполнителя, дату/время прочтения задачи исполнителем; дату/время завершения (для завершенных);
• Задача может быть только в четырех состояниях: неактивная, активная непрочитанная, активная прочитанная (автомат), выполненная (с тем или иным исходом);
• Состояние задачи может зависеть от состояния других Задач:
• Задача может быть неактивной до тех пор, пока не будут завершены с нужным исходом другие Задачи, от которых зависит эта задача;
• Активная задача не может быть завершена с определенным исходом, если не завершены с нужным исходом Задачи, от которых она зависит;
• Выполнение задачи может создавать другие задачи (какие - может зависеть от исхода);
• Самая первая задача в бизнес-процессе может быть создана Событием - специальный тип Задачи без задачи-родителя;
• Завершение Задачи может породить другую Задачу того же типа; тогда в работе участвует только последняя задача в такой цепочке - получается "история выполнения задачи";
• С Задачами можно работать в любом ПИМе; некоторые можно там же завершать, если ПИМ поддерживает нужные исходы.

Примеры:

• Зависимость неактивности: "Оплатить счет" неактивна, пока не выполнено "Получить счет";
• Зависимость завершения: "Оплатить счет" не может быть завершена успешно, пока не выполнена задача "Получить выписку из банка" - тоже успешно;
• Группировка: "Купить товар" не может быть завершена, пока не завершены "Оплатить товар" и "Получить товар"; "Оплатить товар" не появляется, пока не появится "Купить товар".
• Зависимость следующих задач от исхода предыдущей: завершение "Оплатить счет" создает "Получить товар" (если счет оплачен успешно) - или же "Купить за нал", если не оплачен по причине денег на счету ёк;
• Задача порождает задачу того же типа: изменение сроков выполнения задачи, замена исполнителя.

Отличия от классики:

• Нет "состояния" процесса или его части (начал выполнять, выполнил наполовину и т.д.) - есть только Задачи - выполненные и не выполненные. Т.е. "состояние" процесса - это суперпозиция состояний всех его задач.
• Нет многих состояний Задачи (начал выполнять, почти закончил выполнять и т.д.) - только выполнена или нет (неактивна/активна, прочитана/не прочитана - это уже просто техника, юзер оперирует только "открыта" и "закрыта").
• Самое главное: контролируется не процесс, а результат.

Ключевые преимущества:

• динамическое планирование проекта - схема выполнения проекта может меняться на лету без дополнительных усилий - просто в силу внешних обстоятельств и результатов решения промежуточных задач;
• внятное визуальное представление хода выполнения проекта - для руководства (цветной граф задач и их связей - цвет задачи/связи зависит от успешности и сроков её выполнения);
• простое и удобное представление для исполнителей (простой список задач с возможностью группировки/сортировки/фильтров);

Идеи:

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

Пробуем raw http

Идея была такая - а что, если python-gdata делает, больше, чем просят? В смысле - запрашивает.
План работы:
1. написать приложение, которое, пользуясь _чистым_ http сделает те же запросы (ну и вообще полезно для отладки).
2. сравнить результаты.
Сделал. Python+httplib+urllib. По дороге научился получать у гугля ключи от хаты (токен авторизации) - классная вещь.
Результаты: не отличаются НИЧЕМ :-(
gdata отдал 20KB (оформлено - с ns и всё такое), raw http - 19KB неоформленного xml.
Информация - та же.
Вывод - чудо не произошло.
Остался последний патрон: Atom feed history spec (RFC 5005).
ЗЫ: ну не может быть чуда нед! Гугль даже пишет журнал _всех_ запросов! О чем прямо сказано в Google API - "указывайте приложение, каким просите - надо для истории".

GooglePIM alive

Ну вот...
Замучила совесть вконец - человеку ж обещал поработать надо темой - а сам закинул, цуко... Не от хорошей жизни, а от работы - но тем не менее...
Сегодня бортанул все халтуры и немного поработал с GData.
Вопрос был простой: как-то обеспечить синхронизацию локальных данных с гуглем.
Для этого надо знать - что с последнего запроса:
1. удалено
2. добавлено
3. изменено
Ну, с 3) проблем больших нет - нам бы только узнать, что изменилось, а подробности уже получим, когда наступим на это дело. GData такую информацию отдает (в смысле - можно попросить прислать "updated с...").
С 2) тоже не проблема - как 3), только "published с ...".
А вот с 1) - полная засада. Т.е. гугль просто не скажет, что удалено. Удаляется с концами. Единственное исключение - Контакты - они помечаются deleted и живут так ровно 1 мес (если спецом не удалить вообще).

Итого родился алгоритм - спросить гугля пачкой сразу:
1. спросить - сколько элементов вообще (эта цифра ничего не значит еще).
2. спросить - сколько появилось новых (вот в этом месте мы уже будем знать - сколько удалено; хотя, к сожалению, не будем знать - кто - придется шерстить всех, цуко!).
3. и кто изменился.

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

Есть 2 новости - плохая и как всегда.
Плохая - если гуглю ничего не сказать, то по запросу к блогспоту он отдаст:
1. кол-во блогов (это хорошо)
2. updated будет равно времени запроса (это плохо) - а не времени updated хоть одного блога (или времени удаления... короче - времени изменения состояния блогспота);
3. и, цуко, все блоги - с id, линками, названиями, тегами и прочей муйней.
Итого 12 блогов мне обошлись в 20KB. Не бог весть что - но тоже ж жалко... Это только блоги. Контактов, я думаю, отдаст на все 100 кил. Один пук - и 100 кил коту под хвост. С мобилы, ога...

Хорошая новость в том, что можно попросить ?max_results=0 - и гугль отдаст только голову - кол-во блогов (если попросить - то кол-во богов, соответсвующих критерию (updated, published).
Получилось 1KB. Тоже не фонтан - но не 20 же ж!

Теперь - к следующему уроку приготовить:
* попробовать получить блогспот не через python-gdata (может это он гонит - слишком заносит хвост клеенту и берет то, что не просили), а напрямую по atom (только надо разобраться с авторизацией - гугль же хрен отдаст просто так - за что и уважаю).
* Попробовать сделать batch-запрос - итого+published+updated.
* попросить Деда Мороза прислать мне инфу - как попросить гугль отдать только entry id вместо всего entry. Тогда я бы просто получил список id обновленных и новых entries, пометил в своей базе, что они - несвежие, а разбирался бы потом. А самое главное - сразу бы удалил несуществующие.

Еще надо бы внимательнее почитать http://code.google.com/p/libgcal/ - там есть упоминание о некоем fastsync (хотя в чЮдеса не верится).

PS. Но вообще прямо в руки лезет идея промежуточного сервера, который всю эту мороку с rss возмет на себя - а мне отдаст в чистом виде.

GooglePIM reloaded

Мда, забросил я было это дело...
А тут недавно обнаружил, что гугель уже прикрутил Todo в свою балалайку.
Это то, чего не хватало.
Вот теперь можно лепить полноценный ПИМ. Или Гугль-десктоп :-)

В прошлой серии тормознулось из-за того, что при каждом старте софтины надо снимать _всю_ ленту Atom. Т.е. прокачиват сотни метров.
Идея появилась - сделать прокладку в виде SyncML. Но это ж кто её будет делать...
Поэтому сейчас сделаем проще (образно) и хитрее - воспользуемся возможностями сомого gdata.

Общая идея в том, чтобы не качать лишнего.
Для этого:
1. все данные надо кешировать
2. все изменения - журналировать и выполнять оптом (ессно, с проверкой - вдруг кто-то что-то там во время редактирования изменил.

Что для этого надо?
1. хранить последнее updated фида
2. хранить времена updated всех элементов
3. в случае изменения updated фида:
3.1. снять все элементы, у которых update >= feed update (ркурсивно повторить 2+)
3.2. причем не полностью элементы, а только id и updated
3.3. снять все _deleted_ элементы на тех же условиях.
4. снимать элементы небольшими порциями

Да, локально будет храниться полная копия всех элементов. А шо рабиць?
Еще прийдется разруливать конфликты, паче они случатся.
Зато можно поработать offline - и опубликовать в гугле одной педалькой.
В batch-режиме
Локальной базой можно сделать BerkleyDB или SQLite.

Итого план работы:
1. изучить возможности п.п. 3.2 и 3.3
2. разработать алгоритм синхронизации
3. разработать формат базы

Полетели.

FeelingSensitivity

Идея - чтобы система была чувствительна к настроению хозяина. Хуже - "угадывало" его желания.
Пример - пришел домой, хочется музыки. Какой - хез, её много, выбирать - влом.
Система, базируясь на статистике, биоритмах, состоянии расчетного счета etc - грит:
С: хозяин - может это?
Х: не...
С: это?
Х: не!
С: (так... хозяин не в духе... пора думать) Хозяин, приложите руку к сенсору - мы попробуем погадать.
(дальше вычисляется давление, пульс, дыхание, потение etc.)
С: Хозяин, у Вас фигня какая-то... Дыхните в трубочку, плиз.
(хозяин дишит)
С: Кхм... Вроде и пил немного... Хозяин - а посмотрите в камеру своим хлебальцем!
(хозяин смотрит в уеб-камеру)
С: Мдымс... Хозяин, у вас показатели в норме, пили Вы немного, но - судя по выражению Вашего хлебала, у Вас - мегадепрессняк. Предлагаю Rainbow'74, потом - PinkFloyd "The Wall" - и вызвать девочек.
Если Вам что-то посреди дороги не понраится - убейте меня апстену - данная информация поступит в статистику и будет учтена в следующий раз.

Где граница между PIM/DMS/GroupWare?

Имеем классику PIM:
1. Контакты
2. Задачи
3. Мыло
Еще (во многих):
4. Заметки (Notes)
и вот тут начинается интересное:
* notes бывают типа разные. Проще всего - plain-text
* которые быстро становятся richtext (с форматированием)
* который быстро перерастает в html
* или в другой формат (rtf/doc/odt/docbook (!)/иное)
* а еще документы бывают не только текстовые, но еще и типа spreadsheet
* или там media (audio/video/image)
* и вся эта хрень требует навигации
* и получается локальный себе DMS
* а потом оказывается, что этим надо бы поделиться (share)
* и получается groupware
* ...

Где начало того конца, которым кончается начало?

Starting TheStorage

Нельзя объять необъятное. Начинается с каталогов с отдельными схемами, потом пошли связи между объектами внутри каталогов, потом - между объектами разных каталогов, потом - объекты в нескольких каталогах, плюс категории... И заканчивается семавеб, которого нет. Думать можно вечно.
Выход - дорогу осилит идущий.
Сиречь - все таки сделать один продукт за раз. И - трансляторы.
Продукт будет называться скромно и со вкусом - TheStorage.
Размещаться - в code.google.com/p/semen
Там же - keyfeatures etc