HN user
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.
2. Linux servers are targeted and breached. Linux desktop share is too small to be worth it (yet).
Why aren't we replacing them with something better then? Why are most servers still running GNU/Linux?
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 wonder which takes more time, take home tests or LeetCode grind...
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.
Thanks.
Were you trying to link a specific video? Your link just points to the entire playlist.
I actually have this bookmarked somewhere but forgot about it. Thanks!
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 just want to underline that a good engineer should not blindly trust anything, even if it seems to be written by a well received author.
Doesn't this also apply to the opinions of your friend who works at a FAANG? How do you judge between theirs and Fowler's view points?
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.
For the specific incident I mentioned in the original post, I didn't quite get the exact details of the problem, but I think the gist of it was that our MongoDB deployment was using too much memory for its cache. We're running it on our Kubernetes cluster that use M5.xlarge EC2 nodes, and it was causing problems to other applications deployed on the same node. Kubernetes was, understably, having a hard time managing resource and scheduling the deployments.
I think one of the challenges with running databases on Kubernetes is that, at the time of writing, Kubernetes does not really have an abstraction for databases and so it manages them just like any other resource (of a given type). Operators are meant to address this though, and the people at Kubecon seem to be excited about it, but I haven't used it personally.
It actually doesn't matter because you can always rewrite a working product.
False. Sure, technically, this is true, but in practice there are lots of variables at play here. Who is going to pay for the rewrite? Is the company profitable enough to do that while maintaining legacy code for current users to use? I'm not saying the only way to develop a product is to get it right the first time, but ideally, organisations shouldn't have to pay for the same product twice.
Just as bad as the people who obsess over "beautiful code" and whatnot are the people who straight out reject the idea, then label those who observe them the "enemy" of this industry.
I think the key here really is mindfulness. Developers read code significantly more than they write them, and one of the primary goals of best practices and clean coding guidelines is to help teams communicate effectively through code. Writing code well is a skill, but that doesn't start and end at taking all the "rules" to heart; that's just the first step. The next is really to recognise that there aren't any rules, but more heuristics based on collective experiences. Software development is not an exact science, and just like the Agile Manifesto, clean coding guidelines only provide framework upon which to build any team's practices: a starting point from which to find what actually works for their project.
Sorry, I didn't know how to make the question a bit clearer. Basically, it's: how do you ensure that queries on very large, highly dynamic datasets return in acceptable amount of time (especially if clients call/poll it at regular short intervals)?