У dimensions.app (ссылка в посте) после внимательного изучения тоже обнаружилась такая функция — preview mode в правом верхнем углу.
Также у них клевый chrome app — можно поставить прямо в браузер, как я и сделал.
Да, конечно — прежде всего это непрерывная обратная связь, автоматическое развертывание и апдейты проекта. Также очень полезен автоматический сбор всех метрик и инспекции, генерация документации. Причем в сценарии построения можно встроить не только генерацию api-документации но и пользовательской документации, если например писать ее в докбуке и компилировать во вемя билда через phd.
Вобщем преимуществ масса и многие из них зависят индивидуально от вашего проекта и как вы адаптируете автоматизацию к своему процессу разработки. Главное тут поменьше ручного труда ))
То есть для проекта есть три вида билдов: 1. быстрый билд (при каждом коммите в репозиторий) 2. полный билд (каждое утро — все проверки, инспекции и генерация документации) 3. деплоймент-билд (вручную — все проверки + обновление рабочих серверов)
Да, наверное так и есть — но у нас после удачного билда идет автоматический деплоймент на рабочие серверы, поэтому без тестов никак. А если тесты провалились, то нафиг такой код в репозиторий принимать. Можно послать автору коммита сообщение и пускай поправит свой код. Так что почти как контроллер от почки получается ))
Кстати все эти желанные функции становятся все менее актуальны с переходом на репозитории Git вместо Subversion. Некоторое время назад поддержки Git в TeamCity не было, не знаю как сейчас. Возможно уже сделали?
Нужно будет попробовать обязательно. Что мне в нем особенно кажется примечательным — это возможность не принимать коммит в репозиторий если провалились какие-то тесты или инспекции. Так чтобы никто не мог передать в репозиторий сбойный код. В bamboo этого нет.
Я бы посоветовал вам прогнать профайлером свой код и определить узкие места, которые необходимо закэшировать или просто определить их методом здравого смысла. На мой взгяд не нужно кэшировать все методы модели. Непосредственно в методах модели, в табличном гейтвее как у вас или вообще на уровне гейтвея в домен, прописать логику кэширования. Для удобвства можно вынести настройки в конфигурационный файл, (лучше чем в бутстрапер).
Таким образом у вас получается легко конфигурируемая система кэширования для компонента + чистый интерфейс модели, где вам не нужно много думать «как оно там внутри кэшируется» вы просто вызываете одни и те же ясно именованые методы которые уже сами знают как себя кэшировать и просто возвращают данные.
Да, бузесловно. Но это все-таки коммерческий продукт. Нельзя просто так «взять» из него компоненты. С таким же успехом можно использовать компоненты Zend в CI ))
Да, я вот тоже 1.5 года работал с CI. Теперь хочу перейти на ZF. Основные аргументы за — это, прежде всего, поддержка фреймфорка и то сколько у него всего внутри. Выбирая CodeIgniter приходится многие вещи писать заново — поддержку модулей, авторизацию, ACL, а все это уже есть в Zend. Основной аргумент против Zend — это производительность, хотя сами чуваки из Зенда говорят — что у ниж в приоритетах code base и только после perfomance. Прибавьте к этому интерфейсы к вебслужбам, и отличный маркетинг (наример поддержка со стороны adobe, microsoft), и команду Zend с их продуктами типа Zend Server и интеграцию в Zend IDE.
Могу сказать, что имея опыт работы с фреймворками и понимание основных концепций (как тут выше верно заметили) сменить фреймворк не та уж и сложно.
Также у них клевый chrome app — можно поставить прямо в браузер, как я и сделал.
Вобщем преимуществ масса и многие из них зависят индивидуально от вашего проекта и как вы адаптируете автоматизацию к своему процессу разработки. Главное тут поменьше ручного труда ))
Кстати все эти желанные функции становятся все менее актуальны с переходом на репозитории Git вместо Subversion. Некоторое время назад поддержки Git в TeamCity не было, не знаю как сейчас. Возможно уже сделали?
Таким образом у вас получается легко конфигурируемая система кэширования для компонента + чистый интерфейс модели, где вам не нужно много думать «как оно там внутри кэшируется» вы просто вызываете одни и те же ясно именованые методы которые уже сами знают как себя кэшировать и просто возвращают данные.
Могу сказать, что имея опыт работы с фреймворками и понимание основных концепций (как тут выше верно заметили) сменить фреймворк не та уж и сложно.