Aleksei Podgaev

Вопрос в том, как именно вы его запускаете.
Можете пример командной строки привести и что вам на это Node отвечает? Может быть он не может найти файл конфигурации в текущей папке?

Смотря какие проекты вам интереснее делать. Angular в последнее время склоняется в Enterprise, т.е. на нём вы будете делать тяжёлые админки со всякими графиками/диаграммами, сложными задачами типа ленивой загрузки и кэширования таблиц с данными и всё такое прочее. На React делают больше решения ориентированные на массового пользователя, с обилием всяких визуальных плюшек, анимации и т.п. В общем если привлекает возиться с CSS и анимацией - лучше браться за реакт. На нём, кстати, и игры, как мне кажется, легче писать.

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

Очень грамотную статью по лучшим практикам в первом ангуляре от John Papa предложил первый комментатор adamsafr . Полностью согласен и рекомендую к прочтению. В остальном же для быстрой адаптации в новом коллективе самое главное - не закукливаться в себя и как можно больше спрашивать у опытных коллег. Они все пониимают, что вы новичок, и всегда постараются объяснить решения принятые в процессе разработки. Лучше спросить один или два раза сейчас, чем тупить и ошибаться всё оставшееся (недолгое в этом случае) время на новом месте.

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

Лучшим решением будет безусловно предоставление сервисом интерфейса. В описанном варианте, наверное getUsers(), который будет возвращать, готовый массив, Promise или Observable, в зависимости от необходимости. А внутренню кухню и, в частности, переменные, лучше скрывать от пользователей.

Немного непонятен вопрос. Нужно расписать алгоритм из двух циклов или как генерировать таблицу средствами Javascript или что? Нужно это сделать на чистом javascript или можно применять фремворки?

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

Вот так не работает?
<input [attr.formControl]="control" #input>

https://angular.io/docs/ts/latest/guide/cheatsheet.html

Можно сделать по-разному. Главное с самого начала решить, кто будет вносить изменения в данные. Я бы рекомендовал, чтобы изменения вносились только в одном месте (например в указанном в примере контроллере). Если у вас данные будут менять все кому не лень - другие сервисы, директивы, другие вложенные контроллеры, то вы очень скоро потеряете контроль над тем, что происходит у вас в приложении и откуда растут ноги у изменений. Подход с единственным ответственным за изменение данных сильно облегчает жизнь в приложениях со сложной архитектурой, хотя и требует иногда лишнего прокидывания обработчиков событий вверх по иерархии компонентов.

Если хотите Angular2, то берите Ionic. Как уже было сказано выше, для интернет-магазина библиотек подобных Ionic и ReactNative хватает с головой. При определённой прямоте рук и более сложные проекты делают. Я видел как-то презентацию видеостримингового портала сделанного на Angular и Ionic (мобильное приложение). Так что было бы желание.

Согласен с предыдущим автором. Разберитесь как работают промисы и асинхронный код вообще.
Ваша функция GetResponse действительно не ждёт, пока отработает запрос, а сразу возвращает значение "foo". Так что вы получаете именно то, что написали в своём коде. Если вы будете "приостанавливать" выполнение функции, то ваши пользователи проклянут вас за повисший браузер. Лучше сделать, чтобы alert вызывался только после выполнения запроса, т.е. в success.

Необходимо немного больше данных. Blog - это просто объект или Promise? Что такое Blog.Blog? Когда и как это свойство инициализируется?

Я бы рекомендовал взять bourbon+neat как основу. А дальше смотреть как сделано у других (скажем, в bootstrap) и делать только те модули, которые нужны проекту в данный момент.

Я бы разделил работу с моделью и http в разные модули. Тогда в модуле, отвечающем за запросы к серверу можно было бы реализовать и работу с промисами и кэширование по необходимости, а модуль, отвечающий за работу с моделью был бы очень лёгким и понятным. Нужна ли какая-либо пост-обработка пришедших данных или они уже приходят в удобном для представления формате? Если второе, то лучше работать напрямую с промисами - возвращать промисы в те компоненты, которым нужны соответствующие данные.

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

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

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

Страница с блоками хранится в статике или вытягивается из БД?
Если в статике, то да, без cron-а не обойтись. Если же в БД, то от этого и надо плясать. Если страница генерируется динамически, то код сортировки блоков нужно запускать при генерации страницы, а не по расписанию.
Если же блоки должны меняться местами прямо в браузере пользователя, если он, скажем, долго держит открытой страницу (фильм с неё смотрит или ещё что), то тут уже нужно задействовать клиентский javascript.