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

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

Это TypeScript. В такой нотации видно, что принимается в аргументах и что будет вернется.

T это generic параметр. В данном контексте это тип фильтруемого значения.

MonoTypeOperatorFunction это функция с сигнатурой (source: T): R которая еще и унарная функция итд. Это всё иерархия типов для того что бы можно было композировать друг с другом функции по их "смыслу" а не сигнатуре.

Это дженерик. Что-то в роде переменной, но для типов.

https://www.typescriptlang.org/docs/handbook/gener...

date('d.m.Y', strtotime('+1 year', $dateFromDb))

const attacks = [
  { minChance: 7, damage: 40, name: 'critical' },
  { minChance: 5, damage: 20, name: 'big' },
  { minChance: 0, damage: 10, name: 'weak' },
];

const messages = {
  start: (player, enemy) => `Welcome! Yor health is - ${player}%, your enemy health - ${enemy}%`,
  end: (player, enemy) => `You ${enemy <= 0 ? 'win' : 'lost'}! Your hp level - ${player}, opponents hp level - ${enemy}`,
  chance: (player, enemy) => `your chance - ${player}, your opponent chance - ${enemy}`,
  turn: (player, enemy, hit, isEnemy) =>
`${isEnemy ? 'Enemy' : 'Your'} turn...
${isEnemy ? 'Enemy' : 'You'} did a ${hit} hit
${isEnemy ? 'Your' : 'Enemy'} hp - ${isEnemy ? player : enemy}`,
};


const simpleFight = () => {
  const hp = [ 100, 100 ];

  console.log(messages.start(...hp));

  while (hp.every(n => n > 0)) {
    const chances = hp.map(() => Math.random() * 11 | 0);

    console.log(messages.chance(...chances));

    if (chances[0] !== chances[1]) {
      const chance = Math.max(...chances);
      const attack = attacks.find(n => n.minChance < chance);
      const isEnemyAttacks = chance === chances[1];
      hp[+!isEnemyAttacks] -= attack.damage;

      console.log(messages.turn(...hp, attack.name, isEnemyAttacks));
    }
  }

  console.log(messages.end(...hp));
};

При использовании SPA все внешние скрипты-инициализаторы контента должны быть ВНУТРИ SPA и никаких внешних загрузок!

За версионностью и корректностью их работы внутри SPA - также следите Вы (обновился внешний->сохранили к себе->проверили->обновили сборку SPA).

Если речь про контроль загрузки внешнего контента (скриптами-инициализаторами), то здесь придётся создать дополнительно ещё и верификатор доступности внешнего ресурса, загружаемого основным скриптом (из SPA). Это можно сделать через подписку на события отслеживания ajax-соединений (и других необходимых).
Например, так.

Нет

Смотря зачем)). Я когда делаю Code Review критерии следующие:

* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило шлю на **й.
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и !=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

* Организация кода:
- Никаких глобальных функций.
- Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

* Тестируемость (в смысле простота тестирования) кода должна быть высокая.
- Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких ***ть запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

* Принципы SOLD:
- Никаких божественных объектов умеющих во все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.

* Принцип DRY разрешено нарушать в случаях:
- Явного разделения обязанностей
- В тестах (каждый тест должен быть независимым, на сколько это возможно)

* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() - шлю на***й.
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)) )
- Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

UPD

Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions

Вопрос сам по себе глупый. Jquery - это и есть js. По сути, это набор функций, упрощающий разработку и сокращающий код. То что будет быстрее зависит от твоего ур-я. jq писали не глупые люди, сможешь ли ты написать лучше? Не думаю. Другое дело, что функции в jq более универсальны, для этого приходится жертвовать скоростью, но разница в скорости выполнения скрипта будет в пару десятков миллисекунд, а вот что касается скорости загрузки, ты можешь сократить код с jquery на 20-30% минимум.

Hashicorp Vault
или Ansible Vault

Несмотря на совпадение названий - это принципиально разные вещи.

'2019-09-20T07:00:00.000Z'.replace('T',' ').replace('Z','')

Если вы действительно работаете над "хорошими проектами за большие деньги", и видимо что-то из себя представляете, то codementor.
Рейт начинается от $60 в час, $100-120 - это уже хороший уровень, "шабашки" бывают на почаса - час-два, бывает больше.
Это конечно не 1000-2000р, как вы хотите, а 3000-5000 но я готов принять от вас все излишки сверх 2тр чтобы вы получили именно то что спрашивали.

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

Вот вариант максимально короткий и лёгкий для понимания:

const unique = (arr, keys) =>
  arr.filter(n => n === arr.find(m => keys.every(k => m[k] === n[k])));


const result = unique(arr, [ 'model', 'param1', 'param2' ]);

Для вашего случая подходит, но вообще, есть ряд проблем:

• Иногда косячит

  
  Если объект присутствует в массиве несколько раз, то такие дубликаты не будут отброшены. Конкретно эта имеет тривиальное решение - вместо ссылок можно сравнивать индексы, под которыми объекты представлены в массиве:
  
  

  - arr.filter(n => n === arr.find
  + arr.filter((n, i, a) => i === a.findIndex

• Недостаточно гибко

  
  Что если уникализировать надо не по собственно свойствам, а по каким-то производным от них значениям? Например, у объектов есть вложенные объекты, и нужны их свойства; или есть число, а нужен остаток от его деления на какое-то другое число; или есть дата, в которой важен только месяц.
  
• Сложность

  
  Фильтрация линейна, поиск тоже, одно внутри другого даёт квадрат.
  

Так что вот вариант потяжелее:

const unique = function(arr, keys = n => n) {
  const picked = new Map;
  return arr.filter((...args) => {
    const p = []
      .concat(keys(...args))
      .reduce((acc, k) => acc.set(k, acc.get(k) || new Map).get(k), picked);

    return !p.set(this, p.has(this)).get(this);
  });
}.bind(Symbol());


const result = unique(arr, n => [ n.model, n.param1, n.param2 ]);