Алексей Николаев

Именно в таком виде разницы нет. Но, скорее всего такой код встречается в виде (0, obj.func)() или (obj.func || _.noop)()

И в этих случаях есть разница:

let obj = {
    func: function() {
        console.log(this === obj);
    }
};

obj.func(); // -> true
(obj.func)(); // -> true
(0, obj.func)(); // -> false
(obj.func || _.noop)(); // -> false

https://learn.javascript.ru/object-methods

В данном случае разницы нет и смысла в такой записи нет. Но надо понимать, что делает оператор () (помимо вызова функции, и, очевидно, группировки в арифметических операциях). А делает он вот что: вычисляет выражение и возвращает его. Это позволяет не создавать временные переменные на каждый чих и писать такие вещи:

(obj1 || obj2).func() // вызывает obj2.func, если obj1 null, undefined, false и т.д.

options || (options = {}) // сделает options пустым объектом, 
// если он null, undefined, false, часто использовалось для задания значения по умолчанию до ES2015

Без скобочек получилось бы чуть длиннее:

var obj = obj1 || obj2;
obj.func();

if (!options) {
    options = {}
}

1) При таком подходе будет всегда путаница, куча разные классов, правил, нужно коммент делать под каждым запросом.
2) А зачем собственно выносить медию в отдельный файл когда можно делать запрос прямо в правиле и с помощью gulp-combile-media-queries успешно при компиляции выносить всю медию в конец цсс?

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

@mobile: (max-width: 460px);
@tablet:  (min-width: 461px) and (max-width: 970px);
@desktop: (min-width: 971px);

// Значения придуманы от балды

.selector {
  @media @mobile {
    // ...
  }
  @media @tablet {
    // ...
  }
  @media @desktop {
    // ...
  }
}

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

Тем временем, где-то в идеальном мире:

/* Файл /bem/block/block.less */
.block {
  @media @mobile {
    // ...
  }
  @media @tablet {
    // ...
  }
  @media @desktop {
    // ...
  }
}

/* Файл /bem/block/__element/block__element.less */
.block {
  &__element {
    @media @mobile {
      // ...
    }
    @media @tablet {
      // ...
    }
    @media @desktop {
      // ...
    }
  }
}

Лучше выбирать по 1000/5000 записей получать максимальное значение id (PK) и идти дальше, смещаясь по primary key. where id > ? limit 1000 order by id asc
Limit/offset не гуд на больших объемах - так как, к примеру, offset 10000 limit 1000 переберет 10к строчек чтобы отдать 1000

Не могу привести ссылку, но в одном из обсуждений здесь возникал такой вопрос и jsperf показал, что вариант с .find() медленнее. Это можно объяснить тем, что накладные расходы на querySelectorAll меньше, чем на вызов функции.
А сейчас jsperf опять заморожен...

Топовые планки (для DDR2 8 GB это предел) у любой версии стоят гораздо дороже чем средние ходовые.
DDR2 уже отходит в класс устаревшего железа и ее выпуск сокращяется, от этого и растет цена, также издержки (перестраховки) продавцов из за снизившегося спроса.
DDR 4 наоборот, для нее этот объем считается самым ходовым, ну и она современная распространяемая, а значит часто покупают и спрос сбивает цены.
Обычный маркетинг.

сверено с исходниками - все чисто

И в БД тоже? Я очень давно последний раз трогал MODx и на сколько помню там было в моде часть исходников хранить в БД.
Надеюсь вы проверяли исходники не вручную? (в смысле через diff в вашей VCS + в БД)

Есть мысли вынести сайты на уровень выше корня, оставив только точку входа

Это первое, что нужно делать))

Как вообще проводится поиск эксплойтов на сайте, если идей никаких нет?

0 - Если у вас в публичном каталоге не одна точка входа, а весь проект - вы уже себе в ногу выстрелили
1 - Ищутся CVE в багтрекере CMS
2 - Проверяются плагины, установленные в системе, они тоже могут содержать уязвимости
3 - Проверяется возможность загрузить и выполнить файл. Например на uploads (или как там каталог называется) права на запуск должны со всей силы отсутствовать
4 - Проверяются открытые порты сервера (если наружу торчит mysql, redis, memcached, ... - тогда сами себе злобный буратино)
5 - Ищутся все возможные точки с eval/include/require/include_once/require_once/exec/shell_exec/... для стороннего кода это потенциальная точка выполнения
6 - Ищутся возможные sql инъекции по коду cms/плагинов
7 - Ищутся всевозможные phpmyadmin и тому подобные сервисы, торчащие наружу
8 - Если в коде активно юзаются глобальные переменные - это потенциальная дыра в безопасности
9 - Если аргументы методов не проверяются - это тоже потенциальная дыра в безопасности
10 - Вам стоит убедиться и в том, что отсутствует утечка изнутри. На одном проекте случайно нашел залитый бывшими сотрудниками phpspy