Как стать автором
Обновить
3
Карма
0
Рейтинг

Пользователь

  • Подписчики
  • Подписки

Symfony 4: структура приложения

вот в этом месте я для себя пока не решил для себя. после того, как вы замокали инфраструктуру — ваши тесты не стали изолированными?


я пишу тесты так, чтобы мокать, но именно эти моки и определены в тестовом енве. эти же тесты без проблем запускаются и в dev, но они попытаются сходить в реальные сервисы, а не в замоканные

Symfony 4: структура приложения

test — очень похоже на dev но ориентируется на приемочные тесты.


А отдельного env для юнитов нет? С моками и пр.

stage — сервера которые используют QA, фронтэнды, мобильщики, в том числе для e2e тестов.


Про фронтов — я правильно понял, что у вас бэк — это чистое API и фронты пишут отдельное приложение, поэтому им не нужны всякие тормозящие фичи типа автоматических перегенераций кэша, статики приложения и пр? Если так, то ваша позиция понятна, у вас немного другой кейс.

У нас более «классическое» приложение с рендером на стороне твига, и фронты технически пишут то же самое приложение что и бэки, поэтому в нашем случае вот такой выделенный stage env не нужен (точней может и нужен, но не в таком варианте). QA, мобильщики и пр. используют просто prod вариант развернутый на внутренних контурах

Symfony 4: структура приложения

Я правильно понимаю, что на каждую группу разработки (бэки, фронты, итд) у вас есть отдельный env в symfony? Сколько у вас их всего, если не секрет? Мы просто используем классический dev,test,prod набор, а кастомизируем именно параметрами.

Symfony 4: структура приложения

«необходимым» в некоторых кейсах, давайте так. Т.е. есть такие случаи, когда без него не обойтись, в таких случаях его сложно назвать «опциональным»

по умолчанию — не нужен.


Вот с такой формулировкой я соглашусь, можно без него.

Symfony 4: структура приложения

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

Symfony 4: структура приложения

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

Symfony 4: структура приложения

у нас есть, например, дебаг тулбар, который управляется через параметры, т.к не всем разработчикам (фронтам, например) он нужен. да и вообще окружение по умолчанию отличается тем, что в разработке используется dev режим по умолчанию, на контурах дальше — прод. но мне казалось, что это логичная разница с продом, иначе зачем вообще тогда dev режим

Symfony 4: структура приложения

выше уже написали, что дотенв — не панацея

Symfony 4: структура приложения

любое окружение, которое не продакшен отличается от него по определению. не все параметры, как уже сказано выше, можно переопределить через dotenv, так что parameters.yml остается необходимым инструментом в конфигурировании площадки.


понятно что структура самих конфигов совпадает, вопрос именно в безаппеляционом тезисе "parameters.yml — он не нужен"

Symfony 4: структура приложения

А что делать, если у нас три десятка разработчиков с разными параметрами (персональные окружения)?

PHP-Дайджест № 110 – свежие новости, материалы и инструменты (28 мая – 11 июня 2017)

Основная проблема в том, что контр\ковариантность в пхп пока не смогли, потому что это создает какие то проблемы в разработке енамов.

то если у Razor есть наследники (положим, это библиотека), то изменить сигнатуру указанным образом невозможно, это тут же нарушает LSP для наследников.

Если же сделать нового «правильного» наследника, с нужной сигнатурой, то текущая версия PHP кидается ворнингами (т.к. пока мы живем с инвариантами)

https://externals.io/thread/514
https://wiki.php.net/rfc/return_types#variance_and_signature_validation

Так что это полумера, но это единственное что позволяет перейти от одного интерфейса к другому с сохранением обратной совместимости и без особых костылей. Хотя если вы знаете короткий путь, то готов посмотреть

PHP-Дайджест № 110 – свежие новости, материалы и инструменты (28 мая – 11 июня 2017)

А я не говорил, что это определение. Это одно из следствий со стороны обсуджаемого вопроса.

Если вы хотите строго по определению, то пожалуйста. Представьте, что у вас есть тип T с методом T::f(A $a). И есть тип S extends T с методом, который отличается только отсутствием тайпхинта S::f($a).

Если сам код методов идентичен, то если свойство q(T x) верно, то и свойство q(S y) тоже будет верным

Таким образом исключение тайпхинта не нарушает LSP, а текущее поведение (фатал парсера) — нарушает. Что подтверждает мое утверждение

ведет к частично более полному соблюдению LSP

PHP-Дайджест № 110 – свежие новости, материалы и инструменты (28 мая – 11 июня 2017)

Как раз таки этот «вброс» ведет к частично более полному соблюдению LSP, в этом и суть.

Если кратко, то LSP состоит в том, что множество допустимых входных параметров вы можете только расширять, а множество возможных выходных параметров вы можете только сужать.

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

PHP-Дайджест № 109 – свежие новости, материалы и инструменты (14 – 28 мая 2017)

Там основная проблема в том, что HHVM перестал быть совместим даже с композером

тык
тык

Сети Петри с Symfony а-ля WorkFlow компонент

Нашел, действительно, спасибо

Сети Петри с Symfony а-ля WorkFlow компонент

+ Визуализация
+ Guads (3.3)

2.2. Граф можно задавать в конфиге, а не в коде


Вот чего я не могу понять — а можно ли хранить граф НЕ в коде. Если можно, то тогда можно будет делать крутые штуки для бизнес-процессов, а-ля workflows в JIRA

Сети Петри с Symfony а-ля WorkFlow компонент

Ну, возможно, потому, что finite state machine является частным случаем сетей Петри (по крайней мере если судить по енвики)

Опрос. Какой php-фреймворк вы используете?

Не воспринимаю Yii как серьезный фреймворк с тех пор как осознал, что у них все встроенные вещи построены на обязательных паблик полях. В лучшем случае на protected, в случае с AR. Вкупе со статикой люди начинают делать из этого АД. во второй версии все то же самое.

Symfony Flex, как будет выглядеть ваше приложение с Symfony 4

Аналогично. Первая мысль, которая придет мне в голову, если я начну клепать сайты на симфони раз в неделю — это сделать свой отдельный пакет и разворачивать его через create-project

Symfony Flex, как будет выглядеть ваше приложение с Symfony 4

Я подозреваю, что процесс установки сведут к

composer require --dev vendor/dev-depdency
composer require vendor/depdency


Скорей всего ядро будет ориентироваться только на прямые зависимости. Автоконфигурация будет производиться тоже за счет наличия явно подключенного пакета.

Например есть компонент symfony/form. При его наличии в секции require будет происходить установка ключа framework.forms в положение ~. Аналогично, если установлен метапакет, замещающий symfony/form (например, symfony/symfony)

Это уже реализовано в 3.3-dev. Аналогично можно поступать с другими пакетами. Бандлам, я полагаю, будет предложено иметь «дефолтную конфигурацию» и\или иметь стандартные точки расширения, например какой нибудь symfony/security-bundle с помощью symfony/doctrine-bridge может найти единственную сущность, имплементирующую UserInterface и автоматически подключить в качестве провайдера пользовательских аккаунтов. Zero-configuration.

Фантазировать можно много, идея в целом годная. Остается только ждать )

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность