Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API

From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "dev null as a service"
-
Because everything should be a managed-service somewhere in the internet.
https://devnull-as-a-service.com -
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.22 -
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.6