Ask HN: How do I efficiently track record count for big (distributed) DBs?
1 points • 0 comments
@extra_rice | Hacker News
From 3/7/2019, 4:08:20 PM till now, @extra_rice has achieved 41 Karma Points with the contribution count of 28.
Recent @extra_rice Activity
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!
Ask HN: What are the best resources for learning caching strategies?
18 points • 6 comments
Ask HN: Where else can I buy O’Reilly eBooks online?
2 points • 1 comments
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?
site design / logo © 2022 Box Piper