4 ms·
I'm going to weigh in on my opinionated library for logging: [woveon-logger](https://www.npmjs.com/package/woveon-logger https://www.npmjs.com/package/woveon-lo
by cwingrav 8y ago
I'm going to weigh in on my opinionated library for logging: [woveon-logger](https://www.npmjs.com/package/woveon-logger https://www.npmjs.com/package/woveon-logger) (js). Sorry if that's a no-no, but nobody seems to use my much loved library anyway.
The multiple levels are nice, especially for logging errors in production and tracking general information of your software. But in development, logging is often about tracking a particular aspect in your code. You need something that logs to a particular aspect that you are working on, and then can turn off that aspect once you move on. In the future, you often find yourself back to debug and need to flip that aspect back on again.
Summary: Log levels of info, warn and error all have a place. Logging to aspects is valuable during development, easy to turn off for production and useful when returning to debug.
- Karrot_Kream 8y agoWouldn't this be the same as naming loggers? Many logging frameworks allow you to name a logger and just reference that. From there, you can enable or disable named loggers, and get this same "apect" that you talk about.
- hinkley 8y agoLogging is one of the weirder cross cutting concerns, for many reasons but especially including the one you mention. We had to roll back an upgrade last month because one nonfatal (but still pretty bad) problem was generating a ridiculous amount of log entries. We had no way to turn it off or throttle it, so we rolled back. I have fantasized for years about a programming language with a small runtime that supports instrumentation of the code, not just for debugging and profiling, but for logging as well. Logging becomes a set of conditional breakpoints stored with or at least near the code and you can tweak them individually. Something akin to applying the 80/20 rule to Aspect Oriented Programming. We fake this by implementing logging frameworks that try to short circuit out cheaply. But it really only pays off if you can marshal the arguments to the logger very cheaply, and you still have problems with third party code, which can't know that you've got workarounds for problems they consider to be fatal, and are therefore so noisy at the WARN or INFO log levels that you can't see your own log entries (Apache Foundation, I'm looking at you).
- Rapzid 8y agoCheck out log points: https://code.visualstudio.com/docs/editor/debugging#_logpoints https://code.visualstudio.com/docs/editor/debugging#_logpoin...
- hinkley 8y agoIt's buried but my IDE has a similar feature. I meant support for running systems, not local development.
- Rapzid 8y ago"Logpoints are especially useful for injecting logging while debugging production servers that cannot be paused or stopped." There is a lot more going on with them than you might realize. Not sure how coupled it is to the nodejs/kubernetes/Azure stuff they have built into VSCode, but it seems like a working example of the future. Sorta like time travel debugging in node-chakracore. Windows has this facility called EWT that lets you setup all sorts of eventing/tracing that is actually not present(the calls) in the code unless the EWT facility injects the code necessary to enable it into the running process. This allows you to dynamically enable and disable event sources based on stuff like.. whether or not something is currently subscribing to it. Worth looking into just for the sheer amazement of it if you are not a Windows developer and familiar with it.
- deleted 8y ago[deleted]