Сообщение Re[21]: Как в C++ получить Redux и Redux Dev Tools от 10.01.2021 10:36
Изменено 10.01.2021 10:39 Артём
Re[21]: Как в C++ получить Redux и Redux Dev Tools
Здравствуйте, so5team, Вы писали:
S>>>А это выглядит уже как проблема использованного инструмента. Либо же как неспособность разработчика сделать декомпозицию.
Тё>>Вы только что написали "не понятно, в чем там сложность". Её излишней и нет. Ибо декомпозиция.
S>Если там сложности нет, то зачем вы тогда пишете:
S>
У меня навороченные правила формализованы в простом конфиге.
S>>>Ничего подобного. HFSM -- это всего лишь один из возможных типов обработчиков для потока сообщений. И в HFSM нет каких-то принципиальных препятствий к тому, чтобы не справляться с большим потоком сообщений. Поэтому я и говорю, что HFSM не имеет отношения к величине нагрузки. Но вы, видимо, воспринимаете это все как-то сильно по свойму.
Тё>>Сценарий: коннектор заметил утерю пачки UDP пакетов и должен сделать TCP запрос. Он меняет состояние с "нормального" на "ошибка" и "дозапрос истории". В этом нет миллиона измений состояния в секунду. Однако, если сообщения так и не доходят- нужно понять, что там застряло, в чём проблема.
S>И при чем здесь HFSM? У вас что-то застревает внутри HFSM?
У меня в коннекторе была плоская FSM- одна проблема, что плоская, и вторая- отсутствие инструмента для инспекции состояния в случае нештатной ситуации.
Тё>>А как вы понимаете HFSM в разрезе миллиона сообщений в секунду?
S>HFSM не имеет отношения ни к миллиону сообщений в секунду, ни к единственному сообщению в секунду.
S>Если у вас есть поток сообщений в 1M msg/sec и вы его обрабатываете посредством HFSM,
Зачем вы его обрабатываете посредством HFSM? В моей задаче в коннектор складывал сообщения в конверты и писал в файл. Там не нужен HFSM. Далее, были компоненты в другом процессе, которые отвечали за конвертацию из raw формата с биржи (проприетарный либо SBE) в внутренний формат для дальнейшей обработки. Этот конвертор, много разных было. Самый красивый код получился с использованием Visitor.
S> в HFSM ... выбор подходящей реакции на очередное входящее сообщение
И что, на каждое сообщение смена реакции? Или вы таким образом выбираете подходящую функцию-конвертер для сообщения?
S>В общем, дурацкий вопрос.
Я отвечаю на ваши вопросы. Будьте добры, ответьте и вы на мой вопрос.
S>>>Такие проблемы должны диагностироваться показателями телеметрии, которая встраивается в приложение.
Тё>>Показатели говорят, что файл не растёт больше чем 30 секунд. Вам нужно исправить проблему, но если ваш код это спагетти, а ваш императивный код будет спагетти, найти проблему будет непросто.
S>Это вы про какой-то свой кривой код пишете.
Я привёл вам пример вашего шаблона "can_be_with_comma". От которого глаза вытекают.
S>>>Так вам же нужен не крошечный Redux, а комбайн.
Тё>>Опять 25. Нет мне не нужен комбайн. Мне нужно решать проблемы с использованием подходящих инрструментов. Одна маленькая задача- один инструмент.
S>А в сумме, по итогу, комбайн.
В итоге я собираю от простого к сложному, склеивая вместе подходищие инструменты.
S>>>А это выглядит уже как проблема использованного инструмента. Либо же как неспособность разработчика сделать декомпозицию.
Тё>>Вы только что написали "не понятно, в чем там сложность". Её излишней и нет. Ибо декомпозиция.
S>Если там сложности нет, то зачем вы тогда пишете:
S>
S>Либо правила навореченные, либо сложностей нет. А у вас и то, и другое.У меня UI с навороченными правилами
У меня навороченные правила формализованы в простом конфиге.
S>>>Ничего подобного. HFSM -- это всего лишь один из возможных типов обработчиков для потока сообщений. И в HFSM нет каких-то принципиальных препятствий к тому, чтобы не справляться с большим потоком сообщений. Поэтому я и говорю, что HFSM не имеет отношения к величине нагрузки. Но вы, видимо, воспринимаете это все как-то сильно по свойму.
Тё>>Сценарий: коннектор заметил утерю пачки UDP пакетов и должен сделать TCP запрос. Он меняет состояние с "нормального" на "ошибка" и "дозапрос истории". В этом нет миллиона измений состояния в секунду. Однако, если сообщения так и не доходят- нужно понять, что там застряло, в чём проблема.
S>И при чем здесь HFSM? У вас что-то застревает внутри HFSM?
У меня в коннекторе была плоская FSM- одна проблема, что плоская, и вторая- отсутствие инструмента для инспекции состояния в случае нештатной ситуации.
Тё>>А как вы понимаете HFSM в разрезе миллиона сообщений в секунду?
S>HFSM не имеет отношения ни к миллиону сообщений в секунду, ни к единственному сообщению в секунду.
S>Если у вас есть поток сообщений в 1M msg/sec и вы его обрабатываете посредством HFSM,
Зачем вы его обрабатываете посредством HFSM? В моей задаче в коннектор складывал сообщения в конверты и писал в файл. Там не нужен HFSM. Далее, были компоненты в другом процессе, которые отвечали за конвертацию из raw формата с биржи (проприетарный либо SBE) в внутренний формат для дальнейшей обработки. Этот конвертор, много разных было. Самый красивый код получился с использованием Visitor.
S> в HFSM ... выбор подходящей реакции на очередное входящее сообщение
И что, на каждое сообщение смена реакции? Или вы таким образом выбираете подходящую функцию-конвертер для сообщения?
S>В общем, дурацкий вопрос.
Я отвечаю на ваши вопросы. Будьте добры, ответьте и вы на мой вопрос.
S>>>Такие проблемы должны диагностироваться показателями телеметрии, которая встраивается в приложение.
Тё>>Показатели говорят, что файл не растёт больше чем 30 секунд. Вам нужно исправить проблему, но если ваш код это спагетти, а ваш императивный код будет спагетти, найти проблему будет непросто.
S>Это вы про какой-то свой кривой код пишете.
Я привёл вам пример вашего шаблона "can_be_with_comma". От которого глаза вытекают.
S>>>Так вам же нужен не крошечный Redux, а комбайн.
Тё>>Опять 25. Нет мне не нужен комбайн. Мне нужно решать проблемы с использованием подходящих инрструментов. Одна маленькая задача- один инструмент.
S>А в сумме, по итогу, комбайн.
В итоге я собираю от простого к сложному, склеивая вместе подходищие инструменты.
Re[21]: Как в C++ получить Redux и Redux Dev Tools
Здравствуйте, so5team, Вы писали:
S>>>А это выглядит уже как проблема использованного инструмента. Либо же как неспособность разработчика сделать декомпозицию.
Тё>>Вы только что написали "не понятно, в чем там сложность". Её излишней и нет. Ибо декомпозиция.
S>Если там сложности нет, то зачем вы тогда пишете:
S>
У меня навороченные правила формализованы в простом конфиге.
S>>>Ничего подобного. HFSM -- это всего лишь один из возможных типов обработчиков для потока сообщений. И в HFSM нет каких-то принципиальных препятствий к тому, чтобы не справляться с большим потоком сообщений. Поэтому я и говорю, что HFSM не имеет отношения к величине нагрузки. Но вы, видимо, воспринимаете это все как-то сильно по свойму.
Тё>>Сценарий: коннектор заметил утерю пачки UDP пакетов и должен сделать TCP запрос. Он меняет состояние с "нормального" на "ошибка" и "дозапрос истории". В этом нет миллиона измений состояния в секунду. Однако, если сообщения так и не доходят- нужно понять, что там застряло, в чём проблема.
S>И при чем здесь HFSM? У вас что-то застревает внутри HFSM?
У меня в коннекторе была плоская FSM- одна проблема, что плоская, и вторая- отсутствие инструмента для инспекции состояния в случае нештатной ситуации.
Тё>>А как вы понимаете HFSM в разрезе миллиона сообщений в секунду?
S>HFSM не имеет отношения ни к миллиону сообщений в секунду, ни к единственному сообщению в секунду.
S>Если у вас есть поток сообщений в 1M msg/sec и вы его обрабатываете посредством HFSM,
Зачем вы его обрабатываете посредством HFSM? В моей задаче в коннектор складывал сообщения в конверты и писал в файл. Там не нужен HFSM. Далее, были компоненты в другом процессе, которые отвечали за конвертацию из raw формата с биржи (проприетарный либо SBE) в внутренний формат для дальнейшей обработки. Этот конвертор, много разных было. Самый красивый код получился с использованием Visitor.
S> в HFSM ... выбор подходящей реакции на очередное входящее сообщение
И что, на каждое сообщение смена состояния? Или вы таким образом выбираете подходящую функцию-конвертер для сообщения? А завести виртуальную фабрику не судьба? Ах да, вы же не читали GoF.
S>В общем, дурацкий вопрос.
Я отвечаю на ваши вопросы. Будьте добры, ответьте и вы на мой вопрос.
S>>>Такие проблемы должны диагностироваться показателями телеметрии, которая встраивается в приложение.
Тё>>Показатели говорят, что файл не растёт больше чем 30 секунд. Вам нужно исправить проблему, но если ваш код это спагетти, а ваш императивный код будет спагетти, найти проблему будет непросто.
S>Это вы про какой-то свой кривой код пишете.
Я привёл вам пример вашего шаблона "can_be_with_comma". От которого глаза вытекают.
S>>>Так вам же нужен не крошечный Redux, а комбайн.
Тё>>Опять 25. Нет мне не нужен комбайн. Мне нужно решать проблемы с использованием подходящих инрструментов. Одна маленькая задача- один инструмент.
S>А в сумме, по итогу, комбайн.
В итоге я собираю от простого к сложному, склеивая вместе подходищие инструменты.
S>>>А это выглядит уже как проблема использованного инструмента. Либо же как неспособность разработчика сделать декомпозицию.
Тё>>Вы только что написали "не понятно, в чем там сложность". Её излишней и нет. Ибо декомпозиция.
S>Если там сложности нет, то зачем вы тогда пишете:
S>
S>Либо правила навореченные, либо сложностей нет. А у вас и то, и другое.У меня UI с навороченными правилами
У меня навороченные правила формализованы в простом конфиге.
S>>>Ничего подобного. HFSM -- это всего лишь один из возможных типов обработчиков для потока сообщений. И в HFSM нет каких-то принципиальных препятствий к тому, чтобы не справляться с большим потоком сообщений. Поэтому я и говорю, что HFSM не имеет отношения к величине нагрузки. Но вы, видимо, воспринимаете это все как-то сильно по свойму.
Тё>>Сценарий: коннектор заметил утерю пачки UDP пакетов и должен сделать TCP запрос. Он меняет состояние с "нормального" на "ошибка" и "дозапрос истории". В этом нет миллиона измений состояния в секунду. Однако, если сообщения так и не доходят- нужно понять, что там застряло, в чём проблема.
S>И при чем здесь HFSM? У вас что-то застревает внутри HFSM?
У меня в коннекторе была плоская FSM- одна проблема, что плоская, и вторая- отсутствие инструмента для инспекции состояния в случае нештатной ситуации.
Тё>>А как вы понимаете HFSM в разрезе миллиона сообщений в секунду?
S>HFSM не имеет отношения ни к миллиону сообщений в секунду, ни к единственному сообщению в секунду.
S>Если у вас есть поток сообщений в 1M msg/sec и вы его обрабатываете посредством HFSM,
Зачем вы его обрабатываете посредством HFSM? В моей задаче в коннектор складывал сообщения в конверты и писал в файл. Там не нужен HFSM. Далее, были компоненты в другом процессе, которые отвечали за конвертацию из raw формата с биржи (проприетарный либо SBE) в внутренний формат для дальнейшей обработки. Этот конвертор, много разных было. Самый красивый код получился с использованием Visitor.
S> в HFSM ... выбор подходящей реакции на очередное входящее сообщение
И что, на каждое сообщение смена состояния? Или вы таким образом выбираете подходящую функцию-конвертер для сообщения? А завести виртуальную фабрику не судьба? Ах да, вы же не читали GoF.
S>В общем, дурацкий вопрос.
Я отвечаю на ваши вопросы. Будьте добры, ответьте и вы на мой вопрос.
S>>>Такие проблемы должны диагностироваться показателями телеметрии, которая встраивается в приложение.
Тё>>Показатели говорят, что файл не растёт больше чем 30 секунд. Вам нужно исправить проблему, но если ваш код это спагетти, а ваш императивный код будет спагетти, найти проблему будет непросто.
S>Это вы про какой-то свой кривой код пишете.
Я привёл вам пример вашего шаблона "can_be_with_comma". От которого глаза вытекают.
S>>>Так вам же нужен не крошечный Redux, а комбайн.
Тё>>Опять 25. Нет мне не нужен комбайн. Мне нужно решать проблемы с использованием подходящих инрструментов. Одна маленькая задача- один инструмент.
S>А в сумме, по итогу, комбайн.
В итоге я собираю от простого к сложному, склеивая вместе подходищие инструменты.