У вас в профиле указано, что вы из рф, да и статья в блоге газпромбанка. Поэтому, собственно, возникает вопрос - не боитесь ли вы использовать pnpm, учитывая, что это protestware?
Благодарю за статью. Было интересно прочесть, но, к моему сожалению, самый важный момент, поиски ответа на который и привели меня сюда, остался за кадром. И вопрос этот - откат миграций.
Вот настроили мы пайплайн, выкатываем новый релиз, проходят миграции и тут что-то ломается. Пайплайн падает, релиз не случается, но вот миграции в базе уже есть. Что делать в этом случае? Писать отдельный джоб, который будет запускаться если миграции прошли, а пайплайн нет? Но как узнать какие именно изменения откатывать? Вопрос усложняется наличием пост миграций (в которых обычно делают деструктивные изменения за прошлые релизы).
Согласен, технология дорогая. Но за удобство абстракций всегда приходится платить, верно?
А вот накладку в реализации стандартной библиотеке сложно относить к минусам именно самой технологии. Кстати, спасибо что поделились этой информацией, не находил упоминаний об этом ранее.
Спасибо за наводку. Прочту на днях, как раз сам сейчас пытаюсь вникнуть во все тонкости темы.
Возможно, переведу и эти статьи. Или, быть может, уже кто-то перевел?
P.S.: Забавно, что этот автор тоже ссылается на переведенный здесь цикл.
Читая комментарии, часто натыкаюсь на хвалебные оды фентропилу. Потому хочу поделиться своим негативным опытом его применения.
Предыстория такая:
Еще в детстве мне поставили диагноз «Внутренняя открытая гидроцефалия». Ну и ВСД потом.
В связи с этим меня частенько мучили головные боли, характерной чертой которых был очаг в районе правой стороны переносицы. Со временем почти сошло на нет. Боли такого характера стали крайне редкими.
И вот, в мои 20 лет, Родина решила, что мне пора отдать ей свой долг. Мне этого делать не хотелось, и вспомнив про свою болячку я пошел к неврологу, чтобы он мне там понаписал всякого для военкомата. В ходе этого процесса, невролог мне выписал фенотропил. Говорит с твоей болезнью его нужно периодически курсами принимать. Да и вообще для мозга полезно.
Я стал принимать его по рецепту. Никаких улучшений я не заметил. А к середине курса у меня и вовсе возобновились эти характерные головные боли. Я не придал значения этому и допил курс до конца.
Почти сразу после окончания курса боли отступили. Со временем я начал замечать незначительные ухудшения памяти.
Пришло время следующего курса. Я снова начал пить фенотропил. И снова к середине курса у меня возобновились головные боли. Поняв что к чему, я не стал пить его дальше.
Со временем я понял, что память у меня серьезно ухудшилась. Ухудшились так же концентрация и быстрота мышления. Ни с чем другим, кроме как с приемом фентропила я это связать не могу.
Сейчас мне 23 года, каких-то подвижек к восстановлению или дальнейшему ухудшению перечисленных когнитивных функций не вижу.
Я понимаю, что мой опыт довольно специфический, но все же к приму этого препарата стоит отнестись с осторожностью.
P.S.: Спустя какое-то время мой друг решил пропить фенотропил для стимуляции мозговой деятельности. Я отдал ему остатки своего препарата. Никаких ощутимых положительных или отрицательных эффектов он не заметил. Но и пил его не долго.
P.P.S.: Если кому вдруг интересно, от долга перед Родиной моя болячка меня не избавила. :)
Да, ровно так сейчас и вышло. У операций уже до этого были ID, так что с этим проблем не возникло.
Видимо, я хочу от встроенного механизма конечных автоматов слишком многого. :) Ну или моя задача не особо на них (на конечные автоматы, в смысле) ложится и я пытаюсь притянуть ее за уши.
По мере разработки таки наступила ситуация, где без дополнительного сообщения пока не получается выкрутиться.
Стало нужным добавить таймаут для команд. И тут бы идеально подошел time_limit для состояния st_wait_perform. Но так как после таймаута нужно начать выполнять следующую команду из очереди (если она есть), а соответственно и менять состояние обратно на st_wait_perform, то в методах on_enter/on_exit не выйдет обработать событие таймаута. Потому придется слать отложенное сообщение, судя по всему.
Хотя и если реакция зависит от состояния агента, то, вопрос, конечно становится несколько более сложным. Возможно, лучше использовать реакцию кооперации.
Да, это понятно, что возникают проблемы с исключениями при смене состояний.
Просто логично было бы предположить, что SO будет действовать согласно so_exception_reaction, а не просто вызовет std::terminate. Тот же самый рестарт агента может быть логичным поведением программы в подобных случаях.
А расскажите, пожалуйста, про ваш случай подробнее.
У меня есть некий агент, который может выполнять внешние команды. Выполнение команды связано с IO операциями и занимает время. Параллельно выполнять команды нельзя.
Агент принимает команды и складывает их в очередь. В числе прочих, агент имеет такие статусы как st_wait_command и st_wait_perform. Пока выполняется команда агент находится в состоянии st_wait_perform. После выполнения команды нужно начать выполнять следующую команду из очереди, если она не пуста. Или же вернутся в состояние st_wait_command.
И вот код по началу выполнения следующей команды было бы удобно разместить в on_enter состояния st_wait_comman. Тогда оставалось бы просто перейти в состояние st_wait_command после выполнения команды.
Сейчас я уже нашел более-менее подходящее решение — вместо перехода в статус st_wait_command вызывать отдельный метод, который решит нужно ли менять состояние или же начать выполнять новую команду. Это работает, но эстетически смущает. Ведь этот метод занимается как раз тем, чем должен бы заниматься on_enter.
Не noexcept, send может бросать исключения.
Выходит, если нельзя использовать внутри on_enter/on_exit без try/catch (как вы делаете у себя в примере).
Как мне кажется, за зацикливанием должен следить все таки пользователь библиотеки. А то ведь при желании зацикливание можно и другими средствами организовать.
А при таких раскладах приходится слать дополнительное, совершенно не нужное, сообщение для смены состояния.
Кстати, на счет noexept, so_5::send ведь не noexept?
Хм, довольно неожиданно, что из on_enter одного состояния нельзя перейти в другое состояние.
Было бы не плохо этот момент хотя бы немного осветить в этой статье.
Тема stage-агентов оказалась гораздо глубже, чем можно было подумать на первый взгляд. :) Кстати, это довольно не плохая тема для статьи — плюсы и минусы, практика использования, предпосылки к применению, особенности реализации поверх SObjectizer.
Наоборот, статьи довольно интересные. Затрагиваются реальные проблемы, доходчиво объясняются их причины и решения на итерационных примерах улучшения кода. Это очень круто и почитать статьи интересно даже в отрыве от SObjectizer. Хочется надеяться, что комментариев нет только потому, что людям нечего добавить, а просто писать «спасибо за статью» на хабре не принято. :)
Итого, выходит что разница между обычным агентом и stage-агентам только во времени жизни. Эдакий синглтон.
Теперь стало понятнее. Спасибо за пояснение!
Странно, что к вашим статьям так мало комментариев.
Во многих их нет вообще. Пожалуй, оживлю немного ситуацию, хоть это и некрофильство.
В ходе прочтения вашего цикла статей у меня возник вопрос: вы говорите, что IO-агент из предыдущих статей является stage-агентом, потому как он занимается только IO операциями. Следуя этой логике можно было бы заметить, что остальные агенты, для обработки частей email'а тоже занимаются только своим делом. Но почему же тогда они не являются stage-агентами?
У вас в профиле указано, что вы из рф, да и статья в блоге газпромбанка. Поэтому, собственно, возникает вопрос - не боитесь ли вы использовать pnpm, учитывая, что это protestware?
Благодарю за статью. Было интересно прочесть, но, к моему сожалению, самый важный момент, поиски ответа на который и привели меня сюда, остался за кадром. И вопрос этот - откат миграций.
Вот настроили мы пайплайн, выкатываем новый релиз, проходят миграции и тут что-то ломается. Пайплайн падает, релиз не случается, но вот миграции в базе уже есть. Что делать в этом случае? Писать отдельный джоб, который будет запускаться если миграции прошли, а пайплайн нет? Но как узнать какие именно изменения откатывать? Вопрос усложняется наличием пост миграций (в которых обычно делают деструктивные изменения за прошлые релизы).
И дальше по тексту почти везде написано «джойстик». :)
А вот накладку в реализации стандартной библиотеке сложно относить к минусам именно самой технологии. Кстати, спасибо что поделились этой информацией, не находил упоминаний об этом ранее.
Возможно, переведу и эти статьи. Или, быть может, уже кто-то перевел?
P.S.: Забавно, что этот автор тоже ссылается на переведенный здесь цикл.
Предыстория такая:
Еще в детстве мне поставили диагноз «Внутренняя открытая гидроцефалия». Ну и ВСД потом.
В связи с этим меня частенько мучили головные боли, характерной чертой которых был очаг в районе правой стороны переносицы. Со временем почти сошло на нет. Боли такого характера стали крайне редкими.
И вот, в мои 20 лет, Родина решила, что мне пора отдать ей свой долг. Мне этого делать не хотелось, и вспомнив про свою болячку я пошел к неврологу, чтобы он мне там понаписал всякого для военкомата. В ходе этого процесса, невролог мне выписал фенотропил. Говорит с твоей болезнью его нужно периодически курсами принимать. Да и вообще для мозга полезно.
Я стал принимать его по рецепту. Никаких улучшений я не заметил. А к середине курса у меня и вовсе возобновились эти характерные головные боли. Я не придал значения этому и допил курс до конца.
Почти сразу после окончания курса боли отступили. Со временем я начал замечать незначительные ухудшения памяти.
Пришло время следующего курса. Я снова начал пить фенотропил. И снова к середине курса у меня возобновились головные боли. Поняв что к чему, я не стал пить его дальше.
Со временем я понял, что память у меня серьезно ухудшилась. Ухудшились так же концентрация и быстрота мышления. Ни с чем другим, кроме как с приемом фентропила я это связать не могу.
Сейчас мне 23 года, каких-то подвижек к восстановлению или дальнейшему ухудшению перечисленных когнитивных функций не вижу.
Я понимаю, что мой опыт довольно специфический, но все же к приму этого препарата стоит отнестись с осторожностью.
P.S.: Спустя какое-то время мой друг решил пропить фенотропил для стимуляции мозговой деятельности. Я отдал ему остатки своего препарата. Никаких ощутимых положительных или отрицательных эффектов он не заметил. Но и пил его не долго.
P.P.S.: Если кому вдруг интересно, от долга перед Родиной моя болячка меня не избавила. :)
Видимо, я хочу от встроенного механизма конечных автоматов слишком многого. :) Ну или моя задача не особо на них (на конечные автоматы, в смысле) ложится и я пытаюсь притянуть ее за уши.
Стало нужным добавить таймаут для команд. И тут бы идеально подошел time_limit для состояния st_wait_perform. Но так как после таймаута нужно начать выполнять следующую команду из очереди (если она есть), а соответственно и менять состояние обратно на st_wait_perform, то в методах on_enter/on_exit не выйдет обработать событие таймаута. Потому придется слать отложенное сообщение, судя по всему.
Просто логично было бы предположить, что SO будет действовать согласно so_exception_reaction, а не просто вызовет std::terminate. Тот же самый рестарт агента может быть логичным поведением программы в подобных случаях.
У меня есть некий агент, который может выполнять внешние команды. Выполнение команды связано с IO операциями и занимает время. Параллельно выполнять команды нельзя.
Агент принимает команды и складывает их в очередь. В числе прочих, агент имеет такие статусы как st_wait_command и st_wait_perform. Пока выполняется команда агент находится в состоянии st_wait_perform. После выполнения команды нужно начать выполнять следующую команду из очереди, если она не пуста. Или же вернутся в состояние st_wait_command.
И вот код по началу выполнения следующей команды было бы удобно разместить в on_enter состояния st_wait_comman. Тогда оставалось бы просто перейти в состояние st_wait_command после выполнения команды.
Сейчас я уже нашел более-менее подходящее решение — вместо перехода в статус st_wait_command вызывать отдельный метод, который решит нужно ли менять состояние или же начать выполнять новую команду. Это работает, но эстетически смущает. Ведь этот метод занимается как раз тем, чем должен бы заниматься on_enter.
Выходит, если нельзя использовать внутри on_enter/on_exit без try/catch (как вы делаете у себя в примере).
А при таких раскладах приходится слать дополнительное, совершенно не нужное, сообщение для смены состояния.
Кстати, на счет noexept, so_5::send ведь не noexept?
Было бы не плохо этот момент хотя бы немного осветить в этой статье.
Итого, выходит что разница между обычным агентом и stage-агентам только во времени жизни. Эдакий синглтон.
Теперь стало понятнее. Спасибо за пояснение!
Во многих их нет вообще. Пожалуй, оживлю немного ситуацию, хоть это и некрофильство.
В ходе прочтения вашего цикла статей у меня возник вопрос: вы говорите, что IO-агент из предыдущих статей является stage-агентом, потому как он занимается только IO операциями. Следуя этой логике можно было бы заметить, что остальные агенты, для обработки частей email'а тоже занимаются только своим делом. Но почему же тогда они не являются stage-агентами?