I spend most/all of my free time tinkering and playing around with all kinds of things that interest me. My full-time job requires me to have expertise in Microsoft .Net technologies, and more specifically – portal technologies. So, I think about these things more than other interests and have some odd-ball ideas that will get presented here from time to time as raw ideas.
Mythology to Music Project
The basic idea is to take a mythology lineage and construct a series of songs in modern arrangements that convey the core messages of the myths but in a modern context and language.
Status: Not Started
Technology Projects
TechOui Site Redesign 
A redesign of to coincide with the moving from one host to another.
Design Goals:
  • CSS Design / Page Layout
  • Browser neutral (content and admin)
  • Small footprint
  • Compatible with a Partial Trust shared hosting environment
  • Content Management: blog management, page creation
  • Content Export
Status: Phase I complete
Addiitonal Info:
A summary of the architecture coming soon

Dynamic Assembly Loader 
I was working for a client last year (2005) who had some pretty demanding requirements for their portal architecture (SharePoint 2003 based). One of these requirements focused on side by side versioning and conflicted with another core design goal of easy administration of server farms hosting the application. To make a long story short, we wanted to have all the flexibility of side by side versioning and version redirection without having to maintain the web.config file entries on a lot of web server front-ends. The solution to this that we came up with was to put all this assembly version info into a database, and design a loader application that would resolve any assemblies in the application that weren’t resolved by Fusion, .Net’s assembly loader. This worked (not without tons of work and debate over the validity of the design by lot’s of architects and technologists involved) and lead me to the theory that this base idea could be expanded to address deployment issues as well.

The core of my extension to the idea was this:
  • If we can manage the information on what can be loaded, and the parameters associated with the loading, why can’t the physical assembly be centrally located elsewhere from the Web front end server (applies to middle tier too) – a common web server, a file server, a database ?
  • If the remote location was available, the assembly will never really be local, but at the same time will always be local (once loaded) in the assembly cache.
  • All servers would then always have the latest binaries available, without the need for distinct distribution of binaries to the machines.
  • If remote loading was not possible, how about a variation of the ‘click once’ paradigm, where each server runs a small service that has an RSS-type feed pushed to it that defines the assemblies and locations. The service downloads and registers the assemblies, then logs status to the database when ready. Another notification fires when all are ready and these all go live at this time with changes. A management app is used for notifications of problems on particular servers for admin resolution.
Like I stated earlier, the loader part was built and works for managing loading and redirection. I have yet to build and test the remote aspects of this though and prove it. I like the idea though
Status: In Hibernation

A utility for SharePoint 2003 I built in 2005 for examining ghosting in SharePoint sites. WinGhostBrowser is a winforms .Net application written in C# that accesses a Sharepoint 2003 database to gain access to the content of Ghosted pages. There isn't any particular use for this information, and it was built only to have read access to this info for research purposes.
Status: Complete