Ну чтож, пришло время подвоить итоги конкурса. Число-победитель у нас 61, сделал все как подобается фронтендеру в консоли браузера.

Отсчитал 3 раза, и победитель у нас PelllaJikuH я напишу тебе в личку, там уже все обсудим.

Для тех, кто тоже будет пересчитывать, есть 2 момента:

1) Я считал не от 0, так как в рандом функции мином был 1.
2) Был 1 человек с 2-мя комментами подряд, поэтому его не учли.

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

Да уж, вроде раньше картинки могли отправлять вместе в телеге…

Продолжаю вчерашнюю тему, под постом задали такой вопрос:

И все же какие ресурсы?) Пару книг/каналов/блогов было б интересно

Как я уже и говорил, очень много кого-то не смотрел никогда. Но могу посоветовать пару ресурсов:

1) Книга “the complete software developer's career guide” John Sonmez, и его старый канал SimpleProgrammer (сейчас BulldogMindset).

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

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

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

В общем, посмотрите его видосы и прочитайте книгу, она прям топ!

2) Есть прикольный блог от Дена Абрамова - https://overreacted.io/. Там редко выходят статьи, но бывает полезно заглянуть и почитать.

3) Последний ресурс - https://kentcdodds.com/blog. Тоже блог, давно его не смотрел. Но когда-то выборочно читал статьи. Бывает полезно, но больше для начинающих контент.

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

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

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

Как-то так. Всем хорошего дня!

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

Собственно, Евгений тоже поделился полезными ресурсами (большое за это спасибо!) и вот таким мнением:

А насчёт того, как написать приложение, которое не надо будет переписывать каждые три года — это как с ответом на вопрос «как похудеть»: больше двигаться и меньше кушать. Но ответ не всех устраивает и все пытаются найти какие-то читы, как обмануть свой организм. Нет, обмануть свой организм не выйдет. 

С разработкой то же самое: нужно регулярно приложение рефакторить, выполнять технический долг и обновлять зависимости. Чита «как написать приложение, которое не придётся рефакторить», не существует. Его придётся рефакторить. И если заказчик не даёт времени на выполнение технического долга, то никакими читами невозможно будет сделать приложение, которое через три года не придётся переписать. Поэтому статей на эту тему особо никто и не пишет.

Вот, собственно мой ответ:

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

Можно есть 1 прием пищи и 4 больших сникерса в течение дня, что не так уж и много. А в зале делать подходы на 1-2 повтора с большим весом.

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

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

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

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

То же самое касается абстракций. Хорошие абстракции могут сильно упростить обновления на новые мажоры и в целом, смену инструмента под капотом.

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

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

Заключение:

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

Большинство людей к сожалению не знает даже, что такое dependency injection и для чего он может быть полезен. То же самое касается тестов. Хотя для бекенд разрабов это прям вообще очевидность.

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

Это мое мнений и мой совет. Хорошего всем дня!

#devtips

И так друзья, первое видео в этом году посвящено redux и redux-toolkit.

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

Также оставьте свой фидбэк для того, чтобы видео быстрее продвигалось.

https://youtu.be/edmXoRwgQeI

Всем привет!

После последнего видео пришло очень много новых подписчиков в телеграм, что очень круто!

Уже и комьюнити растет и обсуждений и вопросов в комментах много. По возможности стараюсь на все отвечать.

Что ж, сегодня довольно много митингов на работе, поэтому пост будет не такой большой.

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

Решил написать про это после того, как вчера увидел, что у нас на проекте юзается i18next, который весит, 57.5kB minified! Причем тришейкаться это все не будет.

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

Так вот, сейчас в процессе написания своего мини-решения, которе покроет 2 языка (инглиш и арабский). В целом, там все очень просто.

Скорее всего вы сейчас задаете вопрос, Айюб, а почему бы не заюзать готовое решение?

Проблема тут в том, что все пакеты, которые я нашел либо большие и набитые ненужным функционалом. Либо же очень маленькие и простые + не особо популярные. Из-за чего проще держать это у себя.

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

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

Асинхронно тут понятное дело не вариант это грузить)

Плюс ко всему, человек не учел, что вообще это либа умеет и нужен ли вообще весь ее функционал. Если это просто какая-то админка для разрабов, то понятное дело - можно сильно не заморачиваться.

Но когда это лендинг или публичная страница - лучше быть более осторожным.

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

Собственно, мои советы:

1) Прежде чем добавлять либу, внимательнее ознакомьтесь с ее размером. Оцените, повлияет ли это как-то на ваше приложение. Важный момент - нужна также учитывать, есть ли tree shaking, так как он дает большую разницу.

2) Также стоит ознакомиться с ее функционалом, что есть, а что может быть и не будет. Не стоит забывать про то, насколько хороша она поддерживается и сколько зависимостей имеет сама. В долгосрочной перспективе это может быть очень важным фактором.

3) Всегда стоит посмотреть на альтернативные варианты, не надо торопиться.

4) Я не люблю скачивать либы для 1-й функции на 10-20 строк. Лучше это просто скопировать в проект и оставить так. Если в какой-то момент не подойдет - можно будет поправить. Также -1 пакет, о котором нужно заботиться.

Хорошего дня!

#devtips #performance

Случайно нажал на enter - пост еще не дописан 😅.

Так, всем привет!

Хотел сегодня продолжить вчерашнюю тему касательно размеров пакета.

И да, прежде чем начнем, я обычно смотрю всю инфу на https://bundlephobia.com/.

Вопрос, который я хотел сегодня рассмотреть - это то, как понять библиотека большая или нет.

Вопрос довольно хороший, так как react + react-dom тоже весят немало.

Но попробую расписать то, как я подходу к данному выбору.

Тут все зависит от того, для чего используется библиотека и стоят ли дополнительные байты того,

Например, если речь идет о React - то да, это точно оправданно. Без него (или любого другого конкурента) скорость и качество разработки сильно просядет. Да и так, если много лишнего не устанавливать - размер бандла будет адекватный.

С этим примером все просто и ясно.

Но давайте взглянем на i18n, про который я сказал. Что нам нужно было на проекте?

1) Брать текст на нужном языке по ключу.
2) Интерполяция строк в таком виде {{ someKey }}.
3) Плурализация (0 яблок, 1 яблоко и тд). Только 2 языка.
4) Типизация (не устраивает у многих либ)

Кажется, не так уж и много. Можно сделать за 100-200 строк. Заходим в i18next. 57+kb minified.

И что же все это такое???

Находим issue, читаем коммент и понимаем, что это вообще бесполезные вещи!
https://github.com/i18next/i18next/issues/157#issuecomment-26193050

Куча функционала, который нам не нужен. А либо не тришейкается.

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

Свое заюзали, как и говорил из-за простоты и кастомизации типов.

Рассмотрим еще один пример - стор. На примете у нас MobX. Размер у него кстати 58.2kB minified!

И тут можно задаться вопросом - может он большой и не стоит его юзать? Но в данном случае я скажу - нет.

И главная причина это то, что функционал у него своего рода уникальный. И это all in решение для всего приложения.

Что он дает:

1) Полную систему реактивности, основанную на мутациях и прокси.
2) Точечное обновление нужного компонента без лишних ререндеров.
3) Примитивы, которые можно использовать вне реакт для каких-то решений на уровне приложения.
4) Работу с асинк экешнами их коробки.
5) Много утилит для удобной работы с реактивностью и дебаггинга.

И давайте посмотрим на ближайшую альтернативу - redux.

Так, заходим в bundlephobia - 4.4kb. Это же почти в 13 раз меньше!

Но не надо так рано принимать решения, мой друг.

Redux сам никто не использует. Давай посмотрим на полный фарш:

1) redux toolkit - 42.1kb
2) react-redux - 14.7kb

Справедливости ради, mobx тоже требует mobx-react-lite - 6.2kB, но если сравнивать общий размер, получается не такая большая разница.

Так вот, думаю мой процесс мышления вы поняли. Но в целом, все зависит от вашего кейса и приложения.

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

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

А если много - то стоит подумать.

К сожалению, как со всем в жизни, здесь нет простого ответа. Нужно смотреть на каждую ситуацию по отдельности.

#devtips

И так друзья, всем привет!

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

Наконец решил поставить фото, чтобы было проще искать среди списка каналов.

Кстати из смешного, после моих постов в начале из канала сразу же уходит 2-6 человек.

Не знаю почему, но пост про аватарку выше не исключение.

Так, теперь к самому посту.

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

Человек спросил о том, как учить английский.

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

Мой опыт изучения:

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

Но стабильно было 4, что-то в голове оставалось.

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

Но я бы не сказал, что это был какой-то супер левел.

Теперь переходим к самому главному. Как же я начал понимать английский контент?

Во время школы я очень сильно увлекался тренировками. Смотрел очень много материала на ютубе.

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

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

Потом после окончания 9-го класса очень подсел на канал Tristar Gym. Ведет его Firas Zahabi - тренер бойцов ММА (GSP, Rory McDonald и тд).

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

В начале тратил 30-35 минут на просмотр 10-и минут контента. Потом потихоньку уже начал понимать и адаптироваться к речи.

Где-то через 5-6 недель уже мог слушать без переводчика. Разве что местами переводил.

Контента у него было очень много, но за 3 месяца все пересмотрел. Это дало мне очень большой словарный запас.

Дальше уже появилась уверенность и начал смотреть больше каналов.

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

Где-то через 2-3 месяца уже мог слушать все, что угодно.

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

Тут самый важный момент в том, что на английском намного больше материала на любую тему.

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

Поэтому до сих пор в основном смотрю все на английском.

Как бы я это сделал, если бы мог начать заново:

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

Мой путь был бы такой:

1) Найдите ту тему, которая вам интересна и найдите 1 очень хороший канал на эту тему. Важно, чтобы вам было интересно.

И затем смотрите этот канал, пока не пополните свой словарный запас и не начнете почти все понимать.

Количество выученных слов - самый важный фактор.

2) Если есть деньги - найдите учителя, для которого английский - родной язык. Лучший вариант, чтобы он не знал русского.

Он очень сильно поможет с разговорной речью и грамматикой.

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

Заключение:

Как и со всем в жизни, тут нет никаких секретов. Просто так язык не выучишь.

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

Главное помнить, что он не будет длиться вечно. А если не останавливаться - то рано или поздно придете к желаемой цели.

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

#devtips #english

Всем привет!

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

Часта беда, которую я вижу на code review проектов и на работе. Люди слепо следуют принципам функционального программирования, не понимая их цену.

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

https://youtu.be/r4MzOOLCtP4

Всем привет.

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

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

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

Например, последний раз такое было с табличной версткой. Я просто создал html файл и понял, в чем была беда (я забыл детали табличной верстки).

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

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

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

Как-то так!

#devtips #debugging

Всем привет!

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

А приложение находится на стадии, когда еще не все переведено + текста некоторые приходят с бека.

Тут понятный флоу был бы такой - компонент <Text /> отвечает за стилизацию, а переводы приходят из const t = useTranslations().

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

Так там по мимо всего этого есть очень много другой странной логики, которую надо будет вынести/переделать.

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

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

Но, в итоге usege’ев, не подходящих под новый интерфейс очень много (~230). И вот в таких случаях бывает очень полезно хорошо владеть regex.

Я далеко не мастер. Но более менее что-то понимаю.

И получается одной регуляркой сразу обновить через find+replace 10-30 usage’ев, что сильно упрощает процесс.

Конечно же, там не все так переделаешь. Но уже значительную часть смог.

Так вот, к чему это. Если пишите регулярки в приложении, постарайтесь не просто скопировать их со stack overflow, а понять, как это все работает.

Я за свои годы научился базе, которая очень часто выручает. Как и говорю, знаю только банальные вещи, но многие и этого не знают.

Так что в следующий раз прежде чем просто копипастить, уделите 5-15 мин на понимание.

Тут кстати могут помочь сайты типа https://regex101.com/.

Хорошего дня!

#devtips #regex

Всем привет!

Хотел бы дать сегодня один быстрый совет для тех, кто проходит собесы.

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

Но заметил, что многие вообще с этим не знакомы, так как есть встроенный sort метод. Хотя понимать, как это работает, довольно полезно.

В идеале я бы советовал как-то базово ознакомиться с алгоритмами и структурами данных.

Но если нету времени - посмотрите хотя бы про сортировки.

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

Как-то так!

#devtips #algorithms

И так друзья, давайте в честь 1000 подписчиков попробуем собраться и чуть пообщаться голосом.

Друзья, всем спасибо!

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