5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
ну так можно по идее, если использовать таки стейт машину как посредника.
Читать полностью…
потому что не знает о других возможных стейтах и не может делать смену стейта.
Читать полностью…
команда для этого не предназначена, если речь о паттернах из гофа, для этого стейт используется.
Читать полностью…
Звучит как паттерн команда, в нее зашиваешь переходы
Ну и по хорошему нужно где то иметь граф переходов
она прям сама говорит ему какой статус следующий или подает управляющий сигнал а дальше таск сам переходит в следующий стет?
Читать полностью…
Нет, вон же в доке жаргон совсем про другое. Почему там жаргон, а у меня не жаргон? И разве когда рекомендуют "погрепать логи", это не вообще ещё более широкое поискать в логах, вне зависимости от способа их хранения и доступа к ним?
Читать полностью…
В доке же это применение жаргона, под корпорации имеется ввиду построчный фильтр с регуляркой
Читать полностью…
Под distributed grep там скорее всего имеется ввиду прогон через regexp engine всего навсего. Там 100% не вызывается утилита grep
Ну и поиск по регэкспу в интерфейсе это не грепать
в индекс там мало что складывается в отличии от эластика
Читать полностью…
Зачем инструментам грепать, если они просто читают построчно и складывают в индекс?
А то что ты про регэкспу ищешь в интерфейсе инструмента - это не грепать
Спорно. Команда скажет в какой стейт пойти, а стейт машина перейдет в другое состояние, если переход позволен
Читать полностью…
Команда это как раз нечто, что решит по какой ветке стейт машины пойти - из состояния может быть переход более чем в одно состояние
Читать полностью…
Кмк в конечном итоге прийдёшь к какому то виду конечно автомата (стейт машины)
Читать полностью…
Зависит от того как сделать, но какое состояние там будет handler понимает, ну типа running, done, closed. Но так же я могу предположить, что есть кейсы, когда мне на статус закрытия нужно отправить ивенты во внешние системы (т.е. логика может быть чуть сложнее, чем проверить инварианты, поменять статус и сохранить в бд)
Читать полностью…
Потому что мне не техническое решение нужно, там простые переходы, а архитектурное(в теории там, наверное, может и стейта машина быть)
Читать полностью…
Часто сталкиваюсь с тем что надо как-то нормально проектировать переходы по статусам у сущностей, статусная модель же почти везде нужна(но мне не нужен state machine). Пока вижу два варианта:
1. Держать логику смены статусов внутри самой сущности. Но мне это не очень нравится, потому что сущность у меня может быть представлена разными структурами: где-то с relation’ами, где-то без джоинов просто сама сущность.
2. Выделить отдельный сервис (вызывать через интерфейс типа TaskCloser), который будет проверять инварианты, менять статусы и вызывать сторадж для сохранения. Но это выглядит как абстракция ради абстракции, ведь она живёт только в контексте операции (например, закрытия таска).
Для примера: у нас есть Engine, который принимает Task (у таска есть связь с steps). Engine возвращает Result, который обрабатывает EngineHandler, он понимает, что пора бы закрыть таск или перевести его в другой статус, делает нужные действия, и надо корректно перевести статусы таска и степов.
Плюс таск могут менять статус и вне Engine, например, по какому-то внешнему ивенту.
Как бы вы это нормально проектировали?
Тем не менее при этом имеют ввиду именно применение утилиты
Читать полностью…
Если конкретизировать вопрос, то в чём отличие, чем это не греп по S3?
Читать полностью…
То ли локи, то ли вектор на этом строился. quickwit вроде уже так не пиарит в документации, но в какой момент это - по крайней мере по обрывкам воспоминаний - предлагалось как дефолт
Читать полностью…