mrkeen

92 ms·

901.
by mrkeen 2y ago
I don't know why the author blames Spring in this. You can't swing a dead cat in HN without someone saying "just use Spring, it handles session cookies for you automatically" Likewise why blame JWTs for needing to reauth
902.
by mrkeen 2y ago
> Perhaps there's some important principle of rights that's eluding me. Convicting the guy is one alternative, but there's another (non-mutually exclusive) option: punish whoever conducted an illegal search. If a warrant
903.
by mrkeen 2y ago
> I worked with a feature that used this approach once. You work with many features that use this approach. https://www.dbi-services.com/blog/oracle-log-writer-and-write-ahead-logging/ https://git
904.
by mrkeen 2y ago
Two points: * Technically the data is probably there, but I really don't think you want back-up ops invoked by your REST call to /getUserHistory/. Is it even possible to mix old data and new data within the same SQL expressi
905.
by mrkeen 2y ago
This is the technique that developers used to build Aurora, not Aurora the end-product. Customers writing code against Aurora are still doing plain ol' destructive CRUD mutations "now". Event-sourcing is write-ahead-logging i
906.
by mrkeen 2y ago
This kind of thing only works if your whole universe belongs to your database. Transactions and conditional-updates work smoothly if it's your customer browsing your shop in your database - up to a point. But I usually end up with part
907.
by mrkeen 2y ago
Likewise with database backups.
908.
by mrkeen 2y ago
Someone should try it with postgres. Make a raw speed branch that gets rid of the overhead of mvcc: while querying a database each transaction sees a snapshot of data (a database version) as it was some time ago, regardless of the curr
909.
by mrkeen 2y ago
Requiring exclusive ownership avoids the issues, but it also avoids the features. Sometimes you actually do want multiple threads working with data.
910.
by mrkeen 2y ago
> One could also imagine ensuring that > n/2 consensus members are always located inside the restaurant/hardware store/etc. If the simple-majority is inside the restaurant, then the restaurant is online and the rest of
911.
by mrkeen 2y ago
I think your points are pretty spot on - most things have already been invented, and there's too much of a move-fast-and-break-things mentality. Here's a follow-up thought: to what extent did the grey-beards let us juniors down by
912.
by mrkeen 2y ago
> thus the scope for the one log is still small, and it reduces coordination headache for coordinating between the systems. This does not follow. Neither the dev (nor the product seller) is in control of what real-world effects have a ca
913.
by mrkeen 2y ago
I think the author is motte-and-baileying between: Literally one log - which does indeed reduce your coordination headache, but is susceptible to your "giant ass mutex" comment, and One log per ... - which brings the coordinat
914.
by mrkeen 2y ago
That's what the rest of us are doing in event-sourcing land, but TFA is arguing for something much stronger: If everything’s in one log, there’s nothing to coordinate The rest of us have to coordinate the logical log of user cre
915.
by mrkeen 2y ago
If I've understood it, it's like using Kafka with 1 topic and 1 partition. But it shouldn't rule out multiple brokers with a >1 replication factor, giving you CP.
916.
by mrkeen 2y ago
Using one-log-only for an entire system does have its upsides, but it will kill performance. It would be like building a CRUD system with a single mutex for everyone to share.
917.
by mrkeen 2y ago
> pure (n, guard (factor /= n) $> factor) Returns a tuple: Left side is n, right side is (Just factor) if factor is not n, or Nothing if it is.
918.
by mrkeen 2y ago
I'm not so sure. In my (under-read) mental model, blockchain takes you from fail-stop fault-tolerance (a la Paxos) to Byzantine fault-tolerance, i.e. how do you compute in a massively distributed system when no node has any reason to
919.
by mrkeen 2y ago
I read that sentiment here a few years ago but couldn't get anything more out of it than actors can race, but a turing machine is determistic. I could very well have it wrong. If you were computing with actors, and you also had a suff
920.
by mrkeen 2y ago
Yes, but the paper blathers on and on in prose about history and related work and goals and future work. It might only mention eigenvector once in a tangential remark, but that remark is like 80% of the algorithm content of the paper.
921.
by mrkeen 2y ago
I always wonder where the devs come from who end up doing important work. Seniority doesn't mean anything if a dev's 20 years has been spent flinging crap over the wall and then wondering how to keep up with all the support ticket
922.
by mrkeen 2y ago
My working definition is that a unit is something which can be unit-tested. By that I mean: the code being tested has the same properties that you expect of a good unit-test. I guess fast and deterministic are good enough properties for a
923.
by mrkeen 2y ago
They also imbue code with meaning, not just data. For isn't, the return type STM () doesn't give you anything back, but it declares that the method is suitable for transactions (i.e. will change state, but can be rolled back autom
924.
by mrkeen 2y ago
We don't need this article because the 90%-unit/10%-itest was only ever a goal to aspire to. Just like achieving 90% code-coverage - no need for a thinkpiece to say that 40% or 60% is now 'the right amount' of code-cove
925.
by mrkeen 2y ago
> If the Go language ever comes to the point where I’d have to write this n, err := r.Read(context.TODO(), p) > put a bullet in my head, please. Manually passing around a context everywhere sounds about as palatable as manually
926.
by mrkeen 2y ago
The current norm that comes to mind is Biden trying to cancel student debt, to which the SC said no. It's nothing new in that it's something that should have been decided by Congress, not the executive. But I think it's new
927.
by mrkeen 2y ago
In other words, if your world view is that you will never scale out your database beyond n=1, then microservices being part of the scaling-out journey is indeed a fallacy.
928.
by mrkeen 2y ago
In fairness to GP, the post argued for this, rather than declaring it as a fallacy.
929.
by mrkeen 2y ago
> We will debunk these fallacies in the next posts one by one. The next post I will start with the first fallacy, the very widespread fallacy that you need microservices for scalability reasons. Stay tuned … > The microservices fallac
930.
by mrkeen 2y ago
I don't think the idea is to buy crypto locally, and then donate the crypto to Trump. The purchase is the donation. You just wake up one day and decide to purchase some shitcoin. The seller happens to be Trump. He walks away with y

More ›