Installing Windows SDK may clobber your environment

I just ran into this today;

I installed the Windows SDK 7.0 on my work machine, and my first clue that things were awry was that my MSBuild scripts were failing with the parameters I was passing.

After a little googling I found the following two links that were both very helpful:

http://weblogs.sqlteam.com/mladenp/archive/2008/05/28/Serious-Visual-Studio-2008-install-bug-that-can-break-your.aspx

Which also referenced :

http://social.msdn.microsoft.com/forums/en-US/vssetup/thread/75057882-f2ff-49b9-9a7a-65f672f8e88f/

After fixing my various vcvars32.bat files things began working again.

operator== does reference comparison by default

Ran into an interesting topic today.  Resharper flags comparison between an object and a string using == as a potential problem.  You are likely going to be doing a reference comparison rather than a value comparison.

I debated this with a co-worker, and then did some tests and found that yes: using == between an object and a string will do a reference comparison, which could yield unexpected results.

Here is my NUnit test case:

[Test] public void TestEquals() { string normalstring = "hello"; object normalobject = "hello"; // the two previous strings get recognized as the same value and are collapsed // into the same reference. Assert.IsTrue(ReferenceEquals(normalstring, normalobject), "ReferenceEquals(str,obj)"); Assert.IsTrue(ReferenceEquals(normalobject, normalstring), "ReferenceEquals(obj,str)"); // These all pass because they refer to the same object Assert.IsTrue(string.Equals(normalstring, normalobject), "String.Equals(str,obj)"); Assert.IsTrue(string.Equals(normalobject, normalstring), "String.Equals(obj,str)"); Assert.AreEqual(normalstring, normalobject, "AreEqual(str,obj)"); Assert.AreEqual(normalobject, normalstring, "AreEqual(obj,str)"); Assert.IsTrue(normalobject == normalstring, "operator== obj,str"); Assert.IsTrue(normalstring == normalobject, "operator== str,obj"); // force new instances of the string "hello": string newstring = new string(new[] { 'h', 'e', 'l', 'l', 'o', }); object newobj = new string(new[]{'h','e','l','l','o',}); //First assert that value comparisons with these new variables are the same as the //previous ones Assert.AreEqual(normalobject, newobj, "AreEqual(obj,obj)"); Assert.AreEqual(normalobject, newstring, "AreEqual(obj,str)"); Assert.AreEqual(normalstring, newobj, "AreEqual(str,obj)"); Assert.AreEqual(normalstring, newstring, "AreEqual(str,str)"); // next verify that the references are not the same Assert.IsFalse(ReferenceEquals(newstring, newobj), "ReferenceEquals(str,obj)"); Assert.IsFalse(ReferenceEquals(newobj, newstring), "ReferenceEquals(obj,str)"); // using the .Equals method correctly resolves the value comparison Assert.IsTrue(string.Equals(newstring, newobj), "String.Equals(str,obj)"); Assert.IsTrue(string.Equals(newobj, newstring), "String.Equals(obj,str)"); Assert.AreEqual(newstring, newobj, "AreEqual(str,obj)"); Assert.AreEqual(newobj, newstring, "AreEqual(obj,str)"); // but == does a reference comparison!!! Assert.IsFalse(newobj == newstring, "operator== obj,str"); Assert.IsFalse(newstring == newobj, "operator== str,obj"); }

(Actual text is in source)

As you can see by running this, the last two lines fail the comparison, because the == is doing a reference comparison instead of a value comparison.

Kanban

I found this excellent article while researching Kanban, Lean, Agile, etc.

Lean development came into focus for me after a comment by Adam Monago about how they were using Lean internally at ThoughtWorks Studios. What I particularly latched on to was the concept of a work pipeline that was continuously being balanced rather than a product backlog + iterations + release plan + estimation pain, etc. (these are my inferences, not Adam's statements)

Given that back ground, the one of the appealing statements that Karl Scotland made in his article was:

The consequences of using a kanban system are that the Product Backlog can be eliminated, because the immediate queue is the only work of interest, timeboxed iterations (i.e. Sprints) can be eliminated, because work is pulled as necessary, and estimation can be eliminated, because work is not planned into iterations.

Does Scrum Work?

Good read.

Does Scrum Work?

How to Improve as a Software Development Team?

Joel Spolsky has some interesting ideas, but one I want to focus on in this note is his "12 Steps to Better Code"

• Do you use source control?
  
• Can you make a build in one step?
  
• Do you make daily builds?
  
• Do you have a bug database?
  
• Do you fix bugs before writing new code?
  
• Do you have an up-to-date schedule?
  
• Do you have a spec?
  
• Do programmers have quiet working conditions?
  
• Do you use the best tools money can buy?
  
• Do you have testers?
  
• Do new candidates write code during their interview?
  
• Do you do hallway usability testing?

I plan on focusing on these points over the next few weeks here at TransCore, in the 3Sixty FM Client team.

Functional Specifications

 

I'm researching Functional Specs.

 

As usual, Wikipedia has a good overview with lots of good links:

http://en.wikipedia.org/wiki/Functional_specification

 

Excerpts:

"A functional specification does not define the inner workings of the proposed system; it does not include the specification how the system function will be implemented. Instead, it focuses on what various outside agents (people using the program, computer peripherals, or other computers, for example) might "observe" when interacting with the system."

 

And:

"In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed"

My main source of good information is Joel Spolsky (again).

Painless Functional Specifications:

• Part 1: Why Bother
  
• Part 2: What's a Spec?
• Part 3: But... How?
• Part 4: Tips

My take-away?

Functional specs should be easy to read, evolutionary documents that help you think through the design and workflow of your intended application.

Development should not start while there are open issues.

On the other hand, the document should not be considerd 'done' until the project is feature complete.

Side By Side Assemblies

Side-by-side Assemblies



Side-by-side assemblies allow multiple versions of the same DLL to be loaded and available to the same application at the same time.



The SxS Manager is responsible for using the manifests of the application and the Side-by-side (SxS) assemblies.



Overview link: http://msdn.microsoft.com/en-us/library/aa376307.aspx









Isolated Applications



SxS is a part of an overall strategy to implement Isolated Applications.



Isolated Applications are important because they enable stable and reliable installations that are unaffected by installation or removal of other applications.



Isolated and SxS applications can also be reconfigured after deployment without re-installing.



Overview of Isolated Applications: http://msdn.microsoft.com/en-us/library/aa375190(VS.85).aspx











Manifests are the XML files that ship with SxS, Isolated, and other assemblies. They describe the assembly, and contain information for binding and activation.



Manifests: http://msdn.microsoft.com/en-us/library/aa375365(VS.85).aspx











To create a manifest you can include it in an actual DLL or .EXE, or you can include a standalone PE file that contains the assembly manifest information.



http://msdn.microsoft.com/en-us/library/1w45z383.aspx





How the runtime locates assemblies: http://msdn.microsoft.com/en-us/library/yx7xezcf.aspx

And related best practices for assembly loading: http://msdn.microsoft.com/en-us/library/dd153782.aspx