🎄 Продолжаем наш новогодний Python-интерактив! 🎄

❄️Давайте разберём, какой код работает:

Пример 1:

for symbol in ('Новый год!'):
    print(symbol)

Пример 2:

python    
for symbol in (2026):
    print(symbol)

👉Выбирайте свой вариант ответа в опросе и пишите объяснения в комментариях!

Цикл for пытается перебрать элементы, содержащиеся в (2026). Однако (2026) — это не коллекция элементов, а одно целое число, заключённое в скобки.

В Python для того, чтобы число стало коллекцией, его нужно представить в виде списка, кортежа или другого итерируемого объекта. Из-за этого при попытке выполнить данный код возникнет ошибка TypeError, указывающая на то, что объект типа int (целое число) не является итерируемым.

А вот “Новый Год” — это строка. Строки в Python являются коллекциями и по ним можно итерировать, т.е. проходить в цикле. Элементом станет каждый символ строки.

🤔 Давайте вместе разберемся, что не так с этим кодом?

def predict_rub_salary_hh(hh_vacancy):
    if not hh_vacancy or hh_vacancy.get('currency') != 'RUR':
        return

    salary_from = hh_vacancy.get('from')
    salary_to = hh_vacancy.get('to')

    if not salary_to and salary_from:
        return int(salary_from * 1.2)
    if not salary_from and salary_to:
        return int(salary_to * 0.8) 
    if salary_from and salary_to:
        return int((salary_from + salary_to) / 2)


def predict_rub_salary_sj(sj_vacancy):
    payment_from = sj_vacancy.get('payment_from')
    payment_to = sj_vacancy.get('payment_to')
    currency = sj_vacancy.get('currency')

    if currency != 'rub':
        return

    if not payment_to and payment_from:
        return int(payment_from * 1.2)
    if not payment_from and payment_to:
        return int(payment_to * 0.8) 
    if payment_from and payment_to:
        return int((payment_from + payment_to) / 2)

👉 Чтобы понять, что можно исправить, загляните в типичные улучшения Девмана.

Копипаста кода — это плохо.

1️⃣ Если код нужно будет поменять — придётся искать все места, где он использовался и менять его везде, по всем файлам.

2️⃣ Если в коде будет ошибка — её не получится исправить разом, в одном месте, придётся опять же искать все места, где использовался этот код и чинить его несколько раз.

3️⃣Чем больше кода — тем труднее его читать.

Код из нашего примера может выглядеть так:

def get_expected_salary(salary_from, salary_to):
    if not salary_to and salary_from:
        return int(salary_from * 1.2)
    if not salary_from and salary_to:
        return int(salary_to * 0.8) 
    if salary_from and salary_to:
        return int((salary_from + salary_to) / 2)


def predict_rub_salary_hh(hh_vacancy):
    if not hh_vacancy or hh_vacancy.get('currency') != 'RUR':
        return

    salary_from = hh_vacancy.get('from')
    salary_to = hh_vacancy.get('to')

    return get_expected_salary(salary_from, salary_to)


def predict_rub_salary_sj(sj_vacancy):
    payment_from = sj_vacancy.get('payment_from')
    payment_to = sj_vacancy.get('payment_to')
    currency = sj_vacancy.get('currency')

    if currency.lower() != 'rub':
        return

    return get_expected_salary(payment_from, payment_to)

P.S. Спасибо нашим подписчикам за внимательное ревью!❤️ По ходу избавились от пустых return и elif. Если еще есть идеи как улучшить код — пишите свои варианты в комментариях!

🤔 Давайте вместе разберемся, что не так с этим кодом?

from django.db import models


class Owner(models.Model):
    ...

    def __str__(self):
        return f'{self.name}'

👉 Чтобы понять, что можно исправить, загляните в типичные улучшения Девмана

Бесполезные преобразования типов приводят к усложнению кода, дополнительным вычислениям и ухудшению производительности.

Код из нашего примера может выглядеть так:

from django.db import models


class Owner(models.Model):
    ...

    def __str__(self):
        return self.name

❓Как оптимизировать запросы к БД

«Магия» оптимизации запросов в Django ORM — это один из ключевых навыков для борьбы с перегрузом БД и тормознутостью сайта. Проблемы возникают, если использовать реляционную БД со сложными отношениями между таблицами: ForeignKey, ManyToMany.

📌Пример: запросили из базы список постов. Таблица постов связана с таблицей авторов. Если их не запросить сразу, то на каждый пост придется делать ещё запрос для получения автора. С ростом количества постов это приведет к огромному количеству запросов и перегрузу базы.

✍️Цель и метрики
Изначально хочется минимизировать количество запросов к БД. Но еще есть время обработки запроса на стороне базы данных. Чаще всего время обработки запроса в базе пропорционально количеству запросов, но есть исключения.

✍️Инструменты
В уроках курса по базам данных мы предлагаем использоваться Django Debug Toolbar для замера основных метрик: количество запросов, количество дублей, время обработки запроса на стороне БД, общее время запроса.

✍️Методы Django ORM

➡️`select_related`: один жирный JOIN
select_related использует оператор SQL JOIN (внешнее соединение) чтобы присоединить таблицы связанных объектов по внешнему ключу (ForeignKey или OneToOneField) к основному запросу.

Что происходит:
— Django строит один большой SQL-запрос с JOIN.
— База данных возвращает одну таблицу, где строки дублируются для данных из связанных таблиц. Т.е. если уникальных авторов всего два, то строк в таблице будет столько, сколько постов.
— ORM преобразует эту таблицу в объекты Python, уже связанные между собой.

Когда использовать: Когда вам нужно перемещаться «вперед» по связи — от объекта к связанному (книга -> автор). Идеально для связей «один к одному» и «многие к одному».

# ПЛОХО: N+1 запрос
books = Book.objects.all()
for book in books:
    print(book.author.name)  # Новый запрос к БД на каждой итерации!

# ХОРОШО: 1 запрос
books = Book.objects.select_related('author').all()
for book in books:
    print(book.author.name)  # Данные автора уже загружены!

➡️`prefetch_related`: Умная загрузка комплектами

prefetch_related делает отдельные запросы для каждой связи, а затем уже в памяти Python «сшивает» результаты. Python обычно работает медленнее, но база данных освобождается быстрее.

Что происходит:
— Django выполняет первый запрос для получения основных объектов (например, авторов).
— Затем второй запрос (или несколько) для получения ВСЕХ связанных объектов для этих основных (например, всех книг этих авторов).
— В Python ORM создает словарь-кэш и подставляет нужные связанные объекты к каждому основному. Используется оператор SQL IN.

# ПЛОХО: N+1 запрос
authors = Author.objects.all()
for author in authors:
    for book in author.books.all():  # Новый запрос на каждом внешнем цикле!
        print(book.title)

# ХОРОШО: 2 запроса
authors = Author.objects.prefetch_related('books').all()
for author in authors:
    for book in author.books.all():  # Книги для всех авторов уже загружены в кэш!
        print(book.title)

✍️Исключения

Иногда на глубоких цепочках (select_related('a__b__c')) JOIN может стать слишком тяжелым, и prefetch_related будет эффективнее.

Пример есть в уроке Знакомство с Django: ORM. Помните блог с постами, где нужно было оптимизировать запросы? В уроке были расплывчатые рекомендации, так что мы ещё раз их проверили.

Для метода tag_filter получили статистику на увеличенном вдвое количестве постов в БД с помощью Django Debug Toolbar:

select_related: 31 запрос, SQL ≈ 0.1288s, elapsed ≈ 0.1350s
prefetch_related: 33 запроса, SQL ≈ 0.0922s, elapsed ≈ 0.0980s

При увеличении количества постов результаты сохраняются:
— select_related делает на 1-2 запроса меньше,
— время обработки запроса для prefetch_related на 40% меньше

Итого: prefetch_related — лучший вариант оптимизации.

P.S. Но скажем по секрету, если вы использовали любой из методов — это уже неплохо! Ну а проверить что эффективнее, лишним никогда не будет ;-)

P.P.S. Напоминаем, что у нас открыта запись на курс по БД! Успейте забронировать осталось всего два места!

👉 Для записи напишите нам в Телеграм!

⚠️ Сайт временно не работает. Чиним.

✅ Сайт работает

ИИ-разработка: подходы

Вайбкодинг стал словом нарицательным с очень явным налетом чего-то неработающего и вообще 💩. Но так или иначе применение нейросетей набирает обороты и в умелых руках является преимуществом, а не недостатком. Сейчас речь не про замену stackoverflow, а именно написание кода с помощью LLM.

AI Oriented Development
AI не является самостоятельным разработчиком, а скорее ассистентом. Это умные подсказки в IDE, генерация документации, автотесты, помощь в отладке.

По разным данным эффективность использования составляет от минус 19 % (METR) до плюс 20 % (Google) к производительности разработчика. Причем чем выше квалификация разработчика, тем хуже результат.

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

AI Driven Development (AIDD)
Разработчик, а точнее архитектор ПО (Solution Architect), разрабатывает ТЗ и архитектуру -- ИИ пишет код, верстает, тестирует. Архитектор ревьюит и принимает решение вливать ли код в main или отправляет на доработку.

И тут открывается совершенно новый процесс разработки, когда не надо держать в штате 100500 узких спецов под каждый стек, заказчик быстрее видит результаты и может сделать гораздо больше за тот же бюджет, ИТ компании становятся более гибкими и маневренными. Разве что на сервера пока пускать стрёмно, но через несколько лет и это будет возможно. Причем уже сегодня писать качественный код можно на обычных LLM без обучения и тонкой настройки специализированных нейросетей. Да, не хватает языка и инструментов для работы с требованиями и подготовки контекста с учётом лимитов для ИИ. И да, google задрал блочить российские аккаунты, но будущее уже наступает на пятки!

Осталось разобраться где брать этих самых крутяшек архитекторов в достаточных количествах🤔

⚠️ Сайт временно не доступен. Обновляем кластер.

✅ В 21:24 завершили работы

💥Делимся хорошей новостью! До 7 марта действует кэшбэк на оплату наших курсов картой Т-Банка 15%!

💵Акция действует для тех, кто:
— Оплачивает услуги школы впервые через этот банк;
— Оплачивает услуги не через СБП.

👉Успейте воспользоваться выгодой при оплате наших курсов:
— «Профессия Middle Python/Django разработчик»
— Мини-курсы
— Курс по FastAPI
— Курс «Проектирование баз данных»

Остались вопросы? Напишите нам в Телеграм!

⚡️⚡️Напоминаем, что у нас открыта запись на курс по базам данных!

🔥Что будет в программе курса:


⚡️Декомпозиция и проектирование функций программного продукта
⚡️Описание требований на базе Domain Driven Design
⚡️Проектирование схемы БД.
⚡️Отрисовка схемы БД в draw.io
⚡️Реализация моделей и QuerySet-методов в Django ORM
⚡️ 6 индивидуальных созвонов с Евгением Евсеевым.

📌Чтобы принять участие в интенсиве, нужно:
👉 Иметь опыт работы с Django ORM (знать основные связи между моделями, уметь писать и оптимизировать запросы, в том числе с агрегацией, есть опыт схема- и дата-миграций);
👉 Иметь базовый опыт по работе с Django, уметь настраивать админку

Если вы проходили наши мини-курсы Django ORM и Django до 2 урока включительно, то их достаточно для участия в интенсиве.

Максимальная польза — если управляли проектами или был опыт разработки или доработки схем баз данных.

🌟Что вы получите:
🔥 Уникальную возможность поучаствовать в разработке совместного проекта с Евгением Евсеевым;
🔥 Возможность прокачать навыки в проектировании БД;
🔥 Жесткое ревью кода от Евгения Евсеева;
🔥 Множество инсайтов, кейсов из опыта Евгения и тайных знаний.

🚀Стартовать можно в любой день до конца февраля!

❗️Успейте забронировать! Осталось всего два свободных места!
👉 Для записи на курс напишите нам в Телеграм!