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

Если вы в последнее время заглядывали в техно-Twitter, то наверняка видели, как люди обсуждают «Ralph Wiggum» так, будто это чит-код. Мемный нейминг делу не помогает, но идея вполне реальна: это официальный плагин для Claude Code, который превращает одиночный промпт в устойчивый цикл. Агент продолжает работать, исправляя собственные ошибки, пока действительно не дойдёт до финишной черты, которую вы задали.

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

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

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

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

Эта статья - продолжение серии, посвященной неожиданным параллелям между недокументированными операциями советских ПМК и концепциями Карлоса Кастанеды. В этой статье разберём обитателей 4 уровня электронного океана: 0С-Оборотней. Для тех, кто не знаком с темой, перед чтением настоящей статьи рекомендуется ознакомиться с предыдущими частями, где эти параллели разбираются подробно.

Язык T — язык системного программирования, аналог языка C для сбалансированной троичной системы счисления. В отличие от двоичных языков, где информация кодируется битами (0 и 1), язык T оперирует тритами — трёхзначными разрядами со значениями –1, 0, +1, которые изображаются символами -, 0, +. Синтаксис языка T близок к C, что делает его доступным для программистов, знакомых с классическим C, но при этом он расширен конструкциями, необходимыми для эффективной работы с троичной логикой и арифметикой.

Был такой процессор в 80х - Intel iAPX 432. Он разрабатывался в качестве преемника 8080 и изначально даже имел кодовое обозначение 8800. Intel заложила в этот процессор очень много всего - абсолютно новая архитектура, совершенно не похожая на предшественников, и даже некоторые концепции ОС, реализованные прямо в кремнии - поддержка объектно-ориентированного программирования, сборщик мусора, планировщик процессов, асинхронные коммуникации, несколько уровней отказоустойчивости и многое другое.

В прошлой статье я разбирал паттерны и необходимость компромиссов в реальной разработке, и там была одна мысль которую я намеренно оставил в стороне. Паттерны редко живут в одиночку, и любая реальная система это не один паттерн, а несколько, склеенных, скрученые, слепленных, и местами прибитых сбоку гвоздями, и каждый из них закрывает только часть проблемы. Менеджер ресурсов это, наверное, самый показательный пример такой склейки, потому что снаружи он обычно выглядит как пару строчек видаLoadTexture("bark.dds"), а внутри это кэш, политика дефолтов, механика восстановления после сбоя и ещё полдюжины вещей, каждая из которых прошла через пот, кровь и пиксели и осталась в архитектуре этой системы.

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

Понятие "определенная форма" тем не менее тоже звучит абстрактно, поэтому люди предпочитают использовать "текстуру", "меш", "звук" и т.д. Но одну и ту же текстуру wall.dds, которую можно загрузить в DXT5 со сжатием, sRGB и mip-фильтром box, а можно без сжатия, в линейном пространстве и с другим фильтром. Формально у нас был один файл на диске, но с точки зрения ресурсного менеджера теперь это два разных "ресурса", потому что их параметры различаются. Подмена одного ресурса другим в рантайме может сломать игру, потому что игра ожидает определенных данных для шейдера, которая изменилась после фильтра или определённую раскладку мипов, которой может не оказаться.

Более явный пример для шейдеров будет, когда lighting.fx, скомпилированный с дефайном SIMPLE_BUMP_MAPPING, и lighting.fx, скомпилированный с PARALLAX_BUMP_MAPPING, физически выглядят в исходниках как один файл, но дают два разных пайплайна, со своими константными буферами и со своими ожиданиями к набору текстур, а если ресурсный менеджер этого не понимает, то он либо начнёт раздавать второй вариант, когда просят первый.

С мешами история та же самая, и ship.mesh, загруженный в менеджере ресурсов, и тот же ship.mesh, лежащий в GPU это два разных объекта, у которых даже время жизни и поведение при потере устройства будут отличаться, не говоря уже о том, что первый мы можем менять, а в второй нет.

В фольклоре разработчиков встречаются утверждения о том, что Jira (система управления проектами, разработанная Atlassian) полна по Тьюрингу. Однако в таких заявлениях нет конкретики, лишь смутные упоминания фич автоматизации. В этой статье будет приведено доказательство с инструкциями по реализации и трассировкой исполнения.

Полное руководство по аппаратному мультиколору для тех, кто не знает, что это такое и зачем он нужен.

У меня есть книга, которая называется Game++ и несколько статей, где я разбирал какие паттерны применяются в играх и движках. В книге почти сто страниц отведено про эти самые паттерны и подробно рассказано какие они бывают, как выглядят в C++, где у них подводные камни и как их применять. Т.е. ровно те мелочи реализации, которые обычно интересно перечитать, когда вы в очередной раз решаете делать фабрику отдельным классом или попробовать обойтись std::function. Когда я её писал, мне казалось, что это будет очень полезный практический текст, и он таким и получился, и человек с опытом довольно быстро находит там нужное.

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

Если вам вдруг надоест читать эти 106 минут, там в конце есть TL;DR секция, где собрано краткое описание.

В прошлой статье я разобрал, как работает квалифицированный поиск и как using namespace участвует в нём только в качестве запасного варианта, когда собственных объявлений в указанной области нет. Компилятор сначала смотрит, что объявлено непосредственно в текущем контексте, и только при неудаче переходит к именам, подмешанным через директиву using. Казалось бы, схема прозрачная и предсказуемая: есть область поиска, есть приоритет явных объявлений, есть «правило N-объявлений» как страховка.

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

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

Бывают дни, когда на работе делать нечего. А бывают дни, когда ты — программист и звукорежиссёр одновременно, и в голову приходит странная мысль: «А что, если взять аудио, превратить его в картинку-спектрограмму, сжать эту картинку как фотографию (JPEG, WebP, AVIF), а потом попробовать восстановить звук обратно? Как оно будет звучать?»

Спойлер: иногда — удивительно хорошо. Иногда — как из унитаза. Но всегда — интересно.

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

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

Иногда шутят, что когда разработчик переносил игру с PS2 на Xbox, то первое что он делал это выбрасывал систему управления памятью и писал новую с нуля, потому что 32Мб плюс 4Мб плюс 2Мб не помещается в 64Мб.

Для чтения этой статьи вам не потребуется знать ассемблер или работать с конкретными SDK. Достаточно понимать, что такое указатель, чем стек отличается от кучи и что рендерить геометрию параллельно с её обновлением плохая идея, и что классические GPU и CPU паттерны работы по-разному нагружают память.

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

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

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

Поэтому давайте поставим себе задачу чуть более сомнительную, чем следовало бы: воспроизвести Bad Apple в браузере без JavaScript вообще, опираясь почти целиком на CSS и немного на серверную магию.

Ну и чтобы окончательно не сбивать градус абсурда, бекенд мы тоже не будем писать на чем-то скучно-прагматичном. Если заниматься таким делом, то с достоинством: C++26 и Boost.Beast.

Результат посмотреть можно тут и на GitHub.

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

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

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

Потому что в то жаркое лето я познакомился с демосценой.

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

Однако что если ли у вас нет доступа к последним новшествам? Если у вас на руках только кусок металлолома 20-ти летней давности? А все вендоры и поставщики давным-давно от вас отвернулись?

Казалось бы, современный С++ дает столько возможностей… Давайте попробуем препарировать всю эту необъятную мощь, начав с первого шага в любом языке программирования — «Hello World».

Как реализации компиляторов встречают новичка, впервые написавшему свои первые строчки кода?

Всем привет!

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

Начну с предыстории. В 2022 году я переехал в Грузию, в Батуми. Здесь я практически сразу начал учить язык, и мне захотелось чуть упростить себе этот процесс — сделать это я решил с помощью своего Telegram-бота. Почему бота? Всем известно, что материал усваивается быстрее и проще, если не садиться за него раз-два в неделю, а стараться изучать что-то небольшое каждый день. Тут мне бы очень помог Duolingo. Но там грузинского нет, хотя есть клингонский. Короче, было решено сделать свой Duolingo из Telegram-бота, только для грузинского.

Сначала получилось что-то совсем простое: перевести / сохранить слово / устроить с новыми словами квиз. Долгое время этого функционала мне хватало, и бот я не развивал, но вот решил попробовать автоматизировать его при помощи современных LLM. Идея была такая — ночью агенты кодят. А утром я читаю чейнджлог и наслаждаюсь новыми функциями. Что получилось на деле —можно почитать под катом.

Это продолжение темы начатой в статье Важны ли компилятору имена, и продолженной в Ночью все кошки серы, а using'и одинаковы, и далее в Компиляторы тоже путаются в именах. Если не читали, то лучше будет пробежаться по диагонали. Теперь вот мы подобрались к такой интересной теме, как квалифицированный и неквалифицированный поиск.

Что такое простой поиск(неквалифицированный) имени n в области S? Это механизм компилятора, который находит все объявления n, находящиеся непосредственно в этой области. Просто? С виду да, но даже этот простой механизм часто работает не так, как ожидает разработчик.

Например, у нас есть пространство имён N и локальная переменная N. Они могут сосуществовать вместе? Могут, потому что находятся в разных областях видимости. А пространство имён и глобальная переменная с тем же именем могут? Как же мы докатились до жизни такой, давайте разбираться.