Слава

Правильная конструкция функции initStorageEvent:

void initStorageEvent(
  in DOMString typeArg,
  in boolean canBubbleArg,
  in boolean cancelableArg,
  in DOMString keyArg,
  in DOMString oldValueArg,
  in DOMString newValueArg,
  in DOMString urlArg,
  in nsIDOMStorage storageAreaArg
);

Рабочий пример:

var e = document.createEvent( 'StorageEvent' );
e.initStorageEvent('storage', true, false, 'key', 'oldValue', 'newValue', location.href, window.localStorage);
window.dispatchEvent(e);

Подробнее на Mozilla Developer Network (MDN), а также спецификация на WHATWG

вообще легко background-attachment: fixed
https://jsfiddle.net/s8o5hun8/1/

function CoffeeMachine(power) {
  //...

  var self = this; // запоминаем ссылку на текущий объект

  //...

  function getBoilTime() {
    // здесь this будет ссылкой на window, 
    // т.к. вызов метода getBoilTime() происходит из другого контекста
    // доступ к исходному объекту возможен через ссылку, 
    // которая была передана в переменную self
    console.log('this', this);
    console.log('self', self);
    return self.waterAmount * WATER_HEAT_CAPACITY * 80 / power;
  }

  // ...

  this.run = function() {
    setTimeout(onReady, getBoilTime());
  };
}

Привязка контекста и карринг: "bind"

С передачей контекста код будет примерно таким:

function CoffeeMachine(power) {
  this.waterAmount = 0;

  var WATER_HEAT_CAPACITY = 4200;

  function getBoilTime() {
      console.log('getBoilTime', this);
      return this.waterAmount * WATER_HEAT_CAPACITY * 80 / power;
    }

  function onReady() {
    alert( 'Кофе готово!' );
  }

  this.run = function() {
    console.log('run', this);
    var interval = getBoilTime.apply(this, null);
    setTimeout(onReady, interval);
  };

}

var coffeeMachine = new CoffeeMachine(100000);
coffeeMachine.waterAmount = 200;

coffeeMachine.run.apply(coffeeMachine, null);

Эм...
...(..., myfunc);

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

Первый: терминология исторически англоязычная и всяческие попытки переводов чаще вредят, чем помогают понять суть. (Мне, например, пришлось напрячь Гугл, чтоб удостовериться, что под "шлюзом" Вы действительно подразумеваете "pattern gateway", а не что-то там еще).
Второй: термины часто обозначают не конкретные сущности, а абстракции. (Если вдруг значения последних двух слов понятны только на уровне смутного ощущения, разберитесь, что они конкретно означают... абстракция - это не "нечто туманное и заумное", а совсем другое :) ) Соответственно, для толкования этих терминов нужно использовать абстрактное мышление. Как?

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

И - сюрприз(!) - именно в этом и заключается суть паттерна. А вот, для сравнения, его формальное определение: "Объект, который инкапсулирует доступ к внешней системе и ресурсу." Решайте для себя сами, что лучше - знать английский, запоминать такие определения или один раз понять смысл аналогии, только учтите, что у всех слов в определениях тоже есть совершенно конкретный, точный смысл, который нужно знать или уметь находить - иначе определение ничего не объяснит, а только еще больше запутает :)

Далее... как его "сделать в коде"? А фиг его знает! Как удобнее для проектируемой системы, так и делайте. Может, это будет один класс, может микросервис, а может вообще железяка на FPGA. Паттерн не дает никаких готовых рецептов (типа, взять три грузовика бетона, выкопать яму глубиной 5 метров и пр.) - он просто говорит, что чем всем частям системы "лазить наружу" как попало, лучше это дело сконцентрировать в одном месте. И, кстати, патерн не является "современным стандартом" и, вообще, стандартом! Это просто обобщенный опыт поколений разработчиков систем. Не более, чем соображение мыть руки перед едой... если зачем-то нужно, можно и не мыть, но если нет какой-то осознанной мотивации, то мыть в большинстве случаев - лучше :)

Идем дальше... интерфейс. Что это такое? Формочка с кнопочками и чекбоксиками? А может, разъем USB? А может, код на каком-нибудь ЯП? Что между всем этим общего? Да очень просто! Интерфейс, это набор правил и соглашений о том, как пользоваться какими-то функциями того, что предоставляет этот интерфейс :)

Вот и все! В ИТ-шной терминологии нет никакой магии и никакого сакрального смысла. Для понимания достаточно знать ТОЧНОЕ значение довольно небольшого количества слов и для любого непонятного термина всегда задавать два простых вопроса: "что это значит" и "почему", и находить на них ответы. И все туманное и странное быстро становится простым и понятным :)

Если не заморачиваться то просто заверните в try..catch.
Если заморачиваться - то писать функцию, которая пример объект content и строку 'page.search_json.search....', разобьет строку и начнет идти вглубь, проверяя, есть-ли такие поля объекта, и если нет - возвращала что вам надо.
Если брать готовое - в lodash есть метод _.get

На сервере express? И что за странные разделители ";"? Должны быть "&", тогда будут параметры поиска в req.query лежать.

es2015

function ajax (type, value){
    var request = {
        [type]: value
    };
}

es5

function ajax (type,value){
    var request = {};
    request[type] = value;
}

Отключите опцию:

Внутри Docker только Linux, и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows - через виртуальную машину.

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

Это почти виртуальная машина. Почти, да не совсем.

Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости - ситуация еще хуже.

Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. - скомпилировать его невозможно. Запускаем в этих операционных системах в Докере.

С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.

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

Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.

Вы можете сказать - ба, да это же давно известная виртуальная машина. Но нет, это не так. Это так называемые контейнера. Никакой виртуальной машиной там и не пахнет. За исключением Windows и MacOSX, где работа без виртуальном машины пока экспериментально возможно только, а нормой в этих ОС является использование Докера внутри полноценной виртуальной машины.

Но виртуальные машины с Докером используются только для разработки. Для запуска в production виртуальные машины с Докер не используются.

Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер - это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.

Но при этом не используется полная виртуализация. Что существенно экономит ресурсы. Запустить 100 полноценных виртуальных машин вряд ли получится даже на мощном сервере. А вот запустить 100 контейнеров Docker даже на слабом домашнем компьютере - возможно.

Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD. Именно специально подготовленные. Windows - в принципе в контейнере запустить невозможно.

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

Зачем это используется?

Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.

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

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

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

Это позволяет гарантировать гораздо большую идентичность среды разработки и среды исполнения.

До этого люди мучались, придумывали хитрые инсталяторы...

Потом плюнули на попытки упорядочить окружение в ОС - и сейчас концепция такова - устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами - то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.

Другими словами:

• Докер-контейнер нужно использовать для отладки.
  
• Тот же Докер-контейнер нужно использовать и на сервере.
  

Это позволяет не трудиться с настройками "под сервер" локально на машине разработчика. Это позволяет разрабатывать на машине разработчика совершенно разные программы одновременно, которые требует несовместимых настроек операционной системы. Это позволяет давать гораздо больше гарантий, что программа на сервере будет вести себя также как и на машине разработчика. Это позволяет разрабатывать под Windows/MacOSX с удобным "прозрачным" тестированием под Linux.

Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов - то только программное обеспечение без GUI.

Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата - сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.

UPD:

Может сложиться ложное впечатление, что разработчик готовит контейнеры в Докер, а потом передает их админу.
Правильная методология все же другая:

Разработчик отдает весь свой результат в систему CI (обычно через git)
CI на каждый новый коммит делает с помощью Docker образ для тестирования.
Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.

То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ.

Основная идея - что тестировали, ровно то и запускаем на боевом сервере. Один-в-один, включая те же самые файлы (не такие же, а именно те же самые).

Вы ничего не резолвите и не режектите, следовательно данный промис никогда не пойдет дальше по цепочке.
Очевидно, что db.query асинхронная, но так как она не получила колбэка, то выкидывает свое исключение в общий поток, к этому моменту функция-обработчик промиса уже успешно завершена, естественно она не ловит при этом ошибку.
Многое конечно зависит от драйвера БД, но подозреваю что нужно сделать так:

let userInsert = new Promise((resolve, reject) => {
  db.query('INSERT INTO users (email, password) VALUES (?, ?)', [user.email, user.password], err => {
    if(err) {
      reject(err);
      return;
    }
    resolve();
  });
});