I wanted to try the Vista beta on a fresh Virtual PC this evening, but setup doesn’t cooperate.
Here is how I worked around it:
When you get to the “Install Windows” screen, press Shift+F10 toopen a command prompt. Type DISKPART at the prompt and use the following commands.
select disk 0 create partition primary select volume 1 format fs=ntfs label="vista"
After this I typedEXIT to leave the utility, reset the VPC, and started the installation again.
If everything looks good, I’ll cross my fingers and install on my non-virtual laptop over the weekend.
Unit testing fanatics might find the content of this post disturbing. I’m going to point out a fundamental problem with the TDD approach, and I’m not one to just point out problems, so I also offer a solution.
TDD fanatics often wonder aloud why the weary masses have not thrown off the shackles of hack and slash coding, why they have not come running to the glow of green lights and the feeling of confidence the lights imbue. The merits of TDD are so obvious, the fanatics think, that any software developer should instantly evolve into an enlightened one – a test driven developer. Yet, many are left unconverted.
The adoption of TDD is hampered by a glaring problem. The problem begins in the opening description of the methodology, which typically sounds like the following.
The first step is to quickly add a test, basically just enough code to fail.
Do you see the problem?
Let’s take another example. Here is a shot of the NUnit status bar after test execution.
There is the problem again – do you see it yet?
The problem is no ambitious person will wake up in the morning, walk into the shower, and plan ahead for a day of failure. If they did, they wouldn’t be getting into the shower. People who think that way stay lying in bed, daydreaming about the beach and seeing other people in their wet cotton swimwear. Nobody wants to start with a failure.
The word fail is a dirty, dirty word.
You know what we do with dirty, dirty words, don’t you?
We shun dirty, dirty words. We replace them. We turn them into gentle, obfuscated phrases.
As software developers, we are familiar with many euphemisms. For example, instead of saying software has “defects”, we say software has “issues”. Nowadays, no self respecting company will wait until V 1.0 to release a product. A beta release is as good as gold - it just has a some “issues” is all.
Likewise, AJAX is a new euphemism for “I wish this wasn’t a browser based application”. The A in AJAX stands for asynchronous. Asychronicity sells - not that asynchronicity is a real word, but it sounds sexy and could be the title of a hip dance song.
I could go on and on with these examples, but I hope you, as the reader, have seen the solution I am driving towards.
At this time I’m going to borrow an idea from the British education system – the idea of “deferred success”. Instead of saying that a child has “failed” a class, British schoolteachers want to say the child has merely “deferred success”. The word “fail” could scare a child away from future education. A brilliant idea from you bloody Brits.
Let’s apply the concept of deferred success to test driven development.
The first step is to quickly add a test, basically just enough code to defer success.
Doesn’t that statement make you feel success is just around the corner? Why, the word success even appears at the end of the sentence! No nasty f*** words are jumping off the screen, filling developers with a sense of fear and foreboding.
Even NUnit looks better after two changes to StatusBar.cs and a recompile. I need to get in touch with the PM for Team System unit testing ASAP.
Now the choice is up to the test driven development community. They can continue to force failure after failure on software developers, or they can choose the kindler, gentler path to test driven development.
I hope my posting will not defer it’s success in convincing them to make the right choice.
It was a quiet weekend morning, and I thought I’d write up a quick blog posting with the above title. About 1400 words later, I realized I had zoomed past post length material into article length, so I put Design Considerations for Cross Page Post Backs in ASP.NET 2.0 in the main OdeToCode article area. Excerpt:
It’s also interesting to note the behavior of the PreviousPage property during a cross page post back. PreviousPage uses lazy evaluation, meaning no previous page will exist until the first time you touch the property. At that point the runtime will load a new instance of the PreviousPage web form and have it start to process the current request. This might sound odd at first, but we’ll see why the approach makes sense.
The sample code in this post demonstrates that the run time maintains a string intern pool. The intern pool allows sharing of string instances. Interning is primarily a memory optimization, but can also be a performance optimization in some unique scenarios.
The runtime will store strings literals in the intern pool. For example:
using System;
class Class1
{
[STAThread]
static void Main(string[] args)
{
string s1 = "bbb";
string s2 = "bbb";
Console.WriteLine("{0},{1}", s1, s2);
}
}
If you look at the IL code for the above program, you might be tempted to think we are dealing with two different string instances. In other words, s1 and s2 will point to different string objects.
IL_0000: ldstr "bbb"
IL_0005: stloc.0
IL_0006: ldstr "bbb"
IL_000b: stloc.1
This is not the case, as the following program will demonstrate.
using System;
class Class1
{
[STAThread]
static void Main(string[] args)
{
string s1 = "bbbbbb";
string s2 = "bbbbbb";
// this expression returns true
// both string variables reference the
// same interned string
bool b = Object.ReferenceEquals(s1, s2);
Console.WriteLine(b);
// create a new string with the same value
// as the above: "bbbbbb"
string s3 = new string('b', 6);
// this expression returns false
// even though s3 references "bbbbbb",
// it's not the same string instance
// referenced by s1,s2
b = Object.ReferenceEquals(s1, s3);
Console.WriteLine(b);
// See if "bbbbbb" is already interned by
// checking the reference returned by Intern
string s4 = String.Intern(s3);
// this expression returns true
// s4 is pointing to the same object as s1,s2
b = Object.ReferenceEquals(s1, s4);
Console.WriteLine(b);
}
}
I’ve used the snippet of code at the end of this article twice in the last week to clear up some misunderstandings about strings in .NET.
System.String is a reference type in .NET. Don’t let anyone mislead you into thinking otherwise. You’ll hear people saying strings “act like value types”, but this doesn’t mean the runtime makes a copy of the string during assignment operations, and it doesn’t make a copy of a string when passing the string as a parameter.
The equality operator and String.Equals method compare the values of two string objects, and you won’t find a property or method on System.String with the ability to modify the contents of a string – only return a new string object. Because of these two behaviors we sometimes say strings have value type semantics (they feel like value types), but strings are reference types in the runtime. An assignment operation does not copy a string, but assigns a reference. The value given to a string parameter in a method call is the reference, not a copy of the string’s value.
using System;
class Class1
{
[STAThread]
static void Main(string[] args)
{
string s1 = "Hello";
string s2 = s1;
// this test will compare the values of the strings
// result will be TRUE since both s1 and s2
// refer to a string with the value "Hello"
bool result = String.Equals(s1, s2);
Console.WriteLine("String.Equals(s1, s2) = {0}", result);
// next we will check identity
// ReferenceEquals will return true if both parameters
// point to the same object
// result will be TRUE -both s1 and s2reference
// the same object.
// strings are reference types
// there is no copy made on assignment (s2 = s1)
result = Object.ReferenceEquals(s1, s2);
Console.WriteLine("Object.ReferenceEquals(s1, s2) = {0}", result);
// now we will make a copy of the string
s2 = String.Copy(s1);
// compare string values again
// result will be TRUE - both s1 and s2
// refer tostrings with the value of "Hello"
result = String.Equals(s1, s2);
Console.WriteLine("String.Equals(s1, s2) = {0}", result);
// check identity again
// result will be FALSE
// s1 and s2 point to different object instancesbecause we forced a copy
result = Object.ReferenceEquals(s1, s2);
Console.WriteLine("Object.ReferenceEquals(s1, s2) = {0}", result);
}
}
I’m was waiting in the drive-thru lane at the bank today when I picked up the June 2005 issue of Dr. Dobb’s Journal from my backseat. Reading an engrossing article in the car is a fun way to meet new people. When the person behind me honks and shouts “Pay attention, moron! Move forward!”, I know what they are really saying is “I am bored and have nothing to read, will you share?”. You’d be surprised at the conversations that ensue.
One of the articles covered new features in the Linux 2.6 kernel, including the EXPORT_SYMBOL_GPL() macro for use in loadable modules. The macro allows a module to hide it’s API from any module that does not use a GPL-compatible license.
What a great way to punish developers who write Linux software but don’t (or can’t) GPL their work. It’s like a declarative digital rights management system that, like most DRM schemes, inflicts most of it's pain on innocent bystanders.
My latest article: Master Pages In ASP.NET 2.0. Excerpt:
The master page implementation outlined above has another consequence to watch for. Since the master page injects it's controls and markup into a page’s Controls array, any relative URLs in the master page markup may break. Remember, the browser will request the web form, not the master page, so all of the URLs will be relative to the web form. When the web form and master page are in different directories, relative URLs may point to the wrong location. To help alleviate relative URL problems, ASP.NET will rebase relative URLs for server-side controls. Rebasing will build the correct URL to the resource.
P.S. Every tool ever made to format code into HTML has at least one problem that drives me insane.
OdeToCode by K. Scott Allen
Subscribe
Twitter
Search
About
Learn C#