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

👩‍💻 ВЕСЬ React в одном собеседовании. 100 вопросов + 20 задач за 2 часа Это видео представляет собой структурированный разбор ключевых тем React, необходимых для успешного прохождения технического собеседования. Формат сочетает теоретические вопросы с практическим решением задач. Рекомендую посмотреть это видео, как и предыдущее. Считай, сразу готов к собесам 😎 Видео уже на канале! Я не оставляю ссылку, так как видео лучше продвигается, если заходить на него напрямую с YouTube. Это помогает улучшить его рейтинг и увеличить шансы на органическое продвижение. 🔗 Ссылка на вопросы и задачи #react #собеседования

Видео оказалось дольше, чем по React. Сняли одним дублем, без остановки, без монтажа и вставок. Оцените потом, как надо отвечать на собеседованиях, какие глубокие ответы дает Владимир 💪

Готовность 5 минут, скоро съемки 👩‍💻 Вопросы + Задачи Новый герой видео - Владимир. Во вторник (надеюсь) выйдет видео

👩‍💻 ВЕСЬ React в одном собеседовании. Уже собираем интересные вопросы и задачи. Выбран кандидат на прохождение собеса 🤝 Будет пушка 🏆

Мне нравится IT за возможность бесконечно развиваться. Приятно и круто, когда твоя экспертиза не ограничивается одной областью. Я считаю, что хороший специалист должен мыслить архитектурно, понимать инфраструктуру и не ограничиваться своей узкой частью, а видеть, как работает приложение целиком. Помню, как писал пост о том, какие технологии я знаю и с чем успел поработать. Также был список того, с чем хотел бы поработать для полного счастья. В этом списке были Kubernetes и умение создавать инфраструктуру продуктов. И вот я это сделал. Я полностью, от начала и до конца, мигрировал всю инфраструктуру на Kubernetes в YeaHub. Теперь это стартап с enterprise-уровнем инфраструктуры в полном фарше. Я мог нанять DevOps, но решил сделать всё сам — мне нужно было закрыть этот пункт. Все свои шаги я записывал и оформили в пошаговый гайд с объяснениями. Теперь, если у меня появится идея стартапа, я смогу за день развернуть инфраструктуру продукта любой сложности. Круто, что мои ученики изучают процессы разработки на реальном боевом проекте с таким сложным стеком. Мы изучаем разработку на примере YeaHub, учимся работать в команде и писать качественный код. Сейчас мы создаем приложение на Next.js, чтобы ученики получили ещё и опыт с этим стеком. А ещё наша команда растёт. YeaHub объединяет менторов, которые хотят, чтобы их ученики умели работать, а не просто проходили собесы. Для меня это тоже прокачка, только уже в сторону менеджера, руководителя. Сейчас у нас 100 человек на проекте YeaHub, из которых большинство — новички. Сложно всё это поддерживать и контролировать. Легко, когда ты Product Owner в команде из 20 опытных специалистов, но сложно, когда ты Product Owner в команде из 100 человек, 90% которых — новички без опыта 😅 В общем, большие планы у нас. Работаем дальше 💪🚀 ПС. На 1 скрине расписание в YeaHub. На 2 скрине scrum-доска. На 3 скрине наша документация Пост, где я говорю о своих навыках и планах: https://t.me/reactify_IT/1404 Описание инфраструктуры YeaHub: https://t.me/yeahub/75

🚀 UX Performance: как скорость ощущается глазами пользователя Когда мы говорим "сайт быстрый" — это не про цифры в Lighthouse, а про то, как человек ощущает взаимодействие. Google выделил три ключевых метрики, которые напрямую влияют на удобство: LCP — Largest Contentful Paint INP (ранее FID) — Interaction to Next Paint CLS — Cumulative Layout Shift Давай разберём их: что значат, как ломаются и как чинить. 1. 🖼 LCP — "Когда я увидел главное" Что это: за сколько секунд показывается главный кусок контента (большая картинка, заголовок, постер видео).

👉 Хорошо: ≤ 2.5с, Плохо: > 4с.

Пример плохого UX: Открываешь страницу новостей, а вместо фото и заголовка долго смотришь на белый экран. Даже если внизу уже подгрузился футер, пользователю кажется, что страница медленная. Что ломает LCP: - Ленивая загрузка (loading="lazy") у главной картинки. - Большой TTFB (медленный сервер/БД). - Картинка грузится через JS, а не сразу в HTML. Как починить: - Ускорить бэкенд + CDN. - Добавить preload для картинки - Не ленизируйте главный баннер. - Используйте современные форматы (AVIF/WebP). 2. ⚡ INP — "Насколько сайт слушается" Что это: измеряет задержку между действием (клик, ввод) и моментом, когда UI реально отвечает.

👉 Хорошо: ≤ 200мс, Плохо: > 500мс.

Пример плохого UX: Ты кликаешь на кнопку "Добавить в корзину", а сайт думает 1–2 секунды, и только потом подсвечивает товар. Даже если заказ оформляется успешно — ощущение тормоза. Что ломает INP: - Тяжёлый JS-бандл, грузящий CPU. - Обработчик события делает слишком много (например, ререндер целого списка). - Длинные задачи > 50мс на главном потоке. Как починить: - Разбивайте работу на части (Web Worker, requestIdleCallback). - Даём быстрый визуальный отклик, а данные подгружаем асинхронно. - Слушатели прокрутки/тача → всегда passive: true - Для длинных списков — content-visibility: auto; в CSS. 3. 📏 CLS — "Ничего не прыгает" Что это: метрика стабильности интерфейса.

👉 Хорошо: ≤ 0.1, Плохо: > 0.25.

Пример плохого UX: Ты хотел кликнуть "Оплатить", но страница прыгнула из-за подгрузившейся рекламы, и ты ткнул в "Удалить". Боль. Что ломает CLS: - Картинки без размеров. - Баннеры/видео без зарезервированного места. - Подключение шрифтов без font-display: swap. Как починить: - Всегда задаём размеры/aspect-ratio у изображений - Резервируем контейнеры под рекламу. - Используем font-display: swap и fallback-шрифты близкие по метрикам. - Анимации — только через transform/opacity.

📚 Кэширование без меры: когда оптимизация становится проблемой Кэширование и мемоизация звучат как бесплатная оптимизация. Мы думаем: «Раз вычисление можно не делать повторно, значит всегда лучше закэшировать». Но это опасное заблуждение. Если кэшировать без меры, приложение начинает засорять память и работать хуже, а не лучше. 🚨 Как мы засоряем память Представьте, что вы храните в памяти результаты всех вычислений. Старые данные не удаляются, новые постоянно добавляются. В итоге кэш разрастается до сотен мегабайт. На слабых устройствах это выливается во фризы или даже падение. Был реальный кейс: разработчик решил «оптимизировать» React-страницу и мемоизировал каждый UI-компонент. На странице их было сотни. В итоге выигрыш оказался мизерным, а память улетела в космос. Сам процесс мемоизации стал дороже, чем пересчёт. Правильнее было бы мемоизировать целую форму или контейнер, где решение о перерисовке действительно экономит ресурсы. ❌ Пример бессмысленной мемоизации

function add(a, b) {
  return a + b;
}

// кто-то решил мемоизировать даже это
function memoize(fn) {
  const cache = new Map();
  return function(...args) {
    const key = args.join(',');
    if (cache.has(key)) return cache.get(key);
    const result = fn(...args);
    cache.set(key, result);
    return result;
  };
}

const memoAdd = memoize(add);

console.log(memoAdd(2, 3)); // 5
console.log(memoAdd(2, 3)); // 5 из кэша (но толку?)

Сложение и так работает за наносекунды. Хранить результаты в памяти бессмысленно — найти их в Map будет дольше. ✅ Пример, где кэш оправдан Тяжёлые операции, например парсинг или генерация отчётов.

function heavyComputation(key) {
  // имитация дорогой операции
  for (let i = 0; i < 1e7; i++) {}
  return `Result for ${key}`;
}

Если вызывать её часто с одними и теми же данными, кэш реально ускоряет работу. Но нужен лимит. Самый популярный вариант — LRU Cache (Least Recently Used).

import LRU from 'lru-cache';

const cache = new LRU({ max: 100 }); // максимум 100 элементов

function getData(key) {
  if (cache.has(key)) {
    return cache.get(key);
  }
  const result = heavyComputation(key);
  cache.set(key, result);
  return result;
}

console.log(getData("a")); // долго
console.log(getData("a")); // быстро, из кэша

Теперь кэш не растёт бесконечно. Когда хранилище достигает 100 элементов, старые записи выбрасываются. 🔧 Пример из UI Вместо того чтобы мемоизировать каждый компонент по отдельности:

const MemoButton = React.memo(Button);
const MemoInput = React.memo(Input);
const MemoLabel = React.memo(Label);

Лучше мемоизировать контейнер, внутри которого они все живут:

const Form = ({ fields, onSubmit }) => {
  return (
    <form onSubmit={onSubmit}>
      {fields.map((f) => (
        <Input key={f.id} {...f} />
      ))}
      <button type="submit">Submit</button>
    </form>
  );
};

// мемоизируем целиком форму
export default React.memo(Form);

Так вы экономите не на «каждой кнопке», а на всей форме сразу. Это дешевле и эффективнее.

Кэш — это инструмент, а не магическая палочка. Он действительно помогает на тяжёлых вычислениях и часто используемых данных. Но хранить всё подряд — значит засорять память. Лёгкие операции всегда лучше пересчитать заново. А в UI выгоднее мемоизировать крупные контейнеры, а не каждую мелочь.

💡Правило простое: если сомневаешься — лучше пересчитай, чем закэшируй навсегда. #оптимизации #react #frontend #память #memo #кеширование

🎯 Менторство до трудоустройства (всё включено, оплата после оффера) Редко пишу про своё дело, хотя уверен — программа одна из лучших на рынке. Вот почему: 🔹 Авторская программа — все курсы, гайды и материалы написаны мной: от основ HTML до деплоя и архитектуры. 🔹 Реальная стажировка — участие в большом проекте с командой из 60 специалистов (QA, Backend, Analyst, Frontend, iOS, Android, дизайнеры). Работаем по всем процессам как в настоящей компании. 🔹 Максимальная вовлечённость ментора — экзамены, мок-собесы, групповые занятия, личные разборы. 🔹 Трудоустройство под ключ — подготовка резюме, тренировка собесов, сопровождение на этапе оффера и поддержка на испытательном сроке. 🔹 Сообщество 200+ выпускников и студентов — ребята, которые уже прошли этот путь, нашли работу и помогают друг другу. 🔹 Большая база знаний — 200+ записей лекций, собесов, гайдов и полезных материалов. Если ищешь качественное обучение до трудоустройства — пиши. Подробнее 👉 https://t.me/mentor_reactify/150

🖥 Замыкания и долгоживущие ссылки: как избежать утечек памяти Замыкания в JavaScript позволяют функциям «запоминать» переменные внешнего окружения. Но если в замыкании остаются большие объекты или DOM-элементы, сборщик мусора их не очистит — это приводит к утечкам памяти. 🔹 Проблема: долгоживущие ссылки Когда замыкание хранит объект, на который больше нет других ссылок, сборщик мусора не может его удалить, потому что замыкание всё ещё держит ссылку.

function createCache() {
    const cache = { largeData: new Array(1000000).fill('*') };

    return function getCache() {
        return cache;
    };
}

const getCache = createCache();
// cache занимает память, пока существует getCache

Здесь cache будет жить в памяти пока существует функция getCache, даже если мы больше не используем её данные. 🔹 Решение 1: функция очистки Можно добавить метод для обнуления ссылок, чтобы GC мог очистить объект:

function createCache() {
    let cache = { largeData: new Array(1000000).fill('*') };

    function getCache() {
        return cache;
    }

    getCache.cleanup = function () {
        cache = null; // память освобождается
    };

    return getCache;
}

const getCache = createCache();
getCache.cleanup(); // теперь память под cache может быть освобождена

🔹 Решение 2: WeakMap для временных данных Если нужно хранить состояние объектов, но не держать их в памяти навсегда, используйте WeakMap. Сборщик мусора автоматически очистит объект, когда на него не останется ссылок.

const objectData = new WeakMap();

function attachData(obj) {
    objectData.set(obj, { temp: 'data' });
}

let obj = {};
attachData(obj);

obj = null; // объект и данные в WeakMap будут автоматически удалены

🔹 Резюме: как безопасно использовать замыкания - Не храните в замыканиях лишние объекты. - Для больших структур или временных данных используйте WeakMap/WeakSet. - Добавляйте функции очистки (cleanup) для объектов и стейта, которые больше не нужны. - Проверяйте память через DevTools, чтобы убедиться, что объекты удаляются.

💡 Совет для разработчиков: Любой state или кеш, который вы храните в замыкании, должен иметь «точку выхода» — иначе ваше приложение постепенно «накопит» память, которая больше не используется.

#оптимизации #react #frontend #память #замыкания

🧠 Оптимизация памяти во фронтенде Когда говорят про оптимизацию фронтенда, чаще всего думают о скорости загрузки или анимациях. Но есть ещё одна важная область — память. - утечки замедляют приложение со временем - на мобильных устройствах это может приводить к крашам - стабильность UX напрямую зависит от того, как мы управляем памятью Теперь давайте поговорим об основных источниках проблем 1️⃣Замыкания и долгоживущие ссылки Частая ошибка — сохранять в замыкании большие объекты или DOM-элементы, которые уже не нужны. В итоге GC (сборщик мусора) не может их очистить. Решение: не тащить в замыкания лишнее, по возможности использовать WeakMap/WeakSet для хранения. 2️⃣Неудалённые обработчики событий Навесили addEventListener, но забыли removeEventListener. Опасно при работе с компонентами: удалённый компонент может остаться в памяти из-за висящего обработчика. Решение: всегда отписываемся.

useEffect(() => {
  const handler = () => console.log("scroll");
  window.addEventListener("scroll", handler);

  return () => {
    window.removeEventListener("scroll", handler);
  };
}, []);

3️⃣Таймеры и интервалы Забытые setInterval или setTimeout продолжают жить, даже если компонент уже размонтирован. Решение: чистим вручную.

const id = setInterval(() => doWork(), 1000);
// позже
clearInterval(id);

4️⃣Кэширование «без меры» Иногда мы храним результаты в памяти (memoization, cache, global store), но не думаем про «старые» данные. В итоге кэш растёт бесконечно. Решение: использовать LRU cache или ограничивать размер хранения. 5️⃣Глобальные ссылки и синглтоны Всё, что записано в глобальную область (window, global store), живёт всё время жизни приложения. Если туда положить тяжёлый объект, GC его никогда не удалит. Решение: хранить только действительно нужное, очищать ссылки вручную, если объект больше не нужен. 6️⃣DOM-ссылки и оторванные узлы Если держать ссылку на DOM-элемент, удалённый из документа, он остаётся в памяти. Особенно актуально при ручной работе с document.createElement. Решение: обнулять ссылки после удаления узлов. #оптимизации #react #frontend #память

🧠 Оптимизация памяти во фронтенде Когда говорят про оптимизацию фронтенда, чаще всего думают о скорости загрузки или анимациях. Но есть ещё одна важная область — память. - утечки замедляют приложение со временем - на мобильных устройствах это может приводить к крашам - стабильность UX напрямую зависит от того, как мы управляем памятью Теперь давайте поговорим об основных источниках проблем 1️⃣Замыкания и долгоживущие ссылки Частая ошибка — сохранять в замыкании большие объекты или DOM-элементы, которые уже не нужны. В итоге GC (сборщик мусора) не может их очистить. Решение: не тащить в замыкания лишнее, по возможности использовать WeakMap/WeakSet для хранения. 2️⃣Неудалённые обработчики событий Навесили addEventListener, но забыли removeEventListener. Особенно опасно при работе с компонентами: удалённый компонент может остаться в памяти из-за висящего обработчика. Решение: всегда отписываемся. ``` useEffect(() => { const handler = () => console.log("scroll"); window.addEventListener("scroll", handler); return () => { window.removeEventListener("scroll", handler); }; }, []); ``` 3️⃣Таймеры и интервалы Забытые setInterval или setTimeout продолжают жить, даже если компонент уже размонтирован. Решение: чистим вручную.

const id = setInterval(() => doWork(), 1000);
// позже
clearInterval(id);

4️⃣Кэширование «без меры» Иногда мы храним результаты в памяти (memoization, cache, global store), но не думаем про «старые» данные. В итоге кэш растёт бесконечно. Решение: использовать LRU cache или ограничивать размер хранения. 5️⃣Глобальные ссылки и синглтоны Всё, что записано в глобальную область (window, global store), живёт всё время жизни приложения. Если туда положить тяжёлый объект, GC его никогда не удалит. Решение: хранить только действительно нужное, очищать ссылки вручную, если объект больше не нужен. 6️⃣DOM-ссылки и оторванные узлы Если держать ссылку на DOM-элемент, удалённый из документа, он остаётся в памяти. Особенно актуально при ручной работе с document.createElement. Решение: обнулять ссылки после удаления узлов. #оптимизации #react #frontend #память

🔧 Как оптимизировать фронтенд? Во-первых, знание способов оптимизации фронтенд-приложений полезно абсолютно всем разработчикам: это помогает писать более качественный, эффективный и поддерживаемый код. Во-вторых, тема оптимизаций регулярно всплывает на собеседованиях. Когда вас спрашивают, важно не просто перечислить техники, а уметь рассуждать, приводить примеры и объяснять, почему именно этот подход работает. Нужно чувствовать себя в этом вопросе как рыба в воде. Чтобы в этом разобраться, мы будем делить оптимизации на разные категории. Это позволит системно подойти к теме, а не сваливать все приёмы в одну кучу: 📌 1. По направлению оптимизации (Что именно оптимизируем?) → Загрузка (быстрее доставить код и ассеты пользователю) → Выполнение (ускорить работу JS, рендера, анимаций) → Рендеринг (уменьшить количество перерисовок, оптимизировать DOM и Virtual DOM) → Сеть (сократить количество запросов, уменьшить вес ресурсов) → Память (контролировать утечки и тяжелые структуры данных) → Пользовательский опыт (UX perf) (перфоманс как часть удобства: LCP, FID, CLS) 📌 2. По подходу (активные / пассивные) → Активные — мы прямо пишем код с учетом оптимизаций (мемоизация, lazy-loading, code splitting). → Пассивные — мы просто правильно настраиваем окружение и используем инструменты (CDN, HTTP/2, gzip/brotli, кеширование). 📌 3. По уровню применения → Фреймворк-специфичные (React: memo, useCallback, Suspense; Vue: computed, watchEffect, и т.д.) → Языковые/ванильные (JS: Event delegation, Web Workers; CSS: will-change, contain; HTML: loading="lazy") → Инфраструктурные (CDN, кеши, SSR/SSG, bundlers: webpack/vite/rollup) → Браузерные и DevTools (Performance tab, Lighthouse, Coverage, профилировщики) → Архитектурные и паттерны (Декомпозиция, DRY, SOLID и тд.) 📌 4. По типу эффекта → Скорость загрузки (Load performance) — как быстро сайт открывается. → Интерактивность (Runtime performance) — как быстро реагирует на действия. → Гладкость (Smoothness) — FPS, плавность анимаций, отсутствие "лагов". → Устойчивость (Stability) — CLS, предсказуемость интерфейса. 📌 5. По времени применения → До разработки — проектирование архитектуры, выбор стека. → Во время разработки — правильные паттерны, линтеры, code splitting. → После разработки — профилирование, мониторинг перфоманса, оптимизация по данным реальных пользователей (RUM). Я запускаю цикл постов, в котором на конкретных примерах разберём каждую категорию. Посмотрим, какие инструменты и практики можно применять, обсудим их плюсы и минусы, а также то, как они работают в реальных проектах. Цель — собрать большую базу знаний из 50+ способов оптимизации фронтенда (а может, получится и больше). В итоге выйдет не просто серия постов, а полноценная карта оптимизаций, которая станет шпаргалкой для собесов и практической помощью в работе. #оптимизации #react #frontend

🖥 Middle Frontend разработчик в компанию Ай-Теко Техническое собеседование. ЗП: от 200к. Май 2025. Проект: Сбер. Опыт: 4 года. Задачи: Отсортировать список нечетных чисел, валидность скобок. Вопросы: - Перечислите основные методы массивов - Какие есть способы создания объектов и в чем их отличия? - Что такое Promise? - Расскажите про все методы Promise? - Расскажите про this и контекст? Все 14 вопросов можно посмотреть на нашей платформе #собес

🚀 YeaHub растёт — вместе с вами Сегодня YeaHub — это платформа, которая помогает айтишникам готовиться к собеседованиям, развивать навыки и уверенно расти в профессии. Но это только начало. Мы создаём единую точку входа в IT — пространство, где можно не только учиться, но и общаться, развиваться, строить карьеру и создавать. 📺 Медиа-экосистема YeaHub Мы активно развиваем наши медиа-платформы, чтобы вдохновлять, делиться опытом и рассказывать истории IT: ✈️ Telegram-экосистема каналов 📹 YouTube-канал (скоро будет много полезного контента!) 🎵 TikTok с быстрыми и полезными форматами 📷 Аккаунт в Нельзяграме Также мы будем публиковать статьи на внешних площадках от лица YeaHub, чтобы наш голос был услышан шире. 👥 YeaHub — это сообщество Мы строим не просто платформу, а живое комьюнити. Планируем проводить: - регулярные голосования, - обсуждения улучшений, - активности для участников. Каждый участник — важная часть YeaHub. Мы хотим, чтобы вы не только пользовались платформой, но и влияли на её развитие. 👨‍💻 YeaHub — это проект, который делают айтишники Наша платформа создаётся айтишниками для айти — вместе с опытными экспертами и участием стажёров. Для новичков это: - реальный опыт командной разработки, - работа по Scrum, - взаимодействие с разными ролями, - практика на большом, живом проекте. А ещё наш код полностью открыт — специально для тех, кто хочет учиться на реальных проектах. Это отличная возможность погрузиться в живую кодовую базу https://github.com/YeaHubTeam 🦸‍♂️ Кто стоит за разработкой: @ruslan_kuyanets @denispereloma @the_real_daniil — менторы по Frontend, разрабатывают веб-версию YeaHub вместе со своими учениками @kishmyak — ментор по Android, вместе с новичками работает над Android-приложением @isakovios — ментор по iOS, вместе с учениками развивает iOS-версию @edzi_qa — ментор по QA, помогает минимизировать баги и прокачивает будущих тестировщиков @turimik — ментор по системной аналитике, его команда пишет требования и описания задач для всех участников Также в проекте участвуют дизайнеры, backend-разработчики и другие специалисты, которые двигают YeaHub вперёд. Мы растём, и вместе с нами растут участникы команды — получая бесценный опыт. 🤝 YeaHub объединяет Мы развиваем систему Guru (Экспертов) чтобы контент и качество платформы было на высоком уровне. Сейчас в нашей команде экспертов есть: 👩‍💻 Guru Frontend | РУСЛАН КУЯНЕЦ 🖥 Guru Android | АНТОН ГУЛЯЕВ 🍏 Guru iOS | РОМАН ИСАКОВ 👾 Guru Golang | МАКСИМ ЛУКЬЯНОВ 👩‍💻 Guru QA | ЗИЯЕВ ЭД 🚀 Вперёд — к новым вершинам Впереди много вызовов и амбициозных планов. Спасибо, что вы с нами. Мы делаем это вместе 💜 👉 Обучайтесь, общайтесь, растите вместе с https://yeahub.ru

🖥 Ты не сможешь решить эти Event loop задачки На собеседованиях часто просят определить порядок вывода в консоль — это типичные задачи на понимание работы Event Loop в JavaScript. Их нужно не просто уметь решать, но и грамотно объяснять, почему вывод именно такой. Многие новички теряются на таких заданиях, потому что не понимают, как работает механизм очередей и стеков исполнения. На самом деле, всё становится гораздо проще, когда ты разберёшься в логике работы Event Loop. После этого ты сможешь решать практически любую подобную задачу. Кстати, у меня есть видео, где я подробно разбираю 5 разных задач, показывая на схеме каждый шаг: — что куда попадает — в какую очередь отправляется — в какой момент выполняется Рекомендую посмотреть, особенно если хочешь уверенно чувствовать себя на техническом собеседовании. 📹 Разбор задач по Event Loop с собеседований

console.log('Start');

Promise.resolve()
  .then(() => {
    console.log('Promise 1');
    Promise.resolve()
      .then(() => console.log('Nested Promise'));
  })
  .then(() => console.log('Promise 2'));

console.log('End');

console.log('Start');

setTimeout(() => console.log('Timeout 1'), 0);

Promise.resolve()
  .then(() => {
    console.log('Promise 1');
    setTimeout(() => {
      console.log('Timeout 2');
      Promise.resolve().then(() => console.log('Promise inside Timeout'));
    }, 0);
  });

setTimeout(() => console.log('Timeout 3'), 0);

console.log('End');

Promise.resolve('Data')
  .then(res => { throw new Error('Problem'); })
  .catch(err => {
    console.log('Caught:', err.message);
    return 'Recovered';
  })
  .finally(() => console.log('Cleanup'))
  .then(res => console.log('Final:', res));

За чем следить айтишнику 😅 Ваши ставки? Ждём снижение ставки?

Не люблю разводить срачи, но на мой канал запущен таргетинг от одного "ментора". За ним стоит большая команда продюсеров и крупный рекламный бюджет. Сам он занятий не проводит — всё на кураторах. А реклама — повсюду: Яндекс, ВК, Телеграм и т.д. Совсем недавно у него была схема 10k предоплата + 100% постоплата после трудоустройства. Сейчас — только полная предоплата 180k+. Почему так? Видимо, экономика не сходится: нужно платить кураторам, покупать рекламу, греть новых клиентов. А вот с трудоустройством у учеников не всё гладко — до оффера довести получается далеко не всегда. Поэтому и убрали постоплату: деньги нужно забрать сразу, а будет ли результат — неважно. Интересный момент: сам "ментор" начал путь с нуля всего год назад, с помощью другого наставника. Более того, материалы своего ментора он просто украл, за что был исключён из сообщества ОМ. Мораль проста: прежде чем идти на курс или менторство — изучайте, кто стоит за проектом. Репутация, реальный опыт, результаты учеников — всё это важно. Не ведитесь на агрессивную рекламу.

🖥 Практика в Open-Source: как начать и зачем это нужно Участие в open-source проектах — один из лучших способов прокачать навыки, получить реальный опыт и сделать вклад в IT-сообщество. Как начать? → Выберите проект – найдите проект на GitHub/GitLab, который вам интересен (например, связанный с вашим стеком технологий). → Изучите документацию – перед внесением правок разберитесь в структуре кода и правилах контрибуции (часто есть файл CONTRIBUTING.md). → Начните с малого – исправьте опечатки, улучшите документацию или возьмите задачу с меткой good first issue. → Делайте пул-реквесты (PR) – предлагайте свои изменения, следуя стандартам проекта. → Получайте фидбек – ревью от опытных разработчиков поможет вам расти. Зачем это нужно? ✅ Реальный опыт – работаете с живым кодом, а не учебными примерами. ✅ Портфолио – ваши контрибуции видны в профиле GitHub и могут заинтересовать работодателей. ✅ Нетворкинг – знакомитесь с разработчиками и получаете рекомендации. ✅ Помощь сообществу – ваш вклад может упростить жизнь другим программистам. Где искать задачи? →GitHub Explore (github.com/explore) →Good First Issues (goodfirstissues.com) →Open Source Friday (opensourcefriday.com) Совет: Не бойтесь ошибаться – даже небольшие правки ценны. Главное – начать! YeaHub тоже поддерживает open-source инициативу. Мы начали проработку гайдов, задач и issues, чтобы начинающие разработчики могли практиковаться. А пока можете предлагать улучшения😊 https://github.com/YeaHubTeam/yeahub-platform

🚀 YeaHub в цифрах Аудитория: → 3 500 зарегистрированных пользователей → 10 000 подписчиков в экосистеме YeaHub (Telegram) → 2 000 подписчиков в Instagram → 1 000 подписчиков на YouTube → 1 200 подписчиков в TikTok → 100 000+ посетителей с ноября 2024 года Команда и развитие: → Более 100 IT-специалистов работали над платформой (разработчики, дизайнеры, тестировщики) → Инкубировали 60+ молодых специалистов, успешно трудоустроившихся после стажировки → 4 стажёра на Go разрабатывают новый сервис для YeaHub В планах – привлечение начинающих тестировщиков для работы с реальным проектом. Хотите на бесплатную стажировку? Пишите: @yeahub_support Развитие платформы: → Расширяем партнёрство с экспертами для создания качественного контента → Разрабатываем новые сервисы для IT-развития → Постоянно улучшаем функционал платформы YeaHub растёт, обучает и создаёт новые возможности для IT-сообщества. 🚀 Подписывайтесь на каналы Экосистемы YeaHub Проект YeaHub: 🚀 YeaHub | 🖥 GitHub | ✈️ Telegram 🎵 TikTok | 📹 YouTube | 👥 Чат