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

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

Воодушевившись статьёй std::expected в C++23: гайд по миграции с исключений на функциональный error handling, представляю собственную с переписанными примерами на Rust. Код в статье итеративно переписывается и улучшается.

Когда проект растёт, дольше всего начинают тянуться самые «тяжёлые» проверки – UI-тесты. Один-два модуля поменял, а CI всё равно гоняет сотни тестов на эмуляторах и ждёт их десятки, а то и сотни минут. Знакомо?

Это третья, финальная статья цикла о том, как мы в Циане перешли от полного прогона всех проверок к выборочному с помощью Impact-анализа. В первой части я показывал, как мы ускорили статические анализаторы, во второй — как в два раза сократили unit-тесты, научившись обходить граф Gradle-модулей. В заключительной части я расскажу, как у нас на проде реализован выборочный запуск UI-тестов.

sizeof(Mutex<()>) в Rust 1.61 на Linux был 40 байт. В Rust 1.62 он стал 5 (точнее, 8 с учётом выравнивания, но базовый overhead 5).

За уменьшением размера в восемь раз стоит полная переписка стандартного Mutex с pthread на futex напрямую, ускорение uncontended locks в 2-3 раза, и десятилетие, которое стандартный Mutex провёл в роли «возьми parking_lot, std::sync::Mutex медленный».

Сегодня заглянем под капот всей этой темы, разберём, что лежит внутри std::sync::Mutex после 1.62, какой алгоритм там используется, почему он на самом деле быстрее pthread, как устроен fairness (точнее, его отсутствие), зачем нужен poisoning, и в каких случаях parking_lot всё ещё имеет смысл тащить в зависимости. Заодно вернёмся к моей старой async-статье и поясним конкретнее, почему в async-задачах std::sync::Mutex это проблема, и при чём тут вообще futex.

Привет, Хабр! Меня зовут Никита, и я один из тех, кто каждый год делает Frontend CTF в рамках конференции «Я 💛 Фронтенд». Сегодня хочу с вами поделиться, как и зачем мы ежегодно делаем соревнование для тех, кто любит пробираться сквозь загадки, секреты и спрятанные подсказки в браузерной игре.

Вайб-кодинг, или AI-assisted development, отлично работает на уровне прототипа: агент получает текстовое ТЗ и быстро собирает первый рабочий вариант. Но в корпоративной разработке этого мало.

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

В какой-то момент мы задались вопросом: можно ли научить ИИ-агента проходить этот путь самостоятельно? Можно, если собрать вокруг него харнесс (англ. harness). Именно о нем статья.

В Джеймикс мы строим этот мост как инженерный харнесс: набор скиллов, инструментов и проверок, который помогает довести работающий прототип до реально работающей системы. Для его строительства мы используем агентную платформу KodaCode (далее — Koda) в собственной разработке на Джеймикс и регулярно гоняем ее на бенчмарках. Если оценивать по делу, Jmix-задачи агент решает уверенно. Разброс от сессии к сессии есть, мы видим его в собственных прогонах, и строгие pass/fail-бенчмарки его даже преувеличивают. Поэтому ставка не на идеального агента: обвязка и контроль не дают этому разбросу попасть в ваш продакшен. Это SKILLS.md под Джеймикс, преднастроенные инструменты и проверки на выходе. 

Ниже разберем шесть составляющих такого харнесса. Мы собрали их в KodaCode для Jmix-проектов: пакет навыков, преднастроенные инструменты и проверки на выходе. Это можно собрать самостоятельно, но на практике такой путь занимает месяцы проб и ошибок.

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

Я не любитель кликбейтных заголовков, но понимаю, почему редакторам они так нравятся. Заголовок статьи, строго говоря, совершенно правдив, но, наверно, не в том смысле, в котором вы бы ожидали. Обфусцированный код на самом деле оказался пасхалкой, он распространяется в магазинах Uniqlo в рамках кампании Peace for All на замечательных футболках, дизайн которых разработала Akamai.

В работе с AI‑кодерами постепенно меняется формат задачи. Одного промпта часто недостаточно: агенту нужно не только выполнить разовую команду, но и повторять действия до понятного результата. Например: проверить CI, прочитать лог, внести минимальное исправление, снова запустить тест, остановиться при выполнении условий.

Поводом для этой статьи стала заметка Anthropic «Getting started with loops» про циклы (loops) в Claude Code. Там термин«цикл» описывается как повторяющаяся работа агента до выполнения условия остановки.

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

Эта статья - ответ на статью про CLA в открытом коде, изначально записанный в виде комментария.

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

6 июля OpenAI выпустил gpt-realtime — движок «речь в речь», который говорит как человек и держит перебивание. Я делаю голосового ИИ-приёмщика для бизнеса на российском стеке и занервничал: не устарел ли мой подход?

За вечер собрал прототип на OpenAI, откопал, что у Яндекса есть свой Realtime, и замерил задержку у всех трёх подходов одним методом. Цифры честные, с оговоркой про VPN: Яндекс Realtime ~330 мс, OpenAI ~740 мс (под VPN — иначе в РФ никак), старая трёхзвенка ~4,4 секунды.

В статье — грабли обоих движков (400-й эндпоинт у OpenAI, три роли доступа и закрытый обмен OAuth→IAM у Яндекса), почему у OpenAI не лечится акцент в русском, и как я за вечер переписал свой прод на Яндекс Realtime: WebSocket-мост, живой PCM-плеер вместо MP3, перебивание без наушников. С кодом и реальными замерами.

Приветствую!

В этой части мы рассмотрим что такое guard variables и как под капотом работают синглтоны Майерса.

И так, стандарт начиная с С++11 гарантирует нам что локальные статические переменные инициализируются потокобезопасно. Но кто и как это обеспечивает? Это делает ABI.

И все таки о чем же идет речь? Представьте себе что есть вот такая структура:

Хабр, привет! Меня зовут Илья Благородов, я занимаюсь разработкой уже более 30 лет, а ещё я — один из экспертов онлайн-магистратуры «Фронтенд-, бэкенд-разработка и ИИ-решения» ИТМО в партнёрстве с Яндекс Практикумом. Сегодня хочу поговорить о том, как правильно выбирать инструменты для разработки, почему разбираться в разных инструментах — не равно уметь их правильно применять и что с этим делать.

Мы сильно улучшили нашего агента в этом релизе и прокачали нашу топовую модель Koda pro в основе которой GLM 5.2. В момент первого запуска в нашем плагине даже не было режима «Агент», а сейчас он стал для нас основным. С момента запуска этого режима в прошлом сентябре мы накопили много опыта в создании кодового агента. В релизе 1.0 мы значительно улучшили агентность: обновили реализацию агентных инструментов, системный промпт и провели новую итерацию обучения моделей. В результате, на нашем бенче из задач, отобранных из SWE-bench Verified, на нашей старой версии Koda Pro метрики увеличились на 10%.

Модель              resolved/completed

Koda-pro old v9.8. 59%

Koda-pro (GLM5.2)            77.4%

claude-sonnet-5          78.8%

Koda Pro основанная на GLM 5.2 и близка по метрикам к топовым моделям.

Мы провели большое число замеров нашего агента с различными opensource-моделями. GLM 5.2 показала себя наилучшим образом. Также ещё подкрутили настройки под неё. Отдельная история — это оптимальный инференс модели и как её ужать в одну ноду. В итоге у нас получилось раскачать Koda Pro до уровня Claude Sonet 5.

Сколько раз вы слышали тезис о том, что в Java Reflection тормозит, и лучше его избегать. Насколько это правда?

В новом переводе от команды Spring АйО рассмотрим, почему производительность reflection-а имела проблемы.

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

Исключения удобны, пока ошибки не становятся обычной частью логики. В C++23 для таких случаев есть std::expected: он явно показывает в сигнатуре, что функция вернёт либо результат, либо ошибку. Разберём, как перейти к этому подходу без переписывания проекта с нуля.

Тест на List.AsQueryable() зелёный, а на проде всплывают LINQ-трансляция, null, collation, unique index и два воркера, забравшие один платёж. Разбираю, где in-memory тесты помогают, а где начинают врать.

Когда компания растёт из одного продуктового направления в несколько, технический долг начинает выглядеть иначе. Проблема уже не в «старом коде», устаревших зависимостях или сложной поддержке legacy-системы. Долг начинает накапливаться в расхождении инженерных решений между сервисами.

Для нас в QIC digital hub это особенно заметно на фоне миграции на новый Go-бэкенд. Исторически платформа развивалась на разнородном стеке: разные части системы были написаны на разных технологиях. Сейчас мы постепенно переезжаем на Go. Часть сервисов уже в проде, часть ещё на пути. Именно в такой момент легко создать новый слой техдолга поверх старого: переписать поведение на новом языке, но оставить команды один на один с десятками одинаковых инфраструктурных задач, которые каждая решает по-своему.

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

- go-kit — общая библиотека с переиспользуемыми инженерными решениями;

- go-service-template — шаблон, который делает эти решения стандартным способом запуска нового сервиса;

- shared-renovate-config — общий Renovate-конфиг с единой политикой обновления зависимостей для всех репозиториев.

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

Думали ли вы когда-нибудь, что запустить своего бота на сервере можно всего за один запрос к нейронке, который займет около двух минут?

Мы недавно разработали MCP-сервер, позволяющей AI-агенту в Codex или Claude поставить бота на хостинг одним промтом.

Итак, разберем нововведение и опробуем его.

Про ARC, weak/unowned и retain cycle на русском написано столько, что добавить нечего. Про borrowing/consuming и ~Copyable (это, к слову, Swift 5.9, а не 6 - частая путаница) на английском тоже десятки разборов. И почти все они устроены одинаково: объясняют, что фича делает, на игрушечном примере с файловым дескриптором, и заканчивают выводом «так безопаснее и быстрее».

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

Статью я старался написать так, чтобы её читал не только стафф. Поэтому по ходу я коротко объясняю базовые вещи - стек и кучу, ARC, copy-on-write. Если вы это и так знаете, просто пролистывайте врезки «на полях».

Пару лет назад мы масштабно столкнулись с совершенно новой технологией, которая пришла вместе с развитием агентов и LLM — MCP. Она заточена на то, чтобы дать модели интерфейс для общения с какой‑либо системой, программой или сервером.

Изначально MCP были локальными и скромными: «запусти калькулятор», «проверь календарь», «удали лишние фоточки из галереи». Но очень быстро они доросли до remote‑серверов: вставляешь в Claude адрес своего MCP, и он сразу понимает, что сервер умеет, куда подключаться и как с ним общаться. Большое спасибо за это протоколу, который в ноябре 2024 придумали в Anthropic. И как только MCP стал remote, аутентификация перестала быть опциональной. Именно про это сегодня и пойдет речь.