⚡️Осталось три дня! Напоминаем, что сейчас действуют скидки на ВСЕ мини-курсы Devman!

Успейте приобрести мини-курс со скидкой 25%!

⚡️Выбирайте мини-курсы здесь или задавайте вопросы нам в Telegram!

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

import argparse
import os
import httpx
from dotenv import load_dotenv
import json

EARTH_RADIUS_KM = 6378

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

💡Согласно рекомендациям PEP8, импорты стоит разделять на 3 группы. И записывать каждую в отдельных блоках:
— стандартные библиотеки,
— сторонние библиотеки,
— локальные модули.

Кроме того, внутри каждой группы рекомендуется располагать импорты в алфавитном порядке и разделять пустой строкой импорты целиком и отдельных элементов.

✅Правильное расположение импортов будет таким:

import argparse
import json
import os

import httpx

from dotenv import load_dotenv

#оформление_python

Асинхронность vs многопоточность в FastAPI: как не убить производительность

Все, кто хоть немного слышал про FastAPI, вероятно, знают, что он асинхронный. Но в приложениях, написанных с помощью этого фреймворка, можно использовать и синхронные библиотеки. При этом неопытный разработчик может поломать асинхронность кода и таким образом лишиться его преимуществ для проекта.

Представьте: ваш сервис отлично работает при нагрузке в 100 RPS, но когда приходит 1000 запросов в секунду — всё начинает сыпаться. Сервер захлёбывается, время ответа растёт, а клиенты получают ошибки 503 Service Unavailable. Вы добавляете больше CPU и памяти, но проблема не исчезает. В чём же дело?

Проблема синхронных функций в асинхронном подходе

from fastapi import FastAPI
import time  # Синхронная библиотека!


app = FastAPI()


@app.get("/blocking-endpoint")
async def blocking_endpoint():
    """Этот endpoint заблокирует весь event loop на 5 секунд!"""
    time.sleep(5)  # Синхронная блокирующая операция
    return {"message": "Запрос выполнен"}

— Когда вы вызываете time.sleep(5) внутри async def, весь асинхронный event loop приостанавливается. event loop — это механизм для управления асинхронными операциями. Он позволяет обрабатывать задачи, не блокируя основной поток выполнения программы.
— Даже если другие пользователи отправляют запросы в это время, они не будут обрабатываться, пока sleep не завершится.

❌ Это сводит на нет все преимущества от написания сложной логики асинхронного кода

👉 Если вы разрабатываете программный продукт на FastAPI и плохо разбираетесь в асинхронщине — используйте встроенный механизм многопоточности.

👉Собрали список популярных синхронных библиотек.

Встроенная многопоточность

FastAPI по умолчанию заботится о производительности при использовании синхронных (блокирующих) операций. Вместо того чтобы тормозить весь сервер, он автоматически выносит такие задачи в фоновые потоки.

Если вы объявляете endpoint*, как обычную функцию (def):
— FastAPI Определяет, что функция синхронная.
— FastAPI запускает функцию в ThreadPoolExecutor — пуле потоков.
— Пока функция выполняется, основной поток (event loop) продолжает работать и обрабатывать другие запросы.

*Endpoint — это конечная точка в API, к которой можно обратиться для выполнения нужного действия или получения данных. Например, на сайте Девмана есть эндпойнт /modules.

from fastapi import FastAPI
import time


app = FastAPI()


@app.get("/sync-route")  # ← Обычная синхронная функция!
def sync_endpoint():
    time.sleep(5)  # Блокирующая операция
    return {"message": "Это выполнится в отдельном потоке!"}

❗️В Python потоки выполняются не одновременно, а с переключениями. Но для I/O-операций (ожидание БД, сетевых запросов) этого достаточно — пока один поток ждет ответа, другой может работать. Если таких запросов будет слишком много, пул потоков переполнится.

❗️ Важно помнить, что Fast API создает потоки автоматически только для синхронных endpoint-функций:
— Если синхронный код вызывается внутри зависимостей, фоновых задач, middleware, а также при обработке WebSocket автоматическое распределение по потокам не работает.
— Встроенная многопоточность не работает в async def endpoints при работе с синхронными библиотеками. Например, requests.get(), pandas.read_csv() или psycopg2 требуют ручного выноса в потоки при вызовах из асинхронных обработчиков.

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

👉 Если вы плохо понимаете механизмы asyncio, а ваш pet-проект не предполагает высокой нагрузки (более 20 запросов одновременно) — можно положиться на встроенный механизм распределения по потокам.

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

🌟 Код-ревью — это проверка кода, написанного разработчиком для решения задачи, перед вливанием в основную ветку проекта.

✅Почему это полезно?

👉 Прокачивает навыки — вы учитесь на реальных примерах, а не на своих ошибках.

👉 Ускоряет рост — без код-ревью можно годами оставаться на одном уровне.

👉 Заставляет анализировать свой опыт. Если вы сами делаете код-ревью и объясняете, почему предложенное вами решение будет лучше.


Разбираем пользу код-ревью в нашей статье. Читайте и делитесь впечатлениями в комментариях!

Кофеин, стресс и бесконечные митинги: жизнь настоящего проджекта

🌟Проджект менеджер — самый странный человек в вашей команде. Про профессию менеджеров проектов ходят легенды и регулярно появляются мемы. Сегодня попробуем разобраться, кто это и почему к ним такое неоднозначное отношение.

Важно, что менеджеров в IT, около IT и вообще, много. Сегодня мы говорим именно про менеджеров проектов, не про продуктовых, операционных, аккаунт, бренд или каких-то ещё. Если будет интересно, в следующих постах поговорим и о других.

Сегодня Артем Каменев, ПМ с опытом 5+ лет поделится с нами своим опытом. Начнём сразу с самого больного вопроса.

❓Почему программисты ненавидят PM-ов?
Чаще всего, потому что не знают или не понимают, для чего они нужны.

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

❓Что делает PM?
✏️Следит за соблюдением планов и договоренностей;
✏️Отчитывается перед руководством компании о расходах и сроках проекта;
✏️Демонстрирует прогресс для заказчиков, неважно внешние они или внутренние;
✏️Собирает обратную связь по проекту со всех заинтересованных.

❓Как он это делает?
✏️Ведёт задачи в таск-трекере и следит за тем, чтобы другие вели их правильно;
✏️Проводит регулярные и точечные встречи с командой и заказчиком;
✏️Отслеживает трудозатраты и расходы по проекту;
✏️Заполняет отчёты и ведёт статусные страницы в вики-подобном формате;
✏️Переписывается. Постоянно и без остановок.

❓Какие бывают подходы к управлению проектами?

Подходов и фреймворков для ведения проектов много. Однако, их можно разделить на 3 категории:

👉 Каскадный (waterfall) подход. В IT чаще всего встречается в небольших проектах (1-3 месяца) и при работе с гос. организациями.

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

Каскадный подход многие считают устаревшим и неработающим, потому что тяжело предсказать всё при разработке. Тем не менее, иногда это нужно или, всё таки, возможно. Например, при работе над устоявшимся продуктом, типовым проектом или с гос. организациями.

👉Гибкий (AGILE) подход — встречается повсеместно и постоянно, т.к. гибкость понятие очень широкое :)

В отличии от каскадного подхода, гибкий не требует всё знать заранее и быть уверенным в каждом дне. В зависимости от компании, команды, конкретного фреймворка может быть установлен общий дедлайн на проект, конкретные его блоки или задачи. Но не всегда.

Гибкий подход универсален и разнообразен, в неопытных или ленивых руках может привести к хаосу. Тем не менее, он лучше всего подходит в условиях, когда нет чёткого ТЗ или требования меняются слишком часто.

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

👉 Гибридный подход — берём лучшее из каскадного и гибкого подходов, смешиваем и наслаждаемся.

На самом деле именно в гибридном подходе работает большинство компаний и команд. Либо говорят, что работают гибко, но на самом деле используют вместе с этим жёсткие сроки, бюджетирование и прочие атрибуты каскадного подхода.

Именно этот формат работы лучше всего подходит аутсорс командам. Когда требование «сделайте красиво», но бюджет «100 тысяч и не копейкой больше».

Коротко описать гибридный подход можно словосочетанием — управляемый хаос. По факту именно из-за необходимости управлять хаосом и растёт количество менеджеров разного формата.

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

➡️ Какой у вас опыт работы с ПМ-ами? Кто был наихудший, а кто наилучший и почему? И присылайте ваши любимые мемы про проджектов в комменты!

Чем UV лучше pip

❓Что такое UV

UV — это современный инструмент управления зависимостями и сборки Python-проектов. Он предоставляет удобный способ работы с зависимостями, используя стандартный файл pyproject.toml, и обеспечивает более строгий контроль версий, что делает проекты более предсказуемыми и стабильными.

👉Альтернативы
– Pip
– Poetry

✅Почему стоит выбрать UV
— Удобство. UV использует единый файл pyproject.toml для управления зависимостями и конфигурации проекта.
— Совместимость. UV поддерживает PEP 517 и PEP 518, что делает его совместимым с большинством современных инструментов Python.
— Быстрота. UV оптимизирован для быстрого разрешения зависимостей.
— Безопасность. UV предоставляет возможность блокировки зависимостей, что предотвращает неожиданные изменения в версиях библиотек.
— Функциональность. UV предоставляет возможность управления версиями Python в системе, а также автоматическое управление виртуальными окружениями.
— Универсальность. UV имеет одинаковый интерфейс для работы на различных системах, что позволяет одинаково использовать на Windows, MacOS и Linux.

❌ Какие минусы есть у UV
— Новая экосистема. Для пользователей, привыкших к pip, потребуется время на изучение UV.
— Ограниченная поддержка старых проектов. Некоторые старые проекты могут не поддерживать pyproject.toml.
— Меньшая популярность. UV пока менее распространён, чем pip, что может затруднить поиск решений для специфических проблем.

🛠 Установка uv
Актуальные способы установки UV в вашу систему можно найти в официальной документации.

🔧 Интеграция UV в уже существующий проект
Для интеграции UV в проект есть два пути:
📎 Полный переход на UV
📎 Переход на UV с использованием совместимого интерфейса pip

Подробно об интеграции UV рассказали 👉 здесь

Наш преподаватель и Senior QA Tools инженер Артем поделился своим опытом использования UV:

Ребята из команды Astral решили серьёзно заняться экосистемой Python и запилили тулу, которая призвана заменить pip. Тула написана на Rust, придерживается всех PEP'ов и резолвит зависимости в 10-50 раз быстрее pip.

Т.к. в последнее время я много занимаюсь разработкой новых инструментов для команды, кол-во репозиториев в моей работе растёт. Мне нужны быстрые и удобные тулы для управления проектами. И UV в этом направлении превзошёл все мои ожидания.

Скорость резолвинга и установки зависимостей действительно выросла в несколько раз. Я, конечно, не замерял в 10 или в 50 раз быстрее, но скорость заметно выросла.

Работа с виртуальными окружениями и версиями Python порадовала не меньше. Версии Python можно менять на ходу, о виртуальном окружении практически не нужно думать. Когнитивная нагрузка при работе с окружением упала до нуля.

⚡️Вывод: Сегодня pip в Python-сообществе — стандарт, и его популярность отражает широкое использование Python во многих областях, таких как анализ данных, машинное обучение, веб-разработка и многое другое.

Его популярность обусловлена тем, что он — ключевой инструмент для установки и управления пакетами Python. Но появляются новые удобные менеджеры пакетов, которые превосходят pip по скорости и функционалу.

💥На майских праздниках мы провели интенсив по проектированию баз данных!

🔥 Было жарко! На интенсиве каждый из участников общался индивидуально с Евгением. Обсудили:
— как спроектировать БД, чтобы не переделывать 100500 раз,
— как учесть не только текущие требования, но и точки расширения,
— рассмотрели кейсы, чему не место в базе.

Делимся отзывами участников об интенсиве:

Интенсив понравился, Евгений все объяснял доходчиво, формат зашел. Рекомендовал бы тем, кто уже делает проекты на Django, но кому не хватает опыта проектирования более серьезных баз данных.

Я прошла интенсив по проектированию баз данных у Евгения Евсеева. Мой уровень — завершила модуль «От джуна до мидла», впереди стажировка.

Я вообще ни секунды не сомневалась, что это мне нужно. Мне понравилось, что на интенсиве была реальная задача из жизни, правда немного упрощенная. А мне как раз и хотелось посмотреть на реальные задачи.

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

Конечно мне еще учиться и учиться. При проектировании баз данных не достаточно просто знать и понимать какие бывают связи между таблицами, нужно что-то еще. Это как при игре в шахматы не достаточно знать, как ходят и бьют фигуры, нужно что-то еще. И этому нужно учиться. И учиться нужно на практике и у профессионалов. Спасибо Евгению за интенсив и за эту предоставленную возможность.

Интенсив оказался интересным и полезным, хоть и немного не таким, как я представлял. Посоветовал бы, сделать более четкую структуру подачи материала и больше проработать задания, чтобы они были менее «импровизационными». Хотя формат «Заказчик, как в жизни» все равно получился интересным!

Объяснения Евгения были понятными и по делу, получил ответы на все вопросы, которые возникали во время прохождения. В целом — опыт полезный и интенсив понравился, но есть куда расти!

На интенсиве было очень много полезной для меня ключевой экспертной информации, которую очень сложно, а может и невозможно, найти в свободном доступе. Спасибо Евгению за понятное, доступное объяснение, без потери глубины!

На мой взгляд интенсив был полезен, даже не столько информацией о разработке баз данных, сколько ценными сведениями про наведение порядка в бизнес процессах и их структурирование.

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

Интенсив мне понравился! Подача материала была четкой и доступной, а объяснения Евгения — понятными и по делу. Понравился формат созвонов — можно было задать вопросы и подробно все обсудить. Еще хочу отметить суперское вовлечение преподавателя! Я получил ответы на все свои вопросы, которые возникали в процессе.

С ТЗ сначала было сложно работать, но с каждым созвоном оно становилось легче в понимании и представлении конечного результата.

Единственное, что хотелось бы улучшить — это количество встреч для обсуждения вопросов и увеличить длительность самого интенсива.

В целом, очень интересный опыт, считаю, что он будет очень полезен в работе!

💙Спасибо участникам, что были с нами эти дни. Ваша энергия и желание развиваться вдохновляют! Очень надеемся, что новые знания и навыки будут полезны в вашей работе!

✅ Обратную связь и пожелания по новому формату учтем при запуске следующих групп!

🔥А еще скоро мы начнем делиться инсайтами с интенсива! Не пропустите!

Собеседование — важный этап поиска работы мечты. К нему можно и нужно готовиться. Благодаря подготовке, у вас будут не только готовые ответы на типовые вопросы, но и меньше волнения!

Сегодня разберем один из вопросов, который часто задают работодатели на собеседованиях веб-разработчиков на Python!

❓Что происходит под капотом джойна? Какие есть алгоритмы соединения таблиц?

В реляционных базах данных, таких как SQL, операцию соединения (join) используют для объединения строк из двух или более таблиц, основываясь на связанных между
ними столбцах. Есть разные типы алгоритмов соединения, каждый из которых имеет свои преимуществ и подходит для разных сценариев.

Разберем основные типы:

📎Nested Loops Join (Циклическое соединение)

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

⚙️Когда использовать: Эффективен, когда одна из таблиц значительно меньше другой. Обычно применяют, когда нет индексов, которые можно использовать для
оптимизации запроса.

❌ Недостатки: Может быть медленным, особенно если обе таблицы большие, так как требует многократного перебора строк.

📎Hash Join (Хеш-соединение)

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

⚙️Когда использовать: Хорошо подходит для больших таблиц, особенно когда соединение не может быть оптимизировано с помощью индексов. Эффективен для соединений типа equi-join (способ объединения данных из двух таблиц по равенству значений в указанных столбцах).

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

📎 Merge Join (Слияние)

👉 Как работает: Сначала сортирует обе таблицы по столбцам соединения, а затем итеративно проходит через обе таблицы одновременно для поиска совпадений.

⚙️Когда использовать: Особенно эффективен, если обе таблицы уже отсортированы по соответствующим столбцам. Часто используется для соединений с диапазоном условий.

❌ Недостатки: Может быть медленным, если таблицы не отсортированы, так как требует предварительной сортировки.

🌟 Выбор наиболее подходящего алгоритма соединения зависит от множества факторов:
— размера таблиц,
— наличия индексов,
— условий соединения,
— доступной системной памяти.

Современные системы управления базами данных (СУБД) часто автоматически выбирают оптимальный метод соединения на основе этих факторов.

👉Пишите вопросы с собеседований, которые хотели бы разобрать, в комментариях!

#вопросы_с_собесов

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

capitals = ('Москва', 'Лондон', 'Париж')

for i in capitals:
  ...

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

Вместо абстрактной буквы i удобнее работать с конкретным, именованным объектом. Название должно быть содержательным, должно соответствовать объекту, описывать его.

❌Использование абстрактных символов и букв в программировании — плохая практика и вот почему:

— Снижается читаемость
Когда голова забита кодом, вы вскоре уже сами не вспомните, что значит i (особенно, если таких букв не одна). Придется тратить время на расшифровку. Другие разработчики, особенно джуны, будут дольше разбираться в вашем коде.

— Затрудняется поиск нужной переменной
При поиске i вы получите десятки, а может и сотни ненужных результатов.

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

✅ Переменную в нашем примере стоит назвать так:

capitals = ('Москва', 'Лондон', 'Париж')

for capital in capitals:
  ...