Отладка *

В Lua достаточно забыть local перед переменной, чтобы получить баг, который может долго оставаться незамеченным. По отдельности функции работают исправно, тесты проходят, а после подключения нового модуля внезапно начинают пропадать данные или меняться результаты вычислений. Разберёмся, как глобальные переменные создают такие ловушки, чем опасны манипуляции с G и ENV и как защитить код от ошибок, зависящих от порядка вызовов и загрузки модулей.

Harness — построение инфры вокруг LLM таким образом, чтобы man in the loop (человек в процессе поддержки LLM) отсутствовал.

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

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

Реальный продакшен-инцидент: пул соединений забит, активных запросов дюжина, рестарт помогает. Claude нашёл причину за двадцать минут. Нормальный человек на этом обновил бы библиотеку и пошёл дальше, но у меня две RTX 5090 стояли без дела, и зудел вопрос: а локальная 27B-модель смогла бы? Тот же промпт, тот же код, та же песочница, семь локальных моделей, около 40 прогонов. В промпте, кстати, осталась одна правдоподобная, но ложная гипотеза инженера. Я не планировал делать из неё ловушку. Она стала главным фильтром всего эксперимента.

Всем привет! Меня зовут Игорь Белов, я инженер в команде Мобильной Архитектуры Авито. Больше 6 лет занимаюсь iOS-разработкой, а ещё мне нравится изучать фундаментальные темы Computer Science и разбираться, как те или иные вещи работают под капотом.

В статье я расскажу, как исследовать произвольные приложения macOS с помощью отладчика LLDB и сопутствующих инструментов, и тем самым прокачать свой повседневный инструментарий разработчика. Сначала исследуем произвольно запущенные процессы в macOS с помощью LLDB. Затем на основе собранных знаний сделаем инъекцию своего кода, чтобы изменить их поведение. Ещё немного затронем теорию, подготовим и настроим окружение. В конце я посоветую, что почитать, чтобы углубиться в тему.

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

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

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

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

Хочу показать, как эти проекты связаны и где могут пригодиться.

Наивность, fail-fast, fallback, failback, оптимизация и стратегия — на слизне, на кухне и на JavaScript

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

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

В прошлой статье я сделал обзор популярных способов отладки embedded: GDB-клиент -> GDB-сервер (OpenOCD) -> программатор -> целевой МК. Тогда я сформулировал свои субъективные требования к “идеальному” программатору. И на тот момент у меня уже был минимально рабочий вариант такого программатора. И вот спешу представить к чему привели меня изыскания в этом направлении.

Мы переводили карту парковок с растровой подложки на векторные тайлы и получили чёрный экран. Без единой ошибки в консоли: ни исключения, ни предупреждения, идеально чистый лог. Единственной уликой оказалось отсутствие запросов за тайлами — воркер MapLibre не попал в сборку, потому что Rollup не умеет разбирать шаблонную строку в new URL(…, import.meta.url). Разбираем этот баг и ещё два из той же серии: как смена города убивала Leaflet и почему событие load у карты не наступает никогда.

Спросил у Claude Code «Ответь одним словом: работает». Двадцать девять символов. На сервер ушло 305 042 байта — 113 460 токенов, ответ из четырёх.

Поставил между агентом и сервером прокси на сорок строк Python и разобрал тело запроса по частям. Системный промпт — четыре процента. Восемьдесят пять процентов — описания 137 инструментов, из которых 107 принёс один MCP-сервер, которым я в этой сессии не пользовался. Ещё 29 тысяч символов добавил хук плагина. И на каждый ход уходит второй запрос, о котором я не просил.

То же самое проделал с Codex CLI: 29 килобайт, 9 817 токенов, а системный промпт при этом такой же длины. Дальше — таблица, что убирается флагами (один MCP-сервер стоил 52 тысячи токенов на запрос), что это значит для окна и кэша, и скрипт, чтобы посмотреть свой первый запрос.

За полгода Tailscale 19 раз столкнулась с повреждением баз SQLite, но воспроизвести сбой не удавалось: между инцидентами проходили то часы, то недели. Инженеры собирали диагностику прямо в продакшене, проверяли одну гипотезу за другой и в итоге нашли редкую гонку между записью и созданием контрольной точки — баг, который скрывался в SQLite минимум 16 лет.

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

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

Если у вас когда-нибудь ломалась SD-карта, то вы знаете, как обычно решают эту проблему: снова попробовать вставить её в фотоаппарат, сменить кард-ридер, проверить на другом компьютере и, если вообще никто её не обнаруживает, признать карту мёртвой.

Но почему она умерла?

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

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

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

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

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

Я уже думал писать статью, но решил мимолетом запустить 175 воркеров. Это решение создало неожиданную проблему - задача оказалась обработана за 11 секунд до ее создания.

Привет, Хабр! Пилю потихоньку пет‑проект и решил поделиться тем, что вылезло при первом же деплое.

Откуда взялась эта штука 

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

Пока задач несколько, они держатся в голове. Дальше начинается путаница: помнишь, что на этой неделе у кого‑то обновление, а у кого именно — уже нет. Я начал забывать про клиентов. Писал на бумажке. Бумажка не работает по простой причине: про неё тоже надо вспомнить. Она лежит рядом и молчит. А напоминание должно приходить само и туда, где я и так сижу целый день. Так и родилась мысль сделать свой блэкджек.

Мой сервис обрабатывает большой поток PDF от самых разных генераторов. В начале июня один‑единственный файл уложил его на 30 минут: HPA раздул поды до потолка, и все они наглухо повисли, 100% CPU, обработка стоит, очередь копится, алерты сыпятся пачками. Расследование в трёх актах: ложный подозреваемый, закомментированный panic и санитайзер, не знавший алфавит до конца.

Всем привет! Меня зовут Илья Данилкин, я тимлид в Авито Авто.

AI-агенты обычно живут рядом с Python, но всё же немало команд выбирают язык Go. Дело в том, что агенты большую часть времени не заняты сложными математическими расчётами, а ждут ответа модели или результата инструмента. А ещё работают в режиме бесконечных параллельных запусков. И если пользователь останавливает задачу, его запрос и следующие вызовы инструментов тоже нужно остановить.

Поэтому при выборе языка важны не только библиотеки для работы с моделями, но и то, как язык справляется с одновременными задачами, отменяет операции и насколько просто доставить готовое приложение пользователю. В Go для этого есть дешёвые горутины, context.Context и сборка в один бинарник.

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

Сервис жив, CPU в норме, паники нет — а часть запросов зависает на минуты. В async‑Rust привычный стек часто мало помогает: задача могла застрять на блокирующем вызове, мьютексе или просто перестать получать пробуждения.

Разбираем, как отличать эти сценарии в Tokio и куда смотреть, когда отладчик молчит.

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

Может ли лишняя запись в yarn.lock повесить браузер? Наша прожила в репозитории три месяца, не привлекая внимания, а потом ночью после релиза положила прод вечным лоадером - причём только в Chromium. Рассказываю, как мы шли к разгадке через ложные следы и что в итоге оказалось в рантайме.

Я делаю NotiBox — Pusher‑совместимый сервис realtime уведомлений. Под капотом я использую Sockudo — WebSocket сервер на Rust. Прежде чем показывать реальным пользователям, я решил проверить, на сколько Sockudo на самом деле «blazingly fast».

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

Идеальный сценарий — полная загрузка процессора, памяти или сети, тогда ты реально нашёл предел ресурсов. Проверяешь масштабируемость и готово.

Другой сценарий — ничего не перегружено, но новые соединения/запросы не проходят, растёт задержка ответов. Это тоже ожидаемо и понятно как чинить: смотришь на TIME WAIT сокеты, max open files, и другие «предохранители».

А что делать, если там тоже всё по нулям? Вот тут начинается настоящее приключение.