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

Наш сетевой драйвер терял пакеты. Не время от времени, а постоянно. На пропускной способности линии с 64-байтными пакетами мы теряли 31% всего трафика.

В качестве оборудования использовался Ethernet-контроллер на 1 Гбит/с на SoC RISC-V. В спецификациях говорилось, что он может справляться со скоростью проводного трафика. Движок DMA работал корректно. Обработчик прерываний срабатывал вовремя. Тем не менее, пакеты исчезали.

Я начал с очевидного подозреваемого: очереди получения. Реализация выглядела вполне логично — простой связанный список с указателями на голову и хвост. Под нагрузкой (64-байтные пакеты на пропускной способности линии) драйвер терял 31% пакетов! При профилировании обнаружилась причина проблемы: производительность убивали связанный список и спин-блокировки.

Я переписал драйвер, использовав кольцевой буфер без блокировок. Результаты: потеря 31% пакетов превратилась в 0,12% — улучшение в 258 раз!

В этой главе мы поговорим о структуре очередей для драйверов устройств.

Недавно мне попалась отличная статья про IAsyncEnumerable и стриминг данных. В ней у автора упал прод, который пытался выдать 500 000 записей разом и упал на вызове ToListAsync() с OOM при 8 ГБ RAM. Далее в статье описывается, как все это стримить с помощью IAsyncEnumerable с примерами кода. В целом после прочтения статьи может сложиться впечатление, что все свои ToListAsync() срочно нужно убрать и заменить на стриминг.

Но со времен появления стримингового апи в .NET мне всегда было интересно, не только то как отдавать стримы, но и как это все получать на клиенте?

Порезали и собрали для вашего удобства все материалы блиц-докладов со второго митапа сообщества Devhands AI Club. У нас было 6 мини-докладов, по 7 мин на доклад), 2 от фаундеров стартапов и 4 от разработчиков. Темы: ACP и взаимодействие агентов, скилы системного дизайна, AI в инфраструктурном и хостинг стартапах, организация проектов с Claude, транскрибация и саммаризация видео.

В России снова обсуждают вход на сайты через Google, Apple ID, GitHub и другие иностранные аккаунты. Повод — подписанный закон № 199-ФЗ от 26.06.2026, который добавил в КоАП штрафы за нарушение правил авторизации пользователей.

Но сам запрет появился не сейчас. Базовая норма пришла ещё с 406-ФЗ от 31.07.2023 и с 1 декабря 2023 года живёт в ч. 10 ст. 8 закона № 149-ФЗ «Об информации». Новое в том, что теперь за нарушение есть отдельная статья КоАП — 13.55: для граждан 10–20 тысяч рублей, для должностных лиц 30–50 тысяч, для юрлиц 500–700 тысяч.

Обычного пользователя не штрафуют за сам факт наличия Gmail, Apple ID или GitHub. Но если этот пользователь одновременно владелец российского сайта, приложения или сервиса и оставил там вход через иностранный аккаунт, он уже не «просто пользователь», а «субъект обязанности по 149-ФЗ».

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

Помните времена, когда трава была зеленее, мобильный интернет помегабайтным, а Apple осваивала непаханые поля смартфоно-игровых ферм? Начало 2010-х было очень интересным временем, когда мобильные студии создавали целые новые жанры, пытались перенести или адаптировать старые концепции и игры, попутно решая задачи, от которой у десктопного разработчика начинал дергаться глаз. Вот и EA решили взять культовые франшизы SimCity и The Sims со всеми их терабайтами ассетов, сложнейшей симуляцией дорог, пробок и отдельных симов, и попробовать затолкнуть это в карман.

В кармане у пользователя тогда лежал условный iPhone 4 или 5 с уже тогда куцым бюджетом оперативной памяти в районе 100–300 МБ на всё про всё, но айфоновладельцы были "платящей" аудиторией, поэтому игровое подразделение метило в основном в них. Как не превратить смартфон в обогреватель и словить ООМ в первые минуты игры? Выкинуть честную симуляцию на помойку, превратить симов в конечные автоматы, а город сделать хитрой иллюзией из текстурных атласов и таймеров. Раскажу немного как устроены SimCity BuildIt и The Sims Mobile с инженерной изнанки, кода почти не будет, да он и не нужен тут для понимания, а еще будет немного грустинки по российскому подразделению EA, и фотки с закрытия офиса в 2016.

За свои 17+ лет в активной разработке я встречал много проблем, но одна преследовала меня постоянно: JSON. Нет, с самим форматом все ок, но вот с его чтением — не все норм.

Когда я только начинал работать с PHP, я списывал это на скриптовость языка. Отчасти из‑за этого я даже поменял стек. Но когда приходили по‑настоящему большие файлы, это всегда было больно. Иногда — очень. Был проект, где мы ждали не обработку информации бизнес‑логикой, а банального парсинга. Файлы доходили до десятков гигабайт и не всегда влезали в оперативку. Тогда я и заработал себе персональный todo — разобраться с этим раз и навсегда.

Сейчас, находясь в поиске новых возможностей, я решил вспомнить эту старую боль. Я уже давно не PHP‑разработчик, но проблема в индустрии всё та же. Объемы данных растут, требования тоже, а воз и ныне там. Нет, есть море крутых решений. Даже тут, на Хабре. Но для меня всё не то.

Мне нужно решение, а не костыль. То есть: никакой кодогенерации и никаких JIT (я не противник JIT, просто не хочу тянуть эту сложность).

Я ступил на тонкий лед: в Go есть классная штука — пакет unsafe. Почему классная? Потому что она позволяет обойти тяжелые ненужные проверки. Плюс побитовые операции для ускорения всего, до чего только смогли дотянуться руки. Пока изучал чужие парсеры, столкнулся с обманом в репозиториях, подкручиванием статистики (куда же без него?) и перекладыванием ответственности (и аллокаций) на сторону разработчиков.

Swift — это современный язык программирования, лежащий в основе многих приложений, работающих на платформах Apple наших дней. Мне показалось, что было бы неплохо немного вернуться к истокам Apple, к Apple II. Это была первая массовая серия компьютеров Apple, первоначально выпущенная в 1977 году с процессором MOS 6502 с частотой 1 МГц.

19-й выпуск IT-новостей от OpenIDE!

Midjourney открыла медицинское подразделение и сканер всего тела вместо МРТ, Cursor строит замену GitHub под AI-агентов, а в OpenIDE крупно прокачали поддержку Go. Тем временем японская Sakana AI без собственной топовой модели обходит Opus 4.8 и GPT-5.5, а Fable 5 от Anthropic остаётся отключённым по всему миру уже 11-й день подряд.

Всем привет!

Меня зовут Дмитрий Бутенко, я эксперт-разработчик банка Уралсиб.

Всё началось с рабочего созвона в первой половине февраля, на котором упомянули возможность применять модели ИИ прямо внутри инфраструктуры банка. Поначалу речь шла о работе через JetBrains AI Assistant — точечные запросы, ревью, вопросы по проекту. Вопросов, кстати, было много. Но довольно скоро случился переход на OpenCode, и это открыло принципиально другой уровень: не отдельные запросы к модели, а полноценные агенты, которые сами читают файлы, вносят изменения, итерируются по результату.

О том, какими были эти вопросы и задачи, и о том, что из этого вышло — речь пойдёт ниже.

Обычный летний день на проекте: ruff зелёный, mypy зелёный, тесты проходят. А domain при этом тихо импортирует adapters. Слоистая архитектура, которую рисовали на старте, теперь осталась только на схеме.

Линтер ловит неиспользуемый импорт и кривой отступ. Типизатор - что вместо int передали str. А то, что бизнес-логика потащила в себя SQLAlchemy или Redis, не видит никто. Кроме ревьюера, у которого в пятницу вечером открыто восемь PR.

Ниже - как отдать эту проверку машине. Инструмент называется import-linter, ставится за пять минут и встаёт в один ряд с ruff и mypy.

Давно ли вы заходили на Stack Overflow? Только честно. — Я последние года два точно не был. Как-то отпала надобность. Причем даже сами вопросы подобного типа стали неактуальны — не человеческое это дело разбираться, как написать какой-то кусок кода. Это все для нас теперь делают агенты.

Посещаемость некогда сверхпопулярного ресурса для разработчиков упала катастрофически, и его дальнейшая судьба не внушает оптимизма. Остается только надеяться, что случится чудо и Stack Overflow сможет изобрести себя заново в полностью изменившейся среде.

Более пятнадцати лет Stack Overflow был мировым цифровым местом встречи разработчиков. Именно сюда мы приходим, когда в два часа ночи «горит» продакшен, здесь спорим о тонкостях синтаксиса языков программирования и вместе создаем крупнейшую в мире базу технических знаний, проверенную профессиональным сообществом.

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

Однако эта стремительная демократизация выявила серьезную проблему: агентная разработка по своей природе может быть ненадежной. Предоставленные сами себе, миллионы автономных агентов, работающих в терминалах, IDE и конвейерах CI/CD по всему миру, склонны выдумывать устаревшие библиотеки, уверенно использовать уже неактуальный синтаксис и незаметно вносить уязвимости в безопасность. Они чрезвычайно способны, но страдают от фундаментального системного недостатка — они работают в полной изоляции.

Из-за отсутствия общего надежного источника актуальной информации агент в Сан-Франциско может потратить двадцать минут вычислительного времени и бюджет токенов, пытаясь методом перебора найти решение после изменения API, даже не подозревая, что другой агент в Лондоне решил точно такую же проблему всего пять минут назад. Более того, как только сессия пользователя заканчивается, с трудом добытое знание исчезает: контекстное окно агента очищается, а вся остальная экосистема не получает абсолютно никакой пользы.

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

С этим надо было что-то делать.

У меня в Obsidian накопилось под две тысячи заметок. Ежедневники, конспекты, обрывки идей, недописанные черновики. Граф‑вью честно показывает мне облако точек: красиво, но бесполезно. Какие заметки висят сиротами без единой связи, какие дублируют друг друга под разными тегами, какие кластеры тем так и не соединились, из графа не вытащить.

Очевидная мысль: «отдам всё LLM, пусть разберётся». Но 2000 заметок это миллионы токенов. Ни в один контекст это не влезает, а если бы и влезло, стоило бы как крыло самолёта и утонуло бы в шуме.

Так появился идея по созданию Vault Audit AI, плагин для Obsidian, который проводит аудит хранилища через LLM: находит сироты, кластеризует темы, предлагает теги и связи. Я его опубликовал в официальном каталоге и выложил на GitHub. В этой статье разберу инженерную начинку: как обойти лимит контекста через MapReduce, как не платить за повторный анализ, как абстрагировать четырёх LLM‑провайдеров под одним интерфейсом, и что пришлось переделать, чтобы пройти автоматическое ревью каталога.

Код на TypeScript, фрагменты настоящие (слегка почищены от обёрток локализации ради читаемости).

Всем привет, недавно я написал симулятор логических гейтов или вентилей на С++ (sfml для графики + sol2 для интеграции луа скриптов), которые можно программировать на луа таким образом: ```

Здравствуйте. Надеюсь, тут есть люди, которые интересуются вайбкодингом (хотя в списке тем рассылки такой не нашёл, что для меня странно), и уж точно есть те, кто занимается разработкой мобильных приложений. Да, сегодня эти слова очень часто встречаются рядом, что неудивительно. Я большую часть жизни проектировал фронтенд для b2b веб-приложений, но руки всегда чесались в сторону мобильной разработки, случай никак не подворачивался. А тут, как из рога изобилия, посыпались различные ИИ, которые способны после пары абзацев произвольного текста буквально за 5 минут сделать готовое мобильное приложение. Да, я не устоял и попробовал. И доложу я вам, это так. Приложение работает! Но, как говорится, есть нюанс: оно не сильно похоже на то, что вы себе представляли. А уж мне, как дизайнеру, было вообще грустно. Эту грусть я пока не победил, но победил кое-что другое, и это не про дизайн.

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

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

В Python при выборе библиотеки для работы с MQTT почти всегда приходишь к paho-mqtt. Это зрелый и самый популярный клиент, но его API построен на колбэках, а современное Python-приложение живёт в asyncio: FastAPI, фоновые воркеры, асинхронные клиенты и всё это в одном общем event loop.

В одном из IoT-проектов я столкнулся ровно с этим. Мне нужен был MQTT-клиент, который без сложной адаптации встраивается в асинхронное приложение и позволяет работать с подписками как с управляемыми объектами, а не через набор колбэков.

Главная проблема работы с LLM в реальном проекте — не качество модели, а контекст. Рассказываю, как с помощью RAG-индекса репозитория (векторы + граф вызовов) и плагина для Claude Code автоматически собирать правильный контекст по задаче из трекера — без ручного сбора и лишних токенов.

Заметил такую особенность во многих учебных статьях и туториалах: в популярных объяснениях паттернов часто не хватает оговорки, что ради упрощения объяснения в примере нарушены принципы SOLID.

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

Особенно часто это происходит с Factory Method. В этой статье мы разберём несколько популярных примеров этого паттерна, посмотрим, где именно возникает проблема, и обсудим альтернативы в реальных проектах.