It's maddening how few people working with the internet don't know anything about the protocols that make it work. Web work, especially, I spend far too much time explaining how status codes, methods, content-types etc work, how they're used and basic fundamental shit about how to do the job of someone building internet applications and consumable services.

The following has played out at more than one company:

App: "Hey api, I need some data"
API: "200 (plain text response message, content-type application/json, 'internal server error')"
App: *blows the fuck up

*msg service team*

Me: "Getting a 200 with a plaintext response containing an internal server exception"
Team: "Yeah, what's the problem?"
Me: "...200 means success, the message suggests 500. Either way, it should be one of the error codes. We use the status code to determine how the application processes the request. What do the logs say?"
Team: "Log says that the user wasn't signed in. Can you not read the response message and make a decision?"
Me: "That status for that is 401. And no, that would require us to know every message you have verbatim, in this case, it doesn't even deserialize and causes an exception because it's not actually json."
Team: "Why 401?"
Me: "It's the code for unauthorized. It tells us to redirect the user to the sign in experience"
Team: "We can't authorize until the user signs in"
Me: *angermatopoeia* "Just, trust me. If a user isn't logged in, return 401, if they don't have permissions you send 403"
Team: *googles SO* "Internet says we can use 500"
Me: "That's server error, it says something blew up with an unhandled exception on your end. You've already established it was an auth issue in the logs."
Team: "But there's an error, why doesn't that work?"
Me: "It's generic. It's like me messaging you and saying, "your service is broken". It doesn't give us any insight into what went wrong or *how* we should attempt to troubleshoot the error or where it occurred. You already know what's wrong, so just tell me with the status code."
Team: "But it's ok, right, 500? It's an error?"
Me: "It puts all the troubleshooting responsibility on your consumer to investigate the error at every level. A precise error code could potentially prevent us from bothering you at all."
Team: "How so?"
Me: "Send 401, we know that it's a login issue, 403, something is wrong with the request, 404 we're hitting an endpoint that doesn't exist, 503 we know that the service can't be reached for some reason, 504 means the service exists, but timed out at the gateway or service. In the worst case we're able to triage who needs to be involved to solve the issue, make sense?"
Team: "Oh, sounds cool, so how do we do that?"
Me: "That's down to your technology, your team will need to implement it. Most frameworks handle it out of the box for many cases."
Team: "Ah, ok. We'll send a 500, that sound easiest"
Me: *..l.. -__- ..l..* "Ok, let's get into the other 5 problems with this situation..."

Moral of the story: If this is you: learn the protocol you're utilizing, provide metadata, and stop treating your customers like shit.

I've made the json protocol. It's a protocol containing only json. No http or anything.

To parse an json object from a stream, you need a function that returns the length of the first object/array of all your received data. The result of that function is to get the right chunk of the json to deserialize.

For such function, json needs to be parsed, so I wrote that function in C to be used with my C server and Python client. I finally implemented a C function into python function that has a real benefit / use case. Else you had to validate but by bit by the python json parser and that's slow while streaming. Some messages are quite big.

Advantage of this protocol is that it's full duplex.

I'm very happy!

Why do I program everything myself in C, even a rest service? By writing everything yourself in C you make simple things complex to make complex things simple.

Writing a rest service for example learns you a part of http protocol, how sockets work, how to create a parser (in this case json). Three thing's you would miss if I used python.

On top, your rest service uses WAY lesser resource than written in python for example. Especially for CPU usage.

Allocating and free-ing still often have issues there, but I consider it a skill problem / discipline issue. Not blaming C for that. The rules are clear.

Today I learned about binary encoding formats alternative to JSON such as Google Protocol Butter.
I like these binary formats.
Just thought I would share this here so others would benefit as well (and please share your experience if it is relevant)

I wanted to develop a programming language since all programming languages have some shortcoming of their owns so as I walk further along in developing custom parser generator and so forth, I get to the point where I have to consider implementing the Language Server Protocol for the programming language only to realize that while ironically LSP was supposed to make it easy to to have autocompletion features and other stuff made available to other editors, you still end up requiring to make plugins/extensions for such editor like Visual Studio and Visual Studio Codes anyway despise the fact that LSP was meant to solve that. Meanwhile over at Linux Land, we have Kate editor that can be configured to simply connect to LSP server and require no plugin/extension to do so, you just specify it in json config and that's that.

Microsoft... you created LSP protocol and yet you want Plugin/Extensions still for VSCode/Visual Studio even though LSP was made to address that... Make up your mind, ffs. P.S. I have no interest in writing 100,000 LOC of extension/plugin for your editor if it can't get it's $#!^ together.

I'm working on a firmware for 3d printers. I had to send a lot of data to another microcontroller and I was making a very sophisticated protocol. When finished I was so proud of my work but in that moment I remember that there is a thing called JSON but I didn't care. Now I have to send the same data to a webserver and need to move from my own protocol to JSON.
Fuck me.

First you make a filthy JSON protocol where numbers are encapsulated into strings.

Then you document this little fact nowhere. Actually you don't document anything at all.

Then you make a shitty parser that ignores any exception. So that when I try to send my objects, it took two hours to figure out it was "my fault" as I was sending actual integers instead of strings.

I think you deserve to suffer a terrible agony for exactly the amount of time I lost.

I have been working on IoT projects for last five years. After using MQTT in many of my projects I have realized that there is a huge learning curve for the beginners to understand and implement MQTT in their projects. The packet structure of MQTT is complex and MQTT packets are difficult to debug. Also customizing the open source MQTT brokers are also difficult for the beginners, and sometimes even for the experts.

To make IoT and Messaging simple, I am designing a new protocol which uses JSON packets for data exchange and is far less complex than MQTT. I am also developing an open source project which will contain a server (with load balancer support), a python client, a Javascript client and a python based load balancer. I hope this project will reduce the development time as the protocol is easy to understand and the open source code is fully modular & easy to customize.

This will be my very first contribution to the open source community. Wish me luck!

I have been working on IoT projects for last five years. After using MQTT in many of my projects I have realized that there is a huge learning curve for the beginners to understand and implement MQTT in their projects. The packet structure of MQTT is complex and MQTT packets are difficult to debug. Also customizing the open source MQTT brokers are also difficult for the beginners, and sometimes even for the experts.

To make IoT and Messaging simple, I am designing a new protocol which uses JSON packets for data exchange and is far less complex than MQTT. I am also developing an open source project which will contain a server (with load balancer support), a python client, a Javascript client and a python based load balancer. I hope this project will reduce the development time as the protocol is easy to understand and the open source code is fully modular & easy to customize.

This will be my very first contribution to the open source community. Wish me luck!

The project I have been working on was growing and growing and growing... It reached it a point where the front-end was really hard to maintain. The worst part was the communication protocol, we were using JSON to serialize really complex objects.

I took some initiative and suggested that we use protobuf instead of JSON. Long story short, data usage is 10% of what it used to be, serialization and deserialzation is much faster, and the best of all, everything is strongly typed, with auto generated classes. Fucking awesome!