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

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

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

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

Например, эта машина потребляет 50% ресурсов CPU, поэтому, вероятно, способна выполнять вдвое больше своих задач.

Однако когда владельцы пытаются реально проецировать эти значения, то оказывается, что процент использования CPU на самом деле растёт не совсем линейно. Но насколько непрямой может быть зависимость?

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

Недавно на Youtube появилась документалка о Python. Примерно в середине ленты есть драматический эпизод о том, как переход от Python 2 к 3 разделил сообщество (спойлер: в конечном итоге этого не случилось).

Первые версии Python 3 (3.0-3.4) в основном делали упор на стабильность и упрощение перехода пользователей с версии 2.7. В 2015 была выпущена версия 3.5 с новой фичей: ключевыми словами async и await для выполнения корутин.

Миновало десять лет и девять релизов, через считанные недели выпустят финальную версию Python 3.14.

Пока все отвлеклись на фичи разноцветного REPL в 3.14, в release notes появились серьёзные заявления, связанные с конкурентностью и параллелизмом.

Что такое встроенная сеть (embedded network)? Мне довольно сложно было найти подходящее название для этого явления, но я очень часто с ним сталкивался, и поэтому придумал своё. Хорошим примером может служить портативная видеостойка. Допустим, вы таскаете стойку с видео- и сетевым оборудованием, и вам нужно подключать её к сети на месте проведения мероприятия для стриминга в Интернет. Устройства в стойке должны общаться друг с другом, но вы не хотите заново конфигурировать их адреса каждый раз, когда приезжаете на новое место, потому что в нём используется другая подсеть.

Решить эту проблему очень просто! Достаточно добавить в стойку небольшой маршрутизатор, чтобы у вас была постоянная подсеть, а NAT изолирует вас от изменения IP-адресов снаружи вашей маленькой сети. Ваша стойка имеет адреса 10.0.0.0/24, потому что их легко запомнить, а маршрутизатор получает IP-адрес на месте при помощи DHCP.

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

На этом этапе часто начинают выбирать для портативного оборудования странные подсети. «Каковы шансы, что на месте будет использоваться подсеть 172.16.42.0/24 или 10.11.12.0/24?» И да, это будет работать, но однажды у вас возникнет конфликт, потому что люди попросту не очень хорошо справляются с выбором случайных чисел. На самом деле, необязательно, чтобы сеть зависела от случайности, вам просто нужны другие возможности маршрутизаторов, нечасто применяемые в стандартных потребительских моделях.

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

Тогда почему нас может интересовать, как замедлять программы?

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

• Отправляем ввод контроллера с машины А на машину Б по сети

• Б рендерит кадр на GPU

• Б кодирует кадр в битовый поток

• Б отправляет результат по сети машине А

• A декодирует битовый поток

• A отображает изображение на экране

• В мозге цели высвобождается дофамин

Каждый этап в этой цепочке повышает задержки, а нам нужно их как можно сильнее минимизировать. Обычно в качестве решения используется ускоренное GPU сжатие видео при помощи какого-нибудь кодека, обычно H.264, HEVC или, если хотите заморочиться, AV1. В идеале весь процесс должен выполняться примерно за 20 мс.

При создании пустой 3D-сцены в Godot редактор выставляет стандартные параметры освещения и окружения. Благодаря этому можно приступать к работе над сценой, не подбирая освещение и фон для чёрной, как ночь сцены. Выглядит это примерно, как показано на скриншоте.

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

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

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

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

Здесь важно сказать следующее: игры — это не физические движки, а впечатления. И гоночные игры больше других намеренно манипулируют реальностью, чтобы дать нам эти впечатления. Например, мы ожидаем от шутеров определённого поведения; пуль, летающих по прямой, отдачу при выстрелах, перезарядку. Если эти ожидания не оправдываются, игра начинает казаться «не такой». Но в случае транспорта степень допущений может быть огромной.

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

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

OKLCH — это довольно новая цветовая модель, разработанная для обеспечения визуальной однородности. Это означает, что цвета гораздо точнее с точки зрения восприятия человеком, что упрощает работу с ними.

Недавно я написал Space Invader Generator в рамках соревнований по кодингу Creative Coding Amsterdam. Разумеется, я сделал это ради развлечения... но и для господства над галактикой тоже! На скриншоте показано, как он выглядит, а в посте я объясню, как он работает.

С ростом популярности в 1997 году технологий Flash и CSS возникло три философии веб-дизайна. Дэвид Сигел продвигал «хаки», Джейкоб Нильсен стремился к простоте, а Джеффри Зельдман комбинировал элегантность с удобством пользования.

Как и многие из первой волны веб-дизайнеров, Джеффри Зельдман, которому в начале 1997 года исполнилось 42 года, начинал свою карьеру в совершенно другой профессии. Изначально он был автором художественных книг, недолго поработал журналистом, пробовал себя в качестве разъездного музыканта, а потом десять лет посвятил рекламному бизнесу. «Сочинение текстов билбордов с цепляющей графикой — хорошая практика для веба, потому что в нём нужно доносить информацию мгновенно», — рассказывал он позже в интервью.

Творческих людей наподобие Зельдмана привлекло в веб развитие мультимедиа; сам он создал свой первый веб-сайт в 1995 году. «Благодаря гипертексту появился веб, благодаря графике он стал игровой площадкой для потребителей», — писал он на своём личном веб-сайте в конце 1996 года.

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

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

До недавнего времени я по большей мере игнорировал этот ажиотаж. Я читал заголовки, время от времени просил Claude или ChatGPT помочь мне в отладке, но ничего больше. Пришла пора учиться вайб-кодингу!

Я потратил месяц на создание веб-сайта в Docker и теперь готов поделиться ужасными историями.

У меня есть проблема.

Мой веб-сайт (на котором была опубликована эта статья) в основном обслуживается одним двоичным файлом Rust. Он стал слишком длинным. Каждый раз, когда мне нужно внести изменение, я должен:

Собрать новую статически компонуемую библиотеку (с --target=x86_64-unknown-linux-musl)

1. Скопировать её на сервер

2. Перезапустить веб-сайт

Ситуация, мягко говоря, неидеальная.

Поэтому мне бы хотелось перейти к развёртыванию веб-сайта при помощи контейнеров (будь то Docker, Kubernetes или что-то иное), в духе подавляющего большинства ПО, разворачиваемого в последний десяток лет.

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

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

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

Пользователь Reddit опубликовал в r/rustjerk сгенерированный ИИ пост под названием «Почему наш CTO запретил использовать Rust после одного переписывания кода». Очевидно, что этот рассказ выдуман, но у меня есть история похожая на него в том смысле, что успех проекта на Rust привёл к прекращению использования этого языка в компании.

Несколько лет назад я работал в стартапе-«единороге», во время пандемии развивавшемся невероятно быстро. Его основное приложение было написано на Ruby on Rails, а часть инструментария для работы с видео — на Node.js, но мы никак не применяли быстрые компилируемые языки наподобие Rust и Go. Через пару месяцев после моего прихода в компанию нам нужно было реализовать работающий в реальном времени сервис, который бы позволял нам получать информацию о том, кто из пользователей находится онлайн (то есть в профиле есть зелёная точка) и чем они занимаются (например: N пользователей смотрят презентацию X, M пользователей находятся в разделе маркетинга и так далее). Ничего особо сложного, но мы рассчитывали на изначальный рост до ста тысяч пользователей. Эта цель тоже не особо сложна, но большинство разработчиков согласилось, что Ruby — не лучший выбор для этого.

Зачем вообще этим заморачиваться?

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

wmic path Win32_Fan get *

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

Зловредное ПО может определять, запущено ли оно в виртуальной машине, множеством разных способов. Есть различные классы WMI, позволяющие обнаружит присутствие виртуальной машины, например, Win32_CacheMemory, Win32_VoltageProbe и множество других.

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

Я посвящу этой теме целый пост, потому что она «не помещается в окно Овертона»; чтобы люди хотя бы начали понимать, что я пытаюсь описать, мне обычно приходится показывать видео, которое я выложил под катом.

Как вы, наверно, знаете, из-за наличия в компьютере различных кэшей (L1, L2, L3...) и того, что операции с памятью выполняются с линиями кэша размером примерно 64 байт каждая, для обеспечения максимальной производительности мы должны писать программы, обеспечивающие локальность.

(Разумеется, диск здесь не показан)

Но насколько хорошо вы это осознаёте? Допустим, у нас есть массив чисел с плавающей запятой и массив индексов первого массива. Есть программа, складывающая числа из первого массива в порядке, определяемом вторым массивом. То есть в этом примере мы будем складывать ε + α + δ + ζ + β + γ в таком порядке:

Давайте рассмотрим всего два случая: индексы идут в порядке от первого до последнего или в произвольном порядке. До того, как я начал писать этот пост, я не мог ответить ни на один из следующих вопросов:

1. Насколько большим должен быть массив, чтобы разница производительности вычисления в двух порядках стала заметной?

2. Сколько в среднем тратится на каждый элемент в порядке от первого до последнего?

3. Насколько медленнее произвольный порядок последовательного в случае массивов, умещающихся в RAM?

4. Насколько медленнее произвольный порядок последовательного в случае массивов, не умещающихся в RAM?

5. Достаточно ли стандартного тасования Фишера-Йейтса для массивов перемешанных индексов для получения произвольного порядка?

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

7. Максимально ли быстры файлы с отображением в память?

Если вы уже знаете ответы на эти вопросы, то это замечательно! Если же нет, то делайте ваши предположения и проверьте их, прочитав пост.

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

Вот и всё!

Ниже показан скрипт, сочетающий все мои трюки для выполнения этой задачи. Для его работы необходимо установить yt-dlp, ffmpeg и llm.

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

Вам стоит продолжить чтение, если вы недоумеваете, почему я просто не воспользовался встроенной автотранскрибацией YouTube. Краткий ответ будет таким: я недотёпа, считавший (ошибочно), что она недоступна. Поэтому мне пришлось идти по более сложному пути.

Рассмотрим следующий сценарий:

template<typename T>
struct Base
{
// Есть конструктор по умолчанию
Base() = default;

// Некопируемый
Base(Base const &) = delete;
};

template<typename T>
struct Derived : Base<T>
{
Derived() = default;
Derived(Derived const& d) : Base<T>(d) {}
};
// Это assertion выполняется?
static_assert(
std::is_copy_constructible_v<Derived<int>>);

Почему выполняется это assertion? Очевидно, что скопировать Derived<int> нельзя, ведь при этом мы попытаемся скопировать некопируемый Base<int>. И в самом деле, если попробовать скопировать его, то мы получим ошибку.