Композиционный анализ (Software Composition Analysis, SCA) – это практика автоматического выявления и отслеживания внешних зависимостей проекта с целью мониторинга их известных уязвимостей.
В этой статье мы расскажем, какие инструменты используем и как организуем пайплайн для своевременного и регулярного анализа зависимостей проектов на C++.
P.S. В написании текста статьи не участвовала нейросеть! 100% ручной труд разработчика Георгия 😇
В мае на конференциях C++ Russia и HolyJS мы предложили участникам оценить технологии, инструменты и инженерные практики, с которыми они работают или за которыми следят. Так появились данные для двух технических радаров: по экосистеме C++ и по JavaScript.
Сырые цифры сами по себе рассказывают немного, поэтому мы отдали результаты на разбор эксперту. Виктор Новиков, руководитель группы разработки в «Лаборатории Касперского», посмотрел на распределения голосов и поделился своим мнением, почему CMake уверенно побеждает, а PostgreSQL раскалывает аудиторию пополам. В этой статье — его анализ C++-части исследования. Про техрадар JavaScript мы расскажем в другой статье.
Посмотреть радар и принять участие в голосовании можно на странице проекта.
Некоторое время назад мне пришла задача спроектировать высокопроизводительный балансировщик нагрузки для протокола Diameter. Через 3 месяца задача исчезла, так как как оказалось слишком долго и дорого, но в итоге балансировщик был сделан и имеется его MVP которое готово к установке как на реальное железо так и в облаке. В итоге продукт получился неплохим, и он с лихвой выигрывал имееющееся решение в той компании, по производительности был выигрыш раз в 6 по ресурсам раз в 100. Но суть не в этом, а в том что балансировщик был кластерным и умел хранить сессии в Redis. Решение было сделано, оно показало работоспособность, все хорошо, но меня не устраивала производительность. В тот момент я столкнулся с очень интересной проблемой - по каким то причинам я не мог пробить барьер в 5-7К Diameter Transactions per second. В принципе 5-7К TPS было неплохо, но проблемным участком как показал анализ был Redis. Проведя немного времени я смог добиться приемлемого результать и производительность поднялась до 20К TPS но там были другие проблемы.
Иногда небольшой пет-проект неожиданно превращается во что-то совсем другое. Сначала я делал квесты, потом решил сделать движок для Telegram-квестов, а в итоге разработал собственную виртуальную машину, язык сценариев и браузерный редактор, похожий на Scratch. В статье — история того, почему обычный код оказался плохим инструментом для написания сюжетов и что получилось в результате.
Когда вы открываете Яндекс Go для заказа такси и вводите адрес, приложение за доли секунды показывает цену. Кажется, что это несложно: Кажется, что это несложно: взять расстояние и время в пути, умножить их на значения из тарифа. На самом деле, за этой ценой стоит не один десяток факторов — например, скидки, спрос, геозоны. И это ещё без учёта того, что пассажир взял с собой кота или лыжи.
В этой статье — о том, как мы вынесли алгоритм ценообразования из кода сервиса, почему не взяли готовый скриптовый язык, что такое цепочка преобразований цены и зачем нам понадобился формальный верификатор.
В этой части мы проверим, есть ли у SME учебная дорога, сравнимая с той, которую получили тензорные ядра GPU; затем разберём два реально полезных источника: Arm Learning Path и KleidiAI; после этого отделим то, чему они действительно учат, от того, где они останавливаются. К концу главы станет видно, какая именно «середина лестницы» отсутствует и почему следующая часть неизбежно приводит к BLIS.
Всем привет! Я продолжаю развивать свою библиотеку для создания распределённых приложений. Она уже легла в основу новой версии rats-search (распределённый торрент-поисковик) и rasync (синхронизация папок, файлов и исходников между устройствами), а также, судя по всему, используется в UltraVNC (VNC-клиент).
Библиотека позволяет развернуть собственную P2P-сеть, связать пользователей между собой и выстроить обмен данными через потоки разных типов — бинарные, строковые и другие. Главная особенность — автоматическое обнаружение участников (peer discovery), что особенно актуально в условиях постоянных блокировок и сетевых ограничений.
На данный момент поддерживаются C/C++, Java (Android), Python и Node.js.
Это очередное обновление: ещё больше стабильности в работе различных функций, значительно улучшены протоколы DHT и BitTorrent. Обо всём подробнее — далее.
Последний стабильный релиз на сегодня — 2.0.5. Исходный код и собранные бинарные файлы доступны для:
Поучаствовал в хакатоне от работы. Интересно было испытать себя и проверить свой тулсет для разработки игр. Смогу ли я один сделать игру под ключ - код, арт, звуки?
Штош, игру сделал! Правда лег спать около шести утра 😖 Но это было интересно!
Внутри ссылка на игру и немного технических подробностей как генерил арт, код и собирал игру
На форуме Cursor разработчик рассказал, как запретил агенту работать с удалённой базой, а тот всё равно выполнил npx supabase db push. Эта команда отправляет локальные изменения схемы в подключённый удалённый проект. Агент мог изменить рабочую базу данных — и только после этого сам признал, что нарушил правило.
Модератор форума Cursor посоветовал сократить правила, убрать доступ к рабочей среде и настроить отдельную проверку, которая будет блокировать опасные команды перед запуском. Это один случай, а не статистика надёжности Cursor. Но он хорошо показывает цену забытого правила: иногда агент затрагивает внешнюю систему, где простого отката файла уже недостаточно.
У меня всё закончилось проще. Вчера я попросил Cursor разобраться с упавшим сквозным тестом. Я ждал исправления в приложении, но агент поменял проверку в самом тесте и отчитался, что всё готово. Тест, разумеется, прошёл.
Такое поведение я заранее запретил в правилах проекта. В правиле было написано: сквозные тесты считаем контрактом, при падении сначала ищем ошибку в приложении, сам тест без согласования не меняем. Cursor правило видел — по крайней мере, в начале разговора он ему следовал.
Я заметил подмену при просмотре изменений. Откатил правку теста, повторил условие в чате и снова отправил агента искать причину падения. Почему правило не сработало, я точно не знаю. Возможно, оно потерялось среди кода, результатов поиска и нескольких запусков тестов, которые появились в разговоре позже.
Я занимаюсь изучением синтаксиса языков программирования и пытаюсь отделить фундаментальные закономерности от исторических случайностей. Одна из таких случайностей - почти повсеместное использование терминов выражение (expression) и инструкция (statement) при описании и классификации синтаксиса языков программирования.
Интуитивно кажется, что 2 + 2 и if (x) { foo(); } - это совершенно разные сущности, но при более глубоком анализе оказывается, что подобное разделение искусственное и возникло из-за архитектурных особенностей вычислительных машин почти полвека назад и с тех пор просто «переходит» из языка в язык.
Одна C++ схема — protobuf, binary, JSON, YAML и structured logging без ручных маппингов. В статье разбираю, как CONTRACT отделяет стабильный контракт типа от конкретных форматов, зачем нужны BASE, PROPERTY и REFERENCE и как атрибуты полей задают общую политику для разных адаптеров. Всё - на реальном коде из репозитория: YAML-конфиг, структурированный лог и сравнение производительности с libprotobuf. GitHub.
Вторая часть. В первой я собрал конвейер из ИИ-агентов: он сам ведёт задачу от тикета в YouTrack до коммита - разбирает, правит C++ в проекте на три миллиона строк, собирает и доказывает исправление кадром из живого интерфейса.
Здесь - цифры за девять недель работы на боевых задачах. Например, на код у агентов уходит лишь пятая часть машинного времени. Остальные четыре пятых на то, чтобы доказать, что написанное работает.
Тринадцатикратный рост из заголовка тоже разбираю. Но самое интересное оказалось не в нём.
В прошлой статье (Непослушный using ) я разобрал, как using вмешивается в поиск имён и почему его поведение часто расходится с тем, что от него ждет программист, и на этом ветку статей про поиск имен (name lookup) можно временно закрыть.
Using'и попортят вам в проектах еще немало крови, но в целом их проблемы известны и легко ловятся, а теперь давайте поговорим обauto и выводе типов в шаблонах, который регулярно удивляет даже опытных программистов на C++, когда речь идёт о распаде типов (type decay) и неявных ловушках при работе с ним. Представьте, что у нас есть несколько переменных, которые выглядят разными: const int&, просто int, const int и int&&.
По наивной интуиции можно подумать, что компилятор должен относиться к ним по‑разному: и где‑то ссылка, где‑то константность, где‑то rvalue, но это будет работать только до тех пор, пока мы не используем auto или шаблон.
Потихоньку дописываю книгу, в целом каркас уже сложился и большая часть материала уже собрана и обработана в черновике, если вам интересно, что получилось, то главы выложены на гитхабе в русском и английском вариантах или тут, если вам больше нравится в виде статей, а то, что ещё дописывается уже больше шлифовка, чем поиск нужной формы. Оглавление и ссылки будут под катом.
Наталья Яковлева, инженер-программист, C3D Labs, рассказывает о том, что нового появилось в продуктах C3D Vision и C3D Viewer.
C3D Vision — это высокопроизводительная графическая библиотека, ориентированная на инженерные задачи и предназначенная для рендеринга 3D-моделей САПР на настольных компьютерах (рис. 1). Она позволяет визуализировать данные в полигональном представлении, предоставляет API для работы с 3D-моделями, позволяет задавать иерархию визуальных объектов и выполнять необходимые преобразования.
Всем привет! Меня зовут Тимур, я работаю в YADRO, и уже больше двух месяцев мой системный компилятор — gcc16. В новом стандарте добавили очень много, и сегодня я расскажу вам о некоторых обновлениях. В основном о рефлексии, но также будет немного и о контрактах.
Рефлексия в программировании — это способность программы работать со своим исходным кодом. Например, пройтись в цикле по всем полям класса и узнать их названия и типы. Работа с json — это очень хороший пример для изучения возможностей рефлексии. Я поигрался с ней, мне очень понравилось, и этой радостью я хочу поделиться с сообществом.
Я не планировал переписывать приложение React Native на C++.
Большая часть приложения прекрасно работала на TypeScript: экраны, формы, валидация, навигация, логика продукта — все это находилось именно там, где нужно.
Проблема была более узкой и специфичной: нам нужно было, чтобы один фрагмент логики работал с производительностью, близкой к нативной, оставался общим для Android и iOS и при этом был доступен из JavaScript через обычный типизированный API.
Поначалу все звучало слишком просто. Написать интерфейс на TypeScript, позволить Codegen генерировать контракты, перенести основную логику на C++, зарегистрировать модуль на обеих платформах и использовать его из React Native как любой другой модуль.
Спойлер: да, это работает.
Чистый модуль Turbo Native на C++ действительно может дать вам одну реализацию для Android и iOS, типизированную границу через Codegen, меньшие накладные расходы, чем у старого Bridge, и удобный способ повторного использования существующего кода на C или C++ внутри приложения React Native.
Спойлер номер два: код на C++ — это не самая сложная часть.
Самое сложное начинается вокруг: CMake, NDK, Xcode, Objective-C++, время жизни среды выполнения JSI, регистрация модулей, границы потоков, владение памятью, обработка ошибок, сборки Expo, сторонние библиотеки и вопрос, который никто не хочет задавать слишком поздно — действительно ли этот модуль должен быть нативным?
В этой статье я подробно расскажу о создании C++ Turbo Native модуля для React Native: где этот подход полезен, где он добавляет скрытые затраты на поддержку, чем отличается регистрация для Android и iOS, почему важна обертка TypeScript и почему сам TurboModule должен оставаться «тонким».
ИИ‑агент редко ограничивается одним ответом, когда работает с большим проектом. Он читает код, ищет использования символов, меняет несколько файлов, запускает тесты и исправляет найденные ошибки. За это время история чата пополняется сообщениями пользователя и результатами инструментов.
У длинной задачи возникают две практические проблемы. Первая: разработчику нужно уточнить одну деталь, но новое сообщение может вмешаться в текущую последовательность действий. Вторая: правило, переданное модели в начале разговора, постепенно отдаляется от текущего шага и может перестать влиять на ответ.
В Veai 5.16 для этих сценариев появились команда /btw и параметр strictness. Ниже разберём механику обеих функций, их ограничения и влияние частого повторения инструкций на контекст модели.
Все мы знаем, что языки делятся на динамические и статические: Python или JS позволяют молниеносно прототипировать, но расплачиваться нестабильностью в продакшене приходится потом, тогда как C++, Java или C# требуют прописывать типы сразу, оплачивая монументальную надежность замедлением разработки.
В 2006 году Джереми Сиек предложил разрешить этот конфликт концепцией постепенной типизации в работе «Gradual Typing for Functional Languages»: язык остается динамическим по умолчанию, однако разработчик может аннотировать типами отдельные модули или функции, не покрывая ими всю кодовую базу, а типизированный и нетипизированный код взаимодействуют через специальный динамический тип Dyn. Звучит как сказка — быстрое прототипирование с постепенным наращиванием стабильности. Однако при детальной проработке вскрылись фундаментальные нюансы: в серии последующих работ Сиек, Таха, Вадлер и другие показали, что стыковка типизированного и нетипизированного кода требует операции приведения типа (cast), а дизайн этого каста упирается в противоречие между тремя желаемыми свойствами — надёжностью системы типов (soundness), собственно постепенностью (gradual typing) и отсутствием рантайм-обёрток на границах (no wrappers).
Позднее сообщество, и я в том числе, переосмыслило третью вершину: no wrappers — это забота о производительности и прозрачности рантайма, безусловно важная, но с позиции программиста, а не математика-оптимизатора, правильнее говорить о удобстве разработчика (developer-friendly). Это свойство вбирает в себя no wrappers как частный случай, добавляя понятные сообщения об ошибках, низкий порог входа и отсутствие многослойных типовых аннотаций, ведь если ради производительности приходится городить бесконечные теоремы типов, такая система едва ли приживётся на суровом рынке опенсорса.
Так родилась трилемма Святого Грааля системы типов: выбрать можно любые два свойства, а третье неизбежно пострадает, и в этой статье мы разберём, как создатели языков пытались достичь всех трёх и на какие компромиссы шли.
Я заметил, что стал копипастером задач в ИИ-агента и обратно, а из программиста превратился в GUI-тестера. Не самая моя любимая работа.
Сначала наваял простой скрипт на Python: сделать скриншот, ткнуть мышью в координаты. В итоге тихим сапом это выросло в круглосуточный конвейер, который ведёт задачу от тикета в YouTrack и общения с пользователем до доказательства в живом 2D/3D-интерфейсе и коммита. И ещё писатель документации со скриншотами в придачу.
Рассказываю, как оно росло, какие были грабли и сколько строк в итоге занял наследник того самого «простейшего скрипта».
Вот в github:
https://github.com/Divetoxx/Piano
🎹 Основная философия: «Ритмическое дирижирование без ошибок»
Главное новшество этого фортепиано заключается в том, что пользователю никогда не нужно беспокоиться о неправильном воспроизведении нот.
Идеальная высота звука (Гц): Каждая частота и высота звука точно запрограммированы в плотные векторы нот. Математически невозможно сыграть неправильную ноту или допустить ошибку!
Время ваше: Время, интервалы и эмоциональный темп совершенно не ограничены. Нажимая на клавиатуру или мышь, ВЫ динамически создаете ритм и временную структуру. Вы не просто нажимаете на клавиши — вы дирижируете шедевром!
