Не буду оспаривать фичу одновременного коммита в несколько репозиториев, которая имхо довольно рисковая даже если есть хорошие тесты, но вообще-то у composer есть рекомендуемая схема для вложенных пакетов
Разница в том, что при любых настройках второй вариант будет давать свежее состояние вложенного проекта, а первый вариант может сбрасывать состояние при запуске команды composer update
Кроме того для git-хабов (github, gitlab, bitbucket и т.п.) есть другая рекомендуемая схема подключения кастомных репозиториев
в этом случае работа идет через ssh и настройки подключения определяются на уровне пользователя а не конкретного проекта. Например, на винде при подлючении пакета через https будет проверяться отдельная схема авторизации в git-хабе
ну и совсем мелочь, для composer есть парочка интересных плагинов, которые, кажется, не очень хорошо работают… однако предназначены для чего-то подобного, если под многомодульностью понимать аналог многомодульности из gradle а не, что в случае композера называется зависимость
Ну это смотря какое приложение. Более того, я еще раз подчеркну, что это лишь один пример, который говорит про то, что по крайней мере в тех обстоятельствах пришлось стандартное поведение какого-то компонента изменить, чтобы удовлетворить требованиям так скажем протокола с конкретным заказчиком.
Скорее логики представления. Вы же конвертируете там представление данных а не бизнес логикой занимаетесь
Логика представления специфична для клиента, который присылает данные, а не для протокола, которым клиент пользуется. Причем это один из с пару десятков вариантов специфичности десериализации. Этот код нельзя будет применить для другого клиента. Так что я думаю, что это именно бизнес-логика. Возможно я не прав.
То есть под сегментированием логики вы подразумеваете случаи когда логика вытекает наружу? Ну мол нарушение инкапсуляции, закона Деметры, open/close и srp?
Если говорить известными терминами, то да. Оно самое.
в чем это выражается?
Это когда ты смотришь на исходники и понимаешь, можно бы было обойтись меньшим количеством байт ))
Опять же, мне сложно представить себе подобное разделение ответственности усложняет код. Было бы все же интересно хотя бы приблизительно разобрать ваш случай.
Наверное, лучше привести в пример то, как обычно проходит code review. Обычно приходит набор файлов с диффом, из которого довольно сложно понять как точечные изменения позволяют решить поставленную задачу. Конечно, бывают и другие, где понятно, что и почему изменено и почему этот дифф оптимально решает задачу. Но таких PR мало. Увы.
Поэтому мне лично очень интересно как нужно проектировать систему, которая на достаточно большой перспективе позволяет хорошо организовывать бизнес-логику. И было бы очень круто, если подход не будет требовать писать тонны бойлерплейта.
Я имею в виду ситуацию, когда у нас есть, например, шина событий и, как это часто бывает, задачи, которые надо сделать вчера.
Но начать лучше с начала:
Разберу пример с обновлением какой-то сущности, потому что чтение не так наглядно, хотя и там бывают приколюхи.
Вначале не было ничего
Спроектировали идеальную систему с достаточным потенциалом к расширению с учетом всех изначальных требований, где запросы пользователя обрабатываются четко и ровно в том домене, где следует.
роутинг, десериализаци, валидация, если нужно, выборка нужной сущности — POST без выборки или PUT/PATCH для обновления, сохранение, выдача результата — редирект на другой роут или просто страница со статусом выполненного запроса, или сериализация ответа в случае API
Потом приходят требования, которые можно быстро внедрить, например, прям на уровне (де)сериализации. В моей практике это было требование воспринимать строки true\false\0\1 как bool. Это часть бизнес-логики, потому что отправляющая сторона уже написана и формирует запросы именно так. Другой пример, после сохранения новой сущности нужно тригерить обновление чего-то другого в системе. это очень просто делается добавлением еще одного события и эксклюзивного подписчика оного.
В этих двух простых примерах бизнес-логика после внесения изменений теперь находится в двух частях и сходу не видно как без серьезного переписывания не сегментировать (логику). Вероятно, нужно держать разный набор схемы данных для разных слоёв — (де)сериализация, контроллер, дополнительные обработчики — и получится что-то типа middleware, но, кажется, что 1) код распухает и 2) система становится переусложненной со всеми вытекающими последствиями
P.S.: прошу прощения за не очень спешный ответ.
P.S.: Опыт проектирования у меня чуть более чем нулевой, поэтому я не стал приводить несколько разных примеров архитектуры, но, кажется, одного будет достаточно
Кажется, ни один из известных, по крайней мере из популярных, подходов проектирования не рассматривает задачу избежание сегментации бизнес-логики. Причем это про разные стэки верно.
Статья, содержащая в себе фразы типа "нативное наследование", изначально настраивает на недоверие.
Вмешиваться в иерархию типов кажется очень сомнительной идеей. Более того, определение кто кого расширяет противоречит идее использования интерфейсов. как самих по себе так и в составе SOLID.
Не являюсь большим знатоком ворпресса, но коль уж система имеет вполне определенное назначение, что упрекать её в ограниченном наборе хуков, наверное, неуместно.
минусы использования DI надуманные. Его (DI) в хороших реализация работа заканчивается на этапе компиляции зависимостей. А также под DI стилем имеется в виду что? Конфиги? или код? Если конфиги, то тут объяснение простое — явное указание зависимостей — это хорошая практика. Да, часто разработчики испытывают соблазн использовать магию в виде автовайринга но мы же знаем, что явное лучше неявного. Если код, то как правило нет никакого стиля, это просто обычные конструкторы, сеттеры или публичные методы с определенными сигнатурами. Это обычные пользовательские типы и DI тут просто как потребитель а не "требователь" архитектуры.
Кстати да. на этот случай же уже есть секция bin (копирование все этих скриптов из пакета в проектный bin) к композере. если я ничего не путаю, к этому делу можно добавить условно безопасный запуск всего, что есть в проектном бине и будет уже что-то с чем можно работать. не надо перехреначивать конкретный фреймворк… на самом деле надо, конечно, но по другой причине 8)
как попытка упростить работу с symfony приложениям имеют опосредованное отношение, редкий бандл заставляет наследоваться от изкоробочных компонент\сервисов. Как правило, можно всё завернуть в нужный алиас или не очень геморно перегрузить
Конечно же, если обсуждать этот принцип сам по себе, то его достоинства и минусы очевидны и сейчас, имхо, он более уместен, чем, например, лет 5-10 назад.
Сдаётся мне, что все фреймворки (соответствующие ообщества), которые в той или иной степени используют symfony-компоненты, должны разработать PSR для для публикации и подключения компонентов, на основе которых можно будет пилить как базовые скрипты (в композере или в конкретном фреймворке), так и кастомные (в конкретном проекте). Тогда можно будет говорить о реальном упрощении всей этой катавасии с подключением\отключением
А еще вот мне например до сих пор не открылся баланс между упрощением инсталляции (вшитое дефолтное поведение) и наглядностью (инструкция по подключения). Очевидно, что полностью из коробки процесс инсталляции как и подробная но самостоятельная возня в среднем не подходят для всех участников\пользователей.
У Symfony достаточно громоздкий процесс установки внешних бандлов
Упущен довольно важный кусок из истории возникновения composer-а
Fun fact: Composer started as a conversation about how to generically install bundles/plugins/extensions for Symfony and phpBB.
WTF fact: Neither Symfony nor phpBB uses Composer as a way to install its bundles/plugins/extensions.
Я думаю, что вы еще просто не сталкивались с ситуациями, когда задачу надо решить минимальными средствами. в том числе с минимумом сторонних зависимостей.
Да, в баше много чего нет. Мне, например, для удобства пришлось самому реализовать передачу внутрь функций и обратно из функций массивов. Точнее, закостылить (порядка 30 строк на всё), но это точно лучше, чем тянуть десятки и то и сотни мегабайт для подобного готового в питоне или чем-то еще более монструозном.
имхо, от тэгов как правило все только усугубляется. по крайней мере это все сложно использовать если не заворачивать в зонтичные скрипты\бинари\пакетные_операции.
Сам по себе ансибл — очень крутая штука. просто кривая обучения слегка недружелюбна )))
Да, вот только у ансиблса задачи сильно фрагментированы обычно, а плейбуки — что-то типа монолита, причем по несколько штук на разные случаю
Во-вторых, не знаю как вторая версия ансибла, но первая была почти всегда чуть менее чем стабильно. дебажить и подгадывать какие таски или плейбуки запилить… то еще удовольствие.
Правда, всё выше сказанное, не про замену сабжа этого поста на ансибл, а просто про ансибл.
Смотря что под асинхронностью понимать
есть например такое https://wiki.php.net/rfc/fiber
Митап SymCode вынужденно перенесен на 13 марта да и то пока еще не 100% что получится
Увы, сложно с докладчиками пока что ...
Хотел оценить
Drift PHP Frameworkно сайт https://driftphp.com недоступенНе буду оспаривать фичу одновременного коммита в несколько репозиториев, которая имхо довольно рисковая даже если есть хорошие тесты, но вообще-то у composer есть рекомендуемая схема для вложенных пакетов
Вместо
Использовать
Разница в том, что при любых настройках второй вариант будет давать свежее состояние вложенного проекта, а первый вариант может сбрасывать состояние при запуске команды composer update
Кроме того для git-хабов (github, gitlab, bitbucket и т.п.) есть другая рекомендуемая схема подключения кастомных репозиториев
в этом случае работа идет через ssh и настройки подключения определяются на уровне пользователя а не конкретного проекта. Например, на винде при подлючении пакета через https будет проверяться отдельная схема авторизации в git-хабе
ну и совсем мелочь, для composer есть парочка интересных плагинов, которые, кажется, не очень хорошо работают… однако предназначены для чего-то подобного, если под многомодульностью понимать аналог многомодульности из gradle а не, что в случае композера называется зависимость
Ну это смотря какое приложение. Более того, я еще раз подчеркну, что это лишь один пример, который говорит про то, что по крайней мере в тех обстоятельствах пришлось стандартное поведение какого-то компонента изменить, чтобы удовлетворить требованиям так скажем протокола с конкретным заказчиком.
Логика представления специфична для клиента, который присылает данные, а не для протокола, которым клиент пользуется. Причем это один из с пару десятков вариантов специфичности десериализации. Этот код нельзя будет применить для другого клиента. Так что я думаю, что это именно бизнес-логика. Возможно я не прав.
Если говорить известными терминами, то да. Оно самое.
Это когда ты смотришь на исходники и понимаешь, можно бы было обойтись меньшим количеством байт ))
Наверное, лучше привести в пример то, как обычно проходит code review. Обычно приходит набор файлов с диффом, из которого довольно сложно понять как точечные изменения позволяют решить поставленную задачу. Конечно, бывают и другие, где понятно, что и почему изменено и почему этот дифф оптимально решает задачу. Но таких PR мало. Увы.
Поэтому мне лично очень интересно как нужно проектировать систему, которая на достаточно большой перспективе позволяет хорошо организовывать бизнес-логику. И было бы очень круто, если подход не будет требовать писать тонны бойлерплейта.
Я имею в виду ситуацию, когда у нас есть, например, шина событий и, как это часто бывает, задачи, которые надо сделать вчера.
Но начать лучше с начала:
Разберу пример с обновлением какой-то сущности, потому что чтение не так наглядно, хотя и там бывают приколюхи.
Потом приходят требования, которые можно быстро внедрить, например, прям на уровне (де)сериализации. В моей практике это было требование воспринимать строки true\false\0\1 как bool. Это часть бизнес-логики, потому что отправляющая сторона уже написана и формирует запросы именно так. Другой пример, после сохранения новой сущности нужно тригерить обновление чего-то другого в системе. это очень просто делается добавлением еще одного события и эксклюзивного подписчика оного.
В этих двух простых примерах бизнес-логика после внесения изменений теперь находится в двух частях и сходу не видно как без серьезного переписывания не сегментировать (логику). Вероятно, нужно держать разный набор схемы данных для разных слоёв — (де)сериализация, контроллер, дополнительные обработчики — и получится что-то типа middleware, но, кажется, что 1) код распухает и 2) система становится переусложненной со всеми вытекающими последствиями
P.S.: прошу прощения за не очень спешный ответ.
P.S.: Опыт проектирования у меня чуть более чем нулевой, поэтому я не стал приводить несколько разных примеров архитектуры, но, кажется, одного будет достаточно
Кажется, ни один из известных, по крайней мере из популярных, подходов проектирования не рассматривает задачу избежание сегментации бизнес-логики. Причем это про разные стэки верно.
Статья, содержащая в себе фразы типа "нативное наследование", изначально настраивает на недоверие.
Это навскидку.
Кстати да. на этот случай же уже есть секция bin (копирование все этих скриптов из пакета в проектный bin) к композере. если я ничего не путаю, к этому делу можно добавить условно безопасный запуск всего, что есть в проектном бине и будет уже что-то с чем можно работать. не надо перехреначивать конкретный фреймворк… на самом деле надо, конечно, но по другой причине 8)
имхо
как попытка упростить работу с symfony приложениям имеют опосредованное отношение, редкий бандл заставляет наследоваться от изкоробочных компонент\сервисов. Как правило, можно всё завернуть в нужный алиас или не очень геморно перегрузить
Конечно же, если обсуждать этот принцип сам по себе, то его достоинства и минусы очевидны и сейчас, имхо, он более уместен, чем, например, лет 5-10 назад.
Сдаётся мне, что все фреймворки (соответствующие ообщества), которые в той или иной степени используют symfony-компоненты, должны разработать PSR для для публикации и подключения компонентов, на основе которых можно будет пилить как базовые скрипты (в композере или в конкретном фреймворке), так и кастомные (в конкретном проекте). Тогда можно будет говорить о реальном упрощении всей этой катавасии с подключением\отключением
А еще вот мне например до сих пор не открылся баланс между упрощением инсталляции (вшитое дефолтное поведение) и наглядностью (инструкция по подключения). Очевидно, что полностью из коробки процесс инсталляции как и подробная но самостоятельная возня в среднем не подходят для всех участников\пользователей.
В этой части
Кармы не хватает за этот камент вручить жирный плюс
Я думаю, что вы еще просто не сталкивались с ситуациями, когда задачу надо решить минимальными средствами. в том числе с минимумом сторонних зависимостей.
Да, в баше много чего нет. Мне, например, для удобства пришлось самому реализовать передачу внутрь функций и обратно из функций массивов. Точнее, закостылить (порядка 30 строк на всё), но это точно лучше, чем тянуть десятки и то и сотни мегабайт для подобного готового в питоне или чем-то еще более монструозном.
По состоянию на версию докера 1.12.2 вместо команды
надо использовать
Интересно, зачем нужно davidrjonas/composer-lock-diff если есть composer update (-vvv) --dry-run из коробки ?
Причем это более безопасный способ увидеть, что обновится\обновилось
Очевидно, что не хватает typehint-ов
имхо, от тэгов как правило все только усугубляется. по крайней мере это все сложно использовать если не заворачивать в зонтичные скрипты\бинари\пакетные_операции.
Сам по себе ансибл — очень крутая штука. просто кривая обучения слегка недружелюбна )))
Да, вот только у ансиблса задачи сильно фрагментированы обычно, а плейбуки — что-то типа монолита, причем по несколько штук на разные случаю
Во-вторых, не знаю как вторая версия ансибла, но первая была почти всегда чуть менее чем стабильно. дебажить и подгадывать какие таски или плейбуки запилить… то еще удовольствие.
Правда, всё выше сказанное, не про замену сабжа этого поста на ансибл, а просто про ансибл.