Кирилл Текорд

1. GIT не относится не посредственно окружения для вашего кода, так что его имеет смысл использовать глобальный. А вот всякие composer / php / node / gulp / yarn /... - это часть окружения для выполнения, и их лучше держать прямо в контейнере.

Ладно там PHP со своими версиями, но эти же обычно обратносовместимы и не трубуют хранения зоопарка версий.

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

Да и PhpStorm можно один раз настроить указав путь в Git, ноде, File Watchers.

Это да.

Ведь с докером мне на каждом проекте все эти минификаторы, композеры указывать заново?

Да

Действительно ли оправдано использовать Docker одному или небольшой группой?

Да. Например хотите посмотреть проект годичной давности, но обратная совместимость зависимостей вашего проекта потеряна, такое сплошь и рядом.

Возможно, мои проекты не такого уровня, но мне действительно не критично воссоздать dev и prod окружение 1 в 1.

1 в 1 никто и не создает, а вот максимально похоже по стеку технологий - вот это правильно.

Ну и пусть там на боевом крутится php 5.6, когда у меня 7.1.

В таком окружении смысла нема. Ваш код будет работать по другому, на боевом сервере и на вирутальном окружении.

А если ты разрабатываешь с нуля и не знаешь какая будет конфигурация на боевом?

Ко боевому можно предъявлять требования.

Действительно ли деплой так прост, что заменяет все фтп-заливки, jenkins'ы, git-пуллы?

Нет

ikudryash:
1) Модель (везде) - это просто прикладной уровень доменного объекта (т.е. некоторый объект, отображающий предметную область). Она ни от чего не зависит и ничего не требует (в т.ч. наследования).
2) AR-модели (ну или любые другие анемичные модели) никогда и не при каких условиях не должны содержать валидацию бизнес-процессов. Эта зона ответсвенности DbC инвариантов. Если это не нравится - обычной практикой считается DTO. В случае Laravel - вам всё упростили и запили на блюдечке FormRequest'ы, которые автоматом валидируются при резолве из контейнера (т.е. при инжектах).
3) Валидация бизнес-логики должна всегда находиться на уровень выше, т.к. правила создания сущностей привязаны к непосредственной области действия (в том числе прав пользователя и прочего, т.е. зависит от задачи) и может быть разной в разных местах.
4) Для использования внешних сервисов в Laravel есть контейнер, который реализует автовайринг и двойную диспатчеризацию, в отличие от Yii, где подобного нет и фрейм нашпигован скрытыми зависимостями.

вполне должно работать.
html_element['my_custom_param'] = { my_val:1 };

Сам решил задачу =)
Может кому будет полезно:

'pattern' => 'katalog_<modul:(\w+)(/(\w+))?(/(\w+))?>',

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

Но хранить в одном поле данные в разных типах - это очен очень плохая идея. Аукнеться огромными проблемами в будущем. Лучше сделайте пару методов которые будут конвертит в DateTime. Или держите в полях только DateTime, и конвертите строки во время заполнения данных.

То что ты описал является Командой. Принципиальная разница, видна из твоего же вопроса, передавая через конструктор, ты можешь сохранить состояние - но при этом отложить выполнение команды, когда как во втором случае ты сразу передал и сразу сделал дело. На основе первого варианта, возможно реализовать шину команд без всяких траблов. Во втором случае, если данные в метод execute будут передаваться разные, шину команд будет реализовать сложнее, возможно, но сложнее.

// include gulp
var gulp                = require('gulp');
var browserSync         = require('browser-sync').create();
var localhost           = 'site.loc'; // изменить на свой хост
// browser-sync task and settings
gulp.task('browserSync', function(){
    browserSync.init({
        open: 'external',
        host: localhost,
        proxy: localhost,
        port: 8080
    });
});
// start watchers
gulp.task('watch', ['browserSync'], function(){
    gulp.watch('**/*.*', browserSync.reload);
});

Собственно, ставим gulp и browserSync, потом npm install.
Ну, а запускается всё это дело через gulp watch.

www.blendswap.com
https://archive3d.net/
https://opengameart.org/
https://www.davidstenfors.com/
Читаем лицензии, много чего можно использовать в коммерции, много чего нет.
В дополнении, можно поискать бесплатные в магазинах ассетов, возможно придется уточнять у автора можно ли использовать в коммерции:
сторы движков(unity, unreal),
www.turbosquid.com
https://www.gamedevmarket.net/

Для создание гуманоидов можно использовать программы Fuse и MakeFuman, с одеждой только могут возникнуть проблемы, ее мало. Анимировать гуманоидов можно в https://mixamo.com/ на момент публикации бесплатный для коммерческого использования.

И еще один момент, имей виду что качество будет сильно разнится и некоторые модели распространяются в форматах 3d редакторов, возможно придется сохранять самому в нужный формат.

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

Предложил бы отдельно хранить этакие "Ресурсы/Ассеты для оружия".
Какой-нибудь список где по айдишнику оружия, вы можете достать спраит, описание текстовое, модель..что угодно.
Методы для работы со списком возможно для удобства и всей этой инкапсуляции и тд.

Тогда логика оружия условно будет отделена от представления его. Хотите показать мечь - достали спраит из ресурсов - и показали его. а все остальное время храним набор айдишников.

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

Возьмем например Ваш объект репозитория, его достаточно зарегистрировать в контейнере так

Yii::$container->setSingleton('common\domain\Entities\User\Profile\Interfaces\Repository', // указываем интерфейс
    [ // указываем конфигурацию класса реализующего этот интерфейс
        'class' => 'common\infrastructure\Entities\User\Profile\Repository' 
    ], 
    [ // указываем какие данные необходимо передать в конструктор, в частности - экземпляр класса UserProfile
        Instance::of('common\models\ActiveRecord\UserProfile')
    ]
);

Контейнер соответственно сам проинжектит в объекты использующие common\domain\Entities\User\Profile\Interfaces\Repository объект common\infrastructure\Entities\User\Profile\Repository

Сервис регистрируется аналогично:

Yii::$container->setSingleton('common\domain\Entities\User\Profile\Interfaces\Service',
    [
        'class' => 'common\application\User\Profile\Service',
    ],
    [
        Instance::of('common\domain\Entities\User\Profile\Interfaces\Repository')
    ],
);

При создании сервиса, контейнер найден в своих данных объект соответствующий common\domain\Entities\User\Profile\Interfaces\Repository создаст его и проинжектит в сервис

Вы недооцениваете опенсорс. И смотрите только на быстрое получение прибыли с проекта.
Вот пару моментов которые пришли в голову:
1. Распространение своей технологии, своей продукции. Завоевать умы гораздо гораздо легче бесплатным продуктам, особенно когда этот продукт хорош. А люди, аудитория стоят дороже денег, надеюсь это не надо объяснять? В конечном счете подсадив людей на технологию можно ими управлять и диктовать свои правила. Это власть.
2. Деньги можно срубать с больших компаний использующих ваш продукт. Грубо: "Для того что бы я дальше развивал свою технологию мне нужны деньги, иначе я перестану ее развивать, она загнется, а вы, уважаемая компания, потеряете кучу времени и сил переходя на другое решение. По этому прошу отстегивать мне Н-ю сумму ежемесячно" Это грубо, но в целом именно так. Можно сюда еще включить то, что компании могут напрямую просить добавить какой-то функционал в следующую версию вашего продукта.
3. Банальные пожертвования.
4. Поддержка. Опять же, у крупной компании возникли проблемы или не понимания вашей технологии. Вы им оказываете индивидуальную поддержку за приличную сумму.
5. Вас будут приглашать на различные конференции, в универы, в компании и т.д. За это все можно и нужно брать деньги. Вообщем сюда попадает весь заработок с собственного имени и лица, как у голливудской звезды.
6. Еще можно делать технологию полу-бесплатной. Как Юнити, например. Можно юзать бесплатно, но если ваша игра набрала определенную аудиторию вы должны платить за их технологию. Весьма честно и хитро.
Да кучу еще всего можно сюда дописать. Главное - это аудитория и популярность. С этими двумя вещами можно ворочать горы.

Да. Хорошей схемой будет сделать интерфейс IDamageable, а в классах брони и модулей его имплементить. На броню и модули вешаете коллайдеры, далее во время рейкаста ищете у коллайдера интерфейс, наносите ему повреждения, а дальше по логике класса либо повреждается броня, либо ломается модуль, как сами захотите.

Думаю что никак... а спам не самый лучший вариант! - попадешь в спам-базу...

1. Генерацию события EVENT_AFTER_REMOVE стоит разместить сразу после коммита. Если размещать генерацию после блока try/catch может возникнуть ситуация когда в процессе удаления возник какой-то эксепшен, Вы его поймали и откатили транзакцию. Т.е. удаления по факту не произошло, а событие сгенерируется - это не совсем правильно
2. Не стоит, подписчики должны сами обрабатывать ошибки

использование именованных поведений позволяет:
1. Откреплять по необходимости поведения от компонента c помощью функции detachBehavior
2. Работать с поведением в классах-потомках (например, изменять конфигурацию поведения и т.п.)
3. Получать собственно сам объект поведения и при необходимости с ним работать