Ahh, half-timbered houses, parties and pirate hunting. It was a nice day when GoG put it up as one of their good old games.

Speaking of laptop batteries as a UPS source, some laptops come with battery management features that keep the battery healthy even when plugged in full time, usually exposed as a setting in the BIOS/UEFI. I've found that business/enterprise type laptops like Thinkpads and Probooks have this as standard, for example Thinkpads from 2010 already had this, assuming you're lucky enough to find one with a usable battery of course.

Macbooks do this as well automatically if kept plugged in for a certain period of time.

Is there something for Linux/debian? I’m assuming this is part of the OS and wouldn’t work on a MacBook with Linux.

It's managed by the OS when it's awake, by the bios (or uefi or whatever) when it's sleeping.

Both methods work under Asahi Linux on the ARM macs.

Look up tlp's charging thresholds. Just set mines up for debian

Congratulations on launching William. There's quite a bit of criticism here that'll help you refine your app I think. I'm working on a something similar and already learning from the discussion here around user experience and privacy. All the best.

I appreciate it! It’s bound to happen when it’s my first time launching an app. All criticism is good criticism, only up from here. Thanks for the comment!

Thanks for landing the mtmd functionality in the server. Like the other commenter I kept poring over commits in anticipation.

As I read this, Greenspun's tenth rule of programming humorously came to mind: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

Generalized by replacing "C or Fortran" with a language where the user wants more power over it's syntax and semantics, to witness the author pull it off in just 44 lines of JavaScript was a joy.

TLDR: Micro services offer a REPL like experience for application architecture. The way I see it, micro-services are the architectural analogues of functional programming. They let me build pieces of an application similar to a function, including tests and debugging in isolation without the fear of unintentionally messing up data somewhere. This similarity to functions even extends to how micro services are used, calling their API's with keyword arguments e.g get post name id json etc

If you don’t mock out an RPC call in a microservice it has the same implications as not mocking out a database query in a monolith. I’d argue microservices actually encourage testing in isolation which can increase risks when you do ship (assuming you don’t have e2e or integration tests, which can also be more complicated with microservices).

I’m not arguing either way is right or wrong, but I disagree that microservices inherently makes things easier to test. Isolated tests actually implies you tested the lego bricks but not the overall assembly, which would potentially imply higher risk.

It’s also possible to write microservices that are architected in a way contrary to FP, such as having services that mutate their data stores, so I’m not sure id compare microservices to functional programming either.

You compare services to functions, which they are, only with the added complexity of dealing with distributed nature of it. I’m not obviating the benefits, but I disagree microservices are the automatic win you imply.

I would instead attribute the benefits you mention to having good abstraction, whether that’s functions or classes or services, abstractions allow you to isolate mock and reason in isolation.

For instance, the article mentions microservices are supposedly better so a change to your service doesn’t cause spooky action at a distance. I’m not buying this. In a poorly done microservices architecture emitting events can indeed cause spooky action at a distance, especially if you invested heavily into isolated testing only. It is easier for a monolithic architecture to shift boundaries, and in a microservices architecture it is possible (and in my experience common) that changes will need to be made across boundaries

You make fair points in that micro services are not a silver bullet, the functional wins I perceive aren't automatic and I intentionally build a service in that way to get the functional benefits.

So yes there is a caveat, if a service doesn't return the same output for the same input then some benefits of the approach are lost. I would like to add an additional benefit for teams of programmers, in that each team gets the ability to build out a service using whichever technology they find suitable i.e language, frameworks etc. Something I personally find difficult to do with a monolith.

This has helped me to view the GNU GPL in a new light. That is, to ensure freedom, we curtail the freedom to limit the freedom of others with respect to software.