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

The Windows SDK Team blog has posted an open question about some potential features of future SDK releases and is gathering our opinions about it. I'd like to comment a bit on them and provide some feedback.

There are 9 areas the team is looking for feedback on. Let's consider each one:

1. A new, small download of “Core SDK” components is made available to customers, with only the basics.  What components should be included in this product in addition to the Windows headers and libraries?

I think the idea of offering smaller download options is a good one overall, and one that a lot of people (myself included) have asked for a number of times in the past. It's true that the special web downloader/installer we had in the past allowed you to download just parts of the SDK, but it just didn't work sometimes at all, and it was too rigorous in enforcing dependencies that might, or might have not, applied to your specific needs.

However, I disagree on what the contents of the "Core SDK" should be. To me, the most important part of the SDK nowadays is not the Windows headers/libraries, but the SDK tools. Hence, I want the minimum download option to be just the tools. The headers/libraries package should be built on top of the tools package, not the other way around (which is what has happened some times in the past).

My justification for this is that the SDK tools package today is very relevant to all SDK users; both .NET and Win32/64 developers. The headers/libraries package, however, is only relevant most of the time to the second camp.

2. PowerShell Build environment. The Windows SDK would include a script similar to SetEnv that users could run, which will set up an SDK build environment under PowerShell.

I've already said in the past I think this is an excellent idea, which I fully support. For now, I make do with my own custom version tailored to some particular needs of my dev environment.

3. Quick method to install “only .NET” or “only Win32” components.  For example, Win32 developers could quickly choose to receive only Win32 resources in the documents, tools, samples, etc.  Developers focused on managed code could choose to receive only .NET Framework resources in the documents, tools, samples, etc.

I guess this might be a good choice for many people, but to be honest, it's not one I'd particularly use much.

4. Improvements to documentation: better Table of Contents, better filters, search, etc.

Improved documentation is always welcome. The table of contents is the main entry point into it for a lot of people, so organizing it better would definitely be beneficial.

As for the rest, search and filtering really depends a lot on the underlying medium that hosts the documentation itself (the offline help viewer or the online MSDN site), so not sure what the SDK team can actually do to address those issues.

On the face of this, I'd say just focus on improving the content itself.

This does remind me of something: The current local help viewer MSDN uses (and many of the dev-side tools) is not something I'm particularly fan of. I was around when the original HtmlHelp engine was introduced and replaced the old Infoviewer that MSDN/Technet used, and was one of those that complained a lot about it.

I now long for the good old days of HtmlHelp. For example, I've seen the BizTalk SDK docs (which usually ship in the current help technology) in the old HtmlHelp format, and damn, it was way better/faster than what we have now. That sucks.

5. Improvements to documentation: integrate the SDK docs with MSDN docs.

We've had integration between the SDK docs into the MSDN docs in the past. In fact, I'm somewhat surprised it isn't now (I haven't installed either MSDN or the SDK docs in years!).

I used to think this was a good idea; I'm not so sure anymore. Two things come to mind:

• MSDN is already huge, and somewhat bloated. Adding the SDK docs on top isn't going to improve the situation. In fact, considering point 4 above, integrating them is going to make search and filtering them even harder/worse.
• The MSDN/SDK docs integration we had in the past had one significant flaw, in my humble opinion: It tried to integrate the SDK table of contents into separate sections in the MSDN TOC. So if you opened the standalone SDK help, you'd see all the SDK content grouped together, but if you launched the MSDN docs, there wasn't a single place in the TOC where the entire SDK content was hanged of. Annoying as hell.

The second point, in particular, brings up one question: Do we really want them integrated, or merely accessible from a single place?

6. Ship a new “Tools Explorer” to group the tools and provide a more friendly and efficient way for users to search and use the SDK tools.

Not interested. Keep the SDK lean and mean and get it back into shape.

7. Ship a new “Samples Explorer” to group the samples and provide a more friendly and efficient way for users to search and use the SDK samples.

Not interested on an offline tool for this. I think there might be some use for this as an online tool where I could look for a sample and quickly get the code just for that specific sample, instead of having to download the entire SDK samples package (which is huge) to find it.

8. Windows SDK in non-Visual studio IDEs. Provide additional support for other IDEs, such as Windows SDK integration with non-Microsoft development environments, links to Windows SDK documentation from within other IDEs (Eclipse, IBM VisualAge for C++, Borland’s C++ Builder), among other possible integration scenarios.

Haven't been using them at all, so I'm not qualified to really talk about it. I do believe that, for the most part, the SDK should be completely independent of VS and should be usable in a standalone fashion.

9. Create a new Download portal with SDK ‘nuggets’ so that you can download small packages – perhaps a popular tool or file that shipped broken or was missing from a released SDK.

Might be a good idea, but if you're going to do it; do it right and stick with it. The SDK has seen as many changes in installer/downloaders as name changes, and it's a drag.

Don't get me wrong, it's OK to change installers if they bring a significant improvement to the SDK user, but I've never really found that obvious during the several last installer changes. I'm sure each one might have improved something for the SDK team, but from where I'm sitting, it's just been an annoyance to me without bringing any benefits.

It does bring up the question of just what exactly the SDK needs an installer for, besides just registering environment variables and creating the start menu entries...

Windows SDK

Every once in a while someone voices their surprise when they try out one of my Visual Studio Color Schemes and find that all those very large fonts I leave by default on most of them [1].

I've been using Damien Guard's excellent Envy Code R font, usually at 15pt size, which I'm sure looks huge on some screens. It took some time for me to get used to it, as well, but I wouldn't change it now.

 

The reason I started using large fonts when writing was readability. I've been mostly a laptop user for a number of years now, but a couple years back I started using one with a high-resolution (1920x1200) screen.

Having that much screen real state is fantastic, particularly on a large screen, but it can be a bit hard on a 15.4" laptop screen because most things will look pretty tiny. I have good eyesight, but looking at really small text for prolonged hours can really make your eyes (and your brain!) sore.

Instead of just fiddling around with the Visual Studio fonts, the ideal solution would've probably been to adjust the screen's DPI settings accordingly (120 DPI), but the truth is that, right now, that's not really an option on windows if you don't want a lot of applications to (a) look like crap or (b) become unusable because not all the controls fit into the display. Unfortunately, most Windows applications aren't really ready to work with high DPI settings and/or large system fonts, so this isn't as good an option.

However, it turns out that you don't really spend most of your time looking carefully and closely at all applications were text might be small. Instead, you spend most of your time in a few key applications, and simply increasing the font size for those can really make a difference in how you feel at the end of the day.

In my case, those applications are Visual Studio, Vim, Console and Firefox. The first three are easy to set up, and that's why most of my VS settings files include large font sizes for all the key elements (the editor and tool windows).

Tip: If you like/need large fonts in VS, increasing the font size of your tooltips can also make a big difference. This is something I used to do but always forgot to change and make sure my theme files included this setting. The screenshot above uses 11pt Tahoma for the tooltips.

Firefox is a bit harder to set up right, because changing the default fonts used can break a bunch of sites. Fortunately most of the web sites I visit regularly are very friendly to the use of Ctrl-+ to increase the font size.

The downside of using large fonts

There's obviously a downside of using large fonts when programming: You can fit less lines on a screen. Usually, the increased width of text doesn't matter much, particularly on a screen with wide format because there's so much horizontal space. Vertical space, however, is a different matter because it means you can display a lot less lines at at time.

For example, on a full screen VS session using Envy Code R, I can view 55 lines at a time at size 10pt, but only 40 at 15pt. That's 27% less lines!

It's not that I write methods with hundreds of lines, mind you. It's just that even if all your methods are short, sometimes you do have to deal with longer code files. It might be that you have classes with a lot of short methods, or maybe you're dealing with legacy code that's not so nicely factored.

Having a large screen with smallish fonts can make it a lot easier to work on these kinds of scenarios, because navigating and making certain changes/refactorings is a lot easier (even with automated tools for that). For example, one scenario were I really wish I had a larger screen is when dealing with source files that have several shorter classes defined in it (not all people are fans of the "one class per source file" convention).

The solution, of course, is to get a larger screen. For this reason, one of my goals for this year is to get a new desktop machine (after several years desktop-less) with a decent, large LCD. I'm aiming for a 24" display so that I can keep using the 1920x1200 resolution. The downside, of course, is that they are pretty expensive around here, so I still need to save some money before I can afford one alongside with a decent desktop machine.

[1] If you were also surprised about the "15pt Courier New" font; look closely and make sure you install the right font, or replace by your favorite

Programming, Fonts

I had seen the RTM announcement but no mention on when it might be in MSDN. Took a look yesterday, and it was already available, cool . At least the Datacenter/Enterprise/Standard DVD for x86 and x64, Itanium (those are still around?) and Web Server seem to be available.

I'll need to spend some time installing it on a VM to take a good look.

WinServer2k8

Jeff Atwood has an interesting piece about applications polluting the user space, forcing their own folder and file structures and other crap into the user's home folder. He's right, but I think he stops too early.

Jeff's right that the classical Unix practice is a bit better than what Windows has always provided (even on Vista). In a lot of ways, Unix is in a better position because of things that are not directly related, but that do end up helping the issue in the end, like a better (simpler!) overall file system layout, and not having to deal with drive letters (or the stupid registry, for that matter).

However, even Unix suffers from user space pollution quite a bit, though in a different way than Windows user suffer. On Unix, the issue is mostly applications storing temporary and configuration data all over the user's home folder in hidden directories.

Different Kinds of Data

There are several problems that affect how Windows and Windows Applications handle the users directory. For me, however, the lack of good, clear guidelines and the way that application developers abuse the user's home folder are secondary issues.

The real problem to me is that very few developers (or the OS providers, for that matter) realize that there's different kinds of user-specific data, each one with different requirements and storage needs.

I see at least three different kinds of data you might want to store in some user-specific location:

1. The user's own data (documents, videos, music, projects, etc.). Applications will produce and manipulate this data but they should not dictate where and how it has to be stored; that's the user's problem.

   I hate it when applications insist on forcing a specific folder structure on me or on creating their own folders in my documents folder. Exactly because of this is that I've completely given up on using the "My Documents" folder on windows; and consider it pretty much a storage for temporary or throw-away data I don't care about (too many applications putting their crap there).

   I should point out that this category, for me, is, for the most part, about data the user is explicitly aware he is creating, not about other crap the application might be producing as a side effect. In other words, if you're thinking about saving a new file without asking me for a location, don't even dream about storing it here.

   Everything in this location is stuff I want to backup easily, without having to go around excluding folders created by tyrant applications.

2. Application configuration data: This is basically your typical application user-specific settings. To me, data belonging here should be, unless something extraordinary is required, machine independent. This is the settings I simply want to take with me when I switch machines, or that I want to keep synchronized between machines to keep my applications working the same everywhere. Again, this is stuff I want to be able to backup easily without carrying extra loads of crap, but at the same time I don't want to have to deal with it (like navigate through it) unless I explicitly want to modify something here.

   I very much prefer applications store their settings in the Unix-fashion: using simple text files (whatever the format). Even though windows stores the user registry hive file inside the user's profile directory, backing it up is mostly an exercise in futility and it is non-portable for the most part.

3. Other stuff: This will be mostly temporary or cache data used by applications, that I should never have to backup or care about. If it's gone, the application should be able to recreate it as needed or simply work without it. Classical example: a browser's cache and history files.

   Some Unix applications, for example, intermingle this data with their applications settings, which is a big no-no. You don't want to have to worry about backing up your browser settings and ending up with 200MB of its cache in it.

There are probably other kinds of data I'm missing, but the key point is that they are different and should be stored separately. I really wish more application and OS developers started using something like the above discrimination. It would make our lives oh, so much simpler.

Operating Systems