GTRxShock

Вот так же серия неплохих статеек
getinstance.info/articles/react/react-and-es6-part1
getinstance.info/articles/react/learning-react-redux

Упрощенно.

Вагрант — система управлением конфигурацией конкретной машины.
Докер — запуск изолированных процессов на машине.

Докер.
Это не виртуальная машина, а запуск изолированных процессов. Т.е., запущенный процесс думает, что он один единственный, и ничего вокруг нет. Это работает на уровне ядра Linux. Без использования виртуальных машин.

В терминологии Докера есть Images и Containers.
Image — образ, шаблон, на основе которого запускается Container.
Image строится на основе какого-либо базового образа ОС.

Container — сервис, запущенный и построенный на базе Image.

Таким образом, вы можете построить несколько образов, например, образ для Nginx, образ для PHP, образ для MySQL. Вдобавок, вы можете построить несколько образо, для каждой желаемой версии PHP, MySQL и т.п.

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

При всем этом, ваша базовая система остается чиста от устанавливаемых пакетов, свободна от неразберихи с библиотеками, версиями и т.п.

Оба инструмента хороши. Но у каждого свое назначение.

Vagrant — великолепный инструмент для конфигурации удаленных машин с нуля, VDS/VPS и т.п.
Docker — великолепный инструмент для быстрого развертывания/переконфигурации рабочего окружения, практически без изменения системы, на которую он устанавливается.

https://refactoring.guru/

На нормальном проекте должна быть инфраструктура с галпом/вебпаком. Если вам самим лень в таком копаться, погуглите готовые генераторы yeoman с angular+webpack/gulp. Жизнь сразу станет проще и веселее.

https://www.google.ru/webhp?sourceid=chrome-instan...

cpp-reference.ru/patterns

Мне вот этот ресурс нравится
designpatternsphp.readthedocs.io/ru/latest/README.html

Rx.Observable.of(value)
создает поток, который содержит одно событие с value. Это совсем не про изменения.
От шаблона, который вы хотите применить, в Angular2 уходят, в сторону реактивности.

У компонентов в Angular2 есть input-свойства, изменения которых можно отслеживать с помощью life-cycle callback, конкретно интерфейс OnChanges. Выглядеть будет примерно так:

@Component({selector: 'my-component', template: '<span>{{text}}</span>'}}
class MyComponent implements OnChanges {
  public text: string;
  @Input() changeMe: string;
  
  ngOnChanges(changes) {
    this.text = Date.now().toString();
  }
}

Предположим, что в компоненте верхнего уровня у вас есть:

<my-component [changeMe]="someValue"></my-component>

Изменяя someValue вы изменяете input-атрибут changeMe компонента MyComponent. При каждом изменении будет срабатывать ngOnChanges.
Еще одно замечание - если в качестве значения вы передаете объект, то не надо его мутировать. Создавайте новый объект и присваивайте заново.

this.someValue = {value: 1, anotherValue: 2};
this.someValue = Object.assign({}, this.someValue, {value: 2}); // {value: 2, anotherValue: 2} // Но тут this.someValue это ссылка уже на другой объект.

Вот библиотека с нужной функцией.

nnmclub.to/forum/viewtopic.php?t=1003282

https://github.com/domnikl/DesignPatternsPHP

https://sourcemaking.com
https://github.com/PhpFriendsOfDdd/state-of-the-union

Нет.

Полиморфизм, как следует из названия, это когда что-то маскируется под что-то другое. Это свойство системы типов языка на котором вы пишите, он может позволять вам делать вещи, маскирующие свой внешний вид ("названия") но все же это не та же вещь. Ну и стоит заметить что у полиморфизма есть еще разные виды. Например:

Параметрический полиморфизм. Это когда мы можем написать один код, с одним набором имен, которые работает с разными типами аргументов. Пример - шаблоны из C++ или дженерики в Java. То есть "имена" методов одинаковые, потому что они в одном экземпляре. Реализация одна, одно поведение. А вот аргументы могут отличаться.

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

Полиморфизм подтипов. При этом у нас как раз таки будет одни и те же имена и может быть совершенно разное поведение. Например мы можем создать какой-то базовый тип, который, к примеру, отправляет email-ы, и создать его подтип, который вместо отправки email-ов записывает в лог то что мы хотели отправить, после чего уже отправляет данные дальше другому объекту этого типа (шаблон проектирования декоратор).

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

Ну и еще есть одно серьезное ограничение. Если мы хотим заменить в системе объект какого-то типа на объект подтипа (грубо говоря наследника), то система не должна сломаться. То есть "другое" поведение нашего подтипа должно быть совместимо в плане интерфейса с базовым типом. Об этом можно почитать загуглил "Принцип подстановки Барбары Лисков".

Ad-hoc полиморфизм - это пожалуй самый интересный вид полиморфизма с которым можно долго холиварить. По сути при этом виде полиморфизма, у нас одинаковые имена, а поведение зависит от входящих аргументов. Пример - перегрузка методов в C++. Интересен этот вид полиморфизма в основном тем, что он не является "настоящим".

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

Среди PHP-разработчиков немало тех, кто мечтает увидеть в этом языке с динамической системой типов честную перегрузку методов как например в Java или C++. Просто так, потому что if-ы это плохо и лучше уж пусть они будут неявные на уровне компилятора/рантайма.

Полиморфизм с приведением типов - еще один вид "не настоящего" полиморфизма. Мы "эмулируем" полиморфизм за счет того, что на уровне рантайма языка происходят касты действительного в желаемое. Например в PHP мы можем выставить у функции тайпхинтинг string, и можем внутри иметь одно и то же поведение для всех входящих аргументов. Передать же в качестве аргумента мы можем все что можно скастить в строку.

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