JavaScript *

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

И практически с самого первого дня к нам начали обращаться крупные компании, не с просьбой добавить фичу, а с предложением заплатить. Потому что когда организация всерьёз рассматривает IDE для команды в несколько сотен человек, ей важно знать: есть договор, есть SLA, есть кто-то, кто несёт ответственность и завтра никуда не денется. Бесплатный open-source продукт эту уверенность не даёт сам по себе, как бы качественно он ни был сделан.

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

Так появилась OpenIDE Pro.

История про то, как я сделал себе виртуального аватара для коротких видео — без генерации видео через ИИ.

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

В итоге получилась самодельная полуавтоматическая DIY‑система:

— универсальные графические ассеты персонажа
— ручная озвучка моим голосом
— разметка фраз в аудио через Audacity
— текстовый сценарий с управляющими тегами для событий в ролике
— кастомный JSX‑плагин для After Effects

Система берёт сценарий с управляющими тегами, аудиодорожку с голосом и файл разметки, после чего собирает заготовку ролика: аватар, липсинк, мимику, субтитры и слайды.

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

В конце — немного статистики по первым трём роликам, запущенным с нулевых аккаунтов: YouTube, Instagram, TikTok и ВК.

До момента, когда я сел писать эту статью, я вообще не понимал, что такое тамагочи. Нет, не в смысле «никогда не слышал» — конечно, слышал и видел (не вживую, через экран). Где-то на уровне культурного шума это слово всплывало регулярно в американских фильмах или сериалах, где герой с придыханием вспоминает игрушку детства и рассказывает, как ему это нравилось. Ярче всего у меня в памяти отпечаталась сцена из знаменитого детективного сериала «Менталист»: Патрик Джейн с неизменной полуулыбкой вручает коллеге тамагочи, и тот, взрослый серьёзный мужик (не очень серьёзный на вид, но в момент моего просмотра все взрослые люди серьёзные), вдруг расплывается: «О боже, у меня в детстве такой был! Я их обожал! Как ты узнал!» и т. д.

Раньше я реагировал на такие моменты как на упоминание Game Boy или Dendy: «ну да, старая штука, скорее всего, что-то похожее на Game Boy, который мне был понятен на то время», и я думал: «кому-то дорога как воспоминание, но мне-то чего с того, игрушка есть игрушка». Но сейчас в какой-то момент мне стало понятно, что если об этой игрушке говорят до сих пор, если она пережила три десятилетия и кучу переосмыслений — значит, там внутри что-то большее, и надо посмотреть, что это и как работает.

Так я и сделал. И для начала — немного истории, потому что без неё нет смысла вспоминать и описывать старые вещи (всё, что больше 10 лет назад, уже старое, поэтому, надеюсь, без обид xd).

В начале этого года я создал самую быструю JS-библиотеку для работы с цветом: парсинг различных форматов, конвертация в OKLAB/OKLCH, проверка попадания в P3-гамут и многое другое. Библиотека весит всего 7 КБ и не имеет внешних зависимостей. Высокую скорость обеспечили оптимизации под V8: мономорфизм, скрытые классы, ноль лишних аллокаций.

Начнём с предыстории. Когда я опубликовал первую статью про клон Flappy Bird, я хотел получить результат, который был бы мне приятен, но вместо этого получил всего понемногу. Можно сказать, сработал эффект Зейгарник, когда незавершённая задача создаёт когнитивное напряжение, которое буквально «заставляет» нас возвращаться к мыслям о ней. Вроде поучил физику, посмотрел, как лучше работать с рендерингом, узнал, почему птица стала такой популярной игрой, но один комментарий заставил задуматься, что на этом нельзя останавливаться и стоит сделать ещё что-то, пока эффект не пропал.

npm install — такая привычная многим из читателей команда, но за последние пару месяцев она обернулась сущим кошмаром для инженеров по безопасности. И ладно бы всё сводилось к проверке 5 пакетов из package.json, но у каждой зависимости по 10 своих зависимостей, а у тех ещё по 10. В итоге мы тянем 2000, а не 5 пакетов, и тут, кажется, уже руками не проверишь. И именно на этой боли всех безопасников, поддерживающих JS-проекты, сыграла команда TeamPCP. В этой статье я хочу подробно, от А до Я, разобраться, в чём опасность, почему так произошло и как от этого защититься.

В данной статье Вас ждет подробная история о том, как я создал игровой движок с нуля, совместимым с RenderWare (движком, на котором работает GTA San Andreas), запускающийся в браузере. Один, за три недели, с Claude Code.

Инженеры узнают о межсайтовом скриптинге (Cross-Site Scripting, XSS) тремя способами.

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

А есть те, кто узнает о нем через страдания, когда их сайт становится уязвимым. Когда злоумышленник внедряет скрипт, который крадет токены сессий из localStorage, перехватывает файлы cookie или перенаправляет пользователей на фишинговый сайт. Я лично присоединился к клубу «пострадавших» еще в 2005 году, когда встроенная Flash-подпись на форуме, которым я владел, превратилась в кошмар с точки зрения безопасности… но это уже другая история.

В этой статье мы рассмотрим, как браузер, наконец, снимает с нас бремя очистки данных (sanitizing) благодаря новому HTML API Sanitizer.

Начнём с небольшой предыстории: пару недель назад я ждал друга в кафе. Как обычно, он опаздывал примерно минут на сорок. Ноутбук с собой, интернет есть, а игр нет — чисто рабочая машина, ничего лишнего, хотя нужно будет что-то скачать, чтобы играть на работе xd. От скуки я открыл браузер и набрал в поиске «змейка». Google выдал свою фирменную змейку прямо в результатах поиска.

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

Современные фронтенд-приложения постоянно взаимодействуют с файлами.

Пользователи загружают аватары, перетаскивают видео в дашборды, экспортируют CSV-отчеты, просматривают PDF-файлы, скачивают сгенерированные конфигурационные файлы и работают с медиаконтентом прямо в браузере. На первый взгляд все это выглядит довольно просто: поле загрузки файла, элемент предпросмотра, возможно, кнопка скачивания — и задача решена.

Но именно здесь начинаются настоящие проблемы.

Локальные LLM сейчас — это действительно мощный инструмент. Они уже вплотную приблизились к проприетарным моделям вроде Claude, особенно в задачах кодинга. Я сам активно использую локальные модели для разработки на TypeScript и Go.

На данный момент самая интересная модель для моего стека — Qwen3.6-27B. Но один только выбор хорошей модели ничего не гарантирует. Без правильных параметров вы не получите ни скорости, ни качества.

В этой статье я расскажу, с какими конкретно параметрами запускаю Qwen3.6-27B в llama.cpp (мой текущий фаворит среди бэкендов), какие метрики считаю важными, и как нашел баланс между скоростью, стабильностью и качеством.

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

История о том, как один странный git push оказался началом расследования, которое вывело меня не на один взломанный аккаунт, а на цепочку зараженных репозиториев и проектов.

Снаружи все выглядело почти нормально: знакомый автор, знакомый коммит, привычные файлы. Но внутри последнего коммита уже жил чужой обфусцированный JavaScript. Он прятался в конфиге, менял Git-историю и маскировался под обычную работу разработчика.

Первой версией был взлом моего GitHub, но смена ключей и паролей ничего не решила.

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

Это оказалась PolinRider-like supply chain атака, которая использует сам developer workflow как транспорт.

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

Показываю реальные скриншоты, подозрительные изменения в .gitignore и payload внутри babel.config.js.

В конце оставил скрипты, которые могут помочь быстро проверить свои проекты и логи на PolinRider похожие признаки.

Получится ли сделать полноценную 3D-игру на Qt Quick3D?

Именно такой вопрос у меня возник, когда я начал изучать Quick3D. Казалось бы, рендер и партиклы есть, базовая физика в лице Quick3D Physics тоже присутствует. Пример CharacterController из Qt указывал на то, что проблем быть не должно.

Но хотелось проверить это самому на чём-то реальном.

Поскольку моделлер и художник из меня никакой, да и в геймдеве опыта у меня меньше нуля, я решил переписать Quake — любимую игру своего детства. В ней я провёл сотни (тысячи?) часов, играя в мультиплеер на бесплатных серверах МТУ-Информ через модем US Robotics 33600.

В итоге получился проект Kwayk — попытка переписать Quake на Quick3D.

Недавно я увидел видео, где маленький мальчик собирает кубик Рубика за 2,76 секунды (вот оно), и мне тоже захотелось научиться его собирать. Конечно, не за такое время, но главное — суметь сложить хотя бы за 10 минут. Главная проблема в том, что кубика у меня нет; можно купить, но это как-то скучно, на троечку. Поэтому я подумал: а почему бы не написать за выходные простой код, чтобы побыстрее посмотреть и покрутить кубик, а потом уже можно и купить. Заодно и разберусь, где что находится у кубика.

В январе 2014 года мир сошёл с ума из-за игры, где нужно просто тыкать в экран. Flappy Bird приносила создателю $50 000 в день, пока он не удалил её из-за давления и бессонницы. Игру начали продавать на чёрном рынке вместе со смартфонами.

Я решил собрать свой веб-клон, чтобы понять, в чём же здесь магия. А в конце — откровенный список из 12 проблем, из-за которых мой клон всё ещё не тянет на оригинал.

Привет, Хабр! Меня зовут Даниил Подольский, я программист и архитектор, разрабатываю программное обеспечение и спецификации для создания ПО в YADRO. Вот уже девять месяцев я использую методологию Spec-Driven Development (SDD) в работе и управляю AI-агентами, которые пишут код. При этом я не считаю себя вайбкодером, потому что мой подход к работе более комплексный, чем просто «общение с AI».  

Это первая статья из цикла об оборудовании рабочего места SDD-кодера. Я расскажу о базовой настройке AI-агента Claude Code: что делать, если вы хотите оперативно и без перезагрузки переключать используемые модели и делать это для каждого проекта отдельно.

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

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

И в какой-то момент я осознал простую истину: если ты не можешь остановить глобальную деградацию веба — возглавь её.

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

Встречайте: Шакализатор сайтов 3000.

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

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

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

Мотивацией для написания этого поста стали два года собеседований JS/TS-инженеров. Я интересуюсь языками и функциональным программированием, поэтому всегда «разбавлял» технические вопросы разговором о парадигмах. И заметил любопытную асимметрию.

Об ООП кандидаты рассуждали уверенно — но в основном на концептуальном уровне, не вдаваясь в то, как именно ООП реализовано в JavaScript. С FP картина была другой: уверенности меньше, зато критика — конкретная и повторяющаяся: «иммутабельность дорогая по памяти», «рекурсия небезопасна из-за стека». Что характерно — эти аргументы почти всегда были сформулированы через опыт работы с JS, а не с Haskell, Clojure или Scala.

Это важная деталь. Любая парадигма существует на двух уровнях: концептуальном (идеальная модель) и имплементационном (как конкретный язык эту модель выражает). Судить о FP по JS — примерно то же самое, что судить об ООП по bash-скриптам с глобальными переменными.

Параллельно я регулярно слышал, что JS — функциональный язык. Аргументы варьировались от «там есть .map()» до рассуждений о чистых функциях и каррировании. Именно это и стало поводом для поста: я хочу объяснить, что я считаю функциональным языком — и почему JS таковым не является. Не перечислить отсутствующие фичи, а показать, почему их нет и что это значит в реальном рантайме.