Сохранёнки программиста

Разработчик Эрик Ленгьел (Eric Lengyel) сделал огромный подарок для индустрии графики и геймдева. Он досрочно, за 12 лет до истечения срока, передал патент на свой знаменитый алгоритм Slug в общественное достояние.

Slug — это метод рендеринга шрифтов (и векторной графики) на GPU напрямую из кривых Безье, вообще без использования предзапечённых текстур или атласов. Это позволяет отрисовывать идеально чёткий, сглаженный текст любого размера и под любым углом. Алгоритм уже 10 лет является индустриальным стандартом: лицензию на него покупали Blizzard, id Software, Adobe, Ubisoft и другие гиганты.

Главная математическая фишка последних версий Slug — это «динамическое расширение» (dynamic dilation). Вершинный шейдер на лету высчитывает матрицу трансформации и автоматически расширяет полигон каждого глифа ровно на полпикселя в экранном пространстве. Это гарантирует, что растеризатор не потеряет ни одного сглаженного пикселя на границах букв, и при этом не тратит ресурсы GPU на отрисовку лишнего пустого пространства (как это бывает при фиксированном отступе).

Теперь использовать эту технологию можно абсолютно бесплатно в любых проектах. Автор уже выложил эталонные шейдеры (вершинный и пиксельный) на GitHub под лицензией MIT: https://github.com/EricLengyel/Slug

@prog_stuff

BYOVD: как детектить атаку, если EDR слаб перед ней

Есть такая техника, при которой EDR — мощнейшее ПО для мониторинга, обнаружения и реагирования на угрозы — бессессильно. Эта техника называется BYOVD (Bring Your Own Vulnerable Driver). С ее помощью злоумышленники проникают в систему, повышают привилегии и потом совершают мошенничество. Именно BYOVD был одним из ключевых этапов при атаках на СДЭК, Аэрофлот, «Верный».

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

На Tproger вышла статья со сравнением антивирусов специально под рабочие процессы разработчиков.

Главная проблема такого софта в том, что он часто тормозит тяжёлые сборки или ошибочно блокирует нужные утилиты.

Коллеги из редакции сайта проверили:
— Насколько сильно фоновые проверки нагружают систему в рабочие часы.
— Как разные продукты справляются с изоляцией подозрительных скриптов и фишингом.
— За какие дополнительные функции действительно стоит платить из своего кармана.

Полная статья: https://tproger.ru/articles/kakoj-antivirus-my-vybrali--proverili-3-antivirusa-po-cene--aler

@prog_stuff

Интересная мысль из недавних обсуждений: «ИИ не сделает вас богатым, а вот починка багов в сгенерированном ИИ-мусоре — сделает». Сейчас все увлеклись генерацией кода: джуны, менеджеры и стартаперы штампуют проекты целыми кусками с помощью Claude и Copilot. В результате на свет появляется так называемый «AI slopware» — код, который вроде бы работает на демо-стенде, но внутри представляет собой неподдерживаемое спагетти.

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

Автор поста считает, что золотая лихорадка ИИ-стартапов и бесконечных «ChatGPT-обёрток» скоро пойдёт на спад. А вот горы некачественного, сгенерированного кода останутся в корпоративном секторе на десятилетия.

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

Умение вслепую промтить нейросети перестанет быть преимуществом. Главным навыком снова станет фундаментальное понимание того, как работают технологии.

Полный текст: https://boreal.social/post/ai-wont-make-you-rich-but-fixing-bugs-in-ai-slopware-will

@prog_stuff

В блоге NixCI вышла отличная статья, которая ставит под сомнение привычный всем нам процесс работы с непрерывной интеграцией. Обычно мы воспринимаем CI как удалённый сервер (GitHub Actions, GitLab CI), куда мы пушим код и ждём заветную зелёную галочку. Но у этого подхода есть огромный минус — длинная петля обратной связи.

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

Автор предлагает концепцию Local-First CI. Идея в том, что вся пайплайн-логика должна быть описана так, чтобы она могла локально выполниться на машине разработчика до пуша в репозиторий.

Какие плюсы у локального CI:

— Скорость. Рабочие машины разработчиков (особенно современные Mac) часто гораздо мощнее стандартных бесплатных раннеров (у тех же GitHub Actions всего 4 vCPU и 16 GB RAM).

— Фокус. Вы не переключаете контекст. Ошибка падает сразу, и вы фиксите её, оставаясь в потоке.

— Отсутствие вендор-лока. Если весь ваш CI — это условный баш-скрипт ./ci.sh в корне проекта, вам всё равно, где его запускать. Вы не привязаны к специфичным YAML-файлам конкретного провайдера.

— Локальная воспроизводимость. Больше не нужно делать коммиты с названиями fix ci, try again, maybe now?, пытаясь вслепую угадать, почему тест падает на сервере, но работает у вас.

Есть и минусы, конечно.

Главная проблема наивного подхода с ./ci.sh — рассинхрон сред. У вас локально macOS и gcc 15, а на сервере Ubuntu и gcc 14. У вас замусоренная папка с билдами и завалявшийся .env, а CI стартует с чистого листа.

Решением автор логично называет воспроизводимые сборки (reproducible builds), в частности — использование Nix. Команда nix flake check гарантирует, что локальное и удалённое окружение будут абсолютно идентичными вплоть до версий системных библиотек . Но даже без Nix, максимальный перенос логики проверок в локальную среду (например, через Docker) — это отличная практика для ускорения разработки.

Полная статья: https://blog.nix-ci.com/post/2026-03-09_ci-should-fail-on-your-machine-first

@prog_stuff

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

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

Полная статья: https://richwhitehouse.com/index.php?postid=77

@prog_stuff

Scientific American собрали свежую статистику о том, как нейросети влияют на жизнь разработчиков. Изначально все надеялись, что ИИ разгрузит инженеров, но реальные цифры показывают обратную картину: программисты стали работать больше и чаще перерабатывать по вечерам.
​
Главные причины такого парадокса:

— Падает стабильность релизов. Нейросети выдают код мгновенно, но его нужно тщательно проверять. Отчёт DORA подтверждает, что активное использование ИИ напрямую связано с ростом откатов и горячих фиксов на проде.
​
— Растут ожидания руководства. Бизнес замечает ускорение и требует закрывать больше задач. В итоге инженеры берут дополнительный объем, а количество их коммитов в нерабочие часы выросло почти на 20%
​
— Усложняется отладка. Инженеры объективно хуже понимают сгенерированную логику. Когда такой код ломается, на поиск причин и исправление багов уходит гораздо больше сил.
​
Получается, что инструменты действительно ускоряют написание новых блоков, но вся экономия времени полностью сгорает на этапах тестирования и ревью. А если вы начинаете писать код быстрее, в качестве награды менеджеры просто накидывают вам больше новых тикетов.

Полная статья: https://www.scientificamerican.com/article/why-developers-using-ai-are-working-longer-hours/

@prog_stuff

Если вы когда-нибудь работали в кровавом энтерпрайзе на Java, этот репозиторий может вызвать у вас флешбеки и легкую панику. Разработчики создали пародийный проект FizzBuzz Enterprise Edition — ту самую задачу с собеседований про деление чисел на 3 и 5, но написанную «серьёзными бизнесменами для серьёзных бизнес-целей».
​
Вместо десяти строк кода авторы наворотили гигантскую архитектуру. Внутри бесконечные вложенные папки, десяток фабрик, интерфейсы для интерфейсов и классы с названиями в духе FizzBuzzOutputGenerationContextVisitor.
​
Отдельный вид искусства в этом проекте — раздел Issues. Пользователи активно подыгрывают авторам и создают гениальные тикеты. Например, кто-то пожаловался, что код написан слишком качественно и потребовал ухудшить его, чтобы соответствовать реальным индустриальным стандартам. Или предлагают уволить бизнес-аналитика, потому что он слишком понятно объяснил задачу, и требуют добавить больше уровней абстракции, чтобы никто не смог найти, откуда импортируется код.

@prog_stuff

Как эволюционировали OCR-программы

Инструменты для распознавания текста (OCR) появились еще в 1960-х, но только последние 20 лет они используются для чтения документов и облегчают нашу с вами жизнь.

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

Посмотрите на этот безумный проект. Полноценный эмулятор процессора архитектуры x86 на чистом CSS. Никакого JavaScript или WebAssembly, все вычисления происходят исключительно силами браузерного движка стилей.

Как это реализовано технически:
— эмулятор исполняет реальный машинный код для процессоров 8086;
​— тактовый генератор построен на CSS-анимациях, поэтому система работает автономно и не требует от пользователя постоянно водить курсором по экрану;
​— логика работает благодаря новым спецификациям CSS, таким как условные операторы if(), стилевые запросы и кастомные функции

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

Практического применения у проекта нет, производительность получается крайне низкой. Зато это отличная демонстрация того, что современный CSS действительно стал тьюринг-полным языком программирования. Из-за использования экспериментальных функций запустить демку пока можно только в браузерах на базе Chromium.

@prog_stuff