JavaScript *

Разработка 3D-игры в одиночку.

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

Прошлый раз я рассказал, как написал свой калькулятор раскладки плитки, потому что замучился считать ванную в столбик. Тот пост был про версию 1.2 — база, прямая/диагональная раскладка, смета, PDF, нумерация плиток. Комменты были классные, фидбек пошёл сразу, и за месяц я выкатил ещё три версии. Самое заметное — ёлочка и общий план квартиры, где все комнаты лежат на одном полотне. Про это и пишу.

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

Её дали пять довольно тупых правок от двух до тридцати строк каждая. Самая полезная - две строки в конфиге камеры.

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

Хайп-цикл фронтенда, кажется, наконец-то выдохся. Мы вышли из фазы бесконечного переизобретения колеса, где каждый месяц появлялся «убийца React», и вошли в эпоху убийцы Fable инженерной зрелости. Сегодня опытного инженера сложно впечатлить очередным фреймворком: ценность сместилась в сторону предсказуемости, скорости поставки (delivery) и снижения когнитивной нагрузки.

Привет, меня зовут Павел Востриков, и я — архитектор веб-направления в «Лаборатории Касперского». В этой статье хочу разобрать JS-экосистему как набор инженерных компромиссов.

На HolyJS Spring 2026 мы предложили 120+ инженерам оценить свой реальный стек. Получившийся радар мог быть просто списком библиотек, но в итоге вышел срезом того, как выглядит рациональный подход к коду в 2026 году. Мы видим, как разработчики массово идут в сторону предсказуемой скорости масштабирования решений и инженерной гигиены.

Умереть в моей игре нельзя. Можно только похудеть.

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

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

Какое-то время назад я выкладывал статью на Хабр про свое obsidian хранилище.

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

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

Встроенный граф Obsidian хорош ровно до момента, когда vault разрастается и превращается в клубок линий. Я решил сделать из базы знаний место, которое можно запомнить, — и собрал open-source плагин CosmoGraph 3D на Three.js и WebGL. В статье разбираю весь путь от metadataCache и wikilinks до сферической раскладки по золотому углу, процедурного рельефа, кратеров, bloom и нативного ItemView внутри Obsidian. Без облачной обработки заметок и без рассказов о «магии»: только код, архитектурные компромиссы и честный список того, что ещё предстоит ускорить.

«Я собрал приложение за выходные». Почему вайбкодинг в проде опаснее, чем кажется.

Где заканчивается прототип и начинается инженерия, почему «работает у меня» не равно «готово для бизнеса» и за что на самом деле платят опытной команде.

Если бот копирует один и тот же пост в десять каналов, в Google Analytics все клики свалятся в одну кучу. URL у скрытой ссылки живёт не в тексте, а в MessageEntity, а copyMessages копирует его как есть. Ниже — как пересобрать пост под каждую площадку, не сломав жирный шрифт, эмодзи и health‑check.

Telegram умеет одно очень удобное действие: copyMessages. Берёте сообщение из чата A, кладёте в чат B — форматирование, медиа, альбом, скрытые ссылки, всё на месте. Для рассылок и зеркал это идеальный метод.

Для рекламы он ломает самое важное.

Рекламодатель покупает размещения в разных каналах и смотрит в свою аналитику: откуда пришёл клик. Если во всех десяти постах в text_link лежит один и тот же https://shop.example/sale, UTM бесполезен. Каналы неразличимы. Сделка неразличима. Дата размещения неразличима.

Попросил Claude написать таймер одним HTML-файлом — а телефон его не будит: вкладка спит, будильник не звонит. Сделал Kapsula: приложение для Android и iOS, которое запускает такой файл как проект с настоящими будильниками ОС через мост из пяти методов. Внутри — iframe без same-origin, postMessage-RPC, три грабли Android-уведомлений, звук на iOS, правило состояния для ИИ-кода и промпт вместо SDK. Без сервера, без аккаунта, без аналитики.

Как я навайбкодил панель для Wireguard ASC 3.x чтобы не просто безопасно выходить в Интернет, но и объединять устройства в одну сеть.

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

Тот же Rust‑код, что рисует топологию на десктопе, собирается в wasm и рисует в <canvas> через WebGPU. Сайт при этом не знает про GPU: кликнул на нарушение в списке, камера уехала на место, маркер показал дефект. Ниже как это устроено, где «просто пересобрали» было бы враньём, и какие ловушки сидят не в Rust, а в вебе.

Задача

У нас десктопный инструмент для топологии интегральных схем, layout в формате GDSII (и OASIS). Файл описывает геометрию кристалла: иерархия ячеек, на листьях прямоугольники и полигоны по слоям (металл, поликремний, диффузия). Координаты целые, в DBU, единицах базы данных; в микрометры переводим уже при развороте сцены. Реальный проект: сотни мегабайт на диске, миллионы фигур после разворачивания иерархии.

Рядом выросла веб‑платформа с результатами анализа этих дизайнов. Захотелось показать сам layout в браузере, в том же UI: клик по нарушению в списке открывает его место на топологии. В десктопных пакетах это называют RVE, results viewing environment. Нам нужна была такая навигация без второго рендер‑движка.

Что отсекли сразу

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

Canvas2D или SVG на JS. На миллионах прямоугольников не работает. И это был бы второй движок.

Отдельный JS/TS‑парсер и рендер. Формат один, интерпретации через полгода две. Для GDS это особенно опасно: иерархия, зеркала, массивы ссылок.

Остался вариант, который мы и сделали: тот же Rust, цель wasm32-unknown-unknown, картинка в <canvas> через WebGPU.

Абсолютные импорты без расширений в ESM-монорепозитории.

Настраиваем Vite, TypeScript и автоимпорты в IDE (VSCode) с помощью “subpath imports”.

Разрешаем конфликты настроек без костылей.

Добавляем приоритет автоимпорта папок в качестве модулей, при наличии “index.ts”.

Настраиваем Vite и TypeScript на работу с исходниками компилируемой библиотеки в dev-режиме.

Скролл-фильм на лендинге — это обычно сотни WebP и десятки мегабайт. Рассказываю, как заменил секвенции кадров сырым H.264-потоком без контейнера и WebCodecs-декодером: 84 → 18 МБ на мобиле. С параметрами кодирования и тремя честными тупиками: почему HEVC оказался хуже x264, зачем шумодав не нужен и как B-кадры сломали фильм на живом iPhone так, что валидация этого не увидела.

В первой части мы разобрали архитектуру Rari, почему Rust под V8 даёт выигрыш, и посмотрели на бенчмарки. В данной статье хочется поговорить о том, что обычно остаётся за кадром демо: как это работает в продакшене, что конкретно поменялось под капотом, где ломается совместимость с Next.js, как мы портировали их SWC-плагины, и как производительность выросла с 4x до 67x.

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

Число запросов, объём сгенерированного кода и расход токенов показывают активность модели и её стоимость. Для оценки пользы нужны другие данные: сколько времени сэкономил разработчик и прошёл ли результат приёмку.

Для оценки каждой задачи нужны три параметра:

У меня браузерный генератор вывесок: человек набирает надпись, получает STL-модель корпуса под светодиодную ленту. Всё считается на его же машине, файл никуда не уходит. Однажды пришёл вопрос, который сломал мне неделю: надпись 500 мм, стол принтера 256×256. Что делать?

Стандартный ответ — «режьте в слайсере». Слайсер режет плоскостью, и это честно работает ровно до момента, когда вы забираете со стола две половинки со стеклянно-гладкими срезами и понимаете, что совместить их нечем. Клей по гладкому PLA держит на честном слове, при склейке половинки едут, и на видном месте остаётся ступенька.

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

Задумывались ли вы когда-нибудь о том, что на самом деле происходит под капотом, когда вы рендерите приложение React? Мы знаем, что React строит дерево DOM и отображает UI на экране, но как React конструирует это дерево и как он эффективно обновляет его при изменении состояния?

В этой статье мы рассмотрим React Fiber — основной движок согласования (reconciliation) React. Мы рассмотрим, как React строил DOM до v15, недостатки этой ранней стековой (stack) модели с точки зрения производительности и то, как асинхронная архитектура Fiber решает эти проблемы, начиная с React v16 и до React v19.

Как просьба друга «настроить кассу» закончилась open-source ERP, тринадцатью российскими интеграциями и нейросетью, которая теперь считает закупки, ищет косяки в учёте и пишет владельцу в Telegram.

Есть у меня друг. Назовём его Артём.

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

Примерно за месяц до открытия Артём пришёл ко мне с классической фразой:

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

Если вы когда-нибудь были «тем самым знакомым программистом», то примерно понимаете, чем обычно заканчивается слово «помоги». Сначала задача выглядела просто: выбрать что-нибудь вроде iiko, поставить, настроить и забыть.

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

Так в ресторане появился DeepSeek, который скоро заменит Артема, а может и всех остальных. Сам будет заказывать еду, сам кушать... ну это я отвлекся.

Сразу важный момент. Я не писал ресторанную ERP с нуля. Это был бы отличный способ потратить много времени и получить плохую кассу. Я взял готовую open-source систему и начал допиливать её под конкретный ресторан. И вот здесь всё стало интереснее.