Alternatives to pre-commit package in python development

In my opinion, pre-commit package is often misused and I want to show you an alternative way.

Read here: https://shiriev.ru/posts/2024-12-14-pre-commit-in-python/

Asyncio tasks can be canceled, but asyncio provides a way to shield tasks from cancellation via asyncio.shield().

Read here more: https://shiriev.ru/posts/2025-01-30-asyncio-shield/

About strict-mode in mypy.

This article describes some problems which can be faced after turning on strict mode in Mypy and proposes solutions to them.

Read here: https://shiriev.ru/posts/2025-02-07-strict-mypy/

I have recently migrated some projects from poetry to uv and used this tool https://github.com/stvnksslr/uv-migrator. Take a look if you have some poetry projects and consider moving them to uv

How to install and run on MacOS:
1. Install cargo. For this I installed rust by running
brew install rust
2. Install uv-migrator:
cargo install uv-migrator
3. Run command in the root directory of your project:
uv-migrator .

Here is what came out of it https://github.com/community-of-python/microbootstrap/blob/main/pyproject.toml

When using FastAPI with redirect_slashes=True (the default setting), POST requests to endpoints without trailing slashes are redirected to their slash-appended versions. However, this redirect process can cause unexpected behavior where POST requests are converted to GET requests, potentially leading to data loss and incorrect endpoint handling.

I solved this by turning off such redirects completely by settings redirect_slashes argument to False:

from fastapi import FastAPI

app = FastAPI(redirect_slashes=False)

Сегодня пост не про технологии.

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

В общем виде сформулировал идею так: не разделяйте работу на зоны ответственности.

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

Какие преимущества у такого подхода:
1. Я прокачиваю свои коммуникативные и организаторские навыки, так как для решения каких-то особенно сложных проблем может потребоваться подключить много разных людей из разных команд.
2. Я прокачиваю смежные профессиональные навыки и начинаю видеть общую картину, что позволит мне в будущем брать на себя более сложные задачи.
3. Мой руководитель понимает, что со мной не нужен микроменеджмент и я не буду сидеть без дела, потому что столкнулся с проблемой "не из моей зоны ответственности". У него повысится уровень доверия ко мне и он начнет мне доверять более сложные задачи и может порекомендовать к повышению.

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

P.S. я расту именно так, но не утверждаю, что это гарантированный и самый эффективный способ

P.P.S и я не имею в виду, что любую проблему я должен решать собственноручно. Я про то, что если подключу других людей, то как минимум буду держать эту проблему в фокусе и постоянно мониторить ее решение

В команде для общения пользуемся корпоративным mattermost, раньше пользовались Slack.

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

1. Один тред - одна проблема

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

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

2. Чем писать в старый тред, лучше создать новый

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

Преимущества:
1. Участникам не нужно перечитывать весь тред
2. Инициатор освежает в голове контекст, что ведет к более продуктивной дискуссии

3. Отписываюсь от "завершенных" тредов

Что считаю "завершенным" тредом
1. Если обсуждаемый вопрос в треде полностью разрешился
2. Если обсуждаемый вопрос оформлен в виде задачи
3. Если по треду нет активности 2 и более дней (субъективно)

На "завершенный" тред ставлю реакцию с галкой и отписываюсь от него.

Реакция галки для других участников означает, что если нужно переоткрыть данный тред, то есть ненулевая вероятность, что участники треда отписались от него и нужно "упоминание" / "mention", т.е. явный призыв в тред

Преимущества:
1. Таким образом количество тредов не разрастается до бесконечности и можно периодически пробегаться по списку и трекать статус каких-то обсуждений

4. Треды вместо личных сообщений

Если кто-то написал в личные сообщения по рабочим вопросам, то я по возможности перевожу обсуждение в тред

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

5. Треды - не документация

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

Сегодня хочу рассказать, как я работаю с почтой.
У меня есть 3 почтовых ящика: 2 личных и один рабочий. И во всех этих ящиках 0 входящих сообщений. И в спаме тоже пусто. Обычно есть менее 5 сообщений в архиве, это могут быть билеты на самолет, поезд.

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

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

Пример 1
Я недавно уходил в отпуск на полторы недели. За это время мне прилетело 600+ сообщений. Их полная обработка заняла полтора часа и после этого я был полностью в контексте задач, которыми моя команда занималась. Провел ревью всего написанного кода, оставил свои комментарии, завел необходимые задачи и инициировал необходимые обсуждения в чатах.

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

Инвестиция в пустой список входящих окупается с лихвой, поэтому настоятельно рекомендую попробовать.