|
Generally speaking, I use logs for open fires and camping.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Quote: open fires
I imagine you use logs made of wood to keep the fire burning and (for) other leasure activities around the camp.
|
|
|
|
|
If they are big enough, you can sit on them as well!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
camping or trip chairs and tents are my favorites.
modified 4-Jul-22 15:27pm.
|
|
|
|
|
If you are camping by car, then yes. But on a bike, A tent is a necessity (and the rest of the space is free for food and beer) 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
We do a lot of ETL work. Each ETL task takes a different amount of time. We use the logs to calculate the average time for each task to aid in scheduling the next run -- and thereby perform the historically longest-running tasks first.
Similarly, we track record counts and signal an error if a record count falls outside the expected range ( +/- some factor).
|
|
|
|
|
Thanks Piebaldconsult I had to check online the ETL abbreviation for its meaning. That`s field I wasn`t familiar with.
|
|
|
|
|
This is such an insanely huge topic of discussion.
Here's what we do:
- Every exception thrown in our code gets logged
- When we fix a bug that's due to odd input or conditions we generally log the odd condition up to the point where it's common enough we feel we have a handle on it's many guises
- When there's a spot where the code simply cannot, ever, in a million years be reached, and it's reached, we log it.
- When there are failures of external services we might log them in order to work out what conditions will cause it to fail so we can work on preemptively not causing those conditions
- When conditions in our app become extreme (eg serious user load, serious queue back-ups etc) we log them
Some of these logs are for debugging, some for planning, some of these logs are used to trigger alerts, and some for our own amusement.
cheers
Chris Maunder
|
|
|
|
|
Don't you just wish you could have a loonie for every time bullet point 3 has happened?
Shoot, I could have wound up chasing Elon Musk in the Forbes 500. 
|
|
|
|
|
I know, right? And you stare and you stare, and you run every test and scenario and it's simply, positively, absolutely impossible.
And blip. Another log entry pops up.
cheers
Chris Maunder
|
|
|
|
|
Seen this too many times to count. Unbelievably frustrating at times.
|
|
|
|
|
We've had similar situations in so many oddball scenarios I added a dynamic counter window to our tracing app. Rather than watching for an event to go flying by(*), it's easier to see the count increment.
(*) Our product is multicomputer, multiprocess, and multithreaded. Our logging records hundreds or even thousands of events per second, depending on what the thing is doing.
Software Zen: delete this;
|
|
|
|
|
Agree. Huge topic of discussion. Lots of requirements, lots of conditions, and even more requirements.
Start with first order requirements, such as source, frequency, etc.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Sorry not much to add. Chris said it all.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Quote: Huge topic of discussion
at least there is agreement it`s an interesting topic, I think one could say that any recording in a digital format with a date attached is a type of log.
|
|
|
|
|
the same way as one could say any data in a file is a database: a huge stretch of the imagination!
|
|
|
|
|
Yes; for (3), the best I can do is a "Logic error" message.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Every prepared statement that is about to run, the parameters to the statement, the number of rows returned with how long it took.
|
|
|
|
|
Just be aware of sensitive parameter values.
|
|
|
|
|
sounds like a constructive advice thanks
|
|
|
|
|
I use logs to keep track of users so I can say "I told you not to do that!"
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
spying on poor people, how cruel, that`s an interesting logging use case.
modified 6-Jul-22 11:06am.
|
|
|
|
|
I'm communicating with external devices so I log the communication, both what gets transferred & what settings are used for sending/receiving (yup, they're separate, my professional life's weird albeit cool). I don't log the internal workings outside of few debug cases as those get stabilized by unit tests.
I also output a bit of general program info on start. Version, copyright (of course, that's the most important part of all this), relevant environment variables if applicable.
|
|
|
|
|
I have worked on lots of simulators, telescope and sensor control hardware. These desktop applications operate as processes, so progress through their various tasks is logged, as well as important choices that the software makes throughout the process, and substantive I/O values and events. Naturally unexpected events are logged too, as well as meta-info about software modules and hardware devices. Plus whatever extras we need to track down difficult problems.
Often the goal is to provide the user with the right amount of info to help them solve problems themselves without overwhelming them with cryptic detail, but make the detail available when we need to step in. For example, putting in full file paths saves us a lot of tech support calls when the user cannot find their results, or have a typo in their configuration file. Always include the complete software version (and licensed feature level) that produced the log, too.
The rest of the time a log is a useful history of what data as produced, and how.
- Owen -
|
|
|
|
|
I use a singleton, CLogEntry, so I can make 1 line log entries anyplace or time.
Here, someone copied a folder from one place to another:
CLogEntry.MakeLogEntry(CDefines.TYPE_FOLDER, pFolderInfo.nID, CDefines.LOG_ACTION_COPIED, pFileInfo.m_szTitle);
It adds a date and user ID stamp when it write to the table. So any place something notable happens, I can pop in a single line call and save the info.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
