111–116 of 116 posts
Earlier quoted context omitted.
link to the tweet?
> The outage was not caused by a failure to code for the leap year. We had instability in a part of our infrastructure that allows our systems to communicate with each other. https://twitter.com/askrobinhood/status/1234861941413351434?... Sounds like Kafka / message bus to me
Earlier quoted context omitted.
link to the tweet?
> The outage was not caused by a failure to code for the leap year. We had instability in a part of our infrastructure that allows our systems to communicate with each other. https://twitter.com/askrobinhood/status/1234861941413351434?... Sounds like Kafka / message bus to me
Is this due to their Kafka infrastructure being down? Their tweet last night alluded to it.
Earlier quoted context omitted.
That was probably a joke, see Robinhood's reply: https://twitter.com/AskRobinhood/status/1234861941413351434 Seems like infra problems.
It's starting to seem like they use some sort of message bus to tie everything together. If the servers actually processing messages can't handle the volume, the entire show comes grinding to a halt. I've seen similar things in other industries where the entire system looks like its perfectly healthy, and then before you know it 100% of your systems are down because you simply can't push peak message volume or becaus…
Earlier quoted context omitted.
Often it's not dev managers, but a level above who don't prioritize QA engineering because they see it as a cost center and find it difficult to quantify the risk. If it's not leading to growth it is de-prioritized until fires are burning.
A lot of the trouble is that good QA -- and good engineering practices in general -- usually comes down to some equation like velocity x quality = $. If you want to increase your code quality, you either have to slow your velocity or jack up your $'s -- and usually you end up doing some combination of both, going a little bit slower and spending a little bit more money. And if there's one thing people hate more than…
Earlier quoted context omitted.
A lot of the trouble is that good QA -- and good engineering practices in general -- usually comes down to some equation like velocity x quality = $. If you want to increase your code quality, you either have to slow your velocity or jack up your $'s -- and usually you end up doing some combination of both, going a little bit slower and spending a little bit more money. And if there's one thing people hate more than…
Being a QA guy myself, I am of the opinion that this sums it up pretty well: https://en.wikipedia.org/wiki/Project_management_triangle