Всем привет!

Под мои недавним постом о развитии на работе было много обсуждений. Однако хотел бы сфокусировать свое внимание на self review (само проверке) кода.

Для тех, кто никогда так не делал, это все может показаться странным. Кажется, на что там смотреть, если я и так все помню?

Однако если научится снимать менять роль и смотреть на свой pull request со стороны — то можно заметить очень много недочетов и избавится от лишних комментариев.

Наверное самым простым способом будет провести ревью где-то через день. А не сразу после завершения задачи.

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

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

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

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

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

В целом, навык самоанализа полезен во всех сферах жизни.

Сам недавно понял, что всем даю такой совет для написания кода, но почему-то не применяю тот же принцип для улучшения своих видео.

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

#devtips #work

Сегодня узнал интересный момент, касательно анимаций.

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

Например, такой код не будет анимировать ничего:

function animate() {
  const div = document.querySelector("item");

  div.style.height = "0px";
  div.style.transition = "all 1s ease";

  div.style.height = "500px";
}

А такой:

function animate() {
  const div = document.querySelector("item");

  div.style.height = "0px";
  div.style.transition = "all 1s ease";

  requestAnimationFrame(() => {
    requestAnimationFrame(() => {
      div.style.height = "500px";
    });
  });
}

Или такой:

function animate() {
  const div = document.querySelector("item");

  div.style.height = "0px";
  div.style.transition = "all 1s ease";

  div.getBoundingClientRect();

  div.style.height = "500px";
}

Будут.

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

Например, после запуска вот этого кода, у вас также сработает анимация.
```
function animate() {
const div = document.querySelector("item");

div.style.color = "red";
div.style.transition = "all 1s ease";

div.style.color = "white";
}
```
Выглядит так, что браузер просто пытается оптимизировать лишние reflow, поэтому не запускает анимации для свойств, которые на него воздействуют.

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

UPD: В комментах @senheleet подсказал, что с color работает все, так как у нас по дефолту всегда есть какое-то значение. А с height по дефолту значение auto и от него нельзя начать анимацию.

#devtips #js

Сегодня смотрел, что нового происходит в мире JS.

Самое интересное, что я нашел — это выход nest.js v10 и svelte v4.

По поводу nest много сказать не могу, так как я почти не писал на нем.

А вот улучшения по размеру конечного бандла от свелта не плохи, учитывая то, что и так output был у него значительно меньше того же реакт (но меня больше удивило уменьшение размера самого пакета в 4 раза).

Хотя, кажется это только меня и заботило)

Если есть что-то интересное — тоже делитесь в комментариях.

https://svelte.dev/blog/svelte-4
https://trilon.io/blog/nestjs-10-is-now-available

#devtips #js

Сегодня помогал человеку с реализацией draggable canvas (по типу миро, но на html).

Столкнулся с проблемой, когда код внутри setState колбэка вызывался 2 раза.

Код выглядел примерно так:

setPosition(position => {
const deltaX = e.clientX - prevMousePosition.x;
const deltaY = e.clientY - prevMousePosition.y;
prevMousePosition = {
x: e.clientX,
y: e.clientY,
}

return {
x: position.x + deltaX / scale,
y: position.y + deltaY / scale,
}

В итоге при первом вызове стейт вставал в правильное значение, а при втором — все сбрасывалось, так как prevMousePosition был уже таким же, что и clientX/clientY из ивента.

Благо из-за серых логов быстро смог понять, в чем причина. Но все равно выглядит очень странно.

Да, по задумке колбэк должен быть pure function. Но почему нету никакого лога о том, что второй вызов выдал другой результат?

В общем, при обновлении стейта будьте внимательнее.

#devtips #react

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

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

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

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

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

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

#devtips #opensource

Пока все про using говорят, команда TS подвезла нам очень классные фичи для грядущей версии 5.2.

Декораторы, улучшение туплов, работа с методами массивов и тд.

Уже давно не припомню, чтобы в одном релизе сразу столько болей моих правили (последнее что помню — это 4.1).

https://devblogs.microsoft.com/typescript/announcing-typescript-5-2-beta/#decorator-metadata

#devtips #typescript

Одна важная вещь, которую нужно учитывать, если вы предпочитаете использовать типы вместо интерфейсов в TS - это отличие type intersection (`AType & BType`) от наследования интерфейсов.

Давайте для простоты понимания сразу взглянем на пример:

// с типами
type BaseModelType = {
    test: string;
    foo: string;
}

type MyModelType = {
    test: {a: number};
} & BaseModelType;

type TestType = MyModelType['test'];
//    ^?
// { a: number } & string;

// с интерфейсами
interface BaseModelInterface {
    test: string;
    foo: string;
}

interface MyModelInterface extends BaseModelInterface {
//        ^^^^^^^^^^^^^^^^
// Interface 'MyModelInterface' incorrectly extends interface 'BaseModelInterface'.
//   Types of property 'test' are incompatible.
//     Type '{ a: number; }' is not assignable to type 'string'.ts(2430)
    test:  a: number;
};

type TestType1 = MyModelInterface['test'];
//    ^?
// number

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

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

Решение у 2-х проблем одинаковое — использование Omit:

// с типами
type BaseModelType = {
    test: string;
    foo: string;
}

type MyModelType = {
    test: {a: number};
} & Omit<BaseModelType, 'test'>;

type TestType = MyModelType['test'];
//    ^?
// { a: number };

// с интерфейсами
interface BaseModelInterface {
    test: string;
    foo: string;
}

interface MyModelInterface extends Omit<BaseModelInterface, 'test'> {
    test: number;
};

type TestType1 = MyModelInterface['test'];
//    ^?
// number

Не говорю, что нужно использовать одно или другое (я считаю тут просто нужно договориться на уровне проекта), но наследование у интерфейсов по лучше.

#devtips #typescript

Очень крутая статья от GitHub о том, как они пилили новый code view (фича кстати очень удобная, был сильно рад, когда выкатили).

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

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

А тут ребята на много дальше пошли, в общем, прочитаете сами)))

https://github.blog/2023-06-21-crafting-a-better-faster-code-view/

#devtips #js

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

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

До сих пор помню, как сильно волновался и как тяжело было готовить материал, так как на тот момент я только написал где-то 10 статьей на блоге и опыта подготовки презентаций не было. В целом даже power point’ом не пользовался.

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

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

В общем, веселого вспомнить можно много. Но одна вещь после этого поменялась.

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

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

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

По итогу через 2 месяца уже загрузил 3-й видос на канал про хук useCombinedRef. А дальше уже сами знаете думаю.

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

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

#devtips #softskills

Важный момент для тех, кто готов поработать на разных стеках (vue, react etc.) либо позициях (fullstack, frontend, lead). Если вы подаетесь не в бигтех, то лучше делать специализированное резюме под каждую позицию.

Причина тут простая — каждая компания хочет взять человека, который идеально подходит под их ситуацию (особенно во времена, как сейчас). Вы можете написать, что работали с React, Vue и тд. Но по итогу никто в подробности вдаваться не будет, и подумают, что вы не эксперт в этих технологиях.

Понятное дело, что это не везде так. Но кажется сделав несколько резюме вы ничего не теряете.

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

#devtips #job

Всем привет!

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

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

Да, у кого-то меньше, у кого-то больше, но тем ни менее, у всех оно есть.

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

Самое главное — это умение увести свои мысли в сторону проблемы и перестать негативно себя оценивать.

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

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

#devtips #job

Еще 3 новых proposal дошли до stage-3:

- https://github.com/tc39/proposal-source-phase-imports
- https://github.com/tc39/proposal-array-grouping
- https://github.com/tc39/proposal-promise-with-resolvers

Первое нововведение добавляет реально новый функционал. Правда кроме wasm пока не понял, где это может быть нужно. Но я думаю тут подскажут еще.

Что же касается Promise.withResolvers и array grouping — то кажется просто решили добавить пару утилит в сам язык) Мелочь, но может чуть упростить работу местами.

#devtips #js

Еще один простой и полезный совет для тех, кто проходит собесы.

Записывайте все свои собеседования! Уже давно практикую это дело. Очень помогает в разборе ошибок.

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

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

А, ну и для записи проще всего будет скачать OBS — open source, под все платформы, куча гайдов в интернете.

В общем, всем советую.

#devtips #job

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

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

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

Но, как сами понимаете, человек не очень хорош в оценке задач.

Даже с двумя видео в неделю изначально идея была в том, что я всю неделю готовлю материал по 1-2 часа, и потом за один день снимаю сразу 2 видео.

Но после нескольких проб я понял, что так у меня вообще все плохо идет.

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

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

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

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

#devtips #productivity

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

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

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

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

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

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

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

#devtips #learning

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

Однако, если цель проекта — заработок денег, то подходить к нему стоило бы по другому, чем к обычному пет проекту, который пишется «по фану».

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

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

И причем даже если вы и сделаете MVP, и он «не зайдёт», то не особо ясно, в чем проблема. Она находится в самой идеи или же у вас есть проблемы с реализацией — плохой маркетинг, не удобный интерфейс и миллион других проблем.

Я сам в какой-то момент по этой же причине перестал активно занимать сайд-проектами с целью заработка.

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

А уже с этих денег можно и спонсировать более крупные идеи. Либо же просто увеличивать доход от туда.

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

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

#devtips #work

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

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

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

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

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

#devtips #work

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

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

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

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

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

Даже если вы и напишите что-то быстрое, красивое и умное, через 2-3 месяца после вашего ухода кто-то накидает туда костылей, чтобы съэкономить себе пару часов. А через полгода-год вашего кода уже и не будет. Либо он вообще станет легаси, который никто трогать не хочет. Опять же, я может чут-чуть преувеличиваю, но обычно примерно так и происходит.

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

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

#devtips #work

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

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

0.1) Если вы начинающий, то можно написать любой проект, который вы еще не делали на курсах/туториалах. Из некоторых идей — аналог Trello, мини-чат, какое-то специфичное приложение для автоматизации ваших рутинных задач.

0.2) Любой npm пакет (для начало лучше брать что-то простое), которым вы пользуетесь, и не понимаете, как он работает.

1) Библиотека для анимаций под React или любой другой фреймворк. Кода там мало, если рассматривать простые flip анимации. Но очень много интересных кейсов. Я когда-то писал такое решение под React. Очень многому научился.

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

3) Server Dirven UI для форм. Чем-то похоже на конструктор сайтов. Правда тут больше сложностей с продумыванием формата самой схемы вашей формы. Как будет писаться валидация? Как будут работать связанные поля и тд.

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

UPD: Делитесь вашими идеями интересных проектов в комментариях.

#devtips #sideprojects

Одна небольшая вещь, которая показалась интересной в solid js, это то, как работают binding’и в ивентах.

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

// первый способ
const handleClick = e => {...}
<div onClick={handleClick}></div>

// второй способ
const handleClick = (id, e) => {...}
<div onClick={[handleClick, item.id]}></div>

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

Однако в доке написано:

This doesn't use bind or create an additional closure, so it is a highly optimized way of delegating events.

Поэтому мне стало интересно, как же это вообще работает. Если зайти в playground, то можно увидеть, что наш JSX скомпилится в что-то такое:

const _el$ = _tmpl$();
_el$.$$click = handleClick;
_el$.$$clickData = item.id;

То есть как вы можете увидеть, обработчик ивента и сами данные биндятся на прямую в DOM элемент. Дальше, когда ивент доход до document (да, в solid тоже есть делегация ивентов) там из event.target берется сам обработчик и дата, которая была прикреплена к данному элементу (ссылка на код). Затем уже обработчик вызывается с правильной датой и ивентом.

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

#devtips #solid