debudLeg

Серьёзно, как люди вообще пишут продакшен на Python? Сейчас делаю небольшой ТГ-бот, который просто вызывает одну модельку. Казалось бы, простая задача, но каждый шаг – чистая боль.

1. Установка Python

Неважно, что у тебя уже есть Python – он всё равно "не тот". Версия не совпадает, окружение не то, пакеты не работают. Pyenv, venv, poetry – выбери свою религию и страдай.

2. Установка зависимостей

Ты пишешь pip install, а тебе в ответ:

❌ Несовместимая версия

❌ Нет нужного интерпретатора

❌ Требуется компиляция C++ (на Windows – отдельная боль)

И, конечно, если в проекте есть зависимости с TensorFlow или PyTorch – держись крепче.

3. Всё ломается, но никто не знает, почему

Документация говорит одно, stackoverflow – другое, а у тебя вообще третье. Какие-то модули конфликтуют, virtualenv ведёт себя странно, а твой код работает только на твоей машине.

4. Деплой? Ну удачи

Контейнеры, зависимости, версия Python, специфичные окружения – каждый деплой превращается в приключение. И если у тебя сервер с Ubuntu, а разворачивать надо на Alpine – поздравляю, ты только что подписался на ещё один день боли.

💀 Как люди на этом пишут продакшен?

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

Короче, пока я ковыряюсь с этим ботом, скажите, как вы справляетесь с Python в проде?

Мой ТГ

💥 Вчера наш рабочий чатик разорвало провокационное сообщение из чата пользователей. Для контекста: мы разрабатываем внутренний сервис, а вот что написал один из юзеров:

"Мне нужно было привязать свою БД (канал в ТГ) и интегрировать скрипт в сервис. Потратил 25 минут, сделал примитивный интерфейс, и всё работает. Посмотрим, за сколько наши «спецы» справятся. Если, конечно, вообще обратят внимание."

И вот сижу, читаю это и понимаю — ну правда, мы так не можем. И вот почему:

🔹 Продуктовая команда не может знать о каждой хотелке. Кто-то один придумал себе кейс, но для нас это не всегда очевидно.

🔹 Приоритеты. У пользователей одна задача, а у нас — десятки, и далеко не все из них связаны с этим конкретным фич-реквестом.

🔹 Качество решения. Это не просто скрипт «на коленке» для себя. Нужно учесть дизайн, тестирование, безопасность, поддержку, документацию и так далее.

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

И это вообще топовый лайфхак для тех, кто ищет первую работу в IT или проект для портфолио.

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

Я сам, когда работал инженером-проектировщиком на заводе, писал такие тулзы на коленке:

🛠 Считал неиспользованные контакты в разъёме

📊 Автоматически формировал отчёт по приходам и уходам

📂 Собрал базу данных чертежей

Вот такие проекты реальные, полезные и прокачивают.

Мой ТГ

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

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

💡 Как работает Креативный отстойник?

Это твой личный Google Drive для мыслей. Сюда можно закидывать всё — от смелых технических решений до бизнес-идей и диких гипотез. Чем больше идей — тем выше шанс наткнуться на что-то стоящее.

🔥 Примеры идей, которые могли бы попасть в твой Креативный отстойник:

🔹 "А что если Telegram-бот может сам искать скидки и предлагать мне лучшие?" (Ой, кажется, уже реализовано 😏)

🔹 "А что если делать IT-курсы в формате ситкома?" (Представь курс по Kotlin, где студенты — герои сериала!)

🔹 "А что если разработчик мог бы кодить голосом без клавиатуры?" (Ну, голосовые помощники уже рядом...)

🔹 "А что если делать Reels, где ты объясняешь сложные IT-концепты на пальцах?" (Привет, бесплатный трафик на блог)

🔹 "А что если написать книгу, но каждую главу генерирует ИИ по ключевым словам?"

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

🚀 Как создать свой Креативный отстойник?

1️⃣ Фиксируй всё без фильтра. Заметки, голосовые сообщения в телеге, таблички в Obsidian — не важно, где. Главное, не доверять только памяти.

2️⃣ Выделяй время на пересмотр. Раз в месяц открывай архив идей и смотри на них свежим взглядом.

3️⃣ Связывай несвязанное. Иногда самые неожиданные сочетания дают лучший результат (например, чат-бот + мини-игры = твой новый стартап).

4️⃣ Не бойся абсурда. Сначала идея кажется глупой, а потом кто-то на ней делает миллионы (вспомни Flappy Bird).

5️⃣ Экспериментируй. Маленькие прототипы, MVP, тестовые запуски — не думай, а пробуй.

А куда ты сливаешь свои дикие идеи? Или до сих пор фильтруешь их на старте? 😏

Мой ТГ

Если ты когда-нибудь страдал от монолитного кода, который невозможно масштабировать, то пора познакомиться с Domain-Driven Design (DDD).

💡 DDD — это про логику бизнеса, а не про базы данных и API. Его цель — построить код вокруг реальных процессов компании, а не вокруг технических решений.

Но вот в чём проблема:

❌ DDD сложно внедрять

❌ Это не просто «новая архитектура» — это другой взгляд на код

❌ Без дисциплины DDD превращается в обычный антипаттерн

📌 Основные принципы DDD

✅ Bounded Context (Ограниченные контексты) — разделяем систему на независимые домены. Например, "Заказы" и "Биллинг" — это разные процессы, их не нужно смешивать.

✅ Ubiquitous Language (Единый язык) — разработчики, аналитики и бизнес должны говорить на одном языке. Если бизнес использует термин "Клиент", а в коде он называется "UserEntity", то кто-то тут явно врёт.

✅ Entities и Value Objects — сущности со своим жизненным циклом и неизменяемые объекты с бизнес-логикой.

✅ Domain Events — важные события, на которые реагируют другие части системы (например, "Заказ создан" → "Биллингу нужно выставить счёт").

📂 Как хранить код по DDD?

Одна из главных ошибок — думать, что DDD = микросервисы. Это не так. Можно строить DDD внутри одного сервиса, если правильно разложить код.

🔹 Базовая структура DDD-сервиса

🛠 Как применять DDD в реальной жизни?

1️⃣ Определить домены — выделить ограниченные контексты и не смешивать их.

2️⃣ Говорить на языке бизнеса — если в компании термин "Клиент", то в коде это тоже "Клиент", а не "UserEntity".

3️⃣ Разделить слои — доменная логика, инфраструктура и интерфейсы не должны жить в одном месте.

4️⃣ Использовать событийную модель — "Заказ создан" → "Биллинг должен выставить счёт" → "Система уведомлений отправляет письмо".

DDD звучит круто, но на практике далеко не всегда оправдывает затраты. Вот основные минусы и подводные камни:

❌ 1. Сложность внедрения

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

❌ 2. Избыточность для простых проектов

Если ты делаешь небольшой CRUD-сервис, то DDD – это перебор. Ограниченные контексты, доменные события и инфраструктурные слои только усложнят жизнь.

❌ 3. Высокий порог вхождения

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

❌ 4. Усложнение коммуникации

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

❌ 5. Зависимость от качества модели

Если на старте неправильно выделить домены, то всё пойдёт по наклонной. Переосмыслить архитектуру на поздних этапах очень дорого.

❌ 6. Замедление старта проекта

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

🎯 Когда DDD НЕ нужен?

❌ Если проект маленький (обычный CRUD)

❌ Если бизнес ещё сам не понял, как он работает

❌ Если команда не готова поддерживать сложную архитектуру

❌ Если продукту нужно быстро выйти на рынок

✅ Когда DDD полезен?

✔ Если система сложная, с множеством бизнес-правил

✔ Если команда готова работать с доменной моделью

✔ Если кодовая база разрастается и становится неуправляемой

✔ Если модель данных и бизнес-процессы стабильно развиваются

🚀 Итог

DDD — это не просто красивая архитектура, а философия проектирования. Она даёт:

✅ Читаемость кода

✅ Независимость контекстов

✅ Чёткие границы между доменами

Но если всё сделать неправильно, DDD превращается в хаос. 😅 Поэтому главное — не усложнять без необходимости.

Если твой код уже похож на лапшу, возможно, время пересмотреть его структуру. 🏗

DDD — тема непростая, поэтому книги тут играют ключевую роль. Вот парочка отличных источников:

📖 "Domain-Driven Design: Tackling Complexity in the Heart of Software" — Эрик Эванс

Это Библия DDD. Если хочешь понять концепции глубоко — бери и читай. Правда, книга непростая и требует терпения.

📖 "Implementing Domain-Driven Design" — Вон Вернон

Более прикладной вариант. Если после Эванса осталось чувство "что это было?", Вернон поможет разложить все по полочкам.

📝 "DDD Distilled" — тот же Вон Вернон, но в сжатом формате

Если хочешь получить квинтэссенцию DDD без лишней воды — отличный старт.

🎥 Серия лекций от Вон Вернона на YouTube

Можно найти много интересных выступлений, где он объясняет ключевые аспекты DDD.

🛠 Hands-on DDD

На GitHub есть примеры проектов, реализующих DDD, например:

github.com/citerus/dddsample-core (эталонный пример)

github.com/ddd-by-examples/library (пример DDD в библиотеке)

Мой ТГ

Если спросить разработчика: "Кто такой DevOps?", то можно услышать что-то вроде:

👨‍💻 "Ну… это админ, который знает не только bash, но и Python, а иногда даже Go!"

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

🚀 Что делает DevOps?

🔹 CI/CD – настраивает конвейер доставки кода (GitLab CI, Jenkins, GitHub Actions), чтобы каждое изменение залетало в прод без магии шаманов.

🔹 Контейнеризация – заворачивает приложения в Docker, а потом ставит их в Kubernetes, чтобы они не падали при первом же нагрузочном тесте.

🔹 Мониторинг и логирование – разворачивает Prometheus, Grafana, Loki, чтобы никто не бегал по серверу с grep’ом в поисках "почему всё упало".

🔹 Автоматизация инфраструктуры – Terraform, Ansible, Helm – всё, что избавляет от ручной настройки серверов, которые "работают, но лучше не трогать".

🔹 Облачные технологии – Selectel, Yandex Cloud, Cloud.ru – чтобы можно было за 5 минут развернуть 100 серверов, а потом за 10 секунд их удалить, когда приходит счёт за облако 😅.

🤔 А DevOps – это команда или один человек?

Есть две модели:

1️⃣ DevOps-команда – отдельный отдел, который обслуживает несколько команд разработки. Минус – часто становится бутылочным горлышком.

2️⃣ DevOps в команде разработки – тогда DevOps-инженер встроен в продуктовую команду и решает задачи конкретного продукта. Это быстрее, но требует хорошего уровня скилла от разработчиков.

🧐 А что по зарплатам?

Ну… если видишь DevOps, который не спешит менять работу – значит, у него либо зарплата хорошая, либо мониторинг настроен идеально 😆

А как у вас? DevOps – это отдельная команда или интегрированы в разработку? 🚀

Мой ТГ

Сегодня наткнулся на новость: американские спецы обучили нейросетку за $50. Причем данные для обучения им сгенерил... GPT. Да, та самая нейросетка учила другую нейросетку. Матрешка технологий.

И вот я сижу и думаю, в каком же некачественном мире я живу. Это ощущение меня не покидало с тех пор, как я впервые услышал про Agile.

📉 Как работает реальный мир технологий?

Бюджет на маркетинг больше, чем бюджет на разработку.

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

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

А самое главное — потребитель давно не цель, а товар.

👕 Если массово шьют футболки, значит, есть массовый потребитель.

🧠 Если каждая вторая компания заявляет, что у нее есть своя нейросеть, значит, просто так надо говорить. Потому что если не скажешь — инвестор унесет деньги тем, кто сказал.

А на чем реально обучали нейросеть? На реальных данных или синтетике?

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

🧐 Что думаешь? Мир технологий реально деградирует или это просто новая норма? 👇

Мой ТГ

В одном из первых постов я рассказывал, как из-за моей ошибки контора потеряла 10к $. Тогда я отправлял события в очередь до записи в БД. Запрос к БД упал, а уведомление уже улетело в платежный сервис. В итоге деньги списали, но не зафиксировали в системе, а потом это повторилось еще много-много раз.

Если бы тогда использовали реляционную БД и Outbox-паттерн, этого бы не случилось.

🤔 В чем проблема?

Типичная схема взаимодействия с брокером:

1️⃣ Пишем данные в БД

2️⃣ Отправляем событие в очередь

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

Решения без Outbox:

🔹 Повторять отправку? — Дубликаты и сложность в обработке

🔹 Держать транзакцию до подтверждения от брокера? — Тормоза в БД

🔹 Игнорировать? — Потерянные данные и баги

🛠 Как решает Outbox?

Вместо того чтобы сразу пушить событие:

✅ Записываем его в специальную таблицу (outbox) в той же транзакции, что и изменение данных

✅ Отдельный процесс (consumer, cron-job, Debezium) читает outbox и отправляет события в брокер

✅ После успешной отправки удаляем запись из outbox

🎯 Почему это круто?

✔️ Гарантия доставки — без потерь, даже если брокер лег

✔️ Идемпотентность — события можно повторно обработать без дубликатов

✔️ Разделение ответственности — бизнес-логика в одном месте, отправка в другом

🚀 Когда использовать?

✔ Если твои сервисы взаимодействуют через event-driven архитектуру

✔ Если тебе нужно гарантированно отправлять события, даже при сбоях

✔ Если ты используешь реляционную БД и хочешь избавиться от сложностей с distributed transactions

Если бы у нас тогда был Outbox + реляционная БД, я бы просто записал событие в outbox в одной транзакции с изменением данных. Даже если бы платежный сервис упал, событие никуда бы не пропало — оно бы отправилось при следующей обработке.

Вывод: если работаешь с реляционной БД и событиями — Outbox обязателен. Уже используешь или пока надеешься на удачу? Давай обсудим в комментах! 💬