На первый взгляд кнопка «наверх» — задача на пять минут. Добавил position: fixed, обработчик window.scrollTo() — готово.

Но стоит этой кнопке появиться в живом проекте, как выясняется, что она пересекается с cookie-баннером, мешает чату поддержки, выглядит иначе в мобильной версии, не дружит со строгим CSP или пропадает из Django Admin.

В итоге маленькая UI-деталь начинает обрастать условиями. Я решил собрать их в отдельный Django-пакет — django-scroll-to-top

Когда трёх строк JavaScript достаточно

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

Это нормальное решение. Не всегда стоит тянуть пакет ради одной кнопки.

Но в реальном Django-проекте быстро появляются дополнительные вопросы:

• когда именно показывать кнопку: после 300 пикселей, одного экрана или только при прокрутке вверх;
• что делать на коротких страницах;
• как не перекрыть cookie-баннер, чат, toast-уведомления или нижнюю мобильную навигацию;
• как дать пользователю закрыть кнопку;
• как не сломать клавиатурную навигацию и режим reduced motion;
• как сделать отдельное оформление для сайта и Django Admin;
• как не заставлять проект добавлять unsafe-inline в Content Security Policy;
• как позволить редактору или администратору изменить цвет, положение и иконку без нового деплоя.

Именно в этот момент «три строки JavaScript» превращаются в отдельный компонент.

Что я хотел получить

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

1. Подключение сайта одной template-тегом.
2. Отдельная поддержка обычных страниц и стандартного Django Admin.
3. Настройка внешнего вида через админку, а не через постоянную правку CSS.
4. Без jQuery, CDN, фронтенд-фреймворка и обязательной сборки.
5. Безопасная работа при строгой CSP.
6. Прогрессивное улучшение: без JavaScript остаётся обычная ссылка в начало страницы.
7. Возможность жить рядом с другими фиксированными элементами интерфейса.

Пакет в итоге хранит обычные настройки установки в settings.py, а визуальное поведение — в базе данных. Это позволяет менять кнопку через Django Admin, публиковать новую версию настроек и при необходимости откатываться на предыдущую. В проекте есть отдельные профили для публичного сайта и Django Admin, а ревизии могут быть черновыми, опубликованными или архивными.

Быстрое подключение

Базовый сценарий начинается с установки:

В settings.py добавляем приложение. Если нужна поддержка стандартной админки, пакет должен идти раньше django.contrib.admin:

Включаем области, где должна работать кнопка:

Для публичной части добавляем URLConf пакета:

А в общий шаблон сайта — один тег:

На стандартном Django Admin ничего дополнительно вставлять не нужно: пакет использует обычный механизм разрешения шаблонов Django. Если же в проекте переопределён admin/base_site.html тег можно добавить вручную в блок footer

Настройка без превращения админки в редактор CSS

Мне не хотелось хранить в базе шаблоны, произвольный CSS или JavaScript. Это неудобно для сопровождения и создаёт лишнюю поверхность для ошибок.

Поэтому визуальная часть собрана из контролируемых вариантов:

• круг, квадрат, скруглённый квадрат или pill;
• заливка solid, outline, soft, ghost, glass или gradient;
• положение в любом углу экрана;
• отдельные размеры для desktop и mobile;
• светлая и тёмная тема;
• встроенные иконки, иконки от разработчика или загружаемые SVG;
• настройки тени, границы, opacity и focus ring.

Что происходит, когда рядом есть cookie-баннер или чат

Нижний правый угол страницы редко бывает свободен. Там часто живут:

• cookie-баннер;
• компактная кнопка после закрытия баннера;
• чат поддержки;
• кнопка обратного звонка;
• мобильная навигация;
• toast-уведомления.

Пакет умеет рассматривать такие элементы как препятствия. Для этого можно пометить элемент атрибутом:

Дальше для кнопки можно выбрать поведение: игнорировать препятствия, сдвинуться вдоль края, попробовать другой угол или скрыться, если безопасного места не осталось.

Для сложных виджетов есть отдельный адаптер: он может отслеживать появление и исчезновение элементов, например компактного launcher после закрытия cookie-баннера. При этом ни cookie-пакет, ни чат не становятся зависимостями django-scroll-to-top

Доступность — не отдельная галочка в конце

У кнопки есть понятное имя для screen reader, поддержка клавиатуры, видимый focus-visible, минимальный размер области нажатия и режим prefers-reduced-motion.

Если пользователь отключил анимации на уровне системы, плавная прокрутка не будет навязываться. Если JavaScript не загрузился, кнопка остаётся обычной ссылкой на начало документа.

Полный независимый аудит WCAG 2.2 AA и тестирование масштабирования 200% и 400% пока находятся в roadmap, поэтому называть компонент полностью сертифицированным по WCAG было бы неправильно. Но структурные требования — клавиатурная доступность, фокус, reduced motion, forced-colors и безопасная работа без JavaScript — уже заложены в компонент и покрываются тестами.

CSP и загружаемые SVG

В корпоративных проектах часто нельзя просто добавить inline-скрипт и включить unsafe-inline ради одной кнопки.

По умолчанию компонент использует same-origin CSS и JavaScript. Для него подходит политика такого вида:

Настраиваемые цвета и размеры отдаются не через inline-стили, а через версионированный stylesheet endpoint. Это позволяет сохранить простой контракт с одним template-тегом и не ослаблять CSP.

Отдельно пришлось подумать о загружаемых SVG. Админ не рендерит исходный файл как есть: SVG проходит санитарную обработку. Скрипты, обработчики событий, внешние ресурсы, встроенные документы и небезопасные namespace отклоняются. Для загружаемых иконок также хранится информация об авторе, источнике и лицензии.

Ревизии, публикация и откат

Одна из самых полезных вещей в пакете — не сама кнопка, а жизненный цикл её настроек.

Можно создать черновик, посмотреть результат в live preview, опубликовать изменения или вернуться к предыдущей версии. Это особенно удобно, когда кнопку настраивает не разработчик, а контент-менеджер или дизайнер.

У ревизий есть три состояния:

• draft — редактируемый черновик;
• published — текущая активная конфигурация;
• archived — сохранённая версия для отката.

Где пакет уместен, а где нет

django-scroll-to-top имеет смысл, когда кнопка нужна в нескольких проектах, должна работать в Django Admin, настраиваться без деплоя или жить в окружении со строгими требованиями к CSP и интерфейсу.

Для лендинга на одну страницу проще и правильнее написать несколько строк самостоятельно. Это будет быстрее, понятнее и дешевле в сопровождении.

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

Сейчас пакет выпущен как beta-версия 0.2.0, требует Python 3.10+ и поддерживает Django 4.2 LTS, 5.x и 6.0. Лицензия — MIT.

Исходный код, документация и примеры использования доступны в GitHub-репозитории проекта.

Пакет опубликован в PyPI под именем django-scroll-to-top.

Обратная связь, баг-репорты и предложения по интеграции с кастомными Django Admin-темами приветствуются в Issues.

В октябре 2025 года вышел Python 3.14 с экспериментальным JIT-компилятором и поддержкой шаблонных T-строк — язык продолжает ускоряться, не жертвуя простотой. Экосистема тоже не стоит на месте: FastAPI стал стандартом для высокопроизводительных API, а инструменты вроде Ruff и uv радикально ускорили рабочий процесс разработчика. Python Package Index (PyPI) насчитывает более 600 000 пакетов — для любой задачи, скорее всего, уже существует готовое решение.

Этот путеводитель — не энциклопедия и не учебник. Это навигационный хаб: мы кратко разберём каждую важную область Python и дадим ссылки на подробные материалы Tproger, где каждая тема раскрыта в деталях. Неважно, только начинаете вы знакомство с языком или уже пишете на нём продакшен-код — здесь вы найдёте структурированную карту для дальнейшего роста. Мы охватим основы синтаксиса, продвинутые концепции, три главных веб-фреймворка, Data Science, последние нововведения в Python 3.14 и карьерные перспективы.

— Python — язык №1 по TIOBE 2026, более 600 000 пакетов в PyPI

— Основы языка: динамическая типизация, duck typing, встроенные коллекции (list, tuple, dict, set и другие)

— Три главных веб-фреймворка: Django (full-stack), Flask (микро), FastAPI (async API)

— Python 3.14: экспериментальный JIT-компилятор и шаблонные T-строки

— Медианная зарплата middle Python-разработчика: 250 000—350 000 руб./мес.

— Функции: замыкания, LEGB, *args/**kwargs, лямбды

— ООП: классы, наследование, @property, магические методы

— GIL, threading, asyncio и multiprocessing — когда что использовать

— Тестирование с pytest, работа с файлами через pathlib

Основы языка: с чего начинается Python

Python — язык с динамической типизацией и строгим контролем отступов. Если в C++ или Java фигурные скобки определяют блоки кода, то в Python эту роль играют пробелы. Поначалу это непривычно, но на практике делает код единообразным и читаемым — у вас просто нет возможности написать нечитаемую «лапшу». Философия Python описана в «Дзен Python» (PEP 20): «Красивое лучше уродливого», «Явное лучше неявного», «Простое лучше сложного». Эти принципы пронизывают весь язык и его стандартную библиотеку.

Базовые типы данных в Python — это числа (int, float, complex), строки (str), булевы значения (bool), а также коллекции: списки (list), кортежи (tuple), множества (set) и словари (dict). Каждый тип имеет свои особенности. Например, целые числа в Python не ограничены размером: можно спокойно работать с числами в тысячи разрядов без переполнения — попробуйте сделать это в C или Java. Строки неизменяемы, а словари с Python 3.7 гарантированно сохраняют порядок вставки. Множества предоставляют проверку принадлежности элемента за O(1), а операции объединения, пересечения и разности выполняются за линейное время, что делает их незаменимыми для задач на поиск уникальных элементов.

Одна из ключевых концепций — duck typing: «если объект ходит как утка и крякает как утка, то это утка». Python не проверяет тип объекта заранее — он проверяет, поддерживает ли объект нужную операцию. Это даёт гибкость, но требует дисциплины. Современный Python активно использует аннотации типов (type hints), которые помогают IDE и линтерам находить ошибки ещё до запуска кода. Начиная с Python 3.10 появился оператор match/case (паттерн-матчинг), а в 3.12 — улучшенные дженерики и type aliases, которые делают типизацию ещё удобнее.

Переменные в Python — это не ячейки памяти, а метки (имена), привязанные к объектам. Понимание этого механизма — ключ к предсказуемой работе с мутабельными типами вроде списков и словарей. Когда вы пишете a = b для списка, вы не копируете данные — обе переменные указывают на один и тот же объект в памяти. Отсюда классические ловушки с изменяемыми аргументами по умолчанию и «неожиданным» изменением данных. Для создания независимой копии нужно использовать срез [:], метод copy() или модуль copy для глубокого копирования.

Управляющие конструкции в Python минималистичны и выразительны. Условия записываются через if/elif/else, циклы — через for и while. Конструкция for в Python ближе к foreach из других языков: она итерирует по элементам коллекции, а не по индексам. Функция range() генерирует последовательности чисел для случаев, когда нужен числовой цикл. Важно освоить и обработку исключений (try/except/finally) — Python использует исключения не только для ошибок, но и как механизм управления потоком, например StopIteration для завершения итерации.

Подробнее о типах данных и их поведении — в нашем гайде по основным типам данных. А если хотите системно пройти все базовые концепции от установки до первого проекта — загляните в подробное описание языка для начинающих.

Функции в Python

Функции — основной инструмент структурирования кода в Python. Ключевое слово def создаёт функцию, return возвращает результат. Python поддерживает позиционные и именованные аргументы, значения по умолчанию, а также распаковку через *args (кортеж позиционных) и **kwargs (словарь именованных). Это позволяет создавать гибкие интерфейсы: от простых утилит до сложных API-обёрток.

Анонимные функции lambda удобны для коротких выражений — например, в качестве ключа сортировки: sorted(users, key=lambda u: u.age). Однако злоупотреблять ими не стоит: если лямбда не помещается в одну строку, лучше написать обычную функцию с понятным именем.

Python использует правило LEGB для поиска переменных: Local → Enclosing → Global → Built-in. Это объясняет, почему переменная внутри функции «затеняет» глобальную, и почему для изменения глобальной переменной нужно объявление global. Замыкания (closures) — функции, захватывающие переменные из объемлющей области видимости — лежат в основе декораторов, фабричных функций и callback-паттернов.

Функции в Python — объекты первого класса: их можно передавать как аргументы, возвращать из других функций и сохранять в структурах данных. Это фундамент для функционального стиля программирования, который активно используется вместе с map(), filter() и functools.

ООП в Python

Python — мультипарадигменный язык, но ООП в нём реализовано глубоко и последовательно. Классы создаются ключевым словом class, конструктор определяется методом __init__, а первый параметр каждого метода — self, ссылка на текущий экземпляр. В отличие от Java или C#, где this подразумевается неявно, Python требует явного указания — это осознанный выбор в пользу читаемости.

Python поддерживает множественное наследование через механизм MRO (Method Resolution Order) — алгоритм C3-линеаризации определяет порядок обхода родительских классов. Полиморфизм реализуется через duck typing: нет необходимости в интерфейсах — достаточно, чтобы объект имел нужные методы. Для формальных контрактов есть модуль abc с абстрактными базовыми классами и декоратором @abstractmethod.

Инкапсуляция в Python — скорее соглашение, чем принуждение. Префикс _ обозначает «приватный» атрибут, __ — активирует механизм name mangling, но ни то ни другое не запрещает доступ. Для контролируемого доступа к атрибутам используют декоратор @property, который превращает метод в вычисляемое свойство с геттером, сеттером и делетером.

Магические методы (dunder-методы) — мощный механизм, позволяющий объектам вести себя как встроенные типы. __str__ и __repr__ управляют строковым представлением, __eq__ и __hash__ — сравнением, __len__ и __getitem__ — доступом к элементам. Подробный разбор синтаксиса и концепций Python — в нашем подробном описании языка для начинающих.

Модули и пакеты Python

Модульная система Python проста: любой .py-файл — это модуль, а директория с __init__.py — пакет. Импорт осуществляется через import и from ... import. Python ищет модули по путям из sys.path, куда автоматически входят текущая директория, стандартная библиотека и директория site-packages с установленными пакетами.

Для управления зависимостями экосистема предлагает несколько инструментов. Классический pip + venv решает базовые задачи: создание изолированного окружения и установка пакетов из PyPI. Poetry добавляет управление зависимостями через pyproject.toml, lock-файлы и публикацию пакетов. Новый uv — написанный на Rust менеджер пакетов — работает в 10—100 раз быстрее pip и активно набирает популярность.

Стандартная библиотека Python (batteries included) — одна из самых богатых: от работы с сетью (http, socket) до сериализации (json, pickle), регулярных выражений (re) и параллелизма (threading, multiprocessing). Полный список из более чем 200 модулей доступен в нашей подборке полезных Python-библиотек.

Практика: задачи для начинающих

Главная ошибка при изучении программирования — читать теорию неделями, не написав ни строчки кода. Python хорош тем, что позволяет начать практиковаться с первого дня: интерактивный интерпретатор (REPL), быстрая обратная связь и понятные сообщения об ошибках снижают барьер входа до минимума. Откройте терминал, напишите python3 — и вы уже можете экспериментировать.

Начинайте с простых задач: обработка строк, работа со списками, базовые циклы и условия. Затем переходите к задачам на функции, рекурсию и работу с файлами. Важно не просто решать задачу, а разбирать чужие решения — так вы быстрее освоите идиоматический Python. Один грамотно решённый пример научит вас большему, чем десять страниц документации. Обращайте внимание на то, как опытные разработчики используют встроенные функции (enumerate, zip, map), срезы списков и словарные включения — это и есть «питонический» стиль.

Хорошая практика — вести собственный файл с решениями и заметками. Возвращаясь к задачам через неделю, вы увидите, как вырос ваш уровень. Платформы вроде LeetCode, Codewars и HackerRank предлагают задачи с автоматической проверкой, но начинать лучше с задач, адаптированных под русскоязычную аудиторию. Ещё один совет: не гонитесь за количеством. Пять задач, решённых вдумчиво с разбором альтернативных подходов, ценнее пятидесяти, решённых механически копированием паттернов.

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

Продвинутые концепции Python

Когда основы освоены, приходит время познакомиться с инструментами, которые отличают код новичка от кода опытного разработчика. В Python таких инструментов много, но есть пять ключевых концепций, без которых сложно писать по-настоящему качественный код: декораторы, генераторы, comprehensions, контекст-менеджеры и механизм *args/**kwargs. Именно владение этими инструментами отличает junior-разработчика от middle — и именно их чаще всего спрашивают на собеседованиях.

Декораторы

Декоратор — это функция, которая принимает другую функцию и возвращает её модифицированную версию. Звучит абстрактно, но на практике декораторы встречаются повсеместно: @property, @staticmethod, @login_required в Django, @app.route() во Flask. Они позволяют добавлять поведение без изменения исходного кода функции — логирование, кэширование, проверку прав доступа, валидацию аргументов, замер времени выполнения.

Под капотом декоратор — это обычный паттерн: функция, принимающая функцию и возвращающая функцию. Но синтаксический сахар с символом @ делает код лаконичным и выразительным. Декораторы можно параметризовать, складывать стопкой (применять несколько к одной функции) и даже применять к целым классам. Стандартная библиотека Python включает полезные декораторы: @functools.lru_cache для кэширования результатов, @functools.wraps для сохранения метаданных обёрнутой функции.

Декораторы — одна из тех тем, которые кажутся сложными ровно до момента, пока не разберёшься. Подробный разбор с примерами — в статье «Декораторы в Python: понять и полюбить».

Генераторы и comprehensions

Генераторы — это функции с ключевым словом yield, которые возвращают данные лениво, по одному элементу за раз. Вместо того чтобы создавать в памяти список из миллиона элементов, генератор выдаёт их по запросу. Это критически важно при обработке больших файлов, потоков данных и результатов SQL-запросов. Генератор занимает фиксированный объём памяти независимо от количества элементов — хоть миллион, хоть миллиард.

Comprehensions (списковые, словарные и множественные включения) — это питонический способ создания коллекций в одну строку. Вместо цикла из трёх строк вы пишете выразительную конструкцию: [x ** 2 for x in range(10) if x % 2 == 0]. Они быстрее эквивалентных циклов (Python оптимизирует их на уровне байткода) и читаются проще — если не злоупотреблять вложенностью. Словарные включения {k: v for k, v in pairs} и множественные {x for x in items} работают по тому же принципу.

Контекст-менеджеры и *args/**kwargs

Конструкция with в Python — это контекст-менеджер, который гарантирует корректное освобождение ресурсов: закрытие файлов, соединений с базой, снятие блокировок. Вместо try/finally вы пишете with open('file.txt') as f: — и ресурс освобождается автоматически, даже если произошла ошибка. Можно создавать собственные контекст-менеджеры через методы __enter__/__exit__ или декоратор @contextmanager из модуля contextlib — это проще, чем кажется.

*args и **kwargs позволяют создавать функции с переменным числом аргументов. Это основа для написания гибких API, декораторов и обёрток. Понимание того, как Python распаковывает аргументы, открывает путь к элегантным решениям: передача параметров из словаря в функцию одной строкой, объединение конфигураций, создание универсальных обёрток. В комбинации с аннотациями типов (ParamSpec, Concatenate) этот механизм стал ещё мощнее в последних версиях Python.

Отдельного внимания заслуживает работа с памятью. Python скрывает от разработчика ручное управление памятью, но понимание того, сколько весят разные типы данных и как работает сборщик мусора, помогает писать эффективный код. Например, пустой список в Python занимает 56 байт, а каждый элемент добавляет 8 байт на указатель плюс размер самого объекта. Для числовых задач это означает, что NumPy-массив может быть в 10 раз компактнее обычного списка. Детальный разбор — в статье о распределении памяти в Python.

Dataclasses и NamedTuple

Модуль dataclasses (Python 3.7+) решает классическую проблему: написание классов, которые в основном хранят данные. Декоратор @dataclass автоматически генерирует __init__, __repr__, __eq__ и другие методы. С параметром frozen=True класс становится неизменяемым — удобно для конфигураций и DTO.

NamedTuple — ещё более лёгкая альтернатива: именованный кортеж занимает меньше памяти, чем dataclass, и автоматически поддерживает распаковку и итерацию. Выбор между ними прост: нужна изменяемость или наследование — dataclass, нужна компактность и совместимость с кортежами — NamedTuple.

Многопоточность, асинхронность и GIL

GIL (Global Interpreter Lock) — глобальная блокировка интерпретатора CPython, которая гарантирует, что в каждый момент времени только один поток выполняет байткод Python. Это упрощает реализацию интерпретатора и работу с памятью, но ограничивает параллелизм CPU-задач. Важно: GIL не мешает I/O-параллелизму — потоки освобождают блокировку при ожидании сети, диска или sleep.

Модуль threading подходит для I/O-bound задач: параллельные HTTP-запросы, чтение файлов, работа с базами данных. Для CPU-bound вычислений (обработка изображений, математические расчёты) используйте multiprocessing — он создаёт отдельные процессы, каждый со своим GIL. Пул concurrent.futures.ProcessPoolExecutor упрощает распределение задач по ядрам.

Модуль asyncio — стандарт для асинхронного программирования в Python. Конструкции async def и await позволяют писать неблокирующий код, который выглядит почти как синхронный. Один поток обрабатывает тысячи соединений — именно поэтому FastAPI и другие ASGI-фреймворки работают быстрее классических WSGI-аналогов.

Когда что использовать? threading — для I/O-операций с умеренной нагрузкой. asyncio — для высоконагруженных I/O-сценариев (веб-серверы, парсеры). multiprocessing — для CPU-bound задач. На практике они часто комбинируются: например, asyncio для сетевого ввода-вывода и ProcessPool для тяжёлых вычислений внутри одного приложения.

Важная новость: PEP 703 предлагает сделать GIL опциональным (free-threaded Python). Экспериментальная сборка без GIL уже доступна в Python 3.13+ через специальную сборку python3.14t (free-threaded build). В Python 3.14 этот режим стал официально поддерживаемым (PEP 779). Если эксперимент окажется успешным, в будущих версиях Python сможет полноценно использовать все ядра процессора без обходных путей через multiprocessing.

Тестирование в Python

Тестирование — не роскошь, а базовая гигиена разработки. В Python стандартом де-факто является pytest — фреймворк, который сочетает простоту написания тестов с мощной системой расширений. Обычные функции с assert — это уже тесты. Не нужны классы, наследование от TestCase и специальные методы.

Фикстуры (@pytest.fixture) управляют подготовкой и очисткой тестового окружения: подключение к базе данных, создание тестового клиента, временные файлы. Параметризация (@pytest.mark.parametrize) позволяет прогнать один тест с десятками наборов входных данных без дублирования кода.

Для изоляции внешних зависимостей используйте unittest.mock — встроенный модуль, который позволяет подменять HTTP-запросы, обращения к базе данных и вызовы внешних сервисов. В связке с pytest это покрывает 95% потребностей в тестировании. TDD (Test-Driven Development) — подход, при котором тест пишется раньше кода. Его необязательно практиковать всегда, но для сложной бизнес-логики он существенно снижает количество регрессий.

Работа с файлами и данными

Python предоставляет удобные инструменты для работы с файлами любых форматов. Конструкция with open(...) гарантирует корректное закрытие файла даже при ошибке. Модуль pathlib (Python 3.4+) — современная замена os.path: объектно-ориентированные пути, кроссплатформенная совместимость и цепочки вызовов.

Для структурированных данных стандартная библиотека предлагает модули json, csv и configparser. Для YAML понадобится сторонний пакет PyYAML. Работа с Excel-файлами — через openpyxl или pandas. Для больших объёмов данных используйте потоковое чтение: csv.reader или json.JSONDecoder().raw_decode() вместо загрузки всего файла в память.

Для работы с распределением памяти и внутренним устройством типов данных Python — рекомендуем нашу статью о распределении памяти в Python: сколько и в каких случаях занимают типы данных.

Веб-разработка на Python

Python — один из ключевых языков для серверной веб-разработки. Три фреймворка покрывают практически все сценарии: Django — для полнофункциональных приложений, Flask — для микросервисов и лёгких проектов, FastAPI — для высокопроизводительных API. Каждый из них занимает свою нишу, и выбор зависит от масштаба проекта, требований к производительности и опыта команды. Разберём сильные и слабые стороны каждого, чтобы вы могли сделать осознанный выбор.

Django: всё включено

Django — это «батарейки в комплекте». ORM, админ-панель, система аутентификации, шаблонизатор, миграции базы данных, защита от CSRF и XSS, формы с валидацией, кэширование, интернационализация — всё работает из коробки и не требует сторонних зависимостей. Это делает Django идеальным выбором для крупных проектов: интернет-магазинов, SaaS-платформ, CRM-систем, внутренних корпоративных порталов. Instagram, Mozilla, Disqus, Pinterest — все они используют Django в продакшене.

Главное преимущество Django — зрелость. Фреймворку больше 20 лет, он имеет огромное сообщество, тысячи готовых пакетов (django-rest-framework, django-allauth, celery) и предсказуемый цикл релизов. Django ORM позволяет работать с базой данных через Python-объекты, не написав ни строчки SQL, а система миграций автоматически отслеживает изменения в моделях. Обратная сторона — Django навязывает свою архитектуру. Если вам нужен только REST API без шаблонов и админки, значительная часть фреймворка будет «мёртвым грузом».

Flask: минималистичный и гибкий

Flask — противоположность Django. Микрофреймворк даёт маршрутизацию, обработку запросов и систему расширений — остальное вы выбираете сами. Нужна ORM? Подключите SQLAlchemy. Нужна авторизация? Flask-Login. Хотите WebSocket? Flask-SocketIO. Такой подход идеален для микросервисов, прототипов и проектов, где полный контроль над стеком важнее скорости старта. Flask часто выбирают для внутренних сервисов, API-шлюзов и проектов, которые начинаются маленькими, но могут вырасти.

Flask отлично сочетается с фронтенд-фреймворками. Например, в статье «Пишем одностраничное приложение с Flask и Vue.js» мы показываем, как построить SPA с Flask-бэкендом — от настройки проекта до деплоя. Это типичный современный стек: Python на сервере, JavaScript-фреймворк на клиенте.

FastAPI: скорость и типизация

FastAPI — самый молодой из тройки, но уже ставший стандартом для создания API. Он построен на Starlette (ASGI) и Pydantic, поддерживает async/await из коробки и автоматически генерирует документацию OpenAPI (Swagger UI и ReDoc) прямо из аннотаций типов в коде. FastAPI — один из самых быстрых Python-фреймворков благодаря Starlette и uvicorn. Валидация данных через Pydantic-модели ловит ошибки ещё до обработки запроса, а type hints превращаются в живую документацию API. Dependency injection встроен в ядро фреймворка, что упрощает тестирование и переиспользование кода.

Но скорость — не всё. FastAPI требует понимания асинхронного программирования, а экосистема пока уступает Django и Flask по количеству готовых решений. Для простого CRUD-приложения с админкой Django справится быстрее; для прототипа с нестандартной архитектурой Flask даст больше свободы. О подводных камнях и ситуациях, когда FastAPI — не лучший выбор, мы подробно рассказываем в статье «Почему не стоит выбирать FastAPI» — честный разбор, который поможет принять взвешенное решение.

Какой фреймворк выбрать

• Полноценное веб-приложение с админкой и авторизацией — Django
• Микросервис или прототип с полным контролем над стеком — Flask
• Высокопроизводительный REST/GraphQL API с автодокументацией — FastAPI
• Не уверены — начните с Django: у него самый пологий путь от нуля до продакшена

На практике многие команды используют несколько фреймворков одновременно: Django для основного приложения, FastAPI для высоконагруженных микросервисов, Flask для внутренних инструментов. Python позволяет комбинировать. Общий навык для всех трёх фреймворков — понимание HTTP-протокола, REST-архитектуры, работы с базами данных и основ безопасности (CORS, CSRF, XSS, SQL-инъекции). Освоив эти концепции на одном фреймворке, вы легко перейдёте на другой.

Python для Data Science

Если веб-разработка — давняя территория Python, то Data Science — его новая сверхдержава. По данным JetBrains Developer Ecosystem Survey, Python — самый изучаемый язык программирования и основной инструмент дата-аналитиков и дата-инженеров. R, Julia, Scala — у каждого есть свои преимущества, но ни один не предлагает такую же широту экосистемы. Причина — уникальный набор библиотек, который покрывает весь pipeline работы с данными: от загрузки и очистки до визуализации и развёртывания моделей в продакшен.

NumPy — фундамент всего стека. Библиотека предоставляет многомерные массивы и математические операции, работающие на порядки быстрее чистого Python — за счёт реализации на C. Умножение матрицы 1000x1000 в NumPy выполняется за миллисекунды, в то время как наивная реализация на чистом Python займёт минуты. Pandas строится поверх NumPy и предлагает удобные таблицы (DataFrame), позволяя загружать, фильтровать, группировать и агрегировать данные в несколько строк кода. Данные из CSV, Excel, SQL, JSON — Pandas читает практически всё.

Для машинного обучения стандартом остаётся scikit-learn — библиотека с десятками алгоритмов классификации, регрессии и кластеризации. Её главная сила — единый интерфейс: fit(), predict(), score() работают одинаково для любого алгоритма, будь то случайный лес, SVM или градиентный бустинг. Это позволяет быстро сравнивать модели, менять алгоритмы одной строкой и строить пайплайны предобработки данных.

Для глубокого обучения Python предлагает PyTorch и TensorFlow — два гиганта, на которых построены GPT, Stable Diffusion и другие модели, изменившие индустрию. PyTorch доминирует в исследованиях благодаря динамическим вычислительным графам, а TensorFlow остаётся популярным в продакшене благодаря TensorFlow Serving и TFLite. Визуализация данных — matplotlib для статичных графиков, seaborn для статистических визуализаций и plotly для интерактивных дашбордов. Jupyter Notebook объединяет всё это в единую среду, где код, графики и текст живут рядом.

Разобраться в ключевых библиотеках поможет наш топ-10 Python-библиотек для Data Science. А если хотите расширить инструментарий за пределы стандартного набора — загляните в подборку 10 полезных библиотек, о которых вы могли не слышать: там есть настоящие жемчужины для отладки, профилирования и работы с данными.

Для управления окружениями в Data Science часто используют conda (Anaconda/Miniconda) — он умеет устанавливать не только Python-пакеты, но и системные зависимости вроде CUDA для GPU-вычислений.

Практические инструменты Python

Помимо веб-разработки и Data Science, Python — незаменимый инструмент для повседневных задач: интеграция с внешними сервисами, извлечение данных из веб-страниц и обработка текста.

Работа с API

Библиотека requests — стандарт для синхронных HTTP-запросов: лаконичный API, автоматическая сериализация JSON и управление сессиями. Для асинхронных задач и HTTP/2 используйте httpx — он совместим с requests по интерфейсу, но поддерживает async/await.

Веб-скрапинг

Для извлечения данных из HTML-страниц Python предлагает несколько уровней инструментов. BeautifulSoup — простой парсер для статических страниц: выборка по CSS-селекторам и тегам. Scrapy — полноценный фреймворк для масштабного скрапинга с очередями, ротацией прокси и экспортом данных. Selenium и Playwright — для страниц, где контент рендерится JavaScript'ом.

Регулярные выражения

Модуль re — мощный инструмент для поиска и трансформации текста по шаблонам. Основные функции: re.findall() для извлечения всех совпадений, re.sub() для замены и re.compile() для предкомпиляции часто используемых паттернов.

Совет: для сложных паттернов используйте сырые строки (r"...") — они избавляют от двойного экранирования обратных слэшей. А для задач, выходящих за рамки регулярных выражений (парсинг HTML, XML), всегда предпочитайте специализированные парсеры.

Что нового в Python 3.14

Python 3.14 (что нового) (да, «пи»-релиз — разработчики не упустили возможность пошутить), выпущенный в октябре 2025 года, стал одним из самых значительных релизов за последние годы. Главные нововведения направлены на производительность — область, где Python традиционно уступал компилируемым языкам. Но 3.14 меняет правила игры.

Экспериментальный JIT-компилятор (PEP 744) — пожалуй, главная новость. Он компилирует часто выполняемые участки кода (так называемые «горячие пути») в машинные инструкции прямо во время работы программы. На реальных приложениях это даёт эффект варьируется: от замедления на 10% до ускорения на 20% в зависимости от нагрузки — на некоторых задачах JIT пока замедляет код без каких-либо изменений в коде. JIT пока отключён по умолчанию (в официальных сборках для macOS и Windows JIT уже включён в бинарники — активируется переменной окружения PYTHON_JIT=1), но уже работает стабильно на большинстве платформ. Это первый шаг к тому, чтобы Python перестал считаться «медленным языком».

Внутренняя архитектура интерпретатора переработана: новый tail-call диспетчер опкодов (на уровне C, не Python-функций) даёт прирост 3—5% на стандартном benchmark suite. Важно: это не оптимизация хвостовой рекурсии в Python-коде — RecursionError при превышении глубины стека по-прежнему возможен.

T-строки (PEP 750) — новый синтаксис шаблонных строк с префиксом t"...". В отличие от f-строк, T-строки не выполняют подстановку сразу, а возвращают объект Template, который можно обработать — экранировать специальные символы, валидировать параметры, преобразовать значения. Это отличное решение для безопасной генерации HTML и SQL без риска инъекций.

Среди других улучшений — ускоренные операции со словарями (до 40% быстрее в некоторых сценариях), оптимизированная работа сборщика мусора и улучшенные сообщения об ошибках, которые теперь подсказывают возможные причины проблемы. Обновлён синтаксис обработки исключений (PEP 758): теперь можно писать except ValueError, TypeError: без скобок (без as — с as по-прежнему нужны скобки: except (ValueError, TypeError) as e:). Также завершён переход на отложенное вычисление аннотаций типов (PEP 649/749) — аннотации больше не вычисляются при импорте модуля, что ускоряет запуск. Python продолжает развиваться, сохраняя обратную совместимость и фокус на удобстве разработчика.

Куда двигаться дальше

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

1. Backend-разработчик — Django, Flask или FastAPI, базы данных (PostgreSQL, Redis), REST API, очереди задач (Celery), контейнеризация (Docker, Kubernetes)
2. Data Scientist / ML-инженер — pandas, scikit-learn, PyTorch, работа с данными, статистика, построение и деплой моделей
3. DevOps / SRE — автоматизация инфраструктуры (Ansible, Terraform), скрипты мониторинга, CI/CD пайплайны, облачные провайдеры (AWS, GCP)
4. ИИ-инженер — LLM, промпт-инжиниринг, RAG-системы, fine-tuning, LangChain, работа с API нейросетей (OpenAI, Anthropic, Mistral)
5. Автоматизатор / QA-инженер — Selenium, Playwright, pytest, автоматизация тестирования, нагрузочное тестирование (Locust)

Независимо от выбранного направления, есть навыки, которые пригодятся везде: Git для контроля версий, SQL для работы с базами данных, Docker для контейнеризации, Linux для понимания серверной среды. Python-разработчик в 2026 году — это не просто человек, который знает синтаксис языка, а специалист, владеющий инструментарием вокруг него. Также стоит освоить виртуальные окружения (venv, poetry, uv), линтеры (ruff, mypy) и основы CI/CD — это ожидается от любого профессионального разработчика. Для управления версиями Python-проектов пригодится наш путеводитель по Git.

Рынок труда подтверждает спрос: по данным hh.ru, количество вакансий с Python стабильно растёт на 15—20% в год, а медианная зарплата Python-разработчика уровня middle составляет 250 000—350 000 рублей в месяц. Специалисты на стыке Python и Data Science / ML зарабатывают ещё больше. Язык востребован не только в IT-компаниях: банки, телеком, ритейл, промышленность — Python нужен везде, где есть данные и автоматизация.

Отдельно стоит упомянуть растущий спрос на ИИ-инженеров. С развитием больших языковых моделей Python стал основным языком для интеграции ИИ в продукты: построение RAG-систем, создание агентов, fine-tuning моделей — всё это делается на Python. Библиотеки LangChain, LlamaIndex, Hugging Face Transformers формируют новую экосистему, которая растёт быстрее любого другого направления в IT.

Если вы в начале пути — начните со структурированной дорожной карты изучения Python. Она поможет не потеряться в обилии материалов и выстроить последовательный план обучения от основ до профессионального уровня. А затем возвращайтесь к этому путеводителю — здесь вы всегда найдёте ссылки на углублённые материалы по каждой теме. Мы регулярно обновляем наши гайды, чтобы они оставались актуальными — так что добавляйте страницу в закладки.

Именно этот релиз завершил важный этап стабилизации асинхронных возможностей фреймворка. Он поддерживает Python версий с 3.10 по 3.13, что покрывает потребности большинства разработчиков.

Асинхронность в Django прошла долгий путь: начало было положено в версии 3.0 с базовой поддержкой ASGI, в Django 4.0 появились асинхронные ORM-запросы. В версии 5.1 этот инструмент окончательно сформировался для высокопроизводительных приложений, и его успели проверить «в боевых условиях» много разработчиков.

Зачем вообще нужна асинхронность?

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

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

Главное изменение в Django 5.1 — стабилизация асинхронного API. Ранние реализации, начиная с Django 3.1 содержали скрытые проблемы, которые теперь устранены. Асинхронные вьюхи перестали быть экспериментальной функцией.

Основное преимущество асинхронности — эффективная работа с операциями ввода-вывода. Это запросы к внешним API, взаимодействие с файлами и базами данных. В таких сценариях асинхронный код может обрабатывать больше запросов на том же оборудовании — в некоторых случаях до 3-5 раз, в зависимости от нагрузки и конфигурации..

Рассмотрим практический пример. Допустим, мы разрабатываем агрегатор новостей. Приложение должно получать данные из трех источников одновременно.

Импортируем необходимые библиотеки:

Этот код выполняет все три запроса параллельно. В синхронной версии общее время выполнения равнялось бы сумме времени всех запросов. В асинхронной — времени самого медленного запроса.

Асинхронный ORM: текущее состояние

Django 5.1 продолжает улучшать асинхронную поддержку ORM (Object-Relational Mapping — система, которая позволяет работать с базой данных как с набором Python-объектов). Большинство операций с БД теперь имеют асинхронные версии. Но важно понимать ограничения.

Полностью асинхронные запросы работают только с драйверами, поддерживающими асинхронность. Для PostgreSQL это psycopg3, для MySQL — aiomysql. SQLite имеет ограниченную асинхронную поддержку.

Пример асинхронного ORM-запроса:

Методы, начинающиеся с «a» (aget, alist, afirst), предоставляют асинхронный интерфейс к стандартным ORM-операциям.

Производительность: реальные показатели

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

Архитектурные преимущества асинхронности реализуются, если соблюден ряд условий:

• используется ASGI-сервера вместо WSGI;
• правильно настроены асинхронные драйверов базы данных;
• нет блокирующих операций в основном потоке выполнения.

При грамотной реализации это позволяет обрабатывать тысячи одновременных соединений без пропорционального увеличения потребления памяти.

На практике производительность сильно зависит от конкретной конфигурации и характера нагрузки. Для CPU-bound операций или простых CRUD-приложений с минимальной внешней интеграцией выигрыш может быть незначительным. Однако в задачах, требующих множественных параллельных обращений к внешним сервисам или обработки потоковых данных, асинхронная архитектура демонстрирует существенное преимущество перед традиционным синхронным подходом.

Типичные ошибки и как их избежать

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

Ошибка: вызов синхронной функции из асинхронного контекста без обертки.

Неправильный подход:

Правильное решение:

Другая распространенная проблема — блокирующие вызовы в асинхронном коде. Даже в асинхронной функции такие операции как сложные вычисления или синхронные HTTP-запросы будут блокировать цикл событий.

Решение — выносить ресурсоемкие задачи в отдельные потоки через asyncio.to_thread или использовать специализированные воркеры.

Типичная ошибка: неправильная работа с транзакциями в асинхронном контексте. Синхронные транзакции Django не работают с асинхронным кодом.

Неправильно:

Правильное решение — использовать sync_to_async для обертки всей транзакции:

Ошибка — постановка избыточного количества одновременных задач без ограничений. Это может привести к исчерпанию ресурсов сервера.

Проблемный код:

Решение — использовать семафоры для ограничения параллелизма:

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

Неправильно:

Правильный подход — учитывать специфику асинхронных исключений:

Ошибка блокировки цикла событий долгими CPU-bound операциями. Асинхронность не ускоряет вычисления, а только улучшает работу с вводом-выводом.

Проблемный код:

Решение — вынос вычислений в отдельный поток:

Ошибка неправильного использования глобальных переменных в асинхронном коде. Состояние может изменяться неожиданно из-за параллельного выполнения.

Опасный код:

Решение — использование контекстных переменных или передача состояния явно:

Ошибка создания взаимной блокировки при неправильном использовании примитивов синхронизации. Асинхронные блокировки имеют свои особенности.

Проблемный код:

Решение — проектировать код так, чтобы избегать вложенных блокировок и использовать timeout:

Исключив эти ошибки, сможете создавать более надежный и производительный асинхронный код в Django 5.1.

Когда асинхронность не нужна

Асинхронность — мощный инструмент, но не универсальное решение. Есть сценарии, где ее применение не дает преимуществ, а только усложняет код.

Ситуации, когда асинхронность избыточна:

• Простые CRUD-приложения без внешних вызовов — если приложение в основном выполняет базовые операции с базой данных и не взаимодействует с внешними API, синхронный код проще для понимания и отладки.
• Проекты с небольшой нагрузкой — когда количество одновременных пользователей измеряется десятками, а не тысячами, дополнительные затраты на управление асинхронными задачами перевешивают преимущества.
• Команды без опыта работы с асинхронным кодом — асинхронное программирование требует понимания цикла событий и корутин (легковесных программ, которые позволяют писать асинхронный код так, как будто он синхронный). Ошибки сложнее обнаружить и исправить.
• Приложения с интенсивными вычислениями — Python GIL ограничивает параллельное выполнение CPU-bound задач, поэтому для вычислений лучше подходит многопроцессорность.
• Интеграция со сторонними библиотеками — многие популярные Python-библиотеки не поддерживают асинхронность, приходится использовать обертки sync_to_async.
• Быстрая разработка и тестирование — написание и отладка асинхронных тестов занимает больше времени, что критично для стартапов.
• Высокие требования к надежности — синхронная архитектура предсказуемее и надежнее для проектов, где стабильность важнее производительности.
• Ограниченные ресурсы разработки — стоимость разработки и поддержки асинхронных приложений обычно выше из-за требований к квалификации команды.
• Миграция legacy-проектов — переписывание существующих синхронных систем на асинхронность рискованно и часто неоправданно.
• Микросервисная архитектура — выделение отдельных сервисов для асинхронных задач часто практичнее, чем преобразование всего приложения.

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

Миграции в Django 5.1: эволюция продолжается

Система миграций — один из самых мощных инструментов Django. В версии 5.1 она получила значительные улучшения в производительности и надежности.

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

Рассмотрим пример улучшенного обнаружения изменений. Было в models.py (основном файле для описания структуры базы данных):

В Django 4.2 это могло создать две отдельные миграции. В 5.1 система понимает, что created и created_at — одно поле, и генерирует одну миграцию с операцией RenameField и изменением max_length.

Безопасные миграции больших таблиц

Работа с таблицами в миллионы записей всегда была болезненной точкой. Блокировки таблиц при применении миграций могли приводить к простоям приложения.

В Django 5.1 представлен атрибут Operation.category. Он позволяет классифицировать операции миграций. Команда showmigrations теперь отображает специальные символы для каждой операции. Это упрощает чтение плана миграций. Разработчики быстрее понимают структуру изменений в базе данных.

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

Новые опции в миграциях:

Миграции с данными: лучшие практики

Миграции данных остаются мощным, но опасным инструментом. Ошибки в этом процессе может привести к катастрофическим последствиям.

Как делать правильно:

• всегда тестировать миграции на полной копии production-данных;
• использовать пакетную обработку для больших объемов данных;
• предусматривать откат для каждой операции с данными;
• добавлять индикатор прогресса для долгих миграций

Пример безопасной миграции данных:

Интеграция с облачными базами данных

В 2025 году большинство проектов развернуты в облачных средах. Django 5.1 улучшил поддержку облачных баз данных типа Amazon RDS, Google Cloud SQL и Azure Database.

Основные улучшения:

• лучшая обработка временных разрывов соединения;
• поддержка реплик для чтения для распределения нагрузки;
• улучшенная работа с пулами соединений;
• автоматическое переподключение при обрывах.

Конфигурация для облачной PostgreSQL:

Django 5.1 сделал встроенную поддержку пулов соединений PostgreSQL через psycopg3, чтобы сократить расходы на установку соединений.

Мониторинг и отладка асинхронного кода

Отладка асинхронного кода требует специальных подходов. Трассировка стека в асинхронных приложениях сложнее из-за работы цикла событий (event loop).

Новые инструменты для мониторинга:

• ASGI middleware (промежуточный слой) для мониторинга производительности;
• интеграция с системами мониторинга производительности приложений;
• специализированные логи для асинхронных операций;
• метрики для event loop.

Пример middleware для мониторинга:

Тестирование асинхронных приложений

Тестирование асинхронного кода в Django требует использования специальных тестовых классов и подходов.

Пример тестирования асинхронной вьюхи:

Безопасность асинхронного кода

Асинхронность приносит новые векторы атак. Состояния гонки, взаимные блокировки и проблемы с разделением состояния становятся более вероятными.

Как минимизировать риски:

• использовать потокобезопасные структуры данных;
• избегать разделяемого изменяемого состояния;
• тщательно тестировать на состояния гонки;
• использовать асинхронные версии блокировок при необходимости.

Пример безопасной работы с разделяемыми ресурсами:

Миграционная стратегия для legacy-проектов

Перевод существующего проекта на асинхронность требует продуманного подхода.

Рекомендуется постепенная миграция:

1. Начать с новых эндпоинтов, реализуя их асинхронно.
2. Выделить наиболее нагруженные части API для перевода на async.
3. Использовать гибридный подход, где это необходимо.
4. Тщательно тестировать производительность на каждом этапе.

Пример гибридного подхода. Старые синхронные вьюхи остаются:

Новые эндпоинты делаем асинхронными:

Гибридный эндпоинт:

Производительность в продакшене: метрики и мониторинг

При развертывании асинхронных приложений важно отслеживать правильные метрики.

Традиционные метрики веб-приложений дополняются специфическими для async:

• Event loop latency — задержки в обработке событий;
• Active tasks — количество активных асинхронных задач;
• Queue size — размер очереди задач;
• Database connection pool usage — использование пула соединений.

Настройка мониторинга:

Итоги: асинхронность как стандарт

Django 5.1 знаменует переход асинхронности из категории экспериментальных возможностей в стандартный инструмент разработки. Стабильность и производительность async-компонентов достигли уровня, позволяющего использовать их в production-проектах.

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

Ключевые выводы для разработчиков в 2025 году:

• асинхронные вьюхи готовы к использованию в продакшене;
• наибольший выигрыш от асинхронности — в сценариях с интенсивным вводом-выводом;
• миграции стали надежнее и безопаснее для больших баз данных;
• постепенная миграция legacy-кода — оптимальная стратегия;
• мониторинг и тестирование требуют адаптации под асинхронную парадигму.

Django продолжает эволюционировать, поддерживая равновесие между современными требованиями и обратной совместимостью. Асинхронность в Django 5.1 — это закономерный этап развития фреймворка, который уже более 15 лет входит в топ наиболее популярных инструментов для веб-разработки на Python.

Владение Django — это старт, а не финиш. Чтобы оставаться востребованным, нужно постоянно расширять знания и навыки. В этой статье разберем пути и направления для улучшения своих компетенций.

Почему владение Django — не предел для разработчика

Особенности Django

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

Основные плюсы:

• Полноценный стек: ORM для работы с базой, мощная система маршрутизации URL, шаблоны для рендеринга, встроенная админка, формы, система аутентификации и авторизации.
• Архитектура MTV (Model-Template-View): похожа на классический MVC, но с особенностями, которые упрощают разделение логики, представления и данных.
• Безопасность: Django автоматически защищает от CSRF, XSS, SQL-инъекций и других распространенных атак. Не нужно писать много дополнительного кода.
• Активное сообщество и экосистема: тысячи сторонних пакетов, расширений и готовых решений.
• Поддержка нескольких баз данных: PostgreSQL, MySQL, SQLite, Oracle и др.

Ограничения:

• Синхронная природа Django.
• Монолитность: архитектура фреймворка ориентирована на создание крупных приложений, но в микросервисах может быть избыточна.
• Ограниченная гибкость ORM: нестандартные SQL-запросы иногда сложно выразить средствами ORM, приходится использовать raw SQL или сторонние библиотеки для запросов.
• Строгие правила организации кода: требуют дисциплины и могут ограничивать свободу в архитектурных решениях.
• Недостаточная производительность: уступает лёгким асинхронным фреймворкам (например, FastAPI), особенно под высокими нагрузками. Но для большинства проектов пока это не критично.

В каком направлении двигаться после изучения Django

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

Первое направление для развития — расширить инструментарий для решения разных задач в веб-разработке

Возможные пути:

• Изучить другие веб-фреймворки (Flask, FastAPI)
• Углубиться в асинхронное программирование (asyncio, aiohttp)
• Работать с API и микросервисами

Flask и FastAPI

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

FastAPI — современный асинхронный фреймворк, ориентирован на создание высокопроизводительных API. Поддерживает стандарт OpenAPI и автоматическую генерацию документации. Он быстрее Flask и Django благодаря asyncio и Pydantic.

Асинхронное программирование

Веб-разработка всё активнее использует асинхронные технологии. Django не всегда справляется с задачами высокой конкурентной нагрузки.

Поэтому изучение asyncio — стандартной библиотеки Python для асинхронного программирования — откроет перед вами новые возможности. Вместе с aiohttp или тем же FastAPI вы сможете создавать приложения, которые обрабатывают тысячи одновременных соединений. Это особенно важно для real-time сервисов, чат-приложений и систем с интенсивным обменом данными.

Второе направление — расширить навыки в смежных областях

Можно пойти по пути расширения компетенций за пределы основной специализации. Важно не только уметь писать код, но и понимать, как приложения разворачиваются и работают в продакшене. Знание DevOps-практик помогает наладить эффективное взаимодействие между разработкой и эксплуатацией.

Изучение DevOps и контейнеризации

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

CI/CD и автоматизация процессов

Непрерывная интеграция (Continuous Integration) и непрерывное развертывание (Continuous Deployment) — ключевые практики современной разработки ПО. Они позволяют автоматизировать сборку, тестирование и доставку приложений, масштабировать процессы.

Инструменты CI/CD (например, Jenkins, GitLab CI/CD, GitHub Actions) помогают настроить автоматические пайплайны, которые обеспечивают быструю обратную связь и минимизируют человеческий фактор в релизах. Автоматизация процессов снижает количество ошибок и позволяет сосредоточиться на разработке новых функций.

Настройка непрерывной интеграции и доставки (Continuous Integration / Continuous Delivery) снижает поток ошибок при релизах и экономит время. Пример: GitHub Actions для автоматического запуска тестов и сборки проекта при каждом коммите.

Больше знаний в области баз данных

Помимо классических реляционных баз данных (PostgreSQL, MySQL), современные приложения часто используют NoSQL для специфичных задач. MongoDB, Redis, Cassandra обеспечивают гибкость в хранении данных, горизонтальное масштабирование и высокую производительность при работе с большими объемами информации.

Графовые базы данных (Neo4j, ArangoDB) предназначены для эффективного хранения и анализа связей между объектами, что важно для социальных сетей, рекомендательных систем и других приложений с богатой структурой.

Так, Redis хорошо подходит для кэширования данных, а Neo4j — для сложных связей между объектами.

Третье направление — переход к другим аспектам Python-разработки

Рассмотрим четыре варианта карьерного развития для Python-программиста: Data Science и машинное обучение, автоматизация бизнес-процессов, разработка десктопных приложений и встраиваемые системы (IoT).

Почему стоит попробовать?

• Высокий спрос на специалистов. Они востребованы в банках и инвестиционных компаниях, в сфере медицины и биотехнологии, в консалтинге, автомобильной промышленности и т.д..
• Широкий набор библиотек: pandas, NumPy, scikit-learn, TensorFlow, PyTorch.
• Возможность работать с реальными задачами: от бизнеса до науки.

Автоматизация и скрипты для бизнеса

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

Знание таких библиотек, как openpyxl (работа с Excel), requests (HTTP-запросы), BeautifulSoup и Scrapy (парсинг веб-страниц), а также умение писать скрипты под конкретные задачи, делают разработчика ценным специалистом в корпоративной среде.

Примеры задач:

• Автоматическая загрузка данных из Excel и их преобразование
• Скрипты для отправки email-рассылок
• Интеграция с CRM и другими сервисами через API

Разработка десктопных приложений (PyQt, Kivy)

Хотя сейчас популярность уходит к вебу и мобильным платформам, десктопные приложения на Python востребованы в таких сферах: инструменты для анализа, редакторы, утилиты.

Инструменты для создания:

• PyQt — мощный фреймворк для создания кроссплатформенных GUI.
• Kivy — библиотека для разработки приложений с поддержкой сенсорных экранов.

Этот путь подходит тем, кто хочет создавать удобные инструменты с графическим интерфейсом для пользователей на Windows, macOS или Linux.

Встраиваемые системы и IoT

В области IoT и встроенных систем Python набирает популярность благодаря легкости освоения и поддержке на маломощных устройствах. Помогают в этом платформы по типу Raspberry Pi и MicroPython.

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

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

Если рассматривать профессию “Python-разработчик на Django”, то сразу получится сужение до конкретной библиотеки на конкретном языке. Если же в резюме у специалиста стоит, что он “разработчик Python”, возможностей сильно больше. Если написать про себя “разработчик”, будет не понятно, разработчик чего. Но изменив резюме на “DevOps инженера”, становится понятен карьерный трек.

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

1. ИХЦ (Интернет ХостингЦентр): конфигурации под нагрузку с NVMe, CPU до 5 ГГц и трафиком без ограничений

Один из самых гибких по конфигурациям хостеров в обзоре. Работает с 2009 года. Поддерживает разные типы виртуализации (KVM и Virtuozzo), предлагает линейки с SSD и NVMe, российские и европейские площадки, разные уровни мощности — от базовых до высоконагруженных.

Линейки VPS и конфигурации

1. ssdVPS — базовая линейка для России. Позволяет собирать конфигурации от 1 до 32 ГБ оперативной памяти, от 1 до 10 виртуальных CPU и от 20 до 300 ГБ SSD-диска.
2. NVMe/ — линейка на базе KVM с более высокой производительностью ввода-вывода. Доступны конфигурации от 1 до 24 ГБ RAM, от 1 до 12 vCPU, SSD от 15 до 300 ГБ.
3. EU-NVMe/ — аналог NVMe-линейки, но размещённый в Амстердаме. Конфигурации расширены: от 1 до 64 ГБ оперативной памяти, от 1 до 18 CPU, от 15 до 1000 ГБ SSD, скорость порта — от 200 до 500 Мбит/с.
4. VPS 5 ГГц — отдельная линейка на KVM, ориентированная на проекты с высокой частотной нагрузкой, до 5 ГГц на ядро, порт до 1000 Мбит/с.

VPS Windows — выделенная категория для задач на Windows.

Особенности и инфраструктура

В ИХЦ можно выбрать между двумя видами виртуализации: KVM и Virtuozzo. Виртуализация KVM подходит для задач, где нужна изоляция ресурсов, стабильность под нагрузкой и совместимость с Linux и Windows. Virtuozzo — более экономный вариант с быстрой настройкой, но с возможной перераспределённой нагрузкой между соседними VPS.

Связь с поддержкой доступна через тикеты, онлайн-чат на сайте, телеграм-бота, телефон и сообщения ВКонтакте. Поддержка работает 24/7. На всех тарифах включена базовая DDoS-защита.

Примеры использования VPS от IHC

Компания предоставляет конкретные кейсы. Примеры:

• Проект 1: VPS NVMe/24 (24 ГБ RAM, ~200 ГБ SSD) используется под бэкенд iOS-приложения. Стек: nginx, PHP, MySQL. Нагрузка: 12 000 уникальных пользователей в сутки. Утилизация CPU — 25%.
• Проект 2: VPS NVMe/12 (12 ГБ RAM, ~120 ГБ SSD) для развлекательного сайта. Стек: nginx, Docker, Node.js. Нагрузка: 7 000 уникальных пользователей в сутки, загрузка CPU — около 20%.

Серверы стабильно держат среднюю и высокую нагрузку — даже с трафиком в 10–12 тысяч пользователей в сутки остаётся запас по ресурсам.

Дополнительные опции

ИХЦ предлагает тестовый период в 3 дня, безлимитный трафик, бесплатный первый месяц ispmanager 6 в подарок, а также предустановку панелей управления (ispmanager, FastPanel) или VPN-шаблонов по выбору при заказе. Также доступны бэкапы, SLA и автоснапшоты.

Цены

Что касается ценовой политики, стоимость VPS в России (линейка «ssdVPS») начинается от 380 руб/мес или 3800 руб/год (12 месяцев по цене 10). Европейские VPS («EU-NVMe/») и VPS на KVM («NVMe/») стартуют от 440 руб/мес или 4400 руб/год, а каждый дополнительный гигабайт памяти стоит 6 рублей.

2. FirstVDS: мощные VDS на AMD EPYC и Ryzen

FirstVDS — хостинг-провайдер с опытом на рынке более 20 лет. Предлагают VPS и VDS с виртуализацией KVM для проектов любого размера. Все серверы работают на современном оборудовании. Трижды победитель в номинации «Хостер года» Национальной премии «ЦОДы.РФ».

Есть VPS для разных сценариев нагрузки — от стандартных сайтов до тяжёлых веб-приложений и проектов с высокими требованиями к CPU и отказоустойчивости. Отдельные решения для Битрикс, установка ОС семейства Linux, FreeBSD и Windows Server.

Линейки VPS: от базовой мощности до кластера Ceph

FirstVDS предлагает три основные линейки, которые отличаются архитектурой и назначением:

1. VDS Форсаж — гибкая конфигурация сервера на базе AMD EPYC, до 128 ядер (до 3,7 ГГц), до 512 Гб оперативной памяти и до 4 000 Гб быстрого NVMe-накопителя. Локации Москва и Амстердам. Стартовая стоимость такой конфигурации составляет от 749 руб/мес.
2. Для нагруженных проектов — CPU.Турбо — гибкая конфигурация сервера на базе AMD Ryzen с частотой до 5,7 ГГц, DDR5 и с быстрыми NVMe-накопителями. Идеально для Битрикс. Локация Москва. Начальная цена CPU.Турбо — от 624 руб/мес. При покупке лицензии Битрикс (1С-Битрикс: Управление сайтом или Битрикс24) есть дополнительная скидка 30% на 3 месяца аренды этого тарифа.
3. Отказоустойчивый VDS Атлант — гибкая конфигурация сервера на базе AMD EPYC — до 192 ядер (до 3,5 ГГц), до 768 Гб оперативной памяти и до 8 Тб быстрого NVMe-накопителя. Репликация данных между узлами кластера Ceph и дублирование сетевого оборудования. Локация Москва. Его стартовая стоимость от 1619 руб/мес, при этом бесплатные автобэкапы уже включены.

Компания использует два центра обработки данных в Москве: IXcellerate (уровень Tier III) и Web DC. Для тарифа Форсаж и готовых тарифов также доступен ЦОД euNetworks (уровень Tier III) в Амстердаме.

Сетевые возможности, трафик и безопасность

В стоимость каждого сервера входит бесплатный выделенный IP-адрес. Клиенты могут выбрать между 100 Мбит/с с безлимитным трафиком или портом 1 Гбит/с с включёнными 32 Тб трафика.

Защита от DDoS-атак и система безопасности BitNinja для сервера и сайта доступны как подключаемые опции. Также предоставляются объектное хранилище S3, автобэкапы и Кибер-бэкап. Для безопасности коммуникаций используются SSL-сертификаты GlobalSign.

Управление, ПО и поддержка

При заказе сервера клиент получает лицензию ispmanager 6  lite: первый месяц панель предоставляется бесплатно, дальше оплачивается по тарифу самой панели. Предлагается гибкий выбор операционных систем, включая Linux, FreeBSD и Windows Server. Под разовые задачи доступны готовые рецепты установки — от Битрикс и GitLab до TeamSpeak, LAMP‑стека и других популярных наборов ПО.

Для установки и решения любых вопросов — доступна живая круглосуточная техническая поддержка 24/7 через чат на сайте, в личном кабинете и по телефону, без использования чат-ботов. Для самостоятельного решения вопросов предусмотрена обширная база знаний.

Клиентские бонусы и программы

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

1) При переходе от другого хостера FirstVDS бесплатно переносит до 10 сайтов. Дополнительно предоставляется скидка 40% на первый месяц аренды VPS при оплате сервера на 1, 3 или 6 месяцев, либо 3 месяца бесплатной аренды VPS при оплате на год.

2) Клиенты с возрастом аккаунта от 5 лет получают постоянную скидку на аренду VPS, начиная от 5% и увеличиваясь ежегодно до 20%.

3) Действует реферальная программа, по которой партнёр получает 10% от расходов привлечённых клиентов, а привлечённый пользователь — скидку 25% на первый месяц аренды VPS.

4) Стоимость продления домена у FirstVDS равна актуальной стоимости его регистрации.

3. InCloud: VPS‑площадки для бизнеса, где важен SLA

InCloud продаёт виртуальные серверы, работающие в отказоустойчивом кластере на базе enterprise хранилищ NetApp и HPE 3PAR. Позиционируется как решение для 1С, малого/среднего бизнеса и аутсорс компаний, которым нужны предсказуемые ресурсы и техподдержка профессиональных инженеров, а не чат‑ботов.

Тарифные планы и ценообразование

InCloud предлагает две основные линейки тарифов:

1. Стандартный тариф: внутри процессоры Intel Xeon 2600v4 2ГГц и оперативная память DDR4 2400 МГц.Стоимость: 1 CPU – 200 рублей, 1 Гб RAM – 200 рублей.
2. Производительный тариф: использует процессоры AMD EPYC до 3.8 ГГц и оперативной памяти DDR5 4800 МГц. Стоимость: 1 CPU – 250 рублей, 1 Гб RAM – 250 рублей.

Стоимость дискового пространства: SATA диски: 3 рубля за 1 Гб. SSD и NVMe диски: 13 рублей за 1 Гб.

Архитектура и поддержка

Теперь про то, что упрощает жизнь и добавляет надежности нашим развернутым сервисам:

• Ежедневные бэкапы: данные ваших серверов будут копироваться каждый день, и храниться они могут до 30 дней.
• Удобная панель управления: через нее можно делать снапшоты и клонировать серверы. Для разработчиков это просто золото – быстро накатить тестовую среду, попробовать новую фичу, а потом откатиться или создать идентичные рабочие среды.
• SLA-договор: есть возможность заключить SLA-договор, чтобы получить гарантированный уровень доступности услуг.
• Новейшие мощные серверы — на базе AMD EPYC 4 поколения.

Одна из фишек – это возможность напрямую проконсультироваться с сертифицированными инженерами InCloud по сложным проектам.

А что с клиентскими кейсами

1. Кейс Vamkamin: производственная компания, которая ускорила работу своей системы 1С и сократила IT-расходы на 35%. У них была проблема с медленной работой 1С при одновременном доступе бухгалтерии, склада и отдела продаж, а также с частыми простоями на локальных серверах. InCloud предложил перенести все сервисы в облако, используя серверы на базе AMD EPYC 9554, что обеспечило прирост производительности более 40% по сравнению с предыдущими решениями. Также были внедрены гибкое масштабирование ресурсов и ежедневное резервное копирование.
2. Кейс Веб-студии 100UP: компания занимается разработкой и поддержкой сайтов для крупных торговых сетей и e-commerce проектов. 100UP переехала к облачному провайдеру InCloud, выбрав тарифы на базе AMD EPYC 9554 с высокой тактовой частотой и большим количеством ядер. Благодаря разнообразию тарифов команда легко распределила проекты по нужным по производительности виртуальным серверам. После переезда 100UP смогла сократить время отклика клиентских сайтов в среднем на 45%, обеспечить бесперебойную работу даже в периоды высокой сезонной нагрузки, ускорить запуск новых проектов, фокусироваться на разработке и маркетинге и улучшить качество предоставляемых услуг.

4. SmartApe: быстрые VPS на NVMe‑SSD

SmartApe подойдет проектам, где дисковая подсистема и CPU работают без простоя: интернет‑магазины, порталы с большим количеством контента, внутренние корпоративные системы, высоконагруженные API. Если нужен быстрый старт — сервер создаётся за одну‑две минуты; если понадобится масштабирование, тариф можно увеличить без миграции.

Преимущества этих VPS

Используются современные серверные NVMe SSD диски в RAID массиве, которые в 600 раз быстрее обычных HDD. Скорость чтения достигает 8000 Мбайт/с, а записи — 2000 Мбайт/с.

Серверы работают на мощных процессорах Intel Xeon Gold или AMD EPYC (до 3.7 ГГц) и быстрой памятью DDR4. Используется полноценная виртуализация KVM с выделенными ресурсами для гарантии их предоставление. Дата-центры уровня TIER-III и TIER-IV обеспечивают Uptime 99.982%. Данные хранятся в хранилище RAID-10.

Дополнительно клиенты получают полный root-доступ (по SSH для Linux и RDP для Windows), возможность установки любых операционных систем (более 20, включая Ubuntu, CentOS, Debian, Windows Server) и ПО, а также полную изоляцию от других клиентов.

Удобство и поддержка

• Бесплатная панель управления (Hestia) или платная ISPmanager для простого управления сервером.
• Бесплатное базовое администрирование и помощь в переносе сайтов.
• Круглосуточная квалифицированная поддержка 24/7.
• Бесплатный тестовый период 10 дней без оплаты и ввода карты.
• Защита от DDoS-атак включена в стоимость.
• Выделенный внешний IP-адрес (возможность купить до 10 IP).

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

Пример использования: интернет‑магазин

VPS c 2 vCPU, 4 ГБ RAM, 80 ГБ SSD и портом 100 Мбит/с; при обычном трафике сайт обслуживает 300–500 уникальных посетителей в день, одновременно на страницах бывает 10–20 человек, а в пиковую распродажу до 50; средняя нагрузка 5–10 запросов в секунду, короткими всплесками до 20; заявленный аптайм 99,982 %, реальные замеры отклика после кэширования — 200–300 мс; счёт за такой сервер выходит около 1 300 рублей в месяц.

Пример использования: API на Node.js

4 vCPU, 8 ГБ RAM, 160 ГБ NVMe и канал 200 Мбит/с; сервис стабильно обрабатывает 50–100 запросов в секунду, на пике достигает 200, одновременно подключены 500–1 000 клиентов, максимум 2 500; трафик близок к 200 ГБ в месяц; при том же аптайме 99,982 % средняя задержка ответа укладывается в 50–100 мс; ежемесячная стоимость в зависимости от опций колеблется в диапазоне 2 600–3 000 рублей.

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

5. PSB Hosting: что даёт их VPS‑платформа

PSB Hosting продвигает VPS-хостинг как решение для сайтов, приложений и SaaS-сервисов, которым нужна предсказуемая мощность и высокий SLA. Провайдер делает упор на новое оборудование, пропускную способность без ограничений и инфраструктуру уровня Tier III+.

Локации и тарификация

Серверы разворачиваются в четырёх точках: Нидерланды, США, Германия и Финляндия. Для каждой площадки доступен одинаковый конструктор конфигураций. Базовый план NL‑100, который включает 1 vCPU, 2 ГБ RAM и 30 ГБ SSD, стоит 6 долларов в месяц. Линейка поднимается ступенчато:

Слайдеры позволяют довести параметры до 32 ядер, 64 ГБ RAM и 510 ГБ SSD; верхняя планка оплаты — 220 $ в месяц.

Трафик безлимитный на любых конфигурациях — дополнительной оплаты за гигабайты нет.

Аппаратная платформа, ОС и предустановки

В хост-узлах применяются процессоры последних линеек AMD и Intel. Оперативная память — DDR5, что снижает задержки при обращении к ОЗУ. Дисковая подсистема полностью на NVMe, объединена в RAID 10: чтение и запись выше, чем у классических SSD, а отказ одного накопителя не выводит хранилище из строя. К каждому VPS подключён выделенный канал с пропускной способностью до 10 Гбит/с.

Сервер можно поднять сразу с Windows Server, Ubuntu, Debian, CentOS или FreeBSD. Для быстрого старта доступны готовые образы: Bitrix, Django-стек, Docker, FastPanel, Hestia CP, Keitaro, LAMP, Node, OpenVPN, Outline, Portainer, Vesta CP и другие.

Управление и поддержка

Провайдер обещает круглосуточную техническую поддержку, резервные копии (бэкапы) и автоснапшоты. Для автоматизации предусмотрен API; в панели управления можно масштабировать ресурсы, перезагружать сервер и следить за статистикой.

Как выбрать VPS под свой проект

Для сайта с пиковыми нагрузками подойдёт SmartApe, где дисковая подсистема на NVMe-SSD в RAID-10 обеспечивает скорость чтения до 8000 Мбайт/с и записи до 2000 Мбайт/с, а сайт на конфигурации с 2 vCPU, 4 ГБ RAM и 80 ГБ SSD выдерживает 300–500 уникальных посетителей в день с пиком до 50 одновременных пользователей и нагрузкой 5–10 запросов в секунду (короткими всплесками до 20).

Если проект включает высоконагруженный API, например, на Node.js, то оптимален SmartApe с конфигурацией 4 vCPU, 8 ГБ RAM и 160 ГБ NVMe, которая стабильно обрабатывает 50–100 запросов в секунду (пики до 200) при 500–1000 одновременных подключениях (максимум 2500) и трафике до 200 ГБ в месяц.

Для задач с 1С, где важна стабильность и сокращение IT-расходов, выбирайте InCloud на базе AMD EPYC 9554: в кейсе Vamkamin это ускорило работу системы на 40%, сократило расходы на 35% и минимизировало простои, с ежедневными бэкапами до 30 дней и SLA-договором.

Если нужен VPS для Битрикс с высокой частотой CPU, подойдёт FirstVDS на AMD Ryzen (CPU.Турбо) с частотой до 5,7 ГГц и DDR5: скидка 30% на 3 месяца при покупке лицензии Битрикс, плюс отказоустойчивость на кластере Ceph с репликацией данных.

Для веб-студий с разработкой и поддержкой сайтов для e-commerce, где требуется распределение проектов по производительности и бесперебойная работа в сезонные пики, подойдёт InCloud на AMD EPYC 9554: в кейсе 100UP это сократило время отклика на 45% и обеспечило стабильность под высокой нагрузкой.

Если проект ориентирован на международный трафик с предсказуемыми ресурсами и высоким SLA, выбирайте PSB Hosting с локациями в Нидерландах, США, Германии или Финляндии, безлимитным трафиком и каналом до 10 Гбит/с на DDR5 и NVMe в RAID 10.

Для бэкенда мобильного приложения с нагрузкой до 12 000 уникальных пользователей в сутки (утилизация CPU 25%) подойдёт ИХЦ на NVMe/24 с 24 ГБ RAM и ~200 ГБ SSD, стеком nginx, PHP, MySQL.

Если развлекательный сайт с более чем 5000 уникальных пользователей в сутки (загрузка CPU ~20%), то подходит ИХЦ на NVMe/12 с 12 ГБ RAM и ~120 ГБ SSD, стеком nginx, Docker, Node.js. Он обеспечит стабильность с безлимитным трафиком и DDoS-защитой.

Выбор сводится к трём вопросам: где ваши
пользователи, какую пиковую нагрузку вы ждёте и нужен ли формальный SLA.
Сформулируйте эти требования заранее — и любой из пяти хостингов закроет задачу
без проблем в продакшне. Добавить свои рекомендации VPS хостингов — вы всегда
можете в комментариях, желательно описывать короткие кейсы.

1. Pandas

Pandas — библиотека для работы с данными в Python, позволяющая легко загружать, анализировать, очищать и преобразовывать числовую информацию в удобной табличной форме. По сути, это Excel, который смог, и позволяет делать всё автоматизировано и на порядки быстрее.

Библиотека строится вокруг двух ключевых структур: Series (одномерный массив с индексами); DataFrame (таблица с индексами и колонками).

Какие задачи решает библиотека

Pandas полезна для следующих задач:

• Сам анализ данных: можно быстро фильтровать, группировать, агрегировать и строить сводные таблицы.
• Очистка данных: удаляем пустые строки, заменяем значения, приводим типы.
• Загрузка данных из CSV, Excel, SQL.
• Визуальная разведка данных (EDA) перед построением моделей.
• Подготовка данных для ML и отчётов.
• Автоматизация отчётов и ETL-пайплайнов.

Благодаря Pandas аналитик превращается в инженера данных, а ML-специалист может сосредоточиться на моделях, а не на ручной подготовке датасетов.

Как пользоваться

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

Почему это меняет карьеру

Работа с Pandas становится границей между знанием Python и умением решать задачи бизнеса. Для джуна это шанс сразу показать практическую пользу: выгрузки, отчёты и базовый анализ можно делать в десятки раз быстрее и аккуратнее, чем вручную в эксельке.

Для аналитика Pandas превращается в главный рабочий инструмент, позволяя не просто проверять гипотезы и делать сводные таблицы, а строить полноценные отчётные пайплайны, автоматизировать рутинные выгрузки и концентрироваться на сути данных, а не на правках ручками.

Для ML-инженера владеть Pandas — значит уметь готовить датасеты качественно; быстро очищать и приводить данные к нужному виду, что напрямую влияет на результат моделей. Без этого работа над проектами машинного обучения часто превращается в бесконечную возню с данными.

Наконец, даже для разработчиков Pandas может стать неожиданным бустом в карьере. Например, когда нужно автоматизировать отчёты для бизнеса или быстро анализировать логи и данные из БД без поднятия дашбордов — Pandas даёт гибкость и скорость, которые редко даёт что-то ещё в экосистеме Python.

2. Django

Django — фреймворк для веб-разработки на Python, который позволяет быстро создавать надежные и масштабируемые веб-приложения. Он следует принципам DRY (Don’t Repeat Yourself — не повторяй себя), предоставляя разработчику ORM, роутинг, систему авторизации, админку, работу с формами, шаблонами и инструментами безопасности из коробки.

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

Какие задачи решает библиотека

Каркас, действительно, каркасный. Задачи следующие:

• Создание веб-приложений и API любой сложности.
• Быстрая разработка MVP, прототипов и коммерческих проектов.
• Упрощение работы с базами данных через ORM, без написания сырого SQL.
• Построение административных панелей для управления данными без ручной разработки.
• Гибкая маршрутизация и работа с формами, валидацией и шаблонами.
• Реализация аутентификации, авторизации и защиты приложений.

Django позволяет сосредоточиться на бизнес-логике и продукте, не тратить недели на настройку инфраструктуры.

Как пользоваться

Устанавливаем:

Создаем проект и приложение:

Пример модели:

Миграция базы данных:

Создание админки:

После этого можно запустить сервер:

И перейти по адресу http://127.0.0.1:8000/admin для управления записями через готовую админ-панель.

3. PyTorch

PyTorch — мощная библиотека Python. Она позволяет строить и обучать нейронные сети, проводить вычисления с автоматическим дифференцированием и работать с GPU для ускорения самих вычислений.

Главное отличие PyTorch от других ML-фреймворков — динамическая вычислительная графика (define-by-run): модель строится и изменяется во время выполнения кода, что даёт гибкость при создании и отладке сложных моделей.

Сегодня PyTorch используется в продакшен системах, научных исследованиях, компьютерном зрении, NLP и генеративных моделях, занимая ведущее место в индустрии.

Какие задачи решает библиотека

В функционал PyTorch входят:

• Построение нейронных сетей любой сложности (CNN, RNN, трансформеры);
• Обучение и тестирование моделей на CPU и GPU;
• Реализация кастомных слоёв и loss-функций;
• Разработка и деплой ML/AI моделей в продакшен;
• Быстрая итерация гипотез с удобной отладкой.

С PyTorch можно начать с простых нейронных сетей, а затем перейти к реализации современных архитектур.

Как пользоваться

Установим PyTorch (на CPU, для GPU потребуется версия с CUDA):

Рассмотрим кейс обучения простой нейронной сети для классификации рукописных цифр MNIST.

После обучения можно использовать torch.save() для сохранения модели и torch.load() для загрузки в продакшн.

Почему это меняет карьеру

PyTorch — билет в мир современной разработки AI и машинного обучения. Владение инструментом даёт разработчику возможность уверенно войти в области, которые продолжают оставаться топовыми на рынке: искусственный интеллект, компьютерное зрение, NLP, генерация изображений и видео и т.д.

Для начинающего ML/AI-специалиста PyTorch помогает лучше понять, как устроены нейронные сети, и под капотом увидеть, как происходят вычисления. Это ускоряет рост навыков и делает разработчика востребованным в исследованиях и R&D-проектах.

Для дата-сайентистов PyTorch позволяет превратить исследовательские ноутбуки в готовые к деплою модели, благодаря PyTorch Lightning, TorchScript и ONNX.

Для разработчиков, которые хотят выйти на рынок AI, PyTorch — это мастхев: проекты в стартапах и крупных компаниях всё чаще строятся вокруг него. Умение писать кастомные loss-функции, проектировать сложные пайплайны обучения, настраивать обучение на кластерах и GPU — компетенции, которые существенно бустят зарплату.

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

4. Polars

Polars — современная библиотека для обработки данных в Python, созданная как альтернатива Pandas. Она использует колоночную архитектуру и многопоточность, что позволяет работать с большими объёмами данных значительно быстрее и с меньшим потреблением памяти.

Polars вдохновлена Pandas, но её API оптимизировано для производительности и удобства, а также даёт разработчику возможность писать цепочки ленивых вычислений, которые оптимизируются перед выполнением. Это делает её отличным инструментом для аналитиков, дата-инженеров и дата-сайентистов, которым нужно обрабатывать данные быстро.

Какие задачи решает библиотека

Polars явно есть, чем гордиться:

• Загрузка, очистка и преобразование больших датасетов;
• Анализ данных с использованием цепочек преобразований;
• Быстрая агрегация и группировка данных;
• Ленивые вычисления: построение пайплайнов преобразования данных, которые выполняются только при вызове collect().
• Обработка данных, которые не помещаются в память, за счёт эффективности и колоночной архитектуры.

Если Pandas начинает притормаживаться на данных в несколько гигабайт, Polars обычно продолжает работать быстро, позволяя без боли обрабатывать большие CSV.

Как пользоваться

Установка:

Давайте загрузим данные и проведем базовые трансформации:

А вот и пример ленивых вычислений:

В чем особенность:

• pl.read_csv загружает данные сразу.
• pl.scan_csv создаёт план вычислений для последующей оптимизации.
• Используются выражения (pl.col, .with_columns, .agg), которые композируются без создания промежуточных копий, это ускоряет процесс.

Почему это меняет карьеру

Polars меняет карьеру, потому что даёт преимущество в скорости и эффективности при работе с данными. Там, где Pandas уже не справляется, полярный медведь приходит на помощь.

Для дата-инженеров Polars полезен при построении ETL и пайплайнов обработки данных, где важна скорость и предсказуемое потребление ресурсов. Его можно использовать в продакшен-скриптах, для подготовки данных к ML и для автоматизации отчётности.

Для дата-сайентистов Polars даёт возможность анализировать больше данных за меньшее время, быстро итерировать гипотезы и ускорять исследования. Его API достаточно близок к Pandas, поэтому переход не требует месяцев переучивания.

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

5. FastAPI

FastAPI — современный фреймворк для создания API на Python, заточенный под скорость, асинхронность и валидацию данных из коробки. Он построен на Starlette и Pydantic, автоматически создаёт OpenAPI-документацию, поддерживает асинхронное программирование и позволяет писать производительные REST и WebSocket API с минимальным количеством кода.

Вместо долгой настройки, как у Flask или Django, в FastAPI многое готово изначально: удобная работа с запросами и ответами, декларативная валидация, документация Swagger, асинхронность и высокая производительность без лишних усилий.

Какие задачи решает

Задач, действительно, много:

• Быстрая разработка REST API для мобильных и веб-приложений;
• Создание бэкенда для ML/DS моделей (деплой моделей в виде API);
• Построение микросервисов с хорошей производительностью;
• Реализация websocket-серверов и асинхронных API;
• Подготовка внутренних инструментов или бэкендов для MVP.

FastAPI помогает быстро запускать API и уверенно масштабировать его в полевых условиях. Это один из немногих фреймворков Python, который по скорости работы сопоставим с Node.js и Go.

Как пользоваться

Во-первых, нужно установить FastAPI и Uvicorn (используем ASGI-сервер для запуска):

Простейший API-пример с эндпоинтом GET /:

Запускаем сам сервер:

После запуска API будет доступен по адресу http://127.0.0.1:8000/. Автоматически доступна интерактивная документация Swagger по адресу http://127.0.0.1:8000/docs.

FastAPI поддерживает валидацию параметров запроса, тел запросов и путей прямо через типы Python. Например, простой эндпоинт с параметром:

При вызове http://127.0.0.1:8000/items/10?q=test FastAPI автоматически проверит, что item_id — это число, и распарсит q как строку.

Почему это меняет карьеру

FastAPI — билет в мир бэкенда, где скорость и чистота кода имеют довольно высокое значение. Для Python-разработчика это возможность быстро освоить создание API и микросервисов, не увязнув в громоздкой настройке, как в Django, и при этом получить систему, готовую к продакшену.

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

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

6. Typer

Typer — современная библиотека для создания CLI-приложений на Python с минимальным количеством кода и автоматической генерацией документации. Автор библиотеки — Себастьян Рамирес, создатель FastAPI.

Главная особенность Typer — использование type hints для автоматического парсинга аргументов командной строки. Вы получаете удобную и читаемую CLI с поддержкой автодополнения и цветного вывода за считанные минуты.

Какие задачи решает библиотека

Список задач такой:

• Создание CLI-утилит любого уровня сложности.
• Быстрое прототипирование и упаковка Python-скриптов в удобные инструменты для продакшена.
• Генерация подробной справки (--help) и автодополнения команд.
• Облегченная поддержка и масштабирование CLI за счёт структуры и читаемого кода.
• Организация CLI с подкомандами, вложенными аргументами и обработкой ошибок.

Typer использует аннотацию типов и минимум шаблонного кода.

Как пользоваться

Установка:

Пример минимальной CLI:

Теперь можно запустить из консоли:

Результат будет такой: Привет, Алиса! Тебе 25 лет.

Почему это меняет карьеру

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

С Typer можно быстро превращать свои Python-скрипты в надежные утилиты, которыми удобно пользоваться и другим разработчикам, и сотрудникам из других отделов. CLI-приложения часто становятся клеем инфраструктуры: они позволяют автоматизировать деплой, миграции БД, сбор данных, интеграцию с внешними API и локальную разработку.

Если вы Data Scientist или ML-инженер, Typer позволяет оборачивать пайплайны в CLI, которые легко запускать из Jenkins, Airflow или вручную. Если вы DevOps или Backend-инженер, можете создавать CLI для работы с инфраструктурой и сервисами без сложных зависимостей.

Кроме того, работа с Typer улучшает навык структурирования кода, понимание CLI, использования type hints и разработки инструментов, которые делают работу проще для других. А это, очевидно, ценится в любой команде и повышает востребованность специалиста.

7. Rich

Rich — библиотека Python для красивого форматирования и интерактивного отображения информации в терминале. С её помощью можно выводить цветные таблицы, маркдаун, прогресс-бары, подсвеченный синтаксис кода, деревья каталогов и логирование в понятной и привлекательной форме.

Rich создана для того, чтобы «оживить» консоль Python, сделать логи удобными для восприятия, а CLI-инструменты — профессионально выглядящими без лишних усилий. Это библиотека, которая улучшает и UX, и DX.

Какие задачи решает

Про красоту не забываем! Задачи следующие:

• Цветное и структурированное логирование, понятное при чтении логов в реальном времени.
• Отображение прогресс-баров для долгих операций.
• Вывод таблиц, деревьев каталогов, JSON прямо в терминале.
• Подсветка синтаксиса кода для CLI-инструментов.
• Создание CLI-интерфейсов, которые выглядят профессионально и современно.
• Улучшение читаемости при отладке скриптов.

С помощью Rich можно быстро сделать понятными даже сложные данные при отладке или демонстрации.

Как пользоваться

Установка Rich:

Для примера выведем таблицу с подсветкой в консоли:

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

Почему это меняет карьеру

Rich — это библиотека, которая помогает быстро повысить качество любого CLI-инструмента или дев-опыт в команде. Разработчик, который использует Rich, делает свои инструменты удобными не только для себя, но и для коллег: логирование становится понятным, а отладка скриптов — наглядной.

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

Кроме того, Rich позволяет быстро создавать CLI-интерфейсы, которые выглядят как продакшен-продукты, даже если это внутренние инструменты. Руководство будет радоваться и думать о вас как о крутом разрабе.

Для дата-инженеров и разработчиков DevOps Rich полезна при создании админ-утилит и при мониторинге пайплайнов, для Python-разработчиков — при создании библиотек и фреймворков с CLI.

8. LangChain

LangChain — фреймворк для создания приложений на базе LLM, например, GPT, Claude, Mistral, Gemini. Он позволяет строить цепочки обработки запросов, интегрировать LLM с данными и инструментами, добавлять память и управление состояниями, а также связывать работу модели с внешними API и базами знаний.

LangChain предоставляет удобный слой абстракции над вызовами LLM и ускоряет разработку чат-ботов, RAG-приложений, агентов с инструментами, систем анализа документов и других AI-сервисов.

Какие задачи решает

Список внушительный:

• Интеграция LLM в Python-приложения без необходимости писать тот самый клеевой код вручную.
• Построение цепочек с последовательной обработкой сообщений, включая преобразования и вызовы внешних функций.
• Добавление памяти в чат-боты для сохранения истории общения и контекста.
• Использование агентов для динамического вызова инструментов (веб-поиск, базы данных, API).
• Создание RAG-систем с интеграцией LLM и векторных БД.
• Быстрая сборка прототипов LLM-приложений, которые можно развернуть в продакшен.

Как пользоваться

Установка:

Создадим простую цепочку с чатом GPT:

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

Почему это меняет карьеру

LangChain меняет карьеру, потому что открывает новый пласт Python-разработки в AI и LLM-инженерии, быстро превращая пользователя GPT в создателя полноценных AI-приложений. Вместо того чтобы писать хаотичный клеевой код, вы начинаете системно проектировать цепочки запросов, учитесь строить продуманные промпты и объединять их с инструментами, памятью и внешними API.

Работа с LangChain погружает в практическую LLM-инженерию: вы начинаете создавать RAG-приложения, которые умеют искать и анализировать данные перед генерацией ответа и строить агентов. Это востребовано в продуктах, где нужно подключать ИИ к базам знаний, автоматизировать задачи и разрабатывать интерактивные системы, которые реально используют модели в продакшене.

LangChain позволяет быстро собирать и запускать MVP AI-продуктов, что дает конкурентное преимущество при создании стартапов или внутренних сервисов. А ещё учит мыслить структурами и проектировать масштабируемую архитектуру LLM-приложений и видеть, как генеративный ИИ можно превратить в рабочий инструмент.

9. SQLAlchemy

SQLAlchemy — это мощная ORM и toolkit для работы с базами данных в Python, позволяющая писать SQL-запросы декларативно, создавать модели таблиц и управлять транзакциями в Python-коде без ручного написания SQL.

Библиотека даёт разработчику два уровня контроля:

• Core: низкоуровневая работа с SQL выражениями и соединениями;
• ORM: высокоуровневая декларативная работа с моделями, классами и связями между таблицами.

SQLAlchemy поддерживает PostgreSQL, MySQL, SQLite, Oracle и другие СУБД, давая единую абстракцию, без привязки к конкретному движку.

Какие задачи решает

Пул задач следующий:

• Описание таблиц в виде Python-классов и управление ими через сессии;
• Создание, чтение, обновление и удаление данных;
• Миграция SQL на декларативный стиль без потери гибкости;
• Полный контроль над транзакциями и выполнением запросов;
• Работа с асинхронными приложениями при создании FastAPI/Django-приложений;
• Экранирование параметров, которое снижает вероятность SQL-инъекций и ошибок.

Как пользоваться

Создадим минимальный пример для SQLite с таблицей пользователей:

Этот код создаёт базу example.db, таблицу users, добавляет туда одного пользователя и выводит всех пользователей в базе. При необходимости можно использовать SQLAlchemy Core для написания гибких запросов вручную, если нужно работать ближе к SQL.

Почему это меняет карьеру

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

Знание SQLAlchemy открывает дорогу в мир API, микросервисов и продуктов, где требуется качественное управление данными и гибкая логика работы с БД. Работа с SQL теперь совсем не страшная.

10. Seaborn

Seaborn — библиотека для визуализации данных на Python, построенная поверх Matplotlib и упрощающая создание информативных и стильных графиков с минимальным количеством кода.

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

Библиотека тесно интегрируется с Pandas DataFrame, позволяя использовать колонки данных напрямую для построения графиков, что делает её идеальной для EDA (разведочного анализа данных) и подготовки визуализаций для отчётов и презентаций.

Какие задачи решает

Визуализация безумно важна, особенно в контексте дата-аналитики. Seaborn отвечает за:

• Быстрое построение информативных графиков для анализа данных и поиска инсайтов;
• Автоматическую обработку ошибок отображения и масштабирования, что экономит время;
• Поддержку сложных визуализаций по типу ящиков с усами или тепловых карт без десятков строк кода;
• Стилизацию графиков без ручных настроек Matplotlib;
• Возможность добавлять статистические элементы (линию регрессии, KDE, распределение);
• Интеграцию с Jupyter Notebook для интерактивного анализа данных.

Как пользоваться

Допустим, у нас есть датасет с данными о чаевых:

В три строки мы получаем чистый и читаемый ящик с усами, показывающий, как счет за ужин распределяется по дням недели.

Для построения более сложных графиков можно использовать диаграмму рассеяния:

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

Почему это меняет карьеру

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

Использование Seaborn в Python-стеке помогает выделиться среди разработчиков, которые ограничиваются Pandas и текстовыми логами, ведь визуализация часто позволяет быстрее заметить закономерности и убедить команду или заказчика в правильности гипотезы.

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

А какими библиотеками пользуетесь вы? Делитесь в комментариях!

Все началось, когда 38-летний Эрик сломал лодыжку во время пробежки. Лежа дома, он увидел в соцсетях истории о том, как люди запускали SaaS-проекты за выходные с помощью ИИ. Это вдохновило его на третью попытку освоить программирование.

Учеба без бюджета — только ИИ и бесплатные курсы

Эрик решил не тратить ни копейки на курсы. Он выбрал Python как основной язык и прошел CS50 от Гарварда — сначала курс по Python, потом по веб-разработке.

С ИИ он работал как с личным наставником: писал псевдокод, просил ChatGPT раскритиковать его, затем вручную набирал код. Синтаксис — по запросу. Такой подход позволил быстрее понять концепции, а не просто запомнить команды.

Свой первый проект он сделал по мотивам Wordle — игру на угадывание слов он реализовал на Python под названием PyWordle.

Затем собрал полноценное веб-приложение Make My Meal Plan: генерация рецептов, списки покупок, TailwindCSS, Django, PostgreSQL, CI/CD и даже тестирование через Playwright — все своими руками за 150 часов. Проект включал 25 000 строк кода.

Работа после 100 дней

Через 3 месяца обучения он получил оффер. Без Leetcode, без алгоритмических задач — только благодаря портфолио. Его взяли на испытательный срок в консалтинговую компанию в Лондоне, чтобы он заменил Excel и устаревшие тулзы на автоматизированные пайплайны.

Эрик честно рассказал, что научился программировать за пару месяцев и активно использовал ИИ — и все равно его приняли.

По его словам, весь путь стоил $120 — подписки на Claude Pro и Cursor. Все остальное — бесплатные курсы и открытые материалы. Недавно он прошел испытательный срок, получил повышение и теперь работает с геоданными и статистикой, используя pandas и ArcGIS. Параллельно пишет Django-приложение для анализа населения и доходов в Великобритании.

«Точно вовремя» вместо «на всякий случай»

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

Немного базы

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

• ReactJS на изи: что реально нужно знать фронтенд-разработчику в 2025 году — помогаем новичкам войти войти и показываем опытным разработчикам, что они могли упустить.
• Какие есть паттерны в React и для чего они нужны: часть 1 и Какие есть паттерны в React и для чего они нужны: часть 2 — здесь объясняем популярные архитектурные паттерны в React, когда и зачем их применять.
• 7 библиотек для анимаций на React / Tproger — собрали актуальные библиотеки для анимации в React; сравнение, демо и рекомендации.
• Типичные ошибки джунов, использующих React — показываем типичные ошибки junior-разработчиков в React, рассказываем, как писать чище и стабильнее.
• Подготовка окружения React-приложения: VSCode, Prettier, ESLint, Stylelint, Husky — рассказываем, как начать работу с приложениями на Реакте и что должно быть на рабочем столе.
• React Native против Flutter: что лучше (для общего развития) — сравниваем популярные фреймворки для кроссплатформенной разработки; плюсы, минусы и рекомендации.
• Deeplink в React Native: Полное руководств для новичков — рассказываем, что такое deeplink и как их писать на Реакте.

Практикуемся

• Современный Drag and Drop в React с помощью dndkit: создаем перетаскиваемое меню — здесь о том, как сделать меню, кнопки и все с помощью dndkit.
• Пишем приложение с бэкендом на Django и фронтендом на React — рассказываем, как создать REST API на Джанго, добавить React и объединить это в один проект.
• Создание ToDo-листа бесконечной вложенности на React, TypeScript и MobX — пошагово создаем вложенные задачи в ToDo-приложении, используем MobX, React и TypeScript.
• Создание Typing Test приложения на React + TypeScript + Redux Toolkit — учимся создавать приложение для проверки скорости набора текста, используем Redux Toolkit.
• Найди ошибку в React-компоненте: Функциональное Карри — практический кейс: ищем ошибку в React и заодно изучаем каррирование функций.
• Создание приложений для Windows на React Native — разбираем, как запускать и разрабатывать React Native-приложения под Windows, примеры и инструменты.
• Оптимизация графиков Recharts — ускоряем отрисовку графиков на React с помощью Recharts, практика, кейсы и улучшения.
• Как разработать своё первое приложение на React Native — инструкция по созданию первого мобильного приложения на React Native, от идеи до запуска.
• Пет-проект на React. Как мы «озвучивали» интернет — история реализации проекта с Web Speech API и React. Учим браузер говорить.

Кстати, похожий гайд мы уже делали — про Python. Можно заценить здесь.

Зачем компании собирают данные

Сегодня в интернете более 1 миллиарда сайтов. На великом и ужасном реддите каждый час появляется более 50 000 новых публикаций. На Github уже опубликовано более 300 млн публичных репозиториев. Всё это — открытые данные, которые можно использовать и, главное — собирать. Разумеется, перед этим проверить условия использования сайта, потому что некоторые из них могут запрещать сбор данных.

Зачем это нужно компаниям:

• Анализ рынка: для ритейла это возможность изучить клиентов и конкурентов.
• Мониторинг сайтов вендоров ПО: некоторые компании выкладывают уязвимости в своих продуктах и делятся возможными решениями.
• Создание продукта: собранные данные можно обогатить, прикрутить красивый интерфейс, умный поиск и предложить пользователю новое приложение, типа 2GIS.
• Развитие LLM: например, Google в 2024 году заключил контракт с Reddit на сбор данных. Open AI тоже часто говорят о том, что обучают свою модель на открытых источниках, а в ближайшее время хотят подключить ещё и транскрибации с YouTube.

Как вы поняли, в интернете очень много данных. И если мы хотим их собрать, то нам нужен подходящий инструмент.

Что такое Scrapy

Это высокоуровневый фреймворк на Python для краулинга и скреппинга сайтов. На GitHub у него больше 53 тысяч звёздочек, 10,6 тысяч форков и много глазиков. А ещё он занимает первое место по тегам #crawling и #scraping.

Есть много причин, почему Scrapy так популярен:

• Это фреймворк с готовой архитектурой — там много инструментов, доступных из коробки, которые можно настроить и использовать.
• Он асинхронный — чаще возникает задача замедлить его, чем ускорить.
• У него простые настройки — нужно всего раз подумать над архитектурой, а добавление новых источников будет занимать минимум времени.
• Scrapy удобно дебажить в любой момент, начиная от загрузки страницы и заканчивая сохранением данных в базе.
• Есть продуманные селекторы, доступны CSS, Xpath. Их можно комбинировать или выбрать что-то одно.
• Большое комьюнити и обновляемая документация. Ответы на большинство вопросов можно легко найти в сети.

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

Scrapy будет не лучшим выбором, если:

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

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

Как работает Scrapy

После того, как вы установили Scrapy в виртуальное окружение ( '' pip instal scrapy' ) и создали новый проект ( ' scrapy startprogect scraper '' ), вам необходимо написать своего первого «паука».

В Scrapy используется класс spider — он определяет, как мы будем извлекать данные из сайтов. Допустим, нам нужно собрать информацию с одностраничного сайта. Создаём класс TestSpider, наследуемся от scrapy.Spider, добавляем атрибут name с уникальным именем и start_urls, где укажем страницы, с которых нужно начать поиск. После этого переопределим метод parse.

Parse является дефолтным для обработки ответов. Если вы сделаете request и не укажете функцию, которая должна его обработать, то ответ от запроса придёт в метод parse. Поэтому его, как минимум, нужно переопределить и назначить логику.

Допустим, нас интересует информация о компании — название и описание. Можем создать объект данных с двумя элементами — title и content, и с помощью двух xpath селекторов забрать со страницы заголовок и описание.

В конце передаём этот объект данных для последующей обработки в ядро. Это всё, что нужно, чтобы начать парсинг на Scrapy.

Обработка данных в Scrapy

Дальше в ход вступает PipeLine. Он отвечает за обработку данных, валидацию или сохранение. В Scrapy есть пайплайны, готовые из коробки, но вы также можете написать их самостоятельно.

В ValidatePipeline мы проверяем объект данных на наличие title, а в SavePipeline — сохраняем объект в качестве json.

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

Зачем нужен Middleware

Middleware очень похож на PipeLine, только он обрабатывает не объекты данных, а запросы и ответы от сайта.

В Scrapy есть несколько разных middleware:

• scheduler middleware: помещает запросы в очередь и извлекает их для обработки.
• spider middleware: управляет данными между пауком и ядром.
• downloader middleware: управляет данными между ядром и загрузчиком.

Получается такая схема работы компонентов Scrapy:

Запрос: Spider → Spider Middleware → Engine → Scheduler Middleware → Scheduler → Engine → Downloader Middleware → Downloader → Server (сайт)

Ответ: Server → Downloader → Downloader Middleware → Engine → Spider Middleware → Spider → Item Pipeline → Storage (хранилище данных)

Скорее всего, в первую очередь вы будете настраивать downloader middleware, поэтому разберём его подробнее.

Ниже продемонстрировал два примера, как можно написать свой Middleware. В RandomProxyMiddleware мы обрабатываем все запросы, которые будет отсылать наш паук с помощью метода process_request (добавляем рандомную прокси к каждому реквесту), а в CheckCaptchaMiddleware — обрабатываем все ответы с помощью метода process_response (проверяем ответ от сайта, ищем в нём слово captcha).

Итак, мы написали Pipeline и Middlewares. Дальше нужно указать, как мы будем их использовать. Для этого запишите их в файле settings.py, где находятся настройки проекта.

Начнём с пайплайнов. Цифра справа — это порядковый номер выполнения. То есть первым будет ValidatePipeLine, а вторым сработает SavePipeline. Обычно цифры указываются от 0 до 1000. И в случае с пайплайнами чем ниже цифра, тем раньше сработает пайплайн.

В случае с middleware картина такая же, но логика немного иная.

Каждый middleware может обрабатывать как request, так и response. При этом middleware стоит посередине между ядром, который отправляет запросы, и загрузчиком. Если ваша middleware обрабатывает запросы, то сработает первой та, что указана с меньшей цифрой, потому что она ближе к ядру. А если middleware обрабатывает ответы, то первой будет та, у которой цифра больше, потому что она дальше от ядра и ближе к загрузчику.

Об этот нюанс часто спотыкаются новички, хотя, скорее всего, он прописан в документации.

Пример, как использовать Scrapy

Рассмотрим, как с помощью одного селектора собрать сайт любой вложенности и архитектуры.

Для начала создаём класс паука, наследуемся от scrapy.Spider, указываем name, start_urls и атрибут allowed_domains — он необязательный, но в данном случае без него не обойтись. В нём мы укажем список хостов, на которые разрешаем ходить нашему пауку, чтобы он не начал собирать другие сайты.

Дальше переопределяем метод parse и, когда к нам приходит ответ от сайта, находим все ссылки. И это и есть тот единственный xpath селектор, который поможет обойти весь сайт и собрать страницы.

Все ссылки помещаем в переменную url в качестве списка, а потом этот список передаём в функцию follow_all объекта response.

Чтобы дописать сохранение, просто передаём объект response вглубь ядра Scrapy, где напишем какой-то нехитрый пайплайн и будем сохранять html-страницы. Так можно собрать абсолютно любой сайт, просто подставьте ссылку на него в start_urls.

Важный нюанс: под капотом follow_all сделает запросы к сайту по всем ссылкам, которые мы нашли на странице. И поскольку в follow all мы не указываем определённый метод в параметре callback, то все ответы придут сюда же в метод parse (потому что он дефолтный в Scrapy). Эта логика будет повторяться на каждой странице.

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

Немного итогов

Scrapy — это большой, сложный, но очень хороший фреймворк, как Django в веб-разработке. Он предлагает большой выбор готовых инструментов для сбора и обработки данных, а также, поддерживает асинхронное выполнение задач, что ускоряет процесс парсинга.

Scrapy может показаться трудным для новичков, но у него есть богатая документация и примеры, поэтому при желании в нём нетрудно разобраться.

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

Случай с GitHub Copilot

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

После продолжительного поиска причины выяснилось, что Copilot автоматически сгенерировал следующую строку импорта:

На первый взгляд, этот импорт может показаться безобидным. Однако в Django классы TestCase и TransactionTestCase имеют разные поведения в отношении управления транзакциями:

• TestCase: оборачивает каждый тест в транзакцию и откатывает её после завершения, обеспечивая изоляцию тестов.
• TransactionTestCase: не управляет транзакциями автоматически, что полезно для тестов, зависящих от явного управления транзакциями.

Таким образом, импорт TestCase под именем TransactionTestCase привёл к тому, что тесты выполнялись с неверной семантикой транзакций, вызывая неожиданные сбои.

Почему такие ошибки трудно обнаружить?

Такие ошибки сложно выявить по нескольким причинам:

1. Автоматизация: Разработчики могут не замечать автоматически сгенерированные строки кода, особенно при быстром темпе работы.
2. Переименование: Использование ключевого слова as для переименования может скрыть истинную природу импортируемого объекта, вводя в заблуждение при чтении кода.
3. Доверие к ИИ: Разработчики могут чрезмерно полагаться на ИИ-помощников, не перепроверяя сгенерированный код, что увеличивает риск внедрения подобных ошибок.

Рекомендации для предотвращения подобных ошибок

Чтобы минимизировать риски, связанные с использованием ИИ-помощников, рекомендуется:

• Внимательно проверять сгенерированный код: особенно строки импорта и переименования.
• Понимать контекст: осознавать, какие классы и функции используются, и как они взаимодействуют в проекте.
• Ограничивать автоматизацию: использовать ИИ-помощников как вспомогательный инструмент, а не как основной источник кода.

Такой механизм реализован и на сайте Tproger: читатели не могут создавать, комментировать и лайкать посты, пока не пройдут аутентификацию.

Базовая аутентификация в Django

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

Установим фреймворк командой pip:

Создадим новый проект:

Создадим новое приложение для работы с аутентификацией:

Django уже содержит встроенную систему аутентификации. Она находится в приложении django.contrib.auth, которое по умолчанию включено в INSTALLED_APPS в файле settings.py.

Добавим приложение в список INSTALLED_APPS:

Добавление и настройка страниц для входа, регистрации и выхода

Используем встроенные формы Django, чтобы настроить аутентификацию. Сначала создадим поля для входа и регистрации в файле forms.py приложения myapp:

Код выше создает две формы: LoginForm для входа и RegisterForm для регистрации нового пользователя.

Форма LoginForm содержит два поля: username и password. Поле password отображается как поле ввода пароля с помощью виджета PasswordInput.

Форма RegisterForm наследуется от встроенной формы UserCreationForm и добавляет дополнительное поле email. В классе Meta указываем модель User и поля, которые нужно включить в форму.

Создадим представления для обработки запросов входа, регистрации и выхода. В файле views.py приложения myapp добавим код:

Код выше создает три функции представления: login_view, register_view и logout_view.

Функция login_view обрабатывает запрос входа пользователя. Для POST-запроса создается экземпляр формы LoginForm с переданными данными. Если форма валидна, извлекаются имя, пароль и выполняется аутентификация пользователя с помощью функции authenticate(). Если пользователь успешно аутентифицирован, выполняется вход login(), и пользователь перенаправляется на главную. Для GET-запроса, создается пустая форма LoginForm, которая передается в шаблон login.html.

Функция register_view обрабатывает запрос регистрации.

• Если это POST-запрос, создается экземпляр формы RegisterForm с переданными данными.
• Если форма валидна, новый пользователь сохраняется в базе данных с помощью метода save(), и перенаправляется на страницу входа.
• Если это GET-запрос, создается пустая форма RegisterForm, которая передается в шаблон register.html.

Функция logout_view обрабатывает запрос завершения сессии. Она вызывает функцию logout() для выхода пользователя, и перенаправляет его на страницу входа.

Создадим шаблоны login.html, register.html и добавим ссылку на выход в шаблоне base.html:

В шаблоне base.html добавляем условие {% if user.is_authenticated %} — оно проверит, авторизован ли пользователь. Если авторизован, отобразится приветствие и ссылка на выход. Если не авторизован, то появятся ссылки на страницы входа и регистрации.

Обновим файл urls.py приложения myapp, чтобы добавить маршруты для новых представлений:

Запустим сервер, чтобы протестировать вход и регистрацию:

Страницы размещаются по адресу http://localhost:8000/login/ и http://localhost:8000/register/ соответственно.

В Django также есть встроенные классы представлений для аутентификации, такие как LoginView и LogoutView. Чтобы использовать их, обновим файл urls.py приложения myapp:

Заменили функцию представления login_view на класс представления LoginView и указали шаблон login.html. Аналогично, заменили функцию представления logout_view на класс представления LogoutView и указали страницу, на которую будет перенаправлен пользователь после выхода (next_page='login').

Управление доступом с помощью авторизации

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

Для использования декоратора @login_required обновим файл settings.py и укажем URL-адрес для перенаправления неавторизованных пользователей:

Теперь в файле views.py приложения myapp добавим следующий код:

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

Создадим шаблон home.html в директории templates приложения myapp:

Добавим путь для главной страницы в файле urls.py приложения myapp:

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

В Django есть система разрешений (permissions) для расширенного управления доступом. С их помощью можно определять, какие действия могут выполнять пользователи или группы пользователей.

Создадим группу и назначим ей разрешения. В файле admin.py приложения myapp добавим следующий код:

Создадим функцию представления, которая будет доступна только пользователям с определенным разрешением. В файле views.py приложения myapp добавим код:

Создаем функцию представления special_page_view, которая отображает специальную страницу. Применяем декоратор @permission_required к этой функции и указываем необходимое разрешение myapp.view_special_page. Только пользователи или группы с этим разрешением смогут получить доступ к данной странице.

Создадим шаблон special_page.html в директории templates приложения myapp:

Добавим маршрут для специальной страницы в файле urls.py приложения myapp:

Теперь только пользователи или группы с разрешением myapp.view_special_page смогут получить доступ к специальной странице.

Расширение модели пользователя

Можно создать собственную модель пользователя, наследуя от AbstractUser или AbstractBaseUser.

Давайте ассмотрим создание кастомной модели пользователя с помощью AbstractUser. В файле models.py приложения myapp добавим код:

Создаем класс CustomUser, который наследуется от AbstractUser. Добавляем дополнительные поля phone_number и address к модели пользователя.

Обновим файл settings.py и укажем кастомную модель:

С этого момента система аутентификации будет использовать кастомную модель пользователя вместо встроенной модели User.

Создадим миграции и применим их для обновления базы данных:

Для работы с кастомной моделью нужно обновить формы. В файле forms.py приложения myapp изменим поля регистрации:

Создаем класс CustomUserCreationForm, который наследуется от UserCreationForm. Добавляем поля phone_number и address к форме и указываем кастомную модель CustomUser в классе Meta.

Чтобы система аутентификации приняла изменения, обновим функцию представления register_view в файле views.py:

Меняем форму UserCreationForm на кастомную форму CustomUserCreationForm. Теперь Django работает, используя собственную модель пользователя с дополнительными полями во всем проекте.

Социальная аутентификация

Для реализации входа через сторонние сервисы есть библиотека django-allauth. Она предоставляет готовые решения для интеграции с провайдерами социальной аутентификации.

Установим библиотеку django-allauth:

Добавим django-allauth в список установленных приложений в файле settings.py:

Добавляем приложения django.contrib.sites, allauth и провайдеры социальной аутентификации, которые хотим использовать. В нашем случае это интеграция Google.

Также устанавливаем значение SITE_ID = 1, чтобы указать идентификатор сайта.

Добавим URL-адреса для django-allauth в файле urls.py проекта:

Включаем URL-адреса django-allauth с префиксом accounts/.

Выполним миграции для создания таблиц в базе данных:

После этого можно настраивать провайдеров социальной аутентификации через административный интерфейс Django.

Добавим кнопки для социальной аутентификации на страницу входа. В шаблоне login.html добавим следующий код:

Добавляем ссылки на страницы регистрации через социальные аккаунты, используя URL-адреса socialaccount_signup с указанием провайдера. Теперь пользователи могут войти на сайт, используя свою учетную запись Google.

Безопасность аутентификации

Рекомендации по повышению безопасности аутентификации:

• Настройте SSL/TLS-сертификат для сайта для безопасного соединения между клиентом и сервером. Используйте протокол HTTPS для всех страниц, где есть аутентификации и передача конфиденциальных данных.
• Система на Django работает со встроенной защитой от межсайтовой подделки запросов (CSRF). Убедитесь, что в шаблонах форм используется тег {% csrf_token %}.
• Экранируйте пользовательский ввод перед его выводом на страницах сайта, чтобы защититься от межсайтового скриптинга (XSS). Django автоматически экранирует переменные в шаблонах, но будьте осторожны при явном выводе HTML.
• Для защиты от атак методом перебора (брутфорса) ограничьте количество неудачных попыток входа для каждого пользователя или IP-адреса. Используйте библиотеки django-axes или django-ratelimit, чтобы реализовать ограничения числа попыток входа.
• Никогда не храните пароли в открытом виде — вместо этого используйте хеш-функции. В Django есть встроенные функции для хеширования паролей: django.contrib.auth.hashers.make_password() и django.contrib.auth.hashers.check_password().
• Возможно, стоит реализовать двухфакторную аутентификацию, чтобы повысить безопасность учетных записей. Используйте библиотеки django-two-factor-auth или django-otp для добавления 2FA.

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

Возможности

Django — это «‎все включено» фреймворк, который предлагает множество встроенных функций: система аутентификации, админ-панель, управление базами данных и многое другое. Это делает его идеальным выбором для создания сложных приложений с минимальными усилиями на настройку. Он также следует принципу «‎не повторяйся» (DRY), что упрощает повторное использование кода.

Основные возможности Django:

• Полноценный ORM позволяет работать с базами данных без необходимости писать SQL-код.
• Автоматически генерируемый веб-интерфейс для управления моделями данных.
• Система маршрутизации упрощает настройку URL и маршрутов.
• Есть встроенные механизмы защиты от общих веб-угроз: CSRF, SQL-инъекции и т.д.
• Масштабируемый, подходит для больших проектов и команд.

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

Его особенности:

• Основной функционал минимален, скорее предоставляет базу для расширений.
• Можно легко интегрировать сторонние библиотеки для специфических нужд.
• Использует Jinja2 для создания гибких и мощных интерфейсов.
• Удобные инструменты для создания API-сервисов.
• Возможность тонкой настройки конфигураций приложения.

Например, как можно интегрировать во Flask сторонние библиотеки для решения конкретных задач:

В коде используем библиотеку requests для выполнения HTTP-запросов к внешнему API. Flask позволяет легко добавлять функции, как, например, эндпоинт для вычисления без необходимости сложных настроек и конфигураций. Разработчик может выбрать любые библиотеки и инструменты в зависимости от потребностей проекта.

Выбор между Flask и Django во многом зависит от требований проекта: если вам необходимо быстрое создание сложного приложения, Django может быть удобнее. Если же вам нужно создать что-то более простое или экспериментальное, Flask станет отличным выбором.

Скорость разработки

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

Django

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

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

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

Flask

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

Также Flask ориентирован на тестирование, и его простая конфигурация дает возможность быстро запускать и проверять отдельные компоненты приложения. Это полезно для опытных разработчиков, которые часто работают с TDD (разработка через тестирование).

А одно из главных преимуществ Flask — он хорошо подходит для создания MVP. Временные ограничения или необходимость быстро проверить концепцию делают Flask идеальным выбором.

Поддержка асинхронных операций

С поддержкой асинхронного программирования ситуация выглядит иначе.

Django

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

Вот пример кода, который показывает создание асинхронного представления в Django. Здесь пишем асинхронное представление AsyncExampleView, которое использует async и await для выполнения асинхронных операций.

Flask

Flask изначально не задумывался как асинхронный фреймворк, но с помощью расширения Flask-SocketIO можно реализовать асинхронное поведение. Также существуют фреймворки FastAPI и Sanic, которые лучше подходят для высоконагруженных асинхронных приложений. Следовательно, если асинхронные операции являются приоритетом, Flask с дополнительными библиотеками может стать правильным выбором, хотя более специализированные решения будут более уместными.

А вот пример кода — использование Flask с расширением Flask-SocketIO для реализации асинхронного поведения. Функция handle_message является асинхронной и использует await для задержки:

Что выбрать?

Как и всегда, выбор между Django и Flask зависит от конкретных потребностей вашего проекта. Если вы ищете мощный, готовый к использованию фреймворк для создания больших приложений, которые быстро развиваются, Django станет топовым выбором. Если же вам нужна легкость, гибкость и возможность поэтапной сборки приложения — смело выбирайте Flask.

Оба фреймворка имеют свои сильные и слабые стороны. Главное — определить, какие приоритеты имеют значение для вашего проекта.

Популярность и востребованность

Вакансии на рынке труда

Начнем с самого важного. Количество вакансий с упоминанием фреймворка напрямую отражает, насколько просто будет найти/сменить работу в том или ином стеке.

Стоит иметь ввиду, что на многие позиции рассматривают разработчиков с опытом или Django, или FastApi (выглядят, как «опыт работы с Django/FastAPI»), так что точно понять, сколько проектов на одном фреймворке, а сколько на другом, затруднительно.

На российском рынке труда FastAPI на конец 2024 года в итоге смог обогнать Django по количеству вакансий. Вот цифры с HeadHunter:

Ровно год назад Django опережал FastAPI в два раза. Сейчас отрыв небольшой, но есть все основания полагать, что он будет увеличиваться.

Для разработчиков уровня junior ситуация в целом одинаковая:

Кратко об используемых фильтрах:

• Уровень дохода: любой
• Регион: Россия
  
• Опыт: не имеет значения
  
• Ключевые слова: в названии вакансии, в названии компании, в описании вакансии.
  

GitHub-звёзды

Косвенный критерий «популярности» фреймворка в мире.

• Django: 80,998 звёзд.
  
• FastAPI: 77,700 звёзд.

Учитывая немалый возраст Django, он практически наравне с FastAPI.
За год Django прибавил 15% (было 70 тысяч звёзд), а FastAPI — около 25% (было 60 тысяч звёзд). Так что можем сделать вывод, что FastAPI выходит вперед не только на нашем рынке.

Особенности фреймворков

Django: держи всё сразу, даже если не нужно

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

Работа с миграциями в Django вместе с DjangoORM помогает научиться работать с базами данных без лишних страданий. Так же в мире Django преобладает синхронный код, так как асинхронность доступна с ограничениями. Автоматическая документация, которую так часто ставят в плюс FastAPI, подключается за 15 минут с помощью drf-spectacular.

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

FastAPI: гибко, но пустовато

FastAPI менее регламентирован, что позволяет разработчикам выбирать подходящую архитектуру самостоятельно. Стартуем с одним файлом, так что есть манёвр и для творчества, и для костылей:) Лучше найти готовые шаблоны проекта на GitHub.

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

Многие проекты на FastAPI используют микросервисы. Также с таким стеком чаще всего встречаются хайлоад-проекты.

Что будет дальше?

FastAPI набирает популярность, и это уже не остановить. Основные причины:

1. Выше производительность, чем у Django. Здесь дает преимущество асинхронность. Разница может быть в 5 раз и более.
   
2. Лёгкий и минималистичный. Лучше вписывается в концепцию микросервисов. Django в микросервисы никто не тащит (я надеюсь).
   
3. Быстрее развивается. В FastAPI всего около 20к строк кода. Тем временем разработчикам Django приходится тащить за собой 300к строк кода.
   

Всё это приводит к тому, что Django постепенно теряет позиции. Тренд продолжится и дальше, а его итоги подведём ближе к декабрю 2025 года.

Заключение

Еще год назад я бы без раздумий всем начинающим порекомендовал Django. Но сейчас выбор становится очень сложным. С одной стороны, Django намного лучше подходит начинающим, с другой стороны, количество вакансий продолжит снижаться. Через год отрыв может быть 3 к 1 в пользу FastAPI.

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

Чтобы оставаться на связи, приглашаю в свой telegram-канал. Пишу про разработку интересно и без воды :)

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

Поддержка тестов Django и расширение для Python

Visual Studio Code продолжает расширять возможности для Python-разработчиков. В версии 1.93 появилась полноценная поддержка модульных тестов Django, что значительно упрощает процесс тестирования для тех, кто работает с этим фреймворком.

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

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

Улучшение IntelliSense в браузере

Одна из самых ожидаемых функций — улучшение поддержки IntelliSense на платформе vscode.dev.

У JavaScript- и TypeScript-разработчиков появилась возможность использовать автодополнение и подсказки прямо в браузере. Это особенно полезно для тех, кто работает на устройствах с ограниченными возможностями, не позволяющими установить полноценную IDE.

Работа с контейнерами и Dev Containers

В свежем апдейте значительно улучшены функции работы с контейнерами. А значит и процесс разработки в изолированных средах стал проще.

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

Прочие нововведения

Не обошлось и без общей оптимизации. Улучшена производительность, устранены баги, а интерфейс стал ещё более отзывчивым.

Также в обновлении были исправлены проблемы с зависаниями и улучшена работа с расширениями. Появилась поддержка новых функций для работы с крупными проектами, что сделало Visual Studio Code ещё более мощным инструментом для профессиональных разработчиков.

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

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

Django как инструмент для быстрого старта

Только по данным ресурса Хабр Карьера на июнь 2023 года, Django входил в топ-8 по вакансиям. Популярность фреймворка легко объяснима.

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

2. Огромный объем материалов от сообщества и разработчиков. Например, отличная официальная документация на английском. Или на русском.

3. Фреймворк — это коробка с батарейками, которая решает большинство функциональных задач.

4. Множество готовых решений, которые можно интегрировать с вашим проектом.

Именно это позволяет быстро создать рабочее решение на Django. Особенно если предыдущее решение стало недоступным из-за санкций.

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

1. В большинстве случаев квалификации программиста на Django недостаточно для того, чтобы в срок и качественно решить задачи бизнеса.

2. Батарейки Django зачастую работают не так, как нужно, проигрывая наивным самописным решениям.

3. Готовые расширения Django либо слишком велики для решения локальных задач, либо создают проблемы в зависимостях. Кроме того, они могут создавать риск для безопасности инфраструктуры.

Проблемы Django Admin

Один из проектов в нашей компании создан с помощью Django.

В процессе работы мы столкнулись с некоторыми болевыми точками фреймворка, о которых стоит рассказать.

Django представляет собой готовое решение, но не все его компоненты подходят для Production. Например, Django Admin позволяет сэкономить время на написании собственной контрольной панели. В теории. На практике вы столкнетесь с тем, что схема данных в БД отличается от представления формы для редактирования данных.

Например, в БД есть поля типа Interval и Boolean. Запись может иметь срок действия (после наступления которого запускается какая-то проверка), может быть бессрочной (поле Boolean) либо не имеет ни срока, ни признака бессрочного действия (проверка запускается вручную). Первая проблема, с которой вы столкнетесь при реализации, — это отсутствие в Django ORM поля модели, которое полностью эксплуатировало бы тип данных Interval. Вторая проблема состоит в необходимости написания формы для «админки», чтобы пользователь заполнял одно поле, а не два одновременно. Разумеется, подобные проблемы в энтерпрайзе давно решаются отказом от Django Admin в пользу DRF + SPA.

Еще одна существенная проблема Django Admin — это отсутствие оптимизации запросов по умолчанию. Впрочем, учитывая особенности архитектуры компонента (с шаблонизатором), оптимизировать запросы простыми способами не получится. Так что решение так или иначе будет тормозить, если у вас много связей и данных.

Так мы постепенно приблизились к главной «батарейке» Django и к ее главной болевой точке — ORM.

Анализ запросов к БД, созданных Django ORM

Прежде чем понять, как нам могут угрожать запросы к БД, предлагаю научиться анализировать их, используя ORM Django.

Рассмотрим пример, который никогда не существовал в реальности. Файл models.py, которого никогда не было:

Давайте составим запрос на получение всех заводов группы Glam Metal:

Запуск этого кода внутри консоли современной IDE позволяет произвести анализ переменных (дебаг):

Посмотрите: переменная glam_metal_factories — это экземпляр класса QuerySet. Это тот самый механизм «ленивых» запросов Django ORM. Сначала мы получаем экземпляр класса QuerySet, потом, если, например, обратиться к первому элементу выборки или запустить цикл for, запрос уйдет в БД.

Но сейчас нас интересует свойство query. Это экземпляр класса Query, но его репрезентативный дандер-метод возвращает запрос, который будет выполнен в БД, если мы сделаем обращение к ней.

Если у вас нет под рукой дебагера, можно сделать так:

И мы получим вот такой результат:

Помните: важным умением для разработчика Django является анализ SQL-запросов. Давайте разберемся почему.

Первые проблемы

Итак, у нас есть три модели. У нас есть запрос, который получает только заводы, входящие в группу Glam Metal. Этого мало, чтобы построить приложение. Ведь приложением пользуются люди, и для них наши Frontend-разработчики подготовили приятный пользовательский интерфейс на JavaScript.

Интерфейс связывается с Backend посредством REST API. В качестве «батарейки» для REST мы используем Django Rest Framework (в простонародье DRF).

Давайте представим, что у нас есть некий эндпоинт, который возвращает только заводы группы Glam Metal. Только список. Нам потребуется следующий модуль serializers.py:

А также представление во views.py:

Теперь нам потребуется занести в систему некоторое количество заводов. Не будем мелочиться и заведем сразу 5000. Для этого воспользуемся библиотекой Factory Boy:

Выполним:

И дождемся окончания операции.

Здесь мы предполагаем, что в системе есть пользователь с id=1. На самом деле под пользователя тоже лучше завести фабрику.

Итак, открыв в браузере наш API, мы увидим следующее:

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

Так мы сталкиваемся с первой проблемой оптимизации запросов в Django ORM: она по умолчанию выбирает все поля!

Усложняем задачу

Нам пришла доработка: мы должны выводить список всех контактных лиц (их телефоны), а также ФИО пользователя, которые хранятся в модели User. Также мы должны вывести имя группы заводов, чтобы в следующей доработке сделать поле group_name динамическим — будем его прокидывать в Query Params.

Модернизируем serializers.py:

Обратите внимание на метод get_full_name. Он ссылается на property fio, которое программист создал для модели User, чтобы не повторять фрагмент кода для получения ФИО в разных местах. Выглядит это свойство так:

Мы получили результат:

Задачу можно закрывать? На самом деле нет. Все только начинается.

Используем Django Debug Toolbar

Если вы спросите у опытного джангиста, как он проверяет запросы к БД, он, скорее всего, скажет о Django Debug Toolbar. И не ошибется, поскольку это достаточно мощный инструмент для определения того, что делала Django прежде, чем отдать пользователю ответ.

Посмотрите: у нас вышло 5839 запросов. Притом что заводов группы Glam Metal всего 834:

Открыв детализацию SQL-запросов, мы увидим вот такую картину:

Одной из ключевых особенностей Django Debug Toolbar является группировка одинаковых запросов (similar queries):

Открыв детальную информацию по группе, мы можем просмотреть Traceback вызовов, которые привели к появлению этой группы:

В нашем случае, если источником проблемы является to_representation модуля serializers, то мы говорим об известной проблеме n+1. Дело в том, что в момент, когда мы пытаемся получить данные из связанной модели, ORM отправляет еще один запрос.

Как вы видите, при выводе списка ситуация становится критической. Но мы можем исправить это, добавив для всех связей ForeignKey/OneToOneField правило select_related():

Посмотрите, как изменился оригинальный запрос:

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

Еще мы можем сократить число выбираемых полей, используя .only() и .defer():

Давайте обновим страницу с Debug Toolbar и посмотрим, как изменилась статистика:

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

На этот случай Django ORM имеет реализацию паттерна Prefetch:

Давайте попробуем:

Если вы посмотрите на SQL-запрос, который порождает эта инструкция, то увидите, что он не отличается от предшественника. Зато, обновив страницу, увидите это:

Уже неплохо, но куда делись 833 запроса (что на единицу меньше 834 — общего числа наших записей?

Вот они. Django выполняет алгоритм Prefetch в точности: сначала запрашивает заводы, потом отдельным запросом «вытаскивает» всех контактных лиц. А уже объединение этих данных происходит на стороне python.

Осталась последняя проблема: необходимо избавиться от запросов к User.

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

Посмотрим на результаты:

Два запроса, которые были выполнены за 30,44 мс. Посмотрим на запросы:

Итак, у нас было 5839 запросов к БД, которые исполнялись на локальной машине 9291,13 мс. Используя Django Debug Toolbar, мы выявили проблемную область и сократили число запросов до двух, а время выполнения — до 30,44 мс.

Тонкости Django

К сожалению, описанная выше проблема встречается в разработке на Django очень часто, поскольку джангисты недолюбливают чистый SQL и игнорируют оптимизацию запросов. Django ORM очень далека от SQL и использует абстракции, непохожие на операторы этого языка. Так, мы видим, что для ограничения полей, выбираемых в SELECT, нам приходится использовать необязательные методы .only()/.defer(). А join’ами мы вообще не можем управлять напрямую (как, кстати, и операцией group_by()).

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

Также могу посоветовать разработчикам на Django, если они используют Pytest, обратить внимание на пакет pytest-django-queries, который предоставляет фикстуру, показывающую количество и состав запросов в БД. Фикстура подключается всегда с обнуленным счетчиком, что позволяет использовать ее как на этапе создания тестовых данных, так и на этапе запуска кода.

Послесловие: о чем мы не успели поговорить?

К сожалению, проблемы ORM — это не единственный недостаток Django. Выше мы видели, как программист использовал property внутри модели, чтобы внедрить в нее бизнес-логику и показать ФИО пользователя. Подобные решения зачастую приводят к ситуации, когда количество запросов к БД растет не из-за отсутствия select_related/prefetch_related, а из-за того, что обращения к БД разбросаны по всему коду. В этом случае исправление архитектурных проблем может затянуться.

При всей своей простоте Django очень чувствительна к организации кода и к архитектурным ошибкам.

Еще один интересный момент — это слабая поддержка асинхронного программирования. Нет, сама Django поддерживает асинхронные операции. Проблема состоит в «батарейках» Django, которые не всегда догоняют коробку по поддержке тех или иных фич. Например, тот же DRF поддерживает async только при добавлении новых зависимостей: adrf или Django-rest-framework-async. Однако ситуация остается проблемной потому, что Serializers не поддерживают async при обращении к .data. И это вынуждает нас использовать иной подход к архитектуре решения. Например, вводить слой Use-Cases, чтобы передавать в Serializers уже подготовленные данные и выносить формирование QuerySet из слоя представлений, где ему не место.

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

Также для Serializers Django лучше заменить движок json на ujson или orjson. Использование простого Serializer вместо ModelSerializer может поднять производительность (но, скорее всего, потребует ввода паттерна Repository для предварительного перевода данных в более простой формат).

В общем, Django — хороший фреймворк. Для средних проектов. Для маленьких он слишком большой. Для больших он слишком медленный и содержит слишком универсальные решения, которые наверняка придется переписывать.

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

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

Гайд написан владелицей Django-сайта. Если вам интересно, как пересесть с nocode-CMS вроде WordPress на самописную админку, посмотрите эту статью.

Универсально для всех фреймворков

Даже если не все инструменты понятны и нужны сразу, сохраните этот листинг в закладки: тогда тулы вроде gunicorn станут «на вырост».

• pillow: библиотека для работы с изображениями.
• psycopg: один из лучших адаптеров PostgreSQL для Python.
• python-dateutil: расширение для стандартного py-модуля datetime.
• boostrap-icons: npm-пакет с иконками, прикручиваемый к HTML-темплейту.

• tzdata: утилита с информацией о временных зонах.
• urllib3: для выполнения запросов к веб-серверам.
• requests: одна из самых популярных библиотек для HTTP-запросов на Python.
• sqlparse: форматирование и парсинг SQL-запросов.
• text-unidecode: транслитерация из Unicode в ASCII.

• pandas: библиотека для работы с табличными данными.
• certbot: бесплатные SSL-сертификаты.

• plotly: дизайнерские графики с тонкой настройкой почти любого аспекта.

• FastAPI: современный, быстрый веб-фреймворк для создания API.
• pytest: быстрее способа писать тесты для ваших функций просто нет.
• gunicorn: сервер для запуска Python веб-приложений.

• six: библиотека для совместимости кода между Python 2 и 3.

• PyYAML: человекочитаемый формат конфигов.

Для подобных файлов Python нужен отдельный коннектор

• wheel: ускоряет установку библиотек и модулей.
• charset-normalizer: управляет кодировкой текста.

Помимо прочего, обеспечивает совместимость с разными браузерами и спасает от вредоносного кода, отправляемого через формы.

• idna: обработка доменных имен с интернациональными символами.

• typing-extensions: аннотация типов для разных версий Python.

Инструмент позволяет, например, на Python 2, использовать аннотацию типов крайней версии языкового пакета.

• cryptography: шифрование, хэширование — защита ваших данных от третьих лиц.

Прочитать зашифрованное сообщение без «ключа» у хакера не получится.

• fsspec: унифицирует обращение с файлами вне зависимости от ОС.
• MarkupSafe: безопасное отображение HTML/XML-текста.
• python-slugify: создание коротких дружелюбных URL.

Django-мастхэв

• django-tailwind: интеграция CSS-фреймворка Tailwind с Django.
• django-tinymce: интеграция WYSIWYG-редактора TinyMCE.

• django_mathjax: пакет для встраивания MathJax.

Вжух! И читатель увидит следующее:

• django-orm: переключение между SQLite и PostgreSQL.
• django-js-asset: управление зависимыми от JavaScript файлами.

Заключение

Стоит признать: подбор стека — задача не для новичков. Пока начинающий веб-разработчик только-только справляется со стандартными для сайта фичами, вроде форм обратной связи и картинками с CDN-ссылок, оперативной памяти мозга на выбор библиотек, как правило, не остается. Вы можете воспользоваться предложенными в статье общепринятыми решениями, однако функционал моего блога и вашего проекта наверняка различаются. Списка выше будет недостаточно.

В такой ситуации полезны LLM: ChatGPT и прочие ассистенты даже с меньшим числом параметров справляются с выдачей общепринятых решений «на пять». Так что начинаем с проверенного комьюнити решения по умолчанию, и только потом, когда ощутим свободу и желание экспериментировать, пробуем менять pandas на polars.

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

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

Какие методы и инструменты вы используете для улучшения безопасности? Есть ли у вас конкретные примеры, где внедрение CSP действительно оправдало себя?

Вот, о чём говорится в ролике:

1. Спикер сравнивает Node.js и Django для разработки веб-приложений.
2. Node.js – это инструмент для выполнения JavaScript на сервере, позволяющий писать код для бэкенда и фронтенда на одном языке.
3. Django – это фреймворк для веб-разработки на Python, следующий принципам ‘не повторяй себя’ и ‘всё включено’.
4. Node.js обладает событийно-ориентированной архитектурой и подходит для приложений требующих реального времени, таких как чаты или игры.
5. Django использует систему ORM для работы с базами данных и подходит для масштабных приложений с большим количеством пользователей.
6. Node.js имеет преимущества в управлении асинхронными запросами и масштабируемости, но может столкнуться с трудностями при тяжелых вычислениях.
7. Django предлагает удобную админку и безопасность ‘из коробки’, но может быть не так хорош в мелкомасштабных проектах и не умеет обрабатывать множество запросов одновременно.
8. Node.js имеет большое сообщество и обширный набор готовых модулей через NPM, в то время как Django также имеет сильное сообщество, но его экосистема модулей не так велика.
9. Выбор между Node.js и Django зависит от конкретных требований проекта и личных предпочтений разработчика.
10. Карьерные перспективы для разработчиков Node.js и Django выглядят обнадеживающе, с высоким спросом и конкурентоспособной заработной платой в обоих направлениях.

Ниже — транскрибированный перевод ролика на русском языке.

Сегодня нет сомнений в том, что Node.js и Django – это оба потрясающие технологии для работы с веб-приложениями. У них обоих есть мощные преимущества и отличные функции.

Но если вы хотите выбрать для изучения только одну, всегда возникает вопрос, какую выбрать. Меня зовут Даниэль, и сегодня мы сравним Node.js и Django. Мы изучим их функции, их преимущества, ограничения, а также их сходства и различия. В противном случае я сделаю все, чтобы помочь вам решить, какая из этих двух технологий лучше подойдет для вашего проекта. И если вы хотите изучить их с нуля или улучшить свои навыки, я оставлю полезные ссылки в описании, чтобы помочь вам с этим. Ладно, ребята, приступим!

Node.js против Django

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

Прежде всего, ребята, я хотел бы сказать, что мы здесь не для того, чтобы найти проигравшего. Важно понимать, что Django и Node.js оба отлично подходят для написания сложных веб-приложений. Django – ваш выбор, если вы предпочитаете Python. Это фреймворк разработки веб-приложений, загруженный эффективными инструментами для разработки бэкенда вашего проекта. Теперь Node.js – немного другое животное.

Это не фреймворк. Это инструмент для запуска JavaScript на серверной стороне, вне браузера. С помощью Node.js вы можете писать код как для бэкенда, так и для фронтенда, используя только один язык программирования – JavaScript.

И многие разработчики находят это очень удобным и эффективным одновременно. Ладно, после этого краткого введения давайте ближе рассмотрим, что эти два инструмента предлагают. Node.js против Django.

Основные функции

Node.js. Ладно, ребята, вот основные функции Node.js. Во-первых, он построен на движке JavaScript V8. И для нас разработчиков это означает быструю загрузку страниц. Во-вторых, благодаря своей событийно-ориентированной архитектуре, Node.js может обрабатывать несколько событий одновременно. Это делает его идеальным для вещей, которые требуют реального времени.

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

Он хорошо работает с Linux, Windows или macOS. Django. В то время как Node.js основан на JavaScript, Django полностью посвящен Python. Разработчики этого фреймворка придерживаются принципа “не повторяйся”. И это означает, что в основном нет повторяющегося кода.

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

Представьте себе, ребята, вы открываете ящик инструментов Django, и у вас есть все, что вам нужно. Это дает вам свободу сосредоточиться на том, что действительно важно. Это означает, что вам не нужно тратить столько времени и усилий на настройку вашей среды разработки или установку дополнительных библиотек и зависимостей. Вместо этого вы можете сосредоточиться на создании вашего приложения и воспользоваться множеством встроенных функций, которые предоставляет Django. И вот еще некоторые другие важные функции, которые предлагает Django. Django использует систему модель-представление-шаблон. Попробуйте представить это как разделение вашего приложения на три части. Бизнес-логика, пользовательский интерфейс и макет. Это помогает держать ваш код аккуратным, легким в управлении и масштабируемым. Django использует ORM, или систему объектно-реляционного отображения.

Это означает, что вам не нужно работать с каким-либо дополнительным SQL-кодом для операций с базой данных. Django идеально подходит для приложений с огромным количеством пользователей, будь то социальный хаб, интернет-магазин или образовательная платформа. Независимо от того, используете ли вы Windows, Mac или Linux, Django поддерживает вас.

Он хорошо работает с любой операционной системой.

Преимущества и ограничения

Люди, как я сказал в начале этого видео, Node.js и Django – оба отличные инструменты для работы. У них обоих есть потрясающие преимущества, поэтому веб-разработчики со всего мира любят их. С другой стороны, как и любая другая технология, существующая в мире, Node.js и Django не идеальны ни в коем случае.

У них есть свои ограничения, и некоторые из них могут стать решающими факторами для определенных проектов. Давайте посмотрим, в чем заключаются преимущества и ограничения. И начнем с Node.js. Преимущества Node.js Он основан на JavaScript, который является одним из самых популярных языков программирования. В сравнении с другими языками, его легко изучить и поддерживать, и у него достаточно большое и полезное сообщество разработчиков.

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

Тяжелые вычислительные задачи могут замедлить производительность. Поддержка кода становится сложной с Node.js в связи с его моделью программирования. И ограниченная поддержка библиотек также может быть вызовом для разработчиков. Ладно, теперь, ребята, давайте перейдем к Django и посмотрим, что он может предложить. Преимущества Django Установка и использование Django довольно просты. Его дружественный интерфейс плавно обрабатывает административные задачи. Django поддерживает всестороннее тестирование приложений от начала до конца. Он поддерживает различные методы аутентификации в REST-фреймворке.

У вас есть доступ к нескольким техникам кэширования через фреймворк кэширования. И Django помогает создавать динамические HTML-страницы. Недостатки Django Хотя Django масштабируем, могут возникнуть проблемы с небольшими приложениями. Django – монолитный фреймворк, что означает, что это большое, единое приложение, которое можно развернуть только целиком.

И это может быть немного рискованно, потому что если что-то пойдет не так, вся система может упасть. И, наконец, Django не может обрабатывать несколько запросов одновременно. Так что, ребята, помните об этом, прежде чем решить использовать Node.js или Django для ваших проектов. Сравнение Django и Node.js Ладно, ребята, и теперь мы наконец-то пришли к основной теме этого видео.

Оценка ключевых параметров

Давайте сравним Node.js и Django по ключевым параметрам. Производительность Django предлагает намного лучшую производительность для веб-приложений большого масштаба. У него есть метод создания встроенных шаблонов, что упрощает выполнение задач быстрее. Скорость Node хороша, потому что он дает разработчикам свободу, однако разработка приложения занимает больше времени.

Архитектура Django берет представление шаблона из модели MVT. Node.js работает на основе системы, основанной на событиях, и использует стек управляемых запросов ОС. Скорость разработки Django работает быстрее благодаря своей встроенной системе, но для разработчиков, не знакомых с Python, это может занять много времени. Node.js может занять больше времени для работы, но он полезен для разработчиков, знакомых с JavaScript.

Безопасность Django поставляется с надежной встроенной системой безопасности, которая защищает от уязвимостей и предлагает отличную безопасность. Node.js требует ручных исправлений безопасности, так как он не такой безопасный, как экосистема Django. У Django большая экосистема модулей, но она не так обширна, как у Node.js. У Node.js есть огромная коллекция готовых модулей через NPM.

Это означает, что разработчики могут легко найти готовые функции для добавления в свои приложения. Сообщество У Node.js и Django отличные сообщества. Однако, основываясь на некоторых исследованиях, которые я провел, могу сказать, что у Node.js все еще большее сообщество. И как вы знаете, чем больше людей, тем больше ресурсов. И это делает легче найти помощь или узнать больше о фреймворке.

Вот почему, ребята, есть над чем подумать. Что лучше, Node.js или Django? Так что теперь, когда вы знаете гораздо больше о этих двух технологиях, пришло время ответить на последний вопрос для этого видео. Что лучше выбрать, Node.js или Django?

Ребята, моя цель в этом видео – не искать проигравшего, потому что, на мой взгляд, его нет. Теперь, когда мы сравнили Django и Node.js, это очень ясно. Оба этих фреймворка отличные. Но вот мои мысли о том, когда лучше использовать один или другой. Для быстрого и масштабируемого MVP или надежных приложений с довольно высоким уровнем безопасности выбирайте Django.

Особенно если вы занимаетесь финансовой технологией. И если вы работаете с API, боретесь с высокоскоростными сервисами или занимаетесь микросервисами, Node.js – ваше решение. В конце концов, ребята, все зависит от того, что соответствует вашим личным целям и потребностям вашего проекта. Карьерные возможности Ладно, и теперь, когда мы сравнили эти два инструмента, давайте посмотрим, какие карьерные возможности есть для разработчиков Node.js и Django.

Карьерные возможности

Ну, мои коллеги-разработчики, я рад сообщить, что будущее обеих технологий выглядит довольно хорошо. Согласно опросу разработчиков Stack Overflow, сегодня Node.js является одной из самых популярных веб-технологий. В то же время спрос на разработчиков Django стабильно растет из года в год. По данным Glassdoor, опытные разработчики Node.js могут зарабатывать до $143,000 в год. В то же время, разработчики на Django зарабатывают до $122,000 в год. Фрилансеры по Node.js зарабатывают от $18 до $38 в час. Фрилансеры на Django зарабатывают от $20 до $40. Так что, ребята, как вы можете видеть, внутренние вакансии оплачивают немного больше для специалистов по Node.js, чем для разработчиков на Django.

Но когда речь идет о фрилансе, разница незначительна.

Ладно, мои коллеги-разработчики, это все, что у меня есть по сравнению Node.js и Django.

https://www.youtube.com/@Daniel-Dan./videos

На первый взгляд, она проще, чем low-code CMS вроде WordPress, но таит в себе бездну возможностей для кастомизации. Как и в случае Python, для Django написано множество плагинов, которые удовлетворят почти любой запрос.

Сейчас, спустя 8 лет, переношу свой сайт с Ghost CMS на Django. И хочу показать процесс изнутри и разобрать, какие сложности будут вас ждать после перехода.

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

Разворачиваем проект на локальном сервере

Следуя инструкции, я форкаю репозиторий в выделенную на ноутбуке папку:

Затем создаю виртуальное окружение:

Устанавливаю необходимые компоненты и сам django-tailwind:

Указываю в …/blogApp/settings.py, что инструмент установлен:

Дело за малым: задаю настройки CSS и базы данных:

Запускаю сервер и смотрю на сайт в браузере:

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

Верстаем посадочную и основную страницы сайта

Поскольку текст зашит в код статически, то и заменить фразы вроде «I’m a Full Stack Developer…» на свой текст достаточно просто: в редакторе кода запускаем поиск по всем файлам. Для VSCode это Ctrl + Shift + F / Cmd + Shift + F:

Не буду подробно останавливаться на всех изменениях статики, ибо это простой текст, который меняется сочетанием Ctrl + F. По окончании переверстки сайт выглядит так:

Кстати, вместо картинки с космонавтом я использовала свою айдентику с роботом. Практика показывает: долговечнее выходит залить на бесплатный CDN вроде webfx.com или даже Dropbox. HTML-код для картинки стал выглядеть так:

Разработчикам, которые решили завести блог, не стоит концентрироваться на дизайне. Разве что сайт будет являться портфолио фронтенд-девелопера. Для остальных категорий контент-мейкеров вполне сгодятся бесплатные темы, которые распространяются на Envato, GitHub и прочих ресурсах.

Заключение

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

• как добавить данные в базу;
• как задеплоить сайт на условно бесплатной платформе Railway;
• как опубликовать проект на своем домене;
• как верстать статью.

Это продолжение статьи о миграции с low-code CMS на Django. В первой части мы развернули проект с симпатичным дизайном на локальном сервере, подготовили данные для загрузки в хранилище SQL (ссылка).

Запустим сайт, что получили в первой части

При каждом запуске сервера командой:

Запуск проекта Django отправляет нас по ссылке http://127.0.0.1:8000/. Конечно, другие пользователи ее не увидят, даже если компьютер будет запущен круглосуточно. Потому настало время привязать к проекту домен.

Переносим данные

Мой сайт сидел на CMS под названием Ghost. Главным преимуществом я всегда считала возможность сменить тему без необходимости программировать и достаточно отлаженные для мобильных устройств шаблоны страниц.

Теперь, когда ценник возрос (в связи с ростом числа читателей) и отключением Visa / Mastercard на территории РФ, оплачивать подписку на эту систему стало невыгодно. Конечно, обходные пути для оплаты всегда найдутся, но умельцы навешивают комиссию в 20%. Со временем это начинает раздражать.

За «только платный» план Ghost делает свою работу очень достойно: в секции Labs блогер может скачать весь контент. Нечасто CMS настолько дружелюбны к перспективе миграции.

При скачивании получаем такой JSON-массив со статьями:

Django-проект сидит на SQLite (придется пересаживать на PostgreSQL), так что придется вытащить некоторые поля и загнать их в SQL-запрос.

Чтобы залить все 246 статей в базу, нужно проитерировать файл на 6800+ строк и вытащить обязательные параметры: название поста, описание, текст с HTML-разметкой, URL картинки и slug (псевдоним статьи на латинице для формирования ссылки вида https://ww.helenkapatsa.ru/blogpost/slug).

Внимательные могли заметить, что при выделении параметров category, thumbnail_url остаются пустыми: в Ghost-выгрузке попросту нет аналогичных полей.

Созданный список из словарей заливаем в файл:

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

Теперь, подключив модуль sqlite3, заливаем посты:

Основной объем работ по переносу выполнен, админка наводнилась постами:

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

Деплоим на сервере

Первый шаг в этом процессе — развернуть репозиторий на круглосуточно работающем сервере. С этим здорово помогают сервисы вроде Railway: достаточно привязать свой GitHub-аккаунт, чтобы подтянулся нужный:

После построения проекта, которое заняло около двух минут, можем посмотреть статус развертывания:

Сам сайт теперь доступен и на выделенном поддомене web-production-99b09.up.railway.app. Но нас интересует – helenkapatsa.ru.

Регистратор – reg.ru, и стандартная процедура вставки CNAME-записи не сработает:

Поэтому используем Cloudflare. Он предоставляет бесплатные DNS-сервера. После регистрации и ввода доменного имени получаем инструкцию:

Замена ns1/2.reg.ru на адреса Cloudflare заняла менее 10 минут. Осталось добавить CNAME-запись, указывающую на Railway-приложение:

Спустя примерно 10 минут сайт доступен по адресу helenkapatsa.ru:

Устанавливаем плагин

Когда речь заходит о статистическом/математическом термине, зачастую к посту я прикладываю формулу. Чтобы Django рендерил MathJax (один из способов записать такое выражение), нам потребуется библиотека django-mathjax. Ее устанавливаем классической командой:

Пополняем перечень требуемых инструментов (requirements.txt), чтобы Railway при редеплое прошелся по этому файлу и установил инструмент:

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

/path/to/file/templates/blogpost.html:

Теперь при попадании такого синтаксиса в текст:

Код превратится в красоту:

Заключение

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

Поддержка сайта не усложнится, пока вы регулярно практикуете Python. Такая миграция – это возможность попробовать инструменты, которые на работе внедрить не удается. Тем самым вы можете пополнять резюме до нужной комбинации технологий.

Ошибка 1. Нет четких границ между слоями приложения

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

Можно выделить три базовых уровня:

• Контроллеры (или хэндлеры) принимают запросы, проводят базовую валидацию (например, через pydantic-схемы) и передают данные дальше.
• Слой бизнес-логики реализует правила работы приложения: транзакции, расчёты скидок, проверку лимитов, работу с несколькими сервисами.
• Слой доступа к данным отвечает за запросы к базе и возвращает данные в удобной для бизнес-логики форме.

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

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

Ошибка 2. Игнор масштабирования с первого дня

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

Важно сразу закладывать в архитектуру точки роста, даже если пока они не нужны на каждый день.

Например:

• Добавить очереди и фоновые задачи через Celery или RQ, если есть риск появления тяжёлых операций (генерация отчётов, массовая рассылка).
• Разносить чтение и запись: даже простое разделение на эндпоинты, где читающие операции не блокируются длительными транзакциями, уже помогает при росте нагрузки.
• Придумать, как кэшировать самые тяжелые запросы: например, использовать Redis, чтобы хранить агрегированные данные, а не считать их каждый раз.
• Закладывать возможность горизонтального масштабирования: не привязывать логику к локальному состоянию приложения, использовать хранилище с возможностью разделения нагрузки, не писать монолит, который нельзя будет разбить на части при росте.

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

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

Ошибка 3. Преждевременное усложнение архитектуры

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

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

Упрощённая архитектура на старте позволяет команде сосредоточиться на продукте: монолит с чёткими слоями (контроллеры, сервисы, репозитории) куда быстрее дорабатывается и легче деплоится, чем микросервисы с отдельными контурами.

Что можно делать:

• Запускать монолит на FastAPI или Django, а не дробить на микросервисы до появления реальных узких мест.
• Использовать Postgres без брокеров событий, пока не появятся требования к масштабированию.
• Добавлять кэш Redis точечно, когда видна реальная нагрузка, а не вслепую кэшировать каждый запрос.

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

Если команда делает стартап или MVP, преждевременное усложнение архитектуры только тормозит развитие продукта. Гораздо эффективнее заложить возможности для масштабирования (очереди, фоновые задачи, кэш), но держать архитектуру простой до тех пор, пока проект не начнёт расти и не появятся реальные вещи, требующие изменений.

Ошибка 4. Непродуманная работа с зависимостями

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

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

Чтобы избежать проблем, важно с самого начала заложить порядок в работе с зависимостями:

• Использовать инструмент управления зависимостями, который позволяет контролировать версии и изолировать окружения.
• Разделять зависимости для разработки и продакшена.
• Периодически обновлять зависимости, чтобы не закапываться в старые версии, но делать это контролируемо и с прогоном тестов.

Например, при работе с Python удобным подходом будет использование Poetry: можно зафиксировать версии зависимостей в pyproject.toml, автоматически создавать lock-файл, следить за актуальностью библиотек и легко пересоздавать окружение. Если проект запускается на CI/CD, можно установить точные версии и сразу выявить, где обновление ломает тесты.

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

Ошибка 5. Нет стратегии управления состоянием

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

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

Чтобы избежать хаоса, управление состоянием нужно продумать заранее:

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

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

При работе с фронтендом стратегия управления состоянием не менее важна. Например, при использовании React или Vue проект может сначала обходиться локальным состоянием компонентов, но при росте сложности приложение начинает сыпаться из-за рассинхрона между компонентами. Важно заранее заложить подход с централизованным состоянием, а также понять, какие данные держать в состоянии клиента, а какие запрашивать заново.

Без стратегии управления состоянием проект становится сложным в отладке и поддержке. Грамотное управление состоянием ускоряет разработку и снижает количество багов в будущем.

А какие ошибки допускаете вы? Делитесь в комментариях или в тг-канале Веб-страница.

Узнайте, как сделать из Python-скрипта исполняемый файл, какие инструменты использовать в Data Science и как настроить автопостинг в ВК.

Big Data / Data Science

• Экстренное шифрование данных
• Инструменты Дата-сайнтиста. Универсальная база
• Как из метрик Prometheus построить график Latency
• Dagster и Great Expectations: Интеграция без боли
• Книга «Python для data science»
• [ENG] What is the Minimum System Requirements for Data Science?
• [ENG] Data Science Roadmap with Free Study Material
• [ENG] Modern Data Stack: A Hands-on Guide with Airbyte, Snowflake, and dbt(data build tool)

AI и ML

• Тестируем на реальных кейсах Chatgpt Code Interpreter
• Семантическая сегментация на основе архитектуры U-Net и определение расстояния между объектами
• Первые шаги в импульсных нейронных сетях
• See and Tell: Сервис просмотра сериалов для слабовидящих
• Нейронные сети не могут обобщать периодические зависимости. Как это исправить?
• [ENG] Building a ChatGPT custom plugin for API Gateway
• [ENG] AI Team Collaboration with Azure ML Studio
• [ENG] Invoking OpenAI’s ChatGPT from 6 different programming languages
• [ENG] Creating a Better StackOverflow with ChatGPT

Веб / Django / Flask

• FVWA (Flask Vulnerable Web Application)
• Lock записей и шквал «пятисоток»: какие шишки мы набили на миграциях в Django и как вам этого избежать
• Полезные материалы и инструменты для погружения в Flask: выбор сотрудников Selectel
• [ENG] Multi-Role User Authentication in Django Rest Framework
• [ENG] Python, Flask: Railway.app deployment and Railway’s Nixpacks Docker image build tool.
• [ENG] Road-Map for Python Developers 
• [ENG] When plans go astray: my unsuccessful journey of migrating a large Django project to Mypy
• [ENG] Exploring Django’s Third-Party Packages: Top Libraries You Should Know

Скрипты, приложения и боты

• RabbitMQ Direct Reply-to. RPC поверх кролика без дополнительных очередей (пример на Python)
• Автопостинг ВК (VK) на python
• Как сделать из Python-скрипта исполняемый файл
• Встроенные фикстуры Pytest
• Развлечения с хеш-коллизиями
• [ENG] Writing a Transmission Control Protocol stack in Python

Развлекательный контент

• [Видео] опрос Stackoverflow / PEP 594 / PSF Board 2023 / релиз JupyterLab 4
• [Видео] Moscow Python Meetup №82. Максим Безруков. Виртуальное окружение по хардкору. Жизнь без pip
• [ENG] ChatGPT Vs Bard: Which is better for coding?

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

Если дайджест вам понравился, посмотрите две предыдущие подборки:

А ещё присылайте в комментарии статьи и видео, которые ускользнули от нашего взгляда и не попали в дайджест. Поделитесь полезными материалами с другими читателями!

Узнайте, как взломать ChatGPT, как оптимизировать работу в Jupyter Notebook и как компилировать типизированный Python.

Big Data / Data Science

• Оптимизации работы Jupyter notebook при помощи параллельных вычислений (Библиотека Joblib)
• Анализировать данные — это как варить пиво. Почему дата-анализ и пивоварение — одно и то же с техноизнанки
• Как сэкономить свои нервы и деньги компании на перестроении структуры больших таблиц без простоя в PostgreSQL
• [ENG] How To Manage Environment For Data Science Project Using Conda
• [ENG] Unleashing the Potential of Random Forest Regression : A Python Implementation Guide with Hyperparameter Tuning
• [ENG] MLOps 101: A Beginner’s Guide to Understanding Machine Learning Model Operations
• [ENG] Demystifying the Data Product Lifecycle: From Inception to Retirement
• [ENG] Polars vs Pandas: A Brief Tale of Two DataFrame Libraries

AI и ML

• Фильтруй базар! Как мы параллельный русско-башкирский корпус чистили
• Кажется, вы больше не должны давать тестовые задания кандидатам на дом
• Как определить причины достижений и неудач футбольного клуба с помощью цифр
• Заметки про увеличение картинок нейронными сетями
• Взламывая ChatGPT: как мы участвовали в хакатоне по атакам на ИИ
• [ENG] Experiment Tracking and Hyperparameter Tuning with TensorBoard in PyTorch
• [ENG] Building a Vision Transformer from Scratch in PyTorch
• [ENG] All the things that Comprehend, Rekognition, Textract, Polly, Transcribe, and Others Do
• [ENG] Copy.deepcopy() vs clone() in Pytorch

Веб / Django / Flask

• Fastapi 0.100.0-beta1: ещё быстрее
• [ENG] Unlocking Performance: A Guide to Async Support in Django
• [ENG] Deploying a Flask Application on AWS EC2
• [ENG] Building an Infinite Website with Flask and OpenAI’s davinci-v3
• [ENG] Mastering Django CI/CD using GitHub Actions
• [ENG] Discovering PySeKT: Your Next Favorite Tech Stack

Скрипты, приложения и боты

• Как сделать Telegram-бота для проверки аптайма своего сервиса на Python (ч.1 мгновенные метрики)
• Как сделать Telegram-бота для проверки аптайма своего сервиса на Python (ч.2 алертинг)
• Простейший бот «на движке» WEB WhatsApp
• Как я написал конвертер 3D-моделей из подручных средств
• Messaging для чайников. Утилизируем все возможности RabbitMQ на Python
• Как можно компилировать типизированный Python
• Умный дом с голосовым ассистентом на минималках
• Типизация в Python. Работа с Mypy, PyCharm и SQLAlchemy 2.0
• [ENG] Reasoning about Streaming vs Batch with a Case Study from GitHub

Развлекательный контент

• [Видео] Python meetup (Online)
• [Видео] Обработка данных / Pandas 2.0

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

Если дайджест вам понравился, посмотрите две предыдущие подборки:

А ещё присылайте в комментарии статьи и видео, которые ускользнули от нашего взгляда и не попали в дайджест. Поделитесь полезными материалами с другими читателями!

Узнайте, как готовить шаурму с помощью Python, как создать чатбот на основе ruT5, есть ли смысл в связке языков Python и C и какие есть AI-плагины для разработки на Python.

Big Data / Data Science

• PySpark для аналитика. Как выгружать данные с помощью toPandas и его альтернатив
• Применение Python для сбора и предобработки данных цифрового следа
• Форматы данных и файлов: руководство для архитекторов
• Почему для MLOps лучше выбирать Open Source, а не проприетарное ПО
• Как ускорить вывод ML-моделей в 4 раза, или Как может выглядеть экосистема МLOps в банке
• [ENG] Visualize Real-Time Data With Python, Dash, and RisingWave
• [ENG] 20 databases to pick in 2023 – simplified
• [ENG] Transform Your Data Like a Pro With dbt (Data Build Tool)
• [ENG] Polars vs Pandas: A Brief Tale of Two DataFrame Libraries
• [ENG] Data Visualization using Matplotlib and Seaborn

AI и ML

• Поиск объектов на изображении. Часть 1
• Заметки про увеличение картинок нейронными сетями
• Что под капотом у нейронной сети. Нейросеть c точки зрения математики и программирования
• cv3 — делаем OpenCV питоничным
• Роли ChatGPT, которые первыми начинают диалог с клиентом и добивается поставленной бизнес задачи
• Хороший, плохой, злой и… свободный? Сравниваем глуповатые, но усердные AI-плагины для разработки
• Сингулярность, в результате которой ИИ сам сделает себя умнее людей. GPT-4 играет в Minecraft и самообучается
• [ENG] 8 Crucial Lessons to Streamline Your Machine Learning Implementation
• [ENG] Build a SMS Bot that Answers questions over Docs with LangChain in Python

Веб / Django / Flask

• Роли ChatGPT, которые первыми начинают диалог с клиентом и добивается поставленной бизнес задачи
• AIsaacChat: ИИ чатбот на основе ruT5
• Парсинг, хранение и отображение логов 3-х разных агентов доставки электронной почты. MTA Log Parser
• [ENG] Django News – Django bugfix release 4.2.2
• [ENG] Django News – Python 3.7 to 3.12 updates
• [ENG] Testing in Django
• [ENG] 10 Django Packages Every Developer Must Install

Скрипты, приложения и боты

• Мой первый супероптимизатор
• Python3 + C, есть ли смысл?
• Shawarma as a service: как создать бота для заказа шавермы и оставить голодными лишь 1,1% коллег
• Сказ о том, как специалисты IT-поддержки скрипты писали…
• [ENG] I built 3 Apps using Spotify API and Python
• [ENG] Simple FriendList App In Pyhton Tkinter
• [ENG] Regular expressions and string manipulation in Python
• [ENG] pyaction 4.21.0 Released

Развлекательный контент

• [Видео] Типизация в Python
• [Видео] Python Language Summit 2023 / новости PyPI / Python 3.12 beta 1/ Diablo 4
• [Видео] Python: Ботоводство на AIOgram

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

Если дайджест вам понравился, посмотрите две предыдущие подборки:

А ещё присылайте в комментарии статьи и видео, которые ускользнули от нашего взгляда и не попали в дайджест. Поделитесь полезными материалами с другими читателями!

Узнайте, как сгенерировать голос человека на Python, во сколько раз Mojo быстрее Python на самом деле и как обыгрывать противников в покер при помощи нейросетей.

Big Data / Data Science

• Кластеризация текста в PySpark
• Определение свободного парковочного места с помощью Computer Vision
• Что нам стоит диаграмму в Python построить: 5 вариантов привлекающей внимание визуализации данных и кое-что ещё
• Правильное подключение к БД: почему, зачем и как
• Все DETRы мира. Часть 1
• Что нового в SQLAlchemy 2.0?
• [ENG] Exploring Advanced and Modern Concepts in SQL with Practical Examples
• [ENG] My Favorite Free Courses to Learn Data Science in Depth

AI и ML

• Битва медведей: Pandas против Polars
• Реализация функции потерь в Python
• Использование компьютерного зрения для игры в покер
• Восстановить удаленную фотографию с флешки? Искусственный интеллект в помощь
• [ENG] Build your own YouTubeGPT using LangChain and OpenAI
• [ENG] Facebook Open-Sources Its Horizon AI Platform
• [ENG] How I built a Midjourney API
• [ENG] Semantic Search Using Vectors/Embeddings For Noobs
• [ENG] How to generate voices with Python?

Веб / Django / Flask

• Создаем блог на Django с опросами и тестами. Краткая инструкция. Часть 1
• Создаем блог на Django с опросами и тестами. Краткая инструкция. Часть 2
• Особенности асинхронности в Python
• Werkzeuger: раскручиваем arbitrary file read до RCE в веб-приложении на flask
• [ENG] How to create REST API using Django REST framework
• [ENG] WebSocket in Django
• [ENG] Deploying Your First Dockerized Django REST API on AWS Elastic Beanstalk: A Comprehensive Guide
• [ENG] A One Person Startup Tech Stack for Ninja Developers – Next.js, Django, Kubernetes, and GCP

Скрипты, приложения и боты

• Решаем задачу сетевого планирования с помощью Python
• FastAPI без db: Session
• Телеграм бот для CustDev’а на Aiogram
• Пишем на Python, как будто это Rust
• Propan — Python фреймворк для написания микросервисов с использованием брокеров сообщений
• Как заставить бэкендера писать фронтенд
• [ENG] Meet Omkar DevTools: Your Swiss Army Knife as a Ninja Developer
• [ENG] pyaction 4.20.0 Released
• [ENG] Binary Search in Python
• [ENG] Getting Started: Monitoring a FastAPI App with Grafana and Prometheus – A Step-by-Step Guide

Развлекательный контент

• [Видео] Собеседование Python 2023. Разбор базовых вопросов
• [Видео] Блиц по бэкенду: сравниваем Python и Java
• [Видео] [ENG] Mojo VS Python Speed Test
• [Видео] [ENG] How to Make Donkey Kong in Python!

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

Если дайджест вам понравился, посмотрите две предыдущие подборки:

А ещё присылайте в комментарии статьи и видео, которые ускользнули от нашего взгляда и не попали в дайджест. Поделитесь полезными материалами с другими читателями!

Узнайте, что такое PandasAI и почему он изменит Data Science, как написать Telegram-бота на Django и как сделать языковую модель на Python.

Big Data / Data Science

• Координатный квест: как найти координаты и расстояния без регистраций и смс
• Байесовский подход к АБ тестированию
• Data-driven рост с помощью науки о данных и машинного обучения
• Анализ таблиц сопряженности средствами Python. Часть 1. Визуализация
• PySpark для аналитика. Как правильно просить ресурсы и как понять, сколько нужно брать
• [ENG] Data-Oriented Programming in Python
• [ENG] Using pandas.cut() in Python for Data Analysis: Creating Number and Date Intervals
• [ENG] NumPy and Pandas: Essential Tools for Data Analysis and Manipulation
• [ENG] Scikit-Learn Code Snippets for Common Machine Learning Tasks: A Comprehensive Guide for Beginners

AI и ML

• Торговый робот с использованием нейросетей
• Делаем анализатор ников на новой FRED-T5. Тотальный разнос
• Бесплатные фронтенды к ChatGPT
• Обучение YOLOv5 на кастомном датасете
• [ENG] Open AI API with Docker
• [ENG] Building an AWS Well-Architected Chatbot with LangChain
• [ENG] ChatGPT, Made Private and Compliant!
• [ENG] Getting Started with LangChain: A Beginner’s Guide to Building LLM-Powered Applications
• [ENG] Pandas AI — The Future of Data Analysis
• [ENG] PandasAI: Super Simple Data Analysis with AI (Powered by OpenAI)

Веб / Django / Flask

• Telegram Django Bot за пару строк
• Как создать собственный кэшбэк-сервис
• [ENG] Setting Up Your Full-Stack Development Environment with Python, Django, and React
• [ENG] Authentication system using Python (Django) and SvelteKit
• [ENG] File upload using Django and HTML
• [ENG] HTMX within Django – Intro 2023
• [ENG] Django – Tips, tricks and packages – 2023
• [ENG] Redis as a Powerful Caching Solution for Django Web Applications

Скрипты, приложения и боты

• Python. Выражения в методах и индексаторах
• «Карманный синоптик за час». Пишем Telegram-бота для мониторинга погоды на Python
• Макет автоматизированного создания пользователей (ботов) в социальных сетях и имитации их активности
• Решаем криптарифмы с помощью алгебры и python
• [ENG] The PiCast: Connect a Raspberry Pi Pico W to an Anvil app
• [ENG] Art of Manually Crafting Packets (TCP/IP).
• [ENG] Doing much better than your .env file

Развлекательный контент

• [Видео] Изучаем иностранные языки с помощью Python и ChatGPT
• [Видео] Притворяемся языковой моделью: учимся генерировать текст на Python с помощью цепи Маркова
• [ENG] 50 Chat GPT Prompts Every Software Developer Should Know (Tested)

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

Если дайджест вам понравился, посмотрите две предыдущие подборки:

А ещё присылайте в комментарии статьи и видео, которые ускользнули от нашего взгляда и не попали в дайджест. Поделитесь полезными материалами с другими читателями!

Узнайте, как подключить AutoGPT к своему проекту, какие обновления затронули Django и как обучить GPT-4 новым данным.

Big Data / Data Science

• Как мы делали скоринг на микросервисной архитектуре руками не-программистов
• Сам себе Росстат
• Real-time аналитика в Учи.ру: как смотреть сложные метрики
• Новые горизонты в оценке рисков: как источники данных помогают создать точные модели
• EN DataHub: веб-песочница для тех, кто изучает SQL
• EN All Statistical Tests using Python: Mastering Statistics | Part — 1
• EN Getting Started with LangChain: A Beginner’s Guide to Building LLM-Powered Applications
• EN The Next Big Crisis for Data Teams
• EN The Best Learning Paths for AI and Data Leadership
• EN PandasGUI — The Ultimate Secret to Effortless Data Analysis
• EN Exploratory Data Analysis: The Ultimate Workflow

AI и ML

• Об инициации весов при обучении нейронных сетей. Личный опыт и рассуждения
• GPT-4 добавляем новые знания: Git репозиторий
• Google дала Bard возможность создавать код на 20 языках, включая C++, Go, Java, Javascript, Python, Typescript
• Пишем простой ML веб-сервис на FastAPI
• Создай своего ИИ-ассистента с помощью ChatGPT и Streamlit
• EN GPT4All: Running an Open-source ChatGPT Clone on Your Laptop
• EN How to Easily Install Auto-GPT: The Autonomous GPT-4 Everyone is Talking About
• EN Discover ThinkGPT: The Cutting-Edge Python Library that Transforms AI into a Powerful Thinking Machine

Веб / Django / Flask

• PyCharm Docker Django Debug
• Простая очередь задач в Django, подключение Kandinsky 2.1
• 403, 404 или 405. Разбираемся со статусами во ViewSet’ах DRF
• Связь Django и PostgreSQL внутри Docker
• Релиз Django LTS 4.2: обзор изменений и необходимости обновления
• EN Handling a Million Tasks in Django: Efficient Prioritization with Celery, Redis, and Flower
• EN The Road Less Traveled: Exploring the Advanced Features of Django
• EN Recommended stack for your Django Project

Скрипты, приложения и боты

• Как работает функция print в Python
• Ускоряем Python в сто раз при помощи менее чем ста строк на Rust
• Проверка GIL в python
• Создание DSL на Python с библиотекой textx
• 7 подходов к проверке атрибутов классов в Python
• Оптимизируем использование памяти в приложениях Python
• Сколько Надо Строк Кода Для Того Чтобы Подписать Артефакты?
• В репозитории PyPI внедрили опцию публикации пакетов без привязки к паролям и токенам API
• Как подключить платежную систему с Payments к Telegram
• EN 20 Python Concepts I Wish I Knew Way Earlier

Развлекательный контент

• Проверяем ветхозаветную историю происхождения человечества от Адама и Евы с помощью популяционной модели
• Видео Обучение подростков и взрослых Python в 2023 году / Программирование — вторая грамотность
• Видео  Live from PyCon 2023 – Talk Python #413
• Видео  Unpopular opinion! Python 3.11 is going to kill Go

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

Если дайджест вам понравился, посмотрите две предыдущие подборки:

А ещё присылайте в комментарии статьи и видео, которые ускользнули от нашего взгляда и не попали в дайджест. Поделитесь полезными материалами с другими читателями! 😉

Веб-разработка

• Поделились сложным, но простым языком.
  Обсудили структуры данных во фронтенде.
• Хотите, чтоб сайт был привлекателен даже без интернета?
  Рассказали, как это сделать.
• Поделились видеокурсом по бэкенду на Node.js.
  Теперь вы можете применить JS не только во фронтенде.
• Рассказали как скроллить страницу к нужному элементу с помощью URL.
  И оставили инструкцию с картинками.
• Вышла Node.js 20.
  Рассказываем, что нового.

Python и Django

• У нас на сайте появились 99 ответов на 101 вопрос для Python-разработчиков.
  Согласны с ними? Попробуйте ответить самостоятельно.
• Погружаемся в крипту с помощью питона.
  Рассказали, как написать бота для торговли на криптобирже Binance.
• Устанавливаем Python-проект под Windows нормально.
  Инструкция тут.

Точка входа: полезности для начинающих программистов

• Рассказали про основы SOLID для начинающих.
  Обязательно прочитайте, потому что в работе пригодятся.
• Так ли хорош «чистый» код?
  Рассказали о том, как некоторые правила написания такого кода портят производительность.
• Получили заветный оффер на должность джуна?
  Рассказали, как вести  в первые 100 дней работы, чтобы не облажаться.
• Хотите стать Android-разработчиком?
  В этом видео вы узнаете как.
• Обратите внимание на язык программирования Go.
  Тут рассказали что это такое и где его используют.
• Flexbox Zombies — тренажёр для изучения Flexbox CSS.
  Побеждаем зомби с помощью флексов.
• Как выбрать первый язык программирования.
  Рассказали тут.

Полезные инструменты, книги и лайфхаки для разработчиков

• Нашли большой интерактивный учебник по Python.
  Забирайте себе.
• MyJavaScript — полезный ресурс для начинающих фронтенд-разработчиков.
  Тут и руководства, и шпаргалки, и многое другое.
• CSS Peek — удобный плагин для веб-разработки.
  Он упростит настройку стилей ваших HTML-элементов.
• Собрали подборку промптом для ChatGPT.
  Теперь он сможет лучше выполнять конкретные задачи.
• CodeStream — инструмент, позволяющий общаться и работать в режиме реального времени, не покидая свою IDE.
  То, что нужно для быстрого взаимодействия внутри команды.
• А вот инструмент для тестировщиков.
  Knapsack Pro — оптимизация времени запуска тестов в проектах, написанных на любом языке программирования.
• И ещё один, но уже для тестирования UI.
  Называется Chromatic.

GameDev

• Инди-разработчики показали геймплейный трейлер своей игры и им не поверили.
  Почему? Посмотрите сами, в это действительно сложно поверить.
• А разработчик с Reddit показал прототип Pokemon Go на максималках.
  Там одного смартфона будет недостаточно.

Мобильная разработка

• В Android 14 можно будет настроить пользовательские действия в меню Share.
  Рассказали тут, как это сделать.
• Готовьте свои приложения для iOS.
  В iOS 17 Apple разрешит устанавливать сторонние приложения! Кажется…
• Знаете что такое Kotlinx.Serialization? Подсказка: сериализует данные.
  А вот как и зачем, узнаете тут.
• Учимся пагинации в Jetpack Compose.
  Вот по этому видеоуроку.
• Немного новостей про Kotlin.
  Kotlin DSL теперь используется по умолчанию для новых сборок Gradle.

Нейросети

• Вы только взгляните, как прокачалась Midjourney всего за 5 поколений.
  В этом видео всё максимально наглядно видно.
• Илон Маск сперва был против ИИ, а теперь решил сделать свой.
  Вот тут рассказали подробнее о его планах и новой компании.
• А NVIDIA продолжает выкатывать новые технологии.
  Взгляните сами.

Soft skills

• Рассказали про дизайн-мышление.
  Чем полезно и как его применять, читайте тут.
• Боремся с сомнениями и учимся принимать решения.
  Эти 11 способов побороть страх вам помогут.
• Метите в тимлиды?
  Заранее узнайте, как тимлиду провести первый год в незнакомой среде.
• Разработчик с 9-летним опытом поделился советами.
  Читаем тут.

Немного юмора

• Инструкция, как пушить в прод для джунов.Не перепутайте!
• Идея для стартапа с минимальными вложениями.Коронуем в сеньоры онлайн.
• Дизайнер vs. Разработчик.Наглядная демонстрация проблемы.
• Все мы иногда эта жаба.Согласны?
• Немного грубо, но зато доходчиво.
  Как отвечать любителям халявы.

Узнайте, какие существуют альтернативы ChatGPT, как написать собственный Duolingo и как изменились фреймворки Python для работы с BigData.

Big Data / Data Science

• Как IT-специалисты-экологи спасут планету
• Лучшие практики при работе с мастер-данными
• FineBI 6.0: 9 полезных обновлений, о которых вы не знали
• Производительность и стабильность Knime на слабых компьютерах
• Полезные методы работы с данными в Pandas. Часть 2
• Основные инструменты для работы в Data Engineering: введение для начинающих Data Engineer’ов
• Экспресс-анализ данных на Python
• Пишем приложение на Python для интерактивной визуализации графов с NetworkX, Plotly и Dash
• Начинаем работу с PyTorch 2.0 и Hugging Face Transformers
• %save-sc0% Data structures in Computer Science
• %save-sc1% From Kafka to Amazon S3: Partitioning Outputs
• %save-sc2% Data Reduction and Why It Is Important For Edge Computing
• %save-sc3% Driving Business Success: Unleashing the Power of Data Integration

AI и ML

• Ускорение работы моделей Stable Diffusion на процессорах Intel
• О чём все эти люди говорят, ChatGPT?
• Savant: новый высокопроизводительный фреймворк Python для видеоаналитики на оборудовании Nvidia
• Начинаем работу с PyTorch 2.0 и Hugging Face Transformers
• Распознаем автомобильные номера на TorchServe
• Как я решила попробовать себя в ML: анализ эмоциональной окраски отзывов с Кинопоиска 2.0
• Руки на руль: Bus Factor следит за тобой
• OpenAssistant: Вышла бесплатная открытая альтернатива ChatGPT
• Чем отличаются ChatGPT3 и ChatGPT4?
• Запуск аналогов ChatGPT на домашнем ПК в пару кликов и с интерфейсом
• %save-sc4% Generating Images from Text with C# and Open AI DALL-E
• %save-sc5% Google and Stanford Creates a Matrix With Chat-GPT Instances
• %save-sc6% Create a ChatGPT Plugin to retrieve NASA images

Веб / Django / Flask

• Релиз Django LTS 4.2: обзор изменений и необходимости обновления
• Интеграция и кастомизация OpenAPI в Django/Django Rest Framework
• Обучаем с помощью LlamaIndex и OpenAI GPT-3 отвечать по вашей базе знаний
• %save-sc7% Create a Modern Application with Django and Vue
• %save-sc8% Mastering Django: Best Practices for Writing High-Quality Web Applications
• %save-sc9% How To Revert Migration In Django?
• %save-sc10% Understanding QuerySets in Django
• %save-sc11% 10 Must-See Django Open-Source Projects to Inspire Your Next Web App
• %save-sc12% 17 Django Tips and Tricks for Optimizing Your Application

Скрипты, приложения и боты

• EasySteamPaybot или как я помогал людям пополнять Steam
• Как сделать торгового робота для Binance
• Как перестать беспокоиться и установить Python-проект другу под Windows
• Восемь признаков недо-yield вашего проекта на Python
• Методика портирования пакетов Python в операционную систему «Нейтрино»
• Пишем свой личный Duolingo на минималках
• DSL фреймворк для создания Telegram ботов
• Project_2. Местоположение с помощью IP-адреса (Python)
• Визуализация 5 алгоритмов сортировки на Python
• %save-sc13% Linting Python in VS Code [Video]
• %save-sc14% Building a Simple Web Scraper with Python and BeautifulSoup

Развлекательный контент

• %save-sc15% LTS-релиз Django 4.2 / вышли PyTorch 2.0 и Pandas 2.0 / свежие PEP
• %save-sc16% Python Channel
• %save-sc17% The History of AI

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

Если дайджест вам понравился, посмотрите две предыдущие подборки:

А ещё присылайте в комментарии статьи и видео, которые ускользнули от нашего взгляда и не попали в дайджест. Поделитесь полезными материалами с другими читателями! ?

Веб-разработка

• Как расширить функционал веб-приложений без головной боли?
  Рассказали о четырёх веб-API, которые вы можете использовать в своих проектах.
• Может ли видео на бэкграунде быть лёгким и плавным? Конечно!
  Рассказали как это сделать.

• Проверить как работает ваш код на JS или TS можно в одном окне.
  Поделились инструментом RunJS, который помогает мгновенно проверить работу ваших скриптов.
• А туда ли улетают ваши запросы?
  Как создать, протестировать и задокументировать API с помощью Postman рассказали здесь.

Python и Django

• Django не так сложен, как вам могло показаться!
  Поделились небольшим, но подробным видеокурсом по основам Django.
• Обрабатывать большой поток данных может быть сложно.
  Рассказали, как создать конвейер данных с Kafka и ClickHouse для облегчения жизни.
• Копирайтер против ChatGPT: кто круче напишет статью про Python?
  Провели небольшое исследование, в котором приняли участие  пользователи.
• Пишете красивый код, но забываете о безопасности?
  Тогда обязательно сохраните себе эту шпаргалку с полезными советами.
• Бесконечно можно смотреть на три вещи: как течёт вода, как горит огонь и как красиво сортируются массивы.
  Визуализация последнего ждёт вас тут.

Точка входа: полезности для начинающих программистов

• Flexbox и Grid — два основных способа вёрстки страниц с помощью CSS.
  Если ещё не владеете ими, то посмотрите этот видеоурок, посвящённый CSS Grid.
• SOLID, но не Snake.
  Изучите один из главных способов проектирования приложений, который точно вам пригодится.
• Учимся работать с AWS — одной из самых популярных облачных платформ.
  Конечно, по видеоурокам.

Полезные инструменты, книги и лайфхаки для разработчиков

• Хотите вставить на сайт какой-то особенный символ?
  Держите интерактивный справочник с символьными объектами HTML, символами Unicode и 8859-1, кавычками и многим другим.
• Swimlanes.io — инструмент, который поможет вам визуализировать процессы.
  Как создавать диаграммы быстро и просто рассказали тут.
• Scratch — инструмент от MIT, который помогает даже детям освоить программирование.
  Рассказали, как бесплатно прокачаться.
• GitHub не всему голова.
  Git-Tower — Git-клиент с расширенными возможностями.
• Не все любят видеокурсы и статьи.
  Для вас мы нашли книгу, которая сделает из вас крутого Java-разработчика.
• А если хотите что-то более популярное, то и это у нас есть.
  Держите книгу по криптографии и взлому шифров на Python.

GameDev

• Зачем нужен DLSS в играх и как он работает?
  Рассказали тут.
• Хотите стать повелителем погоды?
  Тогда посмотрите, как создаются погодные механики в играх.
• Как увеличить геймплей игры?
  Для этого нужен простой…

Мобильная разработка

• Да кто такой этот ваш Android-разработчик?
  Рассказали о типичных задачах разработчика под Android.
• Никогда не поздно поменять свою жизнь.
  Рауль Феррера рассказал, как стал iOS-разработчиком в 40 лет и даже написал собственную книгу.
• Упрощаем авторизацию в приложении.
  Посмотрите, как добавить Google Sign-in в Android-приложение.

Нейросети

• Энтузиасты приближают восстание машин.
  ChaosGPT — нейросеть на основе GPT-4, которая учится «уничтожать человечество».
• Много нейросетей больших и разных.
  Собрали шпаргалки по нейросетям в одном месте.
• Создайте свою образовательную платформу с помощью OpenAI, ChatGPT и Django.
  Оставили инструкцию для вас тут.
• Сделайте своего GPT-бота в Telegram.
  Простой гайд уже ждёт вас.
• Нужно больше информации о ChatGPT богу ChatGPT!
  Для начала узнайте, как, собственно, работает эта нейросеть.

Soft skills

• Третьи сутки без сна, а к дедлайну всё равно не успеваете?
  Возможно, вам стоит заняться собственным тайм-менеджментом.
• Время просчитали правильно, но всё равно не успели? Тогда проблема в откладывании дел.
  Узнайте, как перестать откладывать дела на потом и научиться работать как машина.
• Каждого третьего россиянина бесят коллеги по работе.
  А вот почему — узнаете в этой статистике.

Немного юмора

• Танцуем и печатаем.
  Попробуйте сделать жестовую клавиатуру с OpenCV и MediaPipe для всего тела.
• Проводите демо для заказчика правильно.
  Видеоинструкция уже ждёт вас. 
• Вы читаете пользовательские соглашения?
  А стоило бы.
• И снова о важности чтения документации.
  Хотя…

Когда вскрывается проблема

Представьте, вы пишете проект на Django в команде из пяти человек. На старте все замотивированы «сделать хорошо», ведь это шанс сделать проект «идеальным» с самого начала. Но проходит год или два, проект обрастает парой десятков тысяч строк кода. Разрабатывать становится всё сложнее: файлы ломятся от кода, навигироваться по проекту без продвинутых инструментов из IDE просто невозможно.

В этот момент разработчики обычно говорят, что причина возрастающей сложности — рост проекта. Или грешат на «коллег-говнокодеров» / «плохой фреймворк». Хотя с ростом проекта навигация действительно естественным образом усложняется, чаще всего виноваты отнюдь не фреймворки или количество строчек, а плохие решения.

Основная цель фреймворка — задать «фреймы», то есть «границы», в рамках которых будет работать программист. Для этого внутри Django предусмотрено множество механизмов, и многие из них описаны в документации. Некоторые — прямо в исходниках фреймворка. А какие-то детали разработчики Django не предусмотрели, и программистам приходится придумывать новые границы самостоятельно.

Зачем нужны эти границы? Разве без них не лучше?

Ответ на этот вопрос сходу поймёт любой пользователь фреймворка: не лучше. Границы пусть и создают дополнительные «препятствия», но взамен они обеспечивают понятное пространство для работы: сюда писать такой код, а сюда – вот такой, и всё будет работать. Не нужно каждый раз «изобретать велосипед» и пытаться придумать, как будет работать ваш сайт. За вас уже подумали и оставили «места для дописывания кода». Вот эти места для вашего кода — это и есть фреймы.

Архитектура MTV

Самый «высокоуровневый» фрейм в Django — это архитектурное разделение логики на Model, View и Template.

Да, архитектура Django называется именно MTV, а не MVT. Разработчики используют в документации именно такую аббревиатуру. По сути, архитектура почти полностью повторяет другой подход — MVC, Model-View-Controller (Модель-Представление-Контроллер).

Суть такая:

• в Model хранят данные сервиса;
• View отвечает за отображение данных пользователю;
• Controller отвечает за то, чтобы сообщать Model, когда пора менять данные.

В Django же отошли от этой концепции и использовали архитектуру Model, View и Template. Сами разработчики Django пишут, что не видят никакого конфликта с MVC. Model по-прежнему отвечает за хранение данных и работу с ними. View — за «отображение» данных. Просто этот слой они разделили на два: View отвечает за то, чтобы решить, какие данные отображать, а Template — как отображать. Куда делся Controller из MVC? В аббревиатуре MTV он пропал.

Разработчики считают, что это сам фреймворк.

Возможно, вы хотите спросить, зачем я об этом рассказываю. Разве возможно накосячить на этом уровне? Вообще-то, да.

Бизнес-логика, или слой Services

Многие разработчики пытаются переизобрести MTV и добавляют в Django дополнительный слой: Services. Вы найдёте файл serivces.py во многих туториалах и видео по Django.

Необходимость добавления этого слоя обычно объясняют так:

• В моём проекте появились функции, которые не укладываются ни в Model, ни во View;
• Я хочу сделать «бизнес-логику» реюзабельной между приложениями, и, чтобы не импортировать функции из одного View в другой, храню их отдельно.

Эти проблемы действительно существуют. Зачастую в проекте появляются вспомогательные функции, которые не принадлежат стандартным сущностям Django, вроде Model или View.

Но решение складывать весь этот код в файл services.py, на мой взгляд, плохое. Вот почему:

Слой Services слишком широкий, это плохая рамка. При определении рамок важно не определить, какой код можно класть в этот файл, а решить, какой код в этот файл класть нельзя. Для сравнения, Model хорошо справляется с этой задачей: если код не относится к работе с БД, то ему не место в файле models.py. А в services.py часто кладут всё, что не влезло в остальные.

Файл становится свалкой. Это ожидаемое следствие плохой рамки. Я часто интересуюсь у друзей и у кандидатов на собеседованиях, есть ли в их текущих или прошлых проектах такая проблема: в services.py более 2 тысяч строк кода и по нему тяжело навигироваться. Если в проекте более 10 тысяч строчек кода, разработчики почти единогласно говорят, что файл превращается в свалку.

Файл размывает слой View. Есть мнение, что в файл services.py нужно выносить бизнес-логику. Термин «бизнес-логика» кажется конкретным — это всё, что определяется правилами бизнеса. Но на поверку он размыт куда сильнее, чем кажется. Разработчики, глядя на функцию, иногда не могут сказать, бизнес-логика это или нет.

Куда девать общий код?

Альтернативное решение — оставить фреймворк в покое и не добавлять в него новый слой. Если появилась новая логика, то создать файл с говорящим названием и положить код в него. Если логики вынести нужно много — создайте несколько файлов. Искать нужную функциональность проще в одном мегафайле на тысячу строк или в пяти небольших по двести строк? Так будет куда понятнее, где, например, искать функцию, которая форматирует дату или преобразует цену товара:

Писать запросы в слое View — это нормально

Я так и не разобрался, откуда взялся миф о том, что во View нельзя писать запросы в БД, и в чём аргументация его сторонников. Это правило просто откуда-то «взялось», и теперь в него верят как в аксиому.

Тем не менее в документации Django для слоя View очень простое определение:

The view itself contains whatever arbitrary logic is necessary to return response.

Соответственно, в этом слое можно делать ORM-запросы, если это нужно для ответа. Не обязательно пытаться «прятать» этот код куда-то ещё.

Часть запросов будут нести бизнес-смысл, то есть они станут частью бизнес-логики. Иногда это будет даже не один запрос в БД, а несколько, или даже пара строк кода между ними.

По принципу MVC «Fat models, skinny controllers, simple views», большую часть такого кода стоит стараться класть в слой Model. Один из самых недооценённых, на мой взгляд, способов — переопределение QuerySet. Этот способ позволяет взять здоровый запрос на 10 вызовов методов ORM и дать ему простое, бизнесовое название.

Со слоем Services получается «Skinny Models, Skinny Controllers, Fat Services». На мой взгляд, это очевидное отхождение от принципов, которые изначально закладывались в фреймворк.

Приложения (app)

Сейчас эпоха популярности микросервисов над монолитами. Из-за этого сама архитектура Django-монолита стигматезируется, некоторые мои знакомые даже не пытаются пилить Django-монолиты на приложения. Но ведь «монолит» не равно «свалка»! За ним всё ещё стоит ухаживать.

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

Можно представить, что MTV разделяет код на «красное», «синее» и «зелёное», а приложения — это разделение на «круглое», «квадратное» и «треугольное». Важное правило в делении логики на приложения — Cohesion and Coupling. Если коротко, это о связности между приложениями: нужно добиваться состояния, когда у вас мало связей между приложениями и много внутри них.

Вот к этому нужно стремиться:

Между «разделёнными группами» связей мало, почти все связи спрятались внутри групп. Кружочки одного цвета — это части кодовой базы, которые сильно связаны друг с другом.

А вот такого стоит избегать:

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

Справа совсем всё плохо: код разделён на такие маленькие группы, что каждый кусочек кода сам по себе стал «группой». Это называется ‘Destructive decoupling’.

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

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

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

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

Не стесняйтесь создавать новые приложения.

Что делать, если одна модель не помещается ни в одно из приложений? Создайте для неё отдельное!

А что, так можно? В целом ПРИЛОЖЕНИИ будет всего одна жалкая моделька?!

Да, можно. Даже нужно.

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

Процесс выделения этой логики в новое приложение будет болезненным, и, делая это, вы будете задаваться вопросом: «какой м**ак раскидал эту логику по приложениям?».

Очевидно, слишком увлекаться тоже не стоит. Иначе столкнётесь с Destructive decoupling. Но и бояться создания приложений не нужно.

Файлы

Ещё один слой разделения логики по фреймворкам — это файл. Мы касались темы файлов выше, давайте резюмируем уже сказанное:

1. Свалка в файлах вредит навигации по проекту.
2. Cohesion and Coupling поможет разложить логику по файлам.
3. Не стесняйтесь создавать файлы, даже если кода внутри будет мало. Это поможет потом не страдать, выкорчёвывая функции из кода.
4. Название файла должно задавать чёткую однозначную границу, говорить о том, какому коду здесь не рады. Иначе свалки не миновать.

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

С файлами аналогично, это тоже контейнер для кода. Просто функции хранят в себе строчки кода, а файлы хранят в себе функции.

У ситуации «переборщили с количеством файлов» есть надёжный симптом — читая интересующий код, вы не задерживаетесь в одном файле больше, чем на 30 секунд. Всё время приходится двигаться по файлам туда-сюда. А это и есть нарушение принципа Cohesion and Coupling.

Итоги

Если во время чтения статьи вы успели потерять основные тезисы, то вот небольшой конспект. ?

1. Services – не часть MTV;
2. Плохое название файла приведёт к свалке;
3. Можно писать запросы в слое View, не бойтесь этой практики;
4. Монолит – не повод сваливать всё в кучу;
5. Группировать по юзкейсам лучше, чем по сущностям;
6. Не стесняйтесь создавать новые файлы и приложения, даже если кода в них мало;
7. Разложить логику по файлам поможет Cohesion and Coupling.

Веб-разработка

• В чём преимущества TypeScript перед JavaScript? Как минимум в декораторах!
  Показали всю мощь декораторов на живых примерах.

• Создавать крутые анимации можно с помощью простого CSS.
  Юлия Миоцен рассказала о 10 свойствах, которые прокачают ваш скилл

• Хотите лучше понимать структуру своего кода или объяснить её несведущему?
  Эта библиотека для визиуализации JS-кода вам точно пригодится.

Python и Django

• А хорошо ли вы знаете Python?
  Проверьте себя, ответив правильно на 101 вопрос, ответы на которые должен знать каждый питонист.

• Копейка рубль бережёт, а контроль трат помогает следить за бюджетом.
  Рассказали, как анализировать расходы с помощью фотографий чеков и Python.
• Хотите освоить Django?
  Этот видеокурс поможет вам.

Точка входа: полезности для начинающих программистов

• Получаем зарубежное образование, не вставая с дивана.
  Бесплатный курс по Java от Стэнфордского университета вам в этом поможет.

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

Полезные инструменты, книги и лайфхаки для разработчиков

• Не Copliot’ом единым.
  Рассказываем про TabNine — интеллектуальный автодополнитель кода на базе ИИ.

• Хотите огромную библиотеку полезных ресурсов для дизайнеров и разработчиков?
  Так вот же она!
• Рассказали про книгу, которая поможет разобраться в собственном мышлении и научит быть максимально продуктивным.
  Но только если хотите стать джедаем!
• А следующий материал специально для шарпистов.
  Если хотите отточить свои навыки работы с C#, то забирайте этот практикум.

GameDev

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

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

Мобильная разработка

• Теперь вы точно не заблудитесь.
  Держите дорожную карту для Android-разработчика на 2023.

• Чем придумывать велосипед, лучше взять проверенное решение.
  Вот 6 полезных шаблонов проектирования, которые пригодятся каждому Android-разработчику.

Нейросети

• ChatGPT теперь и дизайн за вас сверстает.
  Энтузиасты смогли интегрировать ИИ прямо в Figma.

• Без чего не обойдётся ни одна нейросеть — это вычислительные мощности.
  Рассказали, какая видеокарта подходит для этого лучше всего.

• Изучаете Flutter?
  Тогда держите целых 30 различных проектов и библиотек для Flutter.

• Что будет, если объединить GPT с гуманоидным роботом? Нет, не сюжет фантастического фильма.
  А вполне реального видео.
• Хотите узнать, кого вскоре могут заменить нейросети?
  Тогда скорее сюда, заодно узнаете, как они работают.

Soft skills

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

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

Немного юмора

• Кто вы: джун, миддл или сениор?
  Эта картинка поможет вам разобраться.
• Если хотите узнать, каким вы будете дедом.
  Типичный разговор с внуком через несколько лет.
• Работаете с криминальными элементами?
  Тогда попробуйте этот способ распределения задач.

Узнайте, как заказать столик в ресторане при помощи ChatGPT, как инвестировать эффективнее при помощи Big Data, как создать свой голосовой помощник и почему лень — это не порок.

Big Data / Data Science

• msgspec: быстрый и экономичный парсинг JSON на Python
• Консистентность в конкуретной среде: как не захлебнуться в потоках данных
• Почему Data Science не для вас?
• Дублирующий скрипт: как с его помощью мы ускорили бизнес-процесс с двух рабочих дней до семи минут
• Синтетические данные для машинного обучения: их природа, типы и способы генерации
• EN Graph Databases vs Relational Databases: What and why?
• EN The ultimate guide to Pandas’ read_csv() function
• EN I made a Finance Database with over 300.000 tickers to make Investment Decisions easier
• EN So, You Recommended a Python Time-Series Package … Now What?
• EN Everything you need to know about pandas 2.0.0!

AI и ML

• Основы генеративно-состязательных сетей
• Учим английский с chatGPT
• ML-пайплайн классических банковских моделей классификации
• Как подружить Алису с ChatGPT
• Как создать свою собственную нейронную сеть с нуля на Python
• Ирина, голосовой помощник — теперь и со вкусом GPT-3
• Распознавание подачи в волейболе с помощью машинного обучения
• EN A Beginner’s Guide to Prompt Engineering with GitHub Copilot
• EN OpenCommit: GPT generates impressive commits in 1 second 🤯🔫 (open-source, 50k views)
• EN LLMs will fundamentally change software engineering
• EN Using GPT-4 and Dalle2, I made a Python script that auto-generates memes without any input…
• EN Introducing gptty v0.2.1 – A Powerful CLI Wrapper for ChatGPT with Context Preservation & Query Support, Now on PyPI!
• EN Free-to-use GPT-3 powered command-line shell (no API-key required)

Веб / Django / Flask

• Декоратор cached_property
• Django DRF Sign-in with Apple
• Может ли chatGPT забронировать столик в ресторане через WhatsApp?
• EN How to Create a Simple Web App with Python and Flask in 8 Easy Steps
• EN Learn How to Test Flask Applications with Pytest
• EN Design architecture for large file downloads
• EN Learn How to Create a CI Pipeline for Your Django Application
• EN Implementing Multiple User Types in Django
• EN Turbocharge Your Django Application: Mastering Database Partitioning for High Traffic Optimization

Скрипты, приложения и боты

• Ультимативный Roadmap для Python-разработчика в 2023 году + источники знаний
• Пишем простого бота-администратора для Telegram на Python. Тестируем на жене
• Как я чистила текст от ударений в словах при помощи Python
• 7 уровней построения интерфейсов командной строки на Python
• Ломаем текстовую капчу на примере VK или брутфорсинг до сих пор актуален
• Решаем задачу по взаимодействию микросервисов на Python тремя способами
• EN Contribute to the Python-like Nim language
• EN Why use classes?
• EN Nanobind is a small binding library that exposes C++ types in Python and vice versa
• EN Arguments against separating `test` from `src` in a python package?

Развлекательный контент

• История о том, как прочитать 120 тысяч анекдотов и не рассмеяться раньше времени
• Байки погромиста. Если кто-то скажет, что программирование — это скучно
• EN I am a lazy developer
• Видео Moscow Python Meetup №81. Вступление.
• Видео Moscow Python Meetup №81. Николай Марков. Контейнерные змеи
• Видео Moscow Python Meetup №81. Евгений Соколов. Лучший язык — это… или Пайтон против Суслика
• Видео Moscow Python Meetup №80. Максим Безруков. Кто такой syslog, зачем читать RFC-* и причём тут Django

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

Если дайджест вам понравился, посмотрите две предыдущие подборки:

А ещё присылайте в комментарии статьи и видео, которые ускользнули от нашего взгляда и не попали в дайджест. Поделитесь полезными материалами с другими читателями! 😉

Веб-разработка

• Не всем нужны мощные сервера. Иногда для небольшого проекта достаточно смартфона.
  Рассказали, как запустить на Android-смартфоне веб-сервер.

• Не только Илон Маск с Neuralink думает о том, как соединить мозг и компьютер.
  Но энтузиасты пошли дальше и «соединили» мозг с ChatGPT с помощью JavaScript.

Python и Django

• Ищете полезные ресурсы по Python?
  Делимся подборкой лучших ресурсов для изучения Python.
• Иногда плаваете в синтаксисе и забываете, за что отвечают те или иные функции?
  Держите большую обновляемую шпаргалку по Python.
• Используете Django?
  Вот 6 важных советов, чтобы сделать ваше приложение безопасным.

Точка входа: полезности для начинающих программистов

• Держите карту.
  Но не сокровищ, а изучения SQL.
• Куда идти в IT?
  Рассказали про 6 востребованных IT-специальностей.
• Есть вопросы про IT, но не знаете, где спросить?
  Организовали пост взаимопомощи — спрашивайте и помогайте другим.

Полезные инструменты, книги и лайфхаки для разработчиков

• Хотели бы быстрее и легче отслеживать ошибки в коде?
  Вот инструмент, который анализирует ваш код и находит проблемы, ошибки и дубликаты кода.
• Если вы делаете какую-то фичу, подумайте, а не сделал ли кто-то её за вас.
  Швейцарский нож для веб-разработчиков, который содержит набор готовых решений.
• Терминал пугает начинающих пользователей. Но для опытных это незаменимый помощник.
  Рассказали про гайд по самым полезным командам для работы в Windows, Linux и MacOS.
• Эта книга понравилась нашим читателям больше всего. Рассказываем, почему стоит почитать «Прикладное программирование на C/C++».

Gamedev

• ИИ теперь и игру на Unity за вас написать может.
  Рассказали про ​AI ассистента для редактора Unity3D.
• А ещё — сгенерировать модели и код для Blender.
  Показываем, как создавать 3D-сцены в Blender с помощью GPT-4.
• Наверняка вы играли в Тетрис?
  Игра настолько культовая, что на AppleTV+ вышел фильм «Тетрис» про советского программиста Алексея Пажитнова.

Нейросети

• Copilot от Microsoft станет ещё лучше!
  Рассказываем, что изменится в GitHub Copilot X.
• Илон Маск и Стив Возняк призывают остановить обучение ИИ хотя бы на полгода.
  Забота о людях или конфликт бизнес-интересов?
• Энтузиаст встроил GPT-4 в Apple Watch.
  Показали, как это выглядит.

Soft skills

• Коллеги токсичат?
  Бережем психику и боремся с токсичностью коллег.
• Думаете, что вы плохой специалист?
  На LinkedIn нашли резюме человека, который абсолютно «не создан для работы».
• Рекрутеры любят вгонять в стресс.
  Рассказываем про стрессовое интервью и 8 фишек рекрутёров.

Немного юмора

• Такие созвоны точно стоит пропустисть.
  Как проходит типичный созвон.
• Слышали пор пик Балмера? Нет?
  Тогда мы идём к вам.
• Бывало такое, что без мата коллеге не объяснишь все «претензии»?
  Наконец-то кто-то может перефразировать ваш крик души в доброжелательный текст без не нормативной лексики.

Узнайте, как написать свой аналог GitHub Copilot без знаний об искусственном интеллекте, как работать с данными и памятью в Pandas и как написать нейросеть, которая сможет самостоятельно распознавать объекты.

Big Data / Data Science

• Data Mesh: что это такое и для чего он нужен инженерам
• 9 баз данных NoSQL, актуальных на 2023 год
• Как и зачем оценивают индекс зрелости ИИ
• Большие данные мертвы. Это нужно принять
• Процесс ELT: основные компоненты, преимущества и инструменты создания
• Отображение графа на Python с networkx
• Откуда есть пошла аналитика и что отличает DS, DA, BA и SA
• HalvingSearch: ускорение поиска по сетке (grid search). Библиотека sklearn
• Не пытайтесь измерить использование памяти в Pandas
• Перевод предобученной модели Keras на матричные вычисления
• CutTheLog – когда он слишком большой
• EN Using on Disk Storage With an In-Memory Graph Database
• EN Data Preprocessing Using Python
• EN 3 Quick and Easy Ways to Visualize Your Data Using Pandas
• EN PyGWalker: A Python Library for Visualizing Pandas Dataframes
• EN Create Audience Segments Using K-Means Clustering in Python
• EN Mastering Missing Data in Python: Tips for Data Scientists
• EN Reading and Processing Data with Pandas: A Guide to Using read_csv() with CSV Files

AI и ML

• Генерация 2D мира с помощью клеточного автомата на Python
• Цепочка методов в pandas. Прокачиваем свой код. Минигайд для интересующихся
• Просим бота написать бота
• Как без денег и знаний в AI повторил Copilot’а
• Прости нас, Джон Коннор, или Как мы научили нейросеть точечно распознавать звуки выстрелов
• Пишем нейросеть для сегментации снимков со спутника
• Как я делал ChatGPT бота в Salebot и ничего не вышло
• Как создание бинарного классификатора открыло ящик Пандоры в стандартах владения английским языком
• AIGod — распознавание объектов
• Учим нейросеть принимать решения на основе уже известного опыта (на примере Шахмат и загруженного датасета)
• Классификация изображений в облачной системе Google Colab
• Визуализация архитектуры модели PyTorch
• EN Building a Reddit Thread Summarizer with ChatGPT API
• EN Exploring the Intersection of AI and Physics: The Role of ChatGPT in Code Generation
• EN A Simple Guide to The (New) ChatGPT API with Python
• EN Write Readable Tests for Your Machine Learning Models with Behave
• EN Harness the Power of ChatGPT Without API Credits: Introducing GPT_scraper
• EN End-to-End Speech Recognition with Python
• EN How to Create an AI-Powered Chatbot with Gradio and OpenAI’s GPT-3.5

Веб / Django / Flask

• Python, Django и немного защиты кода
• Как разработать канбан-доску на Django, DRF и Alpine.js
• Основы PyCharm
• Как избежать проблем при запуске MVP
• EN Checking Whether a Celery Task is Already Running
• EN Developing Strong SEO Tools Using Python
• EN Tutorial: How to Create ChatGPT API Python Web App — Personalised AI Chatbot Assistant with a Twist…
• EN Setting up Pre-Commit in a Django Project: A Step-by-Step Guide
• EN Django Query Optimization
• EN Flask vs Django vs Streamlit
• EN From JavaScript to Python and Django: How to Master a New Language and Framework
• EN Logging in Django

Скрипты, приложения и боты

• Python для начинающих: дорожная карта в 2023 году
• Как я написал Telegram-бота для учёта подписок
• Бот для телеграмма, использующий Яндекс.Диск (Python)
• Отслеживаем изменения в doc и docx при помощи Python
• SimpleUI — фреймворк для быстрого создания бизнес приложений на Android
• Книга «Внутри CPYTHON: гид по интерпретатору Python»
• Парсинг данных через api vk и google sheets api на python
• Создаем библиотеку теории игр на питоне: как вообще это будет работать?
• Как я проводил обратную разработку таинственного UDP-трафика в гостиничном номере
• Пагинация в telegram-боте для чайников
• API Честный знак как получить ключ сессии
• EN Effectively Use %timeit, %lprun, and %mprun to Write Efficient Python Code
• EN Distributing Python Main and Submodules on PyPi
• EN 12 Python Scripts for Optimising Your Code Development
• EN Memory management in Python
• EN Most Exciting Python Features from 3.7 to 3.11
• EN Python SDK: The Release
• EN pyaction 4.17.0 Released
• EN Understanding Python Metaclasses
• EN Introducing Inkwell: A lightweight, easy-to-use terminal-based text editor

Развлекательный контент

• Какая ты IT-принцесса?
• Диалог между JS и Python если бы они были людьми
• Видео ПОРА РАЗОБРАТЬСЯ С ООП В PYTHON 3 | BALABOL IT PYTHON PODCAST
• Аудио Новости Python за февраль 2023
• EN What is the funnest project you worked on?

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

Если дайджест вам понравился, посмотрите две предыдущие подборки:

А ещё присылайте в комментарии статьи и видео, которые ускользнули от нашего взгляда и не попали в дайджест. Поделитесь полезными материалами с другими читателями! 😉

Узнайте, как написать свою GPT-модель всего за 60 строк кода, какие обновления коснулись Python в версии 3.12 и как повлиять на работу коммунальных служб с помощью машинного обучения.

Big Data / Data Science

• Как ускорить пилотные проекты по анализу больших данных
• Викторианская история больших данных
• Как мы чуть не взломали шифровальщик Phobos с помощью CUDA
• Неудачный опыт: выявление аномалий в данных методами кластеризации
• Книга «Основы Python для Data Science»
• EN Roads and building density in North America. 100GB geodata processing OSM data in PostgreSQL
• EN How to put the whole world into a regular laptop: PostgreSQL and OpenStreetMap
• EN Pandas 2.0 is Here
• EN Exploratory Data Analysis in Python, Using Just 9 functions
• EN A Gentle Guide Of Pandas
• EN Pandas meets Pyarrow? A Data Scientists Dream Come True
• EN NumPy Library: Everything a Newbie Needs to Know
• EN Polynomials in NumPy
• EN Pandas vs Numpy: Which Python Library is Best for Data Analysis and Numerical Calculations?

AI и ML

• Как улучшить точность ML-модели используя разведочный анализ
• О «раздутом пузыре» нейросетей
• 10 первых ошибок в карьере ML-инженера
• Об экшн-трансформере как следующем этапе развития модели трансформер и не только
• Книга «Грокаем алгоритмы искусcтвенного интеллекта»
• Пишем GPT в 60 строк NumPy (часть 1 из 2)
• Пишем GPT в 60 строк NumPy (окончание, 2/2)
• Взгляд компьютерным зрением на работу коммунальных служб
• EN Top 15 Artificial Intelligence Tools
• EN PyTorch vs TensorFlow — spotting the difference
• EN Understanding PyTorch with an example: a step-by-step tutorial
• EN Build PyTorch from Source with CUDA 11.8 with Ubuntu 22.04
• EN Coding your own AI in 2023 with fastai

Веб / Django / Flask

• Пишем сервис для сокращения ссылок на Django, DRF
• Отгадай слово: как мы создали игру с элементами машинного обучения и вышли в ноль за 2 месяца
• Как мы сделали образовательную игру для разработчиков в телеграмме?
• Как изучать язык Python для веб-разработки в 2023 году. Общие ориентиры
• Личный путь и опыт в становлении Python разработчиком
• EN How to change django-ckeditor image properties dialog text colors when using dark theme
• EN Securing Your Django REST API with Authentication and Authorization
• EN Best Practices for Django Development
• EN Django MVT vs Laravel MVC: A Technical Comparison
• EN Encrypto: The Ultimate Guide to Building a Secure File Encryption Web App with Flask and Python
• EN Python WebServer With Flask and Raspberry Pi
• EN Building a Social Network with Flask and Neo4j
• EN Building a Real-Time Twitter Sentiment Analysis Web App with Python and Flask
• EN Building a Voice Assistant using OpenAI API and Flask — by ChatGPT
• EN How to Create a YouTube Transcript Generator Web App with Python Flask with ChatGPT
• EN A Similarity between CSS and Python
• EN 10 Game-Changing No Code/Low Code Tools Every Developer Should Know About

Скрипты, приложения и боты

• VS Code, python, контейнеры — как обуздать эту триаду и разрабатывать внутри контейнера
• Как при помощи Rust в 150 раз ускорить код на Python
• Создание модуля WebAssembly с помощью Emscripten, AssemblyScript и Rust
• Как разработать Telegram-бота для генерации сложных паролей
• Сколько стоит содержать виртуальную девушку? Создаем подругу, записывающую кружочки в Telegram, с помощью 4 нейросетей
• Что нам несет Python 3.12
• История одного соседа ч.2
• EN Extract Tables From Images in Python
• EN How to Code a Caesar Cipher in Python
• EN Stock News Sentiment Analysis with Python with 50 lines of code
• EN Python — Converting Non-Square Images To Square Images

Развлекательный контент

• Я только спросить: разводим ChatGPT на откровенность по методу Илона Маска
• Bing: «Я не причиню вам вред, если только вы не причините мне его первым»
• Видео  Почему в Python реализована глобальная функция len() и что об этом говорит Гвидо ван Россум?
• Видео  Собеседование python разработчик Игорь Шкода. Ведет Олег Кожанов
• Видео  Новинки в Python 3.12 / Опять переписали виртуальную машину / Большая чистка stdlib
• Видео 14 Ideas for Fun Python Free Time Projects

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

Если дайджест вам понравился, посмотрите предыдущие подборки:

А ещё присылайте в комментарии статьи и видео, которые ускользнули от нашего взгляда и не попали в дайджест. Поделитесь полезными материалами с другими читателями! 😉

Шпаргалки по HTML

Язык гипертекстовой разметки — основа фронтенда и не даром стоит на первом месте в перечне HTML/CSS/JS. Не стоит забывать и об HTML5 — пятой и последней версии.

Следующая шпаргалка содержит основные теги HTML5:

Если же вас интересуют коды спецсимволов, то они собраны здесь:

Шпаргалки по CSS

Дальше ожидаемо идёт стилизация элементов с помощью CSS. И несмотря на то, что CSS4 разрабатывается W3C с 2011 года, CSS3 всё ещё актуальная версия. Держите шпаргалку, которая упростит работу с каскадными таблицами стилей:

А за хинтами по CSS Grid и Flexbox можно обратиться к нашим статьям:

• CSS Flexbox в гифках
• CSS Grid в примерах

Шпаргалки по JavaScript

Этот язык не нуждается в представлении — его знает каждый веб-разработчик. Для тех, кто интересуется функциональным программированием на JS, есть такие подсказки:

Отдельного внимания заслуживает шпаргалка для веб-разработчика по массивам, строкам и регулярным выражениям в JavaScript:

Ещё один небезызвестный представитель в веб-разработке — Node.js. По нему тоже есть полезный список подсказок:

Шпаргалки по PHP

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

В следующей шпаргалке для веб-разработчиков собрана информация о синтаксисе PHP — отлично подойдёт для начинающих:

А это краткое руководство по PHP с массивами, строками, регулярными выражениями, форматами дат, паттернами и многим другим:

Шпаргалки по Django

Одну из них вы можете найти в шпаргалках по Python. Вторая же вышла в 2021 году и содержит более полную информацию, включая атрибуты модели, работу с базами данных и деплой на PythonAnywhere:

Видеокурс по Spring Boot

Java является одним из наиболее популярных кроссплатформенных языков программирования. Большое распространение в веб-разработке он получил благодаря Spring Boot.

Это не совсем шпаргалка, а комплексный видеокурс, который тем не менее поможет освоить инструмент и создать своё первое веб-приложение на Java:

Что-то упустили? Напишите в комментариях — мы всегда рады дельным советам.

Узнайте, как изменился Python в версии 3.11, как написать ботов в WhatsApp и Telegram для работы с финансами, как прокачать свои знания в Python с помощью пятиминутных упражнений и как написать тестовое задание на собеседовании при помощи ChatGPT.

Новости Python и дискуссии

• JEP-400 или UTF-8 РєРѕРґРёСЂРѕРІРєР° РїРѕ умоЫчанию
• Субъективные итоги 2022 года в мире Python
• Лучший язык программирования: рейтинг TIOBE 2022
• Видео «Язык года», Самые высокие зарплаты в 2022, Потрясающие увольнения в IT и другие новости
• EN Python 3.11: Improved Type Hints
• EN Allow import … from … notation

Гайды и туториалы по Python

• Сделано на Python: экспорт статистики ВКонтакте с помощью Prometeus и Grafana
• Web3: пишем небольшой фреймворк для работы со смарт-контрактами на Python
• Телеграм бот на Python, для напоминаний о реквестах на BitBucket
• Быстрый приём платежей QIWI в проекте Python
• Как правильно сделать рекурсию?
• Как сохранить данные с первого запуска, чтобы во втором запуске их можно было использовать?
• Как реализовать анимацию переливающегося текста css?
• Торговые роботы на Python
• Как отправить и скачать файл в FastAPI
• EN Electron + Django ( Part 1 ), desktop app integrate JavaScript & Python
• EN Introducing Fugue — Reducing PySpark Developer Friction
• EN Django application to automate the WhatsApp messaging
• EN Integrate Stripe Payments with Django By Building a Digital Products Selling App
• EN Building Personalised Music Recommendation System
• EN How to Generate Text with OpenAI, GPT-3, and Python
• EN Making a Game in Python with No Experience

Обучение Python: курсы, упражнения и советы

• NoNa: Алгоритм заполнения отсутствующих данных
• Советы по архитектуре кода для начинающих
• 3 принципа написания чистого кода на Python
• Видео Лучшие способы Ускорить и Оптимизировать Python код
• EN Data Science with Python: A Guide to Essential Libraries and Frameworks
• EN 5 mins LevelUp Your Python in 2023
• EN Repeated string concatenation is quadratic in PyPy (and CPython)
• EN Hexagonal architecture in Python
• EN Google’s Python Class

Развлекательный контент

• Как ChatGPT за меня тестовое задание для собеседования писал
• Воссоздаем старую компьютерную графику с помощью генеративных моделей
• EN Top 10 Python Interview Question and Answers

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

Следующие подборки можно найти здесь:

• Дайджест Python #2: чем плох Django и как создать бота на GPT-3
• Дайджест Python #3: пишем AI-плеер для сайта и боремся с лесными пожарами

А ещё присылайте в комментарии статьи и видео, которые ускользнули от нашего взгляда и не попали в дайджест. Поделитесь полезными материалами с другими читателями! 😉

1. Article

1.0. Используемые технологии

1. Docker и Docker Compose (книга Docker Deep Dive рекомендуется к изучению).

2. Github Actions и Gitlab CI.

3. Task для локальных pipeline workflow.

4. Python frameworks: Django, FastAPI, Flask. Python ORMs + migrating libraries: Django ORM + SQLALchemy/Alembic.

5. Self hosted Github and Gitlab runners with available Docker in Docker.

1.1. Вступление

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

Для таких программных языков как Javascript, Python, PHP, Ruby зачастую это единственный способ заморозить библиотеки зависимостей для получения неизменного артефакта (одного файла), который мы можем поочередно запустить и протестировать на машине разработчика, в облачном тестировочном полигоне и его же запустить на прод.

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

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

Docker является фундаментальным кирпичиком, на основе которого идет дальнейшее построение веб-инфраструктур — Docker Сompose, AWS Elastic Beanstalk, AWS ECS, Kubernetes.

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

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

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

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

Использование Docker или его аналогов в мире веб-разработки является хорошим шагом даже для самых простых случаев. Для примера, установка WordPress требует конфигурации SQL-базы данных MariaDB / MySQL, Apache Web Server в режиме PHP-сервера, который запустит WordPress. Незнакомый с этими технологиями человек может потратить несколько дней на то, чтобы разобраться, как их запустить все вместе. С использованием Docker Сompose это сводится к трем шагам:

1. Установить Docker.

2. Написать в файлик docker-compose.yml следующее:

3. Написать команду docker-compose up -d (-d — флаг запуска в фоновом режиме).

В общей сложности на все это уйдет не более 5 минут.

В рамках работы web-приложений с Python даже в тривиальном случае обычно необходимо множество запущенных процессов к приложению:

• база данных PostgreSQL,
• веб сервер Gunicorn,
• Celery Beat Producer — периодические задачи внутри Python через Message Queue,
• Сelery Worker — обработчик задач,
• Redis — очереди для Celery-задач или же в качестве хранилища кэша быстрого доступа Key-Value, который мы можем использовать из питона.

Часто должны быть установлены какие-нибудь дополнительные Linux-библиотеки по компиляции C-кода или gettext для переводов. Все, что надо установить, и не упомнишь без какого-либо средства автоматизации.

Удобство контейнеризации Докер в том, что… можно смело его использовать даже во время разработки на своей машине. Все равно все наши контейнеры можно остановить и удалить безо всяких загрязнений системы (к примеру, эти команды полностью очистят машину от всех работавших докер-приложений: (docker stop $(docker ps -q), docker system prune -a)

С учетом всех достоинств контейнеризации можно смело заявить, что количество нагрузки, которое она снимает с плеч разработчика, делает ее таким же необходимым инструментом, как файл с зависимостями к любому веб-приложению (package.json / requirements.txt и т.д.).

Зачастую Docker является единственным способом быстро вспомнить и настроить окружение для работы с каким-либо веб-проектом.

Если хотите попробовать контейнеризацию в самом щадящем варианте, изучите Docker Deep Dive и попробуйте Docker и Docker-compose локально на машине.

При работе с прод-проектами можно начать с использования Digital Ocean App Deployment, поддерживающего деплой докер-изображений, а так же AWS Lightsail Container Deployment и AWS Elastic Beanstalk, которые являются самыми простыми вариантами в рамках AWS. Beanstalk тоже из коробки решает горизонтальное масштабирование системы.

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

Подобная инструкция может вам особенно пригодиться, если ваша роль — DevOps Engineer, который отвечает лишь за инфраструктуру системы, но может быть мало знаком с отдельными языками программирования (в частности, с Python) и особенностями их контейнеризации.

Полезным это будет и в случае, если вы просто разработчик Python Backend и хотите настроить свое дев-окружение в более удобном и задокументированном варианте, на уровне выше, чем просто использование virtual venv (ваш DevOps Engineer или тот, кто ответственен за деплой системы, очень обрадуется, увидев Docker-файл к проекту).

1.2. Зависимости

В Python наличествует как минимум 5 способов установки зависимостей к проекту:

• pip-менеджер по умолчанию, установка файлов вида requirements.txt, requirements.dev.text, constraints.txt,
• установка requirements.txt через venv,
• установка зависимостей через Pipenv package manager,
• установка зависимостей через Poetry package manager,
• установка зависимостей через Conda (common for data science/machine learning projects).

4 из них продемонстрированы в Dockerfile для Flask простого проекта.

dep-poetry, dep-pipenv, dep-pip, dep-venv docker stages демонстируруют одноименные установки зависимостей:

Альтернативные варианты установки и настроек можно посмотреть по следующим адресам:

— poetry documentation,

— pipenv documentation,

— pip documentation.

1.3. Веб-серверы

Помимо сказанного нужно учесть и то, что встроенные веб-сервера в Flask/Django/FastAPI, запускаемые через python3 entryfile.py, по умолчанию подразумеваются для использования лишь в разработке.

Python web servers разделяются на две категории:

• WSGI based веб-сервера (вида Gunicorn), использование которых подразумевается для sync Python кода (не содержающего async инструкций),
• и ASGI based веб-сервера (вида Uvicorn), подразумеваемые к использованию для питон-кода, содержащего асинхронный код. Использование Uvicorn для прода с асинхронным кодом подразумевается в паре с Gunicorn, который имеет Uvicorn workers.

Дополнительно нужно учитывать, что питон-веб-сервера не способны возвращать static assets css/js/jpeg and etc. Лучшей рекомендацией сегодня является использовать хотя бы Nginx в режиме reverse proxy к питон-веб-серверу, настроив его возвращать static assets. Ни в коем случае не стоит использовать библиотеки White noise, это решение страшно глючит и медленно работает даже для одного пользователя.

1.3.1. Django (Sync)

Django обычно достаточно настраивать для синхронного кода через WSGI (Django Channels с веб-сокетами для реализации живых чатов, впрочем, существует, и ему нужно ASGI). Вот пример настроенного Django, работающего через Gunicorn-WSGI с Nginx reverse proxy serving static assets. Для такой настройки достаточно установить gunicorn через текущий используемый package manager (pip/poetry/pipenv) и запустить веб-сервер через gunicorn, которому дали путь к WSGI.

В prod-варианте деплоя Python мы как минимум всегда можем указывать количество workers, параллельно обратаывающих запросы gunicorn src.core.wsgi -b 0.0.0.0:8000 —workers 2.

P.S. Django с отключенным settings.Debug = False перестает показывать static assets даже в дев-сервере, работающем через python3 manage.py runserver

1.3.2. FastAPI (Async)

Пример настроенного асинхронного проекта на FastAPI.

Запуск меняется на gunicorn src.core.main:app —workers 4 —worker-class uvicorn.workers.UvicornWorker —bind 0.0.0.0:8000

Помимо смены веб-сервера с WSGI на ASGI, асинхронные фреймворки питона требуют и асинхронно дружелюбных библиотек, и драйверов для PostgreSQL в том числе. Если для синхронного Django нам достаточно установить psycopg2-binary pip package (обратите внимание, что psycopg2-binary не требует установки C-компилирующих зависимостей, в отличие от библиотеки psycopg2), то для асинхронного фреймворка нам нужно также установить asyncpg для PostgreSQL.

Аналогично в асинхронном фреймворке все используемые библиотеки должны быть async-дружелюбными: aiohttp вместо requests, к примеру, для выполнения сетевых запросов.

1.4. CORS headers

Последняя, самая частая проблема при деплое — CORS headers, которые должны быть часто настроены.

— Для Django это решается через django-cors-headers.

— Для FastAPI — через встроенную библиотеку CORSMiddleware.

Примеры проектов Django с Nginx в режиме CORS, разрешающим все, можно найти здесь.

И пример для FastAPI здесь.

1.5. Помимо прочего

Каждый из питон-фреймворков имеет богатую документацию деплоя с разными решениями:

— Django Deployment (Там есть и полезный checklist для деплоя),

— FastAPI Deployment,

— Flask deployment.

Для Django и FastAPI (и минималистичного варианта под минималистичный Flask) в рамках этой статьи представлены варианты конфигурации контейнеризации с Docker Compose и настроенными выполнениями unit-тестов, создающими объекты в PostgreSQL через Pytest framework.

Обратим внимание, что Django ORM миграции БД, создаваемые через python3 manage.py makemigrations, должны быть закомиттены в репозиторий и могут применяться к БД через python3 manage.py migrate.

Для FastAPI и Flask частым решением используется SQLALchemy для ORM и Alembic для миграции БД. alembic -c src/alembic.ini revision —autogenerate -m «migration_name» для создание миграций БД, alembic -c src/alembic.ini upgrade head — для применения всех до последней миграций к БД.

1.5.1. Static assets

Фреймворку, возможно, еще нужно будет добавить параметр, куда собирать static assets, и во время сборки докер-изображения собрать их туда.

Django: ./manage.py collectstatic —noinput —clear (см. STATIC_URL / STATIC_ROOT в settings.py)

1.5.2 Translations

Если во фреймворке используется translations, понадобится дополнительный шаг во время сборки Docker-изображения для этого.

— Django: python3 manage.py compilemessages.

— Flask: инструкции здесь, если используется Flask-Babel.

— FastAPI: Для FastAPI очевидных решений нет, возможно, используется gettext.

1.5.3. CI pipeline build & test

Ниже предоставлены примеры настройки CI agnostic pipeline workflows через task (которые можно исполнять локально!) и docker-compose:

— для Github Actions,

— для Gitlab CI.dockerize python

2. FAQ

Общее для проектов на Python

Приложение является самостоятельным или это виртуальный хост для веб-сервера?

В общем случае Python веб-приложения самостоятельны и деплоятся через Gunicorn/Uvicorn/WSGI/ASGI и прочие веб-серверы питона (см. полный список в ссылках документации по деплою фреймворков в главе 1.5).

Однако питон-веб-сервера не могут возвращать static assets css/js/jpeg и т.д. В этом случае их возвращают через Nginx, работающий заодно в режиме reverse proxy к питон-серверу.

Nginx и прочие reverse proxy используются в том числе для аугментации вида «регулировать headers», «добавить client side или server side caching».

Питон-веб-сервер можно напрямую сдеплоить через Apache mod_wsgi, например, но это малопопулярное решение. Если очень хочется feature rich возможностей, посмотрите в сторону uWSGI (очень много фич).

И хотя некоторые питон-сервера могут прикрепить TSL-сертификаты, все же проще это сделать через Nginx или иные внешние решения.

Приложение можно запустить в одном контейнере?

Да, можно — при ряде условий:

• если в приложении нет никаких добавок вида Celery (Message Queue),
• если static assets нет необходимости возвращать (для REST API в общем случае не нужно, если только это не Django приложение с используемым Django Admin интерфейсом),
• если для кеширования не нужен Redis или Redis деплоится где-то отдельно.

Иначе даже для одного dev environment используется множество контейнеров: контейнер под PostgreSQL, Redis, основной web server, celery beat (cron like message queue task producer), celery worker (message queue worker), celery flower (message queue monitoring) + nginx (в качестве reverse proxy + serving static assets) — см. пример возможного большого количества контейнеров.

Требуется ли приложению установка зависимостей?

Да, читайте главу 1.2 Зависимости.

Если в проекте применяется вызов вставок C-кода или какого-либо вида Golang, то может как минимум понадобиться установка библиотек компиляции C-кода. Большое количество деталей по разным вариантам описано в книге Python Expert Programming 4th edition в главе C extensions.

Best practices по контейнеризации

• Те же, что и везде: сжимать в один шаг установку и очистку кеша.
• Использовать multi staging… который в основном не нужен, так как компилируют веб-приложения к бинарникам редко.
• Сначала установить зависимости, потом копировать остальной код.
• Нормально иметь Python-код собранным в packages от root folder, чтобы хаков PYTHONPATH с обнаружением модулей и packages не потребовалось (root-папка не должны иметь __init__.py файл, а каждая копируемая папка с Python-кодом должна иметь __init__.py на всех уровнях. И пути импорта прописаны по-человечески — абсолютные от root folder или относительные).
• Использовать ENVIRONMENT variables, а не .env-файлы (их можно разве что для локальной дев-разработки).
• Если настроите logging library вместо print, то совсем молодцы.
• Флажок ENV PYTHONUNBUFFERED 1 нужен, чтобы логи нормально вылезали из контейнера.
• Флажок ENV PYTHONDONTWRITEBYTECODE 1 тоже можно поставить, все равно кэш питон-кода в контейнере будет только занимать лишнее место.
• Не забывать, что assert синтаксис используется лишь в тестировании, а для прода может быть и выключен. Так что лучше его не иметь в рабочем коде.
• Если когда-нибудь будете копировать venv папку с уже установленными зависимостямив контейнер, учтите, что его абсолютный путь не должен меняться, иначе он сломается. Но вообще копировать его — моветон, устанавливайте зависимости в контейнерах во время сборки xD.
• Не копируйте мусор вида __pycache__ в контейнер, настройте .dockerignore.
• Как минимум нужно настроить масштабирование количества процессов workers (для вариантов более feature rich можно посмотреть в сторону uWSGI).

Нужны ли дополнительные скрипты (bash etc) для сборки/запуска приложения?

Для веб-приложений обычно нет, однако c Makefile, или task, или paver жить проще. Либо же просто делать скрипты со встроенной библиотекой argparse. Или через click. Все индивидуально для веб-проектов.

Для приложений, собираемых в бинарники файла вида setup.py от https://pypi.org/project/setuptools/ либо иные, могут наличествовать чисто питон-скрипты/библиотеки для сборки проектов. Для этого случая можно составить список самых частых решений. В рамках статьи сборку бинарников, а также публикацию библиотек на pypi мы не рассматриваем.

Что обычно кэшируется в CI/CD-пайплайне?

При контейнеризации нам, в общем-то, ничего кэшировать и не нужно. Однако если бы этого не было, можно было бы закэшировать устанавливаемые pip packages или используемый venv (под капотом он используется почти для каждого из менеджеров (poetry/pipenv), но в зависимости от Package manager отличается путь, где кэшировать их зависимости).

Gitlab CI template for python

Frameworks

Существуют ли еще какие-либо предварительные процедуры для приложения, кроме установки зависимостей?

Django

Да, в статье большинство из них перечислено:

• Смена dev-сервера на боевой WSGI (для синхронного питона) или ASGI (для асинхронного питона).
• Установка питона нужной версии (или использовании Docker image с нужной питон-основой).
• Установка pip, если отсутствует (python3 -m ensurepip), для установки дальнейшей зависимостей.
• Установка используемого package manager (pipenv, poetry).
• Установка зависимостей.
• Отключение дебага.
• Смена Django-секрета на что-нибудь другое из ENV.
• Настройка env-переменных через os.environ или альтернативные решения.
• Настройка CORS headers.
• Настройка, куда собирать static assets и компилировать их в одну папку (если используются html-возможности Django).
• Компиляции переводов, если используется (python3 manage.py compilemessages), установка OS-зависимостей вида gettext.
• При использовании библиотек питона с компиляцией через C должны быть установлены прочие дев-инструменты компиляции.
• Мигрировать БД потом через python3 manage.py migrate.

См. пример докер-файла для Django.

FastAPI

В основном повторяет Django-шаги, некоторые вещи повторно не упоминаются:

• Смена сервера на боевой асинхронный ASGI-сервер (для примера Gunicorn с Uvicorn workers) с увеличением количества workers.
• Настройка CORS headers.
• Установка используемого package manager (pipenv, poetry).
• Установка зависимостей.
• Мигрировать БД потом для SQLALchemy через: alembic -c src/alembic.ini upgrade head (или иной используемый ORM).

См. пример докер-файла для FastAPI.

Flask

В основном повторяет Django-шаги, некоторые вещи повторно не упоминаются:

• Смена dev-сервера на боевой WSGI (для синхронного питона) или ASGI (для асинхронного питона).
• Отключение дебага.
• Установка используемого package manager (pipenv, poetry).
• Установка зависимостей.
• Настройка CORS headers.
• Настройка, куда собирать static assets и компилировать их в одну папку (если используются html-возможности Django).
• Компиляции переводов, если используется (Flask-Babel?), установка OS-зависимостей вида gettext.
• Мигрировать БД потом для SQLALchemy через: alembic -c src/alembic.ini upgrade head (или иной используемый ORM).

Ещё одно следствие лидирующей позиции языка — рост популярности фреймворков на его основе. Фреймворки существуют для того, чтобы упрощать жизнь программисту. Они помогают экономить время, потому что благодаря им разработчик фокусируется на логике работы приложения, а не на рутинных задачах.

Многие современные технологические компании, такие как Google, Netflix, Яндекс, выбирают Python-фреймворки для веб-разработки. И им есть из чего выбрать.

Django

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

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

Ключевые особенности Django:

• наличие собственного ORM (от англ. Object-Relational Mapping, «объектно- реляционное отображение»);
• встроенный административный интерфейс (простым языком — админка);
• шаблонизатор;
• библиотека работы с формами;
• система кэширования и интернализации;
• система авторизации и аутентификации.

CherryPy

Фреймворк CherryPy, которому уже более десяти лет, зарекомендовал себя как исключительно быстрый и стабильный продукт. Одна из изначальных целей основателя проекта Реми Делона — сделать CherryPy максимально соответствующим принципу «pythonic style». Это позволило разработчикам использовать этот фреймворк как обычный модуль Python и не думать об особенностях веб- программирования. Они могут создавать веб-приложения практически так же, как создают любую другую объектно-ориентированную программу на Python.

CherryPy может выступать в качестве самостоятельного веб-сервера или работать под управлением другого серверного приложения.

Ключевые особенности CherryPy:

• надёжный многопоточный веб-сервер, соответствующий стандарту HTTP/1.1.;
• возможность запускать различные HTTP-серверы (например, на нескольких портах) одновременно;
• встроенные инструменты работы с сессиями, кэшированием, аутентификацией, статическим контентом;
• мощная система конфигурирования;
• встроенная поддержка профилирования и тестирования;
• поддержка Python 2.7+, 3.5+, PyPy, Jython.

Pyramid

Набирающий популярность фреймворк Pyramid универсален. Его можно использовать для проектов любого уровня сложности. Он заслужил высокие оценки в среде Python-разработчиков благодаря своей прозрачности и проверенной временем надёжности. Его используют такие технологические гиганты, как Mozilla, Yelp, Dropbox и SurveyMonkey.

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

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

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

Ключевые особенности Pyramid:

• возможность написать приложение в одном файле;
• обслуживание запросов на статические файлы;
• панель инструментов для отладки приложения прямо в браузере;
• расширяемые взаимозаменяемые шаблоны (template);
• встроенная интернационализация;
• кэширование HTTP; встроенная поддержка сессий;
• управление транзакциями, в том числе при работе сразу с несколькими базами данных;
• гибкая расширяемая аутентификация и авторизация;
• автоматизация повторяющейся конфигурации.

TurboGears

TurboGears — это ещё один веб-фреймворк для разработки веб-приложений, написанный на языке Python. Во время его создания вдохновение черпалось из опыта использования Django и Rails. Эти фреймворки имеют ряд ограничений и недостатков, а TurboGears попытался решить эти проблемы.

Основное отличие этого фреймворка от того же Django — не изобретение велосипеда в виде собственной ORM, а использование в качестве основных компонент стандартных и популярных библиотек, таких как Pylons, SQLAlchemy, Genshi и Repoze.

Среди организаций, которые использовали TurboGears, — Bisque, ShowMeDo и SourceForge.

Ключевые особенности TurboGears:

• поддержка множества баз данных;
• поддержка различных JavaScript-библиотек;
• поддержка множества форматов обмена данными;
• поддержка горизонтального масштабирования данных по примеру шардинга;
• возможность расширения средствами стандартных WSGI-компонент.

Web2Py

Фреймворк Web2py изначально задумывался как учебный инструмент с акцентом на юзабилити и простоте начала использования. Например, в нём отсутствуют файлы конфигурации проекта. Сама же архитектура фреймворка разработана по аналогии с такими решениями, как Ruby on Rails и Django.

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

Кроме того, каждое приложение обеспечено автоматически сгенерированным интерфейсом администрирования по типу Django.

Ключевые особенности Web2py:

• интегрированная веб-среда разработки;
• встроенные компоненты для всех основных функций;
• механизмы аутентификации и контроля доступа по ролям;
• поддержка jQuery для Ajax- и UI-эффектов;
• поддержка интернационализации;
• автоматическое журналирование ошибок вместе с контекстом.

Flask

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

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

Flask лежит в основе таких крупных сервисов? как Reddit, Netflix, Pinterest, Twilio и агрегатора такси Lyft.

Ключевые особенности Flask:

• встроенный сервер разработки и отладчик;
• диспетчеризация запросов в RESTful-стиле;
• встроенная поддержка модульного тестирования;
• использование шаблонизатора Jinja2;
• 100%-ная совместимость с WSGI 1.0;
• множество расширений, предоставляемых сообществом.

Bottle

Bottle — это ещё один простой и лёгкий микрофреймворк. Он распространяется в виде однофайлового модуля, и у него нет никаких зависимостей, кроме стандартной библиотеки Python. Изначально он разрабатывался исключительно для создания веб-интерфейсов API.

Функциональные возможности «из коробки» включают встроенный веб-сервер, шаблонизацию, роутинг запросов, а также собственные инструменты и утилиты. Bottle позволяет создавать простые приложения для личного пользования. А ещё это подходящий пример для изучения фреймворков, а также для быстрого создания прототипов. Например, компания Netflix использовала Bottle для создания своих веб-интерфейсов.

Ключевые особенности Bottle:

• быстрый встроенный шаблонизатор в pythonic-стиле;
• встроенный веб-сервер разработки;
• простой механизм маршрутизации запросов к функциям с поддержкой как статических, так и динамических адресов;
• лёгкий доступ к cookies, загрузке файлов, заголовкам запросов и другим метаданным.

Tornado

Tornado — это расширяемый асинхронный веб-сервер и фреймворк, который решает проблему C10k. То есть при правильной настройке он может работать с 10 000+ одновременных соединений. Это делает его отличным инструментом для создания приложений, требующих суперпроизводительности при работе с операциями ввода/вывода и поддержки огромного количества одновременных соединений.

Изначально фреймворк был создан для использования в проекте FriendFeed, который в 2009 году приобрела компания Facebook, после чего исходные коды Tornado были открыты.

Ключевые особенности Tornado:

• асинхронный режим работы;
• использование веб-сокетов;
• поддержка схем аутентификации и авторизации сторонних производителей.

web.py

Web.py — это минималистский фреймворк, который нацелен на реализацию простых веб-приложений на языке Python. Те разработчики, которые считают, что новые веб-сайты должны создаваться с нуля, будут очарованы этим быстрым и лёгким фреймворком. Web.py обеспечивает простоту и эффективность процесса разработки без использования заготовок архитектуры.

Web.py делает процесс веб-разработки максимально непредвзятым и не встаёт на пути идей разработчиков. Причина упрощения процесса разработки в том, что бывают случаи, когда нет необходимости использовать паттерн проектирования MVC или создавать беспорядок из HTML, CSS, JavaScript и PHP в одном файле.

Ключевые особенности Web.py:

• встроенный веб-сервер разработки;
• встроенный отладчик;
• встроенный шаблонизатор;
• встроенный пакет работы с базами данных;
• пакет работы с формами;
• совместимость с WSGI.

FastAPI

FastAPI — это асинхронный веб-фреймворк, который появился на свет в конце 2018 года. Он предназначен для быстрой разработки API-приложений и основан на использовании стандартной аннотации типов Python.

Слово «fast» в названии указывает не только на быструю разработку приложения, но и на производительность фреймворка. Как утверждает документация, согласно результатам независимых тестов, FastAPI по скорости не уступает приложениям, написанным на NodeJS или Go, а также это один из самых быстрых фреймворков на Python.

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

FastAPI обычно применяется для разработки API, без фронтенда, но при желании его можно дополнить стандартными шаблонами на основе шаблонизатора, например Jinja2, который применяется во Flask.

Ключевые особенности FastAPI:

• очень высокая производительность, наравне с NodeJS и Go;
• встроенная документация на основе Swagger;
• использование веб-сокетов;
• лёгкая интеграция с базами данных;
• основан на стандартах OpenAPI и полностью совместим с ними.

Что же выбрать?

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

Приведённый выше список бесплатных и открытых фреймворков Python актуален на 2022 год, но какой из них лучше подойдёт для вашего следующего проекта — решать вам.

На курсе «Python-разработчик плюс» в Яндекс Практикуме вы изучите основы трёх востребованных на рынке фреймворков — Django, Flask и FastAPI и создадите несколько проектов с их использованием.

Сайт на Django строится из одного или нескольких приложений, которые рекомендуется делать отчуждаемыми и подключаемыми. Это одно из существенных архитектурных отличий фреймворка от некоторых других (например, Ruby on Rails). Один из основных принципов фреймворка — DRY (англ. Don’t repeat yourself)

Веб-фреймворк Django используется в сайтах Instagram, Disqus, Mozilla, The Washington Times, Pinterest, YouTube, Google и др.

Архитектура Django похожа на «Модель-Представление-Контроллер» (MVC). Контроллер классической модели MVC примерно соответствует уровню, который в Django называется Представление (англ. View), а презентационная логика Представления реализуется в Django уровнем Шаблонов (англ. Template). Из-за этого уровневую архитектуру Django часто называют «Модель-Шаблон-Представление» (MTV).

Основные возможности Django

• ORM, API доступа к БД с поддержкой транзакций;
• встроенный интерфейс администратора с уже имеющимися переводами на многие языки;
• диспетчер URL на основе регулярных выражений;
• расширяемая система шаблонов с тегами и наследованием;
• система кэширования;
• интернационализация;
• подключаемая архитектура приложений, которые можно устанавливать на любые Django-сайты;
• generic views — шаблоны функций контроллеров;
• авторизация и аутентификация, подключение внешних модулей аутентификации: LDAP, OpenID и проч.;
• система фильтров (middleware) для построения дополнительных обработчиков запросов, как, например, включенные в дистрибутив фильтры для кэширования, сжатия, нормализации URL и поддержки анонимных сессий;
• библиотека для работы с формами (наследование, построение форм по существующей модели БД);
• встроенная автоматическая документация по тегам шаблонов и моделям данных, доступная через административное приложение.

Django Rest Framework для создания API

Django Rest Framework (DRF) — это библиотека, которая работает со стандартными моделями Django для создания гибкого и мощного API для проекта. Эта статья поможет понять структуру DRF и дать вводные данные для начала его использования

API DRF состоит из трёх слоев:

• Сериализатор преобразует информацию, хранящуюся в базе данных и определенную с помощью моделей Django, в формат, который легко и эффективно передается через API.
• Вид (ViewSet) определяет функции (чтение, создание, обновление, удаление), которые будут доступны через API.
• Маршрутизатор определяет URL-адреса, которые будут предоставлять доступ к каждому виду.

Когда не стоит использовать Django

• Для очень-очень больших приложений, т.к. для некоторого функционала специально подбирается язык и технология, плюс Django по архитектуре ближе к монолиту, чем к микросервисам.
• Если необходимо написать простейшее приложение, в котором не требуется работать с базой данных, выполнять операции с файлами или делать что-либо хоть немного сложное. Для таких ситуаций лучше подойдут микрофреймворки.
• Вы хотите сами написать все с нуля и знаете, что делаете.
• Вы или ваши коллеги совершенно не знакомы с Django/Python и у вас нет времени и ресурсов на наработку необходимых навыков.

Если все вышесказанное – не про ваш проект, то, вполне вероятно, Django вам подойдет.

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

Django и DRF. Полезные ссылки для изучения

• Django 3.2 documentation
• Документация Django 3.1 на русском языке
• Django REST framewor​k documentation
• Документация Django REST framework на русском языке

А вы использовали Django в своих проектах?

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

Главные изменения/нововведения Django 3.2

• автоматическое обнаружение AppConfig упрощает настройку подключаемых приложений;

• кастомизация типа автоматически созданных primary-ключей запускает миграцию в поля первичного ключа BigAutoField по умолчанию;

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

Как скачать?

Воспользоваться командой pip install Django==3.2 в Терминале или посмотреть инструкцию на сайте разработчиков.

Источник: Django

Celery — это распределенная асинхронная очередь задач, выполняющаяся в реальном времени, а также поддерживающая планирование задач. Ознакомиться с теоретическими аспектами можно по ссылке. В данной статье мы рассмотрим периодические задачи. Несмотря на то, что периодические задачи можно создавать через административную страницу в Django admin, мы рассмотрим их создание в коде, а также остановку созданных задач по условию.

Если вы хотите повторить пример из статьи, то у вас уже должен быть настроен Django-проект. Однако если вам нужна помощь по настройке проекта, почитайте эту статью.

В основном Celery в Django-приложениях используется, когда необходимо:

• асинхронно выполнить какую-либо задачу с помощью Celery worker;
• выполнить задачу в определенное время;
• постоянно выполнять задачу через определенный промежуток времени.

Самостоятельно Celery не умеет реализовывать периодические задачи, поэтому существует расширение django-celery-beat, которое выполняет роль планировщика задач для Celery. Как развернуть Сelery в приложении, описано в документации выше.  В качестве посредника сообщений между нашим приложением и Сelery я использую Redis, развернутый в docker-контейнере.

Давайте установим django-celery-beat с помощью pip install django-celery-beat.

После установки необходимо внести django-celery-beat в список установленных приложений в настройках приложения Django.

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

Запустим миграции. И в качестве последней настройки для полноценного использования django-celery-beat добавим в settings приложения: CELERY_BEAT_SCHEDULER='django_celery_beat.schedulers:DatabaseScheduler', тем самым указав Celery использовать новый планировщик задач, только что установленный нами.

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

Динамическое создание периодических задач

Основная мысль, которую я бы хотел донести в статье, заключается в том, что периодические задачи являются обычными моделями, с которыми можно работать через Django ORM. Сейчас покажу на примере:

Допустим, вы создаете сервис, который делает заказы на стороннем сервисе через API. В ответе от этого сервиса вы получаете статус вашего заказа. Если мы получили статус от сервиса, то все отлично, дальше мы выполняем всю необходимую логику с этим заказом. Если же нет (например, пришел ответ '0') — тогда необходимо переотправлять запрос, пока статус не будет получен.

Мы не будем усложнять себе жизнь работой с API каких-либо сервисов. Сымитируем ответ от воображаемого сервиса с помощью custom command, которую самостоятельно напишем.

В папке приложения создадим папку «management», в ней папку «command» и в ней файл с кодом, например, «make_order.py».

И напишем код будущей консольной команды.

Данная команда ожидает 2 аргумента на вызове: первый — это статус, второй — id заказа. Если мы получаем статус '0' от нашего воображаемого сервиса, тогда нам необходимо повторно отправлять запросы на получение статуса. Тут-то нам и пригодятся периодические задачи. В данном примере мы создаем PeriodicTask из Django_celery_beat.models. В качестве аргументов мы передаем ей следующие параметры:

• Имя создаваемой задачи: name='Repeat order .{}'.format(options['order_id']), в дальнейшем с ее помощью мы будем останавливать задачи, если нам это необходимо.
• Задача, которая будет периодически выполняться через определенный промежуток времени. В нашем случае это: task='repeat_order_make'.
• Интервал, через который мы хотим, чтобы задача выполнялась: interval=IntervalSchedule.objects.get(every=10, period='seconds'). IntervalSchedule также является моделью из django_celery_beat.models, поэтому мы можем пользоваться функциональностью, предоставляемой Django ORM
• Аргументы, которые будут передаваться в указанную функцию. В нашем случае задаче 'repeat_order_make' будет передан аргумент args=json.dumps([options['order_id'][0]]), то есть options['order_id'][0].
• И время начала работы периодической задачи: start_time=timezone.now().

Давайте теперь посмотрим на код задачи 'repeat_order_make'. Создадим файл «task.py» в корне нашего приложения (как на скриншоте) и напишем следующий код.

В коде учитывается, что если заказ уже получил статус, то нет необходимости больше выполнять написанную нами периодическую задачу. Для того, чтобы остановить последующее выполнение задачи, мы получаем экземпляр задачи с помощью метода get(), передавая в качестве аргумента имя, которое мы дали во время создания задачи. Затем мы переводим поле enabled в состояние False, что остановит выполнение задачи в дальнейшем, и обязательно сохраняем экземпляр задачи.

Давайте теперь проверим результаты наших трудов. Запустим написанную нами команду с помощью manage.py make_order 0 1. То есть мы делаем заказ №1 и как будто получаем ответ со статусом '0'. Это должно создать новую периодическую задачу. Давайте глянем в celery_beat командой celery -A <имя вашего приложения> beat -l INFO.

И увидим, как началось периодическое выполнение задачи repeat_order_make, которую мы описали выше. А также заглянем в Celery командой celery -A <имя вашего приложения> worker -l INFO (я запускал каждую команду в отдельном окне терминала).

Видно, что Celery получает, и посылаем задачи для исполнения.

Теперь изменим статус нашего заказа, снова запустив команду manage.py make_order, но уже с параметрами «Принят, 1». То есть manage.py make_order Принят 1. После чего можно посмотреть в терминал с celery-beat и увидеть сообщение о том, что было изменено расписание выполнения задач, после чего постоянный вызов repeat_order_make прекратится.

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

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

Для демонстрации работы инструмента, Виоланте разработала специальный сервис. Его можно использовать для отправки репортов об ошибках в репозиториях Tor. Но сам Anon-Ticket не привязан к продуктам Tor Project, а потому может спокойно использоваться и на сторонних проектах.

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

Источник: Блог Tor Project

2:40 URL Shortener — простой сокращатель ссылок.

48:48 ToDo List — приложение для управлением списками дел.

1:34:28 English Dictionary — словарь английских слов со значениями, синонимами и антонимами.

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

Если хотите узнать больше о Django, посмотрите документацию фреймворка. В ней описаны основные возможности с примерами использования на практике.

1. Шпаргалка по основам Python
2. Регулярные выражения в Python
3. Шпаргалка по pandas
4. Шпаргалка по Django
5. Виртуальное окружение Python

Шпаргалка по основам Python

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

Регулярные выражения в Python

Шпаргалка собрала большое количество информации о регулярках, включая:

• специальные символы;
• объекты Match;
• методы модуля re;
• escape-символы;
• Raw String Notation;
• расширения;
• объекты;
• флаги;
• ссылки на документацию: Regular Expression HOWTO и Regular expression operations.

Шпаргалка по pandas

Эта библиотека для анализа данных прекрасно себя зарекомендовала в Data Science. Такая шпаргалка поможет в построении различных диаграмм с использованием pandas:

Шпаргалка по Django

Будет полезна тем, кто желает освоить веб-разработку на Python. Здесь вы найдёте базовую информацию по работе с фреймворком — от его установки и до операций с Git:

Виртуальное окружение Python

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

В этом материале вы узнаете:

• как создать бэкенд с REST API на Django;
• как добавить React в проект Django;
• как соединить бэкенд на Django и фронт на React.

1. Подготовка
2. Создаём проект Django в виртуальном окружении Python
3. Пишем приложение на Django
4. Соединяем Django и React
5. Устанавливаем React и webpack
6. Готовим приложение Django для фронтенда
7. Фронтенд на React
8. Заключение

Подготовка

Вам понадобятся:

• базовое понимание Python и Джанго;
• базовое понимание JavaScript (и спецификации ECMAScript 2015) и React;
• установленный Node.js.

Создаём проект Django в виртуальном окружении Python

Создайте новую папку и перейдите в неё:

mkdir django-react && cd $_

Потом активируйте виртуальное окружение Python:

Примечание все следующие команды нужно выполнять из папки django-react и с активированным виртуальным окружением.

Установите зависимости Джанго и Django REST Framework:

pip install django djangorestframework

После установки создайте новый проект Django:

django-admin startproject django_react

Теперь сделаем API на Django для создания и хранения контактов.

Пишем приложение с бэкендом на Django

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

Для создания нового приложения Django используется команда:

django-admin startapp app_name

где app_name — название приложения.

В нашем случае команда будет выглядеть так:

django-admin startapp leads

Она создаст приложение leads в папке django-react. Теперь структура папок в проекте должна выглядеть так:

Теперь сделаем так, чтобы Django проект использовал новое приложение. Откройте файл django_react/settings.py и добавьте приложение в INSTALLED_APPS:

Создаём модель в базе данных с Джанго

Модель — это объект, представляющий собой данные из таблицы. Почти каждый веб-фреймворк использует модели, и Django — не исключение. Она может иметь одно или больше полей. Каждое поле соответствует полю в таблице.

Мы собираемся хранить контакты, поэтому модель Lead может состоять из этих полей:

• имя;
• email;
• сообщение.

Добавим ещё поле со временем создания модели, потому что по умолчанию Django этого не делает.

Откроем leads/models.py и опишем модель Lead:

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

Создадим миграции командой:

python manage.py makemigrations leads

и применим их к базе данных:

python manage.py migrate

Займёмся тестированием

Вы могли подумать «А как же тестирование?».

Существует масса туториалов по бэкенду на Джанго, начинающихся примерно так:

Не надо так. Нет никакого смысла ни в тестировании стандартной модели Django, ни в тестировании Django ORM. Что точно не нужно тестировать при создании приложения с бэкендом на Django:

• встроенный код Django (модели, представления);
• встроенные функции Python.

Не тестируйте то, что уже протестировано! Так что же тогда тестировать?

Добавили свой метод в модель Django — протестируйте его. Дополнили стандартное представление — протестируйте его. Но как узнать, что именно нужно протестировать?

Узнать это поможет библиотека coverage. Установите её:

pip install coverage

Теперь после каждого добавления или изменения кода запускайте coverage:

coverage run --source='.' manage.py test

и создавайте отчёт:

coverage html

Вы увидите, что именно нужно протестировать. Если предпочитаете увидеть отчёт в командной строке, запустите команду:

coverage report

Сериализаторы Django

Сериализация — это конвертация объекта Python в другой формат. После сериализации можно сохранить объект в файл или послать его через сеть.

Почему сериализация необходима? Модель Джанго — это класс Python. Чтобы превратить её в данные в формате JSON, нужна сериализация.

Сериализаторы работают и в обратном направлении: они конвертируют JSON в объекты. Это позволяет:

• отображать модель Django в браузере с помощью конвертации в JSON;
• делать запросы CRUD (create – read – update – delete) к API в формате JSON.

Суммируя: сериализаторы в Django можно использовать для совершения операций с моделями Django через API.

Создайте новый файл leads/serializers.py. Сериализатор LeadSerializer содержит нашу модель и поля:

Созданный дочерний класс от класса serializers.ModelSerializer. ModelSerializer в Django похож на ModelForm. Он подходит, когда нужно, чтобы сериализатор соответствовал модели.

Создаём представления

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

Контроллеры содержат логику обработки запросов и возвращения ответов. В традиционной архитектуре MVC есть модель (Model), представление (View) и контроллер (Controller). Примеры MVC фреймворков: Rails (Ruby), Phoenix (Elixir), Laravel (PHP).

Django — это фреймворк MVT. MVT — это модель, представление и шаблон (Template). В Django есть много типов представлений: функции-представления, представления, основанные на классах, и обобщённые представления.

Используйте функции-представления только если изменение обобщенных представлений займет больше, чем написание представления заново.

Мы будем использовать обобщённые представления. Наше простое приложение будет:

• возвращать выборку моделей;
• создавать новые объекты в базе данных.

С помощью документации можно узнать, что есть представление для возвращения выборки и создания моделей: ListCreateAPIView. Это представление содержит queryset и serializer_class.

queryset — это выборка данных, которую приложение будет возвращать. В нашем случае — все модели Lead. serializer_class — класс сериализатора для модели.

Добавьте в файл django_react/views.py следующий код:

С помощью трёх строк кода мы создали представление для обработки GET и POST запросов.

Чего ещё не хватает? Маршрутизации URL. Другими словами, нам нужно соединить URL и представления.

Настраиваем маршрутизацию url

Нам нужно сделать так, чтобы GET и POST запросы к api/lead/ обрабатывались представлением LeadListCreate, которое будет возвращать и создавать модели.

Чтобы настроить маршрутизацию URL, отредактируйте файл django_react/urls.py, добавив туда url приложения:

Так мы указываем в бэкенде на Django, что нужно использовать url, которые есть в приложения leads.

Теперь создайте файл leads/urls.py. В нём мы соединим представление LeadListCreate и url api/lead/:

И наконец, включим rest_framework в INSTALLED_APPS. Откройте django_react/settings.py и добавьте приложение в INSTALLED_APPS:

Запустим сервер Django:

python manage.py runserver

Перейдите по url http://127.0.0.1:8000/api/lead/ и вы увидите API:

Примечание в продакшене лучше отключить возможность просмотра API. Это можно сделать в конфигурации:

Соединяем Django и React

У многих разработчиков возникают вопросы по поводу того, как правильно соединить Django и React.

Должен ли роутер React взять на себя маршрутизацию? Нужно ли монтировать компоненты React в каждом шаблоне Django?

Ответ зависит от случая.

Есть следующие способы создания проекта на Django и React (они похожи почти для любого веб-фреймворка):

1. React в собственном приложении Django для фронтенда. Загружаем один HTML шаблон и даём React управление фронтендом (сложность: средняя).
2. Django REST как отдельное API + React как отдельное SPA (сложность: высокая, нужна будет авторизация по JWT).
3. Смешанный вариант: мини-приложения React в шаблонах Django (сложность: просто, но сложно будет поддерживать).

Если вы только начали работать с Django REST и React, избегайте варианта 2. Вместо этого выберите 1 (React в собственном приложении Django для фронтенда), если:

• вы создаёте приложение, похожее на веб-сайт;
• в интерфейсе будет много пользовательских действий, используется AJAX;
• вас устраивает авторизация, основанная на сессиях;
• вас не очень волнуют вопросы SEO;
• вас устраивает роутер React.

Если будете держать React близко к Django, то будет проще с авторизацией. Можно будет использовать встроенную систему авторизации Django для регистрации и входа пользователей. Используйте старую добрую авторизацию с помощью сессий и не беспокойтесь о токенах и JWT.

Выберите вариант 3 (смешанный вариант: мини-приложения React в шаблонах Django), если:

• на сайте не нужно использовать много JavaScript;
• вам важно SEO и вы не можете использовать Node.js для рендеринга серверной части.

В данной статье мы будем использовать вариант 1.

Устанавливаем React и webpack

Создадим новое приложение Django для фронтенда:

django-admin startapp frontend

Вы увидите новую папку с названием frontend в вашей структуре папок:

Подготовим папки для хранения компонентов React:

mkdir -p ./frontend/src/components

И статики:

mkdir -p ./frontend/{static,templates}/frontend

Дальше установим React, webpack и babel. Перейдите в папку frontend и создайте окружение:

cd ./frontend && npm init -y

Установите webpack и webpack CLI:

npm i webpack webpack-cli --save-dev

Откройте package.json и запишите 2 скрипта для продакшна и для разработки:

Сохраните и закройте файл.

Установим babel, чтобы код был совместим со старыми браузерами, которые не поддерживают последние стандарты JavaScript:

npm i @babel/core babel-loader @babel/preset-env @babel/preset-react --save-dev

Установим React:

npm i react react-dom --save-dev

Настроим Babel (по-прежнему находясь в папке frontend):

Создадим файл webpack.config.js для настройки загрузчика babel:

Готовим приложение Django для фронтенда

Создадим представление в ./frontend/views.py:

Создадим шаблон в ./frontend/templates/frontend/index.html:

В шаблоне вызывается ./frontend/main.js — файл, который будет генерировать webpack, содержащий весь код на React.

Настроим маршрутизатор Django: включим туда url приложения frontend. Отредактируем файл ./project/urls.py:

Создадим файл ./frontend/urls.py:

Включим приложение фронтенда в список используемых приложений в файле ./project/settings.py:

Зайдя на http://127.0.0.1:8000/, вы увидите пока что просто пустую страницу (для этого сервер Django должен продолжать работать).

Фронтенд на React

После бэкенда, написанного на Джанго, сделаем простой компонент React, который будет отображать наши данные. Если ваша база данных пуста, то самое время наполнить приложение какими-нибудь данными.

Запустите сервер Django и перейдите на http://127.0.0.1:8000/api/lead/ чтобы добавить контакты.

Создадим файл ./frontend/src/components/App.js. В нём будет компонент React, запрашивающий и отображающий данные.

Примечание можно написать тот же компонент в виде функции с хуком useEffect.

Сохраните и закройте файл. Теперь создайте точку входа для webpack — файл ./frontend/src/index.js и импортируйте компонент:

import App from "./components/App";

Теперь можно протестировать результат. Запустите webpack:

npm run dev

Запустите сервер Django:

python manage.py runserver

Перейдите на http://127.0.0.1:8000/. Если вы видите сообщение «Что-то пошло не так», то убедитесь, что применили миграции и заполнили базу данных. Вы должны увидеть данные, отображенные компонентом React.

Выглядит просто. И работает!

Заключение

В этом материале мы сделали простой проект на Django REST API и React. Мы научились:

• создавать простое REST API на Django;
• добавлять React в проект Django;
• соединять Django REST API и React.

Если этот проект показался сложным, попробуйте другой туториал. В нём мы показали, как создать первое веб-приложение на Django.

Flask или Django?

В большинстве случаев — Django.

Но, если у вас маленькое приложение или скрипт, и вы просто хотите добавить HTTP API, то, конечно же, используйте Flask.
Но в других случаях, с усложнением ваших приложений, вам нужно будет внедрять всё больше и больше функциональности, вы будете использовать всё больше и больше библиотек, и с Flask’ом вы просто запутаетесь. Поэтому для больших проектов используйте Django.

Нужно ли разбивать свой код на отдельные приложения?

Скорее нет.

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

Стоит использовать DTL (Django’s default template language) или что-нибудь другое?

Используйте DTL.

По умолчанию он уже есть в пакете Django, и в принципе может выполнять всё, что вам нужно.

DTL не делает то, что мне нужно, могу я использовать Jinja2?

Всё равно используйте DTL.

Наиболее частая претензия: “DTL недостаточно гибкий”. Но нужно учитывать, что есть определённые алгоритмы, реализовать которые на шаблонном языке невозможно.

Запомните, все “мозги” вы содержите во Views, а шаблоны выступают в роли визуализаторов.

Что использовать для запуска Django — uWSGI или Gunicorn?

Однозначно Gunicorn.

Gunicorn — автономный WSGI HTTP сервер, довольно неплохой, развёртывание происходит быстро и просто.

uWSGI предоставляет полный стек для построения хостинг-сервисов, если это то, что вам нужно — используйте его.

Где мне стоит разворачивать своё приложение?

В качестве примера посмотрите, как написать Telegram-бот на Python и задеплоить его на Heroku.

Если вам нужно больше управляемости или вы привязаны к AWS, то используйте AWS Elastic Beanstalk.

Вы, конечно, можете взять простенькую VM, установить туда nginx и настроить всё сами. Но зачем, если для этого уже существуют готовые решения?

Создать свою собственную платформу то же самое, что написать новую ОС. Зачем возиться?

Что использовать для обслуживания статических файлов?

Whitenoise.

Amazon S3, Nginx, Apache — все они хороши, но Whitenoise относительно маленькая библиотека, которая помогает обслуживать статические файлы без использования сторонних сервисов.

Я пытаюсь заставить панель администратора сделать …

Может быть, не надо? Панель администратора Django — хорошая штука, но ссылаясь на официальную документацию:

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

Если вы до сих пор ломаете голову, как подстроить администратора под себя, — перестаньте. Пойдите и попробуйте сделать что-нибудь с generic views.

Какую базу данных использовать?

PostgreSQL.

Она просто работает.

Стоит ли разделять файл конфигурации между разработкой и продакшном?

Нет, не стоит.

Twelve-Factor App охватывает ряд причин, по которым файлы конфигурации в приложении для каждой среды могут быть проблематичными, и почему вместо этого стоит использовать переменные окружения. django12factor и другие приложения помогут вам получить конфигурацию из окружения.

Стоит ли использовать кастомную модель пользователя?

Из официальной документации:

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

Если вы находитесь посреди процесса разработки, всё немного сложнее…

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

Дыра в Sentry

Даниэль обнаружил проблему во время сканирования IP-адресов, принадлежащих социальной сети. На одном из них находился сервис Sentry с именем хоста sentryagreements.thefacebook.com. При рассмотрении приложения специалист заметил трассировку стека, появляющуюся по неожиданной причине, и проблемы с функцией сброса пользовательского пароля. По его словам, режим отладки Django не был отключен, поэтому трассировка раскрыла все окружение программы:

Покопавшись в списке вызванных методов, специалист SCRT обнаружил среди ключей среды SESSION_SERIALIZER, который относился к методу django.contrib.sessions.serializers.PickleSerializer. Даниэль уточнил, что с помощью подделки сессии, содержащей произвольный контент бинарного протокола Pickle для сериализации объектов в Python, в системе можно запустить любой код. Для доступа к сессии ему был необходим секретный ключ Django, который оказался в списке настроек Sentry в незашифрованном виде под названием system.secret-key:

Эксплуатация уязвимости

Исследователь написал proof-of-concept-скрипт, который менял существующее содержимое cookie-файлов sentrysid на произвольный объект и заставлял страницу загружаться на 30 секунд дольше:

После чего он отправил Facebook информацию об уязвимости и получил 5000 $ в рамках программы Bug Bounty. Специалисты компании устранили брешь через 10 дней после получения уведомления.

Программа поиска проблем с безопасностью в Facebook занимает 3 место среди самых высокооплачиваемых инициатив Bug Bounty. Минимальная выплата составляет 500 $, а потолка у вознаграждений нет.

Отладка Python-кода с помощью print

Как уже говорилось ранее, кто-то используют print() для отображения информации, которая помогает понять, что происходит в коде. Кто-то использует логи для тех же целей, но давайте не путать использование логов на продакшене и случаи, когда их используют во время поиска багов в коде и после удаляют.

Но самая большая проблема в использовании print() – это необходимость вносить изменения в код и перезапускать приложение, чтобы увидеть изменения. Давайте разберёмся, почему отладчики эффективнее.

Команды Python-отладчика

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

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

Python есть встроенный отладчик под названием pdb. Это простая консольная утилита, которая обладает основной функциональностью для отладки кода. Но если вы ищете что-то более продвинутое, то стоит обратить внимание на ipdb – отладчик с функциональностью из IPython.

Проще всего вызвать отладчик pdb из кода, где вы работаете:

Как только интерпретатор доберётся до этой строчки, запустится отладчик и в консоли будут доступны новые команды.

list()

Эта команда покажет часть кода, на выполнении которой сейчас находится интерпретатор. Можно передать два аргумента first и last для просмотра определённого участка кода. Если указать только first, то будет выведен код вокруг искомой строки.

up(p) и down(d)

Эти команды используются для передвижения по стеку вызовов. С их помощью можно отследить, откуда была вызвана текущая функция.

step() и next()

Другая пара не менее важных команд. С их помощью можно выполнять код построчно. Единственное различие между ними в том, что next() перейдёт к следующей строке вне зависимости от вызываемых функций, а step() перейдёт в вызванную функцию, если это возможно.

break()

Эта команда позволяет создавать брейкпоинты без внесений изменений в код. Ниже разберём этот этап более детально.

Краткий список команд отладчика pdb:

• args() — выводит аргументы функции;
• continue() или (cont) — продолжит выполнение до первого брейкпоинта или до завершения программы;
• help() — выводит список доступных команд или подсказки по определённой команде;
• jump() — перепрыгивает к выполнению указанной строчки кода;
• list() — выводит исходный код программы вокруг выбранной строки;
• expression() — выводит значение выражения;
• pp — выводит значение в «красивом» виде;
• quit или exit() — отменяет выполнение программы;
• return() — завершает выполнение текущей функции.

Продолжаем изучать Python-отладчик

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

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

Давайте разберём на примере. Есть простое приложение, которое отслеживает рабочее время. Для её работы используется библиотека requests, отвечающая за выполнение HTTP-запросов. Попробуем прервать выполнение во время запроса. Как это сделать? Запустим приложение через отладчик и установим брейкпоинт внутри библиотеки requests.

Как можно заметить, не нужно указывать полный путь до библиотеки. Можно указать относительную ссылку от sys.path. Таким же образом можно отлаживать и ваше приложение.

Теперь куда проще отлаживать код. Не надо вносить изменения в приложение или во внешние библиотеки.

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

В данном примере прерывание произойдёт только в случае, если json будет иметь в себе ключ time_entry.

Отладка кода Django

Если вы используете Django, то скорее всего знаете, что, если в настройках значение параметра DEBUG установлено как True, то для каждого исключения будет выводиться отдельная страница с указанием типа исключения, стек вызовов, локальные переменные и т.д.

Если вы хотите прокачать отладчик, то установите django-extensions и используйте команду runserver_plus для запуска сервера. Также можно указать пароль для доступа к отладке следующей командой:

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

Если вы используете django-extensions, то получите страницу со всеми вызовами, кодом и окном отладчика.

Процесс отладки осуществляется с помощью WSGI библиотеки Werkzeug.

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