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

Завершение серии статей о параллелях между недокументированными операциями советских ПМК и концепциями Карлоса Кастанеды. Начало тут...

AI должен был сделать мою работу легче. Он сделал. Только вместе с этим куда-то пропало ощущение, что я вообще что-то создаю

Приветствую всех!

Думаю, при упоминании знаменитого бага в процессоре Intel Pentium на ум сразу приходит ошибка деления. Но, как оказывается, она была не единственным косяком этих чипов.

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

Эта статья, по сути, родилась как развёрнутая версия комичной зарисовки, которую вы видите выше.

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

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

или как уместить Вселенную в iPhone, не привлекая внимания санитаров

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

Автор проекта «ЭХО» взял и убрал всё лишнее. Без предупреждения, без RFC, без голосования в команде. Остался минимальный Linux, один бинарник на Go и файловая система — всё остальное полетело в мусор вместе с базами данных, фреймворками и «чёрными ящиками» с гарантией на три года. Получилась система на 250 миллионов анкет, которая работает на обычном пользовательском компьютере и не требует звонить в поддержку AWS в два часа ночи.

Но 250 миллионов — это как-то мелко, правда? Давайте замахнёмся на Вселенную. Ну или хотя бы на Млечный Путь для начала.

Одной из самых сложных частей C++ до сих пор считаются правила поиска имён, и ошибки связанные с name lookup проявляются обычно уже в рантайме. Код компилится и даже работает какое-то время, но при свете луны ведёт себя не так как ожидает программист. За простыми идентификаторами скрывается многоуровневая система областей видимости, категорий имён и специальных правил, и очень многое в нашем текущем стандарте растёт прямиком из восьмидесятых, частенько без изменений. Давайте посмотрим как компилятор видит имена в C++, какие области видимости существуют и почему они ведут себя по-разному.

В C++ есть несколько типов областей видимости, вы наверное сходу назовёте глобальное пространство имён, область параметров шаблона, область видимости класса и область параметров функции, но также есть блочная область видимости и область видимости перечислений. Между этими областями есть исторически сложившаяся асимметрия, которая частенько удивляет: два объявления using, которые вводят одно и то же имя в одну и ту же область видимости внутри пространства имён компилятор съест без возражений, но если попытаться сделать то же самое других областях видимости, то получим ошибку на повторное объявление. В серии статей про "нескучное программирование" я разбираю скользкие случаи и как мы докатились до такого. Это продолжение темы, начатой в "Важны ли компилятору имена", поэтому чтобы картинка была цельной, лучше пробежать её по диагонали.

В C++ уже есть корутины. Есть диапазоны. Есть готовые библиотеки.

Но это не мешает взять гаечный ключ и начать собирать генератор вручную.

В предыдущей статье макросы внезапно начинают изображать из себя язык: DO, LET, IS управляют препроцессорным ритуалом и создают DSL. Это синтаксис. Это оболочка. Это фронтенд.

(чтение предыдущей статьи необязательно для понимания этой)

Но ведь есть не только синтаксис, можно создать и конкретную семантику — генераторы.

В этой статье я строю велосипедный генератор. Самый честный.

RooCode — расширение для VS Code с многоагентной системой (встроено 5 Модов: Orchestrator, Ask, Architect, Code, Debug)
Ключевые преимущества: синхронное выполнение задач (предсказуемость), гибкая настройка модов, MCP-серверы для снижения ошибок и количества запросов к LLM
Основная идея настройки: каждый Мод отвечает за свою задачу, Оркестратор распределяет работу между ними
Настройка идёт по спирали: от базовых настроек → скиллы → моды → провайдеры → итеративное улучшение

В январе 2023 мне пришла в голову идея: а почему бы не управлять своими серверами так же, как я управляю своими проектами — через docker compose up.
Довольно быстро стало понятно, что до меня в эту сторону массово не ходили, если кто так уже делает, то делает это молча… т.е. на все детские грабли на этом пути мне придётся наступить лично.
А вот вам повезло: если тоже захотите пойти в эту сторону, то у вас уже есть и эта статья и пример конкретной реализации.

Кому этот подход может подойти? Тут должны сойтись звёзды несколько факторов:

● Нужно быть программистом, хорошо знакомым с docker-compose.yml.
● Нужно иметь 1-5 личных серверов — не важно, дома или на обычном/облачном хостинге, настоящий ли это сервер или свой десктоп/ноут, выполняющий заодно и функции «сервера».
● Нужно иметь достаточно опыта настройки этих серверов вручную по ситуации, чтобы появилось понимание недостатков этого подхода и желание внедрить IaC (перенести конфигурацию серверов в git и сделать её легко воспроизводимой).
● Но главное — нужно не быть админом, которому Ansible привычнее. 😄

Рассказываю, как я сделал простейший yaml сервис на Java и Vue для разовой загрузки данных, чтобы не писать тонны кода и не мучиться с JSON.

Предыдущая часть: Enovia умерла, да здравствует JMatrixPlatform: пересобираю легендарную платформу на Java и Vue

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

На написание этой статьи вдохновил этот пост: Learn x86-64 assembly by writing a GUI from scratch. Программу из статьи перепишем с nasm на fasmg и сократим размер исполняемого файла примерно на треть.

Я хотел потроллить друга — сделать самый бесполезный статистический сайт в мире. Попросил AI влепить cookie-баннер по приколу. Шутить не просил. А получил целую панель, где каждая категория — отдельная шутка. И понеслось: 6 разделов, специальный humor guide в CLAUDE.md. И еще AI отказался шутить на белорусском.

Продолжение серии статей о параллелях между недокументированными особенностями советских ПМК и концепциями Карлоса Кастанеды, начало — тут..

А что если установить на mac mini Qwen Code CLI, подключить к нему Wolfram Engine и начать управлять этим со смартфона из Delta Chat?

Знакомая ситуация: просишь Claude Code добавить авторизацию — он переписывает половину проекта. Просишь поправить одну функцию — получаешь удалённые тесты и новую зависимость, о которой не просил. За час строишь рабочий прототип, а потом три часа разгребаешь то, что Claude наворотил при «улучшении».

Я Python-бэкенд разработчик, веду свою компанию CREATMAN и кожу в основном один. У меня нет роскоши держать QA-инженера, который будет ловить регрессии после каждого промпта. Мне нужно, чтобы AI-агент помогал быстрее шипить, а не создавал новые проблемы.

После нескольких недель исследования — чтения доков, обсуждений на Reddit, разбора чужих сетапов — я собрал конфигурацию, которая реально работает. Собрал всё в открытый репозиторий с готовыми файлами: claude-code-antiregression-setup. В этой статье — что именно и почему.

Запуск современных Text-to-Video моделей локально — задача не для слабонервных. Когда китайские исследователи из PKU-YuanGroup выложили в open-source свою модель Open-Sora-Plan, энтузиасты бросились её тестировать. Но есть нюанс: оригинальный пайплайн рассчитан на кластеры уровня H100/A100. Веса модели в полном разрешении занимают десятки гигабайт.

Моя цель заключалась в том, чтобы запустить инференс Open-Sora-Plan (v1.3.0) в спартанских условиях — на абсолютно бесплатном инстансе Google Colab с видеокартой NVIDIA T4 (15 ГБ VRAM, архитектура Turing 2018 года) и 12.7 ГБ системной ОЗУ.

Спойлер: скрипт отработал от начала и до конца без OOM (Out of Memory). Но для этого нам пришлось вскрывать исходники, бороться с аппаратными лимитами GPU и в прямом смысле делать нейросети математическую «лоботомию».

Продолжение серии статей о параллелях между недокументированными особенностями советских ПМК и концепциями Карлоса Кастанеды, начало — тут..

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

В этой части мы продолжим знакомство с неорганическими существами из глубин электронного океана, описанных в журнале Техника‑Молодёжи, а я расскажу о тех аналогиях, которые увидел в девятой книге Кастанеды — «Искусство сновидения».

В предыдущей статье мы открыли окно. Теперь давайте его не просто игнорировать.

Как на счёт вкорячить в него поддержку OpenGL?

Это ведь когда-то должно было произойти...

В мире уже есть примерно бесконечное количество туториалов формата "OpenGL Tutorial" (раз, двас).

Возникает логичный вопрос: Зачем ещё один?

Ответ: Чтобы наконец перевести их!

Так что я просто их решил перевести с С/С++ на PHP. А вы что подумали? Я с английского их переводить собрался?

Продолжение серии статей о параллелях между недокументированными особенностями советских ПМК и концепциями Карлоса Кастанеды, начало — тут...