Here are the things that caught my eye this week in .NET. I’d love to hear what you found most interesting this week. Let me know in the comments or on Twitter.Follow @codeopinion
I’ve created a pull request on the ASP.NET Core repository.
Atthe beginning, the changes were just about changing the unsafe code (
toa safe version with
.So, it was a very small change. During the review, Oleksandr Kolomiiets, Günther Foidl, and David Fowler have suggested a few additional changes to improve the performance. Thank you very much for taking the time to review the PR! The comments were very interesting, so I’ve decided to explain them in a post.
Quick update to a post I did a while back regarding Orleans Dashboard — additional reporting metrics for your cluster!
As a refresher, Orleans is a virtual actor model framework — a framework that can be used to build new, distributed “primitives”. These primitives’ work can be farmed out to a cluster of nodes as a means of getting “work” done faster than what would be possible if working constrained to a single piece of hardware.
This is a small collection of some tips and tricks which I keep repeating myself in every ASP.NET Core application. There’s nothing ground breaking in this list, but some general advice and minor tricks which I have picked up over the course of several real world applications.
It seemed like an easy feature to implement, a checkout page to place an order. But this payment gateway has a simple API, so we added that. And this email service provider makes it possible to send an email with one line of code!
Finallywe can notify downstream systems via a message queue. The code looks simple, 6 little lines of distributed systems code.
But those lines hid a dark secret that we only found after launching. Customers complained they didn’t get their email. The back end system wasn’t getting updated from our messages. And by far the worst of all, customers complained they saw an error page but still got charged!
Clearlyit wasn’t as easy as calling a few APIs and shipping, we actually need to worry about those other systems. In this session, we’ll look at taking our 6 lines of distributed systems fail, examining the inevitable failures that arise, and possible mitigating scenarios. We’ll also look at the coupling our code contains, and the ways we can address it. Finally, we’ll refactor towards a truly resilient checkout process that embraces, instead of ignoring, the fallacies of distributed computing.