А еще занятная штука - барабанная память - drum memory. Которую до феррита использовали именно как оперативную, с шизофренией вида "адрес следующей инструкции" и оптимизирующими ассемблерами, разбрасывающими инструкции по этому барабану, чтобы чтение происходило оптимальным образом.
СДВГ - это спектр симптомов, обусловленный биохимией работы мозга, причем еще проблемы эти могут возникать неравномерно в разных областях мозга приводя к разным эффектам. Кора больших полушарий - исполнительная активность, мозжечок - те самые беспокойные ноги (и я только ближе к 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 карточек.
Я не представляю как обычный граф с рандомно расставленными связями позволит хоть чем-то помочь. Но у тикетов нет и этих связей, ни места в системе кроме тегов. Луман жил в мире иерархии не придавая этому значения. Мы же почему-то считаем иерархию злом, подсознательно к ней стремясь. Просто если до Лумана картотеки представляли собой массивы неравной длины с редкими отсылками на другие отделы (Кристи такую описывала у мисс Лемон в рассказах о Пуаро), то Луман научился укладывать в картотеки деревья. А мы эти деревья убираем, в результате пытаясь придумать что-то не очень рабочее взамен.
А еще занятная штука - барабанная память - drum memory. Которую до феррита использовали именно как оперативную, с шизофренией вида "адрес следующей инструкции" и оптимизирующими ассемблерами, разбрасывающими инструкции по этому барабану, чтобы чтение происходило оптимальным образом.
СДВГ - это спектр симптомов, обусловленный биохимией работы мозга, причем еще проблемы эти могут возникать неравномерно в разных областях мозга приводя к разным эффектам. Кора больших полушарий - исполнительная активность, мозжечок - те самые беспокойные ноги (и я только ближе к 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 карточек.
Я не представляю как обычный граф с рандомно расставленными связями позволит хоть чем-то помочь. Но у тикетов нет и этих связей, ни места в системе кроме тегов. Луман жил в мире иерархии не придавая этому значения. Мы же почему-то считаем иерархию злом, подсознательно к ней стремясь. Просто если до Лумана картотеки представляли собой массивы неравной длины с редкими отсылками на другие отделы (Кристи такую описывала у мисс Лемон в рассказах о Пуаро), то Луман научился укладывать в картотеки деревья. А мы эти деревья убираем, в результате пытаясь придумать что-то не очень рабочее взамен.