Интерактивный ребейз. Часть 1.

В разработке довольно часто возникает необходимость отредактировать историю коммитов. Запутанная история комиттов осложняет ее чтение, когда требуется выяснить, какие изменения происходили с продуктом в течение последних нескольких версий. В некоторых командах принято нажимать галочку “squash commits” перед мерджем. Эта опция собирает все коммиты из мердж реквеста в один. Но что, если я не хочу собирать все коммиты в один? Например, в мердж реквесте я сделала один багфикс и одну фичу и хочу поделить эти правки на два разных коммита. В этом случае, если в моей фиче окажется баг, я смогу быстро откатить ее при помощи реверта коммита, не затронув багфикс. В этом случае можно легко отредактировать историю коммитов при помощи интерактивного ребейза.

Итак, допустим, у меня есть следующая история комиттов:

commit db75a1b15cddea5cae2dd047db04dfce69ff5186
  Add feature
commit 76d6818aa1ad6d68e27306b541ff7ab04090bc5b
  Bugfix

После чего я поняла, что в bugfix нужно добавить еще код. У меня получилась вот такая история комиттов:

commit ea5ed9f0245f70853069454d19d53e661679dfa3
  Bugfix too
commit db75a1b15cddea5cae2dd047db04dfce69ff5186
  Add feature
commit 76d6818aa1ad6d68e27306b541ff7ab04090bc5b
  Bugfix

Держите рецепт, как слить первый и третий коммит в один:

1️⃣ Заходим в интерактивный ребейз при помощи git rebase -i. Нам потребуются только три последние коммита, поэтому указываем git rebase -i HEAD~3.

2️⃣ Видим историю наших коммитов. В отличие от истории, которую пишет нам git log, сверху будет самый старый коммит.

  pick 76d6818 Bugfix
  pick db75a1b Add feature
  pick ea5ed9f Bugfix too

3️⃣ В текстовом редакторе меняем места третий и второй коммит

  pick 76d6818 Bugfix
  pick ea5ed9f Bugfix too
  pick db75a1b Add feature

4️⃣ Теперь нам нужно сделать слить два коммита по багфиксу в один. Подсказка в текстовом редакторе говорит нам, что мы можем использовать fixup:

# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#                    commit's log message, unless -C is used, in which case
#                    keep only this commit's message; -c is same as -C but
#                    opens the editor

Указываем флаг f для коммита, который мы хотим слить:

pick 76d6818 Bugfix
f ea5ed9f Bugfix too
pick db75a1b Add feature

5️⃣ Выходим из вима с сохранением (не буду писать про это подробно, в интернете много мемов на тему выхода из вима) и вуаля, ваша история перезаписана, два коммита слиты в один🎉

#интерактивный_ребейз

Зачем нужны @types/node во фронтовом приложении

И правда, зачем? Мы ведь не на node.js приложение пишем. Но тайпинги ноды могут нам потребоваться, например, в конфиге сборщика, если мы хотим задать альясы путей.

Допустим, мы указываем альясы путей как-нибудь так: '~components': path.resolve(__dirname, './src/components’). Для этого нам нужно импортировать в файле конфига стандартный модуль path. И тайпскрипт сругается на него, потому что он не знает, что такое path. Для того, чтобы решить эту проблему, необходимо установить @types/node в ваше приложение как dev зависимость. В этом же пакете будут тайпинги и для других стандартных модулей ноды, например, fs.

Как организовать компоненты в ui kit?

При разработке ui kit многие команды применяют storybook, который позволяет наглядно отобразить компоненты дизайн системы как для дизайнеров, так и для разработчиков, а также позволяет писать простые скриншотные тесты. Однако почти все команды рано или поздно сталкиваются с необходимостью как-то группировать компоненты в сторибуке, чтобы он не превратился в свалку, в которой сложно что-то найти. Мне нравится подход atomic design.

Atomic design делит компоненты на пять уровней: атомы, молекулы, организмы, шаблоны, страницы. В разработке ui kit я обычно использую первые три. Ниже поговорим про уровни компонентов подробнее.

1️⃣ Атомы. Самые маленькие строительные блоки компонентов. Это кнопки, инпуты, лейблы, радиобаттоны, иконки.

2️⃣ Молекулы. Композиции атомов. Простые группы UI, функционирующие вместе. Например, Search - компонент, состоящий из инпута, лейбла и кнопки.

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

4️⃣ Шаблоны. Компоненты, которые определяют структуру страницы. Например, компонент Layout, в котором есть шапка и подвал, и который позволяет использовать его с любым конвентом.

5️⃣ Страницы. Отдельные страницы системы.

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

Выше на рисунке представлены примеры атомов, молекулы и организма: атомами являются простой текст, инпут, кнопка, молекулой - компонент поиска, организмом - шапка сайта.

Сохраняем настройки UI в local storage.

Предположим, у вас есть некоторая таблица товаров, которую пользователь может сортировать и фильтровать. Вы хотите, чтобы выбранные пользователем фильтры не сбрасывались после перегрузки страницы, а сохранялись. Где хранить эти данные? Отправлять их на бекенд кажется избыточным: это настройки UI, а не данные какой-либо модели. Хорошим вариантом для хранения таких данных является local storage: он позволяет персистентно хранить данные на устройстве. Если пользователь зайдет на сайт с другого устройства, то он не увидит своих сохраненных фильтров, но это не выглядит критичной ситуацией. Поэтому local storage является хорошим решением нашей проблемы.

Держите рецепт:

1️⃣ Нам нужен ключ, в котором будут храниться наши фильтры. Например, PRODUCTS_FILTER. Будет хорошим решением вынести ключ в константу, чтобы гарантированно использовать во всем приложении верный ключ. В файле, где хранятся константы приложения (например, const.ts) создаем константу: const PRODUCTS_FILTER = 'PRODUCTS_FILTER'.

2️⃣ В том месте, где мы кликаем на фильтр, необходимо записывать обновленные данные в localStorage.

const saveFilters = (filters) => {
  localStorage.setItem(
    PRODUCTS_FILTER,
    Object.entries(filters)
      .map(([key, value]) => `${key}: ${value}`)
      .join(', ')
  );
};
...

onChange=((filterId, filterValue) => { 
    const newFilters = {…filters, [filterId]: filterValue};
    setFilters(newFilters)
    saveFilters(newFilters)
}

3️⃣ Теперь при загрузке загрузке нам достаточно инициализировать наши фильтры из localStorage

const initFilters = () => {
    const savedFilters = localStorage.getItem(PRODUCTS_FILTER);

    If (!savedFilters) {
         return [];
    } 

    return savedFilters.split(',').reduce((acc, item) => {
         const [key, value] = item.split(': ').map((str) => str.trim());
         acc[key] = value;
         return acc;
     }, {});
}


const [filters, setFilters] = useState(initFilters())

Таким же образом можно сохранять в localStorage и другие настройки UI: параметры сортировки, тему сайта, выбранные/скрытые колонки в какой-либо таблице тд

Мой хороший друг Саня написал пост про идиотские задачки, которые дают эйчары на скрининге.
Задачки и впрямь идиотские. Я работаю разработчиком больше восьми лет, решила тысячи задач и среди них не было ни одной, в которой бы черепашка влезала на столб. Тем не менее, моя точка зрения заключается в том, что на такие задачки можно реагировать двумя способами:

❌ Злиться на профнепригодность эйчаров и нанимающих менеджеров (непродуктивно)
✅ Просто решить эти задачки да и не париться из-за ерунды.

Ниже приведу решения двух задач из поста Сани.

Задача про черепаху и холм.

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

const dayDistance = 50;
const nightDistance = 30;

function getDays(distance) {
  if (distance <= dayDistance) {
    return 1;
  }

  let result = 1;
  let passed = dayDistance;

  while (passed < distance) {
    passed -= nightDistance;
    result++;
    passed += dayDistance;
  }

  return result;
}

Задача про рукопожатия.

Еще проще. Очевидно, что каждому новоприбывшему с номером n необходимо здороваться со всеми присутствующими, чье количество равно n-1. К этому мы прибавляем рукопожатия всех, кто уже был в комнате. Итого очевидно, что нам всего лишь нужно посчитать сумму арифметической последовательности (n-1) + (n-2) +…+ 1. Считаем по теореме Гаусса. Изи.

function calcHandshakes(n) {
  if (n < 2) {
    return 0;
  }

  const prevNumber = n - 1;

  return ((prevNumber + 1) * prevNumber) / 2;
}

Итого, решение первой задачи у меня заняло 2 минуты 40 секунд, второй - 36 секунд.
Короче, было бы из-за чего огорчаться и злиться на эйчаров. По-моему, предмет огорчения слишком незначительный, чтобы как-то всерьез игнорировать из-за этого вакансию.

P.S. В этом году надеюсь успеть сделать курс по алгоритмам на Stepik. Не изучала эту платформу, но курс будет либо бесплатный, если Stepik даст такое создать, либо по той стоимости, которую с меня запросит платформа - чтобы не работать себе в убыток. В курсе буду рассказывать про подход, которым можно пользоваться при решении задач + практические примеры. Stay tuned.

Как новичку дебажить? Часть 3. Разделяй и властвуй.

Допустим, вам в работу дали баг, который происходит по какому-то триггеру. Например, пользователь кликает по кнопке и после этого происходит что-то УЖАСНОЕ. Крашится приложение, седеет продукт менеджер, а на другом конце планеты начинает плакать маленький котенок. Как распутать эту детективную историю и вылечить несчастную кнопку?

1️⃣ Для начала необходимо сузить круг подозреваемых. Вы точно знаете, при клике на какую кнопку происходит катастрофа. Найдите ее в коде. Допустим, вы увидите что-то вроде-такого:

<ButtonWrapper>
    <MySuperButton onClick={handleClick}/>
</ButtonWrapper>

Главных подозреваемых два - MySuperButton и handleClick. Оба эти товарища могут делать с вашим приложением что-нибудь эдакое. Второстепенный подозреваемый - ButtonWrapper. Он тоже может вносить свою лепту, но его смотрим, если главные подозреваемые доказали свою непричастность.

2️⃣ Разделяй и властвуй. Необходимо по очереди изолировать подозреваемых и проверить независимо. Сначала проверяем MySuperButton. Для этого нам надо убрать handleClick, чтобы он не путал нам карты. Пишем:

<ButtonWrapper>
    <MySuperButton onClick={() => {}}/>
</ButtonWrapper>

Кликаем на кнопку. Теперь при клике будет вызываться не handleClick, а пустая функция. Если при этом баг продолжает воспроизводиться, значит, теперь проверяем MySuperButton. Убираем его из кода:

<ButtonWrapper>
    <button onClick={handleClick}>Just test</button>
</ButtonWrapper>

Кликаем на кнопку. Если в этом случае баг исчез, то виновник - MySuperButton.

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

3️⃣ На этом еще не все. Теперь идем в код MySuperButton и смотрим, что такого хитрого он делает. Допустим, мы видим внутри следующую конструкцию:

const onClick = () => {
    prepare();
    handleClick();
    finish();
}

return (
    <button onClick={onClick}>SuperButton</button>
)

handleClick мы уже проверили, с ним все ок. Наши подозреваемые - функции prepare и finish. Пользуемся уже известным нам методом “закомментируй подозреваемых по очереди”. Так мы снова сузим круг подозреваемых и будем разбираться с той функцией, которая портит нам жизнь. Таким образом, мы будем подбираться все ближе и ближе к источнику бага, каждый раз выясняя точно, какая строчка кода проблемная, и в конце концов сможем увидеть баг визуально.

#дебаг

FRONTEND ROADMAP

Этот пост будет актуален для тех, кто только начинает свою карьеру во фронтенде.

Очень много вопросов в личку с просьбами подсказать, где лучше всего изучать фронтенд и как понять, что уже можно начинать искать работу. В интернете очень много курсов и материалов на любой вкус и цвет - и, пожалуй, даже слишком много, новички теряются во всем этом многообразии. Я составила подробный роадмап по необходимым технологиям, необходимым для начинающего специалиста. На мой взгляд, это самый минимум, который необходим, чтобы начать работать. Ссылка: https://devmargooo.notion.site/1-Junior-1cda1781152280a493f0ffae70992f09.

В этом роадмапе есть платные (но очень дешевые - 590р/месяц) материалы, в которых, на мой взгляд, хорошо структурирована информация и ученики легко обучаются по этим материалам. Для тех, кто не хочет платить, я указала бесплатные аналоги (но в них информация структурирована и “разжевана” чуть хуже).

Кратно приведу список моих любимых ресурсов для новичков:

1️⃣ HTML и CSS: https://htmlacademy.ru/. Любимая школа обучения верстки, обычно я даю ссылку на нее своим ученикам и они пропадают на несколько недель, обучаясь самостоятельно и в целом не сталкиваясь ни с какими проблемами. Уровень усвоения материала - близкий к 100%. Платные материалы именно с этого ресурса я включила в свой роадмап, потому что незнание этих тем (и последующее разжевывание их вам ментором), на мой личный взгляд, обойдется вам гораздо дороже.

2️⃣ Javascript: https://learn.javascript.ru/. Абсолютно бесплатный учебник по javascript, который содержит ВСЕ необходимые для трудоустройства и дальнейшей работы темы.

3️⃣ Typescript: https://code-basics.com/ru/languages/typescript. Этот курс, на мой взгляд, лучший из бесплатных. На мой взгляд, он довольно бегло проходится по основным темам, многие из которых можно раскрыть еще на пару-тройку модулей в курсе. Но для новичка этот курс - то, что нужно! Здесь все самое основное и не перегружено подробностями. Для того, чтобы работать миддлом, информации здесь слишком мало :)

4️⃣ React: https://ru.hexlet.io/courses/js-react. Курс по подписке на хекслете, которая стоит 3900р/месяц. На мой взгляд, это вполне справедливая цена за хорошо разжеванный и структурированный материал :) Для тех, кто не хочет платить, есть бесплатные материалы в моем роадмапе - список всех нужных тем и ссылки.

5️⃣ Redux: https://code.mu/ru/javascript/framework/react/book/redux/. Это достаточно простая технология, ее вполне можно изучить по бесплатному материалу на code.mu. Ему не хватает интерактивности, но на мой взгляд, такую простую технологию можно изучить и без интерактивных заданий. Более интерактивный и разжеванный курс есть на хекслете за 3900/месяц: https://ru.hexlet.io/courses/js-redux-toolkit

P.S. Роадмап junior -> middle в разработке

#роадмап

Подборка лучших постов айти блогов за месяц

Я уже писала ранее, что состою в Клубе айти блоггеров, где мы обмениваемся опытом ведения айти блогов. В этот раз мы решили собрать свои лучшие посты за месяц. Мне больше всего понравились посты Артёма и Нади.

Пост Артёма зацепил меня позицией, близкой к моей - я не стремлюсь поймать work/life balance, я стремлюсь поймать shit/awesome balance :D и работа для меня чаще всего попадает в awesome. У Нади в посте интересный технический контент, мне вообще нравятся Next и Nuxt за то, что они позволяют делать интересные вещи. Делюсь всей подборкой:

🪲 У меня самый популярный контент за месяц - серия постов про дебаг: Как новичку дебажить? Часть 1.

👉 Гриша продолжает обозревать фичи Svelte. Публикация уже на канале.

🧠 Наташа помогает отслеживать баги в мышлении, она коуч ICF и QA-инженер: На чём, на самом деле, держится ваша мотивация?

💡 Тимлид Артём рассказал, как у него стёрлась грань между жизнью и работой.

🔥 Коуч Анна делится важностью проявления агрессии в карьере в голосовом.

🐱 Надя снова ломает границы фронтенда! Рассказывает, как настроить телеграм-бота для уведомлений с сайта без бэкенда.

🤵 Разработчик Саша думает о пользователях и рассказывает, как соблюдать UX-законы при разработке фронтенда.

🍔 Раушан ударился в кулинарию: тудушка бутера, алгоритм приготовления суши.

😡 Счастливый тимлид походу перегрелся и бомбит то на кандидатов, то на формы регистрации.

Первая годная статья про оценку задач, которую я встретила на просторах интернета. Метод выглядит как рабочий. Сама я пользуюсь схожим способом - оценку через разработку POC (буду писать об этом подробнее)

https://habr.com/ru/companies/ru_mts/articles/898644/

#оценказадач

Выводим многострочный текст

В javascript многострочный текст можно вывести при помощи шаблонных литералов (строка с косыми кавычками). Но есть лайфхак, который позволяет сделать то же самое другим путем: сделать массив строк, а затем объединить их в одну при помощи «\n»:

const arr = [‘one’, ‘two’, ‘three’];
const str = arr.join(‘\n’);

Это удобнее тем, что теперь к каждой строке можно применить map и как-нибудь преобразовать строки. Например, выполнить toUpperCase или заключить каждую строку в тег <b>. Это может быть полезно для создания кейсов в сторибуке.

Как новичку дебажить? Часть 3.

Выше (по хештегу #дебаг) я писала о том, что при дебаге нам нужно отследить путь данных. Хочу отдельно пояснить, что именно мы отслеживаем.

Любая программа представляет из себя совокупность данных, которые каким-то образом изменяются на протяжении своей “жизни” в программе. Проще говоря, результат преобразований можно представить как y = f(x), где х - входные данные, f - преобразующая функция, y - результат. На примере: допустим, у вас есть функция multipleByTwo, который умножает число на 2. Вы вводите 3 и получаете 8 (а должны были получить 6). В этом примере: y (результат) равен 8 и получен он был путем применения функции multipleByTwo к входным данным (то есть к числу 3).

Получаем:

multipleByTwo(x) = 8

Поскольку результат (восьмерка) является результатом воздействия функции multipleByTwo на x, то ошибка может быть в двух местах:

1. В самой функции (multipleByTwo)
2. Во входных данных (x)

В первом случае это означает, что алгоритм функции неверно написан (например, там какой-то код, отличный от return x * 2). Во втором случае это означает, что мы передали неверные данные (например, промазали по клавиатуре и случайно тыкнули 4 вместо 3).

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

<Select options={mapData(dataFromApi)} />

Таким образом, ошибка может быть в двух местах:

1. В функции, которая мапит данные (ошибка в алгоритме)
2. В данных, которые пришли с бекенда (например, запрос свалился и ничего не пришло)

Для дебага надо проверить оба этих случая.

В реальных фронтенд приложениях данные проходят большой путь от получения их с сервера до вывода на экран. Поэтому реальное уравнение - это не y = f(x), а y = foo(bar(someMethod(a, b, c), d), e). То есть получается довольно длинная цепочка преобразований от начала и до конца. Проследить путь данных - это по всей цепочке выяснить, какие данные (a, b, c, d, e) используются, корректные ли они, а также какие алгоритмы (foo, bar, someMethod) к ним применяются и найти ошибку в этой цепочке.

#дебаг

Накрутка опыта, инфляция и конкуренция

В последнее время на консультации приходит очень много миддлов с 3-4 годами опыта, которые месяцами не могут найти работу и не понимают, что с ними не так. Ребята, с вами все в порядке - проблема не в вас, а в той неадекватной ситуации, которая сложилась сейчас на рынке труда. Неадеватной эта ситуация стала потому, что за последние пару лет накрутка опыта приобрела массовый характер.

В среднем, накрутчики-фронтендеры крутят себе 3-4 года опыта. Ваши резюме попадают с ними в одну кучу и поэтому ваши шансы быть приглашенными на собеседование уменьшаются пропорционально количеству резюме с заявленными 3-4 годами опыта. При ближайшем рассмотрении оказывается, что ваши шансы быть приглашенными на собеседование даже ниже, чем у накрутчиков - их резюме выглядит привлекательнее, потому что придумать всегда можно более классные задачи и результаты, чем сделать и решить на самом деле. Я видела несколько сотен накрученных резюме и их большая часть поразила меня своими выдающимися достижениями. Мое резюме - специалиста с реальным опытом 8+ лет - содержит гораздо более скромный список достижений, чем придуманные достижения накрутчиков. В реальной жизни мы ограничены дедлайнами, необходимостью делать рутинные таски на благо бизнеса, а также ограничениями нашей системы, в то время как придуманные достижения не ограничены ничем, кроме полета фантазии. Суммарно эти два фактора: высокая конкуренция среди специалистов с заявленными опытом 3-4 года и бОльшая привлекательность накрученных резюме снижают ваши шансы попасть на собеседование практически до нуля.

Многие помнят, что популяризаторы накрутки опыта советовали крутить “годик”. Откуда же взялись 3-4 года опыта, спросите вы? Дело в том, что корень проблемы никогда не было в “автофильтрах”, как нам это утверждают популяризаторы накрутки. Корень проблемы всегда был и будет в высокой конкуренции. Пару лет назад высокая конкуренция была только среди джунов: в постковидные времена мы получили большое количество выпускников курсов, которые вышли на рынок, где для них не оказалось такого количества вакантных мест. Накрутка опыта помогала не “пройти автофильтры”, а попасть в ту часть воронки, где конкуренция была ниже - то есть на уровень специалистов с опытом от года. Но как только все массово стали крутить себе годик, то что произошло? Теперь конкуренция перешла на этот уровень. Стало слишком много специалистов с годом опыта работы. Чтобы выделиться среди них, приходилось крутить уже по два года, затем по три, и вот сейчас мы застряли на средней отметке в 4 года накрученного опыта. Так мы пришли к инфляции опыта: чем больше людей крутит себе N лет, тем большему количеству людей приходится крутить себе N+K лет, чтобы не оказаться в той куче, где конкуренция высока, и перейти на уровень, где конкуренции мало или почти нет. Инфляция опыта коснулась и работодателей: теперь эйчары просто смотрят резюме от 5 лет опыта, понимая, что из них реального опыта - пара лет. Чем больше накрутчиков на рынке и чем больше они крутят, тем хуже приходится каждому отдельному накрутчику.

Что же со всем с этим делать? Я хочу обратить ваше внимание на то, что реальной причиной сложности поиска работы всегда были не “автофильтры” (они лишь являются следствием большего количества кандидатов), а конкуренция. Годы опыта и достижения в резюме - основной, но не единственный способ победить в этой конкуренции. Вспомните про альтернативные джоб бордам методы, а именно: рефералки, личный бренд, нетворкинг, участие в хакатонах, выступления на митапах, интересные проекты на гитхабе и тд. Очень многие команды столкнулись с такой проблемой найма, как несоответствие кандидатов заявленным в резюме скиллам, что существенно затягивает процесс поиска работы. Личное знакомство с таким лидом, который ищет специалиста - это путевка на собеседование, минуя все автофильтры. Будьте заметными, вносите вклад в профессиональное сообщество, рекламируйте себя как специалиста - это существенно повышает ваши шансы быть замеченным и нанятым.

#поискработы

Владилен Минин в своем телеграмм канале опубликовал пост с ссылкой на вакансию стажера, в которой кандидату предлагают работать за… опыт и сертификат о прохождении стажировки. И пока в комментариях обсуждают звериный оскал капитализма и беспредельную наглость работодателей, я хочу обратить ваше внимание вот на что: бесплатные стажировки в том или ином виде существуют в большинстве профессий. Например, мастера маникюра после обучения делают маникюр бесплатно на моделях, парикмахеры - стригут бесплатно и тд. В телеграмме и Вконтакте существуют много групп, где можно записаться на бесплатный маникюр или стрижку к вот такому вот стажеру. Ваша покорная слуга является большой любительницей посещать бесплатные фотосессии у новичков-фотографов и потом выкладывать красивые фотографии в соцсети… впрочем, я отвлеклась. Стажировка (практическая работа над реальным или близком к реальному проектом) - это неизбежная часть любого обучения. Если вы программист - в вашей карьере так или иначе будет первый для вас проект, и именно на нем вы будете учиться работать. Для вас существует несколько вариантов:

1️⃣ Бесплатная стажировка в айти компании - похожая на ту, что в вакансии выше.

2️⃣ Стажировка на реальном проекте у ментора / на курсах. В этом варианте вам придется платить за то, что вам все объясняют и делают ревью вашего кода.

3️⃣Самостоятельная стажировка: сделать несколько проектов, залить их в гитхаб, опыт работы над ними подробно описать в резюме, приложив ссылки (к слову, именно этот вариант я и рекомендовала большинству новичков года 2-3 назад - до эпохи массовой накрутки)

4️⃣ Оплачивая стажировка от компании. Обычно стажеру платят 80-120к.

5️⃣ Устроиться на миддла (например, накрутив опыт) и дальше “стажироваться” за счет работодателя, набивая стажерские шишки и наступая на стажерские грабли за зарплату миддла.

Теперь, когда мы выяснили, что стажироваться (т.е. набивать шишки на первом в карьере проекте) так или иначе придется, я хочу привести несколько аргументов того, что первый вариант имеет ряд плюсов, которые делают его довольно привлекательным:

1️⃣ Вы качаете хард скиллы. Это очень важно, потому что у большинства новичков объективно не хватает хард скиллов. Хард скиллы вам нужны, чтобы: а) проходить собеседования без стресса и получать офферы б) успешно справляться с рабочими тасками, не сталкиваясь со стрессом, не перерабатывая. Чем выше хард скиллы, тем ниже стресс, который вы получаете от работы, тем больше работы вы можете сделать, тем больше вы можете заработать.

2️⃣ Вы качаете софт скиллы. Большинство новичков не умеет работать с традиционно принятыми в айти компаниях инструментами управления проектов (например, jira, confluence) и теряется, когда нужно “прогнать задачу по статусам”, а еще не знает, как правильно доносить свои мысли до коллег. Стажировка поможет вам научиться.

3️⃣ Вы можете работать неполный день. Это очень полезно, если у вы свитчер и переучиваетесь с другой профессии: тогда вы сможете плавно войти в новую для себя профессию, при этом сохраняя старую работу и свой привычный доход. Вы реально можете усидеть на двух стульях! В то же время, если вы выбираете вариант №5 (устроиться сразу на миддла с накруткой опыта), вы рискуете не потянуть, быть уволенным и остаться без дохода вообще - ведь с предыдущей неайтишной работы вы уже уволились. Также вариант с неполным рабочим днем идеально подходит для студентов. (продолжение в следующем посте)

(начало в предыдущем посте) Я сама на старте своей карьеры проходила бесплатные курсы-стажировку Focus Start от компании ЦФТ - и там меня научили всему, что мне потребовалось на старте: верстке, написанию кода на js, работе с фреймворком (первый ангуляр… как давно это было). После этой стажировки я очень легко смогла найти работу, потому что у меня были соответствующие хард и софт скиллы, я понимала, как работают процессы в айти компаниях, и понимала, как делать реальные проекты. Поэтому я в большинстве случаев положительно отношусь к бесплатным стажировкам - при условии, что на них действительно учат, а не сгружают на стажера тупую работу типа “поменять строку в коде”. Если вы попали на стажировку и вы чувствуете, что ничему там не учитесь - уходите немедленно.

Почему я не боюсь, что если люди будут соглашаться на бесплатную стажировку, то работодатели воспримут это как то, что теперь можно не платить программистам? Потому что бесплатная стажировка актуально только для тех, кто прошел обучение, но у кого пока нет практического опыта работы с реальным проектом. Если у человека есть опыт работы с реальным проектом хотя бы 2-3 месяца, бесплатная стажировка для него неактуальна от слова совсем. Бесплатными стажерами потребности бизнеса не закроешь, поэтому для программистов, которые желают быть оплаченными, найдется много работы 😊

И последнее. Играет ли какую-нибудь роль сертификат? Конечно нет 😊 Такой сертификат не является документом государственного образца, чтобы значить хоть что-то. Впрочем, в айти и на дипломы ВУЗов обращают не так много внимания - главное скиллы кандидата. Поэтому, если решите пойти на стажировку, внимательно рефлексируйте, действительно ли вы закрываете ваши потребности в том, чтобы попрактиковаться на реальном боевом проекте и отточить свои навыки? Если нет - смело уходите с такой стажировки.

✨ На грядущем PiterJS для вас выступит Маргарита Лукина с докладом:

Эволюция SSR в React приложениях

Появление серверных компонентов внесло путаницу в React сообществе.
🔸Чем серверные компоненты отличаются от клиентских?
🔸В чем преимущества тех и других?
🔸Как они работают под капотом?
Доклад ответит на этот и другие вопросы

Важно! На территорию университета можно пройти только при подтверждении личности! Регистрируйтесь под своим именем и фамилией и возьмите на мероприятие паспорт! 🔥

✨ Регистрируйтесь под своим именем и фамилией, если допустили ошибку => отмените регистрацию и сделайте корректную.

До встречи 😊

Композитная структура фронтенд проекта

Многие мои знакомые в курсе, что я недолюбливаю FSD. В целом, мне не импонируют любые достаточно плоские методологии структурирования проектов - как раз из-за своей плоскости. “Плоским” я называю структуру, в которой у нас существуют директории, предполагающие наличие большого количества содержимого. Например, папочка components, в которой может быть 100 и более компонентов. В таком количестве очень сложно найти то, что тебе нужно. Сегодня поделюсь рецептом структуры, которой пользуюсь я сама. Дисклеймер: возможно, он уже был где-то и кем-то описан - но я про это не в курсе 😊 Я называю такую структуру композитной, потому что она напоминает мне паттерн “компоновщик” (Composite). Итак:

1️⃣ На верхнем уровне я располагаю основные директории - app (главный файл, конфиги приложения), pages (страницы), components (компоненты), helpers (хелперы), store (стор). Важно: в components мы кладем не любые компоненты, а только глобальные - то есть такие, которые используются повсюду в нашем приложении. Аналогично используем хелперы и стор - только для глобальных сущностей.

2️⃣ В pages создаем страницы.

3️⃣ В страницах повторяем верхнюю структуру: components, helpers, store. Сразу уточню, что папочки добавляем по мере создания файликов - пустые папки нам не нужны :) Но на этом уровне кладем сюда только те компоненты/хелперы/стор, которые используются на этой странице. То есть в pages/Home/components может лежать, например, компонент Hero - если он используется на главной странице и больше нигде.

4️⃣ Внутри компонентов структура может снова повторяться: например, компонент Hero может содержать дочерние компоненты, а также может содержать хелперы.

5️⃣ Для каждой страницы действуем по аналогичному принципу.

Таким образом, общий принцип: кладем сущность туда, где она непосредственно используется. Если сущность используется в нескольких местах, кладем на общий уровень для мест использования. На примере компонентов:

🔵 Компонент Card используется только на странице Catalog - кладем компонент в src/pages/Catalog/components/Card

🔵 Компонент CardHeader используется только внутри компонента Card - кладем компонент в src/pages/Catalog/components/Card/components/CardHeader

🔵 Компонент Button используется везде - кладем в src/components.

#архитектура