Yes! You can control for human risks in the tail scenarios. You can't control for the tail scenarios in AI because you don't know what on earth they are, they are a nasty surprise, thrown up by a model which, in the tail, we as engineers don't fully understand
He only resubmitted 10 days ago. Presuming there was something missing with his first application, something like this would need to go through a legal area internally at Amazon to get a considered opinion. Maybe they are busy?
My hypothesis is they get dripfed onto these markets so as not to spook them. Or just transferred off to collateralize other trades - hey it's free money to them, why not set up another trade elsewhere while they are in?
It is not safe to assume anything based off market price action. You seem to be assuming there is some essential relationship between volume traded and price. These are market prices, they can be totally irrational, especially if there is some fake news (Tether is fully backed) behind them.
I think the ponzi continues to work for now, the arbitrageurs can cash out, while the illusion that tethers are backed prevails. So indeed if no one does redeem these USDT as I keep reading could the arbitrageurs just slowly buy the cross to USD over a period of time after the trade? Alternatively USDT seems to be a proxy-currency to move across exchanges and networks, so it may indeed be transferred off to other pairs/tokens to fund alternative trades...
Thanks, that is very enlightening. So Tether are all about maintaining the apparition of a 1:1 backing of USD to USDT. It's the lynchpin of the whole scam. Otherwise the step above you mention around the arbitrage bots buying btc-usd no longer occurs, and the game is ruined for them.
Do you have some modelling, or any credible reference to back up your assertion that the energy used by banks would be higher than a Bitcoin blockchain?
Precisely! So picture some, however oversimplified, code which
searches a customer's orders,
determines which is a phone product id, remembering they sell other stuff which we would not want to update in flight order details on,
then updates the embedded customer address on the order.
I would like to hear some original thoughts on why this is so difficult that a human is doing this work instead.
Obviously maintaining a different behaviour for a class of product ids is painful and not beautiful code to look at, but it is the real world.
While I disagree with the positions put forward by lolc and flukus, that Librem 5 should have the customer address modelled analogously to some 'fast moving goods' e-commerce implementation, I appreciate their comments for being constructive and actually adding something to the discussion.
Well the Librem 5 is not another 'widget in a warehouse'. It was always going to be a long wait to delivery, due to the enormity of the undertaking. This was not a surprise to anyone. Addresses will need to be updated after order in this case! Every implementation is different.
It's precisely the "this is the way it's done" approach you mention, which means they now have to pay a human to do the work their web stack ought to do!
I think people initially work on some of these projects, at least in part, to beef up their CV and make themselves more hirable. Every second tech job advertisement these days brainlessly asks you about your 'open source contributions'.
This company has given me so much, you simply cannot criticise. I still remember spending all night on battlenet playing sc1 back in the day. Big bottle of coke, some candy, headphones on and I was just transported. Loved that game. Never got into sc2 as much, maybe I will get it out and try over.
It's more overhead in the sense that mobx needs to walk all your store objects and check for changes, on top of what React does. Anyway that's fine if you really need that precision. I just useMemo at the 'hotspots' and that is enough. Remember also that if vdom diffing doesn't pick up a change, nothing is flushed out to the DOM, so whether an object is created or long-life doesn't matter in this sense.
To be honest I don't understand why people use mobx this way. I mean short life store objects, populated by props, that are recreated every mount. Might as well just use React state and save the overhead. You might say, because I have several components using the same business logic and fields and such, I can inject the same store into multiple components. I would say that logic can go in functions which take React state as their argument. You don't need a global state management tool to separate business logic from the view.
I think you are essentially talking about unit testing your stores, and in the case where there might be a lot of logic inside them, is a good idea in principal.
But take the case of an app using local state, this logic if indeed separable from UI, could be coded as functions, rather than within imperative object 'stores'. And these functions would obviously be just as testable.
In my opinion, the sharing of state in the manner you described leads to implicit coupling between components, which can be hard to hold in your head as the application grows.
The way that mobx is advised to be used, that is/was documented by its author, promotes the usage of a rootStore, which has as members all the various granular store objects. Is this how your organisation's stores are constructed?
I would always forget to put the observable decorator, then wonder why there was not a re-render. This situation occurred so many times I lost count. It's not mobx, it's me that is the problem.
This is not a religious stand against all global state. Username, permissions fine to be global, this is very easy for someone new to your code to grok. I put them in the top React context, then just useReducer where I need to. Don't need to pass down through props to every component anymore, thanks to React context and useReducer.
Although I was thinking if you wanted to be a religious zealot about not coding any of your own global state you could use the browser session API.