Monday, May 23, 2005

A memorable metaphor

I first started teaching technical classes in 1992 when I joined a software company. At that time, NT 3.51 was just coming out and our mainstream software product was written in Cobol for the VAX and AS/400. I had experience in both Cobol and RPG at the time and taught the same material to two different audiences. Over the last 13 years, I've developed materials and delivered training for VB (and ASP), C++, Java, .NET (C# and ASP.NET) and even taught part-time evenings and weekends at UNH for several semesters. One thing I've learned when trying to convey new concepts and materials is to find ways to relate to the audience and their experiences. Another technique is to use memorable analogies and metaphors that really jog your mind and cause you to stop the stream of consciousness and take notice. Which brings me to the subject at hand. Rebecca has done just that with her MetaData Metaphor post. Not only is she very smart and dynamic (I've been in the audience when she spoke at an Xml East DevCon, her TechEd keynote last year, and Chris Sells' Applied Xml last fall) but she has the gift of communicating ideas which cause you to pause and take notice.

P.S. Thanks for the explanation Rebecca - I honestly said “huh?” when I first saw “SWF” so that means I confess to being married for some time and ignorant to the ways of the dating world.

Original post

How well traveled are you?

I spent 10 years as a “road warrior” consultant working for software companies and pure consulting companies. Most of my travel was inside the U.S. One side of the story it doesn't tell is how much time away from home all this travel cost. Found this via Scott Reynold's blog:

Your Travel Profile:

You Are Very Well Traveled in the Midwestern United States (75%)
You Are Very Well Traveled in the Southern United States (62%)
You Are Well Traveled in the Northeastern United States (57%)
You Are Well Traveled in the Western United States (53%)
You Are Somewhat Well Traveled in Canada (40%)
You Are Somewhat Well Traveled in the United Kingdom (25%)
You Are Mostly Untraveled in Latin America (7%)
You Are Untraveled in Africa (0%)
You Are Untraveled in Asia (0%)
You Are Untraveled in Australia (0%)
You Are Untraveled in Eastern Europe (0%)
You Are Untraveled in New Zealand (0%)
You Are Untraveled in Scandinavia (0%)
You Are Untraveled in Southern Europe (0%)
You Are Untraveled in Western Europe (0%)
You Are Untraveled in the Middle East (0%)

Monday, May 9, 2005

Beware Virtual PC Differencing Disks!

Ah, now that I have your attention, please let me elaborate :)

I just read a post by Russ Nemhauser, Virtual PC - Beyond the Basics, and it reminded me of some caveats I had picked up in my trials. I too thought differencing disks were the way to go and in fact set up several “base” installs to test it out. One of my early reasonings was simply because each .vhd image had about 1 - 2 gigs of duplicate information - that is, a base OS plus tools and assorted service packs. I figured I could free up 10 gigs or so with a single base image.

The reality is that the differencing drives quickly grew to 3 - 4 gigs in size themselves! Considering things like the paging file, event logs, IIS logs, temp directories, etc. it made sense why this was. However, in the long run I ended up using just as much disk space if not more as if I stuck with individual images. Plus it meant I had to remember to always cart along the base image or the differencing image was useless. Yes, I know about the new compacting tool but it's waaayyy too hard to do all this for each image to free up space - just check out these posts by John Howard and Rob Eberhardt.

In the end I stuck with having a single baseline image of an OS which I copy and rename to start a new image. I followed Megan's tips on sysprepping virtual machines with the baseline beforehand. This does mean that a new service pack might have to be rolled out to multiple virtual machine images but I would have to do that anyway with differencing drives since the base drive cannot be touched ever again or the differences become invalidated and meaningless.

Original post

Friday, May 6, 2005

BizTalk Project / Assembly Organization Gotcha

I have a real-world experience to share for organizing your BizTalk projects and assemblies. I think the natural tendency is to group “like things” together so if you have an orchestration with a schema or two and a custom pipeline you'd define all these artifacts in the same project. This way they're always kept together in source control, on disk and deployed together.

That same “benefit” is also the “gotcha” to watch out for. In my case, the custom pipeline is used to specify a schema formatted as a flat-file. The problem comes mostly during development and testing. If you update the orchestration you must stop, unenlist, undeploy, rebuild, deploy, bind, enlist, start - we've all done that hundreds of times. The problem is when undeploying the *assembly* containing the orchestration you're also undeploying the custom pipeline attached to the send port that's in the same assembly. BizTalk will then fallback to the standard Xml pipeline adapter on that port by default. Then, when you redeploy you're adding back the custom pipeline again which is where I get tripped up - I keep forgetting to switch the send port back to the custom pipeline.

The moral of this story is to use separate projects/assemblies for your custom pipelines and schemas. While this creates lots of little assemblies running around in your GAC, it can greatly reduce the failed tests because you forgot to rebind things!

Last note: Jon Flanders has more to say about pipeline components. Too bad this came out during the last phases of development for my current project - not enough time and too much to do!

Original post

Monday, May 2, 2005

Running with a clean machine as non-admin

I've been intrigued with the idea of non-admin since around the time I went to PDC 2003. While I had dabbled around with VMWare it wasn't until I loaded Virtual PC that I took virtual machine technology for a serious tryout. At the time, it gave me a chance to play around with Longhorn but it wasn't long before I realized it could be a big part of a consultant's toolkit.

Before VPC, my average for re-paving a machine was usually 6-12 months. In that timeframe, I would end up adding and configuring software for at least a couple of clients as well as a few different development projects I was working on. Add to that the plethora of utilities and typical desktop software and you can see why it started to look like my home office desktop before long! Let's just say my wife doesn't like to go in there and swears it's impossible for me to find anything. My OS would never seem to hold up long; looking back to Win 3.1, that's a lot of repaving over the last 14 years!

Jason's article on his current setup reminded me of what I set out to do when I recently repaved. I made a point to load only the full Office suite and a bunch of essential utilities and did the following:

  • Each client “gets“ their own VPC image - separate configuration, versions, tools etc.
  • One VPC image for our own internal development.
  • One VPC image for each test/play environment (e.g. VS2005 Beta 2)
  • My primary logon account for the host machine is non-admin. I make use of Aaron's MakeMeAdmin and PrivBar tools for those utilities and times that require it.
  • I have resisted installing any development tools into my host machine with the exception of Dreamweaver MX 2004 - which is almost like another “Office“ tool to me.

One caveat - I make my logon account in the development images Admin mostly because it's still too hard not to and be effective. I know there are workarounds but when I'm in “development mode” it has got to be seamless or I become frustrated too quickly. I did, however, manage to last 4 days developing as non-admin about a year and a half ago! Looking forward to, and hoping that VS 2005 can make it truly seamless.

Original post

Specifying the output filename from a BizTalk orchestration

Once again, I needed a short simple answer but found either examples that didn't match exactly or newsgroup posts that were cryptic. In my case, the target system I was feeding data to required me to specify a filename that included the month and day of posting as well as the next sequential number. Thus the format is MyOutputFile_mmdd-nnn.out where mm is the month, dd is the day and nnn is the next sequential number (in the case of multiple runs during the same day). To do this, within the message assignment block you specify:

OutgoingMsgName(FILE.ReceivedFileName) = BTSHelper.GenerateOutputFilename();

Here you are setting one of the message's context properties so it must be within the scope of the construct message. Then, in the SendPort configuration you can use the macro %SourceFileName% and it will be replaced with the filename you set in the message's context.

In this simplified example, BTSHelper.GenerateOutputFilename() is a method on a .NET helper class that contains logic for creating the filename.

Original post