They are like seeing what's going on in peoples' minds, what they're up to and how all the shit you built it behaving.
But most people don't look at them.
Oh, but some logs are shit. They really are terrible, and cannot be used.
So there are 2 skills you need: excellent log-reading skills, and excellent log-writing skills. We'll cover the reading skills first, because you'll sympathise with the readers of bad logs and better understand how to read good ones.
Reading a log
Logs are your best friend. But there are good logs and there are bad. Good logs lead you very quickly to the problem, sometimes entirely without any searching. For example, suppose you forgot to configure "config.some_property". There are two ways of reporting this in the logs:Expected String, got NullOr
config.some_property was empty. You should set this in config/some_file...Sure, this is a little more maintenance when config/some_file gets pushed out into config/special/things.rb, but the hours you save the rest of the world (including your future self) far outweigh the few minutes you lose updating the message.
There are other logs which are necessarily terse. Server and DB access logs are short and their meaning only reveals itself when you consider the implications of each line, rather than blankly look at it hoping it'll tell you more.
Broadly speaking, a lot of access or more abstract logs look like this
2012 Oct 04 some event happenedThe details of the log vary from a traceroute, through server access logs and DB query logs the format is going to be: something happened around this time. What you need to understand, as the crack debugger you are is what the something that happened implies. Logs being terse, inherently exclude a lot of data and only expose the main event which happened; the hit, the ping, the login.
When reading logs you need to understand what happens behind each event. Take as two examples, a GET and POST from an Apache log.
123.234.123.234 - - [04/Oct/2012:22:31:23 +0000] "POST /shop/api/v1/index/ HTTP/1.1" 200 158679 13234.123.234.123 - - [04/Oct/2012:22:38:36 +0000] "GET /shop/tea/our-teas.html HTTP/1.1" 200 5264 0The two calls tell you two very different stories, but the difference between log entries isn't where you should start from. Start from what you expect. This is what [REF] calls [check term] mental simulation; the coder simulates what happens in their mind.
Logs. The good and the bad.
Good logs translate to this:You need to change the/file/here.rb on line 100 to something like: Fix.the.problem (123)Bad logs read like this:
Something is badThe first thing to know about logs if you're a developer is that you create them. Assume you create bad logs, read everything you create as a bad log because someone else will and then make it better. Direct the debugger (the person reading the message) to somewhere that will help them fix the problem.
