AM
Более непредсказуемое.
Size: a a a
2020 June 05
AM
Давай из этого вопрос сделаем такой: надо написать коробочную CMS. У нее зависимости через Composer и ещё плагины, у них тоже зависимости через Composer. Как бы ты посоветовал это сделать?
AD
Давайте вопросов. Логирование, composer, psr, пакеты, коммерческй opensource, статистика (у него дофига данных от packagist).
Раз не густо с вопросами, я думаю эти могут быть полезны для дискусии.
Логирование:
1) Стоит ли вырабатывать единообразие в записи похожих данных в контекст логов (как в одном большом приложении, или в нескольких связанных сервисах). Или имеет место приводить к одному виду контекст снаружи - logstash и прочие.
2) Мнение про сообщение в логе - когда можно, когда не желательно использовать интерполяцию в сообщении записи лога.
Мои мысли - когда нет интерполяции, проще найти место в приложении, откуда лог пишется с помощью какого-то простого grep.
3) Fingers crossed, большие объекты в контексте и утечки памяти.
Хочется всегда писать в логи как можно больше контекста для полноты картины в момент их изучения.
Но если используется fingers crossed (который не отпустит пачку логов в обработчик до срабатывания "триггера" - например сообщения с уровнем error), то в его буфере будет хранится не отформатированное сообщение с объектами как есть (т. е. не нормализованные) и это кушает память.
Вопрос - как найти эту грань, когда можно скинуть буфер (если у нас приложение работает в демон-режиме - например, queue consumer); какой размер выбрать в качестве размера буфера (кол-во записей); возможно просто не кидать тяжелые объекты к контекст, а "нормализовать" их по месту до проброса в лог (тут мы можем иметь "оверхед" на нормализацию того, что может не использоватся - не сработает "триггер")
Логирование:
1) Стоит ли вырабатывать единообразие в записи похожих данных в контекст логов (как в одном большом приложении, или в нескольких связанных сервисах). Или имеет место приводить к одному виду контекст снаружи - logstash и прочие.
2) Мнение про сообщение в логе - когда можно, когда не желательно использовать интерполяцию в сообщении записи лога.
Мои мысли - когда нет интерполяции, проще найти место в приложении, откуда лог пишется с помощью какого-то простого grep.
3) Fingers crossed, большие объекты в контексте и утечки памяти.
Хочется всегда писать в логи как можно больше контекста для полноты картины в момент их изучения.
Но если используется fingers crossed (который не отпустит пачку логов в обработчик до срабатывания "триггера" - например сообщения с уровнем error), то в его буфере будет хранится не отформатированное сообщение с объектами как есть (т. е. не нормализованные) и это кушает память.
Вопрос - как найти эту грань, когда можно скинуть буфер (если у нас приложение работает в демон-режиме - например, queue consumer); какой размер выбрать в качестве размера буфера (кол-во записей); возможно просто не кидать тяжелые объекты к контекст, а "нормализовать" их по месту до проброса в лог (тут мы можем иметь "оверхед" на нормализацию того, что может не использоватся - не сработает "триггер")
AD
Раз не густо с вопросами, я думаю эти могут быть полезны для дискусии.
Логирование:
1) Стоит ли вырабатывать единообразие в записи похожих данных в контекст логов (как в одном большом приложении, или в нескольких связанных сервисах). Или имеет место приводить к одному виду контекст снаружи - logstash и прочие.
2) Мнение про сообщение в логе - когда можно, когда не желательно использовать интерполяцию в сообщении записи лога.
Мои мысли - когда нет интерполяции, проще найти место в приложении, откуда лог пишется с помощью какого-то простого grep.
3) Fingers crossed, большие объекты в контексте и утечки памяти.
Хочется всегда писать в логи как можно больше контекста для полноты картины в момент их изучения.
Но если используется fingers crossed (который не отпустит пачку логов в обработчик до срабатывания "триггера" - например сообщения с уровнем error), то в его буфере будет хранится не отформатированное сообщение с объектами как есть (т. е. не нормализованные) и это кушает память.
Вопрос - как найти эту грань, когда можно скинуть буфер (если у нас приложение работает в демон-режиме - например, queue consumer); какой размер выбрать в качестве размера буфера (кол-во записей); возможно просто не кидать тяжелые объекты к контекст, а "нормализовать" их по месту до проброса в лог (тут мы можем иметь "оверхед" на нормализацию того, что может не использоватся - не сработает "триггер")
Логирование:
1) Стоит ли вырабатывать единообразие в записи похожих данных в контекст логов (как в одном большом приложении, или в нескольких связанных сервисах). Или имеет место приводить к одному виду контекст снаружи - logstash и прочие.
2) Мнение про сообщение в логе - когда можно, когда не желательно использовать интерполяцию в сообщении записи лога.
Мои мысли - когда нет интерполяции, проще найти место в приложении, откуда лог пишется с помощью какого-то простого grep.
3) Fingers crossed, большие объекты в контексте и утечки памяти.
Хочется всегда писать в логи как можно больше контекста для полноты картины в момент их изучения.
Но если используется fingers crossed (который не отпустит пачку логов в обработчик до срабатывания "триггера" - например сообщения с уровнем error), то в его буфере будет хранится не отформатированное сообщение с объектами как есть (т. е. не нормализованные) и это кушает память.
Вопрос - как найти эту грань, когда можно скинуть буфер (если у нас приложение работает в демон-режиме - например, queue consumer); какой размер выбрать в качестве размера буфера (кол-во записей); возможно просто не кидать тяжелые объекты к контекст, а "нормализовать" их по месту до проброса в лог (тут мы можем иметь "оверхед" на нормализацию того, что может не использоватся - не сработает "триггер")
4) Как выбирать уровни логирования?
5) Стоит ли в сообщение вкладывать больше информации, чтобы оно было уникальным в рамках приложения. Или использовать разные log channels.
5) Стоит ли в сообщение вкладывать больше информации, чтобы оно было уникальным в рамках приложения. Или использовать разные log channels.
VC
Давай из этого вопрос сделаем такой: надо написать коробочную CMS. У нее зависимости через Composer и ещё плагины, у них тоже зависимости через Composer. Как бы ты посоветовал это сделать?
👍
AM
Раз не густо с вопросами, я думаю эти могут быть полезны для дискусии.
Логирование:
1) Стоит ли вырабатывать единообразие в записи похожих данных в контекст логов (как в одном большом приложении, или в нескольких связанных сервисах). Или имеет место приводить к одному виду контекст снаружи - logstash и прочие.
2) Мнение про сообщение в логе - когда можно, когда не желательно использовать интерполяцию в сообщении записи лога.
Мои мысли - когда нет интерполяции, проще найти место в приложении, откуда лог пишется с помощью какого-то простого grep.
3) Fingers crossed, большие объекты в контексте и утечки памяти.
Хочется всегда писать в логи как можно больше контекста для полноты картины в момент их изучения.
Но если используется fingers crossed (который не отпустит пачку логов в обработчик до срабатывания "триггера" - например сообщения с уровнем error), то в его буфере будет хранится не отформатированное сообщение с объектами как есть (т. е. не нормализованные) и это кушает память.
Вопрос - как найти эту грань, когда можно скинуть буфер (если у нас приложение работает в демон-режиме - например, queue consumer); какой размер выбрать в качестве размера буфера (кол-во записей); возможно просто не кидать тяжелые объекты к контекст, а "нормализовать" их по месту до проброса в лог (тут мы можем иметь "оверхед" на нормализацию того, что может не использоватся - не сработает "триггер")
Логирование:
1) Стоит ли вырабатывать единообразие в записи похожих данных в контекст логов (как в одном большом приложении, или в нескольких связанных сервисах). Или имеет место приводить к одному виду контекст снаружи - logstash и прочие.
2) Мнение про сообщение в логе - когда можно, когда не желательно использовать интерполяцию в сообщении записи лога.
Мои мысли - когда нет интерполяции, проще найти место в приложении, откуда лог пишется с помощью какого-то простого grep.
3) Fingers crossed, большие объекты в контексте и утечки памяти.
Хочется всегда писать в логи как можно больше контекста для полноты картины в момент их изучения.
Но если используется fingers crossed (который не отпустит пачку логов в обработчик до срабатывания "триггера" - например сообщения с уровнем error), то в его буфере будет хранится не отформатированное сообщение с объектами как есть (т. е. не нормализованные) и это кушает память.
Вопрос - как найти эту грань, когда можно скинуть буфер (если у нас приложение работает в демон-режиме - например, queue consumer); какой размер выбрать в качестве размера буфера (кол-во записей); возможно просто не кидать тяжелые объекты к контекст, а "нормализовать" их по месту до проброса в лог (тут мы можем иметь "оверхед" на нормализацию того, что может не использоватся - не сработает "триггер")
О, неплохо.
VC
Про логи: в связи с распространением docker и компании, ELK и конкурентов не имеет ли смысл форматом и выводом по умолчанию сделать json stream в stderr? А кому надо выберут другой формат и/или перенаправят в файл. По моей практике запись в json stream в обычный файл позволяет куда более удобно искать руками интересующие вещи с помощью jq, чем grep
AD
Про логи: в связи с распространением docker и компании, ELK и конкурентов не имеет ли смысл форматом и выводом по умолчанию сделать json stream в stderr? А кому надо выберут другой формат и/или перенаправят в файл. По моей практике запись в json stream в обычный файл позволяет куда более удобно искать руками интересующие вещи с помощью jq, чем grep
тут однозначное да.
Иначе получается кошмар в местах, которые должны это распарсить и структурированно разложить.
Иначе получается кошмар в местах, которые должны это распарсить и структурированно разложить.
AM
Про логи: в связи с распространением docker и компании, ELK и конкурентов не имеет ли смысл форматом и выводом по умолчанию сделать json stream в stderr? А кому надо выберут другой формат и/или перенаправят в файл. По моей практике запись в json stream в обычный файл позволяет куда более удобно искать руками интересующие вещи с помощью jq, чем grep
Я верно понимаю что сейчас там текст в stdout?
VC
Я верно понимаю что сейчас там текст в stdout?
сейчас ничего в голом монологе, всё надо конфигурить руками, если фреймворк об этом не заботится.
AM
сейчас ничего в голом монологе, всё надо конфигурить руками, если фреймворк об этом не заботится.
Хм... тогда не очень понял вопрос. Монолог - это библиотека. По умолчанию там конфига нет, насколько помню, верно? Тогда про что речь? Про умолчания какого-то определённого фреймворка, который это использует? Про отсутствие из коробки возможности писать в json stream в stderr?
GI
У меня вопрос по композеру, будет ли поддержка монорепозитория без необходимости экспортировать все пакеты в отдельные репозитории, то есть, чтобы композер мог скачивать нужную подпапку с пакетом из git. Сейчас, если я правильно понимаю монорепозитории, все пакеты разложены по папкам, в composer.json они прописываются как репозитории типа "path". Для того, чтобы зарелизить приложение, нужно всем пакетам проставить версии (одну версию), экспортировать их в отдельные репозитории (git subtree), поменять тип репозиториев в composer.json, и только тогда композер будет их рассматривать как независимые пакеты. Я правильно понимаю?
VS
а как тогда папки версионировать?
выпускать релизы только на всю монорепу?
выпускать релизы только на всю монорепу?
VC
Хм... тогда не очень понял вопрос. Монолог - это библиотека. По умолчанию там конфига нет, насколько помню, верно? Тогда про что речь? Про умолчания какого-то определённого фреймворка, который это использует? Про отсутствие из коробки возможности писать в json stream в stderr?
В версиях 1.* было поведение по умолчанию, в 2.0
> BC Break: There is no more default handler configured on empty Logger instances
> BC Break: There is no more default handler configured on empty Logger instances
AM
В версиях 1.* было поведение по умолчанию, в 2.0
> BC Break: There is no more default handler configured on empty Logger instances
> BC Break: There is no more default handler configured on empty Logger instances
Вопрос в том, стоит ли вернуть поведение по умолчанию?
AM
У меня вопрос по композеру, будет ли поддержка монорепозитория без необходимости экспортировать все пакеты в отдельные репозитории, то есть, чтобы композер мог скачивать нужную подпапку с пакетом из git. Сейчас, если я правильно понимаю монорепозитории, все пакеты разложены по папкам, в composer.json они прописываются как репозитории типа "path". Для того, чтобы зарелизить приложение, нужно всем пакетам проставить версии (одну версию), экспортировать их в отдельные репозитории (git subtree), поменять тип репозиториев в composer.json, и только тогда композер будет их рассматривать как независимые пакеты. Я правильно понимаю?
Записал.
VC
Вопрос в том, стоит ли вернуть поведение по умолчанию?
стоит ли вернуть поведение по умолчанию, если сделать его json stream в stderr
AM
стоит ли вернуть поведение по умолчанию, если сделать его json stream в stderr
Принято.
Y
Вже завтра, 6 червня о 15:30 ви наживо почуєте захоплюючий діалог між Marco Pivetta та Pim Elshoff “DDD: You’re doing it wrong”.
Marco та Pim обговорять:
🔗що таке Domain Driven Design
🔗які завдання DDD вирішує
🔗фактори, які призводять до виникнення проблем у використанні цього методу.
А також вони готують один одному каверзнi запитання 🙈
Дискусія буде запальною🔥
Адже Marco має понад десятиліття досвіду роботи з PHP, є частиною команди Zend Framework CR, а Pim Elshoff — TDD & DDD Coach, який має великий досвід вирішення великих проєктів, які використовують DDD.
Квитки ще можна придбати🤩
Marco та Pim обговорять:
🔗що таке Domain Driven Design
🔗які завдання DDD вирішує
🔗фактори, які призводять до виникнення проблем у використанні цього методу.
А також вони готують один одному каверзнi запитання 🙈
Дискусія буде запальною🔥
Адже Marco має понад десятиліття досвіду роботи з PHP, є частиною команди Zend Framework CR, а Pim Elshoff — TDD & DDD Coach, який має великий досвід вирішення великих проєктів, які використовують DDD.
Квитки ще можна придбати🤩
IB
Тут Леша Петров написал отличный пост про дискуссию Марко и Пима, которая пройдет завтра на конфе. Вам точно будет интересно прочесть и может похоливарить про DDD тут? 😄
https://www.facebook.com/photo.php?fbid=3043776832370380&set=a.3043782092369854&type=3&theater
https://www.facebook.com/photo.php?fbid=3043776832370380&set=a.3043782092369854&type=3&theater
