Фронтенд из трущоб


Channel's geo and language: Russia, Russian
Category: Technologies


Фронтенд клуб любителей и профессионалов.
По любым вопросам и комментариям писать сюда - @stan_kh

Related channels

Channel's geo and language
Russia, Russian
Statistics
Posts filter


Один ESLint - много проектов

Вы наверное помните что на моём текущем проекте мы ввели архитектуру микрофронтендов. Количество репозиториев растёт, а хорошее качество кода никто не отменял. На всех проектах мы используем ESLint, который запускается в редакторе после сохранения и автоматически форматирует код. Для того чтобы обеспечить что ничего кривого-косого не попадёт в master мы дополнительно запускаем ESLint на каждый коммит с помощью Git Hooks.

Почему не Prettier? Коротко ответить на этот вопрос довольно сложно, но если постараться то ответом будет Vue. Мы используем Vue декораторы и TypeScript, и то форматирование которое выдавал Prettier мне абсолюнто не нравится. Да и в целом, даже без Vue мне не очень нравятся некоторые из обязательных правил Prettier, такие как длина строки и то как он автоформатирует под это ваш JavaScript. Я сделал несколько попыток заменить ESLint на Prettier, но все они были неудачными.

ESLint меня устраивал на все 100%, но есть один ньюанс. Мы создали шаблон для каждого нового микрофронетнда, который достаточно склонировать из Git, поменять несколько названий, порт для localhost, и вы уже можете использовать этот микрофронтенд в основном приложении. Этот шаблон содержит конфиг для ESLint, в котором есть набор правил которым мы следуем. На днях я понял что не хватает несколько правил, и понеслась. Я добавил 2 правила в один из микрофронтендов, и для того чтобы эти правила применить к остальным проектам мне нужно было пройтись по каждому репозиторию и создать Pull Request. В данный момент у нас 5 микрофронтендов, и это очень раздражающий monkey-job.

Я подумал о том что большие компании заливают свои конфиги на NPM, такие как eslint-config-airbnb. И вправду, даже если у вас самый секьюрный проект, где вы работаете с данными которые не должны уйти за пределы вашей системы, пошарить свой конфиг и залить его NPM это довольно безопасно. Это всего лишь ваш code style, и конвенции по которым вы пишете код. А если вы еще и назовёте пакет именем вашей компании, то возможно даже привлечёте новых людей в команду.

Оказалось это довольно просто, и ребята с ESLint команды прекрасно описали это у себя в документации. На всё про всё у меня ушло всего 3 часа, и теперь все микрофронетенды просто добавляют новый пакет в package.json и пишут extends: ${scope}/eslint-config в своём .eslintrc. Все правила будут унаследованы с вашего конфига, и всё что нужно сделать в следующий раз это добавить новые правила и запаблишить новую версию на NPM.

Не скучай — ESLint подключай, котик! 🐈

======

Вічна Слава Україні та усім героям, а русский военный корабль - пошёл нахуй! 🇺🇦


Объясни простыми словами

Если вы хотите проверить Senior разработчика на прочность, попросите его объяснить что-то сложное простыми словами. На самом деле такая стратегия работает не только в программировании, а практически во всех сферах нашей жизни.

Всегда во время собеседования на позицию Senior и выше я задаю несколько вопросов и прошу ответить кандидата так, как бы он ответил на этот вопрос начинающему Junior’у. Один из самых попсовых вопросов это объяснить как работает функция reduce на массиве, и тут начинается... Один говорит что “функция reduce считает сумму элементов в массиве”, что лишь частный случай использования reduce, а другой отвечает что “функция reduce выполняет callback reducer записывая промежуточный value в аккумулятор передав начальное значение… бла бла бла”. У обоих ответов есть негативные последствия. В первом случае наш Junior уйдёт с ложными знаниями, а во втором случае он просто ничего не поймёт и подумает что дальше спрашивать особо нет смысла.

Другой пример это когда собираются 2 команды — бекенд и фронтенд, и начинают обсуждать какие-то breaking changes или совершенно новые фичи. Моя любимая часть начинается когда один из бекендщиков встаёт и заявляет: “Мы короче планируем прикрутить Redis в кубере, вы там по сокетам подключитесь и всё заработает, может воркер какой-нибудь еще понадобится, посмотрим”. На самом деле его предложение имеет смысл и прекрасно решит бизнес задачу, но он забывает учесть один факт. Скорее всего, многие из фронтенд команды понятия не имеют о чём он говорит. Да и часто на таких встречах присутствуют менеджеры, бизнес аналитики и другие ребята, для которых это вообще тёмный лес.

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

Здесь есть 3 состояния:
1) Вы играли в Дота 2 и полностью понимаете о чём речь (вы и есть тот бекендщик предлагающий прикрутить Redis)
2) Вы играли в League of Legends или Warcraft 3 и частично улавливаете знакомые слова (вы тот фронтендщик, который услышал только воркер и сокет)
3) Вы не играли в Дота 2 и похожие игры (вы тот самый ПМ, который ждёт когда же это всё закончится).

В этом всём есть одно большое НО, говорить сложным языком абсолютно нормально и даже правильно когда ты уверен что все понимают этот домен. Когда вы собрались фронтенд командой то можете смело предложить использовать декораторы для PropTypes во Vue 2, или переписать все сервисы на behaviorSubject в вашем новом приложении на Angular. Но как только в разговор включается PM, QA, бекенд команда — просьба сбавить обороты, котик 🐈


Боль при работе с микрофронтендами

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

Самой большой болью при работе с архитектурой микрофронтендов является общий код. Как оказалось, если ты “разделываешь” свой большой монолитный проект на микрофронтенды, то замечаешь что абсолютно всё завязано на всём.

Store у всех приложений один, большое количество shared компонентов, да даже axios интерсепторы и синглтон с ролями пользователей шарятся между всеми страницами. А как насчет функций из папки “utils” которые фильтруют данные особым образом? Всё очень завязано, потому что с самого старта работы никто даже не думал про введение новой архитектуры. И весь этот общий код начинает плавно переезжать в отдельные репозитории, и здесь главное быть в адеквате и не перетрудиться.

Первым shared репозиторием стал наш ui-kit, или иначе библиотека компонентов. Во всех репозиториях мы использвовали Material UI, но над некоторыми его компонентами мы надстраивали свои еще более умные компоненты. К примеру у нас был не просто прогресс бар, а крутилка с прогрессом, логотипом компании и градиентной заливкой. И вот если в другом микрофронтенде тебе нужен этот компонент, то тебе нужно перенести его в репозиторий “companyName/ui-kit”, добавить документацию в storybook, закоммитить изменения, зарелизить новую версию библиотеки и залить её в npm. Нехило как для одного маленького компонента, правда?

Вторым shared репозиторием стала библиотека функций, которая содержала axios с его логикой получения и хранения токена, всяческие интерсепторы и другие utils функции. И здесь подход был такой же, переносим функции в отдельный репозиторий “companyName/utils”, добавляем документацию (если нужна), коммитим, релизим новую версию, заливаем в npm.

После того как новая версия готова, ты идешь в свой микрофронтенд и обновляешь этот пакет в package.json. Первые пара недель проходили именно в таком ритме, в постоянных релизах библиотек и головной боли. И пожалуй единственный момент который меня радовал это то что везде используется TypeScript. Поэтому нам не приходилось писать никакие typings чтобы понять какие аргументы принимает та или иная функция, или какого типа передавать props в shared компонент.

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

Я пошёл дальше воевать с новой архитектурой, и надеяться что у тебя на проекте всё более спокойно, котик 🐈


Сумасшедшая архитектура, или как мы вводили микрофронтенды

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

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

Я сразу же решил отбросить мысли об iFrame и попробовал посмотреть что есть на рынке JavaScript на сегодняшний день. Во-первых для такого рода задач был введён специальный термин “микрофронтенд”, что пошло от всем известных “микросервисов” на бекенде. Во-вторых все эти подходы довольно современные и требуют большое количество фич из ES6, и поддержка в каких-то старых браузерах просто невозможна. В-третьих технология действительно еще сыровата, и можно наткнуться на множество невалидных статей и рекомендаций.

Когда нужно задуматься о введении архитектуры микрофронтендов?
- Если вы хотите чтоб над отдельными частями вашего приложения работала другая команда и ваш код не пересекался
- Если ваш репозиторий уже слишком жирный и вы сами начинаете в нём теряться
- Если ваше приложение пишется под нескольких кастомеров и у каждого свои “хотелки”
- Если вы хотите продавать фичи за дополнительную плату (к примеру страница аналитики с графиками за +5000$ в год)

После длительного инвестигейта мы остановились на Single SPA framework, который начали постепенно вводить для нашего проекта. Это была дорога боли и страданий, нерабочих решений и невалидных статей, но по итогу мы получили то к чему шли. За 15 рабочих дней (3 недели) нам удалось полностью уйти от монорепозитория и получить 4 отдельных репозитория, каждый из которых является самостоятельным приложением, которое может легко встроиться в другое с помощью роутера.

Далее мы обсудим какие проблемные места в современных микрофронтендах и на что нужно обратить внимание перед введением этой архитектуры.

Надеюсь ты еще не расплавился от такого жаркого лета, котик 🐈


Emmet plugin или как писать HTML со скоростью света

Сейчас нам не приходится писать большие куски HTML кода как раньше… На смену длинному полотну из HTML тегов пришли компоненты, а на смену кастомным дропдаунам и таймпикерам пришли готовые решения. Сейчас мало кто решается на создание собственной системы компонентов с нуля, и чаще кастомизирует готовый UI Kit такой как Bootstrap или Material UI.

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

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

Написание разметки для меня это всегда что-то наподобие:

.container>.row>div.col-sm{test $}*3

Для быстрого теста можете вставить эту строку в любое место в вашем HTML и нажать Tab (для VSCode нужно включить эту опцию). Эта странная с первого взгляда строка превратится в солидный кусок HTML разметки:



test 1
test 2
test 3



Плагин и вправду позволяет ускорить вашу работу с HTML разметкой, но так же он умеет работать с CSS. К примеру mt20 превратится в margin-top: 20px;, а вот аббревиатура ovh превратится в overflow: hidden.

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

И напоследок, котик, не забывай использовать теги из HTML5, а то уже как бы 2021 год на дворе 🐈


“Не нужно мне ваше ООП” (c)

Последние пару недель я провожу очередной найм на позицию Middle+ / Senior разработчика, и частенько такие серии собеседований меня разочаровывают. Ко мне приходят кандидаты, одни сильнее, вторые слабее, но объединяет их одно — “Я не работал с TypeScript”.

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

Если человек никогда не работал с ООП то в 99% случаев это значит что он не разбирается в:
- Паттернах проектирования
- Структурах данных
- Абстракциях и наследовании

Когда мы говорим про Junior разработчиков, то их основная задача следовать правилам и всем best practices которые заведены на проекте, но когда мы говорим про позицию Middle+ и выше, то эти люди и будут устанавливать эти правила и best practices. На проектах использующих TypeScript и написанных в ООП стиле обязательно должен быть человек, который не падает в обморок при словах абстрактный класс и generics, который способен быстро набросать диаграмму классов и изучить .d.ts файлы для используемой библиотеки.

Хотим мы работать с TypeScript или нет это уже другой вопрос, но с каждым годом количество проектов на TypeScript стремительно растёт. За последние пару лет эта технология просто взлетела, и сейчас каждое второе предложение на рынке требует опыта работы с TS. Далеко ходить не нужно, еще ECMAScript 6 ввёл классы и нормальный синтаксис для наследования, а в ES2021 были предложены приватные поля, которые уже хорошо поддерживаются во многих браузерах. Эти фичи дают новый скачёк для JavaScript в сторону более зрелых объектно-ориентированных языков, и поверьте мне на слово — дальше будет больше.

Подведя черту, я считаю что для любого фронтенд разработчика знание ООП и умение понимать код на TypeScript это must have. А если в этом багаже знаний будут еще и паттерны проектирования — превосходно! Даже если вам и дальше будут попадаться проекты на чистом JS помните, что тот кто умеет писать на TypeScript может легко работать с нативным JS, а вот наоборот это не работает.

Котик, думаю самое время освежить свои знания в ООП 🐈


Кошачий английский #5: Фразы на каждый день

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

Are you still around? - дословно переводится как “Ты всё еще здесь?”. Отлично работает когда вы не знаете работает ли еще человек, или уже ушёл домой (в наше время - закрыл ноутбук).

I really appreciate it / Awesome job, thanks a lot / That’s much, much better - фразы, которые помогут вам поблагодарить и похвалить человека, который выполнил для вас какую-то просьбу. Станет прекрасной заменой попсовому “thank you” так как имеет еще и эмоциональную составляющую.

The more …, the less … - американцы как и мы очень любят сравнивать как зависит полученный результат от начальных условий. Например “The more bugs we close, the less questions we’ll have on the demo”. Вместо more и less могут быть любые варианты сравнительных прилагательных - “The more memory we allocate to the Docker, the faster it can train the models”. Почитать больше тут.

My apologies, I have to jump off to another meeting - Быстро и вежливо сваливаем с митинга в Zoom и т.п.

Last but not least - переводится как “последнее, но не менее важное”. Американцы частенько говорят эту фразу когда доходят до последнего элемента в списке во время презентации, или давая свой фидбек. Вы тоже можете использовать это во время демо, когда доходите до последней фичи, которую собираетесь показать.

Тем временем длинные выходные позади, время возвращаться к работе. Кстати, как прошли майские праздники, котик? 🐈


Я не умею писать регулярки

Мой путь в JavaScript начался с прочтения настоящей “библии” фронт-енд разработчика, а именно книги Девида Фленагана “Подробное руководство JavaScript”. На тот момент это было шестое издание, и с того времени много воды утекло. Когда сегодня меня спрашивают с чего начинать учить JavaScript и фронт-енд разработку я всегда теряюсь, поскольку всё что было актуально в моё время уже потеряло свою силу.

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

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

Единственный валидный пример использования регулярок в моём коде, это был метод String.replace(). Когда мне нужно было заменить все вхождения в строке, мне приходилось закидывать первым аргументом регулярное выражение с флагом /g, для того чтобы заменить все совпадения. Думаю вам эта ситуация так же хорошо знакома:

“Bobby and Bob”.replace(/Bob/g, “Tob”); // result - “Tobby and Tob”

На днях я столкнулся со статьей про новые фичи ECMAScript 2021, и наконец это свершилось — мы получили новый метод String.replaceAll() заменяющий все совпадения строк. Метод довольно свежий, но уже нативно поддерживается всеми современными браузерами кроме IE. С выходом этого метода я говорю регулярным выражениям “до скорых встреч”, и возможно мы увидимся с ними на каком-нибудь специфичном проекте в будущем.

При этом, я не говорю что регулярные выражения бесполезны, и есть множество проектов где без них не обойтись (сложные парсеры файлов, WYSIWYG редакторы, подсветка синтаксиса кода). Но как по мне, то потратить это время на изучение основ Докера будет куда полезней, котик 🐈


Нужно ли техническое образование фронтенд разработчику?

Сколько же раз я слышал этот вопрос… Ответ не слишком уж простой — и да и нет. На самом деле всё зависит от того на каком вы работаете проекте и какую занимаете позицию. У меня вот есть техническое образование и я вдруг поймал себя на мысли, что на моём текущем проекте это и вправду помогает.

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

Да, ситуация и вправду вырожденная. Специфика моего проекта это machine learning, и как не крути ты должен иметь базовые понимания в области ML & AI. Вам может показаться что остальная работа фронтендщика это кнопочки да формочки, но поверьте и там иногда приходится вспоминать школьную программу (простой пример — отобразить линию, показывающую с помощью CSS градиента процент заполнения формы).

Программист это в первую очередь инженер, который решает задачи аналитическим путём. Зачастую все сложности и тонкости внутренней реализации скрыты от нас (прекрасные примеры это RxJS, D3.js, lodash), но поверьте мне на слово, это не будет продолжаться вечно. Каждый ваш прыжок вверх по карьерной лестнице будет вести в мир задач, у которых нету готовых решений. Тогда то и придётся прокачивать свои аналитические способности, другого выхода нет.

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

Я считаю что любой человек способен освоить любую профессию, главное — это найти дело, от которого ты получаешь удовольствие, котик 🐈


Daily stand-up

Дейлики… Это же целая отличительная черта всего IT сообщества. Я постоянно слышу разговоры на кухне как кто-то не успел на дейлик, или сегодня дейлик отменили, или что какой-то Серёжа постоянно затягивает наши стенд-апы. До сих пор у меня ни разу не было проектов, на которых нет дейли митингов. Залетая на новый проект ты всегда спрашиваешь в какое время будут стенд-апы, подразумевая что без них проектов в принципе не существует.

Я посетил больше тысячи стенд-апов, и из проекта в проект я замечаю одни и те же проблемы. Когда ты Junior разработчик, твоя основная задача “отрепортил - и пошёл работать”, а вот когда ты на позиции Senior или Lead, твоя задача еще внимательно слушать то, что репортят другие. Ты должен быть максимально вовлечён в процесс разработки, и понимать кто, когда и зачем этим занимается. Ниже приведу плохие примеры репортинга, которые я настоятельно советую избегать:

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

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

2) Не ссылайтесь на встречи / созвоны, на которых не были все участники стенд-апа.

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

3) Старайтесь избегать общих терминов, давайте больше конкретики

Плохой пример: “Я продолжаю заниматься рефакторингом основных модулей”.
Хороший пример: “Вчера я занимался рефакторингом модуля платежей, а сегодня буду рефакторить модуль системы бонусов для Premium пользователей”

Надеюсь, что тебе не приходится сидеть и слушать “плохие примеры” на своих стенд-апах, котик 🐈


Что делать если не сростаются отношения с заказчиком?

У меня было много разных заказчиков. Была и Европа, и Азия, и Америка, и Канада, не было пожалуй только Африки и Австралии. Я познакомился с огромным количеством умных и продвинутых людей, которые вдохновляли и критиковали, восхищались и огорчались, хвалили и ругали…

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

Как-то раз у меня прямо не сходились характеры с моим заказчиком. Вот от слова совсем. Я инициативный — он консерватор, я хочу подумать над оптимальным решением — он просит задачу на вчера, я хочу написать meeting minutes — он не хочет никакой документации. На этот момент я уже был на позиции Senior, и просто пойти сказать “ну не нравится мне с ним работать” было бы не совсем этично.

Чаще всего мне приходилось подстраиваться, находить правильные слова и приводить аргументы “за” и “против”. В какой-то момент мне казалось что на это уходит больше времени, чем хотелось, и я не понимал стоит ли это того. Тогда мой СЕО сказал мне такую фразу: “Ничего страшного, зато представь как прокачаешь коммуникацию”.

Тот момент кардинально поменял моё отношение к этой ситуации. Когда мы находимся в не комфортной среде — мы по-настоящему разививаемся. Если вы научитесь работать с не комфортными людьми, то работа с комфортными станет для вас еще легче.

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

Но я надеюсь, что сейчас у тебя самый комфортный заказчик. А если нет — то это прекрасное время прокачать свои навыки, котик 🐈


Улучшаем работу с Git

Мне нравится работать с Git. Я с ужасом вспоминаю свой первый проект, на котором мы использовали SVN. Это что-то со времён динозавров, где попросту отсутствует понятие “branch”. Простыми словами, каждая новая ветка в SVN это полная копия твоего проекта…

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

В каждом новом проекте я стараюсь еще лучше узнать эту VCS и попробовать что-то новое. Помню как мой мир перевернулся, когда я научился работать с Rebase и Cherrypick, но сегодня поговорим о не менее интересном подходе работы с Git — Conventional Commits.

Conventional Commits это простая спецификация, по которой вам нужно структурировать свои сообщения в Git. То есть каждое ваше сообщение, должно иметь определенную структуру — типКоммита(Компонент): сообщение.

Приведу несколько примеров:

feat(Dashboard): Added active players label
fix(App): Removed unused toast notifications

Кажется ничего необычного. Но, во-первых это даёт консистентную историю в Git, а во-вторых, главная фича этой спецификации это автоматическая генерация Changelog файла. Если правильно ввести версионирование на проекте, то ваш Changelog будет выглядеть вот так. На просторах npm уже достаточно много пакетов для генерации Changelog’ов из сообщений к коммитам, но самый простой из всех это generate-changelog.

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

Надеюсь, на твоих проектах больше не будет сообщений типа “small bugfix”, котик 🐈


Как вёл себя JavaScript в 2020?

Каждый год в начале января мы с друзьями... изучаем State of JS за прошедший год. Сегодня решил полистать статистику на State of JS 2020 и как всегда узнал много нового для себя.

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

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

Далее, мы можем легко провести анализ рынка по фреймворкам, которые используются по всему миру. Я конечно не самый большой эксперт, но абсолютно не понимаю что там делает Svelte на первом месте в разделе “Удовлетворённость” 😅.

Я изучаю эту статистику уже несколько лет подряд, и скажу что картинка и вправду меняется. Если раньше заинтересованность в React была на высоте, то сейчас уже упала почти до 50%. Angular стабильно теряет очки в удовлетворённости, а Vue стабильно набирает проценты в использовании (спасибо Китайским коллегам).

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

Надеюсь, что я нашёл чем тебя занять на сегодня, котик 🐈


Новогодний merge request

Котики, поздравляю всех с наступившими и наступающими праздниками🎄Спасибо каждому из вас за хорошие фидбеки, лайки, и вашу постоянную поддержку, выражаю каждому свой бесконечный респект.

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

Вспоминается мне смешная история из практики. Когда-то мы сделали простенький footer у себя на проекте, и написали в нём — All rights reserved © 2013-2015. Наступил Новый Год, начался январь и мы создали задачку на борде “Update current year in the footer”. Задача подразумевала изменение года с 2015 на 2016 прямиком в HTML коде футера.

Ничего странного не замечаете? Вот и мой коллега который поменял одну цифру в HTML коде и создал merge request ничего не заметил. А по итогу получил единственный, но очень здравый комментарий:

How about this:


All rights reserved © 2013-{{ new Date().getFullYear() }}


Теперь в следующем году придётся смотреть только под ёлку, а footer обновится автоматически. Старайся делать проще, котик 🐈


Переходим на тёмную сторону

Невероятно, но факт: каждое современное приложение внедряет тёмную тему. И если еще 2 года назад тёмную тему поддерживали только в IDE, то сейчас большинство современных WebApps имеют такую опцию. Посудите сами, GitHub, Figma, Telegram, Outlook, Pinterest, все уже внедрили так называемый Dark Mode. И как по мне главным триггером всех этих изменений стала компания Apple, внедрив тёмный режим в MacOS Mojave в 2018 году.

В Google Chrome и вовсе начали появляться extensions, эмулирующие тёмный режим, типа Dark Mode extension. Он просто инверсирует цвета, самостоятельно адаптируя UI (конечно же не без погрешностей). Хотели Wikipedia в тёмном режиме? Easy!

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

Всё было так до вчерашнего дня, пока я не получил новую задачу с эстимейтом в 2 недели — “Introducing Dark Mode”. И похоже настал тот самый момент, когда я смогу поставить тёмную тему на MacOS, в браузер, IDE и работать с тёмным проектом. Время переходить на тёмную сторону…

Кстати, в том же 2018 году появилось и новое правило CSS, проверяющее какая тема сейчас выбрана у пользователя, под названием prefers-color-scheme. Это новый вид media запроса, имеющий солидную поддержку во всех современных браузерах, кроме IE 11. Данное свойство поможет автоматически включать ту или иную тему в приложении, без введения дополнительных “переключалок” на интерфейсе.

Я думаю самое время попробовать его на production, а позже поделиться с тобой результатами, котик 🐈


Как поместиться в 13 килобайт?

Я большой фанат любых соревнований, и не важно это соревнования по баскетболу, хоккею, киберспорту или… JavaScript?

Довольно часто я пробовал решать всякие задачки на Сodewars и это всегда помогало немного встряхнуть мозг, попробовать отойти от рутинных задач с таблицами и погрузиться в соврешенно другой мир. Иногда эти задачи были настолько нетривиальными с сумасшедшими, что я чувствовал себя настоящим фронтенд хакером. Помню одну задачу на написание HTML верстки с наименьшим количеством символов… Ох как только я не извращался дабы сломать мой Google Chrome самым кошмарным HTML кодом в моей жизни.

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

Вот так вот ребята игрались во всякие войнушки, а потом это перерасло в нечто большее. И теперь каждый год проводится реальный чемпионат по Game Development’у на JavaScript, под названием js13kgames.

Суть конкурса — необходимо создать игру на чистом JavaScript, размером до 13kB. В этот размер должны входить ассеты, звуки, графика, HTML разметка, стили и JS код, то есть полный архив с игрой. Для сравнения мой текущий проект весит около 1.5MB, и это в минифицированной версии.

Если вам интересно, советую перейти на вкладку Winners и посмотреть на победителей этого года. Мои личные фавориты это Ninja vs EVILCORP и Track not found?!. Всё это доказывает огромный потенциал и безграничные возможности языка JavaScript, а нам с вами даёт возможность мотивироваться кропотливой работой профессионалов. У всех проектов открытый source код, так что дерзайте!

Предупреждаю, котик, игры настолько казуальные что есть вероятность залипнуть надолго 🐈


Динамический или как сделать красивые закладки

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

Я сразу же добавил себе закладку в браузере на главную страницу, а позже решил добавить закладку еще и на страницу создания нового реквеста. И что вы думаете? Обе мои закладки по дефолту имели название “AskHR - Your Assistant”. Теперь у меня две закладки, имеющие одинаковый favicon и название, при том что URL адреса соврешенно разные. Играем в игру “угадай ссылку”!

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

Как не попасть в капкан? Во-первых, убедитесь что вы добавили красивый favicon, он реально помогает отличать сайты когда смотришь на N-вкладок у себя в браузере. Ничего нет более унылого, чем его полное отсутствие.

Во-вторых, создавайте динамический title в своих приложениях, опираясь на отображаемый контент. Хорошие примеры это “AskHR - New Request” или “AskHR - Dashboard”. Далеко ходить не нужно, просто посмотри на свои закладки в браузере для хороших примеров.

Сделать такой трюк с динамическим title довольно просто, нужно лишь отлавливать изменения в роутере и переприсваивать значение document.title. На всякий случай подготовил ссылочки с примерами под все фреймворки: React, Vue, Angular.

А вообще, когда твой проект хотят добавить в закладки — это уже маленькая победа, котик 🐈


Демо фронтенда (часть 3/3): Целевая аудитория

Пожалуй, эта часть будет самой важной из всей серии.

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

Самый важный критерий — это оценить является ли аудитория технически подкованной, или нет. Если вся аудитория технически подкована, то смело можем использовать наш технический словарный запас, и без особых угрызений совести использовать слова “bundle, performance, docker, cluster, component, module” и так далее.

Но, последние годы я работаю на стартапах, и здесь ситуация кардинально отличается. На моих демо митингах участвуют абсолютно разные люди, это как development team, так и sales, marketing и иногда даже top management. Все эти люди приходят посмотреть на результат, на рабочий продукт, и моя задача презентовать его как “рабочий продукт”.

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

Я больше недели занимался оптимизацией производительности нашего проекта, что позволило уменьшить размер финального бандла более чем на 2.5Mb. Но я знал, что если я вставлю слайд с текстом “Размер финального бандла был уменьшен с 5.2Mb до 2.7Mb” то это не скажет ровным счётом ничего для marketing команды. Поэтому я замерял скорость загрузки страницы с помощью Lighthouse, и сделал слайд с текстом “Мы ускорили первоначальную загрузку страницы на 40% (1.4s vs 2.5s)”. Этот слайд показазывает всем участникам демо почему задача, на которую мы потратили полтора спринта, была настолько важной и значимой.

Кстати, у меня тут скоро демо, так что время идти готовиться, котик 🐈


Демо фронтенда (часть 2/3): Подготовка к митингу

Этап 1: Тестируем функционал перед демо

Я всегда шёл по такому пути, у меня есть сейчас day-to-day задачи, демо митинг не самое важное в моей работе, поэтому выделю 20 минуток перед самим демо и потестирую как всё работает. На практике это провальный вариант. Если вдруг вы найдёте баг прямо перед демо митингом у вас абсолютно не будет времени его исправить с помощью hotfix’а. Так что я рекомендую проводить тестирование за 3-4 часа до демо первый раз, и потом за 20 минут до начала демо еще разок, на всякий случай.

Этап 2: Не теряем нить рассказа

Вы наверняка думаете, да не нужны мне никакие списки, я прекрасно помню чем я занимался во время спринта. И всё бы ничего, пока во время демо к вам не прилетает тонна вопросов от заказчиков — “А что будет если нажать на плюсик”, “А что это за зеленый кружочек”, “А можем еще раз открыть диалог”. Иногда такие сессии вопрос-ответ затягиваются и человек показывающий демо полностью теряет нить того, на чём остановился. Поэтому я рекомендую всегда составлять для себя список того, что будем показывать, и двигаться сверху вниз по приоритетам во время митинга.

Этап 3: Объясняем “что это и для чего”

Существует несколько факторов сделать так, чтобы вас было интересно слушать. В первую очередь вы должны понимать почему с точки зрения бизнеса появилась эта фича, другими словами почему это важно именно вашим пользователям. Если каждая твоя фича или багфикс будут подкреплёны “Это сделано для того, чтобы …”, или “Это позволит нашим пользователям…” — это создаст впечатление полной отдачи и понимая целей всего проекта. Прогоняй в голове текст и то, что хочешь рассказать во время демо, тогда будешь чувствовать себя максимально уверенно.

Котик, я даю гарантию что твоё демо пройдёт на easy, если будешь готовиться по этому списку. Иначе можешь кинуть в меня помидор 🐈


Демо фронтенда (часть 1/3): Почему это важно?

Я большой фанат демо-митингов, и за свою карьеру провел уже более сотни демок. Это была дорога взлетов и падений, от ужасных демо, где переставало работать абсолютно всё, до демонстрации MVP, перерастающего в проект из 20+ человек. За всё это время я смог сделать огромное количество выводов, и пришло время поделиться ими с вами.

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

Ни одному реальному юзеру не важно какая крутая у вас микросервисная архитектура на Java, как круто у вас настроен deployment через GitLab CI или как вы заменили свой старый Long Polling на использование WebSocket’ов. Мы то с вами знаем, что всё вышеперечисленное является критически важным для создания хорошего приложения, но для пользователей иметь вес будет только ваш User Interface и его работоспособность.

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

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

И об этом мы поговорим в продолжении…

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

20 last posts shown.

694

subscribers
Channel statistics