Дебажим PHP-контейнер с помощью Xdebug и PhpStorm

Я бы даже осмелился предположить, что данная опция вообще не нужна при remote_connect_back = 1

PHP 25 лет: краткая история языка и скидка 50% на PhpStorm

Продление вроде тоже со скидкой.

Автономизация Unit-тестов в PHPUnit

Да, данную функцию нужно явно вызывать. Но в вашем случае надо явно прописывать: property className varible. Собственно по количеству символов ваш вариант не короче.

$var = $this->createMock(Class::class);

Против

@property Namespace\SubSpace\Class var 
$this->var;

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

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

Еще раз повторюсь, ничего не имею против, классная статья, интересная идея и архитектура. Я для себя даже кое что подчерпнул. Но на мой взгляд — излишнее усложнение того, что можно сделать проще. Просто профита не вижу, от написанной сложности.

Автономизация Unit-тестов в PHPUnit

Очень интересная статья и опыт. Спасибо. Но вот просмотрев основной код, можно выделить 2 основные задачи, которые ими решаются:
1) Короткое создание моков + удаление их в tearDown.
2) Парсинг докблока.
Могу ошибаться, но разве это не сложный велосипед? Для быстрого создания моков есть codeception/stub, а для парсинга докблока — phpDocumentor/ReflectionDocBlock (Но возможно не совсем подходит, конкретно под ваш кейс)

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

Беру теоретичсекий код, который должен работать, и все это заменить:

protected $mocks = [ ];
protected createMock($className, $constructorParams = [] ){
    //тут код создания мока
   $this->mocks[] = $mock;
    return $mock;
}

protected function tearDown()
    {
        $this->mocks = null; 
        parent::tearDown();
    }

Разве нет?

Принцип DRY на примере Laravel

Еще добавлю, паттерн декоратор работает с композицией, а не с наследованием. При паттерне декоратор, можно в теории делать сколько угодно слоев декорирования, в этом его смысл. Например вы захотите сделать еще один декоратор, вы будете что декорировать наследованием? LogCreateUser или CreateUser?
Декораторы выглядят так:

SendEmailCreateUser(new StatCreateUser(new LogCreateUser(new CreateUser())))

Принцип DRY на примере Laravel

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

Единственное но — это больше кода, а если проект небольшой, то плюсы которые выходят в статье — просто могут не понадобиться в небольшом проекте.

Неплохой доклад на тему CQRS, как раз с разбором нарастающих проблем.
www.youtube.com/watch?v=mvIXCgwGf9E

Laravel. Локализованный роутинг

1. Дефолтная локаль без подпапки — настройка такая есть. hideDefaultLocaleInURL
2. Проверил свой проект — у меня возвращает 404 для несуществующей локали. Да и логика этой строчки другая. В данной строке вообще нет проверки на разрешенную/нет локаль. Плюс getForcedLocale берет локаль из env, что вообще в документации поверхностной нет. Т.е это некая дополнительная логика.

Laravel. Локализованный роутинг

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

github.com/mcamara/laravel-localization#translated-routes