Василий Банников

Оптимальнее всего будет кабель от провайдера включить в роутер, а от роутера уже кабели до всех потребителей.
Да и скорее всего это будет единственный рабочий вариант.
Ну и да - такого понятия как "разветвитель" не существует. Есть коммутаторы.

Вообще при длительном отсутствии следует и холодильник тоже отключать.
А так:
1. ИБП, чтобы исключить возгорание из-за некачественного электричества
2. Датчики дыма и пожарную сигнализацию, чтобы в случае возгорания вызвать пожарных
3. Камеру, чтобы проконтролировать состояние самостоятельно
4. Какие-нибудь автономные системы пожаротушения - есть специализированные для серверов

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

Всё описано в пользовательском соглашении - Яндекс потом будет с вас требовать эти деньги через суд, тк 28к - это значительный ущерб.

Услуга тут уже в полном объёме оказана, так что как с wb не выйдет.

CORS-это не сайт, а браузер твой ругается. Выставляй корректные CORS-заголовки

Допустим, что СБ отказывает в таких ситуациях.
Получается, чтобы устроиться на работу - нельзя не только быть обвиняемым, но и потерпевшим.
Чтобы не быть потерпевшим, нужно одно из двух:
1. Никогда не становиться жерствой какого-то преступления
2. Игнорировать такие ситуации.

И получается, что такие люди не смогут себе найти работу?
Звучит как какой-то бред.

Скорее всего и отказывать по такой причине тоже незаконно => если у тебя больше нет других причин для отказа, то можно заставить себя трудоустроить и ещё развести компанию на большой штраф.

Если включить логику (вопреки утверждениям, что СБ действует нелогично), то думаем, какие вещи вообще СБ смотрит и зачем.

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

2. Соцсети - логично. Можно составить твой психологический портрет и опять же определить риск слива данных/нарушения NDA или совершения преступлений из п1

3. Наличие родственников, которые подпадают в п1 или п2 - тоже логично. Родственники вполне могут попытаться завлечь тебя в преступную схему.

4. Ты был потерпевшим в рамках уголовного дела или выступал свидетелем - какой тут риск для компании? Что ты подашь в суд на компанию, если будет иметь место нарушение твоих прав? Что ты какой-то неудачник, у которого могут из кармана пропуск в офис украсть? Что у тебя могут с рабочего компьютера украсть какие-то данные?
Кража данных не тобой уже решается при помощи регламентов и специального ПО.
Кража пропусков - аналогично.

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

Написано же - свяжись со службой поддержки, если ошибка не уходит

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

Исключение делают только азиатским языкам (китайский/корейский/японский), тк там очень низкая доля знания английского и графика опять же сильно отличается.

Можешь максимум проверку правописания на русском установить

но не будет ли возникать конфликтов в работе клиента и сервера,

Не должно. Просто разруливай по путям - что к бэку должно идти, а что на статику.

А чтобы "без порта" надо запускать на 80 и 443 порте.
Но если на этой же машине nginx стоит, то будет конфликт.

Совсем немного ускорит благодаря тому что по одному соединению в http/2 может идти несколько запросов одновременно.
=> Нужно будет открывать меньше новых соединений.
+ Он бинарный => всякие multipart запросы также будут передаваться в чуть более компактном виде.
+ В нём есть сжатие заголовков => заголовки тоже будут в более компактном виде идти.

Сделай вместо статического поля - виртуальное нестатическое свойство у которого будет только get.

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

Да, такое может быть. В таком случае цена заявки с такого источника будет ниже.

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

А зачем суммировать?
В том источнике, на который потрачено много денег, но получилось мало заявок, цена заявки будет высокой.
В том источнике, на который было потрачено мало денег, но получилось много заявок, цена заявки наоборот будет низкой.
> Второй источник более выгодный и в него надо попробовать вкинуть больше денег, а в первый наоборот.

Незнаю понятно ли задал вопрос.

Покажи пример своих расчётов.

pair - массив из двух элементов или объект с двумя полями.
["a", "b"]
{"fst": "a", "snd": "b"}

map<string, vector<float> > Объект или Map у которого в качестве значения - массив, а в качестве ключа-строка.
{"a": [1.2, 3.5]}

map<pair<string, string>, float> С этим сложнее, тк что массивы, что объекты в js сравниваются по ссылке => вариант того, как мы представляем pair сам по себе не подойдёт.

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

const map = {};
const a = "abc";
const b = "123";
const key = `${btoa(a)}$${btoa(b)}`;
map[key] = 42;