Станислав

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

При этом тут стоит понимать, что если мы посылаем к Селениуму запрос например для перехода на некий url (webdriver->get(url)), то Селениум ждет, когда это реально случится, и потом только нам возвращается управление (конечно, можно и асинхронно это попытаться сделать, но php-либа от ФБ это делает именно так). А вот когда мы посылаем запрос драйверу на закрытие (не помню как точно уже звучит, типа close() или quit(), наверное), то никакого ожидания мы не получаем, запрос улетает к вебдрайверу, и тот посылает запрос на закрытие браузеру, и соответственно при большой нагрузке на машину у нас этот запрос уже якобы отработал, но в реальности еще только закрывается окно браузера, а потом и тушатся его процесс(ы). И этот временной лаг может достигать десятков секунд.

Только лишь за наличие .gitconfig и .DS_Store я бы уже не рассматривал вас как кандидата - это значит, что вы в принципе не понимаете, чем это может помешать другим людям, а значит в принципе не участвовали в командных проектах. Более того, вы не удосужились и изучить, как оно там бывает. Уверен, что в данной компании даже джуниоров рассматривают из тех, кто что-то понимает в этом.

Далее я честно клонировал ваш апп и попробовал запустить "npm run test:style". Выдало, что такого скрипта нет. На этом моменте ревью было закончено, так как стало понятно, что вы либо крайне невнимательны, раз не включили этот скрипт в рабочую версию в ветке master (или наоборот не удалили, скопировав откуда-то шаблон?), либо не понимаете, что делаете в принципе, нахватавшись откуда-то верхушек, скомпилировав чужой опыт, и тд.

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

Для начала нужно разобраться со схемой работы с Git как таковой, как ее используют повсеместно. При работе над проектом с привлечением более чем 1 человека общепринято делать действительно какой-то общий, удаленный для обоих разработчиков репозиторий, будем называть его головной, с которым каждый из них обменивался бы изменениями.

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

Исходя из всего этого, я бы вам советовал выбрать ту или иную площадку для размещения вашего головного (обычно он получает имя origin) репозитория и после этого настроить к нему доступ со всех рабочих машин разработчиков, плюс можно на рабочем/тестовом сервере вашего проекта сделать аналогично, и разворачивать после там ваш проект. Обмен данными будет происходить через fetch/pull/push команды, о них подробно написано весьма много.

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



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

Конкретно под Убунту можно найти варианты здесь:

Если устанавливаете этот клиент, то вот так:

mkdir ~/.telegram2ndprofile
Telegram -many -workdir ~/.telegram2ndprofile

Также можно использовать клиент для Telegram, поддерживающий несколько аккаунтов.

Попробовать еще вот это:

Установить Chrome и устанавливать Telegram из Web Store.
Установить Wine и Telegram for Windows
Использовать приложение через https://web.telegram.org/ и соответственно в разных браузерах или в разных режимах (инкогнито / просто) / под разными пользователями (так например можно в Chrome) одного браузера.

Разные разработчики имеют тот или иной опыт работы и тот или иной стаж. Соответственно, если сейчас вам уже проще использовать Gulp, да и сами разработчики Bower уже не рекомендуют его использовать для установки пакетов, то вы используете Gulp. Но кто-то начинал ранее, или же просто первым делом столкнулся с Bower, и стал использовать изначально его.

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

Но при этом использовать везде Gulp для управления пакетами тоже нет смысла, так как для простых проектов это плюс один инструмент, который не факт, что нужен. Кому-то будет проще использовать чистый package.json и просто указать в инструкции своего проекта, что нужно запустить установку пакетов из него.

Самый удобочитаемый и короткий способ - сделать вот так:

$('.ads-category__link').on('click',function(){
  $(this).toggleClass('active');
});

Как несложно догадаться, метод toggleClass() не просто добавляет или удаляет указанный ему класс или классы, а "переключает" их, убирая, если они уже есть, или добавляя, если их еще нет.

Одно и другое - суть совершенно разные вещи.

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

GitHub, равно как и BitBucket, который кстати тоже поддерживается Cloud9, равно как и любой другой подобный сервис, не предоставляют возможностей для написания кода, подобных тем, что предоставляют обычно IDE.

Соответственно, ничто не мешает вашим программистам использовать оба этих решения, более того, определиться наверняка нужно только с одним - с местом, где будет храниться ваш код, то есть с сервером репозиториев, это может быть как GitHub, так и локальный сервер, так и любой другой, а вот определяться с тем, кто и где будет писать код, каждый программист может сам - кто-то пускай пишет код в Cloud9, кто-то - в PhpStorm, кто-то - в Notepad++, кто-то - вообще в vim, если захочет, главное, что из всех этих IDE (если по-простому, то из всех этих редакторов кода) код будет попадать в одно место, где будет можно просмотреть кто, что и когда писал, и что из этого стоит пустить на рабочий сервер, а что пока что потестировать, и тд и тп.

Есть два основных пути:

1. Использовать некий условно "движок", который позволяет это сделать его средствами, а именно - позволяет на определенный url сайта отдавать не просто некий файл, а некий результат выполнения некоего кода.
   
   То есть, при запросе вроде your-site.ru/blog/1 он будет отдавать не просто страницу your-site.ru/blog/1.html с обрезанным расширением, а обращаться к некоей функции (условно), которая будет понимать, что ей нужно обратиться к базе данных сайта, взять оттуда запись с индексом 1 и вывести ее пользователю.
   
2. Если описанный выше функционал не предполагается и нужно просто убирать расширения файлов, то воспользоваться функциями модуля mod_rewrite для веб-сервера Apache, а именно создать в корне сайта файл .htaccess и прописать в нем несколько директив:
   

   RewriteEngine On
   RewriteCond %{REQUEST_FILENAME}.html -f
   RewriteRule !.*\.html$ %{REQUEST_FILENAME}.html [L]

   
   Подробнее об этом можно найти в интернете по запросу вида "mod_rewrite remove html extension".
   
   

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

HTML:

<h3>click on picture</h3>
<video poster="http://i.imgur.com/NDOYT4L.jpg">
  <source src="http://video.dailymail.co.uk/video/mol/2015/11/07/2829942071241294818/640x360_2829942071241294818.mp4" type="video/mp4">
</video>

JS:

document.querySelector("video").onclick = function(){
	if(this.currentTime > 0 && !this.paused && !this.ended && this.readyState > 2){
  	this.pause();
    this.controls = false;
  }
  else if(this.paused){
  	this.play();
    this.controls = true;
  }
}

CSS:

video{
  display:block;
  width:300px;
  height:200px;
}

В целом стандартом для документирования API сейчас можно назвать Swagger.io. Для него, в свою очередь, можно найти пакеты как для интеграции его и Laravel, так и для преобразования его yaml-файлов в файлы с markdown-разметкой. Намного больше решений можно найти в Google по запросам вроде "swagger.io laravel", "swagger.io markdown" и т.д.

Вообще, тут нужно понимать, что все подобные задачи в Gulp решаются как правило за счет тех или иных плагинов для него. Так, конкретно для вашей задачи подойдет плагин gulp-modify-css-urls. Сначала вам необходимо установить его:
npm install --save-dev gulp-modify-css-urls
Параметр --save-dev укажите, если хотите, чтобы эта зависимость прописалась в ваш package.json в раздел dev. После этого вы можете модифицировать пути в файлах css с помощью примерно такого кода (взят из доков этого плагина):

var gulp = require('gulp')
  , modifyCssUrls = require('gulp-modify-css-urls');
 
/* style.css
body {
  background-image: url('images/logo.png');
}
*/
gulp.task('modifyUrls', function () {
  return gulp.src('style.css')
    .pipe(modifyCssUrls({
      modify: function (url, filePath) {
        return 'app/' + url;
      },
      prepend: 'https://fancycdn.com/',
      append: '?cache-buster'
    }))
    .pipe(gulp.dest('./'));
});
/* style.css
body {
  background-image: url('https://fancycdn.com/app/images/logo.png?cache-buster');
}
*/

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

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

Для этого нужно зайти в "Свойства системы / Дополнительно / Переменные среды", после чего в разделе "Системные переменные" (не спутайте с "Переменные среды для пользователя %User%") отредактировать переменную path, добавив в нее через строчку запятой расположение исполняемого файла Bower.

Лично у меня и npm, и Bower лежат в одной папке, поэтому моя переменная содержит только лишь путь до нее, это что-то вроде "C:\Users\Stas\node.js\4.4.0\"

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

Плюс, у вас в директории пользователя, судя по логу, есть каталог с именем .bowerrc, а его там быть не должно, вместо этого, при желании, там можно разместить файл с таким именем, в котором будет конфиг для Bower (google .bowerrc).

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

1. Создать команду (team):
   
   после чего сделать этот репозиторий репозиторием этой команды. Ну и соответственно ваши коллеги должны будут зарегистрироваться на Bitbucket, а вы должны будете пригласить их в команду.
   
   
2. Просто дать доступ к личному репозиторию, через специальный функционал:
   

После этого можете спокойно поменять свой пароль. Вам придется немного повозиться с настройками, плюс, например, вы можете сделать так, чтобы только вы могли одобрить pull в ваш репозиторий (так называемый pull request), но это все скорее плюсы, чем минусы.

Это что касается организации работы с самим Bitbucket. Далее, что касается "заливать изменения на действующий сервер". Если я вас верно понял, то таким образом вы реализовали деплой вашего проекта из вашего репозитория на сервер, где работает ваше приложение.

Это не совсем верный путь, а точнее - совершенно неверный, так как подобное можно проворачивать только на тестовых средах, где вы можете что-то подправить, подождать, пока случится собственно pull, ну и так далее. Попробуйте использовать что-либо вроде Capistrano, ну или что угодно еще из подобных утилит. Это решит вопрос и с хранением паролей, и со всем остальным. В крайнем случае, сделайте авторизацию через ключ, а не через пароль. В этом случае, один раз добавив его, вы навсегда забудете о вводе пароля от аккаунта при загрузке вашего приложения. Подробнее об этом можно узнать тут, ну и вообще погуглив про bitbucket ssh key.