Уж до кучи, забыл совсем — flower крайне негативные эмоции вызывает, история задач вечно куда-то теряется, фильтровать нормально нельзя, какие-то пустые поля в задачах часто бывают, чувство потери контроля в сравнении со старым celery cam и djcelery
Такой код вполне допустим на сосебедовании, но я для него поставил бы совершенно другие вопросы кандидату. Но я не показатель, я считаю что простое решение это зачастую хорошее решение, что что-то непонятное это или просто что-то ненужное, или это секта или это маркетинг.
Вопросы:
1. Что в нём плохо?
2. Что в нём хорошо?
3. Объясните что он делает
Вопрос №1 очень важен по любой теме, ответ на него даст вам понять кто перед вами, профессионал или не совсем, профессионал всегда знает минусы и ограничения того в чём он профессионал.
Вы будете смеяться дальше, но нам пока некогда и нет смысла переходить дальше Django 1.8, а celery 4.3 не дружит если у тебя ниже 1.9
Потрясающая зависимость celery и Django :)
Заниматься этим всем и ждать новых сюрпризов смысла не вижу, есть положительный опыт с другой библиотекой, проще перейти.
Это всё до боли знакомо и ясно :)
Но лок устареет только через 60 секунд.
А если у нас длительные процессы с несколько непонятной продолжительностью которые ресурсы берут? Аппроксимация TTL? Обновление TTL? Ну его… не надёжно это всё, всёравно останется какая-то блокировка у которой TTL несколько часов.
Мы своё элегантное решение сделали, пока обкатываем и оформляем, если интересно то пишите asovetnikov на гмейле
По отдельности kombu, billiard и всё остальное прекрасны может быть, но этот зоопарк сильно связан по конкретным версиям между собой и в случае ошибки в одном начинается процесс подбора версий.
Сколько неприятных моментов нам доставили распределенные блокировки по TTL в случае нештатных ситуаций :)
Самое печально, что блокировки по TTL без отслеживания смерти клиента в случае аварии могут помешать системе восстановиться после простого ребута.
Странно, что мейнтейнеры согласились включить это в репозиторий, уж так ли это необходимо?
Вообще celery переживает сложный период с выходом 4.x и качество «продукта» упало.
В celery очень много наростов, которые комьюнити видимо не может поддерживать и они просто вырезаются, из наиболее интересных это прекращение поддержки Redis как брокера.
Внутренности celery и его обвязок тоже не сахар (видел, исправлял, пытался доработать) и как это всё стабилизируется непонятно.
Часто обвязки несовместимы друг с другом, в некоторых версиях есть ошибки, а версии без ошибок уже дают ошибки из-за несовместимости.
Слишком сложный продукт стал для простого запуска задач (построение workflow из задач полноценно не работает в celery, дальше chain и group лучше не ходить).
Работаем с celery c 2015 года и через пару недель надеюсь откажемся от него, хотя задач у нас всего 3000-5000 в час.
1. Вы про производительность? Ну а не надо их бросать в цикле от которого ожидается высокая производительность.
Так эта статья о производительности?
2. Так в каких ситуациях это пользу принесёт? Или это теоретическая статья, вы про практику использования не написали.
Пожалейте новичков, пишите что это теория.
3. У вас был пример со сложением int + результат MaybeParse, почему-то вы не поняли в чём суть вопроса, забудем.
Постоянно пытаюсь из статей о ФП извлечь:
1. Чувство эстетического удовлетворения от применения ФП
2. И пользу для проектов и команды
Но каждая статья начинается с объяснения, что такое монады, зачем монады, примеры вида 1+2+3 и у меня ничего полезного не складывается в голове.
Хочется статью которая начинается с «Мы год использовали ФП, на таком то проекте… 2 члена команды чеканулись, 3 просветлели, ПМ стал улыбчивее, и мы сдали проект на 2 месяца раньше дедлайна».
Очень интересен именно такой опыт.
1. Так и исключение только один раз можно обработать
2.
там где отсутствие (правильного?) значения не является проблемой и допускается логикой программы
Т.е. там где стоит if() на такое значение?
ничто не мешает добавить описание причины остановки выполнения
Ну т.е. надо внедрять протоколирование активно, как обычно, вы только об этом не написали ничего. А потом пойди разбери откуда какой str пришёл.
Вы это всё на практике применяете ежедневно?
Напишите дополнение про боли которые это всё доставляет в продакшене. Не внедряется это всё безболезненно.
3. А когда же MaybeParse() вернёт Maybe? Мы же про уход от if(), а это влечёт работу с Maybe
1. Так ошибка в рантайме всёравно будет (или на этапе передачи в СУБД или ещё куда-то) или надо где-то всёравно обработать IsNothing().
2. А как понять источник «проблемы», если обнаружение этой проблемы происходит в самом конце?
3.
result += await MaybeParse(arg1);
Операцию сложения int с Maybe я ведь должен определять каждый раз? Или все операции с IsNothing() дают IsNothing()?
Да контейнеризация это хорошо, плохо что некоторые непонимают где оно плохо :)
Kubernetes даёт API и другие плюшки, но надо понимать какой ценой.
И всёравно если кластер нужен для автоматизации чего-либо, аля SaaS PaaS, то всёравно надо будет обвязывть всё своими скриптами.
А если так, то может и Docker swarm пойдёт.
Тут даже не силами своих devops всё сделано, а интеграторов позвали.
Недавно статья была, как небольшой компании два отдельных devops сотрудника потребовалось, чтобы свой Kubernetes обслуживать :)
Прямо перед переходом надо в начале считать экономику — кластер должен позволить или уволить админа, или программиста или дать экономию по железу, ну естественно если речь не идёт о подготовке к 10x росту зоопарка ИС :)
Ещё несколько лет назад обычному разработчику в adidas могла потребоваться неделя(!) для того, чтобы получить виртуальную машину
А причём здесь Kubernetes? :) Напрашивается, что тут организационная проблема.
Итогом 6-месячного проекта стал 100%-ный запуск сайта электронной коммерции (e-commerce) adidas на Kubernetes, благодаря чему:
его время отклика сократилось вдвое;
релизы стали происходить по 3-4 раза в день (раньше новый релиз выкатывался раз в 4-6 недель).
Ну вот прямо это всё заслуги Kubernetes?
Поверхностные причинно-следственные связи озвучены, которые сподвигнут неопытных IT-специалистов на длинную петлю проб и ошибок, т.к. за всем этим стоит не сам Kubernetes, а работа инженеров.
Вопросы:
1. Что в нём плохо?
2. Что в нём хорошо?
3. Объясните что он делает
Вопрос №1 очень важен по любой теме, ответ на него даст вам понять кто перед вами, профессионал или не совсем, профессионал всегда знает минусы и ограничения того в чём он профессионал.
Потрясающая зависимость celery и Django :)
Заниматься этим всем и ждать новых сюрпризов смысла не вижу, есть положительный опыт с другой библиотекой, проще перейти.
Но лок устареет только через 60 секунд.
А если у нас длительные процессы с несколько непонятной продолжительностью которые ресурсы берут? Аппроксимация TTL? Обновление TTL? Ну его… не надёжно это всё, всёравно останется какая-то блокировка у которой TTL несколько часов.
Мы своё элегантное решение сделали, пока обкатываем и оформляем, если интересно то пишите asovetnikov на гмейле
Дальше читать не стал :)
Правильный ответ на такую задачу — «ничего», не надо так писать.
Самое печально, что блокировки по TTL без отслеживания смерти клиента в случае аварии могут помешать системе восстановиться после простого ребута.
Про redis погорячился, это в 2016 году они хотели его почикать, но оставили github.com/celery/celery/commit/e15b0bfc658b397955beeae4a84127cf44686d50
Обвязки это billiard, kombu, beat и т.д.
Вообще celery переживает сложный период с выходом 4.x и качество «продукта» упало.
В celery очень много наростов, которые комьюнити видимо не может поддерживать и они просто вырезаются, из наиболее интересных это прекращение поддержки Redis как брокера.
Внутренности celery и его обвязок тоже не сахар (видел, исправлял, пытался доработать) и как это всё стабилизируется непонятно.
Часто обвязки несовместимы друг с другом, в некоторых версиях есть ошибки, а версии без ошибок уже дают ошибки из-за несовместимости.
Слишком сложный продукт стал для простого запуска задач (построение workflow из задач полноценно не работает в celery, дальше chain и group лучше не ходить).
Работаем с celery c 2015 года и через пару недель надеюсь откажемся от него, хотя задач у нас всего 3000-5000 в час.
Версия 3.x была вполне стабильна.
Так эта статья о производительности?
2. Так в каких ситуациях это пользу принесёт? Или это теоретическая статья, вы про практику использования не написали.
Пожалейте новичков, пишите что это теория.
3. У вас был пример со сложением int + результат MaybeParse, почему-то вы не поняли в чём суть вопроса, забудем.
Постоянно пытаюсь из статей о ФП извлечь:
1. Чувство эстетического удовлетворения от применения ФП
2. И пользу для проектов и команды
Но каждая статья начинается с объяснения, что такое монады, зачем монады, примеры вида 1+2+3 и у меня ничего полезного не складывается в голове.
Хочется статью которая начинается с «Мы год использовали ФП, на таком то проекте… 2 члена команды чеканулись, 3 просветлели, ПМ стал улыбчивее, и мы сдали проект на 2 месяца раньше дедлайна».
Очень интересен именно такой опыт.
2.
Т.е. там где стоит if() на такое значение?
Ну т.е. надо внедрять протоколирование активно, как обычно, вы только об этом не написали ничего. А потом пойди разбери откуда какой str пришёл.
Вы это всё на практике применяете ежедневно?
Напишите дополнение про боли которые это всё доставляет в продакшене. Не внедряется это всё безболезненно.
3. А когда же MaybeParse() вернёт Maybe? Мы же про уход от if(), а это влечёт работу с Maybe
2. А как понять источник «проблемы», если обнаружение этой проблемы происходит в самом конце?
3.
Операцию сложения int с Maybe я ведь должен определять каждый раз? Или все операции с IsNothing() дают IsNothing()?
Чуть подробнее если можно
Kubernetes даёт API и другие плюшки, но надо понимать какой ценой.
И всёравно если кластер нужен для автоматизации чего-либо, аля SaaS PaaS, то всёравно надо будет обвязывть всё своими скриптами.
А если так, то может и Docker swarm пойдёт.
Тут даже не силами своих devops всё сделано, а интеграторов позвали.
Недавно статья была, как небольшой компании два отдельных devops сотрудника потребовалось, чтобы свой Kubernetes обслуживать :)
Прямо перед переходом надо в начале считать экономику — кластер должен позволить или уволить админа, или программиста или дать экономию по железу, ну естественно если речь не идёт о подготовке к 10x росту зоопарка ИС :)
А причём здесь Kubernetes? :) Напрашивается, что тут организационная проблема.
Ну вот прямо это всё заслуги Kubernetes?
Поверхностные причинно-следственные связи озвучены, которые сподвигнут неопытных IT-специалистов на длинную петлю проб и ошибок, т.к. за всем этим стоит не сам Kubernetes, а работа инженеров.
Свой хостинг они используют