Ох, я был в обоих лагерях "services vs managers". :)
Для больших проектов 100+ моделей обычно выбираю services последнее время. На практике поддерживать service, где и python логика и ORM в одном месте - легче. Да и распиливать потом - одно удовольствие. Но для маленьких проектов, как у автора - согласен, managers предпочтительнее и чище.
В любом случае вердикт один - нужно выносить из save().
Пару советов для дальнейшего успешного поиска работы:
Используй сразу python poetry + Dockerfile + docker-compose. Сейчас это такие же стандарты, как знание git. Дадут тебе +15 очков на собеседовании.
class Tokens(models.Model) -> class Token(models.Model)
settings.CHARACTERS = string.ascii_letters + string.ascii_digits +5 очков
Вместо цикла while True с filter() query надо использовать try: Model.objects.create() / except IntegrityError - так будет в 99.9% случаев только один запрос. +30 очков
token.requests_count += 1 -> Models.objects.filter().update(requests_count=F("requests_count")+1) +20 очков
Вынести код из save() в отдельный модуль services.create_token . +15 очков
Можно вместо рандомайзера использовать hash от pk, но это так уже, когда совсем делать нечего :) Нашел в одном из своих старых проектов: hashlib.shake_128(user_id.encode("utf-8")).hexdigest(3).upper()
Из реальных минусов django admin не указан самый главный: отсутствие нормальной кастомизации.
В реальной жизни первое время встречались кейсы, когда клиент не понимал почему я сделал такую красивую админку быстро, но не могу "перекрасить всего лишь кнопку".
Теперь я говорю так: админку даю вам в подарок as-is и мы ее внешне не переделываем. Как только функционал бота будет более-менее стабилизирован, бизнес модель протестирована, то выделяем бюджет и делаем нормальную панель на FastAPI + Vue/Flutter/подставьте_свою_технологию с любым дизайном. Такой подход уже работает нормально.
Я один из тех, кто использует aiogram + django admin and migration для MVP.
По минусам в статье:
Изначальная несовместимость фреймворков – какая разница, когда aiogram и django все равно крутится каждый в своем docker и лежит в разных репах? Они выполняет разные функции и django может быть удален одной кнопкой, когда придет время для его удаления? Мы же не говорим что PostgeSQL и Redis несовместимые технологии - просто выполняют разные задачи. Из плюсов - все написано на Python, нам не нужен frontend разработчик.
Django ORM – У нас что, 1000 админов? Зачем нам асинхронная ORM в админке? Понятно, что пользователей бота может быть несколько десятков тысяч + сам интерфейс предполагает быстрое взаимодействие - там нужна скорость, а для админки зачем скорость?
Из пушки по воробьям – no comments. Не нужны forms, tests, views and caches - не используй, не нужны applications - положи все в одну папку. Джанго можно использовать не только как написано в Tutorial, а просто сделать проект на 5-7 файлов в одной папке, если структура БД небольшая.
Дополнительный плюс:
Переодические задачи – если нужно раз в час что-то обновить, то periodiq + dramatiq отлично дружат с Django ORM и так же экономит время и деньги.
У вас есть окно с 6 до 12 месяцев от момент регистрации места жительства в Эстонии, где вы можете поменять права только принеся справку от семейного врача. Если просрочили (живете 12 месяцев и дольше) — то только с пересдачей экзаменов.
Налоговое резиденство никак не связано с гражданством. Достаточно стать налоговым резидентом Эстонии и вы освобождаетесь от налога в РФ на доходы в Эстонии.
Другой вопрос, что вы не освобождаетесь от налога РФ на полученные доходы в РФ. Если у вас остались доходы в РФ, то заплатите 30% НДФЛ в России и еще 20% НДФЛ в Эстонии. Но от этого достаточно просто уйти: получать доходы в РФ не как физическое лицо, а как юридическое. Ну или вообще не получать доходы в РФ.
Проблема только с покупкой и продажей недвижимости в РФ: вот там 50% от продажи отдай обоим государствам.
По словам ведущего аналитика Департамента статистики Алис Таммур, по состоянию на 1 января 2015 года доля эстонцев в численности населения страны составляла 69 процентов, а на начало 2019 года она сократилась до 68,5 процента.
За 5 лет доля эстонцев снизилась на 0.5%, и то в основном благодаря приезду иностранных граждан.
Некоторые европейские лоу-кост агенты авиабилетов требуют сначала заплатить сервисный сбор за возврат, и только после оплаты они готовы сказать сколько они вернут денег и оформить сам возврат.
Вообще, после 2 лет частых авиаперелетов для себя установил правило: если на сайте авиакомпании билеты дороже <10% чем у агента – брать напрямую у авиакомпании.
Потому что бывали случаи, например, берешь авиабилет Туркишей у российского агента. Что-то типо SVX-IST-MIA-IST-VKO, через пару месяцев Турки меняют рейсы на плечах SVX-IST и IST-VKO.
Звонишь Туркам:
– Можно поменять вылет на VKO, а прилет в TLL на 2 дня позже?
– Да, окей, пусть агент пришлет запрос на изменения
Звонишь агенту:
– Запросите авиакомпанию пожалуйста о смене рейсов
– Ой, а мы не можем, вам доступна только возможность одобрения предложенного варианта либо полного возврата стоимость авиабилетов. И вообще Турки никогда не согласятся на такой вариант.
– WTF? Только что Турки сказали что поменяют без проблем
– Ой, мы ничего не знаем, пишите email…
И начинается недельная переписка с агентом, звонки Туркам, чтобы они надавили на агента и тд.
Пару раз с таким столкнулся – больше нет никакого желания связываться с агентами.
По вашей проблеме смотрите документацию:
https://github.com/nginxinc/nginx-amplify-doc/blob/master/amplify-guide.md#what-to-check-if-amplify-agent-isnt-reporting-metrics
А точнее последний пункт:
Some VPS providers use hardened Linux kernels that may restrict non-root users from accessing /proc and /sys. Metrics describing system and NGINX disk I/O are usually affected. There is no an easy workaround for this except for allowing the agent to run as root. Sometimes fixing permissions for /proc and /sys/block may work.
Спасибо dlancer за ответ. Celery более гибко позволяет работать с задачами, причем напрямую из Django проекта. Отсутсвует необходимость «помнить» о расписании в cron'е.
Мы восстанавливаем данные вручную, по запросу. На клиенте этот функционал уже реализован. Интерфейс восстановления и автоматическое восстановление сейчас находится на тестировании, будет доступно к середине августа.
Данная тема, наверно, достойна отдельной статьи. Давайте, попробую объяснить кратко.
Риски у хостеров:
1. Бэкапы хранятся в соседней стойке или на том же СХД (можно вспомнить пример www.clodo.ru/ )
2. ВРемя восстановления непрогнозируемо (представьте, что умерла вся СХД у хостера)
Риски у «дропбокс» решений:
1. В первую очередь предназначен для синхронизации данных, а не для бэкапов
2. Малая скорость
Почему к нам доверия должно быть больше:
1. Мы используем Amazon S3, а не свой велосипед
2. Клиент, который вы ставите к себе на сервер, будет лежать в открытом доступе (можно, конечно, вспомнить про heartbleed, но это скорее исключение из правил)
Ох, я был в обоих лагерях "services vs managers". :)
Для больших проектов 100+ моделей обычно выбираю services последнее время. На практике поддерживать service, где и python логика и ORM в одном месте - легче. Да и распиливать потом - одно удовольствие. Но для маленьких проектов, как у автора - согласен, managers предпочтительнее и чище.
В любом случае вердикт один - нужно выносить из save().
Привет!
Пару советов для дальнейшего успешного поиска работы:
Используй сразу python poetry + Dockerfile + docker-compose. Сейчас это такие же стандарты, как знание git. Дадут тебе +15 очков на собеседовании.
class Tokens(models.Model)->class Token(models.Model)settings.CHARACTERS = string.ascii_letters + string.ascii_digits+5 очковВместо цикла
while True с filter() queryнадо использоватьtry: Model.objects.create() / except IntegrityError- так будет в 99.9% случаев только один запрос. +30 очковtoken.requests_count += 1->Models.objects.filter().update(requests_count=F("requests_count")+1)+20 очковВынести код из
save()в отдельный модульservices.create_token. +15 очковМожно вместо рандомайзера использовать hash от pk, но это так уже, когда совсем делать нечего :) Нашел в одном из своих старых проектов:
hashlib.shake_128(user_id.encode("utf-8")).hexdigest(3).upper()Из реальных минусов django admin не указан самый главный: отсутствие нормальной кастомизации.
В реальной жизни первое время встречались кейсы, когда клиент не понимал почему я сделал такую красивую админку быстро, но не могу "перекрасить всего лишь кнопку".
Теперь я говорю так: админку даю вам в подарок as-is и мы ее внешне не переделываем. Как только функционал бота будет более-менее стабилизирован, бизнес модель протестирована, то выделяем бюджет и делаем нормальную панель на FastAPI + Vue/Flutter/подставьте_свою_технологию с любым дизайном. Такой подход уже работает нормально.
Я один из тех, кто использует aiogram + django admin and migration для MVP.
По минусам в статье:
Изначальная несовместимость фреймворков – какая разница, когда aiogram и django все равно крутится каждый в своем docker и лежит в разных репах? Они выполняет разные функции и django может быть удален одной кнопкой, когда придет время для его удаления?
Мы же не говорим что PostgeSQL и Redis несовместимые технологии - просто выполняют разные задачи.
Из плюсов - все написано на Python, нам не нужен frontend разработчик.
Django ORM – У нас что, 1000 админов? Зачем нам асинхронная ORM в админке? Понятно, что пользователей бота может быть несколько десятков тысяч + сам интерфейс предполагает быстрое взаимодействие - там нужна скорость, а для админки зачем скорость?
Из пушки по воробьям – no comments. Не нужны forms, tests, views and caches - не используй, не нужны applications - положи все в одну папку. Джанго можно использовать не только как написано в Tutorial, а просто сделать проект на 5-7 файлов в одной папке, если структура БД небольшая.
Дополнительный плюс:
Переодические задачи – если нужно раз в час что-то обновить, то periodiq + dramatiq отлично дружат с Django ORM и так же экономит время и деньги.
Другой вопрос, что вы не освобождаетесь от налога РФ на полученные доходы в РФ. Если у вас остались доходы в РФ, то заплатите 30% НДФЛ в России и еще 20% НДФЛ в Эстонии. Но от этого достаточно просто уйти: получать доходы в РФ не как физическое лицо, а как юридическое. Ну или вообще не получать доходы в РФ.
Проблема только с покупкой и продажей недвижимости в РФ: вот там 50% от продажи отдай обоим государствам.
Согдасно последнему отчету все не так плохо:
rus.postimees.ee/6682916/naselenie-strany-v-proshlom-godu-uvelichilos-no-dolya-estoncev-sokratilas
По словам ведущего аналитика Департамента статистики Алис Таммур, по состоянию на 1 января 2015 года доля эстонцев в численности населения страны составляла 69 процентов, а на начало 2019 года она сократилась до 68,5 процента.
За 5 лет доля эстонцев снизилась на 0.5%, и то в основном благодаря приезду иностранных граждан.
51.15.0.0/16
Вообще, после 2 лет частых авиаперелетов для себя установил правило: если на сайте авиакомпании билеты дороже <10% чем у агента – брать напрямую у авиакомпании.
Потому что бывали случаи, например, берешь авиабилет Туркишей у российского агента. Что-то типо SVX-IST-MIA-IST-VKO, через пару месяцев Турки меняют рейсы на плечах SVX-IST и IST-VKO.
Звонишь Туркам:
– Можно поменять вылет на VKO, а прилет в TLL на 2 дня позже?
– Да, окей, пусть агент пришлет запрос на изменения
Звонишь агенту:
– Запросите авиакомпанию пожалуйста о смене рейсов
– Ой, а мы не можем, вам доступна только возможность одобрения предложенного варианта либо полного возврата стоимость авиабилетов. И вообще Турки никогда не согласятся на такой вариант.
– WTF? Только что Турки сказали что поменяют без проблем
– Ой, мы ничего не знаем, пишите email…
И начинается недельная переписка с агентом, звонки Туркам, чтобы они надавили на агента и тд.
Пару раз с таким столкнулся – больше нет никакого желания связываться с агентами.
По вашей проблеме смотрите документацию:
https://github.com/nginxinc/nginx-amplify-doc/blob/master/amplify-guide.md#what-to-check-if-amplify-agent-isnt-reporting-metrics
А точнее последний пункт:
Some VPS providers use hardened Linux kernels that may restrict non-root users from accessing /proc and /sys. Metrics describing system and NGINX disk I/O are usually affected. There is no an easy workaround for this except for allowing the agent to run as root. Sometimes fixing permissions for /proc and /sys/block may work.
Если версия агента 0.35 и оно не работает — отпишитесь, пожалуйста, в Intercom или в личку здесь, на хабре.
Веб-морда, кстати, не такая и мелочь, как кажется.
Риски у хостеров:
1. Бэкапы хранятся в соседней стойке или на том же СХД (можно вспомнить пример www.clodo.ru/ )
2. ВРемя восстановления непрогнозируемо (представьте, что умерла вся СХД у хостера)
Риски у «дропбокс» решений:
1. В первую очередь предназначен для синхронизации данных, а не для бэкапов
2. Малая скорость
Почему к нам доверия должно быть больше:
1. Мы используем Amazon S3, а не свой велосипед
2. Клиент, который вы ставите к себе на сервер, будет лежать в открытом доступе (можно, конечно, вспомнить про heartbleed, но это скорее исключение из правил)