We've all written our share of code. Some days, much more elegant than others. Any of us can go back to something we've written months ago and say "Who coded this garbage?"

But when you have to review other's work, when it counts, when watchful eyes are watching, the words you choose must be carefully selected.

An executive has an application written that needs to be reviewed. They want to know the faults. They want to know whom to blame. Your job: let them know the beauty they hold.

The biggest reason for such a review, is to assess value. Even if you grant them their wish of finding so many faults and so many names that can be assigned blame, the bottom line doesn't change: a lot of resources were presumably wasted. Money, time, people, whatever. I can assure anyone that worked late, read a few extra blogs, textbooks and otherwise did not feel like they were wasting anything at the time.

The funny thing about this exercise is, the application is alive and working. If it wasn't , it wouldn't be a review , it would be an emergency patch or hot fix. And sometimes, the "if it ain't broke, don't fix it" mentality came into play, likely several times , and more than likely decided by someone that didn't do the actual work.

"We have no documentation". Well, a programmer at heart, likes to program, not document. How many artists like to create a catalog and put price tags on their own work? So documentation is typically offered as an afterthought "if we have time", "if you want to allocate budget toward", etc.

"Our test cases are not finding the bugs our customers are". Well, if Unit Tests were mistaken for System Tests, Integration Tests, or outright Smoke Tests, of course that will be the case. How many programmers intentionally put bugs in their code? Ask a programmer to test their own work, what possible faults will they find?

The hardest job of a programmer is to move on after proven, repetitive mistakes are made. When a public speaker says something incorrectly, it becomes mostly forgotten. In the political arena, it will be brought up by opposing forces, but very few people remember or seem to care. When a programmer makes a mistake, it is recorded and repeated, over and over and over, for all to see. Even after it is fixed... "Remember that stupid bug...."

So when it's your turn to review your colleague's work, put yourself in their shoes. Most importantly, because you've been in those shoes before. It's very easy to find the mistakes, it's harder to find the brilliance, but it is there, you just need to look for it. And when you find it, build your review around it. Even those looking for a scapegoat, will be less inclined to scold, and more inclined to appreciate what they have, as opposed to what they don't want to have.

When connecting to the Remote Debugger in Visual Studio, you will need to determine which w3wp.exe process the Application Pool is running under. On a Windows 2008 Server (R2) or Windows 7, the command to do so is:

C:\Windows\System32\inetsrv\appcmd list wp

The process ID will correspond to the value you see in the Remote Debugger window. There will be one process for each ASP.NET application running, so honing in on the exact process will save time loading symbols and waiting to see if the correct symbols loaded.

Ok, so I figured the best way to study for the Microsoft exam was to take notes and make them easily accessible. My blog site seems like a good idea, so stay tuned for blog entries that capture the topics and examples I review for the exam. I wish all of you luck preparing for the exam!!!!

-Vinny Davi

<asp:LinqDataSource ID="LinqDataSource1" 
                runat="server" 
                ContextTypeName="DynamicDataEntityFramework.AdventureWorksLTDataContext" 
                EntityTypeName="" TableName="ProductCategories">
        </asp:LinqDataSource>

<asp:EntityDataSource ID="EntityDataSource1" runat="server" 
            ConnectionString="name=AdventureWorksLTEntities" 
            DefaultContainerName="AdventureWorksLTEntities" EnableFlattening="False"
            EntitySetName="ProductCategories">
        </asp:EntityDataSource>

<asp:EntityDataSource ID="EntityDataSource1" runat="server" 
            ConnectionString="name=AdventureWorksLTEntities" 
            DefaultContainerName="AdventureWorksLTEntities" EnableFlattening="False"
            EntitySetName="ProductCategories" ContextTypeName="DynamicDataEntityFramework.AdventureWorksLTDataContext ">
</asp:EntityDataSource>

When opening a xaml page in Visual Studio, by default the Design View is active. This takes a timely period to load and there are better Design view tools for xaml (i.e. Expression Blend)

Depending on the xaml, you may experience a Visual Studio crash.

If you need to modify the xaml, you will be unable to do so in Visual Studio until you ‘fix’ the issue Visual Studio is having with the xaml. This can be done behind the scenes using Notepad, however a more graceful approach is simply to change the default.

From the Menu Bar, Select Tools -> Options

Expand Text Editor, XAML and Select Miscellaneous.

Under Default View, check Always open documents in full XAML view

Click Ok (see images below)

Happy Coding!!!

WOW!!!! So here are the technology battle wounds for this week!

I needed to build a VS2010 solution within TFS 2008 Builds , however I didn’t have permissions to add the required binaries to the existing TFS Build Server. My solution: create my own TFS Build Server.

So I did some reading, turns out TFS 2010 and TFS 2008 can co-exist on the same server. Well, this must mean they are compatible. Survey Says: NOOOOOOO!!!

So after I install TFS 2010 Build and make this splendid discovery due to poor assumption, I uninstall and install TFS 2008 Build.

The server I was installing on, a Windows 2008 R2 Enterprise Server , AD Domain Controller with all the trimmings! Turns out, TFS 2008 doesn’t like to be installed on a domain controller.

Next step: Hack the installer so that it does like to be installed on a Domain Controller.

Yadda Yadda Yadda, TFS 2008 Build is up and running. It asks me for domain credentials, I use the credentials of the other domain the TFS Server is on, and to my surprise it finds TFS Projects and queries them correctly!

So I hop back over to the other domain and through TFS Team Explorer begin creating a new Build Definition. I make it through that, and Queue a New Build.

Build: Failure. Big. Big. Failure.

I get quite a few of them, make some adjustments and then I hit the wall. On the TFS Build server, I was running the service as Network Service. Well, the TFS 2008 Server on the other domain read  “I don’t know who you are, please go away”. Ok, well that was the more fruitful way it read.

So I’m thinking, this is no problem, I’ll just run the service a as domain user from the other domain. Except of course, that domain doesn’t have any knowledge of the other domain, so you cannot add users from the other domain at the Windows level.

This is when I called in for reinforcements, and got a system administrator involved. He said I could move the server to his domain, which does have associated trusts with the other domain, but I must decommission this server as a domain controller, so they could add it. It also meant much of the existing software could stop working properly. I’m figuring at this point, may as well try, considering the end result, is I’m building a new server from scratch on the system admin’s domain anyway.

After a couple more hours of trying to get the TFS Build Service operational again, the white flag has gone up, a new server will be commissioned and the battle will be fought all over again.

This round goes to the technology goblins, you may have won the battle, but the war will go on indefinitely.

Faithfully submitted,

Vinny Davi,

Avenging software developers from technology terror one battle at a time.