Здравствуйте, so5team, Вы писали:

S>Ну так в чем навороченность? Там никакой сложности не видно.
Навороченные правила от бизнес-аналитика описаны простым конфигом и напрямую исполняются программой, минуя этап конвертации в подверженный ошибкам и разной степени говнистости императивный код. Это же замечательно.

Тё>>>>Сценарий: коннектор заметил утерю пачки UDP пакетов и должен сделать TCP запрос. Он меняет состояние с "нормального" на "ошибка" и "дозапрос истории". В этом нет миллиона измений состояния в секунду. Однако, если сообщения так и не доходят- нужно понять, что там застряло, в чём проблема.

S>>>И при чем здесь HFSM? У вас что-то застревает внутри HFSM?
Тё>>У меня в коннекторе была плоская FSM- одна проблема, что плоская, и вторая- отсутствие инструмента для инспекции состояния в случае нештатной ситуации.

S>Запомним факт того, что плоская FSM -- это проблема.
Да, наколеночная FSM- это проблема. И дополнительное следствие из наколеночной FSM- остутствие инструмента для анализа состояния на работающем приложении, когда возникла нештатная ситуация.

S>Какое отношение HFSM имеет к вашему неумению собирать телеметрию и/или отлаживаться все еще непонятно.
Вы читать разучились или что? Телеметрия работает, автоматически эскалирует проблему, что данные не приходят. Отладка приложения (коннектора) ограничена, только стек трейс дамп и дальше коннектор принудительно перезапускается. И вот stack trace, это императивный инструмент. Из него можно только догадываться, какое состояние было в FSM прежде, чем процесс прибили.

S>>>Если у вас есть поток сообщений в 1M msg/sec и вы его обрабатываете посредством HFSM,
Тё>>Зачем вы его обрабатываете посредством HFSM?

S>А теперь вспоминаем факт того, что плоская FSM -- это проблема.

Тё>>Там не нужен HFSM.

S>Получается, что если вам не нужен HFSM, то он никому не нужен. ok.jpg
Объясните, пожалуйста, сценарий использования FSM/HFSM на каждом из миллиона сообщений в секунду. Это что, торговые роботы реализованы вырвиглазными шаблонами С++?

Тё>>Самый красивый код получился с использованием Visitor.

S>То, что единственное, во что вы умеете, -- это Visitor, давно понятно. Можно не повторяться.
Это не единственный дизайн конверторов, а последний и лучший в сравнении с предыдущими "моделями".

S>>> в HFSM ... выбор подходящей реакции на очередное входящее сообщение
Тё>>И что, на каждое сообщение смена состояния?

S>Почему бы и нет? Какие-то проблемы?
В общем да, в этом проблема.

Тё>>Или вы таким образом выбираете подходящую функцию-конвертер для сообщения? А завести виртуальную фабрику не судьба?

S>Все умные слова перечислили или что-то еще помните?

Тё>>Ах да, вы же не читали GoF.

S>Звиздеть изволите. Как обычно, впрочем.
Для вас виртуальная фабрика- это "умные слова". Блин, это же основы дизайна.

S>>>В общем, дурацкий вопрос.
Тё>>Я отвечаю на ваши вопросы. Будьте добры, ответьте и вы на мой вопрос.

S>Ну так задайте вопрос нормально. На дурацкие вопросы ответить невозможно.
Вы просто хамите на попытку вести конструктивное обсуждение. Вы с коллегами тоже так разговариваете?

S>>>Это вы про какой-то свой кривой код пишете.
Тё>>Я привёл вам пример вашего шаблона "can_be_with_comma". От которого глаза вытекают.

S>Они у вас вытекают потому, что a) вы не понимаете C++, b) вы не в курсе предметной области (но это вам там netch80 очень убедительно объяснил). Вы даже не увидели, что функция, над которой вы тогда решили постебаться, чистая.
Не нужно давить интеллектом. Pure Function- такая, что не изменяет состояние приложения. Тут нет связи с C++, с шаблонами, которые вы абъюзите до состояния, что вытекают глаза, и вашего стиля программирования.

S>>>А в сумме, по итогу, комбайн.
Тё>>В итоге я собираю от простого к сложному, склеивая вместе подходищие инструменты.

S>Ну комбайн же. Даже еще и слепленный из того, что было.

Здравствуйте, so5team, Вы писали:

S>Ну так в чем навороченность? Там никакой сложности не видно.
Навороченные правила от бизнес-аналитика описаны простым конфигом и напрямую исполняются программой, минуя этап конвертации в подверженный ошибкам и разной степени говнистости императивный код. Это же замечательно.

Тё>>>>Сценарий: коннектор заметил утерю пачки UDP пакетов и должен сделать TCP запрос. Он меняет состояние с "нормального" на "ошибка" и "дозапрос истории". В этом нет миллиона измений состояния в секунду. Однако, если сообщения так и не доходят- нужно понять, что там застряло, в чём проблема.

S>>>И при чем здесь HFSM? У вас что-то застревает внутри HFSM?
Тё>>У меня в коннекторе была плоская FSM- одна проблема, что плоская, и вторая- отсутствие инструмента для инспекции состояния в случае нештатной ситуации.

S>Запомним факт того, что плоская FSM -- это проблема.
Да, наколеночная FSM- это проблема. И дополнительное следствие из наколеночной FSM- остутствие инструмента для анализа состояния на работающем приложении, когда возникла нештатная ситуация.

S>Какое отношение HFSM имеет к вашему неумению собирать телеметрию и/или отлаживаться все еще непонятно.
Вы читать разучились или что? Телеметрия работает, автоматически эскалирует проблему, что данные не приходят. Отладка приложения (коннектора) ограничена, только стек трейс дамп и дальше коннектор принудительно перезапускается. И вот stack trace, это императивный инструмент. Из него можно только догадываться, какое состояние было в FSM прежде, чем процесс прибили.

S>>>Если у вас есть поток сообщений в 1M msg/sec и вы его обрабатываете посредством HFSM,
Тё>>Зачем вы его обрабатываете посредством HFSM?

S>А теперь вспоминаем факт того, что плоская FSM -- это проблема.

Тё>>Там не нужен HFSM.

S>Получается, что если вам не нужен HFSM, то он никому не нужен. ok.jpg
Объясните, пожалуйста, сценарий использования FSM/HFSM на каждом из миллиона сообщений в секунду. Это что, торговые роботы реализованы вырвиглазными шаблонами С++?

Тё>>Самый красивый код получился с использованием Visitor.

S>То, что единственное, во что вы умеете, -- это Visitor, давно понятно. Можно не повторяться.
Это не единственный дизайн конверторов, а последний и лучший в сравнении с предыдущими "моделями".

S>>> в HFSM ... выбор подходящей реакции на очередное входящее сообщение
Тё>>И что, на каждое сообщение смена состояния?

S>Почему бы и нет? Какие-то проблемы?
В общем да, в этом проблема.

Тё>>Или вы таким образом выбираете подходящую функцию-конвертер для сообщения? А завести виртуальную фабрику не судьба?

S>Все умные слова перечислили или что-то еще помните?

Тё>>Ах да, вы же не читали GoF.

S>Звиздеть изволите. Как обычно, впрочем.
Для вас виртуальная фабрика- это "умные слова". Блин, это же основы дизайна.

S>>>В общем, дурацкий вопрос.
Тё>>Я отвечаю на ваши вопросы. Будьте добры, ответьте и вы на мой вопрос.

S>Ну так задайте вопрос нормально. На дурацкие вопросы ответить невозможно.
Вы просто хамите на попытку вести конструктивное обсуждение. Вы с коллегами тоже так разговариваете?

S>>>Это вы про какой-то свой кривой код пишете.
Тё>>Я привёл вам пример вашего шаблона "can_be_with_comma". От которого глаза вытекают.

S>Они у вас вытекают потому, что a) вы не понимаете C++,
Вы хотели сказать, что не верую фанатично в превосходство C++? Ибо я успешно кодил на C++ до 2011г, в том числе и ассенизировал авгиевы конюшни после таких, как вы.

S> b) вы не в курсе предметной области (но это вам там netch80 очень убедительно объяснил).
Я в курсе своей предметной области. Кажется, я уже объяснил это. В какой области Вы или netch80, мне не очень понятно. Точнее, совсем не понятно.

S> Вы даже не увидели, что функция, над которой вы тогда решили постебаться, чистая.
Pure Function- такая, что не изменяет состояние приложения. Тут нет связи с C++, с шаблонами, которые вы абъюзите до состояния, что вытекают глаза, и вашего стиля программирования, в частности, наименования сущностей на английском б#####й_у#####к.jpg.

S>>>А в сумме, по итогу, комбайн.
Тё>>В итоге я собираю от простого к сложному, склеивая вместе подходищие инструменты.

S>Ну комбайн же. Даже еще и слепленный из того, что было.