Сергей Протько

Вот проектируя большой проект с нуля ты уже оперируешь не паттерновыми объектами а частами систем

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

Большие проекты начинают проектировать с более высокого уровня. Сначала принимают решение о том, какое разделение на слои у нас будет (для проектов со сроками жизни ~10+ лет имеет смысл позагоняться и вводить гексагональную архитектуру, для проектов со сроками жизни <= строк поддержки фреймворка можно не сильно париться), какие компоненты можно выделить, а уже потом дробить эти большие компоненты на компоненты поменьше.

Затем уже приступать к проектированию каждого отдельного компонента на уровне классов.

Так же если у нас сложная предметная область - проектируют модель предметной области. Обычно тут "паттерны" сами собой получаются тупо при снижении связанности между объектами.

> Собственно вопрос: существует ли сборник всех этих лучших практик?

вне контекста не бывает лучших практик, есть просто практики. В этом плане можно например Фаулера почитать, он очень качественно описывает практики, их плюсы и минусы.

В целом же я бы рекомендовал вам познакомиться поближе с принципами SOLID и GRASP. Последнее мало кто знает, но понимание, например, что такое высокое зацепление, сильно влияет на то, как вы будете проектировать систему.

не совсем при помощи lodash... но

function chunk(arr, n) {
    var chunks = [];
    while(arr.length > n) {
       chunks.push(arr.slice(0, n));
       arr = arr.slice(n, arr.length);
    }
    chunks.push(arr);

    return chunks;    
}

Ведь в любом случае мы получаем глобальное состояние

А глобальное состояние что? Правильно, плохо. У меня тут недалеко есть один небольшой проектик под iOS где ребята решили повесилиться, и сделали сингелтон с сотней публичных свойств. И вся система работает с этим глобальным состоянием плодя побочные эффекты. Инкапсуляция? не, не слышали.

Какой смысл использовать именно singleton?

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

В PHP, где не не особо популярна идея многопоточного программирования, и процветает "умирающая" модель выполнения, в сингелтонах вообще нет смысла. И используют их потому что... внимание... хотят иметь глобальный доступ к различной фигне, в том числе организация глобального состояния.

Когда захожу во второй контейнер и переключаюсь на юзера docker переменная PATH сбрасывается

Ну так вы сменили "окружение" по сути. Единственный способ этого избежать - записать ее в /etc/environment.

В целом же проще будет просто поместить ваш бинарник в /usr/local/bin например.

Погуглив, я посмотрел исходники Yii, Симфони и PHPixie, чтобы узнать, как аутентификация сделана у умных людей

Не забывайте, что в фреймворках это все сделано с одним расчетом - покрыть 95% возможных юзкейсов. А в связи с этим реализация чуточку сложнее. Так же не стоит забывать, что все это "должно" работать на php5.4+, а, например password api появился только в 5.5, а хэширование пароля это целая наука.

Давайте разложим задачу на под задачи:

Нам нужно проверить введенные пользователем данных. Это может быть пара идентификатор + какой-то секретный ключь (email + пароль если проще), а может это просто секретный ключ (токен), или JWT токен... словом вариантов тут много, но нам пока нужна пара старых добрых email + пароль.

Для этого в PHP есть весьма простая в использовании апишка для работы с паролями: password api. Используйте только ее (или что-то что ее под копотом использует) ибо это самый безопасный и надежный способ работы с паролями в PHP. Обязательно прочитайте этот раздел документации.

В очень простом случае (коих большинство) вам при регистрации нужно просто загнать строчку в password_hash и получить на выход новую строчку, которая пишется в базу. При логине мы забираем пользователя с указанным email и проверяем введенный пароль через функцию password_verify.

После того как мы убедились что пользователь не выдает себя за другого, мы можем создать сессию. В самом простом случае мы просто создаем сессию с ID юзера и... собственно все. идентификатор сессии будет записан в http-only куку и все здорово. Правда при работе с сессиями в PHP нужно помнить про CSRF атаки, от которых нужно защищаться (что умеют практически все фреймворки из коробки).

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

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

Для серьезной разработки - нет. Даже air слабоват. Все упрется в процессор. Но для обучения - норм.

если нужно именно писать код

Писать код - это малая часть того чем занимаются программисты. Вам этот код еще запускать надо. И чем серьезнее разработка - тем больше ресурсов требуется. Сначала это просто ruby, потом добавляются различные системы сборок, потом окружение изолировать придется (docker-ы всякие), и так постепенно задачи будут все более усложняться.

давайте думать... у нас есть название "upload". Даже если вы по каким-то причинам не знаете как переводится это слово, достаточно заглянуть в словарик:

upload - загружать

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

1. Перезапись истории нужна, но ее нужно использовать осторожно. Пуш с форсом в мастер - исключение из правил, и в вашей ситуации это полностью оправдано.

2. В 99% случаев спасает реверт. В остальных случаях - push --force, но это крайне редко.

В целом я фанат rebase-ов, что бы история гита была линейной. Если фичабрэнч не fast forward то ребейзимся на мастер и перезаписываем историю этой ветки. Ну а далее fast-forward merge (а еще лучше - сквошить коммиты перед этим). Но тут могут быть несогласные, потому использую те варианты которые приняты в команде.

$ids1 = array_column($result1, 'id');
$ids2 = array_column($result2, 'id');
// ...
$idsn = array_column($resultn, 'id');

$intersection = array_intersect($ids1, $ids2, ..., $idsn);

Или если упростить:

$ids = array_intersect(
    ...array_map(function(array $collection) {
         return array_column($collection, 'id');
    }, $results)
);

updated:

$result = null;
foreach($sql_queries as $sql_query) {
  $query_result =  $wpdb->get_results($sql_query);
  $ids = array_column($query_result, 'id');
  if (null === $result) { 
      $result = $ids; 
  } else {
      $result = array_intersect(
            $result, $ids
      );
  }
  $result = array_merge($result, $query_result);
}

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

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