The Mithycal Console App


This post has provoked a lot of interest, so I managed to generate even more workload for myself. After some time (two years) here is finally dbjsysloglib. A Windows DBJ DLL Component. Release 0.1.0.

Original article

Why hide it, I like this diagram. A lot. It represents a typical “cloud side” (Azure) system using some component called “XYZ”, which happens to be written in C or C++. Most likely C, because it must 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 (2022 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 favorite library, little server or whatever else, including your clever, color-coded, terminal diagnostic output. And here is the point.

Your console output is 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 extraordinarily 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 made a code change, upon a change, upon a change, as requested by paying customers.  Often overnight or over a weekend.  Or even onboard a plane.

And doing so, you had no 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 the “debugger that everyone is using” to any of the data centre admins.

You will be let into the data centre, in the first place, only if some fundamental problem has happened with 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 men. At this moment the last thing you want to say is: “Well we are using this brilliant simple and useful colored terminal output. Can we please connect to it?”

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

But! You are 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”.

The Syslog

In theory, Syslog is optional. But you had better use it and do not think of it as “optional”. Syslog is not used just for network devices monitoring. That is what was invented 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 centre not using Syslog.

Syslog and you
Syslog and you (hint: you are not in the picture, things with a plus prefix are your local devenv situation)

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.

Lastly, the GUI

Here is the Syslog Watcher, (I/we use) GUI part of their syslog server, for developers and data centre admins, in action.

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

By using syslog, your library is server-side admin friendly. But also, the usual Syslog server in use today by developers has GUI app and is developers friendly. It is not just for admins. Even if it is used on the client-side (read: local pc or laptop), while developing some customer app, you will output useful logs, not to the non-existent console, but to the gui enabled local syslog server.

Just say no to the console output.