c++ The Mithycal Console App

Why hiding it, I like this diagram. A lot. It represents a typical “cloud side” (Azure) system using some component called “XYZ”, that happens to be written in C or C++. Most likely C, because it has to be integrated with NODE.JS.

Spot your product
Spot your product

You are C/C++ coder/developer/owner (of XYZ) and this is where your component lives these days (2020 Q1). Or in a place much like this one but on a different cloud.

Right now, when you write these numerous console apps, liberally sprinkled with numerous printfs() even mixed with std::cout you need to have this picture in mind, before shipping your favourite library, little server or whatever else,  including your clever, colour-coded, terminal diagnostic output. And here is the point.

Your console output is just plain redundant

Nobody will ever see it, or care to look at it. Typical small-ish data centre these days has approx ten thousand VM-s.  Do you expect admins to try and find a few of them where your console app is outputting critical information?

Datacenter admins are very complex personalities. Do not ask them to pay special attention to you. Even their paymasters are careful not to. So, do not take it personally.

But, (I hear you say), this is just one library! Yes, it is, but (alas) you have sold it. You are now paid and contract bound. You have done a code change, upon a change, upon a change, as requested by paying customers.  Often overnight or over a weekend.  Or even on board of a plane.

And doing so, you had not a choice but to leave inside exactly what you are not supposed to: a lot of console output. Your thinking is: this is for users/admins, of course, since you have this brilliant debugger that “everyone is using” for developers.

A word of serious golden advice: Never ever mention “debugger that everyone is using” to any of the data center admins.

You will be let into the data centre, in the first place, only if some serious problem has happened on the production VM’s. Yes, you will be summoned  and you will oblige, because this is what the contract says. Just sit tight and quiet and hope nobody will ask you anything.  Because if they do the first question is:

“Where is your diagnostic output?”

And this is the moment when C++ boys turn into the men. At this moment the last thing you want to say is: “Well we are using this brilliant simple and useful coloured terminal output. Can we please connect to it?”

The whole world of a difference in your life, the real turning point in your career, turning to the better, will come if you instead say: “Well the log files are at … “. Very good boy, file logs, good.

But! You are definitely not a “boy”, you are “one of them, the team player, the guy to turn to when the proverbial hits the fan”; just if you say instead (casually and relaxed): “Well it is going to the Syslog, of course”.

Syslog is optional. But you better use it and do not think of it as “optional”. Syslog is definitely not used just for network devices monitoring. That is what it was invented for, decades ago. These days, it is used (and it will stay)  also as a simple, fast, resilient, mature application logging protocol and system. There is no data center not using Syslog.

Syslog and you
Syslog and you (hint: you are not on the picture)

Am I making myself clear here? Good. That was the “why”. Let’s proceed with the “how”.

Never do anything unless you have your logging ready first

However small and insignificant (you might think)  your code is. But I can hear from you again (did I not tell you to be quiet?): “..I will surely not use Syslog server(s) when developing on my laptop, mobile phone, smartwatch, IoT coffee maker ?! ..” (Or whatever you fancy these days.)

Of course, you will not. (I do by the way) All I am kindly asking you to do is to make your life much simpler and never (ever) use directly either <stdio.h> or <iostream> in your code. Ever Again.

Decouple from output libraries

Simple C++ will take you very far from terminal/console output libraries, just if you want to. Here is what we use, and how it looks:

Our development default (Not a production! ) is to have console output with the second resolution time stamp, prefixing each line. If required one can switch to showing nanoseconds in a timestamp:

Crucially, by using the set_sink_function we can change where the final output goes to.

Next, we switch to our Syslog client and proceed as before.

We first switch off the time stamp we generate, then we redirect to our local syslog lib, and the whole of our code suddenly sends proper Syslog messages.

If and when we need to redirect every output back to the console we simply do:

Obviously with the sink_function users are decoupled from the output of choice: console, file, Syslog, etc.

Here is the Syslog Watcher, server GUI, for data center admins, in action.

Syslog server console. Nice and useful isn't it?
Syslog Watcher, server console. Nice and useful isn’t it?

Lastly, the GUI

This way, your library is server-side admin friendly. But also the GUI app friendly. Even if it is used on the client-side (read: local pc or laptop) from some GUI based customer app of yours, it will output useful logs, not to the non-existent console.

This post has provoked a lot of interest, so I just managed to generate even more work load. In next part of this post, I will be presenting the consolidated github repository where the code, we are talking about, is.

Just say no to the console output.

%d bloggers like this: