Итак, что имеем на данный момент?
— Есть модульность — папки с сущностями вкладываются друг в друга но нет зума, да и как он должен тогда работать? На минимальном зуме всё приложение будет парой квадратов с толстыми канатами, это ок? А как должно быть?
— Есть аккуратная геометрия линий — они огибают друг друга, стараясь не пересекаться изо всех сил, но при этом на больших масштабах все равно сливаются вместе. При этом их могут быть сотни. Нужно их как-то объединять логически, как? Также их нужно и разделять по смыслу, чтобы понимать, какие сущности с какими связаны, как это сделать?
— Позиционирование надписей — они просто нигде не влезают и пока сделаны по остаточному принципу. Мб выносить как на инженерных чертежах? Добавить ещё линий в хаос. Делать плашки? Затеняет связи. Обтекать линиями? Всё равно не поместятся при большом отдалении
— Как показывать связи (сэмплы) чтобы было понятно что это именно они — сэмплы это точки в которых соединяются три линии сразу, а то и четыре. Одна исходящая и несколько входящих
— Кстати, как показывать направление движения?
— Есть модульность — папки с сущностями вкладываются друг в друга но нет зума, да и как он должен тогда работать? На минимальном зуме всё приложение будет парой квадратов с толстыми канатами, это ок? А как должно быть?
— Есть аккуратная геометрия линий — они огибают друг друга, стараясь не пересекаться изо всех сил, но при этом на больших масштабах все равно сливаются вместе. При этом их могут быть сотни. Нужно их как-то объединять логически, как? Также их нужно и разделять по смыслу, чтобы понимать, какие сущности с какими связаны, как это сделать?
— Позиционирование надписей — они просто нигде не влезают и пока сделаны по остаточному принципу. Мб выносить как на инженерных чертежах? Добавить ещё линий в хаос. Делать плашки? Затеняет связи. Обтекать линиями? Всё равно не поместятся при большом отдалении
— Как показывать связи (сэмплы) чтобы было понятно что это именно они — сэмплы это точки в которых соединяются три линии сразу, а то и четыре. Одна исходящая и несколько входящих
— Кстати, как показывать направление движения?
До этого года я для скетчей и прототипов использовал графику углём и лайнерами — чёрно-белая стилистика. Очевидно, что визуализации требуют цвета, поэтому прежде чем воплощать идеи в коде, нужно заново ставить руку, на цвет.
Пастель, озеро Иссык в Казахстане так как его вижу я и каким оно было в реальности в моём фотоаппарате) К счастью, особо много навыков получать не требуется, просто базовый уровень рисования и умения чувствовать цвет. Этим и занимаюсь)
Пастель, озеро Иссык в Казахстане так как его вижу я и каким оно было в реальности в моём фотоаппарате) К счастью, особо много навыков получать не требуется, просто базовый уровень рисования и умения чувствовать цвет. Этим и занимаюсь)
Draw svg rope
Всё как я люблю: проектирование на бумаге, использование возможностей свг, анимация, интерактивная статья. Может тоже попробовать отрисовывать верёвки в качестве бандлов линий?)
Всё как я люблю: проектирование на бумаге, использование возможностей свг, анимация, интерактивная статья. Может тоже попробовать отрисовывать верёвки в качестве бандлов линий?)
Muffin Man
Draw SVG rope using JavaScript
This is an interactive article. To fully experience it, you'll need to turn JavaScript on.
Today, I'll take you through the process I came up with …
Today, I'll take you through the process I came up with …
Я собрал минимальный набор требований к тому, что должна уметь схема, чтобы быть полезной:
— Нужно выбрать два сервиса в коде и подсветить «путь» которым они связаны между собой.
— Нужно увидеть кто зависит от юнита/сервис/папка
— Нужно увидеть от кого зависит юнит/сервис/папка
— Файлы других команд и в целом нерелевантный код в проекте нужно уметь сворачивать на произвольную глубину — от полностью свернутых до полностью развернутых
Это то, чем я планирую заняться и выпустить наконец первую публичную версию именно с ними
Из проблем:
— Разумеется эти требования потребуют новых дизайнерских решений на графе: как это должно выглядеть, как с этим нужно управляться, и как это запрограммировать
— С момента предыдущего подхода к визуализации у нас в эффекторе заметно поменялся принцип работы с такими сущностями, теперь это всё делается через Inspect API, открытый вопрос насколько этот апи подходит для такой задачи, ведь код обработки графа перехватывает вызовы операторов, чтобы уметь вести записи вида «sample: clock [units], no filters, no targets, returned unit is called $foo, this is a store placed in file services/foo»
Но думаю с этим уже можно иметь дело
— Нужно выбрать два сервиса в коде и подсветить «путь» которым они связаны между собой.
— Нужно увидеть кто зависит от юнита/сервис/папка
— Нужно увидеть от кого зависит юнит/сервис/папка
— Файлы других команд и в целом нерелевантный код в проекте нужно уметь сворачивать на произвольную глубину — от полностью свернутых до полностью развернутых
Это то, чем я планирую заняться и выпустить наконец первую публичную версию именно с ними
Из проблем:
— Разумеется эти требования потребуют новых дизайнерских решений на графе: как это должно выглядеть, как с этим нужно управляться, и как это запрограммировать
— С момента предыдущего подхода к визуализации у нас в эффекторе заметно поменялся принцип работы с такими сущностями, теперь это всё делается через Inspect API, открытый вопрос насколько этот апи подходит для такой задачи, ведь код обработки графа перехватывает вызовы операторов, чтобы уметь вести записи вида «sample: clock [units], no filters, no targets, returned unit is called $foo, this is a store placed in file services/foo»
Но думаю с этим уже можно иметь дело
effector
inspect 🚀 effector
Business logic with ease.
Для визуализации наметился настоящий стресс-тест — снапшот юнитов в рабочем приложении это json-файл в пол миллиона строк 🫠 Сам визуализатор я пока ещё не запустил, но по всей видимости это будет крайне весело))
Запустил на выходных визуализацию 🫠 Ура новым визуальным багам! Всё оччень интересное, даже жаль что чинить надо. Почему-то начали выезжать блоки с пачками юнитов (точки разных цветов) друг за друга, а папки наоборот, схлопываются в ноль. По прежнему не понятно, как тестировать визуальные баги, кроме как визуально. Запускать puppeter со скринами для юнит тестов как-то жёстко по моему.
Но это ладно, оказалось что увеличение снапшота проекта в 10 раз руинит производительность квадратично. Всё оччччень медленно, вычисления для этого проекта занимают полторы минуты. Переписывать лейаутинг на раст желания пока нет, придётся оптимизировать в жс. Проблем две — роутинг линий и лейаутинг юнитов. Первая проблема прямолинейная — алгоритм A* в текущей реализации не вывозит поля размером в десятки тысяч клеток с многочисленными стенами по пути. Вторая проблема изощреннее — размер папок пересчитывается до тех пор пока в папку не влезут все юниты которые требуются, пересчитывается рекурсивно (до верхней папки), смещая всех соседей, при каждой новой строке/столбце в папке. Не оч понятно как этот алгоритм называется, поэтому он самописный. Очевидно он багованый и медленный. Придётся ресечить. Каждый перезапуск ресерча — полторы минуты. Ээхх
Но это ладно, оказалось что увеличение снапшота проекта в 10 раз руинит производительность квадратично. Всё оччччень медленно, вычисления для этого проекта занимают полторы минуты. Переписывать лейаутинг на раст желания пока нет, придётся оптимизировать в жс. Проблем две — роутинг линий и лейаутинг юнитов. Первая проблема прямолинейная — алгоритм A* в текущей реализации не вывозит поля размером в десятки тысяч клеток с многочисленными стенами по пути. Вторая проблема изощреннее — размер папок пересчитывается до тех пор пока в папку не влезут все юниты которые требуются, пересчитывается рекурсивно (до верхней папки), смещая всех соседей, при каждой новой строке/столбце в папке. Не оч понятно как этот алгоритм называется, поэтому он самописный. Очевидно он багованый и медленный. Придётся ресечить. Каждый перезапуск ресерча — полторы минуты. Ээхх
lines of code
Запустил на выходных визуализацию 🫠 Ура новым визуальным багам! Всё оччень интересное, даже жаль что чинить надо. Почему-то начали выезжать блоки с пачками юнитов (точки разных цветов) друг за друга, а папки наоборот, схлопываются в ноль. По прежнему не понятно…
Читаю Hackernews, часто подкидывает интересные инсайты, и вот вновь помогло: наткнулся на статью Treemaps are awesome, и в принципе меня убедило — они действительно могут справиться с проблемой компоновки блоков. Возьму d3-hierarchy, но видимо всё равно придется форкать: блоки расположены не случайным образом, есть блок title (название папки), который всегда добавляется последним, занимает одну клетку в высоту и всю ранее подсчитанную ширину блока. Более чем уверен, что без модификации кода d3 такие расчёты проводить не сможет.
Вообще, это основная проблема с d3, я именно поэтому его не использую: все его пакеты, даже вычислительные, очень обобщенные, затюнить его под какую-либо конкретную задачу за пределами стандартной визуализации крайне сложно. Но всё же, это гораздо лучше чем писать компоновку самому с нуля. Уже прогресс!
Вообще, это основная проблема с d3, я именно поэтому его не использую: все его пакеты, даже вычислительные, очень обобщенные, затюнить его под какую-либо конкретную задачу за пределами стандартной визуализации крайне сложно. Но всё же, это гораздо лучше чем писать компоновку самому с нуля. Уже прогресс!
Telegram
Hacker News
Treemaps are awesome (Score: 150+ in 8 hours)
Link: https://readhacker.news/s/5KWFW
Comments: https://readhacker.news/c/5KWFW
Link: https://readhacker.news/s/5KWFW
Comments: https://readhacker.news/c/5KWFW
Получилось реализовать производительный box packing по сильно затюнингованному алгоритму команды mapbox. Какое счастье что такие наработки вообще есть в открытом доступе. Кода в этом алгоритме всего сто строк, но это такие строки, которые точно не хотелось бы писать с нуля, есть риск утонуть
Tree maps из d3, ожидаемо, не подошли — d3 делит пространство заранее заданных размеров на части дробной величины, в то время как у меня размер поля суммируется из размеров отдельных блоков дискретной ширины и высоты. Это важно, потому что алгоритм прокладывания линий работает только в дискретном (целочисленном) поле. Как обычно, если с d3 выйти за рамки заранее предусмотренных сценариев использования, то библиотека становится бесполезной
На втором скрине гигантский проект aviasales (уместилась примерно треть). Визуально это уже напоминает проектирование микросхем 😃
Tree maps из d3, ожидаемо, не подошли — d3 делит пространство заранее заданных размеров на части дробной величины, в то время как у меня размер поля суммируется из размеров отдельных блоков дискретной ширины и высоты. Это важно, потому что алгоритм прокладывания линий работает только в дискретном (целочисленном) поле. Как обычно, если с d3 выйти за рамки заранее предусмотренных сценариев использования, то библиотека становится бесполезной
На втором скрине гигантский проект aviasales (уместилась примерно треть). Визуально это уже напоминает проектирование микросхем 😃
Буду выступать на holyjs с докладом о подходе к визуализации бизнес логики и архитектуры приложений над которым я работал последние пять лет 😌 Эффектор, со всей своей декларативностью был написан чтобы это стало возможным
HolyJS 2023 Autumn. Конференция для JavaScript‑разработчиков
Визуализация архитектуры приложений | Доклад на HolyJS 2023 Autumn
Дмитрий расскажет о новом подходе к визуализации архитектуры приложений неограниченного масштаба. Обсудит устройство визуализаций больших схем, детали дизайна, а также принципы стейт-менеджера effector, которые позволяют визуализировать работу команды и взаимосвязи…
Теперь, когда холи наконец позади, можно вернуться к насущным вопросам 😃 Нужно починить линии (я рассказал про это на докладе), после чего уже можно пробовать сделать сворачивание-разворачивание блоков
Придется доработать bin packing чтобы можно было вешать «якоря» к блокам чтобы они не разъезжались при изменении пространства рядом с ними, но выглядит это явно проще, чем алгоритм оптимизации линий
Stay tuned!
Придется доработать bin packing чтобы можно было вешать «якоря» к блокам чтобы они не разъезжались при изменении пространства рядом с ними, но выглядит это явно проще, чем алгоритм оптимизации линий
Stay tuned!
Публичное апи — неотъемлемая часть сервиса в приложении. Детали реализации можно изучать, но нужны они не всегда. Поэтому изображение сервиса состоит из двух частей — публичного апи (юнитов с которыми взаимодействуют другие модули) и полной реализации со всеми подробностями
Зеленые линии обозначают расположение публичных юнитов из левой части в общей схеме сервиса
Отсюда следуют два полезных вывода:
1) Для отображения сервиса в общей схеме приложения нужно изобразить лишь его публичный апи
2) Весь блок публичного апи можно использовать для расположения его составляющих, ранее, в подходе с портами для этого использовались лишь края модуля. Теперь понятно где расположить весь текст!
Зеленые линии обозначают расположение публичных юнитов из левой части в общей схеме сервиса
Отсюда следуют два полезных вывода:
1) Для отображения сервиса в общей схеме приложения нужно изобразить лишь его публичный апи
2) Весь блок публичного апи можно использовать для расположения его составляющих, ранее, в подходе с портами для этого использовались лишь края модуля. Теперь понятно где расположить весь текст!