?

Log in

November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Че-та сюда написать забыл.

Есть набор весьма неприятных проблем, которые возникают в JS в случае, если слой данных SPA действительно сложен. Знаете, например, как на раз делается memory leak в JavaScript? Для мемори лика в языке с GC нам нужны две вещи. Синглтон, и подписка на события. И иногда, утечки добиться настолько легко, что это выглядит как фокус. Я объясню на примере BackboneJS.

Пусть у нас есть глобальная коллекция-синглон каких-то объектов - неважно каких, скажем, users. И где-то на одной из страничек нашего SPA мы выбираем юзеров из списка, и выбранные элементы лежат в другой коллекции. Временной. Которая живет столько же, сколько живет страница (пусть у нас SPA состоит из разных "страниц", которые он переключает меняя рауты).

Ну все, у вас уже утечка памяти. Откуда она берется? Коллекция в Бэкбон подписывается на событие change от своих элементов. Подписка на событие на самом деле означает, что объект, который источник события, держит обратную ссылку на получателя. Чтобы его уведомлять.

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

Ну конечно, если при смене страницы, которая ее создала (в случае SPA это не настоящее закрытие страницы, а лишь видимость, с точки зрения браузера страница одна), не удалить из всех этих коллекций все элементы, лежащие в синглоне. То есть, если у вас нет деструктора - у вас утечка памяти. И не важно, что у нас GC. Добро пожаловать в увлекательный мир, в котором живут программисты на С++.

Бэкбон - это был просто пример. Механизм этой проблемы таков, что ему все равно, бэкбон у вас или не бэкбон.

Так вот. Не знаю, как вы, но не хочу обратно в увлекательный мир С++, частью которого я уже был примерно 6 лет. Поэтому, NestedTypes 2.0 RC, который мы в Volicon/Verizon сейчас готовим к выпуску, и который сейчас лежит в основе наших приложений для мониторинга потоковых видео-трансляций, управляет памятью полностью автоматически. При условии, что вы отличаете агрегацию от ассоциации, и напишете об этом в декларации атрибута модели.

А вот о том, что такое агрегация в ОО - вот вам статья. С веселыми картинками и доступными примерами.

Статья с веселыми картинками


cartoon

NestedReact 1.0 beta. Hierarchical Checklist Demo.

Posted on 2016.08.08 at 21:50
Tags:
Пример из NestedReact 1.0 beta, которая сейчас в бранче develop.

Это вот такой иерархический чекист с правилом - группа выбрана тогда и только тогда, когда все дерево под ней выбрано. 79 строк кода за вычетом комментариев и пустых. В основе - новый движок транзакционных моделей, написанный на TypeScript (NestedTypes 2.0 beta). Кругом ES6 классы. Ни одного стора нет. Просто составное состояние в корневом элементе.



Так вот, здесь, не смотря на data binding и классическое ОО в слое данных - unidirectional data flow, и вовсю работает pure render оптимизация. Очень рекомендую на код посмотреть - я его закомментировал в литературном стиле. Там смотреть то почти не на что - кода тьфу.

https://github.com/Volicon/NestedReact/tree/develop/examples/checklistTree

И то и другое возможно на классических моделях без каких-либо проблем. Не верите - запустите и посмотрите в React Tools как там рендер происходит. :) Оно уже собрано, надо просто сделать клон репозитория, и открыть index.html. Да, эти линии - в них можно кликать мышкой и писать там. Это input на самом деле.

UPD: Теперь оно сохраняет и восстанавливает состояние работая с localstorage. В качестве демонстрации, что любое состояние сериализуемо.

ЗЫ: Все время слышу последнее время - mobx, mobx. Было бы клево, если бы кто-нибудь сделал аналогичный пример на mobx.

TypeScript: https://github.com/mikhail-aksenov/mobxChecklist
ES6: https://github.com/kvasdopil/checklistTree

Спасибо, ребята. Выглядит действительно очень похоже. Оба примера по 90 строк. Пример с NestedReact занимает столько же, только в отличии от примеров mobx он сохраняется в LocalStorage. Бесплатная сериализация - это самое основное отличие. Ну, могу еще для демонстрации отличий валидацию на текстовое поле навесить. :) У меня это делается в модели - "name : String" -> "name : String.has.check( x => x )", и поле с именем получит стиль error, если значение пустое. Красным станет, например. Само.

Полный список возможеностей сверх mobx - two-way data binding, декларативная валидация, миксины, коллекции с индексами по id вместо простых массивов, сериализация (с id-ссылками и без), REST.

ЗЗЫ: На всякий случай напоминаю, что этим волшебным моделям NestedTypes уже два с половиной года. Они как бэ пораньше mobx появились, у нас в Verizon поверх них уже 100К строк наколбашено. Я считаю, это освобождает меня от дурацких объяснений "а зачем оно написано если есть mobx". И если честно - я сильно сомневаюсь, что mobx сравним с NestedTypes по производительности на сериализации и синхронизации с сервером коллекций сложных объектов по десять тыщ элементов. У нас на таком сейчас в 2.0 beta субсекундный отклик, например (часть требований). А вот, например, Backbone на таком - сдохнет, он заблокирует тред браузера секунд на 10. И не только бэкбон :).

ЗЗЗЫ: Это вообще довольно глупый вопрос - "а зачем". Затем, что можем. Не хотим страдать с редуксами, как все, и не собираемся дожидаться, когда кто-то что-нибудь сделает с этим.

cartoon

Введение в NestedTypes

Posted on 2016.08.07 at 01:51
Tags: , ,
React ValueLinks, это конечно, хорошо, но пришло время рассказать о нашей основной технологии, которая лежит в основе продуктов Volicon/Verizon.

https://medium.com/@gaperton/introduction-to-nestedtypes-data-framework-69aff986287e#.nn1a3qsc7

Это универсальная технология управления состоянием приложения. Динамическая сериализуемая система типов для JS.

Мы используем ее в сочетании вот с этим:
https://github.com/Volicon/NestedReact

Которое замещает стандартный React State нашими моделями, и мы получаем сквозную технику управления состоянием. С двухсторонним databinding, естественно - для этого используются наши линки, о которых я писал раньше.

Не побоюсь сказать - это самая совершенная на данный момент технология управления состоянием. И самая простая в использовании.

cartoon

О точных науках

Posted on 2016.06.20 at 04:35
Когда я стал постарше, я, будучи воспитанным как ученый-математик, изменил свое отношение к гуманитарным наукам.

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

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

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

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

В этот момент ты становишься гуманитарием. Освобождаешься от оков "строгости". И начинаешь, наконец, познавать мир.

Математика - это неплохая тренировка ума. Но мир так интересен и разноообразен :). Его описывает не она. Искусство. Только оно способно кратко и точно донести всю правду о мире.

cartoon

TypeScript: Static or Dynamic?

Posted on 2016.06.15 at 21:49
Tags: ,
https://medium.com/@gaperton/typescript-static-or-dynamic-64bceb50b93e#.mbkvfp8hh

Про TypeScript, и немного про теорию языков программирования вообще.

В связи с ростом популярности TypeScript, оживились флеймы static vs dynamic languages. Стороны опять точат копья.

А дело в том, что война окончена. В статье я, взрывая мозг примерами, популярно объясняю, что такое soft type system. На примере TypeScript. Ну и заодно делая небольшой экскурс в терминологию и понятия теории языков программирования.


cartoon
Posted on 2016.06.09 at 02:26
К сожалению, сегодня совсем не веселая картинка. Я бы предпочёл про пм-ов рисовать.



Эта заметка про понятие "сложности" в ПО, и его связь с управлением проектами.

С веселыми картинками и забавными примерами.

https://medium.com/@gaperton/software-managing-the-complexity-caff5c4964cf#.crsq3slua

Во-первых, он таки в React есть. Называется value link. Это такой дизайн паттерн. И не смотря на то, что Фейсбук убирает свою кривую реализацию оного из React, он не может вам запретить его использовать.

Понимаем, что это такое, и учимся делать формы на React просто и приятно.

https://medium.com/@gaperton/managing-state-and-forms-with-react-part-1-12eacb647112#.m4awqrpf2

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

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

https://medium.com/@gaperton/react-forms-with-value-links-part-2-validation-9d1ba78f8e49#.nbf6s3zee

Ну и в третьих. Самое интересное в этом паттерне вовсе не тот очевидный факт, что он устраняет ненужные коллбэки. А то, что он позволяет полностью отделить (и инкапсулировать) способ, которым выполняется data binding, как от слоя view, так и от слоя данных. Чего вообще ни один из популярных фреймворков не может.

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

Учимся работать со сложным состоянием:

https://medium.com/@gaperton/state-and-forms-in-react-part-3-handling-the-complex-state-acf369244d37#.9f9rp5mwi

Помимо того, что это просто красиво - эта техника сокращает объем кода в JSX примерно вдвое.

https://medium.com/@gaperton/software-managing-the-complexity-caff5c4964cf#.3zdeyc03t

Такие дела.

Кому-то могло показаться после прочтении предыдущей статьи, что мне "просто нравится бэкбон", или что я считаю его лучшей в мире технологией. Это не так. Мы начали с backbone по двум причинам: (1) многие с него начинают, и (2) это, пожалуй, минимально возможный фреймворк для браузерных приложений.

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

Вообще-то это черновик, написанный в один проход. Но мне сегодня влом вычитывать.

more...Collapse )


Previous 10