spiff Jun 29 2012 at 13:30

Logy — логгер с человеческим лицом

4 min

Java*Open source*

+16

Comments 42

VoVanJinn Jun 29 2012 at 13:42

А ничего, да, уютненько! Пожалуй возьму побаловаться.
Спасибо!

spiff Jun 29 2012 at 13:44

Пожалуйста! :) Отправляйте баг-репорты, уверен я протестировал не все.

BlackSwan Jun 29 2012 at 14:12

А с андроидовским LogCat оно работаеть умеет? Если нет — реквестирую сборку библиотеки для андроид-программистов.

spiff Jun 29 2012 at 14:14

Нет нет, это только для Java SE/EE. На счет Андроида надо подумать. Я никогда не писал под него. Можете форкнуть и написать врапперы :)

GreyCat Jun 29 2012 at 14:18

Там, насколько я вижу, все используемые вами классы вполне себе будут. Единственное — вместо вывода в файл или stream надо будет докрутить вариант вывода в logcat — можно по аналогии с «stream:err», например, сделать «logcat:something».

spiff Jun 29 2012 at 14:23

Дада. Можно будет просто создать новый класс расширяющий logy.logger.Logger

GreyCat Jun 29 2012 at 14:16

Эм, я, конечно, все понимаю, но, по-моему, import static logy.Logy.* как-то совсем жестоко замусоривает symbol space. Получить такие слова, как:

join
group
fetch
quote
export

и огрести очень возможные пересечения с локальными символами — по-моему — не самая хорошая идея.

Ну и да, как-то совсем странно видеть публикацию библиотеки совсем без javadoc.

spiff Jun 29 2012 at 14:22

javadoc пишется и будет в ближайшее время на ровне с документацией.

По поводу слов. Я думал над этим, но соблазн использовать красивые и понятные названия методов был настолько большим, что я не смог устоять :) Честно говоря не могу сказать на сколько часто я использовал данные названия для переменных/методов. «quote» точно ни разу не писал.

AlexanderYastrebov Jun 29 2012 at 14:33

Автор, просто интересно, вы слышали про slf4j? Если да, то не очень понятны предпосылки создания вашей библиотеки. Какие у нее преимущества?

spiff Jun 29 2012 at 14:34

Слышал. Последний абзац поста как раз отвечает на вас вопрос.

AlexanderYastrebov Jun 29 2012 at 14:47

В вашем подходе с DSL (который дает весьма сомнительные плюшки, кстати) есть один большой минус: куча вызовов instanceof и созданий массивов даже в тех случаях, когда сообщение не будет выводиться в лог

spiff Jun 29 2012 at 14:52

Нене. Ну про плюшки это вы зря. Каждому свое, мне например нравится писать так, как было показано в примерах. Насчет масивов и instanceof тут да — ничего не поделаешь, хотя можно кеширование какое-нибудь прикрутить. Ну это если тормозить будет. Пока ни кто не жаловался — значит летает все :)

AlexanderYastrebov Jun 29 2012 at 14:57

Пока никто и не пользовался, поэтому жалоб и нет :)
Насчет массивов можно решить по другому:

logger.debug("Can't find {quote,upper} in {quote,upper}", "c", s);

spiff Jun 29 2012 at 15:01

Хм. nice try :) Такой подход где-то используется? Или только что придумали?

AlexanderYastrebov Jun 29 2012 at 15:03

Ну это импровизация на тему расширения возможностей синтаксиса slf4j :)

AlexanderYastrebov Jun 29 2012 at 15:02

У вас плюшек то и нет никаких, только изменение регистра и закавычивание.

spiff Jun 29 2012 at 15:04

Ну как это и есть плюшки.

alexandro Jun 29 2012 at 14:34

я просто оставлю эту ссылку:
тыц
чтобы было понятно, почему в slf4j сделано так, как сделано.

spiff Jun 29 2012 at 14:42

Ответил вот тут habrahabr.ru/post/146762/#comment_4942054

Timmmm Jun 29 2012 at 14:36

Можно по подробнее о «динамическое определение параметров логированя (без явной инициализации логгера)». Есть подозрения что будут проблемы с производительностью.

spiff Jun 29 2012 at 14:41

Дада. Предыдущий комментарий как раз об этом.

Я знаю, что получать стек трейсы удовольствие не из дешевых, но я сознательно сделал именно так. Целевой функцией у меня было — удобство использования. К тому-же преждевременная оптимизация блаблабла… Если действительно будут с этим проблемы, я обещаю подумать над другим способом получения параметров.

Timmmm Jun 29 2012 at 14:55

Странно вы рассуждаете. Т.е. вы сначала предоставляете продукт а уже потом думаете о его производительности?
Удобство использования должно включать в себя оптимальную работу. Допустим я начал использовать вашу библиотеку а потом понимаю что он ужасно тупит при использовании. Что мне предложите делать тогда?

spiff Jun 29 2012 at 14:58

Эм… зафайлить баг и привести цифорки о том на сколько оно тормозит.

Timmmm Jun 29 2012 at 15:16

Этим разве не вы должны заниматься перед представлением вашей библиотеки? Таким образом тестировать ваш продукт будут другие разработчики?

spiff Jun 29 2012 at 15:20

Я проводил функциональное тестирование. Performance тестов у меня нет. Я и не планировал их делать. Я не хотел сделать «быстро», я хотел «просто сделать». А потом, если возникнут проблемы у меня или у кого-то еще уже можно было бы заняться оптимизацией. Кажется так делают большинство людей.

Timmmm Jun 29 2012 at 15:25

Если я правильно понял использовать эту библиотеку я должен на собственный страх и риск? «большинство людей» какое большинство? Логирование приложения одна из самых сложных задач в плане производительности и оптимизации, а вы даже не планировали performance тестов. Так «большинство хороших разработчиков» не делают.

spiff Jun 29 2012 at 15:26

зануда

Timmmm Jun 29 2012 at 15:27

Есть немного )

xonix Jun 29 2012 at 14:39

Одна из основных проблем в системах логирования это скорость. Необходимо, чтобы логирование как можно меньше замедляло программу.
У Вас информация о классе и методе берется программно из стека вызовов, что обычно очень неоптимально, и всякие библиотеки типа log4j не рекомендуют вообще пользоваться такой возможностью в критичных к скорости программах.
Ну и по мелочи. Ваши вспомогательные функции принимаютс Object… а значит на каждый вызов оборачивают свои аргументы в массив, что тоже не прибавляет скорости.

xonix Jun 29 2012 at 14:56

github.com/vkostyukov/logy/blob/master/src/main/java/logy/logger/FileLogger.java#L33

Открывать и закрывать файл на каждую запись в него? Не думаю, что это хорошая идея…

spiff Jun 29 2012 at 15:00

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

OnoIt Jul 1 2012 at 12:06

Нормальная. Когда пользователи захотят 1 лог-файл для 4 серверов, придется добавлять дополнительно блокировку при открытии файла.

Ents Jun 29 2012 at 15:39

group(quote(upper(scalar(s)))) — не могу согласиться что это очень читаемо ))))

spiff Jun 29 2012 at 17:10

Возможно пример не очень удачный, можно было просто написать «s» — как массив.

UFO landed and left these words here

voronaam Jun 29 2012 at 21:22

Была где-то статья про историю логгеров в Java. Если кратко, каждый хотел сделать лучше и потому получилось много библиотек.

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

Советую и вам подумать в этом направлении…

xonix Jun 29 2012 at 21:39

>Была где-то статья про историю логгеров в Java.

habrahabr.ru/post/113145/

skywatcher Jun 29 2012 at 23:23

Конфигурировать как? Очень похоже на наколенную студенческую поделку с изобретением велосипеда. Если кому и надо будет такое, то это делается за 2 минуты путем враппинга slf4j/log4j/logback или что у вас там используется

spiff Jun 30 2012 at 08:04

Вы пост читали вообще?

skywatcher Jun 30 2012 at 12:05

Промахнулся с ответом

skywatcher Jun 30 2012 at 12:05

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

relgames Jul 4 2012 at 01:17

log4j? прошлый век, все давно используют slf4j + logback

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 или еще как-то менять исходные данные противоречит самой сути логгирования, ведь логи ведутся не для красоты, а чтобы потом было проще понять, в чем проблема. А вдруг проблема именно в регистре? А в логах все строки будут в одном и том же регистре.