Недавнее обсуждение опасности дверей в геймдеве напомнило мне о баге, вызванном дверью из игры, о которой вы, возможно слышали — Half Life 2. Усаживайтесь поудобнее, мы начинаем.

Когда-то я работал в Valve над проектами виртуальной реальности. Это было в 2013 году, примерно когда появился Oculus DK1. Мы с Джо Людвигом решили, что лучше всего можно понять, как будет работать VR в контексте реальной игры, портировав в неё реальную игру.

Мы выбрали Team Fortress 2 (причина этого — отдельная история, которой я не хочу здесь касаться). В TF2 использовался движок Source 1, и так получилось, что двумя другими играми Valve, тоже построенными на этом движке, были Half Life 2 и Portal 1. Поэтому побочным эффектом стало то, что они тоже будут работать в VR.

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

Зато HL2 игрался достаточно неплохо. Джо потратил довольно много времени на то, чтобы уровни с лодкой работали прилично.

Fizz Buzz — это игра с числами, которая стала неожиданно популярной в мире компьютерного программирования в качестве простой проверки базовых навыков. Правила игры просты: игроки вслух произносят по порядку числа, начиная с единицы. Если число делится на 3, игрок должен сказать вместо него «Fizz». Если число делится на 5, он должен сказать «Buzz». Если оно делится и на 3, и на 5, игрок говорит «FizzBuzz». Вот типичная программа на Python, выводящая нужную последовательность:

for n in range(1, 101):

if n % 15 == 0:

print('FizzBuzz')

elif n % 3 == 0:

print('Fizz')

elif n % 5 == 0:

print('Buzz')

else:

print(n)

А вот её вывод: fizz-buzz.txt. Можно ли усложнить эту программу? Слова «Fizz», «Buzz» и «FizzBuzz» повторяются в этой последовательности периодически. А что ещё у нас есть периодического? Тригонометрические функции! Возможно, нам удастся при помощи этих функций закодировать все четыре правила последовательности в выражении в аналитическом виде. Именно эту задачу мы и исследуем в статье, получив в конце дискретный ряд Фурье, который может получить любое целочисленное n и выбрать для печати соответствующий текст.

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

У нас есть веские причины на то, чтобы пока не присоединяться к таким компаниям, как Anthropic (генерируется 80%), Microsoft (30%) и Google (25%).  

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

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

Вы когда-нибудь выставляли цену за проект, думая, что он займёт месяц, но в результате спустя четыре месяца давали скидку, лишь бы покончить с этим кошмаром?

Этот пост станет глубоким разбором того, как мы снизили задержки P95 конечной точки API с 5 до 0,3 секунды при помощи нишевого трюка computer science под названием «фильтр Блума».

Мы расскажем о том, почему конечная точка была медленной, о решениях, которые мы рассматривали для повышения её скорости, и о критериях выбора между ними. Также мы объясним, как всё это устроено внутри.

Quake, выпущенный в июне 1996 года, за срок своей жизни был вынужден оседлать три технологические волны. Наряду с появлением карт аппаратного 3D-ускорения и развитием Интернета, сложности у разработчиков игры вызвала и смена поколений операционных систем.

Стремясь к распространению Windows 95 и Windows NT, Microsoft начала процесс замены своей старой операционной системы MS-DOS. С 1996 по 1997 год доля DOS на рынке упала на 50%. Некоторые разработчики, например, Blizzard North, делали рискованный шаг и создавали игры наподобие Diablo только для Windows 95. Компания id Software же пошла на подвиг по созданию единого двоичного файла quake.exe, способного работать и в DOS, и в Windows.

Ещё более впечатляет то, что разработчикам удалось реализовать стек TCP/IP Quake лучше, чем у Windows 95. Давайте разберёмся, как им это удалось.

Некоторые концепции легко усвоить абстрактно. Кипящая вода: греем её и ждём. Другие нужно попробовать самому. Вы думаете, что знаете, как работает велосипед, пока не попробуете покататься на нём.

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

К ним относятся и LLM-агенты.

Мнения о LLM и агентах невероятно разнообразны. Но даже если это мошенничество, это серьёзная идея. Они не обязаны вам нравиться, но вы должны быть правы относительно них.

И это одна из причин, по которой вам следует написать агента. Но есть и другая, гораздо более убедительная причина...

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

Зеркала в Sims 4 по-настоящему работают! Для этого игре нужно ещё раз рендерить комнату для каждого зеркала в сцене. Разумеется, это затратный процесс.

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

Введение

Приготовьтесь, мы совершим путь от единственного кубика до целого воксельного движка! Нам понадобится следующее:

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

API рендеринга! Выбирайте что угодно, эта статья — не туториал по рендерингу.

Если в процессе у вас возникнут вопросы, можете связаться со мной на моём сервере Discord или написать на contact@daymare.net.

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

Мне захотелось понять, насколько далеко я смогу зайти, оставив в computer vision только самый минимум: одни лишь 8-битные изображения в градациях серого; никаких сложных структур данных, старый добрый C, немного байтовых массивов и единственный файл заголовка. В конце концов, изображение — это ведь просто прямоугольник из чисел, не так ли?

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

Microsoft Z-80 SoftCard — это плата расширения для Apple II, добавлявшая возможность запуска ПО компьютера CP/M. Согласно Википедии, это был первый аппаратный продукт Microsoft, и в 1980 году он стал самым крупным источником дохода для компании.

CP/M работает на процессоре 8080, а Apple II имеет процессор 6502. Так как же запустить CP/M на Apple II? На плате был смонтирован отдельный процессор Zilog Z80, совместимый с 8080; по множеству причин, перечисленных в Википедии¹, он превосходил 8080.

Отлично, у нас есть процессор. Но что будет происходить со старым процессором 6502? В идеале нужно бы его просто отключить, но это невозможно, потому что некоторые задачи всё равно должны выполняться 6502². Николь Брэнаган подробнее изучила историю о том, как сосуществовали эти два процессора. Принцип заключался в следующем: SoftCard сообщала 6502, что выполняет DMA, поэтому 6502 приостанавливал работу и ожидал завершения DMA. Однако нельзя оставлять 6502 на паузе слишком долго: его внутренние регистры могут деградировать и утерять свои значения.

Для решения этой проблемы можно воспользоваться линией REFRESH процессора Z80, которую он использует, чтобы сообщать, что пока не выполняет доступ к памяти (потому что декодирует команду). Это даёт понять цепи обновления внешней памяти, что она может работать и обновлять ОЗУ, чтобы оно не деградировало и не теряло свои значения.

Недавно мы переделали наши внутренние инструменты, визуализирующие компиляцию JavaScript и WebAssembly. При работе оптимизирующего компилятора Ion мы теперь можем генерировать интерактивные графы, демонстрирующие, как конкретно обрабатываются и оптимизируются функции.

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

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

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

Недавно у Земли появилась седьмая подтверждённая квазилуна. Это 2025 PN7 — маленький астероид типа «аполлон», обнаруженный гавайским телескопом Pan-STARRS 1 лишь благодаря его яркости.

Проанализировав его траекторию, астрономы пришли к выводу, что объект поддерживает с Землёй резонанс 1:1. Иными словами, он совершает оборот вокруг Солнца за то же время, что и наша планета. Из-за такой синхронности издалека кажется, как будто Землю сопровождает крошечный астероид и у неё есть дополнительная луна.

В отличие от лун, квазилуны не привязаны к Земле гравитационно. В космологической терминологии они считаются эфемерными спутниками, следующими собственным путём вокруг солнца. Они настолько приближаются, чтобы казаться гравитационно привязанными, только в определённые интервалы времени. В случае 2025 PN7 минимальное расстояние равно 299 тысячам километров, а самая дальняя точка находится в 17 миллионах километров. Для сравнения: Луна остаётся от Земли на среднем расстоянии 384 тысячи километров.

Давайте поговорим о том, как улитка уха вычисляет звук!

Барабанная перепонка приводится в колебания изменениями давления воздуха (звуковыми волнами). Кости среднего уха усиливают и передают эти колебания в заполненную жидкостью спиралеобразную улитку. Колебания перемещаются по жидкости к базилярной мембране, которая выполняет разделение частот¹: более жёсткое и лёгкое основание (base на иллюстрации) резонирует с высокочастотными компонентами сигнала, а более гибкая и тяжёлая вершина (apex) резонирует с низкими частотами. Между двумя концами резонирующие частоты логарифмически снижаются в пространстве².

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

Пару недель назад, когда я писал пост The Hidden Cost of URL Design, мне нужно было добавить подсветку синтаксиса SQL. Я направился на веб-сайт PrismJS, пытаясь вспомнить, можно ли добавить его в качестве плагина. Меня утомило количество вариантов на странице скачивания, поэтому я вернулся к своему коду. Поискав в файле PrismJS, я нашёл в его начале комментарий, содержащий URL:

/* https://prismjs.com/download.html#themes=prism&languages=markup+css+clike+javascript+bash+css-extras+markdown+scss+sql&plugins=line-highlight+line-numbers+autolinker */

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

Это стало одним из тех моментов, когда ты внезапно снова осознаёшь важность чего-то. Передо мной был URL, не просто указывающий на страницу: он хранил состояние и позволял полностью воссоздать все мои настройки. Не нужна никакая база данных, никакие куки, никакое localStorage. Достаточно одного URL.

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

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

Многие команды работают с кластерами Kubernetes побольше нашего. В них больше узлов, больше подов, больше ingress и так далее. По большинству размерностей нас кто-нибудь, да побеждает.

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

Проблема сильно усугубляется, когда daemonset должен выполнять listwatch пространств имён или сетевых политик (netpol), которые мы определяем для каждого пространства имён. Так как daemonset запускают под в каждом узле, каждый из этих подов выполняет listwatch одних и тех же ресурсов, из-за чего объём используемой памяти увеличивается при росте количества узлов.

Хуже того — эти вызовы listwatch серьёзно нагружали apiserver. Если одновременно перезапускалось множество подов daemonset, например, при развёртывании, то они могли перегрузить сервер запросами и вызвать реальный вылет.

Мне часто доводится вести странные споры с фанатами фреймворков о том, действительно ли <div> «столь же хорош», как и <button>.

Спойлер: нет. И давайте выясним, почему.

Команда разработчиков прислала мне на ревью свой API, в одной из частей которого множество поддерживаемых значений выражалось в виде трёх чисел:

• Минимального допустимого значения.
• Инкремента.
• Максимального допустимого значения.

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

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

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

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

В каждом моём профессиональном и личном проекте рано или поздно требовался diff для визуализации изменения или применения патча. Однако меня никогда не устраивала ни одна из свободно доступных библиотек diff. В профессиональной деятельности это никогда не вызвало особых проблем, но в личных проектах я копировал и модифицировал из проекта в проект собственную библиотеку. Однажды я рассказал об этом коллеге, и тот наставил меня на путь публикации моей библиотеки на Go (порта библиотеки на C++, которую я раньше копировал и модифицировал). И оказалось, что я сильно недооценивал то, насколько близка моя библиотека к возможности публикации!

Как бы то ни было, я опубликовал её и узнал много нового об алгоритмах diff. Библиотеку можно найти по адресу znkr.io/diff, а в этой статье я расскажу о своих открытиях. Я ещё не завершил освоение, поэтому планирую дополнять статью в процессе изучения.

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

Однако у телевизора есть проблема: он очень часто попадает в резонанс со встроенными динамиками, из-за чего корпус устройства начинает достаточно сильно вибрировать и ужасно шуметь.

Чтобы продлить срок жизни этого реликта, я решил вложиться в дешманский саундбар Majority Snowdon II. Благодаря нему удалось решить проблему резонанса, но ей на смену пришли особенности саундбара. А именно, его тупость.

Да, это не смарт-устройство, несмотря на то, что его выпустили в 2022 году. У него есть инфракрасный пульт дистанционного управления, несколько физических кнопок, и на этом всё! Однако когда я покупал его, у меня был план. Я думал, что, наверно, смогу сделать его умнее. Поэтому когда пульт в 87-й раз завалился в щель дивана, я решил вскрыть саундбар и разобраться, что с ним можно сделать.