Программирование *

Осенью 2022-го мы добавляли в наш платёжный агрегатор новый способ оплаты: плательщик уходит по ссылке в приложение своего банка, подтверждает платёж там, а банк присылает нам нотификацию о результате. Песочница у банка была, формально. Отвечала статусами из позапрошлой версии протокола, а нотификации не присылала вообще; обещанные доработки ехали к нам дольше, чем наш дедлайн. Мы перестали ждать и написали двойника провайдера сами - по PDF со спекой, с тестом на каждый сценарий из документации. CI зелёный. Запускались осторожно, тремя волнами мерчантов: первые две прошли тихо. После третьей в саппорт пошли тикеты: у плательщика деньги списаны, у мерчанта платёж висит.

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

EA, Facebook, Google, Adobe, LLVM и рядок компаний поменьше тратят человеко-десятилетия в поисках ответа на главый вопрос жизни, Вселенной и всего такого «почему std:: это медленно, непредсказуемо и жрёт память». По аналогии с прошлой статьей вам не потребуется знать стандарт наизусть, а будет достаточно понимать, что такое указатель, чем вектор отличается от дерева и почему промах в кеше это дорого, а дальше я пройдусь по разным стандартным библиотекам и про каждую немного расскажу, что это, зачем оно появилось и где об него можно больно удариться, потому что про вот этот последний пункт обычно забывают "продаваны" и прочие студийные еванглелисты, когда расказывают какое там всё красивое, легкое и с++двадцатое.

Лямбды в C++ выглядят безобидно, пока не начинают жить дольше переменных, которые захватили. Висячие ссылки, мёртвый this, копии состояния в потоках и ограничения std::function часто проходят компиляцию без шума, зато потом превращаются в undefined behavior.

Разбираем пять задач на захваты и время жизни, где ошибка прячется не в синтаксисе, а в неверном предположении о том, кому и сколько живёт объект.

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

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

TL;DR. Я не пытаюсь сделать кодинг-агента самостоятельным разработчиком. Я задаю для него процесс: SPEC → PLAN → TEST → CODE → REVIEW → LEARN, артефакты на каждом шаге и человеческий accept там, где начинается ответственность. Эта статья — вход в серию про map-framework: хуки, контракты, контекст, память и всё, что я довёл из научных статей до рабочего процесса.

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

Читал ли ты мою предыдущую статью «Ох уж это многопоточное программирование»? Если да, то ты можешь со спокойной душой читать мою статью. Если же нет, то рекомендую сначала прочитать ту предыдущую статью, и уже потом приниматься за этот «десерт».

Привет, Хабр! Jetpack Compose в 2026 году стал стандартом разработки UI на Android, но в проектах регулярно повторяется одна и та же история: на экране со списком в пару сотен элементов прокрутка идёт рывками, профайлер показывает скачки кадров до 200 миллисекунд, а команда чешет голову и предлагает откатиться обратно на RecyclerView.

Проблема почти всегда не в Compose, а в том, как написан UI: recomposition спроектирован как дешёвая операция, но эта дешевизна работает только при соблюдении ряда правил, которые в документации описаны рассыпанно и часто игнорируются.

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

Context7 — мой дефолтный источник свежих доков для агента уже полтора года. И всё устраивало, пока я не начал ловить устаревший код: старый z.string().email() вместо z.email(), поведение Next 15 вместо 16. Причина — упёрся в потолок free-тарифа: квота исчерпана, сервер молча отдаёт пусто, агент спокойно пишет по памяти. И замечаешь это не сразу — вот что бесит. Тут я и задумался: Context7 вообще всё ещё лучший вариант, или за полтора года появилось что-то лучше? Решил проверить системно. Не поверил цифрам с лендингов и прогнал 8 способов доставки доков в контекст на одном токенайзере: что реально влетает в окно, за сколько токенов, с какой точностью. Победил Ref — но он платный. А ещё дважды я чуть не записал инструмент в аутсайдеры, и оба раза виноват был мой собственный вызов, а не инструмент. В итоге собрал бесплатную связку: локальный @neuledge как основной слой + Context7 free как fallback. Локальный слой отвечает за миллисекунды вместо секунд, работает без сети и без лимитов запросов. Осталось проверить, переживёт ли связка квоту free-тарифа — замерил и это. Внутри: методология, таблицы, два разоблачённых near-miss и миграционный кит для агента в подарок.

Привет, Хабр! На связи Smart Engines. Недавно мы провели открытый диалог с Егором Карасевым, первым заместителем Председателя Правления РНКО «Металлург», и обсудили наше сотрудничество длиной в 10 лет. Все это время компания использует технологии Smart Engines для распознавания паспортов клиентов в отделениях. Получился разговор не столько об OCR, сколько о том, как автоматизация меняет потоковое обслуживание, снижает нагрузку на сотрудников и помогает бизнесу не терять клиентов из-за ручного ввода данных.

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

Привет, Друзья!

На связи Михаил Поливаха, технический лидер проекта Axelix.

В рамках программы Hibernate в Spring АйО Academy мы краем обсудили тему, касаемую того, что @OneToOne отличается от других отношений. В частности, Hibernate может спокойно грузить его Eagerly, даже если вы явно поставите FetchType.LAZY. У парней был закономерный вопрос - почему?

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

Иными словами, я в статье постараюсь детально пояснить:

Что на самом деле такое FetchType.LAZY?

Почему @OneToOne не всегда возможно сделать Lazy именно в Java?

Почему при этом @ManyToOne можно сделать Lazy всегда (предполагая не final класс сущности)?

Разберём по шагам.

Привет, Хабр! Мне грустно читать посты о том, как руководители давят на сотрудников по ускорению интеграции AI в рабочие процессы и ставят строгие KPI.

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

Знакомо? Не переживайте, мы всё обязательно рассмотрим. К середине статьи мы научимся всем современным основам Claude Code, а к концу построим мультиагентную систему на очень интересном примере.

AI‑агенту не нужен прямой доступ к базе, чтобы отвечать на вопросы оператора или вызывать действия в системе. Достаточно дать ему набор управляемых инструментов через MCP.

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

Привет, хабровчане! Я Алиса — тимлид в e-commerce агентстве KISLOROD.

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

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

Я Дмитрий, iOS-разработчик из команды Салют — мы делаем устройства и программное обеспечение для Умного дома Сбер. У нас много собственных устройств и ещё больше устройств брендов-партнёров, которые поддерживает платформа. Релизный круговорот фичей и интеграций заставляет думать: как оптимизировать процесс доставки новых функций пользователям?

В статье расскажу про опыт разработки, внедрения и поддержки нашей собственной backend-driven UI парадигмы (BDUI) — подхода, в котором сервер управляет не только данными, но и вёрсткой интерфейсов.

Пока индустрия ждала планового релиза, OpenAI, похоже, втихую запустила A/B-тестирование GPT-5.6 Pro для части пользователей. Никаких анонсов, только внезапно возросшее время генерации (до 20-40 минут) и результаты, которые заставляют переосмыслить возможности LLM. Как насчет полностью функционального симулятора жизни со сложным стейт-менеджментом, NPC и системой профессий, сгенерированного в одном HTML-файле без использования IDE и сторонних фреймворков? Спойлер: модель теперь понимает не только код, но и физику 3D-пространства.

Любой инструмент для «понимания кода», которым я пользовался, рано или поздно упирался в одну из двух стен.

Первая — цикл «grep → открыть → прочитать → перейти по импорту → снова grep». Работает, но медленно, и у него нет ни малейшего представления о том, что process_order, найденный в services.py — это тот самый process_order, который вызывается из api.py, а не однофамилец из tests/. Когда этим занимается LLM-агент, он ещё и сжигает на этом тонну токенов.

Вторая стена — моноязычность. Инструмент прекрасно понимает Python, но слепнет в ту секунду, когда фронтенд на TypeScript дёргает ручку FastAPI на Python. Реальные системы полиглотны. Инструменты вокруг них — обычно нет.

graphlens — это open-source фреймворк (MIT), который спроектирован так, чтобы обойти обе стены. Он парсит исходный проект, нормализует его структуру в общий граф-IR и отдаёт этот граф вам — делайте с ним что хотите: анализ зависимостей, навигацию, поиск мёртвого кода или подачу точных ответов LLM-агенту вместо вываливания файлов в контекст.

Проверил реализацию Boyer-Moore в TheAlgorithms/Python (190K+ звёзд). Оказалось, что сдвиг bad character записывается в переменную for-цикла, что в Python не имеет эффекта. Алгоритм выдаёт правильные результаты, но работает как brute-force O(nm) вместо O(n/m). Плюс ещё две находки: бесконечный цикл в типичных реализациях full BM и ошибка в оригинальной статье 1977 года, которую исправили только в 1980-м.

Мы уже разобрались с тем, что такое BaaS, почему появились Firebase и Supabase, чем они отличаются от обычного backend и можно ли самому собрать что-то похожее.

Как я и говорил в прошлой статье, сегодня мы наконец попробуем самостоятельно собрать альтернативу Firebase с Realtime исключительно на open-source компонентах!

Но важная оговорка: мы не будем делать полный клон Firebase с его тонной функционала, но мы соберем минимальную рабочую альтернативу, которую уже можно подключить к frontend через SDK и использовать почти как Firebase.

Сколько лекций по карате нужно прослушать, чтобы уверенно противостоять нескольким хулиганам в тёмном переулке? Звучит нелепо, правда? Тогда сколько лекций по информатике нужно прослушать, чтобы научиться пользоваться компьютером? Компьютером в широком смысле — аппаратной частью, существующими программами и создавать свои программы под конкретные задачи. И может оказаться, что информатика не учит программировать, особенно если студента или учащегося не готовят именно как программиста. А ведь всё могло бы быть иначе.

Привет! Продолжаю разбирать классические задачи с System Design интервью на стримах (за анонсами можете следить тут https://t.me/siliconchannel), а это текстовая версия стрима. В прошлый раз была бесконечная лента, сегодня очередная классика жанра - веб-краулер. Условие звучит примерно так: