Киллер фича Vue Devtools и IDE

Хочу поделится крутым возможностями которую я недавно обнаружил в Vue Devtools

По умолчанию есть возможность из dev tools перейти прямо к Dom компонента в инспекторе Chrome, что уже очень удобно при отладке разметки и стилей. <> Inspect DOM

Но есть еще более восхитительная возможность переходить в код компонента из браузера прямо в IDE. Можно настроить любой редактор (у меня получилось с VSCode и PHPStorm, другие не пробовал)

Обычно работает из коробки в vue-cli, nuxt, но если нет читайте этот док https://devtools.vuejs.org/guide/open-in-editor.html

Так же эта кнопка появляется только если вы выбираете ваш компонент, а не компонент из Vuetify например.

#vue #devtools #советы

DI и абстракции

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

Например в Nest.JS это можно сделать через Non-class-based provider tokens.

И если у вас поменялась реализация, то будет достаточно просто поменять зависимость в декораторе модуля
#nestjs #di #советы

Многоуровневая передача свойств в Vue.js

Избегайте передачи свойств вложенным компонентам.
Подумайте о том несчастном джуне, который будет дебажить ваш код.
Если одни и те же данные нужны в больше чем одном компоненте, лучше использовать локальный или глобальный стейт - vuex, или composition api

Подробней тут https://bearlogin.notion.site/Vue-3020c1ff6f404768aa9cadd55f6451f7

#vuejs #советы

Error: ENOENT: no such file or directory, stat '/vmlinuz.old'

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

Привычный rm -rf node_modules не спасал. Я дико злился и много гуглил, пока не пролистал логи сборки вверх.

This dependency was not found:
* bowser in ./node_modules/my_awesome_package/src/compositions/useBrowser.js

То есть проблема была в том, что в пакете не были установлены зависимости, так как он подключался локально для разработки. 🤦‍♂️

Окей, гугл, но при чем тут /vmzlinuz.old?
Собсно дело в том, что node_js ищет зависимости аж до system root
https://nodejs.org/api/modules.html#modules_loading_from_node_modules_folders
А vmlinuz - Linux kernel executable
https://s905060.gitbooks.io/site-reliability-engineer-handbook/content/anatomy_of_the_initrd_and_vmlinuz.html

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

А какие были у вас проблемы, решение которых оказывалось не в той области, где вы думали?

Docker stack и replicated 0/1

Если при деплое стака сервис никак не поднимается, то начать стоит с команды

docker service ls

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

back_swoole replicated 0/1

Затем нужно посмотреть список тасок самого сервиса, c флагом —no-trunc для того чтобы увидеть полный текст ошибки.

docker service ps back_swoole --no-trunc

Rejected 2 seconds ago "No such image: back-swoole-05067e0d@sha256:b33e2b25583f4149711e875c7f83b550184e53d01fd640850140563679283d0b"

В данном конкретном случае у нас отвалилась авторизация в docker hub и docker не смог спулить образ :) А слетела она потому что на диске кончилось место. Вот такая вот курица в яйце...

Self-hosted runners

Обычно в облачных CI\CD есть возможность запускать процессы на self-hosted runners. Это когда ты на любой машине запускаешь образ для определенного сервиса и на нем выполняются определенные шаги pipeline. Это полезно, когда для сборки требуются специфические ресурсы - например GPU, или просто очень мощный процессор. Или когда в проекте очень часто идут билды и просто дорого оплачивать build minutes, так как обычно сервисы не списывают минуты за запуск на вашей машине.

Например в bitbucket pipelines только недавно появились self-hosted runners. https://bitbucket.org/blog/pipelines-runners Пока пощупал на сборке Vue проекта. По скорости сборки выигрыша нет. Планирую сделать запуск selenium тестов на машине с GPU.

На злобу дня

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

Выгорание

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

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

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

И вот ты уже делаешь коммиты в 3 часа ночи субботы...

Мне справляться с выгоранием помогает психотерапевт, запланированный отдых, и перечитать курс от ТЖ https://journal.tinkoff.ru/pro/burnout/ А как вы справляетесь с этой напастью?

Анемичная vs богатая модель

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

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

Сервисы в данном случае превращаются в оркестраторы, которые реализуют use cases.

Покажу на простом примере.

class Order {
      shipment: IShipment
      pay: IPayment
      basket: Basket

      constructor(shipment:IShipment, payment:IPayment, basket: Basket) {
        this.shipment = shipment
        this.payment = payment
        this.basket = basket
      }
 

      pay() {
        this.payment.pay()
      }

      ship() {
        this.shipment.ship()
      }
}


class CreateAndPayOrderUseCase {
    handle(basket: Basket) {
        const order = new Order(
          ShipmentFactory::create('DHL'),
          basket, 
          PaymentFactory::create('Stripe')
        )
        order.pay()
    }
}

Таким образом мы видим, что заказ может оплачен и доставлен.

А какую модель выбираете вы?

#архитектура #ddd

Бритва Хэнлона и фейлы

Мы обычно любим рассказывать про свои достижения, а про фейлы умалчивать, но это может быть как познавательно, так и в некоторой степени весело :)

Я думаю у каждого программиста были такие фейлы, которые проходили прямо в соответствии с Бритвой Хэнлона)

Думаю ввести в практику такую тему, и публиковать самые интересные с тегом #бритвахэнлона.
Присылайте мне свои, или пишите в комменты, тоже буду публиковать :)

И так, начну.
Вчера я поднял 2 контейнера - rabbitmq и rabbitmq manager, открыл порт в мир у первого и очень долго не мог понять, почему в manager я не вижу ни подключений ни консюмеров моего микросервиса :)

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

В итоге я допер, что rabbitmq manager - это тот же самый rabbit только с подключенным плагином менеджера и все это время я ломился в одну ноду rabbitmq, а мониторил другую. То есть нужен был только второй контейнер, а первый можно удалить :) #бритвахэнлона #rabbitmq