Безумие дотфайлов

почти все зависимости установились плоско

Круть, только это стечение обстоятельств. Общий размер 2.4 мб

Собсно потом не кричите, что у вас скрипты в браузере раздуты.

Вы сейчас сравниваете мягкое и зеленое. Webpack что научился вычленять только используемую функциональность из подтягиваемых пакетов? Например если требуется пара функций из underscore — тянуть пакет более затратно, чем написать эти несчастные пару функции.

Безумие дотфайлов

… Но вебпак включит его в сборку единственный раз.

И причем тут webpack? Речь про node_modules.

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

Собсно и чо?)) Да, будут повторяться, причем для каждого случая это будет заточенная функция под конкретный случай. Если для вас N зависомостей предпочтительней, чем N функций — это печально.

Безумие дотфайлов

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

Решили вы заюзать express, там 30 зависимостей, но в сумме будет загружено свыше 100 пакетов, учитывая зависимости зависимостей. И это без dev зависимостей.
Как правило у вас не одна зависимость. Вот так и получается, что количество пакетов растет экспоненциально. Причем абсолютная часть того, что вы загрузите — это просто занятые inode, не более того.

Пример с isarray я привел для того, что бы показать то, что пакеты довольно часто очень маленькие, а многие из авторов вместо того, что бы написать у себя функцию на этих же 5 строк предпочитают загрузить пакет. NPM и left-pad: мы разучились программировать?

Безумие дотфайлов

https://www.npmjs.com/package/isarray 19.5kk загрузок в неделю.

Всегда ли Node.js будет медленнее, чем Golang?

Какая-то странная статья, вроде как по заголовку должно быть дофига сравнение, в конкретном направлении для node.js vs golang.
А по факту немножко описывается биндинг имплементации WebSockets на крестах, который "значительно обходит по производительности лучшие решения, написанные на Golang"

12 странных вещей, которые могут произойти после установки npm пакета

Это плюс npm что есть хотя бы кто-то кто проверяет и дорожит своей репутацией.

Ок, вот смотрите: есть github на нем есть проект MyVendor\MyProject. Проект дико популярен, все здорово, его аудитом, пусть и косвенно занимаются люди, которые его используют. То, что я вижу в репозитории и то, что загрузится в зависимости — одно и то же.

Теперь берем npm. Так же с пакетом MyProject. Как я могу посмотреть код пакета? Только установив его через npm. Потому, что содержимое пакета и содержимое репозитория — это разные вещи.

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

Теперь вопрос, а за что они (npm) отвечают, особенно с учетом того, что большинство пакетов под MIT/BSD/WTFPL?

Вспомнил. Что дальше? Из-за того что есть npm пакет бытро вернули, убрали возможность удалять пакеты.

Не вспомнили. Причина удаления leftpad автором заключается в том, что другой пакет (kik) этого же автора администрация npm отозвала, поставив перед фактом, нарушая собственные правила.

12 странных вещей, которые могут произойти после установки npm пакета

Думаю централизованность npm тут выигрывает у например децентрализованого go. Кто будет проверять все сущ репы? А если популярная репа окажется хакнута?

В чем же выигрывает?

• В том, что есть какие-то парни в npm, на которых в случае взлома можно спихнуть вину?
• В том, что твоим пакетом управляет какая-то левая компания? Вспомните историю с leftpad.
• В том, что пакет != код из репозитория, и уязвимости как с тем же eslint в принципе возможны?

Кто будет проверять все сущ репы?

Это задача инженера, который подключает пакет.

А если популярная репа окажется хакнута?

В полной мере от этого никто не застрахован. У того же Go и в случае mod и в случае dep отсутствуют preisntall, postinstall и вот это вот все, что закрывает довольно большой источник уязвимостей.

12 странных вещей, которые могут произойти после установки npm пакета

Иногда кажется, что одно из предназначений экосистемы NodeJS/NPM — это пособие для изучения ИБ))

Почему вам нужно учить больше языков программирования

Нашел автора статьи на linkedin, надеюсь не ошибся. Он работает 16 месяцев программистом, из них 7 в FB.

В принципе все становится на свои места [sarcasm]:

• опытный инженер
• подбор инструментов под задачу
• отсутствие маркетингового булшита
• статья действительно полезна

[/sarcasm]

Почему вам нужно учить больше языков программирования

Потому, что может (с)

За что я ненавижу Eloquent ORM

Да не вопрос. Если вы не используете подходы, описанные в вашем примере — это отлично. Если же используете — ну что ж, печально.

За что я ненавижу Eloquent ORM

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

За что я ненавижу Eloquent ORM

Не обязательно. Результат вашего теста может на прямую зависеть от других тестов. Это очень плохая практика. Поднятие всего окружения для каждого теста (когда их много) — очень ресурсоёмкая задача.

За что я ненавижу Eloquent ORM

Все зависит от настроек, на лонг ране на много проще явно определять и энтити и репозитории.

За что я ненавижу Eloquent ORM

Тестировать нужно логику, а не сохранение в базу.

Вы где-то увидели "INSERT" в примере, что я привел? Или может я написал, что нужен функциональный тест с дерганием живой БД?

И не гонитесь за 100% coverage кучу малозначимых тестов поддерживать будет гораздо труднее.

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

За что я ненавижу Eloquent ORM

Что будет, если до вашего тест кейса выполнится другой, в котором подтянется реальный класс App\DB? Или в ваш же тест кейс дописать такой тест метод.

За что я ненавижу Eloquent ORM

Используются, но не копипастить же это все в каждый метод.

DRY — это круто, но далеко не всегда дает профит. Например: у вас есть две сущности userType1 и userType2, они похожи, но принадлежат разным доменам. Для них код стоит копипастить.

Исключения можно в одном месте ловить например. И логировать их там же.

Вообще говоря это полностью зависит от задачи.

Я думал, под логикой вы подразумеваете, что у вас работа с моделью ($myModel->setName() и т.п.) находится отдельно от транзакций и всего остального, и вы ее хотите тестировать.

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

За что я ненавижу Eloquent ORM

Далеко не всегда стоит разбивать методы, так как вы это делаете. Это вопрос безопасности и сложности интерфейса вашего сервиса. Вот что делает ваш сервис?
Он и реализует фабрику для MyModel, и сохраняет без транзакции, и гидрирует данные (по хорошему еще и отдельный метод для валидации нужен), и сохраняет с транзакцией с транзакцией.

Это все очень круто, если его сделать: final + запретить редактировать. Но, в реальности ваш сервис будет источником проблем. Я не спорю, для мелких проектов такое годится. Но не для чего-то среднего, или большого.

За что я ненавижу Eloquent ORM

Просто так, как вы написали, с AR обычно не делают, хотя бы потому что это куча копипасты.

C AR не используют транзакции? Не используется логгирование? Модели AR не создаются в том же методе, где и сохраняются? Что не используется?)) Или вы просто доколупались до источника данных Request, так же как комментатор выше?

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

public function store(Request $request)
{
    // Проверка запроса...

    $this->entityManager->beginTransaction();

    $myModel = new MyModel;

    $myModel->setName($request->name);

    try {
        $this->entityManager->persist($myModel);
        $this->entityManager->flush();

        $this->entityManager->commit();
    } catch (\Throwable $exception) {
        $this->entityManager->rollback();

        $this->logger->error($exception->getMessage(), ['exception' => $exception]);
    }
}

Что бы покрыть этот класс потребуется 2 теста, как минимум:

1. Позитивный, в котором entityManager->rollback и logger->error не вызываются.
2. Негативный, в в котором бросается исключение, например методом commit, транзакция при этом откатывается и логгируется исключение. которое мы бросили.

Я создам мок от EntityManagerInterface, укажу какие методы будут вызываться, на этапе persist — проверю, что объект $myModel — создался правильно.

За что я ненавижу Eloquent ORM

А доктрина вам как тут поможет?

Я могу замокать entityManager, в который буду делать persist нового инстанса MyModel.

Я к тому, что так же как вы пишете логику с доктриной, можно писать и с AR, с поправкой на то, где находится метод save().

Мы сейчас про тесты этой логики говорим))