For some time, I used org-mode for almost all type of note taking. I love the structure being functional without HTML rendering. However, it's pretty much locked to emacs and so the portability is very poor. I need most of my notes to be at least readable on my mobile devices.
When I discovered Obsidian, I decided to fully switch to Markdown. It's very nice that it supports vi bindings.
A lot of words that we use are arbitrary anyway. I respect people's preferences for their style of communication, but let's stop pretending that things like blacklist and whitelist are difficult to understand.
DP as a paradigm is very interesting. From a high level view, one can appreciate the essential concepts that make it work, with things like memoization, optimal substructure, etc. It's also interesting how it relates to shortest paths problems, and greedy algorithms.
However, as you said, actually trying to solve DP problems relies on knowing the trick, and the tricks varies almost wildly from problem to problem. They're unintuitive, and difficult to derive normally. The intuition you gain from one of them could be entirely useless, or, worse, counterintuitive for another. I personally think, they shouldn't be used for interviews because being able to solve them seems to be more a matter of luck than actual competence.
I’m not really arguing which one is easier to run, maintain, or anything; I was just making a point about abstractions and system modularisation.
Hypothetically, I should be able to take a well-designed monolith and “deconstruct” it into a distributed system by deploying modules individually and replacing function calls with network calls. Going the opposite direction, I should be able to do the reverse with a well-structured distributed system.
This pattern of modularisation exists across the software stack; it goes as far as the digital logic level with lumped-element abstraction. In general, we trade-off some benefits with a more complex messaging mechanism, akin to threads sharing the same memory space VS processes communicating through sockets or files. In general these are all technical details that help us accomplish what we need our system to do, but pinning the right abstractions helps us actually reason about our system.
> Anyone that isn't able to write modular code using the language features is going to write network spaghetti code, with the added benefit to debug network packets and connection issues on top of everything else.
This is the most important bit. To me microservices is just another way to arrange your system into module, not much different in concept to modules and packages. Regardless of whether you’re dealing with monolithic or distributed system, if your abstractions are poor, your work and your system will suffer.
I currently work on a project that has struggled to make actual sense for a few years now. Sure I like getting paid, but there's a growing void in my soul.
I can't consider myself to be an emacs superuser but I've built muscle memory around its key bindings so on JetBrains IDEs, I use my custom emacs based key maps. I used to be an Eclipse user many years ago, but when IntelliJ community came out, and it started supporting emacs key maps, I made the jump. I'm now using ultimate licensed by the shop I work at.
When people say writing tests first slows you down, they are usually only looking at the upfront costs. They do not factor in the costs of maintenance, and having to fix and/or extend a previously written code.
Send my best regards to Steven. I share the views as his.
Are SWEs at Google expected to firefight especially outside of normal work hours? This is one thing I imagine SREs are expected to be doing that regular SWEs aren't. I think this is also why they require strong development background for the role.
You can easily serialise a well fleshed out (i.e. non-anemic) object. Does the view layer in this particular example need to know the encapsulated business rule? In my experience, not usually. Otherwise, there's most likely a problem with responsibilities. And when that data comes back from the UI, it's also relatively easy to reconstitute it back to well fleshed out objects.
I don't understand how anemic domain models are irrelevant now especially in a time where a lot of software practitioners seem to observe domain driven design. In the age of microservices, it is very important to determine clear context boundaries. "Logic lives across multiple services" sounds more like a design smell to me. In this case, changing even very simple business requirements could mean changes in multiple parts of the system, which could mean multiple redeployments of many different services. Also implies more complex integration (even e2e) testing.
Not sure what exactly you meant with this. Are you suggesting that we migrate over to Postgres, or that we can somehow use the Postgres operator with MongoDB? I'm honestly open to switching databases, but I don't think management will be thrilled with the idea (not for now at least).
Yeah, sounds like operators really are a perfect fit for this use case. For your e2e, I imagine you use the operators to spin up new database instances for every run? I really like the idea of being able to do that, which is something I imagine would be difficult outside of Kubernetes.
For production though, do you have any specific scheduling logic to ensure that database resources don't cause issues with other services in the cluster, or is it just a matter of configuring the database service?
> unless you use a host only PV and if you do that you are likely limiting you db instamce to a specific node which can have scaling and/or HA impacts
This is exactly what we do, and we're having trouble because of it and not only in terms of scaling the database, but also because it runs on the same node as all other Kubernetes resources. We are considering spinning up a dedicated node for it, but I thought at that point we should probably just buy an actual dedicated database solution instead; buy the expertise we don't have currently.
Yeah, this is one of the things we are considering at the moment. However, if I understand correctly, for MongoDB specifically, you need to be using their enterprise offering to be able to utilize their operator.
When I discovered Obsidian, I decided to fully switch to Markdown. It's very nice that it supports vi bindings.