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

Система довольно проста: моя домашняя машина с Debian. У меня работает Postgres 17 в Docker с shared_buffers = 16MB, track_io_timing = on. В качестве накопителя используется локальный SSD NVMe с ext4. Я намеренно создал таблицу такого размера, чтобы она не умещалась в кэш.

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

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

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

Мы можем легко принять, казалось бы, здравое решение, которое неожиданно вызовет проблемы. Кроме того, многоопытные разработчики (и старые системы) могут иметь ожидания, ранее бывшие корректными, но больше не работающие. Итак, без лишних предисловий, перейдём к вымыслам…

Nintendo DSi

В большинстве случаев браузер был включён в пакет системного ПО DSi (2008 год), в противном случае его можно было бесплатно установить из DSi Shop. Для браузера не требовался Memory Expansion Pak благодаря тому, что в DSi имела встроенные 16 МБ ОЗУ. Браузер сильно улучшили по сравнению с версией для DS, это урезанная версия Opera 9.50¹.

Важным аспектом стало добавление поддержки HTML canvas: на различных сайтах наподобие DSiPaint, DSiCade, DSiPlaza и Social Neko, написанных специально под браузер DSi, использовалась эта поддержка и другие веб-технологии, упрощающие интерактивные действия. Браузер поддерживал только один шрифт и три его размера, а контент преобразовывался в соответствии с этим ограничением.

Авторы обзоров того времени критиковали отсутствие поддержки Adobe Flash и воспроизведения видео, а также достаточно частые сообщения о заканчивающейся памяти, но всё равно считали браузер серьёзным шагом вперёд по сравнению с ПО для DS. Он получил единственное обновление до версии 1.4 (август 2009 года), которое немного уменьшило занимаемый в памяти размер.

Несмотря на увеличившийся размер ОЗУ, DSi не была совместима с браузером DS из-за обязательной проверки на наличие Memory Expansion Pak, который невозможно было установить DSi из-за отсутствия Slot-2.

^{1. Несмотря на некоторые утверждения, браузер работал в самой DSi, не используя прокси рендеринга Opera Mini.}

Видеоигровые консоли и веб-браузеры имеют долгую совместную историю. Ещё с самого появления World Wide Web консоли пытались выйти онлайн. Браузеры в видеоигровых консолях изначально в основном были попытками предоставить дешёвое окно в веб для обычной аудитории без технического опыта, однако со временем они становились всё более масштабными и интегральными частями систем.

В этой статье мы подробно изучим браузеры консолей, однако рассмотрим только официальные веб-браузеры. Во многие консоли можно установить браузеры через специализированные прошивки и homebrew, но они не войдут в рамки нашей статьи, как и системы без веба наподобие Satellaview, а также онлайн-сервисы, не предоставляющие браузер, например, XBAND, Sega Meganet и Sega Channel.

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

Считается, что порт Doom можно запустить на любом технологическом устройстве. У игры изящный, быстрый, модульный код, который может работать практические везде. Порты выпустили даже для систем, появившихся до Doom, а некоторым портам помогает специальное оборудование как, например, в случае первого Doom на SNES. Чистый и изящный код написан на C, в нём не так сложно разобраться. В нём не используются никакие современные дополнения языка и какие-то устаревшие технологии, поэтому он замечательно компилируется. Кроме того, он удобен для разных endiannes, что очень важно для портируемости.

Поэтому неожиданно, что порт Doom так и не появился на Neo Geo. В конце концов, в Neo Geo работает тот же CPU Motorola 68000, что и в Sega Genesis с Commodore Amiga, а для обеих этих платформ, несмотря на их слабые характеристики, есть версии Doom. Для Neo Geo же её найти невозможно. Многие разработчики, работавшие с Neo Geo, часто говорили, что на ней практически невозможно запустить Doom. Но почему? У этой консоли есть видеодисплей, CPU, ОЗУ и всё необходимое для запуска видеоигр. Давайте же разберёмся.

В базах данных в качестве первичных ключей часто используют случайные UUID. Один из известных недостатков случайных UUID заключается в том, что их неупорядоченность (UUID4) может вызывать большое количество дополнительных обращений к страницам кластеризованных индексов (clustered index), потому что строки вставляются в случайные места B-дерева, и его приходится постоянно перебалансировать. В этой статье я попытаюсь помочь вам выработать более интуитивное понимание того, как влияют на производительность все эти дополнительные операции со страницами.

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

В новом релизе Pizza Legacy v0.1.0 появилась возможность выиграть игру, как в оригинале.

Когда я играл в Pizza Tycoon (1994 год) в детстве, то не особо задавался вопросом, как победить. Мне просто нравилось открывать рестораны и придумывать пиццы, а также приторговывать оружием для финансирования роста моей империи пиццы. Но выигрыш? Я никогда до него не доходил и, вероятно, даже не задумывался о нём.

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

Первая строка ENDE.E:

Вы достигли немыслимого! Вы — король всего западного рынка фастфуда! Вы — тот самый, МАГНАТ ПИЦЦЫ.

Это даёт нам понять, что игру как-то можно выиграть, но не как именно.

Я просто забыл об этом вопросе, ведь мне предстояло реализовать столь многое до того, прежде чем задумываться о победе игрока, но однажды наткнулся на пост «Я "выиграл" в Pizza Tycoon? (Как это произошло?)». После нахождения этого поста мне стало любопытно, но не настолько любопытно, чтобы заниматься расследованием, поэтому я поискал условия конца игры в ассемблерном коде и попросил Claude проанализировать их. Он сказал следующее:

end_of_week_processing раз в неделю проверяет, есть ли у текущего игрока >= доля рынка 5% во ВСЕХ 10 городах.

Это соответствует моим представлениям: логично с точки зрения геймплея и текста, найденного в ENDE.E. Однако это не соответствовало написанному пользователем Reddit: он утверждал, что у него были рестораны только в Париже и Берлине; возможно, он опустил какие-то подробности или у него просто был повреждённый файл сохранения? Я написал ему, но не получил ответа...

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

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

В 2004 году я слишком много играл в RuneScape на модеме 56k, который разрывал соединение, когда мама поднимала трубку. 3D-мир, на сервере которого могло быть до тысячи игроков и десятки на экране одновременно... И всё это в браузере со скоростью 5 килобайт в секунду. Каким-то образом всё это работало. Давайте пошагово разберёмся, как же именно.

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

Методология

Подробности, приведённые в этом посте, взяты и декомпилированного клиента RuneScape 2 от 2004 года. Фрагменты кода — это приблизительная трансляция этого декомпилированного кода, местами подчищенная для удобочитаемости, но с сохранением логики.

Базовые принципы различаются между разными версиями, но большинство из них остаётся неизменным от самой RuneScape Classic (2001 год) до современной RuneScape 3 и, разумеется, до Old School RuneScape.

Если вы играли в RuneScape в начале 2000-х и у вас всё ещё есть жёсткие диски из той эпохи, то советую заглянуть в RuneScape Archive Project. Его авторы проделали отличную работу по каталогизации исторических версий RuneScape, которые в противном случае были бы утеряны, и им важен каждый вклад.

Примерно в 400 километрах над поверхностью Земли летает Международная космическая станция, окружённая своеобразной космической погодой.

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

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

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

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

Люди тоже их создают. Для меня один из самых удивительных паттернов, которые мы придумали — это дороги.

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

Градостроительные симуляторы и их дороги

Должен сказать, что дороги восхищали меня с детства.

До сих пор помню, как в возрасте шести-семи лет впервые играл в SimCity 2000. Я понял не особо многое и не знал, что такое зонирование, налоги и спрос. Но дороги сразу меня восхитили.

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

Развязки. Перекрёстки с круговым движением. Эстакады. Сужения полос. Замечал каждую мелочь.

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

А вы знали, что теперь можно нативно запускать Microsoft 3D Movie Maker в Linux? В течение последних полутора лет я работал над 3DMMEx — моим портом исходников 3D Movie Maker. Одной из целей моего форка была портируемость. Недавно проект достиг важного этапа: теперь он компилируется и запускается в Linux, благодаря чему 3DMMEx стал первым из известных форков 3D Movie Maker, работающих вне Windows! В этом посте я расскажу о некоторых из трудностей, с которыми я столкнулся при портировании на новую платформу написанного тридцать лет назад мультимедийного приложения.

За свои первые каникулы в колледже, вдохновившись Satisfaction75, я создал устройство, которое назвал Dissatisfaction65 — беспроводную клавиатуру формата 65%. Не помню, почему конкретно, но, изготовив несколько проводных клавиатур, мне хотелось попробовать собрать самодельную беспроводную. Для реализации беспроводной связи я выбрал микроконтроллер Adafruit 32u4 Bluefruit LE, потому что опенсорсная клавиатурная прошивка QMK поддерживала Bluetooth конкретно с этой платой. Получившееся устройство выглядело прекрасно, но производительность была чудовищной. Из-за задержек при вводе пользоваться им было почти невозможно, и несмотря на огромный аккумулятор, работало оно от него всего несколько дней.

У компаний наподобие Logitech и Apple есть беспроводные клавиатуры с низкими задержками и долгой работой от аккумуляторов, поэтому я понимал, что это не предел. На следующие два месяца я погрузился в мир беспроводных микроконтроллеров и самодельных клавиатур. Почти сразу же я понял, что любители выбирают микрочипы Nordic, а правит в этом мире формат Pro Micro. В процессе исследований я обнаружил три микроконтроллера, разработчики которых пытались связать эти две технологии: BlueMicro, nRFMicro и BLE-Micro-Pro¹.

Из-за форм-фактора BlueMicro я бы не смог изготовить большинство клавиатур Pro Micro, потому что они бы мешали друг другу. BLE-Micro-Pro был довольно дорогим, закрытым и продавался только в Японии. Ближе всего оказался nRFMicro. Сначала я решил модифицировать под свои нужды nRFMicro, но вскоре осознал, что мои цели слишком амбициозны, поэтому начал с нуля.

Размытие — базовый строительный блок множества эффектов постобработки в видеоиграх, без него не обходятся красивые современные GUI. Оно используется в эффектах Depth of Field, Bloom или панелях с эффектом матового стекла современных пользовательских интерфейсов.

Эффект Bloom — один из множества способов применения алгоритмов размытия

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

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

Открытие: цифровая капсула времени из 1987 года

Представьте: на дворе 26 октября 1987 года. Ещё стоит берлинская стена, World Wide Web состоит из одного текста, а ПО распространяется через новостные группы USENET в текстовых файлах, разбитых на несколько постов. В этот день Эдвард Барлоу опубликовал на comp.sources.games нечто особенное:

«conquest – многопользовательская игра в средиземье, Part01/05»

Так Эд Барлоу впервые объявил о ней, но вскоре поменял название на Conquer.

Это была Conquer — сложная многопользовательская стратегия, повлиявшая на бесчисленное количество других. Игроки брали под своё командование народы Средиземья, управляли ресурсами, армиями, системами магии и дипломатическими отношениями. Примечательной игру делал не только геймплей, но и то, что она была создана и распространялась в эпоху, когда ещё даже не придумали понятие «open source».

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

Возьмём для примера Toto.

Если вы проводите много времени в американских общественных туалетах или вы просто их особо внимательный завсегдатай, то могли заметить унитазы Toto: они отличаются запоминающимся логотипом с засечками «TOTO». Унитазы Toto не доминируют в туалетах США, потому что имеют сильных конкурентов в лице местных туалетных лидеров American Standard и Kohler; впрочем дела Toto идут всё лучше с повышением популярности у американцев биде; в глобальном же масштабе Toto — один из крупнейших в мире производителей унитазов и биде. А у себя на родине, в Японии, Toto можно найти практически повсюду: в 80% японских домов установлен биде-унитаз Toto.

Если вы давний акционер Toto, например инвестор, особо интересующийся туалетной утварью, то этот год был для вас невероятно прибыльным. На текущий момент акции Toto поднялись с начала года на 60%; всего за несколько последних недель они выросли на 30%. Дела у Toto лучше некуда: её чистая прибыль за первый квартал 2026 года выросла на 230% по сравнению с тем же периодом прошлого года.

Однако успешность года для Toto в основном определяется не унитазами и биде. Да, Toto основали в 1910-х с миссией «обеспечения здорового и цивилизованного образа жизни» посредством доступных унитазов, и за последующие десятилетия она стала мировым лидером на туалетном рынке. Но Toto занимается и кучей других вещей. Toto изготавливает не только биде и унитазы, но и плитку для ванных, готовые модули туалетов, раковины, модульные кухни, фотокаталитические покрытия для зданий и оборудование для помощи пожилым людям. И, что самое важное, Toto имеет очень прибыльный побочный бизнес — производство чипов памяти.

В когда-то скромном уголке компании, называющемся «подразделением передовой керамики», она с 1988 года производит специализированный компонент — электростатический держатель (electrostatic chuck, или e-chuck). E-chuck — это высокоточная керамическая пластина размером примерно с автомобильный руль, которая при помощи электростатической силы обеспечивает идеально плоское расположение и тепловую стабильность кремниевой пластины, пока на ней выполняется плазменное травление чипов памяти. Изготавливать такие компоненты крайне сложно, потому что керамический корпус не должен генерировать практически никаких частиц и быть отполирован до субмикронной гладкости; поэтому только несколько компаний в мире способны изготавливать e-chuck, обеспечивая стабильное качество. Почти все они — Shinko Electric, NGK, Toto, Kyocera, Sumitomo Osaka Cement, Niterra — расположены в Японии.

Бóльшую часть своей истории прибыль подразделения передовой керамики в балансовой ведомости Toto было сравнимо с погрешностью округления: как и в 1910-х, деньги компании приносил бизнес унитазов и биде. Но настала новая эра. Произошёл взрывной спрос на ИИ, а значит, и на широкополосную память, требуемую для дата-центров. Это привело к взрывному спросу на чипы памяти, а значит, и на e-chuck. Вот так подразделение передовой керамики Toto внезапно стало крупнейшим

В разработке ПО произведение двух целых чисел часто вычисляется до фиксированного количества битов с переполнением. Возьмём для примера 8-битные целые. Если умножить 127 на 127, то мы получим число 1 в виде 8-битного беззнакового целого с переполнением. Реальное полное произведение равно 16129. Для представления 16129 обычно используются 16 бит точности.

Таким образом у нас появляется понятие полного произведения. Полное произведение двух 32-битных чисел обычно представляется при помощи 64 бит. У меня возник вопрос, какую долю всех 64-битных чисел можно записать, как произведение двух 32-битных целых.

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

Да, вы всё поняли верно. If site == X, do Y.

Особого обращения заслужили TikTok, Netflix, Instagram* и даже SeatGuru.

Так поступают Safari и Firefox. Но не Chrome.

И это говорит нам кое о чём любопытном.

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

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