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

В новом переводе от команды Spring АйО на простом Java-примере показываем:

– как работает мутационное тестирование с Pitest;  
– почему 100% покрытия недостаточно;  
– откуда берутся выжившие мутанты;  
– почему не стоит прогонять MT по всему проекту;  
– и в каких случаях этот подход действительно окупается.

А ещё как поручить настройку и запуск Pitest AI-агенту с помощью готового skill.

Сервис зависает, контейнер не отвечает, а в логах — только «обработанные» ошибки. Часто причина таких инцидентов скрывается в слишком широком except Exception, который мешает приложению корректно завершаться. Разберем, как правильно обрабатывать исключения в production‑воркерах и избежать подобных проблем.

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

Меня зовут Женя Ерохин, у меня около 15 лет опыта разработки драйверов на C++ под macOS. Сейчас я старший разработчик в Kaspersky Lab, занимаюсь операционной системой KasperskyOS. Много всего создал в ее микроядре, а теперь знакомлю нашу ось со всяким железом на мобильных устройствах.

Под катом я покажу, как мы использовали C++ при разработке драйвера для микроядерной ОС. В том числе разберу гетерогенный lookup — возможность выполнять поиск по разным типам аргументов без лишних преобразований. На практике такая фича хорошо показывает, почему C++ может быть полезен даже там, где обычно ждут C. Я расскажу, почему драйверы на C++ для микроядерной ОС — вполне рабочее инженерное решение. Покажу, где именно плюсы помогают писать более аккуратный и надежный код, как они упрощают работу со структурами данных и почему в нашей задаче такой выбор оказался естественным.

За последние пару лет произошло странное: написать работающий код стало почти неприлично легко, а построить хорошую программную систему наоборот - сложнее. Сегодня человек без классического IT-бэкграунда может за вечер собрать интерфейс, API, базу и даже что-то задеплоить. А потом начинается самое интересное: архитектура расползается, зависимости живут своей жизнью, безопасность появляется «во второй версии», а никто уже толком не понимает, почему система вообще работает.

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

Отсюда и главный вопрос: как вообще должна выглядеть маленькая IT-компания, если значительную часть работы уже могут выполнять цифровые исполнители?

Представляю мою спорную модель такой компании: умница-аналитик, архитектор-разработчик, супертестировщик, фантазёр, DevOps, параноик по безопасности. Плюс общая память компании, потому что без неё нейросети очень быстро начинают изобретать архитектуру заново.

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

Разбираем необычную конструкцию async void

В чем отличие от написания async Task? Какие проблемы могут за ней скрываться? Для чего ее ввели в язык? Как ей правильно пользоваться?

Ответы на все эти вопросы далее в статье

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

Приветствую, Хабр! На связи Евгений Сапрыкин, я главный специалист техуправления по прокатным валкам на Западно-Сибирском металлургическом комбинате. 

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

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

Есть регламенты по плановому ремонту валков. Но хорошо бы обслуживать их не просто по графику, а по мере реальной необходимости. И быстрее настраивать прокатный стан на отремонтированных валках с изменённой геометрией. Всё это позволит нам не допускать брака и аварийных ситуаций.

Эту статью я написал вместе с коллегами из команд IT и разработки бизнес-системы: Евгением Никитиным, Владимиром Рыжковым, Ольгой Чегодаевой, Диной Сизиковой, Ильёй Нечкасовым. Расскажем, как мы наладили систему для обмена информацией о валках между специалистами из эксплуатации и ремонта — и какие задачи это помогло решить.

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

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

Я начинал с простого AI-аудита заметок, а в итоге Vault Audit AI вырос в систему с двумя индексами, поиском по смыслу, Similar Notes, semantic duplicates и RAG по собственному хранилищу. В статье разбираю, как всё это устроено, что ломалось по дороге и почему почти 700 тестов всё равно не спасли от сюрпризов в реальном Obsidian.

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

Покрывают его тестами и пишут документацию.

Делают ревью, находят баги и исправляют их.

Параллельно работают над разными задачами.

Так почему же некоторые люди продолжают вручную набирать каждую строчку кода?

Почему они не хотят делегировать это ИИ агентам?

Вечером 02.09 у нас не вышел плановый пост в TenChat. В логе задачи планировщика — ничего осмысленного, просто ненулевой код возврата и алерт «слот не закрыт». Разбор растянулся на весь вечер, потому что там оказались не одна поломка, а три, и каждая маскировала следующую.

Команда — шесть разработчиков, полтора десятка параллельных проектов. Задачи жили в Excel, чатах и головах. В какой-то момент стало понятно, что «а кто это делает?» задаётся чаще, чем «как это сделать», — пора заводить трекер.

Дальше случилось то, что случалось у многих: мы честно прошлись по рынку, везде что-то мешало, и в понедельник я открыл пустой репозиторий. Во вторник команда уже вела задачи в своём трекере.

А самое интересное произошло между этими точками: канбан-доска — то, ради чего всё затевалось, — прожила в интерфейсе два с половиной часа. По истории коммитов видно точно.

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

Почему не готовое

Сразу дисклеймер: всё перечисленное ниже — нормальные инструменты. Не подошли они нам из-за наших ограничений, а не потому что плохие.

Jira и Linear отпали первыми: данные о внутренних проектах не должны жить во внешнем облаке, а с обслуживанием российских аккаунтов у обоих вендоров всё сложно. Kaiten, YouGile, Weeek — приличные российские альтернативы, но это опять облако с чужим хранением, а по деньгам на команду — подписка за то, чем мы будем пользоваться на пять процентов.

Self-hosted Plane был ближе всего, но тащить и обслуживать чужой комбайн ради шести человек не хотелось.

GitHub Issues мы используем и любим, но тут споткнулись о главное: трекер нужен не только разработчикам. Руководителю нужны карточки, сроки и картинка загрузки — а не list view с лейблами. Фраза, убившая этот вариант, звучала так: «Issues не умеют пользоваться менеджеры». Это не претензия к менеджерам — это факт о интерфейсе.

В Go 1.27 encoding/json стал тонким слоем поверх нового encoding/json/v2. Собрал тулчейн из исходников, прогнал один и тот же код в четырёх конфигурациях и разобрался, почему разбор в any стал медленнее в полтора раза.

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

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

В дату релиза проект деплоится в прод. Но почему-то там все также один пользователь — сам создатель.

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

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

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

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

Начинал я как все, со связки Obsidian и Claude.

Первые свои выводы начал делать после того, как загружено было 219 353 файла. Я не знаю как для вас, но для меня Obsidian теперь - это просто программа для просмотра, а не то что я раньше про него думал. Вся ценность всего этого массива моих данных - в трёх вещах: обычные текстовые файлы на диске, ссылки, перелинковки между ними и агент, который читает и пишет их напрямую.

Как это у меня устроено сейчас и сколько токенов на это потрачено

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

Я поставил Obsidian, завёл хранилище, стал туда складывать заметки, документы, истории - да все подряд.

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

Из этого сбылось только то, что граф действительно приятно смотреть, и заметки удобно читать глазами. Но Obsidian это не база знаний. Для меня сейчас это программа для просмотра папки с текстовыми файлами. Она красивая, с графом и плагинами.

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

Откройте почти любую статью про FFI на Rust. С вероятностью девять из десяти там написано: «паника, вышедшая за границу с C, — это неопределённое поведение». Эту фразу повторяют пять лет, я и сам её цитировал, в том числе в одной из прошлых статей. Она перестала быть правдой почти два года назад: с Rust 1.81, вышедшего в сентябре 2024-го, такая паника гарантированно и предсказуемо завершает процесс.

Причём это не единственный протухший совет. Второй я поймал на себе буквально недавно. Есть присказка, живущая в статьях лет десять: поставь panic = "abort" — и бинарник похудеет процентов на десять. Написана она в релиз-нотах 1.10 за июль 2016 года, я повторил её в чужом пулреквесте, а потом сообразил, что ни разу не проверял. Собрал одну программу тремя способами, посмотрел в size -A и получил шесть десятых процента вместо десяти. Причём в сборке, где раскрутки быть не может по определению, преспокойно лежали одиннадцать килобайт таблиц, существующих исключительно ради раскрутки.

Но всё это финал истории, а начинается она с того, что паника — вовсе не «программа крякнулась». Это полноценный механизм исключений на той же машинерии, что и в C++. Раскрутка идёт не в один проход, а в два. Каждое исключение метится восемью байтами b"MOZ\0RUST", доставшимися в наследство от Mozilla, где Rust когда-то жил. catch_unwind ловит не через personality routine, как принято думать, а через отдельный компиляторный интринсик. А ещё есть дыра, про которую почти не пишут, потому что вылезает она только при раскрутке между двумя независимо собранными копиями стандартной библиотеки — и защищает от неё канарейка, живущая прямо внутри исключения.

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

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

31 августа в 14:32 по Москве у нас вышла последняя штатная публикация. Дальше cron честно стартовал по расписанию, генератор успевал выбрать тему и написать текст, но в ленте ничего не появлялось. Так повторилось четыре раза: три запуска 1 сентября и утренний запуск 2 сентября.

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

Привет, Хабр! Мы — Настя, Эвелина и Михаил — бэкенд-разработчики Т-Банка, пишем код на Scala и горим желанием его популяризировать. Мы собираем и агрегируем новости из разных источников, включая Scala Times, блог Petr Zapletal, добавляем дополнительные материалы и собственные комментарии. Мотивацию черпаем из желания развиваться и делиться полученными знаниями.

Всех поздравляем с наступившим сентябрем. Поздравьте учителей, переверните календарь — и вперед, читать наш дайджест! 

Приветствуем любую обратную связь! (づ ◕‿◕ )づ