Шоу “Громкий вопрос” одно из немногих, которые мы с женой часто смотрим по вечерам. Помимо развлекательной составляющей, оно интересно тем, что каждую игру формируется новая команда, и их игра очень напоминает как работают современные команды разработки.

Первые минут 15-20 знакомства с новым гостем мы обычно проматываем, но тут есть несколько интересных командообразующих деталей, на которые стоит обратить внимание начинающим тимлидам.

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

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

В-третьих и самое важное на мой взгляд – обязательно звучит фраза “мы сегодня все вместе или выиграем или проиграем”. Это вообще прямая отсылка к Agile манифесту.

Дальше начинается игра и она очень напоминает работу по Scrum методологии. Есть спринты (в жизни обычно 2 недели, в игре – один раунд). В начале спринта команда проводит планирование, решая какие задачи они возьмут в работу в спринте. У каждой задачи есть своя оценка сложности – в часах или сторипоинтах (попугаях). В игре у них есть зеленые, синие и черные вопросы.

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

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

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

В этом году планирую больше внимания уделить ИИ и их внедрению в рабочие процессы. Посмотрел несколько докладов, и пока самым интересным показалось выступление Алексея Раптева: “Оптимизация процесса разработки с помощью LLM”.

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

Также можно попробовать с помощью LLM проанализировать существующие тест-кейсы нашей системы. Возможно, получится найти противоречия или места, которые пока слабо покрыты тестами.

В общем, надо пробовать. Тема кажется перспективной.

Ссылка на доклад: https://www.youtube.com/watch?v=dzB3q3xNsIE

Фича-флаги во фронтенде: плавные релизы и современный подход к разработке 🚀

Фича-флаги (feature flags) — это инструмент, который позволяет безопасно и управляемо внедрять новые фичи. С их помощью можно:

✔️ Запускать фичи на ограниченной аудитории: Например, тестировать новую функциональность на 5-10% пользователей, чтобы проверить её стабильность.
✔️ Постепенно расширять охват: Увеличивать количество пользователей, видящих новую фичу, без стресса для команды.
✔️ Управлять доступом по сегментам: Включать функционал только для бета-тестеров, премиум-аккаунтов или других категорий.


🛠️ Фича-флаги и Base Trunk Development

Фича-флаги идеально работают в связке с подходом Base Trunk Development (разработка в основной ветке репозитория). Этот метод позволяет:

✔️Деплоить "сырой" код в основную ветку без риска — фича остаётся выключенной до готовности.
✔️Избежать конфликтов между ветками, так как все изменения сосредоточены в основной ветке.
✔️Быстро итеративно дорабатывать фичи, активируя их только тогда, когда они полностью готовы.


Пример:

if (featureFlags.enableDarkMode) {
renderDarkMode();
} else {
renderLightMode();
}

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


❓ А если флаги — это не только для релизов?
Фича-флаги часто рассматриваются как временный инструмент, но что, если их использовать для постоянного управления функционалом? Например:

✔️Разделение функционала между тарифами (базовый, премиум, корпоративный).
✔️Динамическая настройка доступов для разных групп пользователей.

Это добавляет новые вызовы:
❓Как проектировать архитектуру, чтобы избежать путаницы в коде?
❓Как эффективно управлять большим количеством флагов?

🎥 О том, как нам удалось внедрить это в Sendsay и сделать понятную архитектуру, рассказал наш техлид Артем Герус на MoscowJS в Т-банке:
https://www.youtube.com/live/XIHCtCwF0hk?t=558s (начало 9:20)

Мокирование API-запросов в runtime: ⚡️ ускоряем проверку специальных сценариев

Мы столкнулись с множеством ситуаций, когда разработчики меняют крошечные детали (например, текст), которые видны только определённым клиентам на специфичных аккаунтах. QA-команде приходилось тратить уйму времени, чтобы найти «особенного» пользователя и получить к нему доступ. Мы решили эту проблему, позволив подменять часть ответа бэкенда «на лету» — так нужное состояние интерфейса можно получить мгновенно.

🔑 Ключевая идея

Единый «коннектор»

Все запросы к API проходят через один модуль (например, обёртку для axios). В нём мы проверяем, есть ли для данного запроса mock в localStorage. Если mock найден, реальный запрос всё равно отправляется, но при получении ответа мы подменяем указанные поля.

Хранение mocks в localStorage

Сохраняем JSON: какие запросы «ловить» и какие поля ответа подменять.
Подмена происходит уже после реального запроса, в «коннекторе».
Чтобы удалить mocks, достаточно очистить localStorage через Dev Tools.

Удобное редактирование прямо в интерфейсе

Обычно можно было бы сделать специальные функции и «вытащить» их в глобальное окружение, чтобы управлять этим через Dev Tools.
Но у нас в интерфейсе Sendsay есть «API-консоль» (аналог Postman). Мы добавили в неё поле mock: всё, что туда записывается, сохраняется в localStorage и применяется при следующих запросах.


✅ Преимущества

Экономия времени: не нужно искать «особенного» клиента.
Гибкость: легко проверять сценарии для специфичных аккаунтов.
Прозрачность: управление мокированием сосредоточено в одном месте, а данные для mock хранятся в localStorage.

✨Итог

Мы реализовали мокирование запросов прямо в интерфейсе, не отказываясь при этом от реальных ответов сервера, а лишь подменяя нужные поля «на лету». Это ускорило работу QA и упростило тестирование редких сценариев. Теперь, чтобы проверить изменения для определённых категорий пользователей, достаточно создать или отредактировать нужный mock в «API-консоли» — и сразу увидеть, как всё будет выглядеть в приложении.

Почему тестовые работы кандидатов «улетают в трубу»?

Кажется, мы уже привыкли: кандидат выполняет тестовую работу, отправляет её — и в ответ тишина. Это воспринимается как стандарт, хотя на самом деле это не норма и так быть не должно.

На TeamLead Conf я рассказал, почему кандидаты часто не получают обратной связи. Мы разобрали основные причины: отсутствие процессов, нехватку времени у HR и тимлидов, субъективность оценки заданий. Все это создаёт проблемы не только для кандидатов, но и для компаний.

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

Вот ключевые моменты:

✅ Чек-листы для оценки. Прозрачные критерии делают процесс объективным и понятным.

⚙️ Автоматизация. Упрощение рутинных задач помогает сосредоточиться на сути.

✍️ Культура обратной связи. Даже несколько строк об успехах и недостатках задания помогают кандидатам расти.

Команда — это самое важное. А начинается она с найма. Прозрачный и уважительный процесс отбора помогает заложить прочный фундамент для сильной команды.

🎥 Смотрите запись моего выступления, чтобы узнать больше: https://www.youtube.com/watch?v=fh7J93LUZLE.

🎨 50 оттенков хаоса: как мы навели порядок в палитре проекта

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

Например, синяя кнопка везде оставалась синей, но оттенки различались: где-то она была светлее, где-то темнее. Особенно это бросалось в глаза на бордерах и тенях. Мы осознали, что у нас в проекте используется множество близких, но разных оттенков одного и того же цвета — своеобразные "50 оттенков серого" (и не только серого, но и синего, зелёного и других).

Эта проблема знакома многим командам, особенно на крупных проектах, где над дизайном работают разные люди. На эту тему есть классный доклад Семена Левенсона про дизайн-систему Яндекс.Дзена, но готового решения там не было. Поэтому мы решили создать свой инструмент.

🛠 Как мы это сделали
Мы разработали CLI-утилиту, которую назвали zimablue (с отсылкой к одноименной короткометражке из "Любовь, смерть и роботы"). Вот как она работает:

1️⃣ Создание палитры
В основе лежит JSON-файл с палитрой всех цветов. Мы взяли палитру Tailwind и добавили в нее наши брендовые цвета.

2️⃣ Анализ проекта
Утилита с помощью регулярных выражений парсит весь код проекта, находит все упоминания цветов (в любом формате: HEX, RGB, HSL) и приводит их к HEX-формату.

Пример запуска для поиска всех цветов в проекте:
npx zimablue -f './**/*.css'

3️⃣ Сравнение и подбор
Затем она выводит список всех использованных в проекте цветов, подбирая к каждому ближайший оттенок из палитры по специальному алгоритму. Если найденный оттенок подходит в рамках заданной дельты, он подсвечивается зеленым.

4️⃣ Проверка дизайнером
Мы отдали результат дизайнеру на согласование, чтобы убедиться, что автоматическая замена работает корректно.

5️⃣ Автоматическая замена
После одобрения мы повторно запускаем утилиту с аргументом, который заменяет цвета в коде на выбранные из палитры.

Пример команды для автоматической замены цветов:
npx zimablue -f './**/*.css' --replace

✅ Результат
В итоге мы смогли унифицировать большую часть цветов в проекте, ускорить процесс и минимизировать человеческий фактор.

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

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

🌐 Утилита в открытом доступе
Мы опубликовали zimablue в npm как публичный пакет. Если у вас в проекте стоит похожая задача, вы можете воспользоваться нашим решением. Надеемся, оно сэкономит вам время и нервы!

🔗 Ссылка на утилиту в npm

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

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

1️⃣ Страх выступления — это нормально
Многие думают, что боятся выступать сильнее, чем остальные. На самом деле страх перед публикой есть у всех. Главное — перебороть себя в первый раз, дальше будет легче, но волнение никогда не уходит полностью. Я знаю одного известного спикера, который после выступления сказал: "Блин, меня всего трясло перед выходом на сцену". Это как прыжок в воду с высоты: страшно только перед первым шагом.

2️⃣ Не нужно быть суперэкспертом
Есть миф, что для выступления нужно обладать какими-то уникальными знаниями. На самом деле, мы все работаем с похожими технологиями, но у каждого свой путь, и ваш опыт может оказаться ценным для других. К тому же на митапах много начинающих специалистов, которым интересны даже базовые вещи. Формула хорошего доклада: 60% знакомого большинству материала, 30% углубления в тему и 10% уникальной информации, которую нашли только вы.

3️⃣ Не вам решать, интересна ли тема
Если у вас есть идея доклада, но кажется, что она неинтересна — доверьте это программному комитету конференции. Они видели сотни заявок и знают, что зайдет аудитории. Просто подайте заявку, и если тема не подходит, вам скажут, как её доработать. В большинстве случаев с вами свяжутся, предложат созвониться и дадут рекомендации.

4️⃣ Не нужно готовить доклад месяцами перед подачей
Лучше сначала отправить заявку с идеей, а уже потом дорабатывать материал вместе с программным комитетом. У меня был опыт, когда я подавался с полностью готовым докладом — и пришлось его переделывать. Гораздо удобнее идти поэтапно: идея → обсуждение → план → слайды → речь → репетиция. Так меньше лишней работы и больше пользы.

5️⃣ На конференции сложно пробиться
Да, на некоторые конференции действительно большой конкурсный отбор, но в большинстве случаев программному комитету не хватает спикеров, и они остро заинтересованы в новых докладах. Пока моя личная статистика такова, что меня брали везде, где я подавался. Начните с бесплатных митапов и двигайтесь дальше, постепенно переходя к более масштабным и дорогим конференциям.

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

Решил в свободное время потихоньку разбираться в смарт-контрактах и блокчейне. Казалось бы, что может быть дальше от фронтенда? Другая парадигма, строгая типизация, low-level программирование, какие-нибудь сложные языки...

Но на один из первых же вопросов «Как создать свой мем-коин?» получил такой ответ:

Установите Node.js, если его у вас еще нет.
Установите необходимые npm-пакеты:


npm install -g hardhat
npm install @openzeppelin/contracts



Создайте новый проект и смарт-контракт на Solidity:


// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract MyMemeCoin is ERC20 {
constructor() ERC20("MyMemeCoin", "MEME") {
_mint(msg.sender, 1000000 * 10 ** decimals());
}
}

Задеплойте его через Hardhat...

Стоп. Чего?! NPM пакеты?! Вы могли выбрать что угодно, но выбрали JavaScript и npm модули?

Блокчейн, в котором миллионы долларов зависят от безопасности кода, используют npm-пакеты, которые могут удалить, взломать или подменить в любой момент? Теперь понятно, почему в крипте столько скама.

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

Я хорошо помню время, когда каждые пару дней кто-то стучался в телегу с предложением. Мы сами стали свидетелями, как всего за несколько лет рынок ИТ перешёл из «HR-ы, просьба не беспокоить» к «эй, HR-ы, ау, вы где?».

Причины у этого понятные и общие для всей экономики: высокая ставка ЦБ, санкции, сокращение инвестиций. Это не только про ИТ — это про весь рынок труда. Вот немного цифр для контекста.

Последние два года я всем говорю одно и то же: пытаться «войти в ИТ» сейчас — всё равно что догонять поезд, где люди уже сидят на крыше, а сам поезд давно отъехал от перрона. Это как в трейдинге: если ваш таксист между делом покупает крипту прямо на светофоре — значит, пора фиксировать прибыль, потому что скоро будет обвал.

Что делать? На мой взгляд, куда разумнее смотреть на ниши, которые только набирают обороты. Например — ИИ. Пока в МФЦ стоят очереди и работают толпы сотрудников, значит, есть огромное поле для автоматизации. Самое время разбираться, как создавать ИИ-агентов и овладевать инструментами вроде Flowise или Motion.