DEV Community: Гимаев Наиль

2. Celery

Гимаев Наиль — Fri, 08 Aug 2025 07:19:29 +0000

Используйте transaction.on_commit

В одном из файлов встречается использование sleep.

@celery.task(name="users.rebuild_tags")
def rebuild_tags(student_id: str | int) -> None:
    # preventing race condition when task looks for user which isn't saved into db yet
    time.sleep(1)  # ❌
    user = apps.get_model("users.User").objects.get(pk=student_id)

    generate_tags(user)

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

Причина появления sleep указана в комментарии. Как же так получается, что student_id уже есть, а пользователя связанного с этим id в БД ещё нет? Всё дело в транзакциях. Пока транзакция не завершится, созданные ею изменения не видны.

Рассмотрим следующий пример

class UserView(APIView):
  def post(request):
    user = create_user(request)
    rebuild_tags.delay(student_id=user.id)  # ❌
    long_time_db_operation()
    return Response({"id": user.id}, status=201)

По умолчанию в django все http-запросы заворачиваются в транзакции. Это значит, что созданный пользователь виден только в представлении (view), которое его создала. Код за пределами представления не видит этого пользователя, пока не завершится транзакция. Для простоты, будем считать, что транзакция завершается, когда выполниться return.
Задача rebuild_tags ставится в очередь раньше, чем будет выполнен return, а значит возможна ситуация, когда задача выполнится раньше завершения транзакции. sleep должен был решить эту проблему, но представим себе, что long_time_db_operation может иметь переменную длительность в зависимости от загруженности базы данных, тогда в некоторых случаях длительность может быть больше одной секунды и тогда sleep не поможет.

Есть надёжный вариант

class UserView(APIView):
  def post(request):
    user = create_user(request)
    task = rebuild_tags.s(student_id=user.id).delay
    transaction.on_commit(task)  # ✅
    long_time_db_operation()
    return Response({"id": user.id}, status=201)

transaction.on_commit - принимает на вход функцию, которую нужно выполнить после завершения транзакции, поэтому у .delay нет скобок
Параметры задачи переезжают в метод .s, это позволяет задаче запуститься с нужными параметрами.
Таким образом, не важно сколько времени занимает транзакция, фоновая задача будет запущена, только после успешного завершения транзакции.

Offtop. С точки зрения TDD вариант со sleep правильный, т.к. TDD требует писать минимальный код, который будет проходить тесты. Но если написать тест, который проверяет, что задача не ставится в очередь при падении транзакции, то тогда без on_commit не обойтись.

Используйте именованные аргументы

Ещё посмотреть на события celery во flower, то информация о задаче может выглядеть rebuild_tags args=(1) kwargs={}. Когда параметров много, это могло выглядеть так args=(10, 1000, true, 1, 100). Неизвестно что означают эти числа. Когда перед глазами сотни событий celery, это не очень хорошо. Исправить это очень легко, достаточно добавить *, перед аргументами задачи. В нашем примере это будет так:

@celery.task(name="users.rebuild_tags")
def rebuild_tags(*, student_id: str | int) -> None:  # ✅
  ...

Во flower это будет отображаться так rebuild_tags args=() kwargs={"student_id": 1} - так намного понятней.

Рассмотрим ещё один пример. Пусть в celery beat добавлена задача, которая должна отправить письма тем пользователям у которых сейчас 8 утра по их местному времени.

@celery.task(name="Рассылка")
def send_mails() -> None:  # ❌
  users = find_users(8) # Найти пользователей, у сейчас которых подходящее локальное время
  # Странная, но необходимая проверка, которая мешает тестированию
  if now().minute = 0: 
    ...

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

@celery.task(name="Рассылка")
def send_mails(*, hour: int = 8, minute: int = 0) -> None:  # ✅
  users = find_users(hour) # Найти пользователей, у сейчас которых подходящее локальное время
  if now().minute = minute: # Странная проверка, которая мешает тестированию
    ...

Теперь, можно задавать именованные аргументы через админку celery beat в блоке Arguments конкретной задачи в формате json: {"hour":17, "minute":47}. Так можно тестировать задачу в любое время.

1. Тесты

Гимаев Наиль — Fri, 08 Aug 2025 07:19:16 +0000

Быстрая обратная связь от тестов

Начнём с Makefile.
Часть касающаяся тестов выглядит так

manage = poetry run python src/manage.py
SIMULTANEOUS_TEST_JOBS=4

test:
    cd src && poetry run pytest -n ${SIMULTANEOUS_TEST_JOBS} -m 'not single_thread'

make test - Запустит все тесты в 4 потока.
Тут не ошибок, но этот код можно улучшить.
Во-первых, сделаем SIMULTANEOUS_TEST_JOBS=auto - это позволит ускорится тестам на компьютерах с большим числом процессоров, при этом однопроцессорные машины не будут захлёбываться от четырёх параллельных процессов.
Во-вторых, стоит добавить ключ --ff. Если тесты падают, то следующий прогон начнётся с упавших тестов. Не придётся ждать, чтобы понять исправились они или нет.
В третьих, стоит добавить библиотеку pytest-testmon, с ней окончательный вариант будет выглядеть так:

manage = poetry run python src/manage.py
SIMULTANEOUS_TEST_JOBS=auto

test:
    cd src && poetry run pytest -n ${SIMULTANEOUS_TEST_JOBS} -m 'not single_thread' --ff --testmon

testmon:
    cd src && poetry run pytest -n ${SIMULTANEOUS_TEST_JOBS} --ff --testmon -x -l

testmon собирает в БД связи между кодом и тестами, которые его покрывают, в локальную БД. Не забудьте добавить БД в .gitignore.
Если запустить команду pytest --testmon, то будут запущены только те тесты, которые относятся к изменившемуся коду. Это быстрее, чем запускать весь код. И надёжнее чем запускать единственный тест, который, как вам кажется, относится к вносимым вами изменениям.
Нужно учитывать одну особенность testmon, если задан ключ -m, то выполняются тесты подходящие под условие ключа, а не тесты текущих изменений. Именно поэтому в Makefile теперь 2 команды.
make test - нужно запускать перед началом работы, чтобы наполнить БД testmon связями. И после окончания работы, чтобы проверить, что все тесты отрабатывают.
make testmon - можно запускать после каждого изменения кода. Это можно делать часто, так как запускаться будет, только малая часть тестов.
Ключ -x, нужен чтобы не ждать окончания тестов, если найдена проблема
Ключ -l, нужен чтобы в консоли отображались значения переменных, что упрощает исправление ошибки без отладчика.

Не держите фикстуры в файле тестов

В одном файле расположена фикстура paid_order и тест test_break_if_current_user_could_not_be_captured, который её использует.
Взглянем на тест поближе

def test_break_if_current_user_could_not_be_captured(mocker, refund):  # ❌
    mocker.patch("apps.orders.services.order_refunder.get_current_user", return_value=None)

    with pytest.raises(AttributeError):
        refund(paid_order, paid_order.price)

Тест проверяет, что код падает с ошибкой, если пользователь которому нужно сделать возврат равен None.
Действительно, если добавить фикстуру paid_order в аргументы теста, то произойдёт ошибка. Только это будет другая ошибка. Откуда же взялся AttributeError? Он возникает здесь: paid_order.price - это попытка обратиться к полю price функции (а не фикстуры) paid_order. До вызова refund дело даже не доходит, а значит тест не проверяет то, что должен был. А всё потому, что IDE видит эту функцию и не подсвечивает проблему.
Чтобы такого не происходило, нужно держать все фикстуры в файле conftest.py рядом с файлом теста. Так как фикстуры не импортируются, то они не видны IDE, пока не будут переданы в тест.

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

Держите фикстуры ближе к тестам

Хотя django создаёт для каждого приложения свой файл test.py, но лучше делать отдельную папку с тестами, так как желательно, чтобы на рабочие сервера попадали только необходимые файлы, а файлы тестов и документации к таким не относятся.
Допустим у вас все тесты лежат в одной папке tests, в ней лежат папки для приложений django, а уже в них папки с тестами разбитыми по функциональности. В каждой из папок могут находится файлы conftest.py.
Когда pytest ищет фикстуру, сначала она ищет фикстуру в том же классе, где находится тест, если класс есть, потом в том же файле, потом в conftest.py в той же папке, потом conftest.py родительских папок до корня тестов.
Где расположить фикстуру user, которая нужна во всех тестах? Можно сделать вывод, что если писать на уровне приложений или уровне функциональности, то нарушается принцип DRY, и лучше расположить фикстуру в корень тестов. В реальности, общая для всех тестов фикстура, начинает со временем приносить проблемы, так как её будет очень сложно менять. Другими словами, корень тестов хорошее место только для фикстур, которые не меняются, вроде подключения к БД.

Мой алгоритм поиска места для фикстуры.

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

Не пользуйтесь одноимённым наследованием фикстур

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

Наследованием фикстур будем называть фикстуру, которая на отдаёт на выходе ту же фикстуру, которую получает на вход. Одноимённое наследование, это когда фикстура на вход получает фикстуру с таким же именем. Такое часто можно встретить в статьях по pytest.
Вот так выглядит пример на django:

@pytest.fixture
def user():
  return User.objects.create(is_staff=True)

class TestLastLogin:
  @pytest.fixture
  def user(self, user):  # ❌
    user.last_login = datetime.now()
    user.save()
    return user

Можно было бы назвать дочернюю фикстуру по другому, это упростило бы чтение кода, но само по себе наследование фикстур опасно, так как приводит к сайд эффектам

@pytest.fixture
def user():
  return User.objects.create(is_staff=True)

class TestLastLogin:
  @pytest.fixture
  def user_no_staff(self, user):
    user.is_staff = False
    user.save()
    return user

  def test(self, user, user_no_staff):
    user.refresh_from_db()

    assert user.is_staff  # ❌

Этот тест упадёт, т.к. фикстура user_no_staff повлияла на фикстуру user, и это поломало тест.

Можно воспользоваться трюком

@pytest.fixture
def user():
  return User.objects.create(is_staff=True)

class TestLastLogin:
  @pytest.fixture
  def user_no_staff(self, user):
    user_no_staff = User.objects.get(user.id)
    user_no_staff.id = None
    user_no_staff.is_staff = False
    user.save()
    return user

  def test(self, user, user_no_staff):
    user.refresh_from_db()

    assert user.is_staff  # ✅

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

@pytest.fixture
def user():
  return User.objects.create(is_staff=True)

class TestLastLogin:
  @pytest.fixture
  def user_no_staff(self, user):
    return User.objects.create(is_staff=False)

  def test(self, user, user_no_staff):
    user.refresh_from_db()

    assert user.is_staff  # ✅
    assert not user_no_staff.is_staff  # ✅

0. Вводная

Гимаев Наиль — Thu, 07 Aug 2025 15:27:57 +0000

В начале своей карьеры я ориентировался на проект education-backend, как на образец best practis. Проект коммерческий, т.е. приносит автору деньги. Фёдор Борщёв, автор проекта, часто выступает с докладами о том как правильно делать проекты на django. Так что код достаточно качественный.

Мне захотелось понять, насколько я стал опытнее и провёл ревью проекта. Чем дальше я анализирую код, тем больше вижу ошибок, которые могли бы не возникнуть, если бы соблюдались некоторые правила.
В общем, я решил записать для себя и для коллег правила, соблюдение которых позволит совершать меньше подобных ошибок.
Заметки будут пополняться и корректироваться по мере обнаружения новых интересных моментов.

Прим.: Все фрагменты с правильными решениям написаны прямо в редакторе dev.to, по памяти, поэтому их работоспособность не гарантируется

DRF: SerializerMethodField vs DataSerializerField

Гимаев Наиль — Tue, 04 Feb 2025 14:21:26 +0000

Оставлю это здесь, как черновик.
drf-spectacular плохо дружит с SerializerMethodField. Поэтому я написал свой класс поля.

from typing import Type, cast, TypeVar
from uuid import uuid4

from rest_framework.fields import Field
from rest_framework.serializers import ListSerializer, Serializer

SerializerType = TypeVar("SerializerType", bound=Serializer)

class DataSerializerField(Field):
    """A serializer for calculated data"""

    def __new__(cls, serializer: Type['SerializerType'], *args, method_name=None, **kwargs) -> 'SerializerType':
        class GetAttributeMixin(Field if TYPE_CHECKING else object):
            def get_attribute(self, instance):
                if self.source_attrs:
                    value = super().get_attribute(instance)
                else:
                    default_method_name = f'get_{self.field_name}_data'
                    attr_name = method_name or default_method_name
                    method = getattr(self.parent, attr_name, None)
                    if not method:
                        raise AttributeError(f'Method {attr_name} not found in class {type(self.parent).__name__}')
                    value = method(instance)
                return value

        class_name = f'{serializer.__name__.replace("Serializer", "")}DataSerializer'
        list_serializer_class = type('DataListSerializer', (GetAttributeMixin, ListSerializer), {})
        parent_meta_class = getattr(serializer, 'Meta', object)
        ref_name = f'{class_name}_{uuid4().hex}'
        meta_class = type(
            'Meta',
            (parent_meta_class,),
            {'list_serializer_class': list_serializer_class, 'ref_name': ref_name},
        )
        data_serializer_class = type(class_name, (GetAttributeMixin, serializer), {'Meta': meta_class})
        kwargs.setdefault('source', '*')
        kwargs['read_only'] = True
        kwargs['required'] = False
        return data_serializer_class(**kwargs)

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

class ParentSerializer(Serializer):
  serializer_field_object = DataSerializerField(ChildSerializer)
  serializer_field_list = DataSerializerField(ChildSerializer, many=True)

  def get_serializer_field_object_data(parent_obj) -> ChildObject:
    return ChildObject()

  def get_serializer_field_list_data(parent_obj) -> list[ChildObject]:
    return [ChildObject(), ChildObject()]

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

Этот же код с SerializerMethodField выглядел бы так

class ParentSerializer(Serializer):
  serializer_field_object = SerializerMethodField()
  serializer_field_list = SerializerMethodField()

  def get_serializer_field_object(parent_obj) -> ChildSerializer:
    return ChildSerializer(ChildObject()).data

  def get_serializer_field_list(parent_obj) -> list[ChildSerializer]:
    return ChildSerializer([ChildObject(), ChildObject()]).data

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

Мои отношения с клавиатурой и типографикой

Гимаев Наиль — Sat, 14 Dec 2024 07:48:01 +0000

Данный пост родился после прочтения комментариев к другому посту: https://t.me/t0digital/1001

Начну с маленькой новости.
В стандартной раскладке есть символ ₽ — Right Alt + 8

Я всю жизнь пользуюсь виндой, слепой печатью не владею. В основном работаю аккордами, в IDE — это Ctrl + Пробел. В текстовых редакторах — это стрелки в сочетании с клавишами Ctrl и Shift в разных комбинациях.

Не могу работать на коротких клавиатурах. Даже если клавиатура длинная, но на ней сдвинута хотя бы одна одна клавиша, то работать не могу. Я использую все 100% клавиш. Даже Scroll Lock.
Удивительно, но на столе шириной 1 метр хватает места для широкой клавиатуры и для мыши.

В прошлом я был эникеем. Это значит, что я проводил 10% времени за чужими компьютерами. Это научило меня работать на дефолтных настройках и приложениях. Никаких vim-сочетаний или раскладок Бирмана на своём компьютере, иначе будешь страдать на чужих компьютерах.
Ctrl+C и Ctrl+V работают везде. Ctrl+Shift+6 и Ctrl+NumPlus работают в любом проводнике.

Как работать с типографикой, если всё дефолтное? Очень просто — Word. В Word очень не плохо с типографикой. А если чего-то не хватало, то можно было подкрутить функцию автозамены.

А что, если хочется не Word, а блокнот? Тогда пользуемся функцией автозамены в Punto Switcher.
В Punto Switcher обязательно нужно отключить автозамену. Тогда он превращается из врага программиста в друга.
Если нужно корректировать раскладку последнего слова жмём Pause, а для выделенного текста — Shift+Pause.

А если нужна типографика для текстов от других людей, у которых нет раскладки Бирмана, то тут приходит на помощь «Типограф от Артемия Лебедева»

А если не хочется каждый раз ходить в типографику руками, то Артемий Лебедев предоставляет SOAP.
Мыжпрограммисты. Пишем программу, которая берёт текст из буфера обмена, прогоняет через типографику и кладёт обратно в буфер обмена.
Далее создаём ярлык на рабочем столе или в Пуск. Открываем его нажатием Alt+Enter. Задаём хоткей в поле «Быстрый запуск».
И всё, жмём последовательно Ctrl+C, ваш-хоткей, Ctrl+V.

Для совсем программистов есть open source.

Когда я только начинал работать в Word, я всегда начинал с оформления.
В результате, получал идеально оформленный документ, в котором не было текста.
Я успевал потерять мысль задолго до того, как успевал дописать.
Поэтому мой любимый инструмент — это Sublime Text. Главное контент, а не оформление и не типографика.
Когда текст завершён, можно будет думать о товарном виде.

Типизация в drf-spectacular

Гимаев Наиль — Sat, 28 Sep 2024 11:15:05 +0000

Заранее прошу прощения, мне лень писать статью с скриншотами сваггера и с реальным кодом, поэтому пишу сразу без правок и вычиток. Если будет интерес, возможно, когда-нибудь оформлю в виде статьи на Хабре.

Этот пост - ответ на статью https://habr.com/ru/companies/amvera/articles/843232/

Статья хороша. Вот только есть одно очень большое НО, и это - декораторы: extend_schema и т.п.

1. Декораторы - это плохо 🟧

drf-spectacular - это уже третья библиотека для swagger в проекте, который я веду. Сначала был django-rest-swagger - в нём документация велась с помощь doc-string. В какой-то момент эта библиотека передала эстафету библиотеке drf-yasg в ней уже были декораторы. Счастье было долгим, но нужна была поддержка OpenAPI v3. Всем желающим drf-yasg предложил перейти на drf-spectacular.
Мне дважды пришлось переписывать документацию к swagger и мне это не понравилось, т.к. проект большой.
К счастью, drf-spectacular (далее spectacular) спроектирован так, что если API написан правильно, то декораторы вообще не нужны.

2. `GenericAPIView` и `GenericViewSet` - это хорошо ✅

Достаточно унаследовать свои вьюхи от указанных классов и spectacular сам извлечёт необходимые сведения из get_queryset и get_serializer_class.
Т.е. можно написать такой код и swagger сформирует правильную документацию

def get_serializer_class(self):
    if self.action == "create":
        return CreateSerializer
    if self.action == "retrive":
        return RetriveSerializer
    return super().get_serializer_class()

3. Иногда декораторы - это необходимость ✅

Возникает вопрос, зачем нужны декораторы, если spectacular справляется сам. Иногда нужно писать API, которое берёт данные не из БД. Разного рода API-калькуляторы, или API-посредники, которые возвращают вычисленные данные или полученные из вне. В этом случае, приходится наследовать вьюху от APIView. Тут без декоратора не обойтись.

4. `SerializerMethodField` с простыми типами - это хорошо ✅

Если поля имеют простые типы: IntergerField, CharField, то spectacular справляется очень хорошо. Но если используется SerializerMethodField, то ему уже нужны подсказки. Для простых типов это просто, достаточно указать тип возвращаемой функции.

class MySerializer(Serializer):
  a = IntegerField()
  b = IntegerField()
  sum = SerializerMethodField()

def get_sum(self, obj) -> int: # Возвращаемый тип: int
  return obj.a + obj.b

Этот способ хорошо работает, даже если нужно вернуть список простых объектов, например List[str]

5. SerializerMethodField для объектов - это плохо 🟧

Со сложными объектами, не так всё просто. К примеру, у нас есть такой код

# 🟧
class ExperimentSerializer(DummySerializer):
    entity = SerializerMethodField()

    @staticmethod
    def get_entity(_) -> dict:
        return {"a": 1, "b": "2"}

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

# ⁉
class EntityDict(TypedDict):
    a: int
    b: str


class ExperimentSerializer(Serializer):
    entity = SerializerMethodField()

    @staticmethod
    def get_entity(_) -> EntityDict:
        return {"a": 1, "b": "2"}

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

# 🟧
class EntityDict(TypedDict):
    a: int
    b: str

class EntitySerializer(Serializer):
  a = IntegerField()
  b = CharField()

class ExperimentSerializer(Serializer):
    entity = SerializerMethodField()

    @staticmethod
    def get_entity(_) -> EntityDict:
        return EntitySerializer(obj.entity).data

Работает, но тут есть нарушение DRY. Попробуем по другому:

# 🟧
class EntitySerializer(Serializer):
  a = IntegerField()
  b = CharField()

class ExperimentSerializer(Serializer):
    entity = SerializerMethodField()

    @staticmethod
    def get_entity(_) -> EntitySerializer:
        return EntitySerializer(obj.entity).data

От дублирования избавились, swagger всё ещё работает, но тип метода get_entity не соответствует возвращаемым данным.

В общем, для своего проекта я написал класс DataSerializerField, который решает эту проблему.

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

# ✅
class EntitySerializer(Serializer):
  a = IntegerField()
  b = CharField()

class ExperimentSerializer(Serializer):
    entity = DataSerializerField(EntitySerializer)

    @staticmethod
    def get_entity_data(_):
        return obj.entity

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

Форматер black и миграции

Гимаев Наиль — Mon, 04 Oct 2021 05:19:52 +0000

Описание проблемы

С недавних пор PyCharm перестал ругаться на форматирование, которые получается при использовании форматёра black и я полностью отказался от встроенного форматера. Сделал всё как описано в этой инструкции. Потом настроил CI, чтобы он не пропускал код не соответствующий формату black. А чтобы плохой код не доходил до CI, настроил precommit hook в git. Всё хорошо и замечательно до тех пор, пока дело не касается миграций. В обычном коде я постоянно жмякую хоткей, который приведёт код в порядок. Исправил строку - жмякнул. Но в автоматически созданных миграциях нет необходимости открывать файл и из-за них комиты не проходили. Сгенерировал миграцию, попытался сделать коммит, переформатировал код, сделал коммит. И эта последовательность действий повторялась снова и снова. Хотелось этого избежать.

Решение

Я работаю в Windows. Естественно, мой код работает в docker'е. Каждый раз запуская контейнер приложения из консоли я монтирую домашнюю папку. В результате, сохраняется история команд bash и django shell_plus между запусками контейнера.
А раз есть домашняя папка, то можно сделать инициализацию псевдонимов (алиасов). Вот содержимое моего файла .bashrc

echo BASHRC
m () { ./manage.py $@; }
m1 () { MDO_DB=LOCAL m makemigrations $@ && black .; }

alias m2='MDO_DB=LOCAL m migrate'
alias mm='m1 && m2'
alias plus='m shell_plus --print-sql'

alias -p

m1 - создание миграции
m2 - применение миграций
mm - создание и применение

Кстати, о переменной MDO_DB. Я могу переключаться между разными БД: локальной, тестовой и даже продом. За это отвечает упомянутая переменная. К проду подключаться могу, но никогда этого не делаю, а вот тестовому серверу подключаюсь часто, когда нужно пройти отладчиком на данных тестовой среды. И чтобы миграция применялась только на локальной базе, используется явное указание MDO_DB=LOCAL.

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

Глоссарий

Хоткей - горячая клавиша
Жмякнуть - нажать
Псевдоним, алиас - alias
Прод - production-сервер
Глоссарий - словарик

Аннотация типов в миксинах

Гимаев Наиль — Sun, 25 Jul 2021 10:10:28 +0000

При написании кода я стараюсь устранить все замечания линтера PyCharm. Но с миксинами сделать это не так просто
Возьмём для примера, вот такой миксин:

Линтер не доволен, т.к. не понимает при чём тут self.request. Этот вопрос я решал просто, я просто затыкал рот линтеру.

Линтер доволен и молчит, даже если есть явная проблема.
В конце концов, безмолвный линтер стал проблемой, и я решил разобраться в вопросе. Я заглянул в документацию mypy из которой узнал, как можно решить множество замечаний линтера связанные с типами и аннотацией, но не для миксинов. К счастью, я не первый кто задумался об этом, и хоть не с первого раза, я нашёл ответ на StackOverflow, но вам я его не покажу, т.к. не могу найти его снова. Зато я могу показать, как выглядит то, что в итоге получилось:

from typing import TypeVar

T = TypeVar('T')


def mixin_for(_: T) -> T:
    return object

Функция mixin_for позволяет сказать линтеру к какому классу будет подмешиваться миксин.

Заодно получаем автодополнение кода.

На этом всё.

Глоссарий

миксин - mixin, примесь
линтер - linter, статический анализатор кода

Настройки приложений Django

Гимаев Наиль — Mon, 07 Sep 2020 09:26:04 +0000

Вводная

Для всех последующих примеров кода предполагается, что выполнен импорт settings

from django.conf import settings

Проблема

Если мы захотим использовать какую-то из настроек django в своём коде без упоминания его в settings.py, то проблем не возникнет.

# Обычно никто не задаёт значение для CSRF_COOKIE_AGE, 
print(settings.CSRF_COOKIE_AGE) # никаких ошибок, всё работает

Часто для своего приложения нужны свои настройки¹. Чтобы приложение не упало из-за отсутствия настроек в settings.py нужны проверки и подстановка значения по умолчанию.

print(getattr(settings, 'MY_APP_PARAM_1', default_value_of_param_1))

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

# my_app/conf.py
default = {
    'MY_APP_PARAM_1': default_value_of_param_1,
    # Представьте, что здесь перечислены остальные настройки
}
def get_param_value(param_name):
    return getattr(settings, param_name, default_value_of_param_1)

# my_app/any_place.py
from .conf import get_param_value
print(get_param_value('MY_APP_PARAM_1')) # выглядит не очень, но работает
print(get_param_value('MY_APP_PARAM_L')) # IDE не помешает нам ошибиться

Хочется, чтобы работа с настройками была одинаковой для всех приложений, чтобы вид настройки был похож на settings.MY_APP_PARAM_1 и чтобы работало автодополнение.

Решение

Я не стал придумывать велосипед, а взял чужой. Подозреваю, что на просторах PyPi можно найти ещё с десяток, поэтому свой туда забрасывать не стал, хотя найти аналогичный мне там не удалось.
Скачать результат можно на github gist
Код в основном взят из django-rest-framework, из него выкинуто всё, что мешает переиспользованию. Файлик кладётся в папку доступную для всех приложений django. У меня это папка utils.
Посмотрим как это работает

# my_app\settings.py
from utils.django import AppSettings

# Описание настроек приложения.
# 1. Все поля находятся в одном месте
# 2. Видны все значения по умолчанию
# 3. При желании можно добавить типизацию
class MyAppSettings(AppSettings):
    URL = ''
    USER: str = ''
    PASSWORD = ''

# Объект с инициализированными данными 
# 1. Достаточно написать "conf." в любом IDE
#    и редактор сам предложит название настройки
# 2. Все обращения приложения к настройкам должны
#    происходить через этот объект, тогда не будет риска,
#    что приложение "сломается" из-за внешних факторов
conf = MyAppSettings('MY_APP_CONF')

# django_project\settings.py
# ...

# Настройки Django-проекта
# 1. Могут быть заданны частично
# 2. Могут быть совсем не заданы
# 3. Могут быть заданы явно, без использования .env
MY_APP_CONF = {
    'URL': env('MY_APP_URL', default=''),
    'USER': env('MY_APP_USER', default=''),
    'PASSWORD': env('MY_APP_PASSWORD', default=''),
}

# my_app\using.py
from .settings import conf
# Здесь создаётся условный клиент с подключением к некому сервису
client = get_data(conf.URL, conf.USER, conf.PASSWORD)

На что следует обратить внимание:

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

Я называю настройкой константу, которая влияет на поведение программы и значение которой можно задать в settings.py ↩

Отладчик Pycharm против проблемы 1+N

Гимаев Наиль — Mon, 07 Sep 2020 08:15:18 +0000

Лирика

К примеру, требуется вывести в API список пользователей, но не все данные, а только их username, и поэтому queryset=User.objects.only('username'). Допустим, что за один запрос выводится список из 20 пользователей. Теперь мы решили добавить поля first_name и last_name (в сериализатор, но не в queryset). Django Rest Framework перебирает все объекты по очереди. Не обнаружив в текущем объекте поля first_name, django делает запрос в БД за данными этого поля, потом повторяет то же самое для last_name. И так для каждого объекта. В результате имеем один запрос к БД для получения списка объектов и ещё 20 раз по 2 запроса. Итого 41 запрос.
В данном случае достаточно добавить недостающие поля в only или не использовать метод only вовсе. Даже тот, кто знает о коварстве метода only, может не знать об его участии в данном фрагменте кода. А всё потому, что подготовка queryset происходит во view, а использование в serializator.
Описанный случай, является достаточно экзотичным, но хорошо показывает, как на пустом месте вместо одного запроса можно получить множество. Гораздо чаще приходится прописывать prefetch_related для борьбы с 1+N.

Задействуем мощь отладчика Pycharm

Если при ручном тестировании своего кода мне нужно делать обращение к API, то я всегда включаю вывод логов отладчика, чтобы видеть обращение к БД. Я покажу как это делается, но перед этим вам нужно прочитать

Ссылки в Pycharm

Гимаев Наиль ・ Aug 30 ・ 1 min read

Прочитали? Тогда начинаем.

Откройте свой проект django и перейдите по ссылке CursorDebugWrapper.execute или CursorDebugWrapper.debug_sql если у вас Django 3+
Поставьте breakpoint на logger.debug
Сделайте правый клик на красном кружке
В появившимся диалоге отключите Suspend
Включите Evalute and log и напишите '(%.3f) %s; args=%s'%(duration, sql, params)

Должно получится так:

Теперь, если вы запустите проект под отладчиком, то увидите в консоли все запросы к БД и время их выполнения. В моём проекте запросов в БД от вызова одного API не очень много и 1+N сразу бросается в глаза, если не включен cacheops. Отключайте cacheops на машине разработки, тогда неправильные запросы к БД вы будете буквально чувствовать на собственной шкуре без всякого логирования и не допустите плохой код в проект.
Главная прелесть логирования через отладчик в том, что не требуется вносить изменения в код, и не придётся убирать за собой забытые print'ы. При этом я не удаляю breakpoint, когда он мне не нужен, а просто выключаю (Ctrl+Shift+F8). А когда становится нужен, снова включаю. Т.е. настроив breakpoint один раз, пользуюсь им всё время.

Но нужно знать 2 вещи. Во-первых, без отладчика эта история не работает. Во-вторых, даже с отладчиком эта история не работает, если у вас mssql aka SQL Server.

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

Перенос docker wsl2 на соседний ssd

Гимаев Наиль — Wed, 02 Sep 2020 18:01:18 +0000

Лирика

Так уж получилось, что мой компьютер развивался эволюционно, сначала был только один ssd объёмом 120GB. Со временем появился появился второй SSD объёмом 240GB, на который переехала виртуальная машина huper-v с docker внутри. Для этого было достаточно сменить соответствующую настройку в Docker Desktop. Совсем недавно мой Windows обновился до версии 2004. И у меня появилась возможность задействовать WSL2. Включив WSL2 в Docker Desktop обнаружил, остатки свободного места заняты, а системе поплохело. Настроить средствами Docker Desktop расположение wsl-подсистемы нельзя. Зато можно это сделать средствами windows через командную строку.

Update 1. Перенос docker автоматически

После того, как я написал статью, github предложил посмотреть проект, который делает тоже самое. Смотреть я не стал, но возможно он сэкономит время вам. https://github.com/pxlrbt/move-wsl

Перенос docker

Сначала нужно закрыть Docker Desktop, чтобы его значка в трее не было.
Нам потребуются права администратора. Нажмём Win+X и выберем "Командная строка (администратор)"
Данный код можно скачать

:: С двойного двоеточия начинаются комментарии, 
:: поэтому можно весь код скопировать и вставить 
:: в командную строку или в батник.

:: 1. Окончательно усыпим Docker Desktop, чтобы он не нервничал, когда wsl пропадёт

   sc stop com.docker.service

:: 2. Остановим все wsl-машины, чтобы все файловые кэши сбросить на диск

   wsl --shutdown

:: 3. Сделаем дампы подсистем докера

   wsl --export docker-desktop-data d:\dumps\docker-desktop-data.tar
   wsl --export docker-desktop d:\dumps\docker-desktop.tar

:: 4. Удалим подсистемы докера

   wsl --unregister docker-desktop-data
   wsl --unregister docker-desktop

:: 5. Восстановим подсистемы докера в новом расположении

   wsl --import docker-desktop-data d:\wsl\docker-desktop-data d:\dumps\docker-desktop-data.tar --version 2
   wsl --import docker-desktop d:\wsl\docker-desktop d:\dumps\docker-desktop.tar --version 2

:: 6. Запустим службу Docker Desktop

  sc start com.docker.service

Теперь можно запускать Docker Desktop и пользоваться.

Примечание №1. Команды писал по памяти и мог где-то ошибиться. Напишите в комментариях, если найдёте ошибку.
Примечание №2. Чтобы освободить ещё немного места, можно заменить на символические ссылки базовые образы докера в "Program Files", а сами образы положить туда, где места много.

Ссылки в Pycharm

Гимаев Наиль — Sun, 30 Aug 2020 09:42:08 +0000

Если вы и ваш коллега при работе над одним проектом используете PyCharm, то вы можете отправить ему ссылку на строку кода воспользовавшись "Copy reference" Ctrl+Alt+Shift+C¹
Ваш коллега должен дважды нажать Shift и вставить в открывшееся поле полученную ссылку.
В большинстве случаев, ссылки бывают рабочими, в некоторых случаях нужно менять # на .. Поэтому отправляя ссылку желательно проверить, что она открывается, коллеги вам будут благодарны.

Здесь и далее указаны клавиши для Windows ↩

DEV Community: Гимаев Наиль

2. Celery

Используйте transaction.on_commit

Используйте именованные аргументы

1. Тесты

Быстрая обратная связь от тестов

Не держите фикстуры в файле тестов

Держите фикстуры ближе к тестам

Не пользуйтесь одноимённым наследованием фикстур

0. Вводная

DRF: SerializerMethodField vs DataSerializerField

Мои отношения с клавиатурой и типографикой

Типизация в drf-spectacular

1. Декораторы - это плохо 🟧

2. GenericAPIView и GenericViewSet - это хорошо ✅

3. Иногда декораторы - это необходимость ✅

4. SerializerMethodField с простыми типами - это хорошо ✅

5. SerializerMethodField для объектов - это плохо 🟧

Форматер black и миграции

Описание проблемы

Решение

Глоссарий

Аннотация типов в миксинах

Глоссарий

Настройки приложений Django

Вводная

Проблема

Решение

Отладчик Pycharm против проблемы 1+N

Лирика

Задействуем мощь отладчика Pycharm

Ссылки в Pycharm

Гимаев Наиль ・ Aug 30 ・ 1 min read

Перенос docker wsl2 на соседний ssd

Лирика

Update 1. Перенос docker автоматически

Перенос docker

Ссылки в Pycharm

2. `GenericAPIView` и `GenericViewSet` - это хорошо ✅

4. `SerializerMethodField` с простыми типами - это хорошо ✅