Asynchronous enumerations - again

Almost 2 years ago I wrote about this problem with accessing data from Azure and returning it in a LINQ friendly way. Well not long ago the discussion came up again only this time it was in regard to access data in a Cassandra cluster.

To await or not to await - that is the question

One question that comes up quite often is if you should always use async/await or not. Sadly enough the answer is not simple because there is a trade-off between performance and ease of understanding exceptions.

Do you really want to properly implement TAP?

There is one part of implementing an API using TAP that I've always found cumbersome and that is the guideline to throw argument exceptions before the task is started. I've always been glad that I never had to make the call since I haven't been developing externally available libraries, but recently I had an interesting discussion at work that made me reevaluate my standpoint. Maybe...

Writing async tests

Ever since async/await was introduced in .net 4.5 I've seen people happily using those keywords in their (unit) tests. A usage I believe to be a mistake.

Logical task combinators

When I had to use Erlang for the very first time it was a brand new language and I was in collage. Back then Erlang did not have a logical not function so we had to define our own in order to make our code readable. At least given the knowledge me and my lab partner had at the time. So the other week I had a deja vu moment since I had a Task<bool> that I wanted to negate. At first it felt real weird and I ended up solving my problem in a different way. But then I started to think.

Unexpected Progress

When I was working on the WithProgress extensions I learned something about Progress<T> that I didn't expect.

Task-based Asynchronous pattern - for your pleasure

If you liked my old series of articles covering TAP and especially the different extension methods I showed. Then you will be even happier now.