для тестов аще топчик штука)

для тестов аще топчик штука)

Для типизированных колбэков ещё

для тестов аще топчик штука)

типа фейк какой-нибудь запилить?

Для типизированных колбэков ещё

ну тоже как вариант, да

типа фейк какой-нибудь запилить?

ну у меня это подкласс ивента - тестирую листенер

prophecy, блин, не обновляют никак...

Ребятя есть HTML5 формы с помощью JS вытащил из них данные и записал в переменные как мне эти переменные записать в php а потом в Json?

Ребятя есть HTML5 формы с помощью JS вытащил из них данные и записал в переменные как мне эти переменные записать в php а потом в Json?

Про сабмит формы слышал?

или про ajax

давай сюда лучше @phpGeeksJunior

Кто-то пользовался виртуальными серваками на ARMv8?

Кто-то пользовался виртуальными серваками на ARMv8?

один раз надо было подешевле машинку взять, а что?

и как совместимость с железом?

один раз надо было подешевле машинку взять, а что?

Машинка нужна под tor, rabbitmq, redis, mysql (pgsql), php, nginx... симфа будет жить там...

вот думаю, лучше меньше ядер, но x86_64, или больше ядер ARM?

вот думаю, лучше меньше ядер, но x86_64, или больше ядер ARM?

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

вот думаю, лучше меньше ядер, но x86_64, или больше ядер ARM?

Больше ядер это 2 vs 4?

Или 4 vs 16?

Или 4 vs 16?

2 vs 6

Всем доборого дня. Я тут ломаю голову над хорошим решением. Пожалуйста, если у кого-то есть идеи — подскажите. В приложеии есть сервис-нотификатор, который шлет уведомления. Есть две имплементации, по смс и по пушам. При этом нужно, чтобы клиенту уведомления шли по смс, а продавцу через пуш. Как лучше такое организовать? Сейчас так, но, мне кажется, это какой-то больной путь: customer_notificator: class: App\Service\Notificator\SmsNotificator public: true seller_notificator: class: App\Service\Notificator\PushNotificator public: true

Ребзя, такой вопрос по поводу логирования. Настолько здравая идея выплевывать логи через echo/в stdout. А потом собирать это все и сливать куда то на анализ/хранение ?

Всем доборого дня. Я тут ломаю голову над хорошим решением. Пожалуйста, если у кого-то есть идеи — подскажите. В приложеии есть сервис-нотификатор, который шлет уведомления. Есть две имплементации, по смс и по пушам. При этом нужно, чтобы клиенту уведомления шли по смс, а продавцу через пуш. Как лучше такое организовать? Сейчас так, но, мне кажется, это какой-то больной путь: customer_notificator: class: App\Service\Notificator\SmsNotificator public: true seller_notificator: class: App\Service\Notificator\PushNotificator public: true

Паттерн стратегия.

Ребзя, такой вопрос по поводу логирования. Настолько здравая идея выплевывать логи через echo/в stdout. А потом собирать это все и сливать куда то на анализ/хранение ?

https://12factor.net/logs

Паттерн стратегия.

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

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

тебе ? Ну все просто. описываешь интерфейс нотификации. делаешь 2 имплементации. затем кому нужно подсовываешь нужную имплементацию.

тебе ? Ну все просто. описываешь интерфейс нотификации. делаешь 2 имплементации. затем кому нужно подсовываешь нужную имплементацию.

Вот сейчас так и есть. Но какая мне нужна имплементация, я могу узнать только в месте где отправляю. Чем тогда стратегия будет лучше нынешнего решения?

тебе ? Ну все просто. описываешь интерфейс нотификации. делаешь 2 имплементации. затем кому нужно подсовываешь нужную имплементацию.

Не сообщение в чате. ) Сообщение в нотификаторе моем.

Всем доборого дня. Я тут ломаю голову над хорошим решением. Пожалуйста, если у кого-то есть идеи — подскажите. В приложеии есть сервис-нотификатор, который шлет уведомления. Есть две имплементации, по смс и по пушам. При этом нужно, чтобы клиенту уведомления шли по смс, а продавцу через пуш. Как лучше такое организовать? Сейчас так, но, мне кажется, это какой-то больной путь: customer_notificator: class: App\Service\Notificator\SmsNotificator public: true seller_notificator: class: App\Service\Notificator\PushNotificator public: true

А есть объект нотификации? Что принимает нотификатор?

А есть объект нотификации? Что принимает нотификатор?

Пользователя и сообщение.

К сожалению, у пользователя есть просто поля, селлер и кастомер. Где лежат уже объекты селлера и кастомера. А сообщение — просто дто.

К сожалению, у пользователя есть просто поля, селлер и кастомер. Где лежат уже объекты селлера и кастомера. А сообщение — просто дто.

Может тебе нужен какой-нить билдер-нотификатор, в который ты отдашь пользователя, а он вернет нужный нотификатор?

Может тебе нужен какой-нить билдер-нотификатор, в который ты отдашь пользователя, а он вернет нужный нотификатор?

Интересная мысль. Но я не могу по пользователю понять, кто он. То есть один и тот же пользователь может быть как продавцом, так и покупателем. (думаю, так делать была плохая идея, да)

Интересная мысль. Но я не могу по пользователю понять, кто он. То есть один и тот же пользователь может быть как продавцом, так и покупателем. (думаю, так делать была плохая идея, да)

а как ты понимаешь, кто есть кто?

Интересная мысль. Но я не могу по пользователю понять, кто он. То есть один и тот же пользователь может быть как продавцом, так и покупателем. (думаю, так делать была плохая идея, да)

Одновременно?

Одновременно?

Да.

Да.

Как так? В рамках одной сделки?

а как ты понимаешь, кто есть кто?

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

Как так? В рамках одной сделки?

Нет. В целом. В рамках одной сделки только одна роль, конечно.

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

И в этом месте ты эту информацию откуда берешь? Спрашиваешь у пользователя?

И в этом месте ты эту информацию откуда берешь? Спрашиваешь у пользователя?

Нет. Это место — сервисы обработки заказа. И там я знаю кому заказ и от кого. Достаю два нотифиактора и шлю нотификации.

Давать нотификатору заказ нельзя, потому что не все нотификации о заказе.

Ну там, тогда и разруливай всю эту петрушку, можешь действительно билдера какого-то запилить и мапу соотношений ролей и имплементаций

сделай интерфейс резолвера, который возвращает нотификатора а в имплементации ему контекст передавай

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

ему - резолверу

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

тем, что появляется зависимость от контейнера

тем, что появляется зависимость от контейнера

Вот да

Точно. Понял. То есть лучший вариант — сделать резолвер, передавать туда какой-нибудь контекст, и чтобы он возвращал конкретуню имплементацию, верно?

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

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

Видится, что да

Спасибо! Прояснилось в голове ?

Интересно, насколько хорошо работают AR + anemic model + transaction script? Такое выкорчёвывание поведения из состояния вызывает сомнение. Хотя вообще-то AR + anemic model быть наверное не может, потому-что это уже не AR =\ Даже не так спрошу, а по-другому: Пошли бы вы работать в место, где из AR сделали шлюз/anemic model, а логика в transaction script?

Интересно, насколько хорошо работают AR + anemic model + transaction script? Такое выкорчёвывание поведения из состояния вызывает сомнение. Хотя вообще-то AR + anemic model быть наверное не может, потому-что это уже не AR =\ Даже не так спрошу, а по-другому: Пошли бы вы работать в место, где из AR сделали шлюз/anemic model, а логика в transaction script?

ну, я лично не вижу конфликтов во фразе AR + anemic model - ведь та часть поведения, которая относится к AR, не является частью бизнес-логики, про которую обычно говорят в разрезе anemic/rich model

просто в сознании закреплено, что анемичная модель - фуфуфу бяка

ну, я лично не вижу конфликтов во фразе AR + anemic model - ведь та часть поведения, которая относится к AR, не является частью бизнес-логики, про которую обычно говорят в разрезе anemic/rich model

ну, если всё-таки есть где-то место, где эти данные слепляются с поведением, то наверное да

Интересно, насколько хорошо работают AR + anemic model + transaction script? Такое выкорчёвывание поведения из состояния вызывает сомнение. Хотя вообще-то AR + anemic model быть наверное не может, потому-что это уже не AR =\ Даже не так спрошу, а по-другому: Пошли бы вы работать в место, где из AR сделали шлюз/anemic model, а логика в transaction script?

что значит насколько хорошо?

лучше чем когда у тебя sql в контроллерах

> Пошли бы вы работать в место, где из AR сделали шлюз/anemic model, а логика в transaction script? смотря что ты видишь как альтернативу. Пойдешь ли ты в проект где люди думают что у них нормальная доменная модель а по факту переусложнанная хуита?

что значит насколько хорошо?

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

> Пошли бы вы работать в место, где из AR сделали шлюз/anemic model, а логика в transaction script? смотря что ты видишь как альтернативу. Пойдешь ли ты в проект где люди думают что у них нормальная доменная модель а по факту переусложнанная хуита?

а ты сам видел нормальную доменную модель?) как по мне, так всё, что я видел и что делаю сам - хуита

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

Yagni

а ты сам видел нормальную доменную модель?) как по мне, так всё, что я видел и что делаю сам - хуита

Именно

> Пошли бы вы работать в место, где из AR сделали шлюз/anemic model, а логика в transaction script? смотря что ты видишь как альтернативу. Пойдешь ли ты в проект где люди думают что у них нормальная доменная модель а по факту переусложнанная хуита?

Да, вот с альтернативами беда. Но тут наверное проблема в моей некомпетентности =\ Хотя людей рассуждающих на собеседовании про модель предметной области или вообще про что-то из SOLID, GRASP, DDD я ещё не встречал.

Да, вот с альтернативами беда. Но тут наверное проблема в моей некомпетентности =\ Хотя людей рассуждающих на собеседовании про модель предметной области или вообще про что-то из SOLID, GRASP, DDD я ещё не встречал.

Ну можем кпкнить обсудить по позже

Именно

в смысле не видел, или лишнее подтверждение того, что я хуиту делаю?)

ERROR: S client not available

:D

точка зрения - сложная штука)

в смысле не видел, или лишнее подтверждение того, что я хуиту делаю?)

По какому критерию можно судить говно или нет?)

Задачи бизнеса решает? Искать разработчиков чтоб не долго их учить можно? Бизнес доволен скоростью реализации их нужд?

Сроки более менее предсказуемые?

с разработчиками упс)

далеко не все могут сходу вникнуть во всю срань с сагами

Как ты думаешь, что для них самое сложное в осознании?

Как ты думаешь, что для них самое сложное в осознании?

то, что мир не замкнулся на request\response

то, что yield from \ yield new Success() / Promise - это не ссаная магия, которая работает с позволения аллаха. тем, что вся цепочка описана в саге непонятными и несвязанными на первый взгляд действиями

Как ты думаешь, что для них самое сложное в осознании?

основная проблема в том, что люди мыслят в контексте запрос -> пошли в базу данных -> отрендерили ответ -> сдохли нахер

то, что yield from \ yield new Success() / Promise - это не ссаная магия, которая работает с позволения аллаха. тем, что вся цепочка описана в саге непонятными и несвязанными на первый взгляд действиями

Ты сломал мой мир! Каждый раз, когда вижу yield - думаю о магии :D

Ты сломал мой мир! Каждый раз, когда вижу yield - думаю о магии :D

аще ничего сложного с генераторами нету. Надо просто попробовать

аще ничего сложного с генераторами нету. Надо просто попробовать

Ну, сложность - понятие относительное. Тебе вот легко, а кнопкодаву может и сложно будет :D. Но надо попробовать, вдруг действительно ничего сложного ;0

Ну, сложность - понятие относительное. Тебе вот легко, а кнопкодаву может и сложно будет :D. Но надо попробовать, вдруг действительно ничего сложного ;0

уж пора бы) им уж сто лет в обед)

аще ничего сложного с генераторами нету. Надо просто попробовать

Ну вот с ходу сказать как они работают под капотом я например не смогу))

Ну вот с ходу сказать как они работают под капотом я например не смогу))

гугл спешит на помощь)

кстати PHP-кнопкодав звучит более логично, чем PHP-программист :D

гугл спешит на помощь)

Лень)) у меня есть свои мысли на этот счёт, но копаться в доках лень

вроде бы Коняш упоминал, что лучший способ разобраться с генераторами и асинком - написать свой ивент луп

вроде бы Коняш упоминал, что лучший способ разобраться с генераторами и асинком - написать свой ивент луп

ну, я бы не сказал, что эт прям лучший способ

ну так скажи, какой лучший)

на хабре была пара статеек, логгер пилили. Вполне приемлимо) можно попробовать файлы большие попарсить. Тоже ок

reactphp/amphp?

моё имхо - в задницу реакт. Громоздко слишком. a+ промисы эти... либо ты делаешь бесконечную плоскую цепочку в чём-то +\- серьёзном, либо всё прячешь за амповскими корутинами. Да, можно упороться и корутины поверх реакта захерачить, но я смысла особого не вижу. 2 точки отказа вместо 1й

с точки зрения комьюнити у обоих дела обстоят одинаково (херово). Неблокирующих штуковин откровенно не хватает.

мне в принципе пофиг) ну или взять что другое

угу, го)

Ну в восьмерочки есть шансы на libuv в ядре... а это уже огромный шаг

Ну в восьмерочки есть шансы на libuv в ядре... а это уже огромный шаг

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

Много. Не придется всю socket / io фигню реализовывать в user land

угу, го)

не, с ним надо чуть дольше разбираться кмк + его асинк слишком своеобразный в плане доступности тут лучше начать с тем, где асинка by design нет)