СДВГ - это спектр симптомов, обусловленный биохимией работы мозга, причем еще проблемы эти могут возникать неравномерно в разных областях мозга приводя к разным эффектам. Кора больших полушарий - исполнительная активность, мозжечок - те самые беспокойные ноги (и я только ближе к 40 заметил, что я дествительно непроизвольно дергаю ногой когда сижу или лежу). И разумеется, что в разной обстановке и у человека с более типичным мозгом могут проявляться эти симптомы, могут отступать, и у СДВГшника ослабляться или усиливаться.
Нынешние привычки и образ жизни приводят к тому, что СДВГ усиливается у тех, кто его имеет, а СДВГ-подобные симптомы проявляются у тех, кто его не имеет. В конце концов, проблемы со вниманием, рассеянностью, неспособностью сконцентрироваться бывают у всех - это симптомы, как, например, симптом - высокая температура, являющаяся признаком воспалительного процесса. А вот причиной этого процесса может быть что угодно - от теплового удара и банальной простуды до лимфомы.
Но у СДВГ есть довольно специфические, более глобальные проявления, которые в ряде случае значительно ухудшают качество жизни. СДВГ - это не просто неспособность сконцентрироваться на чем-то - это неспособность сконцентироваться на том, что неинтересно. Причем неспособность буквально физическая, ты понимаешь, что это сделать нужно, проклинаешь себя, заставляешь - но не можешь. При этом тем, что тебе интересно в данный момент, ты можешь заниматься с упоением, часами, буквально забывая сходить поесть или в туалет, не обращая внимания на затекшие ноги. Интересная книга или сериал, о которых еще вчера не слышал - запоем, даже если завтра на работу. Пет-проект, новое хобби, внезапно возникшее желание нарисовать картину или собрать коллекторный узел. Ты начинаешь изучать тему, читать, смотреть, пробовать - иногда даже получается, иногда даже неплохо. Но потом к начатому пропадает интерес - буквально отрезает. И там, где другой человек может годами заниматься любимым хобби СДВГшник не подойдет и на пушечный выстрел. Вообще никогда в жизни или до следующей "маниакальной стадии".
Забывчивость - ключи, зонтики, кошельки, стики, зажигалки - иногда это выправляется жесткой дисциплиной и ритуалами проверки. Но часто теряется пачками. Можешь зайти в комнату и забыть зачем ты туда пришел. И так несколько раз подряд. Можно зайти в ванную, обнаружить грязный умывальник в 11 вечера, вытащить Кёрхер (интересно же) и начать убирать - мозг получил свой дофамин, ему классно.
Ну и отдельная песня - работа в условиях стресса. Когда наш проект был еще маленьким стартапом я обожал инциденты или баги на проде. Стресс - норадреналин - дофамин - и когда остальные коллеги начинают суетиться или не понимают что делать, у тебя открывается второе дыхание - даже если это вечер пятницы после тяжелой недели - ты НАКОНЕЦ-ТО чувствуешь себя замотивированным, тебе интересно, ты готов сидеть и ковырять этот баг до двух ночи, потому что нужно, потому что важно, потому что ИНТЕРЕСНО. Иногда это прикольно, конечно. но в целом врагу не пожелаешь. Но, насколько я понимаю, среди пожарных и спасателей должно быть много СДВГшников именно по этой причине.
Еще раз перечитал - вы вот здесь свернули сильно не туда.
И если попробовать проанализировать, что же у нас является состоянием в этом коде, то можно придти к мнению что текущим состоянием, которое подлежит загрузке в систему является не только состояние лампочек светофора, состояние включает в себя еще и периоды на которые эти лампочки зажигаются или выключаются!
Состояние автомата не равно состоянию светофора. Это вообще разные категории. Как и периоды, к слову. Лампочки - выходная функция от текущего состояния автомата, они никак в систему не загружаются и не должны, они являются выходом системы и входом станут только тогда, когда понадобится это состояние проверять, чтобы на основе наблюдения сделать следующий переход.
Временные интервалы - константы конфигурации. Автомату совершенно все равно какие они, 8-10-20, 3-5-15 - это один и тот же КА с двумя разными конфиграциями инстанса.
Лампочки - это уровень представления. Состояние автомата - это и есть индекс таблицы (или некоторая именованная метка). Пришли в узел графа, вызвали связанную с этим функцию (поведение), результат каким-то образом визуализировали (помигали лампочками), определили куда идти дальше.
Проблема с семантической перегруженностью термина State.
Control State - это и есть состояние автомата, индекс, енум, узел графа состояний.
Data State - это состояние светофора в памяти - то, что можно менять с помощью i/o операций - переменные, описывающие индикацию и датчики.
Presentation State - собственно состояние лампочек, спиннеры сайта, внешний вид кнопок (активна-не активна).
Смешение этих понятий и приводит к выбору неверных абстракций.
Ну вот я автору об этом и говорю: тот же класс задач, что требует конечных автоматов, но за счет того, что состояния меняются в простом цикле они могут быть редуцированы до табличной формы с безымянными состояниями. А он обижается.
Добавьте к вашему светофору внешние ивенты: кнопка пешехода (нажали и получили зеленый для пешехода, причем с нюансами - нужно ли выдерживать отрегулированный режим или нет), ночной режим (моргаем желтым), "зеленую линию", задаваемую извне - и попробуйте это описать вашей таблицей. Начнется каша, которую и устраняет КА.
Немного уточню. Фундаментальные решения - это, скорее, инварианты. Не доменные и системные ограничения, а те базовые решения, когда выбор был произведен из нескольких возможных и сделан аксиомой - тем самым фундаментом, на котором архитектура строится. Архитектура может быть и достаточно гибкой, в примере с гаражом это, скорее, не его размеры (инвариант), а постройка гаража на участке заданного размера и в заданном месте из выбранных материалов так, чтобы он мог при необходимости разместить две машины, а в их отсутствие быть мастерской и хранить нужные вещи. Вот с учетом этих требований-инвариантов дальше и выстраивается архитектура. И цементирование происходит тогда, когда мы размываем границу между дизайном и архитектурой, верстак ставится не на пол, а на отлитый для него бетонный постамент, приборы подключаются не в розетки, а кабели вмуровываются в стены и т.д. Аналогия поплыла немного, но думаю мысль донес.
Есть стандартные слои и все сразу измениться не может - иначе это уже другой проект. Если вы стандартно распределили все по слоям, то на каждом из них можете принять определенное решение, выбрав архитектуру слоя. Поползет дизайн - будете менять дизайн. Поползут бизнес-требования - будете менять компоненты, инфраструктура не поменяется. Выносите конфигурацию, потому что получились разные версии аппки - архитектура становится лучше. Возможно мне просто повезло работать на хороших проектах, но обычно если приняты правильные решения сразу и дисциплина достаточно хорошо поддерживается, то и код относительно легко приводится в нужную форму. Просто на каком-то этапе требуется стадия "посидеь-подумать-переписать", возможно несколько раз за цикл жизни проекта, а если на это нет времени и бюджета приходится идти вперед с неудачной архитектурой.
Ну строго говоря это и не архитектура, это композиция-декомпозиция компонентов средствами фреймворка, архитектура живет уровнем выше.
Архитектура - это выделение слоев и их изоляция. Слой представления, слой системной логики, инфраструктурный слой. Тот же redux - он же не просто так возник как и rxjs - это попытки отделить общее состояние и работу с API от представления, которым изначально и был фронтенд.
И решения на таких слоях принимаюся до написания первой строчки кода (или в процессе рефактора), там не получится дождаться "трёх использований". Вы не слишком рано делаете правильно, сложность возникает из-за отсутствия четких границ между слоями.
Хорошая архитектура тем и хороша, что выбор решений позволяет довольно легко ее поддерживать в изменяемых местах, не залезая в неизменяемые. Какой-то странный у вас пример. Либо выбор абстракций неудачный, либо тупо не справились с уровнем сложности.
Семантическая - мы можем четко назвать некоторое состояние для различения с другими. Представьте таблицу побольше, представьте что какое-то новое состояние добавили или убрали - поведение строки №3 или №5 может уплыть, если ориетироваться просто на порядок.
Индексная - тот самый указатель за которым скрывается поведение - некоторая единица кода. Вам повезло, что в вашей модели поведение меняется циклически, вы можете переходить от строки к строке последовательно, возвращаясь к началу в конце. То есть это последовательный переход между состояниями. Представьте, что где-то нужно перескочить через строку или вернуться назад на две - все, вы неизбежно переходите к именованным состоянием.
Ну и главное - ваш основной посыл - конечные автоматы не нужны, вот пример, где они не работают. Вы начинаете пример с построения неудачной модели конечного автомата, создав неудачную абстракцию, в которой состояние светофора нужно вывести через состояние его лампочек. После этого вы создаете другую абстракцию, которая представляет собой ДРУГОЙ конечный автомат без именованных состояний с простым циклическим переходом между ними. Возможно ли такое упрощение? Вполне. Но как только задача будет усложнена, вы вернете назад все то, что заботливо скрыли.
То есть весь пост можно свести к "линейному FSM не нужен явный синтаксис состояний, поэтому он может быть представлен в табличной форме".
Табличным автоматом я называю саму абстракцию, которая реализуется таблицей и интерпретатором (данными и кодом по сути).
В коде нет понятия состояния, но оно существует неявно и задаётся индексом. Замените индекс на enum, дайте ему именованные значения - вот вам и переменная "состояние". То, что вы заменили набор свитчей и ифов таблицей - ну прекрасно, это лишь способ представления или реализации.
"Конечность" подразумевает конечность состояний. Очевидно, что у конечной таблицы оно конечно. Замена таблицы на другую создает другой конечный автомат, ну так вы можете задать их целое семейство, в котором каждый автомат будет конечен.
И как вам правильно замечали, у вас не самая удачная абстракция - именно потому, что вы старались уйти от модели FSM, реализуя ее неявно. Состояние лампочек светофора не эквивалентно состоянию автомата, можете считать их маппингом, визуализацией условно говоря состояния автомата. Состояние автомата - это строка в таблице, лампочки и период - атрибуты состояния. У вас "зелёный" встречается трижды - и это три разных состояния автомата, анализируя горит сейчас зелёный или не горит мы состояние автомата (строку таблицы) не получим. А вот переход между строками таблицы (между состояниями автомата) или само это состояние может сопровождаться какими угодно эффектами.
Состояние "можно ехать" - включи зеленую лампу. Состояние "готовься" - моргай зелёной лампой. Только получается что нужно два таймера - один управляет КА, второй - анимирует лампу, запуская моргание. Можно просто запустить какой-нибудь setMode(green, 'blink', 1000); setMode(red, 'off'); setMode(yellow, 'off');
А можно упороться, если поведение отдельного состояние сложное и превратить его в КА в свою очередь, получив иерархический КА. То есть переход в состояние "готовься" запускает дочерний КА с его собственным набором состояний, если хотите. И это тоже КА с конечным набором состояний, композиция КА конечна.
Так что вы просто перепутали слой отображения со слоем логики, интуитивно придя к той же самой модели КА в табличной форме.
Не интересно, но полезно для сбора статистики - где можно ужать расходы, например. Сколько я трачу в месяц на необходимые вещи и сколько можно себе позволить в случае, если необходим кредит. Банальное - окупает ли себя проездной или абонемент, насколько дороже обходится покупная готовая еда с учетом собственных затрат времени на готовку, можно ли ужаться по коммуналке в случае необходимости, где я вышел за среднее. Ну и сколько я стою, в конце коноцв, потому что в том же GNU Cash можно вести учет и стоимости активов - квартира, машина, гараж, ценная техника.
Встречи и звонки лучше всего настраиваются в софте для встреч и звонков. Списки дел - ну такое, создавать списки для рутины - тратить драгоценное время, а для работы обычно хватает инструментария проекта. Obsidian все же для заметок.
Мы переоцениваем свою занятность и попытки впихнуть в расписание еще что-то по правилам превращает нас в роботов. Придется вписывать еще и время на ответы на комменты на Хабре.
А зачем вбрасывать куда-то статьи, чтобы что? Чтобы еще более лучше хранить списки бесконечных статей? Еще более лучше вести список двух активностей и бесконечных дел, которые когда-нибудь потом? Нейроатипичность - это результат перегруза информацией, который вы дополнительно кормите своими миллионами систем для контроля.
Люди писали заметки не для фиксации ЧУЖИХ мыслей, которые они вытаскивают из статей, а для фиксации своих реакций на эти мысли в плане применимости их к собственной жизни и собственным сферам. Не сопливые рефлексии на тему "мне это напоминает чувство, возникшее на каникулах у бабушки 10 лет назад", а какое-то осмысленное утверждение, предположение или вопрос, формирующие ВАШИ знания, а не наборы из разобранных книжек.
Это же бесконечные цифровые балконы или цифровые гаражи, в которых вы только и придумываете как бы докупить больше места и сделать ремонт, чтобы еще больше влезло.
Я с трудом себе представляю, что у современного задрота с Хабра настолько насыщенная жизнь, что её нужно дополнительно настраивать с помощью такого сложного инструментария. Для финансов есть прекрасный GNU Cash с правилами бухгалтерского учёта - я настроил раз, каждую неделю прохожу по своим тратам, вбиваю их и получаю нормальные отчёты при необходимости. Было бы несколько источников дохода - позволило бы еще лучше контролировать баланс, но у меня доход фиксированный.
Obsidian - это про заметки. Зачем его люди со своим дурацким бесконечным ADHD, который сейчас так же навязчиво утомителен как непереносимость глютена, а до него аллергия на все, превращают в монстра из оповещений о том, что надо убрать квартиру?
Всевозможные списки - чего? Календарь - для чего? Справочная система - чего? И т.д., и т.п - вот именно, что и т.д., и т.п. Система выстраивается от жизни, а не жизнь подгоняется под систему. В результате вся жизнь будет посвящена настройкам системы, что я и наблюдаю в сообществе.
Obsidian - это средство ведение заметок. Заметки - это, преимущественно, конспекты и мысли. Не таски. Zettelkasten - это про метод организации заметок таким образом, чтобы их можно было легко находить и связывать друг с другом.
Какое отношение это все имеет к управлению активностями - я ума не приложу. Луману Цеттелькастен позволял фиксировать свои мысли, которые он боялся забыть. Не потому, что память была плохая, а потому, что мыслей было много.
Вам же нужно (зачем-то) фиксировать необходимость уборки в квартире. Это называется организация рутины, цифровые средства для этого мало подходят - в результате вы вместо собственно рутины занимаетесь её организацией в цифровом виде. В результате ваша система стала такой простой, что для ее подробного пояснения понадобилась огромная статья.
Посты на Хабре пишутся в жанре эссе. Эссе как и любая прочая non-fiction литература требует написания нескольких черновиков и вычитки, а черновики - плана. Плюс нарративной последовательности - стандартная трехчастная структура (с кучей реализаций типа диалектики Гегеля, постановки задачи и ее решения, сравнения двух вариантов с предварительным описанием - десяток схем всего, если я помню).
Попытки написать пост в жанре комментария приводят к тому, что вы пишете комментарий. Что наглядно демонстрирует и этот ваш пост.
Ну видите, а в результате начинающие пользователи воспринимают ЦК чисто как сетевую структуру с ассоциативными связями, совершенно упуская из вида его гибридность. У Лумана классическая иерархия была изначально и она обеспечивалась нумерацией. Вы можете обеспечить ее очень простым способом - кроме некоторых "корневых", "входных" карточек, список которых вы можете держать в системе, используйте в своих шаблонах поле parent или как-то так, обязательно помещая туда ссылку на родительскую заметку. Я использую up, например. Если такой родительской заметки нет - пусть будет висячая ссылка. Но до тех пор, пока заметка не доходит до корня, я не бросаю ее в папку физически, они лежат во временной папке-отстойнике, пока я эту структуру не сформирую.
В результате вместо физических папок можно обойтись такой структурой, которая элементарно отрисовывается тем же dataview - я написал функцию, которая рисует мне дерево заметок начиная от нужной мне на определенную глубину. Там же можно настроить фильтрацию по тегам, например. Главная задача - знать куда "посадить" каждую заметку, чтобы у нее обязательно был родитель, как полка для книги - тогда эта система начинает работать как надо, а не затыкается на паре сотен заметок, заброшенных в сеть. Попробуй их потом найди, если не помнишь ключевых слов, а заметок тысячи.
Настоящий Цеттелькастен и есть такая гибридная иерархическая система с небольшим облаком случайных ассоциативных связей. Иерархия обеспечивается нумерацией, но можно все заменить деревом из папок при желании - правда при наличии связей это бессмысленно. Другое дело, что в ЦК эти связи различаются принципиально - структурные задаются нумерацией, определяя место в иерархии, а ассоциативные - вот теми самыми гипертекстовыми ссылками.
Ну как бы сам по себе Zettelkasten - это способ организации карточек с атомарными заметками, обеспечивающий определенные свойства такой системы. У Лумана не было нашего полнотекстового поиска, но зато у него был контекст. И этот контекст "сетевики" упускают, а без него все превращается в неструктурированный гипертекст. Связи становятся натужными и лишними, к тому же по мере эволюции системы ни связи, ни теги не работают - нужно поддерживать какие-то карты знаний и обновлять теги по имеющимся карточкам регулярно - это адский труд, который мы себе добавили сами.
Кстати, я не совсем понял почему вы организацию тикетов называете ZK? Это обычные атомарные заметки с тегами, в вашем примере есть только внешние ссылки. Полноценным ZK они бы стали, если бы у вас была собственная база знаний или хотя бы ее имитация с минимальными описаниями и заглушками, типа Linux - подсистемы, отдельные пакеты, классы софта - связное дерево, на которое вы сажаете тикеты, которые благодаря наличию родительских связей могут лежать в папке свободно. Все равно основным инструментом остается полнотекстовый поиск, но появляется приятный бонус в виде контекста, можно посмотреть какие тикеты находятся по соседству, если решение из тикета не подходит - иногда это наводит на мысль.
Но в целом Луман решал свои очень специфические задачи, он работал в науке, отдельные области которой сам же и создавал. Для него этот контекст был принципиально важен, взяв любую карточку он мог пробежаться от корня или от любой вышестоящей карточки и проугляться по цепочке рассуждений, уйти в ответвления и пройти по цепочке там - это все работало на массивах от 20 - 30 000 карточек.
Я не представляю как обычный граф с рандомно расставленными связями позволит хоть чем-то помочь. Но у тикетов нет и этих связей, ни места в системе кроме тегов. Луман жил в мире иерархии не придавая этому значения. Мы же почему-то считаем иерархию злом, подсознательно к ней стремясь. Просто если до Лумана картотеки представляли собой массивы неравной длины с редкими отсылками на другие отделы (Кристи такую описывала у мисс Лемон в рассказах о Пуаро), то Луман научился укладывать в картотеки деревья. А мы эти деревья убираем, в результате пытаясь придумать что-то не очень рабочее взамен.
Вы совершенно неправильно воспринимаете Zettelkasten - и я вас даже не виню, это устоявшаяся ошибка всех, кто читал о нём в пересказе. Zettelkasten никогда не был сетевой системой. У меня даже лежит на эту тему недописанная пара статей, надо будет заняться.
Если коротко - Zettelkasten иерархичен, причем строго, по определению - у каждой заметки есть предок. Сама система нумерации позволяла вставку любой заметки в любом месте как категорию предыдущей или как продолжение какой-то мысли, ветвление. Это были не рандомные уникальные ID типа временной метки, как это принято показывать сейчас, а что-то типа 1/23a/7b55 - начинались с какой-то базовой темы (что уже предполагало базовую иерархию, Луман был академическим ученым все же), но не очень строгую. И дальше по цепочке рассуждений. По сути Луман хранил в своих ящиках деревья, которые можно было легко отсортировать по порядку и найти нужную последовательность. Последовательностями он и мыслил - каждая мысль крепко "сидела" в каком-то конкретном месте - что-то придумал - записал как аргумент, пример, контраргумент, замечание. Он всегда знал что куда "вставить".
Слой случайных, ассоциативных связей, которым так восхищаются "сетевики" был очень редким, множество заметок вообще не ссылалось на другие просто потому, что их позиция в иерархии задавалась номером - мы всегда могли знать кто предок заметки по ее номеру и кто ее потомки. Весьма вероятно, что вот эти "блуждания", "прогулки" Лумана были именно походами по цепочке рассуждений. Фактически, он конспектировал свои заметки не просто как конспекты, а как рассуждения, элементы будущей книги, которые ему достаточно было просто переносить на бумагу - это не очень удобно для тех, кто ничего не публикует, но все же может быть полезно.
Я много думал на эту тему и достаточно много читал - это популярные дискуссии среди поклонников Цеттелькастена, но пришел к выводу, что именно такая система должна работать. Просто случайный граф превращает систему в дурацкую википедию, которая будет хуже по качеству, чем настоящая, не дает возможности ничего найти или "вставить" пришедшую мысль. Луман гордился гипертекстововстью, потому что для него она была уникальной, новой, не замечая от рождения присущую его системе очень строгую иерархичность.
СДВГ - это спектр симптомов, обусловленный биохимией работы мозга, причем еще проблемы эти могут возникать неравномерно в разных областях мозга приводя к разным эффектам. Кора больших полушарий - исполнительная активность, мозжечок - те самые беспокойные ноги (и я только ближе к 40 заметил, что я дествительно непроизвольно дергаю ногой когда сижу или лежу). И разумеется, что в разной обстановке и у человека с более типичным мозгом могут проявляться эти симптомы, могут отступать, и у СДВГшника ослабляться или усиливаться.
Нынешние привычки и образ жизни приводят к тому, что СДВГ усиливается у тех, кто его имеет, а СДВГ-подобные симптомы проявляются у тех, кто его не имеет. В конце концов, проблемы со вниманием, рассеянностью, неспособностью сконцентрироваться бывают у всех - это симптомы, как, например, симптом - высокая температура, являющаяся признаком воспалительного процесса. А вот причиной этого процесса может быть что угодно - от теплового удара и банальной простуды до лимфомы.
Но у СДВГ есть довольно специфические, более глобальные проявления, которые в ряде случае значительно ухудшают качество жизни. СДВГ - это не просто неспособность сконцентрироваться на чем-то - это неспособность сконцентироваться на том, что неинтересно. Причем неспособность буквально физическая, ты понимаешь, что это сделать нужно, проклинаешь себя, заставляешь - но не можешь. При этом тем, что тебе интересно в данный момент, ты можешь заниматься с упоением, часами, буквально забывая сходить поесть или в туалет, не обращая внимания на затекшие ноги. Интересная книга или сериал, о которых еще вчера не слышал - запоем, даже если завтра на работу. Пет-проект, новое хобби, внезапно возникшее желание нарисовать картину или собрать коллекторный узел. Ты начинаешь изучать тему, читать, смотреть, пробовать - иногда даже получается, иногда даже неплохо. Но потом к начатому пропадает интерес - буквально отрезает. И там, где другой человек может годами заниматься любимым хобби СДВГшник не подойдет и на пушечный выстрел. Вообще никогда в жизни или до следующей "маниакальной стадии".
Забывчивость - ключи, зонтики, кошельки, стики, зажигалки - иногда это выправляется жесткой дисциплиной и ритуалами проверки. Но часто теряется пачками. Можешь зайти в комнату и забыть зачем ты туда пришел. И так несколько раз подряд. Можно зайти в ванную, обнаружить грязный умывальник в 11 вечера, вытащить Кёрхер (интересно же) и начать убирать - мозг получил свой дофамин, ему классно.
Ну и отдельная песня - работа в условиях стресса. Когда наш проект был еще маленьким стартапом я обожал инциденты или баги на проде. Стресс - норадреналин - дофамин - и когда остальные коллеги начинают суетиться или не понимают что делать, у тебя открывается второе дыхание - даже если это вечер пятницы после тяжелой недели - ты НАКОНЕЦ-ТО чувствуешь себя замотивированным, тебе интересно, ты готов сидеть и ковырять этот баг до двух ночи, потому что нужно, потому что важно, потому что ИНТЕРЕСНО. Иногда это прикольно, конечно. но в целом врагу не пожелаешь. Но, насколько я понимаю, среди пожарных и спасателей должно быть много СДВГшников именно по этой причине.
Еще раз перечитал - вы вот здесь свернули сильно не туда.
Состояние автомата не равно состоянию светофора. Это вообще разные категории. Как и периоды, к слову. Лампочки - выходная функция от текущего состояния автомата, они никак в систему не загружаются и не должны, они являются выходом системы и входом станут только тогда, когда понадобится это состояние проверять, чтобы на основе наблюдения сделать следующий переход.
Временные интервалы - константы конфигурации. Автомату совершенно все равно какие они, 8-10-20, 3-5-15 - это один и тот же КА с двумя разными конфиграциями инстанса.
Лампочки - это уровень представления. Состояние автомата - это и есть индекс таблицы (или некоторая именованная метка). Пришли в узел графа, вызвали связанную с этим функцию (поведение), результат каким-то образом визуализировали (помигали лампочками), определили куда идти дальше.
Проблема с семантической перегруженностью термина State.
Control State - это и есть состояние автомата, индекс, енум, узел графа состояний.
Data State - это состояние светофора в памяти - то, что можно менять с помощью i/o операций - переменные, описывающие индикацию и датчики.
Presentation State - собственно состояние лампочек, спиннеры сайта, внешний вид кнопок (активна-не активна).
Смешение этих понятий и приводит к выбору неверных абстракций.
Ну вот я автору об этом и говорю: тот же класс задач, что требует конечных автоматов, но за счет того, что состояния меняются в простом цикле они могут быть редуцированы до табличной формы с безымянными состояниями. А он обижается.
Добавьте к вашему светофору внешние ивенты: кнопка пешехода (нажали и получили зеленый для пешехода, причем с нюансами - нужно ли выдерживать отрегулированный режим или нет), ночной режим (моргаем желтым), "зеленую линию", задаваемую извне - и попробуйте это описать вашей таблицей. Начнется каша, которую и устраняет КА.
Немного уточню. Фундаментальные решения - это, скорее, инварианты. Не доменные и системные ограничения, а те базовые решения, когда выбор был произведен из нескольких возможных и сделан аксиомой - тем самым фундаментом, на котором архитектура строится. Архитектура может быть и достаточно гибкой, в примере с гаражом это, скорее, не его размеры (инвариант), а постройка гаража на участке заданного размера и в заданном месте из выбранных материалов так, чтобы он мог при необходимости разместить две машины, а в их отсутствие быть мастерской и хранить нужные вещи. Вот с учетом этих требований-инвариантов дальше и выстраивается архитектура. И цементирование происходит тогда, когда мы размываем границу между дизайном и архитектурой, верстак ставится не на пол, а на отлитый для него бетонный постамент, приборы подключаются не в розетки, а кабели вмуровываются в стены и т.д. Аналогия поплыла немного, но думаю мысль донес.
Есть стандартные слои и все сразу измениться не может - иначе это уже другой проект. Если вы стандартно распределили все по слоям, то на каждом из них можете принять определенное решение, выбрав архитектуру слоя. Поползет дизайн - будете менять дизайн. Поползут бизнес-требования - будете менять компоненты, инфраструктура не поменяется. Выносите конфигурацию, потому что получились разные версии аппки - архитектура становится лучше. Возможно мне просто повезло работать на хороших проектах, но обычно если приняты правильные решения сразу и дисциплина достаточно хорошо поддерживается, то и код относительно легко приводится в нужную форму. Просто на каком-то этапе требуется стадия "посидеь-подумать-переписать", возможно несколько раз за цикл жизни проекта, а если на это нет времени и бюджета приходится идти вперед с неудачной архитектурой.
Ну строго говоря это и не архитектура, это композиция-декомпозиция компонентов средствами фреймворка, архитектура живет уровнем выше.
Архитектура - это выделение слоев и их изоляция. Слой представления, слой системной логики, инфраструктурный слой. Тот же redux - он же не просто так возник как и rxjs - это попытки отделить общее состояние и работу с API от представления, которым изначально и был фронтенд.
И решения на таких слоях принимаюся до написания первой строчки кода (или в процессе рефактора), там не получится дождаться "трёх использований". Вы не слишком рано делаете правильно, сложность возникает из-за отсутствия четких границ между слоями.
Хорошая архитектура тем и хороша, что выбор решений позволяет довольно легко ее поддерживать в изменяемых местах, не залезая в неизменяемые. Какой-то странный у вас пример. Либо выбор абстракций неудачный, либо тупо не справились с уровнем сложности.
Именованное состояние служит двум целям.
Семантическая - мы можем четко назвать некоторое состояние для различения с другими. Представьте таблицу побольше, представьте что какое-то новое состояние добавили или убрали - поведение строки №3 или №5 может уплыть, если ориетироваться просто на порядок.
Индексная - тот самый указатель за которым скрывается поведение - некоторая единица кода. Вам повезло, что в вашей модели поведение меняется циклически, вы можете переходить от строки к строке последовательно, возвращаясь к началу в конце. То есть это последовательный переход между состояниями. Представьте, что где-то нужно перескочить через строку или вернуться назад на две - все, вы неизбежно переходите к именованным состоянием.
Ну и главное - ваш основной посыл - конечные автоматы не нужны, вот пример, где они не работают. Вы начинаете пример с построения неудачной модели конечного автомата, создав неудачную абстракцию, в которой состояние светофора нужно вывести через состояние его лампочек. После этого вы создаете другую абстракцию, которая представляет собой ДРУГОЙ конечный автомат без именованных состояний с простым циклическим переходом между ними. Возможно ли такое упрощение? Вполне. Но как только задача будет усложнена, вы вернете назад все то, что заботливо скрыли.
То есть весь пост можно свести к "линейному FSM не нужен явный синтаксис состояний, поэтому он может быть представлен в табличной форме".
Табличным автоматом я называю саму абстракцию, которая реализуется таблицей и интерпретатором (данными и кодом по сути).
В коде нет понятия состояния, но оно существует неявно и задаётся индексом. Замените индекс на enum, дайте ему именованные значения - вот вам и переменная "состояние". То, что вы заменили набор свитчей и ифов таблицей - ну прекрасно, это лишь способ представления или реализации.
"Конечность" подразумевает конечность состояний. Очевидно, что у конечной таблицы оно конечно. Замена таблицы на другую создает другой конечный автомат, ну так вы можете задать их целое семейство, в котором каждый автомат будет конечен.
И как вам правильно замечали, у вас не самая удачная абстракция - именно потому, что вы старались уйти от модели FSM, реализуя ее неявно. Состояние лампочек светофора не эквивалентно состоянию автомата, можете считать их маппингом, визуализацией условно говоря состояния автомата. Состояние автомата - это строка в таблице, лампочки и период - атрибуты состояния. У вас "зелёный" встречается трижды - и это три разных состояния автомата, анализируя горит сейчас зелёный или не горит мы состояние автомата (строку таблицы) не получим. А вот переход между строками таблицы (между состояниями автомата) или само это состояние может сопровождаться какими угодно эффектами.
Состояние "можно ехать" - включи зеленую лампу. Состояние "готовься" - моргай зелёной лампой. Только получается что нужно два таймера - один управляет КА, второй - анимирует лампу, запуская моргание. Можно просто запустить какой-нибудь setMode(green, 'blink', 1000); setMode(red, 'off'); setMode(yellow, 'off');
А можно упороться, если поведение отдельного состояние сложное и превратить его в КА в свою очередь, получив иерархический КА. То есть переход в состояние "готовься" запускает дочерний КА с его собственным набором состояний, если хотите. И это тоже КА с конечным набором состояний, композиция КА конечна.
Так что вы просто перепутали слой отображения со слоем логики, интуитивно придя к той же самой модели КА в табличной форме.
Ну то есть вы буквально заменили конечный автомат на табличный конечный автомат, чтобы доказать, что конечные автоматы не нужны?
Не интересно, но полезно для сбора статистики - где можно ужать расходы, например. Сколько я трачу в месяц на необходимые вещи и сколько можно себе позволить в случае, если необходим кредит. Банальное - окупает ли себя проездной или абонемент, насколько дороже обходится покупная готовая еда с учетом собственных затрат времени на готовку, можно ли ужаться по коммуналке в случае необходимости, где я вышел за среднее. Ну и сколько я стою, в конце коноцв, потому что в том же GNU Cash можно вести учет и стоимости активов - квартира, машина, гараж, ценная техника.
Встречи и звонки лучше всего настраиваются в софте для встреч и звонков. Списки дел - ну такое, создавать списки для рутины - тратить драгоценное время, а для работы обычно хватает инструментария проекта. Obsidian все же для заметок.
Мы переоцениваем свою занятность и попытки впихнуть в расписание еще что-то по правилам превращает нас в роботов. Придется вписывать еще и время на ответы на комменты на Хабре.
А зачем вбрасывать куда-то статьи, чтобы что? Чтобы еще более лучше хранить списки бесконечных статей? Еще более лучше вести список двух активностей и бесконечных дел, которые когда-нибудь потом? Нейроатипичность - это результат перегруза информацией, который вы дополнительно кормите своими миллионами систем для контроля.
Люди писали заметки не для фиксации ЧУЖИХ мыслей, которые они вытаскивают из статей, а для фиксации своих реакций на эти мысли в плане применимости их к собственной жизни и собственным сферам. Не сопливые рефлексии на тему "мне это напоминает чувство, возникшее на каникулах у бабушки 10 лет назад", а какое-то осмысленное утверждение, предположение или вопрос, формирующие ВАШИ знания, а не наборы из разобранных книжек.
Это же бесконечные цифровые балконы или цифровые гаражи, в которых вы только и придумываете как бы докупить больше места и сделать ремонт, чтобы еще больше влезло.
Я с трудом себе представляю, что у современного задрота с Хабра настолько насыщенная жизнь, что её нужно дополнительно настраивать с помощью такого сложного инструментария. Для финансов есть прекрасный GNU Cash с правилами бухгалтерского учёта - я настроил раз, каждую неделю прохожу по своим тратам, вбиваю их и получаю нормальные отчёты при необходимости. Было бы несколько источников дохода - позволило бы еще лучше контролировать баланс, но у меня доход фиксированный.
Obsidian - это про заметки. Зачем его люди со своим дурацким бесконечным ADHD, который сейчас так же навязчиво утомителен как непереносимость глютена, а до него аллергия на все, превращают в монстра из оповещений о том, что надо убрать квартиру?
Всевозможные списки - чего? Календарь - для чего? Справочная система - чего? И т.д., и т.п - вот именно, что и т.д., и т.п. Система выстраивается от жизни, а не жизнь подгоняется под систему. В результате вся жизнь будет посвящена настройкам системы, что я и наблюдаю в сообществе.
Obsidian - это средство ведение заметок. Заметки - это, преимущественно, конспекты и мысли. Не таски. Zettelkasten - это про метод организации заметок таким образом, чтобы их можно было легко находить и связывать друг с другом.
Какое отношение это все имеет к управлению активностями - я ума не приложу. Луману Цеттелькастен позволял фиксировать свои мысли, которые он боялся забыть. Не потому, что память была плохая, а потому, что мыслей было много.
Вам же нужно (зачем-то) фиксировать необходимость уборки в квартире. Это называется организация рутины, цифровые средства для этого мало подходят - в результате вы вместо собственно рутины занимаетесь её организацией в цифровом виде. В результате ваша система стала такой простой, что для ее подробного пояснения понадобилась огромная статья.
Посты на Хабре пишутся в жанре эссе. Эссе как и любая прочая non-fiction литература требует написания нескольких черновиков и вычитки, а черновики - плана. Плюс нарративной последовательности - стандартная трехчастная структура (с кучей реализаций типа диалектики Гегеля, постановки задачи и ее решения, сравнения двух вариантов с предварительным описанием - десяток схем всего, если я помню).
Попытки написать пост в жанре комментария приводят к тому, что вы пишете комментарий. Что наглядно демонстрирует и этот ваш пост.
Ну видите, а в результате начинающие пользователи воспринимают ЦК чисто как сетевую структуру с ассоциативными связями, совершенно упуская из вида его гибридность. У Лумана классическая иерархия была изначально и она обеспечивалась нумерацией. Вы можете обеспечить ее очень простым способом - кроме некоторых "корневых", "входных" карточек, список которых вы можете держать в системе, используйте в своих шаблонах поле parent или как-то так, обязательно помещая туда ссылку на родительскую заметку. Я использую up, например. Если такой родительской заметки нет - пусть будет висячая ссылка. Но до тех пор, пока заметка не доходит до корня, я не бросаю ее в папку физически, они лежат во временной папке-отстойнике, пока я эту структуру не сформирую.
В результате вместо физических папок можно обойтись такой структурой, которая элементарно отрисовывается тем же dataview - я написал функцию, которая рисует мне дерево заметок начиная от нужной мне на определенную глубину. Там же можно настроить фильтрацию по тегам, например. Главная задача - знать куда "посадить" каждую заметку, чтобы у нее обязательно был родитель, как полка для книги - тогда эта система начинает работать как надо, а не затыкается на паре сотен заметок, заброшенных в сеть. Попробуй их потом найди, если не помнишь ключевых слов, а заметок тысячи.
Настоящий Цеттелькастен и есть такая гибридная иерархическая система с небольшим облаком случайных ассоциативных связей. Иерархия обеспечивается нумерацией, но можно все заменить деревом из папок при желании - правда при наличии связей это бессмысленно. Другое дело, что в ЦК эти связи различаются принципиально - структурные задаются нумерацией, определяя место в иерархии, а ассоциативные - вот теми самыми гипертекстовыми ссылками.
Ну как бы сам по себе Zettelkasten - это способ организации карточек с атомарными заметками, обеспечивающий определенные свойства такой системы. У Лумана не было нашего полнотекстового поиска, но зато у него был контекст. И этот контекст "сетевики" упускают, а без него все превращается в неструктурированный гипертекст. Связи становятся натужными и лишними, к тому же по мере эволюции системы ни связи, ни теги не работают - нужно поддерживать какие-то карты знаний и обновлять теги по имеющимся карточкам регулярно - это адский труд, который мы себе добавили сами.
Кстати, я не совсем понял почему вы организацию тикетов называете ZK? Это обычные атомарные заметки с тегами, в вашем примере есть только внешние ссылки. Полноценным ZK они бы стали, если бы у вас была собственная база знаний или хотя бы ее имитация с минимальными описаниями и заглушками, типа Linux - подсистемы, отдельные пакеты, классы софта - связное дерево, на которое вы сажаете тикеты, которые благодаря наличию родительских связей могут лежать в папке свободно. Все равно основным инструментом остается полнотекстовый поиск, но появляется приятный бонус в виде контекста, можно посмотреть какие тикеты находятся по соседству, если решение из тикета не подходит - иногда это наводит на мысль.
Но в целом Луман решал свои очень специфические задачи, он работал в науке, отдельные области которой сам же и создавал. Для него этот контекст был принципиально важен, взяв любую карточку он мог пробежаться от корня или от любой вышестоящей карточки и проугляться по цепочке рассуждений, уйти в ответвления и пройти по цепочке там - это все работало на массивах от 20 - 30 000 карточек.
Я не представляю как обычный граф с рандомно расставленными связями позволит хоть чем-то помочь. Но у тикетов нет и этих связей, ни места в системе кроме тегов. Луман жил в мире иерархии не придавая этому значения. Мы же почему-то считаем иерархию злом, подсознательно к ней стремясь. Просто если до Лумана картотеки представляли собой массивы неравной длины с редкими отсылками на другие отделы (Кристи такую описывала у мисс Лемон в рассказах о Пуаро), то Луман научился укладывать в картотеки деревья. А мы эти деревья убираем, в результате пытаясь придумать что-то не очень рабочее взамен.
Вы совершенно неправильно воспринимаете Zettelkasten - и я вас даже не виню, это устоявшаяся ошибка всех, кто читал о нём в пересказе. Zettelkasten никогда не был сетевой системой. У меня даже лежит на эту тему недописанная пара статей, надо будет заняться.
Если коротко - Zettelkasten иерархичен, причем строго, по определению - у каждой заметки есть предок. Сама система нумерации позволяла вставку любой заметки в любом месте как категорию предыдущей или как продолжение какой-то мысли, ветвление. Это были не рандомные уникальные ID типа временной метки, как это принято показывать сейчас, а что-то типа 1/23a/7b55 - начинались с какой-то базовой темы (что уже предполагало базовую иерархию, Луман был академическим ученым все же), но не очень строгую. И дальше по цепочке рассуждений. По сути Луман хранил в своих ящиках деревья, которые можно было легко отсортировать по порядку и найти нужную последовательность. Последовательностями он и мыслил - каждая мысль крепко "сидела" в каком-то конкретном месте - что-то придумал - записал как аргумент, пример, контраргумент, замечание. Он всегда знал что куда "вставить".
Слой случайных, ассоциативных связей, которым так восхищаются "сетевики" был очень редким, множество заметок вообще не ссылалось на другие просто потому, что их позиция в иерархии задавалась номером - мы всегда могли знать кто предок заметки по ее номеру и кто ее потомки. Весьма вероятно, что вот эти "блуждания", "прогулки" Лумана были именно походами по цепочке рассуждений. Фактически, он конспектировал свои заметки не просто как конспекты, а как рассуждения, элементы будущей книги, которые ему достаточно было просто переносить на бумагу - это не очень удобно для тех, кто ничего не публикует, но все же может быть полезно.
Я много думал на эту тему и достаточно много читал - это популярные дискуссии среди поклонников Цеттелькастена, но пришел к выводу, что именно такая система должна работать. Просто случайный граф превращает систему в дурацкую википедию, которая будет хуже по качеству, чем настоящая, не дает возможности ничего найти или "вставить" пришедшую мысль. Луман гордился гипертекстововстью, потому что для него она была уникальной, новой, не замечая от рождения присущую его системе очень строгую иерархичность.