metallix

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

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

Учитывай ещё и бюджет заказчика своего, тк бюджет явно будет ограничивающим фактором при разработке

Вариант два: проведи преданалитику и оцени трудозатраты. Далее смотри на свой ценник за час / за более мелкие подзадачи, смотри п1.

Если по обоим способам не можешь назвать цену (например преданалитика требует больше времени), то тогда можно попробовать "долгосрочное сотрудничество", где заказчик будет платить не за сделанный проект, а за затраченные часы.

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

В целом телеграмовские мини-приложения - это обычные SPA, так что можешь ориентироваться на них.

Нужно ещё смотреть, на сколько детально проработано ТЗ. Нарисован ли дизайн и прочее.
Уже на берегу ясно, что много часов уйдёт на разные уточняющие вопросы заказчику.

Я просто не понимаю откуда берётся 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 уже само по себе хорошая документация, а "сложность структуры БД неумолимо растет" больше про проблему проектирования базы.