Сюда же накину, если автор не против. 5. Работа с миграциями, data миграции, миграции в команде (git) и миграции при работе с несколькими основными ветками staging и prod например (git). 6. Таски (celery etc.) - соответственно фишки, кроны, чейны и т.д. 7. Кэш - польза, применение и т.д. Прошу прощения если какая-то из тем уже есть на канале.

Ох, это будет топ-годнота!

Вангую перенаправят вас с вашими аппетитами на курс)) Но темы класс, плюсую)

1. Сигналы - отстой, не надо их использовать:) Заколебаться потом искать, кто где меняет данные. 2. Что тут было бы интересно? Я предпочитаю использовать джанговых ORM на простых запросах и писать сырой SQL на сложных запросах, но в целом раз уж юзать ORM, то стоило бы и на сложных запросах использовать ORM (бенефиты автоматического рефакторинга IDE будут доступны и тп). Но я не могу заставить себя учить очередной птичий язык очередного ORM плюс не доверяю ему на сложных запросах. В оракловой БД есть подсказки для БД, которые вставляются в SQL, и подсказывают оптимизатору, как лучше выполнять запрос. Какой тут ORM:) В постгрес такого нет, но я всё равно скептически отношусь к ORM для чего-то сложного. 3. Сессии. Ну, они есть, джанговый механизм вполне юзабелен и описан docs.djangoproject.com/en/3.2/topics/http/sessions/, что по нему интересно? 4. Auth и кастомный юзер - да просто AbstractUser реализуй и в путь:) docs.djangoproject.com/en/3.2/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project 5. Миграции. Вопрос интересный, но мне хочется больше деталей вопроса. Миграции в команде? Ну мержить придется, тут других выходов нет, кажется:) 6. Celery - злющее зло, все не доходят руки выпилить его к едрене фене с проектов, но однажды точно дойдут. Cron лучше, чем celery beat. Для асинхронных задач, запускаемых из джанго вьюшек, надо найти какую-то замену Celery, сам Celery не нравится. И DRF тоже не нравится. Но Celery больше:)

@@t0digital А чем конкретно Celery + beat не нравится? У нас пара десятков воркеров с ним, свои задачи выполняет стабильно.

Рад, что полезно!

Спасибооо! Буду продолжать!

Если есть уверенность, что никто нигде не забудет обернуть нужный функционал в транзакцию - то да

Однозначно. Именно поэтому любой фреймворк - говно, потому что надо знать кучу магии которая происходит внутри фреймворка, чтобы написать программу чуть сложнее чем hello world. А если самому стартовать транзакции никакой фреймворк нафик не нужен

@@t0digital ну тут вопрос решается достаточно просто. Прежде чем начать реализовывать кусок кода необходимо включить головушку, посидеть подумать, хорошенько расписать задачу и только потом кодить :)

​@@pin689 чтобы написать программу чуть сложнее чем hello world - фреймворк и не нужен, а не любой фреймворк - говно. Фреймворк относится к стеку знаний, обладая которыми вы можете прийти в проект и быстрее начать работать над задачами. Он уменьшает объем проектных знаний, которые кому-то вам потребуется объяснить и кучу особенностей как там все написано в каждом конкретном проекте, какие библиотеки используются, когда и какие вызывать, костыли и т.п. Фреймворк задает структуру как писать, где писать: компоненты так и там, вьюхи там, контроллеры там. Т.е. задает частичные ограничения снижая вероятность написания чего-то своего непонятно где и как попало. И чем больше свободы действий, тем больше увеличиваете объем проектных знаний, которые будут накапливаться. Они вам вряд ли пригодятся в другом проекте, а человек, который прийдет из вне будет 3 месяца изучать всю кухню структуры проекта. Там и без этого хватит бизнес логики в которую придется вникать, добавлять сюде еще самописные костыли со структурой, которая будет только в этом проекте - заведомо усложнять жизнь другим и себе в будущем при разрастании проекта. Обладая знаниями фреймворка вы уже придя в проект понимаете, чем будете пользоваться и как. Вам эту огромную часть не нужно уже объяснять, чтобы вы начали писать код. Как-то так приблизительно.

кстати, отличная идея запилить серию видосов с вариантами неочевидных выстрелов в ногу - "как неожиданно зафейлить {something}"

Что за рейтинг роликов? Где его посмотреть?

@@expollux да просто посмотри, какой у ролика % лайков по отношению к количеству просмотров. На сейчас 821 лайк к 7600 просмотров - примерно 11%. Это очень много.

Спасибооо!

Всем полезно, кто незнаком сильно с предметом обсуждения

Мне хватает, нормально, но это дело привычки/вкуса

Это pyright lsp server. Сделаю материал по настройке

@@t0digital Очень ждём)

Спасибо!

Если уверены, что никто нигде не забудет обернуть нужный функционал в транзакцию - то да, это будет работать более эффективно, но с бОльшим риском однажды получить неконсистентные данные в БД.

@@t0digital Так у Вас та же проблема. Все будет работать если все будут помнить что ошибки ловить нельзя. В чем разница?

@@ihorkovryhin1767 ничего нигде не делать легче, чем везде делать, не находите? Взять правило не обрабатывать ошибки, которые должны улететь клиенту - легче, чем везде реализовывать транзакции

@@t0digital Обрабатываем ошибки в проекте мы довольно часто и с учетом, что работа с базой может быть в глубине различных вызовов понять, что мы обработали ошибку которую не нужно было обрабатывать весьма не тривиальная вещь. Я не говорю что одно решение лучше другого, просто хотел обратить внимание на то, что не все так однозначно хорошо. Явное лучше чем не явное. Атомарные запросы хороши для простых проектов, но чем сложнее наша система, тем больше подводных камней будет вылазить. Когда система разрастется до того уровня, что пора бы уже контролировать транзакции и не делать их длинною в жизнь, то добавить транзакции будет весьма не тривиальной задачей.

@@ihorkovryhin1767 ну куча запросов к бд в 1 http запросе это все равно плохо, даже не применительно к транзакциям, и куча долгих запросов к БД в рамках 1 хттп запроса это тоже плохо - стартовать транзакции на все запросы это особенно плохо, когда БД запросов много в каждом http запросе и они долгие, база начнет вешать всё

Спасибо! Да, я хочу ещё донастроить и потом сделаю материал по настройке, сейчас линтер ругается в одном месте, где нет ошибок, хочу выяснить почему и как пофиксить

@@t0digital Я правильно заметил, что это neovim а не vim enhanced?

@@ashotvantsyan9028 nvim, yes

Вероятность, что кто-то забудет обернуть что-то в транзакцию - имхо сильно выше. А что до "явное лучше неявного" - почему бы тогда не разбирать пришедший хттп запрос вручную, а то что это его кто-то неявно разбирает за нас, непорядочек:) собирать хттп ответ тоже самим, заголовки проставлять. Джангу в топку, у нее там под капотом стооолько неявного :)

документацию нормальную пишите к проекту и все будет ок

Блин, спасибо!! Не понимали, почему у нас на проекте периодически что-то падало

Технически можно вернуть что угодно, конечно. 500ка это означает неожиданную ошибку сервера, если обрабатываемый сценарий именно такой, значит, стоит вернуть 500ку. Но фронтенд может ожидать всегда 200 или как-то не так обрабатывать 500ку, как вам нужно, такое тоже бывает, зависит и от фронтенда

@@t0digital Понял, спасибо Вам )

Привет! Спецы БД, ETL и тп зарабатывают нормально. Oracle, большие корпорации, нормально, если это ваше:) А вот если чувствуете, что это не ваше (неуютно себя чувствуете в корпорации или таких проектах для enterprise бизнеса), то можно подумать о переходе. Надо заниматься тем, что драйвит. Если текущее драйвит - отлично, если нет - ищите, что будет драйвить.

Великоват для водки:)!

@@t0digital возможно размер стакана пропорционален количеству проблем с проектом)))

Ан нет, мы досягаемо круты:)))

не стоит. Но читать FastAPI уже пора:)

@@t0digital спасибо! да, FastAPI - хорош, хотя я его пока нигде не практиковал. Я беспокоюсь, потому что пока учусь и реального опыта тоже

джанго более распространен сейчас и в ближайшем будущем, начинать веб разработку в питоне в любом случае придется с него