metallix

Я просто не понимаю откуда берётся Providers в пути автозагрузки

модель расположена в нестандартном месте

App\Providers\Models

от этой модели вызывается метод factory который относится к трейту HasFactory, там вызывается куда передается неймспейс твоей модели и подставляется к шаблону для неймспейса фабрики

Соответственно есть 2 пути решения:
1) перенести модель по пути App\Models (переносишь файл, обновляешь неймспейс)
2) объяснить laravel где искать класс:

В GameFactory

class GameFactory extends Factory
{
    protected $model = \App\Providers\Models\Game::class;
...

В app/Providers/AppServiceProvider.php

public function boot(): void {
     // ...  
    Factory::guessFactoryNamesUsing(function(string $modelName) {
         return 'Database\\Factories\\' . class_basename($modelName) . 'Factory';
    });
}

1. Перед спавном проверять коллизии. Если есть коллизия - выбирать другое место
2. Спавнить по умному - например, по сетке. Или вычислять точку спавна на основе уже имеющихся машин.

У вас же тупой простой рандом - в нем нет никаких логик проверок - поэтому увы

Быстрее будет присвоение $someProperty = $this->someProperty до цикла.
Но это именно про приведённый код с учетом, что цикл 1000 внутри someMethod. Прирост скорости настолько незначительный, что в реальных условиях может выиграть и echo $this->someProperty;
Но ведь в реальности такой код не имеет смысла...
Если уж заменять, то с реальными циклами и требуемым окружением.

По памяти разницы нет - создание новой переменной без изменения не выделяет дополнительную память.
`CV` - compiled variable == ссылка на реальную переменную.

// для echo $someProperty;
0000 EXT_STMT
0001 T0 = FETCH_OBJ_R THIS string("someProperty")
0002 ECHO T0
0003 EXT_STMT

// для echo $this->someProperty;
0000 EXT_STMT
0001 T1 = FETCH_OBJ_R THIS string("someProperty")
0002 ASSIGN CV0($someProperty) T1
0003 EXT_STMT
0004 ECHO CV0($someProperty)
0005 EXT_STMT

Мини-микро-нано прирост скорости возможет только из-за того, что в цикле для `echo $someProperty; ` будет выполняться только ECHO, тогда как для `echo $this->someProperty; ` две инструкции FETCH_OBJ_R и ECHO.

Вынесено из комментариев.
Василий Банников , ну, что вам на это сказать?

Сильно легче код писать таким образом.

Писать - да, читать - it depends, как говорят англичане.

Если тебе сложно понять смысл кода без типов - значит кто-то плохие имена дал переменным.

А разве в legacy 4-5-летней выдержки, над которым поработало много программистов, хороших и разных, по-другому бывает? А ещё имена могут дать хорошие, понятные - но основанные на системе понятий, которая нетривиальна и не попала при этом в документацию. Чтобы понять, о чем я - попробуйте почитать исходники подсистемы маршрутизации в ASP.NET Core. лучше всего - после работы с чем-нибудь типа MVC или Razor Pages: сомневаюсь, что вы сразу въедете, что Model там и Model тут - это разные Model.

А ещё бывает, что методы называются почти одинаково, но типы значений у них разные. Пример: builder.Services.AddOptions() и builder.Services.AddOptions<TOptions>() из кода конфигурирования контейнера сервисов, методы расширения IServiceCollection для Option Patterns - типы возвращаемых значений у них разные. А их ещё любят цеплять друг к другу к таким же методам через точку - вот и смотри потом, чой-то в ConfigureOptions какие-то лишние параметры вылезли.

с анонимными типами без var работать было бы очень сложно.

Правильный вопрос - зачем вообще заставлять работать с анонимными типами? Подозреваю, что их из-за маршрутизации в MVC завезли - как типы параметров, вместо того, чтобы передавать в методы генерации ссылок вместо IDictionary<String,Object>, как это оно там реально требуется. Но, в Microsoft решили, видимо, тогда не делать инициализаторы для словарей (при том, что потом всё равно сделали, не отвертелись), а притащить вместо них анонимные типы (интересно откуда - неужели прямо из JS?). Но это не точно. (Ага, в комментарии мне напомнили про LINQ)

Тренд говорит об обратном - автоматический вывод типов сейчас есть практически во всех статически-типизированных языках в том или ином виде.

Это потому что сейчас главное - быстрее писать MVP, для веба - особенно. Ну, а потом можно сказать волшебное слово: "Legacy".

Ну и помни ещё, что ты же не в блокноте код пишешь

Но читаешь-то ты его не только в IDE. В частности, MS в своей документации на сайте в примерах очень любит писать var - вот и выбирай потом, что делать: лезть прямо сразу в документацию по API (а ссылки отнюдь не прилагаются) или рисковать упустить что-то важное? А если ещё учесть, что сейчас принято документацию ограничивать примерами (MS любит, да) - оно вообще весело.

Но, с другой стороны, автор вопроса, похоже, с трех- и более этажными дженериками ещё не сталкивался (ну, или забыл, как они выглядят) - там без var тоже грустно.
Как-то так

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

Итого, есть три пути:

1. Беспроигрышный. Это Wordpress. Берете, делаете, все счастливы. Туториалов миллиарды, плагинов ещё больше, всё будет зашибись. Проблема одна: если надо будет тонко настраивать, то надо будет хоть немного изучить PHP.

2. Когда надо быстро что-то добавить, даже с мобилы или с компьютера девушки, и чтобы оно сразу отобразилось на сайте, то либо смотрим в сторону п.1, либо если не хотите изучать PHP, выбираете себе CMS на базе Javascript. Есть даже так называемые headless cms, которые генерируют вам только JSON, а вы у себя на фронтенде сами его обрабатываете и рисуете всё на основе полученных данных.

Это самый сложный вариант из трёх

Вот список некоторых из таких CMS
https://jamstack.org/headless-cms/

3. Если вам не нужна молниеносная публикация новых материалов, и вы можете потерпеть до доступа к рабочему ноуту, то можно выбрать генератор статических сайтов.

Сразу посоветую вам Astro https://astro.build/

Прелесть Astro в том, что новый контент вы можете писать в Markdown. Это такой простейший язык разметки текстовых документов. Вы сможете его выучить за час, не больше. Там всё настолько интуитивно и просто, что больше времени вам не понадобится. При этом формат мощный, убедиться в этом можно, посмотрев почти любой репозиторий на Гитхабе. Практически каждый из них имеет файл README.MD, где как раз всё написано в Markdown (MD)

В Astro вам надо будет создать несколько шаблонов astro (html). Шаблон хедера, футера, сайдбара, основного контента, разных типов страниц (статья, список статей, и т.д.). И в этих шаблонах будет указано, где нужно выводить сгенерированный из Markdown контент. И далее новые странички вы будете добавлять путём добавления в соответствующие папки файликов с Markdown разметкой. Это очень просто, быстро и не напряжно.

После добавления этих файликов вы запустите генерацию сайта, и Astro сгенерирует вам кучу готовых html страничек, которые вы просто зальёте на сервак. Профит!

Берите youtube, набирайте там "Astro markdown", и изучайте туториалы. Процесс всего этого чрезвычайно прост, вы много времени не потеряете, зато сэкономите себе массу времени на создании новых материалов на сайте

Можете посмотреть и другие генераторы статических сайтов тут https://jamstack.org/generators/

Укажите запуск команды композера от имени текущего пользователя на хосте:

docker compose run --user $(id -u):$(id -g) composer create-project laravel/laravel .

Вы также можете задать пользователя по умолчанию в composer.Dockerfile:

FROM composer:latest

WORKDIR /var/www/laravel

RUN adduser -D -u USER www-data
USER www-data

ENTRYPOINT ["composer", "--ignore-platform-reqs"]

Похоже на попытку реализовать язык Prolog или его форк.
Любые попытки использовать это в документации приведет к тому, что нужно будет всем учиться читать такие записи, и техническому писателю учиться правильно формировать их без логических ошибок.
Лучше подобные фичи описывать как теоремы/гипотезы в математике:
1. Условие применимости фичи (область действия теоремы/гипотезы).
2. Суть фичи (формулировка теоремы).
3. Результат применения (что получаем).

Диаграммы же. Смотрите в сторону с текстовой базой. Типа UML и прочее. Вот еще тоже неплохой онлайн инструмент для создания диаграмм из текстового описания: https://www.mermaidchart.com/landing (можно запустить локальный инстанс у себя).

UPD1:
Пример флоу-диаграммы русалки:

flowchart TD
    A[Полльзователь] --> B(Скидка)
    B --> C{Тариф - платина?}
    C -->|Да| D[15%]
    C -->|Нет| E[5%]

Картинка:

UPD2: Можно взять что-то гибридное типа ЯП Дракон.

{{isset($item->quantity) ? $item->quantity : '0'}}

Единственное что могу предполагать это не совместимость версии и правил валидации кода PHP.

APP_ENV=production 
APP_DEBUG=false

Плюс на локальной машине скорее всего отключен вывод варнингов.

Поставьте диод в разрыв +5 которые идут к ESP. И за ним - конденсатор электролитический побольше.
Вообще лучше разделять питания силовые, аналоговые и цифровые. В данном случае - питать драйвер/двигатели от отдельного источника.

ORM уже само по себе хорошая документация, а "сложность структуры БД неумолимо растет" больше про проблему проектирования базы.

Пройти типы в go и узнать, что это массив из byte длиной 4