unclechu

на начальном этапе в кач-ве бека можно использовать https://github.com/stympy/faker в связке с https://github.com/typicode/json-server

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

React, Redux, Redux Saga, React Native и без еды ты уже никогда не останешься.

Нет одинаково эффективного пути для всех и каждого.

Я учился на конкретных задачах. Обучение практически всегда начиналось с состояния хочу сделать вот это (четко осознаваемый конечный результат), но вообще понятия не имею как это делать, и даже с какой стороны подойти и за что хвататься...

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

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

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

Далее из модулей, как из кубиков лего пытаешься собрать функциональные блоки. Тут важно понимать, что чем более автономные модули и блоки у тебя получаются, тем лучше, особенно для целей тестирования. Если ты забиваешь болт на тестирование, то тебе нечего делать в разработке.

На первых порах, тестирование будет занимать до 99% времени и сил. Заодно подтягивается синтаксис используемых языков (вообще не важно каких), вырабатывается внимательность, концентрация, тренируется память и пр.

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

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

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

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

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

Ах да, обложись справочниками по любому инструменту и научись быстро вникать и подхватывать необходимый минимум. Обычно достаточно на 20% владеть инструментом, чтобы решать 80% задач.

В любом случае я за критерий истины держу платежеспособный спрос.

Контейнеры данных

Они не нужны, используйте named volumes вместо этого (с версии 1.9 докера).

Исходный код и локальные npm-модули (или лучше это в предыдущий контейнер, и при старте выполнять

Нет, npm install надо выполнять ДО сборки образа. Когда контейнер стартует - внутри у него уже все должно быть. Опять же я лично против того, что бы выносить исходники проекта в отдельный контейнер-пустышку. У вас есть контейнер с нодой - исходники для ноды должны быть там. Есть некоторые нюансы связанные со сборкой контейнера но это так.

На файловой системе хоста

Ничего.

Логи прокидываются в stdout/stderr контейнера и собираются на хосте через докер любым подходящим драйвером (читаем документацию).

Конфигурация - все что в конфигах от окружения к окружению меняется - в ENV переменные. Все остальное - не меняется и потому просто вшито внутрь контейнера.

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

Динамическую XML карту сайта тоже желательно реализовать (в ней должны отсутствовать страницы пагинации новостей)
Страницы пагинации новостей закройте правилом через robots.txt - главное, чтобы не было запрета на индексацию детальных страниц новостей
Проверку корректности robots можно проверить здесь

не надо использовать datepicker для мобильных устройств, используйте нативный

<input type="date">
<input type="datetime">

Используйте submodules, так и главный репозиторий будет чище и права доступа можно разграничивать по модулям.

Это — метка. Как case: или default:, использующиеся в switch.
Обычно в JS редко увидишь использование меток, поскольку единственная их цель — в случае нескольких вложенных циклов переходить из тела любого внутреннего цикла к отмеченному внешнему, невзирая на уровень вложенности.

Для этого используются инструкции break и continue, которые без метки работают непосредственно с тем циклом, в теле которого указаны. Если добавить метку, происходит прерывание (break) помеченного цикла либо переход к его блоку изменений (continue).

Там же написано:

useful for nested loops

Пример:

var stop = 7;

label:
for (var i = 10; i--;) {
	console.log('i:', i);
	for (var j = 10; j--;) {
		console.log('j:', j);
		if (j == stop) {
			console.log('stop');
			break label;
		}
	}
}
console.log('stopped');

Не всегда. Если выделяют, то обычно начиная их имя с подчеркивания:
var obj = { _answer: 42}
Не стоит забывать и про protected.

Да, IcedCoffeeScript добавляет в ванильный кофе только операторы defer и await. И все.