Всем привет!

Продолжаем видосы по TypeScript (это должен быть предпоследний).

В этот раз разберем актуальную для всех тему - типизация сложных кейсов в React (memo, forwardRef, hoc, component as prop).

Обязательно оставляйте лайки, фидбэк в комментариях и делитесь видео с друзьями - это помогает каналу быстрее расти.

https://youtu.be/JysvuDPCS80

Всем привет!

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

Однако хотел бы вкинуть свои 5 центов и рассказать об еще одном варианте, с помощью которого можно получить реальный опыт - стажировки в больших фирмах.

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

Я лично знаю про то, как обычно это происходит в Яндексе (про другие несложно найти в инете):

1) Записываетесь на стажировки (сейчас кстати идет весенний набор, если не ошибаюсь)
2) Проходите контест (алгоритмы)
3) Проходите 1-2 собеса (один на JS, другой на алгоритмы)

Пару советов, которыми можно воспользоваться:

1) Зарегайтесь на контест с 2-3 акаунтов и прорешайте задачи заранее, так как там дается определенное кол-во времени.
2) Почти все задачи на алгоритмы есть на литкод, там есть список задач Яндекс (другие фирмы тоже - Гугл, фейсбук и тд.). Их там не так много.

Если выделить время и подготовится - то попасть на стажировку не так сложно. Самый главный тут плюс в том, что вы знаете чего ожидать.

#devtips #job

Всем привет!

Вышло еще одно видео по TypeScript, где мы разбираем 3 самые важные вещи, которые вам нужны для написания сложной типизации - conditional types, mapped types, infer.

Обязательно оставляйте лайки и фидбэк в комментариях. Также не забывайте делиться видео с друзьями - это помогает каналу быстрее расти.

https://youtu.be/wfGhhmtDsDQ

Всем привет!

На позапрошлой неделе у меня выходил 1 видос, вместо обещанных 2-х, поэтому давайте проведем розыгрыш на эту тему.

Для тех, кто не в курсе, я пообещал выпускать 2 видео в недели и 1 пост в день на протяжении 2023-го года. За каждый пропущенный видос или пост я разыгрываю $50 или 1:1 сессию консультации/менторинга.

Для участия нужно будет оставить ровно 1 комментарий под следующим постом. Победителя выберу на этой неделе (не раньше, чем через 24 часа). Нужно просто разобраться с тем, как это можно делать через бота.

Пост для сбора комментариев на розыгрыш.

Всем привет!

Пару недель назад наткнулся на вот эту статью про clean code и там поднималась тема перформанса при соблюдении всех правил чистого кода.

Статья довольно интересная (там также есть видео по ней), однако тут мне кажется нужно думать не только о перформансе кода, но и о смысле оптимизации наперед.

Очень часто у разработчиков (у меня в том числе) бывает желание сделать код "более универсальным", покрывая кейсы и проблемы, которых сейчас нету. И в итоге получается какая-то махина, которая только все усложняет.

Особенно часто у меня такое бывает на своих проектах, где нету четкого ТЗ и дедлайна.

Тоже самое и касается архитектуры. Я планирую сделать по ней отдельное видео, однако я очень часто вижу, что люди просто все переусложняют.

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

Тоже самое и касательно структуры папок, очень много споров, хотя казалось бы, не такая значительная вещь. Главное, чтобы была какая-то структура и ее придерживались, а остальное думаю уже не важно.

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

Однако пытаться покрыть кейсы, которые могут произойти в будущем не стоит. Я также часто люблю себе напоминать о том, что с первого раза никогда не получается сделать что-то хорошее.

Поэтому если есть новый функционал - делайте его хорошо, но не стремитесь к идеалу. Когда настанет время переделывать - тогда уже будет виднее. А может переделывать его вообще не придется, по крайней мере вам).

#devtips #cleancode

Всем привет!

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

Почти все темы из своего списка я уже покрыл (осталось 2-3 видоса — выпущу их чуть позже). Хочу собрать фидбэк по серии видосов.

Для оценки можно использовать критерии, которые мы собрали в прошлый раз (Сейчас отвечаю на данное сообщение).

Дополнительный фидбэк тоже приветствуется. Может вы хотите, чтобы я покрыл какую-то тему? Что может не стоило включать и вы уже и так это знали?

Из того что я сам заметил:

- До сих пор часто тороплюсь.
- Кажется, что нужно как-то понятнее объяснять сложные слайды с кодом, но пока не пойму как. Буду рад предложениям.
- Нужно пробовать добавлять визуал, но тоже пока нету четкого понимания, где и как.
- Скорее всего видео про utility types не стоило делать, так как тема не такая сложная для понимания.

Из дальнейших планов - переснять плейлист по хукам, однако добавить туда дополнительную инфу и улучшить подачу. В этот раз думаю миксовать с другими видео, чтобы тема не приедалась.

А так есть еще пару важных апдейтов, поделюсь ими в ближайшее время.

Как-то так, жду ваших комментов!

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

Раньше всегда для картинок с кодом использовал сервис https://carbon.now.sh/. Однако кастомизаций у него не так много, да и подсветка там мне не сильно нравилась.

Сегодня наткнулся на https://showcode.app/ — выглядит, как намного более хорошее решение.

Может кому-то тоже будет полезно.

Всем привет!

Сегодня наткнулся на статью, от chrome, где они презентуют WebGPU - API для проведения вычислений на GPU.

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

На самом деле очень рад данным изменениям. Возможно photoshop теперь наконец выпустят свою веб версию).

https://developer.chrome.com/blog/webgpu-release/

#devtips #news

Наткнулся тут на видео от Primagen, где он реагирует на статью про то, как одна строка в tanstack table улучшила перфоманс в 1000 раз.

Сама причина там очевидная, мы разбирали подобные кейсы в моем видео про цену иммутабельности. Однако больше удивило то, что вообще такой код попал в библиотеку и был там столько времени.

Не знаю почему, но по какой-то причине для многих людей в мире JS нормальная практика писать иммутабельный код где попало, даже там, где он ненужен и может повлечь за собой O(n^2), а иногда даже и больше.

Понятное дело, что на 20 элементах это вряд ли как-то скажется, но тут ситуация то совсем другая. Это библиотека, тем более для написания таблиц, в том числе и виртуализированных.

Соотвественно, ей нужно расчитывать как минимум на 100к элементов (если объекты не такие большие, то это займет не так много памяти).

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

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

P.S. Если не понятно, о чем идет речь - советую прочитать статью либо посмотреть мое видео.

#devtips #performance

Всем привет!

Мне часто пишут подписчики и просят запилить отдельный плейлист либо стримы по разработке проекта.

Что-то такое сделать я думаю можно, однако я хотел бы показать людям, что в опен сорс также есть реальные проекты, которые используют тысячи пользователей.

1) Телеграм web клиент, да и в целом любой клиент (iOS/android/desktop) телеграмма находится в открытом доступе и его код можно почитать в гитхаб.

Насколько я знаю, сейчас есть 2 актуальных веб клиента:

https://github.com/morethanwords/tweb
https://github.com/Ajaxy/telegram-tt

2) Kibana - https://github.com/elastic/kibana

3) Grafana - https://github.com/grafana/grafana

На самом деле есть еще много проектов, у которых frontend в открытом доступе. Найти их не так сложно. Помню даже как-то список был.

Однако кроме этих я ничего не вспомнил, так как остальные я детально не изучал.

А, ну и еще есть слитый код Яндекса. Не совсем опенсорс, но поизучать тоже можно).

#devtips #opensource

Всем привет!

Думал сначала выпустить видео по реакт хукам, однако там все чуть затянулось. Поэтому пока что продолжаем наш TS плейлист).

На этот раз разберем 8 вещей, которые мне не нравятся в TypeScript. Детально поговорим про данные проблемы, когда они происходят, и как их можно решить (иногда никак).

Обязательно оставляйте лайки и фидбэк в комментариях. Также не забывайте делиться видео с друзьями - это помогает каналу быстрее расти.

https://youtu.be/jEWLhZ3ZJzQ

Всем привет!

В первую очередь, у нас на канале набралось 2000 подписчиков, за что хочу сказать всем спасибо!

А сегодня хотел бы поделиться основными структурами данных и алгоритмами, которые по моему мнению стоит знать фронтенд разработчику.

Также сразу скажу, что по моему мнению лучше вначале уделить больше времени на изучение и понимание структур данных. Ну и в целом строить все обучение CS на этом.

Изучили структуру - порешали задачки с ней. А затем уже можно переходить к более сложным задачам, которые требуют комбинации нескольких структур и знание определенных алгоритмов.

Теперь сам список того, что я считаю нужным:

- Map, Object, Set. Задач тут много на них, но самые частые - sum two, sum three и тд. Да и в работе думаю есть много примеров, где нужны данные структуры.
- O(n) - Не совсем алгоритм или структура данных. Однако важная тема, которую нужно понимать. По крайней мере для того, чтобы писать оптимальный код.
- array - Тут много есть разных и интересных задач, конкретное что-то выделить не могу. Но все из них обычно очень полезные.
- stack - Самая популярная задачу тут - проверка последовательности скобок. Если хотите чуть сложнее - то можно попробовать проверять последовательностью с html-like тегами. Например, <1>asdf</1>asdf<asdf></asdf> - валидно, <1>asdf</1>asdf<asdf> - невалидно.
- queue
- recursion - на рекурсию тоже много интересных задач, прямо выделить какие-то не могу. Также полезно знать, как можно переделать рекурсию на обычный цикл с помощью stack/queue.

Не прямо, чтобы нужные, но очень рекомендую поизучать:

- Heap - Иногда может быть полезен для неординарных задач (используется, кстати, в самом коде React).
- graph/tree/linked list - тут можно изучить прям базу (bfs/dfs и нахождение circular reference). Глубоко я бы уходить не стал, если нет желания конечно.

Мой список примерно такой. Да, указал все почти все, но на самом деле есть и более продвинутые структуры (ring buffer, sorted map и тд.), которые бывают нужны в очень специфичных ситуациях.

В плане задачек, я бы решал до уровня medium. На самом деле даже некоторые medium бывают очень сложные, поэтому не надо расстраиваться, если идет не так просто.

В плане ресурсов, уже рекомендовал на этом канале вот этот бесплатный курс и плейлисты по алгоритмам и структурам данных от HackerRank.

Как-то так!

#devtips #algorithms

Всем привет, друзья!

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

Небольшая предыстория, на 2-х последний работах у нас не было ручного тестирования вообще. Связанно это с тем, что команды сами по себе были маленькие.

В целом, с самим отсутствием тестировщиков я был согласен — в этом есть смысл с точки зрения эффективного распределения ресурсов. Однако часто бывало такое, что я выкатывал прям совсем глупые баги на прод.

И каждый раз это было связанно с тем, что я поленился зайти и потыкать пару кнопок. Так как такое случалось не один раз, то я уже понимаю мой мыслительный процесс.

Обычно я все проверяю сам, пока не появляется какая-то очевидная вещь, которую кажется даже не надо тестить — там и так все просто. Особенно, если такой простой кейс сложно протестировать — нужно делать сетап в админке, получать мейлы и тд.

Часто бывает сразу пушишь коммит, проходишь ревью, выкатываешь на препрод (а иногда даже прод) и тут бац. Оказалось там не правильно написан if. Либо же опечатка в типизации, что следовательно ведет за собой опечатки в коде и тд.

Еще один частый паттерн, это когда у меня есть большая фича и я вношу изменения. С каждым изменением я проверяю, что все работает правильно. Однако проверяю я именно те части, которые по моему мнению должны были быть задеты.

Как вы сами понимаете, мое понимание может сильно отличаться от реальности.

На самом деле я встречал коллег, у которых вообще нету такой проблемы. Даже я бы сказал обратное — слишком датошно смотрят каждую деталь.

Однако для себя я понял решение. Если я чувствую, что я не достаточно хорошо все проверил, либо же там реально значимые изменения — я попрошу протестить еще раз кого-нибудь из разработчиков либо продуктов. Обычно никто не отказывает.

Соотвественно другим я тоже помогаю в тестировании. И причем я заметил, когда тестируешь чужой код — таких проблем нет. Всегда все нормально проверяешь.

Как-то так! А есть ли у вас проблемы с тестированием своих задач?

#devtips #testing

Всем привет!

Наверняка со всем хайпом вокруг solid.js, сигналов и подобных решений вы наверняка могли слышать такой термин, как "Fine-Grained Reactivity".

Однако задавались ли вы вопросом, что он означает?

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

Однако пару дней назад задался вопросом, правильно ли я понял значение или же тут есть какие-то детали?

К моей радости, термин я понял правильно, и он означает, что каждая нода реактивного стейта знает о том, где она используется - какие реакции/эффекты ее используют.

Чтобы понять о чем я, давайте посмотрим на данный пример кода:

const object = observable({ a: 5, test: 'asdf' });

autorun(() => {
  console.log("object.a: ", object.a);
}); // залогирует при инициализации object.a: 5

object.a = 10; // залогирует "object.a: 10"

object.a = 11; // залогирует "object.a: 11"

object.test = 'asdf2'; // не залогирует ничего

Как мы видим наш auto run callback вызывается только при инициализации и изменении стейт, на который он завязан.

Однако в кейсы с React, можно делать вот так:

function Component() {
  const [, forceUpdate] = useReducer((v) => v + 1, 0);

  console.log('I render');

  return <button onClick={forceUpdate}>Update Me</button>;
}

И тут при каждом клике у нас будет обновляться Component, даже не смотря на то, что мы вообще не используем наш стейт.

Соответственно, у нас есть реактивность только на уровне компонента, а не на уровне каждого свойства. И как раз из-за этого в react'е часто есть проблема лишних рендеров.

Так что теперь можете использовать данную фразу (fine-grained reactivity), если хотите выглядеть умным в глазах других коллег (я бы не советовал).

Если хотите углубиться в тему подробнее - то можете ознакомиться с данной статьей от создателя Sold:
https://dev.to/ryansolid/a-hands-on-introduction-to-fine-grained-reactivity-3ndf

#devtips #reactivity

Всем привет!

Вот наконец вышел первый ролик нового плэйлиста по хукам. В нем мы поговорим про самый полезный хук для оптимизаций!

Разберем что это за хук, как он работает, чем он может быть полезен, и разберем конкретные примеры оптимизации кода.

Обязательно оставляйте лайки и фидбэк в комментариях. Также не забывайте делиться видео с друзьями - это помогает каналу быстрее расти.

https://youtu.be/XOSgHVzHEV4

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

Поэтому сегодня подводим итоги!

Победитель у нас Саша, с комментарием “asd”.

Давайте поздравим победителя!

Всем привет!

Продолжаем наш плейлист по React хукам. В сегодняшнем видео разберем мои топ 6 хуков оберток над useState.

Каждый из этих хуков я использовал на своих проектах, так что некоторые из них должны быть вам тоже полезны.

Обязательно оставляйте лайки и фидбэк в комментариях. Также не забывайте делиться видео с друзьями - это помогает каналу быстрее расти.

https://youtu.be/3SB278SY73s