the5x

эмм.... а зачем нужен laravel-excel для импорта csv?
возьмите пакет из лиги и читайте построчно. я им миллионы строк каждый день импортирую, без всяких очередей.

https://csv.thephpleague.com/

Метод Upsert

Вместо .data[1]. должно быть .data[i].

Я думаю это для подавления ошибок, которые могли бы потенциально прервать бессрочное выполнение скрипта. Лучше так не делать

Как написал коллега выше это абсолютно разные тесты.
- Первый пример: это модульный тест или unit. Обычно им тестируют класс и несколько классов когда они в зависимостях. Для примера если в аргументах примитив(число) в тестах можно передать все случаи 0 или даже отрицательные числа. Если у вас подход (DDD) можно протестировать инварианты.
- Функциональные(интеграционные или E2E - end to end) тесты - (в Laravel папка Feature) тестирование черного ящика. Например вы делаете запрос и ожидаете определенного ответа. В laravel это сделано не совсем корректно - так как предлагается в тестах лезть в базу

$this->assertDatabaseHas('users', [
            'email' => 'some@something.com'
        ]);

Функциональное тестирование не про базу, оно о том как приложении работает в целом.

Первое - юнит тесты
Второе - интеграционные

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

https://laravel.com/docs/8.x/blade#layouts-using-t...
extends для header, footer и других блоков это нелогично - достаточно создать основной шаблон, экстендить его и через section дополнять контентом

Проще всего найти "топ 20 вопросов по фреймворку" (на английском, там свежее), если бегло можешь ответить на них то понимание есть, сложные тесты есть только в платных сертификациях

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

если у коллекции блоков то:
const block = document.querySelectorAll('.block')
block.forEach((bl, index) => bl.addEventListener('click', () => console.log(bl.className, index)))

Это функция php
Особой разницы нету, Но выглядит по компактнее.

Разница в том что вы пишите.
['posts'=>$posts]

Когда таких не сколько ,все это выглядит громоздко.

Можно просто
compact("posts")

https://www.php.net/manual/ru/function.compact.php

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

Ты, во-первых, не понимаешь что такое dependency injection, а во-вторых - что делает твой код.

Если отбросить все умные и красивые слова которые ты тут наскреб по сусекам, то оба твоих примера - про type hinting. Только в первом кусочеке кода мы просим интерпретатор проверять входящий параметр, а во втором - возвращаемое значение.
Type hinting двольно размытый термин, мне больше нравится "контроль типов", который используется в документации. Поскльку в данном случае это не "подсказка", а строгий контроль: скрипт упадёт с ошибкой если в первом примере в метод придет что-то отличное от класса реализующего интерфейс Foo, а во втором - если метод вернет что-то отличное от такого класса.

Контроль типов надо использовать, чтобы твой код был чище и работал предсказуемее.

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

Вот вам 12 маленьких задач на 12 паттернов:
github.com/zfcampus/zendcon-design-patterns

1. Открываете папку с паттерном.
2. Читаете README.md с описание задачи.
3. Открываете exercise.php и пытаетесь решить задачу, применив соответствующий паттерн.
4. При необходимости вспоминаете теорию: github.com/domnikl/DesignPatternsPHP
5. Сверяетесь с решением в solution.php.

В примере ниже, метод makeInterviewer(): Interviewer возвращает тип интерфейса Interviewer.

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

Соответственно, никакой магии тут нет, просто в вашем примере не хватает классов-наследников с конкретной реализацией.

interface Interviewer {
    public function askQuestions();
}

abstract class HiringManager {
    abstract public function makeInterviewer(): Interviewer;

    public function takeInterview() {
        $interviewer = $this->makeInterviewer();
        $interviewer->askQuestions();
    }
}

class TeamLead implements Interviewer {
  public function askQuestions() {
    ...
  }
}

class Boss extends HiringManager {
  public function makeInterviewer(): Interviewer {
    return new TeamLead();
  }
}

https://www.php.net/manual/ru/language.oop5.abstra...

Возвращает не "тип интерфейса", а должен возвращать объект класса реализующий интерфейс Interviewer.
Следовательно он точно должен содержать в себе метод askQuestions.
Вроде бы паттерн Strategy, но это не точно