JavaScript *

Это продолжение моей статьи о том, как я сделал движок совместимый с GTA San Andreas для запуска в браузере, рекомендую сначала прочитать:

https://habr.com/ru/articles/1051828/

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

Я не пытался сделать «приватный мессенджер» и вообще не думал про слежку и прослушку.

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

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

В прошлых статьях я уже подробно разобрал базовую инфраструктуру Matomo: как развернуть систему на собственном сервере LAMP, рассчитать нагрузку, выстроить правильную архитектуру сайтов, measurable и Roll-Up аналитики внутри Matomo. Но вся эта серверная часть — только фундамент. 

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

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

Angular часто воспринимают как тяжёлый корпоративный фреймворк «из прошлого»: сложный вход, много правил, меньше хайпа, чем у React. Но за последние годы фреймворк заметно изменился: появились сигналы, обновился SSR, стало проще начинать, а экосистема перестала быть закрытым «котлом» только для энтерпрайза.

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Олегом Щёголевым — frontend-разработчиком, преподавателем, ментором и специалистом по Angular автором Telegram-канала «SUMMON_THE_CODER».    

В этом выпуске мы разбираем путь в профессию, реальные проекты, ситуацию на рынке труда, зарплаты, использование нейросетей в разработке, статус GDE, современный Angular, сигналы, SSR, CLI, директивы, модули и главный вопрос: почему React популярнее, но крупные компании всё равно продолжают выбирать Angular.

Эта идея появилась у меня давно.

Когда мы внедряли BI в крупном банке, я заметил одну вещь: больше всего внедрению радовались руководители. У них появлялись дашборды, графики, показатели, визуальная картина происходящего.

А вот люди, которые каждый день работали с данными, не всегда были в таком же восторге.

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

И вот тут уже приходится разбираться не с графиком, а с данными.

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

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

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

Так появилась первая версия программы: она формировала отчёты в Excel и хранила на сервере историю выгрузок.

9 мая пост «I’m going back to writing code by hand» набрал на Hacker News 1038 баллов и 617 комментариев. Автор семь месяцев вайб-кодил Kubernetes-дашборд с Claude, дошёл до god object на 1690 строк и бросил AI-кодинг. Я узнал в этом свою историю полугодовой давности, но вывод сделал другой.

Решил я поиграть на выходных в Carmageddon. Но вот незадача!- Заводить всё это в эмуляторе DosBox нет никакого желания (он стоит у меня для других целей, ну вы понимаете))- То что мы с Сашей Гурьяновым делали на DosZone у меня тормозит, так как не вывозит мой старенький процессор. Пора уже собрать комп для нашей ДОС Зоны))- Ремейки типа Carmageddo: Max Damage и Reincarnation полная фигня. Куплено в стиме и полно разочарования

Что же делать? Будем сами портировать в браузер! Всё как мы любим. Для эксперимента и развлечения ради!

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

Привет, Хабр! Меня зовут Оля Борисова, я фронтенд-разработчик в ПСБ. Работала как в продуктовых, так и в платформенной команде. Сегодня хочу поделиться нашим опытом разработки внутренних пакетов, их релизным процессом, расскажу какие проблемы у нас были, а также постараюсь дать советы тем, кто еще в начале пути.

На момент написания статьи у нас около 300 репозиториев, большинство из которых представляет собой внутренние библиотеки, утилиты, конфиги и микрофронты. 

Так было не всегда, когда-то у нас был один проект и все что с ним связано (компоненты, хелперы, конфиги и прочее) хранилось внутри него. Это работало пока не появилась надобность переиспользования наработок и лучших практик в других приложениях и направлениях. Так мы пришли к тому, что нам необходимы внутренние пакеты и механизмы их организации и менеджмента.

Красная волнистая линия под строкой раздражает, и самый быстрый способ её убрать — дописать any, as или !. Компилятор замолкает, сборка зеленеет, PR уходит дальше. Вот только ошибка никуда не делась: она переехала из редактора в рантайм, поближе к пользователю.

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

Поэтому на code review я задаю не привычное «как затипизировать, чтобы TypeScript замолчал», а обратный вопрос:

Что именно я здесь отключаю — и правда ли без этого нельзя?

Веду frontend-команду, много времени провожу в чужих диффах, и про any, as и ! у нас постепенно сложился небольшой свод договорённостей для review. Из него и выросла эта статья: 13 сценариев, которые складываются в один короткий фильтр. Для каждого есть пара «плохо → хорошо» и рабочий пример на TypeScript 6 — всё можно потрогать в playground (он написан на React, но сами приёмы относятся к TypeScript в целом). Разберём any и unknown, сужение и type guards, satisfies, as const, оператор ! и валидацию данных на границе.

Главная мысль:

Типы — это проверяемые обещания о данных. any, а также необоснованные as T и !, позволяют компилятору принять такое обещание без доказательства. Если тип неизвестен — это unknown и сужение; если известен, но невиден компилятору — это guard, валидация или контролируемый инвариант, а не слепое утверждение.

На code review я регулярно встречаю один и тот же вопрос, только записанный разным кодом: «Как правильно синхронизировать эти значения через useEffect?»

Со временем я понял, что чаще полезнее спросить иначе: а эффект здесь вообще нужен?

В статье разбираю 12 типичных сценариев из React-код-ревью: производное состояние, события, цепочки эффектов, внешний store, useEffectEvent, загрузку данных и современные подходы React 19.2. Для каждого случая — пример «плохо → хорошо» и практический фильтр, который помогает выбрать между рендером, обработчиком события, Action, useEffect или query-библиотекой.

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

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

Самое обидное, что я понимал: дело не в моей исключительной лени. Так происходит у большинства. Более того, многие вообще не начинают вести базу знаний, потому что заранее боятся этого хаоса. «У меня будет свалка из трёхсот файлов, зачем начинать». И из этой личной боли выросла идея плагина.

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

Как я ускорил работу с тулингом на своем проекте в среднем более чем в 10 раз, заменив JS-инструменты на нативные.

Поиск работы в 2026 году — это инженерная задача, которую все решают вручную. hh.ru перемешивает релевантные роли с шумом: на запрос «Senior PHP» прилетают джуны, фронтендеры и «PHP со знанием 1С». Одна и та же вакансия репостится под разными URL — и отследить, что ты уже откликался на неё месяц назад, практически невозможно. Зарплатные вилки скрыты или указаны в разных форматах. Значительная часть рынка вообще живёт вне hh — в ATS западных компаний (Greenhouse, Ashby, Lever, Workday), на Habr Career, в GetMatch и GeekJob, и у каждого источника свой API и своя схема данных. А поверх всего этого — ИИ по обе стороны воронки: резюме первым читает ATS-скринер, а не человек, рынок захлёстывают массовые AI-отклики, и рекрутёры в ответ закручивают фильтры.

Если декомпозировать задачу честно, получается типовой ETL-конвейер: агрегация из неоднородных источников, нормализация и дедупликация в единую модель, скоринг против резюме, трекинг откликов во времени. Ровно то, что бэкендеры строят на работе, — только над данными о собственном трудоустройстве. Я так и поступил: написал локальный клиент, который агрегирует 41 источник, оценивает каждую вакансию под резюме, ловит репосты, ведёт воронку откликов и разворачивается одной командой. Сервер слушает только loopback — резюме и история откликов не покидают машину.

В статье — разбор архитектуры и решений: фронтенд без сборки и без virtual DOM, два реестра адаптеров с тестами на согласованность, SSRF-защита на DNS-pinning, двухфазный SSE с детерминированным завершением, 13 локалей с RTL, тестовая пирамида из 1543 кейсов и Spec-Driven Development как замена командного ревью для solo-проекта.

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

┼┼┼┼┼┼┼┼┼▄▀▀▀▄▄▄▄▄▄▄▀▀▀▄┼┼┼┼┼┼┼┼
┼┼┼┼┼┼┼┼┼█▒▒░░░░░░░░░▒▒█┼┼┼┼┼┼┼┼
┼┼┼┼┼┼┼┼┼┼█░░█░░░░░█░░█┼┼┼┼┼┼┼┼┼
┼┼┼┼┼┼─▄▄──█░░░▀█▀░░░█──▄▄─┼┼┼┼┼
┼┼┼┼┼┼█░░█─▀▄░░░░░░░▄▀─█░░█┼┼┼┼┼
┼┼┼██░██░████░██░░░██░░░█████┼┼┼
┼┼┼██▄██░██▄▄░██░░░██░░░██░██┼┼┼
┼┼┼██▀██░██▀▀░██░░░██░░░██░██┼┼┼
┼┼┼██░██░████░████░████░█████┼┼┼

Для строительства компиляторов, нам нужны начала математики. Из них, как мы убедимся, проистекает добрая половина понимания и всех наших работ.
В частности, без начал не понять лямбда-исчисление Чёрча, которое мы применим на этапе работы с AST. Рассмотрим элементы дискретной математики с примерами на С, JavaScript, SQL.

В прошлых статьях мы рассказывали про архитектуру ГИГАХРУЩА — браузерного survival horror с процедурной генерацией, WebGL-рейкастером и полноценным симулируемым миром (A-Life, Самосбор, физика) без использования готовых движков вроде Unity или Godot. Проект работает полностью локально, загружаясь в браузер за секунды.

Но что, если мы хотим добавить мультиплеер, где игроки смогут вместе ходить по одним и тем же бесконечным бетонным коридорам, встречать друг друга, отстреливаться от монстров и прятаться от гермодверей во время Самосбора?

Обычно для таких задач пишут выделенный headless-сервер на Node.js или C++, который крутится 24/7. Но у нас жесткое правило: мы делаем независимый проект с инфраструктурным бюджетом в $10/month. Мы не можем держать десяток мощных серверов, постоянно просчитывающих сотни процедурных этажей для пустого мира.

Вот как мы решили эту архитектурную задачу. Спойлер: браузер одного из игроков работает как полноценный сервер симуляции, а Cloudflare Durable Objects используются только как легковесный релей.

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