.Net 4.5 has a new feature that allows you to easily do asynchronous programming. You achieve it by the use of the async and await keywords.

At first I thought it was a "nice to have" feature but I wasn't as excited as I was with the introduction of lambdas... Until I used it, and boy am I using it A LOT. I cannot fathom this application (a data profiler) that uses Azure as repository without these keywords.

The data profiler talks to the service via WCF and here's the awesome news: WCF gives you an Async method FOR FREE! That's right, here's an example:

On the WCF service you might have a service interface with the following contract:

        [OperationContract]
        List<Server> GetServers();

When you consume the WCF service you automagically get an Async method

I'm using them with Visual Studio 11 and like lambdas I simply cannot go back to programming without them.

I'm building a data profiler (don't have a name yet) and having to hit the save button seemed kind of odd. The problem I see is that if I'm doing something it's because I want it to be saved eventually, so why not *now*.

Apparently I'm not the only one in this camp because the Google documents also work like this. They're saving your progress as you go along.

What if the user makes a mistake? The users should always be able to undo their actions. Plain and simple.

So far I'm pretty happy with the implementation. To let the users know the changes haven't been committed the text boxes turn murky. When the changes are saved the text boxes return to white.

Technical stuff:

WPF has a very nice new feature for the bindings, the Delay property. It allows you to specify how much time you want it to pass before the changes are committed. This new attribute is just perfect for this application.

This error is thrown by Visual Studio when you run out of disk space.

I got this because I ran multiple performance profiles of my pet project ClosedXML and forgot to delete them as I was testing. Apparently not many people forget to do this because I couldn't find anything about this error on the web.

For the last 6 months I've been working on an open source project to make Excel files and now it's at a point where I can start "promoting" it. I called it ClosedXML and it's hosted on Microsoft CodePlex.

The reason for the name is simple, after seeing how horrible it is to deal with Open XML files my first thought was "If this what it's like to work with Open XML I'd rather work with something that was closed!".

The component is coded in C# but can be used by any .Net language like Visual Basic (VB). It has many features geared toward handling data, for example you can set the value of a cell to an IEnumerable of any kind and ClosedXML will create a table from that object (it works with DataTables too).

For a full list of features as well as a plethora of examples please go to ClosedXML - The easy way to OpenXML.

To be more precise the title should have been "The case against enforcing Test Driven Development (TDD) as a strength jacket onto developers". I have absolutely nothing against people using TDD if it helps them write better code. The problem I have is with forcing developers to think and behave in a way that it's not natural to them. Those who want to use it fine, the ones that don't let them be.

More...

I recently attended an event of .Net Rocks! (one of my favorite podcasts). They were "on tour" making a show on 15 cities throughout the country. The event was divided into the following 3 sections:

• Ivar Jacobson's Interview:
• Richard's presentation on load testing
• Carl's presentation on Silverlight 4

More...

I'm a big believer in the 80-20 rule (http://en.wikipedia.org/wiki/Pareto_principle) because I see it work almost every day while developing business applications. After gathering the requirements and sketching the application, we try to identify that 20% of effort which will give us 80% of the results. Usually after building it, our users are so satisfied with the product that we only have to tweak a few more things and move on to the next high value item. If the business side thinks it's worthwhile to invest more in the product we proceed to identify what else will give the company the best bang for their buck.

The phrase "Use the right tool for the right job" gets thrown a lot and in my opinion it's just overated. You're much better off learning to use a small number of tools very well than trying to learn how to use a plethora of tools because you want to use the right tool for the right job. More...

In part 1 we looked at how we can implement tracing and debugging to know what our program is doing and any error it may encounter. In this post we'll take a look at more ways to use the Trace and Debug classes, the listener's output, and implementing an easy way to get plenty of information in our trace files with minimal code.

In these examples we're going to use a lot of boilerplate code. This is only necessary for us to show what kind of information we want our trace files to have. In a later post we'll learn how to remove almost all this boilerplate code and still have all the tracing functionality we need. 

The main purpose of this post is to give you ideas on how you can implement tracing in your own applications.

More...

This is the first in a series of posts to shed some light into tracing and debugging techniques. We'll start with the basics, configurations (via code and settings file), and then move on to more advanced topics like implementing your own customized trace listener and using aspect oriented programming to trace/debug an entire class/assembly by adding an attribute to it.

In this post we'll take a look at simple debugging and tracing techniques in the .NET Framework. More...