Hello World для STM32 На RP2040 для Hello World достаточно printf() и пары настроек в CMake. Со STM32 ситуация другая — действий от программиста заметно больше. Уже на старте появляются CMSIS, LL и HAL, дерево тактирования, CubeMX, программатор, аппаратный отладчик и вопрос, куда вообще выводить строку. Самый привычный вариант — UART, но им дело не ограничивается: есть semihosting, SWO и SEGGER RTT. И тут начинается практика, которая не всегда совпадает с красивой таблицей поддержки. У автора semihosting упорно не работал через J-Link Server, а SWO в CLion заработал только после обновления ПО J-Link. Так простой Hello World превращается в хороший способ разобраться, что происходит между вызовом printf() и появлением символов в терминале. Заодно становится понятнее, зачем в этой цепочке нужны интерфейсы, отладчики, серверы отладки и среда разработки — и почему один и тот же проект с разными связками инструментов может вести себя по-разному.

Статистика по коду Хекслета Раз пошла такая пьянка, давайте я вам выдам еще кучку разной инфы. Про деньги и бизнесовую часть поговорим потом, а щас про коммиты и код. И так погнали. Хекслет не такой маленький проект, как может показаться тем, кто не погружен в нашу кухню. Это по сути lms (learning management system), где много разных биллинговых историй (покупки подписки), управление студентами, кабинет для b2b клиентов, маркетинговые инструменты, управление контентом и большая подсистема запуска и подготовки практик. И это не считая отдельного редактора (по сути ide) и множества других систем делающихся в отдельных репах. В базе порядка 300 таблиц, а про код поговорим ниже. Задач тут много от всех команд, поэтому и изменений тоже много. Активно писать через ИИ мы начали в конце 24 года, но там был долгий этап подготовки, мы типизировали проект, переходили на sdd, делали рефакторинги и всячески адаптировали проект под удобство ии. И вот когда это закончилось (плюс минус), мы рванули фигачить фичи. Поэтому я взял данные за последний год. Учитывайте что это не показывает как было до ии и после ии. Это показывает разгон на фоне улучшения харнеса и перехода в sdd. Итоги года по кодовой базе Hexlet, с октября 2025 по октябрь 2026 Автогенерацию я не считал, только реальный код. В цифрах «было» нет легаси, которое мы за год удалили. Объём кода вырос со 180 до 322 тысяч строк, в 1,8 раза. TypeScript вырос втрое. Ruby полгода стоял на месте, а с весны пошёл вверх. За год мы сделали 5 268 коммитов. Добавили 633 тысячи строк, удалили 460 тысяч. Самым активным месяцем стал сентябрь: 713 коммитов. Сейчас две трети кодовой базы написаны на языках программирования: 114 тысяч строк на Ruby и 103 тысячи на TypeScript. Ещё четверть составляют данные и конфиги: фикстуры, локали, YAML и JSON. По rails stats бэкенд вырос с 20 до 78 тысяч строк кода, а тесты к нему — с 6 до 25 тысяч. Контроллеров было 118, стало 310. Моделей было 122, стало 205. Живых таблиц в базе данных было 149, стало 228. Тестов стало вдвое больше: 1 948 против 918 год назад. Из них 1 536 интеграционных (79%) и 401 юнит-тест (21%), ещё 11 проверяют архитектурные правила. Тестовый код растёт вровень с приложением: на каждые 100 строк кода приходится около 35 строк тестов. Покрытие сейчас 92,4%. Около 60% текущей кодовой базы написано с помощью ИИ. Точно это известно для кода с середины мая: тогда мы начали коммитить через Claude, и с тех пор на ИИ приходится 83% новых строк. Если считать, что до этого доля была такой же, выходит около 60%. По коммитам с явной пометкой получается минимум 38%.

🥂Разбор Go 1.27 полностью дописан! Вы уже, наверно, забыли о том, что вышла новая версия языка, и что я пишу о ней статью.. 😩 В статье появились разделы про аллокации и рантайм, net/http, портируемый SIMD и go fix, а в самом конце чек-лист на случай, если после апгрейда у вас упал CI. А ещё я добавил в большинство запускаемых код-сниппетов, включая старые, переключатель версии, чтобы сравнить новое поведение с прежним (там, где это имеет смысл). Так ещё интересней щупать изменения. Если запутались в истории обновлений этого обзора, можете тыкнуть на дату обновления (в шапке статьи), там будет хронология важных правок. ---- 😩 Честно говоря, на эту статью я потратил неадекватно много времени. Релиз вышел 19 августа, а на дворе уже октябрь. Каждый раз, когда я брал в работу новый пункт из release notes, упирался в вопросу «а почему?». Например, авторы пишут, что мелкие аллокации подешевели «до 30%» на микробенчмарке и примерно на 1% в реальном коде. Откуда такой разрыв? Пришлось лезть в исходники рантайма и гонять разные бенчмарки на трёх машинах. Оказалось, что ускорение выключается, пока сборщик мусора помечает живые объекты. Чем больше программа аллоцирует, тем чаще работает сборщик и тем реже ей достаётся ускорение. А ещё мне хотелось, чтобы всё это читалось интересно и легко, даже сухие разборы бенчмарков. К примеру, я очень долго возился с графиками, пытаясь сделать их максимально понятными, наглядными и простыми. Но оно того стоило. В итоге, обзор релиза превратился в небольшой, но глубокий экскурс во внутрянку актуального Go — как аллокатор раскладывает объекты по спанам, когда запускается сборщик мусора, как были устроены таймеры до 1.23, зачем процессору векторные регистры и др. Так что, даже если сам релиз вам не особо интересен, статья — хороший повод углубить свои знания. Ну и на собеседовании про аллокатор будет что рассказать. Надеюсь, вам понравится! ———— Теперь напьюсь отдохну, и пойду дописывать обновлённую серию статей про Планировщик. Работы непочатый край.. ❤️ Если захотите поддержать мой труд, милости просим в наш закрытый клуб. Я сейчас занимаюсь контентом фуллтайм, и ничего не продаю, поэтому ваша поддержка очень важна.

Как мне ИИ помогает в быту. Тесно сотрудничаю с ИИ-помощником в разработке. Он экономит мне кучу времени на рутину, находит неочевидные детали и предлагает оптимальные решения. Вот несколько кейсов только на этой неделе. 🔹Статистика Решил я добавить статистики в PersMarket. Ну, там, просмотры, география, прочее. Обычно для таких целей сразу тащу в проект ClickHouse. Но недавно писал про SereneDB, новую быструю СУБД с PostgreSQL-коннектором. Думаю, надо пробовать. Запустил режим планирования в моем ИИ-коллеге и попросил прикинуть, как реализовать статистику, упомянув обе СУБД выше. Тот пошуршал и выдал план, в основе которого обычный советский PostgreSQL. Про ClickHouse сказал, что рано. Про SereneDB почитал документацию на сайте и сказал, что пока тоже не стоит. Я пытался его убедить, что стильно-модно-молодежно, но тот был непреклонен, настаивал на своем варианте, без всякого вот этого "Вы абсолютно правы". В отчете привел обоснования и примерные оценки. По совокупности факторов я с ним согласился и пока не жалею. А вот если бы принимал решение сам, мог бы внедрить новое и потом увязнуть в настройке-поддержке. Да еще сервер мощнее брать бы пришлось. 🔹Лендинги Умеет мой нейродруг верстать, поэтому я делаю в нем лендинги. Сначала традиционный режим планирования, придумываем экраны, обсуждаем всякие завлекательные и убеждающие фразы, CTA-элементы и вот это все. Я пишу, что мне надо в итоге, он готовит этот поэкранный сценарий. Затем я согласую, и он верстает. По умолчанию получается немного нейрослопно, но есть скиллы, дополняющие его опыт всякими лучшми практиками. Они корректируют типографику и композицию, так что получается вполне прилично для работы на час. Но вот не умеет он генерировать картинки, к сожалению. Вернее, умеет вектор и SVG, умеет диаграммы и графики, а вот фотореализм не умеет. А для лендинга надо. И я прошу его: "У меня есть платное AI API, там есть модельки, умеющие генерировать изображения. Сделай мне скилл для генерации, чтобы недорого и приемлемо." Он сходил на сайт API, почитал документацию, скачал список моделей с расценками, сделал несколько тестовых запросов, выяснил оптимальный вариант и соорудил скилл. Собственно, скилл - это текст с инструкциями + скрипт на Python. И вторым запросом я ему говорю: "А теперь примени этот скилл для нового лендинга". 5 минут - и вуаля! - картинки на месте. Он сам составил запросы с учетом контекста, получил готовые картинки, оценил с точки зрения релевантности, вставил в лендинг и отформатировал. Придраться было не к чему. 🔹Баги На одном из проектов пользователи создают отчеты и прикрепляют к ним фото. И регулярно жаловались, что пропадают загруженные фото. Я не мог понять закономерность и воспроизвести это дело. Функционал делал не я, к тому же там использовалась сторонняя библиотека как ядро платформы. Попросил своего AI-гуру посмотреть, что может быть. Он посмотрел, говорит, что бывают фото большие, и в определенных случаях пользователи загружают их пачками, что не пролезает в лимиты. Давай, говорит, будем их уменьшать прямо на фронте. Ну конечно давай, говорю. Он сделал. Поверил за собой, тесты всякие, туда-сюда. Всё нормально. Кстати, говорит, а ты знаешь, что у тебя фото сохраняются неправлиьно на сервере? Не знаю, говорю. А вот, говорит, та сторонняя библиотека сначала пишет оригинал, а потом в этот же файл пишет уменьшенную копию, не отрезая хвост. Картинки потом отображаются нормально, потому что там все сигнатуры нормальные, но мусорный хвост увеличивает размер файла, иногда в разы. Ну разве я бы такое нашел глазами? Я бы и не искал, файлы без ошибок пишутся и открываются, а кто там на размер смотрит. Ой, мама, сказал я, сделай что-нибудь. Он исправил сохранение и по своей инициативе написал мне консольную утилиту для обрезания хвостов уже загруженных файлов, даже режим dry-run не забыл. Пробую - на каждые три месяца фоток до 500 мб хвостов. А история там за 4 года. В общем, не представляю, как раньше жил без такого покладистого помощника и, главное, быстрого, как электровеник. #ai

Онбординг агентов в Enterprise кодовые базы на миллионы LoC Вместе с Максимом Ключниковым (Этихлид) поделились своим опытом о том, как добиться максимум эффективности от AI агентов на больших легаси проектах. Я рассказывал про построение тезауруса и борьбу с тех долгом, а также поделился неочевидными результатами наших бенчмарков, измеряющих эффективность контекстных движков (векторный RAG, графовый RAG). Во второй части Максим рассказал об AI-native инфраструктуре . А в третьей части к нам присоединился Глеб Михеев (Уставший техдир) и мы вместе поотвечали на вопросы зрителей, обсудили тему миграции больших проектов, а также тему объективного измерения эффективности агентов на своей кодовой базе. Запись на YouTube: Конвертируем Enterprise-проект в Dark Factory — Родион Мостовой и Максим Ключников Таймкоды: 00:00 Знакомство со спикерами и начало доклада 02:15 Что такое Dark Factory и что для неё нужно 09:25 Делаем Enterprise-проект понятным агенту 14:20 Тезаурус, инварианты и знания команды 26:05 Исследование подсистем и проблема missing change 29:20 Контекстные движки: поиск и GraphRAG 36:50 Верификация: тесты, AI QA и запуск в CI/VM 56:30 Максим Ключников: замыкаем петлю на инфраструктуру 1:25:25 Воркфлоу для типовых задач 1:28:05 Профиль готовности проекта к агентам 1:31:05 Сколько работы можно отдать агентам 1:42:30 Обсуждение и вопросы участников @ai_driven

Забавно, насколько быстро всё поменялось буквально за пару недель. Я тут сравнивала новые модели openai и anthropic. Как раз во вторник у меня закончились кредиты opus 5.5. Ресет будет только сегодня в 14:00. И я пересела на sol 6.1 (openai). Конечно, это очень хорошая модель. Чётко выполняет задачи, сильно дешевле astra, и в целом с ней довольно комфортно работать. Но! Поймала себя на совершенно абсурдной вещи: у меня есть новая функциональность, которую очень хочется сделать, но я даже не хочу рисковать и отдавать её codex :) Я просто описываю пока задачи, чтобы в 14:00 сразу поставить их claude. Сейчас доверяю opus 5.5 больше. Она лучше подхватывает контекст, у неё лучше вкус, и как будто она уже заранее понимает, как примерно я сама хотела бы решить задачу. И, конечно же, несколько motion-видео тоже ждут своей очереди. sol 6.1 тут на порядок уступает: нет нужной динамики, не попадает в look&feel. А astra очень прожорливая. А ведь буквально пару недель назад всё было совсем наоборот. Короче, лениво промчу sol 6.1 и жду ресета opus 5.5 :) P.S. Сегодня вечером будет глобальный ресет в codex, можно смело переходить на astra и выжимать из неё всё. @wealldesigners

Артефакты в Claude 🚀 Лично для меня открытие этого года артефакты в Claude, если со скиллами было понятно с самого начала, что и как делать, то когда я смотрел примеры артефактов в Claude от самого Claude, то не понимал, зачем их вообще создали. Ну может быть карточки для создания тестов. Сейчас же один из самых удобных вариантов, обсудить и быстро собрать прототип почти любой фичи. А учитывая, что у Claude Code еще доступ к коду есть, то достаточно близко и к дизайну текущему получается, плюс он сразу смотрит на существующую логику в коде. Вот, например, делаем мы новую фичу в Mini Apps Builder в категории приложений "Events", можно описывать как раньше задачу, но иногда лучше ее сразу собрать в такой прототип. 😀 Mini Apps Builder 💩 Говно в продуктах #claude #artifact #база

Статистика по задачам. Как повлиял ии? Заметил интересный эффект. По мере внедрения агентов, мы стали очень сильно ускорятся в скорости закрытия тасок, в какой-то момент мне почудилось что еще чуть-чуть то текучка пропадет и мы займемся, новыми большими фичами почти без отвлечения. Но как я был не прав :) Задач было столько не потому что их было столько, а потому что где-то мы не все видели и ИИ подсветил, где-то просто перестали добавлять даже в беклог, понимая что за эти задачи мы в ближайшее десятилетие не возьмемся. Когда задачки стали закрываться, а у продактов и других ребят появились коннекторы ко всем системам, мы получили такой рост количества тикетов, что уже пришлось просить притормозить. У нас бывают дни когда за раз открывается новых несколько десятков и закрывается несколько десятков. То что раньше делалось недели, проскакивает за часы. В итоге прямо сейчас задач висит столько, сколько не висело никогда. А между тем 5 агентов (только у меня) херачат сутками. У меня кстати накопилось уже материала по изменениям, буду про это писать скоро. И переписывания на го и снижение цены лида и улучшение аналитики. Ух сколько всего. Цифры Посчитал все тикеты разработки, фидбека и контента в Трекере с октября 2025 по сентябрь 2026. За год создано 1340 тикетов, закрыто 1032. Точка отсчёта — 14 мая: в этот день в репозитории появился первый коммит, написанный вместе с Claude. Сколько создаём и закрываем в месяц • Октябрь–апрель: создавали около 70, закрывали около 50. • Июнь–август: создаём около 105, закрываем около 105. • Сентябрь: создали 422, закрыли 222. Как быстро закрываем • До мая тикет жил до закрытия в среднем от 3 недель до 2 месяцев. Начиная с мая — 5–6 дней. • Доля тикетов, закрытых за неделю, выросла примерно с 20% до 35–48%. Исключения — июнь и сентябрь. Коммиты • До мая было около 400 в месяц, в сентябре — 713. У 87% сентябрьских коммитов соавтор — Claude. Выводы 1. Тикеты закрываются примерно в 6–10 раз быстрее, чем до мая. 2. Летом мы впервые закрывали не меньше, чем создавали. До этого очередь только росла. Аппетиты растут во время еды :)

😩 OpenAI только что кинули меня на 15 баксов. Оказывается, когда вы пополняете баланс API, вы не просто кладёте деньги на счёт, а покупаете кредиты. И действуют они всего год. 🤦‍♂️ То есть моя гениальная тактика «один раз закинуть дофига денег и потом несколько лет понемногу их тратить» здесь тупо не работает. 🤬 Сегодня у меня внезапно посыпались ошибки в моих продуктах: запросы не проходят, баланс API нулевой. Пошёл проверять — действительно нулевой. Начал разбираться. Оказалось, что оставшиеся у меня там 17 с копейками баксов просто сгорели, потому что с момента пополнения прошёл год. 😡 Всё. Были деньги — нет денег. Я даже не знаю, как к этому относиться. 🤷‍♂️ Но у меня очень горит жопа. С хера ли я не могу пользоваться деньгами, которые уже закинул? Не попадайтесь на эту удочку: не закидывайте деньги на API сильно впрок. Видимо, нормальная тактика — настроить автопополнение и докидывать понемногу по мере расхода. 🫠 Свята место | 10МДК | YHub

Европейская комиссия опубликовала EU KIDS Act на прошлой неделе, который прикрывается защитой о детях, когда на самом деле совсем о другом. Росс сделал хороший обзор по теме. Его это особенно задевает в контексте инициативы Stop Killing Games. И выглядит это реально как попытка протолкнуть инициативу крупных издателей, чтоб доминировать на европейском рынке. Там 100 страниц канцеляризмов, но основные моментики: - Слишком расплывчатые формулировки. - Касается всех игр, а не только онлайн игр. - Переписывание определений. Например, они там все игры записали в сервисы. - Касается не только игр, но и операционок. В контексте Линуксов вдвойне не ясно, что делать, учитывая, что на многих дистрах проверки возраста в принципе нет. - Приватные сервера вне закона. - Огроменный список требований, который, если примут эту дич, инди-разработчиков будет довольно тяжко (и дорого) реализовать. Европейцы могут поддержать вот эту инициативу по борьбе с актом. Пока что выглядит всё весьма печально. Если в таком виде примут, то это повлечёт кучу проблем именно инди-разработчикам.

Вниманию фронтендеров и вайбкодеров. В очередной рассылке попалось несколько наборов для построения вашего UI. Не знаю, насколько в наше время это актуально, но делюсь. 🔹Sharl UI - более 90 компонентов на все случаи жизни. Минималистично-аккуратно. Репозиторий. 🔹Vuzeno - дизайн-система на основе Ark UI (это headless-платформа, независимая от фреймворка). TypeScript, всё как положено. Репозиторий. 🔹Kibo UI - набор компонентов для использования с shadcn/ui, от color-пикера до почти диаграммы Гантта. Репозиторий. 🔹Jelly UI - тоже набор стандартнызх компонентов, но с такой игривой, "желейной" визуализацией. 🔹NeonBlade UI - в целом нестандартный подход, для любителей кибер-панка, всякие компоненты в неоновом стиле, ну и вспомогательные, типа Матрицы. #ui #frontend

ИИ все чаще пишет код сам. Тогда чем теперь занимается разработчик? На конфе Яндекса по образованию YaC/e говорили о том, как теперь учить айтишников: часть задач уже можно отдать нейронке, но понимать, как все работает вместе, все равно придется самому. Если кратко, нужны три навыка: — Разговаривать с ИИ на одном языке. Понимать устройство технологий, контекст, RAG и работу языковых моделей; — Видеть ограничения технологий, которые требуют инженерной доработки; — Смотреть на задачу не только как разработчик, но и как аналитик и продакт — пройти мысленно путь от идеи до конечного результата и видеть проект целиком. Поэтому ИТ-универам предлагают готовить «архитекторов сложных систем». Больше внимания — математике, физике и естественно-научному мышлению: такая база помогает быстрее разобраться с новой задачей. Стек поменяется. А разобраться, что именно ты построил вместе с ИИ, все равно придется.