В том-то и дело, что я даже запустить прогу не могу свободными средствами. В OpenOffice можно подключиться к mdb-шкам через ODBC. И ффсё. Несвязанные таблички. Через ODBC можно подключиться из Питона, но, похоже, проще создать новую оболочку, чем переделывать из Access.

Могу "питонизировать" идею как быстрый прототип. Но нужно что-то типа ТехЗадание. Без ТЗ все наши разговоры - пшик.

У меня нет ТЗ. У меня ХЗ. Сами посудите.

Техническое задание (?) на разработку программного обеспечения для проекта “Омега».
Проект должен быть разработан на механизме Google Apps.
Пользователь может сам создавать классы учета при помощи конструктора классов или описывая его с помощью XML. Программа должна формировать форму ввода объекта класса, форму просмотра и редактирования (если это ему доступно), а при необходимости.
Система состоит из объектов и связей их друг с другом. Связь – это тоже объект, но специфический. Объекты могут появляться и исчезать, но в базе данных физического удаления объектов и информации о нем не происходит. Делается только отметка о том, что объект удален и временная отметка когда это произошло. Ну и когда создан тоже. Существует корневой объект – Система, который изначально порождает объекты. В дальнейшем объекты могу порождать другие объекты или изменять их свойства.
В систему встроены некоторые классы, с предопределенным поведением. В их число входят такие классы как: человек, цель, бухгалтерский счет, денежная транзакция, организация, запись в дневнике и пр.
Свойства объектов – это все что угодно: числовые данные, текстовые, описание поведения (методы). В системе ведется летопись какой объект когда что создал или изменил или удалил. Таким образом всегда можно выяснить, что происходило и происходит и кто в этом виноват ).
Все объекты в системе пронумерованы уникальным счетчиком.
У каждого объекта есть набор свойств. У каждого объекта должна существовать форма для создания нового объекта, просмотра, редактирования существующего объекта.
В системе каждый объект порожден, каким либо другим объектом.
Первые объекты системы – пользователи. Их порождает Система. Пользователи создают классы объектов, описывая их через определенный интерфейс (как вариант в виде XML документа). После создания описания класса, можно создавать объекты этого класса.
Любые два объекта можно связать с друг другом связью с «биркой», т.е. с указанием типа связи.
Некоторые классы объектов уже смоделированы мной.
В моей системе не реализована фишка «Летопись».

Они и должны быть несвязанными. Они связываются по-другому. Это хранилища экземпляров классов.

Выдалось свободное время.
http://narod.ru/disk/14329611000/presentation1.wmv.html
http://rutube.ru/tracks/2516665.html...584d618adc2313

http://rutube.ru/tracks/2516818.html...39b422f623591c
http://narod.ru/disk/14330891000/presentation2.wmv.html

Дайте, пожалуйста обратную связь по презентации

http://narod.ru/disk/14923704000/illustation1.pptx.html

Интригующе! Но кто не в теме, вероятно, ничего не поймёт.
Надо с дизайнерами поговорить, чтобы они помогли дать более чёткие и яркие образы того, что хотел донести автор.
Также можно дополнить презентацию тезисами (на вкладке примечаний) для уточнения смысла.

Кстати, для примера, онлайн игра про развитие местного сообщества http://www.socialtradegame.org/.

Спасибо за обратную связь, поработаю еще над презенацией. Скоро будет все очень понятно (надеюсь). Много образов в голове, сразу не переведешь в рисунки и текст.

Соратники. Дайте, пожалуйста, обратную связь по слайд-шоу
http://www.slideshare.net/glotis/descipline1
Это слайды для презентации среди учителей начальных классов.
Слайды не дублируют текст презентации, они его дополняют.

Второй выпуск начальной школы управления
http://vkontakte.ru/photo-10864662_147367058

Юрий Юрьевич, есть некие мысли. Интересно ваше мнение:

Все мы знаем, что деньги суть эквивалент цего-то ценного и придуманы для удобства товарообмена. Отказаться от денег сразу нереально. Да вообще-то и не обязательно. Если не включать печатный станок , когда душе угодно, то денежная масса в идеале будет сохраняться. В замкнутой системе при избытке того-или иного товара начнет падение цены вплоть до ее обнуления. Что мешает реализации такой системы?
Первое, что надо сразу запретить - это частичное банковское резервирование и любой ссудный процент. Посредством частичного резерва денежная масса не остается постоянной, а постоянно увеличивается. Ну а процент - это узаконенный грабеж. Но самое главное, что нужно реализовать в этой системе - это "пилюлю" против лжи. Ни один из участников системы не сможет:

1. технически добавить себе денег (даже хакнув другого и сохранив балланс денежной массы)
2. контролировать некий сервер, где лежат счета каждого члена системы
3. войти в сговор с группой для махинаций.

Денежная масса на момент старта системы фиксирована и не меняется ни при каких условиях в будущем. Например "кокосовый миллиард"

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

Итак остров Чунга-Чанга с 1000 жителями и местной комп. сеткой. Вождь постановил каждому заложить по 1 000 000 виртуальных "кокосов". Осталось придумать систему и запустить.
Предлагайте именно технологии. Хотя бы в общих чертах.

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

Чтобы такого не происходило нужно взимать налог за хранение денег (демередж). Т.е. если деньги поступили на счет и лежат там больше месяца, то с них берется налог.

На счет "буказоидов" я высказывал свое мнение в ветке про концептуальные деньги. Идея отличная, базовый принцип реализации заложен в "Омеге", но это все нужно переложить на веб-интерфес. Наверное, самое простое решение php+mySQL. И тут сразу отпадут все вопросы об имитаторах-провокаторах и прочее. Кто решит участвовать в системе и будет ее использовать в расчетах между участниками - тот поддерживает идею открытости, и уже вправе вносить конструктивные предложения по развитию системы на основе действительной обратной связе. Остальные же - проходят мимо.
Демередж, я считаю обязательным. Это заставит мысли крутиться в направлении "куда потратить средства с наибольшей пользой". Но для кого-то это будет сликом круто. Опять же нравственный фильтр.
Но помимо движка, нужны еще "шлюзы", я об этом говорил. Т.е. участник системы, который производит обмен КД на текущую валюту. Такой шлюз должен быть в каждой территориальной единице, где есть участники. Скажем, если будут шлюзы в Москве, Питере, Сочи, Новосибирске, то я, например, из Сочи смогу оплатить услуги какого-участника в каком-либо другом городе и он сможет их при необходимости перевести в текущую валюту.

.
Тогда встает вопрос о том у кого будет находиться первичная база данных? И как не крути, рано или поздно этим начнут злоупотреблять.

Необходимость неизменность денежной массы дает абсолютную гарантию от многих бед и простой способ проверки законности прохода платежей.

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

Смотрим:
Финансовая элита скупает КД и закрывает "лавочку". Может лучше внедрить это в достаточно большой ячейке. Например в экопоселениях с последующей интеграцией с подобными поселениями и объединением денежной массы. Причем "грязные" деньги никто не отменяет. Они отвалятся сами по себе, когда необходимость в мировой фин. струкутре отпадет.

Правильно. И этот налог равномерно распределять среди участников. В таком случае при выходе участника из системы его деньги не утекают в никуда и балланс сохраняется.

Система (буду называть ее далее ФСЧЧ:)) должна развалить нынешнюю постепенно и изнутри.
Не должно быть никаких курсов обмена на нынешние деньги(как в онлайн РПГ проектах например).Начать можно например с торговли всякими не особо нужными вещами(книги, диски, б.у. вещи). Некая "ФСЧЧ онлайн барахолка". Постепенно ассортимент будет сам собой расширяться и доверие к КД возрастет и люди начнут ими пользоваться. Вначале это группа энтузиастов которые получают сразу на счет N КД. Далее при достижение количества участников некого числа. Денежная масса замораживается и больше не меняется НИКОГДА. Новые участники получают КД только продавая услуги или товары и тем самым вливаются в систему.
Некие псевдосистемы уже есть и работают. Например сайты знакомств, однокласники итд. Там за реальные деньги продают всякие "фантики-срантики" за которые можно поиграть, украсить свою анкету, прикупить новый смайлик и т.п. Только там вся это система принадлежит владельцам сайта и они могут сделать все что угодно.

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

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

Зачем копить? Почему сразу не инвестировать, частями в рассрочку и т.п.?

Это все детали. Давайте не будем думать о дверном глазке, когда еще нет чертежа дома. Банальное решение - налог идет в ту клинику, где его будут оперировать.

Самое сложное создать абсолютно неподкупную и честную систему взаиморасчетов. Вот что мне ответил один человек на другом сайте:

Я о приведенной выше технологии ничего не знаю, и даже представления не имею как к ней подступиться. А говорю я всегда о том, что мы даже на том же php и mySQL ничего сделать еще не можем, а замахиваемся на какие-то огомные проекты.
Взять, например, мою программу - хоть кто-нибудь не счел за труд ее установить и начать ее "ковырять"? Вопросы мне позадавать, что да как. Глядишь я бы и инстркуции понемногу набросал и пр. Нет, таких не нашлось. Поэтому делать надо то, что можно делать в текущей ситуации и с теми кадрами, которые мы имеем. Совершенно очевидно, что в этом проекте смогут учавствовать только энтузиасты, да и те, только те, кто может держать цель.
К сожалению я не знаю ни одного ООЯП, но пока обладаю некими ресурсами в области хостинга и разработанной архитектурой управления целями и учета денежных средств. Пользуйтесь. Начните с малого - зделайте аналог каких-либо электронных денег на самом доступном движке. После этого многое прояснится. А так - это все благие намерения, которым известно куда дорога выстлана.

Почему на этом форуме часто вспоминают в первую очередь именно PHP? Нет, ну я понимаю, было время, когда в институтах работали косномыслящие преподаватели, однажды и на всю жизнь освоившие только один язык программирования Pascal, что породило неслабую волну Delphi-программистов, панически боящихся ступить шаг в сторону от VCL и Windows, и зачастую даже не подозревающих, что существуют кросс-платформенные реализации языка Object Pascal, не привязывающие разработчика к одной платформе и одному фреймворку.

Но на дворе 2010 год. Как насчёт Ruby? На мой взгляд, очень перспективный язык, учитывая какими мотивами руководствовались разработчики - не допиливать безконечно язык сценариев для персональных домашних страниц (PHP == Personal Home Pages), а разработать изначально универсальный объектно-ориентированный язык, дружественный для разработчика и особенно - для команды сопровождения. И при этом незаангажированный (в отличие от C# и Java) в пользу какой-либо корпорации.

Это я говорю к тому, что лично я не не могу сделать что-либо на PHP, а просто не хочу этого делать. Ruby пока в процессе освоения. Но я не парюсь по этому поводу. Если начать сегодня (на мой взгляд, довольно грамотно написаны учебники от Dave Thomas "Programming Ruby" и "Agile Web Development with Rails"), то через год-два можно будет делать что-среднее, а потом и побольше. А если не начать - то через год-два будет всё тот же PHP+MySQL или, как популярная альтернатива - C#+M$.

После отступления от темы, хочу вернуться к проекту "Омега".

Программа запускается и под Microsoft Works (который включает в себя Access), которая часто поставляется вместе с ноутами и Windows Vista.
Тем не менее попадаются битые ссылки на файлы, лечится комментированием части строчек.

Сама система довольно аскетична и без знания Access и VBS разобраться (а точнее починить какую либо мелочь) будет непросто.

Архитектурно выполнена просто: панель с кнопками и обработчиками на VBS для каждой. Множество таблиц и отчетов. Сейчас разбираюсь методом тыка и изучаю код. Вариант переноса вижу как экспорт всех модулей в отдельные файлы с последующим переводом на другой язык и сборкой обратно. В коде модулей есть комментарии разработчика.

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

Пробую применить для простых задач, по результатам выложу комментарии подробнее.

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

А время это наступило очень быстро, когда количество целей превысило сотню. Вот тогда-то я и задумался над тем, как же правильно расставлять приоритеты. Ведь между приритетом, например 75 и 76 разница небольшая. И тогда немного изучив тему и вспомнив что говорил Петров в лекциях об огромном векторе государства, я подошел к реализации такого понятие как "дерево целей".
Его я реализовал в простейшем варианте, т.е. несмотря на то, что некоторые цели могут быть отнесены к нескольким объемлющим целям, я это сознательно упростил, т.к. механизм реализации сложного дерева для меня не ясен.

Для реализации механизма дерева целей нужна корневая цель. Ее выбор, конечно, строго субъективен, но для автосинхронизации она должна быть единой. Поэтому я предлагаю всем соратникам устанавливать единую для всех коренную цель. Лично у меня эта цель - переход человечества к III-типу цивилизации. (См. квалификацию здесь http://www.world-goals.info/universe/ в разделе "Гибель цивилизации".
Я выбрал эту цель не смеха ради, а как достаточно большую и находящуюся за пределами жизни (читай В. Тарасова "Книга для героев") и как определяющую концепцию жизнеустройства в пределе - для того, чтобы человечество перешло к третьему типу цивилизации, ему явно надо преобразиться и как минимум придти к человечеству. Поэтому "Переход человечества к человечному строю психики" - всего лишь подцель вышеуказанной объемлющей цели. Как бы это не выглядело, но всех кто приемлет для себя такую цель заявляет о приверженности концепции устойчивого развития человечества, а не "после меня хоть потоп".
Но ставить такие большие цели совсем не обязательно. В любом случае нужно выбрать какую-то корневую цель, чтобы начать формировать дерево из уже существующих "свободных целей".
Что касается интерфейса - чтобы зарегистрировать цель в системе нужно нажать на кнопку с изображением карандаша и заполнить два поля:
Краткое описание цели и более подробное ее описание. Например, краткое описание - позвонить тому-то. А в подробном - по поводу того-то. Краткое отображается в векторе, поэтому должно быть довольно кратким. После регистрации все "свободные", то есть не привязанные к дереву цели можно увидеть нажав на кнопку с изображением полосатого стакана "Множество свободных целей".
Чтобы зделать цель корневой, нужно в поле уровень указать 1 и в поле "объемлющая цель" указать 0.

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