Sorry Cypress Not Sorry

Любите ли вы JS-драмы так же, как их люблю я?

Есть такая штука для написания E2E тестов в браузере — cypress. Существует вот уже 9 лет. Я знаком с ним очень поверхностно, но в целом мои впечатления от него положительные — с тестированием браузеров всегда всё было очень плохо и непонятно (да, селениум, я про тебя), а тут тебе всё просто, понятно и на JS.

Но сам сайпрес — это просто тест-раннер. А помимо запуска тестов вам захочется ещё смотреть отчёты, реплеи упавших тестов, чтоб понять что случилось, параллелить запуск тестов, чтобы они не занимали вечность и т.д. Всё это делается через Cypress Cloud — отдельный платный продукт.

Как известно, платить хочется далеко не всегда. Так подумал и Андрейс Голдис (agoldis) и практически единолично написал sorry-cypress — опенсорсную альтернативу, которую можно развернуть в том числе и у себя. А вместе с этим он запустил currents.dev — sorry-cypress на стероидах, прямого конкурента Cypress Cloud. У них практически полный паритет по фичам, местами currents умеет чуть больше и имеет более гибкий и дешевый прайсинг.

Currents, как и sorry-cypress, существует вот уже пару лет. Но 25 сентября в блоге сайпреса вышел пост Changes in defense of Cypress Intellectual Property. Написан он достаточно странно: что-то в духе «мы ограничиваем работу сайпреса в некоторых сторонних продуктах и сервисах». Ограничения ввелись начиная с 13 версии сайпреса.

Андрей написал ответный пост Cypress.io Blocking of Sorry Cypress and Currents, в котором разобрал как именно сайпрес детектит использование в «нежелательных» окружениях.

Из-за публичной критики сайперсу пришлось объяснять свои действия в отдельном посте Why Cypress decided to block Currents.dev and Sorry Cypress. И, как видите, явно обозначить что же всё таки означало «defense of Intellectual Property» и явно перечислить причины блокировки: кибер-сквотинг, использование бренда и т.д.

Но помимо объяснения, сайпрес забекпортили блокировку в 12 версию сайпреса и, тем самым, сломали тесты всем пользователям sorry-cypress.


У меня по поводу этого всего есть следующие мысли:
1. Имя sorry-cypress действительно не очень удачное — как минимум это просто некрасиво.
2. С другой стороны имеет cypress имеет MIT лицензию, а Cypress — это отдельная компания.
3. Судя по всему Андрей действительно смог поставить Cypress в уязвимое положение, иначе бы этой истории не было. Возможно, у сайпреса действительно не самый лучший прайсинг и им стоит поработать в этом направлении.
4. В целом, запрет использовать новые версии сайперса в «нежелательных» окружениях — это нормально. Но бэкпортить ограничения в старые версии, которыми пользуются юзеры — очень грязный трюк. Это может сильно повлиять на репутацию и заставить пользователей мигрировать на другие инструменты (тот же Playwright).
5. Думаю, что у Cypress как компании нет никаких легальных рычагов давления. По идее они могли бы пойти в суд, но видимо понимают, что ничего не получится.
6. Оценить какое количество юзеров это задело, кажется, невозможно, но у докер-образа agoldis/sorry-cypress-director 6.6 миллионов пулов только с докерхаба (а многие используют кеширующие прокси для таких целей).

Конспект книги Современная программная инженерия. Глава 9. Модульность

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

Модульность определяется как «степень, в которой могут быть разделены и объединены компоненты системы, часто с целью гибкости и разнообразия в использовании»

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

Признаки модульности

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

Недооценка важности хорошего дизайна

В индустрии мы часто спорим о языках, фреймворках, стилях программирования. Однако, мы упускаем важность дизайна систему и не уделяем достаточно внимания модульности решения. Как следствие, получаем сложные решения, с которыми сложно работать и в которые сложно вносить изменения. Также, в модульных решениях сложнее допустить ошибку (из-за снижения сложности), а если ошибка была допущена - её легче исправить.

Важность тестируемости

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

Тестируемость повышает модульность

Представьте, что вы создаете систему, состояющую из трех модулей А,Б,В, где модуль Б связан с модулями А и В. Как протестировать модуль Б? Можно тестировать всё целиком, но такой подход вызывает много проблем т.к. вся система содержит слишком много сложности.

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

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

Сервисы и модульность

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

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

Развертываемость и модульность

Continous delivery подразумевает, что существует пайплайн развертывания и если он *зеленый*, значит систему можно релизить. Модульность важна для обеспечения такого пайплайна. В модульных системах модули можно собирать, тестировать и обновлять независимо друг от друга, что повышает скорость и безопасность развертывания. Если что-то из этого нарушается - значит система на самом деле немодульная.

Модульность в системах, создаваемых человеком

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

#конспект #современная_программная_инженерия

Дайджест за 2023-11-06 - 2023-11-10

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

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

В комментариях к посту указали, что есть сомнения в аккуратности замеров

⭐CSS Selectors: A Visual Guide
Визуальный гайд по css-селекторам. В гайде коротко рассказывается про то, какие селекторы бывают и как их можно комбинировать. Каждое объяснение также сопровождается визуализацией (иногда даже немного интерактивной).

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

⭐Headless Component: a pattern for composing React UIs

В блоге Мартина Фаулера появилась статья про паттерн Headless Component. Это когда мы разделяем UI-логику компонента от его верстки. Это дает нам возможность переиспользовать одну и ту же логику для разной вёрстки.


Speeding up the JavaScript ecosystem - Tailwind CSS
Очередная статья про ускорение экосистемы JS. В этот раз под анализом оказался tailwind CSS, который в целом работает быстро, но и там нашлось что улучшить.

Автор нашел 1 интересную проблему: недостаточно точный regexp для поиска использования tailwind-классов. В рассматриваемом проекте, из 26466 срабатываний regexp, 19630 были ложно-положительными - они не являлись tailwind-классами, но regexp их заматчил. Оптимизация regexp ускорила фазу поиск tailwind-классов в 4 раза.

Репост из канала "Валя читает ишью" про драмму вокруг Cypress
Если коротко, в cypress есть платная фича - дашборд тестов, который нужен для запуска тестов параллель (возможно я здесь чуть чуть не прав, но не в этом суть). И есть опенсорсный аналог, который делает то же самое, но забесплатно. Cypress начал борьбу с аналогами, бэкпортнув вендорлок в уже вышедшие версии cypress.

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


——————————————

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

Mastering DOM manipulation with vanilla JavaScript

Огромный список статей, демо, туториалов про работу с HTML и DOM нативными средствами Javascript. Хотя есть статьи, где решение сделано не на ванильном JS, а на React

По сути, это крутой список короткий (в большинстве своем) рецептов работы с HTML и DOM. Некоторые из них неактуальны при работе с фрейморвками, но некоторые будут полезны даже при использовании фреймворков.

https://phuoc.ng/collection/html-dom/

#development #javascript #dom #vanilaJs #recommended #list

How to Do a TypeScript Conversion

Статья рассказывает про ловушку при миграции с JS на TS. Когда проект решает перейти на TS, то у команды есть выбор: переписать всё разом, или переходить небольшими итерациями, в идеале используя принцип бойскаута "потрогал файл => переписал на TS". Для более менее крупных проектов, естественно, выбирается путь пошагового внедрения типов. Однако, пошаговое переписывание тоже можно сделать по-разному.

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

Желательно также сразу типизировать все зависимости файла, т.к. если зависимость не типизирована, то при импорте зависимости она будет резолвиться как any, а значит, в будущем мы можем столкнуться с необходимостью снова править типы в файле (т.к. TS выявит несоответствие типов). Поэтому, следует начинать типизацию от файлов, которые ни от кого не зависят и спускаться все дальше к корню дерева зависимостей.

https://v5.chriskrycho.com/journal/how-to-do-a-typescript-conversion/

#development #javascript #typescript #migration #refactoring

Moveable

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

https://github.com/daybrush/moveable

#development #javascript #library #dragndrop

Main thread scheduling

main-thread-scheduling - библиотека, позволяющая разгрузить main thread, оставив UI отзывчивым, без использования веб-воркеров.

Как я понял, библиотека предоставляет простое API, которое легко интегрируется в код. Например, если у вас алгоритм, обрабатывающий кучу файлов, то в цикле, перед началом обработки нового файла, можно поставить await yieldOrContinue('user-visible'), который будет ждать, пока шедулер не передаст обратно контроль для выполнения.

Шедулер выполняет 1 таску в 1 момент времени. Также доступны 2 приоритета для задача. Основной прикол, что шедулер слежит за API браузера isInputPending и не выполняет таски, если пользователь взаимодействует с UI. Что как раз и защищает от зависаний интерфейса.

В целом, API простое, концепция работы тоже вроде бы простая. Однако, я, честно сказать, не увидел как сообщить шедулеру что задача закончилась. Выглядит так, что я в коде могу дождаться от шедулера сигнала "пора работать", но не могу шедулеру сообщить, что я закончил обработку задачи. Если это так, то возможна ситуация, когда таска будет выполняться долго и шедулер даст сигнал "пора работать" следующей и будут работать 2 таски в одно время. Судя по написанному в доке, так оно и есть т.к. шедулер выделяет какое-то количество ms в зависимости от приоритета таски на её выполнение

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

https://github.com/astoilkov/main-thread-scheduling

#development #javascript #library #performance #schedule

re-re-reselect — Simplifying React state management

В сложных приложениях, как правило, сложные решения для хранения состояния. Компания Causal имеет 5 хранилищ состояния (redux, apollo, router и еще 2 ) и напрямую столкнулась со сложностями при работе с получением данных - необходимо уметь получать и обрабатывать данные из нескольких разных источников. Эту задачу обычно решают реализуя кастомный react-hook, но команде Causal это не понравилось, поэтому они начали делать свой микро-фреймворк для селекторов.

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

https://causal.app/blog/re-re-reselect

#development #javascript #selectors

Дайджест за 2023-11-13 - 2023-11-17

⭐Mastering DOM manipulation with vanilla JavaScript
Огромный список статей, демо, туториалов про работу с HTML и DOM нативными средствами Javascript. Хотя есть статьи, где решение сделано не на ванильном JS, а на React

По сути, это крутой список короткий (в большинстве своем) рецептов работы с HTML и DOM. Некоторые из них неактуальны при работе с фрейморвками, но некоторые будут полезны даже при использовании фреймворков.

How to Do a TypeScript Conversion
Статья рассказывает про ловушку при миграции с JS на TS. Когда проект решает перейти на TS, то у команды есть выбор: переписать всё разом, или переходить небольшими итерациями, в идеале используя принцип бойскаута "потрогал файл => переписал на TS". Для более менее крупных проектов, естественно, выбирается путь пошагового внедрения типов. Однако, пошаговое переписывание тоже можно сделать по-разному.

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

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



Main thread scheduling
main-thread-scheduling - библиотека, позволяющая разгрузить main thread, оставив UI отзывчивым, без использования веб-воркеров.

Как я понял, библиотека предоставляет простое API, которое легко интегрируется в код. Например, если у вас алгоритм, обрабатывающий кучу файлов, то в цикле, перед началом обработки нового файла, можно поставить await yieldOrContinue('user-visible'), который будет ждать, пока шедулер не передаст обратно контроль для выполнения.

re-re-reselect — Simplifying React state management
В сложных приложениях, как правило, сложные решения для хранения состояния. Компания Causal имеет 5 хранилищ состояния (redux, apollo, router и еще 2 ) и напрямую столкнулась со сложностями при работе с получением данных - необходимо уметь получать и обрабатывать данные из нескольких разных источников. Эту задачу обычно решают реализуя кастомный react-hook, но команде Causal это не понравилось, поэтому они начали делать свой микро-фреймворк для селекторов.

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

——————————————

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

Гайд по микрофронтендам на single-spa, или Как уже наконец-то уйти от монолита во фронтенде

Достаточно хорошая статья от Самокат про переход от монолита на ангуляре к микрофронтендам на VueJS с использование single spa (фреймворк для микрофронтендов). Реально интересная статья, показывающая на простом примере, как построить простое приложение на микрофронтендах

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

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

https://habr.com/ru/companies/samokat_tech/articles/766978/

#development #javascript #microfrontends #vue #singleSpa

Eslint: Deprecation of formatting rules

Eslint анонсировал deprecate правил и функционала, связанного с форматированием кода. В целом, давно пора, т.к. эту нишу занял Prettier и в последние годы почти никто (хотя у меня есть такие знакомые) не ожидает, что eslint будет что-то форматировать. В плагине Prettier даже есть конфиг, который отключает все правила форматирирования eslint, чтобы не было конфликтов с Prettier

В самом Eslint отказ объясняют следующими причинами:
- При разработке таких правил, нужно постоянно помнить о том, что они могут конфликтовать друг с другом
- Большие ожидания от этих правил, которые сложно оправдать
- Сложность разработки (сложно учесть все нюансы форматирования)
- Чем больше времени тратится на поддержку этих правил, тем меньше времени уделяется важному функционалу
- Отсутствие интереса у сообщества

Лично я давно использую связку eslint + eslint-plugin-prettier. Плагин запускает prettier вместе с eslint, что позволяет объединить 2 инструмента в одном, что убирает потребность в настройке отдельного запуска prettier в CI, пре-коммит хуках и тп.

https://eslint.org/blog/2023/10/deprecating-formatting-rules/

#development #javascript #eslint

Дайджест за 2023-11-20 - 2023-11-21

------

Статей на прошлой неделе было мало т.к. готовился к выступлению на митапе. Очень порадовало, что часть читателей канала пришли на митап - был рад вас увидеть и получить от вас фидбек 🧡

На этой неделе вхожу в привычный ритм - ссылка на что-то интересное будет каждое утро

------

Гайд по микрофронтендам на single-spa, или Как уже наконец-то уйти от монолита во фронтенде
Достаточно хорошая статья от Самокат про переход от монолита на ангуляре к микрофронтендам на VueJS с использование single spa (фреймворк для микрофронтендов). Реально интересная статья, показывающая на простом примере, как построить простое приложение на микрофронтендах

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

Eslint: Deprecation of formatting rules
Eslint анонсировал deprecate правил и функционала, связанного с форматированием кода. В целом, давно пора, т.к. эту нишу занял Prettier и в последние годы почти никто (хотя у меня есть такие знакомые) не ожидает, что eslint будет что-то форматировать. В плагине Prettier даже есть конфиг, который отключает все правила форматирирования eslint, чтобы не было конфликтов с Prettier


——————————————

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

Announcing TypeScript 5.3

Команда Typescript анонсировала релиз 5.3. Основные изменения, за которые зацепился мой глаз - оптимизация перформанса и размера и улучшение уточнения типов

Начну с уточнения типов: завезли корректное уточнение типов для паттерна switch (true)

function f(x: unknown) { 
 switch (true) { 
  case typeof x === "string": 
   // x - строка
   console.log(x.toUpperCase()); // нет break!
  case Array.isArray(x): 
   // 'x' - строка и массив
   console.log(x.length);
  default: 
   // а здесь x - unknown
 } 
}

Также улучшили уточнение проверки типов при сравнении с булами

interface A { 
 a: string; 
} 
interface B { 
 b: string; 
} 

type MyType = A | B; 

function isA(x: MyType): x is A { return "a" in x; } 

function someFn(x: MyType) { 
 if (isA(x) === true) { 
  console.log(x.a); // TS больше не ругается на эту строчку
 } 
}

Также улучшили работу instanceof. В JS есть возможность управлять работой оператора через Symbol hasInstance, но раньше typescript это не обрабатывал. Теперь обрабатывает.

class IAmUndefined { 
 static [Symbol.hasInstance](testedValue) { 
  return testedValue === undefined; 
 } 
} 

console.log(undefined instanceof IAmUndefined); // true

По поводу оптимизаций: typescript теперь избегает парсинга JSDoc - это ускоряет работу компилятора. Поведение можно включить обратно через опции TS. Также оптимизировали работу юнионов.

Еще из интересного - TS экспортировал 2 файла - typescript.js и tsserverlibrary.js с немного разным API, что усложняло использование TS. В итоге эти 2 файла объединили, что уменьшило итоговый размер пакета на 20%.

https://devblogs.microsoft.com/typescript/announcing-typescript-5-3/

#development #javascript #typescript #releaseNotes

Promises Training

Очень интересный репозиторий, который содержит в себе задачки по работе с Promise'ами. Они разделены на уровни сложности. К каждой задачке есть четкое описание, что нужно сделать и на все задачки написаны тесты. Если все тесты проходят - вы решили задачку правильно.

Это что-то типа сайтов с алгоритмическими задачами (типа литкода), но только механика задача+тесты используется для интерактивного обучения. Выглядит очень интересно.

https://github.com/henriqueinonhe/promises-training

#development #javascript #Promise #recommended #tutorial

Using the OpenAI platform to analyse automated test failures

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

Вот автор задался тем же вопросом и написал кастомный reporter для nightwatch - фреймворк для браузерного тестирования. Репортер, при получении ошибки в тесте, идет в специальное API для уточнения, что же с этой ошибкой делать. Сервер, предоставляющий API, представляет собой expressjs, который ходит в openai со специальным шаблоном, в который подставляется текст ошибки.

Итого, репортер видит ошибку -> идет на expressjs сервер за информацией -> expressjs идет в openai -> пользователь вместо непонятной ошибки видит предложения от gpt о том, что случилось и как это исправить

Выглядит интересно. Вдохновляет тоже запилить что-то эдакое.

https://labs.pineview.io/using-openai-platform-to-analyse-automated-test-failures/

#development #javascript #chatgpt #autotests

Moving back to React

Сайт daily.dev переходит с Preact на React. Долгое время команда писала на Next.js + Preact. Не смотря на то, что Preact поддерживает основные фичи React, команда столкнулась с проблемами:
- Медленный Hot Reload
- Медленная работа сборки в dev-режиме (включая фризы вкладки)

Этих проблем нет при использовании Next + React, поэтому было решено переходить на react.

Плюсы от потенциального перехода на React:
- React совместим с текущим Next.js и со всеми будущими фичами
- Меньше возни с конфигами
- Меньше зависимостей
- React более стабилен и в нем больше уверенности. Preact же старается быть как React, но также тащит фичи из других миров

Минусы:
- Размер бандла увеличится
- Нужно поменять много кода

Размер бандла
Увеличение размера бандла оказалось ожидаемым - ровно на разницу между React и Preact. Влияние можно минимизировать, выделив react в отдельный чанк с отдельным кешированием. Также, во время замеров, были обнаружены возможности для оптимизации размера бандла в приложении, решение которых позволит еще сильнее минимизировать влияние перехода на React на пользователей

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

Т.к. Preact поддерживает подмножество функционала React, то переезд на React не должен быть в целом сложным. Но при этом проблемы, естественно, возникнут. Эти проблемы решили поделить на 2 категории: ошибки и предупреждения (errors and warnings). Предупреждения - это все то, что не влияет на работу приложения или на пользователя. Ошибки же - все, что может привести к неправильной работе сайта (в том числе утечки памяти)

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

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

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

https://daily.dev/blog/moving-back-to-react

#development #javascript #react #migration

Microservices aren't the problem. Incompetent people are

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

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

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

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

Инженеры считают себя умными, но, как правило, большинство из них такими не являются. Автор называет это smart-ass complex. Если переводить грубо, то "комплекс умной задницы", хотя мне в последнее время для обозначения этой проблемы нравится классика - "Горе от ума".

smart-ass инженер:
- Переусложняет решения. Там где можно было сделать что-то в лоб, умный инженер сделает микросервисную масштабируемую систему с наиболее подходящим тех. стеком
- Использует разные имена для одной концепции, говоря, что в разных контекстах названия должны быть разные (например фасад, адаптер, мост и тд для обозначения врапера)
- Борется с несуществующими проблемами. Наиболее яркий пример - взять практики гугла, имея на сервис менее 1 RPS, зато получив запас прочности при масштабировании на десятилетия вперед
- И так далее

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

Как быть компетентным? Автор предлагает свое видение принципов, которым следуют компетентные инженеры:
- Применять SOLID на разных уровнях: код, сервисы, команды, организация (в оригинале расписано очень подробно, но я переводить не стал. Если вам интересно - окунитесь в оригинал)
- В чем отличие монолита от микросервиса? В коде приложения разнцы особой нет т.к. вся суть в том, что единственная разница - это механика коммуникации. В монолите мы просто вызываем нужную функцию, в микросервисе же используем сетевое взаимодействие для той же цели. Следует применять сервисную архитектуры. Т.е. писать такие сервисы, которые не микро, но и не монолит. Каждый сервис принадлежит конкретной команде, которая за него ответственна
- Думайте о Developer Experience
- KISS
- Откиньте подход "все или ничего". Не следует ультимативно следовать каким-то практикам т.к. в большинстве случаев это непрактично. Например, не случится ничего страшного, если вы добавите функционал в существующий микросервис сбоку, вместо написания нового. Написанный сбоку функционал всегда можно вынести позже.
- Ownership - у каждого сервиса есть свой owner и только он туда может вносить правки. Это позволяет быть уверенным что владелец знает все о том, как работает сервис и что он поддерживает его качество на высшем уровне.

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

https://nondv.wtf/blog/posts/microservices-arent-the-problem-incompetent-people-are.html

#development #microservices #architecture #softwareEngineering

Advent of TypeScript

Набор заданий type challenge для TypeScript, который будет открывать по одной задаче в день с 1-ого по 25-ого декабря и может послужить отличным поводом или дополнительно попрактиковаться, или изучить работу типов в языке.

Дайджест за 2023-11-27 - 2023-12-01

Announcing TypeScript 5.3
Команда Typescript анонсировала релиз 5.3. Основные изменения, за которые зацепился мой глаз - оптимизация перформанса и размера и улучшение уточнения типов

Начну с уточнения типов: завезли корректное уточнение типов для паттерна switch (true)

⭐Promises Training
Очень интересный репозиторий, который содержит в себе задачки по работе с Promise'ами. Они разделены на уровни сложности. К каждой задачке есть четкое описание, что нужно сделать и на все задачки написаны тесты. Если все тесты проходят - вы решили задачку правильно.

Это что-то типа сайтов с алгоритмическими задачами (типа литкода), но только механика задача+тесты используется для интерактивного обучения. Выглядит очень интересно.

Using the OpenAI platform to analyse automated test failures
С появлением нейронок появляются все новые и новые интеграции в существующие инструменты. Некоторые идеи лежат прям на поверхности и вот, статья как раз об одной из них. Существует проблема, что ошибки от инструментов не очень информативные. Например, упал пайплайн в CI. Средний разработчик может зайти в упавшую джобу и ничего не понять и тогда ему приходится гуглить. Почему бы это не автоматизировать с помощью gpt нейронки?

Вот автор задался тем же вопросом и написал кастомный reporter для nightwatch - фреймворк для браузерного тестирования. Репортер, при получении ошибки в тесте, идет в специальное API для уточнения, что же с этой ошибкой делать. Сервер, предоставляющий API, представляет собой expressjs, который ходит в openai со специальным шаблоном, в который подставляется текст ошибки.

Moving back to React
Сайт daily.dev переходит с Preact на React. Долгое время команда писала на Next.js + Preact. Не смотря на то, что Preact поддерживает основные фичи React, команда столкнулась с проблемами:
- Медленный Hot Reload
- Медленная работа сборки в dev-режиме (включая фризы вкладки)

Microservices aren't the problem. Incompetent people are
Какое-то время назад все только и говорили о микросервисах. Затем, стали говорить, что микросервисы не нужны - слишком сложно и много накладных расходов. Дмитрий Нон возвращается к этой теме, но рассматривает её под другим углом - проблема не в подходе микросервисах, а в недостаточной компетенции разработчиков.

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

——————————————

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

67 Weird Debugging Tricks Your Browser Doesn't Want You to Know

Список из 67 трюков для дебага кода в браузере. Причем, это не те простые трюки, которые часто описывают в туториалах, здесь описаны прям хорошие приёмы. Описаны применение API-браузеров и продвинутой использование breakpoint'ов с условием по выражению.


Например, вы знали, что в GoogleChrome есть функция, навесив которую на другую функцию, вы будете получать в консоль все её вызовы?

function test() {}
monitor(test);
test('lol', 'kek')
// в консоли будет function test called with arguments: lol, kek

Сталкивались ли вы с таким, что вам нужно понять, кто меняет какое-то css свойство элемента? Т.к. css-стили - каскадные, это может быть сложно сделать. Но ведь можно повесить breakpoint, который срабатывает на JS выражении, которое будет проверять итоговые стили. Например, мы хотим остановить исполнение кода, когда backbround-color станет красным:

window.getComputedStyle(document.body).backgroundColor === "rgb(255,0,0)"

Или другой кейс. У вас есть какое-то поведение на элементе при наведении на него и оно реализовано через JS, а не css :hover. Как быть? Автор предлагает следующий хак: вызвать debugger в setTimeout, затем навести мышку на нужный элемент и дождаться вызова debugger. Работа браузера остановиться и можно дебажить элемент сколько угодно

setTimeout(() => { debugger; }, 5000)

В общем, очень крутой список. Рекомендую к ознакомлению

https://alan.norbauer.com/articles/browser-debugging-tricks

#development #googleChrome #debug #recommended #javascript