Anton Mashletov, если нужна такая необходимость, то для этого лучше использовать переменные окружения.
А еще лучше пробрасывать этот флаг из самого первого уровня, где мы это объявляем:
Другими словами, проверками "не если такой константы вдруг нет, то давайте ее объявим" разработчики только усложняют жизнь себе и другим. В коде все должно быть четко: либо есть константа, либо ее нет)
Внешние ключи позволяют сохранять целостность данных в базу.
Другими словами если у Вас нет категории с id 555, то добавить видео в эту категорию не получится.
Так же как и взять и легко удалить категорию в которой есть видео.
Дополнение: бытует мнение, что называть классы как Manager, Helper и другими неоднозначными словами не очень хорошо. Критика сводится к тому, что таким образом нельзя легко и быстро понять из названия класса чем он занимается, и не является ли он одним из примеров god-object.
На мой взгляд, книга Мэта Зандстра достаточно хорошо приподносит материалам и расталковывает смысл и задачу ООП на примере простых шаблонов. К тому же охватывает многие темы, которые непосредственно относятся к работе php программиста: git, phing, phpunit и др.
Читал 4-е издание на русском: читается и усваивается легко, советую всем знакомым junior-ам
semki096: В моей ситуации получается, что в контейнере у меня идет работа только на локальных машинах разработчиков (те же баш скрипты позволяют быстро поднять окружение для разработки на локальных машинах)
Все остальное же разворачивается на gitlab runners, а они могут уже быть какими им вздумается: docker, ssh, virtualbox (полный перечень есть по ссылке)
Отвечая на вопрос зачем тянуть докер: он тянется по большей части на локальных машинах, чтоб не поднимать vagrant или что-то подобное. А так как мне важна максимальная приближенность к боевому серверу, поэтому выбор либо docker либо более тяжеловесный (в плане виртуализации) vagrant.
Все достаточно просто:
В целом все что выше описал (баш скрипты для автоматической установки и настройки нужных приложений в non-interactive режиме)
И все это подпитывается стандартным .gitlab-ci.yml файлом для гитлаба. В этом файле мы говорим гитлабу, какой образ взять (в случае докер раннеров), просим запустить наши баш скрипты установок нужного софта и запускаем тесты.
Самая большая проблема здесь - это скорость автоматической проверки и установки софта.
В моем случае используется ssh runner, поэтому установка софта происходит по сути 1 раз. В случае докер runner-а надо будет заранее подготовить базовый образ с установленным софтом, чтоб сборки проходили быстро.
По возможности 1 apt-get update на весь install скрипт. Все проверки софта через dpkg-query.
Так же важным моментом у меня было вынесение папки /var/lib/mysql в оперативку, т.к. банальное применение кучи миграций и заливка фикстур длились очень долго на HDD.
Итого на данный момент сборка "образа" и юнит тесты с покрытием проходят примерно 1 минуту, а если добавить функциональные тесты с покрытием, то уже сразу 3-4 минуты.
Ivan Sokolov: в том то и вопрос как их поставить. Ясное дело, что для просмотра исходников и документации их сначала надо скачать себе. Вопрос в том как это подключить в IDEA?
Для maven зависимостей можно нажать ПКМ и выбрать Download Source & Documentation, а для родных такого пункта нет и быстрый поиск ничего не дал.
Правильным решением кажется обновить пакет в надежде что там внесено исправление.
Если в пакете нет исправления, правильно будет создать pull request в GitHub на это исправление и довести до мержа, и потом обновиться