Дмитрий Уланов

Буду исходить из "дано" задачи "PHP программист" и из того что автор вопроса стремится заниматься сугубо back-end программированием. Заранее прошу прощения, я несколько увлекся
Итак:
1. Установка сервера (Open Server, Xampp, Denver), на начальном уровне. (просто из exe)
2. Общие принципы.
2.1. Типы данных.
2.2. Переменные.
2.2.1. Работа с переменными по ссылке.
2.2.2. Методы объявления и уничтожения переменных.
2.3. Управляющие конструкции (если знаком, то особенности синтаксиса в рамках языка).
2.3.1. Условия.
2.3.2. Циклы.
2.4. Конструкции вывода(print, print_r, echo).
2.5. Конструкции отладки и управления выполнением(var_dump,die,exit,break в циклах, пустой return;).
2.6. Пред определенные глобальные переменные($_GET,$_POST,$_REQUEST,$_SERVER), константы зарезервированные под модификаторы (static, function, const, $this)
2.7. Особенности версий 5.3, 5.4.
2.7.1. Анонимные функции.
2.7.2. Замыкания.
2.7.3. Особенности объявления массивов.
2.7.4. Пространства имен.
3. HTTP протокол.
3.1. Заголовки входящие.
3.2. Заголовки исходящие.
3.3. Процесс общения.
3.4. Метод php “header(…)” в контексте темы.
3.5. Глобальная переменная $_SERVER[] в контексте темы.
4. Установка сервера на среднем уровне (основы файла .htaccess и RewriteRule)
5. Процедурное программирование.
5.1. Математические методы.
5.2. Оперирование типами.
5.2.1. Методы оперирования массивами (array_values,array_keys,array_map и т.д.)
5.2.2. Методы оперирования строками (strlen,substr и т.д.).
6. ООП.
6.1. Классы.
6.1.1. Инкапсуляция(public,protected,private). Понимать разницу.
6.1.2. Наследование.
6.2. Интерфейсы.
6.2.1. Имплементация интерфейсов.
6.3. Абстрактные классы.
6.4. Полиморфизм.
6.5. Магические методы.
6.5.1. Базовые (__construct,__get,__set,__destruct)
6.5.2. Расширенные (__invoke,__serialize,__isset)
6.5.3. Разобраться когда стоит применять магические методы а когда это плохая практика.
7. Библиотека SPL, и расширение поведенческих возможностей классов за ее счет.
8. Базы данных.
8.1. SQL
8.2. Примитивный уровень общения с БД. (mysql_connect,mysql_close,mysql_query).
8.3. Средний уровень общения с БД(PDO и другие кастомные библиотеки).
8.4. Высокий уровень (ActiveRecord,DataAccessObject,ObjectRelationMapping).
8.5. NoSql БД на примере MongoBD (настоятельно рекомендуется, но не обязательно).
9. Фреймворки. На мой вигляд можно начать с Kohana. Сужу по уровню вхождения стажеров которых видел и отсутствию пространств имен с которыми по первах могут возникать проблемы.

И главное, Внимание! Личностные качества.
- Усидчивость.
- Владение Google при оттачивании темы или сложной задаче на уровне, когда поисковик видит в пользователе не то что DDOS а полноценный физический краш. тест.
- Не брезгливость. Умение заставить себя разбираться в гов… хм. Нелицеприятных дебрях.
- Збагойствие. Отсутствие паники при различных ошибках и не состыковках. Всегда остыть и попробовать снова, но по другому.

может кому до сих пор нужно, но я скруглил так:
#map > ymaps {
border-radius: 5px;
overflow: hidden;
}
если задавать скругление блоку #map, то оно не работает.

Посмотри,может что то да и подойдет:
https://codepen.io/MyXoToD/pen/xGRrgQ
https://codepen.io/kaolay/pen/ozkovw
https://codepen.io/Kristina_Glaz/pen/zeNvpp

index0h: Нельзя "знать node.js". Это как сказать, что я знаю не Java, а JVM или не C#, а .NET.

Знать надо JavaScript, а в случае с Node.js нужно дополнительно иметь представление об архитектуре серверных приложений (хотя Node.js это не только сервер, а по сути возможность писать на JS вообще все что душе угодно) и о том, какие задачи можно решить модулями npm. Вернее даже не знать, а уметь гуглить и понимать английский.

Но проблема в том, что на хорошем уровне JS знает со значительно большей вероятностью фронтендщик, чем бэкендщик. Отсюда проблема поиска: чтобы писать серверное приложение на Node.js - это либо фронтендщик начинает осваивать сервер, что, безусловно, похвально, но требует понимания многих вещей, с которыми человек ранее не сталкивался, либо бэкендщик начинает осваивать JavaScript, для которого, скорее всего, в новинку событийный подход и другие моменты из мира JavaScript который, как известно, во многом сильно отличается от классических языков с поддержкой ООП. Это я еще не упомянул тот факт, что Node.js появился сравнительно недавно, и специалистов по нему чисто физически не может быть очень много.

Еще один момент. Программисты изучают то, что приносит деньги, то есть то, что более-менее востребовано. Компании, в свою очередь, стараются использовать технологии, для которых легко найти специалиста (привет, 1С-Битрикс). В итоге замкнуый круг, который потихоньку, конечно, разомкнется, но нужно время.

Итого: дефицит специалистов, которые бы умели все, что необходимо. К тому же ты хочешь получить и фронт, и бэк в одном флаконе, что еще больше усложняет поиск.

ВАЖНО! Ниже строго ИМХО.

Если коротко, то либо Angular 4, либо Vue.

Angular (почти) привязан к TypeScript (что не плохо, но стоит иметь в виду) и строг с точки зрения подходов к разработке. Он отлично подходит для крупных компаний, где много разработчиков трудятся над одним проектом. По крайней мере из всех существующих фреймворков/библиотек он лучший в сегменте.
Ну и, разумеется, Angular 1 уже можно даже не рассматривать - это фактически совсем другой фреймворк, да и плюс один из первых в своём роде. На нём была произведена своеобразная работа над ошибками, результат которой мы видим сейчас не только в Angular 2/4, но и во многих других фреймворках/библиотеках.

Vue - это вариант гораздо более простой и понятный, но оттого не менее крутой. Он даёт больше свободы, что скорее плохо для больших команд, но зато писать на нём одно удовольствие. Я бы сказал, что Vue вобрал в себя всё лучшее от Angular и React, в итоге став полноценной альтернативой первому и заменой второму. Он сейчас очень активно развивается и вангую, что рано или поздно он вытеснит React.
И я не утверждаю, что React плохой, просто Vue объективно лучше по всем параметрам. Пока что кроме сообщества в силу разницы в возрасте, но это временно.

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