Bring It On

It all started with this excellent post from Herb Sutter, followed by some comments from Jeff who is in turn referencing Chris Sells - a different post from the one that I am linking here, but relevant nonetheless.

I suggest reading the posts in the order I list them. If you followed all the links, you will notice the following:

• There are real-life scenarios where there is a need for some background work to be performed by an extra thread
• Future processors will make applications that utilize many threads a lot faster as there will be real hardware to execute these extra threads
• If the work is UI independent, all is good; .NET 1.1 already has great support for asynchronous calls to be executed on a thread from a pool that is really easy to use; however, when there is a need for sending back (to UI) progress of work performed as well as allowing user to cancel long running work, things get complicated pretty fast
• In order to remedy this, Microsoft has introduced a new class in .NET 2.0 called BackgroundWorker; Chris links to an existing implementation today that even works with Compact Framework (very cool)
• Unfortunately, MSDN provided sample for BackgroundWorker usage in expected scenario is somewhat flawed; the problem is that long running operation they use (Fibonachi number calculation) is performed with recursive call (simplest form of implementation) which makes cancelling the work very complicated - the code as presented will work, but the cancellation will not be immediate, as it might take quite a while to return from deeply nested recursive call; contrast that to reimplementation of Sells' MSDN article about Pi calculation which is an excellent example of the benefits that BackgroundWorker brings to the table

Threading is still hard, but classes like BackgroundWorker will make one class of problems a lot easier. However, as evident even from a MSDN example for it, the fight for simplicity is still not over, and there is a lot of space for code leading to unintended behavior.

I have just finished “Refactoring” book from Martin Fowler. Here are my impressions - in short, it is very good. Note that this comes from a seasoned C++ and to a certain extent C# developer, so no worry about samples in the book using Java.

I find the following most useful:

• Some of the refactorings mentioned are completely new to me (after 8 years of professional coding and almost 20 with computers in general I do not consider myself a beginner)
• Even though many developers I know perform refactoring on daily basis, the mechanics of it has been mostly chaotic and semi-random; the book provides clear steps on how to slowly and incrementally perform a certain refactoring making the process as easy as possible and safe too
• Having a naming scheme will help developers talk about and exchange opinions on refactorings more easily

If you haven't, do yourself a favor and pick this book up. Not everything will be new or revolutionary, but it is an easy and light read (400 pages but a lot of code listings).

I heard this phrase the other day on the radio: “... and cheap prices!”.

Err, cheap prices? I don't want to buy prices from anyone, I usually buy products or service.

I recently read a blog entry (can't find it though) that explained that impact of extra unused using (C#) or Imports (VB.NET) is negligible for the resulting code. That might tempt you to just leave them sitting there even if you know you don't need some of them. Don't. There are at least two reasons against this:

1. Name pollution - you will be forced to prefix all (now) ambiguous names of types with their namespaces just because you carelessly imported names you will not use at all
2. Intellisense tools (built in and add-ons like Visual Assist or Resharper) will get confused and will become more nuisance than help for the same reason

Just because you can do something and the compiler will let you get away with it doesn't mean you should do it :)