Александр Ме

Junior разработчиком после выполнения пары проектов в отвратительном качестве не стать.

в моей голове junior - это тот, кто пишет круды и что-то там допиливает в проектах

Этот тот которому дают простое задание и говорят, как делать и он делает, так как ему сказали.

Я могу сделать какой-нибудь обычный crud с sql, но, видимо этого не достаточно.

У Вас не обычный CRUD, а тот который никогда делать не надо. Следует узнать о шаблозаторах Twig и Smarty. Попробовать сделать свою простую шаблонизацию на PHP, что бы отделять верстку о логики.

Также у меня есть пару книг популярных по этому языку и там тоже нечего взять полезного.

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

После того, как будет понимание о языке PHP и его возможностях, следует посмотреть на работу с SQL, создать несколько баз данных руками, попробовать JOIN из нескольких таблиц, написать простой CRUD каталог по архитектуре MVС, что бы понять, как реализуется роутинг.

Поиграться с каким нибудь API, делать получение и отправку запросов.

Изучать тему Linux и как работать в консоли, настройка LAMP и LEMP окружения.

Желательно посмотреть на Docker и Vagrant, запустить их у себя на машине и установить внутри какой нибудь обычный WordPress.

Попробовать работу с PHP фреймворками, сделать несколько простых проектов.

Изучать лучшие практики работы PHP правильный путь

P.S. и постоянно учиться чему то новому...

Отложить загрузку на 5 секунд - выход, но грубоватый (имхо конечно). Я делаю по-другому - оборачиваю код в скролл-ивент + задержка в 1 секунду. То есть, сайт загрузился быстро, и как только пользователь начал скроллить хоть чуть-чуть - секундный таймаут и загрузка дополнительных ресурсов. Гугл доволен, пользователи вообще не замечают задержки:

var fired = false;

window.addEventListener('scroll', () => {
    if (fired === false) {
        fired = true;
        
        setTimeout(() => {
            // Здесь все эти тормознутые трекеры, чаты и прочая ересь,
            // без которой жить не может отдел маркетинга, и которые
            // дико бесят разработчиков, когда тот же маркетинг приходит
            // с вопросом "почему сайт медленно грузится, нам гугл сказал"
        }, 1000)
    }
});

Вот это order_fields поле должно быть объектом. В целом, если хочется удобства, целостности данных и надежности, то неплохо бы вместо ассоциативных массивов использовать обычные объекты, самые простые с обозначенными типами для полей, да хоть с паблик полями, или сделать их readonly.

Возможно, это нормально, так и должно быть ? или как архитектурно правильно решать подобное?

Это нормально. Безликие массивы становятся осмысленными сущностями. Такой код становится проще понимать и поддерживать.

Используемый вами подход называется data transfer object (DTO). Широко распространенная практика. DTO отлично сочетается с иммутабельностью, которая присутствует в ваших классах.

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

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

Называется ORM. Находится в ответственности ORM слоя/фреймворка.

Нет, не так.
В 7 версии: т.к. сравниваем число и строку, то преобразовываем строку в число (int)"wow" = 0, и сравниваем результат: 0 и 0 - true.
В 8 версии: т.к. сравниваем число и строку, то проверяем содержит ли строка число, в данном случае - нет, не содержит (что-то вроде is_numeric("wow")), а раз не содержит - false.

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

store это обертка над putFileAs для удобства - смотрите здесь
putFile тоже использует putFileAs

Вот более стандартные статусы https://developer.mozilla.org/en-US/docs/Web/HTTP/... ИМХО 404 тут вообще не в тему

В исходниках Laravel или каких-то официальных пакетов они 204 вроде возвращают. Т.е. как бы уже по статусу 2** очевидно что запрос успешен, и всякие 'Удалено' там не нужны

Итак для тех кто, так же как и я, не будет видеть "скрытых" include. Но будет думать, что они ДОЛЖНЫ быть по всей логике, ответ следующий: для сервера apache есть .htaccess (да еще и не один, а во многих папках) и там будут правила перенаправления запросов RewriteRule (или аналогичные, например, вот справка https://httpd.apache.org/docs/2.4/howto/htaccess.html). Именно эти правила и могут вам помочь. В моем случае срабатывало правило

RewriteRule ^(Frameset|Journal|Objects|Reports)/(viewFooter|viewHeader|Structure|Operation)/$ index.php?mode=$1&action=$2

которое перенаправляло запросы вида /frameset/viewFooter на адрес /index.php с параметрами, а уже там был нужный include.

72% NTSC = 72% Adobe RGB = 100% sRGB
Если вам нужно работать с цветом в пространстве Adobe, то не подойдёт.
Если вы работаете с цветом в пространстве sRGB, то подойдёт.

sRGB имеет смысл выбирать, если вы планируете, что вашу работу будут смотреть обычные люди на обычных мониторах. (например вы занимаетесь веб дизайном)
Adobe RGB следует выбирать, если вы планируете потом свою работу пускать в печать (например вы работаете с фото и хотите потом напечатать их в журнале)

Полагаю, что на самом деле вы спрашиваете «откуда берется очередь emails». Сущности очереди, по большому счёту, в Laravel нет с точки зрения простого сайта. Вы названия нужных очередей указываете в конфигах приложения и супервизора, а дальше фреймворк сам под капотом их создаёт.

Нет, не только. Вебпак может что угодно собирать.
https://dev.to/marcinwosinek/tutorial-for-building...

*/30 * * * * rm -rf /systen/storage/cache/exchange1c

но, мне кажется, что удалять каждые 30 минут - не верно. нужно удалять в 30 (или больше) минут каждого часа. 30 * * * * rm -rf /systen/storage/cache/exchange1c