​Пора переходить на микрофронтенд?

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

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

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

Микрофронтенд бывает горизонтального (по функциональным блокам приложения) и вертикального разделения (по сервисам/модулям и их доменам). Архитектурный подход организуют с помощью одного из 3 самых популярных фреймворков: Podium, Single-SPA и Module Federation.

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

1. В вашем приложении сложная функциональность, над которой работают две и более команды (например, вы реализуете несколько продуктов и код всего приложения громоздкий)?
2. Вам часто приходится интегрировать компоненты фронтенд коллеги/другой команды, которые работают над другой функциональностью приложения?
3. Вам приходится ждать, когда компоненты другой функциональности приложения обновятся, и это тормозит вашу работу?
4. Компоненты в интерфейсе долго грузятся у пользователя при авторизации в приложении и переходе между модулями/решениями?
5. Вам нужно сделать плавный переезд с одной технологии на другую (например, с JS на библиотеки React/Angular/Vue)?

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

👉 @seniorFront

​Принципы общения с людьми при провалах — тезисы для обретения дзена

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

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

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

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

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

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

Больше пунктов в статье

👉 @seniorFront

Color Gradient Feature Table

Эта таблица реализована с использованием Pug и CSS. Настройки завязаны на CSS переменные, значения которых изменяются в JS.

👉 @seniorFront

Password Strength Checker in Javascript

В этом видео создается форма ввода пароля на HTML и CSS. В JS создается логика проверки сложности пароля.

👉 @seniorFront

👉 @seniorFront

Infinite Portals

Создано и анимировано на canvas с использованием возможностей THREE.js

👉 @seniorFront

Bubbles (CPC)

Свёрстано и анимировано на HTML и SCSS.

👉 @seniorFront

Direction-Aware Text Hover Effects

В этом видео создается анимация при наведении на текст, которая меняется в зависимости от места наведения курсора.

👉 @seniorFront

Greyscale Infinite Swiper

Создано на React и стилизовано в SCSS.

👉 @seniorFront

Christmas Trash Party

Вы получите trash1 и trash2, которые могут иметь следующие значения:
[], false, '', new Array(), null, NaN, undefined, 0, -0, 0n, -0n, '0'.

Вы должны вернуть булево значение, если они строго равны.

Примечание:
тройное равенство === и строгое неравенство !== не допускаются

Пример:
compareTrash(0, false) => false
compareTrash('', '') => true
compareTrash([], 0) => false

👉 @seniorFront

Не бойтесь бросать свои пет-проекты

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

Выводы, к которым автор пришел:
Вместо того, чтобы подходить к своему первому проекту чисто из амбициозных соображений или чтобы впечатлить работодателя, взгляните на него в первую очередь как на способ изучить новые возможности. Как только вы наберётесь достаточно опыта (то есть заброшенных пет-проектов), остальное придёт само. Личные проекты должны быть креативными и интересными. Если вы заметите, что вас начинает беспокоить срок готовности вашего начинания или, хуже того, если вы из-за него начнёте выгорать, то не мешкая бросайте. Велика вероятность, что при внимательном рассмотрении вы заметите немало ценности, которую он вам уже принёс.

👉 @seniorFront

​Более надёжные кастомные чекбоксы с псевдо-классом focus-within

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

 <body>
   <div class="custom-checkbox">
     <input id="cb" type="checkbox" class="custom-checkbox__input">
     <label class="custom-checkbox" for="cb">Запомнить данные</label>
   </div>
 </body>

 .custom-checkbox__input:focus + .custom-checkbox__label::before {
   outline: 3px solid #222;
 }

Есть специалисты, которые нашли недостаток этого способа. По их мнению, часто происходит так, что люди случайно вставляют элемент <input> в другое место. По этой причине селектор перестаёт работать.


Думая над решением этой проблемы, ко мне пришла мысль: «А почему бы не заменить соседнего родственного комбинатора + на псевдо-класс focus-within?». Ведь данный псевдо-класс срабатывает, когда сам элемент или кто-то из его дочерних элементов находится в фокусе. И в случае использования его в нашей задаче, получится так, что позиция элемента <input> неважна.


Заменим фрагмент кода с комбинатором + на псевдо-элемент :focus-within.

 .custom-checkbox:focus-within .custom-checkbox__label::before {
   outline: 3px solid #222;
 }

Мне кажется, даже код выглядит «красивее». А вы как думаете? Напишите в комментариях.

👉 @seniorFront

CSS animated SVG

Это SVG картинка, стилизованная и анимированная в SCSS.

👉 @seniorFront

Неразрешимые проблемы программирования

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

Собеседования
Мы сейчас ограничимся программистской спецификой. Понятно, что у рекрутеров, тимлидов и HR-менеджеров свои трудности с соискателями. Вольётся ли человек в коллектив? Это не наша забота. Наша забота — за час времени определить технический уровень кандидата.

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

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

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

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

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

Код-ревью
Здесь прекрасно всё, даже трудно выбрать, с чего начать. Да, вы и сами всё знаете.

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

Когда нас называют идиотами, мы конечно, возмущаемся. А когда мы называем идиотами — нет.

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

👉 @seniorFront

​Хороший парень, плохой код: доброта дороже денег?

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

Робин Гуд наоборот
Представьте, что вы — суперпонимающий, эмпатичный тимлид. У вас возникает соблазн оставить этого неэффективного разработчика просто потому, что он хороший человек. Но вот в чем загвоздка: по сути, вы будете платить ему из денег, заработанных его коллегами, теми, кто действительно выкладывается, фигачит овертаймы и вносит свой вклад в успех проекта. Такой вот странный сценарий Робина Гуда, только он отбирает у работящих, чтобы отдать... ну, не очень работящим.

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

Если же это не помогло, вариантов два:
Рефакторинг. Скорректировать зарплату разработчика в соответствии с его реальным вкладом. Это может показаться жестким, но это способ сохранить справедливость и обеспечить всем соответствующее вознаграждение.

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

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

👉 @seniorFront

Squidematics

Реализовано на canvas и JS без использования библиотек для создания анимаций.

👉 @seniorFront

Awesome Cursor Animation on Mousemove

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

👉 @seniorFront

Когда решил запустить программу, которую написал без тестов:

👉 @seniorFront

Rotating 3D Slider

Логика поворота слайдера реализована в JS. Стилизовано в SCSS.

👉 @seniorFront

animated icons

Это SVG картинки, анимируемые в SCSS при наведении.

👉 @seniorFront