Руслан Куянец | Reactify

Вчера побывал на «Профсоюзная Конференция». Хочу сказать следующее: «Если интернешенал - это праздник доты, то профсоюзная - это праздник айти» Ни на одной другой конфе/митапе я так много не общался. Зарядился энергией от самых разных людей. Хардворк ✊🏼 В комментарии пришлю немного видео/фото с конфы

Как устроены ИИ-агенты, которые умеют программировать сами? 27 августа в 19:00 встречаемся в кампусе Центрального университета на митапе про кодинговых ИИ-агентов. На митапе: ⚫️ узнаем, почему кодинговые агенты превращаются в отдельные сервисы и как устроены распределенные агентные системы; ⚫️ разберем протоколы ACP и A2A и посмотрим, как разные агенты и клиенты могут взаимодействовать между собой; ⚫️ на практическом мастер-классе создадим собственного автономного агента с помощью Deep Agents от LangChain — с планированием, управлением контекстом, файловой системой и параллельной работой сабагентов. Мастер-класс — с ноутбуками, так что получится не только посмотреть, но и попробовать собрать агента своими руками. Спикеры: ⚫️Денис Артюшин — технический владелец продукта агентской платформы в Т-Банке ⚫️Полина Реброва — ведущий инженер по разработке, Сбер ⚫️Александр Шахов — инженер-преподаватель и академический руководитель направления «Разработка» в Центральном университете 📍 27 августа, 19:00 📍 Кампус Центрального университета, Москва Зарегистрироваться по ссылке

Видео по CI/CD готово Такого вы не видели еще На следующей неделе... скоро..

ИИ эпидемия Уже не первый раз слышу такой фидбек

Все готово Завтра сниму видео про CI/CD, в понедельник опубликую Потом сниму видео по инфраструктуре Все это я буду показывать на примере YeaHub https://github.com/YeaHubTeam/yeahub-platform

💪 Как я довожу Frontend-разработчиков до оффера (показываю всю систему) https://www.youtube.com/watch?v=ZIl3kHEL0XQ Разошелся я с контентом, но мои гайды по менторству устаревают очень быстро за счет добавления новых ритуалов 😁 Плюс решил окончательно на схеме отбить все вопросы по процессу обучения. Один раз провести презентацию и отправлять это видео в приветственном сообщении, чтобы экономить 15–20 минут на каждой консультации на вопросы вроде: «А с чего начнем?», «Как всё проходит?», «А что такое стажировка?» и т. д. В общем, видос уже на YouTube. Держим качество. Улучшаем всё. Скоро видео по инфраструктуре, CI/CD и деплою. 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

Задания с собеса Задание 1 (код с Promise):

let counter = 0;
const increment = new Promise(resolve => {
    counter++;
    resolve(0);
});
await increment;
await increment;
console.log(counter);

Вопрос: Чему будет равен counter? Задание 2 (React-компонент с Counter A и Counter B):

import React, { useState } from "react";
import "./styles.css";

console.log = (...args) => {
    const node = document.createElement("div");
    node.innerHTML = args.join(" ");
    document.getElementById("log").appendChild(node);
};

const Counter = (props) => {
    console.log(`Counter ${props.name} rendered`);
    return (
        <div>
            Counter {props.name} : {props.count}
        </div>
    );
};

export default function App() {
    const [countB] = useState(0);
    const [countA, setCountA] = useState(0);
    const handleCountA = () => {
        setCountA(countA + 1);
    };

    return (
        <div className="App">
            <Counter name="A" count={countA} />
            <Counter name="B" count={countB} />
            <button onClick={handleCountA}>Count A</button>
        </div>
    );
}

Задача: Counter A и Counter B рендерятся вместе, нужно чтобы Counter B не ре-рендерился при клике на Counter A. Оптимизировать компонент. Задание 3 (сравнение функций):

const test = 0 => test()
const test1 = async 0 => await test1()
const test2 = async 0 => await Promise.resolve(0).then(test2)
const test3 = 0 => setTimeout(test3, 1)

Вопрос (по контексту собеса): С чем можно столкнуться (например, переполнение стека, бесконечный цикл, таймаут и т.д.)? Вопрос про переполнение стека вызовов и разницу между синхронной/асинхронной рекурсией. 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

🖥 20 вопросов с жесткого Frontend собеседования: V8 / JS engine / React Fiber Почему один JavaScript-код работает быстро, а другой тормозит? Что происходит внутри V8, когда мы запускаем наш код? В этом видео разбираем оптимизации JavaScript под капотом: — как работает JIT-компилятор — что такое Hidden Classes в V8 — почему структура объектов влияет на производительность — что такое мономорфизм и deoptimization — как работает Garbage Collector и поколенческий сборщик мусора — почему создание лишних объектов может замедлять приложение — когда использовать Object, а когда Map Это вопросы, которые часто встречаются на собеседованиях Frontend Senior уровня, но самое важное — понять не термины, а логику работы JavaScript-движка. После этого видео станет понятнее: - почему V8 любит предсказуемый код - почему один и тот же JS может работать в 100 раз быстрее в разных условиях - какие привычки в коде помогают движку оптимизировать приложение JavaScript — это не просто язык, который выполняется в браузере. Внутри работает сложный движок, который постоянно анализирует наш код и пытается сделать его быстрее. Видео уже на канале Reactify! Я не оставляю ссылку, так как видео лучше продвигается, если заходить на него напрямую с YouTube. Это помогает улучшить его рейтинг и увеличить шансы на органическое продвижение. 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

Айти уходит на дно 😭

👩‍💻 Эволюция Frontend Архитектуры: от Монолита до Microfrontends (Monorepo, Multirepo) В этом видео разберём эволюцию больших frontend-систем: Monolith → Modular Monolith → Monorepo → Multirepo → Microfrontends. На примере роста большой платформы посмотрим: — почему один frontend начинает не справляться с ростом команды; — зачем переходят от монолитного приложения к модульной архитектуре; — чем отличаются Monorepo и Multirepo; — когда появляются отдельные приложения и бизнес-контуры; зачем нужны Microfrontends; — как независимые команды получают свои релизы, CI/CD и жизненный цикл. Разберём: — Frontend Architecture — Microfrontend Architecture — Monorepo vs Multirepo — Modular Monolith — Frontend Scaling — Large Scale Frontend Applications Видео будет полезно frontend-разработчикам, архитекторам и техническим лидерам, которые строят масштабируемые веб-приложения. Видео уже на канале Reactify! Я не оставляю ссылку, так как видео лучше продвигается, если заходить на него напрямую с YouTube. Это помогает улучшить его рейтинг и увеличить шансы на органическое продвижение. 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

Скоро возвращение на YouTube 💪🏼 1. Разбор самого душного собеса: V8, Hidden classes, JIT, TS, Garbage Collector и другие необычные темы на собесе 🤯 2. Архитектура Frontend: Monorepo, Multirepo, Microfrontends, Monoliths Схема эволюция на примере больших компаний Видео в монтаже 💪 Так же много сценариев написал, буду контент машину запускать 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

👩‍💻 CI/CD для фронтендера часть 3 В прошлый раз мы остановились на моменте, когда Pull Request прошел ревью, получил аппрув и попал в ветку develop. Теперь начинается самое интересное — что происходит после merge и как код оказывается в Kubernetes. Разберем путь от merge до деплоя. Итак, разработчик сделал merge:

feature/YH-1422 → develop

С этого момента обычно запускается новый workflow. Первый этап — сборка. CI/CD система берет свежий код из ветки develop и выполняет примерно такие шаги: — скачивает репозиторий; — устанавливает зависимости; — собирает приложение; — запускает необходимые проверки; — создает артефакты сборки. Для фронтенда результатом обычно будет набор статических файлов:

dist/
 ├── index.html
 ├── assets/
 ├── javascript bundles
 └── styles

Но часто в современных проектах дальше появляется Docker. Вместо того чтобы просто отправлять файлы на сервер, приложение упаковывается в Docker image. Например:

код приложения

↓

npm install

↓

npm run build

↓

Docker image

↓

Container Registry

Docker image — это готовая версия приложения вместе с необходимым окружением. Например:

frontend-app:1.25.0

Эта версия уже сохранена в Registry, откуда ее сможет забрать Kubernetes. Следующий этап — Kubernetes. Kubernetes сам по себе не знает, какую версию приложения нужно запускать. Ему нужно описать желаемое состояние: — какой image использовать; — сколько запустить копий приложения; — какие ресурсы выделить; — какие настройки применить. Обычно это описывается через Kubernetes manifests или Helm charts. Например:

frontend:
  image: frontend-app:1.25.0
  replicas: 3

То есть мы говорим Kubernetes: "Мне нужно 3 экземпляра фронтенда версии 1.25.0" И Kubernetes делает все необходимое: — скачивает Docker image; — создает контейнеры; — запускает приложение; — проверяет, что оно работает; — заменяет старую версию новой. В GitOps подходе мы обычно не отправляем команды напрямую в Kubernetes. Вместо этого есть отдельный репозиторий с описанием состояния инфраструктуры. Например:

application-config

frontend:
  image: frontend-app:1.25.0

Изменили версию в Git → система увидела изменение → обновила Kubernetes. И здесь появляется ArgoCD. ArgoCD постоянно сравнивает: что написано в Git vs что реально запущено в Kubernetes. Если есть различия — он выполняет синхронизацию. Например: В Git: frontend-app:1.25.0 В Kubernetes: frontend-app:1.24.0 ArgoCD увидит расхождение и обновит приложение. В итоге весь путь выглядит примерно так:

Merge в develop

↓

CI/CD workflow

↓

Build приложения

↓

Docker image

↓

Container Registry

↓

Обновление конфигурации в Git

↓

ArgoCD

↓

Kubernetes

↓

Новое приложение работает

И вот этот процесс обычно скрыт от фронтендера. Разработчик сделал merge — через несколько минут новая версия уже доступна на стенде. Но за этим стоят несколько систем, которые работают вместе: Git → CI/CD → Docker → Registry → GitOps → ArgoCD → Kubernetes Первые 4 шага можно изучить в нашем репозитории: https://github.com/YeaHubTeam/yeahub-platform/blob/main/Dockerfile В следующей части можно разобрать уже сам Kubernetes: что такое Pod, Deployment, Service, Ingress и как вообще фронтенд приложение живет внутри кластера 🙂 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

💼 Персонализированная подготовка Весь июль тестировали Календарь собеседований и внедряли новый подход к подготовке. Раньше мы в основном готовили ученика до выхода на рынок, а дальше уже подключались точечно, если нужен был мок. И этого подхода в целом хватало. Каждый ученик до выхода на рынок проходил 5–13 экзаменов по всем темам (экзамен = мок с ментором), потом ещё 2+ дополнительных мока и прожарки. Плюс были рандомные моки с другими ребятами примерно 2 раза в неделю. Этого было достаточно, чтобы получать офферы. Но рынок стал тяжелее. Конкуренция выросла, компании стали сложнее отбирать кандидатов, и сейчас нужно выжимать максимум из каждого шанса. Поэтому мы поменяли подход. Есть собеседование в Т-Банк и там лайвкодинг? Сделаем мок лайвкодинга именно под формат Т-Банка. Финальный этап в Сбере? Сделаем часовой мок по софтам и разбору опыта, чтобы максимально повысить шанс пройти. То есть после выхода на рынок ученик теперь имеет возможность делать практически неограниченное количество моков с ментором по необходимости, пока ищет работу. Это и есть персонализированная подготовка. И всё это стало возможным благодаря трекингу собеседований через Календарь. Но моки — это только часть. Календарь даёт ещё несколько сильных возможностей. 🚂 Паровозы собеседований Например, Ваня прошёл собеседование в Авито. Через неделю Петя идёт туда же — Ваня может передать ему вопросы, рассказать про этапы и помочь подготовиться осмысленно. Раньше такие связи часто терялись. Теперь мы специально их создаём. 📚 Материалы и реальные вопросы Мы подключили помощника, у которого есть доступ к куче источникам с записями собеседований, слитыми вопросами, задачами и закрытыми базами. Когда ученик добавляет собеседование в календарь — мы можем искать актуальные материалы именно под эту компанию и этот этап. Давать это ученику. 🤝 Рефералы Ещё один важный эффект — растёт база контактов. Например, ученик прошёл собеседование в Сбер, но понял, что ему не подходит офисный формат. Он с большей вероятностью сможет порекомендовать другого ученика, которому такой формат подходит. Получается система, где ученики помогают друг другу получать больше возможностей. За июль Календарь уже показал хороший результат: — 8 рефералок ученик → ученик — 11 паровозов по собеседованиям — 20 собеседований, где удалось найти вопросы и записи, которые совпали с реальными этапами примерно на 90% — дополнительные моки для подготовки к алгоритмам и финальным этапам Это только первый месяц. Чем больше данных собираем, тем точнее понимаем, где можно помочь, какие компании сейчас нанимают и как увеличить шанс получить оффер. Мы не ждем хороший рынок 🚀 Мы побеждаем на любом 💪

Для меня это был шок. Код был слабый, базовой логики и понимания разработки почти не было. Но человек получал 250 тысяч рублей в месяц. И знаете что? Он молодец. Он смог попасть в систему, пройти фильтры и получить результат. Возможно, ему вообще не интересно, что кто-то считает его путь неправильным. Типа: «Хэй, я получаю 250к, а вы тут сидите и год ищете работу, зато говорите про честность». Это было бы не очень красиво с его стороны. Но доля правды в этом есть. Потому что рынок в итоге вознаграждает не самых правильных. Он вознаграждает тех, кто смог адаптироваться под его правила. И, наверное, главный вопрос не в том, правильно это или нет. А в том: Нужно ли быть лучшим разработчиком или нужно уметь доказать рынку, что ты им являешься?

🤬 Дилемма IT-рынка Дилемма разработчика: быть хорошим инженером или хорошим кандидатом? Под комментариями к видео-прожарке люди разделились на два лагеря. https://youtu.be/a43a-SCCHLg Одни говорят: «Как можно не знать такие вопросы? Это же база». Вторые говорят: «А зачем вообще задавать такие вопросы? Они ничего не показывают». При этом и среди первых, и среди вторых были люди как с опытом, так и без него. И вот тут начинается интересная дилемма. Когда еще не было всей этой рыночной истерии, к собеседованиям относились проще. Опытные ребята, работающие в топовых компаниях, на собесах могли просто поговорить за жизнь — и их брали в Альфу, ВК, Сбер, Ростелеком и другие компании. Не было жесткой проверки знаний. Алгоритмы, задачки и вопросы с собеседований считались отдельным навыком, который хороший разработчик знать не обязан. Время шло. Записей собеседований на YouTube стало в сотни раз больше. Списки вопросов, подборки задач, сервисы подготовки — все стало доступно. Подготовиться стало намного легче. Но вместе с этим поменялись и правила игры. Сейчас уже недостаточно просто хорошо работать. Если ты приходишь на собеседование неподготовленным, то можешь проиграть человеку с меньшим опытом, который просто хорошо натренировал формат собеседования. Готовиться к собеседованиям нужно. Это буквально часть профессии и реалии текущего рынка. Улучшать резюме, правильно себя презентовать, иногда чуть подкручивать формулировки — это тоже часть игры. Потому что какой смысл быть добрым, честным и иметь реальные навыки, если ты просто не проходишь первый фильтр и месяцами сидишь без работы? Особенно сейчас, когда самый жесткий рынок находится в диапазоне 1-3 лет опыта. Но даже если человек условно добавит себе год и попадет в фильтр 3-6 лет, он все равно будет внизу выдачи. HH ранжирует кандидатов: сначала идут люди с опытом 5+ лет, потом уже 3-4 года. Когда я делал эксперимент с вакансией, в топ-50 выдачи было около 80% людей с опытом 5 лет и больше. Хотя на саму вакансию откликались разные люди. Кандидатов с 3-4 годами было тоже много, просто они находились ниже. Кстати, проводя собеседования опытным ребятам, которые приходят за помощью с поиском работы, я часто вижу пробелы в базе. Многие опытные разработчики не знают нормально про классы и прототипы. Ошибаются в задачах на this и Event Loop. Не умеют решать алгоритмические задачи. Кто-то не может нормально отрефакторить React-компонент — хотя это один из популярных типов лайвкодинга. А иногда проблемы вообще с базой: человек не помнит, что делают логические операторы, какая разница между функциями, как работают фундаментальные вещи языка. И вот тут возникает вопрос: а что тогда вообще считать опытом? Количество лет в компании? Количество написанных строк кода? Умение решать реальные бизнес-задачи? Или способность пройти проверку на рынке? Правильно говорят, что собеседования — это отдельный навык. Если опытный разработчик не готовится, его может обойти менее опытный специалист, который просто лучше подготовился и умеет играть по новым правилам. Еще часто говорят: «Опытный разработчик не значит хороший разработчик». И я с этим согласен. Я регулярно встречаю людей с большим опытом, которые пишут код, который сложно поддерживать, сложно читать и сложно масштабировать. Мне кажется, что в ближайшие годы с развитием нейросетей разница между просто опытным разработчиком и специалистом, который умеет думать, писать хороший код и правильно использовать AI-инструменты, будет только расти. Мой пик менторства и помощи с трудоустройством новичкам пришелся на 2025 год. И честно, я иногда не понимаю, как некоторые ребята раньше без нейронок умудрялись накручивать опыт и работать в компаниях. Только если с помощью сильного наставника на испытательном сроке. Но как-то же люди справлялись. И за это им большое уважение. Помню, в начале 2024 года я помогал человеку, который накрутил себе 3 года опыта и попал в Сбер. Он обратился за помесячной помощью на испытательном сроке.