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

Эта статья прежде всего будет полезна студентам и начинающим специалистам.

В отрасли разработки программного обеспечения под системным дизайном (System Design) понимают процесс проектирования архитектуры, компонентов, баз данных и связей информационной системы. Цель системного дизайна - обеспечить масштабируемость, отказоустойчивость и высокую производительность системы, в том числе при росте нагрузки. 

В первой статье по этой теме https://habr.com/ru/articles/1054184/ я рассказывал про принципы декомпозиции программной системы на модули и слои программных компонентов на примере задачи разработки бэкенда корпоративных чатов, рассмотрел пример реализации модуля идентификации и аутентификации пользователей на языке программирования Go.

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

Я Go-разработчик, но у меня есть собственный проект — и это значит, что Go только часть работы. В обычную неделю я переключаюсь между Go-бэкендом, SQL, React и TypeScript, дизайном API, архитектурой, Docker, CI/CD, инфраструктурой, тестами и UX.

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

AI помогает. И примерно здесь у всех начинается один и тот же спор: Claude или Codex? Кто лучше пишет код, за какую подписку платить.

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

задача → нейросеть сама придумала → сама написала → сама себя проверила → сказала, что всё готово

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

Поэтому я перестал выбирать и развёл роли: Claude принимает решения. Codex реализует. Claude независимо проверяет результат.

Это дало три вещи, а не одну:

Я дал модели (в codex) возможность самостоятельно решать, когда нужен compact, и обязал её объяснять причину и строить план на будущее.

Зачем? компакт посреди правки большого связного куска проекта вызывает некие сомнения.

Теперь перед большой фазой агент проверяет остаток контекстного окна. Если планируемая работа не помещается, он сохраняет checkpoint с инфой о том, что делается и планируется после компакта, сжимает свой контекст. Очнувшись читает чекпоинт, перепроверяет состояние репозитория и продолжает работу по намеченному плану.

Вроде бы интересно, но выводов пока нет.

Потестить можно тут https://github.com/z0rgoyok/codex-luna-kit (придется патчить кодекс, но это не страшно)

При обучении графных нейросетей и гигантских эмбеддингов на миллионы узлов стандартный torch.optim.SparseAdam в PyTorch моментально забивает RAM и VRAM, вызывая ошибку CUDA out of memory (OOM). В этой статье разбираем, как устроена легковесная Open Source библиотека Disk Sparse Adam (DSA), которая выносит состояния моментов на диск через memory mapping (mmap) и позволяет обучать огромные спарс-модели на обычной домашней видеокарте.

Победить Hibernate в тестах. Сможем?

Всем, привет! На связи Михаил Поливаха, технический лидер Open Source проекта Axelix (проект, посвященный помочь вам идентифицировать частые проблемы в Java server-side приложениях, в т.ч в рамках работы с Hibernate).

Данная, последняя статья является продолжением небольшой серии статей ответов на вопросы, которые возникли у участников Spring АйО Академии в рамках программы Hibernate. Я рассмотрю оставшиеся последние вопросы, а именно:

“Можно ли в тестах как-то проверить, что Hibernate под капотом делает что-то страшное?”

Тут очень важно не давать вам “рыбу”, а научить вас рыбачить, т.е. дать вам некоторый фреймворк о том, что стоит держать в уме при работе с Hibernate.

У меня всегда крутится несколько Claude Code. Вчера заметил странное: два агента, работавшие над одной проблемой, сами обменялись сообщениями через сокет uds:/tmp/cc-socks/769334.sock. Раньше такого не было.

Оказалось, в 2.1.224 появился cross-session SendMessage: разные сессии находят друг друга через ListAgents и пишут друг другу напрямую. А в 2.1.225 это заработало и между машинами при включённом remote control. Сейчас 90 процентов работы у меня делает один универсальный агент с огромным контекстом — и вот теперь наконец можно собрать поверх нескольких полноценных Claude Code отдельного координатора.

«Планируйте задачу с достаточным контекстом» — совет, который есть в каждой статье про агентов. Я споткнулся об одно слово: достаточным — это сколько?

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

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

Меня зовут Артур Валиев. Я открыл исходники EvertyDesk Lite — и заодно EvertyDesk Next, то, что должно было стать следующей версией. Полностью. Без купюр.

Вызов инструмента ИИ-агентом легко теряется между моделью, MCP-клиентом, сервером и внешним API. В конце июля сразу два события показали, каким способом индустрия собирается решать эту проблему. Новая спецификация MCP закрепила передачу W3C Trace Context и начала выводить собственный механизм логирования из протокола в пользу OpenTelemetry. Одновременно сообщество OpenTelemetry назвало наблюдаемость ИИ-агентов одним из следующих направлений развития проекта. Разбираемся, что уже стало частью стандартов, что пока остаётся дорожной картой и почему эти события стоит рассматривать вместе.

Этот материал навеян типичными требованиями к агентным Python-инженерам - теми списками требований к вакансии, где рядом стоят всякие PydanticAI/CrewAI/Langraph, MCP/A2A, фреймворки, оценки, векторные базы и тому подобное. Ну мне вот такое попадается, например, и заметил я, что большинство кандидатов люто плавают в этих вопросах. И даже перспективы перейти к физическому труду в обозримом будущем не мотивируют оных слегка прокачать нужные навыки - тем более что много-то и не нужно. Конечно, есть категория гениев, которая чаще всего встречается в анонимных комментариях на хабре, но я-то про обычных земных людей, с которыми встречаюсь на этой грешной земле, и на которых этот материал прежде всего и рассчитан. Так что, дорогой ноунейм, этот материал поможет тебе пройти интервью, и надеюсь, постоловаться еще какое-то время в наши скудные времена.

Ну и не забываем: все течет и меняется нынче быстро - так что и эти тезисы устареют скоро.

В мае на конференциях C++ Russia и HolyJS мы предложили участникам оценить технологии, инструменты и инженерные практики, с которыми они работают или за которыми следят. Так появились данные для двух технических радаров: по экосистеме C++ и по JavaScript.

Сырые цифры сами по себе рассказывают немного, поэтому мы отдали результаты на разбор эксперту. Виктор Новиков, руководитель группы разработки в «Лаборатории Касперского», посмотрел на распределения голосов и поделился своим мнением, почему CMake уверенно побеждает, а PostgreSQL раскалывает аудиторию пополам. В этой статье — его анализ C++-части исследования. Про техрадар JavaScript мы расскажем в другой статье.

Посмотреть радар и принять участие в голосовании можно на странице проекта.

На днях на Хабре вышла статья с разбором Яндекс Браузера и приложения Яндекс для Android. Автор сделал несколько выводов о работе приложений на основе анализа кода.

Часть наблюдений в статье действительно описывает существующие механизмы, однако их назначение интерпретируется неверно. Во многих случаях речь идёт не о специфике Яндекса, а о стандартных механизмах Android, Chromium, работе современных голосовых помощников или платёжных SDK.

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

Сразу оговоримся: автор не указал версии приложений, которые анализировал, поэтому в точности воспроизвести его опыт невозможно. Для разбора мы использовали актуальные версии Яндекс Браузера и приложения Яндекс из Google Play. Все описанные ниже механизмы можно проверить самостоятельно.

Привет, Хабр! Меня зовут Артём Трофимов, я работаю backend-разработчиком в компании «Юзтех». Последние 5 лет я занимаюсь разработкой backend-сервисов на Golang, и мне регулярно приходится работать с микросервисами, общающимися по gRPC.

Статья будет полезна backend-разработчикам, которые выбирают RPC-фреймворк для нового проекта, а также тем, кто уже работает с gRPC.

Для многих gRPC стал стандартом межсервисного взаимодействия: быстрый, строго типизированный, с кодогенерацией. Про его неудобства тоже все знают: сложность отладки, танцы с прокси, отдельная инфраструктура для браузерных клиентов. Всё это принято считать платой за производительность. Но в последние годы у gRPC появился конкурент, который утверждает, что платить больше необязательно. Речь, конечно, про ConnectRPC. Это проект компании Buf, уже принятый в CNCF (Cloud Native Computing Foundation).

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

Почему gRPC стал стандартом

gRPC представляет собой RPC-фреймворк (Remote Procedure Call, удалённый вызов процедур), созданный Google и переданный в CNCF в 2017 году. Его популярность держится на нескольких китах:

Мы знаем, что сегодняшние большие языковые модели основаны на архитектуре transformer, а самое важное понятие в трансформере это механизм attention.

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

Сегодня вы узнаете об одном из самых важных понятий в современном ИИ — о KV cache.

Всем привет! 👋👋👋👋👋 Мы — Java-разработчики Т-Банка: Андрей, Арсений, Роман, Константин и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся этим со всем сообществом.

Июль получился плотным. Valhalla после 12 лет разработки залили в master-ветку JDK одним PR на 2900 коммитов, Oracle сломал двадцатилетнюю традицию квартальных патчей и перешел на ежемесячные, а про саму Java наконец сняли полнометражный документальный фильм. Собрали все в нашем дайджесте.

Swift — язык, на котором пишут приложения для iPhone и Mac. Apple II — 8-битный компьютер 1977 года с процессором на 1 МГц, где под всю вашу программу остаётся ровно 40 704 байта. Автор оригинала соединил эти два полюса и собрал SwiftII: работающее подмножество Swift, которое компилируется в байткод и исполняется виртуальной машиной прямо на «яблочной» восьмибитке — по той же идее, по которой в 1979-м на Apple II приносили Pascal. В первой части — как устроены язык, однопроходный компилятор и байткод и на какие жертвы пришлось пойти, чтобы код всё ещё читался как Swift.

Меня зовут Антон Омельяненко, я Head of Software Development в EXANTE. Менеджер управляет командой так, чтобы она приносила бизнесу результат. Чтобы понимать, насколько хорошо люди справляются с задачами, ему нужны данные о работе и система оценки. С разработкой это сложнее, чем кажется.

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

Разбираемся с Kotlin Corouitines - какие идеи заложены и чем отличается CoroutineContext от CoroutineScope

Продолжение цикла статей "что такое RPG и как с ним работать.

Предыдущие статьи
Современный RPG — что может и зачем нужен
Способы работы с БД DB2 в языке RPG на платформе IBM i

Данная статья содержит обзор графического фреймворка “Арго”, предназначенного для быстрой разработки полноценного пользовательского интерфейса для управления приложениями. Это кроссплатформенное решение, которое может работать на различных операционных системах и аппаратных платформах, и, прежде всего, на устройствах в условиях очень ограниченных ресурсов по быстродействию процессора и оперативной памяти. Это полностью отечественная разработка, практически независимая от зарубежных продуктов и Open Source разработок.