Сергей Протько

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

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

Используйте какое промежуточное хранишище, типа APC/APCu, или redis или записывайте в файл.

наплюйте на принципы единой ответственности и инверсии зависимостей, влепите сингелтон и вуаля! Ах да, и не забудьте про один базовый класс аля CObject или CComponent для вообще всего что есть во фреймворке (ну или в большей части его частей).

А если серьезно, то зачем? В целях обучения? Если так, то может имеет смысл сразу почитать литературу на эту тему? Сразу больше всего откроете для себя.

читаем документацию к composer:
https://getcomposer.org/doc/

В частности в пакетах указываются бинарники. По умолчанию они ставятся (а точнее симлинки на них) в vendor/bin, но можно в composer.json попросить ложить их куда-то еще:

{
    "config": {
        "bin-dir": "bin"
    }
}

Нет, это не нормально. Нормально выносить в трейты какой-то bootstrap код, или прокси-код для реализации композиции методов, но именно реализацию классов - не ок.

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

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

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

в хроме, в дебаг панели вы можете: посмотреть все обработчики событий на элементе (не очень помогает при использовании jQuery), или же поставить бряку на изменение dom элемента, и таким образом находить код, который собственно этот элемент и меняет.

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

https://github.com/blueimp/jQuery-File-Upload/wiki... - это единственное что я помню из готового. Но идея простая - загружаем на клиенте изображение в canvas, делаем с ним что нам нужно, сохраняем в base64 и отправляем.

Откройте для себя славный пусть DDD.

Вообще у вас обычная связь Many-to-Many, в этом случае у вас должно быть три таблицы:
card с полями id, car_number и всечто относится к машинам
goods с полями id. и остальными специфичными только для goods полями
и что-то типа goods_cars_link с полями goods_id, car_id, которые связаны через foreign key со своими таблицами.