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

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

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

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

В то время мне помогла смена работы. Это было время, когда я перешел с немецкого стартапа AppSmart на проект Сбера в Айтеко. Это был совершенно другой уровень, рост в зарплате, в задачах, переезд в Москву, новый ЯП. Это решило мои проблемы, я почувствовал, что у меня появилась новая цель.

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

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

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

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

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

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

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

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

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

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

https://forms.gle/ivyiqmY6FtaLZvjC8

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

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

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

Вторая проблема это убежденность в том, что нужно сначала выучить полностью что-то одно, чтобы двигаться дальше. Например, так многие застревают на изучении html/css перед тем, как приступать к Javascript. По мере того, как вы двигаетесь в обучении, будет забываться предыдущее и это нормально. Да и все выучить невозможно, всегда будет попадаться то, что вы не знаете. Суть обучения состоит в том, чтобы понимать, как это работает и всегда знать, где найти и что искать.

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

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

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

С радостью возобновляю ведение канала! Возвращаюсь с новым опытом, с новыми идеями и контентом.

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

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

Подписывайтесь, пишите комментарии, оставляйте вопросы)

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

Кратко выдержка из статьи:

🔵 Больше рассказывать о себе, о своем пути и о своих ошибках

🔵 Стажер должен знать, что от него ожидают

🔵 Должна быть четкая цель и план по достижению этой цели, который понятен как ментору так и стажеру

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

🔵 Задавать правильные вопросы, а не давать готовые ответы

🔵 Регулярные синки. Дать возможность делиться проблемами и ощущениями

🔵 Поощрять инициативу и уверенность в себе

You don't (may not) need lodash/underscore

Статья на github, в которой говорится, что в большинстве случаев (на самом деле во всех) вам не обязательно тянуть lodash, чтобы воспользоваться какой-то супер удобной функцией, и любую из них можно заменить нативной альтернативой

Также приводится пример для каждого метода, как бы он выглядел нативно и в lodash

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

#chill_coding_useful_articles

Почему стоит использовать Neovim в качестве среды разработки?

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

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

🟢 Скорость разработки. Время между навигацией и вводом минимально, так как юзаем только клавиатуру

🟢 Возможность освоить 10 пальцевый ввод

🟢 Гибкая автоматизация рутины

🟢 Можно склонировать свой конифг и получить привычную среду например на серваке

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

🟢 Read & Write mode. Позволяет разделять контекст между просто чтением кода и его написанием (хотя вроде можно и в других редакторах и ide)

🟢 Большое комьюнити. Можно писать плагины на любом языке.

🔴 Высокий порог входа, придется потратить время на конфигурацию и практику

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

Neovim & Lua guide
Мой конфиг на github
Lua in 15 minutes
Готовая сборка 1
Готовая сборка 2

Про пирамиду тестирования слышали? Забудьте. Теперь трофей тестирования фронтенда

Концепцию трофея тестирования предложил разработчик библиотеки testing-library - Kent Dodds.
И она максимально точно описывает, каким должно быть тестирование

Несколько тезисов

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

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

e2e тесты
Сложны в поддержке, нужно поднимать окружение, думать об изоляции. Более подвержены поломке, недоскролилась страница, API не ответил и тд. Покрываем максимально важный функционал.

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

Скриншот тесты
Проверяем что кнопка реально 100px в ширину и желтая. Тут нам в помощь storybook. Круто, если в приложении уже описаны стори для компонент, тогда их будет проще покрыть скрншотами.

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

https://amorgunov.com/posts/2023-04-01-testing-trophy/

Про надежность интеграционных тестов на фронте

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

При том, что сама бизнес логика не изменилась.

Функциональность заключается в том, что есть компонент, который позволяет вводить правила на заранее заданном языке. Этот язык мы разработали самостоятельно, и он позволяет гибко настраивать бизнес правила. На фронтенде для ввода этого языка используется популярная библиотека monaco-editor.

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

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

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

1. Пользователь рендерит форму фичи
2. Пользователь заполняет форму
3. Пользователь нажимает на кнопку "Создать"
4. Проверяем, что отправился POST запрос с параметрами

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

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

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

Кстати, отличная подборка статей на тему тестирования.

Там и про зачем и про как

List virtualization performance pattern

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

Один из таких это list virtualization. Часто на собесах ребята называют его (что уже отлично), но не все знают, как он работает.

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

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

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

Вот несколько библиотек, которые помогут в реализации списка с виртуализацией

react-virtualized

react-window

react -window-infinite-loader

Также на этом сайте много крутых практик проектирования фронтенда

Reactivity patterns in vanilla javascript 🚀

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

Проблема в том, что часто мы связываем реактивность с фреймворками. Это сужает понимание области применения реактивщины и паттернов в целом.

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

🟣Pub Sub pattern
Автор показывает реализацию паттерна с помощью простого объекста js, у которого по сути 2 метода subscribe, и publish. А все подписки хранятся в объекте формата

{ 'eventName': [ callback1, callback2, ... ] }

Также в Browser API есть реализация этого паттерна в интерфейсе EventTarget, когда мы подписываемся на событие, а при вызове события срабатывает callback, который на него подписан

addEventListener('some event', callback)
dispatchEvent('some event')

Авто показывает реализацию этого интерфейса кастомным классом

🟣Observer pattern
По сути этот механизм похож на pubSub. Мы все также имеем события и подписчиков на эти события. Единственное исключение, что у нас появляется механизм отписки

🟣Proxy pattern
С помощью Proxy объекта мы можем добавить функциональность базовым свойствам объекта и реагировать на добавление, удаление или определение свойства. Такой паттерн может использоваться для логирования, преобразования входных и выходных параметров перед их применением

Автор показывает пример использования базового интерфейса Proxy в javascript

🟣Прямое переопределение поведения свойств объекта
Пример похож на предыдщуий, но тут мы напрямую переопределяем базовые методы get и set для конкретного свойства объекта с помощью метода
Object.defineProperty

Object.defineProperty(object, prop, handlers)

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

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

    const updates = this.subscribers.map(async (callback) => {
      await callback(key, value);
    });

    await Promise.allSettled(updates);

🟣Observables (rx.js)

Самыми популярными реализациями observable являются библиотеки rx.js и mobx

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

Автор рассматривает реализацию observable на чистом javascript

🟣Signals (SolidJS)
Концепция сигналов активно используется во фреймворке solidJS. На гитхабе есть реализация этого паттерна от разработчика фреймворка

Концепция в том, что у нас есть функция которая хранит в замыкании значение, а изменении оповещает подписчиков. реализация прдеставлена в функциональном стиле и похожа на useState в react

const [read, write] = createSignal(null);

🟣Reactive rendering

Автор просто демонстрирует механизм изменения в html (innerHTML) как реакцию на изменение данных в объектах javascript

🟣Reactive DOM attributes
С помощью MutationObserver можно подписываться на изменение атрибутов в html и реагировать на это

🟣Reactive Attributes in Web Components
Такой же механизм отслеживания изменений в атрибутах, но с помощью Web Components

🟣Reactive scrolling IntersectionObserver
Еще один пример как можно задавать свое поведение и реагировать на скролл с помощью нативного интерфейса IntersectionObserver

А также реактивная анимация и реактивный css подробнее в статье

Подъехала новая статья: "Сетевая инфраструктура - от основ до Дата Центров".

За 10 лет работы инженером у меня накопилось много вопросов о сети, часть из которых я либо не знал, либо не понимал. Сеть эффективно скрывает от нас всю свою сложность, делая нашу жизнь проще. Но иногда эти пробелы в знаниях сказывались, например:
- Когда меня спросили на собеседовании про Level 3 и Level 4 балансеры.
- Когда я стал лидить проект, связанный с инфраструктурой (создание Cassandra as a Service)
- Так и при проектировании высоконагруженных систем, когда требуется глубокое понимание сети для оптимизации и правильного дизайна.

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

В статье вы узнаете:
- Что такое OSI Level?
- Как функционируют TCP/UDP/QUIC? Что такое пакет, фрагмент, датаграм?
- Как устроена сеть между клиентом и сервером. Что такое ISP, BGP, Anycast?
- Что представляют из себя Edge networks?
- И в заключение — как устроена сеть в дата-центре компании Meta.

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

На русском: https://amarchenko.dev/blog/2023-10-02-network/
На английском: https://amarchenko.dev/translate/2023-10-02-network/

Temporal API скоро избавит от боли при работе с датой и временем в javascript

Работа с датой и временем всегда была проблемой в javascript. API интерфейса Date очень беден и неудобен. В особенности, когда приходилось делать что-то большее, чем просто сравнивать даты. При этом инстанс объекта, который мы получаем из Date мутабелен по мере применения методов. Сложно было форматировать дату в нужный формат и также учитывать таймзону. Невозможно легко добавить часы, минуты, секунды к дате

Из-за этого приходится постоянно эксперементировать с библиотеками momentjs, date-fns, luxon. Это накладывает ограничение на работу с языком. Не хватало нативного способа.

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

Что дает temporal api?

- Простое API для вычисления и форматирования даты
- Объект даты имутабелен
- Возможность учитывать таймзону, переход на летнее время
- Объект для Calendar

В статье рассматривается более подробно возможности temporal api. А для того, чтобы добавить поддержку к себе в код, можно использовать полифил @js-temporal/polyfill

Доклад на Frontend Conf про trunk based development

Вкратце TBD это подход к организации релизного процесса и флоу работы в репозитории

В презе отлично рассказывается на примере из практики, какие проблемы были в Git Flow в команде, на что эти проблемы влияли и как их спас TBD

Тезисно требования для внедрения TBD
- Все ветки кроме мастера живут максимум 2 дня
- Все merge request напрямую в мастер и сразу с тестами
- Маленькие задачи
- Требует почти 100% автоматизации тестирования
- Нужны фича флаги для неготовых фич

Преимущества
- Мастер всегда готов к релизу
- Уменьшает time to market идеи
- Можем деплоить код неготовых фич
- Быстрое ревью
- Шаринг знаний

Трудности при внедрении
- Сложная настройка CI для полной автоматизации
- Навык построения абстракций и декомпозиции
- Требует устоявшихся процессов в работе, зрелости команды