Виктор Янышев

Можно-то можно, только вот у вас код бессмысленный. То, что возвращается из forEach попадает вникуда - никто эти результаты не использует и не может использовать. Возможно, вам нужен метод .filter? В любом случае, результатом будет массив объектов.

Вот как должен выглядеть ваш код:

var getActiveTab = function() {
    var activeTab = document.querySelector('.cont-tabs a.selected');
    var id = activeTab.getAttribute('href').match(/[\d]+/)[0];

    return {
        id: id,
        tabId: '#tab-content-' + id
    };
};

И тогда уже можете смело писать getActiveTab().id

Если я вас правильно понял, то действия следующие:
1. Берём родительский блок, задаём flex. Задаём два дочерних блока. Высота дочерних блоков будет равна высоте родительского. Это специфика flex-объектов.

<div style="display:flex">
  <div></div>
    <div></div>
  </div>
</div>

2. Для манипуляции ширины дочерних блоков используется свойство flex-grow:

<div style="display:flex">
  <div style="flex-grow:2"></div>
    <div style="flex-grow:1"></div>
  </div>
</div>

Это свойство действует как пропорция, всё пространство родителя делится на суммарное число flex-grow и каждой дочке выделяется столько частей, сколько указано в её flex-grow.
Можно также одной из дочек явно указать ширину width. Тогда другой дочке нужно присвоить flex-grow:1, чтобы она растянулась на оставшуюся ширину.
Вот пример. Надеюсь я вам помог =)

Потому что li используются в качестве inline-block`ов, которые имеют небольшой отступ. Добавьте ul св-во font-size:0; и a нужный font-size (https://jsfiddle.net/u0hggbnz/1/)

Привожу живой пример из личной продакшн практики. PHP-CLI скрипт как запускаемое приложение
Начальные условия:
Наличие GNU Linux (в моём случае это Debian)
Установленные пакет php, php-cli, остальные по вкусу и зависимостям
В качестве таймера используется класс React\EventLoop\Factory
1. Создаём пустой файл, можно без разрешения (например daemon), открываем в текстовом редакторе
Важно, чтобы в начале была строка #!/usr/bin/php -q
2. Пишем

#!/usr/bin/php -q
<?php
ini_set("display_errors", 1);
error_reporting(E_ERROR);
require "/var/project/vendor/autoload.php";
require '/var/project/bin/cli_config.php';
use Ratchet\Session\SessionProvider;

$loop = React\EventLoop\Factory::create();
//вызовы $loop->addPeriodicTimer можно ставить в нужном количестве, первый параметр - количество секунд
$loop->addPeriodicTimer(120, function(){
//код здесь будет выполняться каждые 120 секунд
});
//если нужен повторяющийся цикл 
//$loop->run();
//а если нужен один раз на вызов
$loop->tick();

3. chmod a+x /www/project/bin/daemon - даём права на выполнение
4. запускаем ./daemon будучи в папке с файлом. Если ошибок нет, всё будет работать
5. А ещё скрипт можно установить как демон в systemd и управлять с помощью /etc/init.d/daemon.service (start|stop|restart) и есть ещё bash-скрипт который будет держать службу на контроле и перезапускать если что, так как не всегда ошибка возвращает код и systemd считает, что процесс не упал, а его остановили, но это уже другая история

6. Для решения задачи "Требуется по запросу юзера (нажал кнопку) вести отсчет таймера от 120 секунд до 0 и произвести действие" в php на действие пользователя просто запустить exec('/var/project/daemon', $output_1, $exitval);

File -> export setting
сохраняешь архив

File -> import settings
загружаешь настройки с архива
потом он сам предложит обновить плагины

Таблица принятия решений (таблица решений) - очень эффективное решение для такого рода задач.
Из русской Википедии:

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

На английском - Decision table - можно найти гораздо больше полезного материала, чем на русском. Допустим, это видео с объяснением.
Таблицы можно хранить в СУБД и обмениваться при помощи CSV.
IBM и многие другие компании применяют их в разных своих продуктах. Особенно полезны для описания деятельности бухгалтерии, складского учета и пр.

Если вы все возитесь в одной папке для разработки, то у вас не только проблемы с CI\CD, но и в целом с культурой командной разработки.
Думаю вам можно начать со схемы попроще, чтобы люди в команде пообвыклись, поняли как улучшается коллективная разработка и потом уже на необходимый рабочий минимум вам нужно начать накручивать дополнительные фичи.
Только без лишнего оверхеда, ибо легко увлечься всеми современными трендовыми подходами для проекта, на котором оно не сильно надо.

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

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

Мне кажется уже этой схемы вам хватит надолго. А если и этого будет мало - можете продолжить плодить git-flow полный набор веток. Но для этого вы себе должны серьезно аргументировать их необходимость
Может быть для понимания CI\CD схемы на конкретном примере поможет такая статья antonov-dev.ru/blog/11
Там хоть и про битрикс, но общей идеи это не меняет особо

sudo echo "121.0.0.1 test.dev" >> /etc/hosts
sudo применяется только к вызову команды echo, запись в файл выполняется от имени обычного пользователя
правильно сделать так
echo "121.0.0.1 test.dev" | sudo tee -a /etc/hosts
echo выполняется от обычного пользователя, ее вывод перенаправляется на вход команды tee, запущенной от имени рута, она входной поток дописывает (-a опция) в конец файла, ну и дублирует в stdout.
получается запись в файл от имени рута.

Обычно в финансах работают с целыми числами, представляющими собой тысячные (иногда и десятитысячные) доли рубля. Доли, по возможности, представляют натуральными дробями. В этом случае ваша задача преобразуется из (12.50 * 0.2) в (12500 * 2 / 10). При целочисленных вычислениях минимизируется погрешность самих расчётов.

Следующая проблема - округление до целых копеек при сложении. Если мы получили 0.3 и 0.4 копейки (3 и 4 в тысячных долях рубля), то при их округлении получим 0.3 ≈ 0 и 0.4 ≈ 0, а при округлении их суммы получим 0.3 + 0.4 = 0.7 ≈ 1. То есть в результате будет 0 + 0 = 1.
Для решения такой проблемы применяют системное округление. Сначала все слагаемые округляются с отбрасыванием дробной части, а их сумма округляется по общим правилам. Вычтя из округлённой суммы сумму округлённых слагаемых получим количество единиц, которые надо раскидать. Затем исходные слагаемые сортируются по убыванию дробной части и соответствующее их количество округляется вверх.

Скажем слагаемые у нас 1.6, 2.7 и 3.8.
Их сумма 1.6 + 2.7 + 3.8 = 8.1
Если округлить слагаемые по общим правилам, то получим 2 + 3 + 4 = 9 ≠ 8
Округляем их с отбрасыванием: 1 + 2 + 3 = 6
Округлённая сумма 8.1 ≈ 8
8 - 6 = 2, значит два слагаемых с наибольшей дробной частью надо округлить вверх.
3.8 ≈ 4, 2.7 ≈ 3, 1.6 ≈ 1
4 + 3 + 1 = 8

Либо у Вас sourceLanguage приложения совпадает с language либо у Вас не находит перевод (в этом случае воспользуйтесь логом yii или дебаг-панелью)