Игорь Махов

Вам надо слушать не клик, а change

1)let arr = str.split(' ');
Возьмет строку, в данном случае 'aa bb cc aa bb aa', разобьет на части используя пробел как разделитель. В результате получим:
let arr = ['aa', 'bb', 'cc', ' aa', 'bb', 'aa']
2) Следующий кусок кода просто произведет подсчет одинаковых частей.

return arr.reduce((acc, rec, index) => {
    return (typeof acc[rec] !== 'undefined')
      ? { ...acc, [rec]: acc[rec] + 1 }
      : { ...acc, [rec]: 1 }
  }, {});

Рассмотрим его подробнее. Начнем с аргументов:
acc – последний результат вызова функции, он же «промежуточный результат».
rec – текущий элемент массива, элементы перебираются по очереди слева-направо.
index – номер текущего элемента.

Что собственно происходит:
-typeof acc[rec] !== 'undefined' проверит есть ли в объекте 'acc' ключ 'rec'.
- и если мы уже встречали такой( например когда "aa", но уже во второй раз ), тогда изменить значение этого ключа прибавив 1.{ ...acc, [rec]: acc[rec] + 1 }
- если же такого ключа еще не было, то создадим его со значением 1, ибо он в первый раз попался{ ...acc, [rec]: 1 }

Нужно понимать принципиальную разницу подхода:

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

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

snap по большому счёту часто используют для установки тяжёлых приложений, которые может бысть сложно опакетить, особенно учитывая разнообразие присутствующих в мире дистрибутивов (debian/ubuntu и их клоны) разных версий. В то время как большинство штатного общеиспользуемого софта чаще распространяют в виде пакетов, идущих в составе дистрибутива или отдельно (в том числе в виде разных собранных под разные варианты систем пакетов).

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

Вообще, нужно взять бумажку и задать на высшем уровне абстракции все возможные в текущем представлении сущности. Если разговор о "змейке" - задаете вопрос, что у вас в игре есть как сущности. Скажем, есть змея, есть стены, есть жрачка, их пишете как сущности. Затеяли добавить "муху" - пишете тоже. Затем пишете, кто что умеет делать: змея умеет ползать, стукаться в стены или жрачку, расти и возможно что-нибудь ещё, стены просто стоят, жрачка умеет появляться, съедаться. И так далее, пока всю игру в примитивах не опишете. Дальше - каждая сущность это класс, каждое отношение это метод, каждый параметр, выясненный в процессе, это свойство класса. Но чем дальше в лес, тем больше грабли. На уровнях выше начинаются модули со своей инкапсуляцией, события, гонки всякие, а-ля "кто съел яблоко, вы или противник", асинхронное взаимодействие, подписки на что-либо, и так далее, интерфейсы становятся сложнее, какие-то объекты передаются как параметры и всё такое, но общий принцип остается - сначала большими кусками всё делится на куски поменьше, определяются интерфейсы (кто что может спросить или повлиять на кого), пытается реализовываться, потом, вполне возможно, находятся противоречия, которые приходится устранять рефакторингом, и по спирали.

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

latex

Характеристики:

Говно. Старое, никому не нужное, никчемное говно. Небольшой домашний сервачок на линухе с файлопомойкой наверное можно сделать...

На него можно поставить Windows 10 home (pro)

Скорее всего нет. Попробовать конечно можно, но вовсе не факт, что в винде окажутся дрова на scsi-контнроллер, а без них винты просто не увидятся.

*Будет задействовано 2 процессора (интересно).

И что?

На него можно поставить elementary OS

Может быть. Встанет с большей вероятностью чем винда.

Он рассчитан только на Windows Server

Нет, конечно же

*Если только Windows Server, то на нем можно работать как на обычном Windows.

Если встанет, наверное можно, но это будет весьма убогая винда

Им можно пользоваться как домашний компьютер

Только класса "печатная машинка"

Оценочная стоимость модернизации (ваше мнение).

0 руб. Брэндовое железо не модифицируется. Оно полностью, сверху до низу свое собственное.

Особенности эксплуатации (ваше мнение, примерно).

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

А приведенный выше piece of shit годится только на небольшой сервачок на линухе - изучать линух и сервисы, ну и файлопомойку.

Никто не покупает сервера, чтобы поставить туда Windows

Learn JavaScript
MDN
JavaScript Garden

На ютубе рекомендую этот канал. (ссылки на плейлисты с него)
https://www.youtube.com/watch?v=FX2fiUvrYP4&list=P...
https://www.youtube.com/watch?v=aQkgUUmUJy4&list=P...
И так ещё по каналу посмотрите отдельные видео.

Никак.

можно, конечно, взять webrtc и sfu и самому всё запилить, но это сложно и долго. Гугли jitsi-meet, это готовое бесплатное решение, которое просто устанавливаешь на сервер, настраиваешь и можешь подключаться через свой домен или jitsi-meet мобильное приложение, либо своё приложение можешь запилить. Там можно настроить разные типы авторизации (кто может создавать/присоединяться) - по паролю, по токену и тп.

Конечно можете. После await у вас должен идти промис, который будет ресолвиться из обработчика события. Если речь о событиях DOM, то как-то так:

HTMLElement.prototype.waitFor = function(event_name) {
    if (event_name) {
        return new Promise((res, rej) => {
        	const listener = function() {
        		res()
        		this.removeEventListener(event_name, listener)
        	};

        	this.addEventListener(event_name, listener);
        })
    } else {
        throw 'No event passed to waitFor method!';
    }
}

async function foo() {
	const start = new Date();
	await document.querySelector('body').waitFor('click');
	console.log('uspeshno dojdalis clicka, jdali celih ' + ((new Date().getTime() - start.getTime())/1000) + ' sekund');
}

foo();

почитайте что такое ssh jump host (или ssh bastion host).

Вот неплохая ссылка.
https://www.redhat.com/sysadmin/ssh-proxy-bastion-....

Оба разработчика, когда работают в своих ветках, должны поддерживать актуальное состояние, т.е. периодически вливать (merge) dev в свою ветку.

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