Бэкенд

Профилирование Java‑приложений в production часто упирается не в отсутствие инструментов, а в их ограничения: CPU горит в одном месте, latency копится в другом, аллокации давят на GC, а lock contention вообще не виден в обычном CPU‑профиле.

В статье разбираем, как использовать async‑profiler для диагностики реальных Java‑сервисов: снимать CPU, allocation, wall‑clock и lock‑профили, читать flame graph и понимать, где именно приложение тратит ресурсы.

Рассказываю, как написал кроссплатформенную .NET-библиотеку для глобального перехвата клавиатуры и мыши. Под капотом: WH_KEYBOARD_LL на Windows, CGEventTap на macOS и polling через XQueryKeymap на Linux. Один интерфейс, три реализации, ноль внешних зависимостей.

Привет. В предыдущих статьях этого цикла мы разбирали, как Kubernetes-объекты читаются (первая — informer и кэш в controller-runtime) и записываются (вторая — Server-Side Apply, patch’и, managedFields). Сегодня — про их жизненный цикл.

Между kubectl apply и появлением объекта в etcd проходит целая цепочка: admission chain, мутирующие и валидирующие вебхуки, schema-валидация, встроенные плагины. Между kubectl delete и реальным исчезновением объекта может пройти от миллисекунд до часов — в зависимости от того, какие на нём финализаторы и какая стратегия каскадного удаления выбрана. Механизм при этом универсален для любого ресурса: Pod, Deployment, ваш CRD — жизненный цикл у всех один.

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

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

Как-то раз на одном из программистских форумов я наткнулся на интересную задачку. Интересна она была тем, что требовалось рекурсивное решение на Java. Мне захотелось разобраться…

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

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

«Смерть айтишной профессии» обсуждать не будем, ибо это тема для дум-скроллеров, поговорим про ИИ.

ИИ — потенциальный gamechanger

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

TL;DR. Один «безобидный» foo.GetAsync().Result в middleware способен превратить ASP.NET Core, державший 50k RPS с p99 = 40 мс, в сервис с 12k RPS и p99 = 4 с — при CPU 8 %.

Виноват не сам blocking call, а hill-climbing — фидбэк-луп в ThreadPool, в недрах которого живёт дискретное преобразование Фурье. Разбираем по исходникам CoreCLR, почему это вообще возможно, воспроизводим эффект на ~80 строках кода и разбираемся, почему SetMinThreads — не решение, а анестезия.

Когда я начал поднимать PostgreSQL через Docker для своих проектов, всё выглядело просто: описал сервис в docker-compose.yml, запустил контейнер - база доступна.

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

«Ты кнопкодав с многолетним опытом смузихлёбства» — примерно так сейчас звучит позиция рынка в адрес опытных разработчиков. Венчурные деньги уходят в AI-first, штаты сокращаются, джуны уверены, что знают лучше. Я руководил отделом из 30 человек и наблюдал это изнутри.

Это не нытьё про «раньше было лучше». Это попытка честно разобраться, что происходит с профессией — через личный эксперимент.

Статья о том, как получить наблюдаемость (observability) в приложении с минимальным кодом, а бонусом получить структурированные логи с типизированными шаблонами, автоматическую корреляцию со спанами OpenTelemetry, всё это с помощью набора библиотек, которые я называю CleverBrush Framework.

Как организовать шифрование на уровне протокола? На самом деле тема непростая и пожалуй (имхо) это как раз та самая тема, где прийти к компромиссу почти никогда не получается. Разве что просто не передавать чувствительные данные вовсе.

Я расскажу как шифрование можно организовать на уровне протокола brec и ни в коем случае не буду затрагивать те самые принципиальные решения, влияющие на безопасность (как передавать, куда передавать, отправлять ли, и хранить ли чувствительные данные вовсе). Иными словами нас интересует инструментальная сторона вопроса.

Каждый, кто программирует с агентами (Claude Code, Codex и т.д.), знает: перед тем как приступить к задаче, агент исследует проект. Это кажется логичным, естественным и закономерным, ведь люди делают так же. Обычно говорят: «агент наполняет контекст».

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

- задача определена в общем виде (кто знает, что имел в виду автор)
- пути исследования не детерминированы (в общем виде не используется специфика фреймворка)
- используются базовые инструменты (read, grep, cat, find)

В итоге при первичном исследовании легко столкнуться с ситуацией, когда основной контекст заполнен сведениями, слабо относящимися к исходной задаче.

В Anthropic быстро осознали эту проблему и вынесли всю описанную работу в Explore sub-agent. В результате основной agent ставит задачу промптом, Explore выбирает путь исследования, а результат формирует в виде отчета. Проблему чистоты основного контекста они, конечно, решили. Но что с качеством такого анализа?

Наблюдая за работой Explore и видя, как агент, используя «примитивные» инструменты, в агонии пытаясь отыскать недостающее или, наоборот, пропускает важные сведения о проекте, невольно ловишь себя на мысли: «Как так вышло, что последние 10 лет развития индустрии инструментов прошли мимо agent?» А может, это человечество свернуло не туда?

Ксения Прокофьева, руководитель отдела разработки C3D Converter, C3D Labs, рассказывает об обновлениях и перспективах развития модуля C3D Converter.

До недавнего времени модуль C3D Converter поддерживал только стандартные форматы обмена данными — SAT, STEP, Parasolid и пр. С 2020 г. началась активная работа с проприетарными форматами: изначально с использованием сторонних решений. А начиная с 2023 г. началось развитие собственных разработок (рис. 1).

В этой части собираем headless-слой для фронтов: Gateway, композицию API, SDK, ETag, SSR, идемпотентность и единые правила работы с запросами. 

Привет, хабровчане. Это снова Алиса, снова Laravel, Bitrix и попытка не превратить фронтенд в распределенный монолит. К этому моменту у нас уже есть быстрые доменные сервисы: каталог, корзина, цены, заказы, интеграции. Но фронту от этого не сильно легче. Ему все еще приходится ходить в десяток ручек, собирать ответы, следить за авторизацией и одинаково обрабатывать ошибки.

Поэтому поверх доменных сервисов появляется Headless API Gateway — тонкий слой, который работает как BFF для фронтов.

Он берет на себя JWT-cookie, CORS, rate-limit, кэширование, единый формат ошибок и композицию сценариев вроде листинга, карточки товара или чекаута. При этом Gateway не дублирует бизнес-логику. Его задача — валидировать входящие запросы, сходить в нужные сервисы, собрать ответ и вернуть фронту компактный JSON с ETag и нормальными HTTP-заголовками.

Дальше собираем это на Laravel: CORS, middleware для JWT-cookie, rate-limit, единый формат ошибок, композиционные ручки для фронтов, кэш-заголовки и роутинг через Nginx.

Если ваша CMS или CRM умеет отправлять email‑копию о новом заказе на произвольный адрес — этот гайд для вас. InSales, RetailCRM, МойСклад, WooCommerce, Битрикс, самописная система — без разницы. Инфраструктура одна и та же. Ссылка на гитхаб с полным мануалом по установке на русском в конце статьи.

Поводом написать стало то, что неделю назад приложение InSales было удалено из App Store и пуши о заказах пропали сразу. Таким образом мы пропустили несколько заказов, но благо они не сорвались полностью, хотя небольшой неприятный осадок остался.

Первая мысль при поиске решения — n8n или Make. Но зарубежные no‑code платформы сейчас работают в России нестабильно из‑за замедлений и блокировок трафика. Строить критическую бизнес‑инфраструктуру на том, что может лечь в любой момент — плохая идея.

Задача: автономная система, работающая внутри РФ, без постоянного сервера, с доставкой уведомлений в Telegram за секунды. Решение — Yandex Cloud Serverless, т.к он не боится блокировок, имеет очень щедрые лимиты, благодаря чему функция работает полностью бесплатно. К тому же сервис очень гибок в настройке и улучшении.

Расскажу, что получилось, и дам полный гайд по настройке.

Привет, Хабр! Меня зовут Никита, я являюсь разработчиком в направлении SSL инфраструктурной команды биллинга в Timeweb Cloud. Сегодня я хочу рассказать, как мы наводили порядок в коде одного из наших микросервисов, почему отказались от лапши в контроллерах, и главное — почему мы решили выложить наш внутренний архитектурный фреймворк в Open Source. Если вы пишете на Python и хоть раз сталкивались с болью распределенных транзакций, отваливающихся внешних API и проблемой dual-write (двойной записи) — присаживайтесь поудобнее. Речь пойдет про наш open-source фреймворк python-cqrs (он же доступен на PyPI).

Привет, Хабр! Меня зовут Александр, я Java-разработчик в GlowByte. Работаю в практике управления рисками и комплаенс (Risk & Compliance). Хочу поделиться своим опытом и в целом рассказать о том, чем мы здесь занимаемся. А занимаемся мы автоматизацией систем управления рисками – от AML (противодействие легализации доходов) и операционных рисков до коллекшна (взыскание просроченной задолженности) и систем принятия решений.

Моё направление – как раз последнее: системы принятия решений (СПР). Если коротко, мы автоматизируем стратегии, где нужно в реальном времени перерабатывать кучу входных параметров, учитывать множество факторов и выдавать сложные, комплексные решения. Типичные примеры: оценка риска, предстраховые проверки, системы мониторинга, расчет резервов, расчет комиссионных вознаграждений страховым агентам и многое другое.

Чем это интересно? На выходе – не просто «да/нет», а полноценное управляемое бизнес-правило, которое можно быстро менять без переписывания кода.

В этой статье хочу поделиться опытом разработки backend API на Spring Boot-проекте, где нам пришлось много работать с OpenAPI-спецификацией, динамическими запросами и тестированием бизнес-логики.

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

Если и у вас есть желание написать какую-нибудь сложную абстракцию «на будущее» или применить новый паттерн просто потому, что вы его выучили — остановитесь на секунду.

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

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

Пару дней назад я просматривал статьи в песочнице «Хабра» и наткнулся на статью парня от 2011 года, где с полным воодушевлением обсуждает открытие стартапа. После чего я открыл сайт, и он даже открылся (хотя если пробить информацию по налоговой базе, становится понятно, что какой-то коммерческой деятельности там уже давно нет). И это меня навело на мысль, что гараж, который строят за пару месяцев, стоит годами, а софт устаревает за несколько лет и уходит в небытие. У меня появился внутренний вопрос: «Стоят ли ваши усилия и профессионализм того, чтобы софт, написанный сегодня, ушёл в небытие через несколько лет?» Такой экзистенциальный вопрос профессионализма?