CTO: We'll use epochs for any time related fields in our services.

After service integration...

Dev from producer team: Hey the time field is showing up as 1970 and not null in your table. That seems to be a bug.

Me: Code looks fine. We are converting epochs to timestamps here. Null is taken care by the library function itself.

The same dev: Actually we are sending zero instead of null values in that time field. But we'd want the end table to treat that as null.

Me: Why can't you send null then?

The dev: Actually avro doesn't support nulls. Hence the zero.

Me: WTF??????

Manager to me: Actually you need to convert them as null. Anyways, this is not a blocker and we can live with it for now.

END OF RANT

Why can't they fucking send it as null? And when I asked about the details, that particular event type doesn't require that field. Still the manager insists on sending that field for it.

I explained last week in great detail to a new team member of a dev team (yeah hire or fire part 2) why it is an extremely bad idea to do proactive error handling somewhere down in the stack...

Example
Controller -> Business/Application Logic -> Infrastructure Layer

(shortened)

Now in the infrastructure layer we have a cache that caches an http rest call to another service.

One should not implement retry or some other proactive error handling down in the cache / infra stack, instead propagate the error to the upper layer(s) like application / business logic.
Let them decide what's the course of action, so ...
1) no error is swallowed
2) no unintended side effects like latency spikes / hickups due to retries or similar techniques happens
3) one can actually understand what the services do - behaviour should either be configured explicitly or passed down as a programmed choice from the upper layer... Not randomly implemented in some services.

The explanation was long and I thought ... Well let's call the recruit like the Gremlin he is... Gizmo got the message.

Today Gizmo presented a new solution.

The solution was to log and swallow all exceptions and just return null everywhere.

Yay... Gizmo. You won the Oscar for bad choices TM.

Thx for not asking whether that brain fart made any sense and wasting 5 days with implementing the worst of it all.

So I think I have answered this, but here goes.
I have ddns service I need to update periodically. I chose once every 5 minutes. I am using this command:
/usr/bin/wget -O /dev/null -o /dev/null <webcall url>
I have it running every 5 minutes in a cronjob. I checked and wget is using port 443 to connect to my webcall url which is https. I am assuming this is hiding the details of the url. Is this true? Also, I don't like that the cronjob is sending the whole command to syslog. Is there a way to prevent it from syslogging this? I would rather keep the details of the url hidden as much as possible. I am the only user on the server, but am curious if there is a way.

So questions are:
1. Is wget hiding the details of the url from prying eyes? It is using port 443 for https.
2. Cannot I not log the cronjob command in syslog? I supose I could create a script that hides this.