5,450 karma · joined April 12, 2010
You have to deal with this to some extent in any webapp that has more than 1 OS thread or process. But if you're keeping actions around for minutes or hours instead of second you're going to have to account for a lot of weird stuff you normally wouldn't.
If you really wanted something like this, I would think you would want a concept of "stale" data and up-to-date data. If a process is OK with stale data, the service can just return whatever it sees. But if a process isn't OK with it (like, say, checkout), you probably need to wait on the queue to finish processing.
And since the front end may care about these states, you probably need to expose this concept to clients. It seems like a client should be able to know if it's serving stale data so you can warn the user.
Maybe I'm mistaken.
When they started removing ports I use I switched to a Thinkpad T-series. It's been the perfect laptop for my use.
I don't know. The level of complexity this introduces seems to be way higher than anything in the original article.
E.g. for placing something in cart, its not only the next page that is reliant upon it, but anything that deals with the cart - things like checkout, removing from cart, updating quantities, etc. Adding to cart has to be mindful of queued checkout attempts. And vice versa. It sounds way messier than the comparatively isolated concepts such as CI, DI, and zero downtime deploys.
Async communication certainly seems desirable across subsystems that are only loosely connected. E.g. shopping, admin, warehouse, accounting, and reporting subsystems. But by using asynchronous comms you're actually introducing more state into your application than synchronous comms. State you should be testing - both in unit & integration tests (somewhat easy) and full end-to-end tests (much more expensive).
I'm sure Amazon has all sorts of complexities that are required at their scale. But you can heavily benefit from the techniques in the OP even if you aren't Amazon scale.
So I'm having trouble envisioning how your system actually works. At least in the stuff I work on, realistically, very few things are "fire and forget". Most things are initiated by a user and they expect to see something as a result of their actions, regardless of how the back end is implemented.
I hope AMD starts using more than 1 chiplet for laptops. Until they do an AMD laptop is limited to 4 cores.
I think the key might be that the IRS is viewing bitcoin as a payment for the service of mining.
But in Clojure it's not a problem. I find lots of applications where working with stale, consistent data is just fine.
Also, if you ever need to rewind your state Clojure's immutability makes it trivial. I've used this in e.g. latency compensation for multiplayer games.
The fire problem in California is basically anywhere there is any wilderness. The state inevitably gets dry and becomes a tinderbox.
Because corporations as they exist are completely fictional, you bet your ass we can take those completely made up protections away from them once they stop being a net benefit to society.
If that were done, corporations would do an absolute shit job of returning value to shareholders.
It is exactly those plunderers, enslavers, and colonizers that, well, colonized the new world and built their economies on top of slavery which eventually became independent countries.
> In any case, the longest possible character string that can be stored is about 1 GB.
This gives people enough information as to whether or not a change is worth it. If the difference between, say, 2 and 5 days makes or breaks the feature it's probably not worth exploring in the first place.
But that isn't anywhere near the point of the article. It's talking about scientists that did NOT switch to writing software professionally, but continue to write it merely as a tool to accomplish their primary scientific goals.
Also, calling it "fierce competition" is a mischaracterization of their actions. They have been fined by countries for these practices, and have done what they could to keep the evidence from public view. Intel deserves the suspicion they get.
The macbook should be closer to the current pro, rather than this basically an air/but not an air thing they have going on.
The pro should be for actual professionals, not for anyone that wants a laptop with more than just 2 cores.