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
Даже когда я не был лидом, благодаря этой технике просматривал весь код, который писала команда. И всегда был в контексте происходящего на проекте, был в курсе проблем, с которыми столкнулись коллеги и был вооружен, если сам сталкивался с такими проблемами.

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

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

Преимущества данного подхода:
1. Быстрая адаптация на новом месте работы. Когда я только прихожу в новую компанию, возникает очень много вопросов, но если активно уменьшать неопределенность, то адаптация происходит гораздо быстрее
2. Быстрое развитие профессиональных навыков. Благодаря данному подходу можно открывать для себя много новых возможностей для роста. Это важно для развития, как архитектора или лида. Это прокачивает так называемый технический кругозор (Technical Breadth)
3. Если обсуждения происходят в публичных чатах, то это и еще источник развития для всей команды, потому что у других людей тоже могут возникать те же самые вопросы, но они стесняются их задавать.