Сергей Соколов

А ведь и правда есть термин для них (но не тип, конечно): Well-Known Intrinsic Objects

Если же вы спрашиваете как затипизировать что-то, что может быть "RegExp, Array, Function и другим" (и не указывая при этом каждый тип явно), то должен, наверное, подойти только object (не смог в доке TS найти отличается ли TS-тип object от базового JS-объекта; например, в TS есть явная типизация функций, но можно ли её заменить на object?). Но это максимально странная задача, которую явно надо решить каким-то другим способом.

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

Можно давать ссылку на http/https, который редиректит на sms.

Подойдет разделить видео на части и запустить двумя процессами, с разными настройками для cpu и gpu, после же объединить полученные куски в режиме copy (на максимальной скорости диска)?

Размеры кусков подобрать эмпирически после экспериментов, во сколько раз cpu медленнее gpu.

Что то похожее я делал, перекодируя видео на нескольких физических машинах.

Ну если это время, то:

import datetime

timestamp = 1685700050
str_time = datetime.datetime.fromtimestamp(timestamp)
print(str_time)

У меня получилось 2023-06-02 13:00:50

UPD. Это не код, а UNIX-время - количество секунд, прошедших с полуночи (00:00:00 UTC) 1 января 1970 года

Судя по документации и FAQ, вы не можете использовать полученный токен для того, чтобы разрешить сообществу отправлять сообщения пользователю (метод messages.allowMessagesFromGroup доступен только для standalone-приложений и требует одобрения со стороны ВК).

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

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

Если говорить про "запросы к БД", то для таких тестов "массив с данными" использовать просто глупо. Это получится какой-то формальный тест: "проверяем, что метод возвращает массив из трех строк - и тут же возвращаем этот самый массив". В чем смысл? Если вы тестируете запрос к БД, то и надо тестировать запрос к БД. По-другому никак.

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

И сюда же использование для тестов БД другой системы. Например основная БД MySQL, а для тестов используется Sqlite. Тут сразу можно сказать, что это профанация. Различие даже в какой-то одной настройке БД может повлиять на результаты запроса (и теста как следствие) - а тут и вовсе используется совсем другая БД.

С другой стороны, работу с БД скорее стоит тестировать не в юнит тестах, а скажем в интеграционных. Но не будем углубляться.

Массив же "с данными, симулирующими ответ из базы данных" используется на следующему уровне, там где требуется "ответ из базы данных". Взьмём метод, который использует данные, полученные из БД. Например авторизация юзера. Этот метод должен не сам лезть в базу, а дёргать отдельный метод, вполне возможно, что совсем другого класса. И вот чтобы протестировать авторизацию, вы и мокаете метод для работы с БД, и из этого мока возвращаете тот самый массив без всякого обращения к бд.

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

Так что разбивайте ваши длинные методы на мелкие, и тогда вопрос, как их тестировать, в большинстве случаев отпадёт сам собой.

RTFM: https://learn.javascript.ru/async-await

1. Нельзя итерироваться по объекту и одновременно изменять его
2. pop удаляет с конца, а for of идет по массиву сначала

Первая итерация цикла number=3, pop удаляет с конца, то есть 5
вторая итерация number=8, pop удаляет 9
и так далее
когда number=6(четвертая итерация), 6 - это последний элемент массива, так как остальные удалил pop

Проксируется в целом ровно точно так же, как и любая сетевая нагрузка: клиенты [n] -> балансер -> сервера [m]. Лимит портов в 65к достаточно просто преодолевается путем добавления дополнительных сетевых адаптеров/каналов.
Дополнительные ссылки:
https://unetworkingab.medium.com/millions-of-activ...
https://blog.postman.com/postman-engineering-milli...
https://serverfault.com/questions/725224/how-to-ha...
https://josephmate.github.io/2022-04-14-max-connec...
https://github.com/eranyanay/1m-go-websockets
https://github.com/ramsicandra/1million-ws

Кроме того, WS коннекты можно балансировать как HTTP - банальным редиректом на прямой коннект к серверу. Т.е. клиент коннектится к балансеру, а он ему говорит: "а теперь тебе вот сюда коннектится надо". Или можно совмещать. Пару слов про проксирование WS в nginx: в сети пишут, что nginx с этим плохо справляется под существенной нагрузкой и лучше всего проксировать WS через специализированные прокси типа HAProxy.

var timeoutId;
// ...
timeoutId = setTimeout(...
// ...
timeoutId = setTimeout(...
// ...
function stop() {
  clearTimeout(timeoutId);
}
document.getElementById("placeholder_text").click = stop;

Ну и не называй функцию do, есть ключевое слово do ... while.

В package.json есть раздел overrides как раз для таких модификаций зависимостей зависимостей. В примерах в документации там почему-то акцент сделан только на версии пакетов, но можно и полностью заменить пакет на свой, если указать не версию, а локальный путь к нему.