Павел

const result = tags.filter(n => active.some(m => m.name === n.name));

или

const result = tags.filter(function(n) {
  return this.has(n.name);
}, new Set(active.map(n => n.name)));

или

const tagsObj = tags.reduce((acc, n) => (acc[n.name] = n, acc), {});
const result = active.reduce((acc, n) => ((n = tagsObj[n.name]) && acc.push(n), acc), []);

В adblock добавьте. В нём можно указать путь до DOM блокируемого содержимого в настройках

вот твоя ошибка
if (empty($mes) or empty($mesname))

Сетевые принтеры расшарить, и установить на ближайших к принтерам компьютерах, как принтер по умолчанию.

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

USB принтеры так же можно расшарить для всех, но при выключенной host-машине принтер станет недоступен.

Snappy Driver Installer, как мне кажется

Зайдите по скрину в этот раздел меню и добавьте свой action
На скрине уже добавлен

https://learn.javascript.ru/events-change

<input type="text" id="login"> 
<script>
  var input = document.getElementById("login")
  var data = {
    "login":"",
    "password":""
  }
  input.oninput = function() {
    data.login = input.value;
  };
</script>

Заставить всех использовать LF и забыть об этой проблеме. PHPStorm достаточно умён, что бы и на винде понимать такой формат.

На сервере DHCP настроить так, чтобы по маку выдавался один и тот же адрес.

const data = $('table tr')
  .get()
  .map(tr => $('input', tr).get().map(n => $(n).val()))
  .filter(row => row[row.length - 1])
  .map(row => `(${row.map(n => `'${n}'`).join(', ')})`);

вопросы у вас философские, на каждый можно отвести часы обсуждения

Полноценный CI/CD поднимать не вижу смысла ввиду размеров

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

1) git не есть инструмент для развертывания по, git лишь для версионирования кода
и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
Артефакты желательно хранить в каком-то артефактории,
но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

2) как только вы получили артефакт - его можно деплоить
неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

В чем еще преимущество такого подхода: если вам нужно сделать roll-back на предыдущую версию вам не нужно собирать проект заново выкачивая все с гита, ведь у вас есть предыдущие артефакты, ролбек в таком случае вообще не проблема - просто указываем предыдущую версию артефакта и деплоим еще раз и все

3) Env Variables
когда приложение стартует - считывает все что ему нужно из переменных окружения
деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

Итого имеем
- логика сборки проекта описана в Dockerfile и находится под гитом
- логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
- на сервере мы ничего не устанавливали совершенно кроме самого докера
- мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
- сервер не знает ничего о гитах
- на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
- имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)

Какие самые топовые двигатели существуют?
Где заканчиваются возможности двигателей и начинаются возможности других способов что-либо двигать?

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

Так же и тут - "топовых" небывает, есть популярные для решения конкретных видов задач.
Любая CMS это обычно веб-продукт, и при желании ВСЕ можно реализовать в CMS, просто иногда задача бывает такова, что нет смысла переписывать CMS, а проще написать с нуля свое.

\n перенос, \t табуляция

var num = 1;
$('.b1').on('click', function (e) {
  num = parseInt($(this).data('num')); 
})

$('.modal').on('shown.bs.modal', function () {
  $('.slider__prod').slick({
    initialSlide: num-1,
    arrows: true,
    prevArrow: '<button class="slick-prev slick-arrow" aria-label="Prev" type="button" style=""><i class="fa fa-chevron-left" aria-hidden="true"></i></button>',
    nextArrow: '<button class="slick-next slick-arrow" aria-label="Next" type="button" style=""><i class="fa fa-chevron-right" aria-hidden="true"></i></button>'
  });
});

content-type: text/plain заменить на content-type: text/html