IDisposable as a Wrapper

I needed to make a bunch of webservice calls from a WinMobile 6 device. None of the calls are particularly heavy, but I wanted to give some feedback that something behind the scenes was going on, otherwise the user gets confused about why he can’t click on things.

My first iteration was this ugly custom Form that took two callbacks as parameters. The first call back did the real work, the second was called after completion so that the UI thread could do something with the results. It was verbose, ugly, unreadable, and confusing. Don’t do that.

Furthermore, it turns out all that marshalling data around between UserWorkItem threads and the UI thread made the service call appear to be taking far longer than it really was. Color me unsurprised.

Duh. Windows has had this ability for over a decade: the WaitCursor.

On a Mobile device, at least the model I’m using, this is rendered as a colorful spinner in the center of the screen. Moral of the story? Read the docs.

I didn’t feel like wrapping all the Service Calls with:

1
2
3
Cursor.Current = Cursors.WaitCursor;
callWebService();
Cursor.Current = Cursors.Default;

Talk about tedious. So I came up with this scheme:

1
2
3
4
5
public class WaitHelper : IDisposable
{
public WaitHelper() { Cursor.Current = Cursors.WaitCursor; }
public void Dispose() { Cursor.Current = Cursors.Default; }
}

Then to use it,

1
2
3
4
using(new WaitHelper())
{
callWebService();
}

This has the added benefit that Cursor.Current will be set back to Cursors.Default inside a finally block, so even if the service throws, you don’t have to remember to set it back yourself.

This does however allocate a bunch of tiny, insignificant and data-less objects all over the place. Though perhaps the compiler or the jitter is smart enough to ignore it and inline the methods.

I don’t care though. I like it.

The answer to pretty much every performance question ever

Which is faster, A or B?

Honestly? Who cares????

This question comes up all the time, and 99 times out of 100, the methods in question are not even close to the real bottleneck in the application.

If you’re asking about a string concatenation operation on the far side of a 250ms database query, son, you’ve got bigger fish to fry. Your time is better spent throwing a where clause on the end of that thing and moving on to fixing your IE6 compatibility.

I intend to write a lot more about this, because its so obnoxiously prevalent in my industry, especially among the hacks that call themselves PHP developers. There is just something frightfully absurd about PHP devs asking inane performance questions and posting ridiculous micro-benchmarks as “proof” of their concerns. PHP was designed to be easy to develop against. It was not designed to be the most performance driven programming language. You don’t get both.

But I digress.

Migrating SVN Repositories

Create the new repository. I had to use my hosting provider’s control panel.

If you were naive, you might think to just zip up an export of your project directory, move it to the new location, and check that sucker in.

But you would be wrong.

That would make you lose your revision history, which kind of defeats the purpose of having version control. Instead, you’re going to want to move the repository itself.

You’ll need to dump the source repository to a text file for later import. Windows, which lacks a lot of cool things out of the box, doesn’t give you the svnadmin tool. But no matter, if you’re using VisualSVN Server (which, if I recall, is about your only option on this platform), its included as part of the installation. You’ll need to change directories to the installation folder before running the dump command.

Oh, and you’ll need to be using an Administrator command prompt. If you can’t figure out how to open one, you probably shouldn’t be trusted with the company’s source control infrastructure.

On VisualSVN, by default, the repositories are all stored in C:\Repositories\ We’re going to dump the “project” repository to file.

1
2
cd "C:\Program Files (x86)\VisualSVN Server\bin"
svnadmin dump C\:/Repositories\project > c:project.txt

Then move that monstrosity to the new server using FTP, or a thumbdrive, or whatever other means are at your disposal. Finally, load it into the new repository:

1
~: cat project.txt | svnadmin load svn/project

svn/project is the directory where the repository will be stored. You chose this directory when you made the repository.

Bam. Now you’ve moved.