This is probably a big duh for some of you out there, but if you're running the remote debugger that comes packaged with Visual Studio 2008 (you can find it at C:\program files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger) on a remote machine and you try to attach to that remote machine using Visual Studio 2005, you'll get an error. In fact, VS2005 will tell you that it can't find any servers running on the remote machine. All afternoon yesterday, I was trying to figure out how this one users' security was wrong and keeping me from attaching to a remote debugger he was running when, in fact, I just had an older version of Visual Studio trying to talk to a newer remote debugger.

*sigh*

Maybe now I can figure out what the original problem I was trying to debug was in the first place.

This morning, I had my annual eye appointment and I completely forgot that they might dilate my eyes. Of course, my appointment was also scheduled first thing in the morning - essentially before work. Now, I'm sitting in front of my computer and literally everything is completely blurry. I can't read anything on the screen. It doesn't matter if I get close to the screen or far away, it is all blurry.

Enter ZoomIt! I initially heard about this tool from Scott Hanselman. It is another wonderful tool from Sysinternals (i.e. the guys that make Process Explorer, Process Monitor, etc.) so you know it is pure gold. The tool's primary use is to aide in presentations, so that you can easily zoom in to a portion of the screen so that people can see it better.

Today, I'm using it to just help me read the screen at all. I'm basically touch typing and periodically checking what I've written by zooming in to see if everything looks good. It is actually working pretty well, too.

Thankfully, the blurriness isn't lasting too long. As I'm writing this post, it has already cleared up considerably. Still, ZoomIt has come to the rescue for me this morning.

In case you've been under a rock recently, Visual Studio 2008 was released recently which supports a lot of functional capabilities like lambda expressions. I've been playing around with the lambda syntax in both C# and VB.NET recently and the addition to the languages is great. I did run into one thing that is still frustrating me in VB.NET, though.

Check out the below C# snippet:

TryTimes(() =>
{
   Console.WriteLine("hi there.");
   throw new Exception("haha");
   Console.WriteLine("hi there after   .");
}, 5);

This is the prototype for the usage of a function that could try an operation a certain number of times and then fail if the operation didn't succeed after N number of tries. Obviously, the above code sample will fail every time, but the idea could work alright for file I/O if you're unsure if anyone else might have locks on the file.

The above is impossible to do in VB.NET, though, because VB.NET does not support multi-line lambda expressions. The C# supports them by wrapping the expressions in curly braces, essentially making the lambda expression a block. I wanted to emulate the same thing with VB.NET, but after some fruitless web searches, I came across this MSDN forum posting on VB.NET and lambdas which then pointed to Paul Vick's post on the VB 2008 features that are still in.

I've been wanting the equivalent of anonymous delegates in VB for a long time and I thought, with lambda expressions, I might finally get them. We are a lot closer, but they still don't provide quite the benefit that they could have had we gotten multi-line lambda support. I guess those annoying line continuation characters in VB mess this all up. I think if I could change anything about VB, it would be to make those optional.

On the positive side, though, the intellisense support for VB.NET has increased substantially. For that, I am thankful.

I'm close to finishing up some work on one of my first true TDD projects and it has gone great for the most part. It did take a long time to get started though. The hardest part for me was fighting the urge to just open the designer and start dropping controls. Visual Studio really does guide developers towards a designer-centric approach which, after having done this for a few years, is very hard to resist. What I ended up doing was thinking about the problems that this application was going to solve and starting there. Make your tests define the problem area and move outward. The idea is that, if you can't write your tests that show what your code will do, are you even ready to write the code yet?

I was able to get my first few tests out quickly, but then I hit a block where I struggled with the structure I wanted to follow. This turned out to be good because, instead of coding something up that was substandard, I was able to fight through this struggle and come out with a better solution in the end. In doing this, I discovered a great benefit that TDD provides - you can continue coding even if you don't know all of the answers to all of the problems that your application will solve. For example, I'm still not sure what file format I'll be using in my application (or even if I'll use the file system). It really doesn't matter, though, because I was able to set up an interface and mock that dependency out in my tests and continue with the rest of my application. Had I started with the designer, I likely would have sat around until I had hashed out the file format requirements.

Once I got past my initial hang ups, I was able to fly through the rest of the code. What is even better is that I feel a huge amount of confidence in this code - code that still has no UI around it. I haven't felt this good about code quality in, well, ever.

If you're wanting to start with TDD, I'd like to recommend a few resources. First, read more code. If you aren't using it yet, go get TortoiseSVN and pull down some open source code. The Rhino.Commons repository is an excellent source of code (as well as great utilities). I can also recommend Jeremy Miller's StoryTeller code. I don't do anything with FIT tests, but the code is still a great example of WinForms code driven by tests.

Another great resource is screencasts. Watching someone write their tests first helps immensely. Evan Hoff has a great screencast on TDD. It also shows some of the power of ReSharper.

One final thought for this post is something that Bob Martin spoke about in this Channel 9 interview on programming discipline. Bob pointed out that few disciplines are as fragile as programming is. For example, if even one bit is off in your application, it has the potential to crash. One example of a profession that is also fragile is accounting. If one digit is off in the wrong spreadsheet, the CEO of a corporation can get thrown in jail. The way that the accounting profession has solved this is by entering their numbers twice - with credits and debits. If something gets entered wrong, it won't balance. When the sheets balance, there is confidence in the reported numbers. In the same way, TDD and unit tests provide the balance and confidence that applications are doing what they were intended to do.

I didn't expect to see this in the next version of PowerShell - very cool. It definitely still needs some work, but I like the start. The syntax highlighting for opened script files is nice. I'd like to see some intellisense in there, but it isn't a big deal. If intellisense would slow it down much, I think I'd rather not have it anyway. I think the biggest issues I've got with it so far is the lack of options to customize fonts and colors as well as tab expansion.

I've haven't had a chance to play with anything else, but it seems nice so far.

I'm finding myself wondering if I'm a beta junkie or a CTP junkie.

Why?

Because Jeffrey Snover announced that there will be a CTP release of PowerShell 2.0 next week. I'm not waiting for the beta either - I'm downloading the CTP bits as soon as the post announcing its release gets to Google Reader. Maybe I should change my "beta junkie" title to "pre-release junkie" or "I just like to install things junkie."*

PowerShell 1.0 single handedly turned me into a console user. I do 90+% of my file operations from PowerShell instead of Windows Explorer. I also do a large portion of my pseudo coding at the command prompt to see whether a basic algorithm will work the way I expect it to. I'm very excited to see what the team has come up with.

Update (per post from Jeffrey Snover):

The PowerShell V2 CTP is not for everyone. You should read this PowerShell Team blog entry ( http://blogs.msdn.com/powershell/archive/2007/11/02/ctp-watch-this-space.aspx ) to find out what it is and what it isn't and then make an informed decision before installing the CTP.

I may be an "I just like to install things junkie" but that doesn't mean that you should be to. Be responsible with pre-release software. If you've got production code that relies on PowerShell behavior, etc. you should consider holding off on installing it on your development machine.

* With all these installs I do, I actually do see UAC prompts a lot. And no, I haven't turned off the prompt.

If you live anywhere around Memphis, be sure to be there on November 10. That is when the Memphis Day of .NET is scheduled. It was just announced today that Charles Petzold will be delivering the keynote as well! Charles has already posted about it on his blog. I'm incredibly jealous of all of you who are planning on being there - I had been planning to go but then when I found out when it was scheduled, I realized I had conflicts and wouldn't be able to make it. Of the other speakers scheduled, I got the chance to meet both Keith Elder and Jeff Blankenburg at DevLink and I know their presentations will be great. I know that Colin and others have put a lot of hard work into making the Day of .NET great, so if you get the chance, go out there and show them your support!

It is Halloween after all. It would be a great day to start learning Boo.

Sorry. I couldn't help myself.