Думаю не нужно объяснять почему для места падения выбрали полигон на Камчатке, а не Тихий океан или территорию «вероятного противника»(в первом случае съест пресса, во втором вероятный противник).
Ну прям вот очень понравилось. :) Спасибо!
Да и вообще, спасибо за статью. Слежу за успехами наших на любых фронтах. Приятно как то. :)
State — это текущее состояние Activity (то есть кубика), он и только он сохраняется в базу.
Это и так сохраняется. Просто движок воркфлоу это сложная штука. И продолжая…
Execution — это Singleton уровня Instance или приложения — не знаю, как бы я делал, но самое главное, что он бы не сохранялся в базу.
Не совсем понял что вы имеете ввиду. А как же дополнительные данные о воркфлоу, такие как какой сейчас шаг, под кем был запущен, состояние общее, контекст выполнения? Эти вещи нужны движку воркфлоу. Их то куда деть?
И как раз таки не Delay должен решать, нужно ли делать паузу (а следовательно и выгрузку — загрузку) или нет.
Имею ввиду должны ли мы попасть в Delay Activity или нет. И если попали, то дальше уже рулить тем, как мы ведем себя в ожидании путем реализации UnloadOnIdle.
Видимо у нас с Вами разное восприятие понятия пауза в каком либо рабочем потоке. :) Я предполагаю, что это не просто пауза, а выгрузка всего процесса из памяти с последующей загрузкой. И как раз таки не Delay должен решать, нужно ли делать паузу (а следовательно и выгрузку — загрузку) или нет. Да и управлять тем, делать ли Unload при простое или нет, можно путем реализации UnloadOnIdle в, уже упомянутом вами, WorkflowPersistenceService.
Про сохранение — я привел в пример delay activity, когда ждать следует 0 секунд. Зачем здесь сохраняться?
Вы сейчас хотите сделать так, что бы Delay Activity стал очень умным. DelayActivity должен сохранить состояние процесса, выгрузить его из памяти и при необходимости «поднять» его и снова запустить. Delay Activity не надо делать очень умным, как и любой блок вашего WorkFlow. Сам WorkFlow должен выбирать куда идти и что делать. Если вам надо попасть в Delay Activity, значит вам надо сохранить и заморозить поток. Какой срок, это исключительно ваше дело, но этот блок должен делать именно то, что он сейчас делает.
Интересно. Вообще, хранение своих заметок это очень полезно. Но я, для таких личных заметок использую Evernote.
Но недавно понял что не могу найти что нибудь, типа вики движка, но для хранения заметок по задачам. Что бы просто, быстро, расшарить можно. Да, вики движок решает эту задачу. Вики движки использовал разные, люблю Atlassian решение, даже покупал. Но немного не то. Надо проще и гораздо более предметно ориентированное.
В общем начал делать свой такой дневничок, но только в вебе, с возможностью поработать нескольким пользователям над заметками, группировкой по проектам-задачам. Пока использую только для себя. Не знаю, насколько интересно это людям, но может быть рано или поздно сделаю паблик.
Из фишек выделить особо нечего, такого прям уж что бы ах. :)
— Веб
— Markdown
— Хранение истории и сравнение версий
— Возможность комментировать
— Возможность расшаривать
— Оповещения
И скриншотик:
Скриншотик
В общем интересно узнать, что думает сообщество. :)
А, вы в целом понимаете что такое рекалькуляция индекса, я не верно понял Ваш вопрос. :) Детали по ElasticSearch я рассказать не могу. Подождем автора.
Это означает, что после вставки нового элемента, индекс меняется. Вот обновление\перестройка\рекалькуляция индекса необходима для того, что бы индекс был в актуальном состоянии.
Ну… Я бы сказал что зря так делали. :) :) Извините. Да, Вы опытнее преподавателя. Но большая ошибка, пробовать это показать. Вообще, всегда в таких случаях советую Карнеги почитать.
Проблема заинтересованности, как правило, гораздо сложнее, чем кажется на первый взгляд.
Но, я абсолютно уверен, что бывают ситуации, когда преподаватель может «заразить» студента интересом к предмету. Студент преподавателя «заразить» предметом не может. Выводы очевидны.
Ну прям вот очень понравилось. :) Спасибо!
Да и вообще, спасибо за статью. Слежу за успехами наших на любых фронтах. Приятно как то. :)
Это и так сохраняется. Просто движок воркфлоу это сложная штука. И продолжая…
Не совсем понял что вы имеете ввиду. А как же дополнительные данные о воркфлоу, такие как какой сейчас шаг, под кем был запущен, состояние общее, контекст выполнения? Эти вещи нужны движку воркфлоу. Их то куда деть?
Но опять таки, оставлять активити, лишь потому что «а вдруг», есть очень плохой путь.
Пример того, как класть в очередь, как доставать и вывод: «AMQP — крутая штука. Надо пользовать.». Очень убедительно. :D
Вы сейчас хотите сделать так, что бы Delay Activity стал очень умным. DelayActivity должен сохранить состояние процесса, выгрузить его из памяти и при необходимости «поднять» его и снова запустить. Delay Activity не надо делать очень умным, как и любой блок вашего WorkFlow. Сам WorkFlow должен выбирать куда идти и что делать. Если вам надо попасть в Delay Activity, значит вам надо сохранить и заморозить поток. Какой срок, это исключительно ваше дело, но этот блок должен делать именно то, что он сейчас делает.
что абсолютно логично.
А вот проблемы с параллельностью это да, это ад.
Но недавно понял что не могу найти что нибудь, типа вики движка, но для хранения заметок по задачам. Что бы просто, быстро, расшарить можно. Да, вики движок решает эту задачу. Вики движки использовал разные, люблю Atlassian решение, даже покупал. Но немного не то. Надо проще и гораздо более предметно ориентированное.
В общем начал делать свой такой дневничок, но только в вебе, с возможностью поработать нескольким пользователям над заметками, группировкой по проектам-задачам. Пока использую только для себя. Не знаю, насколько интересно это людям, но может быть рано или поздно сделаю паблик.
Из фишек выделить особо нечего, такого прям уж что бы ах. :)
— Веб
— Markdown
— Хранение истории и сравнение версий
— Возможность комментировать
— Возможность расшаривать
— Оповещения
И скриншотик:
В общем интересно узнать, что думает сообщество. :)
Проблема заинтересованности, как правило, гораздо сложнее, чем кажется на первый взгляд.
Но, я абсолютно уверен, что бывают ситуации, когда преподаватель может «заразить» студента интересом к предмету. Студент преподавателя «заразить» предметом не может. Выводы очевидны.