JavaScript *

На 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-режим, зависимости и скоупы.

Хочу анонсировать свой фреймворк Point0. Это первый Bun FullStack фреймворк сопоставимый по функционалу с Next.js и TanStack Start. Однако, имеет кардинально другой DX, ради которого и был создан.

Мне всегда не нравились существующие фреймворки, особенно Next.js и Remix (React Router). Но я думал, что, видимо, по-другому фреймворки просто не получаются, поэтому и не делают. А громоздкость, чужие строгие соглашения, неповоротливость архитектуры, это просто необходимое зло, с которым я должен смириться.

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

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

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

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

Делимся веб-компонентами

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

Расскажу, как и почему я в какой-то момент решил написать собственный pivot grid — без сторонних библиотек, на чистом JavaScript и DOM. И что из этого получилось: от первой версии с обычным GROUP BY до кэширования больших выборок и цепочки связанных гридов.

Ну что же…, на дворе 2026 год, первый DogPlanner живёт своей жизнью, доступен на многих площадках мобильных приложений, мы о нём много писали в соцсетях и различных блогах. С тех пор как мы сделали его, а опубликовали мы его аж в июне 2020 года, вы прислали нам много различных идей по его доработке, написали множество отзывов, а также мы узнали о приличном количестве проблемных мест по его функциональности и содержанию, и всё это было абсолютно заслуженно! Хотим сказать вам огромное спасибо за всю обратную связь, которую мы получили, и получаем до сих пор от вас! Но давайте снова вернёмся к критике…

Предисловие

Возможно то, про что я хочу рассказать в своей первой статье тут, покажется не новым, уже знакомым велосипедом. Речь пойдет о контроллерах на базе ESP32 и программном обеспечении. Да, современных решений, открытых и бесплатных – много. А сейчас зарождается еще одно (а опенсорса мало не бывает, я считаю).

В статье я упущу и не буду рассказывать ни про свое знакомство с ардуиной, esp, php, python, js ни про то, что пришел сюда давным-давно гуманитарием. И да простят мой, вероятно не корректный, «жаргон» истинные профессионалы в микроэлектронике и программировании - итак, приступим.  

Совсем недавно я отключил RPI4 с HA и наконец «воткнул» в котельную очередную, но «готовую к деплою» версию контроллера (разрешите его далее называть «УМНЫЙ К1», спасибо).

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

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

Уже почти июнь подходит к концу, а я так и не выпустил эту статью. Исправляюсь.

Обзор на браузерные API, которые стали Widely available в мае 2026. Раз в месяц я буду вам напоминать, что вы уже можете использовать в проде.

Каждый месяц выходят новые CSS-свойства, HTML-атрибуты, JavaScript-методы и WebAPI, но применять в проде мы их конечно же не будем. 2.5 года назад также каждый месяц выходили новые фичи в браузере, а вот их уже пора начинать применять.

У меня в Obsidian накопилось под две тысячи заметок. Ежедневники, конспекты, обрывки идей, недописанные черновики. Граф‑вью честно показывает мне облако точек: красиво, но бесполезно. Какие заметки висят сиротами без единой связи, какие дублируют друг друга под разными тегами, какие кластеры тем так и не соединились, из графа не вытащить.

Очевидная мысль: «отдам всё LLM, пусть разберётся». Но 2000 заметок это миллионы токенов. Ни в один контекст это не влезает, а если бы и влезло, стоило бы как крыло самолёта и утонуло бы в шуме.

Так появился идея по созданию Vault Audit AI, плагин для Obsidian, который проводит аудит хранилища через LLM: находит сироты, кластеризует темы, предлагает теги и связи. Я его опубликовал в официальном каталоге и выложил на GitHub. В этой статье разберу инженерную начинку: как обойти лимит контекста через MapReduce, как не платить за повторный анализ, как абстрагировать четырёх LLM‑провайдеров под одним интерфейсом, и что пришлось переделать, чтобы пройти автоматическое ревью каталога.

Код на TypeScript, фрагменты настоящие (слегка почищены от обёрток локализации ради читаемости).

Спойлер: коды готовы — вставьте и пользуйтесь.

Знаете, что меня расстраивало больше всего в чатах с нейросетями? Сидишь, читаешь длинный ответ в момент генерации. Дошёл до середины, понял, что упустил какую-то деталь в начале, крутишь скролл вверх. А бот в этот момент дописывает новый абзац, и весь текст уезжает обратно вниз.

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

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

Если к вам придут с задачей внедрения интерактивной карты офиса, какой рендер вы выберете? Canvas или SVG? Верхнеуровневый обзор скажет, что Canvas хорош для частых перерисовок (географические карты, игры), а SVG — когда важна работа с отдельными элементами, которые естественным образом присутствуют в DOM.

Мы выбрали SVG.

В этой статье не будет глубокого анализа, это живая история о том, почему мы отказались от идеи использовать Canvas, как строили карту с нуля, какие инструменты использовали, как организовали связь между SVG-элементами и данными в БД, и как сделали админку, где карту могут менять дизайнеры без участия разработчиков.