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

Куда уходит процессорное время? Этот вопрос встает перед разработчиком встраиваемой системы как при поиске узких мест, так и при разборе ситуаций, когда система укладывается в сроки на стенде и перестает укладываться на объекте.

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

Десять дней разработки — и язык, на котором держится веб. В этой статье — история JavaScript и инструментов, которые привели его к этому.

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

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

Ранее мы уже предпринимали всевозможные ухищрения, чтобы ускорить компиляцию: стирали типы, активно продавливали дедупликацию кода, сокращали строки, связанные с генерацией кода. В этом мы достаточно преуспели. Но недавно мы стали осваивать работу с крупным новым клиентом (энтерпрайз), у которого оказалась масса сложного SQL-кода. Они написали при помощи наших инструментов много больших программ. Например, там был образец размером в 8562 строк на SQL, который наш компилятор в итоге превращал примерно в ~100k строк на Rust.

Привет, Хабр. Я уже не тот беззаботный парнишка, что собирал 486-й компьютер. Время бежит, я скуф успел поработать с C++, C#, Java и Kotlin, последние 10 лет занимаюсь мобильной разработкой. Программирование я до сих пор люблю потому что больше ничего не умею. Но чем дольше работаешь, тем чаще ловишь себя на мысли, что от некоторых вещей начинает подгорать. Сегодня я расскажу, как я попытался избавиться хотя бы от части таких вещей.

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

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

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

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

Все знают авто-электриков и диагностов. Я IT-автоэлектрик объединяю знание физики автомобильных цепей и низкоуровневого программирования на С для создания инструментов анализа и изучения j1939.

CAN шина это мост между двумя мирами авто-электриков и IT специалиста. Но для многих этот мост, увы кажется непреодолимой пропастью. Ребята попробуйте программировать на Си и вы пойдёте по этому мосту. Я начинал программировать в телефоне termux. То есть для этого нужно только желание.

Я себя не считаю самым умным. Я просто нашел для себя мощную точку пересечения этих профессий и стал называть этот подход IT-автоэлектрик. Писать свои собственные утилиты на С чтоб заглянуть под капот CAN шины. Под капотом ДВС менее интересно.

Размер моих логов на сегодняшний день 1 - 3 мегабайта. Если вес лога гигабайты то по идее данные нужно положить в голову страницы и процессор полетит как пуля. Размер скомпилированного файла map_id_j1939.c и viz_j1939.c по 16.5 КБ.

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

Даже если явно попросить ответ по JSON Schema, модель может добавить пояснение, пропустить поле или вернуть не тот тип. Нативный structured output у части провайдеров есть, но он работает не везде и не одинаково.

В новом переводе от команды Spring АйО разбираем, как в Spring AI 2.0 решается эта проблема.

Спойлер: оба находятся в опасности, но по-разному. Эта разница имеет значение.

Я не собирался сравнивать веб и мобилку как две враждующие платформы.

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

На вебе можно спрятать админку за условием в JavaScript и решить, что доступ закрыт. В мобилке можно положить токен в SharedPreferences и надеяться, что до него никто не доберется. Можно оставить открытый бакет, отключить нормальные правила Firebase, забыть про rate limit на логине или принять userId из тела запроса.

Все это выглядит как мелочи, пока приложение работает.

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

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

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

Воодушевившись статьёй 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 лет, а ещё я — один из экспертов онлайн-магистратуры «Фронтенд-, бэкенд-разработка и ИИ-решения» ИТМО в партнёрстве с Яндекс Практикумом. Сегодня хочу поговорить о том, как правильно выбирать инструменты для разработки, почему разбираться в разных инструментах — не равно уметь их правильно применять и что с этим делать.