TypeScript *

Почему зелёный CI не гарантирует, что система работает

Кейс из QA automation: как миграция на TypeScript привела к скрытому удвоению тестов без единого падения в CI

CI зелёный.

Тесты проходят.

Pull request’ы мерджатся.

Но система уже сломана.

И самое опасное — это не видно ни в логах, ни в отчётах CI.

В большинстве команд CI воспринимается как индикатор здоровья системы:

• зелёный CI → всё работает

• красный CI → есть проблема

Это удобная модель. Но она не всегда верна.

Контекст кейса

После миграции проекта с JavaScript на TypeScript мы заметили странное поведение:

• CI стал выполняться почти в 2 раза дольше

• тесты не падали

• ошибок не было

• метрики оставались “нормальными”

На первый взгляд — ничего критичного.

Что происходило на самом деле

Playwright начал подхватывать одновременно два набора тестов:

• .spec.js

• .spec.ts

В результате один и тот же тестовый набор запускался дважды.

Самое неприятное — CI не просто не показывал проблему. Он создавал иллюзию, что всё становится лучше: время выполнения росло постепенно, и это воспринималось как “нормальная деградация после миграции”.

Почему это было незаметно

Проблема усугублялась полным отсутствием сигналов:

• CI оставался зелёным

• тесты не фейлились

• никаких warning’ов

• никаких алертов

Единственный симптом — увеличение времени выполнения. Которое списали на “ну TypeScript, наверное тяжелее”.

Как проблема была обнаружена

Случайно. Ближе к завершению миграции, при удалении .js файлов, количество тестов внезапно сократилось примерно в два раза:

• было ~240

• стало ~120

До этого момента CI фактически выполнял двойную работу — без каких-либо признаков аномалии.

Root cause

Root cause оказался банальным — и именно поэтому его так долго не замечали.

В playwright.config.ts отсутствовал явный testMatch. Playwright по умолчанию подхватывает все файлы, соответствующие glob-паттерну — и .js, и .ts одновременно.

Фикс — одна строка:

testMatch: [‘**/*.spec.ts’]

Но чтобы до неё дойти, нужно было сначала понять, что вообще происходит.

Архитектурный вывод

Большинство проблем в тестовых системах не проявляются как падения.

Они проявляются как:

• дублирование выполнения

• скрытая деградация производительности

• изменения в поведении runner’а без изменений в тестах

И у них нет алертов — потому что мы их не проектируем.

Например, в нашем случае проблему можно было бы поймать простым счётчиком discovered tests в CI.

Финальный вывод

CI — это не инструмент контроля качества системы. Это инструмент контроля того, что тесты не упали.

И если вы используете его как индикатор качества — вы просто получаете ложную уверенность быстрее.

CI отражает только одно: тесты выполнились без явных ошибок.

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

Если система может быть “зелёной” и при этом работать некорректно — значит у вас есть статус выполнения, но нет наблюдаемости.

Как это выглядит в реальной системе

Именно этот кейс лёг в основу проекта, который я собирала как QA portfolio. В pipeline добавлен счётчик discovered tests: если количество отклоняется от ожидаемого, CI падает явно, а не молчит. Рядом — buggy branch с намеренно сломанной конфигурацией, чтобы можно было воспроизвести и починить самостоятельно.

Код и структура проекта: GitHub (https://github.com/Ariless/clinic-booking-api-tests)

Если собираешь QA портфолио или готовишься к техническому собеседованию — в Telegram-канале Тесты как система (https://t.me/qa_as_a_system) разбираю такие кейсы с кодом и объяснением: что показывать, как объяснять решения, какие находки работают на собеседовании.

Обновлена открытая библиотека theSVG из 5 880+ векторных SVG-иконок для разработчиков и дизайнеров. Есть вшитый поиск, CDN, CLI, API и готовые пакеты для React, Vue и Svelte. Бонусом у иконок есть разные варианты: цветные, монохромные, светлые, тёмные и wordmark.

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

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

Авито:

1. Всё адово тормозит при рендере. Ему надо дать сильно подумать внутри браузера, прежде чем на что-то уже можно будет нажать. "эти компутеры в космос запускать можно, а вы одну кнопку нормально сделать не можете". Тупая фраза, но мысль передаётся.

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

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

4. Непродуманные элементы управления в принципе дофига где. Много слабо интуитивного, неудачные расположения, пропадающие элементарные фильтры в непредсказуемых местах. В одной категории фильтр "Б\У" есть, а если подняться в родительскую - уже нет. Почему? Например контр-интуитивен и туп сам факт того, что нельзя просто написать в строке поиска used:1 pricerange:100-500 и просто вывалить кучу всего бу из любых категорий от 100 до 500 руб. Какие-то выпадающие менюшки вокруг логотипа "авито" такие, что раскрываются и загораживают сам логотип, если ты попытался прицелиться в него (чтобы перейти на главную) и чуть промахнулся. Жмёшь на какой-то пункт этой менюшки в итоге.

Я вот просто в целом экономически не понимаю как так получается. Что за АвтоВАЗ? Там у вас победило "можно, а зачем"? За что вы платите 450к/сек фронтендерам? Видимо просто за "желательно ничего не сломать, но внедрить новую кнопку от партнёра". Ну ладно, допустим - корпорация, все заняты митингами и KPI, работать некогда, а исследовать внутренности google chrome и всё оптимизировать - тем более никто не даст. А в гугле почему дают? Там просто денег больше? Там это почему работает, хотя их ЦК КПСС в разы жирнее авитовской корпорации.

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

Извините, просто подумал вслух о помоечном состоянии user interface сабжа. Интересны скорее законы скатывания продукта в хламину и невозможность выделить бюджет на сравнительно небольшой отдел, доводящий лицо проекта до идеала, причём при условии бесконечных толстых потоков денег. Нельзя уволить на мороз какого-нибудь там директора департамента по HR или корпоративного психолога и закинуть освободившиеся 700 тыр в месяц в какого-нибудь гения в области google-chrome движка?

Анализ истории сделок на предмет перекоса шортистов/лонгистов

Ссылка на GitHub

В backtest-kit модуль volume-anomaly используется как источник в графе сигналов - параллельно с GARCH. Если GARCH отвечает на вопрос «достаточно ли ожидаемое движение», то volume-anomaly отвечает на вопрос «является ли прямо сейчас статистически необычным моментом в микроструктуре рынка».

Пример кода

import { sourceNode, outputNode } from '@backtest-kit/graph';
import { predict } from 'volume-anomaly';
import { getCandles } from 'backtest-kit';

const ANOMALY_CONFIDENCE = 0.75;
const N_TRAIN  = 1200; // обучающее окно — должно быть без аномалий
const N_DETECT = 200;  // окно детекции

const reversalSource = sourceNode(
  async (symbol) => {
    // Важно: recent не должен пересекаться с historical
    const all        = await getAggregatedTrades(symbol, N_TRAIN + N_DETECT);
    const historical = all.slice(0, N_TRAIN);  // старые сделки — baseline
    const recent     = all.slice(N_TRAIN);     // новые — без overlap

    return predict(historical, recent, ANOMALY_CONFIDENCE);
    // {
    //   anomaly:    true,
    //   confidence: 0.81,
    //   direction:  'long' | 'short' | 'neutral',
    //   imbalance:  0.61,
    // }
 },
);

const entrySignal = outputNode(
  async ([reversal, ...]) => {
    if (!reversal.anomaly) return null;
    if (reversal.direction === 'neutral') return null;

    const position = reversal.direction; // 'long' | 'short'

    return {
      id: randomString(),
      position,
      priceTakeProfit: ...
      priceStopLoss: ...
      minuteEstimatedTime: 60,
    };
  },
  reversalSource,
  ...
);

Ключевые детали

• Hawkes Process - кластеризация ордеров

• CUSUM- сдвиг buy/sell дисбаланса относительно исторической нормы

• BOCPD- смена режима: момент когда распределение дисбаланса само меняется

Как использовать

Классическая проблема DCA - ты усредняешься в падающий нож. Цена идёт против, ты докупаешь, а она продолжает падать. volume-anomaly заточен именно под это: докупать не по расписанию или по сетке уровней, а только когда ордерфлоу показывает разворот агрессии.

О прогнозе нейтрального тренда актива

Ссылка на GitHub

В backtest-kit GARCH используется как один из источников в графе сигналов. Идея: вход открывается только если GARCH-канал достаточно широк, чтобы TP и SL уместились с запасом над комиссиями.

Например, этим можно законтрить боковик, который был на BTCUSDT в Феврале 2024

• 5–10 февраля, 73% нейтральных баров

• 11–16 февраля, 63% нейтральных баров

• 19–24 февраля, 75% нейтральных баров

• 26–29 февраля, 69% нейтральных баров

Пример кода

import { sourceNode, outputNode } from '@backtest-kit/graph';
import { predict } from 'garch';
import { getCandles } from 'backtest-kit';

const CANDLES_FOR_GARCH = 300;
const GARCH_CONFIDENCE = 0.6827; // ±1σ

const garchSource = sourceNode(
  Cache.fn(
    async (symbol) => {
      const candles = await getCandles(symbol, '8h', CANDLES_FOR_GARCH);
      return predict(candles, '8h', null, GARCH_CONFIDENCE);
    },
    { interval: '8h', key: ([symbol]) => symbol },
  ),
);

const entrySignal = outputNode(
  async ([trend, volume]) => {
    // Пропускаем если модель не сошлась
    if (!volume.reliable) return null;

    // Проверяем что до границ канала достаточно места
    const upperDiff = percentDiff(trend.close, volume.upperPrice);
    const lowerDiff = percentDiff(trend.close, volume.lowerPrice);

    if (upperDiff < TAKE_PROFIT_PERCENT) return null;
    if (lowerDiff < STOP_LOSS_PERCENT) return null;

    // TP и SL по границам GARCH-канала
    const tp = trend.position === 'long' ? volume.upperPrice : volume.lowerPrice;
    const sl = trend.position === 'long' ? volume.lowerPrice : volume.upperPrice;

    return { position, priceOpen: trend.close, priceTakeProfit: tp, priceStopLoss: sl };
  },
  trendSource,
  garchSource,
);

GARCH здесь не генерирует направление. Он отвечает только на вопрос «достаточно ли ожидаемое движение». Направление приходит от другого источника (это может быть Pine Script через @backtest-kit/pinets или LLM через @backtest-kit/ollama)

Ключевые детали

• Parkinson estimator для per-candle RV: (1/4ln2) · ln(H/L)² — в ~5× эффективнее squared returns

• Log-normal bands: P·exp(±z·σ) — не линейное приближение, правильное маппирование в ценовое пространство

• reliable: true когда: оптимизатор сошёлся + persistence < 0.999 + Ljung-Box p ≥ 0.05

• Оптимизация: multi-start Nelder-Mead, GARCH — 4 рестарта, NoVaS — 7 (11-мерная задача)

• 932 теста, включая ground-truth тест с синтетическими данными известной волатильности

Cursor или Harvi Code: какой ИИ для кодинга в 2026 году реально работает в России без VPN и головной боли с платежами

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

Cursor — это сейчас, пожалуй, самый продвинутый AI-редактор на рынке. По сути, это VS Code, в который встроили настоящий искусственный интеллект на стероидах. Composer позволяет одной командой править сразу десяток файлов, агент понимает весь проект, хорошо справляется с рефакторингом, поиском багов и даже архитектурными решениями. Качество кода от Claude Sonnet 4.5 или свежих GPT часто вызывает искреннее «вау».

Но есть большая ложка дёгтя. Cursor — американский продукт, и российские карты он не принимает. Чтобы купить подписку Pro, приходится либо использовать виртуальные карты через крипту, либо платить посредникам (Oplatym и подобные), либо покупать готовые аккаунты (что рискованно). Сам редактор после оплаты работает без VPN, но первоначальная настройка оплаты — это отдельный квест. Бесплатная версия быстро упирается в лимиты, особенно если активно юзаешь мощные модели.

Harvi Code — Первый в России AI кодинг-агент. Российский ответ на все эти заморочки. Это полноценный AI-агент прямо внутри VS Code. Пишешь задачу в чате — он генерит код, рефакторит, фиксит баги, работает с контекстом всего проекта. Не тормозит, контекст держит хорошо, интерфейс привычный.

Самое приятное — модели на любой бюджет. Есть топовые (Claude Sonnet 4.5, GPT-5.4 и другие). А главное — очень низкая стоимость токенов. Для каждой модели есть свой коэффициент стоимости. Для большинства повседневных задач их хватает с головой, и можно вообще почти не тратить деньги. Оплата — российскими картами или СБП, без всяких посредников и VPN.

Коротко по делу:

• Если тебе нужен мощный multi-file agent и ты готов один раз настроить оплату через проверенного посредника — бери Cursor. Он до сих пор в топе по возможностям.

• Если хочешь работать стабильно, без лишних телодвижений и не думать каждый месяц про «как бы оплатить» — Harvi Code сейчас выглядит гораздо практичнее для российского разработчика.

А вы как сейчас кодите с ИИ? Пробовали оба варианта? Что в итоге оставили в основном редакторе? Пишите в комментариях, интересно почитать реальный опыт.

Сделал интерактивный квиз!

→ Ознакомительная статья

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

Делал долго, мой магнум опус.

Представлен открытый проект TUI Studio (Visual Terminal UI Designer), среды для визуального проектирования интерфейсов пользователя, работающих в текстовом терминале. Среда позволяет в интерактивном режиме наглядно формировать интерфейс, перетаскивая готовые блоки мышью, редактируя свойства в визуальном режиме и предпросматривая результат на лету. Сформированный макет интерфейса может быть экспортирован для использования во фреймворках Ink, BubbleTea, Blessed, Textual, OpenTUI и Tview.

Решение написано на TypeScript с использованием React, Vite, Zustand, Tailwind CSS и Lucide React. Код распространяется под лицензией MIT. Из особенностей разработки отмечается, что почти весь код TUI Studio написан ИИ‑ассистентом Claude.

В TUI Studio предоставляется более 20 готовых компонентов для формирования интерфейса (кнопки, меню, таблицы, списки, индикатор прогресса, диалоги, всплывающие подсказки и тому подобное) и поддерживается 8 тем оформления, а также светлый и тёмный режим, градиентные заливки, ASCII‑цвета и акцентные цвета. Имеется возможность отката изменений. Доступен интерфейс для создания своих компонентов. Проекты сохраняются в формате JSON.

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

P.S. Все также бесплатно и таким останется, пока у меня есть деньги на поддержку и развитие ресурса.

Недавно общался с крупной зарубежной продуктовой компанией. Штат 500–1000 человек, вроде зрелые процессы, ЗП у разрабов 5000€ баг-репорты по ISO/IEC/IEEE 29119. И при этом:

«Не успеваем уделять время автотестам. Сфокусированы на скорости разработки и релизах.»

Что меня зацепило — каждый их аргумент против тестов я интерпретировал как аргумент за:

— «Слишком частые релизы» → А не потому ли они такие частые, что баги проскакивают на прод?

— «Требования постоянно меняются» → Тем более — как вы контролируете, что старое не ломается?

— «И так работают наизнос если еще и тесты заставить писать — выгорят» → А не от бесконечного ли футбола с багами они выгорают?

А как у вас? Есть автотесты на проекте? Или тоже «не до них»?

Я написал целую статью на эту тему, если все выше вам откликается рекомендую к прочтению: Нет времени на тесты — через неделю релиз

Фронтенд 2026: взлеты и падения

Открываешь проект 2020 года и видишь знакомые имена в package.json: create-react-app, enzyme, moment.js, axios. Пять лет назад это был золотой стандарт. Сегодня же эти технологии вызывают у коллег искреннее недоумение: «Зачем это тут?»

Подготовили для вас быстрый, но очень полезный срез того, как за 5 лет поменялась ментальная модель фронтендера. Внутри инструменты реально умерли, разберемся почему SSR/SSG снова в игре, а TypeScript теперь почти must-have, узнаем почему фронтенд всё чаще = full-stack и что с этим делать.

Главный урок 2015→2025: фронтенд развивается циклически. Каждый цикл — это не «прогресс», а перебалансировка компромиссов. Читайте на Хабр в статье «Фронтенд 2026: что умерло, что выжило и что взлетело неожиданно»

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

Мы запустили молодую платформу с двумя типами аккаунтов: обычные пользователи и разработчики (публикуют PWA и управляют приложениями).

Бренда и доверия пока нет, поэтому вопрос авторизации быстро стал не техническим, а психологическим.

С чего начали

Для обычных пользователей:
• Email / пароль
• Google
• GitHub

Для разработчиков — жёстче:
• Обязательная привязка Google
• Обязательная привязка GitHub

Логика казалась разумной:
«Разработчик = есть GitHub»
«Двойная верификация = меньше спама»

На практике это не сработало.

Первые тревожные сигналы

Регистрация разработчиков шла крайне медленно, несмотря на интерес к публикации приложений.

Сначала списывали на:
• новый продукт
• низкое доверие
• отсутствие аудитории

Но после общения с разработчиками (в том числе через Habr) картина прояснилась.

Что отпугивало разработчиков

1. Новый сервис → нежелание делиться данными

Даже если это «просто email», психологический барьер остаётся.

Когда с первого шага нужно:
• линковать внешние аккаунты
• проходить несколько этапов подтверждения
• подключать сторонние сервисы

это воспринимается как лишний фрикцион.

Особенно для соло-разработчиков и небольших команд.

2. Git ≠ GitHub

Ключевой инсайт.

Мы обнаружили, что:
• не все хотят логиниться через GitHub
• часть использует GitLab или Bitbucket
• некоторые принципиально не хотят связывать GitHub с новым сервисом

Обязательная привязка GitHub стала серьёзным барьером.

А мнение стандартных пользователей разделилось:

Часть говорила:

«Чем больше OAuth-кнопок, тем солиднее выглядит платформа».

Логика простая:
• если есть Google / Facebook / Discord — значит не ноунейм
• интеграции с крупными сервисами повышают доверие

Это не про безопасность — это про ощущение легитимности.

Другие говорили ровно противоположное:

«Слишком много кнопок — ощущение перегруженности».

И это тоже справедливый аргумент.

Что мы изменили

1. Упростили форму для пользователей

Оставили:
• Google
• Facebook
• Discord

Достаточно выбора для доверия, без визуального шума.

2. Git-провайдеры вынесли в отдельную группу

Под отдельной кнопкой:
• GitHub
• GitLab
• Bitbucket

Для разработчиков это стало понятнее и логичнее.

3. Убрали обязательный GitHub

Теперь для developer-аккаунта нужно подключить любой Git-аккаунт, если ни один не подключён.

Без принудительного GitHub.

Первые цифры (осторожно)

Прошла всего неделя, выборка маленькая, платформа всё ещё молодая.

Тем не менее:
• Зарегистрированные пользователи: +13%
(было 0–6% в неделю)
• Зарегистрированные разработчики: +16%
(было 0–3%)

Похоже, это те разработчики, которые знали о платформе, но их останавливало требование GitHub.

Выводы (пока не финальные)
• OAuth — это не только безопасность, но и психология доверия
• Жёсткие требования на старте почти всегда бьют по росту
• Git ≠ GitHub — и это важно
• Много провайдеров могут как повышать доверие, так и перегружать UI

Для молодой платформы даже такие ранние сигналы уже показательны.

Интересно услышать опыт коллег:
добавляли ли вы OAuth-провайдеров после запуска?
были ли случаи, когда обязательная авторизация через конкретный сервис тормозила рост?

💥 Новое в Gramax 💥

• Модуль метрик в Gramax Enterprise Server. Появились отчеты с метриками просмотров, визитов и посетителей на портале документации. А также статистика поисковых запросов. Отчеты можно фильтровать по дате и пользователям, выбирать период (день, неделя, месяц).

• Поддержка Git LFS . Добавили возможность работать большими бинарными файлами (изображения, архивы, PDF и др.) через спецификацию Git LFS. 

• Превью файлов. На портале для читателей доступно превью файлов PDF и DOCX по клику. Читателю не обязательно скачивать файл на компьютер — он может просмотреть его прямо в браузере.

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

• Ссылки между каталогами. Добавили возможность добавлять относительные ссылки на статьи в других каталогах. 

• Удаление запроса на слияние. Теперь можно закрыть запрос на слияние в интерфейсе Gramax — он будет удален для всех пользователей после публикации изменений.

• История комментариев. В просмотре изменений теперь проще отслеживать обновления комментариев: слева появляется иконка комментария, которая показывает, что в тексте изменились или появились комментарии. Там же можно кликнуть по комментарию, открыть его и отредактировать.

Подробнее об изменениях читайте в статье — https://gram.ax/resources/docs/whats-new

А как?

Как?

Реально, как? Скажите мне. Почему это происходит так..

Представлена открытая платформа LifeForge. Этот проект — швейцарский нож для мониторинга жизни и работы. Инструмент заменяет такие сервисы: планировщик задач, трекер привычек, заметки, финансы, цели, обучение, дневник и ещё десятки инструментов — всё в одном месте. Внутри есть контроль задач, проектов и дедлайнов, учёт расходов и бюджета, заметки, идеи, дневник, обучение, флешкарты, база знаний, личные цели и прогресс. Работает локально, без облаков. Можно настроить под себя и отключить лишнее. По сути это Notion + Todoist + трекер привычек + финансы + личная CRM + учебная платформа в одном проекте.

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

KeyValueDiffers позволяет создать KeyValueDiffer для сравнения изменений текущих пар ключ-значение с новыми. Если вы используете иммутабельные объекты, то можно просто обернуть все в эффект, ну а если вы наследники крутого легаси, где все объекты мутируются по ссылке, тогда проверку нужно вешать в DoCheck, чтобы реагировать на каждый тик change detection.

Накидал оба примера, чтобы поделиться с вами:

Иммутабельный с effect:

@Component({
  selector: 'app-test',
  template: ''
})
export class TestComponent {
  public state = input.required<Record<string, string | number>>();
  
  private differs = inject(KeyValueDiffers);
  private differ: KeyValueDiffer<string, string | number> | undefined;

  constructor() {
    effect(() => {
      const currentState = this.state();
      
      // создаем диффер, если он еще не создан
      if (!this.differ) {
        this.differ = this.differs.find(currentState).create();
      }

      // Эффект будет перезапускаться при изменении инпут-сигнала.
      const changes = this.differ.diff(currentState);

      // только если есть изменения
      if (changes) {
        changes.forEachAddedItem((record) => {
          console.log(`В объект добавлена запись: Ключ: ${record.key} | Значение: ${record.currentValue}`)
        });

        changes.forEachChangedItem((record) => {
          console.log(`Изменено: ${record.key} | Новое значение: ${record.currentValue}`)
        });

        changes.forEachRemovedItem((record) => {
          console.log(`Удалено: ${record.key}`)
        });
        
        // Остальные методы forEachItem и forEachPreviousItem по необходимости
      }
    })
  }
}

Легаси подход, которого, надеюсь, ни у кого нет, но на всякий случай :)

@Component({
  selector: 'app-legacy',
  template: ''
})
export class LegacyComponent implements OnInit, DoCheck {
  @Input({ required: true }) state!: Record<string, string | number>;
  
  private differs = inject(KeyValueDiffers);
  private differ: KeyValueDiffer<string, string | number> | undefined;

  ngOnInit() {
    // Создаем диффер при инициализации
    this.differ = this.differs.find(this.state).create();
  }

  // Запускается на каждый тик change detection, так как мутации по-другому не отследим.
  ngDoCheck(): void {
    const changes = this.differ?.diff(this.state);

    if (changes) {
      changes.forEachAddedItem((record) => {
        console.log(`В объект добавлена запись: Ключ: ${record.key} | Значение: ${record.currentValue}`)
      });

      changes.forEachChangedItem((record) => {
        console.log(`Значение изменилось: ${record.key}`)
      });

      changes.forEachRemovedItem((record) => {
        console.log(`Запись удалена: ${record.key}`)
      });

      // Остальные методы forEachItem и forEachPreviousItem по необходимости
    }
  }
}

Решил сегодня почитать, что пишут в Ангуляр комьюнити Хабра, и увидел сильно популярный пост с аж 51 лайком и 71 закладкой.

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

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

Автор условно говорит, что у нас есть плохой пример использования:

this.http.get('/api/data').subscribe((data) =>; {
  this.data = data; // Что если запрос не вернётся?
});

и затем приводит хороший пример с сигналами и RxJs:

readonly data = signal([]);
readonly error = signal(null);

loadData() {
  this.http.get('/api/data').pipe(
    tap(() =>; this.error.set(null)), // Сбрасываем предыдущую ошибку перед загрузкой
    catchError((err) =>; {
      this.error.set('Не удалось загрузить данные');
      return of([]); // Возвращаем пустой массив, чтобы поток не прерывался
    })
  ).subscribe((result) =>; {
    this.data.set(result);
  });
}

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

interface State<T = object> {
  data: T[];
  error: string | null;
}

@Component({...})
export class BestRxJs {
  private http = inject(HttpClient);
  private loadDataAction$ = new Subject<void>();

  private state$ = this.loadDataAction$.pipe(
    switchMap(() => 
      this.http.get<State[]>('/api/data').pipe(
        map((result) => ({ data: result, error: null })),
        catchError(() => of({ data: [], error: 'Не удалось загрузить данные' })),
        startWith({ data: [], error: null })
      )
    ),
    shareReplay({ bufferSize: 1, refCount: true })
  );

  readonly private state = toSignal(this.state$, {
    initialValue: { data: [], error: null } 
  });

  readonly protected data = computed(() => this.state().data);
  readonly protected error = computed(() => this.state().error);

  protected loadData(): void {
    this.loadDataAction$.next();
  }
}

Этот пост для новичков, которые, начитавшись популярных статей, могут начать применять вредные практики.

Почему стоит использовать protected в Angular компонентах?

Если вы используете в своих компонентах только public и private, вы упускаете возможность сделать архитектуру чище. Я предлагаю четко разделять ответственность членов класса.

Часто мы по инерции делаем public любые методы и свойства, которые нужны в шаблоне (HTML). Но public в TypeScript означает, что это публичный API компонента - к этим методам может получить доступ любой родительский компонент через @ViewChild.

Почему стоит использовать protected:

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

2. Защита от регрессии: Если другой разработчик попытается вызвать такой метод через @ViewChild, TypeScript выдаст ошибку. Это заставит его задуматься: «Действительно ли мне нужно делать этот метод публичным?» или «Может, стоит создать отдельный метод для API?».

3. Читаемость: Открывая код, вы сразу видите: public - для внешнего мира, protected - для шаблона, private - для внутренней логики сервисов и подписок.

Разделяйте Public API и внутреннюю логику шаблона - ваш код станет надежнее и понятнее.

@Component({
  selector: 'app-user-profile',
  template: `
    <!-- В шаблоне мы без проблем обращаемся к protected свойствам -->
    <div class="card">
      <h3>{{ userName() }}</h3>
      <button (click)="onUpdateClick()">Обновить</button>
        @if(isLoading()) {
          <div>Загрузка...</div>
        }
    </div>
  `
})
export class UserProfileComponent {
  // PRIVATE: Внутренняя логика. 
  // Не доступно ни в шаблоне, ни родительскому компоненту.
  private _userId = 123;

  // PROTECTED: Доступно только внутри класса и в ШАБЛОНЕ.
  // Идеально для переменных состояния UI и обработчиков событий.
  protected userName = signal('Алексей');
  protected isLoading = signal(false);

  protected onUpdateClick(): void {
    this.logAction();
    console.log('Кнопку нажали в шаблоне');
  }

  // PUBLIC: Публичный API компонента.
  // Только эти методы мы разрешаем вызывать родительскому компоненту.
  public resetState(): void {
    this.userName.set('Гость');
    this.isLoading.set(false);
  }

  private logAction(): void {
    console.log(`Action logged for userId: ${this._userId}`);
  }
}

Как получить почти бесконечное зацикливание без использования циклов и без переполнения стека вызовов:

// Установите N = 64, и эта функция никогда не завершится  
// Количество вызовов (calls) = 2^(N+1)  
// Максимальная глубина вложенности = N

let calls = 0
const N = 18
function func(state, visited) {
  calls++
  if (calls > 10_000_000) {
    throw new Error('calls: ' + calls)
  }
  if (visited.includes(state)) return

  const newVisited = [...visited, state]

  func((state + 1) % N, newVisited)
  func((state + 1) % N, newVisited)
}

func(0, [])
console.log('calls:', calls)

Почему это работает без переполнения стека?

func(0, [])
├── func(1, [0])
│   ├── func(2, [0,1])
│   │   └── ... глубина растёт до N
│   │           и перебираются все возможные комбинации значений в newVisited
│   └── func(2, [0,1]) - возвращается, глубина УМЕНЬШАЕТСЯ
└── func(1, [0])       - второй вызов, стек уже освободился

А Garbage Collector (GC) при этом бесконечно удаляет созданные ранее массивы newVisited

Стек "дышит" - достигает максимума N, потом сворачивается, потом снова растёт. Это обход огромного дерева, имеющего небольшую глубину, но очень большую ширину. Это не бесконечная рекурсия. Но при N = 64 количество вызовов будет 2^65 (примерно 10^19) - это займёт тысячи лет, и стек никогда не переполнится.

Философия IT-собеседований: взгляд разработчика и DevOps-инженера

Привет, Хабр! Мой пост носит дискуссионный характер. В веб-разработке, администрировании и DevOps я уже 17 лет. Долгое время работал «на себя», оказывая помощь клиентам, с которыми выстроены надёжные взаимоотношения, но текущие реалии рынка подтолкнули к поиску работы по ТК, об этом я и хочу поговорить.

Обо мне: 40 лет, из которых 17 лет в коммерческой разработке. Прошел долгий путь как в fullstack-разработке (web), так и в создании embedded-решений (каршеринг), администрировании и DevOps.

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

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

1. Диалог на равных.
   Мое лучшее интервью: техлид не мучил теорией, а предложил обсудить реальную дилемму, которую он решает в данный момент (внедрение NoSQL-хранилища ради одного специфичного сервиса, т.е. доп. точка отказа vs производительность). Без таймера и стресса мы искали решение. Итог — оффер и годы отличной работы.

2. Проверка логики, а не памяти.
   Люблю кейсы в духе: «Вот дано А, почему происходит Б?». Из банального: может ли Вася из другого города достучаться до вашего локального IP? Это показывает понимание базы лучше любого теста.

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

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

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

2. Вакансии-обманки.
   Зачем заманивать стеком DevOps (Linux, Nginx, Ansible, Terraform, Puppet, Docker, Kubernetes, MySQL, PostgreSQL, Elasticsearch, Logstash, Kibana, Zabbix), если по факту сообщаете, что ничего этого не будет, а ищите классического сисадмина 9-18? — Давайте адкеватный запрос, а не тратьте время.

3. Терминологическая каша. Сложно отвечать экспертно, когда интервьюер путает CI и OCI или Redis и Rabbit. Если нет погружения в контекст, конструктивного диалога не выйдет. Готовиться к собеседованию должен не только соискатель, но и тот, кто нанимает.

4. Отсутствие пунктуальности.
   Для меня было шоком, что фаундер может просто не явиться на собседование, или рекретер забывает о диалоге и назначенной встрече. У вас там всё нормально?) Хотя рекрутер мало чем отличается от агента недвижимости, но фаундер забывающий про собеседование для меня персонаж странный.

5. Узкая специализация.
   Раньше, как мне кажется, ценилась универсальность, способность разработчика понимать инфраструктуру, а инженера/админа — код. Сегодня индустрия уходит в жесткую сегментацию, видимо, для более точного просчёта рисков. А я считаю, что именно универсальность — это страховка проекта от того, что решение будет принято в вакууме одного стека, без учета общей картины.