Алексей Павлов: вообще по поводу слоев - есть такой термин как "шестигранная архитектура". То есть ваше приложение или его часть представляет собой шестигранник (на самом деле на количество граней пофигу просто так звучит круче). Каждая грань - это какой-то вариант взаимодействия - база данных, http, rest, связь с другими частями приложения... короче связь с внешним миром. Первым слоем идет в этом случае - слой фреймворка. Это собственно контроллеры и доктрина и т.д. Затем идет слой приложения, это наш сервисный слой. Репозитории относятся туда же. Далее идет слой предметной области где содержится вся бизнес логика (стоит разделять бизнес логику и логику приложения, к которой относятся такие вещи как "послать email кому-нибудь если все удалось"). Ну и в самом центре - энтити и value object-ы в которых большая часть бизнес логики приложений.
FireGM: mainBowerFiles для подключения зависимостей, gulp-inject, gulp-es6-transpiler, gulp-ng-annotate ну и т.д. и т.п.
по структуре - придерживаюсь рекомендованной в angular styleguide (единственное что, пока не так часть приложение разделяю на маленькие модули но стараюсь исправляться). Ну и пытаюсь сейчас покрывать тестами через cucubmer.js что бы можно было одни и те же фичаспеки и на бэкэнд и на фронт ложить (на бэкэнде тестами покрываю через behat).
Qixing: ну несовсем... вы должны сделать класс-репозиторий (и написать его вместо Doctrine\ORM\EntityRepository из приведенного мной примера) - он же будет классом сервиса.
Вы поймите - сервисы это все что можно взять из DI, но это просто классы.
des1roer: я ничего не понял из вашего предложения. Может вам стоит поспать?
Дефолтная реализация Python медленнее пыха, но есть еще Pypy который чуть быстрее, но есть еще HHVM который вроде тоже пока быстрее... А вообще у вас там не может быть столько данных что это вообще хоть сколько нибудь проблема.
Roman Hinex: вы о чем? Конфигурация инициализируется при вармапе кэша. Если у вас потом данные в базе поменялись (например пользователь поменял или миграции не накатились) то все, нужно будет чистить кэш заного.
Ярик: положения вещей не изменилось - мнений все так же много. Надо пытаться сформировать свою точку зрения. Я понимаю что в виду отсутствия опыта это сложно сделать. Надо пробовать на практике а это лень, есть ощущение "в пустую потраченного времени" и т.д. На вашем этапе любая практика, пусть и неудачная - это опыт а значит не зря.
Александр: бэкбону это нужно что бы знать нужно синкать данные с серваком или нет. Вы можете так же реализовать свою модель с геттерами/сеттерами или вообще бэкбон подключить в довесок. А "обзерверы" ангуляра детектят только локальные изменения и следят только за тем за чем его просили следить.
К сожалению эти сервисы не покрывают случаи со странностями отрисовки (моргания, артефакты при анимациях и т.д.), так же если вы имеете дело с приложениями то все еще хуже так как надо либо писать на селениуме что-нибудь для установки прекондишена, либо... никак.
Алексей Калинин: а я думаю что окружение - личное дело разработчика. Чистый настроенный VPS с по умолчанию закрытыми портами (кроме 80 и 22) а дальше можно все через ansible/puppet поставить. Если с точки зрения хостера - можно подготовить плэйбуки базовые для провиженинга VPS.
