Веб-разработка *

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

В этом есть своя прелесть и свои ограничения. С которыми я прямо столкнулся во время решения задачи.

Агент несколько раз писал «готово» или «да, теперь идеально!», но на экране оставались углы в воздухе, узкая колонка по центру и сетка вместо одной формы. По итогу у меня получился стресс-тест для моделей, с которыми они так и не справились.

Состояние во Vue обновилось, а интерфейс остался прежним — и начинается охота на watch, nextTick и принудительный ререндер. Разберём, где именно рвётся реактивная связь, почему это происходит и как находить такие проблемы до того, как вокруг них вырастут костыли.

После статьи о выборе Tauri нас спросили, сколько памяти будет занимать программа, которая живёт в трее рядом с игрой. Мы запустили старый БОЛТУН на Win32 и новый на Tauri в одинаковом пустом лобби. Получилось 2,2 МБ против 128 МБ. Разбираемся, откуда взялись девять процессов WebView2, что показал замер и почему это не стало автоматическим отказом от нового интерфейса.

Что происходит, если вместо массовой раздачи AI-инструментов сначала изучить, как на самом деле работают команды?

Рассказываю, как мы начали AI Enablement в крупной финансовой организации: оценили 13 команд, визуализировали их delivery pipelines, обучили около 800 человек и построили программу вокруг реальных ботлнеков, а не вокруг модных AI-инструментов.

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

Обычно мы не замечаем эти этапы. Они становятся заметны, когда сайт начинает тормозить. Задержка может появиться ещё до обращения к серверу — например, во время DNS-резолвинга, — или уже после получения ответа, когда браузер разбирает JavaScript и строит интерфейс.

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

Тот же 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.

Переписал с Perl/GTK3 на C++/GTK4 ds-measurer — утилиту для измерений поверх живого экрана, снятия скриншотов (в буфер обмена и/или на диск) и цветов в различных CSS-нотациях (в буфер обмена и/или c выводом на экран).

Есть поддержка цветовых схем с переключением по ним, направляющих с прилипанием к ним, выделение из центра и/или с фиксированным соотношением сторон, настраиваемые сетки и хоткеи.

Знакомая ситуация: продукт написан за выходные, гипотеза подтвердилась, кто‑то уже платит. Приходит дизайнер и просит файл.

Файла нет. 

Есть интерфейс, который существует только в виде кода. Кнопка там называется.btn‑primary,.btn‑add и.button‑save — три класса, одна кнопка, паддинги отличаются на пиксель. Серый цвет записан тремя способами, и один из них, судя по всему, опечатка. Отдать это дизайнеру нельзя. Нарисовать заново — значит выбросить полгода работы и начать спорить про радиусы. 

Мне стало интересно, что тут реально может AI. Не «сделай красиво», а честный замер: я собрал маленькое демо, намеренно заложил в него шестнадцать несогласованностей, записал их в отдельный файл и спрятал. Потом запустил на этом коде свежую сессию Claude Code, которая файла с ответами не видела.

В статье — что из этого вышло, с цифрами и с местами, где всё сломалось.

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

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

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

В интернет‑магазинах уже есть поиск, фильтры и карточки товаров. Но этого часто недостаточно, когда человек приходит не с конкретным названием товара, а с задачей. Например: «Мне нужен инструмент для ремонта квартиры» или «Чем отличаются эти два товара и какой подойдет лучше?».

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

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

Проект мы разрабатывали командой ASAP, и в этой статье разберем, как мы подошли к проектированию AI‑консультанта: устроили взаимодействие LLM с каталогом более чем из 200 тысяч товаров, какие задачи оставили коду, как работаем с актуальными ценами и остатками и почему вокруг языковой модели в итоге пришлось построить достаточно большой слой классической backend‑логики.

Привет, Хабр!

В CSS огромное количество псевдо-элементов и псевдо-классов. Так много, что я не знаю ни одного фронтендера, который помнит все. Я тоже не исключение из этого правила.

Часто нахожу что-то новое и интересное у зарубежных блогеров, рассказывающих о CSS. Так что неудивительно, что мы с вами упускаем пользу. Это нормально.

Сегодня я пришёл к вам, чтобы исправить это. Мы рассмотрим несколько псевдо-элементов и псевдо-классов, которые, по моему мнению, редко используют. Хотя они принесут немало пользы!

Давайте посмотрим, что я вам подготовил.

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

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

Август для меня традиционно пора проведения аудитов сайтов и кабинетов контекстной рекламы Яндекс.Директ. Поток писем и звонков с вопросами идет волнами.

Что интересно, до сих пор довольно большая часть корпоративных сайтов все еще не соответствуют требованиям Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных». А подавляющая доля тех, кто работает с контекстной рекламой, не знает о том, что Яндекс включает новые опции и инструменты автоматически, и сильно удивляются, почему проседает поток лидов.

Давайте обсудим, на что нужно обратить внимание.

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

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

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

Дальше не про кнопки, а про проверки: какая доска настоящая, не протух ли ответ, пока считал движок, куда девать WASM, когда Chrome гасит service worker, и почему «сыграй как 1500» нельзя получить, урезав глубину. Отдельно, без эвфемизмов: подсказка в партии с человеком — это чит.

Этой весной мне понадобился лист QR‑кодов с подписями: по коду на каждую позицию, чтобы скачать PDF, распечатать и разрезать. Онлайн‑генераторы делают коды по одному или просят подписку за пакет, так что я написал свой сервис на PHP 8.2. В посте про то, что интереснее разработчику: чистое детерминированное ядро с golden‑тестами байт‑в-байт, кириллические домены и punycode, кириллица, которую TCPDF молча теряет в SVG, артикулы в виде 4.6E+12 из Excel, “прозрачный” PNG с маджентовым фоном и самописный EAN-13 с оракулом в тестах.

Когда используешь корпоративный VPN для рабочих сервисов и локальный прокси для “внешних” сайтов, то иногда просто добавить основной домен в прокси оказывается недостаточно:

YouTube может остаться без превью, Letterboxd — без постеров, а ChatGPT — без загрузки файлов.

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

Привет, хабр! Уже 11 лет я пилю свой игровой движок, и я готов представить его публике. Я все еще дорабатываю его, но он уже вполне стабилен и я делаю игры на нем.

Движок открытый и бесплатный, нацелен преимущественно на мобильные игры, поддерживает пачку платформ — ios, android, web, mac, windows, linux. Он компактный (всего несколько мегабайт), производительный, позволяет писать логику игры как на C++, так и на JavaScript. Внутри есть убер‑редактор для всего — вот он на скриншотике выше

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

Сразу скажу что именно чтобы тем кому надо знать только итог не тратили свое время на чтение. Сайт лежит в виде виртуальной машине убунта без морды на арендованном довольно шустром хосте с 64 Озу 12 ядер 500 ССД и канал 1G. Хост крутит тоже убунта без морды.

Ну и для сайта выделено было пару ядер и пару гигабайт памяти.

Что делает сам сайт — он подключен ко всем буквально источникам новостей об ИИ как к лидерам рынка, так к вендорам и агрегаторам. Суммарно 100 источников. Он собирает все новости что найдет и те что не на английском переводит на английский. Затем чистит от дубликатов. То что осталось раскладывает на рубрики, переводит на 15 языков и выкладывает себе в ленту, выкладывает в Канал в телеге на русском только и все новости на всех языках пихает в ленту RSS.

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

И вдруг выясняется что сайт на этой машине буквально еле ползает. Сайту неделя. Я там единственный пользователь. И чтобы ему нормально было работать оказалось что надо до 6G ему добавить память и выделить еще два ядра. Провел я расследование и вот что оказалось