inputmode="numeric”

Если вам нужен инпут с только числами, без точек, запятых, минуса и “e” (1e2 == 10**2 == 100), то можно попробовать использовать inputmode="numeric”, который как-то там должен поддерживаться на мобилках, но на десктопах ведет себя непредсказуемо.

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

UPD: а не, плохо я тестирование провел, проблема с очисткой поля от компонента юйкита.

Про идею приложения для заметок. Про m5stack и toit.

Лид

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

Разберем основные из них:

1) Ревью пул/мердж реквестов и общая настройка этого процесса.
2) Поддержание качества кода соглашениями и автоматизациями.
3) Поддержание морального духа и интереса к разработке, организация общих технических событий.
4) Архитектура: понимание и контроль перспектив кодовой базы и ее потенциальной сложности обслуживания.
5) Техническая инфраструктура: как билдить, превьюить и паблишь, как переиспользовать библиотеки / конфигурации сборки и тп.
6) Проектная инфраструктура: как ведется документация, как пишуться тесты, как синкается беклог и работа над кодом и тп.
7) Технический менторинг, прокачка членов команды.
8) Формирование команды и проведение технических интервью.

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

Как стать лидом? Как под руку подвернется, главное иметь наставника в этом деле, как и в любой другой роли. Для этого нужно работать в большой компании с другими лидами и их комитетом или нанимать ментора, например, на getmentor.dev (не реклама, все равно спросили бы).

The last, but not least. Лид не должен знать вообще все, он может косячить и может во многих аспектах быть не так продвинут как члены его команды. Лид - это роль, такая же как любая другая в разработке. Вопрос лишь в опыте, зонах и количестве ответственности.

middleware VS decorator

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

Важнее то что наличие мидлвары всегда implicit (не явное) для интерфейса домена, а вот наличие декоратора explicit (явное), что выражается, например, в изменении входных параметров.

Мидлвара добавляется в общий сервис обработки фич и описывает (обрабатывает) общую для всех логику. Декоратор добавляется точечно к каждой фиче и настраивает ее индивидуально.

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

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

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

Как мониторить перформанс в React

Собрал гайд по тому, как настроить свой мониторинг React-перформанса — как с живыми пользователями, так и синтетический. Со всеми подводными камнями, про которые знаю: https://3perf.com/blog/react-monitoring/

Зачем это всё
Мой любимый ответ на «как сделать, что приложение оставалось быстрым» — это настроить мониторинг перформанса. Это, конечно, не решает все проблемы (дашборд с мониторингом ещё нужно смотреть, а увиденные проблемы — исправлять), но помогает.

Челленж в том, что готовых инструментов для React-перформанса нет. Для мониторинга скорости загрузки есть миллион сервисов (SpeedCurve, Treo, Lighthouse CI и иже с ними). А вот что, если важна не скорость загрузки, а скорость реакции кнопочек? Придётся настраивать что-то своё — про это и гайд.

(первая статья на 3perf.com за пару лет, да ✨)

Программирование - это не сложно, это дорого.

В эту пятницу хочу поделится докладом о процессах разработки в бывшем Facebook. Множество радикальных и вдохновляющих мыслей: https://youtu.be/UNdJFEmKkJU

JavaScript empty mark

Есть такой интересный proposal-partial-application, который предлагает сахар для частичного биндинга аргументов функции.
Мне нравится идея этого предложения, я сталкиваюсь с задачами где это могло бы быть полезно, но мне очень не нравится что это предлагается решать новым синтаксисом.

Все тоже самое и даже больше можно реализовать и не меняя синтаксис, а введя новый Symbol.empty, по аналогии с Ramda reduced (есть аналоги и в других библиотеках). Я создал issue на этот счет, но уже три недели на него никто не реагирует 💁‍♂️

Сайпрес тесты на CI гонятся минут 20. Локально на моем м1 2.5 часа 🥲
Будем искать лики…

Такой заголовок прикольный))
https://github.com/cypress-io/xvfb/issues/98