To clarify, the total funding amount is a bit more than $700m. $903m according to Crunchbase.
273 karma · joined September 19, 2013
Just an observation that this very specific denial without offering anything else makes me think that what they _actually_ do is probably controversial as well.
Just to clarify, YouTube revenue in 2019 was around $15 billion, which even for Google is not a small number.
> “Companies don’t tap their credit line unless they need to,” said David Ritter, an analyst at Bloomberg Intelligence, who spoke generally about the issue without commenting directly on Robinhood. When companies do, it’s “perhaps not a good signal with regard to their cash burn, which could make creditors nervous.”
Does anyone else feel this as well? Is it just my small sample size? I would like to continue using Apple Maps over Google Maps because of the integration with Apple Watch, but it's getting harder and harder each day to justify.
When I was learning Phoenix, I spent a substantial amount of time learning Elixir as well and OTP is one of the first few things they put in front of you. Don't get me wrong, I loved learning about it personally, but I am not surprised that a lot of people would consider it too much effort.
Aside from that, pyre looks like a super useful tool. Hopefully it has fewer rough edges than mypy.
Is the writing quality of techcrunch articles normally this poor?
http://www.forbes.com/sites/greatspeculations/2015/04/28/com...
I don't think it's strictly needed, but it's best practice because instances in each AZ remain independent from failures in other AZs. Were the AZ with the single NAT to go down, then instances in the other AZs wouldn't be able to communicate outside the VPC (ie. to the rest of the internet)
There's also a side benefit of much lower latency using a NAT in the same AZ vs going across AZ (unscientific benchmark is 0.1ms in same AZ vs 0.3ms across AZ)
> it would have been more efficient to schedule other deliveries in the mean time and just come pick up the food when it was ready?
There are a lot of factors at play so it's hard to say what exactly happened in this instance, but some considerations:
* The wait time at a restaurant is probably not enough time to fit comfortably another delivery. Deliveries take a bit of time. I don't have the exact #'s, but you can imagine 5-20 minutes driving to restaurant (+ parking), 0-5 minutes waiting at a restaurant, 5-20 minutes driving from restaurant to customer, which ends up being around 10-45 minutes with high variance.
* We want food to be as fresh as possible for the customer, so on average we may prefer a dasher to wait a little rather than arrive the food is ready. Like the other replies mention, we try to measure how long food prep takes for a restaurant and we may err on the side of caution with restaurants with high variance by sending them to a restaurant assuming the shortest estimated food prep time.
* Restaurants don't always provide accurate estimates of how long the food is going to take to make.
* In your specific anecdote, we likely predicted the food to be ready much earlier (atleast earlier enough that you wouldn't have you felt they could have done another delivery) but some things may have changed from the original delivery. Eg: The kitchen was especially backed up during this time and we didn't have examples of this in our dataset. Or perhaps we did have examples of this and it didn't happen enough to increase its weight in the food prep calculation. Customer may have made an adjustment to the order, which caused additional wait time after we made the original dasher/delivery assignment. Kitchen may have made a mistake with the order and had to remake it. Our estimate for drive + parking time may have been too high. In other words, some of the time that you saw the dasher in the restaurant could have been time that we estimated for driving/parking instead.
There are a ton of other factors at play, but I hope this gives you some sense of complexity of the problem :)
Eg. latency across availability zones in the same EC2 region is <2ms (and obviously even faster in the same AZ)
Not just Stripe. Braintree, I've heard, is comparable or bigger.
When Johnson and the Trop finally agreed, he had whittled the house edge down to one-fourth of 1 percent, by his figuring. In effect, he was playing a 50-50 game against the house, and with the discount, he was risking only 80 cents of every dollar he played. He won’t say what all the adjustments were in the final e-mailed agreement with the Trop, but they included playing with a hand-shuffled six-deck shoe; the right to split and double down on up to four hands at once; and a “soft 17” (the player can draw another card on a hand totaling six plus an ace, counting the ace as either a one or an 11, while the dealer must stand, counting the ace as an 11)
The house edge of this game (using http://wizardofodds.com/games/blackjack/calculator/) is 0.33457. There's no additional player-favorable rule that I can imagine to which all 3 casinos agreed (like late surrender, a rule I've never seen in a Las Vegas strip casino) that would account for the ~0.08 difference in house edge. Like another comment suggested, I think there's a good chance he intended to count cards when calculating his odds. A simplistic card-counting strategy (http://wizardofodds.com/games/blackjack/card-counting/high-l...) could account for the difference.
I was under the impression that standard casino blackjack shoes were 8 decks (machine shuffled).
And whether a game is machine-shuffled or hand-shuffled will usually depend on the min bet. The higher the minimum, the more likely the table is to be hand-shuffled, and the lower tier the casino, the lower that minimum is likely to be. For example: the Wynn Las Vegas' $100 min table is machine-shuffled, while Harrah's Lake Tahoe $100 min table is hand-shuffled.