phpus: если он новичек, то что бы он не выбрал - загубит проект. А CQRS даже в неумелых руках (я не представляю как можно криво реализовать этот довольно четко описанный паттерн, в отличии скажем от MVC) хорошо поддается изменениям и рефакторингу.
Kokaas: советую вам почитать чего про паттерны проектирования и меньше зацикливаться на данном этапе понимния ООП на всяких там MVC. Уясните откуда взялась необходимость MVC (разделение на слои и введение дополнительного слоя для уменьшения связанности двух других), а как это назвать уже дело третье. В бэкэнде вообще православного MVC нет, есть только адаптации.
AlexLIn: уточнил, там вообще-то завятая стояла, не перечисление а отделение двух частей предложения. Но на всякий раскрыл чуть более полно.
phpus: с SOAP везде все плохо. По началу вроде бы все не плохо, а потом боль.
Kokaas: шину данных для SOA, если вы будете разносить приложение на отдельные сервисы. Просто у автора там было про пуши, пушами заниматься должно отдельное приложение, к примеру на ноде, а весь остальной бэкэнд можно реализовать на чем угодно. В этом случае посредствам очереди сообщений можно организовать общение двух элементов системы без привязки к конкретной имплементации и языку программирования.
Сергей Илларионов: indexOf возвращает индекс искомого элемента массива или -1 если его нет. В этом примере splice удаляет один элемент из массива, находящийся по индексу, который вернул нам indexOf.
Антон Иванов: что значит "функцию сабмита в $q"? Функция сабмита должна просто вернуть промис. А от переменной вы не избавитесь. Ну то есть можно конечно (ивентами, интерцепторами и т.д.) но это сложнее как разрабатывать так и поддерживать.
Антон Иванов: вся соль в том что мы просто экспортируем в scope промис (читать про промисы обязательно). Кто именно его генерит, асинхронный ивент (у меня как раз такой), $http или что-то еще - не суть вообще. В Angular все асинхронное кидает промисы.
NETChaser: хм.... мультиверсионного API.... сама трактовка вводит меня в ступор. В контексте CRM/ERP можно просто построить приложение используя CQRS + Event Sourcing на бэкэнде, никакой привязки к фреймворку, чисто архитектурные решения. Если вы в контексте именно версионизации API - то тут как бы больше подходят мидлвэры...
NETChaser: и тут возникает вопрос, причем тут фреймворки? Мне кажется основная проблема всех этих неповоротливых CRM/ERP как раз таки в том что внутри сильно связанный говнокод, и тут проблема как раз в том что люди слишком сильно полагаются на фреймворки. В итоге их бизнес логика жестко завязана на средства разработки.
NETChaser: вы поймите, сайтов где люди ищут себе чем заняться - нет. Обычно разработчики присоединяются к уже существующим opensource проектам. Собутыльников/единомышеников можно находить на митапах/конференциях, либо светить идеей везде и всюду.
По личному опыту могу сказать что если у вас нет времени заниматься разработкой проекта, то и ставить задачи времени не будет. А найти достаточно опытного разработчика, который будет работать без ваших указов и самостоятельно сможет принимать решение - не выйдет. Вам как минимум придется описать полностью все моменты своей идеи, а это ужасно много времени отнимает. Мне проще код написать скажем чем расписать все фичи проекта и мокапы подготовить.
NETChaser: вам нужно место где тусуются люди у которых дофига свободного времени.
А в фразах куча противоречий. Из него следует что чувак должен уметь писать велосипеды. Это вопервых. Во вторых... вы можете в контексте Javascript написать НЕ OO фреймворк? Не думаю.
