Project SemEn blog

TBPD: HelpDesk

2010-03-28T08:33:00.000-07:00

Так, с наворотами в HelpDesk в виде цепочки задач я немного психанул...
* там нет много задач. Там одна задача. Которую надо как-то порешать.
* состояния открыто/закрыто - мало. Схема new-accepted-done-submited - лучше. Это тоже, что и Opened/Close, но используя простейшее квитирование (подтверждение приема). Open/Close годится для Google Task - когда сам себе автор и исполнитель. Где участвует двое - там нужно подтверждение, что до человека дошло.
* Другой вопрос - ведение журнала изменения состояния задачи. Это - да, вещь. Пока можно ограничиться заливкой в журнал Django - с каментами - что произошло.
Итого - схема такая:
* Задача - одна.
* Состояний - 4 (New, Accepted, Completed, Approved) - отдельная модель.
* Переходов - 8:
** Create ( None => New)
** Route ( New/Accepted => New )
** Invalid/Duplicated ( New => Completed )
** Accept ( New => Accepted )
** MkDep ( Accepted => Accepted ) - родить подзадачу / зацепиться за существующую
** Done ( Accepted => Completed )
** ReOpen ( Completed/Approved => New )
** Approve ( Completed => Approved )
* Форм - 2 (список (с фильтром) / задача (с историей))
* ведется журнал в системном журнале Django:
** объект - эта задача
** время - автомат
** user - понятно
** каменты: действие (переход из - в), каменты (юзеровские)

ЗЫ: Не, нифига. Сливать задачу Из New в Invalid - не надо. Человек нажаль педаль Просмотреть на задаче - всё, он её прочитал - значит - Принял (Accept). А потом уже пусть делает с ней всё, что хочет - перенаправляет, сливает, жалуется - пофик. Он её _прочитал_ => принял к сведению. Типа подтверждения прочтения. Чтобы вариантов "а я еще не заглядывал в список - компьютер не работал" не было.

TBPD: Tasks

2010-03-08T11:58:00.000-08:00

С контактами (организациями и людьми) разобрались - там хоть и навороченно, но вопросов пока нет концептуальных.
Переходим к Задачам.
Экспериментировать будем на HelpDesk. За пример возьмем opentodo и bugzilla - с доработкой напильником под себя.
(Следующей кошкой можно взять классику - Заявка/Счет/Оплата/Доверка/Накладная|Акт+СФ/Оприход. Тут уже интереснее - масса ветвлений и неожиданных поворотов - зато всё определено (а на этой базе можно сделать данный документооборот - с формами, но без бухучета... Кстати - идея! :-)).
Общие принципы:
* все объекты (в т.ч. задачи) наследуют одного предка;
* все специфичные задачи наследуют общий класс Задача - с доработкой по месту;
прохождение задачей своего жизненного пути - это цепь задач, только одна из которых (последняя в цпочке) может быть активной. Остальные уходят в архив - для истории;
* Задача может быть только открытой и закрытой;
* Закрыться задача может только успешно - или родив следующую задачу;
Задача может включать другие задачи, только когда все подзадачи завершены (условия и/или - потом);
* Задачу можно заблокировать успешным выполнением другой задачи (то, что в bugzilla назвается блокирующим багом). Это - не подзадача, а совсем из другого потока.
Итак - пора рисовать классы (на пальцах):
GwObject
Предок всех остальных классов. Gw - от GroupWare. Здесь прошиты возможности наследования, группировки и ассоциаций - всё по-взрослому. Все поля (кроме type) - необязательные:
* type:GwOType - тип наследника (расписыват не буду - просто enum); Обязательно прописывается наследниками.
* ancestor:GwObject - предок - объект, с которого тянутся поля, которые в данном объекте не прописаны (пример: девушку угораздило выйти замуж; тогда всё, кроме фамилии, она может наследовать от своей предыдуще жизни);
* group:GwObjects[] - массив подчиненных объектов. Хотя в первой версии лучше сделать поле master:GwObject - объект, которому подчинен данный. В последнем случае 1 объект может входить только в одну группу, но на безрыбье пока хватит.
* links:GwObjects[] - связи, просто связи. Связи образуют некие группы, один объект может участвовать в нескольких группах связей. Реализация тривиальна, расписывать не буду.
Методы:
* delete() - здесь объект должен поприбивать всех подчиненных (это будет сделано автоматом) и связи (аналогично).
* addson() - (решил сюда перенести, раз уж группы - здесь) - добавить подобъект (того же типа (?)).
* delson() - хез, может надо...
Task
Задача в самом общем виде. В принципе, её можно сразу и сажать в некий tasklist. Все поля (почти) тоже необязательны.
* subtype:TaskType - здесь, например, HdTask (задача HelpDesk'а) указывает свой подтип.
* author - понятно
* assignee - понятно
* created - обязательно, автомат
* deadline - понятно
* subject - обязательно
* description - понятно
* completed:bool - True - задача завершена
* result:enum(Null/ok/forward) - если задача завершена, то поле должно быть установлено - в ok, если всё чики, или в forward - если неуспешно и управление перешло следующей задаче. Вариант #2 - этого поля нет, а поле prev заменить на необязательное next - так будет лучше с т.з. неизбыточности даннных.
* prev:Task - какой задаче перешло управление по завершению данной. Обе задачи должны иметь один subtype (?). Это поле - реализация последовательности задач - об чем, собсно, и гениальность идеи - реализация бизнес-процессов как групп/последовательностей задач. По существу - однонаправленный список (хотя, может, лучше сделать двунаправленный?..)
Методы:
* delete() - здесь, ко всему прочему, надо "выкусить" себя из последовательности.
* complete() - завершить успешно. Мы не можем завершить задачу, пока не завершены успешно все подзадачи.
* forward() - завершить эту задачу, родить новую, передать ей всё, что надо - и сообщить папе (master'у группы), что мы уже не играем, мы в домике (архиве) - а за нас играет следующая задача (вот её окончания и надо ждать).
HdTask
Собсно, задача для HelpDesk. Все поля - необязательные.
* project:Project - ну или там тема, категория... Для фильтра.
* state:enum - состояние текущей задачи - в соответствии с диаграммой состояний.
* comments:txt[] - каменты.
* files:File[] - файлы.
Все поля можно указать только в главной задаче, в подзадачах - или не указывать совсем, или наследовать - кроме state (пока не решил).
Диаграммы состояний opentodo и bugzilla:
В принципе, если выкинуть справа состояние Unconfirmed (которое нужно только в public-трекерах), то диаграммы очень похожи. Ну, разве что, слева - более упрощена. Кроме того, добавим action "поцепить зависимость от другой задачи" (есть прецеденты).
Вот теперь будет use cases на пальцах.
* Юзверь создает задачу. Создается HdTask и сразу же - его первая (если не будет аварии - единственная) подзадача того же типа HdTask. Мегазадача будет ждать, пока текущая подзадача не завершится успешно. Пусть юзверь не назначил исполнителя (блондинко, куле...), подзадача будет со статусом Unassigned.
* Сисодмин видит список Unassigned-задач, назначает исполнителя. Этим он завершает задачу-сына, но не успешно, а forward: эта подзадача закрывается, открывается новая, в старой прописывается поле next, мастер-задаче вместо первой подзадачи подсовывается новая, старая уже не играет и уходит в историю. Теперь мастер-задача ждет окончания второй подзадачи. Новая задача имеет статус Assigned. Можно браться за работу.
* Исполнитель может обнаружить, что одна задача требует массу телодвижений. Не бидэ - жмем педаль "Подзадачи" - и текущая подзадача (2-го уровня) рождает несколько подзадач (уже третьего) - и будет нежно ждать успешного завершения всех из них.
* Или же исполнитель обнаружил, что ему сказали налить ведро воды, а он вчера сказал секретутке купить ведро (оракул потому что). Тогда он может повесить свою задачу в DenendsOn задаче, которую дали ему. Это разные задачи и не из одной группы - но факт имеет место быть. Тут пока плавает, на первом этапе можно похерить (возможно, лучше сделать вхождение объекта во много групп).
* Ну, пуст исполнитель тупо выполнил задачу Assigned. Жмем педаль, задача закрывается, пойвляется новая - с состоянием Resolved (Master-задаче статус не даем - она тупо ждет завершения всех подзадач - это для тех мастер задач, которые запускают сразу несколько подзадач).
* Автор проверят результат, жмет "Одобряю". Состояние новой подзадачи становится - Verified.
* Исполнитель жмет "Close". Подзадача завершается успешно. Можно вручную или или же автоматом закрыть и основную задачу. Тема закрыта.
Слайды

Addresses

2010-03-04T10:53:00.000-08:00

Начал рисовать МегаСуперБазу классов. Коих аж ДВА - 1. Контакты, 2. Задачи.
А больше ничего интересного пока нед.
В контактах вроде всё разрулил, дошедши до самого интересного - адреса.
Скачал КЛАДР - почитал - долго думал...
Резюм: а) ребята проделали охренительно огромную работу. Само ТЗ - высший пилотаж. После того, как прочитамши, что может быть адрес населенный_пункт-дом или там область-какой-то_километр_жд-будка - выпал в астрал...
б) но реализация... все эти DBF-выкрутасы с индексами в 2010-м году выглядят в лучшем случае странно...

Итого принято решение - что будем делать с Адресом:
1. адреса будут в отдельной модели, у Контактов будет сцылки на адреса.
2. база адресов - _своя_. И представляет собой одну-единственную рекурсивную таблицу.
3. но - в базе указываются "мягкие" (зависящие от страны - типо "KLADR:123456789000") ссылки на местные справочники, по которым можно проверить правильность адреса.

Слайды:

TBPD: Tasks-based Business-Processes Definition

2010-02-24T09:00:00.001-08:00

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

Суть:

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

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

Любая Задача имеет как минимум автора, дату/время создания, исполнителя, дату/время прочтения задачи исполнителем; дату/время завершения (для завершенных);
Задача может быть только в четырех состояниях: неактивная, активная непрочитанная, активная прочитанная (автомат), выполненная (с тем или иным исходом);
Состояние задачи может зависеть от состояния других Задач:

Задача может быть неактивной до тех пор, пока не будут завершены с нужным исходом другие Задачи, от которых зависит эта задача;
Активная задача не может быть завершена с определенным исходом, если не завершены с нужным исходом Задачи, от которых она зависит;

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

Примеры:

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

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

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

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

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

Идеи:

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

Пробуем raw http

2010-02-03T09:30:00.000-08:00

Идея была такая - а что, если 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

2010-01-24T13:14:00.000-08:00

Ну вот...
Замучила совесть вконец - человеку ж обещал поработать надо темой - а сам закинул, цуко... Не от хорошей жизни, а от работы - но тем не менее...
Сегодня бортанул все халтуры и немного поработал с 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

2009-10-07T12:39:00.000-07:00

Мда, забросил я было это дело...
А тут недавно обнаружил, что гугель уже прикрутил 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

2009-05-17T09:42:00.000-07:00

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

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

2009-03-31T10:23:00.001-07:00

Имеем классику 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

2009-03-01T00:36:00.000-08:00

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

$

2009-01-12T10:15:00.000-08:00

IMHO - на этом таки можно заработать.
Подписать на нормальный сервис на божеских условиях за божеские дегни.
Like (Google Apps):
* demo - ограничено + сказки (+desktop под все платформы)
* trial - Full на X дней
* и там разные схемы - от ёмкости, скорости etc.

Ибо задалбывает всё в голове держать патамушта.

ЗЫ: а это уже катит на бизнес-план... тока хрен там - йа сам :-)

Google Gears, SyncML и всё-всё-всё

2008-11-09T11:07:00.000-08:00

Ковыряюсь же ж с этим поделием - GooglePIM.
Каждый старт - медленная закачка по Atom (aka RSS) всех блогов, постов и каметов.
Порезал - чтобы по одному.
Всё-равно долго.
Ессно, возникает мисль кешировать это дело.
Вспомнив, что еще хотелось бы оффлайн работать (например - писать блоги в метро), возникает мисль локального кеширующего типа прокси-сервера...
Оформляются требования, продумывается архитектура... На всякий случай - попытка проверить - может уже умные люди что-то подобного сделали... И тут - шойтан! - всплывает Google Gears. Читаем спецификацию - точно! - то, что доктор прописал :-)
Но есть один нюанс (с) - он делает хороший занос хвоста, но политика синхронизации - каждый сам себе доктор.
Формируем себе ТЗ, определяем гениальный алгоритм синхронизации, учитываем все возможные засады... На всякий случай - может уже есть? Например - SyncML. Шойтан! - там уже всё прописано :-)

Ессно, возникает вопрос - а зачем было самотужки выдумывать свои решения, если есть готовые?
Спрашивали - отвечаем:
1. их - готовых - вагон и телега;
2. если сначала сам _допер_ как что надо делать - а потом это же прочитал в спецификациии - значит, а) ты правильно допер, и б) это - правильная спецификация.
3. когда до этого допрешь сам - та же спецификация читается совсем по-другому - не "и нафига этот цирк?..", а "ну ессно!".

синкмл синкмлом, но пока не всё так радужно.
1. SyncML очень многое оставляет на реализацию.
2. во всех 7 вариантах синхронизации сервер - активный партнер. В плане гугля последний - пассивный партнер.
3. RTM (как пример использования Gears) - штука хорошая, но они ж сам себе сервер... Активный сервер.
Вооот...

Пока что (влёт) приходят в голову только следующие варианты:
* таки да, пытаться взять на себя (сиречь - на каждое устройство) функции и кеширования, и синхронизации;
* кеширование оставить на устройстве (ессно), но сделать промежуточный сервер (GAE), реализующий SyncML-интерфейс к GData;
* иное
Для этого надо:
* поковырять Google Gears - может, расколятся, как у них там устроено?
* поковырять GData Atom - может, через Atom удастся получить _удаленные_ объекты? (это самое геморрное в этой истории).

ТЗ на JS

2008-07-04T00:31:00.000-07:00

Цель:

создание программы на JavaScript, включаемой в статическую online-страницу, для динамической навигации по ресурсам Internet.

Прототип

Данные:

xml-файл с описанием узлов/рёбер графа. Для узлов - название, ссылка, подсказка.

Внешний вид:

на странице отображается центральный узел и ближайшие связанные с ним узлы - уровень рекурсии указывается пользователем. Каждый узел - это элемент "ссылка". Если у узла (внешнего) существуют связи с узлами за пределами текущего отображения - рядом с таким узлом появляется элемент +. При нажатии на сам узел происходит переход на его URL. ПРи нажатии на + - узел оказывается в центре нового графа - со всеми вытекающими.
Размещение элементов - по алгоритму DirectGraph, но может быть изменено пользователем.

Поведение

Смена одного графа на другой - с анимацией, алгоритм которой можно будет изменять:

Удаляемые узлы - остаются на месте и постепенно исчезают;
Новые узлы - постепенно проявляются на своих местах;
Остающиеся узлы - двигаются от старых координат к новым

Рёбра двигаются за узлами. Перемещение от начального состояния к конечному - за конечное же время. Физика перемещения может быть в дальнейшем заменена.

Т.о. выделяются модули, которые можно будет в дальнейшем заменять:

data (источник данных - файл, внешний ресурс)
layout (алгоритм размещения узлов)
animation (алгоритм анимации)
view (метод отображения - html/svg/canvas)

Standalone (AKA OnPage) dynamic graph

2008-06-27T10:45:00.000-07:00

An idea is - to make 1 (one) js + 1 (one) graphml data, that:

Prototype

dynamic from-to

Functions:
- Standalone expand/collapse
- Customed speed
- Customed recurse level
- Customed Layout

Technologies:
- use pure HTML (div + position)
- Runge-Kutta lines

Pure HTML graphics

2008-06-26T01:56:00.001-07:00

Окаааазывается!
Можно рисовать графику (по крайней мере ту, что нас интересует - графы) на чистокровном HTML!
Без svg, flash, canvas и т.д.!
Показываю (в левом верхнем углу (100x100px) должно появиться сцылко node0, текст node1 и цепочка между ними):

node0

node1

Onpage vs client-server

2008-06-25T00:22:00.000-07:00

Речь о том, какой вариант навигатора делать, все-таки, первым - встроенный в страницу на JS, или же клиент-серверный.
Onpage имеет то преимущество, что его можно разместить где угодно - даже на Google pages в статических страничках. За это мы имеем:
1. заморочки с JS;
2. большой и тяжелый для браузера код;
3. инсекурность данных;
4. ограничение в применяемых инструментах - т.е. _все_ программы надо носить с собой.
С другой стороный, C-S вариант требует наличия этого самого S. Зато мы не ограничены в средствах, разгружаем клиента, сохраняем know-how.
Резюме - первым бум делать вариант C-S, рендер - graphviz, исходные данные - xml, формат вывода - svg, без анимации.

n-dimention

2008-06-21T05:51:00.000-07:00

2D-сеть для отображения - это хорошо. Но - мало.
Было бы намного презентабельней - 3D вариант.
Но этого тоже бывает мало - бывает, необходимо искать/фильтровать по
8..10..X размерностям.
Здесь можно остальные измерения обозначить другими атрибутами (а не
только связями) - цвет (заливки и границы), форма узлов, текстура и т.д.
По этим атрибутам можно как минимум фильтровать. По цвету - даже близкие
цвета (с заданной глубиной).

Net vs Table

2008-06-19T03:03:00.001-07:00

Вообще, конечно, сетевое представление данных - тоже не идеал.
Оно годится для навигации по очень разнородным данным, хитро связанным между собой.
Тогда как по однородным данным лучше, всё-таки, таблица. Тут можно быстро сравнить позиции, сортировать, фильтровать. Наглядно получается.
Пример - знаменитые краны шаровые.
Выглядеть это будет так:
1. набираем в поисковой строке "кран"
2. получаем сеть, где есть все краны - шаровые и нет, для газа и жидкости, металлические и ПЭ. Рядом - связанные понятия - среда, материал, категории (арматура) - может, человек и не кран искал, а клапан.
3. и вот теперь, когда он выберет конкретный тип крана (шаровый металлический под газ) - получает таблицу всех кранов - и ряд полей для уточнения рядом: DN, PN etc - т.е. общие атрибуты для данного типа кранов
4. Он может выбрать и 2 типа оборудования - e.g. ПЭ под газ и металл под жидкость. Тогда отображаются и те и те - с общими атрибутами.
Возможно, часть поля останется с сетью - для дальнейшей навигации и чтобы быть в курсе дела, а часть - под таблицу с выбранным оборудованием.

GooglePIM start

2008-04-07T07:06:00.000-07:00

Вот, завел новый блог - к проекту GooglePIM.
Первое приложение этого проекта - как раз работа с блогом.
GoogleAPI, конечно, рулит - потрясающе.
Еле разобрался, что куда.
В общем стартовый объект - один, назвал я его blogspot.
В нем может быть несколько блогов.
В каждом блоге - несколько постов.
Ну, и к каждому посту - несколько комментариев. На этом вложенность, слава богу, заканчивается.
На текущий момент уже получаю все блоги, посты и каменты.
Используется python и python-gdata.
Теперь это надо красиво в PyQt4 закатать - сделать дерево блогспот-блог-пост-камент.

Grouping-sorting-filtering

2008-03-15T06:12:00.000-07:00

1. Выборка осуществляется в графическом режиме, подбором "шнуров" (т.е. ребер графа) в "шнуркомплекты". Т.е. Если надо отобрать "Краны" И "DN50" - то отбираются именно эти узлы (или ребра?) в комплект;
2. Каждый пользователь может создать свою пачку шнуркомплектов;
3. Можно создать библиотеку общих комплектов (шаблонов?);
4. схема комплектов может быть сетевой (т.е. "формула" комплекта для выборки данных из сети - сама - сеть);
5. но основная схема - неизбыточна (что я имел в виду?..).

About

2007-09-01T05:12:00.000-07:00

Проект SemEn (SEMantic ENVironment) - это попытка сделать управление информацией максимально близким человеческому типу мышления - ассоциативному. Проект основан на идеях Semantic Web и Semantic Desktop, но называется Environment - т.к. Web (по смыслу) - это управление информацией в Сети, а Desktop - соответственно - на машине. Мне же хочется, чтобы пользователь не заморачивался разделением - что у него в вебе, а что - на машине (да еще знать - на какой из).
Общий смысл - создание семантического окружения - т.е. все объекты информационного поля связаны (ассоциированы) друг с другом по смыслу - а не по ключевым словам, тегам и т.д.
Т.о. поиск информации в такой системе - это проход по смысловым связям, что повторяет образ мышления человека.
По идее - должно сильно помочь.