the year of the LINQ

Back in the 90s, business seemed to fall in love with Microsoft Access. Homegrown applications were popping up everywhere and in the short-term they offered relief to business. IT could be slow in response, and an executive's admin could open MS Access and "develop an application" to support a business need by simply creating a couple of tables and dragging and dropping controls onto forms.

It was a quick and easy way to get the job done. These applications grew, and were shared, and eventually became relied upon to the point where they were business-critical.

These applications grew large enough that their poorly designed and developed systems failed. The lesson learned by most was that the MS Access application was good for a short-term fix or a small, personal project that would not expand in scale or scope.

This is not developer snobbery. It's simply a fact. Applications need to be designed and developed by experienced developers if you expect them to support large, business-critical needs. This is a lesson many learned in the past, and now we have the opportunity for history to repeat with the introduction of LINQ.

What is this blasphemy of which I speak? Surely LINQ is the next great development paradigm, no?

No.

Mind you, these are my first impressions of the technology, but you know what they say about first impressions.

Now with the addition of LINQ a "developer" can open Visual Studio, create tables in a database, use LINQ to create a data access layer without writing any code, then create forms and data consuming pages by simply dragging and dropping objects on a page. In minutes you can go from an idea for an application to pushing something out onto the servers for everybody to use without writing a bit of code nor contemplating design decisions.

Sounds like MS Access all over again.

So, all you consultants out there, don't ignore LINQ. Spend time learning it. LINQ will be great for prototyping. Better yet, it will also be a great revenue generator for you in 2009 or 2010. Ronstrodomous predicts you will undoubtedly be seeing a large number of projects rolling through begging you to fix a now business-critical LINQ-based application that Joe from accounting created in 2008.

vsts process template modifications

Here's a little tidbit that might come in handy if you find yourself modifying a process template for Visual Studio Team System. Say you're going to add a new field to a work item type. Seems simple enough. You step through it until you're faced with a dialog box for the newfield. Each required field on the dialog box seems self explanatory, except for RefName.

What the heck is a RefName?

There is no help on the dialog box. The next logical thing is to look for an example to help you out. You click cancel on the input box and look at the list of RefNames for the pre-existing fields. Those certainly look like namespaces to me. So, what is the name space to use for this new field? Is it based on field type? Is it a control namespace?

Maybe it was a lack of coffee that morning, but for some reason it stumped me for a few minutes. I'm sure you've all figured it out already, but just in case you haven't, here's the answer. The key is that it is a namespace, and just like any other namespace you create for your code, you simply create your own. YourCompanyName.FieldName is a good start. Pick a namespace that makes sense not only for this field, but one that can be used for future additions. Once you've decided on the namespace, simply type it into the text box and off you go.

disambiguation, virtual earth, and other words to impress your friends

Ah, disambiguation. It's such a great word. I'll use it frequently throughout this posting because it makes me sound smart. I suggest you use it with your friends and co-workers for the same reason.

Disambiguation is the process of narrowing your search criteria in Virtual Earth from something fairly generic or confusing to something exact. For example, if you were to search for McChord, VE wouldn't know for sure if you meant McChord AFB or something else, so VE would need you to clarify before showing you a map.

That's where disambiguation comes into play. Virtual Earth will prompt you with a list of possibilities - forcing you to disambiguate by selecting a specific location.

Disambiguation, disambiguation, disambiguation...

The easiest way to handle disambiguation is to let Virtual Earth handle it for you. The way you do that is to set the ninth argument in the Find method to true. This argument is the useDefaultDisambiguation argument and basically it tells Virtual Earth to prompt the user with a list of possibilities if their criteria isn't specific. The code for this is simple and looks like this:

<script type="text/javascript">
var map = null;
var results = null;

//called from body.onLoad
function GetMap()
{
  map = new VEMap('MapDiv');
  map.LoadMap();
}

function FindLocation()
{
var where = "McChord";
try
{
 map.Find(null,
  where,
  null,
  null,
  0,
  10,
  true,
  true,
  true, //useDefaultDisambiguation
  true,
  ProcessResults);
}
catch(e)
{
 alert(e.message);
}
}

//callback function for map.Find
function ProcessResults()
{
}
</script>

So, in the code block above, the second to last boolean value is the argument called useDefaultDisambiguation. Again, setting this to true uses the default Virtual Earth disambiguation box. The code above should pop a disambiguation box with a list of options.

"But wait," you say in your leather pants and best Zoolander accent. "My users are super smart and sexy. They would be insulted to be questioned by a simple tool such as this computer. Remove that small boxy thing from my sight."

That, my friend, is what we like to call customization. Another big word. That's right. Disambiguation customization. How is my brain so big?

If your users are too smart and sexy for disambiguation, you can set up Virtual Earth to just use the first (what it considers the "best") option from a list of disambiguated locations. In other words, if you typed in McChord, Virtual Earth would guess that you might mean McChord AFB and take you straight there.

Giving you the option to show or hide the disambiguation box allows you to customize the experience to your users. If you have a savvy user base you can probably suppress the dialog box. If you feel that some of your users would be confused or mad if they are brought to the wrong Portland or Bangor, then you will probably want to show them the disambiguation dialog box.

This post is getting long, so I'm going to save custom disambiguation for the next post. Until then, happy coding!