Початок
Anton Konkevych
так минуло більше, ніж планувалося, викладаю в загальний доступ те, що обіцяв.
Зразу зауважу, що зроблено дещо менше, ніж я планував, в тому числі, від
самого веб-інтерфейсу системи є лише заготовка. Втім, архітектура проекту дещо
промалювалась, і вже є, що обговорити.
Код доступний за адресою http://code.google.com/p/citizen-
tools/source/checkout . Мова - Python, веб-фреймворк - django. Після
завантаження потрібно додати каталог, куди було скачано вихідні коди, в змінну
оточення PYTHONPATH, і створити файл конфігурації citizenwww/settings.py на
основі citizenwww/settings.py.example. На даний момент можна прогнати деякі
unittest'и та запустити веб-сервер, який поки що нічого не робить.
$ python citizenwww/manage.py runserver
$ python libcitizen/testsuite.py
Одразу вибачаюсь, що в коді мало коментарів і docstring’ів. Документацію по
архітектурі я зараз пришлю окремим повідомленням, а в вихідних кодах поправлю
днями, якщо матиму час. Також окремим повідомленням я пришлю своє бачення, що
можна робити далі.
Anton Konkevych
Дана система задумана як база майбутньої розподіленої системи, що
зумовило
деякі з архітектурних рішень, непотрібні у випадку чистої веб-системи.
2. УЧАСНИКИ СИСТЕМИ
В системі беруть участь такі сторони:
+ Платники (учасники) проекту. Приймають публічну оферту авторів
проекту та
фінансують його.
+ Керівники (менеджери) проекту. Пропонують широкому колу проект у
вигляді
публічної оферти, яка містить бюджет та цілі проекту.
+ Власники технічної площадки (хостери), на якій відбувається
взаємодія
учасників. Надають менеджерам проекту обмежений доступ до
розпорядження коштами,
зарахованими на рахунки їхнього проекту, і, таким чином, контролюють
виконання
деяких умов оферти.
+ Платіжні системи.
3. ТЕХНІЧНА РЕАЛІЗАЦІЯ
3.1. СТРУКТУРНИЙ ПОДІЛ СИСТЕМИ
Проект поділено на дві основні частини:
- код бізнес-логіки системи (взаємодія учасників). Цей код має бути
переношуваним. Він розташований в каталозі libcitizen
- код веб-системи. Являє собою фронтенд (код інтерфейсу користувача)
та бекенд
(код зберігання в БД) для попереднього пункту. Розташований в
каталозі
citizenwww. Базується на фреймворкові django.
В майбутньому можливе також написання інших версій, приміром, програма-
клієнт,
на базі тієї ж бібліотеки. Саме з цією метою бекенд (зберігання в БД)
виділено
окремо від libcitizen - бібліотека не має бути залежною від пакетів
django.
3.2. МОДУЛІ libcitizen
Бібліотека містить три основних модулі: project, user та
payment_system.
+ project - реалізує бізнес-логіку проекта, його робота
виконується від імені
"хостерів".
+ user - реалізує бізнес-логіку учасника проекту та менеджера
проекту.
+ payment_system - інкапсулює роботу з платіжними системами.
В рамках системи citizenwww весь код виконується на одній машині, а
користувачі
мають лише веб-доступ. Однак, в майбутньому планується розподілена
система, з
розміщенням користувачів та майданчика збирання коштів на (можливо)
окремих
серверах. Тому інтерфейс взаємодії користувачів між собою та з модулем
project
має зберігатися максимально прозорим і доступним для швидкого
перенесення в
RPC-інтерфейс.
Можливі варіанти розгортання системи:
Базова web-конфігурація: всі підсистеми розташовані на одній машині,
доступ до
коду роботи користувача винесено в web-інтерфейс. Перша черга
citizenwww.
Приклад: на сайті citizen.yyy розміщується майданчик, на якій
реєструються
організатор проекту та його учасники. Організатор надає оферту,
учасники її
приймають, сплачують кошти, контроль над цими коштами доступний лише
через даний
майданчик. Потім керівник проекту розпоряджується коштами для
реалізації задумів
Розподілена web-конфігурація: організатор проекту реєструється на
сайті
citizen.aaa, виставляє свій проект на оплату, після цього користувач,
зареєстрований на citizen.bbb, засобами веб-інтерфейсу своєї системи
під'єднується до citizen.aaa через деякий інтерфейс, наприклад,
xmlrpc, отримує
оферту проекту і вносить кошти. Далі, як раніше.
2-стороння: Те саме, що базова веб-конфігурація, тільки зібрані кошти
контролює
одразу організатор проекту. Може застосовуватись у випадку, якщо у
платників
довіри організатору більше, ніж довіри власникам техмайданчика.
На базі програм-клієнтів: організатор і платник мають клієнти, якими
через
вищезгаданий інтерфейс з'єднуються з техмайданчиком, на якому
організатор
розміщує проект, учасник оплачує, а потім організатор розпоряджується.
Криптографічна p2p-конфігурація: техмайданчика, як такого, не існує,
будується
крипторгафічний бекенд, який дозволяє розпорядитися коштами проекту
лише певним
чином.
3.3 ІНТЕРФЕЙСИ МОДУЛІВ libcitizen
3.3.1 Модуль project:
клас Project: реалізує бізнес-логіку проекту. Проект - це відкрита
пропозиція
(оферта) від імені організатора широкому загалу, яка полягає в
декларуванні
засобів досягнення мети (бюджету). Бачу сенс в тому, щоб
пропозиція
з моменту виставлення широкому загалу обов'язково залишалась
незмінною;
будь-які зміни до проекту (в т.ч. зміна бюджету) або варіативні
складові
(напр., виконувати розв'язку мостом чи тунелем) мають
оформлюватись як
окремі підпроекти, і платник має конкретно вказати, які варіанти
він готовий
оплачувати, а які - ні. (Поки що архітектура підпроектів не
пророблена).
Проект має один або більше аккаунтів платіжних систем, на які він
збирає
кошти, і один або більше цільовий фонд. Фонд - це базова одиниця
бюджету
проекту, яка має цільове призначення і обмеження на використання.
Проект
вважається профінансованим, якщо кошти, зібрані на рахунки
(аккаунти
платіжних систем), можуть покрити витрати всіх фондів. При цьому
мають
враховуватися обмеження коштів (скажімо, фонд, з якого проплати
мають бути
публічними, може забороняти оплату через анонімні платіжні
системи).
Приклад проекту:
Назва: проект реконструкції транспортної розв'язки А
Цілі: реконструкція транспортної розв'язки А до трьохрівневої
Очікувані результати: збільшення пропускної здатності розв'язки до
10000 авт/год.
Термін збору коштів: 01 лютого 2012 р.
Термін виконання: 01 липня 2012 р.
Бюджет:
Фонд оплати робіт:
Опис: грошові засоби для виконання безпосередніх робіт по
реконструкції
Обмеження: виведення грошей лише банківським переказом
Пункти:
витрати на проектування 1000000 грн
витрати на узгодження 100000 грн
витрати на будівництво 10000000 грн
Фонд оплати праці:
Опис: оплата праці апарату проекту. Не включає оплату
виконання
робіт з реконструкції
Обмеження: виведення грошей лише банківським переказом або
готівкою
Пункти:
- заробітна платня працівників: 50 000 грн.
- інші платежі та збори: 30 000 грн
Фонд накладних витрат апарату:
Опис: витрати, пов'язані з адмініструванням проекту
Обмеження: виведення грошей лише банківським переказом або
ч/з WebMoney
Пункти:
Оренда приміщення: ... грн
Інтернет та зв'язок: ... грн
Розробка, хостинг та підтримка сайту проекту: ...
грн
Інше:
Опис: інші витрати, пов'язані з проектом:
Обмеження: виведення ч/з будь-яку платіжну систему, не
більше
1000 грн за один платіж
Пункти:
реклама, медіапідтримка ... грн
витрати на компенсації зацікавленим
та постраждалим сторонам ... грн
Резервний фонд:
Опис: для непередбачених витрат
Обмеження: переведення коштів лише у інші фонди даного
проекту
Пункти:
резерв: ... грн.
Методи та властивості класу:
get_name(self)
set_name(self,user,name): назва проекту. Всі функції, які
виконують дії,
які потребують авторизації, приймають параметром об'єкт
"користувач" для
перевірки допустимості дії.
owner(self) користувач-організатор проекту
get_state(self),flow(self,user,new_state): стан (стадія) проекту:
готується,
збір коштів, повернення коштів, реалізація, завершено, невдача,
опубліковано звіт.
get_obligation_text(self),set_obligation_text(self,user,obligation_text):
текст оферти - юридичні зобов'язання організатора перед
учасниками
get_goal_declaration(self),set_goal_declaration(self,user,goal_declaration):
задекларована автором мета проекту
get_expectancies_declaration(self),set_expectancies_declaration(self,user,
expectancies_declaration): заплановані результати проекту
funds[] - фонди (бюджет) проекту
accounts[] - рахунки (на яких зберігаються гроші) проекту.
funds[].restrictions: технічні обмеження, накладеня на
розпорядження
коштами проекту
get_full_offer(self): повний опис проекту, включно з
зобов'язаннями та
деклараціями, у текстовому вигляді
Клас ProjectManager: представляє об'єкт, який завідує створенням,
знищенням та
доступом до всіх екземплярів класу Project
Клас Fund: представляє фонд (елемент бюджету) проекту. Підклас
BudgetLine являє
собою структуру - строку бюджету. Клас Fund містить список строк
бюджету
свою назву та обмеження, накладені на розпорядження грошима.
Клас ProjectRenderer: інкапсулює переведення об'єкту "проект" в
вигляд,
придатний для читання людини - текстовий. Також надає конкретні
формулювання
стандартних текстів, вжитих при цьому переведенні. Ці формулювання
мають
бути попередньо підготовані юристами і запропоновані організатору
на етапі
планування проекту. Організатори можуть використовувати різні
варіанти
формулювань, для цього їм будуть запропоновані пресети,
реалізовані у вигляді
різних ProjectRenderer'ів. Можливо, назва класу не найвдаліша,
буду радий
альтернативним пропозиціям.
3.3.2 МОДУЛЬ user
Клас User: бізнес-логіка учасника або менеджера проекту (учасника
системи)
full_name - ім'я людини
login - ім'я облікового запису в системі
bookmarked_projects,shareholded_projects,managed_projects -
відповідно
проекти, відмічені користувачем, проекти, які він оплатив, і
проекти,
якими він розпоряджується
create_project() - ініціювання проекту
participate(), sponsor() - оплатити проект. Друга ф-я
застосовується для
оплати без обов'язкового moneyback. Це може застосовуватись
для
анонімних платежів або часткового фінансування проекту самими
організаторами
Клас Usermanager: представляє об'єкт, який завідує створенням,
знищенням та
доступом до всіх екземплярів класу User
3.3.3 МОДУЛЬ payment_system
Клас PaymentSystem: описує платіжну систему
get_new_account() - створити новий (порожній) обліковий запис
get_existing_account() - створити об'єкт на базі існуючого
облікового запису
платіжної системи (наприклад, додати до системи рахунок,
створений
програмою-клієнтом платіжної системи, або передати системі
реквізити
платіжної картки Visa).
Клас PaymentSysAccount: обл. запис системи (рахунок).
summ - сума на рахунку
acc_type - тип рахунку. Використовується для контроля сумісності
рахунків
can_receive_from() - чи може отримувати платежі з рахунків певного
типу
pay() - оплата
get_invoice() - видає інформацію, потрібну платнику, щоб
перерахувати гроші
на даний рахунок. В деяких платіжних системах без цього
неможливо
прийняти платіж
pay_invoice() - оплата вищеописаного інвойса
4. ЗАУВАЖЕННЯ
1) Пріоритетом проектування системи була можливість максимально
швидкого
отримання працездатного макету з урахуванням можливості подальшого
розвитку.
Саме тому код бекендів (зберігання інформації про учасників та проекти
в БД) не
був внесений до libcitizen. Концептуально це зробити варто, але поки
що
найшвидшим шляхом отримання результату є використання django models.
Зі згаданих
вище міркувань цей код не був внесений до libcitizen, що не
перешкоджає, однак,
в майбутньому включити до неї власний бекенд.
2) З подібних міркувань в проекті не згадуються спілки та форум МС. Я
взагалі
сумніваюсь в потребі внесення коду форуму до libcitizen. Спілки - інша
справа,
але їх також можна відкласти до другої черги.
Anton Konkevych
що в запропонованій архітектурі варто обговорити і виправити перш, ніж
рухатись далі. Думаю, тижня цілком вистачить на з’ясування цих питань, і тоді
подивимось, чи є сенс рухатись далі і в яких напрямках.
Очевидний перший milestone - система в об’ємі "зареєструвався - створив проект
- задав бюджет - виставив на оплату - прийняв оплату - вивів кошти - написав
звіт". Другим, як на мене, має бути нарощування функціоналу в напрямку
детального бюджетування, потім субпроекти (як у вигляді опцій, пропонованих
від початку, так і у вигляді додаткових затій, що виникають під час реалізації
проекту), далі - форум і спільноти. Паралельно має йти розвиток ядра системи у
напрямку контролю виконуваних операцій - на даний момент контроль дуже
спрощений.
Пропоную наступні правила ведення проекту:
Система керування версіями - GIT, Оскільки у ньому робота з гілками дуже
проста, пропоную одразу кожному розробнику вести свою гілку, причому, бажано,
заливати її на сервер. Моя гілка зветься ichthuss. Зливати гілку в master
(головну гілку) новий код - лише після проходження тестів. При суттєвій зміні
інтерфейсів классів, думаю, варто перед злиттям викласти код на сервер,
написати повідомлення з описом пропонованих змін, і зачекати зауважень або
заперечень. Теж саме щодо рефакторингу коду, особливо чужого.
German Zhivotnikov
eduard_k
DoctorX
>>необходимо сразу проектировать распределенную децентрализованную системуХм... Если бы вы смогли запустить эту систему в режиме веб-доступа - она бы уже смогла приносить пользу. Разверните тестовую версию и мы готовы смириться с её глюками.Для разработчиков это возможность наращивать функциональность системы в режиме обратной связи с потребителями.
--
©
Anton Konkevych
kirand
German Zhivotnikov
German Zhivotnikov
Anton Konkevych
> А подскажите, пожалуйста, что нужно сделать для создания структуры СУБД?
python citizenwww/manage.py syncdb
Це автоматично встановить базу. Перед цим потрібно ввести налаштування
СУБД у файлі settings.py . Також можна виконати
python citizenwww/manage.py sqlall ctzsite
- видасть структуру БД у вигляді SQL-коду.
Anton Konkevych
> Не могли бы вы еще раз написать что откуда качать и как запускать. Или стоит
> дождаться веб-версии?
Фактично, протестувати там щось складно по причині відсутності UI - є
лише голі інтерфейси. Можна програти автоматичні тести, можна також
дописати свої тести. Для цього потрібно:
1. Скачати вихідні коди. На сторінці checkout на гуглькоді є детальні
інструкції.
2. Додати адресу, куди поміщені вихідні коди, в змінну оточення
PYTHONPATH. Скажімо, у мене вдома вихідні коди розміщені за шляхом
/home/anton/soft/citizentools/repo/ . Тому я дописав такі дві строчки
в ~/.bashrc :
PYTHONPATH=/home/anton/soft/citizentools/repo/
export PYTHONPATH
Можна ці строчки виконати вручну, але це діятиме протягом одного сеансу.
Для Windows детально не підкажу, але ось є інструкція:
http://docs.python.org/using/windows.html . Знову ж таки, потрібно в
змінну PYTHONPATH прописати адресу, куди розміщено вихідні коди.
Для запуску тестів (Linux):
$ cd /home/anton/soft/citizentools/repo/
$ python libcitizen/testsuite.py
В Windows аналогічно, тільки змінюється шлях до кодів і до
інтерпретатора python.
Ще можна запустити тестовий веб-сервер, який поки що не надає ніякого
доступу до системи. При цьому має бути встановлений django. Найперше,
потрібно створити файл citizenwww/settings.py на базі
citizenwww/settings.py.example. Потім можна виконати:
$ cd /home/anton/soft/citizentools/repo/
$ python citizenwww/manage.py runserver
Після цього можна звернутись до веб-серверу за адресою http://localhost:8000/
Якщо виникнуть питання, звертайтесь.
Anton Konkevych
German Zhivotnikov
eduard_k
Владимир Золоторев
отсутствуют сообщества. Сообщества а) имеют в рамках нашей сети свою
страницу бюджета для регулярных целей (например, бюджет кондоминиума
или сетевого общества социального страхования); б) могут предлагать
проекты от имени сообщества. В этом случае получателем денег является
частное лицо-участник сообщества, однако такой проект позиционируется,
как проект сообщества.
> ...
>
> продолжение >>
Владимир Золоторев
проектов)))
On 3 авг, 06:05, eduard_k <eduard.kurgans...@gmail.com> wrote:
> Я не оспариваю необходимость закладывать децентрализованную архитектуру на
> этапе проектирования системы. Я лишь обсуждаю алгоритм разработки системы.
>
> Я призываю разработчиков БЫСТРО сделать что-то простое, чем уже можно
> пользоваться (одну систему на одном сервере под одного заказчика с
> веб-доступом). Далее наращивать функциональность системы с учётом обратной
> связи с реальными пользователями. И привлекать в группу новых разработчиков
> благодаря рекламе системы, которая будет исходить от первых пользователей.
>
> Мы не можем сейчас предсказать что окажется наиболее важным для
> второй итерации - система защиты от DDOS, или редизайн UI, или .... Но в
> ходе первой итерации вопросы безопасности и децентрализации можно обойти
> организационно - надо просто ограничиться некоей закрытой группой
> пользователей которые будут использовать систему для своих внутренних
> потребностей. Выбрав в качестве тестовой "не агрессивную группу" и
> заручившись поддержкой её лидеров можно не переживать, что система "будет
> конкурировать с кем-либо/чем-либо".
>
> В качестве альтернативы/дополнения к уже предложенной группе "Вільний
> простір" могу предложить группу Polit Club<http://www.facebook.com/uapolitclub>.
kirand
вторник, 2 августа 2011 г. 17:22:49 UTC+3 пользователь Ichthus написал:
> Я, честно говоря, не понял как тестить.
> Не могли бы вы еще раз написать что откуда качать и как запускать. Или стоит
> дождаться веб-версии?Фактично, протестувати там щось складно по причині відсутності UI - є
лише голі інтерфейси. Можна програти автоматичні тести, можна також
дописати свої тести. Для цього потрібно:1. Скачати вихідні коди. На сторінці checkout на гуглькоді є детальні
інструкції.
Command-line access
Get a local copy of the citizen-tools repository with this command:
DoctorX
DoctorX
Anton Konkevych
> Если бы я еще что-то в этом понимал... В участниках системы
> отсутствуют сообщества. Сообщества а) имеют в рамках нашей сети свою
> страницу бюджета для регулярных целей (например, бюджет кондоминиума
> или сетевого общества социального страхования); б) могут предлагать
> проекты от имени сообщества. В этом случае получателем денег является
> частное лицо-участник сообщества, однако такой проект позиционируется,
> как проект сообщества.
В даному випадку під учасниками системи мались на увазі люди та/або технічні
засоби, які можуть обмінюватись інформацією з системою. З цього погляду спілки
не є учасниками системи, вони є групами, в які вступають учасники системи,
тобто користувачі. А так, звісно, спілки мають бути. Хоча для мене самим
неясним залишається питання внутрішньоспілкової організації (окрім, власне,
проектів). Мені здається, що система має бути маштабована, тобто "україна-2.0"
має бути просто глобальною спілкою в рамках системи. І от тут не зовсім ясно,
якими обирати засоби внутрішньоспілкової демократії: "один учасник - один
голос" чи якісь альтернативи (скажімо, для ОСББ - згідно з долями власності).
Владимир Золоторев
универсальные задачи, которые приходится решать именно сообществам.
Например, бюджет, проекты и голосование. Сами сообщества могут быть
организованы так, как им захочется
eduard_k
вторник, 2 августа 2011 г. 1:34:59 UTC+3 пользователь Ichthus написал:
2. УЧАСНИКИ СИСТЕМИ
В системі беруть участь такі сторони:
+ Власники технічної площадки (хостери), на якій відбувається
взаємодія
учасників. Надають менеджерам проекту обмежений доступ до
розпорядження коштами,
зарахованими на рахунки їхнього проекту, і, таким чином, контролюють
виконання
деяких умов оферти.+ Платіжні системи.
При этом, возможно, теряется "прямой контроль" за счётом. Но а) это очень упрощает старт системы, б) остаётся возможность контроля за соблюдением условий руководителем проекта и остановки его финансирования через публичное распространение информации о нарушениях среди участников системы.
Anton Konkevych
> Немного не ясно с владельцами технических площадок:
>
>
> Т.е. это своего рода банки? Они дают доступ к деньгам?
> Не проще ли систему интегрировать с существующим веб-банкингом (Приват24,
> ПУМБ) и Webmoney? Т.е. полный доступ к управлению деньгами имеет менеджер
> проекта, а техническая площадка может получать всю информацию о движениях по
> счёту через API.
> При этом, возможно, теряется "прямой контроль" за счётом. Но а) это очень
> упрощает старт системы, б) остаётся возможность контроля за соблюдением
> условий руководителем проекта и остановки его финансирования через
> публичное распространение информации о нарушениях среди участников системы.
Власник техмайданчика володіє секретними реквізитами доступу до
рахунків і надає обмежений доступ до розпоряждення рахунком. Фактично,
він не є банком, гроші лежать в справжньому банку (або платіжній
системі), він є розпорядником коштів, що діє згідно з інструкціями
організатора проекту і згідно з обмеженнями, накладеними на
розпорядження ними угодою між організатором та платниками.
Щодо того, що для старту проекту краще не заморочуватись, я згоден.
Для цього може використовуватись спеціальний тип "рахунків" системи:
приміром, рахунок з неексклюзивним доступом, або рахунок без доступу
системи до нього. При цьому в першому разі платникам видається
повідомлення, що система технічно нездатна накласти обмеження на рух
коштів по рахункам, лише відображувати цей рух; у другому - що система
не може ні обмежувати, ні відслідковувати рух коштів, і вся
відповідальність лежить на організаторах проекту. Тобто цей
стартаповий варіант - частинний випадок описаного.
Anton Konkevych
German Zhivotnikov
Владимир Золоторев
"устава" сообщества.