Руслан Махин

Замените

@keyup.enter.prevent

на

@keydown.enter.prevent.exact

select u.* from users as u
inner join messages as m
  on u.id = m.user_id
group by u.id
order by max(m.createdAt);

В общем сдедал. Создал файл /etc/dnsmasq.d/dev.conf со следующим содержимы

listen-address=127.0.0.1
address=/.dev/192.168.1.200

Что удивительно, если вместо .dev будет .local, то не работает.

var str = ' some     string  and        something  ';
str = str.replace(/ +/g, ' ').trim();

str.replace(/\s+/g, ' ').trim()

$response = $client->request('PUT', '/put', ['json' => ['foo' => 'bar']]);

docs.guzzlephp.org/en/latest/request-options.html#json

Из коробки в Symfony4 есть простенький компонент Messenger.
Но если нужно сделать именно демонизированную обработку - то есть бандл, который вполне себе стандарт отрасли :)

Вот хорошая статья, где все по полочкам разложено.

Как хранить бизнес-логику чтобы модели не превратились в монстров из десятков тысяч строк?

Тут не совсем модели. Entity - это просто объект данных, умеет хранить их в себе и бросать исключения, если не правильные данные вставляете, все. Repository - умеет работать со своим Entity И БД.

БЛ находится в классах сервисах.

Читал про Command Bus где, если правильно понял, на каждое действие в системе – свой класс?

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

Как их организуете (их тогда будут сотни)?

Иерархически. Путь к классу должен быть "понимаем".

Есть ли смысл выносить каждую доменную модель в модуль/микросервис, хранить всю связанную логику где-то там внутри, а с остальными общаться по внешнему API?

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

За ответы в клиентскую часть – отдельный сервис-фронтенд?

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

Каков оверхед?

Ничтожный.

Используют ли такое на практике?

Да

Какие подводные камни?

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

Как не превратить кидание/получение событий типа PostBeforeEdit/PostBeforeEditHandler в "callback hell"?

Если есть возможность отказаться от событийной модели - часто лучше отказаться.
Листнеры доктрины конечно штука мощная, но работает не всегда очевидно.

Функционал "PostBeforeEdit/PostBeforeEditHandler" часто дешевле и проще вынести в сервис, но опять же руководствуйтесь здравым смыслом.

ACL Где храните указанную логику?

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

Какие структуры для описанного выше – best practice?

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

В моём понимании это выглядит как куча трёхмерных кубов доступа "crud – group – entity – field", как это сделать более плоским пока только одна идея – делать кучу таблиц many-to-many.

Гибкая настройка вплоть до каждого поля 90% что не нужна. Если можно свести к понятию скопов прав - сделайте это.
Структуру можно предлагать только зная ваш проект.

Версионирование. Как вы версионируете подобные проекты?

Semver.

А если нужна "N-1" рабочая версия на продакшене?

Значит на прод попадает ваша версия с тегом "N-1"))

Есть ли смысл разделять версии в рамках единой кодовой базы проекта и как (неймспейсы, конфиг, модуль, что-то ещё)?

Храните яйца в отдельных корзинках. Если модуль развивается полностью отдельно и может быть вынесен как зависимость проекта в vendor - делайте.

И, самое главное – как всё это совместить?

• РУКОВОДСТВУЙТЕСЬ ЗДРАВЫМ СМЫСЛОМ
  
• Принимаете жесткие соглашения по правилам написания кода, например такие
  
• Постарайтесь убедить бизнес в том, что без покрытия кода автотестами будет дороже, нестабильней и дольше. + Пишите тесты. Если объем тестов в 4 раза больше кода, который они тестируют - это норм. У меня бывали случаи, когда для критичного функционала тестов было в ~16 раз больше, чем кода.
  
• Жесткие, обязательные кодревью.
  
• Если задача крупная - декомпозируйте ее.
  
• Технический долг - возвращайте обязательно И как можно скорее.
  
• Перед тем как писать код для работы с внешним сервисом - имеет смысл написать его эмулятор.
  
• Спешите только в случае серьезных проблем на проде)). Фичи "на вчера" отличаются от фич "на потом" только приоритетом выполнения, более ничем.
  

Симфонисты не работают с yii2 и не до конца понимают о чем пишут :)
Я скажу так: оба фреймворка на высоте, по возможностям одинаковы, но подходы очень разные.
Объективно скажу так: на yii2 не получится запускать отдельные модули без запуска всего приложения, тут у симфони2 огромный плюс. Так же у симфони более классные консольные команды для генерирования каркасов, мне больше нравится, чем gii(но дело вкуса). Но по факту большинство сильных сторон симфони не оправдывается в связи с высоким порогом вхождения. Найти хорошего симфони программиста намного сложнее, чем найти его на yii2. Поэтому взависимости от бюджета и масштаба проекта можете выбирать. Симфони2 - это больше уровень корпораций, yii2 более простой при практчески том же функционале.
Если знаете симфони2, то лучше подтяните его. Yii2 изучить намного проще, намного всё прозрачнее внутри работает, там Вам хватит пару вечеров, чтобы пройтись по исходникам и всё для себя понять как изнутри как работает.

Поддержи отечественного производителя: takama/daemon. К тому же пэкедж без лишних зависимостей.

Добрый день. Если вы хотите что то выводить в консоль - необходимо писать данные в поток вывода. В yii 2 для этого предусмотрен метод stdout. Пример использования:

private function log($success, $error = null)
    {
        if ($success) {
            $this->stdout(date("Y-m-d H:i:s") . ': Success!', Console::FG_GREEN, Console::BOLD);
        } else {
            $this->stdout(date("Y-m-d H:i:s") . ': ' . $error, Console::FG_RED, Console::BOLD);
        }
        echo PHP_EOL;
    }

Есть примеси

парсим большие csv

<?php
function getRows($file) {
    $handle = fopen($file, 'rb');
    if ($handle === false) {
        throw new Exception();
    }
    while (feof($handle) === false) {
        yield fgetcsv($handle);
    }
    fclose($handle);
}

foreach (getRows('data.csv') as $row) {
     print_r($row);
}