That's not what a double-entry accounting system is for. If all you're doing is keeping track of one account/balance, then double-entry doesn't add anything. You might want to still implement it that way for future proofing though if you're implementing an accounting system.
The main thing to takeway is to store transactions like you mentioned (+20, -20). And in the simplest case, just apply all of them based on time.
You're not entirely wrong that double-entry accounting doesn't add much to keeping track of one balance. And the example provided in the article was very simple, just like mine was very simple. Transactions do help, but if you are trying to keep track of a balance and understanding how that balance is changing, double-entry accounting is helpful.
Agreed. I'm building a presentation software[1] so it needs to work locally (can't afford lost of connection). But I also want it to be accessible from anywhere. Unfortunately those two things don't mesh that easily.
The tech is getting there though. With things like hole punching or webrtc, P2P is getting pretty easy to implement. Though it's still a challenge to implement it in an actual project.
I do believe that we're going to start seeing quality local-first software w/ great networking pop up more and more soon. I'm working on that, but I'm sure there are plenty others who are doing the same.
Never said you shouldn't. Tailscale uses a bunch of different techniques including hole punching for it to work. If that's what you need, go ahead. I opted for Iroh for a few different reasons but Tailscale is an awesome choice too.
I've noticed this recently. Libraries that normally wouldn't have much documentation now has quite a long README.
I thought it was a blessing until I start reading them and realize that many of them are clearly generated by AI... The information is not wrong, but most of the time it's too long and a pain to read. Human written documentation are typically better at picking and choosing relevant information rather than dumping every single little thing
I for one think that this discipline is what separates a good developer from being a good engineer. This kind of rigorous process is the kind of thing that I'd expect from most devs but is sadly missing most of the time.
A senior can write, test, deploy, and possibly maintain a scalable microservice or similar sized project without significant hand-holding in a reasonable amount of time.
A junior might be able to write a method used by a class but is still learning significant portions and concepts either in the language, workflow orchestration, or infrastructure.
A principal knows how each microservice fits into the larger domain they service, whether they understand all services and all domains they serve.
A staff has significant principal understanding across many or all domains an organization uses, builds, and maintains.
AI code assistance help increase breadth and, with oversight, improve depth. One can move from the "T" shape to "V" shape skillset far easier, but one must never fully trust AI code assistants.
Does anyone use this in production? I tried it and it was great. But I stopped using it since I assume there'll be quite a performance hit compared to a traditional build, then running with node.
