Александр А: со мной работает команда из десятка дизайнеров, и всем скетч понравился в контексте web дизайна и дизайна мобильных приложений. Я согласен про субъективизм, но есть еще консерватизм. Потому я сужу по большинству.
ngc789: angular - клиент, yii - бэкэнд. Вы не можете реализовать бэкэнда на angular, так как это UI фреймворк, предоставляющий какую-то дополнительную инфраструктуру и общий каркас в виде контейнера зависимостей и т.д.
Вопрос выбора решается просто - концентрируйтесь на языке, фреймворка это второстепенная штука, важно понимать принципы заложенные в оные. И желательно хотя бы два фреймворка пощупать.
Neoline: я лучше буду поручать работу разработчикам, которые ценят клиента, а не свой код. Да и "произведения искусства" - это весьма субъективная штука. Вы же видели эти шедевры "соверменного искусства"? Большинство скажет что это просто булшит, но есть "ценители".
Программирование - это не искусство. Это просто работа. Причем скучная. Код должен быть скучным. Не вызывать вопросов (покрайнемере слишком часто) со стороны других разработчиков. И вот тогда - это идеальный код. Он работает, он скучный, и с ним может быстро разобраться любой разработчик.
p.s. Вы тесты пишите?
Fetur: Передавайте все содержимое вашего git репозитория. Я банально делаю git export. Так же у меня для каждого проекта есть README, в котором прописана детальная инструкция для разработчиков о том, как поднять проект. И делаю я это не только потому, что со мной работают другие люди, и частенько проект передается между разработчиками. Но и в принципе что бы была возможность "сбросить" надоевший проект без вреда для оного.
мне кажется что стоит перед паттернами ознакомиться с SOLID и GRASP. А потом уже паттерны, и искать в них применения принципов SOLID и GRASP. Тогда это все будет продуктивно, будет видна причина и следствие.
ngc789: Можете работать с Yii но документацию по Laravel проглядите. Там много пересекающихся вещей, а документация по Yii мягко скажем описывает только Yii, сам же Yii предлагает решения только для очень простых задач.
По поводу angular на фронтэнде и что-то там на бэкэнде - вот мы сейчас на тостере - можно это дело на ангуляре сделать. Или хабр. Или любой другой проект. Только тупые сайты визитки, где просто статический контент и никакого интерактива лучше делать тупо как статический сайт. Словом, там уже идет здравый смысл и оценка профита.
Роль rest api - транспорт данных между фронтэндом и бэкэндом. интеграционный слой. Как RPC или что вы там могли юзать. Опять же гугл в помощь.
Neoline: програмное обеспечение - это не произведение искусства. Работа оплачена, отдаем исходники. Причем на более-менее серьезных проектах за раскрытие исходников или вообще любых деталей о реализации проекта, вам налагается нехилый такой штраф (NDA называется, и на западе его придется подписать при работе с любым серьезным продуктом).
Аналогию с exe файлами не понял. Если вы заказчик и заказали exe-ник, вам должны предоставить и исходники из которых можно потом это добро собрать.
Neoline: вот с таким подходом фрилансеров нормальных долго икать приходится. Вам не за код платят, а за решение поставленной задачи. Если оно удовлетворяет требованиям - отдаем исходники и все хорошо. А если вы пытались "наколоть" заказчика - ну так это лично ваша проблема.
Пётр: читаем что такое $digest, читаем как работают фильтры в ангуляре. Если коротко, фильтры в первом ангуляре срабатывают на каждый чих, и чем сложнее они, тем больше проблем с производительностью. Да и отфильтровать в контроллере намного проще, нежели в темплейте, больше контроля. А так как есть возможность юзать те же фильтры в контроллере, мы вообще ничего не теряем от этого.
copal: тут спорно. Я частенько вижу как переиначивают названия в разных фреймворках, и это создает хаоса еще больше. Народ то не особо любит разбираться что где и почему.
Дмитрий: ну... скорее просто сущности, onion как бы говорит "база данных второстепенная штука", мол абстракции от слоя хранения данных через репозитории и т.д.
copal: "тестировать методы" вообще как-то не звучит. Мы покрываем тестами код метода, но тестируем мы объект (поскольку их отделить друг от друга не выйдет, только если это статический метод, представляющий собой чисту функцию).
По поводу тривиальности - тут опять же надо смотреть по ощущениям. Если вы боитесь что кто-то в вашей команде сломает это добро, то надо покрыть тестами. А если вот эта проверка (hasItem) довольно часто встречается - проще сделать UniqueList какой-нибудь который сам будет этим заниматься, и тогда мы сильно упростим себе жизнь.
