проверил после этого сразу, было >=7.0.0 :)

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

дада, это я уже понял))

каким образом, типа оповещения?

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

а то так сделаешь composer update и узнаешь что "вот маленькая либка нифига не по semver работает")

Ребят, у меня пхп7 ругается на each()

Unknown: The each() function is deprecated. This message will be suppressed on further calls in ...

как быть?

Ребят, у меня пхп7 ругается на each()

deprecated же, не использовать его

от него отказались в пользу foreach

while ( $count < $opts['length'] && list($page, $pageStr) = each($files) ) {

ого конструкция

А что вложенный foreach не катит?

ну это не я писал

катит

сейчас переделаю

array_splice($files, 0, $opts['length']); foreach($files as list($page, $pageStr) ) { }

$pageStr = array_shift($this->pageStr); можно так еще

чуть подправил вариант

Йо, Ребята. Вопрос. Как быть, если я хочу логировать процесс выполнения некоторой операции инкапсулированной в сервис, но не хочу тянуть в зависимости сервиса логгер? Event Bus?

если symfony - то лучше декоратор сервиса https://symfony.com/doc/current/service_container/service_decoration.html

https://medium.com/@ibrahimgunduz34/decoration-of-services-with-symfony-813e35f1025e

если symfony - то лучше декоратор сервиса https://symfony.com/doc/current/service_container/service_decoration.html

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

Йо, Ребята. Вопрос. Как быть, если я хочу логировать процесс выполнения некоторой операции инкапсулированной в сервис, но не хочу тянуть в зависимости сервиса логгер? Event Bus?

если делать через ивенты, то точную последовательность сложно наверное проследить будет, при параллельых запросах

если делать через ивенты, то точную последовательность сложно наверное проследить будет, при параллельых запросах

это если асинхронные

если делать через ивенты, то точную последовательность сложно наверное проследить будет, при параллельых запросах

Не страшно, в сообщениях лога будут уникальные идентификаторы

это если асинхронные

а какие еще могут быть запросы к приложению?

а какие еще могут быть запросы к приложению?

ивенты)

хотя...

ивенты)

ну ивенты то пораждаются приложением, а оно запросом :)

Переформулирую вопрос. Не зашкварно ли использовать Event Bus для операций логирования?

Переформулирую вопрос. Не зашкварно ли использовать Event Bus для операций логирования?

При всей моей любви ко всяческим басам, логгирование совсем не про них

Почему сложно притянуться логгер в сервис?

Если сложно (перевожу - лень) инжектить ничего не стоит написать маленький статический сервис локатор только для логов.

Почему сложно притянуться логгер в сервис?

ну как минимум тогда логгер станет часть логики сервиса. И если что то сломается в логгере, то весь сервис окажется не рабочим

И какова вероятность того что-то сломается в логгере?

ну как минимум тогда логгер станет часть логики сервиса. И если что то сломается в логгере, то весь сервис окажется не рабочим

Да

И какова вероятность того что-то сломается в логгере?

вероятность есть всегда :)

И какова вероятность того что-то сломается в логгере?

А если этот сервис будет использоваться в сценарии, где в логировании нет необходимости? Пихать в зависимости NullLogger?

Если сложно (перевожу - лень) инжектить ничего не стоит написать маленький статический сервис локатор только для логов.

Есть мнение, что https://habrahabr.ru/post/270005/

Это не значит что он плох :) Ох уж этот максимализм. В Java годами пишут: Logger log = Logger.getLogger(MyService.class.getName()); и никто не парится.

А если этот сервис будет использоваться в сценарии, где в логировании нет необходимости? Пихать в зависимости NullLogger?

Что это за сценарий такой? На ум приходят только разные окружения... Но это закрывается тем же Null Logger.

Есть мнение, что https://habrahabr.ru/post/270005/

первое же предложение упоминает на статически типизированые языки, так что мнение мимо кассы. Энивей, если у тебя логирование — часть процесса, то нужно его каким-то образом запихнуть. Если боишься, что поломается логер — оберни каждый вызов логгера в try\catch

можно заюзать BufferingLoger и писать куда нужно на shutdown function

но это уже инфрастуктурные проблемы, не БЛ

Можно еще AOP заюзать, но это не про PHP :)

первое же предложение упоминает на статически типизированые языки, так что мнение мимо кассы. Энивей, если у тебя логирование — часть процесса, то нужно его каким-то образом запихнуть. Если боишься, что поломается логер — оберни каждый вызов логгера в try\catch

Ок, статья с неудачным вводным предложением. Суть мнения в том, что СервисЛокатор - этоинфраструктурная зависимость и он действительно нарушает инкапсуляцию и зачем его использовать, если зависимость можно указать явно?

первое же предложение упоминает на статически типизированые языки, так что мнение мимо кассы. Энивей, если у тебя логирование — часть процесса, то нужно его каким-то образом запихнуть. Если боишься, что поломается логер — оберни каждый вызов логгера в try\catch

Ну и сразу же возникает вопрос, как тестировать что-то с сервисЛокатором внутри?

Зачем вообще использовать локатор или зависимости, которые не являются частью логики? Например, логгер... почему бы не использовать PublisherSubscriber, а уже снаружи ловить события и при необходимости их логировать?

можно заюзать BufferingLoger и писать куда нужно на shutdown function

И смысл не в том, что логгер сломается, а в том, как "правильно" расширять и изменять систему

Зачем вообще использовать локатор или зависимости, которые не являются частью логики? Например, логгер... почему бы не использовать PublisherSubscriber, а уже снаружи ловить события и при необходимости их логировать?

Вот я и спросил, не зашкварно ли использовать EventBus

имхо логгер в сервисе это нормально, если он логирует бизнес-логику.

имхо логгер в сервисе это нормально, если он логирует бизнес-логику.

Если бизнес-логика подразумевает, что нужно хранить историю шагов, то почему логгер? Завтра кто-то захочет по ней искать или строить отчёты...что будем делать? Писать сторилку в б/д с поддержкой PSR-3?

Йо, Ребята. Вопрос. Как быть, если я хочу логировать процесс выполнения некоторой операции инкапсулированной в сервис, но не хочу тянуть в зависимости сервиса логгер? Event Bus?

Йо, Ребята. Вопрос. Как быть, если я хочу логировать процесс выполнения некоторой операции инкапсулированной в сервис, но не хочу тянуть в зависимости сервиса логгер? Event Bus?

Почему бы и нет? Сегодня нужно логирование - добавили подписчика-логгера в конфиге. Завтра не нужно - отключили.

Если бизнес-логика подразумевает, что нужно хранить историю шагов, то почему логгер? Завтра кто-то захочет по ней искать или строить отчёты...что будем делать? Писать сторилку в б/д с поддержкой PSR-3?

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

да и вообще вопрос не мой, мы ушли от темы :)

на https://habrahabr.ru/post/165329/

выбирай сложность для себя сам )

Большое всем спасибо! Люблю этот чатик.

логер в сервис норм.. не хочешь логер в сервис, можно евенты, но осозновай что пошло усложнение

я бы логирование через события не делал) ровно как и через аспекты. Не очень удобно

С событиями удобно, в случае, если нужно не только логировать но и еще что-то делать. В ином случае, если это write-only можно и просто логгером.

С событиями удобно, в случае, если нужно не только логировать но и еще что-то делать. В ином случае, если это write-only можно и просто логгером.

ну это ближе к доменным ивентам

ну это ближе к доменным ивентам

Да, но я так понимаю что там скорее всего это и нужно. Учитывая что они срабатывать должны после onChange если это какой-то do/action log

Да, но я так понимаю что там скорее всего это и нужно. Учитывая что они срабатывать должны после onChange если это какой-то do/action log

ну в общем случае да)))

ERROR: S client not available

budet

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

isset

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

Вакансия: #symfony #devops #remote #parttime Компания: http://flant.ru/ Локация: Удаленка Описание вакансии: Нужны дополнительные голова и руки на backend на Symfony. Удаленка, part-time. Часов на 50-70 в месяц. Ставка $16+ в час по результатам https://docs.google.com/document/d/1FsBUdgdh2jMYU4q4GWL_WJI2XgCRdCZb7bZ_ACfZZ7w/edit# Контакты: @bav4ik

Сделал канал, куда буду направлять все вакансии связанные с симфони. так что подписывайтесь https://t.me/symfony_careers

коллеги-модераторы, если с утра зайдете и подумаете что это спам - перечитайте внимательно?

16$h для симфони - это спам ;)

16$h для симфони - это спам ;)

для кого-то это нормальные деньги)

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

завтра вон обещают норм вакансию скинуть, где можно с @fes0r поработать вместе ;)

я правда не знаю это хорошо или плохо

ну ты делаешь стандартную ошибку оценки "нормальности денег" исходя из уровня жизни в месте проживания... правильно все же делать оценку исходя из уровня предложений ;)

2500(если фултайм) для мидла симфони вполне норм деньги

в белую если, то да

т.е. с заложенным отпуском, больничными, налогами и т.п.

налог 5%, ну то такое

ну в общем ладно, есть такие, кто о таких вещах не думают ;)

если выбирать 2500 удаленку или 3000 офис, то тут мнения могут разделиться)

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

пока жил в таиланде ничего себе не ломал)

аргумент уровня джуна "у меня все работает" ;)

ну аргументы в общем такие себе) дома безопаснее

а до работы доехать/дойти еще надо

?

дома как бы тоже можно много что сломать... тут вопрос не в том, что удаленка или офис, а в том, что как оформлено все это. Удаленка тоже может быть по ТК ;)

дома как бы тоже можно много что сломать... тут вопрос не в том, что удаленка или офис, а в том, что как оформлено все это. Удаленка тоже может быть по ТК ;)

ну тут еще реалии разных стран

в Украине ты с вероятностью 98% попадешь на оформление по ФОП (ИП) - а там никаких гарантий от государства

работаю на удаленке, с отпусками, плачу налоги и тд. так шо не показатель