Константин Китманов

Потому что оно не вызывается, а передается в функцию как функция-аргумент(колбек), для дальнейшего вызыва.

А зачем, собственно?
Банально ставить спиннер перед отправкой запроса и снимать его при resolve уже не работает?

Так ничего и не изменилось. В edit mode выделяешь грани, затем либо через ПРОБЕЛ ищешь "Bridge Edge Loops", либо просто жмешь на F

Мы стараемся не запускать эту проблему посредством code review, пытаясь распределить нагрузку по ревью между наиболее опытными участниками. Если в коде есть проблемы - тикет возвращается на доработку с замечаниями. Даже если банально не мержится с главной веткой. Попробуйте наладить этот процесс.

Также мы всё собираемся настроить Continuous Integration. Jenkins может прогонять по коду проверку на соблюдение стандартов и покрытие тестами, а затем показывать результаты в красивом виде. Если чей-то коммит показывает более чем N ошибок в расчёте на единицу объёма кода - можно возвращать на исправление.

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

Ещё пара идей.

• можно отправить разработчиков на какой-нибудь онлайн-курс по чистому коду, хотя я таких даже не знаю, но наверняка должны быть
  
• или устраивать "хакатоны чистого кода", на коих команда разбивается на пары-тройки, каждая из коих пишет какую-нибудь маленькую, но полезную, а главное чистую и оттестированную штуковину, причём тема - по собственному выбору. Потраченное время - оплачиваемое, разумеется. Это уже зависит от руководства фирмы, согласится ли оно на такие развлечения.
  

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

Ну и важно, чтобы у самих разработчиков была установка на хороший код, профессиональная гордость. У фрилансеров её, бывает, нет, а есть отношение "тяп-ляп, лишь бы работало и лишь бы часы оплатили, а там хоть потоп". Учитывая, что их заказчики занимаются code review нечасто, развитие такого отношения закономерно. Но всё-таки хочется писать красивые программы. Такое желание обязано быть.

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

if (window.navigator.userAgent.indexOf("OPR") > -1 || window.navigator.userAgent.indexOf("Opera") > -1) {
   // ...
}

if (window.opera && opera.toString() == "[object Opera]"){
   // ...
}

Представьте, что у вас два грузовика. Сначала они были одинаково пусты, потом вы загрузили в один грузовик пару мешков с песком, а в другой - мешок с углем.
Условно первый грузовик - master, второй - dev.

git checkout master
git merge dev

Теперь в master у нас мешки с песком и мешок с углем
А в dev, как и прежде, только мешок с углем.

Так что у вас не только те папки, которые в development, но и те, которые были в master.

Если вы пушили ветку development, то при clone она тоже должна была стянуться, просто на данный момент git смотрит на master. Напишите git status чтобы проверить, в какой вы ветке, и переключитесь на нужную.
Если ветки development нет, сначала вам предстоит её запушить.

В случае, если в двух ветках разные файлы (не противоречащие друг другу), то merge просто размещает их все вместе, как будто вы скопировали файлы из одной ветки в другую.
Но если в двух ветках в файлах с одинаковыми именами разное содержимое, выполняется auto-merging, т.е. попытка автоматически объединить два содержимых в одно. Эта операция успешна, например, если вы в одной из веток просто добавили в конец файла ещё одну строку, а в другой ветке не трогали файл вовсе.
Если содержимое менялось и в той и в другой ветке, происходит конфликт. Git вставляет в место спорного контента что-то вроде

<<<<HEAD 
один контент
<<< commit1111
другой контент 
<<<end

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

Есть там как раз подходящая статья https://docs.unrealengine.com/latest/INT/GettingSt...
А в основном - все так же, как и с C#/Unity. Так же - это в смысле как изучали их, так и изучайте Unreal.

Этот тип игр называется платформер.
1. Английский язык.
2. Javascript
3. Crafty.js
DEMO-заготовка для понимания из документации.

pointer-events: none;

транспайлер нужен не для того чтобы es6 работал. транспайлер нужен, чтобы конвертировать код написанный на es6 в код на es5, т.к. не все браузеры понимают es6. nodejs поддерживает es6 практически на 100%, смотрите здесь

Ну зашибись идейка!
Необходимость что-то спросить часто (почти всегда) возникает внезапно. И ты такой идешь за помощью, а тебе херакс - сначала сам ответь на 10 вопросов! Прям сейчас ответить?.. У меня задача горит, а вы меня грузите своей дедовщиной? 9 из 10 просто уйдут, 1 нафлудит мусора в 10 вопросах, чтобы пройти фильтр.

Вот что было бы реально полезно - так это кнопка "не нравится". Иногда очень хочется.

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

Зачем разбивать класс на файлы?
Может и переменные класса по файлам разделить?
Изврат же полный и как раз таки оверхед.

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

Про GitHub.

1) Любой проект, даже самый маленький начинаю в новом репозитории. Потому что:
- мало ли что из него вырастет,
- код в Гитхабе это бэкап, не засерается место в Дропбоксе или других облаках,
- мгновенный поиск по коду в репозитории, актуально когда проект уже достаточно большой,
- легче спросить совета у коллег или показать проблему, когда исходники можно посмотреть онлайн,
- проект удобно хоронить, если он заглох, или закинуть в портфолио, если он клевый.

2) Создал себе на Гитхабе две дополнительные организации внутри своего аккаунта.
- «paulradzkov-forks» — для форков чужих проектов.
- «paulradzkov-heaven» — кладбище для старых проектов, куда перемещаются все неактуальные проекты.
Эти две дополнительные организации позволяют очистить основной аккаунт от мусора. В нем теперь только несколько актуальных проектов, в которых легко ориентироваться.

3) Перемещаю все старые проекты из Дропбокса на Гитхаб в «paulradzkov-heaven». Проектов много, это долго, но освободилось уже несколько гигов (т.к. там кроме кода psd-исходники, архивы с инсталляторами и прочее). Место в облаках заканчивается, а на Гитхабе — резиновое.
Это кладбище уже пригодилось, когда у меня попросили поискать исходники проекта, над которым я работал 3 или 4 года назад, а я через минуту ответил им ссылкой на нужный репозиторий. Не пришлось никуда лезть, распаковывать, искать, запаковывать, отправлять почтой или закачивать в облако.
Повторюсь, что на Гитхабе классный поиск по исходникам: если нужно посмотреть, как что-то сделал в старом проекте, но не помнишь в каком — можно довольно быстро найти искомое без возни с архивами.

Итого.
Код должен лежать на Гитхабе.
В том числе старые проекты.
Используйте организации, чтобы рассортировать проекты, если их много.
Порядок там, где у каждой вещи есть своё место. Придумайте себе правила порядка заранее и соблюдайте их, чтобы не тратить время на ликвидацию беспорядка.