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

Путь разработчика

Мне всегда было интересно уметь делать не только frontend, но и backend. Поэтому node.js я тоже использую в своих приложениях. Почему именно node.js? Потому, что это самая популярная технология для frontend. Но вот что изучать? Проанализировав кучу вакансий на позицию full-stack разработчика, я пришёл к выводу, что сейчас популярны:

Next
Nest

Причём, трудно выделить что-то из них. Они немного разные и у них есть существенные отличия, но они оба сейчас в тренде.

Путь разработчика

При изучении новых технологий, очень часто сложно определиться с тем, что начинать изучать. В результате, можно сразу же изучать очень много различных технологий. И это очень негативно сказывается на процессе изучения. Во первых, возникают очень поверхностные знания, потому, что не достаточное количество времени затрачено на каждую из технологий. Но самая большая проблема - это ощущение, что мозг не понимает, как это всё можно изучить. Чувствуется, что это неподъёмная ноша.

Путь разработчика

🔹Разбираться в плохой постановке задачи. Порой, постановка может состоять из одного заголовка. И возникает вопрос: "Почему так?" И ответ будет - потому что автору задачи было лень делать постановку, либо она казалась ему очевидной.
🔹Правильно задавать вопросы. Исходя из предыдущего пункта, становится очевидно, что проблема с постановкой - очень частая проблема. И в таком случае, нужно задавать правильные вопросы, чтобы получать именно то, что важно, затратив как можно меньшее количество времени.
🔹Учится себя презентовать. Если у Вас страх публичных выступлений, то от него придётся избавиться. Постоянное прохождение собеседований, а также выступления на различных групповых встречах - это необходимое условие в работе разработчика.
🔹Умение взаимодействовать с различными людьми. В команде часто бывают люди, которые имеют не самый простой характер. Избежать общения с ними, когда речь идёт о каких-то рабочих моментах, не получится. По этой причине, придётся учиться взаимодействию с ними.

Путь разработчика

Когда я был руководителем отдела, я старался с определённой периодичностью проводить беседы 1 + 1. И многим было не понятно, для чего это нужно вообще. Ведь если у них есть вопрос, то они могут просто написать об этом сообщение. Но вся правда в том, что напишет не каждый. Если сотрудник чем-то не доволен, у него есть альтернатива - уйти в другую компанию. Даже, если проблема незначительная и её можно с лёгкостью исправить, некоторым проще выйти на рынок труда. И именно из-за таких мелочей можно потерять ценных сотрудников. Беседы 1 + 1 нужны для того, чтобы сообщить о чём-то важном друг другу. Эти беседы в равное степени нужны, руководителю, так и сотрудникам из его отдела.

Путь разработчика

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

🔹Не оцениваю баги. В этом нет особого смысла. Да и руководитель этого не требует. Баг может быть исправлен за несколько минут, а может за несколько часов.
🔹Для руководителей главное, чтобы уложился в оценку, а не чтобы она была наименьшей.
🔹Декомпозиция - максимально разбиваю задачу на небольшие блоки. Маленькие блоки оценивать легче.
🔹Не поддаюсь на мысли, что можно сделать быстрее, если в голову приходит оценка. Всегда, когда я поддавался таким мыслям, я не попадал в оценку.
🔹Обязательно нужно закладывать риски, около 20% от задачи. Очень часто это помогает уложиться в срок.
🔹Если это возможно, то оцениваем задачи в паре с другим разработчиком. Берём максимальную оценку из тех, что определили.

Путь разработчика

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

Путь разработчика

Когда мой английский был слабоват, но я работал разработчиком несколько лет, то заметил за собой забавную особенность. Я знал огромное количество названий методов и сущностей, однако мне не приходило в голову посмотреть из перевод. В результате получалось, что порой у меня в голове путались некоторые похожие слова, например slice и splice. И такое положение вещей складывалось до тех пор, пока я не взялся за изучение английского языка всерьёз. И сейчас, мой мир стал гораздо более понятным и простым. Было ли у Вас подобное? 🙃

useCallback - довольно распространённый хук в React, но не все понимают, для чего он нужен. Представим, что у нас функция a(), объявленная внутри компонента, которую мы передаём в React компонент B, обёрнутый в memo, в качестве параметра. Поскольку все компоненты - функции, то при каждом запуску функции - компонента, будет создаваться новый экземпляр функции a(). Объект функции a() каждый раз будет другим. И компонент B каждый раз будет думать, что функция a() - другой параметр, ведь он сравнивает значения параметров по значению. В результате, при каждом рендеринге родительского компонента, компонент B также будет рисоваться заново, ведь значение параметра меняется. Чтобы избежать избыточных перерисовок компонента B, мы можем обернуть функцию a() в useCallback. Это поможет не создавать новый экземпляр функции a() при каждом рендеринге родительского компонента, а следовательно, параметр не будет каждый раз изменяться. Тем самым, мы избежим избыточных рендерингов компонента B.

Путь разработчика

Очень частый вопрос на собеседовании: "Почему плохо использовать индексы в качестве keys в React?" На самом деле, это плохо не всегда. Это плохо только в тех случаях, когда порядок node может измениться. Например, если происходит сортировка массива nodes или добавление новых элементов в начало или середину массива. Почему это плохо? Потому, что при подобных операциях теряется соответствие node и индекса, который выступает в качестве key . Если же мы используем в качестве key уникальный id из объекта - элемента массива, то при любом изменении порядка элементов, соответствие node и key будет сохраняться. Если же мы точно знаем, что элементы массива nodes не будут менять порядок, то индекс в качестве key - неплохое решение. Иногда, другого выхода просто нет.

Путь разработчика

Сравнивая строки в JavaScript с помощью операторов сравнения (<. >, ===), Вы можете обнаружить, что, например "ё" > "я", что с точки зрения языка выглядит странно. В чём же причина? А причина сравнения кодов этих символов в UTF. Но почему же так разработчики UTF просто не задали всё в правильном порядке? А причина в том, что когда мы говорим, например, о латинице или кириллице, то имеются ввиду латиница и кириллица в целом. Например, латиница используется в английском, турецком, хорватском. И у каждой из них есть свои символы и свой порядок букв в алфавите. Для оптимизации и удобства, они не дублируются для каждого языка. Учитывать порядок символов в алфавите каждого языка - нетривиальная задача.

Благо, в JS есть функция str.localeCompare(str2), которая учитывает особенности языка. В ней сравнение происходит по алфавиту. Если str < str2, то получим -1, если str = str2, то получим 0, а если str > str2, получим 1.

Путь разработчика

Недавно решил порешать задачи на алгоритмы. Вот моя реализация стека

class Stack {
_data;

push (payload) {
this._data = {
payload,
prev: this._data,
}
}

pop () {
const total = this._data;

this._data = this._data.prev;

return total;
}

toArray () {
const total = [];
let data = this._data;

while (data) {
total.push(data.payload);

data = data.prev;
}

return total;
}
}

Вчера я окончательно разочаровался в библиотеке Formik. Задача была в том, чтобы добавить новую простую форму с одним полем. Но по структуре приложения получается, что она оказывается внутри другой формы. И благодаря этому, у неё перестал работать preventDefault. И с этим ничего не поделаешь. Форма запускает его самостоятельно и не передаёт объект event в обработчик события. Да, там есть возможность обойти это, не самым красивым способом. Но это ещё больше усложнит понимание. К тому же, в моём текущем приложении предыдущий разработчик написал обёртку, которая не даёт доступа даже к этому. В общем, сплошное разочарование и впустую потраченные часы, на то, чтобы понять, что идёт не так.

Путь разработчика

I cannot understand people who have experienced doing something in the past, but cannot continue to do that again because it was a long time ago. Time after time I was in circumstances when I had to do that this way. For example, I lived in a country when I was not driving for a long time. In my case it was 1.5 years. And after that I ерщгпре that I had forgotten all about it. But when I started driving again in a couple of minutes I felt that there was not that pause and I felt the same as before the pause. The same was when I had a pause in working as a head of department. It was unused the first time, but after a couple of weeks it was the same as it was before the pause for 2.5 years. And I have the same feeling when I did not write code for several months. And for example I had not performed at a meetup for 3 years. And after that long time of pause I decided to do that again. And it was not difficult.

Путь разработчика

Сотрудники из VK рассказывают, что они спрашивают на собеседованиях (конспект их речи на 1.5 часа)

Что будет после того, как ввели адрес сайта в адресную строку. От начала и до отображения конечного результата.
Какие типы данных есть в JS. Чем отличается null или undefined.
Приведение типов. Не обязательно складывать всё со всем. Приведение типов toString, valueOf, и другие… Разница двойного и тройного равно. Приведение типов к boolean.
Что такое замыкание и область видимости. (Может на примере). Какой-то кусок кода могут показать. Почему так работает.
Цепочка promise (then, catch). Сложные цепочки.
Hosting переменных (всплытие)
Стрелочная и обычная функция. Задачи.
call, apply, bind.
Что такое this. Контекст.
Event loop. Макро и микро задачи.
События в js. Обработчики событий.
Прототипное наследование. И в целом, наследование в JS.
Почему CSS называется каскадной таблицей стилей. Как работает каскад.
Способы позиционирования и центрирования
Cookies
CORS
Методы массивов и объектов.

Путь разработчика

WebSocket

Особенности:
🔹Клиент инициирует постоянное соединение
🔹Сервер может самостоятельно давать ответ (без запроса)
🔹Каждая вкладка браузера - отдельное соединение

Минусы:
🔹Постоянное соединение, которое создает нагрузку
🔹Труднее в поддержке
🔹Отсутствует кеширование

Сфера применения:
🔹Чаты и мессенджеры
🔹Игровые приложения в реальном времени
🔹Мониторинги состояния критически важных сервисов в реальном времени
🔹Торговых приложениях с обновлением статуса заказов в реальном времени (финансовые биржи, аукционы)


Путь разработчика

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

Не секрет, что для привязки контекста используется метод функции, который называется bind.

Но что произойдет, если вызвать этот метод дважды?

Ответ прост: bind привязывает контекст только один раз. Все последующие попытки привязки не дадут результата.

В приведенном примере мы увидим в консоли строку "Dima". И это останется неизменным.

Путь разработчика

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

!important - 10000
style - 1000
id - 100
class - 10
название элемента - 1

Но это наталкивает нас на мысль, что 10 class = 1 id, что совсем не так.

И это я видел не только у неё. Почему авторам подобных интерпретаций не приходит это в голову - загадка…

Путь разработчика

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

Путь разработчика

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

https://habr.com/ru/articles/884862/