Last night's .NET User Group meeting was pretty awesome.  A great friend of mine from Microsoft, Matt Smith, gave us a presentation on the new and upcoming version of Visual Studio called Visual Studio Team System (VSTS); it is code-named “Burton“.  This product was officially unveiled at TechEd so this was a great presentation for those of us that didn't get a chance to attend TechEd.

VSTS rocks!  What I really liked about VSTS is what it's name implies: Team.  It is very heartening to see that MS is making great strides and in-roads into placing the software development process into its flagship development environment.  VSTS encompasses the entire gamut of application development - from the initial concept and envisioning stages all the way through design, development, and testing, to deployment and maintenance.  One very cool aspect is that you can define an application development methodology (such as MSF) and incorporate that directly into how you interact with Visual Studio.  The methodologies are extensible as well so you can even create your own, in-house methodologies.

VSTS seems to really drive home the concept that the team is an integrated, cohesive unit.  I absolutely loved the integration with SharePoint and I feel this will even further enhance the sharing of information across the team.

The things built into VSTS are not all revolutionary - some have existed in other forms and in other tools, but it does offer them in a completely integrated, end-to-end offering which is very exciting.

These are a few of my favorite capabilities built-in (in no particular order):

• Integrated Source Control - the new source code control system (written from the ground up) leverages SQL Server as its back-end data store.  This eases backups as well as makes the data universally more accessible.  Plus when creating a new project in VSTS you start out integrated with the source control system with a new branch.
• SharePoint - when creating a new project you can immediately create a SharePoint team site.  This is fantastic because all team members can automatically see schedules, tasks, and deliverables and share information and documents with each other.  If you haven't had a chance to work with SPS, do!
• Tasks - members of the team can associate tasks (or be assiged tasks) that must be completed.  This goes further than simple 'fix this bug' tasks.  Policies can enforce rules associated with the tasks so that code must be tested and verified before it gets checked into source control.  Awesome.
• WhiteHorse - this is fantastic.  This modeling tool enforces that the model is the code is the model.  You have to see it to believe it.
• FxCop - I am very excited to see FxCop built into VSTS.  Rather than being a separate step in the application development process, you get the warnings to frequent gotchas right in the dev environment.

The list goes on and is not limited to the above, but includes also the built-in performance analysis, stress tests, daily builds, etc.

This is really gonna be a great tool set.  I have a feeling that this package is going to feed coal to the Whidbey freight train.  What is that? Do I see a coffee cup on the train track?

While flying back from Santa Barbara I had a few minutes to sit back, relax, and work on my PC version of The Settlers of Catan.  The coach steward noticed it and was amazed by it.  We spent several minutes talking about it and how it's just a fun game.  This was quite reassuring.  I guess this game's popularity is just booming, especially here in Utah as I now see it almost everywhere.  I'm now even more envigorated and want to see it through to completion.

Today (rather, tonight) I focused on aspects of the player's turn and UI state.  Also, I began work on a different type of hexagon hit test.  You may have read what I posted previously on hexagon hit testing.  This is kind of test, rather that checking for a hit test on the hexagon itself, focuses on hit tests against the corners and the edges (with a certain allowance on either side to make the selection easier).  I'll post my code when I have it working...should be soon!  Also, I extended the hex hit test further to allow (or deny) certain type of hexes to be selected.  This is important for game play because there are times where only water hexes or only resource hexes can be selected.

Just wanted to jot down some thoughts and observations before I retire for the evening.  I had the opportunity to spend this last weekend in California working with a good friend of mine on some software.  It was a gruelling set of days, but such is the way and life of a devout coder (or so I hear - maybe I'm just denying myself the good things in life).

The application that we are writing targets the ASP.NET platform.  One of my tasks this last weekend was to take what we had started recently and migrate it to be more of a component rather than written directly into the website.  This was our intention all along but time restraints caused us to reevaluate our immediate priorities and coaxed us down a different path.  Fortunately, we designed it in such a way that facilitated a reengineering.

The goals in 'componentizing' this application were the following:

• Remove it from the existing sample website (test harness) - DONE
• Write it in such a way to support templated layout - IN PROGRESS BUT DEFINITELY SUPPORTED
• Be able to 'plop' it down in an existing website and with very few changes (no recompilation) have the whole product just work - DONE

In (re)writing this, I also had a personal goal of having the component be deployed once to the web server instead of within each virtual directory.  I'd like to support both installing the app once on the web server for all sites/virtual directories to use it (though this implies some common security across the sites - maybe not such a good idea) as well as installing it individually in the site/virtdir that uses it.  Such functionality hearkens back to the good ol' days of the System Registry.  Well, this is best accomplished in .NET with the Global Assembly Cache (GAC).

So here's what I did:

The natural choice in designing the component was to write a Web Server Control that, when compiled, yields a .dll.  Web server controls can be easily integrated within other websites and also offer several advantages over their .ascx (HTML Server Control) counterparts such as client browser detection, a nice clean object model, templated child controls, and much more.  This was exactly the functionality I needed.

A while back I had written a batch file that I use during the project's Post-Build Event.  This batch file copies the newly compiled assembly to a version-specific folder, unregisters it from the GAC if the same version was already registered, and registers it anew.  If you want a copy, just let me know and I'd be happy to send it to you.  It wasn't until I employed this batch file that I realized that it wasn't really well suited for Web Server Controls due to a peculiarity with the ASP.NET worker process.

As it turns out, if your website utilizes a GAC-registered Web Server Control, the worker process (aspnet_wp or w3wp) copies your control dll into a subfolder within WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files at runtime and holds onto it for dear life.  This was manifested by the fact that changes made to the server control were never reflected within the browser.  This basically means that if you want to use a GAC-registered component that is in development, you'll have to kill the ASP.NET worker process after each compilation.  This was incredibly frustrating.  Now if there is an alternative to this, I don't know what it is, but by the same token I haven't looked into it hardly at all.

Needless to say, I reneged on my desires to have it GAC-registered and settled for having it copied into each virtual directory.  This resulted in a much easier and productive development experience.  Who knows, maybe I try to do things the hard way too often.

I just had an interesting discussion with a coworker of mine and wanted to write down my thoughts on the matter.  The question revolved around whether it was preferred to call Close() or Dispose() on a SqlConnection.  This discussion obviously extends to pretty much any IDisposable/Closeable class but for clarity I'll focus on the SqlConnection object.  His question was spurred on by a snippet from the MSDN documentation that states that the Close() method 'is the preferred method of closing any open connection.'  His question goes a bit deeper than this seemingly inocuous question.  The SqlConnection seems to go counter to some other MSDN documentation that indicates that Close() should call Dispose() where Close() is a more natural means of shutting down an object.

To begin, let's take a peek at what our good friend IL DASM has to say on the matter.  Opening up the IL for the SqlConnection.Dispose() we see the following:

...
IL_000a:  ldloc.0
IL_000b:  switch     ( 
                      IL_0020,
                      IL_001a)
IL_0018:  br.s       IL_0020
IL_001a:  ldarg.0
IL_001b:  call       instance void System.Data.SqlClient.SqlConnection::Close()
IL_0020:  ldarg.0
IL_0021:  ldnull
IL_0022:  stfld      class System.Data.SqlClient.SqlConnectionString System.Data.SqlClient.SqlConnection::_constr
...

As we can see, when Dispose() is called, it first does a check to see if the connection to the database is open (an extraneous check in my book, but oh well) and then it calls Close() if the connection were open in the first place.  Afterwards, it nulls out the connection string.  Now we all know that once an object is disposed it should no longer be used.  An advantage to calling Close() is that you can in effect reopen the connection on the same SqlConnection instance.  When Close() is called (or Dispose() by virtue of what it does) the connection is not actually closed but is returned to the database connection pool - remember that the connection pool is a collection of SQL Connections, not SqlConnection objects.

When deciding on whether you should call Close() or Dispose() you may be persuaded by language constructs to elect one over the other in certain circumstances.  For instance, as a devoted C# developer I find the using() {...} pattern very persuasive.  The advantage of this is you can in essence avoid having to call Dispose() as it will automatically be cleaned up for you:

string getUserName(string id) {
   using ( SqlConnection cn = new SqlConnection(“...“) ) {
      // open the connection
      // execute scalar to retrieve the name
      // return the name
   }
}

Okay, that may be a bit simplistic but it gets the idea across.  If you're using a different language, say, Visual Basic you'll have to jump through other hoops:

Function getUserName(ByVal id As String)
   Dim cn As SqlConnection
   Try
      cn = New SqlConnection(“...“)
      ' open the connection
      ' execute scalar to retrieve the name
      ' return the name
   Finally
      cn.Dispose()
   End Try  
End Function

Obviously I have neither of these snippets of code have been tested - I typed them in here and not within the IDE.

As for a recommendation, it's hard to say.  I definitely have a preference, however: use Dispose(), especially for one-off, autonomous database operations.  Ok, I guess the recommendation would be to call at least one of the functions - don't not call one.  If you have to choose one over the other, call Dispose().  At the end of the day, however, this probably won't be the straw that broke the camel's back...code it how you see fit for your circumstances and how you like. 

I owe lunch to a great friend of mine for helping my solve this.  Jason Walker (a fellow member of our .NET User Group leadership) was kind enough to research an issue I was having.

The team up at Redmond was kind enough to include a method called EnableVisualStyles() in .NET Framework v1.1.  This method alleviates the need to include .manifest files for each .exe for which you want the sleek, cool Windows XP look and feel.  This method should be called prior to any UI or control being presented so it is routinely the first line of code in your app's entry point.  I suppose (for I haven't looked deeply into it yet) that calling this method internally performs a PostMessage() operation which is an asynchronous, fire and forget method (vs SendMessage() which is synchronous).

Through heartache and pain I have found that if your application displays a modal dialog window an exception will be thrown when the dialog closes down.  Well, I was programming along and all of the sudden I was greeted by a very noxious-looking and uninformative System.Runtime.InteropServices.SEHException when a wizard that I had written (which is displayed as a modal dialog) shut down.  It didn't occur to me that my call to EnableVisualStyles() was the offender of this obscure error.  I was trying to figure out whether it was something to do with some custom non-UI to UI thread marshalling or something of the like.  The stack trace revealed the following:

SEHException at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg) at
System.Windows.Forms.ComponentManager.System.Windows.Forms.UnsafeNativeMethods+IMsoComponentManager.FPushMessageLoop(...)
...

I should have read the stack trace more closely before applying my own rationale to solving the problem.

The solution is to call Application.DoEvents() just following the call to Application.EnableVisualStyles() so that the message posted has a chance to complete before proceeding.

Today is the first day that I feel I can officially talk about it (except that which I've already done with a few close friends).  I have decided to leave my current employment and persue an independent route.  Having given my company 6 (!) weeks notice, I will be joining a very good and close friend in California.  My last day will be June 23rd - this, giving me enough time to complete my current project and commitments, will mean that I begin anew on June 24th.

This new position is very exciting for me.  For starters I will be able to work from home, which is undoubtedly a perk.  It will be difficult, however, as I must discipline myself not to be distracted in the minutae of everyday life.  Also I will be responsible for bringing an already-written Win32 app over to a web-based platform with the full, rich UI that customers have grown to expect - daunting, but exciting.

I am very much looking forward to this opportunity.

Arguably, I should learn more about Java.  At times I do feel the need to understand the Java industry, J2EE, EJB, and Sun, and all that goes with it.  I have been bred, indoctrinated, and inculcated if you will in the Microsoft religion.  And believe me, I am very happy as a devoted MS developer.  It goes without saying, however, that as a consultant I should broaden my horizons.  This would empower me in many ways, ways in which I am not yet empowered. ;)  I have written a few small (very small) programs in Java in an effort to become familiar with it but that was several years ago.  And honestly, having a strong background in C#/C++ I found its syntax welcoming and pretty straight forward.

Over the years I have had the opportunity to delve into many Microsoft technologies and feel very much at home writing applications for Windows.  Regardless of whether the apps are of the Managed (.NET) variety or native Win32 applications I'm very much at home.  Whether the apps are your traditional desktop, single-user apps, or multi-user client/server apps, or enterprise-worthy applications that leverage COM+ services I feel comfortable designing and constructing such applications.  I wouldn't have the faintest idea, on the other hand, how to begin to design, architect, program, and deploy such an application using Java and the Java-based tools.

I feel a lot like N. Alex Rupp as he expresses in his blog.  He raises several valid points, focusing on the US vs THEM attitude that developers seem to exhibit.  I have felt the schizm that for some reason exists between Microsoft and non-Microsoft developers (Is it me or is the industry extremely polarized?  Either you hate MS or you love them...there's very little middle ground).  I prefer not to take sides, always attempting to weigh the matter at hand.  When it comes to technology and tools, I have a strong tendency to lean towards MS for the reasons mentioned above.  I also share in their vision and their perception of computing.  I feel that the schizm exists primarily due to a lack of understanding of the other party.  We must all be educated.

This week is kind of bittersweet.  On the one hand I'm sad that I'm missing Tech Ed.  I wanted so bad to go.  And on the other hand we're getting a lot done around the house:

1. we've poured a new entryway/patio/porch area
2. we're pouring a new parkstrip
3. we've ripped out our front 'lawn' and grated the front and back
4. we're having landscapers come in and overhaul our sprinkler system and lawn

So it's been an interesting week so far (and it's only Tuesday).

I have been able to keep abreast of the many goings-on by reading other fellow bloggers' posts.  My good friend Aaron Skonnard is updating quite frequently his blog as well as a good friend and colleague Scott Golightly keeps me posted on what's happening.  So in a way I'm sorta vicariously there, but I hope to make it in person in the coming years.  It's pretty exciting to see that WSE 2.0 has been released/unveiled.  Also it appears that there is quite a focus on Web Services (as if that's not big these days) and SO(A) - exciting stuff!

I tend to get a lot from these conferences (I've been to PDC and VBits several times) and am looking forward to participating in the future...here's to next year!

An interesting discussion was started at the SQL Server Users Group last night.  Basically, the question was whether it was ok to add 26 (!) Text/Image fields to a table.  And if not, what a viable resolution would be.  Now, I've had the opportunity to address a similar issue before and will withhold my solution for the time being from this blog entry so as not to bias the result.

Well, first of all, it seemed like the mandate to include these 26 fields (an arbitrary amount?) came from management which is a glaring red flag to me.  Very rarely (if ever?) does management actually understand database architecture and design and even more rarely how to tune and optimize a database for the applications that use it.  Ok, so management has asked for the ability to store tons of additional (categorized?) information and be able to retrieve it...that's what we need to know, not how they think it should be implemented - that's the responsibility of a knowledgable and creative DBA (more on that another time).

Now the real question: How should the data be stored so that it can be retrieved when needed?  It should be painfully obvious that putting the 26 columns in the table is wrong.  Wrong for a lot of reasons, architecturally and logically.  Some suggestions were:

1.  Create a related table with a foreign key and a single Text field (and possibly other metadata).  When you need the information you join that child table in and return it.

2.  Move the data (if it's file-based) off to a file server with a link in the database back to the actual physical file.

The group (I was a mere observer and didn't venture an opinion) ultimately came to the conclusion that it depends.  It depends on

• the kind of data being stored (binary, text/comments, files, etc)
• the amount of information stored (can you use a (N)VARCHAR instead?)
• does the information need to be queried? (thus possibly requiring Full Text Search capabilities)
• how is the information to be retrieved? (SQL? FTP? etc)

Anyway, what is your opinion? How would you recommend approaching this problem?