Привет! Меня зовут Алексей, мне 27 лет и вот уже 5 лет я работаю в IT. За это время мне удалось из trainee в ноу нейм компании вырасти до Lead frontend engineer в топ 3 аэропортов по пунктуальности перевозок во всем мире "Международный аэропорт Шереметьево" ✈️, а перед этим успел еще и поработать годик в Черногории на американском IT гиганте в области изучения психологии "Twill"🚑. В этом посте ты узнаешь, чем я тебе могу быть полезен и почему тебе стоит остаться на этом канале.
За весь свой опыт я сформировал 3 главных принципа, как быть успешным в своей работе, которые позволяют мне эффективно повышать свой грейд, регулярно получать офферы от сторонних компаний и повышать уровень своей заработной платы:
1️⃣ Будь всегда на шаг впереди, изучай best practices, новые технологии и паттерны проектирования;
2️⃣ Объясняй просто, без излишней терминологии и воды;
3️⃣ Пиши масштабируемо и расширяемо.
💪Если ты хочешь стать востребованным специалистом, тратить минимум времени на работу и закрывать таски быстро и своевременно, а свободное время тратить на отдых и путешествия, то ты попал по адресу. В этом канале я буду делиться всеми самыми полезными секретами, лайфхаками из мира фронтенд разработки, чтобы сделать твою работу на порядок эффективнее.
Этот канал поможет тебе, если:
1️⃣ Ты хочешь войти в IT и сделать это максимально быстро и без лишних трудозатрат;
2️⃣ Тебе надоело быть одним из 800-900 кандидатов на позицию фронта, ты хочешь выделиться из серой массы;
3️⃣ У тебя не получается пройти дальше технического собеседования;
4️⃣ Ты хочешь попасть в какой-нибудь бигтех (Яндекс, Тинькофф, Сбер), но у тебя не получается.
За свою работу я успел:
1️⃣ Довести более 10-ти учеников от нуля до трудоустройства на позицию junior+ - middle;
2️⃣ Провести более 70 менторинг-консультаций для людей, которые хотели поднять свой грейд или поменять работу;
3️⃣ Суммарно увеличить оклад своих менти на более чем миллион рублей в месяц.
И зачем я это начал? - спросите вы меня. А все очень просто, я искренне хочу создать свою комьюнити, которое поможет начинающим программистам не свернуть с пути, добиваться своей цели и добиться первоклассных результатов в области Frontend разработки.
Приятно познакомиться, меня зовут Алексей Пудов и погнали!
За весь свой опыт я сформировал 3 главных принципа, как быть успешным в своей работе, которые позволяют мне эффективно повышать свой грейд, регулярно получать офферы от сторонних компаний и повышать уровень своей заработной платы:
1️⃣ Будь всегда на шаг впереди, изучай best practices, новые технологии и паттерны проектирования;
2️⃣ Объясняй просто, без излишней терминологии и воды;
3️⃣ Пиши масштабируемо и расширяемо.
💪Если ты хочешь стать востребованным специалистом, тратить минимум времени на работу и закрывать таски быстро и своевременно, а свободное время тратить на отдых и путешествия, то ты попал по адресу. В этом канале я буду делиться всеми самыми полезными секретами, лайфхаками из мира фронтенд разработки, чтобы сделать твою работу на порядок эффективнее.
Этот канал поможет тебе, если:
1️⃣ Ты хочешь войти в IT и сделать это максимально быстро и без лишних трудозатрат;
2️⃣ Тебе надоело быть одним из 800-900 кандидатов на позицию фронта, ты хочешь выделиться из серой массы;
3️⃣ У тебя не получается пройти дальше технического собеседования;
4️⃣ Ты хочешь попасть в какой-нибудь бигтех (Яндекс, Тинькофф, Сбер), но у тебя не получается.
За свою работу я успел:
1️⃣ Довести более 10-ти учеников от нуля до трудоустройства на позицию junior+ - middle;
2️⃣ Провести более 70 менторинг-консультаций для людей, которые хотели поднять свой грейд или поменять работу;
3️⃣ Суммарно увеличить оклад своих менти на более чем миллион рублей в месяц.
И зачем я это начал? - спросите вы меня. А все очень просто, я искренне хочу создать свою комьюнити, которое поможет начинающим программистам не свернуть с пути, добиваться своей цели и добиться первоклассных результатов в области Frontend разработки.
Приятно познакомиться, меня зовут Алексей Пудов и погнали!
React Вкатуны pinned «Привет! Меня зовут Алексей, мне 27 лет и вот уже 5 лет я работаю в IT. За это время мне удалось из trainee в ноу нейм компании вырасти до Lead frontend engineer в топ 3 аэропортов по пунктуальности перевозок во всем мире "Международный аэропорт Шереметьево"…»
Поговорим о процессе оптимизации react компонентов.
Давайте обсудим процесс оптимизации компонентов React. Глобально, этот процесс можно разделить на 6 последовательных шагов:
1️⃣: Использование Базовых Хуков Мемоизации
2️⃣: Декомпозиция Компонентов
3️⃣: Контроль за Props Drilling
4️⃣: Использование Data Mappers
5️⃣: Использование Виртуальных Списков
6️⃣: Использование Time Slicing
Но обо всем по порядку:
1. Хуки React: Одним из самых простых способов оптимизировать компонент в React является использование базовых хуков для мемоизации. В частности, их три:
useMemo - мемоизирует значение.
useCallback - мемоизирует функцию.
React.memo (Higher-Order Component) - мемоизирует компонент.
Этот инструмент действительно хорош и его хватает для 90% всех оптимизаций. Однако важно помнить, что мемоизация не является панацеей. Она не бесплатна и в некоторых случаях может дать обратный эффект. А когда ее использовать?
✅Если у нас есть какое-либо сложное вычисление, которое мы хотим выполнить только один раз при отрисовке компонента.
✅Если у нас есть компонент, в который передаются нечасто изменяющиеся пропсы или их вообще нет.
✅Если у нас нет сильно зависимых и сложно связанных структур. Если такие структуры имеются, стоит подумать о Data Mappers, о которых пойдет речь ниже.
Во многих случаях можно обойтись и вовсе без мемоизации, вынося вычисления за пределы компонента или сохранять результат в state. Для более подробной информации рекомендую ознакомиться с отличной статьей Марка Ериксона Blogged Answers: A (Mostly) Complete Guide to React Rendering Behavior
2. Props Drilling: передача пропсов через цепочку компонентов. Но чем это чревато?
По умолчанию, React проходит по цепочке вниз от компонента, инициировавшего рендер, и обновляет все дочерние (вложенные) компоненты. Конечно, мы можем использовать React.memo, но что насчет памяти? Память будет страдать, и если пользователь решит отлучиться на чашечку чая, то, вернувшись, обнаружит, что браузер съел всю память, а вкладка пала смертью храбрых. Таким образом, Props Drilling не только усложняет код, но и влияет на производительность, а значит с ним нужно как-то бороться. Но как?
✅ Использование Контекстов;
✅ Использование Стейт-менеджера;
✅ Использование стейт там, где это действительно необходимо: В некоторых ситуациях можно обойтись и вовсе uncontrolled компонентами, не передавая зависимости напрямую, например, в случае с формами нам не обязательно знать какое состояние формы до отправки компонента на сервер, но для этого есть onSubmit.
3. Декомпозиция кода: В отличие от Solid.js, рендеринг в React является компонентным. Это означает, что при изменении состояния внутри компонента будет перерендерен весь компонент, включая все дочерние узлы (если они не обернуты в React.memo). Хорошая новость в том, что повторный рендер не всегда плохо, благодаря Fiber и Virtual DOM мы не рендерим заново DOM-дерево. Однако, все же вычислительные мощности тратятся на сравнение DOM и Virtual DOM.
Лично я для себя вывел правило: не создавать компонентов длиной свыше 200 строк. Но также не стоит мельчить, так как execution context никто не отменял, и вычислительные мощности тратятся на создание области видимости компонента и отслеживание рендеринга этого компонента. Золотая середина в 200 строк может существенно улучшить ситуацию.
По умолчанию, React использует поверхностное сравнение при сравнении DOM-дерева. Это означает, что если внутрь пропса передается объект или массив, изменивший лишь часть свойств, мы все равно перерендерим все полностью. Можно воспользоваться Mobx или любым другим стейт-менеджером, реализующим глубокое сравнение при мемоизации, но если мы захотим перейти на другое решение, нам придется полностью реорганизовывать код.
Давайте обсудим процесс оптимизации компонентов React. Глобально, этот процесс можно разделить на 6 последовательных шагов:
1️⃣: Использование Базовых Хуков Мемоизации
2️⃣: Декомпозиция Компонентов
3️⃣: Контроль за Props Drilling
4️⃣: Использование Data Mappers
5️⃣: Использование Виртуальных Списков
6️⃣: Использование Time Slicing
Но обо всем по порядку:
1. Хуки React: Одним из самых простых способов оптимизировать компонент в React является использование базовых хуков для мемоизации. В частности, их три:
useMemo - мемоизирует значение.
useCallback - мемоизирует функцию.
React.memo (Higher-Order Component) - мемоизирует компонент.
Этот инструмент действительно хорош и его хватает для 90% всех оптимизаций. Однако важно помнить, что мемоизация не является панацеей. Она не бесплатна и в некоторых случаях может дать обратный эффект. А когда ее использовать?
✅Если у нас есть какое-либо сложное вычисление, которое мы хотим выполнить только один раз при отрисовке компонента.
✅Если у нас есть компонент, в который передаются нечасто изменяющиеся пропсы или их вообще нет.
✅Если у нас нет сильно зависимых и сложно связанных структур. Если такие структуры имеются, стоит подумать о Data Mappers, о которых пойдет речь ниже.
Во многих случаях можно обойтись и вовсе без мемоизации, вынося вычисления за пределы компонента или сохранять результат в state. Для более подробной информации рекомендую ознакомиться с отличной статьей Марка Ериксона Blogged Answers: A (Mostly) Complete Guide to React Rendering Behavior
2. Props Drilling: передача пропсов через цепочку компонентов. Но чем это чревато?
По умолчанию, React проходит по цепочке вниз от компонента, инициировавшего рендер, и обновляет все дочерние (вложенные) компоненты. Конечно, мы можем использовать React.memo, но что насчет памяти? Память будет страдать, и если пользователь решит отлучиться на чашечку чая, то, вернувшись, обнаружит, что браузер съел всю память, а вкладка пала смертью храбрых. Таким образом, Props Drilling не только усложняет код, но и влияет на производительность, а значит с ним нужно как-то бороться. Но как?
✅ Использование Контекстов;
✅ Использование Стейт-менеджера;
✅ Использование стейт там, где это действительно необходимо: В некоторых ситуациях можно обойтись и вовсе uncontrolled компонентами, не передавая зависимости напрямую, например, в случае с формами нам не обязательно знать какое состояние формы до отправки компонента на сервер, но для этого есть onSubmit.
3. Декомпозиция кода: В отличие от Solid.js, рендеринг в React является компонентным. Это означает, что при изменении состояния внутри компонента будет перерендерен весь компонент, включая все дочерние узлы (если они не обернуты в React.memo). Хорошая новость в том, что повторный рендер не всегда плохо, благодаря Fiber и Virtual DOM мы не рендерим заново DOM-дерево. Однако, все же вычислительные мощности тратятся на сравнение DOM и Virtual DOM.
Лично я для себя вывел правило: не создавать компонентов длиной свыше 200 строк. Но также не стоит мельчить, так как execution context никто не отменял, и вычислительные мощности тратятся на создание области видимости компонента и отслеживание рендеринга этого компонента. Золотая середина в 200 строк может существенно улучшить ситуацию.
По умолчанию, React использует поверхностное сравнение при сравнении DOM-дерева. Это означает, что если внутрь пропса передается объект или массив, изменивший лишь часть свойств, мы все равно перерендерим все полностью. Можно воспользоваться Mobx или любым другим стейт-менеджером, реализующим глубокое сравнение при мемоизации, но если мы захотим перейти на другое решение, нам придется полностью реорганизовывать код.
Решение простое: не использовать в React сложные структуры данных и разделять их на простые. Например, массив объектов можно разбить на простой массив из идентификаторов, а значения держать в словаре.
Например структура
[
{ id: '1', name: "Alex" },
{ id: '2', name: "Tomas" }
]
Легким движением руки превращается в:
const ids = [1, 2];
const dictIds = {
1: { name: 'Alex' },
2: { name: 'Tomas' }
};
Сразу disclaimer, в контексте данного примера, делать такую штуку будет overhead, такая декомпозиция подходит если у нас есть большое количество данных и высокая степень связанности.
5. Использование виртуальных списков в React: может существенно спасти ситуацию, когда дело касается рендеринга больших списков. К счастью, изобретать свой велосипед в этом плане не нужно, так как у нас есть множество доступных инструментов как конфигурируемых, так и неконфигурируемых, например
React Virtuoso
react-virtualized
react-virtua
Если у вас есть большое желание и энтузиазм, вы можете реализовать и свой виртуальный список. Однако, я умоляю вас не пытаться сделать это на production проектах. Не факт, что ваше решение будет работать эффективнее, а затраченное время может быть существенным, начиная с выбора подходящего инструмента (requestAnimationFrame, Intersection Observer или комбинация onScroll с функцией throttle), заканчивая правильной обработкой DOM элементов и настройкой перекрестных значений. Если вы все же решитесь на это приключение, вот вам полезная статья, которая помогла мне.
Ну и последнее, что мы рассмотрим, — это механизмы таймслайсинга. В целом, идея очень проста. У нас все еще есть наш любимый event loop, и рано или поздно мы можем столкнуться с его переполнением по самым разным причинам. Но посчитать то нам надо, и что же делать?
Самым логичным решением было бы спихнуть эту ответственность на бэк, но что если мы говорим о вычислениях по отрисовке чего-либо? Тут уже проблема, придется решать это на фронте. Но как? Все просто, мы можем не скопом решать поставленную задачу, а делать это отложенно, по кусочкам или вообще распределить эту задачу между очередью макро и микро задач. И тут в бой у нас вступают две функции: throttle и debounce.
Разница между ними в следующем:
Debounce - это функция, которая откладывает вызов другой функции (f) на заданное время (ms миллисекунд), если она не была вызвана в течение этого времени. Если функция (f) вызывается снова, таймер сбрасывается, и откладывание начинается заново. В результате, debounce гарантирует, что функция (f) будет вызвана только один раз после последнего вызова, даже если она была вызвана несколько раз в течение короткого промежутка времени. Debounce полезен, когда мы хотим, чтобы функция (f) вызывалась после того, как пользователь закончил вводить данные или выполнил какое-либо действие.
Throttle - это функция, которая ограничивает частоту вызова другой функции (f) не чаще чем раз в заданное время (ms миллисекунд). Если функция (f) вызывается чаще, чем раз в заданное время, она будет откладываться до тех пор, пока не истечет это время. В результате, throttle гарантирует, что функция (f) будет вызываться не чаще, чем раз в заданное время, независимо от частоты вызовов. Throttle полезен, когда мы хотим ограничить частоту вызова функции (f), чтобы предотвратить перегрузку системы или обеспечить плавную работу интерфейса.
Таким образом, механизмы таймслайсинга, такие как debounce и throttle, помогают нам управлять временем выполнения задач и оптимизировать производительность в веб-разработке. Правильное использование этих функций может существенно повлиять на качество и производительность веб-приложений.
Например структура
[
{ id: '1', name: "Alex" },
{ id: '2', name: "Tomas" }
]
Легким движением руки превращается в:
const ids = [1, 2];
const dictIds = {
1: { name: 'Alex' },
2: { name: 'Tomas' }
};
Сразу disclaimer, в контексте данного примера, делать такую штуку будет overhead, такая декомпозиция подходит если у нас есть большое количество данных и высокая степень связанности.
5. Использование виртуальных списков в React: может существенно спасти ситуацию, когда дело касается рендеринга больших списков. К счастью, изобретать свой велосипед в этом плане не нужно, так как у нас есть множество доступных инструментов как конфигурируемых, так и неконфигурируемых, например
React Virtuoso
react-virtualized
react-virtua
Если у вас есть большое желание и энтузиазм, вы можете реализовать и свой виртуальный список. Однако, я умоляю вас не пытаться сделать это на production проектах. Не факт, что ваше решение будет работать эффективнее, а затраченное время может быть существенным, начиная с выбора подходящего инструмента (requestAnimationFrame, Intersection Observer или комбинация onScroll с функцией throttle), заканчивая правильной обработкой DOM элементов и настройкой перекрестных значений. Если вы все же решитесь на это приключение, вот вам полезная статья, которая помогла мне.
Ну и последнее, что мы рассмотрим, — это механизмы таймслайсинга. В целом, идея очень проста. У нас все еще есть наш любимый event loop, и рано или поздно мы можем столкнуться с его переполнением по самым разным причинам. Но посчитать то нам надо, и что же делать?
Самым логичным решением было бы спихнуть эту ответственность на бэк, но что если мы говорим о вычислениях по отрисовке чего-либо? Тут уже проблема, придется решать это на фронте. Но как? Все просто, мы можем не скопом решать поставленную задачу, а делать это отложенно, по кусочкам или вообще распределить эту задачу между очередью макро и микро задач. И тут в бой у нас вступают две функции: throttle и debounce.
Разница между ними в следующем:
Debounce - это функция, которая откладывает вызов другой функции (f) на заданное время (ms миллисекунд), если она не была вызвана в течение этого времени. Если функция (f) вызывается снова, таймер сбрасывается, и откладывание начинается заново. В результате, debounce гарантирует, что функция (f) будет вызвана только один раз после последнего вызова, даже если она была вызвана несколько раз в течение короткого промежутка времени. Debounce полезен, когда мы хотим, чтобы функция (f) вызывалась после того, как пользователь закончил вводить данные или выполнил какое-либо действие.
Throttle - это функция, которая ограничивает частоту вызова другой функции (f) не чаще чем раз в заданное время (ms миллисекунд). Если функция (f) вызывается чаще, чем раз в заданное время, она будет откладываться до тех пор, пока не истечет это время. В результате, throttle гарантирует, что функция (f) будет вызываться не чаще, чем раз в заданное время, независимо от частоты вызовов. Throttle полезен, когда мы хотим ограничить частоту вызова функции (f), чтобы предотвратить перегрузку системы или обеспечить плавную работу интерфейса.
Таким образом, механизмы таймслайсинга, такие как debounce и throttle, помогают нам управлять временем выполнения задач и оптимизировать производительность в веб-разработке. Правильное использование этих функций может существенно повлиять на качество и производительность веб-приложений.
Mark's Dev Blog
Blogged Answers: A (Mostly) Complete Guide to React Rendering Behavior
Details on how React rendering behaves, and how use of Context and React-Redux affect rendering
Вкатуны, какие бы посты вы хотели видеть на этом канале?
Anonymous Poll
8%
Познавательные про IT
8%
Карьерные
25%
Полезные про Frontend разработку
8%
Идеи для pet проекта
50%
Все везде и сразу
Пишем резюме по STAR. Звезд с неба не хватает? Да, все очень просто: STAR✨ - это аббревиатура и способ сделать свое резюме респектабельнее и не упустить ничего важного.
STAR расшифровывается так:
S - SITUATION (Ситуация)
T - TASK (Задача)
A - ACTION (Действие)
R - RESULT (Результат)
Суть данного подхода в том, чтобы показать своему потенциальному работодателю, что вы не боитесь трудностей и готовы брать на себя ответственность за результат. А самое главное - довести начатое до конца. Для этого нам собственно и нужен этот сценарий под названием STAR.
Давайте разберем каждый из пунктов более детально:
✅ Ситуация - этот раздел вашего резюме должен содержать какую-то проблему, бизнес-потребность, боль бизнеса, если хотите, которую вы как специалист высшего пилотажа можете закрыть.
✅ Задача - здесь важно показать, что вы, как настоящий профи, можете не просто решить задачу, а разложить ее по полочкам, декомпозировать и спланировать решение данной проблемы. Иными словами, сформировать план по решению бизнес-задачи. В свою очередь, план должен содержать три основных атрибута:
1️⃣ План должен иметь свой deadline. Не бойтесь оперировать цифрами, даже если они примерные. Рекрутеры очень любят разного рода аналитику, и если вы справились с фичей за неделю вместо положенных трех - это обязательно необходимо описать в резюме.
2️⃣ Необходимо сформировать финальное видение того, что должно получиться в итоге. Не всегда удается этого сделать, ведь бизнес-требования могут меняться хоть каждый день. По этой причине важно описать, как вы с этим справлялись.
3️⃣ Декомпозиция. Не всегда задача от бизнеса приходит достаточно декомпозированной со стороны бизнеса, и нам необходимо быть готовыми вовремя скоординироваться, спланировать ресурсы и декомпозировать разработку фичи внутри команды.
✅ Действие - вот мы спланировались, рассчитали, какое количество времени нам требуется для выполнения данной задачи, и даже декомпозировали задачи между командой. А что дальше? Дальше нам необходимо описать для работодателя, как именно мы решали поставленную задачу. Какие инструменты мы для этого использовали, что пошло не так в процессе, и какие экстренные решения мы принимали, чтобы не выбиться из плана. И, конечно, не забываем про цифры, цифры и еще раз цифры.
✅ Результат - самый важный этап нашего резюме - это результат нашей работы, чего мы добились и что от этого выиграл бизнес. Если у вас есть действительная статистика выхлопа от вашей фичи, обязательно приложите ее. Показатели прироста производительности, конверсия траффика или уменьшение TTM (time to market) для последующей разработки.
Вывод:
Использование STAR в резюме поможет вам сделать его более эффективным и привлекательным для потенциальных работодателей. Описав ситуацию, задачу, действия и результат, вы покажете, что вы действительно способны решать проблемы, достигать целей и не боитесь ответственности.
STAR расшифровывается так:
S - SITUATION (Ситуация)
T - TASK (Задача)
A - ACTION (Действие)
R - RESULT (Результат)
Суть данного подхода в том, чтобы показать своему потенциальному работодателю, что вы не боитесь трудностей и готовы брать на себя ответственность за результат. А самое главное - довести начатое до конца. Для этого нам собственно и нужен этот сценарий под названием STAR.
Давайте разберем каждый из пунктов более детально:
✅ Ситуация - этот раздел вашего резюме должен содержать какую-то проблему, бизнес-потребность, боль бизнеса, если хотите, которую вы как специалист высшего пилотажа можете закрыть.
✅ Задача - здесь важно показать, что вы, как настоящий профи, можете не просто решить задачу, а разложить ее по полочкам, декомпозировать и спланировать решение данной проблемы. Иными словами, сформировать план по решению бизнес-задачи. В свою очередь, план должен содержать три основных атрибута:
1️⃣ План должен иметь свой deadline. Не бойтесь оперировать цифрами, даже если они примерные. Рекрутеры очень любят разного рода аналитику, и если вы справились с фичей за неделю вместо положенных трех - это обязательно необходимо описать в резюме.
2️⃣ Необходимо сформировать финальное видение того, что должно получиться в итоге. Не всегда удается этого сделать, ведь бизнес-требования могут меняться хоть каждый день. По этой причине важно описать, как вы с этим справлялись.
3️⃣ Декомпозиция. Не всегда задача от бизнеса приходит достаточно декомпозированной со стороны бизнеса, и нам необходимо быть готовыми вовремя скоординироваться, спланировать ресурсы и декомпозировать разработку фичи внутри команды.
✅ Действие - вот мы спланировались, рассчитали, какое количество времени нам требуется для выполнения данной задачи, и даже декомпозировали задачи между командой. А что дальше? Дальше нам необходимо описать для работодателя, как именно мы решали поставленную задачу. Какие инструменты мы для этого использовали, что пошло не так в процессе, и какие экстренные решения мы принимали, чтобы не выбиться из плана. И, конечно, не забываем про цифры, цифры и еще раз цифры.
✅ Результат - самый важный этап нашего резюме - это результат нашей работы, чего мы добились и что от этого выиграл бизнес. Если у вас есть действительная статистика выхлопа от вашей фичи, обязательно приложите ее. Показатели прироста производительности, конверсия траффика или уменьшение TTM (time to market) для последующей разработки.
Вывод:
Использование STAR в резюме поможет вам сделать его более эффективным и привлекательным для потенциальных работодателей. Описав ситуацию, задачу, действия и результат, вы покажете, что вы действительно способны решать проблемы, достигать целей и не боитесь ответственности.
Please open Telegram to view this post
VIEW IN TELEGRAM
Никогда такого не было и вот опять. Вчера, находясь в метро, я прочитал 😰 шокирующую новость: рынок IT якобы "сдулся", программисты испытывают трудности с поиском работы, а компании масштабно сокращают персонал.
🤔 Мой интерес был возбужден, и даже появилось некоторое волнение, но затем я успокоился, вспомнив о своих многочисленных задачах на работе и планах компании на будущее. В целом, подобные сообщения появляются с завидной регулярностью, примерно раз в полгода. Но мой пытливый ум захотел узнать, в чем же на самом деле дело.
👨💻 Исследуя статью, я не обнаружил ничего нового. Оказывается, коварный chatGPT и горстка nocode решений якобы пытаются отобрать у нас рабочие места, отправляя всех junior и middle специалистов на улицу. Решив разобраться во всем этом, я взялся за собственное расследование, чтобы раскрыть правду.
😅 Что меня больше всего позабавило, так это то, что так называемые эксперты, восхваляющие ИИ, не совсем понимают, какие именно задачи решает программист. Они почему-то думают, что мы сидим и решаем алгоритмические задачки уровня "fizzBuzz" или пытаемся отсортировать четные числа в массиве (Поставьте лайк, если вспомнили про задачи на собеседовании).
🧑🔬Но реальный мир не так идеален, как хотелось бы. Часто задачи прилетают без достаточной проработки, в них есть неразрешимые коллизии, противоречия или банальные ошибки (человеческий фактор). В этом случае, ИИ либо выдаст бредовое решение, либо воспользуется своей любимой фразочкой: "Ой, извините за предыдущий ответ...". Настоящая же ценность программиста заключается в его способности организовать процесс разработки, найти узкие места программы и превратить их в сильные, существенно сократив ttm (time to market) разработки новой фичи, увеличив performance приложения и сделав код более декларативным и описательным. Вряд ли chatGPT справится с этой задачей когда-либо, и если даже справится, то добро пожаловать в Skynet.
✨ А что же происходит в реальности по цифрам? В 2019 году из-за пандемии произошел настоящий бум в области информационных технологий. Согласно данным Bureau of Labor Statistics (BLS), количество рабочих мест в области IT в США увеличилось на 18% с 2019 по 2024 год, что превышает средние показатели по всем отраслям. В 2019 году на отрасль насчитывалось 4,4 млн рабочих мест, а уже к началу 2024 года их количество достигло 5,2 млн. Среди самых востребованных отраслей оказались: кибербезопасность, разработка программного обеспечения, облачные технологии и аналитика данных со среднегодовым показателем роста рабочих мест в 30-40% в год. Кибербезопасность выросла на 35% (с 350 тыс. до 475 тыс. рабочих мест), разработка программного обеспечения - на 32% (с 1,2 млн до 1,6 млн рабочих мест). Согласно отчету CompTIA, в 2022 году 70% компаний испытывали нехватку квалифицированных IT-специалистов, что привело к увеличению зарплат и предложений по найму.
🤔 Что же нам с этим делать? Безусловно, рано или поздно chatGPT научится писать код в достаточной мере качественно и организованно. Поэтому нам, как разработчикам, никогда не стоит останавливаться в развитии. Нам нужно развивать как hard, так и soft скилы, смотреть широко и не бояться выходить за пределы своего профиля или стека технологий, развивать навыки первоклассного инженера и менеджера. А что нам останется после того, как chatGPT научится писать код в достаточной мере качественно и понятно? Да, мы будем выстраивать для него приоритетность, последовательность и детализированность задач, разрабатывать архитектуру приложения, выявлять коллизии между фичами и описывать сценарии поведения приложения, а также транслировать потребности бизнеса ИИ, чтобы он правильно их интерпретировал.
Итог: даже если до полного исчезновения айтишников все еще очень далеко, расслабляться точно не стоит: придется постоянно приспосабливаться под новые запросы работодателей, которые давно ищут дешевую альтернативу даже самым дорогим сотрудникам. Хорошая новость заключается в том что если вы горите своим делом, готовы много учиться и брать на себя ответственность, заменить вас будет ох как непросто.
🧑🔬Но реальный мир не так идеален, как хотелось бы. Часто задачи прилетают без достаточной проработки, в них есть неразрешимые коллизии, противоречия или банальные ошибки (человеческий фактор). В этом случае, ИИ либо выдаст бредовое решение, либо воспользуется своей любимой фразочкой: "Ой, извините за предыдущий ответ...". Настоящая же ценность программиста заключается в его способности организовать процесс разработки, найти узкие места программы и превратить их в сильные, существенно сократив ttm (time to market) разработки новой фичи, увеличив performance приложения и сделав код более декларативным и описательным. Вряд ли chatGPT справится с этой задачей когда-либо, и если даже справится, то добро пожаловать в Skynet.
Итог: даже если до полного исчезновения айтишников все еще очень далеко, расслабляться точно не стоит: придется постоянно приспосабливаться под новые запросы работодателей, которые давно ищут дешевую альтернативу даже самым дорогим сотрудникам. Хорошая новость заключается в том что если вы горите своим делом, готовы много учиться и брать на себя ответственность, заменить вас будет ох как непросто.
Please open Telegram to view this post
VIEW IN TELEGRAM
REACT 19 близко Pt 1. "Миша, все херня, давай по новой" Грядет масштабное обновление React 19 что оно принесет, что поменяется и как не поплыть кукухой. На эти вопросы постараемя сегодня ответить.
⚒️SSR, не путать с SSSR:
Возможно самое масштабное изменение коснется именно введения в React нового SSR (Server Site Rendering) режима. Неужто разработчики React решили подвинуть сам Vercel вместе с их хваленым Next.js? В React 19 мы действительно получим SSR, включая улучшенную поддержку потокового рендеринга и оптимизацию производительности. Однако это не означает, что React 19 сможет полностью заменить Next.js. Основная причина заключается в том, что Next.js — это не просто обертка вокруг React, а полноценный фреймворк, который предлагает множество встроенных функций, упрощающих процесс разработки.
1️⃣Next.js предоставляет готовую систему маршрутизации, основанную на файловой структуре, что означает что react-router-dom мы можем выкинуть в garbagge collector. Что значительно ускоряет разработку, снижает количество ошибок, а самое главное количество срачей по поводу того как организовать routerConfig.
2️⃣Next.js включает в себя мощные инструменты для обработки данных, такие как getStaticProps и getServerSideProps, что позволяет получать данные как на серваке, так и на фронте, что безусловно дает больше гибкости и дает больше возможностей для оптимизации приложения, в то время как в React 19 Таких плюшек не завезли.
3️⃣Next.js предлагает автоматическую оптимизацию производительности, включая разделение кода, предзагрузку страниц и поддержку статической генерации, что позволяет создавать быстрые и отзывчивые приложения без необходимости ручной настройки.
Не смотря на то что Next безусловно надерет задницу React 19 в этом неравном бою, React может дать ту самую гибкость за которую мы его так сильно любим при выборе инструментов и механик для выстраивания собственной архитектуры своего SSR приложения и это не может не радовать.
А какой толк от SSR на фронте, читайте тут
🥊Новые хуки заказывали? Нет? а мы приехали:
useActionState - значительно упрощает управление состоянием асинхронных действий, таких как загрузка данных или отправка форм. Например, при выполнении запроса к API, хук может автоматически устанавливать состояние загрузки во время запроса, обрабатывать возможные ошибки и обновлять состояние на успешный ответ.
useFormStatus - упрощает управление состоянием форм, позволяя легко отслеживать статусы запроса. API хука аналогичен useActionState, однако применяется именно для API форм.
useOptimistic - позволяет оптимистичные обновления состояния, улучшая отзывчивость интерфейса при взаимодействии с асинхронными действиями. Позволяет временно обновить состояние в интерфейсе, предполагая, что операция пройдет успешно, и в случае ошибки откатить изменения. Это создает более плавный пользовательский опыт.
`const [items, setItems] = useState([]);
const addItem = useOptimistic(async (newItem) => {
await api.addItem(newItem);
});`
Oh my Ref. API взяимодействия рефами также придержались изменений, ими стало сильно удобнее пользоваться и это не может не радовать. Только посмотрите, это же щедевр!
1. Теперь нет необходимости использовать Hoc forwardRef, теперь ref
будут приходить нативно в внутри компонента.
`function CustomInput({ placeholder, ref }) {
return <input placeholder={placeholder} ref={ref} />
}`
2. теперь при unmount внутри колбэка ref мы также можем удалить его в случае необходимости
`<input
ref={(ref) => {
// Создание ref
return () => {
// Очистка ref
}
}}
/>`
О других плюшках расскажу во 2 части, следите за новостями и оставайтесь на моем канале😎
⚒️SSR, не путать с SSSR:
Возможно самое масштабное изменение коснется именно введения в React нового SSR (Server Site Rendering) режима. Неужто разработчики React решили подвинуть сам Vercel вместе с их хваленым Next.js? В React 19 мы действительно получим SSR, включая улучшенную поддержку потокового рендеринга и оптимизацию производительности. Однако это не означает, что React 19 сможет полностью заменить Next.js. Основная причина заключается в том, что Next.js — это не просто обертка вокруг React, а полноценный фреймворк, который предлагает множество встроенных функций, упрощающих процесс разработки.
1️⃣Next.js предоставляет готовую систему маршрутизации, основанную на файловой структуре, что означает что react-router-dom мы можем выкинуть в garbagge collector. Что значительно ускоряет разработку, снижает количество ошибок, а самое главное количество срачей по поводу того как организовать routerConfig.
2️⃣Next.js включает в себя мощные инструменты для обработки данных, такие как getStaticProps и getServerSideProps, что позволяет получать данные как на серваке, так и на фронте, что безусловно дает больше гибкости и дает больше возможностей для оптимизации приложения, в то время как в React 19 Таких плюшек не завезли.
3️⃣Next.js предлагает автоматическую оптимизацию производительности, включая разделение кода, предзагрузку страниц и поддержку статической генерации, что позволяет создавать быстрые и отзывчивые приложения без необходимости ручной настройки.
Не смотря на то что Next безусловно надерет задницу React 19 в этом неравном бою, React может дать ту самую гибкость за которую мы его так сильно любим при выборе инструментов и механик для выстраивания собственной архитектуры своего SSR приложения и это не может не радовать.
А какой толк от SSR на фронте, читайте тут
🥊Новые хуки заказывали? Нет? а мы приехали:
useActionState - значительно упрощает управление состоянием асинхронных действий, таких как загрузка данных или отправка форм. Например, при выполнении запроса к API, хук может автоматически устанавливать состояние загрузки во время запроса, обрабатывать возможные ошибки и обновлять состояние на успешный ответ.
const { loading, error, data, execute } = useActionState(fetchData);useFormStatus - упрощает управление состоянием форм, позволяя легко отслеживать статусы запроса. API хука аналогичен useActionState, однако применяется именно для API форм.
const { submitting, error, success, submit } = useFormStatus(handleSubmit);useOptimistic - позволяет оптимистичные обновления состояния, улучшая отзывчивость интерфейса при взаимодействии с асинхронными действиями. Позволяет временно обновить состояние в интерфейсе, предполагая, что операция пройдет успешно, и в случае ошибки откатить изменения. Это создает более плавный пользовательский опыт.
`const [items, setItems] = useState([]);
const addItem = useOptimistic(async (newItem) => {
await api.addItem(newItem);
});`
Oh my Ref. API взяимодействия рефами также придержались изменений, ими стало сильно удобнее пользоваться и это не может не радовать. Только посмотрите, это же щедевр!
1. Теперь нет необходимости использовать Hoc forwardRef, теперь ref
будут приходить нативно в внутри компонента.
`function CustomInput({ placeholder, ref }) {
return <input placeholder={placeholder} ref={ref} />
}`
2. теперь при unmount внутри колбэка ref мы также можем удалить его в случае необходимости
`<input
ref={(ref) => {
// Создание ref
return () => {
// Очистка ref
}
}}
/>`
О других плюшках расскажу во 2 части, следите за новостями и оставайтесь на моем канале😎
Хабр
CSR, SSG, SSR — про рендеринг приложений на примерах
Всем привет, меня зовут Хаджимурад, занимаюсь фронтенд разработкой уже 3,5 года и за это время успел поработать на многих проектах: интернет магазин, панели администрирования, проекты для...
Всем привет, ловите анонс моего интервью) обещаю, будет интересно!
Forwarded from Создание программного продукта (Vasily Rudomanov)
🚀 Анонс первого интервью с ментором сервиса Айти Кадр (https://itkadr.ru)!
Мы начинаем серию вдохновляющих интервью с топовыми менторами в IT, чтобы показать вам их карьерные пути, поделиться ценными инсайтами и помочь вам определиться с выбором наставника для своих целей.
🎙 Первое интервью будет в четверг 31 октября в 15.00 в телеграм-чате https://tttttt.me/pdt_chat, и нашим гостем будет Алексей Пудов - эксперт, которому всего за 5 лет удалось из trainee в ноу нейм компании вырасти до Lead frontend engineer в топ 3 аэропортов мира. Алексей расскажет о том, как он пришел в IT, что побудило его стать ментором и как он помогает менти достигать своих целей.
Ставьте колокольчик🔔 в чате, чтобы получить напоминание от Telegram.
Темы интервью:
📈 Путь Алексея в карьере — от первых шагов до лидерства.
💡 Что побудило его стать ментором и какие ценности он разделяет в своей работе.
🎯 Как он помогает менти разрабатывать карьерные стратегии и достигать профессиональных вершин.
🔑 Что, по его мнению, нужно современному специалисту для успеха в IT.
Это интервью — отличная возможность узнать больше о нашем менторском сервисе Айти Кадр и о том, как менторы могут помочь вам построить успешную карьеру в IT.
Айти Кадр - это платформа, где каждый может найти наставника под свои нужды. Мы предлагаем:
🧑🏫 Индивидуальные сессии с экспертами в разных сферах IT.
🎓 Карьерное сопровождение для тех, кто стремится на новый уровень.
💻 Мастер-классы и воркшопы для тех, кто любит учиться через практику.
🙋♂️Скрининг-интервью на которых вы можете в безопасном пространстве протестировать свой уровень перед реальным собеседованием.
На Айти Кадр все просто: выбирайте ментора, который близок вам по духу, и развивайтесь вместе с ним. Мы верим, что каждый может достичь вершин в IT с правильной поддержкой и вдохновением.
Мы начинаем серию вдохновляющих интервью с топовыми менторами в IT, чтобы показать вам их карьерные пути, поделиться ценными инсайтами и помочь вам определиться с выбором наставника для своих целей.
🎙 Первое интервью будет в четверг 31 октября в 15.00 в телеграм-чате https://tttttt.me/pdt_chat, и нашим гостем будет Алексей Пудов - эксперт, которому всего за 5 лет удалось из trainee в ноу нейм компании вырасти до Lead frontend engineer в топ 3 аэропортов мира. Алексей расскажет о том, как он пришел в IT, что побудило его стать ментором и как он помогает менти достигать своих целей.
Ставьте колокольчик
Темы интервью:
📈 Путь Алексея в карьере — от первых шагов до лидерства.
💡 Что побудило его стать ментором и какие ценности он разделяет в своей работе.
🎯 Как он помогает менти разрабатывать карьерные стратегии и достигать профессиональных вершин.
🔑 Что, по его мнению, нужно современному специалисту для успеха в IT.
Это интервью — отличная возможность узнать больше о нашем менторском сервисе Айти Кадр и о том, как менторы могут помочь вам построить успешную карьеру в IT.
Айти Кадр - это платформа, где каждый может найти наставника под свои нужды. Мы предлагаем:
🧑🏫 Индивидуальные сессии с экспертами в разных сферах IT.
🎓 Карьерное сопровождение для тех, кто стремится на новый уровень.
💻 Мастер-классы и воркшопы для тех, кто любит учиться через практику.
🙋♂️Скрининг-интервью на которых вы можете в безопасном пространстве протестировать свой уровень перед реальным собеседованием.
На Айти Кадр все просто: выбирайте ментора, который близок вам по духу, и развивайтесь вместе с ним. Мы верим, что каждый может достичь вершин в IT с правильной поддержкой и вдохновением.
Please open Telegram to view this post
VIEW IN TELEGRAM
Вкатуны, мне пришла идея что было бы интересно, если бы я вам скидывал процесс разработки pet проекта, который я делаю с целью обучения. Буду рассказывать с какими сложнастями сталкиваюсь и как их преадалеваю. Что бы вам интересно было бы видеть?
Anonymous Poll
70%
Емае, покажи картиночки что получается.
50%
backand чать на Rust (axum, kafka, redis, postgres)
60%
frontend часть на js (React-native, rnui, mobX)
0%
Нафиг нам твой проект, иди уроки делай
