В этой статье я хотел бы рассмотреть микросервисные паттерны под другим углом. Когда я начинал изучение микросервисных паттернов, у меня постоянно был вопрос: Так это же было в другом паттерне. Я решил немного структурировать их: объединить по похожим элементам. Кластеризировать микросервисные паттерны достаточно тяжело так как каждый паттерн по‑своему уникален, однако для запоминания на собеседованиях или для себя это сделать можно. Основной контент статьи — картинка, далее идёт описание, чтобы всё было в одном месте.

Эта статья предназначена для более быстрого запоминания/повторения паттернов микросервисов. Кое‑где я приводил кейсы, которые могут быть непонятны новичкам. Здесь нет подробных кейсов применения каждого паттерна так как иначе статья получилась бы на другую тему. Для удобства я приложил ссылки — чтобы избежать дублей.

Привет, Хабр! Меня зовут Андрей Слесаренко — frontend‑разработчик с опытом работы более 8 лет. Прошёл путь от джуна до тимлида, работал над разными высоко‑нагруженными проектами. В начале этого года начал активно использовать LLM‑агентов в повседневной работе — и за это время набил немало шишек.

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

В новой статье от команды AI for Devs разбираемся, как организовать вайб-кодинг с плагином Kilo Code в VS Code и IntelliJ IDEA из России. Пошагово настраиваем Kilo Code через RouterAI, подключаем Claude, GPT, DeepSeek и другие модели, разбираем роли агента, diff-патчи, правила проекта и нюансы работы с контекстом.

Сразу расставлю все точки над «и»: LLM полезны. Вопрос не в том, могут ли LLM писать код, они на это способны. Вопрос в том, почему вайб-кодинг может оказаться вашей худшей карьерной инвестицией.

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

До недавнего времени я по большей мере игнорировал этот ажиотаж. Я читал заголовки, время от времени просил Claude или ChatGPT помочь мне в отладке, но ничего больше. Пришла пора учиться вайб-кодингу!

Сергей давно интересуется домашней автоматизацией и любит разбираться в технологиях глубже, чем даже продвинутый пользователь. Несколько лет назад он собрал умный дом в предыдущей квартире на беспроводных устройствах: Zigbee-датчики, кнопки, один из популярных шлюзов. Он пробовал разные сценарии, экспериментировал с mesh-сетью. На практике система работала, но не всегда предсказуемо. Устройства периодически «отваливались», свет включался с задержкой, а работа сценариев зависела от интернета. Этот опыт закрепил мысль: надежную автоматизацию без проводов не построишь.

Когда семья купила новую трехкомнатную квартиру площадью 102 м², Сергей решил реализовать эту идею на практике. Он основательно переделал планировку: изменил геометрию комнат, выделил прачечную, оптимизировал два санузла, добавил зоны хранения. Параллельно он прорабатывал архитектуру умного дома. После неудачного опыта с беспроводными решениями он сделал упор на надежности и локальной логике, которая не зависит от интернета и облачных платформ.

Интегратор «Демос», к которому он обратился, предложил собрать систему на базе программируемого контроллера и модулей расширения.

В статье разберем, как устроена автоматика в этой квартире, какие сценарии заложил интегратор и какие со временем добавил сам Сергей, когда начал жить в умном доме каждый день.

С появлением AI-агентов разработка программного обеспечения изменилась кардинально. Я, как и многие разработчики, начал активно использовать Claude, Cursor и другие инструменты для автоматизации написания кода. Результаты поначалу впечатляли: за один вечер, занимаясь системным анализом, проектированием архитектуры и промпт-инжинирингом, я мог сгенерировать до 100 000 строк кода.

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

Проблемы начались не сразу. Первые несколько дней работа шла гладко: AI быстро генерировал код, тесты проходили, функциональность работала. Но затем, примерно через неделю-две активной разработки, я стал замечать тревожные симптомы.

Как можно Cursor IDE превратить в полноценную мультиагентную среду разработки, где каждый AI‑агент выполняет роль члена команды: аналитика, архитектора, планировщика или разработчика?

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

Как добиться сходимости к стабильному результату в ходе длительной самостоятельной работы команды ИИ-агентов?

Рассказываю, как я пришёл к таким результатам с помощью команды агентов под управлением оркестратора и применения принципа разрабокти «сверху вниз», когда код рождается постепенно, но осмысленно: от общей идеи до рабочего решения.

Помните старую поговорку про семь раз отмерь? В мире AI-кодинга она обрела новый смысл.

Сегодня расскажу о практике AI-Driven разработки (AIDD), которую мы у себя в команде ежедневно применяем для разработки ИИ-решений. Она успешно зарекомендовала себя в различных проектах и задачах — будь то стартапы или легаси, приложения на Python, Java или даже 1C.

Разбирать методику будем в AI редакторе Cursor, но повторить ее вы сможете в любом кодовом ассистенте. Поехали...

За последние 3 месяца я провел 200 часов за вайбкодингом и хочу поделиться мыслями, которые сэкономят вам нервы и время, если вы тоже решились заняться этим делом. Я буду рассматривать Cursor, но эти правила подойдут и для других аналогов

Как мы воскресили русский NLP и сократили потребление памяти на 90%

Форкнули четыре ключевых библиотеки русского NLP (pymorphy, razdel, slovnet, natasha), которые не обновлялись годами. Сократили потребление памяти на 90%, ускорили загрузку в 30 раз, повысили точность токенизации с 70% до 95%. Всё работает offline, 100% совместимо с оригинальными API. Экосистема MAWO — production-ready инструменты для работы с русским текстом.

Помните ли вы тот момент, когда открываешь проект для обработки русского текста и видишь знакомую картину? В requirements.txt красуется pymorphy2, последний коммит в репозитории датирован 2015 годом, Python 3.12 ругается на deprecated методы, а production ждать не будет. Знакомо? Тогда эта история для вас.

Мы ускорили релизный цикл в 2 раза за счёт жёсткого shift‑left: запретили писать и коммитить код без ранней проверки требований и автогенерации тестов ИИ. Рассказываем, как у нас это получилось и насколько выгоден такой подход компании.

Привет! Сегодня вам расскажу, как я полностью отказался от Google Photos и настроил своё собственное хранилище фотографий на базе Immich с кучей функций, не уступающих тем, что есть у популярных представителей данных сервисов.
Это не обзор ради обзора, а мой реальный кейс. У меня дома стоит свой собственный домашний сервер, который я собрал не так давно, куда я уже перенес все свои фотографии и видео.

Салют, Хабр! Я думаю, каждый из вас знаком или, по крайней мере, слышал о такой прекрасной утилите как NoDPI написанной на питоне (большое спасибо @Lord_of_Rings!). Сегодня я хочу представить вам (почти) свою разработку, не требующую ни питона ни прокси. Мы будем патчить прямо на диске библиотеку chrome.dll - входяющую в пакет Chrome на Windows и лежащую в директории "C:\Program Files\Google\Chrome\Application\140.0.7339.208\chrome.dll". Цифры могут меняться в зависимости от версии. Данный патч занимает всего 8 байт и после него у нас появится YouTube.

Python щедро раздаёт нам удобные абстракции. Создаёшь список, словарь или строку — и не думаешь, где под это выделилась память и как она потом освободится. Но внутри интерпретатора работает довольно сложный механизм, и он устроен не так, как в C или других языках.

Идея сделать приложение-визуализатор пришла после чтения книги CPython Internals. Там подробно объясняется, как устроены арены, пулы и блоки. Но пока читаешь текст, всё это воспринимается слишком абстрактно. Захотелось увидеть механику своими глазами: как память выделяется, как освобождается и почему иногда остаётся занята. Так и появился MemoryMonitorApp, а вместе с ним — эта статья.

IT-рынок в России и СНГ меняется очень быстро: появляются новые технологии, меняются зарплаты, одни профессии становятся востребованнее, другие — уходят на второй план. Чтобы понять, что происходит прямо сейчас, я решил взять данные напрямую с hh.ru и собрать аналитику в Power BI.

В период с 9 июля по 29 августа 2025 года удалось собрать и проанализировать 85 207 вакансий в сфере IT. В этой статье рассказываю, какие технологии на пике, как меняется спрос на специалистов, какие зарплаты предлагают и где сосредоточено больше всего вакансий.

Django - отличный фреймворк, но он, на самом деле, толком не дает, да и не должен давать, ответ на вопрос, каким образом лучше всего хранить вашу бизнес-логику. Хранение бизнес-логики в моделях или views имеет множество недостатков, которые обычно начинают проявляться при росте кодовой базы проекта. Чтобы решить эти проблемы, разработчики часто начинают искать способы выделения бизнес-логики в своем приложении.

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

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

На самом деле, изложенный далее текст относится не только к Django-проектам. Разрабатывая веб-приложения, используя другие инструменты, вроде Flask, люди используют те же концепции веб-разработки, причём часто именно в таком же виде, как они реализованы, в Django - views, request-response объекты, middlewares, модели, формы.

В прошлой статье я рассказал, как за год использования нейросетей сэкономил несколько миллионов рублей и получил результаты лучше, чем с командой разработчиков. В комментариях и личных сообщениях у меня спрашивали практические советы: как именно работать с ИИ, какие инструменты выбрать, с чего начать. Сегодня поделюсь практическим руководством — теми самыми приёмами и подходами, которые позволяют не просто поиграться с нейросетями, а создавать реальные продукты.

При выполнении параллельной программы, активно задействующей CPU, нам часто необходимо, чтобы пул потоков или процессов имел размер, сопоставимый с количеством ядер CPU на машине. Если потоков меньше, то вы будете использовать все преимущества ядер, если меньше, то программа начнёт работать медленнее, так как несколько потоков будет конкурировать за одно ядро. Ну, или такова ситуация в теории.

Как же проверить, сколько ядер есть у компьютера? И действительно ли это хороший совет?

Оказывается, на удивление сложно определить, сколько потоков выполнять:

- В стандартной библиотеке Python есть множество API для получения этой информации, но ни одного из них недостаточно.

- Хуже того, из-за таких функций CPU, как параллельность на уровне команд и одновременной многопоточности (Hyper-threading в CPU Intel), количество ядер, которое можно эффективно использовать, зависит от того кода, который напишете вы!

Давайте разберёмся, почему так сложно определить, сколько ядер CPU может использовать программа, а затем подумаем над потенциальным решением.

Привет, Хабр!

Я потихоньку перевожу статьи Маркуса Винанда из блога use the index luke.

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

Привет, Хабр!

Помните времена, когда «белый» IP-адрес был нормой, а не платной услугой? Когда для доступа к своему серверу хватало простого ssh user@ip_address? Я тоже помню. Но эта эпоха незаметно уходит.

Сегодня мы оказались в новой реальности. Ваша домашняя «Малинка» задыхается за провайдерским NAT, а облачный VPS в Европе кажется далеким и изолированным островом. Как получить доступ к первой или второй?

Эта статья — не очередной гайд по VLESS или Shadowsocks для обхода сложных блокировок. Это не "серебряная пуля" против DPI. Это честный гайд по постройке вашей личной, плоской и безопасной L2-сети поверх хаоса современного интернета. Мы соберем VPN-хаб, который не боится NAT, независимо от того, где он будет жить — на скромной «Малинке» дома или на арендованном VPS в другой стране. Мы разберем весь процесс по шагам, от регистрации до настройки полного туннеля, и честно поговорим о компромиссах этого решения.