Home page .NET Core is out. Officially. After a lot of waiting, it's finally a real, finished, RTM thing, and as developers who are passionate about the .NET ecosystem, we're very excited about it. How cool is it to know that we can write code in C# (or VB.NET, or F#, etc.) and have it run on Windows, Linux, and even macOS? So why on earth doesn't NServiceBus support .NET Core yet? Well, good question.
Read moreMany .NET developers have been busy upgrading their code to take advantage of the async and await keywords. These keywords make asynchronous programming a lot easier by allowing us to represent a call to an asynchronous method almost as if it were a synchronous one. We just add the await keyword, and the compiler does the hard work of dividing the method into sections and keeping track of where to resume execution once async work completes. However, it's difficult to hide all the complexity of asynchronous programming behind a couple keywords, and there are a host of pitfalls and gotchas that you should be aware of. Without proper tooling, it's all too easy for any one of them to sneak up and bite you.
Read moreIn order to support the async/await keywords in NServiceBus 6.0, we had to make the first ever breaking change to the message handler API. We realize that this is a big change, and it's not one that we made lightly. The move to async/await required that the Handle method signature return a Task instead of void. At the same time, we replaced IBus with context-specific parameters to make it clearer which messaging operations are available from within a message handler. In order to make the conversion process as easy as possible, we've prepared a screencast that demonstrates how to convert a message handler from the previous syntax to the async-enabled API in NServiceBus 6.0.
Read moreScaling out a web server is easy. All you have to do is stand up a bunch of web servers behind a load balancer like HAProxy and you're covered. Unfortunately, it hasn't been quite as easy to scale out MSMQ-based NServiceBus systems. That is, until now.
Read more
When I make a promise to someone, I do my best to keep it. If I'm pretty sure I won't be able to do something, I don't make any promises about it. Instead, I say I'll try to address it eventually. It's all about managing expectations. In some ways, a promise is like a software interface — a kind of contract between the other person and me. With asynchronous computations, we make promises in software too. They are similar to the promises you and I make, representing operations that haven't happened yet but are expected to happen in the future. In JavaScript, for example, there is an explicit Promise construct. In .NET, this is done with the System.Threading.Task class. Unfortunately, not everyone takes promises seriously — both in real life and in software.
Read moreMSMQ was the very first NServiceBus message transport, and while not overly flashy, it got the job done. You could almost call MSMQ a finished product because, while it's updated with each Windows release, it doesn't really change much. It's solid, reliable, dependable, and overall, it Just Works™. One of the biggest changes we made in version 6.0 of NServiceBus (V6) is that the framework is now fully async. The thing is, the MSMQ's API in the .NET Framework hasn't been updated to support async/await, so what could we do for the MSMQ transport in NServiceBus? Make it go faster anyway. That's what.
Read more
With the upcoming version 6 of NServiceBus, we bid the IBus interface farewell and in its place, welcome a new wave of context-specific interfaces that are more intuitive and easier to test.
Read moreIn the 1960s, Shigeo Shingo, a Japanese manufacturing consultant from Saga City, Japan, pioneered the concept of *poka-yoke*, a Japanese term that means "mistake-proofing." In a nutshell, *poka-yoke* involves saving time and cutting waste by reducing the possibility of defects. Although some number of mistakes will always occur, processes can be put in place to catch those mistakes before they turn into actual customer-facing defects. This is a model we've been trying to follow with NServiceBus -- not only with regards to our internal development processes, but also in our efforts to guide developers toward building message-driven systems. Through countless API design decisions over the years, we've been making it ever easier to use NServiceBus the right way and ever more difficult to use it wrongly. This way, developers naturally fall in to a pit of success.
Read more
The speed of light is actually quite slow. Light emitted from the sun this very instant will not reach us here on Earth for 8.3 minutes. It takes a full 5.5 hours for sunlight to reach Pluto and 4.24 years to reach our closest neighboring star, Proxima Centauri. And we cannot communicate at the speed of light; we must bounce data around between Ethernet switches, slowing things down considerably.
Meanwhile, human expectations of speed are pretty demanding. A 1993 Nielsen usability study found that, for web browsing, a 100 millisecond delay was perceived as reacting instantly, and a one second delay corresponded to uninterrupted flow. Anything more than that is considered a distraction.
Read more
Have you ever been pulled in to a software project and had to figure out how everything works? Often, your options are limited to either sifting through piles of documentation or diving into thousands of lines of code. Unfortunately, the documentation probably became obsolete as the software grew and evolved and, while the code is accurate by definition, it requires a lot of concentration to trace through and figure out how everything fits together.
Ideally, what we really want is a method that reflects the accuracy of the code but is more accessible and easier to understand. The best strategy for large software systems to achieve this is to create a kind of living documentation. The idea with living documentation is to generate it from the existing codebase. This way, the documentation is accurate and can be easily kept up-to-date – just regenerate it as needed (for example, as part of an automated build).
Read more
