ermouth | media-bis 3 (Reply)

Я начал переделывать свой пульт управления бизнесом. Полностью, с нуля. Это будет версия 3. Версия 1 закрылась на 1.1429, версия 2 – на 2.209. Вот первый скриншотег с айпада альфа-версии) Клик – в полном разрешении, довольно адовом бгг

База, естессно, тестовая. Как это устроено (реально XXI век):

Старая система, привязанная к Виндовс-серверу и InfoPath, достигла потолка развития. Дальше не пускает платформа – в текущем виде это виндовые приложения и набор служб-роботов, и всё это через веб работает только в RDP-сессии. Старая система сейчас выглядит примерно также, как и на этом скриншоте, сделанном в 2008:

А хочется в браузере, с айпада там. С нативными фичами айпада – чтобы заметочки там делать рукописные, контролы родные, дизайн под пальцы…

Начал я 1 августа, как из Питера прилетел. У меня как раз там за дорадой и фруктами очень хорошо думалось.

За прошедшие почти 4 недели система пришла в состояние рабочей бета-версии, сделано два приложения из примерно 20-25. На сейчас это устроено так:

CouchDB, перед ним Апач со статическим контентом
Javascript-приложение в клиентском браузере, управляющее исполнением других приложений

Про CouchDB

CouchDB – очень необычная БД. Это NoSQL-хранилище json-документов со встроенным версионированием и контролем доступа. По сути, CouchDB обеспечивает выборку за счёт выполнения map-reduce функций пользовательских над огромным набором json-узлов.

Сам CouchDB написан на Эрланге, а map-reduce функции выборки (аналог SQL-запросов в некотором смысле) пишутся на… javascript.

Понятия join нет вообще, зато есть условная репликация. Consistency обеспечивается версионированием – то-есть блокировки при обновлении не происходит, отдаётся просто предыдущая версия документа.

Ресолв конфликтов сохранения лежит на отправителе. Он при сохранении должен отправить номер версии документа, которую он собирается обновить, и если эта версия не последняя, сервер сохранять откажется.

Замечу, что работает это всё для такого набора технологий исключительно, невероятно быстро. Ключевые функции выборки компилируются, результаты их работы индексируются в момент сохранения. То-есть, при сохранении документа в базу к нему поочерёдно применяются все определённые для него map-функции, результаты их работы индексируются в B-tree и служат потом ключами.

Про клиентскую часть

Главное архитектурное соображение, что я применил, я услышал в лекции Дугласа Крокфорда, чувака, который придумал json. Крокфорд предлагает считать яваскрипт-движок виртуальной машиной для js-приложений, совмещённой с системой доставки этих самых приложений (ajax).

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

Кста применение лексических замыканий и прототипов по-правильному полностью снимает необходимость во всяких объявлениях типа public static final. Замыкание само рассказывает окружающему миру, что он может увидеть внутри этого замыкания.

Именно так и устроена моя платформа. Она исполняет загружаемые из БД экземпляры приложений внутри замыканий и предоставляет им некий общий локальный сторидж, “BIOS” для записи-чтения данных и “GDI” (набор jQuery-плагинов и всяких вспомогашек). То-есть приложения – это такие-же документы в БД, как и данные.

Приложения слабо связаны – то-есть я эксплуатирую Unix-принцип (он же принцип построения iOS-экосистемы) “много слабо связанных программ для разных функций, каждая программа реализует что-то одно, но очень хорошо”. Слабая связанность позволяет загружать их по запросу и успешно исполнять сложную довольно систему на мобильных устройствах.