Ted Kooser is my hero.

I'm a great fan of Nick Parks and his Wallace and Grommit series. Over the holidays my boys and I found this very basic but free stop-motion-animation software on the internet: clayanimator.com. Using an old laptop and a webcam, in an hour or so my 7-year old was happily producing movies like this one. Not Nick Parks yet, but he's got time :)

A few days ago I received via email asking how vShadow library that I created manages to get the same code to run under multiple operating systems (XP/2008 Svr R1-64/2008 Svr R2-32, etc.).

The answer is that the code in question is a C DLL and that there are actually many flavors of that same C-DLL, one per operating system that I want to support. There's a managed code wrapper that determines which operating system it is running on and then uses the appropriate version of the C-DLL. The managed code that does this is on my web site, here.

Which leads me to a new year's resolution. It seems that Microsoft has introduced a file sync framework, the Microsoft.Files.Synchronization namespace. This seems like it could be very useful and I intend to learn more about what this framework can do. It may be that I don't need vShadow any longer. I do have lots of applications that move files back and forth or need to keep directories in several locations synchronized so I'm hoping that this framework will handle some of this for me.

My other new year's resolutions? Well, the usual such as get more exercise. But I've also resolved to bone up these of tech topics:

1. Sharepoint.
   This is the intranet framework at the company where I work, and my hope is to wrap the zillions of little web applications up using web parts and other sharepoint technnologies.
   
   Using sharepoint should result in less proprietary code. I'm also hoping that I'll be able to use the Business Data Catalog functionality to make the data in my applications available to Enterprise Search. I think this could have a big impact if it works the way I hope it works. I've purchased a book, Sharepoint 2007 Development, which I am slowly working my way through. Next up, a Sharepoint 2007 development environment with which to try stuff out (essential to the learning process!)
   
   
2. Powershell.
   I support a lot of batch processes. It can be really difficult to organize batch applications. They are typically not very complex but also not very standard, and there are lots of them.
   
   Trying to wrap them all up in some sort of master application would be an exercise in complexity. Writing tiny little apps to automate each one works pretty well, but then one needs to be able to organize and manage the source code for many applications.
   
   For example, let's say that there's a batch process that pulls data in from two servers, consolidates it and puts it on an FTP server for pickup by a client. Let's say that it works fine for two years and then all of a sudden on Saturday night at 2am it stops working. By then, any direct familiarity with the application would have faded into obscurity so the priority is: 1) how quickly can we review the flow of this application to determine why it has stopped working, and 2) how easily can we alter the flow to get it working again?
   
   This is where I think powershell will really shine for me.
   
   My idea is to have more-or-less standard applications which do things like move files to an FTP site (with logging and validation) and retrieve standard kinds of data from database servers. These applications will then be linked together in a powershell script that can trap errors and perform logging and, since it is a script, can be viewed with a text editor so those Saturday middle-of-the-night emergencies can be resolved with less effort.
   
   I'm excited about this, and on the advise of an associate have purchased Bruce Payette's Powershell in Action. This looks to be a fine book and Bruce Payette is Powershell language dev lead. Powershell is built into Vista and 2008/Windows 7 so I look for it to be something that is stable and has long term support from Microsoft.
   
   

3. XML, more specifically SQL Server support for XML.
   Learning SQL is more of a vocation than an end in itself. One can always learn better, more efficient ways to structure a query and there are a zillion obscure techniques for making queries better/simpler/more efficient.
   
   I firmly believe that XML and its attendant technologies (XSL/XQUERY/XPATH, etc.) will supplant SQL as the way that enterprise data is natively stored. SQL Server 2005 and 2008 have much improved support for XML and one of my goals is to gain a better understanding of the limitations and advantages of this support.
   
   I know, for example, that XML data stored in a SQL Server 2008 column of type XML can be queried with XPath. This strikes me as really potent stuff. Have a bit of data with a lot of variation? Put it in XML then put the XML in your table, rather than creating a really complex relational schema.
   
   Let's say that you're designing software to track employee parking passes. You need to store information about the type of vehicle for which the parking pass was issued. Moreover, let's say that that the information varies a lot: Some vehicles are personal cars, some are company cars and some are large trucks, and that the type of information that needs to be stored is different for each of those types.
   
   The relational design for this could be complicated: A pass has a vehicle, but company vehicles have insurance info and large trucks have owner/registration info. Personal vehicles have neither.
   
   Storing this vehicle info in XML could really simplify the database design. Just have a "vehicleInfo" XML column containing an XML document with the vehicle info. The schema of the XML document is different for each of the three types: company car, truck and personal vehicle, and stored procedures and applications can delve into this data.
   
   I want to learn more about the performance impact of storing data in XML format in SQL databases, and about the limitations in querying and updating this data but the concept is really exciting.
   
   Here's an example of an XML query that I'm using now.

select top 1
 b.[name]
from
 dbo.tApplication a
  LEFT OUTER JOIN tReferral AS b ON b.[id]
   = a.[xml].value('(//application/personal_information/@s1_referred)[1]','varchar(50)')
where
 a.[companyid]=@CompanyID
 and a.[isdeleted]=0
 and a.[dateapplied] between dbo.WeekBeginning(@TodayDate) and dbo.WeekEnding(@TodayDate)
group by
 b.[name]
order by
 count(distinct a.[id]) desc

On the subject of XML, but not really a resolution: I've decided that XML works really well for web apps where you want to provide save/cancel and the data presented in the form is contained in multiple tables.

For example, let's say that you have an invoice with a list of purchased items. You want to enable the user to edit the invoice and the items (add a new item, delete an item, change a quantity, change the shipping address on the invoice, etc.) and you don't want *any* of the changes to take effect until the user clicks on "save".

The approach I've started using for this case is to use XML to pass the data back and forth to the database. My business layer gathers the data up from the various relational tables and packages it up as XML before passing it to the form. The form receives the data as XML and persists it. At save, the XML is updated and passed back to the business layer which breaks it back part into into its relational components and updates the database where necessary.

This seems to be working pretty well although I haven't really tried it yet on anything where performance issues would show up.