Иван Корюков

Чтобы sql запрос выдал вам только уникальные строки необходимо в секцию select добавить слово distinct.
Вот так:
select distinct id, name, date...
Примерно то же самое можно сделать и через eloquent builder
Model::query()->distinct()...

Однако это работает именно со строками ответа.
Если же у вас строки ответа разные, но дата повторяется, то там нужно более сложное решение.

На моей памяти Windows Terminal никогда с tmux нормально не работал. И ConEmu тоже.
Адекватно себя ведут только терминалы из cygwin и mingw. Чтобы получить такой терминал достаточно установить git и открыть git bash.

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

nohup - это команда bash, которая просто указывает самому bash'у что фоновому процессу не надо отправлять сигнал HUP при завершении работы.
& это тоже фишка bash, позволяющая перевести процесс в фон

Проблема в том что php это вам не bash и он наверное сам отслеживает состояние запущенного им процесса.

Попробуйте использовать setsid.
В отличие от nohup это полноценная программа, которая запускает указанную в качестве аргумента программу в отдельной сессии. Как только целевая программа запущена setsid завершает работу. Это должно "отпустить" php почти моментально.

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

Как уйти в фон самостоятельно:
Процессы (работающие программы) имеют идентификаторы и знают кто их запустил, посредством хранения id родительского процесса. Т.о. у нас есть дерево процессов. Родительский процесс может управлять дочерними, и он должен при своём завершении завершать и свои дочерние процессы. Если он этого не сделает, то дочерний процесс сменит родителя на процесс с id = 1, т.е. на init процесс. Поэтому чтобы уйти в фон, ваша программа должна всего лишь остановить её родительский процесс.
Проблема в том, что родительский процесс для программы, которую вы запускаете в консоли - это сама консоль и нам не надо чтобы она закрылась.
Поэтому уходящие в фон программы перед остановкой родителя увеличивают уровень вложенности - т.е. запускают свою копию, и эта копия, будучи дочерней для первого процесса программы, убивает уже не баш, а вспомогательный родительский процесс.
Другой момент - это отвязаться от консоли. Тут всё просто - надо перенаправить stdin, stderr и stdout в файлы.
Ну и наконец надо позаботиться об управлении демоном, ведь пока что нам не остаётся ничего другого, кроме как посылать ему сигналы командой kill. Чтобы реализовать более понятные команды, надо сделать две вещи:
1) во время ухода в фон сохранить в файл pid результирующего процесса
2) написать немного кода в самой программе или во вспомогательном скрипте, который, при вызове его в консоли, будет читать pid из файла и манипулировать процессом.

Такая функциональность часто выделяется в отдельную библиотеку, можно поискать в документации или на гитхабе.

Другой вариант - использовать вспомогательные программы.
С одной стороны у нас есть возможности самого баша - jobs т.е. фоновые процессы, которые однако умирают при закрытии консоли. Чтобы это обойти есть команда disown и программы nohup и setsid.
Они позволяют так или иначе получить процесс отвязанный от баша. Однако управлять процессом можно будет только сигналами.
С другой стороны есть менеджеры процессов. Например supervisord или pm2. Это такие программы, которые умеют уходить в фон и умеют, уже будучи демоном, запускать другие программы и управлять ими.

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

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

Возможность самостоятельно уйти в фон и реализация собственных команд управления процессом нужна только если у вас наполеоновские планы и вы хотите дать пользователям возможность запускать вашу программу на разных ОС.

Важно не то, где код находится, а то, в какой последовательности данные отправляются/заносятся.
Если это на одной странице, то старайтесь сделать это одной большой формой, либо собирайте данные с форм и отправляйте потом на сервер сразу все данные.

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

Понимание ООП приходит с опытом. Сначала надо написать много кода, самому заметить его недостатки и тогда перечитывая те же самые статейки вы начнёте по новому понимать, что вот конкретно эту штуку можно было бы использовать в том моём коде, и было бы лучше.

Я разделяю ООП на аутентичное и классическое. Аутентичное, это ООП как его представлял автор - объекты обмениваются сообщениями.
Классическое - это то как оно реализовано в Java.
И там и там есть инкапсуляция и полиморфизм. Наследование это приятная фишка классического ООП. Так же как и все пляски с типами. Вообще строгая типизация не является частью ООП. По крайней мере не является частью аутентичного ООП.

Поэтому переход на typescript позволит только более точно воспроизводить классическое ООП. Ну и проверку типов добавит. Это само по себе полезно, но для ООП никакого значения не имеет.

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

Заметьте, про js я почти ничего не сказал. Потому что дело не в нём. Дело только в понимании ООП. У языков программирования, конечно, есть различные возможности и ограничения что которые позволяют использовать ту или иную парадигму. Но ООП на js можно было делать и до es6, просто потому что в js можно инкапсулировать код в объект.

И ещё, когда мы начинаем делить код на объекты, необходим механизм разделения кода на файлы и собирания его обратно. Т.е. нужна модульность. Лучше всего, конечно, использовать webpack, но вроде как в js есть и другие системы. Не сборки, а именно подключения модулей.

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

Т.е. ваши сервисы не должны запускаться по крону, а должны постоянно работать.

Вообще некоторые сборщики js кода, такие как webpack и rollup умеют делать tree shaking, т.е. по цепочке импортов и вызовов понимают какой код используется, а какой можно в итоговый бандл не собирать.

Вот вам в эту сторону копать надо.

ssh + htop
а вообще мониторинг серверов это очень обширная тема

Нужно.

В автодополнении есть две крайности.
Вариант один - просто разбиваем текст на слова, добавляем в список ключевые слова текущего языка и как-нибудь подсказываем то что начал набирать программист.
Вариант два - выполняем честный анализ кода, прям как это делает компилятор/интерпретатор, и в зависимости от контекста в котором набирается слово подсказываем только возможные варинты. Ну например, если мы набираем определение класса, то после названия может быть либо extends либо implements. Если набрали extends то дальше однозначно будет название класса, причём не финального.

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

Я для себя определил универсальный подход для отладки в любом сетевом окружении.
В простейшем случае, когда разработчик один, а сервер за NAT, надо на сервер прокинуть порт через ssh.
ssh user@host -R 9000 localhost:9000
При этом в php.ini xdebug надо настроить чтобы он коннектился на localhost:9000.

Когда разработчиков много, я использую модифицированный dbgp прокси.
https://github.com/MadridianFox/php-xdebug-proxy
Если он стоит на том же сервере что и php, настройки xdebug те же. Прокси слушает 9000 порт. Каждый разработчик выбирает себе уникальный порт и прокидывает его по ssh на сервер. Так же надо обратно прокинуть 9001 порт чтобы зарегистрировать свой idekey в прокси.

ssh user@host -R 9002 localhost:9002 -L 9001 localhost:9001

И самое главное - при регистрации своего idekey через шторм в поле idekey надо написать myidekey:9002
В этом же окне порт прокси - 9001, хост прокси - localhost.

В настройках шторма указываем что для отладки надо слушать 9002 порт.

В браузере, не важно, используете вы расширение или прописываете XDEBUG_SESSION_START, надо указать myidekey без порта!

В случае с докером вы можете либо добавить ssh сервер в контейнер с самим php, либо поднять дополнительный ssh контейнер. При единоличной разработке этого достаточно. Просто в зависимости от размещения ssh прописываете разные хосты в xdebug. Прокидывает туда порт.

Если разработчиков больше одного - выделяете контейнер с ssh + dbgp прокси и каждый разработчик прокидывает туда свой порт.

Запоминайте какие классы куда добавили и при обновлении расставляйте их заново.