UfoStation

В прошлом, во второй половине 2000-х, я, как и многие, для общения с внешним миром использовал ICQ и сидел на форумах. Интернет тогда считали по мегабайтам, а для связи я пользовался старым кнопочным телефоном с поддержкой GPRS. Из интересов — попытки делать небольшие сайты на PHP. Слово Denwer вам о чём-нибудь говорит? О боже, кажется, до сих пор можно найти мой цифровой след, благо я сидел под другим ником. Когда начинал свой путь, то в окружении все были старше и опытнее, и многим я верил на слово. Что взять с подростка? Интересовавшие меня веб-технологии были не так развиты, и знаний о них тоже было немного. Обмен знаниями происходил через общение — это было очень медленно, но лучше, чем ничего: всё то же чтение форумов и переписка в аське. В один прекрасный день я не смог войти в аську. Перепроверил пароль, попытался сбросить — неужели взломали? Зарегистрировал новый номер и решил проверить старый. Вдруг он онлайн? Он был онлайн! Взломали! Написал на свой взломанный номер: — Привет! Как дела? — Привет! Нормально) — Ты забрал мой номер ICQ! *Непродолжительный диалог* — 50 долларов — и я верну. — Но у меня столько нет. — А сколько есть? — 10 — Хорошо, вернёшь сейчас 10 и потом ещё 10. И не вздумай меня обмануть — я могу в момент удалить всё с твоего компьютера. Отправил злоумышленнику свои кровные WMZ (доллары в webmoney). Пароль от аккаунта мне прислали, я тут же заменил на свой. И после этого я экстренно начал форматировать системный диск, чтобы переустановить Windows, так как понятия не имел, откуда и как это могли сделать. Пока шла переустановка, я начал перебирать в памяти, от кого и что я мог скачать из сети, и вспомнил: один из моих новых интернет-знакомых предложил в качестве развлечения установить динамические обои на Windows. Это, на минуточку, был исполняемый файл, расширение .scr, Windows Screen Saver file. Я вспомнил, что запускал его за пару месяцев до инцидента. Правда никаких обоев тогда не появилось. «Не знаю почему, но у меня работает», — написал тогда отправитель. Так я подхватил троянского коня. И только спустя время, видимо, чтобы не было подозрений, у меня увели аську. Теперь со мной подобного уже никогда не повторится. Легендарный мессенджер icq уже давно как не работает.

Когда я перестал делать акцент на Frontend разработке и пересказывать новости, у канала начались отписки, в среднем 5-10 человек на заметку. Выходит, что у меня осталось 300 постов до закрытия канала. Шутка На самом деле превратил канал в более личный и пишу о том, что нравится. Ниже хочу поделиться воспоминаниями и небольшой историей из прошлого. Спасибо, тем, кто продолжает читать ❤️

Еще DOOM-like проекты Заметкой выше я никого не ругаю, но помогаю тем, кто хочет погрузиться в детали. Более того, я только рад всяческим новым проектам. Например, на днях один разработчик анонсировал в статье Catlantean 3D - Making Graphics Like It's 1993 на своем блоге, разработку игры в стиле DOOM и Duke Nukem 3D про похождения «кота-космодесантника расхитителя гробниц». И кажется он действительно хочется повторить опыт прошлого: My goal was to build a complete, shippable first-person shooter using techniques that were common in the early 90s, while allowing myself the luxury of using a modern compiler and a platform abstraction layer. Игра пока только анонсирована, однако долгое время находится в разработке. Будем наблюдать за развитием 🔭

Еще DOOM-like проекты Заметкой выше я никого не ругаю, но помогаю тем, кто хочет погрузиться в детали. Более того, я только рад всяческим новым проектам. Например, на днях один разработчик анонсировал в статье Catlantean 3D - Making Graphics Like It's 1993 на своем блоге, разработку игры в стиле DOOM и Duke Nukem 3D про похождения «кота-космодесантника расхитителя гробниц». И кажется автор действительно хочется повторить опыт прошлого: My goal was to build a complete, shippable first-person shooter using techniques that were common in the early 90s, while allowing myself the luxury of using a modern compiler and a platform abstraction layer. Игра пока только анонсирована, однако долгое время находится в разработке. Будем наблюдать за развитием 🔭

Почему cssDOOM это не DOOM 😒 Выше обещал разобраться насколько проект cssDoom близок к оригинальному doom. Короткий ответ: с точки зрения геймплея и реализация близка, а с точки зрения технической реализации рендеринга — нет. Начну с того, что лично для себя я так и не понял, можно ли визуально похожие игры, но отличающиеся технически (со всеми вытекающими), считать одной и той же игрой? Вывод был бы однозначным, если бы не было такого понятия, как remastered. Это когда создатели берут старую игру и переводят ее на обновленный движок. Интуитивно близкий подход к разработке Doom в браузере — это хранить где-то в памяти данные об уровне, затем на их основе вычислять геометрию уровня, текстуры, движение и прочее и прочее на стороне JavaScript, а с помощью Canvas API заниматься отрисовкой пикселей. Автор проекта cssDoom, Нильс Линхеер выбрал другой подход. Отрисовка происходит через DOM. DOOM в DOM, каламбур. В его подходе для сцены создается множество <div /> элементов, вместо отрисовки на canvas. Каждая стена, пол, бочка и монстр — это отдельный элемент в DOM-дереве. У каждого <div /> есть набор CSS-свойств, которые устанавливаются из настроек уровня, например:

<div class="wall" style="
  --start-x: 2560;
  --start-y: -2112;
  --end-x: 2560;
  --end-y: -2496;
  --floor-z: 32;
  --ceiling-z: 88;
">

Затем все дальнейшие расчеты берет на себя CSS. В репозитории проекта прямо так и пишется, что на стороне CSS вычисляет ширину, высоту и 3D-преобразования с помощью тригонометрических функций:

.wall {
    --delta-x: calc(var(--end-x) - var(--start-x));
    --delta-y: calc(var(--end-y) - var(--start-y));

    width: calc(hypot(var(--delta-x), var(--delta-y)) * 1px);
    height: calc((var(--ceiling-z) - var(--floor-z)) * 1px);

    transform:
        translate3d(
            calc(var(--start-x) * 1px),
            calc(var(--ceiling-z) * -1px),
            calc(var(--start-y) * -1px)
        )
        rotateY(atan2(var(--delta-y), var(--delta-x)));
}

Здесь можно дальше погружаться в описание проекта и его исходный код, чтобы найти использование множества CSS свойств для отрисовки, и по итогу воскликнуть: А что так можно было что ли? Однако здесь я поднимаю другой вопрос. Насколько это реализация повторяет оригинальный DOOM Если изучить код WAD-файл и исходники, то можно заметить, что автор отказался от использования BSP-дерева (бинарного разбиения пространства). Напомню, что именно этот алгоритм, реализованный Джоном Кармаком, позволил оригинальному Doom эффективно работать на слабом железе 90-х: движок обходил только видимые стены и не тратил ресурсы на отрисовку перекрытых областей. В cssDoom всё иначе. Вместо эффективного обхода стен и исключения ранее нарисованных при отрисовке следующих, автор рисует сразу все стены и предметы — используя CSS-свойство translate3d. Что это дает это свойство? ➡️ Графика перестает быть плоской 2D или условно трехмерной (2.5D), а становится полноценной 3D. То есть благодаря CSS-трансформациям каждый объект получает реальные координаты в пространстве. Кстати, в превью к заметке добавлена специально трехмерная версия игры, cssDoom сам такое позволяет делать. ➡️ Каждый элемент <div /> после попадает в отдельный композитный слой браузера в понятиях браузерного рендеринга. При изменении страницы происходит (пере)компоновка этих слоев — эту работу берет на себя GPU. ➡️ В оригинальном Doom всё рисовалось исключительно на процессоре, пиксель за пикселем, с кучей ручных оптимизаций. В cssDoom мы уходим от идеи «нарисовать для уровня 1 пиксель 1 раз» — вместо этого браузерный движок сам решает, как и когда обновлять слои через видеокарту. Что же это тогда Разработчики прошлого старались искать всевозможные оптимизации, чтобы добиться максимальной скорости отрисовки на слабых машинах. Проект cssDoom это скорее концепт или технический эксперимент, способный визуально повторить и показать возможности современного CSS, но безусловно достойный внимания и уважения 🎩

First Person Shooter. Алгоритмы из 90-х на браузерных технологиях В видео краткий срез того, чем занимался последние два месяца, плюс небольшой интерактив в конце. Освещены идеи и их проблематика, с которыми нужно будет или придется столкнуться в разработке игр прошлого. Ужал все, что только мог в отведенное время на выступление — 40 минут. Видео выложил с согласия ПК ❤️ конференции CodeFest, официально видео докладов будут доступны через полгода. Напоминаю, что в течение оставшегося месяца буду переводить текстовые заметки (на отдельном ресурсе) по разработке 2.5D рендер движка из статуса сырой черновик в статус черновик. @xufostation

I'm back Давно не писал в канал, копил ману и готовился к ежегодной конференции Codefest, чтобы рассказать как можно написать wolf3d и doom с нуля в браузере, правда показывал слайды и демки в основном про отрисовку стен. Моей целью было пробежаться по идеям и вдохновить тех, кто задумывался пройти по этому пути сам. Очень тяжело сжимать и укладывать идеи в 40 минут, когда за каждой из них стоят потраченные вечера или выходные. Чтобы погрузиться и оценить каждую идею нужно проделать путь с понимаем какую задачу решаем и как она связана с прошлой. Из интересного. Буквально за неделю до доклада вышел ролик на youtube, который уже тогда успел собрать несколько десятков тысяч просмотров и получить восторженные комментарии. Про Doom спустя 30 лет в сети очень много информации: книги, обзоры, мемуары, фансайты, плюс ИИ, который сэкономит время на поиске информации. Здесь нужно подождать пока аудитория остынет и можно снова похайповать. Из не технического, очень рекомендую (снова) — Джон Ромеро. «Икона DOOM. Жизнь от первого лица. Автобиография» Но, если цель стоит проникнуться и повторить идеи, чтобы попасть в клуб тех, кто смог написать что-то похожее на Doom, то здесь как в анекдоте: — Расскажи как написать Doom? — Давай расскажу — Рассказать я и сам могу! Как написать? Такого материала в сети мало. Из хорошего и проверенного лично мной, есть проект DIYDoom и серия роликов Recreating Doom in Python. Правда, в своё время мне их "немного" не хватило, чтобы быстро во всем разобраться или как вариант я просто глупый не опытный в геометрии. Если читает этот канал давно, то возможно помните как я лихо начал что-то повторять из DIYDoom и потом моя серия статей остановилась. Потом еще одна проблема в том, что попытки повторить Doom основываются на WAD файле. Это файл, который описывает уровень из Doom, он содержит в себе набор структур, которые толкает использовать обход BSP-дерева, что не формирует интуицию почему doom реализован именно так. В общем, я решил пойти своей дорогой и написал в виде черновика пару десятков заметок и демок в отдельном проекте, поэтому ничего не спамил более месяца в канал. Ознакомившись с ними, надеюсь, вы сможете написать свой мини-движок похожий на DOOM. На протяжении двух недель начну выкладывать разделы получившегося туториала (если это так можно назвать) на канал, необходимо перевести все из совершенного сырого черновика в читаемый черновик. PS Если захотите немного развлечься, то от выступления остался артефакт, викторина Game renderers from 90s — запускайте и играйте с друзьями (требует VPN), займет не более 5 минут

cssDOOM На днях вышел проект, который попытался воссоздать в браузере оригинальный DOOM 1993 года, судя по популярной карте, и перенести всю отрисовку в CSS. Играть в браузере Исходники на github

Frontend Interview - Intensive course - Live event 🚀 Всем привет! Последние последний год, пока я готовился к интервью к различным компаниям (HFT / Finance / FAANG) , накопилось много фронтенд задач, которыми я так и не поделился, просто из-за нехватки времени. Мне хотелось представить их в более менее структурированном формате, чтобы люди могли получить максимальную пользу. Поэтому я решил записать курс по подготовке к кодинг интервью и я снова сколлаборировался с FrontendMaster, так как курс по Системному дизайну вышел очень удачным. 18-19 Марта, в 14.00 по Лондону, приходите на бесплатный двухдневный стрим, где мы в течении 12ти часов решим самые интересные и часто встречаемые задачи с фронтенд интервью Будем очень очень много кодить крафтово и без АИ агентов! В сумме решим около 60ти задачек и даже напишем свой небольшой клон Google Sheet. Стрим бесплатный, подписка не нужна. Задачи будут также доступны на гитхабе, где ты можешь можешь скачать репу и решить все сам. ----- Hi everyone! Over the past year, while preparing for interviews with various companies (HFT / Finance / FAANG), I accumulated a lot of frontend interview problems that I never shared—mostly due to lack of time. I wanted to present them in a more structured format so people could get the most value from them. So I decided to record a course on coding interview preparation, and I’ve collaborated again with Frontend Masters, since our System Design course turned out to be very successful. On March 18–19 at 14:00 London time, join us for a free two-day livestream where, over the course of 12 hours, we’ll solve some of the most interesting and frequently asked frontend interview problems. We’ll do a lot of hands-on coding—craft-style and without AI agents! In total, we’ll solve around 60 problems, and even build a small Google Sheets clone. The stream is completely free, and no subscription is required. The problems will also be available on GitHub, so you can download the repository and solve everything on your own.

Какие три слова хочет услышать докладик? Твой доклад принят 👍 Последующие 3 месяца будут посты исключительно с фиксацией некоторых идей и опыта вокруг и про создание DOOM-like игры или не будет постов совсем (потому что будет просто некогда), а все потому что мне одобрили выступление на CodeFest. PS. В видео выше умельцы запустили doom-like wolfenstein3d-like игру на бумаге

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

Всем привет! 👋 Вместо Advent of Code в декабре устроил себе небольшой Advent of Vibecode и сделал https://systemdesigntrainer.com/ — кому актуально, кто готовится к секции по системному дизайну сейчас, пожалуйста, велком в бету. 🚀 Какую проблему решает сервис 👇 Зачастую системный дизайн заваливают не потому, что не знают, как делать бэкенд (нормальная ситуация: когда 10 лет программируешь, потом идёшь на собес и заваливаешь его), а потому что не знакомы с форматом интервью. Этапы: сбор требований, back-of-the-envelope, high-level дизайн, модель данных, deep dive и так далее. Либо слишком быстро уходят в детали, не уточнив требования, либо, напротив, долго ходят по кругу, когда уже прошла половина интервью. https://app.systemdesigntrainer.com — это тренажёр, чтобы набить руку: укладываться в формат и тайминг, вспомнить основные концепции и диаграммы порисовать, все как на настоящем интервью. По ходу интервью собираются сигналы (как бы это делал живой интервьюер), в конце выдаётся фидбек (как на мок-интервью).

В прошлом выпуске подкаста был спрятан несложный флаг, за который можно было получить пиццу. Победитель уже найден, с чем его и поздравляю 🤝 PS. Флаг был только один, больше ничего искать не нужно

Референсы ко второму выпуску подкаста История соревнований Capture The Flag в России и мире, статья RuCTF 2008 - первые всероссийские соревнования CTFtime - агрегатор и хаб для международных соревнований Frontend CTF - мероприятие в рамках Я 💛 Фронтенд

Frontend CTF 2026

— Слушай, а почему ты меня не спрашиваешь - где ты пропадал все это время? — Где ты пропадал-то все это время? Малыш и Карлсон

Ранее на канале писал, что в этом году будет несколько поводов взять паузу в написании заметок и вот создание CTF для Frontend-разработчиков как раз и послужила первой такой паузой. Несколько лет подряд мы с ребятами создаем Frontend CTF и уже устали считать сколько их было проведено, поэтому пришлось сделать лендинг, на котором можно посмотреть прошлогодние игры и вспомнить победителей прошлых лет. В одной из следующих заметок расскажу о том, как появилась эта активность, как создается и за счет чего и на чем держится. Знаю, большие текста вы любите читать, а я писать. А пока анонс: Запуск сегодня в 18:47 (по мск) Frontend CTF 2026 Запуск сегодня в 18:47 (по мск) Frontend CTF 2026 Запуск сегодня в 18:47 (по мск) Frontend CTF 2026 А это уже практически через 1 час ⏳ Чат участников - @yalovefrontend_ctf

С наступающим 2026 годом и рождеством🎅 Желаю всем и каждому профессиональных успехов, счастья в личной жизни, здоровья и всего того, что сделает вас счастливее в этом новом году 🎁 Также подготовил для вас несколько предсказаний. Загадайте число от 1 до 10. Загадали? А теперь открывайте: 1) Тебя не заменит ИИ, потому что ты незаменимый 2) Станешь амбассадор бигтех компании 3) Уйдешь в тимлиды и будешь меньше писать кода 4) Когда ты положишь production, никто не заметит, потому что это будет stage 5) У тебя будет 50 pull request'ов, которые пройдут review с первого раза 6) Тебя повысят в компании 7) Сможешь пропускать встречи и созвоны на протяжении месяца 8) Получишь известность и признание в сообществе 9) Следующий проект будет на технологиях, которые выберешь ты 10) Сможешь отложить дедлайн на 2 месяца

Про технический долг в бандлерах Представьте себе абстрактную задачу Дано: список хэш значений, он хранится у вас в файле или в памяти, есть список JavaScript файлов, в котором используется одно или несколько значений из списка выше Необходимо: обновить указанное хэш-значение в списке и в файлах, где это хэш значение используется В голову приходит сразу два решения. Первое решение это наивно найти подстроку в строке, другими словами в исходном коде, и заменить ее. Второй путь — это получить структуру AST дерева для каждого файла и искать по определенным типам узлов, брать значения этих узлов, сравнивать с искомым значением и делать замену. Алгоритмическая сложность обхода строки и обхода по всем узлам AST-дерева O(n) по времени. Но очевидно, что для второго решения нужно еще построить то самое дерево, необходимо найти какой-то паттерн, где может лежать искомый хэш: может ли он быть частью математического выражения, является ли он ключом какого-то объекта, может ли он являться значением какого-то массива — в общем вариантом множество. Для второго решения нужны будут дополнительные вводные, как следствие код решения от каждого нового условия будет расти и более того потребуется дополнительная память. Первое решение дешевле и легче. Попробуем им воспользоваться? Есть риск, что найдется какая-то часть кода похожая на хэш, но может хэшем не являться. Получим новый битый код или еще хуже рабочий синтаксически код, но с битой логикой. Пример, у вас хэш функция, которая на выходе отдает N-значное целое число, одновременно с этим в коде массив ID пользователей и вы по итогу меняете одного пользователя на другого по алгоритму замену строки. Как тестировать? Без знания контекста об этих ID никак. В результате терпим фиаско. Теперь поговорим о фронтенд разработке. В декабрьских заметках обозначил, что существует тренд ухода от webpack. Так, например, ребята из Яндекса для некоторых проектов используют rspack. Rspack – бандлер написанный на rust, пытается быть совместимым с webpack и местами пытается повторять его поведение. И в webpack и в rspack среди прочих настроек присутствует такая как output.realContentHash, которая говорит о том, что необходимо высчитывать обновленное значение хэш для чанка на основе контента, а затем делать замену в других чанках . Как происходит замена хэш значений? Вспомните задачу выше. Вот это оно и есть. Исходники webpack: webpack/lib/optimize/RealContentHashPlugin.js Исходники rspack: rspack/crates/rspack_plugin_real_content_hash/src/lib.rs Webpack на мой взгляд взял технический долг и вместо честного анализа AST дерева и замены хэш значений проходится по исходному коду и меняет найденные подстроки на свой риск новые хэш. Rspack в свое очередь просто повторяет идею этого поведения, но со своей реализацией на другом языке. Правда в webpack используется md4, а в rspack md4, sha256, xxhash64 — чуть больше реализаций. Тем не менее появляются вот такие issues: https://github.com/web-infra-dev/rspack/issues/5339 https://github.com/web-infra-dev/rspack/issues/8474 Проблема может возникнуть в любом проекте с настройками из коробки, конечно это маловероятно, но поверять мне на слово, что когда это произойдет с вами, то будет очень неприятно. Вся эта ситуация напоминает отрывок из известного фильма с цитатами "Может бахнем?", "Обязательно бахнем, но потом". Как от этого уберечься? Только пытаться уменьшить вероятность такой коллизии. Пытаться не использовать обрезанные значений хэш функций. Пытаться не использовать в исходном коде значения похожие на результаты хэширования. А пока так и живем.