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

редактирование отношений: 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