I just published the source code for my FixEncoding pipeline components for BizTalk Server 2006 to GitHub as well. FixEncoding provides two custom components that can help you resolve issues when resolving charset/encoding issues when receiving or sending messages.

I haven't touched FixEncoding in a while, but I still find it very helpful on a lot of projects. You can find the new repository here: http://github.com/tomasr/fixencoding/

Nick Heppleston, a fellow BizTalk blogger and user of my PipelineTesting library, left a comment on a recent post asking why I chose to put the library code on GitHub instead of CodePlex. I think it's a fair question, so let me provide some context.

As many of you are probably aware of it by now, there has been much talk lately about Distributed Version Control Systems (DVCS), as an alternative to the more traditional, centralized control systems that have been common in the past (and still are). DVCS has gained a lot of traction lately, particularly with Open Source projects because it really suits the already distributed nature of Open Source development.

For a long time I remained fairly skeptical of DVCS tools. To be honest, I just didn't get what the fuzz was about and centralized systems had worked just fine for me. I use CVS, Subversion and Team Foundation Server on a regular basis, and you can use all of them successfully with your projects. Obviously, each one has its strengths and issues, but they are all very usable tools.

However, during last year I've been working on a bunch of different projects where the workflow that suited my work style and my requirements best started to make using a centralized source control system a bit harder than it used to be before.

This made me realize that for some of the things I do, a centralized control system just doesn't cut it anymore. In other words, I crossed some invisible threshold where the SCCS stopped being an asset and started becoming a liability. Instead of having source control be a painless, frictionless process, it was becoming something I dread to deal with. And that's when I finally understood what DVCS was all about.

Why GIT?

So at that point I started to look into DVCS tools and playing a bit with them. There's a good discussion of some of the most important DVCS tools around, but in the end I finally settled for GIT, using the msysgit installation on my windows machines.

So far, I haven't really run into any really significant issues when running msysgit; the core stuff seems pretty solid, at least in my experience. I know there are some issues with git-svn in current builds, but I haven't used it yet so I can't comment on that.

I'm still very much a newbie at this, but I'm slowly getting the hang of it, and so far, I'm really liking it. Some aspects of git I really like are:

• Speed: It's pretty fast in most operations, even with large source code files (like tool-generated ones).
• Local branches: I love being able to create and switch between branches very easily and fast. Once you realize how easy it is to use them, you start taking advantage of branching a lot more than on regular, centralized version control systems.
• Single work-tree: Not having to maintain N-copies at the same time of your work directory when you're dealing with N-branches is a real plus in many cases. Of course, you can choose to do so if you like, but it's no necessary, like with other tools.

Why PipelineTesting?

I've always shared the code of my PipelineTesting library through this website. However, I was only publishing snapshots of the code, and while that was fine given how few people use it, it was sometimes a drag. I really did want to share the code more broadly and make it easier to get to some of the changes I was working on even when I had not explicitly released a new official version of the library.

Last year I even commented a bit on this topic and asked for feedback about what the best place to host the code for some of my projects might be, but in the end I didn't make any decision about it.

Why not CodePlex?

CodePlex is a fine site for publishing and hosting your open source projects. I was skeptical about it at first, but it really took off and has a number of things going for it.

The greatest strength that CodePlex has is precisely that it's a Microsoft-technology oriented site. This means that it is a natural choice both when publishing projects that explicitly target the MS stack, and when you're looking for open source projects based on said technology.

I think that, overall, the CodePlex team has done a great job of keeping the site running and making sure it became a viable and valuable service to the community (and Microsoft itself).

The downside of CodePlex is, unfortunately, the technology it is based on: Team Foundation System. TFS is a fine, robust, centralized source control tool. But it also has a few things that manage to take the fun out of using it:

• The support for working disconnected from the centralized server is just not good enough. Sure, it has improved a bit since the initial release, but it is far from a friction-less experience.
• The TFS Client, integrated into Visual Studio. This is supposed to be an asset, but, honestly, I don't always want my source control integrated into my IDE. It can be good sometimes, but it can also be very painful.

Just to set the record straight: Yes, I am aware of the command line tools for driving TFS, and that's certainly an option. Yes, I'm also aware of SvnBridge, which I haven't used myself yet, and it is a really good option and addition to CodePlex, but means running yet another tool.

Why GitHub?

The surest way to get proficient at something is to do it. I want to learn more about DVCS so that I can improve my workflow, and that means using my tool of choice.

For the time being, I'm choosing to stick with git for my personal projects (and some of my work). Given this choice, GitHub was a natural choice as to host my public stuff.

There are several aspects about GitHub that I like, but most of all, its that it is very simple overall, easy to get started with, and mostly stays out of my way. I also find the social aspects of it very intriguing, though naturally I'm not using those yet.

Of course, not everything is perfect in GitHub-land. Some will argue that it doesn't offer as many features as CodePlex in some aspects (like no forums) but that doesn't bother me at this point, as I don't really need that for now.

A bigger issue, however, could be that GitHub is not yet a very visible site among the .NET/BizTalk communities. Heck, I'm pretty sure PipelineTesting is the only BizTalk-related project on it . I think that anyone looking for my library is probably going to find it through this weblog first, so I'm not that worried about it, and the BizTalk community itself isn't all that large (it has grown enormously, but it's still small by comparison).

What's next?

I plan to continue working on PipelineTesting and I have a few features in mind for the next release. If anyone wants to contribute or has suggestions/bugs, please let me know about it!

I will continue to offer a copy of the library for download that includes a snapshot of the source code and a pre-compiled copy of the library, like I've been doing so far. People shouldn't have to install git just to get a copy of the library and use it, unless they need something in the code that's not yet in an "official" build. Of course, I'm a nice guy, so if you really really need it, just ask .

I also plan to start taking advantage of some GitHub features. In particular, I want to migrate some of the "documentation" that I've written over time as blog posts to a more appropriate format that's easier to maintain and to use. For this, I want to put the GitHub Wiki to use and also add a proper readme file to make it easier to get started with the library.

PipelineTesting, git, GitHub, CodePlex, BizTalk

Fellow BizTalk developer Bram Veldhoen was kind enough to send me some suggestions for a future version of my PipelineTesting library, as well as with a question that could point to a potential bug in the library.

The problem basically revolves around consuming a stream returned by the XML Assembler component in a send pipeline when testing under a library. What Bram noticed was that executing the pipeline would seem to work, but trying to read the body part stream of the output message would fail with a ComException with error code 0x8004005 (E_FAIL).

I was fairly confident this should've been working, based on my own use of the library, but I sat down to test it just to make sure. What I discovered was that indeed this can happen if the pipeline context for the test is not aware of the schema for the message being processed by the pipeline.

I added a new test to the library to make sure this was working correctly:

There are a few things to keep in mind about this issue:

1. If you're using the XML Assembler, make sure your pipeline context has all the necessary schemas. There are three ways you can do this, depending on how you are creating the pipeline:
   1. If you're using the original raw API, you can use the AddDocSpec() method of the SendPipelineWrapper class.
   2. If you're using the new, simple API, you can add the schema through the WithSpec() method, which is what the test above does.
   3. If you're using the simple API, but you're dynamically creating the pipeline, you can just add the schemas directly in the XmlAssembler configuration using the WithDocumentSpec() and WithEnvelopeSpec() methods (see the XmlAssembler.cs file for details).
2. Make sure you're testing the right thing. Sometimes, it's enough to make sure that the pipeline can be executed successfully. Remember, however, that pipelines are streaming beasts, so a lot of the work will oftentimes happen just when you read the resulting stream, thus causing the processing to happen.
   This is exactly the scenario we're seeing here today.

The second point is really important, but, for some reason, I never put much emphasis in it when creating the library and when talking about it. I think this is important enough to warrant doing something about it.

For starters, I've committed a few changes to the PipelineTesting repository. Besides adding the test above, I've also added a few ConsumeStream() and ReadString() helper methods to the MessageHelper class to make it easier to validate your components work by simply reading the entire stream from a message. I'll add a few other helper methods for this later on, but the idea is to make it so that you can write less code for your tests.

BizTalk, PipelineTesting

I just noticed that Console 2.00b140 was recently released on its SourceForge site. Downloaded it and started running right away and it's working pretty well so far. I can't tell for sure yet, but it appears to be a bit faster than b139.

The new version seems to built using VC++ 9.0 (2008), but the download zip file comes with the runtime libraries if you need them.

Console is a most excellent utility that I use everyday. Highly recommended if you're not using it yet.

Console

I don't really know much about fonts, but I still love them; particularly monospaced fonts for writing code. I've tried a lot of monospace fonts over the years, including two of my past favorites: Consolas and, more recently, DejaVu Sans Mono. Great fonts both.

However, I'm a huge fan of Damien Guard's Envy Code R font. It's an absolutely beautiful font all around and Damien has put a lot of effort into making it very readable on screen with good hinting. It just looks gorgeous on Visual Studio, particularly thanks to the italics-as-bold trick Damien came up with. (Which reminds me that I really owe Damien at least a few beers if we ever meet!)

Unfortunately, every time I tried to use Envy Code R  on one of my Ubuntu machines, the result was not what I expected; for whatever reason it just didn't look as good as it did on Windows. DejaVu Sans Mono, however, looked good on both platforms, so I was using that as my default font for GVim.

Here's how Envy Code R looked like in GVim under Ubuntu, contrasted against the Windows version (with ClearType enabled):

Ubuntu	Windows

Both images were taken using the Envy Code R at size 13. You should be able to spot several differences right away:

• The text in normal weight (non-bold) looks a bit thinner on Ubuntu
• Some characters really show a significant difference in how they are rendered. The 'm' in particular looks very thin and aligned too much to the left.
• The quotes are a lot harder to see, especially in comments where there is less contrast between the foreground and background colors.

I pinged Damien to ask if he knew what this might be related to. He pointed out that every Operating System had a different way of rendering fonts so it was natural for them to look a bit different on each one. I was, of course, aware of this and even remembered that Jeff Atwood had touched on this topic in the past. Damien also suggested I verified that my Ubuntu installation had sub-pixel hinting enabled.

I went ahead and checked it one more time, and the font settings clearly showed sub-pixel rendering and full hinting enabled:

Damien's comment regarding the settings made me remember something: I use Xubuntu, which uses XFCE as the desktop manager. However, I believe GVim is written on top of GTK+ (Gnome) and wondered if this had anything to do with it.

I went ahead and checked the Gnome settings just in case, and they did not have sub-pixel smoothing enabled; only the "best appearance" setting was checked. So I went ahead and changed the Gnome settings as well, restarted the machine (just in case) and.... no dice. The font still didn't look right.

Solving the Puzzle

After a couple of days of tweaking options here and there, I finally found a combination of settings that allowed Envy Code R to be rendered on Ubuntu a lot better for my taste.

Here's the catch: I had to enable sub-pixel hinting (setting it to RGB), but change the hinting setting from Full to Slight. This makes some fonts look a little bit more fuzzy, but it makes both Envy Code and DejaVu Sans Mono look great (or at least a heck of a lot better), which is what I wanted all along:

Turns out that the XFCE vs. Gnome thing wasn't really important after all. In the end, here's how I got it to work:

1. Open the XFCE Settings Manager, and then launch the User Interface applet.
2. Make sure that the "Use Hinting" option is set to "Slight" and that the "Use sub-pixel hinting" option is set to "RGB" (or whatever is appropriate to your screen).
3. If you have any GVim instances open (or other GTK+ based apps, like gnome-terminal), then close and restart them. Otherwise, they won't completely pick up the changed settings.

If you're using Gnome as your desktop, you can get the same using the Gnome appearance applet:

1. Run the Gnome settings UI by launching the gnome-appearance-properties application from a terminal window. I don't remember where this is located in the UI, but should be easy to get to.
2. Go to the Fonts tab and then click the Details Button. In here, set the Smoothing option to "Subpixel (LCDs)" and the Hinting option to "Slight". Make sure the subpixel order option matches your screen.
   
   
3. Apply all the settings.

Now I can enjoy Envy Code R on Linux as well as Windows .

Ubuntu, Vim, Fonts

Like most other people making a living out of working with computers, I'm first line technical support for my friends and family. This morning my sister came up asking why her computer wasn't booting anymore, so I go to take a look.

It's not pretty.

My sister got a Dell Inspiron 1525 laptop a few months ago, running Windows Vista Home, and it has been working mostly fine since then (except for a minor issue with the wireless network). Last night, however, Windows Update popped up asking her to install the latest batch of critical updates. So she installed them, of course.

This morning, when she turned on her laptop, Vista greeted it with an empty black screen, with just the cursor in it. Shut it down (forcefully), and restarted only to get stuck at the same place.

So I tried the obvious list of things to check:

1. Was the machine hanging up? Not really. You could still move the cursor, and the keyboard seemed to be responding; you just couldn't do anything at all because the black screen came before the logon desktop appeared.
2. Try starting in Safe Mode? All of the three safe mode variants (regular, with network, with command prompt) get stuck at the same black screen.
3. Try booting with default VGA drivers? Nope; still gets stuck.
4. Try booting with the "Last known good configuration"? Nope. Apparently black screen was considered a good configuration. Go figure.

I then tried the recovery console, which did manage to start correctly. Unfortunately, it's useless. I checked for booting problems, and it found none. I then tried going to a previous restore point, only to find to my dismay that the system drive did not contain a single restore point. I'm pretty sure neither me nor my sister disabled system restore, so I can only guess that Dell disabled it when it shipped it from the factory. Why? Who knows.

Off to Google I go. Apparently, we're not the only ones to get hit by this issue. I was able to find at least one other Inspiron 1525 owner stuck with the same problem, but no solutions.

I then turned to Dell support, which was, predictably, useless. Without even bothering to look up any details or see if anyone else had reported a similar issue I got the standard "reinstall windows" response. Oh, well, I also got told that "Dell recommends that you turn off automatic Windows Updates after installing Windows". Not sure what to even respond to that.

Of course, at this point, there's really no other choice, but the fact that is that, for all I know, Windows Update might crap the machine again after repaving it; and for obvious reasons not getting the updates doesn't strike me as a good alternative.

A Suspect

At this point, I still don't know for sure what might have cause the issue. I do, however,  have a suspect. I noticed this morning that Vista had also downloaded and applied the updates on my own laptop (a Dell Latitude D820), without any nasty side effects.

So I checked the list of updates installed and ran into the hotfix mentioned by KB951618:

A black screen issue occurs on a Windows Vista-based computer or a Windows XP Service Pack 2-based computer that has Onekey Recovery 5.0 installed when you upgrade the operating system.

Well, the article never explains what a "Black Screen Issue" really is, but it sounds familiar. We don't have OneKey Recovery (at least in theory), but it's the only thing that sounds even somewhat related.

To be honest, though, I'm not even sure if that update got installed on my sister's laptop or not, since the recovery console doesn't really let you do much spelunking around (and I'm not very familiar with it).

Looks like I get to spend some quality time installing Vista again. Yippee!

Vista, Windows Update, Dell

Neil Houghton asked a couple of days ago if I could share my PowerShell prompt() function. Here's what my prompt looks like:

I tried to keep my prompt relatively short while still on a single line. There are two things I care about in my prompt: The machine name I'm working on (useful when I have VMs opened) and the current path, in abbreviated form.

Thus, my prompt() function looks like this:

The abbreviation of the current directory is partially inspired by Unix (use ~ if it's under the $HOME) and partially by how GVim shortens paths for its tab captions:

Here's the function that takes care of this:

One thing to keep in mind regarding shorten-path: I do a very simple replace of $HOME by ~. The reason it works correctly is that I ensure in my profile script that the $HOME variable has a fully qualified path and "completed" using the resolve-path command. I also modify what the home directory is under PowerShell by using a trick I've described previously.

PowerShell, Customization

I've mentioned in the past some of the color scheme scripts that I've used to make Vim nicer, and there are some really nice ones. However, I was growing tired of them lately. I looked around the Vim site trying to find something better but came up empty handed.

Around that time I ran into Hamish Macpherson's blog, and noticed he was using a really nice color scheme on his code screenshots, and then read in one of his comments that it was a slightly modified version of the monokai theme for TextMate.

I decided to try porting them to Vim, though it's a very loose port. I've been using and tweaking it for a few weeks now, but I'm pretty satisfied with it. I decided to post it here just in case anyone else is interested.

There are two variations to the theme; which one is used can be controlled by setting the g:molokai_original variable in your .vimrc file.

The default option (molokai_original == 0) uses the dark gray background variation similar to Hamish' version, and looks like this:

With molokai_original == 1, the script will use the original monokai colors, and looks like this:

You can get the script from my dotfiles repository on github; where you'll find always the most recent version. Enjoy!

Vim, monokai