Александр Гамов

1. Включаем ip-forwarding
https://www.google.com/search?q=ip+forwarding+debian
2. Разбираемся с фаерволом и нат
https://wiki.debian.org/iptables
https://www.opennet.ru/docs/RUS/iptables/
3. Разбираемся с вланами
https://www.google.com/search?q=debian+vlan

Потому что */*, что означает любой тип.

1) и 2) это одно и то же. И это простая математика.
Перемножаете передаточные числа главной пары и выбранной передачи, умножаете результат на обороты мотора - получаете обороты колёс. Всё это умножаете на длину окружности колеса - получаете скорость.
Длина окружности = Пи * D.
Приблизительно диаметр колеса D (мм) = (размер колёсного диска в дюймах)*25.1 + 2*(профиль шины в процентах от ширины)*(ширина шины)/100%
Если точнее, то надо конкретные колёса на конкретном автомобиле замерять, и эта величина даже будет немного плавать в зависимости от давления воздуха в шинах. На некоторых спортивных машинах бывают передние и задние колёса разных размеров (не только на драгстерах, не только на болидах "Формулы"), в этом случае нужно брать размеры ведущих колёс (это задние, большего размера).
Ну ещё в конце перевести в привычные единицы измерения. Потому что частоту меряли в об\мин, длину окружности в мм, а скорость хотим в км\ч (наверное), а не в мм\мин.

3) это нельзя вычислить по формулам, это зависит от множества параметров (модель мотора, обороты, нагрузка, качество топлива, степень износа мотора, температура и давление воздуха, температура мотора, наличие компрессора или турбины и степень наддува; нагрузка в свою очередь зависит от скорости, включенной передачи, массы автомобиля (с учётом топлива в баке, с учётом массы водителя, пассажиров и содержимого багажника), степени износа деталей трансмиссии, давления в шинах, "злости" протектора и степени его износа, качества дорожного покрытия, наличия уклона дороги,... даже порыв ветра изменит мгновенный расход топлива в зависимости от того, встречный ветер или попутный). Мозги мотора (ЭСУД) всегда точно знают расход лишь потому, что они же сами и отдают команду форсункам каждую долю секунды, сколько топлива впрыснуть сейчас.

Если мы говорим про итерирование стандартных массивов php, то эти массивы - двусвязные списки, и их перебор наиболее эффективен при использовании указателя, а не обращения по ключу. Поэтому перебирать их следует с помощью итераторов (либо foreach, либо ООП итераторы, либо процедурные итерационные функции next(), prev(), reset() и т.д.). В js простые массивы устроены иначе, поэтому и работать с ними рекомендуется по-другому.
Для простого перебора слева направо всего массива достаточно foreach, но могут быть и более сложные варианты, тогда задействуются другие способы.
Насчет while(key($user_ar)), уже написали: while проверяет условие на true/false, если key($user_ar) = 0, то после динамического преобразования в bool, это будет false.

В общем проблема оказалась в конфиге php, был включен параметр mbstring.func_overload 2. А там по цепочке неправильно работал метод random_bytes, т.е. он выдавал строку, длину которой strlen считал не правильно. В итоге метод проверки валидности кук выдавал false.

Начиная с php7 композер будет выдавать ошибку, что этот параметр нужно выключить, так что сомневаюсь, что кто-то еще столкнется с этой проблемой.

Потому что PHP вообще никакого отношения к css файлам не имеет и никогда их не читает.

"Видит" css файлы твой браузер.
И достраивает к ним путь от текущего каталога.
Для того чтобы любой локальный ресурс, упомянутый в HTML, гарантированно читался, путь к нему надо указывать абсолютный, от корня веб-сервера.

То есть не file.css, а /folder/file.css

Подробнее читаем тут

Решил свой вопрос созданием класса мутатора, все шаги описаны ниже

Добавляем пакет кастомных типов данных

composer require mll-lab/graphql-php-scalars

Создаем класс мутатор

php artisan lighthouse:mutation ClassNameMutator

По пути /yourPath/appName/app/GraphQL/Mutations будет создан файл ClassNameMutator.php
Пишем в самом конце свой метод createOrUpdate

use App\Models\ModelName;

...

public function createOrUpdate($rootValue, array $args, GraphQLContext $context)
{
    $model = ModelName::find($args['id']);
    if ($model == null) {$model = new ModelName();}
    $model->fill($args)->save();
    $model = ModelName::select($args['field'])->find($args['id']);

    return $model;
}

В файле /yourPath/appName/graphql/schema.graphql прописываем следующее:

"A Json string with format normal Array"
scalar Mixed @scalar(class: "MLL\\GraphQLScalars\\Mixed")

 ...
    
type Mutation {
    uoiModel(input: uoi! @spread): Mixed @field(resolver: "ClassNameMutator@createOrUpdate")
}
input uoi{
    id: ID!         //Поле таблицы в запрос
    otherField: ID  //Поле таблицы в запрос
    field: Mixed    //Поля, которые нужны в ответ, указываются в виде простого массива ["field1","field2","fieldn"]
}

Теперь у нас есть мутация, которой можно легко пользоваться, запрос будет таким:

mutation {
    uoiModel(
        input: {
            id: 900003
            status: 49
            field: [
                "id",
                "status"
            ]
        }
    )
}

Данное решение подходит для таблиц как с инкрементным id, так и без

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

Развивайтесь в сторону создания более сложных вещей - там и технологии поймутся.
Более сложные - это всевозможные веб-приложения, забудьте о сайтах.
А приложения могут быть уже какими угодно и с большим разбросом по сложности - может быть CRUD админка которую любой индус накидает, а может быть какая-нибудь замороченная система бизнес-аналитики, где кнопки в браузере - это только 10% от всего функционала, и это одна из причин почему ищут фуллстеков. Фуллстек в состоянии взять фичу и сделать её полностью, а не "накидать кнопок и ждать бекенд" или "сделать апишку и отдать фронту".

switch ($ar['op']){
   case '+':
      $price_type3 = $value['p_type3_price'] + $setup['value'];
   break;

   case '-':
      $price_type3 = $value['p_type3_price'] - $setup['value'];
   break;

//И так далее

}

При разработке нормализованной или денормализованной базы размер HDD играет последнюю роль.

В первую очередь нормализация данных нужна для устранения бардака и, как следствие, упрощения системы (уменьшение количества состояний системы), что приводит к существенному уменьшению ошибок.

Нормализуя данные вы перекладываете часть логики проверки данных на СУБД, такие как консистентность и (частично) корректность. То есть уже на уровне вставки/изменения данных вы не можете не заполнить обязательное к заполнению поле или изменить поле в одной таблице, но забыть (или неправильно изменить) в другой (консистентность), вы не можете в поле date внести не дату, а в в поле int не int (корректность) и вы не можете удалить запись, если есть записи, которые на неё ссылаются (консистентность).

Нормализованное состояние БД это идеальное состояние базы, денормализацию нужно делать только если без неё никак не удаётся достичь нужных результатов (при условии, что вы разбираетесь как работает СУБД, как выбираются данные, индексы, сортируются и ищутся пересечения), если для вашей системы достаточно одного сервера, то в 99% случаев денормализация данных вам совершенно не нужна и противопоказана.
Проще говоря - если вы не знаете зачем нужна нормализация, то вам однозначно она нужна.

Замыкание, передаваемое в метод "load" модели или в метод "with" построителя запросов, принимает на вход Illuminate\Database\Eloquent\Relations\Relation (в данном случае, возможно HasMany или BelongsToMany). То есть, это тоже самое, как если бы вы написали:

$clinic->doctors()->each(function ($doctor) {
    $doctor->append('custom_atr');
})

Что не привело бы ни к какому результату, в виду того факта, что в Eloquent нет IdentityMap, который позволил бы связать записи вытаскиваемые при обходе each() c записями находящимися в отношении.
А вот что действительно поможет:

$clinic = Clinic::with('doctors')->find(1);
$clinic->doctors->each(function ($doctor) {
    $doctor->append('custom_atr');
});

Здесь мы делаем итерации над уже загруженными докторами.
Вообще, в данном конкретном случае, когда нас интересует одна конкретная клиника, даже `with` - лишний шаг, потому, что на следующей строке доктора все равно будут лениво загружены. Но для ясности можно и оставить.

Во-первых: начните изучать архитектурную часть программирования, изучите паттерны проектирования, изучите SOLID, DRY, KISS и остальные модные словечки, постарайтесь всё это осознать, или, на крайняк - зазубрить. Всё придет с опытом, изначально все не понимали зачем всё так сложно, но эта сложность обусловлена неисчислимыми литрами слёз и потраченных нервов, всё не просто так.

Судя по всему это тестовое или учебное задание. От вас требовалось отоверинжинирить простую задачу. Давайте попробуем:

Суть задачи - есть файл с определенной структурой хранения данных, структура строковая. Требуется этот файл преобразовать в другую структуру данных и вывести эту структуру в json формате. Задача ясна.

Разобъем задачу на отдельные независимые этапы:
1) Преобразование одной структуры данных (текстового файла) в другую (объект, понятный PHP, к примеру)
2) Преобразование этой структуры данных в Json формат.
Первый вопрос, который может возникнуть - почему сразу не преобразовать в json? Ответ - при расширении системы в будущем - нам понадобится вывести данные в виде массива, или в виде XML, или даже в виде готового файла Excel. Нам будет сложно дополнять логику изначального класса, ничего при этом не сломав и не затронув уже существующий функционал. Также ответом на этот вопрос может являться каждая буква из SOLID принципов, подробнее отвечу дальше, когда буду пояснять за реализацию, см. ниже

Теперь рассмотрим эту задачу с точки зрения ООП, начнем думать не от конкретной реализации, а от интерфейса и абстракции (мы не парсим конкретный файл, мы парсим просто файл, мы не переводим его в конкретное представление json, мы переводим его просто в представление):
Нам понадобится 2 класса - непосредственно класс, читающий файл и преобразующий его в простейший тип данных (например PHP array). Второй класс - преобразователь простейшего типа данных парсера в какой-то определенный тип:

1. LogFileReaded implements/extends FileReaderContract(интерфейс, возможно абстрактный класс, если понадобится предустановленная логика)
   
   Непосредственно наш преобразователь (не забываем, что передавать путь к файлу и все настройки нужно из вне, к примеру, в конструктор. Нельзя, как вы - хардкодить всё внутрь файла, на крайний случай - можно использовать конфигурацию), на ввод получает файл определенного типа с определенной известной структурой, на выходе выдает информацию из файла, преобразованную в базовый тип (массив, в нашем случае). Если нам когда-то понадобится парсить другой тип данных или структура данных будет изменена - мы сможем написать отдельный класс для этой логики, а не рушить целостность уже работающего кода, добавляя туда новую логику. Запомните - нужно стремиться не менять, а дополнять.
   
   
2. JsonPresenter implements/extends DataTypePresenterContract
   
   Абстракция содержит контракт на метод output(), а в конструкторе принимются исходные данные. В конкретной реализации JsonPresenter в output() будет банальный json_encode() (да, это нормально, нет, класс не лишний и нет, json_encode() нельзя пихать в сам парсер) А теперь к вопросу - почему не следует просто запихать это всё в парсер и вместо массива отдать json: в будущем, когда система будет расширяться - нам понадобится представить данные в виде XML - что тогда будем делать - переписывать весь код парсера ради добавления switch case "json" и т.д.? А если что-то сломается во всей системе? А если вариантов представления станет настолько много, что файл будет просто не читаем? А при данном подходе достаточно будет просто написать новый класс XMLPresenter, или даже ExcelPresenter, который на выводе не строку будет выдавать, а целый файл (опустим типизацию output пока)). Также этот класс можно реализовать в виде декоратора (паттерн), да и много еще как.
   
   

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

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

P.S. В данной реализации опускаются и упрощаются некоторые моменты для понятности

Файл /config/database.php, строка 53: 'strict' => true, (в "разделе" 'mysql'), значение поменять на false.

Подробности:

Заглядывали в issues? Почему-то мне кажется это ваша проблема. Вроде бы есть и workaround, а вроде бы последний комментарий не воодушевляет :)