JT
Где можно захостить картиночки? В самом проекте держать не вариант, их там 300мб
AWS S3 мы используем.
Size: a a a
2020 October 07
DT
S3 у яндекса еще есть, с точно таким же API
AK
S3 у яндекса еще есть, с точно таким же API
Там вроде только ограниченное подмножество возможностей амазоновского апи поддерживается, не?
DT
Там вроде только ограниченное подмножество возможностей амазоновского апи поддерживается, не?
Получение мета инфы по файлам? Я не знаю какого функционала нет. Мы просто решилм взять как файлопомойку. Вполне дешевая и по фз152 проходит
DT
Ну и с джангой дружится за 1 минуту
NK
посоветуйте почтовый сервер на убунту чтобы протестить функцию send_mail на django
NK
нужно с инструкцией
NK
и более простую для установки и настройки
DT
Зачем подымать свой, когда можно заюзать гугл, яндекс и пр
DT
EMAIL_BACKEND = ‘django.core.mail.backends.smtp.EmailBackend’
EMAIL_HOST = ‘smtp.gmail.com’
EMAIL_USE_TLS = True
EMAIL_PORT = 587
EMAIL_HOST_USER = ‘your_account@gmail.com’
EMAIL_HOST_PASSWORD = ‘your account’s password’
MZ
Добрый вечер!
У меня довольно наболевший вопрос к тем, кто давно, регулярно и успешно использует celery на пратике: почему вы считаете, что celery это не переоцененный велосипед, а стоящий инструмент, который нестыдно затащить к себе в окружение?
Мой опыт работы с сельдереем несколько месяцев. И весь этот опыт я могу описать исключительно как мучение.
Проблемы:
1) ядро целери представляет собой набор из нескольких библиотек, каждая из которых ведется своей полугруппой разработчиков, которые не слишком оглядываются друг на друга. Каждый новый релиз что-то ломает в совместимости.
2) Они внедряют какие-то экзотические возможности, в то время как самые базовые работают криво. Ишью тянутся годами из одной мажор версии в другую. Большая из них тупо закрывается с комментарием: "у нас на это нет времени и ресурсов", либо "разработка функциональности не профинансирована".
3) Часть заявленных возможностей не работает с rabbitmq, другая - c redis. Про другие вообще говорить не стоит.
4) Совершенно непрозрачный механизм работы с очередями и внутренними счетчиками. Такое ощущение, что никто полностью не понимает, как оно работает. Информацию приходится выуживать из какие-то отдельных комментариев по всей сети.
5) Если бы мне нужна была очередь асинхронных задач, то, мне кажется, проще было бы поднять несколько нод на каком-нибудь асинхронном фреймворке в качестве апстрима за nginx, который бы по раундробину раскидывал бы запросы.
6) Если бы мне нужна была очередь отложенных асинхронных задач, то надежднее было бы полагаться на свой транспорт и свое хранение, а не на какие-то непонятные обертки над amqp и redis.
7) Ни rabbit, ни redis не имеют встроенной поддержки eta. Она реализуется через внутренние счетчики и виртуальные очереди на воркерах. Малейший рассинхрон с временной областью видимости и задачи начинают множиться. То есть, одна из основных идей, может подвести в любой момент - не рассчитал временные окна или какой-то воркер вовремя не отослал acknowledge - лови 50 писем одному пользователю!
8) Не работает на винде (так себе минус, но все же)
9) Мониторинг через flower, который отстает на несколько версий от latest. При этом сам flower агент тоже является подписчиком очереди из-за чего тоже вносит путаницу в распределение и назначение задач. Можно снимать прометеус метрики - их не смотрел.
10) Документация частично неактуальна и специально приукрашивают плюсы, специально скрывая минусы.
11) Если меняется код задачи, а система воркеров распределенная, то менять надо везде с релоудом всех. И тут своими броадкаст сообщениями они вообще вносят хаос в общую обработку.
12) Поддержка джанги тоже где-то с краю. Интеграция делается четвертыми лицами со своим додумыванием. Сюда же дичь с временными зонами. Если использовать что-то кроме utc, то начинается трэш: в логи пишется системное время, внутри воркеров utc, в цветке что-то свое
Почему вы ставите ему звезды на гитхабе? У вас более положительный юзер экспериенс? Вас не подводит eta? Вы молотите сотни и тысячи запросов в минуту и упираетесь именно в транспорт, а не в другие ресурсы? С этим не справился бы крон или свой микро-веб-сервис? Вы тоже чувствуете боль, но какие-то фишки вас заставляют терпеть? Если да, то какие?
У меня довольно наболевший вопрос к тем, кто давно, регулярно и успешно использует celery на пратике: почему вы считаете, что celery это не переоцененный велосипед, а стоящий инструмент, который нестыдно затащить к себе в окружение?
Мой опыт работы с сельдереем несколько месяцев. И весь этот опыт я могу описать исключительно как мучение.
Проблемы:
1) ядро целери представляет собой набор из нескольких библиотек, каждая из которых ведется своей полугруппой разработчиков, которые не слишком оглядываются друг на друга. Каждый новый релиз что-то ломает в совместимости.
2) Они внедряют какие-то экзотические возможности, в то время как самые базовые работают криво. Ишью тянутся годами из одной мажор версии в другую. Большая из них тупо закрывается с комментарием: "у нас на это нет времени и ресурсов", либо "разработка функциональности не профинансирована".
3) Часть заявленных возможностей не работает с rabbitmq, другая - c redis. Про другие вообще говорить не стоит.
4) Совершенно непрозрачный механизм работы с очередями и внутренними счетчиками. Такое ощущение, что никто полностью не понимает, как оно работает. Информацию приходится выуживать из какие-то отдельных комментариев по всей сети.
5) Если бы мне нужна была очередь асинхронных задач, то, мне кажется, проще было бы поднять несколько нод на каком-нибудь асинхронном фреймворке в качестве апстрима за nginx, который бы по раундробину раскидывал бы запросы.
6) Если бы мне нужна была очередь отложенных асинхронных задач, то надежднее было бы полагаться на свой транспорт и свое хранение, а не на какие-то непонятные обертки над amqp и redis.
7) Ни rabbit, ни redis не имеют встроенной поддержки eta. Она реализуется через внутренние счетчики и виртуальные очереди на воркерах. Малейший рассинхрон с временной областью видимости и задачи начинают множиться. То есть, одна из основных идей, может подвести в любой момент - не рассчитал временные окна или какой-то воркер вовремя не отослал acknowledge - лови 50 писем одному пользователю!
8) Не работает на винде (так себе минус, но все же)
9) Мониторинг через flower, который отстает на несколько версий от latest. При этом сам flower агент тоже является подписчиком очереди из-за чего тоже вносит путаницу в распределение и назначение задач. Можно снимать прометеус метрики - их не смотрел.
10) Документация частично неактуальна и специально приукрашивают плюсы, специально скрывая минусы.
11) Если меняется код задачи, а система воркеров распределенная, то менять надо везде с релоудом всех. И тут своими броадкаст сообщениями они вообще вносят хаос в общую обработку.
12) Поддержка джанги тоже где-то с краю. Интеграция делается четвертыми лицами со своим додумыванием. Сюда же дичь с временными зонами. Если использовать что-то кроме utc, то начинается трэш: в логи пишется системное время, внутри воркеров utc, в цветке что-то свое
Почему вы ставите ему звезды на гитхабе? У вас более положительный юзер экспериенс? Вас не подводит eta? Вы молотите сотни и тысячи запросов в минуту и упираетесь именно в транспорт, а не в другие ресурсы? С этим не справился бы крон или свой микро-веб-сервис? Вы тоже чувствуете боль, но какие-то фишки вас заставляют терпеть? Если да, то какие?
N
всем привет. Как можно менять текст админки (site_header) в зависимости от пользователя, который входит в админку ?
AF
Добрый вечер!
У меня довольно наболевший вопрос к тем, кто давно, регулярно и успешно использует celery на пратике: почему вы считаете, что celery это не переоцененный велосипед, а стоящий инструмент, который нестыдно затащить к себе в окружение?
Мой опыт работы с сельдереем несколько месяцев. И весь этот опыт я могу описать исключительно как мучение.
Проблемы:
1) ядро целери представляет собой набор из нескольких библиотек, каждая из которых ведется своей полугруппой разработчиков, которые не слишком оглядываются друг на друга. Каждый новый релиз что-то ломает в совместимости.
2) Они внедряют какие-то экзотические возможности, в то время как самые базовые работают криво. Ишью тянутся годами из одной мажор версии в другую. Большая из них тупо закрывается с комментарием: "у нас на это нет времени и ресурсов", либо "разработка функциональности не профинансирована".
3) Часть заявленных возможностей не работает с rabbitmq, другая - c redis. Про другие вообще говорить не стоит.
4) Совершенно непрозрачный механизм работы с очередями и внутренними счетчиками. Такое ощущение, что никто полностью не понимает, как оно работает. Информацию приходится выуживать из какие-то отдельных комментариев по всей сети.
5) Если бы мне нужна была очередь асинхронных задач, то, мне кажется, проще было бы поднять несколько нод на каком-нибудь асинхронном фреймворке в качестве апстрима за nginx, который бы по раундробину раскидывал бы запросы.
6) Если бы мне нужна была очередь отложенных асинхронных задач, то надежднее было бы полагаться на свой транспорт и свое хранение, а не на какие-то непонятные обертки над amqp и redis.
7) Ни rabbit, ни redis не имеют встроенной поддержки eta. Она реализуется через внутренние счетчики и виртуальные очереди на воркерах. Малейший рассинхрон с временной областью видимости и задачи начинают множиться. То есть, одна из основных идей, может подвести в любой момент - не рассчитал временные окна или какой-то воркер вовремя не отослал acknowledge - лови 50 писем одному пользователю!
8) Не работает на винде (так себе минус, но все же)
9) Мониторинг через flower, который отстает на несколько версий от latest. При этом сам flower агент тоже является подписчиком очереди из-за чего тоже вносит путаницу в распределение и назначение задач. Можно снимать прометеус метрики - их не смотрел.
10) Документация частично неактуальна и специально приукрашивают плюсы, специально скрывая минусы.
11) Если меняется код задачи, а система воркеров распределенная, то менять надо везде с релоудом всех. И тут своими броадкаст сообщениями они вообще вносят хаос в общую обработку.
12) Поддержка джанги тоже где-то с краю. Интеграция делается четвертыми лицами со своим додумыванием. Сюда же дичь с временными зонами. Если использовать что-то кроме utc, то начинается трэш: в логи пишется системное время, внутри воркеров utc, в цветке что-то свое
Почему вы ставите ему звезды на гитхабе? У вас более положительный юзер экспериенс? Вас не подводит eta? Вы молотите сотни и тысячи запросов в минуту и упираетесь именно в транспорт, а не в другие ресурсы? С этим не справился бы крон или свой микро-веб-сервис? Вы тоже чувствуете боль, но какие-то фишки вас заставляют терпеть? Если да, то какие?
У меня довольно наболевший вопрос к тем, кто давно, регулярно и успешно использует celery на пратике: почему вы считаете, что celery это не переоцененный велосипед, а стоящий инструмент, который нестыдно затащить к себе в окружение?
Мой опыт работы с сельдереем несколько месяцев. И весь этот опыт я могу описать исключительно как мучение.
Проблемы:
1) ядро целери представляет собой набор из нескольких библиотек, каждая из которых ведется своей полугруппой разработчиков, которые не слишком оглядываются друг на друга. Каждый новый релиз что-то ломает в совместимости.
2) Они внедряют какие-то экзотические возможности, в то время как самые базовые работают криво. Ишью тянутся годами из одной мажор версии в другую. Большая из них тупо закрывается с комментарием: "у нас на это нет времени и ресурсов", либо "разработка функциональности не профинансирована".
3) Часть заявленных возможностей не работает с rabbitmq, другая - c redis. Про другие вообще говорить не стоит.
4) Совершенно непрозрачный механизм работы с очередями и внутренними счетчиками. Такое ощущение, что никто полностью не понимает, как оно работает. Информацию приходится выуживать из какие-то отдельных комментариев по всей сети.
5) Если бы мне нужна была очередь асинхронных задач, то, мне кажется, проще было бы поднять несколько нод на каком-нибудь асинхронном фреймворке в качестве апстрима за nginx, который бы по раундробину раскидывал бы запросы.
6) Если бы мне нужна была очередь отложенных асинхронных задач, то надежднее было бы полагаться на свой транспорт и свое хранение, а не на какие-то непонятные обертки над amqp и redis.
7) Ни rabbit, ни redis не имеют встроенной поддержки eta. Она реализуется через внутренние счетчики и виртуальные очереди на воркерах. Малейший рассинхрон с временной областью видимости и задачи начинают множиться. То есть, одна из основных идей, может подвести в любой момент - не рассчитал временные окна или какой-то воркер вовремя не отослал acknowledge - лови 50 писем одному пользователю!
8) Не работает на винде (так себе минус, но все же)
9) Мониторинг через flower, который отстает на несколько версий от latest. При этом сам flower агент тоже является подписчиком очереди из-за чего тоже вносит путаницу в распределение и назначение задач. Можно снимать прометеус метрики - их не смотрел.
10) Документация частично неактуальна и специально приукрашивают плюсы, специально скрывая минусы.
11) Если меняется код задачи, а система воркеров распределенная, то менять надо везде с релоудом всех. И тут своими броадкаст сообщениями они вообще вносят хаос в общую обработку.
12) Поддержка джанги тоже где-то с краю. Интеграция делается четвертыми лицами со своим додумыванием. Сюда же дичь с временными зонами. Если использовать что-то кроме utc, то начинается трэш: в логи пишется системное время, внутри воркеров utc, в цветке что-то свое
Почему вы ставите ему звезды на гитхабе? У вас более положительный юзер экспериенс? Вас не подводит eta? Вы молотите сотни и тысячи запросов в минуту и упираетесь именно в транспорт, а не в другие ресурсы? С этим не справился бы крон или свой микро-веб-сервис? Вы тоже чувствуете боль, но какие-то фишки вас заставляют терпеть? Если да, то какие?
крон и докер больная тема, как раз юзаю celery-beat ибо не смог нормально крон всунуть
N
всем привет. Как можно менять текст админки (site_header) в зависимости от пользователя, который входит в админку ?
никак? этот состояние при запуске фиксируется вроде
DT
Добрый вечер!
У меня довольно наболевший вопрос к тем, кто давно, регулярно и успешно использует celery на пратике: почему вы считаете, что celery это не переоцененный велосипед, а стоящий инструмент, который нестыдно затащить к себе в окружение?
Мой опыт работы с сельдереем несколько месяцев. И весь этот опыт я могу описать исключительно как мучение.
Проблемы:
1) ядро целери представляет собой набор из нескольких библиотек, каждая из которых ведется своей полугруппой разработчиков, которые не слишком оглядываются друг на друга. Каждый новый релиз что-то ломает в совместимости.
2) Они внедряют какие-то экзотические возможности, в то время как самые базовые работают криво. Ишью тянутся годами из одной мажор версии в другую. Большая из них тупо закрывается с комментарием: "у нас на это нет времени и ресурсов", либо "разработка функциональности не профинансирована".
3) Часть заявленных возможностей не работает с rabbitmq, другая - c redis. Про другие вообще говорить не стоит.
4) Совершенно непрозрачный механизм работы с очередями и внутренними счетчиками. Такое ощущение, что никто полностью не понимает, как оно работает. Информацию приходится выуживать из какие-то отдельных комментариев по всей сети.
5) Если бы мне нужна была очередь асинхронных задач, то, мне кажется, проще было бы поднять несколько нод на каком-нибудь асинхронном фреймворке в качестве апстрима за nginx, который бы по раундробину раскидывал бы запросы.
6) Если бы мне нужна была очередь отложенных асинхронных задач, то надежднее было бы полагаться на свой транспорт и свое хранение, а не на какие-то непонятные обертки над amqp и redis.
7) Ни rabbit, ни redis не имеют встроенной поддержки eta. Она реализуется через внутренние счетчики и виртуальные очереди на воркерах. Малейший рассинхрон с временной областью видимости и задачи начинают множиться. То есть, одна из основных идей, может подвести в любой момент - не рассчитал временные окна или какой-то воркер вовремя не отослал acknowledge - лови 50 писем одному пользователю!
8) Не работает на винде (так себе минус, но все же)
9) Мониторинг через flower, который отстает на несколько версий от latest. При этом сам flower агент тоже является подписчиком очереди из-за чего тоже вносит путаницу в распределение и назначение задач. Можно снимать прометеус метрики - их не смотрел.
10) Документация частично неактуальна и специально приукрашивают плюсы, специально скрывая минусы.
11) Если меняется код задачи, а система воркеров распределенная, то менять надо везде с релоудом всех. И тут своими броадкаст сообщениями они вообще вносят хаос в общую обработку.
12) Поддержка джанги тоже где-то с краю. Интеграция делается четвертыми лицами со своим додумыванием. Сюда же дичь с временными зонами. Если использовать что-то кроме utc, то начинается трэш: в логи пишется системное время, внутри воркеров utc, в цветке что-то свое
Почему вы ставите ему звезды на гитхабе? У вас более положительный юзер экспериенс? Вас не подводит eta? Вы молотите сотни и тысячи запросов в минуту и упираетесь именно в транспорт, а не в другие ресурсы? С этим не справился бы крон или свой микро-веб-сервис? Вы тоже чувствуете боль, но какие-то фишки вас заставляют терпеть? Если да, то какие?
У меня довольно наболевший вопрос к тем, кто давно, регулярно и успешно использует celery на пратике: почему вы считаете, что celery это не переоцененный велосипед, а стоящий инструмент, который нестыдно затащить к себе в окружение?
Мой опыт работы с сельдереем несколько месяцев. И весь этот опыт я могу описать исключительно как мучение.
Проблемы:
1) ядро целери представляет собой набор из нескольких библиотек, каждая из которых ведется своей полугруппой разработчиков, которые не слишком оглядываются друг на друга. Каждый новый релиз что-то ломает в совместимости.
2) Они внедряют какие-то экзотические возможности, в то время как самые базовые работают криво. Ишью тянутся годами из одной мажор версии в другую. Большая из них тупо закрывается с комментарием: "у нас на это нет времени и ресурсов", либо "разработка функциональности не профинансирована".
3) Часть заявленных возможностей не работает с rabbitmq, другая - c redis. Про другие вообще говорить не стоит.
4) Совершенно непрозрачный механизм работы с очередями и внутренними счетчиками. Такое ощущение, что никто полностью не понимает, как оно работает. Информацию приходится выуживать из какие-то отдельных комментариев по всей сети.
5) Если бы мне нужна была очередь асинхронных задач, то, мне кажется, проще было бы поднять несколько нод на каком-нибудь асинхронном фреймворке в качестве апстрима за nginx, который бы по раундробину раскидывал бы запросы.
6) Если бы мне нужна была очередь отложенных асинхронных задач, то надежднее было бы полагаться на свой транспорт и свое хранение, а не на какие-то непонятные обертки над amqp и redis.
7) Ни rabbit, ни redis не имеют встроенной поддержки eta. Она реализуется через внутренние счетчики и виртуальные очереди на воркерах. Малейший рассинхрон с временной областью видимости и задачи начинают множиться. То есть, одна из основных идей, может подвести в любой момент - не рассчитал временные окна или какой-то воркер вовремя не отослал acknowledge - лови 50 писем одному пользователю!
8) Не работает на винде (так себе минус, но все же)
9) Мониторинг через flower, который отстает на несколько версий от latest. При этом сам flower агент тоже является подписчиком очереди из-за чего тоже вносит путаницу в распределение и назначение задач. Можно снимать прометеус метрики - их не смотрел.
10) Документация частично неактуальна и специально приукрашивают плюсы, специально скрывая минусы.
11) Если меняется код задачи, а система воркеров распределенная, то менять надо везде с релоудом всех. И тут своими броадкаст сообщениями они вообще вносят хаос в общую обработку.
12) Поддержка джанги тоже где-то с краю. Интеграция делается четвертыми лицами со своим додумыванием. Сюда же дичь с временными зонами. Если использовать что-то кроме utc, то начинается трэш: в логи пишется системное время, внутри воркеров utc, в цветке что-то свое
Почему вы ставите ему звезды на гитхабе? У вас более положительный юзер экспериенс? Вас не подводит eta? Вы молотите сотни и тысячи запросов в минуту и упираетесь именно в транспорт, а не в другие ресурсы? С этим не справился бы крон или свой микро-веб-сервис? Вы тоже чувствуете боль, но какие-то фишки вас заставляют терпеть? Если да, то какие?
Нормально прорвало. Да все городят свои велосипеды очередей обработки чаще всего. А пока велосипед не нагорожен - используется сельдерей.
DT
А про
eta. А где это, если не секрет, гарантировано и известно как работает? Только не надо про mongo. А вообще мир тлен, даN
никак? этот состояние при запуске фиксируется вроде
ок, пусть тогда не site header, а в общем нужно вывести название филиала, к которому привязан оператор
N
ок, пусть тогда не site header, а в общем нужно вывести название филиала, к которому привязан оператор
в шаблон тег get_sublocation_name или че нить такое)
N
это ок, а какой метод нужно переопределять ?
N
чтобы вывести например в base_site свою переменную