Setting TFS work items to default to be unassigned

Wouldn’t it be nice to have your work items in Team Foundation Server default to be “unassigned”, so that it is easier to determine what jobs are being worked on and what are unallocated?

Well it turns out this is possible.

First of all, you need to export the work item definitions that you want to customise:

cd "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE" witexport.exe /t tfsserver /p ProjectName /n Bug /f c:\Bug.xml witexport.exe /t tfsserver /p ProjectName /n Task/f c:\Task.xml

Now open these .xml files, locate the “Assigned To” field and update it to be the following:

 <FIELD name\="Assigned To" refname\="System.AssignedTo" type\="String" reportable\="dimension"\>

 <HELPTEXT\>The person assigned to do the work</HELPTEXT\>

 <ALLOWEDVALUES expanditems\="true"\>

 <LISTITEM value\="\[Project\]\\Project Administrators" />

 <LISTITEM value\="\[Project\]\\Contributors" />

 </ALLOWEDVALUES\>

 <PROHIBITEDVALUES\>

 <LISTITEM value\="Project Administrators" />

 <LISTITEM value\="Contributors" />

 <LISTITEM value\="domain\\tfssetup" />

 </PROHIBITEDVALUES\>

 </FIELD\>

What this does is limit the users that are displayed in the “Assigned to” drop-down list box to be just the direct project administrators and contributors.

Import these back into TFS:

witimport.exe /t tfsserver /p ProjectName /f c:\Bug.xml witimport.exe /t tfsserver /p ProjectName /f c:\Task.xml

Next, from Team Explorer, right-click on the team project and select Team Project Settings | Group Membership. Click on the ‘New’ button and create a new project group named “Unassigned”. Select the [Project]\Contributors group and add the [Project]\Unassigned group as a member. Now, select the team foundation server from with the Team Explorer, and right-click and ‘Refresh’ to reload the new templates.

ADSL2+ is here!

In the time it takes to have a shower, our broadband connection has been swapped over and we now have ADSL2+!

ADSL1 (Before, Telstra DSLAM) | | Upstream | Downstream | | — | — | — | | SNR Margin | 24.5 dB | 24 dB | | Line Attenuation | 34.5 dB | 20.0 dB | | Speed | 256,000 | 1,536,000 |

ADSL2+ (After, Agile DSLAM) | | Upstream | Downstream | | — | — | — | | SNR Margin | 9.0 dB | 9.0 dB | | Line Attenuation | 38.5 dB | 21.0 dB | | Speed | 942,600 | 11,467,480 |

Internode have the facility to customise the ADSL2+ profile, so tweaking that may improve things slightly. I’ve also got a Central Splitter that I plan to install as part of our house extensions so that should help things slightly too. But you can’t complain about a 10x improvement!

Data constraints in a multi-tier application

I’m wondering about what are the best practises, particularly in a .NET world for this kind of scenario, which must be pretty common. My goals are to a) have decent performance and b) have as few instances of separate (but identical) constant values as possible. Here’s the scenario:

1. You have a database with some tables, and say a table has a varchar column with a maximum length of 255 characters. All good so far! (Constant count = 1)
2. You then create a .NET 2.0 DataSet with TableAdapters for that table, so now the DataSet also knows that the column has a MaxLength of 255. (Constant count = 2)
3. You now create a business object which has a property which also maps to the same column (and would be persisted by passing it back through the DataSet/TableAdapter from step 2). You add checks to this property to ensure it also never gets larger than the maximum length allowed. (Constant count = 3)
4. You create a web form (or a Windows Forms for that matter) that has a text field for the user to edit the same column. You set the maxlength attribute of that text field so the browser restricts the user to the size limit for that field. You also add a server-side validator to validate the text field and enforce that size limit (just in case their web browser ignores the maxlength attribute). (Constant count = 4)

We’ve managed to embed the value ‘255’ at least 4 times in our application! While that may not bother some people, it it does annoy me. The concept of having a single constant that represents a value and allows you to easily change the value in one place should you need to is something I’ve adopted for a long time.

So how can we reduce this down?

Assuming that we’re going to stick with a normal relational database and keep the limit for the column there, then that’s one instance we can’t remove.

It is true that we could use database queries to retrieve that value and use it all over our app, but I’m pretty sure the performance for that would not be ideal, and it does mean that some potential compile-time checks might be missed.

If you assume that your UI tier only talks to the business layer, and the business layer is the only thing that talks to the data layer, what is the best way to percolate through these kind of values with as few separate constants as possible? If I change the length of the column in the database, I want to change as few constants in my code as possible, so that there’s less chance I miss one and cause a problem with the application.

I’d be interested in other people’s thoughts, or if anyone has links to content that covers this topic.