Smart copy-paste

Infamous "Copy-Paste" method produced more lines of code than any company or person in whole world. Despite an enormous number of errors it produced this method was (is and probably will be)the most popular way to create code.

You may either deny this or live with this knowledge. If you accept possibility that your code may be replicated you could prepare and make your code more flexible and less error prone for future reuse.

.NET reflection provides you features to make it easier.

For instance, if you need to add tracing for different methods you could ether

a) add different lines with traces like below
public override void Validate()
{
System.Diagnostics.Trace.WriteLine("Validate");
base.Validate();
}

protected override void OnLoadComplete(EventArgs e)
{
System.Diagnostics.Trace.WriteLine("OnLoadComplete");
base.OnLoadComplete(e);
}

b) or just put a line below to each method:
System.Diagnostics.Trace.WriteLine(System.Reflection.MethodBase.GetCurrentMethod().Name);

P.S. Be aware that the reflection has its own cost, taking time for finding methods dynamically

A few links regarding Performance Monitoring

Performance optimization is one of the most complex areas in software engineering.

The first step for performance improvement is monitoring an application and finding bottlenecks. So, here is a couple of related links on this topic:

Can you tell me more about the processor queue length?
javascript:void(0)
Recommended CPU Related SNMP Helper Sensors

Thanks to Yury Habets for sharing links with me

Kill FireFox

Some time ago I was running UI automation tests. Often many instances of Firefox stayed in the memory if tests didn't finish succesfully. To workaround this issue I created a simple batch file that has a single line below:
taskkill /IM FireFox.exe /F
It removes all instances of Firefox from PC's memory. After adding a shortcut to this file I can run it in a single click

FireShot plugin

I've installed another plug-in to Firefox today. It is called FireShot. This add-on allows a web page to be captured and saved in a few clicks. It has awesome usability - I'd recommend it for everyone who uses FF and needs pages' context to be persisted as image files.

Using Fiddler 2 with Firefox

As soon as FireFox is my base browser sometime I need to capture and review traffic which is sends and receives. Using an article at
From the Life of A Developing Developer
I was able to do it minutes.

XML Serializable dictionary in C#

I found a nice implementation of an XML serializable dictionary at
Paul Welter's Weblog
So if you should create something similar it's better take a look before reinventing a wheel :)

Practical TDD

Recently I was asked (twice) whether I preferred to write test first (as it's implied by TDD). Some time ago I published a post at my old blog
http://dima-ch.blogspot.com/2007/04/test-or-not-to-test-first.html

I still believe that it depends on a situation.
When it's a new system that needs to have as good and testable design as possible - this is definitely a case when tests should be written first. As soon as most people prefer not to make additional work (like creating 10 classes instead of one) they will create (it's not guarantied but very probable) concede methods and methods with meaningful names (which is good for code readability). Thus while following test-first practice the good design will be created 'for free' (nothing is free but a cost should be affordable)

Another case is when you have existing system which has no unit tests at all or only few up-to-date. In most cases design decisions for a system are known and changing then is rather difficult and not always needed. In such cases I may create tests for new functionalities after adding some methods. Unit tests in this case are used as short test programs to debug and validate some methods. Sometimes I don't even know what exact result a method should return. Imagine a case when you have a formula that should process a million of entries. You may know the formula but not results until you have the first run. So I may debug a function, run it with some parameters without assertions. After stooping at a breakpoint I note an output value, then modify the test and add assertion for this value. If I find more cases I just add more unit tests to cover all typical ones.

Anyway, I believe that the main measure for unit tests is the code coverage. If you have a code coverage constantly high (90% or even more) then no matter in what order you write tests if you have everything working and tested.