Комментарии 42
А ничего, да, уютненько! Пожалуй возьму побаловаться.
Спасибо!
Спасибо!
А с андроидовским LogCat оно работаеть умеет? Если нет — реквестирую сборку библиотеки для андроид-программистов.
Нет нет, это только для Java SE/EE. На счет Андроида надо подумать. Я никогда не писал под него. Можете форкнуть и написать врапперы :)
Эм, я, конечно, все понимаю, но, по-моему,
и огрести очень возможные пересечения с локальными символами — по-моему — не самая хорошая идея.
Ну и да, как-то совсем странно видеть публикацию библиотеки совсем без javadoc.
import static logy.Logy.* как-то совсем жестоко замусоривает symbol space. Получить такие слова, как:- join
- group
- fetch
- quote
- export
и огрести очень возможные пересечения с локальными символами — по-моему — не самая хорошая идея.
Ну и да, как-то совсем странно видеть публикацию библиотеки совсем без javadoc.
javadoc пишется и будет в ближайшее время на ровне с документацией.
По поводу слов. Я думал над этим, но соблазн использовать красивые и понятные названия методов был настолько большим, что я не смог устоять :) Честно говоря не могу сказать на сколько часто я использовал данные названия для переменных/методов. «quote» точно ни разу не писал.
По поводу слов. Я думал над этим, но соблазн использовать красивые и понятные названия методов был настолько большим, что я не смог устоять :) Честно говоря не могу сказать на сколько часто я использовал данные названия для переменных/методов. «quote» точно ни разу не писал.
Автор, просто интересно, вы слышали про slf4j? Если да, то не очень понятны предпосылки создания вашей библиотеки. Какие у нее преимущества?
Слышал. Последний абзац поста как раз отвечает на вас вопрос.
В вашем подходе с DSL (который дает весьма сомнительные плюшки, кстати) есть один большой минус: куча вызовов instanceof и созданий массивов даже в тех случаях, когда сообщение не будет выводиться в лог
Нене. Ну про плюшки это вы зря. Каждому свое, мне например нравится писать так, как было показано в примерах. Насчет масивов и instanceof тут да — ничего не поделаешь, хотя можно кеширование какое-нибудь прикрутить. Ну это если тормозить будет. Пока ни кто не жаловался — значит летает все :)
Ответил вот тут habrahabr.ru/post/146762/#comment_4942054
Можно по подробнее о «динамическое определение параметров логированя (без явной инициализации логгера)». Есть подозрения что будут проблемы с производительностью.
Дада. Предыдущий комментарий как раз об этом.
Я знаю, что получать стек трейсы удовольствие не из дешевых, но я сознательно сделал именно так. Целевой функцией у меня было — удобство использования. К тому-же преждевременная оптимизация блаблабла… Если действительно будут с этим проблемы, я обещаю подумать над другим способом получения параметров.
Я знаю, что получать стек трейсы удовольствие не из дешевых, но я сознательно сделал именно так. Целевой функцией у меня было — удобство использования. К тому-же преждевременная оптимизация блаблабла… Если действительно будут с этим проблемы, я обещаю подумать над другим способом получения параметров.
Странно вы рассуждаете. Т.е. вы сначала предоставляете продукт а уже потом думаете о его производительности?
Удобство использования должно включать в себя оптимальную работу. Допустим я начал использовать вашу библиотеку а потом понимаю что он ужасно тупит при использовании. Что мне предложите делать тогда?
Удобство использования должно включать в себя оптимальную работу. Допустим я начал использовать вашу библиотеку а потом понимаю что он ужасно тупит при использовании. Что мне предложите делать тогда?
Эм… зафайлить баг и привести цифорки о том на сколько оно тормозит.
Этим разве не вы должны заниматься перед представлением вашей библиотеки? Таким образом тестировать ваш продукт будут другие разработчики?
Я проводил функциональное тестирование. Performance тестов у меня нет. Я и не планировал их делать. Я не хотел сделать «быстро», я хотел «просто сделать». А потом, если возникнут проблемы у меня или у кого-то еще уже можно было бы заняться оптимизацией. Кажется так делают большинство людей.
Если я правильно понял использовать эту библиотеку я должен на собственный страх и риск? «большинство людей» какое большинство? Логирование приложения одна из самых сложных задач в плане производительности и оптимизации, а вы даже не планировали performance тестов. Так «большинство хороших разработчиков» не делают.
Одна из основных проблем в системах логирования это скорость. Необходимо, чтобы логирование как можно меньше замедляло программу.
У Вас информация о классе и методе берется программно из стека вызовов, что обычно очень неоптимально, и всякие библиотеки типа log4j не рекомендуют вообще пользоваться такой возможностью в критичных к скорости программах.
Ну и по мелочи. Ваши вспомогательные функции принимаютс Object… а значит на каждый вызов оборачивают свои аргументы в массив, что тоже не прибавляет скорости.
У Вас информация о классе и методе берется программно из стека вызовов, что обычно очень неоптимально, и всякие библиотеки типа log4j не рекомендуют вообще пользоваться такой возможностью в критичных к скорости программах.
Ну и по мелочи. Ваши вспомогательные функции принимаютс Object… а значит на каждый вызов оборачивают свои аргументы в массив, что тоже не прибавляет скорости.
github.com/vkostyukov/logy/blob/master/src/main/java/logy/logger/FileLogger.java#L33
Открывать и закрывать файл на каждую запись в него? Не думаю, что это хорошая идея…
Открывать и закрывать файл на каждую запись в него? Не думаю, что это хорошая идея…
group(quote(upper(scalar(s)))) — не могу согласиться что это очень читаемо ))))
НЛО прилетело и опубликовало эту надпись здесь
Была где-то статья про историю логгеров в Java. Если кратко, каждый хотел сделать лучше и потому получилось много библиотек.
У нас тоже есть библиотека для более дружелюбного к программисту логгирования. Но, в отличие от вам, мы не стали переписывать весь логгер, вместо этого написали один класс с удобными функциями (в т.ч. и варианты с varargs), который затем вызывает ванильные методы log4j.
Советую и вам подумать в этом направлении…
У нас тоже есть библиотека для более дружелюбного к программисту логгирования. Но, в отличие от вам, мы не стали переписывать весь логгер, вместо этого написали один класс с удобными функциями (в т.ч. и варианты с varargs), который затем вызывает ванильные методы log4j.
Советую и вам подумать в этом направлении…
Конфигурировать как? Очень похоже на наколенную студенческую поделку с изобретением велосипеда. Если кому и надо будет такое, то это делается за 2 минуты путем враппинга slf4j/log4j/logback или что у вас там используется
Вы пост читали вообще?
Промахнулся с ответом
Да уж наверное. И даже не поленилсчя посмотреть код на гитхабе, который оставляет желать лучшего
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 или еще как-то менять исходные данные противоречит самой сути логгирования, ведь логи ведутся не для красоты, а чтобы потом было проще понять, в чем проблема. А вдруг проблема именно в регистре? А в логах все строки будут в одном и том же регистре.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Logy — логгер с человеческим лицом