Category: история

Category was added automatically. Read all entries about "история".

flow

Про dependency graph

Тут народ спрашивает, чем реализация UI через dependency graph может быть лучше обёртывания retained mode в immediate mode (типа React) или FRP. Отвечаю: всем.

Так как граф зависимостей может включать в себя _любые_ цепочки преобразований, включая и типовую (server DB, server API, client DB, client UI). В этом его отличие от гадюшников типа MVC, MVP, MVVM или других решений, представляющих лишь частичные решения для последнего звена этой цепи.

Что характерно, команды, разрабатывающие React в FB, это тоже понимают. Прекрасной видеоиллюстрацией этого служит доклад React.js Conf 2015 - Data fetching for React applications at Facebook: https://www.youtube.com/watch?v=9sc8Pyc51uU

Один из примеров работы с зависимостями есть на 12:20 этого видео. Это лучше и надёжнее, чем распространённые на сегодняшний день решения.

Но мой интерес в этой теме идёт несколько дальше. На самом деле, в примере с queries и render можно избавиться от queries, автоматически выводя зависимости из render. И это не так дорого сделать. Но есть и другие частные случаи, где вывод и верификация зависимостей будут кстати. Более общая модель dependency graph делается сложнее. Однако, и перспектив в этом случае больше.
flow

Разные ниши

Прочитал в http://wizzard0.livejournal.com/340036.html про NoFlo. Да, даже в нашем 21-ом веке всплывает то самое дерьмо мамонта с "революционным программированием мышкой". Теперь - в модной хипстерской обёртке и на кикстартере. Грусть-печаль.

Минутка Капитана Очевидности:
Почему это плохо работает и всегда работало плохо?
1. В FBP зафиксирован низкий уровень абстракции, ручная обработка потоков данных. Если для начала семидесятых FBP был где-то над средней температурой по больнице, то сейчас время сущностей высших порядков и метапрограммирования, позволяющих добиваться лучших результатов меньшим количеством кода. Однако, вы не сможете ими воспользоваться в NoFlo-подобных решениях. Вполне может быть, что сами авторы NoFlo не умеют ими правильно пользоваться.
2. Графовые представление значительно более затратны в разработке и поддержке. А если диаграмма в рабочем размере не помещается в экран, то её необходимо разбить на несколько, иначе любые когнитивные улучшения графов относительно текста автоматически теряются.

Далее о неочевидном - откуда, в таком случае, берутся success stories продуктов, где описание процесса обработки данных происходит именно на диаграммах? Они берутся из совершенно другой ниши. Синтезаторы Sync Modular и NI Reaktor, демомейкерская среда werkkzeug, etc - это не средства программирования. Это средства дизайна. Работа в них - не написание правильного алгоритма, а процесс поиска тех сочетаний кубиков и параметров, которые приводят к эстетически подходящим результатам. Здесь часто пригоден уровень абстракции FBP, а проблема крупных графов не стоит так остро. Очень важно, что результаты отдельного преобразования или всей цепочки можно сразу посмотреть, послушать, а затем принять или продолжить редактирование. Сюда же относятся инфографические фокусы Брета Виктора. Это отдельная, очень красивая ниша.

Текст выгоднее для обработки данных, а диаграммы хороши для синтеза эстетики. Такие дела. А на хипстерское разводилово вестись не надо - проекты целее будут.
flow

Дополнение

В дополнение к http://justy-tylor.livejournal.com/205218.html

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

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

Непонимание такого базового различия некоторыми программистами приводит в ад к коровникам к созданию странных продуктов (Git, Mercurial, ...), понять темпоральную природу которых не могут ни их авторы, ни авторы сопутствующих гайдов по навигации между граблей.
flow

Графы

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

Навеяно http://ailev.livejournal.com/1069810.html

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

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

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

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

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

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

Прототипы

В комментариях отвечал на тему прототипов, выношу в отдельный пост.

Что читать:
George Lakoff "Women, Fire, and Dangerous Things"
Douglas R. Hofstadter "Gödel, Escher, Bach: An Eternal Golden Braid"
... и от них далее по референсам

Где смотреть:
Системы организации данных в САПРах и средах 3D-моделирования (атрибуты+клонирование)
Lua (как наиболее наглядный пример из языков с динамической типизацией)

Можете ещё погуглить на тему "prototype-based programming", но чисто для исторической справки, пейперы обычно хлам.
flow

редактирование отношений: N-Edge Tree

В последнее время меня очень интересовал вопрос: как удобно представить для редактирования произвольную систему фактов/отношений. Обычно всё сначала сводится к графу.

Отношения в графе могут быть такие:
Вася любит Свету
Vasya -(loves)> Sveta

... или такие:
P-123 is classified as a centrifugal pump
P-123 -(is classified as a)> centrifugal pump

Этот граф может быть нарисован в красивой тетради, с оформлением из сердечек, или диаграммой стандарта [...] в специальном редакторе. Но если схема отношений достигает определённого уровня сложности - ей уже не поместиться на листке тетради, и даже диаграмма в редакторе становится слишком запутанной для восприятия. Что ещё можно использовать кроме списков и диаграмм? Смотрите дальше с картинками.
Collapse )

Приветствуется как использование этого материала, так и интересная обратная связь.


Иллюстрация:
Напоследок, ещё одна картинка. Визуальный дизайн деревьев может различаться. Такие отношения лучше представимы в дизайне девичьей тетради - с сердечками, каваем и приятными спецэффектами. Кстати, вполне себе идея для приложений в социальных сетях - "пиши анкеты на записках-самолётиках, рисуй отношения своих друзей". Тоже хитрые сплетения связей. :)
  • Current Music
    Iwasaki Tarou