I was listening to the SILY Episode 322 where Darrel talks about setting goals. That reminded me of a goal I had and failed to reach until a took counter measures. But let’s rewind back for a second. Continue reading
I’m doing a series of async/await related blog post on the particular blog. This one might also be interesting for you.
You might not know this, but the 4.5.0 version of the .NET Framework contains a serious bug regarding System.Transactions.TransactionScope and how it behaves with
async/await. Because of this bug, a
TransactionScopecan’t flow through into your asynchronous continuations. This potentially changes the threading context of the transaction, causing exceptions to be thrown when the transaction scope is disposed.
This is a big problem, as it makes writing asynchronous code involving transactions extremely error-prone.
The good news is that as part of the .NET Framework 4.5.1, Microsoft released the fix for that “asynchronous continuation” bug. The thing is that developers like us now need to explicitly opt-in to get this new behavior. Let’s take a look at how to do just that.
- If you are using
async/awaittogether, you should really upgrade to .NET 4.5.1 right away.
TransactionScopewrapping asynchronous code needs to specify
TransactionScopeAsyncFlowOption.Enabledin its constructor.
If you want to learn more about async/await and how to flow TransactionScopes over continuations, I suggest you read the full blog post originally posted on the particular blog.
During my day to day work, we are running a number of integration tests against various queuing systems. In order to have a clean slate after and/or before each integration test run, we need to clean up the queueing system. With RabbitMQ cleaning up, the broker is usually very simple. Continue reading
I wanted to briefly mention a blog post which I wrote on the particular blog. It is a product centric announcement around the Particular Platform about the move towards an async-only API. Although it is product centric I believe this post contains a lot of valuable information around async/await and its benefits and caveats. In my biased opinion, it is definitely worth a read.
Async/Await is a language feature introduced in C# 5.0 together with Visual Studio 2012 and the .NET 4.5 runtime. With Visual Studio 2015 almost ready to be shipped to end-users, we can see that async/await has been around for quite some time now. Yet NServiceBus hasn’t been exposing asynchronous APIs to its users. Why the await?
We have been carefully observing the adoption of async/await in the market and weighing its benefits against its perceived complexity. Over the years async/await has matured and proven its worth. Now the time has come to discuss our plans regarding the async/await adoption in NServiceBus and our platform.
- Future versions of the NServiceBus API will be async only.
- Synchronous versions of the API will be removed in future versions.
- Microsoft and the community have made this decision for you, by moving toward making all APIs which involve IO operations async-only.
- Don’t panic! We will help you through this difficult time.
You’re going to be blown away by the additional benefits that asynchronous NServiceBus APIs will provide. But first, let’s review why asynchronous APIs are such a big deal in the first place.
If you want to learn more about async/await, I suggest you read the full blog post originally posted on the particular blog.
I listen to a few podcasts. Mainly technical ones. I recently got a hint from Mike Minutillo about a podcast called “Stuff I learned yesterday”. I was blown away when I started listening to this podcast. It makes you think more about stuff that you learned. Furthermore, this podcast is full of stories from the podcasters themselves but also from the community. You’ll find the podcast here
One of the recent inspiring and very emotional episodes are
If you have lost someone in your life like I did, you know why I like this one.
Are they even listening?
If you are a parent, like I am, you know why I like this one.
Subscribe! It is emotional, inspiring, makes you laugh, cry, think…
Post picture by http://www.gotcredit.com/
Once you’ve already learned the ins and outs of a library, it may seem obvious how it should be used (and which parts should be avoided). The thing is that, from one project to the next, we often make use of new and different libraries and frameworks and may not appreciate some of the more subtle differences among those technologies.
The better frameworks out there will log all kinds of information, often telling you when you’re using them incorrectly. So don’t just think of log files as something only relevant for production. There are nuggets in there that can really help you in development as well.
Look at your log files at regular intervals. Doing that from time to time and, even better, automating it, can save you from headaches even before you release your products into production. Eventually, this practice will not only prevent bugs but it can also dramatically improve performance in certain cases.
If you want to know how this story goes on, I suggest you read the full blog post originally posted on the particular blog.
In my last post, I explored xunit as an alternative to MSpec. In this blog post, I’m going to do the same with NUnit. Most people underestimate the power of NUnit. It is a great testing framework that has been around since the early days of .NET and Open Source and is still actively maintained. When it comes to tool integration, NUnit has one major advantage: The Resharper plugin is developed by JetBrains and shipped together with every Resharper release. So everybody which uses NUnit never has to worry about if there will be a Resharper integration. Furthermore, they’ll never worry about the plugin no longer being maintained (like in other One-Man-Show-Plugins). In fact there is even a 3.0 Beta release currently available of NUnit, all development is done on Github. Be sure to check out the release notes! Yes, yes nitpickers, it uses attributes and such but who cares?
So to reimplement the basic functionality of Machine.Specifications you need Continue reading
In my last post, I showed how a Heisenbug can look like to you. In this post, I want to explore the different options I was considering to get rid of some of the pesky things around Machine.Specifications. During the work, I did for Machine.Specifications I asked myself more and more if it is really worth maintaining a whole ecosystem of tools when there are excellent frameworks available in the Open Source world. Why did I even look at alternatives? Why didn’t I just say, that’s it and move away from Machine.Specifications? Continue reading