Daria Motorina

Школьная геометрия.
1) Сначала вычисляем угол, куда (X, Y) игрок (x0, y0) смотрит:
dx = X - x0; dy = Y = y0;
d = sqrt(dx*dx + dy*dy); - длина отрезка
alpha = arccos(dx/d); - вычисляем угол. Здесь нужно будет дополнить, т.к. знак может потеряться. Смотри на dx и dy.

2). Теперь строим угол обзора (betaLeft, betaRight):
betaLeft = alpha - ugObz/2;
betaRight = alpha + ugObz/2;

3). Всё. Теперь вычисляем точки, через которые будет проходить линия обзора:
xL = x0 + cos(betaLeft) * Radius;
yL = y0 + sin(betaLeft) * Radius;
xR = x0 + cos(betaRight) * Radius;
yR = y0 + sin(betaRight) * Radius;

И строишь через эти точки бесконечную линию, чтобы она выходила за пределы экрана. Можешь для этого подобрать Radius такой, чтобы он был больше разрешения экрана

Команду вы никак не "дёрнете". Но вы можете хранить её статус в каком-нибудь доступном вебу хранилище - например, Redis.
А если нужно совсем реалтайм - можно через очереди (RabbitMQ, beanstalkd) посылать из команды сообщения серверу вебсокета, который будет уже отдавать статус на фронтенд.

array_walk($pagesArray, function($v, $k, $p) use(&$s) {
  if (!isset($p[$v])) {
    $s[] = $v;
  }
}, array_flip($permisArray));

Перезагрузитесь, ёлки.
/tmp должен (но не обязан) очищаться при перезагрузке.
Если нет - загрузитесь с LiveCD и снесите.

1. Создай единую точку входа, и оставь ее в корне сайта, остальные файлы вынеси за пределы (Это не только сделает твое приложении более гибким, понятным, и структурированным, но и в случае отваливания веб сервера, такое когда-то у меня было, после кривого обновлении до php7, исходный код показывался браузером)
2. Не забудь про SQL иньекции. Никакой конкатенации или вставок PHP. Только плейсхолдеры и байндинг
3. Если есть возможность загружать файлы, нужно исключить возможность исполнения в этой папке.

Сегодня что, CORS day? В 100500 раз - браузер не даст обращаться просто так через js с одного домена на другой. Или ставьте сервер как бэк на роут в том же домене или же ставьте правильные заголовки allow origin.

Ну и в догонку - для браузера localhost это всегда пользовательская машина, но никак не ваш vps

Нажатие через js, сохранение в куках.

https://github.com/jenssegers/imagehash
https://github.com/xwiz/phash

Ищите минимальное расстояние Хэмминга и после - уже на них ищите отношения цветов пикселей (RED25%/TOTAL, RED50%/TOTAL, ..., GREEN25%/TOTAL, GREEN50%/TOTAL,....): каждого цветового сегмента одного канала к общему количеству пикселей.
Цветовой сегмент - это процент по цветовому каналу.
Самые близкие дроби нужного Вам цвета - это и будет то, что Вам нужно: похожие с конкретным цветом.

И нужно чтобы степень схожести цветов можно было задавать.

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

Уменьшить кол-во цветов: здесь и см. 1-й коммент!
PS: пока - можно без НС всё сделать.

на JS...

Хватаем текстовое содержимое элемента, с помощью регулярного выражения находим тот кусок, который надо обернуть в span, выполняем замену, записываем результат обратно в элемент, но уже не как текст, а как разметку:

document.querySelectorAll('.scroll_list li').forEach(n => {
  n.innerHTML = n.textContent.replace(/\d+ шт./, '<span>$&</span>');
});

// или

for (const n of document.querySelector('.scroll_list').children) {
  n.innerHTML = n.innerText.replace(/\S+ \S+$/, m => `<span>${m}</span>`);
}

...или PHP

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

console.log(__dirname);

С каких это пор "dir" переводится как "файл"?

console.log(require('path').basename(__filename));

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

Тут не совсем модели. 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 раз больше, чем кода.
  
• Жесткие, обязательные кодревью.
  
• Если задача крупная - декомпозируйте ее.
  
• Технический долг - возвращайте обязательно И как можно скорее.
  
• Перед тем как писать код для работы с внешним сервисом - имеет смысл написать его эмулятор.
  
• Спешите только в случае серьезных проблем на проде)). Фичи "на вчера" отличаются от фич "на потом" только приоритетом выполнения, более ничем.
  

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

Раскидываю по неймспейсам. Скажем все действия относящиеся к юзерам находятся в папке Users.

Только вы учитывайте что CQRS это прикольно но особо не нужно. К примеру это сразу подразумевает что вы используете UUID вместо автоинкрементов и прочей чуши. Можете сделать хотя бы как Дядя Боб предлагает в своей Clean Architecture. Просто сервис на каждое действие.

Есть ли смысл выносить каждую доменную модель в модуль/микросервис

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

Раньше для дополнительных действий мне достаточно было использовать что-то вроде beforeUpdate/afterCreate модели.

ну а сейчас вы будете эти вещи в сервисы пихать. Причем возможно не в один сервис. Вообще старайтесь не делать "хуков" и не будет с ними проблем. Есть к примеру DomainEvents такая штука, ну и можно все эти "дополнительные действия" в хэндлерах команд делать.

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

Просто забудьте об этих ивентах.

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

Есть в симфони security vouters, а дальше все зависит от того что вы делаете.

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

git + docker теги в мастере. Ветки нужно плодить только тогда, когда у вас система деплоится кастомерам и нужно поддерживать сразу кучу версий. Называется это gitflow.

На какие проекты (точнее, на код) можете посоветовать посмотреть для лучшего понимания? Ссылки на репозитории?

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

p.s. почитайте книжки:

- Эрик Эванс - Предметно ориентированное проектирование
- Крэйг Ларман - Применение UML 2.0

p.p.s. Все ваши загоны не имеют никакого смысла если вы не будете пользоваться практиками вроде Test-Driven-Development, ну или хотя бы покрывать систему интеграционными тестами. Без этого вы не сможете делать частный мелкий рефакторинг, а без этого ваша система быстро превратится в легаси.