Logging advice

Ok, an actual post about doing things right, instead of me venting my spleen.

So, let's talk about logging messages.

When writing logging messages for technical use - monitoring, statistics, etc, pick a separating character that is not part of the various fields you have interest in.

For example, most log messages will include a timestamp, so use of ':' is out.  Likewise, if the timestamps include the date, the '/' or '-' is right out.

A good choice for the field divider is the '|', and then the use of spaces as separation of the subfields.

It's the goddamn 21st century....

Why is someone declaring a message string with only 256 characters on a server-side program?  I mean, we are running on systems with hundreds of gigs of RAM, and it's for a freaking LOG MESSAGE, local variable, on the fucking stack.

But 256 characters it was, and  we decided we wanted to log a command line for a Java program, so between the log4j path argument and the Java binary path, it was 270 chars long, and it stomped on the stack, leading to a premature exit.

The Mismeasurement of Code

Christ on a crutch.

My PM is suddenly gung-ho on getting measurements for "KPIs", and beaing able to "get ahead of things" when event volume changes.

Never mind that speaking up gets everyone and his brother pointing fingers at you for their problems, even when it's someone else in the middle who has screwed up.  The corporate mindset is such that whoever says they have a problem is suddenly the cause of the problem.

Never mind that we have a cient to who *not* in production, but acts like any small time out of service is like the Fires of Hell are burning their ass and it's all your fault.

Been sayin that for years

Just read an article in the PyCoders weekly list about refactoring functions to have multiple return points.

The article is well-written, but I was floored by the need for it.  I've been an advocate of multiple return points for 2 decades.

The only reason to hold to a single return point in a function is to guarantee release of resources, and every OO language has had a means to do that with a local variable and destructor for over 25 years.

Multiple return points make the logic clear, handle special cases better, and allow better refactoring later for all purposes.

Do as I say, not as I do

I am beyond tired of being the one who has to follow all process and procedures, while being subject to other systems whose owners do not.

We had 2 major system failures this week, that essentially stopped our application from running or getting its data out.  In both cases, we were contacted by the downstream application teams, demanding to knwo th reason for the outage, and when it would be over.  Curiously, neither of the mission-critical systems that failed contacted us in any way, despite our system being well-documented as being on those machines and using that system.

Yet somehow, there seems to be no fallout to those systems for this utter lack of communication to the end users about this.

I may have complained previously about a manager who once told me that once I was told about a problem I had to "own it".  I responded with the obvious question - why didn't the person who told be about the problem have to own it?  I did not receive a good answer, except that the manager wanted to seem in control.

Readiness

So one team that wants data we will provide is pressing for us to turn the spigot on.  And this afternoon, they inform us that they can't decrypt the encrypted data, and the error code is that they are not accessing the encryption system correctly.
So we had to get the data to them right away, so that they could find out they weren't ready for the data.

Vanishing staffers

So The Job, like many megacorporations, is trying to cut staff by having contractors do the work.

My team consists of 4 permanent employees, and  5 contractors, and half the temporary folks will be gone in a year.

So I am stuck with trying to figure out how to transfer knowledge, and juggle workload, and transistion support.

Sheesh