binwalk

Apr. 29th, 2017 01:01 am
ermouth: (Default)
Стал собирать на Маке binwalk, чтобы устроить тотальную вивисекцию Билайновской прошивки с бэкдорами – и прифигел.

Собирается уже 3-й час, и пока не видно конца. Плюс оно не может собраться без gcc, clang не катит. А gcc сам по себе собирался час со скачиванием. Сейчас вот qt собирается, подозреваю это ещё с часик.

Я сначала было подумал что binwalk – это такой консервный нож навороченный, а там похоже целое хирургическое отделение о_О

--- 

В результате не собралось, потому что Homebrew внезапно незалюбил Macports о_О

---

Обошёлся без binwalk-а. В прошивке, в одном из конфигов, нашлось вот такое:

manufacturer="RON-Telecom"
manufacturerURL="http://www.rontel.ru/"
modelURL="http://www.rontel.ru/"
model_name="RFT620"
model_num="1000"
modelDescription="WLAN Access Point"
device_name="RFT620"

Это очень любопытно, особенно если посмотреть где ещё проявляется этот RFT620, и как его инкарнации выглядят (по-разному), а также на каких условиях попадают к абонентам (обычно льготных). А ещё сходить на сайт этого РОН-телекома и очень удивиться. Тут явно вырисовывается что-то интересное. 

Сама прошивка – линух, по-моему, неряшливый, хотя я не спец. Кажется, при старте монтируется довольно большой RAM-диск (32Мб), не понимаю, зачем.

И – ура – к линуху, если подкрутить конфиг через веб-интерфейс, оказалось можно подключиться по ssh – что сильно облегчает дальнейшие шаги. To be continued.
ermouth: (ang)
Хром, когда-то бывший на фоне конкурентов просто таки blazing fast, уже не торт. Удивительно, но по некоторым характеристикам нынешний Хром медленнее Хрома 2014 года, например.

Я скажу больше: overall responsiveness у Хрома среди всех современных браузеров наихудшая. Это как-то плавно и незаметно произошло.

Когда-то давно (2014) я делал виджет для представления бюджета Архангельской области в виде интерактивного многоуровневого бублика, смотреть на https://dvinaland.ru/budget. Задача была сделать так, чтобы 500+ SVG-секторов не тормозили при анимации, в результате там jquerymy-виджет и подкрученный d3.js с пачкой довольно tricky кода поверх. Для анимации надо кликать на сектора есчо.

Так вот, в 2014 оно не тормозило только в Хроме и Сафари, а во всех остальных браузерах подлагивало. Теперь, в 2017, оно не тормозит вообще во всех новых браузерах (даже в IE Edge), кроме Хрома. Зато в Хроме просто адово лагает.

У меня есть ещё несколько тестов подобной сложности, релевантных моему workflow. В некоторых тестах Сафари уделывает Хром вдвое – а всего года два назад было почти наоборот. Даже FF стал Хром уделывать.

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

Что такое случилось с Хромом?

La Piovra

Feb. 26th, 2017 04:55 am
ermouth: (ang)

Я когда-то нашёл занятный концепт “Программа как осьминог” – и так на всю голову впечатлился, что мы примерно такое сейчас и делаем.

Архитектура нервной системы осьминога:

v46

Архитектура федерации узлов и данных, которую мы сейчас сочиняем:

v47

Забавно, что наш осьминог, как и всамделишный, может целиком вытечь через один канал. Без остановки сервисов, включая обновления кода и состояния, которые происходят во время “перетекания”.

Только в нашем осьминоге не обязательно 8 щупалец. И можно отращивать новые или соединять имеющиеся в одно ничего не останавливая.

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

И да, во избежание возникновения конкурирующей расы сетевых октопоидов 🐙, функции вымётывания икры у нашей системы на всякий случай не предусмотрено )

Clustrmaps

Dec. 18th, 2016 11:07 pm
ermouth: (ang)
Адски пиарю сабж, это карта-счётчик, стоИт у меня в шапочке ЖЖ. Установлена уже тыщу лет, и до последнего времени там ничего особо не менялось.

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

Радует короч.
ermouth: (Default)

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

Это я контексте обдумывания IDE в VR наткнулся. Размышлял, как именно (в какой последовательности) дети лепят фигурки из пластилина и в каком порядке взрослые рисуют более-менее геометрически связанные фрагменты пространства.

Brief Overview

Снимок экрана 2016-08-02 в 2.55.11

Why TDA beats dimension reduction

Снимок экрана 2016-08-02 в 3.07.24

Ну и слайдшер с некоторыми подробностями (т.е. ключевыми словами для дальнейшего чтения)

Снимок экрана 2016-08-02 в 3.12.04

Почему-то вспомнилась классификация животных из Борхеса Ж)

ermouth: (ang)
У tonsky хороший пост про IDE responsiveness. Хорошо согласуется с моими впечатлениями, хоть и не учитывает подсветку синтаксиса.

Я использую вебовый CodeMirror, который там на 10 месте – и опережает кучу десктопных IDE. Использую как раз потому, что он шустрый, после него пересаживаться в WebStorm или Eclipse – просто боль, потому что они кажутся невыносимо тормозными. Это, заметим, при том, что у меня подсветка синтаксиса и разбор исполняются в главном потоке, а в десктопных IDE – это почти всегда отдельный поток.

Ещё не учтён важный фактор скорости запуска – для веба, особенно когда надо на одной страницы быстро инстанцировать/удалять новые экземпляры редактора, к CodeMirror вообще ничего даже не приближается. Столь любимый многими Ace (основа Atom-а) просто нереально сосёт по сравнению с CodeMirror в плане как скорости старта, так и подсветки синтакиса.

Предсказуемо, VS Code там вовсе на последнем месте, кста – что тоже полностью соответствует моим ощущениям.

Mic drop

Apr. 2nd, 2016 11:32 pm
ermouth: (Default)

Я недавно писал про важность компоновки в интерфейсах, и тут такой пример подоспел. Google на 1 апреля знатно обмишурился, вставив рядом с кнопкой Send непонятную шнягу:

drop

Этот Send+ отправляет письмо с двусмысленным сюрпризом, что, учитывая сотни миллионов пользователей, привело к очень некрасивым всяким, хотя и единичным, последствиям.

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

Хорошие мальчики делают вот так:

Снимок экрана 2016-04-02 в 23.16.59

Или вот так (не то же самое, потому что надо учитывать ещё и расположение контролов выше кнопки):

Снимок экрана 2016-04-02 в 23.17.58

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

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

ermouth: (Default)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ermouth: (Default)

Ой-вэй, не прошло и месяца, как обновление Javascript-компилятора выкатил webkit.org. То-есть там круто, ребята заменяют LLVM на что-то более узкоспециализированное.

https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/

LLVM в вебкитовском Джаваскрипте используется(вался?) для оптимизации критических фрагментов кода. То-есть, упрощённо, сначала JS компилится совсем быстрым компилятором, а потом те фрагменты, которые активно используются во время рантайма, компилятся ещё раз с оптимизациями.

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

Тем не менее, вебкит решил, что можно сделать ещё круче, в одно базовое соображение: IR (intermediate representation, промежуточное представление) между двумя специализированными компиляторами может быть компактнее и проще полного IR LLVM.

Это похоже на историю с Флипбордом, который придумал собственный упрощённый DOM с рендером прямо в битмап на клиенте.

Новый IR называется B3 IR, в статье есть его описание и масса любопытных идей и наблюдений, из которых он родился. Вообще, оптимизации там такие… уж очень специфические. Если сравнивать с авиацией, это примерно как “мы сделали новые законцовки крыльев и экономим 1% топлива”. Но их там много и сразу.

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

Думаю, в 2017 javascript overall превзойдёт Java по скорости.

И ещё один прогноз, уже совсем волюнтаристский. Думаю, к ~2020 мы увидим ОС, предположительно для IoT, в которой JS-engine будет на той же роли, на которой сейчас в Андроиде Dalvik.

ermouth: (Default)

В самом конце 2013 я с уверенностью предположил, что в 2014, максимум в 2015 мы увидим порт Win 95 под браузер.

Я ошибся на месяц, да.

Снимок-экрана-2016-02-01-в-17.06.17

https://win95.ajf.me/win95.html, я пробовал в Хроме. Время от времени сайт лежит – туда сегодня куча народу ломанулось.

Оно вообще довольно долго стартует – потому что выкачивает под 100Мб с черепашьей скоростью. Причём кэшируется примерно треть, остальные 2/3 выкачиваются на каждой перезагрузке страницы, ой вэй. Ну это легко поправить – и, я думаю, поправят.

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

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

19-летний чувак сделал. Я фигею.

ermouth: (Default)

Год начался по-високосному.

Для начала, у меня посреди зимы в зверскую сушь и морозяку (на улице –25, дома +25) зазеленела моя новогодняя ёлка, с верхушки. И, похоже, собирается цвести дальше вниз. Это вот называется “апикальный рост”:

IMG_1484

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

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

Яваскриптовое опенсорц комьюнити внезапно тоже зимой “расцвело”. Я ожидал примерно чего-то такого в 2016, но не подряд, и не таких масштабов:

  1. Oracle выпустил JS-рантайм для JVM, причём по заявлениям довольно шустрый. Назвали Грааль (Graal).
  2. Microsoft заопенсорцила Chakra Core – JS-engine из IE11 и WinJS.

Эзотерические названия вполне закономерны, приличные JS-компиляторы уже давно ворочают минимум двумя уровнями intermedite representation и некоторые механики, скромно рисуемые вот на таких схемках как Bailout – чистый хак и магия.

chakracore_pipeline

То, что MSFT выложила свой JS-энджин в опенсорц для меня полная неожиданность. Там у них какой-то совсем тектонический сдвиг.

А вот то, что Oracle сделает в какой-то момент нормальную JS-машину я предполагал, но совершенно из сторонних соображений. Дело в том, что HotSpot вырос из компилятора Smalltalk’а под названием Strongtalk. Который придумал чувак по имени Ларс Бак 20 лет назад.

Он же, неожиданно, придумал Google V8 – самый быстрый JS-компилятор до недавнего времени. Все основные идеи в V8 – родом из Strongtalk’а. Раз эти идеи породили отличный JS-компилятор в одном месте, странно было бы, если б они не выросли во что-то похожее где-то ещё.

Конвергентная эволюция, да. Нисколько не удивлюсь, если найду в Чакре в том месте, что изображено загнутой стрелкой Bailout, те же идеи, кстати.

Апикальный рост начинается примерно одновременно сразу в нескольких местах, ога )

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

Апофеоз истории вот тут https://github.com/pouchdb/pouchdb/issues/3961. В результате я написал тест, который имитирует, что происходит в cloudwall без запуска cloudwall – но оказалось, что этот тест никто кроме меня не может воспроизвести. А у меня он железно воспроизводился на двух моих Маках в 100% случаев – но только для двух доменов, для остальных доменов всё было ок. Я даже стал подозревать в какой-то момент, что зелёные человечки – не выдумка (шучу :)

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

Так и оказалось – на обоих Маках у меня были сбои на FS. На эйре, видимо, деградировал SSD, а на iMac – HDD, который часть Fusion Drive. Именно поэтому баг и не проявлялся, пока не закроешь вкладку в Хроме – браузер закрывал файл, а файловая система его обнуляла из-за ошибок в бинарном дереве каталога.

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

Из этого надо вынести несколько уроков:

  1. БД ни при каких обстоятельствах не должна считать нижележащую технологию надёжной. А так считают и PouchDB, и IndexedDB и, увы мне, CloudWall.

  2. При обнаружении багов с потерей данных идти надо начинать снизу вверх, а не сверху вниз. Это тот-же ровно принцип, как и в случае с проверкой розетки, питания и предохранителей в первую очередь, когда «компьютер сломался». Я как-то не соотносил эту народную мудрость с высокими технологиями, а напрасно.

  3. Баг – лучший учитель. Я за последнюю неделю досконально разобрался, как устроен PouchDB  в части репликации, внешних ajаx-запросов и взаимодействия с IndexedDB. Попутно разобрался со схемой запросов к IDB по-хорошему (ну и гадость, доложу я вам), с производительностью IDB, с тем, как устроены файлы каталогов в HFS+, и много ещё чего попутного по мелочи.

Такие дела. Извинился перед чуваками за наезд – хотя он бесспорно был небесполезен. Я ясно вижу, что они меняют и тесты, и сам подход.
ermouth: (ang)
По совету morfizm написал лонгрид на Медиуме – про историю с PouchDB.

https://medium.com/@ermouth/making-pouch-a-db-a5c7ee4dbd60

Первый длинный пост на инглише, ога. Ругайте. И инглиш тоже )
ermouth: (Default)

Отличный материал про промисы, от самого активного контрибутора PouchDB.

http://pouchdb.com/2015/05/18/we-have-a-problem-with-promises.html

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

Снимок экрана 2015-05-19 в 19.09.24

Вообще, систематическое применение промисов порождает вот такой, например, код:

Снимок экрана 2015-05-18 в 19.08.45

Снимок экрана 2015-05-18 в 19.09.49

Это реальный код из cloudwall.me, слева – старт приложения, справа – старт системы. По читаемости с коллбэками не идёт ни в какое сравнение, конечно. Нельзя сказать то же о скорости и прожорливости, но всё не так плохо.

http://spion.github.io/posts/why-i-am-switching-to-promises.html

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

ermouth: (Default)

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

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

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

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

Read more... )
ermouth: (Default)

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

http://www.mongodb.com/blog/post/high-performance-benchmarking-mongodb-and-nosql-systems

Интересно в этой публикации что она – враньё. Ребята из монго озвезденели настолько, что решили себя посравнивать с Couchbase (не путать с CouchDB). И получилось у них, что монго типа быстрее раз в 25.

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

Любому, кто своими руками сравнивал монго и couchbase (как я), понятно, что это полная херня – потому что монго с любыми ухищрениями многократно медленней.

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

Couchbase не замедлил ответить.

MongoDB performs well when it 1) is limited to a single node, 2) doesn’t store a lot of data, and 3) doesn’t support a lot of users. This is a sweet spot for MongoDB.

http://blog.couchbase.com/mongodb-rules-single-node-deployments

Тут в цитате всё правда. Монго это такая БД, для тех кто уже не хочет MySQL, а хочет по-модному, чтобы JSON – но при этом с запросами, похожими на SQL. Правда, даже в этом случае Postgre куда лучше подходит, чем Монго.

Реальная картинка сравнения Couchbase и Mongo выглядит примерно так:

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

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

---

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

ermouth: (Default)

Новое модное веяние, во многом – просто красивое название для концепции distributed render, которая у меня оформилась в середине 2012. Дополнительно к distributed render это ещё и быстрая синхронизация локальных данных клиента и сервера, максимальная согласованность того, что в UI и того, что в главной БД.

Ну и главная фишка – более-менее единый код для клиента и для сервера.

Я с этими штуками за 3 последних года вдоволь наэкспериментировался вдоль и поперёк – просто не называл это isomorphic javascript. В этой связи у меня оформилось несколько стойких соображений.

Изоморфность, когерентность и диффы

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

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

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

Простой пример. У нас есть чатик, который дописывает узлы в какой-то док по мере появления реплик. Пусть он их передаёт diff-ами, например.

Мы начинаем передавать в чатик 10 картинок по 10 мегабайт каждая. Добавляем их в UI – и хотим написать реплику со ссылкой на одну из картинок.

Если мы требуем ссылочной когерентности – реплика не сможет быть отправлена в БД до того, как туда попадут картинки. Это, конечно, так себе чатик будет.

То-есть требование ссылочной когерентности отвалилось на простейшем юз-кейсе. Ну или нам надо сделать такую БД в которой два произвольных апдейта всегда коммутируют – что-то не видать таких, ога.

Итого: изоморфность – наверное, когерентность – видимо нет.

Декомпозиция задачи

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

Мы, в идеале, хотим иметь такую среду исполнения, приложения которой:

  1. можно использовать на клиенте как UI для модификации подлежащего документа,
  2. можно использовать на сервере как валидатор,
  3. можно использовать на сервере как параметризуемый шаблон, генерящий HTML,
  4. не должны заботиться, где вообще находится документ и его реплики.

Ну и мы подразумеваем, что у нас приложение – это одинаковая сущность и для клиента, и для сервера.

Условие №1, клиентский UI – чисто здравый смысл. Приложения – они для людей.

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

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

С точки зрения математики каждый валидный документ приложения образует неподвижную точку для функции, которая “вычисляет” приложение над документом.

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

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

Условие №3. Приложение как параметризуемый шаблон. Это считается главной серебряной пулей, чуть не самой желанной фичей. Дескать чтобы вот передать на сервер URL – а он тебе HTML-снапшот приложения в нужном состоянии.

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

Это серебряной пулей считается напрасно, хотя усилия по реализации предприняты в целом колоссальные. Это примерно так же переоценено, как responsive layouts. Да, иногда нужно, и даже удобно – но если всё так делать, то это очень ограничивает.

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

То-есть не надо смешивать две задачи:

  1. Максимально эффективно скормить гуглу вашу базы.
  2. Иметь на сервере функцию, которая может вам прислать HTML-снапшот вашего приложения в любом его состоянии.

Первая задача стОит, чтобы её решать, вторая – ну её нафиг.

Условие №4. Среда исполнения должна сама выбирать стратегию распространения изменений по уровням кэша (локальная БД >> удалённая БД или несколько удалённых БД, пиринговая доставка другим юзерам, дайджесты на емэйлы и тп).

Ну или как минимум давать максимально удобно конфигурировать параметры стратегии.

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

Я такую конструкцию в части API к БД смог довольно быстро собрать – но в целом оно довольно неудобно. С одной напрягает бардак с promise. С другой – с памятью.

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

Серверные API, напротив, просто обязаны давать возможность обрабатывать данные экономно с точки зрения монопольного занятия CPU и памяти надолго.

Это, вообще говоря, требования противоречивые (ситуация кста касается и пункта №2 про валидатор).

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

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

Итого

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

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

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

Вообще, думаю, тут не обойдётся без появления нового языка (или следующей итерации JS) – и он будет ближе к Erlang по компоновке кода и соглашениям, чем к JS.

ermouth: (ang)

Прочитал на Хабре про успехи npm и решил написать пост. npm – это пакетный менеджер и публичный репозиторий для node.js, и успехи реально очень впечатляющие.

Снимок экрана 2015-01-10 в 7.04.56

Фишка в том, что этот репозиторий – база CouchDB. Не “веб-сервер плюс БД”, а именно просто БД. Кластер там, с обвесами – но основные функции выполняет CouchDB, вот на её мету прямой выход. И именно CouchDB там используется неспроста.

Доступность

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

По-хорошему, CouchDB сразу после установки становится веб-сервисом. Доступ к БД – только через http(s)-запросы, через REST-интерфейс, то-есть веб-сервер уже встроен в БД. Веб-приложение админки тоже встроено в БД, аж в двух версиях.

Система контроля доступа – простая, но совершенно железобетонная – тоже встроена в БД, как и механика авторизации.

БД умеет синхронизироваться в непрерывном режиме с другими экземплярами через http(s), в тч в режиме “мастер-мастер”. Протокол репликации хорошо документирован и основан на согласовании деревьев ревизий.

Последняя фича, например, значит, что можно иметь полную локальную “живую” копию npm. Можно даже в браузере, без установки CouchDB.

Хранение и запись

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

Операция записи/обновления – просто POST запрос, например, аяксом. Запись неблокирующая, это называется MVCC, и тут он честный, а не как в табличных БД.

У каждого дока есть ревизия, которая состоит из номера версии и случайного значения (типа 15-12efdab). При каждой записи в док версия инкрементится, а значение меняется. Записать в док можно только отправив значение предыдущей ревизии, причём если сохранённая ревизия не равна отправляемой, запись отменяется.

Запись идёт в режиме “append only”, ничего не пишется поверх. Это значит, что база помнит все ревизии документов до тех пор пока не будет выполнена операция очистки/оптимизации. Также это значит, что база выжимает из SSD-дисков всё, на что они способны – и при этом их бережёт.

И самое главное – к JSON-документам возможны файловые аттачи, примерно как к емэйлам. То-есть это не просто блобы, это блобы с именем и mime-типом.

Выборка по ключу

Нет ничего проще – GET-запрос типа domain/dbname/doc_id – например https://ermouth.couchappy.com/cwmanual/cw-Demo-Controls-4vx1 – сразу отдаст JSON-документ.

В этом документе есть приаттаченный файл – картинка. Она тоже доступна по прямой ссылке https://ermouth.couchappy.com/cwmanual/cw-Demo-Controls-4vx1/turing.jpg. Вот она, отображается прямо из CouchDB.

Выборка запросами

Любая выборка запросом из CouchDB – это выполнение map/reduce и выдача запрошенного диапазона ключей.

Именованные пары map/reduce функций, к которым выполняются запросы, хранятся в самой БД в специальных документах. Документ выглядит примерно так ermouth.couchappy.com/cloudwall/_design/cloudwall. Видно, что функция – javascript.

Снимок экрана 2015-01-10 в 8.50.45

Запрос к этой map/reduce паре (в которой reduce, правда, нет) выглядит примерно так:
ermouth.couchappy.com/cloudwall/_design/cloudwall/_view/info?startkey="cw"&endkey="cwz"

На выходе – краткая информация о документах в базе, подготовленная map-функцией. В диапазоне ключей cw…cwz.

Важнейшее отличие CouchDB от других БД – результаты вычислений map/reduce кэшируются и повторно map-функции не вычисляются, если документ не обновился.

То-есть map/reduce не требует фуллскана каждый раз, как, например, это происходит в Mongo. Фактически map-функции используются для построения индексов.

Валидация записи и частичное обновление

POST-запросы на запись могут проверяться в БД функциями-валидаторами. Они тоже js и тоже хранятся прямо в БД как специальные документы. Например, вот эта функция не даст писать в БД, если вы не авторизованы:

Снимок экрана 2015-01-10 в 9.03.51

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

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

Применимость CouchDB

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

Табличка вот по кейсам, 0 – совсем не подходит, 5 – лучше не придумаешь.

Версионированные хранилища доков 5
Распределённые синхронизированные хранилища 4
Хранилища частично нормализованных связанных данных 1-4
Полностью нормализованные данные 0
Быстрые логи 2
Медленные логи / Агрегаторы логов для анализа 5
Вообще большие наборы данных для анализа 5
Необходимость транзакционной целостности 0
Сложные повторяющиеся “фигурные” выборки 4
Выборки сабсетов узлов документов (частей документов) 5
Подключенные клиенты хотят уведомлений, что база обновилась 4
Хранение файлов (типизированных блобов) 4
SSD диски как хранилище 5+++
Синхронизация / репликация по каналам с потерями и обрывами 5+++

CouchDB вместо сервера приложений

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

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

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

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

----

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

Есчо, на Винде тоже прекрасно работает.

ermouth: (Default)

Хорошая умеренно доступная работа про сабж. http://arxiv.org/pdf/cs/0409016v1.pdf, инглиш естессно.

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

Так вот, под перечисленные фичи “базового языка” в главе 2 публикации просто безукоризненно подходит яваскрипт. А примеры из главы 5 на нём прекрасно переписываются (что неудивительно, создатель javascript держал в голове Scheme, язык примеров из монографии).

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

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

Просто наткнулся на хорошее изложение. Ещё раз – Domain Specific Languages, 8 страниц всего.

jQuery.my

Jun. 22nd, 2012 03:13 am
ermouth: (Default)

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

Так вот, я сделал под это всё сайт. Ну, то-есть делаю. Туториал с примерами уже просто чумовой. Ну и публичная бета для экспериментов.

Всё на кривом инглише, сорри ) Форма на заглавной тыкабельна и сделана как раз с помощью $.my.

Снимок экрана 2012-06-22 в 2.40.29

Оно реально очень крутое – там элементарный синтаксис, 7 слов надо запомнить, чтобы начать делать формы интерактивные.

Пример, что на jQuery.my рисуется при навыке за полтора вечера – на картинке вот, кликабельно:

Снимок экрана 2012-06-22 в 2.42.08

Тут форма с кучей взаимосвязей, ограничений, сложной формулой расчёта – всё один instance jQuery.my.

Веб-деятели, enjoy! Ну и RT plz )


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 07:30 pm
Powered by Dreamwidth Studios