3 ms·

Specifics, please. I just implemented a logging backend for slf4j on Android in roughly ~1 hour with virtually no prior knowledge other than generally how to us

by koko775 14y ago

Specifics, please. I just implemented a logging backend for slf4j on Android in roughly ~1 hour with virtually no prior knowledge other than generally how to use slf4j and how to use Android's Log class. It just worked, and it was pretty darn simple, and now I have fancy log messages. I even customized the tags so that instead of com.example.some.path.to.Something, I can summarize that to c.e.s.p.to.Something.

bborud 14y ago
Writing a logging backend for slf4j isn't hard. Anyone unable to do that should not be programming. Trying to figure out how to a) get lots of components that rely on wildly different logging frameworks and even multiple versions of the same logging frameworks and b) try to distill that into common practices in an engineering organization, is hard. In part because you have to spend two hours explaining the problems we've been through every time someone thinks all these problems have a 5 minute fix. (And the slf4j technique of placing a bridge in the class path and hoping for the best is just priceless. That deserves an entire hour of slow clap)
- koko775 14y ago
  Okay, now we're getting somewhere, but as someone who has used Java more client-side than server-side, I'm not familiar with the problems everyone's else been through. I would love for you to enlighten me, if you could! Also, what would you substitute in place of StaticLoggerBinder? It did strike me as somewhat janky to rely on a class with a matching name and class just existing.
  - bborud 14y ago
    The problem is not software. The problem is people. Rather than trying to explain the problem (which most people who work on logging struggle to see), let me outline how you determine when the problem is either solved or absent. The problem is solved when people like me (a hands-on system architect who writes code and tries to make decisions on behalf of a number of developers) do not have to think about logging APIs, facades or backends anymore. When nobody in my organization has to spend time trying to resolve the conflicts that arise from different logging technologies (and different versions of same technologies) being in use in the same system. We have an example of that in Java: the collection classes. For most bread-and-butter uses Java has List, Map and Set types that people can just use. They are well designed, well documented and you can count on them to be available at no extra cost. It is unusual for a non-mad() Java programmer to feel the need to introduce extra dependencies for simple lists, sets, maps etc. You most likely are not going to feel the pain of logging chaos if you are writing a single application. If you try to make decisions on behalf of 50+ projects, some of which rely on an obscene number of libraries, that pain will manifest itself every day and you will re-live the same pointless discussions and get the same pointless advice over and over and over. Hope this sheds some light on why I think what I think. () there are idiots who depend on third party implementations where the types in J2SE would suffice.

by koko775 14y ago

bborud 14y ago

Writing a logging backend for slf4j isn't hard. Anyone unable to do that should not be programming. Trying to figure out how to a) get lots of components that rely on wildly different logging frameworks and even multiple versions of the same logging frameworks and b) try to distill that into common practices in an engineering organization, is hard. In part because you have to spend two hours explaining the problems we've been through every time someone thinks all these problems have a 5 minute fix. (And the slf4j technique of placing a bridge in the class path and hoping for the best is just priceless. That deserves an entire hour of slow clap)

koko775 14y ago
Okay, now we're getting somewhere, but as someone who has used Java more client-side than server-side, I'm not familiar with the problems everyone's else been through. I would love for you to enlighten me, if you could! Also, what would you substitute in place of StaticLoggerBinder? It did strike me as somewhat janky to rely on a class with a matching name and class just existing.
- bborud 14y ago
  The problem is not software. The problem is people. Rather than trying to explain the problem (which most people who work on logging struggle to see), let me outline how you determine when the problem is either solved or absent. The problem is solved when people like me (a hands-on system architect who writes code and tries to make decisions on behalf of a number of developers) do not have to think about logging APIs, facades or backends anymore. When nobody in my organization has to spend time trying to resolve the conflicts that arise from different logging technologies (and different versions of same technologies) being in use in the same system. We have an example of that in Java: the collection classes. For most bread-and-butter uses Java has List, Map and Set types that people can just use. They are well designed, well documented and you can count on them to be available at no extra cost. It is unusual for a non-mad() Java programmer to feel the need to introduce extra dependencies for simple lists, sets, maps etc. You most likely are not going to feel the pain of logging chaos if you are writing a single application. If you try to make decisions on behalf of 50+ projects, some of which rely on an obscene number of libraries, that pain will manifest itself every day and you will re-live the same pointless discussions and get the same pointless advice over and over and over. Hope this sheds some light on why I think what I think. () there are idiots who depend on third party implementations where the types in J2SE would suffice.