tgindex

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

описание

Я IT-специалист, ментор и основатель проекта YeaHub и сообщества Reactify. Здесь рассказываю про Frontend и IT. Менторство: https://reactify.ru YouTube канал: https://youtube.com/@reactify-it YeaHub: https://yeahub.ru/ Связь: @ruslan_kuyanets

← к каналу@reactify_IT
6 563
подписчиков
Охват к подписчикам
29,2%
ERR
Реакции к просмотрам
0,97%
1 244 на 50 постов
Пересылки к просмотрам
1,26%
1 627
Постов в день
0,7
всего 57

Где отзываются чаще

доля реакций к просмотрам
  • 14 авг.без подписи4,12%
  • 14 авг.без подписи3,57%
  • 11 авг.без подписи3,19%
  • 10 авг.Скоро возвращение на YouTube 💪🏼 1. Разбор самого душного собеса: V8, Hidden classes, JIT, TS, Garbage Collector и другие необычные темы на собесе 🤯 2. Архитектура Frontend: Monorepo, Multirepo, Microfrontends, Monoliths Схема эволюция на примере больших компаний Видео в монтаже 💪 Так же много сценариев написал, буду контент машину запускать 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube3,15%
  • 2 авг.💼 Персонализированная подготовка Весь июль тестировали Календарь собеседований и внедряли новый подход к подготовке. Раньше мы в основном готовили ученика до выхода на рынок, а дальше уже подключались точечно, если нужен был мок. И этого подхода в целом хватало. Каждый ученик до выхода на рынок проходил 5–13 экзаменов по всем темам (экзамен = мок с ментором), потом ещё 2+ дополнительных мока и прожарки. Плюс были рандомные моки с другими ребятами примерно 2 раза в неделю. Этого было достаточно, чтобы получать офферы. Но рынок стал тяжелее. Конкуренция выросла, компании стали сложнее отбирать кандидатов, и сейчас нужно выжимать максимум из каждого шанса. Поэтому мы поменяли подход. Есть собеседование в Т-Банк и там лайвкодинг? Сделаем мок лайвкодинга именно под формат Т-Банка. Финальный этап в Сбере? Сделаем часовой мок по софтам и разбору опыта, чтобы максимально повысить шанс пройти. То есть после выхода на рынок ученик теперь имеет возможность делать практически неограниченное количество моков с ментором по необходимости, пока ищет работу. Это и есть персонализированная подготовка. И всё это стало возможным благодаря трекингу собеседований через Календарь. Но моки — это только часть. Календарь даёт ещё несколько сильных возможностей. 🚂 Паровозы собеседований Например, Ваня прошёл собеседование в Авито. Через неделю Петя идёт туда же — Ваня может передать ему вопросы, рассказать про этапы и помочь подготовиться осмысленно. Раньше такие связи часто терялись. Теперь мы специально их создаём. 📚 Материалы и реальные вопросы Мы подключили помощника, у которого есть доступ к куче источникам с записями собеседований, слитыми вопросами, задачами и закрытыми базами. Когда ученик добавляет собеседование в календарь — мы можем искать актуальные материалы именно под эту компанию и этот этап. Давать это ученику. 🤝 Рефералы Ещё один важный эффект — растёт база контактов. Например, ученик прошёл собеседование в Сбер, но понял, что ему не подходит офисный формат. Он с большей вероятностью сможет порекомендовать другого ученика, которому такой формат подходит. Получается система, где ученики помогают друг другу получать больше возможностей. За июль Календарь уже показал хороший результат: — 8 рефералок ученик → ученик — 11 паровозов по собеседованиям — 20 собеседований, где удалось найти вопросы и записи, которые совпали с реальными этапами примерно на 90% — дополнительные моки для подготовки к алгоритмам и финальным этапам Это только первый месяц. Чем больше данных собираем, тем точнее понимаем, где можно помочь, какие компании сейчас нанимают и как увеличить шанс получить оффер. Мы не ждем хороший рынок 🚀 Мы побеждаем на любом 💪2,68%
  • 12 авг.👩‍💻 Эволюция 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 Элита — 📚 Менторство — 📹 YouTube1,76%
  • 6 авг.👩‍💻 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 Элита — 📚 Менторство — 📹 YouTube1,59%
  • 23 июл.👩‍💻 Прожарка собеса на Frontend Разработчика https://youtu.be/a43a-SCCHLg Когда мне предложили провести прожарку собеса, я сначала хотел взять какой-нибудь идеальный кейс. Тот самый собес, где ученик приходит, отвечает на все вопросы, закрывает все этапы и забирает оффер. Казалось бы, для ментора это самый красивый пример. Но когда я начал готовить сценарий, понял — разбирать там особо нечего. В YouTube и так много собесов, а сама идея прожарки как раз в другом: найти ошибки, разобрать их и понять, что можно было сделать лучше. Поэтому решил взять первый серьезный собес ученика в Big Tech. Ученик учился 8 месяцев: прошел весь стек, закрыл все основные темы и сдал 13 экзаменов. После этапа теории еще 2-3 месяца ушли на практику, стажировку, создание резюме, проработку опыта и подготовку самопрезентации. И вот здесь есть важный момент. Когда ты проходишь большой объем теории, а потом несколько месяцев фокусируешься на практике и подготовке выхода на рынок, часть тем уже не ощущается так свежо, как сразу после изучения. Поэтому перед собесами всегда важно возвращаться к базе и держать знания в тонусе. Сейчас рынок тяжелый, поэтому стратегия была не уходить в бесконечную подготовку, а быстрее выйти на рынок: начать откликаться, получать реальные собеседования и параллельно повторять уже изученный материал. Плюс нужно учитывать временной лаг: часто после отклика проходит 2-4 недели, пока HR дойдет до резюме и начнется активная коммуникация с компаниями. Но хорошее позиционирование сработало быстрее, чем ожидали. Уже в первые дни начали приходить сообщения от компаний, а технические этапы начали назначаться буквально через пару дней. Среди них были крупные компании: Альфа, Сбер, VK, Яндекс, X5 и другие. Поэтому я и решил прожарить именно первый его собес в Big Tech: сделать работу над ошибками, вместе с Антоном разобрать моменты, дать советы и навалить базы. 📚 Материалы для подготовки к собеседованиям Что важно понять из этой истории: — Даже на сложном рынке правильная подготовка и позиционирование могут привести к большому количеству возможностей. — Даже если ты прошел все темы и сдал десятки проверок, нельзя терять тонус. Базу нужно постоянно поддерживать. — Любой собес — это не приговор, а обратная связь. Он показывает, что нужно докрутить перед следующими этапами. — Не стоит быть вечным учеником. Конечно, если бы подготовка продолжилась еще 1-2 месяца, знаний было бы еще больше. Но было бы столько собесов? А кто его знает, рынок меняется быстро. Спустя месяц после этого собеса ученик получил оффер в финтех-компанию с хорошей зарплатой — 260к. Он не сдался, продолжил искать, сделал работу над ошибками и выбрал правильную стратегию выхода на рынок. 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube1,54%
  • 10 мая 2025 г.без подписи1,54%
  • 9 янв. 2025 г.без подписи1,49%
  • 22 июн. 2025 г.без подписи1,39%
  • 31 окт. 2024 г.без подписи1,32%