Юрий Ярош

Нужно понимать что даже если хранить JSON в PostgreSQL под gin индексом, то это будет быстрее чем Btree в Mongo. Потому что using index with vodka ! JSON в PostgreSQL можно и не нормализовать, там есть flyweight шаблон, так что ничего лишнего он хранить не будет - посмотрите примеры работы. А вот в реляционных табличках какого-нить enum будет более чем достаточно, хотя я обычно не ленюсь, и создаю кучу табличек с id name +unique, и отдельным ts полем для поиска.

Есть самописные polyfill'ы на Intl vmin vmax и rem'ы, но поддерживаю ie9+.

Android Studio и так по умолчанию использует Gradle Demon - быстрее не получится.
Надо купить быстрее тазик и поставить SSD'шный RAID.

Просто у некоторых контроллеров бывает взаимная нелюбовь.
Такое часто встречается на ноутбуках и некоторых asus'овских материнках.

Сидим в slack'е с jira и phabricator'ом, но потиху слазим в trello, есть gitlab и gitlab-ci, тесты пока гоняются в browserstack'e. Из расходов - лицензия на browserstack, и пока что Jira. Всего сейчас работает 5 человек, и около 20 человек продажников и поддержки. CRM'ка самописаная, со своей админкой и своим Asterisk'ом.

На самом деле всё равно на чём писать магазин, так как это банальный CRUD и AAA сервисы, на практике обычно даже до нормальной модели БД не доходит.

Браузерные SPA (одностраничные приложения) сулят проблемами с SEO, а нормально написать на react'е изоморфное приложение не каждый сможет, да и prerender.io с angular.js не всегда хорошо себя ведёт, хотя можно поиграться и рендерить angular.js в jsdom'e... в общем найти человека который в этом всём нормально разбирается сейчас очень сложно.

Для описанной архитектуры аля CQRS-ES нужны бюджеты от 3000$+, что, собственно точно не самая лучшая идея для среднестатистического магазина, либо нужен энтузиазм разработчиков на котором далеко не уедешь, и мотивировать одним лишь энтузиазмом очень сложно. Готовых решений в этом плане просто нет в природе, а проверить не пишут ли там пятиколёсные велосипеды не всегда представляется возможным.

Проще взять любой среднестатистический РНР фреймворк и не заморачивать себе одно место, покрыть нормально тестами (Codeception к примеру), прикрутить полнотекстовый поиск и отчёты, разобраться как правильно реализовать ААА, убедится что у вас нормализирована модель БД. В последнее время, я всё реже и реже вижу даже 3тью нормальную форму, про остальные 3 история умалчивает.

Если у вас есть нормальный бюджет, 8000-10000$ на разработку магазина - можно думать о всех, описанных выше, вещах, но вам нужно правильно организовать процесс разработки и контроль качества, разобраться в мотивации разработчиков, и только потом можно будет думать не тратятся ли эти деньги не понятно на что, потому что, на моём веку люди так миллионы у.дмурдских е.жей запускали в космос изобретая никому ненужное нечто, и среди таких контор есть даже IBM, Logitech, и TI.

В общем для начала стоит разобраться в более простых вещах, а потом пытаться строить андроидов, иначе нас всех ждёт Skynet им. Kokaas'a.

p.s. php для меня уже года 2 как мёртв, а в 7ом будет больше от Java чем от php.

Достаточно плохо сформулирован вопрос

Если прямо в JSX шаблоне

{typeof FormOne !== 'undefined'? (<FormOne />): typeof FormTwo !== 'undefined'? (<FormTwo />): '' }

а вот так уже внутри шаблона не получится

{if (FormOne !== 'undefined') (<FormOne />) else if (typeof FormTwo !== 'undefined') (<FormTwo />)}

Так можно сделать только вне шаблона

render: function() {
  var Component = false
  if (FormOne !== 'undefined')
    Componenet = (<FormOne />);
  else if (typeof FormTwo !== 'undefined')
    Component = (<FormTwo />);

  return (
    {!!component ? (<Component/>): 'No component'}
  );
},

Тут всё сложно...
Нужно прикрутить сборку на gulp, с использованием csslint. Препроцессоры нужно использовать по шустрее, желательно postcss или stylus, sass/scss довольно медленные. ~4000 это очень много, ~1000-1500 потолок Нужно использовать относительные размерности, vmin, vmax, и rem, для осликов и iOS7 есть нормальные polyfill'ы. media-queries там тоже получаются довольно специфические, но все выводятся по формулам и оформляются в виде одного mixin'a. Одним из главных критериев качества разметки является количество div'ов на странице - уж больно сильно людей тянет на дикие раздувательства, но не зря же в html5 добавили тучу тэгов для упрощения структурирования контента, а для сss'a обычно достаточно селекторов из двух элементов, что бы не раздувать CSSOM и упростить рендер. Тестировать это всё дело можно в galen и browserstack.

Вообще вопрос QA в вёрстке сейчас довольно проблематичен - в постсоветском его почти нет, а всплывает чаще всего только во всяких забугорных lean стартапах, у которых есть деньги на наукоёмкие решения и их анализ.

Можно почитать/посмотреть записи с различных конференций, посмотреть как шардят большие конторы.
1. Аутентификация != Авторизация
2. Нужно понимать что при горизонтальном масштабировании сервер не должен хранить состояний - обычно люди хранят данные сессии в просоленной куке, а не в базе.
3. Распределять нагрузку нужно в зависимости от текущей, соответственно должен производится мониторинг, и запросы должны отправляться на наименее нагруженный сервер
4. В куке сессии должен записываться IP cервера который обрабатывает запросы от текущего пользователя, а DNS в свою очередь должен отдавать адрес сервера который работает с данной сессией. Таким образом с одним пользователем может работать только один сервер, и между ними не нужно гонять никаких редиректов, но на первое время можно просто редиректить.
5. В случае с push-нотификациями, и кэшированием там вообще всё очень сложно и нужно крутить CQRS-ES, иногда нужно решать задачу консенсуса Raft'ом.

Нет таких. Сейчас MV* (mvc mvp mvvm hmvc) потиху отходит на второй план, есть очень много вещей которые с его помощью, к сожалению, нельзя нормально реализовать. Довольно медленно развивается тема реактивных приложений, но нет нормальных юзабельных реализаций с RAD'ом, про полноценное SOA история вообще умалчивает. Всё где есть push-нотификации, близкие к реальному времени, требует нормального CQRS-ES'a, там тоже приходится писать костыли и ничего готового нет. Кодогенерация в зачаточном состоянии, а существующие реализации scaffolding'a у меня, лично, не вызывают ничего кроме ухмылки.

В общем пойду писать CQRS-ES SOA фреймворк под golang когда появится возможность.

С РНР/Python/Ruby проблема - в них нет возможности нормально писать масштабируемые реактивные приложения.
Нет возможности постоянно держать соединения для push'a без костылей типа gearman / beanstalk / celery / sidekiq etc, и там уже не MVC, a CQRS-ES ... в общем весело.

Советую присмотреться больше к Java / Golang'у.
Вот к ноде лезть не советую - слишком мелкая производительность, и сомнительная обратная совместимость.

У меня оно бывает вот так.
Думаю, у вас будет где-то так же через 5-7 лет ...

Обязательно нужно научится работать с существующими решениями для разворачивания инфраструктуры: puppet, chef, saltstack, ansible. А потом уже думать что учиться настраивать, и как...

Имеется ввиду количество переменных в $scope к которым применяется $watch'еры, и во время $digest цикла выполняется двойное связывание. Лечится вот так.

Если поместится на 2 страницы - не стоит вообще публиковать ... туторов и так полно.