Comments 42
А ничего, да, уютненько! Пожалуй возьму побаловаться.
Спасибо!
Спасибо!
-1
А с андроидовским LogCat оно работаеть умеет? Если нет — реквестирую сборку библиотеки для андроид-программистов.
0
Нет нет, это только для Java SE/EE. На счет Андроида надо подумать. Я никогда не писал под него. Можете форкнуть и написать врапперы :)
0
Там, насколько я вижу, все используемые вами классы вполне себе будут. Единственное — вместо вывода в файл или stream надо будет докрутить вариант вывода в logcat — можно по аналогии с «stream:err», например, сделать «logcat:something».
0
Эм, я, конечно, все понимаю, но, по-моему,
и огрести очень возможные пересечения с локальными символами — по-моему — не самая хорошая идея.
Ну и да, как-то совсем странно видеть публикацию библиотеки совсем без javadoc.
import static logy.Logy.*
как-то совсем жестоко замусоривает symbol space. Получить такие слова, как:- join
- group
- fetch
- quote
- export
и огрести очень возможные пересечения с локальными символами — по-моему — не самая хорошая идея.
Ну и да, как-то совсем странно видеть публикацию библиотеки совсем без javadoc.
+3
javadoc пишется и будет в ближайшее время на ровне с документацией.
По поводу слов. Я думал над этим, но соблазн использовать красивые и понятные названия методов был настолько большим, что я не смог устоять :) Честно говоря не могу сказать на сколько часто я использовал данные названия для переменных/методов. «quote» точно ни разу не писал.
По поводу слов. Я думал над этим, но соблазн использовать красивые и понятные названия методов был настолько большим, что я не смог устоять :) Честно говоря не могу сказать на сколько часто я использовал данные названия для переменных/методов. «quote» точно ни разу не писал.
0
Автор, просто интересно, вы слышали про slf4j? Если да, то не очень понятны предпосылки создания вашей библиотеки. Какие у нее преимущества?
0
Слышал. Последний абзац поста как раз отвечает на вас вопрос.
0
В вашем подходе с DSL (который дает весьма сомнительные плюшки, кстати) есть один большой минус: куча вызовов instanceof и созданий массивов даже в тех случаях, когда сообщение не будет выводиться в лог
+1
Нене. Ну про плюшки это вы зря. Каждому свое, мне например нравится писать так, как было показано в примерах. Насчет масивов и instanceof тут да — ничего не поделаешь, хотя можно кеширование какое-нибудь прикрутить. Ну это если тормозить будет. Пока ни кто не жаловался — значит летает все :)
-1
Пока никто и не пользовался, поэтому жалоб и нет :)
Насчет массивов можно решить по другому:
Насчет массивов можно решить по другому:
logger.debug("Can't find {quote,upper} in {quote,upper}", "c", s);
0
У вас плюшек то и нет никаких, только изменение регистра и закавычивание.
0
Ответил вот тут habrahabr.ru/post/146762/#comment_4942054
-1
Можно по подробнее о «динамическое определение параметров логированя (без явной инициализации логгера)». Есть подозрения что будут проблемы с производительностью.
0
Дада. Предыдущий комментарий как раз об этом.
Я знаю, что получать стек трейсы удовольствие не из дешевых, но я сознательно сделал именно так. Целевой функцией у меня было — удобство использования. К тому-же преждевременная оптимизация блаблабла… Если действительно будут с этим проблемы, я обещаю подумать над другим способом получения параметров.
Я знаю, что получать стек трейсы удовольствие не из дешевых, но я сознательно сделал именно так. Целевой функцией у меня было — удобство использования. К тому-же преждевременная оптимизация блаблабла… Если действительно будут с этим проблемы, я обещаю подумать над другим способом получения параметров.
0
Странно вы рассуждаете. Т.е. вы сначала предоставляете продукт а уже потом думаете о его производительности?
Удобство использования должно включать в себя оптимальную работу. Допустим я начал использовать вашу библиотеку а потом понимаю что он ужасно тупит при использовании. Что мне предложите делать тогда?
Удобство использования должно включать в себя оптимальную работу. Допустим я начал использовать вашу библиотеку а потом понимаю что он ужасно тупит при использовании. Что мне предложите делать тогда?
0
Эм… зафайлить баг и привести цифорки о том на сколько оно тормозит.
+1
Этим разве не вы должны заниматься перед представлением вашей библиотеки? Таким образом тестировать ваш продукт будут другие разработчики?
0
Я проводил функциональное тестирование. Performance тестов у меня нет. Я и не планировал их делать. Я не хотел сделать «быстро», я хотел «просто сделать». А потом, если возникнут проблемы у меня или у кого-то еще уже можно было бы заняться оптимизацией. Кажется так делают большинство людей.
0
Если я правильно понял использовать эту библиотеку я должен на собственный страх и риск? «большинство людей» какое большинство? Логирование приложения одна из самых сложных задач в плане производительности и оптимизации, а вы даже не планировали performance тестов. Так «большинство хороших разработчиков» не делают.
0
Одна из основных проблем в системах логирования это скорость. Необходимо, чтобы логирование как можно меньше замедляло программу.
У Вас информация о классе и методе берется программно из стека вызовов, что обычно очень неоптимально, и всякие библиотеки типа log4j не рекомендуют вообще пользоваться такой возможностью в критичных к скорости программах.
Ну и по мелочи. Ваши вспомогательные функции принимаютс Object… а значит на каждый вызов оборачивают свои аргументы в массив, что тоже не прибавляет скорости.
У Вас информация о классе и методе берется программно из стека вызовов, что обычно очень неоптимально, и всякие библиотеки типа log4j не рекомендуют вообще пользоваться такой возможностью в критичных к скорости программах.
Ну и по мелочи. Ваши вспомогательные функции принимаютс Object… а значит на каждый вызов оборачивают свои аргументы в массив, что тоже не прибавляет скорости.
+1
github.com/vkostyukov/logy/blob/master/src/main/java/logy/logger/FileLogger.java#L33
Открывать и закрывать файл на каждую запись в него? Не думаю, что это хорошая идея…
Открывать и закрывать файл на каждую запись в него? Не думаю, что это хорошая идея…
0
group(quote(upper(scalar(s)))) — не могу согласиться что это очень читаемо ))))
+1
UFO just landed and posted this here
Была где-то статья про историю логгеров в Java. Если кратко, каждый хотел сделать лучше и потому получилось много библиотек.
У нас тоже есть библиотека для более дружелюбного к программисту логгирования. Но, в отличие от вам, мы не стали переписывать весь логгер, вместо этого написали один класс с удобными функциями (в т.ч. и варианты с varargs), который затем вызывает ванильные методы log4j.
Советую и вам подумать в этом направлении…
У нас тоже есть библиотека для более дружелюбного к программисту логгирования. Но, в отличие от вам, мы не стали переписывать весь логгер, вместо этого написали один класс с удобными функциями (в т.ч. и варианты с varargs), который затем вызывает ванильные методы log4j.
Советую и вам подумать в этом направлении…
+2
Конфигурировать как? Очень похоже на наколенную студенческую поделку с изобретением велосипеда. Если кому и надо будет такое, то это делается за 2 минуты путем враппинга slf4j/log4j/logback или что у вас там используется
-1
Вы пост читали вообще?
-1
Промахнулся с ответом
0
Да уж наверное. И даже не поленилсчя посмотреть код на гитхабе, который оставляет желать лучшего
0
log4j? прошлый век, все давно используют slf4j + logback
выведет
Приводить к UPPER CASE или еще как-то менять исходные данные противоречит самой сути логгирования, ведь логи ведутся не для красоты, а чтобы потом было проще понять, в чем проблема. А вдруг проблема именно в регистре? А в логах все строки будут в одном и том же регистре.
String s[] = {"a", "b"};
log.warn("Can't find '{}' in {}", "c", s);
выведет
22:28:19.443 [main] WARN Test1 - Can't find 'c' in [a, b]
Приводить к UPPER CASE или еще как-то менять исходные данные противоречит самой сути логгирования, ведь логи ведутся не для красоты, а чтобы потом было проще понять, в чем проблема. А вдруг проблема именно в регистре? А в логах все строки будут в одном и том же регистре.
0
Sign up to leave a comment.
Logy — логгер с человеческим лицом