This post show you how Big O is defined, how do we use it for measuring program complexity, and what does complexity even means.
Reading X3DH protocol used by Signal is not very obvious at first. It is just a key-exchange protocol, after all. What is wrong with the standard X3DH?
In this post, I show how you can build a Redis server in Go, finding its bottleneck and show some performance improvement you can do to make it more performant.
Here I share some of my advice for you who just started software engineering.
Math is vast. You don’t need to understand most of its branch, but you need some of it to function even as human. But, you might not need its notation. Math notation is just like a language, you don’t have to know it, but not knowing it limits your ability to learn from mathematical sources. You can still learn from another language, though. But knowing the math is not enough. You also need creativity to solve a problem.
Reflection makes it easy to write generic utility functions like encoders and decoders. But it is slow and has a high memory footprint. You can be more efficient by writing the code manually for every possible instance, assuming you are OK with that. However, now you have a correctness problem. Changing a field in your struct means you need to update your encoder and decoder. But if you forget to update them, there is no error message, and this can be a problem. As a middle ground, you can write the test using reflection so that it makes sure that your implementation is correct and still performant.
This is how I view the term parallel, sync, async and concurrent.
I don’t really see the advantage of Go implicit implementation. Changing the interface causes an error show up on wrong place, and it hides the intention of the implementor, making things hard to understand and maintain.
Redis protocol, i.e. RESP, is very simple, you can build it with few lines of Python code.
The fact of having ITaxCalculator and TaxCalculatorImpl means you don’t have a good reason to make it an interface. Usually, it is a way to make your code mockable. This, however, makes a bad habit to just mock everything and never think about testing.
The need for unique IDs is common in backend software engineering. It is often better to make unique IDs ordered to give us better cache locality. However, restricting an ID to be auto-incrementing usually provides no benefit, makes things more complex, and can even harm your development. The fact that your ID is strictly incremental rarely matters. Instead, we can use things like UUIDv7 or Snowflake IDs to get the benefits of unique, incremental-ish IDs with less complexity.