Couchbox

Jul. 27th, 2017 03:52 am
ermouth: (Default)

Месяц назад мы запустили публичную бету vezdelegko.ru, сервиса бронирования экскурсий, отелей и транспорта. Сервисы бронирования – сами по себе штука сложная, это как магазин, по которому надо вести учёт ассортимента на каждый день, причём ассортимент день ото дня меняется и цены зависят от дня и количества. Причём в магазине куча отделов, и партнёры сами управляют своим ассортиментом.

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

Снимок экрана 2017-07-27 в 2.26.24

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

Code follows data

Нативная CouchDB хранит в базах не только данные, но и код для predefined map/reduce запросов, по которым строятся высокоэффективные persistent индексы. Этот код, на JS или Erlang, хранится в документах рядом с данными и может распространятся между узлами в тех же потоках репликации, что и сами данные.

Couchbox, наша платформа, расширяет это всё механикой хуков, реагирующих на изменения документов в базе, и эндпоинтов – REST–концов, обрабатывающих входящие запросы через https. То-есть в те же специальные документы, где в обычной CouchDB живёт код функций индексов, для Couchbox-а можно добавить ещё и код функций хуков и внешних REST API эндпоинтов. Получается распределённая платформа приложений.

Особо примечателен факт, что с точки зрения установленного софта узлы не различаются вообще.

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

Файлы – это очень скучно

Важный момент, как именно код функций попадает в БД.

Код лямбд вообще не существует в виде исходных файлов. Он создаётся в специализированной среде разработки, основанной на CloudWall и Ddoc Lab. Выглядит это примерно так:

Снимок экрана 2017-07-27 в 3.52.11

То-есть, сорцы, из которых собираются лямбды, хранятся в PouchDB в браузерах разработчиков, реплицируются в CouchDB на какой-то из узлов, собираются, а затем распространяются по остальным узлам.

Деплой обновлений и скорость разработки

Такая архитектура расслаивается на три части по критерию обслуживания:

  1. Убунта, CouchDB, Redis, node.js и nginx – фундамент со временем между рестартами в месяцы. Для обновления или рестарта фундамента нужен доступ к каждому узлу через терминал.
  2. Couchbox – платформа приложений с временем между обновлениями сейчас в недели, скоро станет в месяцы. Разрабатывается на файловой системе в обычных IDE, для обновления на узлах нужен доступ через терминал.
  3. Код приложений, очень гибкий, может обновляться и дополняться с высокой частотой. Для разработки и отладки как клиентской (UI), так и серверной части (REST API) приложений не нужно ничего, кроме браузера. Код деплоится по узлам автоматом.

Общий объём кода, написанного в браузере для этой системы, перевалил за 100К SLOC и пока всё просто прекрасно. Стартскрин бэкэнда выглядит сейчас вот так:

Снимок-экрана-2017-07-27-в-4.29

Я, в общем, доволен – это самая сложная штуковина, которую я когда-либо придумывал, и её получилось не просто сделать как задумано, но ещё и в плановые сроки почти уложиться. Как с самой платформой, так и с приложениями на ней.

И да, Couchbox is MIT licensed. Опенсорц наше всё.

ermouth: (Default)

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

Couchapp – это когда есть CouchDB, и она для всего, а больше кроме CouchDB ничего и нет. Я в чистом виде так ещё не делал, всегда был node.js ещё как минимум. В этот раз node.js нет, но в архитектуру couchapp добавлено два слоя – JS rewrite на сервере и PouchDB на клиенте.

JS rewrite, только появившийся в CouchDB 2.0 моими и @kxepal трудами, позволяет делать сложный раутинг прямо внутри БД. То-есть кастомные API, access control и тп.

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

Архитектура одного узла выглядит так (может быть из одной, двух или трёх физ. машин):

Read more... )
ermouth: (Default)

Написал длиннющий пост про isomorphic apps – и у меня впервые за тыщу лет выпал LiveWriter, причем сразу с XP (да-да, я для LiveWriter-а спецом держу под Parallels-ом Windows XP, заодно там тёплый ламповый IE8 для тестов).

Наверное, это мне вселенная так говорит, что надо покороче написать пост )

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

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

Причин такого подхода две:

  1. Для рендера документа в ~статический HTML нужно гораздо меньше кода, чем для редактирования этого-же документа. Стало быть, “серверная” версия приложения может быть проще и быстрее – например, нам незачем обрабатывать события, поэтому код может быть синхронным.
  2. На бэкэнде (который offline ready) и в публичной части существенно различаются способы адресации бинари-ресурсов (картинки, документы для скачивания и тп). Картинки в режиме редактора, например, имеют уникальные каждый раз разные сессионные ObjectURL, а в публичной версии это простые всегда одинаковые пермалинки.

Overhead на такой подход в строках кода оказался неожиданно небольшой (~200SLOC для приложения в 300Кб JS) – но я вряд ли буду делать так часто.

Дело в том, что любой код, модифицирующий другой код, довольно hacky. Такой код требует тщательного обдумывания и аккуратного написания, и всё равно он от этого не становится “прозрачным”.

Более того, я не придумал какого-то разумного обобщения, позволяющего избежать ручного указания, что из исходного кода конкретного приложения оставить, что вырезать, а что трансформировать. То-есть, я придумал в самом деле – но тогда надо либо грузить на клиент туеву хучу лишних библиотек, либо сильно замедлять сервер лишними абстракциями.

В общем, интересно, но не серебряная пуля.

ermouth: (ang)
(При)открыли lesorub.pro – мы этот чемпионат типа продюсируем. Сайт пока с заглушками и плэйсхолдерами, рыхлый, неполный и вообще такой... угловатый – но пусть уже открытым висит.

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

Админка, как водится у нас в последнее время, offline first приложение. То-есть не только редактирование текста, но и редактирование/просмотр фоток и файлов вложений работает при отключенном интернете. Как только инет появляется, правки улетают на сервер и публикуются (если это не черновик), или прилетают с сервера, если кто-то редактирует.

На этом проекте я проверил применимость подхода offline-работы на существенных объмах данных, закэшированных локально в браузере – в проекте сотни мегабайт картинок, и на всех клиентах бэкэнда сервер поддерживает локальные копии ап ту дэйт в реальном времени. До этого я применял непрерывный sync только на коротких документах.

Третий умный термин – progressive rendering. Большинство страниц публичной части приходят сформированными так, чтобы как можно быстрее показать «первый экран». Остальное догружается по ходу пьесы. Из этого всего делается догрузка длинных страниц по мере промотки и непрерывный скролл по лентам материалов, не готово пока.

Может, успеем ещё вставить всякие интерактивные штуки, но тоже не уверен.

Ну и всякие параллаксы там, responsive вёрстка и тп плюшки – всё на месте. Может, даже 3Д-панорамы с коптера будут – уже готовы, но есть всякие обстоятельства.

Рыхлое блин только всё визуально, не хватает прихотливости.
ermouth: (Default)

Внезапно вчера в Архангельске прошла мегаконференция StartupStandup и, хоть меня туда и не приглашали (какой из меня стартапер, ога), один сделанный нами проект там внезапно оказался.

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

Коль скоро заказчик проекта его официально презентовал, правда, больше с бизнесовой стороны, не вижу причин не расказать о solovki.pro с колокольни разработчика. Несмотря на то, что всё только-только из-под Under construction выведено, за некоторые вещи “уже не стыдно” (с).

Фронтэнд

С точки зрения посетителя – это калькулятор туров на Соловки. Кулькулятор сразу туры продаёт, а не только считает. Заказ или уже можно оформить, или вот-вот можно будет, ждём от Сбера подтверждение включения платежного шлюза.

Туры кастомизированы – то-есть выбирается транспорт, проживание и развлечения на месте. Калькулятор устроен таким образом, что знает capacity каждого ресурса на каждую дату и даёт заказывать соразмерно возможностям принимающей стороны.

Снимок-экрана-2016-03-17-в-19.03

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

Capacity, к слову, считается на сервере одним единственным хитрым map/reduce-ом всего на 200- SLOC.

Калькулятор – jQuery.my приложение, 120 с небольшим кб в исходных текстах. Сделан в CloudWall, там же и отлажен. На картинке вот калькулятор исполняется в отладчике, в окошке.

Снимок экрана 2016-03-17 в 19.31.50

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

Самый простой пример – доступность номерного фонда отеля не на конкретную дату, а в диапазоне (надо брать наименьшие значения по набору, с нюансами). Посложнее: что делать при сдвижке дат – можно лучше сделать, чем сейчас, и тп.

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

Мобильную версию калькулятора пока не делали – заказчик посчитал, что подождёт.

Приложения бэкэнда

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

Веб-приложения бэкэнда с самого начала заточены под работу в сетях с ненадёжной и медленной связью, то-есть они offline-ready. Однажды загруженная вкладка с приложением прекрасно работает и без соединения и заказчивает/скачивает изменения в данных, когда оно появляется. С учётом качества связи в местах экологического туризма это не прихоть.

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

В самом деле приложения даже не знают, с каким набором данных они работают – всю синхронизацию за них делает платформа. Приложение просто делает this.db.get(), this.db.query() или this.db.put().

Например, вот так выглядит диспетчер со старыми тестовыми данными:

Снимок-экрана-2016-03-17-в-19.17

Окошки таскабельны, компоновка сделана под большие мониторы – чтобы можно было свободное поле вокруг календаря обвесить окошками. На мониторах поменьше и планшетах, правда, тоже нормально, просто не 7 дней помещается по ширине.

Из диспетчера можно отправлять СМСки и звонить – это важно, потому что климат на Соловках переменчивый и иногда надо туристов оперативно уведомлять.

Естессно, все приложения – манифесты jQuery.my.

Технологии

Особо детально не буду расписывать, потому что есть чувствительные данные в системе.

Серверная часть – node.js, патченная CouchDB и nginx. То-есть, основная часть кода на JS и немножко на Erlang-е. База крутится на SSD. Памяти на инстанс надо немного совсем. В общем, ничего необычного.

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

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

Локальные данные позволяют трюки, которые затруднительны при обычной архитектуре – например, массивные map/reduce запросы. Вообще, серверные мощности бэкэнда очень скромны, потому что основной объём всякой тяжести вынесен в клиентские браузеры.

“Цена” поддержания канала постоянной синхронизации неожиданно невелика – примерно 14Кб в час, если новых данных не поступает/отправляется. Канал, кстати, гарантирует доставку в конечном итоге, сообщения не могут быть потеряны.

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

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

Поглядим, как это всё полетит )

UPD. Хехе, тут вот уже багов накидали. Аккурат на пограничные случаи. Поправили, но чует моё сердце, что это не последние.

ermouth: (Default)

У нас недавно в процессе тестовых прогонов одного проекта нашёлся удивительного свойства баг, такой очень хитрый race. Race этот прожил в глубинах CloudWall-а два года никак не проявляясь ни в тестах, ни в реальной жизни.

Вернее, он, вероятно, проявлялся, но этот race до определённых условий имеет тенденцию саморассасываться, и поэтому может быть незаметен.

История такая.

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

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

Никаких 4хх, 5хх или обрывов по пути нет, то есть оно не рестартует на ошибку, оно просто много раз качает одно и то же.

Дело оказалось вот в чём.

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

Это сделано для того, чтобы ни один процесс репликации не мог надолго монопольно захватить каналы передачи. Типичный браузер не поддерживает больше 10 одновременно открытых XHR-соединений на вкладку, остальные стоЯт и ждут освобождения слота.

Так как CloudWall партиционирует локальную базу и может поддерживать связь сразу с несколькими удалёнными БД, такой подход оправдан. Беда только, что он даёт race на медленных каналах – потому что PouchDB старой версии, что используется, иногда не закрывает соединение при отмене репликации.

То-есть оно продолжает качать себе дальше, если там что-то длинное.

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

Пока не наступает одно из пограничных условий (а они довольно искуственные), рэйс так или иначе рассасывается – потому и не заметно было. Тесты то проходят.

Интересно, что починилось в ~10 строк кода, но доставило невообразимо, да.

ermouth: (Default)

Я вчера, уже когда засыпАл, пребывая под впечатление от Win95 на JS, размышлял, чего же не хватает, чтобы сделать из браузера условно-полноценную платформу для виртуализации. То-есть, сделать из браузера гипервизор.

В диктофон записалось “локалсторидж и юдипи”, после этого я уснул. Расшифровываю.

Синхронная файловая система

В браузерном JS есть всего две сущности, которые могут сойти за синхронную запись/чтение на файловую систему, и обе очень ограниченные.

localStorage – единственная локальная браузерная БД, чтение/запись в которую синхронные. Главная проблема – localStorage крошечный, единицы мегабайт.

Есть ещё IndexedDB и уже считающаяся устаревшей (а напрасно) WebSQL – они дают объём до 1/10 диска на домен, но они обе асинхронные.

Synchronous XHR – синхронный ajax-запрос. Это сетевой запрос, а не локальный, стало быть сразу прилагается куча соответствующих проблем. Более того, Mozilla пометила синхронные ajax-запросы как deprecated.

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

Про “адаптацию имеющегося” я говорю вот почему. В браузерах накоплено существенное количество самых разных технологий, которые могут очень неожиданно сочетаться. Например, btoa(unescape(encodeURIComponent(string))) служит для конвертации в base64 unicode-строк, и лишь единицы самых рафинированных экспертов впервые её увидев скажут вам, как и почему это вообще работает. Хотя все три функции – “системные” для браузера, их сочетание вводит в полный ступор сначала.

UDP

Сейчас в браузере нет никакого способа выполнять UDP-запросы. Я не думаю, что он появится, потому что такая возможность ставит под угрозу безопасность не конечного пользователя, а всей сети. Тем не менее, очевидно существует множество “классических” приложений, которым нужен UDP. Как тут быть, не очень понятно.

В браузере есть некоторое "идейное” подобие, чтоли – называется WebRTC. Эта технология предназначено для веб-версий “настольных” технологий, где UDP задействуется особенно широко. Потоковое видео, VoIP и тп.

Возможно, WebRTC будет как-то адаптирован под более широкового плана нужды.

Итого

Френды, если есть у вас какие-то навскидку соображения про фундаментальные ограничения на идею “браузер как гипервизор” – напишите плиз коммент.

ermouth: (Default)

Килозвёздочка дала себя знать явно – чувак, который мне её поставил, чирикнул в тви про это. 1K☆ репо при 15 issues за три года и всего одном контрибуторе – это в моей извращённой картине мира достижение, да.

На гитхабе ~1.7M javascript-репозиториев, из них ~470k c 1+☆, 11.7k 100+, 1615 с 1000+ (я здесь, это 0.1%) и всего 66 с 10К+☆.

Багов, каэш, не 15 нашлось за всё это время – но большинство я нашёл сам. Плюс я не запариваюсь оперативно переписываться с юзерами вне гитхаба и либо чинить промежуточными версиями, либо предлагать roundtrip до релиза. Вообще, багов реально практически нет.

Есть довольно много вопросов, потому что по некоторым сложным моментам документация оставляет желать лучшего – но по рядовым моментам вопросов у юзеров почти нет.

Снимок экрана 2015-12-01 в 20.33.02

При таком вот месячном покрытии jquerymy.com я получаю примерно 10-15 писем в месяц с вопросами по фичам. Приемлемо, хотя точно можно лучше – вопросы по преимуществу на две всего темы, по которым маны нестройные и неполные.

Раз у меня такой майлстоун случился, я решил расписать длинной ретроспективой, что это и как оно всё развивалось.

Read more... )

RST

Nov. 28th, 2015 10:39 am
ermouth: (Default)

В субботу с утра пораньше сел писать доки к новой фиче в CouchDB. Это уже третий подход к снаряду – доки там в в волшебном формате .rst, который через жопу показывается буквально во всех IDE, что у меня установлены как нативные приложения, и даже это “через жопу” требует установки зависимостей пачками.

В результате я плюнул искать и напилил редактор этого .rst сам. Заняло это по часам 27 минут, из которых половину я потратил на поиски и вкручивание в приложение подходящего мода для кодмиррора и его зависимостей.

Снимок-экрана-2015-11-28-в-10.27

Это всё, естессно, не выходя из браузера, прямо в CloudWall. Теперь эти rst, которые руководства к CouchDB, наконец-то и хранятся в CouchDB, ога.

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

UPD. Ой, забыл код приложения же показать. Вот он:

Read more... )

Inliner

Sep. 10th, 2015 04:13 am
ermouth: (Default)

Почти довёл до нестыдного состояния офлайновый редактор контента зверски навороченный. Та-же технология, что и Ddoc Lab примерно, но это не стэндэлон, а больше компонент для других систем.

Тык по картинке – живое редактируемое демо. Стартует первый раз очень долго, может полминуты пыхтеть – загрузка не оптимизирована потому что ещё. Дальше всё летает пулей.

Снимок экрана 2015-09-10 в 3.56.50

Длина самого приложения, без обвеса – 100 Кб, а под углифаем-гзипом и вовсе 25-30 кило.

Я этот редактор как компонент уже впилил в Ddoc Lab, пока не задеплоил ещё. Собираюсь сделать под него шаблончик, который позволит на cloudant.com развернуть простенький блогодвижок в два копипэйста, реально.

Не без глюков всё пока, но на мой вкус редактор жирненький получился ) Медиум об коленку, ога.

Ddoc Lab

Jul. 30th, 2015 11:31 pm
ermouth: (ang)

Зарелизил CloudWall 1.8, в который вошло новое приложение – Ddoc Lab.

Для этого приложения, выведенного стэндэлоном, сделал отдельный сайтик. Сейчас инглиш вычитывается и пытаюсь пофиксить merchant-account на пэйпэле (дичайший гимор). А так всё уже работает в хорошем приближении.

Клик по картинке – на сайт.

Снимок экрана 2015-07-30 в 23.10.38

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

Софтинка эта написана в полном CloudWall-е, а на сайте работает под его порезанной стэндэлон-версией. То-есть теперь у меня есть такая специальная версия CloudWall, которая поддерживает всего одно приложение и одну открытую БД на вкладку. И есть генератор этой мини-версии из большого CloudWall-а, да.

То-есть это позволяет релизить сингл пэкиджом из одного JSON-файла сразу и приложение, и ОС под ним. Этот JSON можно копипастить как документ в CouchDB – и приложение сразу взлетает на той базе, куда скопипащено.

Ещё заодно пробую “Pay what you want” модель монетизации – Ddoc Lab в виде JSON-а в некоторых случаях может быть просто бесценен ) То-есть это можно приложение поставить себе в CouchDB  в один копипэйст буквально – и заиметь человечий редактор индекс-функций и приложений у себя локально.

Такие дела.

ermouth: (ang)

Текущий набор иконок “публичных” приложений CloudWall выглядит так:

Снимок экрана 2015-07-08 в 10.28.48

Две последних – новое приложение, которое появится в CloudWall 1.8 и будет выложено стэндэлон-сервисом.

Приложение называется DDoc Lab и служит для разработки, линковки и публикации Couchapp-приложений произвольной структуры. То-есть, это специализированная IDE.

В самом деле редактировать и собирать можно не только Couchapps, но и любые сложные документы для CouchDB. Например, следующая версия FEED CMS пересобирается именно в DDoc Lab, и ускорение против работы в обычном IDE не просто кратное, а скорее на порядок. FEED естессно не Couchapp – просто код хранит в CouchDB, не более того.

Все прелести в пакете – инклюд внешних сорцов, сборка, валидация, частичное обновление, проверка целостности и прочая и прочая.

Началось всё вот с этого поста в рассылке CouchDB в мае. Выделить время в мае у меня не получилось, а в июне у меня куча времени выпало из-за боёв с кривизной PouchDB. Ну, в июле – не поздно )

Постановка задачи

В силу того, что CouchDB-документы – это не файл, а JSON плюс набор файловых аттачей, сборка приложений с файловой системы делается либо руками, либо специализированным CLI-тулом (раз, два). Что так, что так – дикий геморрой в самом деле.

Вообще, крива сама идея CLI-тулов, которым нужен или Питон, или node.js, чтобы собирать приложения для БД, которая себя позиционирует как единое решение для веба. В браузере это должно делаться.

Теперь вот делается.

Ну и под занавес скриншотик вот:

Снимок экрана 2015-07-08 в 11.03.41

Скоро на экранах! )

ermouth: (ang)

Написал за ночь сегодня логгер для следующеего релиза CloudWall, сейчас потестил – оч шустро вышло. Написал заметочку в корпоративной Стене и решил сюда кросспостнуть.

Под катом инженерные соображения про логгер для браузерной системы.

Клик чтобы раскрыть... )

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

Справочно: скорость записи в localStorage небольших фрагментов (десятки килобайт) колоссальна: на моём i7 – сотни мегабайт в секунду в любом браузере. Это многократно превосходит среднюю скорость сериализации в JSON, например.

Коллеги, что я забыл про важные фичи лога?

ermouth: (ang)

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

Снимок-экрана-2015-04-20-в-0.12

Уважаемые френды кто про схемку спрашивал, так понятнее?

ermouth: (Default)

Мы все привыкли, что в javascript-коде, особенно клиентском, можно особо насчёт RAM не париться. Автоматические сборщики мусора уже очень хороши во всех браузерах и прекрасно переваривают даже существенно корявый код и сложно зацикленные указатели.

Но есть одно исключение, когда памятью в js нужно управлять прямо – то-есть делать allocate-deallocate кодом, а не полагаться на автомат. В полный рост это исключение проявляется в noBackend приложениях.

Жизнь без пермалинков

Дело в том, что для бинари-ресурсов, хранимых локально в браузере, не существует пермалинков. То-есть, если надо вставить картинку, то src="http://url.com/image.jpg" написать не получится – нет у картинок урла.

Read more... )
ermouth: (Default)

Перепозиционировал это всё как noBackend OS, с известной долей иронии каэш. Теперь и на гитхабе – https://github.com/ermouth/cloudwall

Снимок-экрана-2015-04-08-в-1.37.50 

Главные фичи

Оно теперь опенсорц. Установить можно на любой статический хостинг прямо из .tgz, там только html + js + json + css.

Исправлено куча багов, апгрейд библиотек сделан, примерчики добавлены, приложения обновлены. Ещё я там на заглавной выложил унылый шестиминутный скринкаст как за час сделать, отладить и задеплоить приложение для организации распределённых дискуссий. Целых 4кБ длиной приложение, ога.

И – тадам – это всё можно форкать и править/пересобирать форк самого CloudWall прямо в браузере. То-есть можно скачать себе в браузер исходники, это примерно так выглядит:

Снимок экрана 2015-04-08 в 1.38.45

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

Important notice

Если кто-то юзал или смотрел cloudwall.me до этого, не забудьте обновить системные приложения. Как войдёте – серая кнопка Check updates в левой панели внизу.

И да, информация о документе и всякие copy/delete теперь – через клик по иконке документа.

Сделано в CloudWall

CloudWall в текущей версии полностью написан и собран в CloudWall, только иконки не в окошке браузера нарисованы. Сам сайт cloudwall.me тоже управляется прямо из CloudWall.

Вообще, у меня лично внутрибраузерная боевая БД перевалила за 400 мегов. Полёт прекрасный.

---

Хвалите, поздравляйте, ставьте, пробуйте. На планшетах кста норм работает, да.

ermouth: (ang)

Год назад я запустил первую версию cloudwall.me. Жэжэшечка у меня тогда была закрыта, так что написал я об этом только в мае и в Medium.

clouds-09

В тот момент cloudwall.me работал на PouchDB 1.4 (это такая локальная NoSQL БД в браузере). Тогда она была дико глючная и медленная. За год PouchDB стараниями комьюнити доросла до 3.3 и стала вполне стабильной. Среда исполнения приложений на jquerymy за год тоже здорово подросла и в плане скорости, и в плане надёжности.

Плюс добавился IDE, плюс ещё всякие редакторы и приложения, плюс я сайт jquerymy переделал.

Короче, сейчас cloudwall.me – простейшая браузерная ОС, которая для работы не требует инет-соединения. Год назад я говорил (и думал), что ОС эта совсем игрушечная – но, похоже, что не такая уж и игрушечная.

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

И контракт этот – на разработку софта на платформе cloudwall.me. Offlline-ready, все дела. Интересно, что контракт сам меня нашёл.

Что дальше

CloudWall система уникальная в том плане, что её исходники не существуют в виде файлов.

Текущая версия CloudWall (платформы) создана внутри него самого, исходники – это JSON-документы в локальной браузерной БД. Синхронизированной, конечно, с удалёнными репликами CouchDB.

Сам сайт cloudwall.me – статически слинкованный – это один документ CouchDB с 32 аттачами. То-есть, чтобы запустить CloudWall у себя, как свой сайт, достаточно поставить CouchDB и скопировать в неё один-единственный документ. Больше ничего делать не надо – оно сразу заработает само.

В общем, я планирую довести это всё до стадии open-source для начала. Это не так и просто – потому что файлов нет, а на гитхаб можно положить только файлы, то-есть нужен трюк.

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

Что-то типа MS Active directory + DFS получается, только в браузере и для запуска js-приложений. Ну и без дикого сопутствующего гимора как в Винде. И клиенты по определению однопользовательские.

Но сначала я раскрою cloudwall. Скоро на гитхабе, да.

CouchDB PR

Mar. 4th, 2015 06:03 pm
ermouth: (ang)

Меня пропиарили ребята из CouchDB. Причём сразу двумя строчками, ога )

Снимок экрана 2015-03-04 в 17.49.06

Сразу и cloudwall.me, и CoverCouch. А я ведь едва не забросил развивать и то, и другое – а тут внезапно такой наплыв. В этой связи я думаю, что пора их converge в одну систему, ну и cloudwall.me опенсорцить.

В общем, понятны следующие шаги – но цель какая-то нереально амбициозная вырисовывается.

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

JSON editor

Jan. 9th, 2015 07:44 am
ermouth: (ang)

У меня тут в качестве побочного инструмента разработки возникла потребность в нормальном JSON-редакторе. Это то-есть такого, который:


  • распознаёт таймстампы и показывает их как даты

  • понимает стрингифаенные функции

  • определяет, что строка – base64 и её можно показать/скачать

  • прощает ошибки набора JSON (пропуск кавычек), но генерит корректный JSON

  • понимает JS-выражения, которые сразу вычисляет

  • позволяет размножать/переставлять ветки

  • позволяет каждую ветку поправить сорцом

  • даёт экстендить один JSON другим.

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

У меня такой редактор написался внезапно, и такой хорошенький, что я вот его обвесил всякими сэмпл-доками и выложил как online tool. Он умеет доки хранить в локалсторидже есчо, так что всё помнит.

Снимок экрана 2015-01-09 в 7.26.06

http://cloudwall.me/etc/json-editor.html

Любопытно, что эта штука – “рекурсивное” приложение. Оно при раскрытии веток юзером инстанцирует само себя как дочки. Я сначала думал что это довольно дорого в плане памяти и CPU, но неожиданно оно норм даже на айпаде полетело. Хотя прожорливое, конечно.

ermouth: (ang)

server-emulationПридумалась тут на днях офигенная концепция как на клиенте, в браузере, разрабатывать и отлаживать серверный js-код, работающий с БД. Из картиночки справа в общем всё понятно.

В нашем типичном стеке серверных технологий – node.js + express + cradle + CouchDB – достаточно заменить только cradle.js на PouchDB.

Обвес, позволяющий проделывать весь этот трюк в браузере, оказался на удивление несложным в целом. Я его как proof of concept написал за вечер, а на следующий вечер у меня уже заработал серверный код, полностью написанный в нашей самопальной IDE.

Как ни странно, всё взлетело сразу почти, без особого бубна с функционалом БД. Споткнулся я сначала на криптографии, но это мы проработали прошлой зимой, оставалось только чуток подкрутить. Гораздо более серьёзным оказался затык на библиотеке, обеспечивающий Promise-функционал нужного синтаксиса.

Промисы – модная и очень удобная штука, мы активно используем. Коллбэки – фу, промисы – кул. Беда в том, что синтаксис промисов иногда существенно отличается от библиотеки к библиотеке, там нет единого стандарта.

Исторически так сложилось, что на клиенте мы используем модель jQuery.Deferred – которая не очень то удачна, по-честному. Ну и оказалось что для node.js нет либы, которая повторяла бы синтаксис $.Deferred – чему я был очень удивлён.

В результате перебора bluebird.js, затем lie.js [ага, var Promise = require("lie")] и затем Q.js оказалось, что проще всего имитировать $.Deferred под нодом с помощью Q. Ну, как известно “то, что вы ищете, вы найдёте в самом последнем месте”, да.

Так вот, в самом простейшем варианте код выделки симулякра $.Deferred из Q.defer умещается в 20 строк:


var Q = require("q");
var Promise = function(){
 var q = Q.defer(),
 qp = q.promise,
 pi = {
  then:function(a,b){return qp.then(a,b);},
  fail:function(a,b){return qp.fail(a,b);},
  done:function(a,b){return qp.done(a,b);},
  progress:function(a,b){return qp.progress(a,b);},
  promise: function(){return q.promise;},
  resolve:function(a,b){q.resolve(a,b); return pi;},
  reject:function(a,b){q.reject(a,b); return pi;},
  notify:function(a,b){q.notify(a,b); return pi;},
  isResolved:function(a,b){return q.isFulfilled(a,b);},
  isRejected:function(a,b){return q.isRejected(a,b);},
  state: function(){ 
   var state = qp.inspect().state;
   return state==="fulfilled"?"resolved":state;
  }
 };
 return pi;
}


Если не заигрывать сильно с this, не засовывать синхронный код в промис и использовать только базовый синтаксис, этого достаточно. Вдруг кому пригодится.

Сегодня кста выяснилось, что node.js даже последних сборок использует уже не поддерживаемую Гуглом версию V8. А нод много где в продакшене используется о_О

Profile

ermouth: (Default)
ermouth

September 2017

S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 24th, 2017 04:54 am
Powered by Dreamwidth Studios