У нас есть отдельная команда, которая занимается внутренними инсталляциями Temporal и его тюнингом. Подробностей я не знаю, но, в частности, в хранилище используется YDB (сам слой персистентности доступен в open source: https://github.com/yandex/temporal-over-ydb)
Да, формулировка получилась не очень. Я имел в виду следующее: например, при создании заказа нужно выполнить довольно много действий. При этом результат некоторых действий требуется для некоторых других, а кроме того, падение одних действий можно игнорировать, падение других требует фоллбеков, а падение третьих приводит к невозможности дальнейшей обработки.
В старой парадигме (на очередях и стейт-машине) большая часть этих действий выполнялась последовательно, чтобы не усложнять дополнительно код, и так усложнённый асинхронными вызовами и фоллбеками. Temporal позволяет гораздо лучше сфокусироваться на бизнес-логике, и правильно расписать зависимости между действиями, не запутывая код настолько, что его невозможно будет поддерживать.
Поэтому даже с дополнительными задержками на взятие задач в работу весь этап завершается заметно быстрее
с Perfect я никогда не имел дело, но судя по сайту, у них нет такого акцента на надёжность и воспроизводимость бизнес-логики, как у темпорала, и он не построен на event sourcing, а просто поддерживает кеширование промежуточных результатов пайплайна. Поэтому у меня пока сложилось впечатление, что Perfect гораздо ближе по замыслу к Airflow
Тут довольно тонкий момент. Некоторые изменения — например, изменение продолжительности таймера, или изменение аргументов вызова Activity — не приводят к недетерминизму (вот здесь подробнее). Кроме того, мы вольны менять код activity вообще в любой момент, на них требования детерминизма не распространяются
А что делать, если его надо изменить?
Тут возможны разные варианты действий в зависимости от конкретной ситуации. Если воркфлоу паникует и не может пройти какой-то шаг, то здесь просто поможет релиз исправленного кода воркфлоу. Если workflow завис в бесконечном ожидании, то после выкатки новой версии кода можно его reset-нуть, и бизнес-логика будет выполняться заново (вместе со всеми activity) с того места, на который reset-нули. В принципе в большинстве случаев reset должен помочь — даже есть воркфлоу пошёл неправильно и уже закончился, мы всё равно сможем его reset-нуть.
По сути своей reset — это terminate исходного воркфлоу и копирование какой-то части истории в новый, который и продолжит выполняться
Перезапуск сервера Temporal приводит к остановке процессов, или они восстанавливаются в той же точке с тем же контекстом?
Всё восстановится в той же самой точке, потому что в истории событий в БД хранится вся необходимая информация, все остальные компоненты, в общем, stateless. Так, например, можно спокойно остановить сервер, обновить его, и запустить заново, единственным эффектом будет задержка выполнения действий на время этой операции
Безопаснее это на уровне железки сделать. Дублирование экранов, на втором настраиваешь зум. С точки зрения софта система чиста, разве что два монитора в режиме повторения. Но вряд ли это будет подозрительно
А можно было бы здесь, собственно, отображаемый пользователю адрес почты (strong.text-almost-black) сделать заблокированным инпутом с особым оформлением (чтобы просто выглядело как текст)? Тогда, кажется, и дублирование не понадобится.
Другое дело, что я часто встречаю формы из двух экранов — на первом только логин, на втором только пароль. Вот тут без скрытого поля уже очевидно никак
Не смог быстро найти инструкцию ручного развёртывания сервера на своём VPS. Такая есть? Не могу себе позволить вводить реквизиты от рутового доступа куда-то, кроме ssh-клиента
Оригинальные терминалы в маке тоже подтормаживали. У меня даже закрадывались мысли, что тормоза там специально, чтобы снизить нагрузку на кухню, ибо тормозило именно тогда, когда много заказов — впрочем, плохая оптимизация будет выглядеть так же
У нас на подъезде был именно такой классический «Сезам», абонентское устройство ровно как на фото. Установили его где-то между 1998 и 2000. Помню, что пластмассовые ключи были дешевле в заказе, но ломались в кармане очень просто, поэтому довольно быстро все сделали металлические.
Главная проблема у нашего была в том, что у него очень быстро стали мутными окошки для цифр, да и сами цифры с дисков стёрлись. Поэтому набирать их приходилось наощупь по оставшимся видимыми цифрам. И заодно привычка — сбрасывать цифры после того, как набрал свою квартиру, на всякий случай
Всё так, автоматическое чтение кода тоже пробовали (из внутренностей Psalm довольно удобно строится граф вызовов, с этой помощью мы находим затронутые пулл-реквестом эндпоинты/очереди), но получается на выходе довольно много мусора, так как количество потенциальных путей существенно превышает количество реальных.
Можно было бы попробовать прогонять какой-то автоматический анализ кода, опирающийся на намайненные данные: не что вообще может вызываться, а что вызывается при таком вот пути исполнения кода, этакий гибридный подход
Дядюшка Боб писал, что фреймворк — это деталь (которую должно быть легко заменить), поэтому я с подозрением отношусь ко всем шаблонам вида «чистая архитектура для...». Кстати, с этой точки зрения и «проверка доступности» — такая же деталь, которая, наверное, имеет значение только для балансировки трафика. Ведь если приложение действительно недоступно, то об этом пользователи узнают при любом запросе.
Но в связи с первым хочу задать вопрос: насколько эта структура поменяется, например, при смене фреймворка с Laravel на Symfony? Придётся ли переписывать что-то, кроме «клея» между бизнес-логикой и фреймворком? И, наверное, самый важный вопрос: как такая структура защищает от «прикипания» к конкретному фреймворку?
Спасибо! Вы написали статью, которую я давно хотел написать! На прошлой работе по заветам Голдратта организовал ретроспективы и удивительным образом проблемы начали решаться так, как никогда не решались до того. Правда, оригинальная нотация Голдратта не очень подходит для Миро (рисовал там), поэтому её слегка модифицировали.
Ещё из интересного: в решении конфликтов хорошо помогает ТРИЗ, ядро которой — снятие противоречие вместо нахождения компромиссов, а в поиске причинно-следственных связей — феноменологическое всматривание, то есть вместо Голдраттовского «да ну?» (Really?) задавать вопрос «а как я понимаю, что из А следует Б?» с рефлексией собственного восприятия
Десятки тысяч running workflow в моменте для нас норма
У нас есть отдельная команда, которая занимается внутренними инсталляциями Temporal и его тюнингом. Подробностей я не знаю, но, в частности, в хранилище используется YDB (сам слой персистентности доступен в open source: https://github.com/yandex/temporal-over-ydb)
Да, формулировка получилась не очень. Я имел в виду следующее: например, при создании заказа нужно выполнить довольно много действий. При этом результат некоторых действий требуется для некоторых других, а кроме того, падение одних действий можно игнорировать, падение других требует фоллбеков, а падение третьих приводит к невозможности дальнейшей обработки.
В старой парадигме (на очередях и стейт-машине) большая часть этих действий выполнялась последовательно, чтобы не усложнять дополнительно код, и так усложнённый асинхронными вызовами и фоллбеками. Temporal позволяет гораздо лучше сфокусироваться на бизнес-логике, и правильно расписать зависимости между действиями, не запутывая код настолько, что его невозможно будет поддерживать.
Поэтому даже с дополнительными задержками на взятие задач в работу весь этап завершается заметно быстрее
с Perfect я никогда не имел дело, но судя по сайту, у них нет такого акцента на надёжность и воспроизводимость бизнес-логики, как у темпорала, и он не построен на event sourcing, а просто поддерживает кеширование промежуточных результатов пайплайна. Поэтому у меня пока сложилось впечатление, что Perfect гораздо ближе по замыслу к Airflow
Да, есть Child Workflow
Тут довольно тонкий момент. Некоторые изменения — например, изменение продолжительности таймера, или изменение аргументов вызова Activity — не приводят к недетерминизму (вот здесь подробнее). Кроме того, мы вольны менять код activity вообще в любой момент, на них требования детерминизма не распространяются
Тут возможны разные варианты действий в зависимости от конкретной ситуации. Если воркфлоу паникует и не может пройти какой-то шаг, то здесь просто поможет релиз исправленного кода воркфлоу. Если workflow завис в бесконечном ожидании, то после выкатки новой версии кода можно его reset-нуть, и бизнес-логика будет выполняться заново (вместе со всеми activity) с того места, на который reset-нули. В принципе в большинстве случаев reset должен помочь — даже есть воркфлоу пошёл неправильно и уже закончился, мы всё равно сможем его reset-нуть.
По сути своей reset — это terminate исходного воркфлоу и копирование какой-то части истории в новый, который и продолжит выполняться
Всё восстановится в той же самой точке, потому что в истории событий в БД хранится вся необходимая информация, все остальные компоненты, в общем, stateless. Так, например, можно спокойно остановить сервер, обновить его, и запустить заново, единственным эффектом будет задержка выполнения действий на время этой операции
Стоило хотя бы указать, что всё это позаимствовано из Голдратта... И куда лучше описано в оригинале, чем в корявом пересказе в «методичке»
Безопаснее это на уровне железки сделать. Дублирование экранов, на втором настраиваешь зум. С точки зрения софта система чиста, разве что два монитора в режиме повторения. Но вряд ли это будет подозрительно
А можно было бы здесь, собственно, отображаемый пользователю адрес почты (
strong.text-almost-black) сделать заблокированным инпутом с особым оформлением (чтобы просто выглядело как текст)? Тогда, кажется, и дублирование не понадобится.Другое дело, что я часто встречаю формы из двух экранов — на первом только логин, на втором только пароль. Вот тут без скрытого поля уже очевидно никак
Не смог быстро найти инструкцию ручного развёртывания сервера на своём VPS. Такая есть? Не могу себе позволить вводить реквизиты от рутового доступа куда-то, кроме ssh-клиента
Интересное! Хочется теперь прочитать «полную версию», с реальными данными и интересными медицинскими фактами
Оригинальные терминалы в маке тоже подтормаживали. У меня даже закрадывались мысли, что тормоза там специально, чтобы снизить нагрузку на кухню, ибо тормозило именно тогда, когда много заказов — впрочем, плохая оптимизация будет выглядеть так же
Какие фичи есть в платформе из того, что нет в bupaR?
У нас на подъезде был именно такой классический «Сезам», абонентское устройство ровно как на фото. Установили его где-то между 1998 и 2000. Помню, что пластмассовые ключи были дешевле в заказе, но ломались в кармане очень просто, поэтому довольно быстро все сделали металлические.
Главная проблема у нашего была в том, что у него очень быстро стали мутными окошки для цифр, да и сами цифры с дисков стёрлись. Поэтому набирать их приходилось наощупь по оставшимся видимыми цифрам. И заодно привычка — сбрасывать цифры после того, как набрал свою квартиру, на всякий случай
Когда я искал свою первую работу, меня на собеседовании спрашивали, что выведет в PHP конструкция
или как-то так. Прикол в том, что print всегда возвращает 1, и за годы работы это знание не пригодилось мне ни разу.
Не так давно я узнал правильный ответ на этот вопрос: «я не знаю, что выведет этот код, но знаю, что сделаю я: git blame»
Причём автор даже не удосужился указать, в какой записи они «слушают» оную музыку. Зато много красивых слов с не вполне определённым смыслом.
Всё так, автоматическое чтение кода тоже пробовали (из внутренностей Psalm довольно удобно строится граф вызовов, с этой помощью мы находим затронутые пулл-реквестом эндпоинты/очереди), но получается на выходе довольно много мусора, так как количество потенциальных путей существенно превышает количество реальных.
Можно было бы попробовать прогонять какой-то автоматический анализ кода, опирающийся на намайненные данные: не что вообще может вызываться, а что вызывается при таком вот пути исполнения кода, этакий гибридный подход
Так целая глава называется
Оглавление «Чистой архитектуры»
Дядюшка Боб писал, что фреймворк — это деталь (которую должно быть легко заменить), поэтому я с подозрением отношусь ко всем шаблонам вида «чистая архитектура для...». Кстати, с этой точки зрения и «проверка доступности» — такая же деталь, которая, наверное, имеет значение только для балансировки трафика. Ведь если приложение действительно недоступно, то об этом пользователи узнают при любом запросе.
Но в связи с первым хочу задать вопрос: насколько эта структура поменяется, например, при смене фреймворка с Laravel на Symfony? Придётся ли переписывать что-то, кроме «клея» между бизнес-логикой и фреймворком? И, наверное, самый важный вопрос: как такая структура защищает от «прикипания» к конкретному фреймворку?
Спасибо! Вы написали статью, которую я давно хотел написать! На прошлой работе по заветам Голдратта организовал ретроспективы и удивительным образом проблемы начали решаться так, как никогда не решались до того. Правда, оригинальная нотация Голдратта не очень подходит для Миро (рисовал там), поэтому её слегка модифицировали.
Ещё из интересного: в решении конфликтов хорошо помогает ТРИЗ, ядро которой — снятие противоречие вместо нахождения компромиссов, а в поиске причинно-следственных связей — феноменологическое всматривание, то есть вместо Голдраттовского «да ну?» (Really?) задавать вопрос «а как я понимаю, что из А следует Б?» с рефлексией собственного восприятия
Меня больше другое занимает: масштаб оси X на этом графике:
Скрытый текст
Извините за рисование с телефона, просто продлил один «масштаб» оси X и другой
Не говоря уже о том, что график зависимости суицида от возраста выглядит совсем иначе:
Источник: https://rannks.ru/upload/iblock/45a/240921 Мартынихин презентация.pdf
(автор своих источников не указывает, разумеется)