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

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

Ну а думать над оптимизациями не зная всей картины довольно сложно. И опять же не понятно причем тут setTimeout

Обмен данными лучше повесить на WebSockets а еще лучше на WebRTC (там есть поддержка UDP для обмена данными).

Убунту и собирать... зачем? Только собранные пакеты. И зачем вам phpfarm...

Если вы хотите управлять окружением для каждого проекта - vagrant (возможно + docker) + ansible/puppet вариант намного лучше так как потом можно будет наладить и автоматический деплоймент.

Теорию эффективнее подкреплять практикой. Выучили хэш-мэпу - реализовали. Выучили бинарные деревья - реализовали.

Паралельно можно изучать язык программирования, типы данных, ООП и т.д.

А вы я смотрю не угомонитесь никак.

С токи зрения конкретно реализации разницы нет, с точки зрения читаемости кода - второй вариант.

Просто прочитайте код:
1) вернуть инстанс если он есть иначе вернуть результат присванивания инстанс равен инстанцирование себя
2) если у нас нет инстанса, то мы создаем его, затем мы возвращаем инстанс.

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

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

между синьер PHP/Ruby/Python не сильно велика разница по ЗП. Более того, обычно эти самые синьер PHP знают тот же Python и/или Ruby. Возможно у вас статистика размыта за счет большего количества вакансий. Уровень ЗП все же вы определяяете. То есть вы можете найти мидла который получает как джуниор только потому что у него занижена самооценка или просто у него есть какие-то проблемы с тем, как начать разговор о деньгах.

Короче на уровень ЗП лучше вообще не смотреть. И на PHP можно спокойно кодить и много зарабатывать.

Вам нужна нормализация базы, вынесите жанры в отдельную таблицу и свяжите их через many-to-many связь.

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

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

C jQuery
$('.selector').data('item');
Без
document.querySelector('.selector').dataset.item;

Ищите что-то интересное на гитхабе или что-то что вы используете, заходите в ишус трекер, разбираетесь, фиксите и делаете pull request.

У вас в $jsonData ключи будут начинаться входить в диапозон [119, 125], что уже говорит о том что вы используете $jsonData не как массив а как хэш-мэпу.

Хотите массив - отдавайте массив скормив предворительно $jsonData функции array_values.

Коммиты можно делать хоть на каждый чих. Хотя логичнее было бы что-то законченное коммитить.

По поводу пушить код... вообще есть такое мнение что идеально когда у всех разработчиков хотя бы один раз в день код одинаковый. Пусть и не рабочий. То есть у вас есть master для стабильного кода и dev для разработки. Между ними можно еще staging впиндюрить. А дальше два варианта - feature-branch или feature-switch. Минус первого - изменения не должны ломать проект перед тем как попадут в dev ветку. При втором подходе вы каждую фичу оборачиваете в проверочку включена эта фича или нет. Ну и кому нужно - тот включает и т.д. Плюс этого подхода в том что у всех в команде кодобаза одна и та же.

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

arr = arr.reduce(function (result, el) {
    el.method();
    return result; // ничего не добавляем, на выходе будет то чем мы инициировали
}, []); // а инициируем мы пустым массивом

<div ng-controller="MyCtrl as my">
    <button ng-click="my.pressed = !my.pressed;my.loadData();">
    <table ng-show="pressed">
        <tr ng-repeat="row in my.data">...</tr>
    </table>
</div>

function MyCtrl(dataProvider) {
    var self = this;
   
    this.loadData = function () {
        if (!self.pressed) return;
        dataProvider().then(function(data) {
             self.data = data;
        });
    }
}

- { path: ^/api/\w+/(create|update|delete)$,   roles: ['ROLE_ADMIN'] }

Хотя по сути у вас не должно быть этих update/delete/create. У вас должно быть POST/PUT/DELETE метод.

Я обычно это дело прописываю в контроллере (через аннотации), либо разруливаю в сервисе. Если у нас все очень сложно - можно реализовать воутер (начиная с Syfony2.4 вроде как).