Как стать автором
Обновить

Комментарии 34

Блин, где вы этих слонов берете постоянно?!
НЛО прилетело и опубликовало эту надпись здесь
Соглашусь в том плане, что есть более важные вещи требующие стандарта. А они эти логгеры где-то полгода мучали, может даже больше, не помню. И да, у нас внезапно появился аж один логгер соответствующий стандарту ) Хз насколько реально, но пусть бы они разработали стандарт кросс-фреймворкового middleware. Понимаю, логгер может быть первым шагом на пути к этому, но тогда было бы неплохо принимать весь этот стандарт в комплексе. Чтобы мы видели замчем это всё надо и почему стоит под него подстраиваться.
А мне они все кажутся спорными из-за пробелов (в смысле, таких — " "). Я не хочу сейчас разжигать, просто констатирую факт — мне это не нравится (как и многим другим). Неужели во втором десятилетии 21-го века это является проблемой?

Ну, стандарт есть стандарт (не важно, кто его принял, важно кто его поддерживает), потому я перешел с табов на пробелы. Пока радости не испытываю.

А есть альтернативная версия стандарта? Вот 1в1, но с табами? :)
Можете выжимку конкретики сюда кинуть?

* Типа чё за выскочка — какой из фреймворков, какие минусы этого «стандарта». Я например уже ужасаюсь фразе «заместо табов пробелы».
* С какого из языков можно тупо скопипастить такой стандарт? У явистов это есть?
У нас (явистов) есть log4J2 от apache
log4J2 ??

У log4J же более-менее устоявшийся интерфейс — чё бы его не взять и не изобретать лисипеды.

Btw, можете глянуть github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md?

На сколько дико он отличается в худшую сторону от log4j`я?
Не особо дико. Хотя это же всего интерфейс.
Тут надо смотреть на конечную реализацию.

PSR-3 вообще мне напомнил уровни syslog'a (скорее всего оттуда ноги растут)

Сисадминам намного приятнее работать с логами, которые прямо можно интерпретировать в syslog. Учитывая, что подавляющее большинство серверов с PHP крутится на Linux мне кажется это разумным решением.
Ухты у меня почти соотвествует система PSR-3 =)
В принятии стандарта участвовали 26 проектов, среди них PEAR, Doctrine, Composer, Joomla, Drupal, CakePHP, Symfony, PyroCMS, phpDocumentor, Zend Framework. Это не «внутри довольно узкой группы людей».
Не 26 проектов, а 26 человек из разных проектов. Плюс к тому же я бы не стал доверять мнению многих их них. Например, что за PyroCMS? Эти люди собираются учить вас как писать код. Выглядит как просто попытка быть причастным к чему-то глобальному.
PyroCMS это проект Phil Sturgeon, популярного блоггера и разработчика CodeIgniter. Кстати, его пост есть и в этом дайджесте. На самом деле, если оценивать этих 26 чекловек, то в первую, как мне кажется, очередь критерием является их публичность. Такая себе попытка создать сообщество лидеров PHP опен-сорс комьюнити. Пусть код некоторых проектов сам далеко не идеален (Друпал, Джумла, они тоже в списке, если чо), но эти люди собравшись вместе могут что-то изменить в опен-сорс мире за счет своего влияния. Но главное, не разработать стандарт, а внедрить его… Увы, это может занять годы.
26 человек это те, кто имеют право голоса. Из большинства проектов в обсуждении принимает участие не один человек. Более того, принимать участие в обсуждении и выдвигать свои предложения может любой человек, в том числе и Вы, например. И даже более того! Любой может запросить право голоса, отправив соответствующую заявку на рассмотрение.
На самом деле, стандартизация полезна, но только тогда, когда участвуют в голосовании все, в том числе и сообщество. Потому что хочется иметь возможность менять компоненты в целой системе, сохраняя прежний функционал. И то, что сейчас происходит в PHP — давно пройденный путь в Java.
Даже названия похожие: JSR и PSR. Тут даже равенство напрашивается: PSR-3 = JSR-47 )
Увы, пока нету пока какого-то сообщества PHP. Есть сообщества друпалистов, симфонистов, зендистов, и т.п. И они представляют своих лидеров. Считай, что это непрямая демократия. Сообщество чистого РНР пока слишком слабо и аморфно.
Зачем? Зачем нужны какие-то рамки в этом? Есть простенький логгер с тремя методами, есть крутой с десятком
Это все хорошо до той поры когда мы считаем что самый лучший код — это самописный, и в сотый раз изобретаем велосипед, нежели посмотреть к соседу на гитхабе и заюзать его решение, как делают все остальные во всех языках: руби, питон, ява.

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

Когда у тебя будет 5-6 разных логеров со своими заморочками мы либо придем к замечательному утверждению — чужой код гавно, я тут лучше свой напишу со своими велосипедами, либо все таки задумаемся о том, что стандартизация все таки необходима. Во второй вариант в мире php я вот верю слабо, слишком уж большое количество велосипедостроителей с интеллектом как у улитки. Поэтому и язык развивается со скоростью этой самой улитки.

Если интересно, можете почитать про нашу проблему habrahabr.ru/post/113145. Поучительная история про логирование
В других языках используют готовые библиотеки для логирования, вместо изобретения велосипеда. Стандарт же предлагает обрывки логгера, разрешая расширить его своими методами (т.е. сделать «крутой логгер с десятком методов»). Что меняет этот стандарт?
От расширения ты никак не застрахуешься, оно в некоторых местах очень даже полезно и нужно. Какие базовые вещи должны быть в стандарте для логирования, да впринципе вот они:

Какие уровени логирования должны быть и за что они отвечают, в какой последовательности идут. Это что бы не было такого, что у одного велосипеда два уровня логирования — error и debug, а у другого — только для одного дебага штук пять их.

API для работы с ним. Тут всякие интерфейсы типа Logger, LogLevel, Appender и прочие.

Описание как оно все должно управляться внутри. Опять же, по большей части я уверен это можно описать и в интерфейсах.

А реализация — ну тут уже либо она соответствует, либо нет.

Какой-то перец захотел, чтобы у всех PHP-библиотек логгирования был одинаковый интерфейс.

Не какой-то перец, а какие-то перцы, и не у всех библиотек, а у разрабатываемых этими перцами. Отличное решение, на мой взгляд. Соглашусь только, что корректней было бы его назвать FIG-1 вместо PSR-3.

И да, раскажите, пожалуйста, слезливую историю о том, как после принятия стандарта PSR-3 (PHP Standard Recommendation) ваша свобода творчества была ограничена, и как вам диктовали какие методы должны быть в ваших классах.
И да, раскажите, пожалуйста, слезливую историю о том, как после принятия стандарта PSR-3 (PHP Standard Recommendation) ваша свобода творчества была ограничена, и как вам диктовали какие методы должны быть в ваших классах.

Ну как же, вон, в приведенной ссылке на «личные мысли и критику», чуть ли не первым пунктом идет критика названий методов. Ах да, еще и почему-то emergency не принимает Exception cause.
Вы, по-моему, не улавливаете суть. Если вам не нравится psr-N, вы его не поддерживаете в своей библиотеке. Если есть идеи по улучшению, или несогласие с чём-то конкретно — всегда есть issue tracker, изгалайте свои мысли там, вас услышат.
Забавно читать закрытые issues: «Не не, это же PSR», «Мы там голосовали все когда-то и менять не будем ничего».

Или от Nate Abele: «As far as I'm concerned, someone who's willing to suggest something so patently awful has no business going near any standards whatsoever.». Каким бы не было глупым предложение, отвечать так нельзя.

Нет смысла излагать свои мысли, там все уже решили.
Полагаю, вы либо не читали список членов FIG, либо не знаете, что это за люди.
github.com/php-fig/fig-standards
Если вы именно этих людей назвали «выскочками», то, полагаю, вы очень плохо знакомы с миром PHP.
О, мой пост в дайджест попал=) Приятно.
Вот не как не пойму зачем логгер в psr а не в spl?
<< Немного личных мыслей и критики
Все по делу, я с ним согласен. Как и с критикой PSR-2. Особенно названия методов радуют.
По поводу АОП — что вы рекомендуете почитать? Не реализации, а теорию. У меня пока не было проблем со сквозным кодом (точнее, они легко решались событиями), но хочу знать, чего стоит бояться в будущем.
К сожалению, про АОП теории крайне мало. И отдельных материалов, без привязки к реализации, практически не найти. Однако есть целый сайт этузиаста АОП: crosscuttingconcerns.com. Там можно найти очень много всего полезного. А еще старенькая статья про АОП с phpAspect.
> Мультизадачность на PHP

Никто не знает есть ли на win системах хотя бы один гарантированно работоспособный способ взаимодействия между процессами? PCNTL недоступен. proc_open невозможно использовать из множества критичных багов (то что поддерживается только блокирующий режим у потоков ладно, с этим жить можно, но что stream_select уже лет 5 работает криво это совсем печально...)
Минусуя — аргументируй! Ибо оно действительно не работает…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий