В чем вы создаете php/tpl/html шаблоны?

ну я так же использую Angular, дробя все на компоненты (директивы с контроллерами, которые появились в Angular 1.3 и стали юзабельными в Angular 1.4, В Angular2 в принципе выходит примерно так же как и у полимера с определенными оговорками)

Есть ли объективные причины отказаться от аннотации?

wittyrider: профит... ну вот в чем профит от MVC/ADR? Разделение обязанностей на слои. Тут тоже самое, можете почитать про луковую архитектуру и все такое.

Типичная картина для Symfony, это использование доктриновских сущностей как тупые контейнеры для данных. Кто-то делает это в контроллере в виде CRUD, кто-то делает сервисный слой и выходят транзакционные скрипты, кто-то балуется CQRS, кто-то упарывается по DDD. Так вот, я из последних).

У меня сущность доктриновская является так же сущностью предметной области (это стало по сути более-менее возможно только начиная с Doctrine 2.5, без embeddable было грустно). То есть у меня есть отдельный слой называемый domain-layer в котором все сущности, объекты значений и маленькие сервисы которые выполняют какие-то бизнес правила, которые не выходит впихнуть в сущность, например проверка уникальности значения - это дело не запихнуть в сущность так как сущность ничего о других сущностях не знает).

Сущность не имеет ни геттеров ни сеттеров (почти, обычно у меня появляется что-то типа getId()), она содержит методы бизнес логики и т.д.

Так же у меня есть сервисы уровня приложения. Это грубо говоря те же контроллеры, только принимают они не HttpRequest а DTO. Плюс этого подхода в том что контроллеры конвертируют данные из формата интерфейса (HTTP, CLI, MQ) запрос в формат приложения (DTO). В итоге мне не составляет труда добавить еще один интерфейс, версию API или еще чего. Внутри сервиса у меня так же логики особо нет. только дергаются сервисы других слоев, а сам сервис уровня приложения только определяет что в какой последовательности я буду дергать.

Ну и flush у меня в контроллере.

Если хотите подробнее о разных подходах, в том числе и о CQRS и о DDD + агрегатах, можно посмотреть один докладик который я люблю скидывать людям:

https://www.youtube.com/watch?v=ajhqScWECMo

Как писать высоконагруженные и масштабируемые Rails приложения?

Risent: По моим представлениям рельсы этот тот инструмент, где высокие нагрузки идут на втором плане. То есть сначала мы быстро реализуем MVP а потом уже делаем кастыли что бы все быстро работало. Так например сделали чуваки из твиттера, быстро запилили продукт, занялись горизонтальным масштабированием и потом переписали самую узкую часть, а именно поиск, на Scala.

Как писать высоконагруженные и масштабируемые Rails приложения?

CapeRatel: этот коммент не дает полноценного ответа на ваш вопрос.

Как писать высоконагруженные и масштабируемые Rails приложения?

Высоконагруженные и масштабируемые приложения - это вопрос не кода а архитектуры. Микросервисы (к вопросу о "вставках" на другом языке, вместо вставок просто реализуют узкие места как микросервисы на том языке на котором удобнее всего), организация кеширования и т.д.

На каком языке удобней писать websocket сервер?

HaruAtari: опенсурс это здорово, кидайте конечно, мне особо интересны описанные сценарии. Сам я планирую ближайшие пару недель стартануть в рамках опенсурса систему управления тест кейсами, так же для своей команды. Как-то существующие варианты показались убогими.

В целом да, наилучший вариант организовать WS-сервер на каком-нибудь socket-io и связать с php приложением через MQ и pub/sub для авторизации.

Я в одном из проектов последних использовал JWT для аунтефикации, что позволило упрастить схему авторизации для соединений, так как токен нужно проверять только на валидность подписи, а для этого не нужно ничего форвардить в пых. Связать же пых и ноду и заставлять его пересылать пользователям сообщения не составляет труда.

На каком языке удобней писать websocket сервер?

Задумка Ангуляра в том, что он позволял верстальщикам делать интерактивность просто.

Это плюсы конкретно дата биндинга и только, остальное достигается за счет дробления UI на директивы, в этом случае за логику верстальщики (если у вас есть отдельная такая личность) не отвечают.

Проблем с производительностью у ангуляра особо нет, если не пихать все во view и разумно использовать этот самый дата биндинг. Конкретно работа с WS и т.д. всеравно ложится на плечи разработчика, это модель, ангуляр тут ни на что не влияет.

Есть ли объективные причины отказаться от аннотации?

BoShurik, ну как бы это нормально, я обычно всегда так делаю, в контроллерах аннотациями, в yaml подключаю все контроллеры по отдельности. Это довольно удобно и нет никаких проблем с сортировками.

В прочем я большую часть времени пишу апишки, так что у меня таких проблем в принципе нет.

С чего начать изучение написания TDD - тестов?

Oxoron:

Тратим время на изменение системы. Поскольку рефакторить без тестов ненадежно и страшно - тратим много времени.

Нуу... при TDD у нас уже есть тесты когда мы начинаем рефакторить, так что не так уж много времени. Просто нужно следить за руками и никогда не менять между прогонами тестов и тесты и код. И тогда проблем будет куда меньше. Так что... я пока не вижу проблемы. Это просто часть цикла разработки, пишем красный тест, делаем его зеленым, чистим код. При определенной длине итерации это не так скучно и это не так сложно и долго. Длину цикла надо подбирать из собственной уверенности в том что вы делаете. Если вы не уверены - уменьшаем, пишем маленькие тесты, потом мало кода и чуть-чуть рефакторинга. Если мы уверены в себе - пишем сразу много тестов, много кода и жесткий рефакторинг. Если при этом что-то идет не по плану, то надо уменьшать длину итерации, находить баланс.

Если же мы работаем с кодом, состоящим из спагетти

Вы видимо описываете ситуацию, когда у нас уже есть готовая система и мы хотим перейти на TDD. Ибо спагетти и TDD сложно сочитаются. Опять же у Кента Бэка в книжке описываются мысли как быть в такой ситуации. Решение - тесты уровня приложения, то есть функциональные или интеграционные тесты. Если у вас задача отрефакторить код, то да, TDD тут не сильно поможет если код изначально небыл написан с применением TDD (ну или хотя бы без нормальных юнит тестов, которые опять же исключают вероятность совсем уж плохого кода). А если у вас задача добавить функционал - то тут можно просто покрыть сначала часть системы тестами уровня приложения и затем дописывать юнит тесты по неоходимости. Со временем наша система станет преображаться и все станет хорошо.

Тут важный момент. Рефакторинг системы, когда у нас есть лапша и мы хотим сделать хорошо, это уже выходит за рамки TDD. TDD подразумевает эволюционный подход, выживает самый полезный кусок кода. Все остальное жесточайше рефакторится постепенно. Потому система большую часть своей жизни находится в стабильном состоянии. А в случае с лапшой нужно устроить революцию, и тут уже совсем другая история.

недостатков TDD и области применения методики.

Ну недостатки... в принципе понятны из плюсов и описания методологии. Это эволюционный подход, он плохо применим когда надо что-то резко и координально поменять. С другой стороны это не совсем здоровая ситуация когда надо что-то резко и координально поменять так что жизнь в этом случае всеравно боль и тлен.

А вот по поводу области применения - соглсен. Следовало написать.

С чего начать изучение написания TDD - тестов?

я как-то около месяца просидел, обкладывая тестами будущую программу, в которой не было ничего, кроме воздуха.

Как это понимать? Вы месяц тупо писали тесты? Это как бы идет в разрез с TDD если что.

продумываешь все её компомненты в голове до мельчайших подробностей

Вот в этом и ошибка, TDD подразумевает что мельчайшие подробности вы обдумываете в тот момент, когда пишите тесты.

Уже видишь эти данные

Используя TDD вы все это видите еще на этапе написания тестов, обратная связь может быть достигнута существенно раньше, ошибки планирования и более явное понимание задачи приходят раньше, проблемы открываются раньше. Хотя не спорю иногда PoC реализация быстрее. TDD хорошо себя показывает когда вы делаете что-то более-менее сложное, где есть взаимодействие объектов хотя бы. Скажем покрывать тестами код, который должен только заменить данные (по сути сеттеры, хотя я сеттеры аля setSomething не пишу).

Но надо соблюсти правила TDD

Один мой коллега не так давно сетовал на то что kanban это весьма неудобная и не дает никакого профита. В разговоре с ним оказалось что из 3-х правил kanban-а ребята выполнили только одно, и два других просто проигнорировали, зато добавили десяток своих правил (вроде как долго таск может быть в in progress). Словом... сетовали на то что правила канбана отстой и при этом ни разу не выполняли этих правил и даже не подозревали об этом.

Я это к чему, можете сформулировать эти самые правила TDD?

В результате, у тебя множество тестов, длинная история в репозитории из их создания и ноль программы.

Этого не может быть, если вы практикуете TDD. Следовательно вы не практиковали TDD а просто писали тесты и потом код. Либо я не понимаю вашей позиции, выгоядит она именно так.

И становится просто жалко стирать тесты, которые к новой версии вообще не подходят.

Для этого может быть только одна предпосылка - редкое изменение требований, когда часть функционала больше не нужна. А так, при обычном рефакторинге у вас не должно возникать таких проблем. Я во всяком случае не могу придумать себе сценария при котором мне пришлось бы удалять какие-то тесты. И да, я не покрываю тестами тупой бойлерплейт или чего еще что часто меняется и не несет на себе большой смысловой нагрузкой. Такие вещи у меня обычно покрыты функциональными тестами которые менее подвержены изменениям.

Всегда нужно понимать что здравый смысл всегда важнее каких-либо правил, какой бы умный мужик в каких бы умных книжках не писал бы что-то. В этом плане рекомендую вам все же почитать Кента Бэка, он довольно много времени в своей книге уделил здравому смыслу и рефакторингу. Во всяком случае если руководствоваться его советам таких проблем, какие описали вы, можно спокойно избежать.

С чего начать изучение написания TDD - тестов?

Oxoron: это как так? Можете раскрыть мысль? Как по мне это одна из самых сильных сторон TDD.

С чего начать изучение написания TDD - тестов?

Еще есть лекции Дяди Боба на эту тему, но у него более радикальные взгляды.

Про шаблонизаторы, кто подскажет?

Используйте twig

Где сайт о машинной графике?

Сухроб Хусамов: нууу лучше почитайте лекции. Конкретно эти неплохи, по ним когда-то учился)

Как изменять сущности без форм?

Никита Гущин: да да, это та причина по которой мне нравится symfony/serialier.

Как изменять сущности без форм?

Никита Гущин: потому я и рекомендовал бы symfony/serializer так как там таких проблем нет. И да, по поводу ваших сервисов... они бессмысленны, так как вы всеравно завязываетесь на HTTP. По сути вы вынесли кусок контроллера в сервис, но это всеравно кусок interface layer внутри application layer, реюзать этот сервис для CLI уже не выйдет, как и для MQ или чего-то еще.

Как подключить symfony2 в существующий проект?

мидлвэри это называется. С тех пор как в PHP появился PSR-7 (да и с HttpKernel) это можно организовать на уровне объектов а не сетевых запросов.

Как изменять сущности без форм?

Никита Гущин: jms serializer уже больше двух лет активно не пилится, ишусы остаются без ответов... шмидсон все сили бросил на скрутинайзер свой, так что.... пользоваться jms сегодня как-то печально.

Как изменять сущности без форм?

Никита Гущин: я бы вообще порекомендовал бы вам обратить свой взор на symfony/serializer, так как JMS уже давно не суппортится и не так удобен. Тогда ваша проблема разрешится автоматически.

Почему проставляются слеши и режутся теги?

мэджик квоты ж удалили в php 5.4....