If you are in the Batimore / Washington D.C. area, come out to the next CMAP user group meeting on Tuesday (August 2, 2005).
I’ll be giving a 20 minute presentation on Master Pages in ASP.NET 2.0 as part of the opening act for Brian Noyes. Brian’s feature presentation is also a 2.0 topic: Present Rich Data Interfaces with the DataGridView Control.
User group meetings are a great chance to network, eat free pizza, win prizes, and discuss technology. The setting is comfortable, the screen at the new meeting location is massive, and you won’t leave without learning something.
See the CMAP site for directions and more details.
I hope to see you there.
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);
}
}
OdeToCode by K. Scott Allen
Subscribe
Twitter
Search
About
Learn C#