Ненормальное программирование *

Я тепломеханик, начальник отдела в проектной организации, в проектировании четырнадцать лет. Программистом не был ни дня, с нейросетями вожусь меньше года. Весной взялся вырастить из слабых локальных моделей рой, который окажется умнее самой сильной из них. Рой не поумнел. Зато по дороге я разложил шесть маленьких моделей по схеме, по которой работает любой проектный институт, и замерил, что из этой схемы держит нагрузку. Держит одно деление на разделы, и слабой модели оно дает больше, чем сильной.

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

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

Блютус обычно воспринимается, как что-то совсем локальное и непригодное для нормальной связи. Но иногда привычные, казалось бы, технологии могут удивить (или нет).

Все вокруг кричат про тотальную цифровую трансформацию, маркировку и ЭДО. Наш ресторан купил красивое готовое решение для импорта документов/поставок, из ЕГАИС в StoreHouse, и импорт документов/поставок из ЭДО в StoreHouse, и другое.

Круто? Да, но только на бумаге.

Крупные федеральные поставщики присылают документы в ЭДО или ЕГАИС, каждый день. Эти документы спокойно импортируются в StoreHouse. А вот мелкие локальные контрагенты (крафтовые производители зелени, сыроварни, поставщики свежего мяса) до сих пор живут в прошлом веке. Им ЭДО не обязателен. Максимум, на что они способны — забить накладную в свой Excel и скинуть менеджеру в Telegram, самый плохой вариант — это мягкие накладные, написанные непонятным почерком.

Итог: каждый день бухгалтер‑калькулятор вынужден руками вбивать по 100–300 строк в StoreHouse.

Год назад я копировал файлы в чат с нейросетью по одному. Сейчас агенты читают проект сами через MCP‑сервер, и месяц наблюдений за ними удивил сильнее, чем вся предыдущая работа: почему текстовое дерево дороже JSON, почему папку build нельзя пропускать по имени, как спрятать пароль и не сломать код, и что агент делает с контекстом, когда его никто не контролирует.

В статье описано, как реализовать многоканальный звук на RP2040 с использованием HD аудиокодека ALC889. Будет краткий разбор интерфейса HDA link и ссылки на пару рабочих демо-проектов с описанием их работы.

Где заканчивается парсинг и начинается решение

Предыстория: около месяца назад подробно обсуждал архитектуру этого проекта в личке с хабровчанкой (не имею права раскрывать ник). Она набросала мощные хардкорные идеи: прикрутить предохранитель на объем выдачи, внедрить счетчик пропусков missed_runs для отсечения ложных удалений и использовать сессии Telethon. До реализации её паттернов руки всё никак не доходили (да и заказчик активно пользовался проектом). Момент настал, а вчера OpenAI выкатила GPT-6 Luna Decisions с её Decisions API. И тут мне в голову пришла альтернативная мысль, о которой эта статья. Мне крайне интересно мнение со стороны касательно изменения проекта.

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

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

В описании Luna Decisions на OpenRouter меня заинтересовал подход: модель возвращает типизированные оценки, а приложение само выбирает действие. Не «напиши, насколько это интересно», а отдельный результат, который можно проверить, сохранить и сравнить с порогом.

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

Сейчас почти всё переехало в Telegram: блогеры, авторитетные ресурсы, СМИ — у каждого свой канал.

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

Я перепробовал всё, что обычно пробуют. Папки — аккуратно разложенный завал. «Сохранёнки» — кладбище, куда всё уходит умирать. Отписаться жалко: а вдруг именно тут выйдет то самое.

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

Когда делаешь голосовой мессенджер на Go, React и LiveKit, медиасервер поначалу кажется самой простой частью: поднял комнату по документации, выдал токен — звук пошёл.

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

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

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

LLM может быть уверена в своём ответе, но это ещё не означает, что системе разрешено выполнять действие. В AI Career Inbox Assistant разделены понимание сообщения, принятие решения и фактическое выполнение действия. Модель извлекает намерение и факты, профиль кандидата остаётся источником истины, а отдельный policy/decision layer определяет, что можно сделать: подготовить draft, попросить пользователя принять решение, ничего не делать или отправить безопасный автоответ при заранее заданных условиях.

На практике это особенно важно для Telegram‑ассистента, который может отвечать от имени пользователя. Ошибка в тексте и ошибочное действие — не одно и то же: второе уже становится архитектурной проблемой. Поэтому в статье разбирается, почему UNKNOWN должен оставаться неизвестным, почему уверенность LLM не должна расширять права системы и почему даже правильное решение требует отдельной защиты на уровне исполнения, например от повторной отправки сообщения.

Главный принцип: уверенность модели — это сигнал для принятия решения, но не разрешение на действие.

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

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

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

Привет, Хабр. Я соло разработчик: студия из одного человека и ИИ ассистента. У нас есть сайт, и на нём живёт «дело №031»: сезонный детектив в формате ARG (alternate reality game). Игрок находит спрятанную папку с делом, ловит голубя свидетеля, читает чужой дневник 1999 года, разгадывает цепочку шифров и в финале выясняет, что расследование было не совсем расследованием.

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

<cut>

Что будет, если production smoke-тесты начнут вести себя почти как настоящие пользователи? В статье рассказываю, зачем я запускаю автоматические проверки прямо в проде, как они проверяют реальные пользовательские сценарии и почему однажды из-за них статистика мессенджера внезапно оказалась слишком оптимистичной. Разберём synthetic traffic, soft delete, искажённые DAU/WAU/MAU и то, как отделять техническую активность от реальной, не отказываясь от production smoke.

В октябре 2013 года яндекс выкупил КП. Для меня на тот момент это ничего не значило, ведь сервис остался прежним и продолжал работать. И перезапуск 2015 года не сильно повлиял на мое мнение, ведь все вернули обратно. Но всё-таки они реализовали свою идею в 2018 году и добавили онлайн просмотр. Следующая неприятность случилась в 2019 году, когда авторизацию сделали только через яндекс. Именно тогда мне и пришлось зарегистрироваться в этой экосистеме. А в 2020 году изменили систему оценок. Все это, несомненно, не доставляло положительных эмоций. Но то, что происходит в последние годы, совершенно другая история...

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

Сейчас узнаем что из этого следует.

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

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

Проблема встаёт в момент, когда человек узнаёт, сколько в реальности нужно собрать, чтобы получить готовый sysroot для, например, QT: объём работы для подготовки сборочной площадки убивает всю выгоду от идеи. Но что если этой работы делать просто… не нужно.

P.S. Да, это Doom в браузере. Опять. А ещё там есть HoMM2. Ссылка на playground в конце статьи, там, в браузере, можно его запустить, и собрать на свой десктоп. И посмотреть другие примеры.

Сейчас у меня регулярно занимаются четыре ученика. Для четырёх человек CRM звучит как избыточное решение. Но проблема оказалась не в числе контактов: один диалог жил в Telegram, другой — в WhatsApp, ещё два канала были VK и MAX. Перед уроком я вручную вспоминал, где написать ученику, отправлял напоминание и искал ссылку на встречу.

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

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

Я не программист. Я модель и писатель. Мне просто надоело печатать, поэтому я попросил ChatGPT помочь сделать собственную голосовую диктовку для Windows. С какими сложностями столкнулся и что из этого вышло?