Очень легко заходит этот курс после прохождения первых двух! С синей обложкой я помучался. Очень долго его проходил, иногда на то чтобы понять и вникнуть в суть одного видео у меня уходило 3-4 дня. Может потому что мне 49 годиков?)))Но я не двигался дальше пока на 100% не усваивал урок. Зато теперь просто кайф) p.s. Огромное спасибо тебе Серега за этот канал!!! И Руслану из клуба Дедов программистов за мотивацию!!!
Спасибо за отзыв! На самом деле очень полезный. Сейчас как раз над новым курсом-интенсивном работаю и очень хотелось бы знать с какой скоростью его проходят. Вчера как раз созвонился с Русланом и рассказал ему про этот твой комментарий)
@@SeniorPomidorDeveloper У меня есть небольшая мебельная фабрика и есть одна идея, которая мне спать не дает)) До того, как наткнулся на его канал у меня и в мыслях не было, что эту идею я сам смогу реализовать на практике!!! Он меня вдохновил!!! В школе на олимпиадах по информатике бывал, но это 30 лет назад было)) И вот сейчас я уверен, что у меня все получится! Еще раз низкий вам поклон!!! И с нетерпением жду новый курс!!!!
Очень полезные видео и на удивление нигде таокго не найти, спасибо за контент. Странно что так мало зрителей как по мне заслуживаешь больше. Привет из Украины
Вроде идея курса хорошая, но много мелких нюансов которые прям цепляют глаз, типа того что не нужно копировать файлы в контейнер до установки зависимостей, или что можно делать префетч сразу через две таблицы и подтянуться обе не нужно для каждой таблицы отдельный префетч. Ну и главная проблема - используйте black, смотреть больно как вы код форматируете)
для изменения структуры ответа для листа лучше использовать кастомный pagination класс, ну и для отдельных сущностей все это лучше делать через сериализатор, потому что от этого зависит как будет формироваться сваггер
в общем понимаю, что курс скорее всего записан, но если будете делать еще что-то подобное и понадобится взгляд со стороны - обращайтесь - могу поревьюить, высказать свои пожелания =)
Курс вцелом немного про другое. Если каждое решение «полировать» то видео получались бы раза в два дольше. Я тоже сторонник того чтобы все выглядело чистенько и красиво. На работе обычно не жалею времени на такое. Но в какой-то момент я понял , что приоритеты должны быть в другом. Любой разработчик понимает и MethodField и CharField , любой понимает и синтаксис prefetch с двумя таблицами или если два по одной. Вложеность запроса будет понятна и через pagination (что конечно более красиво) и через костылек. То есть все эти вещи они и читаются легко и по скорости отрабатывают абсолютно также. Разница только в эстетическом восприятии. А если разработчик забудет поставить префетч, забудет подебажить SQL, забудет вынести расчеты в асинхронный воркер, забудет закешировать значение, там где это легко сделать. Вот тут начинаются настоящие проблемы при нагрузке. В этом курсе акцент я делаю на этом, на оптимизации. А вообще все ваши замечания принимаю и со всеми согласен.
Хочу задать вопрос. Зачем мы взваливаем вычисление "total_amount" на базу данных? Ведь у нас уже есть на руках price для всех обьектов в переменной queryset, и мы этот total_amount можем посчитать в python, не делая доп.запрос в базу данных?
Про это я говорю на 23:50 Ну и также важно понять, что в переменной queryset нет ничего. Она lazy и пока мы к ней не обратились, запросов она не производит. Часто поверх ложится еще и пагинация. А total_amount будет нормально работать по любому кол-ву данных. Хоть 1000 хоть 100.000. Но если мы хотим именно выбрать оптимальный способ (к примеру замерить скорость первого и второго варианта) то в зависимости от кол-ва записей быстрее может стать первый или второй. Я предпочитаю такие штуки сразу через aggregate делать, пока данных мало оба варианта будут работать моментально
@@SeniorPomidorDeveloper про queryset я понял. А вот про вычисление в базе данных нет. Почему в БД это вычисление идёт быстрее. Разве там не нужно пробежаться по всем price в таблице и сложить их, а затем выдать одно число?
@user-kn5ip9lr6r не могу описать точно как это делает база. Но это функция движка базы , которая специально для этих агрегаций и предназначена. Это точно не перебор из select-ов со сложением , она работает быстро и на больших кол-вах данных.
Отличный урок! Подскажите, почему мы в функции list берём queryset = self.filter_queryset(self.get_queryset()) Почему не queryset = self.get_queryset() Зачем нужен .filter_queryset?
Спасибо за знания которыми так щедро делишься с нами
Сеньор Помидор! Я не знаю, как выразить свою благодарность за то, что вы делаете!
Очень легко заходит этот курс после прохождения первых двух! С синей обложкой я помучался. Очень долго его проходил, иногда на то чтобы понять и вникнуть в суть одного видео у меня уходило 3-4 дня. Может потому что мне 49 годиков?)))Но я не двигался дальше пока на 100% не усваивал урок. Зато теперь просто кайф)
p.s. Огромное спасибо тебе Серега за этот канал!!! И Руслану из клуба Дедов программистов за мотивацию!!!
Спасибо за отзыв! На самом деле очень полезный. Сейчас как раз над новым курсом-интенсивном работаю и очень хотелось бы знать с какой скоростью его проходят.
Вчера как раз созвонился с Русланом и рассказал ему про этот твой комментарий)
@@SeniorPomidorDeveloper У меня есть небольшая мебельная фабрика и есть одна идея, которая мне спать не дает)) До того, как наткнулся на его канал у меня и в мыслях не было, что эту идею я сам смогу реализовать на практике!!! Он меня вдохновил!!! В школе на олимпиадах по информатике бывал, но это 30 лет назад было)) И вот сейчас я уверен, что у меня все получится! Еще раз низкий вам поклон!!! И с нетерпением жду новый курс!!!!
@BELLA_VESTA вам спасибо что смотрели!
Все очень доступно объяснил, спасибо! 👍🏻
Спасибо за труд!
Спасибо! Как всегда все супер!
Очень полезные видео и на удивление нигде таокго не найти, спасибо за контент.
Странно что так мало зрителей как по мне заслуживаешь больше.
Привет из Украины
Привет! Спасибо за отзыв)
Вроде идея курса хорошая, но много мелких нюансов которые прям цепляют глаз, типа того что не нужно копировать файлы в контейнер до установки зависимостей, или что можно делать префетч сразу через две таблицы и подтянуться обе не нужно для каждой таблицы отдельный префетч. Ну и главная проблема - используйте black, смотреть больно как вы код форматируете)
не нужен там сериалайзер метод филд после аннотации, можно просто указать тип данных, в поле и сериализатор сам его подхватит
для изменения структуры ответа для листа лучше использовать кастомный pagination класс, ну и для отдельных сущностей все это лучше делать через сериализатор, потому что от этого зависит как будет формироваться сваггер
в общем понимаю, что курс скорее всего записан, но если будете делать еще что-то подобное и понадобится взгляд со стороны - обращайтесь - могу поревьюить, высказать свои пожелания =)
Вот это грамотные замечания, но курс все равно хороший
Курс вцелом немного про другое. Если каждое решение «полировать» то видео получались бы раза в два дольше.
Я тоже сторонник того чтобы все выглядело чистенько и красиво. На работе обычно не жалею времени на такое.
Но в какой-то момент я понял , что приоритеты должны быть в другом. Любой разработчик понимает и MethodField и CharField , любой понимает и синтаксис prefetch с двумя таблицами или если два по одной. Вложеность запроса будет понятна и через pagination (что конечно более красиво) и через костылек.
То есть все эти вещи они и читаются легко и по скорости отрабатывают абсолютно также. Разница только в эстетическом восприятии. А если разработчик забудет поставить префетч, забудет подебажить SQL, забудет вынести расчеты в асинхронный воркер, забудет закешировать значение, там где это легко сделать. Вот тут начинаются настоящие проблемы при нагрузке. В этом курсе акцент я делаю на этом, на оптимизации.
А вообще все ваши замечания принимаю и со всеми согласен.
спасибо!
Супер
Хочу задать вопрос. Зачем мы взваливаем вычисление "total_amount" на базу данных? Ведь у нас уже есть на руках price для всех обьектов в переменной queryset, и мы этот total_amount можем посчитать в python, не делая доп.запрос в базу данных?
Про это я говорю на 23:50
Ну и также важно понять, что в переменной queryset нет ничего. Она lazy и пока мы к ней не обратились, запросов она не производит. Часто поверх ложится еще и пагинация. А total_amount будет нормально работать по любому кол-ву данных. Хоть 1000 хоть 100.000.
Но если мы хотим именно выбрать оптимальный способ (к примеру замерить скорость первого и второго варианта) то в зависимости от кол-ва записей быстрее может стать первый или второй. Я предпочитаю такие штуки сразу через aggregate делать, пока данных мало оба варианта будут работать моментально
@@SeniorPomidorDeveloper про queryset я понял. А вот про вычисление в базе данных нет. Почему в БД это вычисление идёт быстрее. Разве там не нужно пробежаться по всем price в таблице и сложить их, а затем выдать одно число?
@user-kn5ip9lr6r не могу описать точно как это делает база. Но это функция движка базы , которая специально для этих агрегаций и предназначена. Это точно не перебор из select-ов со сложением , она работает быстро и на больших кол-вах данных.
@@SeniorPomidorDeveloper спасибо большое. Узнаю много нового
Отличный урок!
Подскажите, почему мы в функции list берём queryset = self.filter_queryset(self.get_queryset())
Почему не queryset = self.get_queryset()
Зачем нужен .filter_queryset?
чтобы когда мы передаем фильтр в API запросе, он отработал. это просто копипаст из основного list(), лучше это не менять, если не уверен что он делает
@@SeniorPomidorDeveloper большие спасибо! Вы лучший! :)
Просмотров 1,2к а лайков 97 - это неуважение!
Да стандартно 7%-10%
А вообще конечно, ставим лайки! )
👍
спасибо!