5 ms·

I'm not sure this article does a good enough job of explaining why it's a code smell. Aside from the event bus code looking slightly better, I don't see any big

by dimgl 5y ago

I'm not sure this article does a good enough job of explaining why it's a code smell. Aside from the event bus code looking slightly better, I don't see any big advantages. One disadvantage is that if you have a big class with lots of different events, you now have to import all of your events rather than just importing the singular logger. Typically I only resort to logging in situations where I don't want to propagate an error but I do want to log that an error happened. I also sometimes get lazy and debug using logs. I'm trying to avoid this as much as possible and instead debug by attaching to a process and using breakpoints. However this article doesn't touch on either of these scenarios. Also, log4j's vulnerability had nothing to do with the actual concept of logging. AFAIK the vulnerability came from log4j's JNDI lookup functionality, which was not doing any kind of input sanitization which allowed attackers to perform remote code execution. I was really looking forward to a post on logging as a code smell, mostly geared towards inexperienced developers. Pretty disappointed with the actual post.

gregoryl 5y ago
Awful hard to attach a debugger to a production system?
- gkhartman 5y ago
  Agreed. In a perfect world all production bugs can be reproduced on a test instance, but that's often not the case in the real world. Also, I've seen plenty of timing sensitive bugs that get covered up by the delay introduced by the attached debugger. The much feared "Heisenbug".
- rad_gruchalski 5y ago
  What if you don’t have physical access to a production system?
  - 908B64B197 5y ago
    That's an organizational problem, not a technical one.
    - ahonhn 5y ago
      yeah? well its a pretty standard organisational problem too
    - sorokod 5y ago
      That developers don't have live access is dictated by industry rules in some cases. Not a problem but rather a fact of life.
      - xwolfi 5y ago
        So who has access, if at all ? If nobody has access, how is deployment done or setup ? Can you imagine the "deployer" person ... learning or being replaced by a developer ? This is an organisational weakness not to have figured out a way to make the people responsible for production, also responsible for reproduction and bug fixing. I've seen companies with a full team of developers who never add new features but only reproduce and fix the errors of the other feature teams, companies with read-only access to obfuscated informations good enough to reproduce without any client reference, companies who localize enough people in each jurisdiction the production is regulated in rather than have everyone out and unable to reach it. It's an organisational problem, fix it instead of saying it's impossible to be creative with it. And if my experience if anything to go by, regulators and auditors are either misunderstood in wayyy too conservative ways or are themselves misunderstanding in conservative ways their own rules: there always are ways to explain that it's more risky not to maintain production rather than let if rot slowly because "I can't ssh to the box". While it's always easier to be conservative with vague rules, it's also always possible to be clear faced with absurdity and it's rare people embrace the absurdity: usually they tell you: "I'll lose my job if I don't follow the rule X put in place 20 years ago" and not "I want the production to be offline the entire day during heavy traffic because I think clients prefer when they can't use our software". So, easy: "20 years ago, X. made a mistake - let's show him", and the answer from X is almost always "Why the fuck are you even asking me, ofc exceptions are possible, fix now we do the process after". And "doing the process" is often to can the old rule, or make it change so much it loses all fear factor and start being actually useful. Give up and rot, give feedback and soar :)
- _ZeD_ 5y ago
  I hope so
- theshrike79 5y ago
  Usually impossible. It's easier to tell the customers to send the logs from the relevant timeframe and narrow down the problem. Maybe instruct them to up the log level a bit and see if the problem surfaces again. Always log enough to see where the bug is just by looking at the logs. Getting permission to deploy a new version with additional logging might be a bit of a pain.
908B64B197 5y ago
Logs are useful because they give an idea of what was going on when a particular failure happened. More context than a call stack. > Pretty disappointed with the actual post. I am as well. What the author describes isn't new or novel, it's been in Windows in the form of ETW since the early 90's. And Windows wasn't the first OS to get it. Had the author taken a serious System/OS class he would have known. You can't build high performance applications without using some scheme similar to what the author describe.
- joshka 5y ago
  It sounds like the thing you're missing is the concept of "context" not "logging". If you frame the question as what information do I need to diagnose a problem with this code if (and only if) it fails, and likewise what info when it succeeds do you end up with logging as the best solution? Probably not - events seem to be a better perspective on this. >Had the author taken a serious System/OS class he would have known. I'm guessing the author probably did so - this comes across as fairly ascerbic btw.

by dimgl 5y ago

gregoryl 5y ago

Awful hard to attach a debugger to a production system?

gkhartman 5y ago
Agreed. In a perfect world all production bugs can be reproduced on a test instance, but that's often not the case in the real world. Also, I've seen plenty of timing sensitive bugs that get covered up by the delay introduced by the attached debugger. The much feared "Heisenbug".
rad_gruchalski 5y ago
What if you don’t have physical access to a production system?
- 908B64B197 5y ago
  That's an organizational problem, not a technical one.
  - ahonhn 5y ago
    yeah? well its a pretty standard organisational problem too
  - sorokod 5y ago
    That developers don't have live access is dictated by industry rules in some cases. Not a problem but rather a fact of life.
    - xwolfi 5y ago
      So who has access, if at all ? If nobody has access, how is deployment done or setup ? Can you imagine the "deployer" person ... learning or being replaced by a developer ? This is an organisational weakness not to have figured out a way to make the people responsible for production, also responsible for reproduction and bug fixing. I've seen companies with a full team of developers who never add new features but only reproduce and fix the errors of the other feature teams, companies with read-only access to obfuscated informations good enough to reproduce without any client reference, companies who localize enough people in each jurisdiction the production is regulated in rather than have everyone out and unable to reach it. It's an organisational problem, fix it instead of saying it's impossible to be creative with it. And if my experience if anything to go by, regulators and auditors are either misunderstood in wayyy too conservative ways or are themselves misunderstanding in conservative ways their own rules: there always are ways to explain that it's more risky not to maintain production rather than let if rot slowly because "I can't ssh to the box". While it's always easier to be conservative with vague rules, it's also always possible to be clear faced with absurdity and it's rare people embrace the absurdity: usually they tell you: "I'll lose my job if I don't follow the rule X put in place 20 years ago" and not "I want the production to be offline the entire day during heavy traffic because I think clients prefer when they can't use our software". So, easy: "20 years ago, X. made a mistake - let's show him", and the answer from X is almost always "Why the fuck are you even asking me, ofc exceptions are possible, fix now we do the process after". And "doing the process" is often to can the old rule, or make it change so much it loses all fear factor and start being actually useful. Give up and rot, give feedback and soar :)
_ZeD_ 5y ago
I hope so
theshrike79 5y ago
Usually impossible. It's easier to tell the customers to send the logs from the relevant timeframe and narrow down the problem. Maybe instruct them to up the log level a bit and see if the problem surfaces again. Always log enough to see where the bug is just by looking at the logs. Getting permission to deploy a new version with additional logging might be a bit of a pain.

908B64B197 5y ago

Logs are useful because they give an idea of what was going on when a particular failure happened. More context than a call stack. > Pretty disappointed with the actual post. I am as well. What the author describes isn't new or novel, it's been in Windows in the form of ETW since the early 90's. And Windows wasn't the first OS to get it. Had the author taken a serious System/OS class he would have known. You can't build high performance applications without using some scheme similar to what the author describe.

joshka 5y ago
It sounds like the thing you're missing is the concept of "context" not "logging". If you frame the question as what information do I need to diagnose a problem with this code if (and only if) it fails, and likewise what info when it succeeds do you end up with logging as the best solution? Probably not - events seem to be a better perspective on this. >Had the author taken a serious System/OS class he would have known. I'm guessing the author probably did so - this comes across as fairly ascerbic btw.