Raymond writes an interesting post about how some programs run faster if you hold down the mouse.

This is a classic situation to get yourself into – I’ve probably seen it 5 times, and hit it again recently.

When we’re burning a DVD, the burn engine calls back into the UI layer so that we can update the progress bar. To give the user a single monotonically-increasing progress bar, we (well, Dean, actually) have to play some games with our progress tracking, which means that sometimes we get progress callbacks once a second, and sometimes we get them 100 times a second.

The progress dialog looks fine, but if you look a profile of the burn, you’ll find that a fair amount of time is being spent in the UI code updating. In this case, it’s not a big deal, but I’ve seen cases where programs are spending 90% of their time updating the UI. That takes a 10 second operation and makes it take 100 seconds, which is pretty bad.

The fix? Well, there are two good ones.

The simplest one is to simply update every <N> calls. I traditionally start with N=10, which is guaranteed to same 90% of the overhead, and usually works fine.

If your callbacks are sporadic – as they are in the DVD Maker case – it works better to timebox the updates. Whenever you update the UI, record the time, and then don’t update it again until a specific time has gone by. I usually find 1/4 second to work well.

Paul wrote an informative response to my post on collaboration.

I’ve just been writing some stuff about where I think our group should go in the future, and I’ve decided to downplay pair programming. Not because I think it’s a bad idea, but more because I think that opinions around it tend to be a bit religious.

Instead, I’ve decided to advocate an open environment where pairing can happen in a natural way

• General comments and suggestions
• New climbs to add, both on the eastside and in Seattle and elsewhere
• Better data for maximum gradients
• Descriptions for the climbs.
• Rankings for the climbs. I currently have green, yellow, and red. I’m going to add something beyond red for climbs like the zoo, but if you think I’m off on the relative ranking of climbs, let me know.

More sage words from Rico…

And a followon…

Jay wrote a post entitled Properties? Not my bag, baby.

When I first started writing C# code, I used properties for everything. But recently, I’ve felt that I was wasting a lot of time writing trivial properties. Yes, I know that in Whidbey I’ll be able to use expansions to write them easily, but that still means that I have to deal with the property bodies cluttering up my code.

So, that got me thinking about whether it makes sense to be writing properties in the first place. After a bit of thought, here’s my current position:

Properties are a great thing for component libraries. There are certainly cases where you would want the future-proofing and decoupling that properties gives you.

But when you’re working on a single project that gets built all at once, I don’t think you’re getting any future-proofing benefits, and you have to pay the “property tax” the whole time.

This may be heretical, since “use properties” has been the common guideline.

What do you think?

Josh writes:

I’ve been working professionally with C# for about 2 years now and am just blown away by the things I can do with it. Lately though, I’ve felt like I’ve plateaud at this beginner to intermediate level. Every book I look at is either “Hello, World” or beyond my level of expertise, I feel like I’m always one step behind the game and my code is becoming stale.

That’s a very interesting question. I’m not longer a professional programmer (though I was for a little over a decade), so you’ll also want to listen to the comments that others are sure to write.

If you haven’t read them, there are a couple of books that I’d definitely recommend.

Code Complete
The Pragmatic Programmer

Both of these are currently on my bookshelf (actually, they would be if somebody hadn’t walked off with my copy of Code Complete).

To expose yourself to some new ideas, I’d also suggest:

Refactoring: Improving the Design of Existing Code
Extreme Programming Adventures in C#
Test-Driven Development in Microsoft .NET

Whether you agree with these approaches or not, they are certainly thought-provoking.

The best programmers that I’ve known always have a few side projects going on, where they’re exploring new areas, new environments, etc. If you’ve never done network programming, try writing some socket code, or play around with remoting, or DirectX. Play around with tools, like a profiler, or measure the performance of different options. Get a book on .NET IL and spend some time under the covers (Richter’s book is a good guide here).

Finally – and this may seem like weird advice from a C# guy – spend some time writing some code in a language such as Perl. Scripting languages lead to a different mindset that can be useful in language.

I got this reference from http://www.theserverside.net, but since they require login to get to the link, I’ll instead refer you to the book page

I took a look one of the sample chapters, and I thought it looked pretty good, except for the fact that the first interface in the chapter is named “Environment” (the others are fine). 

I’ve just finished doing a security review of my MSDN columns, and as part of that,
I needed to add some security to an add-in architecture, so the add-in architecture
won’t run antisocial code. The approach taken by .NET security is reminiscent of ACLs,
which means (at least to me) that it’s confusing and I need to read the code 5 or
6 times before I understand it. Along the way, I got a chunk of code from somebody
on the .NET security team, which I’ll reproduce here:

private NamedPermissionSet FindNamedPermissionSet(string name)
{
	IEnumerator policyEnumerator = SecurityManager.PolicyHierarchy();

	while (policyEnumerator.MoveNext())
	{
		PolicyLevel currentLevel = (PolicyLevel)policyEnumerator.Current;

		if (currentLevel.Label == "Machine")
		{
			IList namedPermissions = currentLevel.NamedPermissionSets;
			IEnumerator namedPermission = namedPermissions.GetEnumerator();

			while (namedPermission.MoveNext())
			{
				if (((NamedPermissionSet)namedPermission.Current).Name == name)
				{
					return ((NamedPermissionSet)namedPermission.Current);
				}
			}
		}
	}
	return null;
}
    

Ugly, isn’t it?

The root of the problem is that PolicyHierarchy returns an IEnumerator instead of
an object that supports IENumerable.  This means that I can’t use foreach on
it, and have to write the traversal myself. This decision also means that, without
a collection returned, there’s no place to hang a useful method like “LookupLabel()”
on, so all users are stuck writing the search code themselves (or encapsulating it
off into a separate method).

PolicyLevel.NamedPermissionSets uses a different approach, that of returning an IList,
which is better than an enumerator, as I could use foreach on the IList, but the person
who wrote this sample didn’t because they didn’t know about foreach. If they had,
they would have done the right thing.  

We need to not do this.

We have a ski place in Skykomish, WA (20 miles from Stevens
Pass) that my wife and I have been finishing for the past couple of years (contractor
did the shell to painted drywall, we do everything else). Having music while doing
this is a critical factor, so I brought an old stereo (my first receiver, in fact,
from 1980) and a 5 disk CD changer up there. That’s has worked okay, but when your
used to having all your CDs (somewhere around 200) accessible and automatically scheduled
with your PC-based system, you kindof get tired of the same 12 CDs. (Yes, I know,
I *could* bring up more, but that would require me to plan ahead, and I still wouldn’t
bring up the right one).

I did some research into CD jukeboxes, and wasn’t terribly impressed. They’re a bit
smaller than a PC, but all they do is music, and they don’t implement the system that
my home-based on does. So I held off on buying one.

I’ve recently been working on a C# version of my system, and it’s starting to wake
up and look around, and it’s almost good enough to use. So I decided to build a small
PC to hold my music and run the software.

I started at NewEgg, who supplied the components
for my current office system. I wanted a minimal system with a reasonable size disk
and network. A little research got me a motherboard, case, cd-rom, memory, processor,
fan, and hard disk for $328 to my doorstep. One trip to the computer store to get
another IDE cable and to get a fan that would actually *fit* in the case (its a
micro atx size). That’s a pretty good price for an Athlon 1500, 256M of memory and
40 Gig of disk space.

So, once I get XP on the system, I’ll copy the files over, and probably install the
current version of my software. One problem with the system is coming up with something
that isn’t a big ugly PC. The Micro ATX case helps a bunch, but what do you do with
the monitor and keyboard? My real home system uses IR remote control, which is a possibility,
but the new system also supports using a PocketPC as a controller. At work I use a Toshiba
e740 with built-in wireless as the test for remote control, and it works great,
but I’m not going to use a $500 PPC to control a $330 music system. I needed something
cheaper. I decided to forgo the wireless and bought a reconditioned Toshiba e310 on
ebay for $125, and I’ll use that in the cradle as a remote control (I hope. I think
I can get this to work over the USB, but I haven’t actually tried it yet).