В Netflix тысячи Java-репозиториев. Когда в библиотеку вносят изменение, часть пользователей может перестать собираться или начать работать некорректно. Чаще всгео эта проблема возникает потому, что public контракты являются public только для авторов библиотеки, а не для пользователей.

С новом переводе от команды Spring АйО разбираемся, как ребята из Netflix ввели простые метки для API: @Public - можно использовать снаружи, @Experimental - тоже можно, но интерфейс может меняться, @Deprecated - готовится к удалению. Все остальное считается внутренним и использованию извне не подлежит. Но сами аннотации проблему не решают, нужна проверка на масштабе.

Решение - ArchUnit + Nebula ArchRules. 

ArchUnit анализирует скомпилированный байткод, поэтому одинаково работает для Java/Kotlin/Scala и проверяет реальный код на classpath. Команды пишут правила (например: «вне пакета библиотеки нельзя зависеть от ее deprecated/internal API»), публикуют их как отдельный arch-rules JAR, а runner автоматически запускает проверки в репозиториях и делает отчеты с точной строкой нарушения.

Покупая подписку ChatGPT за 20$, вы получаете возможность использовать токены на сумму ~1000$. Покупая подписку к Claude за 100$, вы получаете токенов на сумму ~2000$. Но подключить эти подписки напрямую в Cursor нельзя. Формат запросов в API и подписке отличаются. Вам нужен обходной путь — проксирование запросов.

Привет, Хаброжители! Добро пожаловать в будущее Java! Изучите главное новшество Java 21 — виртуальные потоки. Помните, как приходилось бороться с высокой стоимостью создания потоков, сталкиваться с ограничениями масштабируемости и трудностями при попытке достичь высокой пропускной способности? Те дни прошли! Это практическое руководство проведет вас от Java 1.0 до прорывных достижений Project Loom.

В четвертой части мы начали изучение задачи классификации и разобрали метод kNN.

Мы уже дошли до той точки, когда можем построить худо-бедно работающий классификатор. Но если нас спросят: “а насколько хорошо он работает?”,
то максимум, что мы пока сможем ответить — что-то вроде: “ну... на тестовой выборке модель правильно ответила в p% случаев”.

С одной стороны, как гласит древняя пословица: лучше иметь 500 рублей, чем 200. Но гарантирует ли высокий p% качество модели?

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

Как перестать копировать формы и построить масштабируемую архитектуру

В enterprise-приложениях формы множатся быстро: create, edit, import, create-from-lead, duplicate — и вот у вас уже шесть копий одной формы, а внутри условный ад из if (mode === …).

Почему mode prop и giant form component не масштабируются, как разделить форму на четыре слоя: presentation, orchestration, context, data source. Что такое capabilities и почему они лучше условной логики. Как адаптеры отвязывают форму от source entities. Куда прятать submit, валидацию и внешний store. Как тестировать такую архитектуру изолированно.

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

Недавно я купил умный дверной звонок на Temu, китайской торговой площадке, которая набирает популярность во всем мире в последние пару лет. Я хотел узнать, насколько безопасно дешёвое подключённое оборудование, продаваемое на этой платформе. Устройство поставляется под названием «Умный дверной звонок X3» и сопрягается через мобильное приложение под названием «X Smart Home». Камера, микрофон, двусторонняя аудиосвязь, внутренний приёмник в диапазоне ниже ГГц. Такое оборудование незаметно появилось на многих входных дверях.

В этой статье мы разберём реальную задачу на проектирование Maven Multi‑Module: от циклических зависимостей и неправильного использования spring‑boot‑maven‑plugin до смешения ролей агрегатора и родителя. Затем соберём эталонную структуру по лучшим практикам Spring Cloud и Netflix, добавим CI/CD‑диаграмму и научимся запускать сервис локально без Eureka и RabbitMQ.

Если описать NestJS-архитектуру как граф — вершины это модули и классы, рёбра — зависимости между ними, — утверждение «архитектура не деградирует» перестаёт быть оценочным. Формально доказывается, при каких условиях циклы между модулями топологически невозможны, при каких размер публичного API не растёт с каждой новой ручкой, и при каких стоимость добавления фичи остаётся константой, а не растёт с числом существующих потребителей. Три измеримых структурных свойства, а не ощущение. Для типовой feature-based-структуры, которую сегодня продвигают как стандарт, ни одно из них не выполняется.

Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна.

Часть 5 — финал серии. Архитектурный подход, при котором эти три свойства соблюдаются (Feature-Based Clean Architecture), нагружается тем же сценарием годового роста, под весом которого деградирует обычный feature-based: партнёрка, анти-фрод, рефералки, расширенная аналитика, утроение модуля пользователей. Без художественности: реальный код, граф зависимостей «до» и «после», и формальное доказательство трёх свойств — DAG-инвариант, граница связности, O(1)-стоимость инкремента — на языке теории графов. Точка, в которой «архитектура не деградирует» становится не похвалой, а конкретным структурным утверждением.

Если вы работаете с Claude Code на больших проектах, знаете картину: задаёшь вопрос “как устроена авторизация” — и агент рекурсивно бегает по файлам через grep, жжёт токены и время. Я уже разбирал SocratiCode, который решает это через векторный поиск. CodeGraph идёт другим путём — строит граф символов через tree-sitter и хранит в SQLite. Разобрал архитектуру, проверил бенчмарки (92% меньше вызовов — правда, но с нюансами) и сравнил с альтернативами. Заодно поправил телеграм-маркетинг про выдуманного “агента Hermes”.

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

21 мая 2026 года вышел мажорный релиз, переосмысляющий то, как платформа управляет жизненным циклом от идеи до деплоя.

Основной повесткой как уже принято стал ИИ, в Gitlab уделили этому особое внимание.
ИИ уже генерирует больше кода, чем успевают проверять инженеры. Merge Request'ы накапливаются, конфликты разрастаются, секреты утекают в переменные окружения, а зависимости с уязвимостями тихо живут в requirements.txt. GitLab 19.0 отвечает на этот вызов не просто набором фич, а сменой парадигмы: платформа берёт на себя операционную работу, оставляя командам только решения, требующие человеческого суждения.

Ниже я разберу релиз подробно, постараюсь описать примеры конфигурации, архитектурные схемы и дам выводы, таким образом как я это понял)

Собрали для вас подробный материал про DWH — корпоративное хранилище данных:

— что это такое и как работает КХД - простыми словами
— когда DWH действительно нужно и какие задачи решает
— как устроена архитектура DWH (LSA, A16Z, подходы к проектированию)
— как данные проходят путь от источников до дашбордов
— какие сложности чаще всего могут возникнуть при внедрении

Этот разбор DWH — от базовых понятий до архитектуры и стека — даст вам целостное понимание и поможет ответить на основные вопросы о хранилищах данных.

Когда мы пытаемся в одном бэкенде совместить и строгую бизнес-логику, и все «рюшечки» для фронта — получается монстр Франкенштейна. Это потому, что стабильная по своей природе бизнес-логика начинает дёргаться от каждой «косметической» правки в интерфейсе.

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

Рассказываю о том, что делать со всем этим безобразием...

Этот пародия, продолжение истории про Stopilot — инструмент‑противовес для Cursor и прочих AI‑assisted IDE, который не даёт писать код, пока разработчик не объяснит, что именно меняет, зачем, как откатить и кто будет это поддерживать.

После первого текста стало понятно, что Stopilot сделал то, чего обычно не делают инструменты против лишней активности: сам породил запрос на продолжение. Один технический директор сформулировал точнее всех: «Мы поставили Stopilot, и разработчики действительно стали писать меньше лишнего кода. Но теперь они стали больше обсуждать, почему они его не пишут. Можно как‑то остановить и это?»

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

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

Именно этого, как выяснилось, рынку не хватало.

Начинаете писать E2E-тесты? Думаете, нужно просто открыть страницу, нажать кнопку и написать expect?

Разберем на примере Playwright, почему отчёт может быть зелёным, но бесполезным.

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

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

Программирование — это редко про «написать кнопку». Чаще это попытка перевести хаос бизнес-процессов, привычек пользователей и странных требований в систему, которая должна работать стабильно. В статье — реальные истории из легаси, enterprise и автоматизации: DOS-мышление в вебе, Excel как основа бизнеса, реверс-инжиниринг без документации и почему иногда лучший аналитик — оператор с цифровым блоком клавиатуры.

Когда продакшен падает в три часа ночи, строка ERROR Something went wrong не помогает никому. В статье разбираем, почему привычные текстовые логи быстро превращаются в шум при реальной нагрузке, как перейти на structured logging, зачем каждому запросу нужен request_id и как настроить нормальные JSON‑логи в Python и Go без лишней инфраструктуры.

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

По данным SHRM, замена одного сотрудника обходится компании в 50–200% его годовой зарплаты. А 20% новых сотрудников уходят в первые 45 дней. Это не проблема найма. Это проблема адаптации новых сотрудников.

Хорошая новость: первые 30 дней сотрудника — управляемый процесс. Один из самых работающих подходов — геймификация онбординга. Не «давайте нарисуем бейджики», а настоящая игровая механика: прогресс, достижения, уровни. Всё это работает, потому что обращается к базовой нейробиологии мотивации.

Этот чек-лист онбординга — конкретный список действий с разбивкой по дням.