Скорее всего есть причина объясняющая эти расхождения, я её не знаю,...
Рискну предположить, что я такую причину знаю. И она лежит совсем в другом измерении. Просто в почти всех видах биржевых торгов в конечном итоге "основной составляющей" является "игра в орлянку" (случайный бинарный выбор) с неравными ставками. Именно поэтому, чем больше вы играете, тем с большей вероятностью спустите всё вложенное. На эту тему я написал воспоминание в своих "мемуарах" "Не играйте на деньги с людьми богаче вас. Часть 2". (Для лучшего понимания лучше сначала прочитать часть 1). Но это окололитературные объяснения. В посте в моей группе в Телеграмме я попытался на качественном уровне (с графиком, но без формул) показать суть процесса. Сейчас я заканчиваю разрабатывать симулятор этого процесса. Он почти готов. Он очень прост, как проста суть (основная компонента) биржевых заумностей.
Сделать это можно. На это даже тикет в GitHub заведён. Но это не сделано, потому что я сначала делаю то, что нужно моим проектам, и если это может быть интересно и другим, предлагаю миру. А моим проектам этого пока не нужно.
Реализованный вариант лучше предложенного в следующих ситуациях, когда
приложение высоко-автономное и, возможно, глючит как раз при отсутствии связи с сервером,
поддержка осуществляется из разных пунктов, в том числе и средствами сообщества пользователей,
в стране пользователя существуют строгие ограничения на передачу и хранение приватных данных (а если пользователь их сам отослал, сам за это и ответчик),
пользователи хотели бы иметь понятный контроль над данными, которые они отсылаю куда-либо,
провайдер услуги (использующий в своём коде эту библиотеку) не хочет тратиться на поддержку сервисного сервера.
правильно делаете, что системно создаете продукты, которых самим не хватает. Это верный путь!
Спасибо. Да, путь верный. Но даже по некоторым комментария к этой статье видно, насколько различны представления о том, что надо. И много времени тратится на шлифовку. Но... остаётся надеяться, что кому-то это потребуется тоже.
Потенциальный crash приложения, если вдруг будет циклический JavaScript объект.
За замечания по форматированию и очепяткам ещё раз спасибо. А как возможен crash приложения, я не понял. Не могли бы Вы переслать пример, который ломается? Как я понимаю, для этого вся библиотека вам не понадобится. Можно в личку.
Потенциальные утечки памяти
Почему? Не могли бы Вы описать это подробнее?
но я не вижу как можно удалить один конкретный логгер
Такая возможность действительно не предусмотрена. Зачем это может быть нужно? Удаление всех логгеров сразу и так сделано в целях перестраховки.
Есть только clearAllLoggers, который не факт что вызовется.
Почему?
Метод setLogLevelsByAllLoggers и setLogLevel делают почти одно
Не соглашусь. По моему опыту первый полезен в продакшине, а второй при разработке.
Вместо метода containsPath можно было бы обойтись регулярным выражением
Да, вы правы. Это рудимет от более сложной задумки. Но это внутренности и это работает.
Зачем defaultPathPostfix в LoggerFactory public?
Чтобы можно было просто его сменить.
Зачем LoggerFactory это класс если имеет только static методы? Такого же эффекта можно добиться если переписать класс на функции и экспортировать только публичные.
В каждом логируемом классе LoggerFactory вызывается только один раз. Поэтому LoggerFactory.doSomething() для меня предпочтительнее чем LoggerFactory.getInstance().doSomething()
Если уж так хочется в ООП, то его нужно реализовывать правильно. А как правильно, можно посмотреть
Нет, в ООП я в своей жизни наигрался. А как правильно - вопрос спорный. Сначала надо договориться о критериях правильности.
Множественные опечатки
Спасибо, в следующей версии исправлю. (Возможно, уже сегодня). Очепятки - моя беда :-(
Если Вам вдруг нужен удобный функциональный логгер для браузера, посмотрите в сторону consola. Как будто бы он удовлетворяет всем Вашим потребностям.
Да нет, как будто бы совсем не удолетворяет. Возможно, в браузере он и работает, но заточен под Ноду. И самого главного - управления выводом на лету я там не увидел.
Большое спасибо за потраченное время и конструктивные предложения. Я постараюсь спокойно разобраться с Вашими замечаниями и предложениями. На это мне потребуется некоторое время.
Никто не оспаривает полезность сбора и анализа серверных логов. Это - огромная тема, большое количество открытых и платных инструментов. Но эта библиотека предназначена совсем для другого. Типичный Use Case в production: Пользователь сообщает о проблеме с приложением. Сотрудник отдела поддержки решает, что проблема в клиентской части (которая работает в браузере). Он просит пользователя включить логирование, открыть вкладку консолли в браузере и повторить операцию, при которой происходит ошибка, скопировать вывод из консоли и послать в поддержку.
Просто обернуть вывод в консоль — красивой оберткой — никакого смысла не имеет.
Наши мнения очевидным образом расходятся. Я в своих профессиональных и приватных проектах я много намучился с этой проблемой и попытался её решить. Решив для себя, подумал, что мое решение и остальным может оказаться полезным.
Что я ясно вижу, о чем уже писал в другом комментарии - надо еще активнее подчеркнуть, что это библиотека для работы а браузере, а не в тяжелых серверных приложениях на Node.Js. В простых серверных предложениях - возможно.
Тут Вы правы. Надо подчеркнуть легковесность библиотеки. То, что моя библиотека инспирирована Log4J не значит, что она повторяет её функциональность. В Log4J вбиты десятилетия труда программистов.
Это ИИ так нарисовал. В моём промте этого не было.
Кстати, я просил только нарисовать рубку со штурвалом и столом, на котором лежит бортовой журнал, чернильница и перо. А приглядитесь - он стол со стеночками ограничительными нарисовал и чернильницу закрытую. Понимает морскую специфику 😉.
Дата и уровень логирования и так появится в выводе. Помещать контекст Вам никто не запрещает, но библиотека это делать и не заставляет. Проблема в том, что message часто бывают неразличимы, поскольку одни и те же параметры выводятся в разных местах функции или ловится ошибка, которая может тоже в разных местах выскочить одна и та же. И вы, анализируя лог, не в состоянии понять, в каком месте кода она выскочила и залогирована.
Именно для этого я советую сознательно различать точки логирования.
Меня не оставляет ощущение, что мы на пороге открытия математического аппарата, который будет единообразно и точно описывать и лавины в горах и дюны в пустынях и волны на воде.
Рискну предположить, что я такую причину знаю. И она лежит совсем в другом измерении.
Просто в почти всех видах биржевых торгов в конечном итоге "основной составляющей" является "игра в орлянку" (случайный бинарный выбор) с неравными ставками. Именно поэтому, чем больше вы играете, тем с большей вероятностью спустите всё вложенное.
На эту тему я написал воспоминание в своих "мемуарах" "Не играйте на деньги с людьми богаче вас. Часть 2". (Для лучшего понимания лучше сначала прочитать часть 1). Но это окололитературные объяснения. В посте в моей группе в Телеграмме я попытался на качественном уровне (с графиком, но без формул) показать суть процесса. Сейчас я заканчиваю разрабатывать симулятор этого процесса. Он почти готов. Он очень прост, как проста суть (основная компонента) биржевых заумностей.
Век живи, век учись. Учту при следующей публикации 😉😂
Спасибо. Считаю, что публикация очень полезная. Непонятно, за что её минусовали.
Сделать это можно. На это даже тикет в GitHub заведён. Но это не сделано, потому что я сначала делаю то, что нужно моим проектам, и если это может быть интересно и другим, предлагаю миру. А моим проектам этого пока не нужно.
Реализованный вариант лучше предложенного в следующих ситуациях, когда
приложение высоко-автономное и, возможно, глючит как раз при отсутствии связи с сервером,
поддержка осуществляется из разных пунктов, в том числе и средствами сообщества пользователей,
в стране пользователя существуют строгие ограничения на передачу и хранение приватных данных (а если пользователь их сам отослал, сам за это и ответчик),
пользователи хотели бы иметь понятный контроль над данными, которые они отсылаю куда-либо,
провайдер услуги (использующий в своём коде эту библиотеку) не хочет тратиться на поддержку сервисного сервера.
Спасибо. Да, путь верный. Но даже по некоторым комментария к этой статье видно, насколько различны представления о том, что надо.
И много времени тратится на шлифовку.
Но... остаётся надеяться, что кому-то это потребуется тоже.
Ещё раз спасибо. Уже исправлено в тексте и в библиотеке.
За замечания по форматированию и очепяткам ещё раз спасибо.
А как возможен crash приложения, я не понял. Не могли бы Вы переслать пример, который ломается? Как я понимаю, для этого вся библиотека вам не понадобится. Можно в личку.
Почему? Не могли бы Вы описать это подробнее?
Такая возможность действительно не предусмотрена. Зачем это может быть нужно? Удаление всех логгеров сразу и так сделано в целях перестраховки.
Почему?
Не соглашусь. По моему опыту первый полезен в продакшине, а второй при разработке.
Да, вы правы. Это рудимет от более сложной задумки. Но это внутренности и это работает.
Чтобы можно было просто его сменить.
В каждом логируемом классе LoggerFactory вызывается только один раз.
Поэтому LoggerFactory.doSomething() для меня предпочтительнее чем LoggerFactory.getInstance().doSomething()
Нет, в ООП я в своей жизни наигрался. А как правильно - вопрос спорный. Сначала надо договориться о критериях правильности.
Спасибо, в следующей версии исправлю. (Возможно, уже сегодня). Очепятки - моя беда :-(
Да нет, как будто бы совсем не удолетворяет. Возможно, в браузере он и работает, но заточен под Ноду. И самого главного - управления выводом на лету я там не увидел.
Большое спасибо за потраченное время и конструктивные предложения.
Я постараюсь спокойно разобраться с Вашими замечаниями и предложениями.
На это мне потребуется некоторое время.
Никто не оспаривает полезность сбора и анализа серверных логов. Это - огромная тема, большое количество открытых и платных инструментов.
Но эта библиотека предназначена совсем для другого.
Типичный Use Case в production: Пользователь сообщает о проблеме с приложением. Сотрудник отдела поддержки решает, что проблема в клиентской части (которая работает в браузере). Он просит пользователя включить логирование, открыть вкладку консолли в браузере и повторить операцию, при которой происходит ошибка, скопировать вывод из консоли и послать в поддержку.
Наши мнения очевидным образом расходятся. Я в своих профессиональных и приватных проектах я много намучился с этой проблемой и попытался её решить. Решив для себя, подумал, что мое решение и остальным может оказаться полезным.
Что я ясно вижу, о чем уже писал в другом комментарии - надо еще активнее подчеркнуть, что это библиотека для работы а браузере, а не в тяжелых серверных приложениях на Node.Js. В простых серверных предложениях - возможно.
Ваш комментарий я расцениваю как повод уточнить в документации к новой версии фокус, на что библиотека ориентирована и на что нет.
С чего Вы это взяли? Я пишу о том, что в любом языке программирования (на чтобы он не был нацелен) должно быть встроенное логирование.
Тут Вы правы. Надо подчеркнуть легковесность библиотеки. То, что моя библиотека инспирирована Log4J не значит, что она повторяет её функциональность. В Log4J вбиты десятилетия труда программистов.
Это ИИ так нарисовал. В моём промте этого не было.
Кстати, я просил только нарисовать рубку со штурвалом и столом, на котором лежит бортовой журнал, чернильница и перо. А приглядитесь - он стол со стеночками ограничительными нарисовал и чернильницу закрытую. Понимает морскую специфику 😉.
Дата и уровень логирования и так появится в выводе. Помещать контекст Вам никто не запрещает, но библиотека это делать и не заставляет. Проблема в том, что message часто бывают неразличимы, поскольку одни и те же параметры выводятся в разных местах функции или ловится ошибка, которая может тоже в разных местах выскочить одна и та же. И вы, анализируя лог, не в состоянии понять, в каком месте кода она выскочила и залогирована.
Именно для этого я советую сознательно различать точки логирования.
Действительно, вопросов больше, чем ответов.
Меня не оставляет ощущение, что мы на пороге открытия математического аппарата, который будет единообразно и точно описывать и лавины в горах и дюны в пустынях и волны на воде.
Скорее всего да. Или вы будите разбираться сами с перенаправлением в файл на уровне stdout.
Она не для этого. Она для высокофункциональных браузерных приложений, что и написано во первых строках.
А тащить в пользовательский браузер монста только ради логирования мне не хотелось. А тут - 62Кв. Это то, что надо.
То что автор статьи и автор пакета одно лицо, я доказывать Вам не буду. Наверное, вы не дочитали статью до конца и не посмотрели репозиторий проекта.
А что по сути неверно в этом предложении?
Авторы пакета сами пишут (цитата):
(Хотя ее название похоже на название библиотеки Java log4j, думать, что она будет вести себя так же, принесет вам лишь огорчения и замешательство.)
Спасибо, что заметили очепятку в сигнатуре. Глаз замылился. Исправлю и залью новую версию.
Буду признателен за другие замечания, если увидите.
А почему Вы решили, что автор не разработчик?
Спасибо! Я внимательно посмотрю.