Бэкенд

Почитал у известного чела о пост-условиях (“посткондишнс”) на свифте - и знаете, раст все равно лучше. Тупо приятнее язык даже для создания торговой биржи со своей мудреной бизнес-логикой - тикерами, логикой стопов и лимитных ордеров, многопоточностью, паттерн матчингом, децентрализованной сетью, графиками, распределениями парето, гаусса, стьюдента. Не трогая деревативов и разницу форвард/фьючерс, есть “аск” и “бид”, три вида ордеров, тикеры, взлеты и падения, вискарь-тревоги-роботы - короче, что нужно сделаем (кроме роботов), а для всего остального мастер кард (или МИР, а для европейцев “е-ц” карты).

Простейшая реализаций биржы (тикера) складывается всего из двух куч (binary heap) или двух стаканов: “аск” (продажа) и “бид” (покупка), и следствием их пересечения является сделка. Кто-либо создает ордер на покупку, указывая количество, и ордер исполняется мгновенно по верхней цене в стакане. Если хочется купить дешевле, создается лимитный ордер с указанием цены, а сделка ожидает продавца, согласного продать вам по указанной цене. С точки зрения реализации нет особой разницы между “asap” и лимитными ордерами. Чуть сложнее стопы.

Микросервисы обещают масштабирование и независимость команд, но чаще ломают систему медленнее монолита. Почему?

В статье разбираем семь архитектурных ошибок, которые можно встретить в реальных системах: выбор по моде, shared database, игнорирование network latency, операционная сложность на потом, слишком мелкая декомпозиция, отсутствие стратегии consistency, недооценка сроков миграции.

Классическая проблема аналитических систем: кластер СУБД сайзится под пик, а 28 дней в месяц он задействован чуть больше чем наполовину. StarRocks (shared-data) и автоскейл Kubernetes убирают этот избыток. Compute добавляется под нагрузку и сворачивается на спаде. Внутри легкая пятничная статья: как это работает и где у эластичности потолок.

Меня зовут Даниил. Я разработчик интеграций — до этого Kafka, REST, highload. В 2024–2025 мне первый раз поставили задачу, которую HR называет по‑разному: AI automation, n8n integrator, applied AI engineer. Я называю это AI‑интегратор: человек, который собирает бизнес‑процесс из событий, API и LLM — в основном без классического релиза, на no‑code/low‑code оркестраторе.

Я не ML‑инженер. Я не prompt‑инженер в вакууме. Я впервые поднял и довёл до рабочего состояния self‑hosted n8n с LLM внутри pipeline: событие приходит → модель что‑то понимает → данные улетают в Google Sheets, Telegram, amoCRM / Bitrix24.

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

Для достижения требуемого уровня производительности применяется масштабирование. Его принято разделять на два основных подхода: вертикальное масштабирование, при котором увеличиваются вычислительные ресурсы отдельных узлов, и горизонтальное масштабирование, предполагающее добавление в систему дополнительных сервисов, обслуживающих запросы. Однако независимо от выбранного подхода сетевой уровень остаётся критическим фактором, влияющим на производительность. Это связано с тем, что сетевую часть невозможно масштабировать столь же гибко, как остальные компоненты системы.

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

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

Оказывается, документация Claude Code рассказывает не всё. Стоило только лишь заглянуть в исходники. И вот что можно настроить, но чего нет в доке:

— hooks, которые переписывают команды на лету;
— автоодобрение safe-команд без лишних подтверждений;
— постоянная память агентов между сессиями;
— auto-mode, который понимает описание окружения на обычном английском;
— самообучающиеся циклы памяти и «снов»;
— скрытые поля skills, agents и permissions, которых нет в документации.

И все это работает уже сейчас, а исходники Claude Code лежат у вас в node_modules. Мы собрали все в статью. Там больше конкретики, JSON-конфигов, shell-хуков и примеров, которые можно утащить себе почти без правок.

По данным зарплатного калькулятора Хабр Карьеры, медианная зарплата тимлида-разработчика — 424 тысячи рублей, а лида DevOps — 461 тысяча рублей. 

Управленческий трек в IT — один из самых доходных в российской экономике. При этом переход от специалиста к руководителю довольно сложный. Это не просто повышение, а смена профессии — из исполнителя в управленцы.

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

GitHub постепенно превращается в кладбище старого кода. Мы сравнили тысячи репозиториев и посмотрели, какие языки быстрее теряют активность, а где экосистема всё ещё растёт.

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

Привет, Хабр! Меня зовут Иван Воробьев,  я работаю в команде рекомендаций VK Видео, AI VK. В данной статье хочу рассказать, как и зачем я переделывал систему построения I2I-рекомендаций. Поговорим о том, какие решения были поставлены в её основу, насколько они оправдались, а также причём тут якори и как они связаны со свежестью рекомендаций. 

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

Если честно, то лично я считаю, что это не просто «альтернатива», а предпочтительный выбор по умолчанию для большинства API (где конфигурация — это именно данные).

По большому счёту, паттерн Resolvable Config Struct просто наводит порядок в тех структурах Config и Options, которыми мы все пользуемся на порядок-два чаще, чем Functional Options. Чтобы его внедрить понадобится лишь минимальный рефакторинг, потому что всеми элементами этого паттерна мы и так постоянно пользуемся, просто сейчас там бардак, в который нужно добавить немного строгости чтобы стало намного лучше.

Мой поинт не в том, что Functional Options были ошибкой. Скорее это был разумный ответ на плохие конструкторы и наивные Config-структуры образца «просто положим всё в поля и как-нибудь разберёмся». Но сегодня есть решение получше, и его стоит внедрять.

Cilium работает в сетевом пути уровня ядра в миллионах Kubernetes-pod'ов: от облачных провайдеров до собственных кластеров банков и телекомов. Если бы кто-то скомпрометировал сборочный пайплайн Cilium, зона поражения была бы сопоставима с инцидентом SolarWinds, но в облачно-нативной экосистеме. Поэтому подход проекта к безопасности CI/CD интересен не только мейнтейнерам других опенсорс-проектов: те же паттерны полезны любой команде, которая собирает прод-артефакты в GitHub Actions. Команда VK Cloud перевела статью с конкретными YAML-конфигами, дизайн-решениями и честным списком того, что у Cilium пока не сделано.

AI-агенты умеют искать по Obsidian-хранилищу, но делают это слишком топорно через glob и grep. Да, для кода эти инструменты работают потрясающе, но хранилище в Obsidian не имеет такой же высокой структурированности. Искать по нему чисто лексически – значит терять инсайты, которые связаны по смыслу.

Чтобы решить эту проблему, я разработал Obsidian Hybrid Search – MCP-сервер и CLI, которые дают агенту мощный поисковый движок поверх заметок.

GitHub + Obsidian Plugin

Когда я впервые увидел backtrace паники в Rust, я решил, что это просто аналог исключения. Вызвал panic!, стек раскрутился, деструкторы вызвались, поток умер. Примерно как throw в C++ или raise в Python. Потом я попытался передать панику через FFI-границу, и программа молча упала без backtrace. Потом обнаружил, что catch_unwind перестаёт работать, если в Cargo.toml поменять panic = "unwind" на panic = "abort". Потом выяснил, что двойная паника (когда деструктор паникует во время раскрутки) убивает процесс безусловно, и это не баг, а так задумано.

Оказалось, что за простым panic!("oops") стоит сложная система из сменных runtime-ов, платформозависимой раскрутки стека и кучи граничных случаев...

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

Последние полгода я активно применяю LLM в своей работе. Автокомплитом от Github Copilot я пользуюсь с момента начала бесплатного бета-тестирования, а с выходом Opus 4.5 стало возможно отдавать железяке на реализацию целые блоки логики. Нужно только организовать виртуальную клетку, внутри которой он будет вынужден писать работающий код.

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

Здравствуйте, уважаемые читатели Хабра!

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

Профилирование 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-схемы.