Վիտալի Լագունով

К ответу выше: вместо new Promise можно просто пометить функцию как async — она автоматически вернёт Promise, который будет заполнен по достижении return или throw (но сам Promise будет возвращён сразу же ещё до начала фактического выполнения функции):

exports.findOrCreate = async function findOrCreate(userID, provider){
    const accountID = await client.getAsync('accounts:' + provider + ':' + userID);
    
    if (accountID !== null) {
        return client.hgetallAsync('account:' + accountID); // 1
    }else{
        throw 'user not found';
    }
};

(async () => {
    const promise = findOrCreate(1); //Возвратит promise
    const users = await findOrCreate(1); //Возвратит пользователей
    const users = await promise; //Возвратит пользователей, аналог предыдущей строчки
})();

Гуглить по запросу async await.

Очевидно, что редис намного медленнее, чем обычный доступ к переменной, поэтому оптимальнее всё хранить в переменных. Особенно большой оверхед даст посылка запросов. Например, 100-200 тыс простых запросов в секунду они вполне могут загрузить ваш скрипт на 100% и redis процентов на 30.

Тем не менее, redis всё-равно очень полезная вещь по следующим причинам:

1. Удобно хранить постоянные данные, которые не должны теряться после остановки/перезапуска скрипта или сервера.
   
2. Если доступ к данным требуется сразу из нескольких скриптов. В этом случае если Вы вместо редиса поюзаете хранение в обычных переменных, то получите следующие проблемы:
   
   • Данные придётся дублировать сразу в нескольких скриптах, что может значительно увеличить расход памяти
     
   • Нужно следить, что во всех скриптах находится актуальная версия данных.
     
   • Это сильно усложняет проект и его поддержку. Если раньше нам чтобы что-то изменить, достаточно было записать это в базу данных из любого скрипта, то теперь нам придётся провзаимодействовать с каждым из таких скриптов. Причём просто провзаимодействовать не получится, надо ещё в сами скрипты добавить код, который ответит на это взаимодействие, и обновит данные в своей памяти, а также ещё, возможно, провзаимодействует с другими скриптами.
     
     В общем, как видите, чтобы проделать даже такую простейшую операцию, приходится проделывать огромное количество действий, а ведь раньше с редисом нам достаточно просто новые данные в базу и всё.
     
     Другой пример — код становится зависимым. Раньше, у нас ничего не хранилось в памяти скрипта и все запросы были полностью обособлены друг от друга. Теперь же они зависят от каких-то глобальных данных, хранящихся в памяти скрипта. Во-первых, обработчики запросов становятся привязаны друг к другу, во-вторых, усложняется состояние каждой такой подпрограммы, т. к. теперь есть зависимость от глобальных данных, в-третьих, их теперь нельзя так просто взять и перенести в другое место.

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

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

Подойдёт любой монитор 4K, их полно.

Windows сама поменяет маштаб, но можно и вручную: правой кнопкой по рабочему столу –> Персонализация –> Экран –> Я хочу выбрать один масштаб для всех дисплеев –> Поставить 200%.

В Ubuntu: Параметры системы –> Настройка экранов –> Масштаб меню и заголовков окон: 2.

По поводу "симуляции" — это будет не симуляция ретины, а монитор с такой же плотностью, как ретина, т.е. ничем не отличается от ретины. Не только Apple использует плотность 2x.

Я советую использовать Windows 8+ или Ubuntu 16+.

Придумал очень простое решение, как измерить частоту с точностью до сотых без вообще каких-либо инструментов, кроме калькулятора:

Нужно взять МАЛЕНЬКИЙ объект и быстро передвигать его по экрану. При быстром передвижении будет видна явная ступенчатость, т.е. вы будете видеть не один объект, а как бы сразу много его копий одновременно. Между этими копиями есть определённое расстояние. Можно измерить это расстояние, и если скорость передвижения объекта равномерна, то можно вычислить частоту монитора по формуле (speed / distance), где speed — скорость движения объекта в пикселях в секунду, а distance — расстояние между копиями объекта в пикселях.

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

Попробовал способ на практике:

• Speed = 7170 px/sec, distance = 238.7px. Результат: 30.04 Гц. Реальная частота стояла 30 Гц. Ошибка 0.04 Гц.
  
• Speed = 4996 px/sec, distance = 146.9px. Результат: 34.004 Гц. Реальная частота стояла 34 Гц. Ошибка 0.004 Гц.
  
• Speed = 7165 px/sec, distance = 119.4px. Результат: 60.02 Гц. Реальная частота стояла 60 Гц. Ошибка 0.02 Гц.
  
• На частоте 120 Гц расстояние между копиями объекта не изменилось, т.е. в реальности я получил те же самые 60 Гц. Вариантов два: либо мой монитор на самом деле выдаёт 60 Гц вместо 120 Гц, либо проблема в выбранных технологиях, т.к. я писал программу на HTML+js, и сам браузер мог порезать анимацию.
  

Кто-то может посоветовать, с помощью каких инструментов можно переписать программу так, чтобы точно быть уверенным, что анимация не режется?

PS. Кто-то может удивиться, как я смог измерить частоту с такой высокой точностью, даже не пользуясь линейкой. Дело в том, что я подбирал такую скорость, чтобы скорость объекта была кратной частоте экрана. В итоге в этот момент 7 копий объекта как бы замирают на месте, при этом постоянно мерцая. В итоге я просто поделил ширину поля, в котором передвигался объект, на 7, и получил расстояние между объектами С ОЧЕНЬ ВЫСОКОЙ ТОЧНОСТЬЮ.

PS. Скорость движения объекта тоже была задана с максимальной точностью, т.к. я делал свою программу на HTML+js, а там можно получить текущее время с точностью до микросекунд, а на основе времени при отрисовке анимации можно точно рассчитать позицию объекта.

PS. Дополнительно я произвёл измерение на 72 Гц. Я получил 17 копий объекта, что дало результат 72.00042 Гц. Но из этих 17 копий объекта отображались не все: каждые 5 копий был пустой пробел, который с определённой скоростью двигался вправо. Этого говорит о том, что 1 из 6 кадров выкидывается, что в итоге даёт нам частоту 60.00035 Гц. Получается, на самом деле частота монитора не 72 Гц, а всего лишь 60 Гц, хотя в спецификации монитора указано, что он может работать с частотой до 76 Гц (хотя как я говорил выше, возможно, это вина не монитора, а браузера, который может резать анимацию до 60 кадров в секунду).

PS. Если Ваши копии постоянно скачут, и настройка скорости не помогает, то подберите ширину поля, в котором двигается объект, так, чтобы она была кратна скорости, делённой на предполагаемую частоту. Если это не помогает, возможно, у Вас плохой таймер, который срабатывает не через одинаковые промежутки времени, либо эти промежутки слишком большие. Подбор ширины кстати может приблизить Ваши результаты к предполагаемым, но я получал точность 0.01 Гц и без подбора ширины.