Друзья, начинаем стрим через 5 минут. Подключайтесь, у кого есть время!

https://youtube.com/live/oP432XhwSHg?feature=share

Выглядит, как интересная идея.

https://microsoft.github.io/TypeChat/blog/introducing-typechat/

Также сегодня наткнулся на интересную статью про разбор vscode property mangling и как он помог им уменьшить размер приложения.

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

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

https://code.visualstudio.com/blogs/2023/07/20/mangling-vscode

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

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

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

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

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

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

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

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

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

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

#devtips #productivity

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

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

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

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

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

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

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

#devtips #learning

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

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

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

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

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

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

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

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

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

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

#devtips #work

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

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

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

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

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

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

А как вы боритесь с подобными мыслями?

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

Смотрю даже на гитхабе мейнтейнер текущий поднимает вопрос ES модулей и ищет человека, который смотрел бы его ПР.

Если кто-то хотел начать контрибьютить в опен сорс — можно попробовать)))

https://www.npmjs.com/package/backbone

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

А пока давайте проведем розыгрыш по видосам за эту неделю и прошлым “долгам” (всего 5).

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

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

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

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

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

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

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

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

#devtips #work

Всем привет!

Наконец вышло новое видео на канале. На этот раз разбираем тему, которая сейчас у всех на слуху — React Server Components.

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

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

https://youtu.be/AQY9N6TY66I

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

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

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

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

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

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

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

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

#devtips #work

Пришло время подводить итоги розыгрыша. Наши 5 победителей — @the_lensky, @ughurba, @kimanowka, @sasauges, @ArsenRuslanov.

Удачные индексы (считаются с 0) вы видите на экране. Давайте поздравим победителей!

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

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

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

Всем привет!

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

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

https://youtu.be/pG-H9lK3NQA

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

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

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

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

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

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

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

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

Интересная статья от мейнтейнера redux и его экосистемы (rtk, react-redux и тд) о его незавершенном переводе пакетов на ESM. Мне кажется все уже 100 раз слышали о том, что система модулей в JS просто отвратительная. Но эта статья прямо полноценно открыла мне глаза на проблему)

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

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

https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/

Давно завалялась тема о которой меня спрашивали в моем старом видео (качество тогда было у меня не очень) о хуках useMap/useSet. Вот наконец решил ответить на вопрос и убрать его из списка)))

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

На самом деле, хуки эти приходиться использовать очень редко. Чаще всего для кеширования каких-то вычислений (замеры DOM, например). Выходит удобнее, чем объекты.

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

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

Вот кстати ссылка на код из видео — https://codesandbox.io/s/lhvg5r