Обычно я так и делаю. Один пакет чистый без зависимостей, а второй bundle для Symfony с конфигами и всеми делами.
Хочешь юзать в Symfony ставь бандл. Если у тебя не Symfony, юзай чистый пакет.
Я сейчас перевожу один проект на PHP 7. Одн из пакетов оказался не совместим с PHP 7.
Так как проект заброшен, я просто взял и заменил его на другой. Переписал пару адаптеров и все.
Ну ещё немножко смазал маслицем чтоб лучше зашёл
Очевидно же, что в библиотеке require желательно оставить пустым, а в require-dev пишем, что хотим, так как эти пакеты используются только для разработки и тестирования и к клиенту они не попадут.
В проекте же, в require, можно вообще любые зависимости держать. За них отвечает команда разработчиков.
Проблема совмещения не совместимых пакетов мне вообще не понятна.
Зачем пытаться совместить несовместимое?
Если пакеты не совместимы, то просто не используйте их или выберете совместимую версию. В крайнем случае, всегда можно выбрать конкретный коммит в пакете. Да, выбрать конкретную версию зависимости у зависимости тоже можно.
А если хочется использовать фичу из последней версии пакета, которая не совместима с другими пакетами, то просто не используйте эту фичу. Подождите пока исправят совместить или сделайте PR.
Не стоит гнаться за последними релизами.
Мне бывает приходится использовать фиксированную версию пакетов, но только потому, что разработки ломают обратную совместимость.
Решение vendor in vendor мне видится странным и наверняка добавит проблем.
JS это штатные средства, а решение кросбраузерное и всего в несколько строк кода.
В любом случае нужно на чем-то описать бизнес логику, а js, кроме всего прочего, позволяет проверить не заблокирована ли ссылка на которую будем делать редирект.
Ну почему же нельзя куки передавать. Можно. Ходы надо знать.
Думаете как SSO работает?
Просто придется переадресацию делать через js, а не через nginx.
А по хорошему куку передавать и не надо.
Один раз переадресовали и поставили куку на домен.
Если куки нет то запускаем ещё раз процедуру переадресацией.
Если добавить к этому несколько доменов второго уровня, то получится неплохая защита для распространения нелегального контента.
Собственно вирусы так и распространяются.
Пожалуй да. Можно подумать, что компоненты лежащие на одной грани не могут взаимодействовать с компонентами на другой грани, но на схеме нет явного разделения, что может привести к неоднозначному восприятию архитектуры.
Я сторонник "Явное лучше не явного" и слоистая архитектура на мой взгляд более явно демонстрирует разделение компонентов на слои.
Действительно, эти архитектуры во многом схожи, хотя разница в деталях.
Например здесь неплохой разбор Clean Architecture и представление ее в слоистой схеме.
Мне лично, не нравится этот способ представления. Как подметил автор:
Однако, можно заметить, что UI и Data Access компоненты расположены в одном слое
Кампоненты расположенные в одном слое должны иметь полный доступ друг к другу.
То есть UI имеет полное право обращаться к Data Access, что не правильно само по себе. И ни одна из схем не противоречит этому.
Понятно, что авторы подразумевали нечто другое, но это савсем не очевидно из схемы.
А вот схема слоистой архитектуры достаточно наглядно даёт понять невозможность взаимодействия UI и Data Access компонентов.
У меня похожая проблема, но ещё хуже.
Я без понятия как монетизировать проект.
У меня полно конкурентов которые предоставляют похожие услуги бесплатно.
И аудитория в общем не готовая платить.
Мой опыт говорит, что Windows это не прихоть, а необходимость.
В некоторых компаниях, политика компании разрешает только Windows. Не разрешает виртуалки и вторую ось. А локального админа, чтоб хотя бы hosts править, приходится вымаливать через руководство.
И не подумайте, что компании плохие, просто админам так проще, когда у них несколько сотен компов, а разрабов, которым нужны никсы, всего десяток или два.
С той же проблемой сталкиваются дизайнеры на маках.
Решений проблемы много.
В одной из компаний мне не давали локального админа. Я плюнул и притащил свой ноутбук с ubuntu. Тоже решение.
А по подробней можно?
Мне с ходу в голову приходит только ограничение доступа к файлам и отслеживание начала скачивания/проигрывания видео.
Отслеживание проигрывания лучшие делать через плеер. Больше возможностей и контроля.
Как резерв конечно можно сделать отслеживание скачивания на сервере.
Я приятно удивлен увидеть статью про яхтинг на Хабре.
Добавлю пару комментариев.
Согласование терминологии
В яхтинге единые правила и терминология МППСС. Единственное что в мировых водах используется английская терминология, а в Российских внутренних водах русская терминология.
У меня с этим были затыки так как большая часть опыта именно во внутренних водах. Но это просто слова, суть одна и та же.
Расходы на топливо, по мнению нового капитана, должны были дополнительно оплачиваться экипажем, хотя владелец говорил о других условиях. Сумма за счет многочисленности экипажа вышла небольшая, около 20 евро.
Когда у меня был переход по Атлантике 1200 мм, мы за свой счёт залили полный бак, все канистры что были и я ещё уговаривал капитана купить дополнительных канистр и взять с собой топлива побольше, потому что это серьезный переход и свою жизнь я ценю больше.
В последствии, мы сильно жалели, что взяли мало топлива так как у нас вместо обещанных 40 узлов попутного ветра всю дорогу был штиль и топлива до берега не хватило.
Это море. Нужно всегда ориентироваться на самое худшее.
Правда, он ограничился только самыми необходимыми вопросами — сколько яхтенного опыта
По большому счету это все что нужно.
Также желательно заранее узнать у команды об их аллергии, болезнях, списке лекарств, их применении и местоположении. Если у кого-то на борту неожиданно случится приступ, это будет очень не хорошо.
Описывать свои достижения капитан не обязан. Авторитет капитана неоспорим. Это на берегу вы можете сказать, а на воде ваша жизнь зависит от капитана. Если капитан сказал прыгать за борт, матрос должен тут же исполнять команду.
«дойти до точки В» и «стараться не повредить яхту» — существенно отличающиеся цели
Почему отличающиеся? Это напрямую связанные цели. На поврежденной лодке вы можете не дойти до точки В и обратное тоже верно.
Первоочередная цель в любом яхтенном переходе это дойти из точки А в точку Б. Желательная цель дойти целыми, но мы помним что жизнь человека ценнее лодки.
Я не знаю какая у вас была ситуация и что вы называете при свежем ветре. Если была отдана такая команда, то на это, я думаю, были причины.
Как уже говорил ранее, команды капитана не обсуждаются.
посуду мыли только при помощи ручной помпы
При наличии ручной помпы, очевидно что пользоваться нужно только ей. Этого не знают только те кто никогда не имел дела с ней.
Это не критика. Я тоже на эти грабли наступал.
капитан не проинструктировал экипаж и вахту о необходимом оповещении его в этой ситуации
Ну это просто смешно.
При любой внештатной ситуации нужно поднимать капитана, даже если он уснул 10 мин назад.
Это ваш косяк, а не капитана.
команды вроде «Уберитесь на камбузе», «Отдайте кормовые»
Ну, мы всё же не в армии.
Команды вроде "Ты идёшь убираться на камбузе" и "Ты встаешь на левый кормовой" четки, понятны, эффективны и особенно важны в интернациональных командах. Но иногда хорошо бы дать право выбора.
В моей практике не редко звучат команды "Подготовится к швартовке" и "Кто на кормовых?".
Подитожу
На мой взгляд, яхтинг больше похож на армию, чем на классический менеджмент. Матрос который ни чем не занят, плохой матрос.
Соглашусь. Если какое-то действие в сущности одного контекста должно стригерить действие в сущности другого контекста, то конечно логично делать это через доменные события.
У меня подобное подвешено на события от заказа, в частности когда заказ становится оплаченным.
Если событие обрабатывается в сущности заказа, как в моей библиотеке, то все гуд. Я это и предлагал.
А вот если вы начисляете бонусы за оплаченный заказ в отдельном сервисе слушателе, то это не есть хорошо. Это пример размазывания бизнес логики по проекту, что часто встречается при использовании событийно-ориентированного подхода.
Скорей: начисление бонусов рефералу за создание заказа.
Пересчет делается в сущности реферала, а вот инициировать процедуру начисления бонусов можно через заказ.
Согласен с Fesor. Очень трудно говорить не зная особенностей бизнеса.
Например мне не понятно почему вы не можете пересчитывать бонусные баллы реферала дважды?
Они пересчитываются по разным событиям и количество начисляемых баллов может, а скорей всего и будет, различаться. Также хорошо бы сохранить в истории начисления баллов за что их начисляли каждый раз. То есть опять же нужно сохранять их раздельно.
По идее, вам надо по каждому событию от заказа пересчитывать баллы рефералов и генерить событие обновления счета, их агрегировать и отправлять рефералу уведомление с подробным отчётом за что и сколько он получил баллов.
Обычно я так и делаю. Один пакет чистый без зависимостей, а второй bundle для Symfony с конфигами и всеми делами.
Хочешь юзать в Symfony ставь бандл. Если у тебя не Symfony, юзай чистый пакет.
Я сейчас перевожу один проект на PHP 7. Одн из пакетов оказался не совместим с PHP 7.
Так как проект заброшен, я просто взял и заменил его на другой. Переписал пару адаптеров и все.
Ну ещё немножко смазал маслицем чтоб лучше зашёл
Я видимо что-то не понимаю.
Очевидно же, что в библиотеке
requireжелательно оставить пустым, а вrequire-devпишем, что хотим, так как эти пакеты используются только для разработки и тестирования и к клиенту они не попадут.В проекте же, в
require, можно вообще любые зависимости держать. За них отвечает команда разработчиков.Проблема совмещения не совместимых пакетов мне вообще не понятна.
Зачем пытаться совместить несовместимое?
Если пакеты не совместимы, то просто не используйте их или выберете совместимую версию. В крайнем случае, всегда можно выбрать конкретный коммит в пакете. Да, выбрать конкретную версию зависимости у зависимости тоже можно.
А если хочется использовать фичу из последней версии пакета, которая не совместима с другими пакетами, то просто не используйте эту фичу. Подождите пока исправят совместить или сделайте PR.
Не стоит гнаться за последними релизами.
Мне бывает приходится использовать фиксированную версию пакетов, но только потому, что разработки ломают обратную совместимость.
Решение vendor in vendor мне видится странным и наверняка добавит проблем.
JS это штатные средства, а решение кросбраузерное и всего в несколько строк кода.
В любом случае нужно на чем-то описать бизнес логику, а js, кроме всего прочего, позволяет проверить не заблокирована ли ссылка на которую будем делать редирект.
PS: блокировать ссылки могут ещё антивирусы
Ну почему же нельзя куки передавать. Можно. Ходы надо знать.
Думаете как SSO работает?
Просто придется переадресацию делать через js, а не через nginx.
А по хорошему куку передавать и не надо.
Один раз переадресовали и поставили куку на домен.
Если куки нет то запускаем ещё раз процедуру переадресацией.
Если добавить к этому несколько доменов второго уровня, то получится неплохая защита для распространения нелегального контента.
Собственно вирусы так и распространяются.
Пожалуй да. Можно подумать, что компоненты лежащие на одной грани не могут взаимодействовать с компонентами на другой грани, но на схеме нет явного разделения, что может привести к неоднозначному восприятию архитектуры.
Я сторонник "Явное лучше не явного" и слоистая архитектура на мой взгляд более явно демонстрирует разделение компонентов на слои.
Действительно, эти архитектуры во многом схожи, хотя разница в деталях.
Например здесь неплохой разбор Clean Architecture и представление ее в слоистой схеме.
Мне лично, не нравится этот способ представления. Как подметил автор:
Кампоненты расположенные в одном слое должны иметь полный доступ друг к другу.
То есть UI имеет полное право обращаться к Data Access, что не правильно само по себе. И ни одна из схем не противоречит этому.
Понятно, что авторы подразумевали нечто другое, но это савсем не очевидно из схемы.
А вот схема слоистой архитектуры достаточно наглядно даёт понять невозможность взаимодействия UI и Data Access компонентов.
У меня похожая проблема, но ещё хуже.
Я без понятия как монетизировать проект.
У меня полно конкурентов которые предоставляют похожие услуги бесплатно.
И аудитория в общем не готовая платить.
Мой опыт говорит, что Windows это не прихоть, а необходимость.
В некоторых компаниях, политика компании разрешает только Windows. Не разрешает виртуалки и вторую ось. А локального админа, чтоб хотя бы hosts править, приходится вымаливать через руководство.
И не подумайте, что компании плохие, просто админам так проще, когда у них несколько сотен компов, а разрабов, которым нужны никсы, всего десяток или два.
С той же проблемой сталкиваются дизайнеры на маках.
Решений проблемы много.
В одной из компаний мне не давали локального админа. Я плюнул и притащил свой ноутбук с ubuntu. Тоже решение.
Ну вот как бы да. Зачем php если все прекрасно разруливается через nginx?
Профит какой?
А по подробней можно?
Мне с ходу в голову приходит только ограничение доступа к файлам и отслеживание начала скачивания/проигрывания видео.
Отслеживание проигрывания лучшие делать через плеер. Больше возможностей и контроля.
Как резерв конечно можно сделать отслеживание скачивания на сервере.
У меня только один вопрос.
Зачем стримить видео через php?
Чем не угодил nginx?
Я приятно удивлен увидеть статью про яхтинг на Хабре.
Добавлю пару комментариев.
В яхтинге единые правила и терминология МППСС. Единственное что в мировых водах используется английская терминология, а в Российских внутренних водах русская терминология.
У меня с этим были затыки так как большая часть опыта именно во внутренних водах. Но это просто слова, суть одна и та же.
Когда у меня был переход по Атлантике 1200 мм, мы за свой счёт залили полный бак, все канистры что были и я ещё уговаривал капитана купить дополнительных канистр и взять с собой топлива побольше, потому что это серьезный переход и свою жизнь я ценю больше.
В последствии, мы сильно жалели, что взяли мало топлива так как у нас вместо обещанных 40 узлов попутного ветра всю дорогу был штиль и топлива до берега не хватило.
Это море. Нужно всегда ориентироваться на самое худшее.
По большому счету это все что нужно.
Также желательно заранее узнать у команды об их аллергии, болезнях, списке лекарств, их применении и местоположении. Если у кого-то на борту неожиданно случится приступ, это будет очень не хорошо.
Описывать свои достижения капитан не обязан. Авторитет капитана неоспорим. Это на берегу вы можете сказать, а на воде ваша жизнь зависит от капитана.
Если капитан сказал прыгать за борт, матрос должен тут же исполнять команду.
Почему отличающиеся? Это напрямую связанные цели. На поврежденной лодке вы можете не дойти до точки В и обратное тоже верно.
Первоочередная цель в любом яхтенном переходе это дойти из точки А в точку Б. Желательная цель дойти целыми, но мы помним что жизнь человека ценнее лодки.
Я не знаю какая у вас была ситуация и что вы называете при свежем ветре. Если была отдана такая команда, то на это, я думаю, были причины.
Как уже говорил ранее, команды капитана не обсуждаются.
При наличии ручной помпы, очевидно что пользоваться нужно только ей. Этого не знают только те кто никогда не имел дела с ней.
Это не критика. Я тоже на эти грабли наступал.
Ну это просто смешно.
При любой внештатной ситуации нужно поднимать капитана, даже если он уснул 10 мин назад.
Это ваш косяк, а не капитана.
Ну, мы всё же не в армии.
Команды вроде "Ты идёшь убираться на камбузе" и "Ты встаешь на левый кормовой" четки, понятны, эффективны и особенно важны в интернациональных командах. Но иногда хорошо бы дать право выбора.
В моей практике не редко звучат команды "Подготовится к швартовке" и "Кто на кормовых?".
Подитожу
На мой взгляд, яхтинг больше похож на армию, чем на классический менеджмент.
Матрос который ни чем не занят, плохой матрос.
Зря вы так. Мне вот интересно было что вы изобрели.
Хоть бы ссылку на гитхаб кинули.
если что, кроме
kernel.terminateесть ещеconsole.terminate(пруф)Соглашусь. Если какое-то действие в сущности одного контекста должно стригерить действие в сущности другого контекста, то конечно логично делать это через доменные события.
Если событие обрабатывается в сущности заказа, как в моей библиотеке, то все гуд. Я это и предлагал.
А вот если вы начисляете бонусы за оплаченный заказ в отдельном сервисе слушателе, то это не есть хорошо. Это пример размазывания бизнес логики по проекту, что часто встречается при использовании событийно-ориентированного подхода.
Скорей: начисление бонусов рефералу за создание заказа.
Пересчет делается в сущности реферала, а вот инициировать процедуру начисления бонусов можно через заказ.
Согласен с Fesor. Очень трудно говорить не зная особенностей бизнеса.
Например мне не понятно почему вы не можете пересчитывать бонусные баллы реферала дважды?
Они пересчитываются по разным событиям и количество начисляемых баллов может, а скорей всего и будет, различаться. Также хорошо бы сохранить в истории начисления баллов за что их начисляли каждый раз. То есть опять же нужно сохранять их раздельно.
По идее, вам надо по каждому событию от заказа пересчитывать баллы рефералов и генерить событие обновления счета, их агрегировать и отправлять рефералу уведомление с подробным отчётом за что и сколько он получил баллов.