Собрали в одном месте самые важные ссылкии сделали Тренажер IT-инцидентов для DevOps/SRE
Современный диабетик использует сразу несколько устройств и сервисов. Сенсор непрерывного мониторинга глюкозы, приложение производителя, иногда инсулиновую помпу, иногда обычные шприц-ручки. Каждый производитель строит собственную экосистему, и объединять их между собой никто не собирается.Мне хотелось получить единую систему, которая автоматически собирает показатели сахара, хранит историю и предоставляет данные уже моему приложению.
TL;DR: я сделал sqlalchemy-query-manager — небольшой слой поверх SQLAlchemy для типовых backend-запросов. Он не заменяет SQLAlchemy, а добавляет более компактную запись для частых операций: фильтры в стиле number__gte=100, условия через Q, фильтрацию по связанным моделям, eager loading, CRUD helpers, агрегаты и просмотр итогового SQL. Идея в том, чтобы оставить SQLAlchemy в основе, но убрать повторяющийся код там, где запросы становятся слишком большими.
Согласие на обработку персональных данных в Django-проекте часто начинается с одного BooleanField. Но затем оказывается, что недостаточно помнить только факт нажатия на чекбокс: пользователь мог видеть другую редакцию документа, отозвать согласие, выбрать лишь часть категорий файлов cookie, а администратору может понадобиться журнал действий и выгрузка в CSV. Я сделал для этого два полностью независимых Django-пакета с открытым исходным кодом:
Раньше я уже писал о своих идеях (1 и 2) о том, как сделать django асинхронным. Они основывались, вслед за sqlalchemy, на использовании гринлетов. Несмотря на то, что proof-of-concept был успешно получен, а трудностей - встречено меньше, чем ожидалось, я всё-таки отказался от этого подхода: во-первых, он уже применяется в sqlalchemy. Во-вторых, это ведёт к усложнению, и растёт так называемая test matrix - потому что поддерживается как синхронный случай, так и асинхронный. А simple, как мы знаем, is better than complex.
Когда Docker-образ backend-приложения начинает весить 1,5 GB, это уже хороший повод хотя бы посмотреть, что вообще лежит внутри. Пока все работает, мало кто задумывается, сколько мусора, dev-зависимостей и ненужных файлов уезжает в production вместе с приложением. Но на самом деле от «лишнего веса» нужно избавляться, потому что каждый лишний мегабайт — это более долгие сборки и дополнительные сложности.
Это третья часть мини-серии о Django-миграциях. В первой части мы готовились к миграциям и разбирались с конфликтами, во второй чинили типичные подводные камни. Если их не читали, то рекомендую начать именно с них, а затем вернуться сюда.В этом же материале поговорим о самом интересном: что происходит, когда python manage.py migrate запускается в 17:30 в пятницу на проде, под 3k RPS и таблицей в 200 миллионов строк. Расскажу какие блокировки в PostgreSQL берёт каждая операция Django, что внутри atomic = False, как пишется правильный паттерн expand-migrate-contract, зачемнужны AddIndexConcurrently, AddConstraintNotValid, SeparateDatabaseAndState и как обновлять данные на больших таблицах.
Здесь мы рассматриваем фабрики в тестировании. На очень элементарных примерах, с использованием языка python и инструментов Django, pytest, factory_boy.
Сегодня я расскажу, как мы сделали самый быстрый и самый семантически корректный фреймворк для создания апишек на Джанго. Поговорим про конкурентов, покажу очень крутые интеграции, поделюсь своей философией и правилами, которые использовались для создания фреймоврка, ну накину на вентилятор для интереса.
Если вы разработчик и выбрали для своего проекта Django Framework, но не делали большие миграции на своем проекте, эти советы вам точно пригодятся.
Django ORM прячет SQL за красивым Python-интерфейсом. Пишешь User.objects.filter(active=True).order_by('name')[:10] — получаешь список пользователей. Круто. Но когда запросы тормозят или N+1 пожирает базу, приходится понимать, что вообще происходит.Разберём внутренности QuerySet: почему он ленивый, как работает chaining, когда запрос реально выполняется, и чем select_related отличается от prefetch_related на уровне SQL.
Как только ты начинаешь углубляться в изучение баз данных, так сразу на горизонте возникают такие понятия как подзапросы, CTE, представления и временные таблицы. По опыту работы в университете заметил, что с этими темами у людей часто возникают проблемы и недопонимания. В частности больше всего путаницы вносит именно CTE.
Сегодня поговорим о том, как включать и выключать функциональность в Django, не разворачивая каждый раз новый деплой. В больших проектах эту задачу решают через feature flags, такие условные флажки , которые позволяют запускать скрытые возможности лишь для части пользователей или откатывать фичи, не выкатывая заново весь код. Если вы хотите поэтапно раскатать новую функцию, сделать A/B тест или просто спрятать недоделанный модуль за переключателем, вам сюда.
Вторая часть из серии статей «Сервисы — место, где живет бизнес логика». Если Вы еще не знакомы с первой частью, то рекомендую начать с нее, чтобы у вас сложилась общая картина. Сегодня мы постараемся ответить на все оставшиеся вопросы: познакомимся с прекрасной, легковесной DI-библиотекой, научимся «инжектить» в Django, посмотрим на несколько дашбордов в Кибане и поговорим про доменные модели.
Есть числа, которые полезно знать программистам на Python. Насколько быстро добавляется элемент в список? Как насчет открытия файла? Это занимает меньше миллисекунды? Если ваш алгоритм зависит от производительности, какую структуру данных вы должны использовать? Сколько памяти занимает число с плавающей запятой, один символ или пустая строка? Насколько быстр FastAPI по сравнению с Django?
Я работаю в компании и, так сложилось, что нас имеет мы имеем DRF монолит на писят два миллиона строк кода. И вот однажды, чью-то светлую голову посетила мысль — «а давайте писать код одинаково». Идея прозвучала чертвоски просто и соблазнительно. С этого момента мы завели себе ишака по имени «Django Service Layer», и все дружно начали на него наваливать
В свежем релизе фреймворк усиливает совместимость между СУБД, упрощает работу с email, улучшает ORM, добавляет удобства в шаблонах и снижает риск «выгорания» первичных ключей.
Фреймворк наконец получил встроенный API для очередей задач — но без воркеров, так что чудес пока ждать рано.
Классический сценарий: есть база данных и приложение на бэкенде. Для подключения достаточно знать адрес, порт, имя пользователя, пароль — и прямой доступ перед вами. Но что делать, если необходимо подключить no-code базу данных, которой можно управлять только через REST API?
Сделал поиск по личному архиву фотографий с применением трех нейросетей, векторного расширения к PostgreSQL и Django
Большинство наших «проектов мечты» умирают не потому, что идея плохая, а потому что мы останавливаемся на уровне «ну вот, фронт есть, бэк вроде тоже, как-нибудь допилю оплаты и выложу». Не допиливаем. Если у вас в голове крутится мысль «я бы запустил свою фичу, если бы была готовая дорожка к деньгам» — это она.