Stanislav

Есть паттерн Worker Pool, пример можете посмотреть здесь: https://gobyexample.com/worker-pools

Сделай форк на гитхабе, внеси свои изменения в свой форк и подтягивай по имени форка, а не оригинала.

Укажите видимость переменной $arr. Например public. И что передается в метод test конкретно?

<env name="DB_DATABASE" value="test_database"/>

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

Я не знаю как ваш Users устроен, но в общем и упрощенном случае следует сделать так:

class Users extends Model {
    ...
    protected $id;
    protected $name;
    protected $password;
    ...
    public function getById($id)
    {
        // Т.е. мы возвращаем эту же модель Users, но уже с данными конкретной записи из БД
        return $this->where('id', $id); 
    }

    public function rating()
    {
        // Возвращает модель рейтинга данного пользователя
        // Саму модель рейтинга здесь хардкожу, но в реальности лучше что-то более гибкое придумать
        return RatingModel::where('user_id', $this->id); 
    }

    public function updateRating($rating)
    {
        // обновляем рейтинг данного пользователя
        $this->rating()->update(['rating'=>$rating]);
    }


    ...
}

Таким образом получается гибкая и понятная система. В самом коде используется так:

$user = (new Users)->getById(1);
$user->updateRating(200);

Статику следует использовать тогда, когда это оправданно и необходимо, и когда без неё нельзя.

function allUnique($str) {
    $strUniqueChars = count_chars($str,3); // 3 - режим, возвращается строка без повторений символов
     /* Если строка без повторений по длине равна изначальной
     * значит повторений изначально и не было */
    return strlen($str) === strlen($strUniqueChars);
}

var_dump( allUnique('1234') ); // bool(true)
var_dump( allUnique('41234') ); // bool(false)

PHP docs: count_chars

Во-первых: начните изучать архитектурную часть программирования, изучите паттерны проектирования, изучите 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. В данной реализации опускаются и упрощаются некоторые моменты для понятности

Нет. Как минимум следует сделать count в контроллере. А еще лучше воспользоваться Scope ларавеля и писать нечто вроде:

public function scopeHasPefrormer($query)
{
    return $query->where('performer_id', '<>', null);
}

$performersCount = $user->favorites()->hasPerformer()->count();

View отвечает за отображение данных, а не за их поиск.

Сайт не помрет, все будет в порядке, зависит от сервера и кол-ва запросов. Вообще лучше не делать так, как вы описали, если хотите действительно удобную и расширяемую функциональность. В идеале - поставить node.js сервер(в дополнение к тому, на котором стоит PHP) и socket.io / любую другую библиотеку WebSockets. Но если хотите использовать на сервере только PHP и JQuery / нет возможности использовать VDS/VPS - есть более простой вариант - использовать Pusher/PubHub/ любой другой удаленный обработчик сообщений, в таком случае вам ставить дополнительно на сервере ничего не нужно будет (ну кроме небольшой js библиотеки), но и придется дать денюжку, если запросов будет много, тарифы разные у всех.

Можно и на PHP сервер сделать, могу посоветовать удобную библиотеку Ratchet.

https://github.com/yiisoft/yii2/issues/7670

$config = [
    // ...
    'params' => require(__DIR__ . '/params.php'),

    // redirect to the page with the trailing slash
    'on beforeRequest' => function () {
        $app = Yii::$app;
        $pathInfo = $app->request->pathInfo;
        if (!empty($pathInfo) && substr($pathInfo, -1) !== '/') {
            $app->response->redirect('/' . rtrim($pathInfo) . '/', 301);
        }
    },
];

У меня работает, в чем конкретно проблема?

Нет, это ардуино. А вот программатор: www.banggood.com/ru/USBASP-USBISP-3_3-5V-AVR-Downl...

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

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

public function rules()
    {
        return [
            [
                'user_name', 
                'match', 
                'pattern'=>'/^[A-Z][A-Za-z]*_[A-Z][A-Za-z]*$/', 
            ],
        ];
    }

Почитайте про инъекцию зависимостей.

Интерфейс дает возможность использовать все реализующие его классы без изменения кода класса, где используются подклассы этого интерфейса (звучит криво, но вчитайтесь :) )

А суть паттернов в двух словах - свести к минимуму кол-во изменений существующего кода при добавлении новой функциональности.

Еще про SOLID принципы почитайте, тоже будет полезно.

SELECT max(id) FROM tablename

<?php

class Dish
{
    protected $ingridients;

    public function addIngridient($ingridient)
    {
        if($ingridient instanceof Ingridient)
            $this->ingridients[] = $ingridient;
        else
            die('error');
    }

    public function showIngridients()
    {
        foreach ($this->ingridients as $ingridient)
        {
            echo 'Ingridient: '.$ingridient->name.'<br>';
        }
    }
}

class Ingridient
{
    public $name;
    public $price;

    public function __construct($name, $price)
    {
        $this->name = $name;
    }
    //Код класса ингридиента
}

$soup = new Dish();

$soup->addIngridient( new Ingridient('water', '1$') );
$soup->addIngridient( new Ingridient('beef', '5$') );
$soup->addIngridient( new Ingridient('salt', '0.1$') );
$soup->showIngridients(); //нет ошибки

$soup->addIngridient('test'); //есть ошибка
$soup->showIngridients();