Есть противная проблема с AWS CloudFormation, которую пока не могу победить (не хватает знания). Смотрите, какая фигня получается:

CloudFormation позволяет описывать инфраструктуру как код. Всё хорошо, всё красиво.

Добавляем в приложение новый роут в API Gateway или создаём новую группу логов. Не важно что, важно, что это в коде. Деплоимся, CloudFormation создаёт новый ресурс.

Дальше откатываем на предыдущую версию (например, переключив ветку с нашей feature на main и задеплоив продовую версию.

Вливаем feature в main и деплоим новую версию. И тут получаем

An error occurred: BlaDashblaDashblaLogGroup - Resource handler returned message: "Resource of type 'AWS::Logs::LogGroup' with identifier '{"/properties/LogGroupName":"/aws/lambda/Bla-bla-bla”}’ already exists."

Ну а дальше идём и руками чистим ресурс созданный дев-веткой и катим снова.

Ерунда какая-то. Памагите.

Ко вчерашнему посту.

Немного поясню, почему окружение шатается так сильно, ведь казалось бы, ну как часто у нас меняется конфигурация системы? На самом деле очень часто, если речь идёт о лямбдах. Каждая лямбда это один контроллер, облуживающий 1 роут. Т.е. на лямбду нужно создать и хранилище в S3 и роут в API Gateway и группу в логах. В итоге крупный микросервис стремительно летит к лимиту AWS на количество ресурсов и невозможно просто заводить ресурсы с префиксом feature-ветки — они мгновенно выжрут лимит.

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

Вот только следующий вопрос сразу возникает — а нафига вообще заворачивать в лямбду, может просто поставить в EC2 нормальное приложение? =)

После выхода WebStorm 2022.2 можно новый UI ставить уже не на EAP и плагин не нужен. Здорово

По идее можно врубить через registry, проверено на idea ultimate 2022.2 :

Open Find Action (Ctrl/Cmd+Shift+A on Win&Linux/Mac respectively).
Type Registry...
Enable the ide.experimental.ui key.
Restart IDE.

Раз уж такая пьянка, то вкину свои копейки. Кент в общем-то говорит простую вещь — хватит мокать всё подряд (stop mocking so much stuff). Чем больше у вас моков в юнитах, тем меньше они отражают реальность в какой-то момент. В Osome мы полностью отказались от юнитов на бэке и пишем только интеграционные (кидаем данные на вход хэндлера и смотрим, что получили на выходе). Сетевые связи с другими микросервисами закрыты через nock.

Заодно сам собой снялся вечный вопрос про тестирование приватных методов. Нет доступа — нет тестов.

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

https://news.1rj.ru/str/msosnovfeed/383

Сегодня и Сергей Сова на бизнес-логику в хуках ругался и в патреоновом чатике JavaScript.Ninja вспомнили прекрасное — useEffect в React 18 срабатывает дважды, если вы в Strict Mode. Вот такая мотивация:

Так как в будущем мы собираемся в целях улучшения производительности маунтить/анмаунтить компоненты туда-сюда (с сохранением стейта, конечно), то уже сейчас внедряем в Strict Mode поведение, когда каждый компонент маунтится, тут же анмаутится и снова маунтится. Чтобы вы успели подготовиться к прекрасному будущему.

* React mounts the component.
* Layout effects are created.
* Effects are created.
* React simulates unmounting the component.
* Layout effects are destroyed.
* Effects are destroyed.
* React simulates mounting the component with the previous state.
* Layout effects are created.
* Effects are created.

[линк]

Вот-вот, помните, вы не управляете хуками. Хуками управляет движок реакта.

В общем-то есть очевидное ишью [Bug: v18 - How to deal with useEffect being called twice in Strict Mode?] где Дэн предлагает не забывать делать cleanup и отменять свои фетчи. Или вообще вообще использовать что-то для дедупликации и кеша запросов.

На худой конец, говорит, отключайте Strict Mode, если вам мешает, мол React 18 важнее, чем сидеть на старой версии.

Ну что значит «отключайте». Отключайте, правьте код, и снова включайте, чтобы быть готовыми к светлому будущему.

Тут в комментах Владимир процитировал Фаулера, а я заметил в цитате старую проблему с пониманием S из SOLID. Забавно, как долго Мартин пытается объяснить, что имел ввиду совсем другое, и как столь же долго практически вся индустрия отказывается принять изначальную трактовку и идёт по более простому пути. Обратимся к Мартину:

===============
«Из всех принципов SOLID наиболее трудно понимаемым является принцип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соответствующего сути. Услышав это название, многие программисты решают: оно означает, что каждый модуль должен отвечать за что-то одно.

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

Традиционно принцип единственной ответственности описывался так:

Модуль должен иметь одну и только одну причину для изменения.
…
Фактически принцип можно перефразировать так:

Модуль должен отвечать за одного и только за одного пользователя или заинтересованное лицо.
…
Окончательная версия принципа единственной ответственности выглядит так:

Модуль должен отвечать за одного и только за одного актора»

Чистая архитектура. Искусство разработки программного обеспечения
Мартин Р.
===============

Почему так случилось и почему изначальная трактовка важна? Для меня весь SOLID это прежде всего архитектурные принципы. Мы задаём границы, описываем правила их пересечения, направление движения данных и контракты. На этом уровне восприятия нас не волнует размер и сложность функций и классов, мы проектируем систему. И в контексте архитектуры системы S (в изначальном понимании Мартина) — очень важно.

Полезная штука:

Если в package.json прописать

"engines": {
"node": ">=16"
"npm": "8"
}

и в .npmrc

engine-strict=true

то npm i на старой node.js выплюнет ошибку Unsupported engine

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

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

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

Из утреннего чатика:

Андрей: Ссылка для отпускников и безработных https://teamlead.wrike.tech/

Олег: прикольно, только не понимаю, почему тимлид всегда ревьюит всех ? чот странно

Илья: Вчера аудиторы спрашивали, у вас типа какой то руководитель код смотрит перед мержем.
Я даже растерялся

Андрей: Еслинт Приттирович Сонаров смотрит

——
Только так. И точка.

Кстати, у Сонара есть плагин для eslint https://github.com/SonarSource/eslint-plugin-sonarjs

Статья для субботнего утра. Мощные аргументы Вильяма в защиту SPA.
https://williamkennedy.ninja/javanoscript/2022/05/03/in-defence-of-the-single-page-application/

Для меня архитектура — это как сделать сегодня так, чтобы не было мучительно больно завтра. Если про завтра не думать, то и архитектура не нужна. Например, по таким законам живут MVP и одноразовые промо-странички. https://news.1rj.ru/str/artalog/340

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

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

—- в этой части автор ругает миддлвары. Пропустим очевидное —-

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

https://insertafter.com/en/blog/no_more_middlewares.html

В пятницу буду на Я люблю фронтенд (мы собрали осколки того то, что от нас осталось, склеили кое-как и дотащили конфу до продакшена) рассуждать о том, какой стек для бэкенда на node.js я бы выбрал в 2022. Будет онлайн, всё как всегда бесплатно, знания бесценны.

Ах да, наконец-то скажем, кто и как победил в ctf.

В Barking store наткнулся на шапочку архитектора.

Одна из самых больших проблем в запоминании принципов SOLID (если вы зачем-то хотите их запомнить) — это буква L, (LSP, Liskov substitution principle, или принцип подстановки Барбары Лисков). Каноническое определение его скучно до зевоты: Пусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.

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

Наиболее простой способ понять этот принцип — это проблема квадрата и прямоугольника. Квадрат нельзя наследовать от прямоугольника, потому, что после этого мы теряем свойство родителя (независимое управление длинами сторон X и Y). У квадрата стороны равны, у прямоугольника нет. Сторонами прямоугольника можно управлять раздельно, и квадратом не заткнуть любую дырку, которую может занять прямоугольник.

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

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

https://news.1rj.ru/str/xufostation/772

Цитата с Хабра

«Вообще, при разработке, наследование можно рассматривать с двух позиций: подклассы — это подтипы, со всеми ограничениями контрактного программирования и принципа Лисков, и подклассы — это способ переиспользовать код, со всеми своими потенциальным проблемами. Т.е. можно либо думать и проектировать ответственности классов и контракты и не переживать про клиентский код. Либо думать про то, какой может быть клиентский код, как классы будут использоваться, и быть готовым к потенциальным проблемам, но в меньшей степени заботится о соблюдении принципа подстановки. Решение как обычно за разработчиком, самое главное, чтобы выбор в конкретной ситуации был осознанный и было понимание какие плюсы, минусы и подводные камни сопровождают то или иное решение.»

После сегодняшнего обсуждения лямбда-боли:
——
думаю, что мы придём к тому, что будет одна лямбда для всего http и отдельным опциональным лямбдам там, где нужен s2s
——

Предложил сразу встроить фастифай и позже отправить это в кубер :troll_mode_activated:

Кстати, если среди читающих есть опытные пользователи лямбд — поделитесь в комментах: пакуете ли вы все HTTP-лямбды в одно приложение с внутренним роутингом, слушающее корневой роут в API Gateway, или разделяете на множество мелких «контроллеров», обслуживающих отдельные роуты?

Первый раз за несколько месяцев написал

let

. Но потом одумался и вынес код в функцию.