HN user

sbov

5,450 karma
Posts0
Comments1,492
View on HN
No posts found.

Depends on the project. We have some that use PostgreSQL backed queues. Some using Redis. As you get more traffic RDBMS resources are precious - wasting them on queues starts to become a poor tradeoff. Redis is so generally useful we tend to use it on most projects anyways, so it doesn't add another moving part. And we tend to be really conservative about adding new things to our production environment, and despite that Redis has found a home in our stack.

And if the algorithm came out with the reverse result - an 80 female/20 male split, then the right-leaning opinion would call the outcome impossible (tech does have a strong left-wing bias!). I'm not sure your theoretical example proves anything except most people won't believe reality even if it smacks them in the face.

Your solution seems to assume only one thing will be accessing what is being mutated at once. If another thread comes in and gets a cart (e.g. maybe the user reloads the page) and they aren't waiting on the operation to be processed anymore. If you remove it from the queue after a few seconds of failure then fine. But if the point is "self healing" it presumably hangs around for a while.

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.

My assumption has always been that the "Pro" line is aimed at content creators. Because in lots of professional work you would want a plethora of ports which Apple doesn't give you.

When they started removing ports I use I switched to a Thinkpad T-series. It's been the perfect laptop for my use.

If your system is extremely simple this may not be worth it. But you could say that about anything in the article, really.

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.

It's certainly fairly simple to use queues for straightforward, independent actions, such as sending off an email when someone says they forgot their password. It's less obvious to me how your proposal lines up with things that are less so. Such as a user placing an order.

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.

This was my thought. I wish they spent that area on giving me more cores. But whatever.

I hope AMD starts using more than 1 chiplet for laptops. Until they do an AMD laptop is limited to 4 cores.

Also, most languages are not sinking ships. Certain uses of them are of course. But even languages this site hates, such as C, C++, C#, and Java have very long lives ahead of them for certain uses. Obviously C++ vs Rails... well, you're going to be out of a job. But if you were using C++ for the sorts of things you would have used Rails in 2009 you were already a decade or so behind the curve.

That's when you buy it. I'm not an accountant, but AFAIK if someone gave you stock for performing a service you would pay taxes on it at that point in time. Then if you sold it you would pay taxes on the difference in value.

I think the key might be that the IRS is viewing bitcoin as a payment for the service of mining.

Legalizing drugs is the best thing the US could do with respect to the cartels. Not only would it reduce profits, it would give producers an arbiter to go to when there are disputes rather than forcing them to rely on their own version of justice.

Rust doesn't let you have a mutable reference while you have immutable ones. It's only a problem in Rust because mutating the underlying data would cause problems for chunks of code using the immutable data.

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.

Reminds me of the an article a while back talking about how via studying tree rings and sediment, that scientists think California experienced back-to-back 200 year droughts starting around the year 850.

Corporations as they exist in the US are a legal fiction. Just because you have the right to associate with people does not mean you have a right to be shielded from the ramifications of what your association does. However this is not the current law as it exists in the US with the corporate veil.

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.

I do something similar, except don't assign to a number. My back of the envelope estimates are: hours, days, weeks, months.

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.

You're basically saying scientists can become good programmers if they become professional programmers. Of course they can be, and I doubt anyone would argue that. Some of the best programmers I know have zero college education at all, so of course it's possible for mathematicians and scientists to do the same.

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.

So basically: fool me once, shame on you. Fool me twice, shame on me. Learn your lesson, it's a conspiracy theory.

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.

Ah, looks like they shrunk that keyboard by an inch or so since I bought my old apple keyboard - the newer one is about the same as my current keyboard. I use a vortex pok3r - I got it for the mechanical switches and programmability in addition to the size.

The macbook pro is barely a professional device. Just look at the bottom end of the specs.

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.

In a logical discussion whataboutism is never a relevant response. If something is bad it is bad if any side does it. But hypocrisy as a fallacy don't necessarily apply when discussing geopolitical power struggles. This is because people on one side using a tactic but not the other is usually a disadvantage, so when someone accuses you of hypocrisy they're basically saying that you're trying to get me to stop, but you won't, which will give you the upper hand, so... why should I stop?