🚀 Мизулина предложила разблокировать X (бывший Twitter) в России — мол, теперь там меньше цензуры и деструктива.
А у меня X давно был, просто стоял пыльный в углу. Но теперь я его почистил, помыл и готов к разблокировке 😎
А вот и ссылочка, если что 👉 https://x.com/debug_leg
#новости
А у меня X давно был, просто стоял пыльный в углу. Но теперь я его почистил, помыл и готов к разблокировке 😎
А вот и ссылочка, если что 👉 https://x.com/debug_leg
#новости
👍2
📱 Цифровой шаббат: мозгам тоже нужен выходной
Всё чаще ловлю себя на том, что залипаю в соцсетях. Эти короткие видео засасывают так, что даже не замечаешь, как прошло полчаса. А месяц назад наткнулся на статью, где написано, что от этого чуть ли не мозги гниют. Теперь мы с Юлей подкалываем друг друга: если кто-то зависает в телефоне, сразу получаем «Эй, у тебя там уже плесень растёт?» 😆
Но шутки в сторону — надо что-то делать. Первая мера — цифровой шаббат. День без телефона, соцсетей, новостей и прочего инфошума. Только офлайн, только хардкор.
А может, ну его нафиг и взять Nokia 3310? 🤔
#bio
Всё чаще ловлю себя на том, что залипаю в соцсетях. Эти короткие видео засасывают так, что даже не замечаешь, как прошло полчаса. А месяц назад наткнулся на статью, где написано, что от этого чуть ли не мозги гниют. Теперь мы с Юлей подкалываем друг друга: если кто-то зависает в телефоне, сразу получаем «Эй, у тебя там уже плесень растёт?» 😆
Но шутки в сторону — надо что-то делать. Первая мера — цифровой шаббат. День без телефона, соцсетей, новостей и прочего инфошума. Только офлайн, только хардкор.
А может, ну его нафиг и взять Nokia 3310? 🤔
#bio
🔥1
💡 Почему так много языков программирования?
Долго не мог понять, зачем придумывать новые языки, пока не услышал одну шутку:
📜 У нас есть 10 стандартов. Давайте объединим их в один универсальный!
📜 Теперь у нас 11 стандартов...
#мем
Долго не мог понять, зачем придумывать новые языки, пока не услышал одну шутку:
📜 У нас есть 10 стандартов. Давайте объединим их в один универсальный!
📜 Теперь у нас 11 стандартов...
#мем
❤1
💻 Кто такие DevOps?
Если спросить разработчика: "Кто такой 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 – это отдельная команда или интегрированы в разработку? 🚀
#толки
Если спросить разработчика: "Кто такой 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 – это отдельная команда или интегрированы в разработку? 🚀
#толки
Доброе утро! ☕️ Маск снова в деле — он хочет купить OpenAI и вернуть компанию к опенсорсу.
Предложение уже на столе у совета директоров, но Альтман не в восторге и даже предложил Маску продать Twitter за 9 млрд в ответ.
Будет ли новая война миллиардеров или OpenAI действительно сменит курс — пока загадка, но скучно точно не будет 🔥
Предложение уже на столе у совета директоров, но Альтман не в восторге и даже предложил Маску продать Twitter за 9 млрд в ответ.
Будет ли новая война миллиардеров или OpenAI действительно сменит курс — пока загадка, но скучно точно не будет 🔥
👍1
🏗 DDD — от теории к практике: что это и как его внедрять
Если ты когда-нибудь страдал от монолитного кода, который невозможно масштабировать, то пора познакомиться с Domain-Driven Design (DDD).
💡 DDD — это про логику бизнеса, а не про базы данных и API. Его цель — построить код вокруг реальных процессов компании, а не вокруг технических решений.
Но вот в чём проблема:
❌ DDD сложно внедрять
❌ Это не просто «новая архитектура» — это другой взгляд на код
❌ Без дисциплины DDD превращается в обычный антипаттерн
📌 Основные принципы DDD
✅ Bounded Context (Ограниченные контексты) — разделяем систему на независимые домены. Например, "Заказы" и "Биллинг" — это разные процессы, их не нужно смешивать.
✅ Ubiquitous Language (Единый язык) — разработчики, аналитики и бизнес должны говорить на одном языке. Если бизнес использует термин "Клиент", а в коде он называется "UserEntity", то кто-то тут явно врёт.
✅ Entities и Value Objects — сущности со своим жизненным циклом и неизменяемые объекты с бизнес-логикой.
✅ Domain Events — важные события, на которые реагируют другие части системы (например, "Заказ создан" → "Биллингу нужно выставить счёт").
📂 Как хранить код по DDD?
Одна из главных ошибок — думать, что DDD = микросервисы. Это не так. Можно строить DDD внутри одного сервиса, если правильно разложить код.
🔹 Базовая структура DDD-сервиса
Если ты когда-нибудь страдал от монолитного кода, который невозможно масштабировать, то пора познакомиться с Domain-Driven Design (DDD).
💡 DDD — это про логику бизнеса, а не про базы данных и API. Его цель — построить код вокруг реальных процессов компании, а не вокруг технических решений.
Но вот в чём проблема:
❌ DDD сложно внедрять
❌ Это не просто «новая архитектура» — это другой взгляд на код
❌ Без дисциплины DDD превращается в обычный антипаттерн
📌 Основные принципы DDD
✅ Bounded Context (Ограниченные контексты) — разделяем систему на независимые домены. Например, "Заказы" и "Биллинг" — это разные процессы, их не нужно смешивать.
✅ Ubiquitous Language (Единый язык) — разработчики, аналитики и бизнес должны говорить на одном языке. Если бизнес использует термин "Клиент", а в коде он называется "UserEntity", то кто-то тут явно врёт.
✅ Entities и Value Objects — сущности со своим жизненным циклом и неизменяемые объекты с бизнес-логикой.
✅ Domain Events — важные события, на которые реагируют другие части системы (например, "Заказ создан" → "Биллингу нужно выставить счёт").
📂 Как хранить код по DDD?
Одна из главных ошибок — думать, что DDD = микросервисы. Это не так. Можно строить DDD внутри одного сервиса, если правильно разложить код.
🔹 Базовая структура DDD-сервиса
/src
├── /order # Контекст "Заказы"
│ ├── /application # Сценарии использования (Use Cases)
│ │ ├── PlaceOrderHandler.py
│ │ ├── CancelOrderHandler.py
│ ├── /domain # Бизнес-логика
│ │ ├── /models # Entities и Value Objects
│ │ │ ├── Order.py
│ │ │ ├── OrderItem.py
│ │ │ ├── OrderStatus.py
│ │ ├── /services # Бизнес-сервисы (доменные)
│ │ │ ├── OrderService.py
│ │ │ ├── DiscountCalculator.py
│ │ ├── /events # Доменные события
│ │ │ ├── OrderPlaced.py
│ │ │ ├── OrderCancelled.py
│ │ ├── /repositories # Абстракция работы с БД
│ │ │ ├── OrderRepository.py
│ ├── /infrastructure # Взаимодействие с внешним миром
│ │ ├── /persistence # Реализация репозиториев
│ │ │ ├── OrderSQLRepository.py
│ │ ├── /messaging # Интеграция с брокерами событий
│ │ │ ├── KafkaPublisher.py
│ │ ├── /external # API-запросы к сторонним сервисам
│ │ │ ├── PaymentGateway.py
│ ├── /presentation # API-интерфейсы
│ │ ├── /http # REST API
│ │ │ ├── OrderController.py
│ │ ├── /cli # Консольные команды
│ │ │ ├── ImportOrders.py
│ │ ├── /events # Обработчики событий
│ │ │ ├── OrderPlacedListener.py
├── /customer # Контекст "Клиенты"
├── /billing # Контекст "Биллинг"
├── /shared # Общий код между контекстами
│ ├── /kernel # Базовые интерфейсы и абстракции
│ ├── /events # Кросс-доменные события
│ ├── /utils # Хелперы и вспомогательные классы
├── main.py # Точка входа
├── settings.py # Конфигурация
└── requirements.txt # Зависимости
🛠 Как применять DDD в реальной жизни?
1️⃣ Определить домены — выделить ограниченные контексты и не смешивать их.
2️⃣ Говорить на языке бизнеса — если в компании термин "Клиент", то в коде это тоже "Клиент", а не "UserEntity".
3️⃣ Разделить слои — доменная логика, инфраструктура и интерфейсы не должны жить в одном месте.
4️⃣ Использовать событийную модель — "Заказ создан" → "Биллинг должен выставить счёт" → "Система уведомлений отправляет письмо".
DDD звучит круто, но на практике далеко не всегда оправдывает затраты. Вот основные минусы и подводные камни:
❌ 1. Сложность внедрения
DDD требует глубокого понимания бизнес-процессов. Нужно не просто писать код, а строить архитектуру вокруг бизнеса. Если команда не готова, получится монструозная система с кучей ненужных сущностей.
❌ 2. Избыточность для простых проектов
Если ты делаешь небольшой CRUD-сервис, то DDD – это перебор. Ограниченные контексты, доменные события и инфраструктурные слои только усложнят жизнь.
❌ 3. Высокий порог вхождения
Разработчикам, привыкшим к классическим архитектурам, будет больно. Код становится менее очевидным, а навигация требует знания всех контекстов.
❌ 4. Усложнение коммуникации
Если разделить систему неправильно, то контексты будут постоянно взаимодействовать друг с другом, создавая чрезмерную связанность. В итоге бизнес-логика снова расползётся, а команда утонет в согласованиях.
❌ 5. Зависимость от качества модели
Если на старте неправильно выделить домены, то всё пойдёт по наклонной. Переосмыслить архитектуру на поздних этапах очень дорого.
❌ 6. Замедление старта проекта
DDD требует времени на проектирование, а в реальном мире бизнесу нужны фичи вчера. В стартапах, где важна скорость, проще начать с простого решения, а DDD внедрять постепенно.
🎯 Когда DDD НЕ нужен?
❌ Если проект маленький (обычный CRUD)
❌ Если бизнес ещё сам не понял, как он работает
❌ Если команда не готова поддерживать сложную архитектуру
❌ Если продукту нужно быстро выйти на рынок
✅ Когда 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 в библиотеке)
#тек
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - citerus/dddsample-core: This is the new home of the original DDD Sample app (previously hosted at sf.net)..
This is the new home of the original DDD Sample app (previously hosted at sf.net).. - GitHub - citerus/dddsample-core: This is the new home of the original DDD Sample app (previously hosted at sf....
Спокойной ночи! 🌙 Я иду спать, но в шоках, как сложно сделать миграцию схемы БД, если используешь Python 😅💥
👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Всем доброе утречко 🌞. Только что, меня забулили весы и написали что я жирны 🥺
Please open Telegram to view this post
VIEW IN TELEGRAM
😁1
Креативный отстойник: место, где рождаются гениальные идеи 🚀
Когда ты пишешь код, ты ведь не выкатываешь его сразу в прод? Сначала тесты, отладка, эксперименты. Так почему с идеями должно быть иначе?
У каждого разработчика должен быть Креативный отстойник — место, куда можно сливать все сырые, странные и на первый взгляд бесполезные идеи. Большинство из них, конечно, окажутся мусором. Но среди этого хаоса могут появиться инсайты, которые изменят твою жизнь и карьеру.
💡 Как работает Креативный отстойник?
Это твой личный Google Drive для мыслей. Сюда можно закидывать всё — от смелых технических решений до бизнес-идей и диких гипотез. Чем больше идей — тем выше шанс наткнуться на что-то стоящее.
🔥 Примеры идей, которые могли бы попасть в твой Креативный отстойник:
🔹 "А что если Telegram-бот может сам искать скидки и предлагать мне лучшие?" (Ой, кажется, уже реализовано 😏)
🔹 "А что если делать IT-курсы в формате ситкома?" (Представь курс по Kotlin, где студенты — герои сериала!)
🔹 "А что если разработчик мог бы кодить голосом без клавиатуры?" (Ну, голосовые помощники уже рядом...)
🔹 "А что если делать Reels, где ты объясняешь сложные IT-концепты на пальцах?" (Привет, бесплатный трафик на блог)
🔹 "А что если написать книгу, но каждую главу генерирует ИИ по ключевым словам?"
Суть в том, что в момент появления идея может казаться бредом. Но если дать ей отлежаться в Креативном отстойнике, через пару недель или месяцев ты увидишь в ней потенциал.
🚀 Как создать свой Креативный отстойник?
1️⃣ Фиксируй всё без фильтра. Заметки, голосовые сообщения в телеге, таблички в Obsidian — не важно, где. Главное, не доверять только памяти.
2️⃣ Выделяй время на пересмотр. Раз в месяц открывай архив идей и смотри на них свежим взглядом.
3️⃣ Связывай несвязанное. Иногда самые неожиданные сочетания дают лучший результат (например, чат-бот + мини-игры = твой новый стартап).
4️⃣ Не бойся абсурда. Сначала идея кажется глупой, а потом кто-то на ней делает миллионы (вспомни Flappy Bird).
5️⃣ Экспериментируй. Маленькие прототипы, MVP, тестовые запуски — не думай, а пробуй.
А куда ты сливаешь свои дикие идеи? Или до сих пор фильтруешь их на старте? 😏
#пробую
Когда ты пишешь код, ты ведь не выкатываешь его сразу в прод? Сначала тесты, отладка, эксперименты. Так почему с идеями должно быть иначе?
У каждого разработчика должен быть Креативный отстойник — место, куда можно сливать все сырые, странные и на первый взгляд бесполезные идеи. Большинство из них, конечно, окажутся мусором. Но среди этого хаоса могут появиться инсайты, которые изменят твою жизнь и карьеру.
💡 Как работает Креативный отстойник?
Это твой личный Google Drive для мыслей. Сюда можно закидывать всё — от смелых технических решений до бизнес-идей и диких гипотез. Чем больше идей — тем выше шанс наткнуться на что-то стоящее.
🔥 Примеры идей, которые могли бы попасть в твой Креативный отстойник:
🔹 "А что если Telegram-бот может сам искать скидки и предлагать мне лучшие?" (Ой, кажется, уже реализовано 😏)
🔹 "А что если делать IT-курсы в формате ситкома?" (Представь курс по Kotlin, где студенты — герои сериала!)
🔹 "А что если разработчик мог бы кодить голосом без клавиатуры?" (Ну, голосовые помощники уже рядом...)
🔹 "А что если делать Reels, где ты объясняешь сложные IT-концепты на пальцах?" (Привет, бесплатный трафик на блог)
🔹 "А что если написать книгу, но каждую главу генерирует ИИ по ключевым словам?"
Суть в том, что в момент появления идея может казаться бредом. Но если дать ей отлежаться в Креативном отстойнике, через пару недель или месяцев ты увидишь в ней потенциал.
🚀 Как создать свой Креативный отстойник?
1️⃣ Фиксируй всё без фильтра. Заметки, голосовые сообщения в телеге, таблички в Obsidian — не важно, где. Главное, не доверять только памяти.
2️⃣ Выделяй время на пересмотр. Раз в месяц открывай архив идей и смотри на них свежим взглядом.
3️⃣ Связывай несвязанное. Иногда самые неожиданные сочетания дают лучший результат (например, чат-бот + мини-игры = твой новый стартап).
4️⃣ Не бойся абсурда. Сначала идея кажется глупой, а потом кто-то на ней делает миллионы (вспомни Flappy Bird).
5️⃣ Экспериментируй. Маленькие прототипы, MVP, тестовые запуски — не думай, а пробуй.
Креативный отстойник — это не просто свалка для идей. Это инкубатор будущих проектов, о которых ты пока даже не подозреваешь.
А куда ты сливаешь свои дикие идеи? Или до сих пор фильтруешь их на старте? 😏
#пробую
👍1