ermouth: (Default)

Написал админку для CouchDB – Photon.

То-есть уже есть две – Futon (исторически первый) и Fauxton (для новых версий). Второй – модный, но совсем неудобный, плюс в угоду моде очень сильно страдает информационная плотность. Первый – существует только для версий до 1.6.1 (актуальная – 2.1), тоже не слишком удобный, но всё прекрасно с информационной плотностью. Плюс у обоих проблемы с обновлением – то-есть поставил CouchDB и живи потом всегда со встроенной админкой в той версии, которая была на момент установки.

Я решил сделать и удобный, и с нормальной информационной плотностью, и обновляемый независимо от самой БД. Дополнительным ограничением было отсутствие любых опен-сорцных библиотек, происходящих из крупных корпораций. Последние события показали что их опен-сорц с гнильцой (привет, Фейсбук и Реакт).

Первые эскизы нарисовались в конце августа, примерно так:

Photon-1

В результате три эскиза превратились в полное приложение за две с небольшим недели:

Снимок-экрана-2017-09-10-в-17.32

Установка – просто курлом или копипастой засунуть в базу 1 (один) json-документ объёмом 1.5 мега. Обновление потом по одному клику из интерфейса, с AWS S3 CDN, так сейчас очень много кто делает.

Конечно же, приложение никогда не существовало в виде исходных файлов на файловой системе, вся разработка – в браузере, в CloudWall. Выглядит это примерно так:

Снимок экрана 2017-09-10 в 18.00.10

На картинке Photon запущен в окошке в среде разработки и просматривает сам себя: функция слева – исходник в IDE, функция открытая в окошке – она же, но в коде уже собранного Photon-а. Рефлект рефлекта, редкий зверёк.

Оч здорово получилось в целом, кто юзает CouchDB – рекомендую.

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)

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

Снимок экрана 2016-11-04 в 13.21.24

Приложение видит языковые константы как this.lang.%VARNAME c уже применённой текущей локалью. Локаль устанавливается при старте приложения – берётся из параметров, или с родительского приложения, или с дефолтного по системе значения.

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

---

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

Иначе просто взрывается голова – количество ограничивающих факторов перевалило за 40, и есть взаимосвязанные статистически. Это самые гнусные связи – потому что я не знаю ни одного человека, который в уме бы считал Байесовы вероятности. Связи надо аккуратно выписывать, строить сети (это даже для нескольких связанных событий изрядный геморрой) и задавать сетям правильные вопросы.

Подумал ещё, что мне бы пригодился Surface Studio (где бы попробовать?) – потому что у рисования на айпаде внезапно нашёлся таки фундаментальный недостаток. Я иногда листочки бумаги раскладывал на полу – чтобы увидеть общую картину.

Сейчас у меня как раз случай, что хочется быстро разложить и пошафлить листочки – а с айпадом так, увы, не забалуешь. Надо экспортировать в PDF, пересылать и смотреть на большом экране.

Вообще, снова очень захотелось среды разработки в VR.

ermouth: (ang)
Запилил кроппер для мобилок, даже на видео заскринкастил. На ведроиде тоже прекрасно работает, поворот фоток я поборол. Домен есчо тестовый, там пусто.

Идея с пинчем двумя пальцами отвалилась кста не прожив и двух дней – по двум причинам.

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



Ещё я сегодня голыми руками (точнее, рукой) поймал на лету синицу. Мне на лоджию залетела – и оказалась настолько тупой, что как муха стала биться в стекло. Пока нёс до окна, чтобы выбросить, успел удивиться, что она перестала дёргаться сразу, как я её схватил. Наверное, подумла, что её уже съели )
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: (ang)
(При)открыли lesorub.pro – мы этот чемпионат типа продюсируем. Сайт пока с заглушками и плэйсхолдерами, рыхлый, неполный и вообще такой... угловатый – но пусть уже открытым висит.

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

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

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

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

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

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

Рыхлое блин только всё визуально, не хватает прихотливости.
ermouth: (ang)
Я впервые сделал локализованное (двуязычное) приложение со всем обвесом на платформе CloudWall + jQuery.my. Типа, майлстоун. Покажу черех месяцок вместе с проектом, который сейчас на приложении делается.

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

Причин появления велосипедика несколько.

1. «Статическая» локализация это нэ

jQuery.my app, в общем случае, это набор вложенных друг в друга приложений, каждое из которых «сидит» на своём поддереве данных, модифицируя его в зависимости от действий юзера или других событий. Как правило, верхние уровни приложения мало что знают о подробностях работы глубоких уровней, и наоборот. Они могут даже вообще не знать о существовании друг друга.

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

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

2. Полная локализация во время инициализации – это нэ

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

3. Тридцать лет и три года

Ну и русский язык же. То-есть, мы можем записать для инглиша "User is {1} year old", например. А в русском, по-хорошему, нам нужно склонять. 15 лет, 21 год, 33 года, вот это всё. Строковым шаблончиком не отделаться никак.

То-есть, у нас должны быть где-то строки, где-то шаблоны (такие, например), а где-то – вовсе функции. Которым надо что-то передавать и не давать повалить/изуродовать приложение, если они поломались.

4. Компоновка

Вообще говоря, локаль должна иметь возможность влиять на компоновку и пропорции интерфейса. То-есть, кнопки «Сохр.» и «Закр.» вместо Save и Close – это хороший пример, когда CSS и локаль живут отдельными независимыми жизнями и между ними бетонная стена. Так быть не должно.

----

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

Это вторая фича, которая войдёт в jQuery.my 1.3 как новая. А первая – поддержка ARIA-кодов, да.
ermouth: (Default)

Отрелизил сабж, релиз больше про рефакторинг/оптимизацию. Проковырялся неделю вечерами с профайлером, открыл много нового про GC и скорость регэкспов. Вот примерчик особенно злодейский:

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

Попутно напишу вот про виджет с заглавной, оч хорошо на нём видно и что такое $.my, и что я там оптимизировал. Пример, собсно, по клику на картинку.

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

В примере 100 строк кода, 2Кб, это с HTML-ем уже. Эти 2 Кб грузят внешние данные и делают из них master/detail.

Особая фишка – в левой колонке позиции таскабельны. И номера обновляются по мере перетаскивания, причём если справа открыта карточка и тыкнуто в поле ввода, то фокус не теряется.

Ну и если справа начать имя править, слева оно немедленно рефлектится. Причём можно даже начать тащить айтем слева и одновременно печатать справа )

Кто делал что-нибудь похожее хоть раз в жизни, знает, что 100 строк кода на такое – это вообще наглухо магия.

Инициализация этого виджета с 280 строками данных (каждая из которых – тоже форма) занимает примерно 300мс. По 1мс на форму. Флеймчарты до и после оптимизаций:

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

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

В самом деле 1мс – это чрезвычайно дохрена. Мы на каждую строку слева инциализируем по сути маленькое приложение, и это дорого. Увы, такой подход можно наоптимизировать ещё примерно только раза в 2 и будет потолок.

Но у меня есть план Б.

В jQuery.my 2.0 будет другой (точнее, ещё один) алгоритм. Во-первых, просто сам старт одинаковых форм станет быстрее, потому что полуфабрикат формы будет кэшироваться. А во-вторых, рендерить я их буду чанками.

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

Завтра-послезавтра days off.

ermouth: (Default)

jquerymy.js до вчерашнего дня был единым куском кода и я таки решился раздербанить 4К+ строк на компоненты и полностью перенести разработку $.my с файловой системы в браузер, в мой волшебный  IDE.

Это оказалось неожиданно небыстро. Попутно пришлось решать проблему пересборки кода с переформатированием на правильное количество табов – это тоже оказалось неожиданно небыстро.

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

Снимок экрана 2015-12-06 в 16.33.33

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

Некошерность тут в том, что если функция этот аргумент использует, вся форма становится непригодна для серверной валидации данных через неё, потому что в node.js серверным валидатором никакой DOM естессно не рисуется. А у меня внезапно на генерик-валидатор, в связи с новым JS-рерайтом в CouchDB, появились большие планы.

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

Не надо на сервере DOM, ни реальный, ни виртуальный. HTML DOM – он чтобы в браузере показываться, если он выплывает на сервере где-то – значит недодумано.

И меня в какой-то момент торкнуло, что мне надо просто взять все $.my-манифесты, что мне доступны, и посмотреть, а как-же этот третий аргумент по факту в реальном коде используется. В силу того, что именование этого аргумента – вполне себе устоявшийся паттерн, это не было очень как-то сложно.

Подходящих bind- и check- функций нашлось чуть больше 1500, и внезапно анализ показал, что в 99%+ (это из тех, где аргумент используется, а таких меньше 1/5) один и тот-же сценарий. Этот аргумент используется чтобы принудительно триггерить системные события на контролах формы, по их строковому селектору как правило.

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

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

То-есть вместо $ctrl.my('find', '#ctrl1').trigger('check') мы будем писать this.my.check('#ctrl1'). Красота, и прекрасно имплементится в серверном валидаторе безо всякого DOM.

Такая вот колбаса.

cdnjs

Dec. 4th, 2015 06:10 pm
ermouth: (Default)

jquerymy.js во всех версиях теперь доступен с cdnjs.com, который живёт на Cloudflare. Больше доступности – это гут.

Заодно подбил статистику за ноябрь у себя – мой личный CDN за ноябрь отдал 243К запросов.

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

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

ermouth: (ang)
Прекрасное просто https://www.quantamagazine.org/20150519-will-computers-redefine-the-roots-of-math/

Про множества, теорию типов, гомотопии, эквивалентность и изоморфизм – и мой любимый HoTT, на идеях которого и построен jQuery.my.

Материал написан очень простым и доступным английским языком. Очень рекомендую.

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

FEED CMS

May. 20th, 2015 09:42 pm
ermouth: (Default)

Оформили в первом приближении нашу новостную CMS в продукт. Вот уж не думал, не гадал. Клик по картинке – на сайт в первой итерации.

Снимок экрана 2015-05-20 в 21.16.31

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

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

FEED специально заточен под такие задачи – организацию высоконагруженного непрерывного потока информации лентами. Под статические сайты он не подходит – будет очень ограничивать и дорого стОит для статики.

Самое старое боевое внедрение FEED за два года отдало 5+Тб страничек и ни разу не упало, чихнуло разве что пару раз. Есть ещё одно внедрение, на котором в течение полугода менялись один за другим студенты и кому ни попадя права админов раздавались. Там такое с системой вытворялось, что даже я был удивлён, как её можно выкрутить – и тоже не разу не упала, но крепко, правда, спотыкалась.

Всё целиком, от первой до последней строчки, javascript. Весь бэкэнд и мобильная версия – jQuery.my-приложения. Исторический эскизик вот, с которого всё началось:

image

Всё немного посложней в жизни вышло, но примерно принцип понятен, как оно работает.

С Днём Рождения, FEED )

Atomic CSS

Apr. 20th, 2015 10:00 pm
ermouth: (Default)

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

Оказывается, эту же технику использует Yahoo под названием Atomic CSS. Там прекрасный флейм в комментах кста.

Техника эта – когда мы пишем кучу правил типа .mt10 {margin-top:10px} или .fl {float:left} – особенно удобна, если сделать набор генерализованных правил большим, с частой сеточкой.

В CloudWall и системах, на нём построенных (общий объём выдачи с таких систем – 600К страниц в месяц есличо) объём таких правил в CSS-файлах – примерно 30Кбайт. Это 10Кб гзипом, меньше маленькой картиночки.

Игра свеч определённо стоит. Когда заранее неизвестно, что будет на странице и как могут конфликтовать селекторы, строить стайлшиты на основе БЭМ или подобных техник очень утомительно и получаются они жирнее.

В самом деле наилучший вариант – обе техники сочетать.

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

То-есть, даже очень сложные приложения требуют относительно скромных кастомных CSS-стайлшитов в стиле БЭМ – если подставить под БЭМ более “низкоуровневую” технику типа Atomic CSS.

В реальности это даёт вкусные каврижки. Скажем, для довольно сложного мобильного приложения весь CSS-код укладывается в 80 строк:

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

Типичный объём CSS для таких приложений – полтысячи строк и больше, и конечно при БЭМ подходе чистоганом хрен их встроишь куда-то. А тут оно что на мобиле, что во всплывайке, что виджетом на странице одинаково работает и выглядит.

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: (Default)

За каникулы случился minor version upgrade – добавилось немножко вкусных фич. Заодно оказалось, что это 10-й юбилейный релиз, да.

В jQuery.my теперь есть внутрисистемный pub/sub и управляемое наследование.

Radio/ listen

Pub/sub организован по принципу радио – каналы и подписчики. Подписчики – контролы в приложениях, они могут апдейтиться на сообщение в канале.

В отличие от типичных чисто js-реализаций pub/sub, я заюзал DOM. Просто мне надо иногда ограничивать вещание, примерно вот так:

unnamed

То-есть какие-то каналы броадкастятся всем, а какие-то приложение может ограничивать и наружу не выпускать. А какие-то и вовсе просто глушить.

С учётом того, что $.my это loosely coupled система, такую функциональность – что по границам каждого приложения может проходить radio-relay c ретранслятором/обработчиком/глушилкой – оказалось не так просто сделать по канонам.

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

В общем, скомбинированные события jQuery и обычный pub/sub вполне решают проблему без создания каналов с частными именами. Также не нужен контроль за тем, жив ли ещё подписчик или его уже прибило по пути и это последние коллбэки в темноте дёргаются – то-есть можно не отписываться от канала в деструкторе, тебя автоматом отпишут по выбытию.

Expose / inherit

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

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

Было бы удобно ей сразу передавать кукую-то ветку манифеста вызывающего приложения, отвечающую за БД. Это и раньше можно было делать, но надо было код писать – а он всегда исполняется после require. Теперь можно сразу фэйлить старт, если вызывающая форма не expose’ит какие-то нужные фичи.

В общем то, недавний редактор JSON написан как раз отчасти чтобы это всё потестить.

Картинки

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

unnamed1 unnamed (1) unnamed (2)

Каникулы кончились, на дворе адище, русский зима, –30. А я дома в трусах и у меня внезапно ядовитый паслён Solanum pseudocapsicum мало того, что зацвёл, но ещё и ягодки будут.

В общем, сдержанно-оптимистичный пост, да.

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, но неожиданно оно норм даже на айпаде полетело. Хотя прожорливое, конечно.

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 05:02 am
Powered by Dreamwidth Studios