Sergio Pereira

dotTrace 3.1 64-bit disabled inside Visual Studio 2008

2010-03-12T18:15:00Z

I work on a web application and I use dotTrace when some profiling is needed. The problem is that I cannot fire off doTrace directly from inside Visual Studio 2008 because the commands and toolbar icons to launch it are permanently disabled. Well, not anymore.

Background

The web application I work on is a 64-bit application. I use a 64-bit version of Windows (namely, Win2008 x64). I installed the 64-bit version of dotTrace 3.1 and it does work stand-alone but it never worked integrated with VS 2008, which is a shame because it contains some neat features like it's enabling the ReSharper test runner to run the chosen test(s) directly under dotTrace profiling. The screen shot below shows how it should look like but on my box these dotTrace commands were simply disabled.

The fix

After much disappointment with the missing features, my fellow Devlicio.us blogger Hadi Hariri put me in contact with Oleg Stepanov.

The first suggestion was trying the 32-bit version of dotTrace, which wasn't an option for me because, as I said, my application and all the supporting utilities are 64-bit, it runs under a 64-bit process, so that's ultimately how I need to profile it.

Then Oleg explained that the problem is that VS is a 32-bit application and it was looking for a registry key in the wrong place, not finding it, and then it was assuming dotTrace wasn't available.

Hmmm... That sounded eerily familiar, didn't it? Once again the little annoyances of developing 64-bit code with 32-bit tools come to bite us.

To fix the problem, just like the other time it happened, we just need to copy the right registry key to its corresponding place under the Wow6432Node key.

Open the Registry Editor and go to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ key. One of its GUID-named subkeys will contain the dotTrace information. Just search for dotTrace and find the right subkey. Now just copy (or export/edit/import) that key under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\ and you're ready to restart Visual Studio and see all the integrated dotTrace features come alive.

[ANN] Chicago ALT.NET shows Rake and Albacore

2010-03-09T23:35:00Z

I haven't mentioned our meetings here in a while but our group has been going strong and enthusiastic all this time.

Tomorrow, March 10^th our topic will be build scripts for .Net projects using Rake and Albacore. I've been using Rake and a little bit of Albacore in my own projects and I'm ready to say that it will take a very serious event to make me go back to NAnt or MSBuild.

Introduction to Rake with Albacore.NET

6:00 pm
Pizza and networking time

6:30 pm

How would you to write your build scripts using a scripting language instead of XML? In this month's meeting we will see how the ease of programming in Ruby can be used to create a much more pleasant and extensible build script.

Rake isn't just for Rubyists or Alphageeks anymore. Albacore helps bring the power and expresiveness of the Ruby language to the world of .NET build automation. Using Rake it's never been easier to handle build automation, test execution, continuous integration and just about any task you need to automate for your build.

Michael D. Hall has been developing software on the Microsoft platform for over a decade. He's been an Alt.NETter for years and is really enjoying the exposure to different ideas and concepts beyond the safe confines of the .NET world. Currently he's a consultant working with Obtiva and has started a Cloud Developer's Group that meets monthly in McHenry county.

Rule "Previous releases of Microsoft Visual Studio 2008" failed

2010-03-07T10:43:00Z

Today I was trying to install SQL 2008 on my box and the setup stopped after checking a bunch of rules. The error message was the title of this post.

A quick search on the internet revealed that somehow the installer didn't believe I had VS 2008 SP1 installed, which I did. The recommendations in the KB article were kind of insulting. There's no way I'd spend hours of my day uninstalling and reinstalling VS and SQL — sorry, no chance. I also could not accept not installing the Management Tools, for example. I also did not have any Express version of VS or SQL installed in this box.

A little snooping around with ProcMon led me to the following registry key:

HKLM\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VS\Servicing\9.0\IDE\1033

In that key I noticed the suspicious values:

"SP"=dword:00000000
"SPIndex"=dword:00000000
"SPName"="RTM"

Without quitting the SQL server installer validaton screen, I changed these values to what you see below, crossed my fingers and rerun the installer validation, which passed!

"SP"=dword:00000001
"SPIndex"=dword:00000001
"SPName"="SP1"

Now, I didn't really guess those values. I looked in a sibling registry key (...Servicing\9.0\IDE\1033) and saw that it contained those new values, then I copied them.

I think I didn't break anything. So far all seems to be working. But, as usual with anything related to manual registry hacking, you have to be really insane to change your settings because you read on a random blog on the 'net. I'm just saying... Don't come crying if your house burns down because of this.

jQuery Custom Element and Global Events

2010-02-21T18:09:00Z

This last week I learned a new thing about jQuery custom events, particularly the ones of global nature. There's good documentation and examples about custom element events, but not much for the global ones.

Why do we need custom events?

Custom events make it easier to keep complex pages under control. They are a pillar for loosely-coupled UI scripts. Let's start with a simple example.

Suppose we have a fairly complex and dynamic page where many elements are Ajax-editable, using in-place editors or any other approach that posts updates to the server. Depending on how quickly the server responds to the request, there's a chance the user can start another simultaneous request before the first one finishes, maybe even seeing inconsistent results, by clicking a button too soon.

In our example — a fraction of what a real complex page would be — what we want to do is disable some of these buttons while the data is being changed, and re-enable them once we hear back from the server.

Click the field to edit it:<br>

<input type="text" readonly="readonly" id="email" name="email"
   value="joe@doe.com" style="background-color: #eee;"/> 

<input type="button" class="userOperation" id="sendButton" value="Send Message">
<input type="button" class="userOperation" id="summaryButton" value="Summary">

Custom Element Events

Let's tackle this problem first with the custom element events. Below is a summary of how these custom events are used.

$('#publisher').trigger('eventName');

$('#publisher1').bind('eventName', function() {
   //eventName happened. React here.
   $('#subscriber1').doStuff();
   $('#subscriber2').doOtherStuff();
   // more...
});

In this case we will make the elements being edited announce that they entered edit mode so that any other element can act on that announcement.

$('#email').
click(function(){
	$(this).removeAttr('readonly').css({backgroundColor: ''});
	$(this).trigger('editStart');
}).
blur(function(){
	$(this).attr('readonly', 'readonly').css({backgroundColor: '#eee'});
	$.post('/updateEmail', $('#email').serialize(), function() {
		$(this).trigger('editComplete');
	});
}).
bind('editStart', function(){
	// "this" is the #email element
	console.log('edit started, this =  ' + this.id);
	$('.userOperation').attr('disabled', 'disabled');
}).
bind('editComplete', function(){
	// "this" is the #email element
	console.log('edit complete, this =  ' + this.id);
	$('.userOperation').removeAttr('disabled');		
});

$('#sendButton').click(function(){
	//code to send a message
	alert('Message sent');
});

$('#summaryButton').click(function(){
	//code to generate summary
	alert('Summary created');
});

This approach works well in the beginning but gets really ugly as more elements need to publish their own similar events or when other new elements need to do somethings with these events too. We will need to bind handlers to all these element's events and the code inside these handlers will start getting longer and probably too far from the rest of the code that relates to it.

One step forward with page level events

Since the events we are producing here really reflect the document state more than any individual field's state, let's move that event to a more top level element, namely the body element:

$('#email').
click(function(){
	$(this).removeAttr('readonly').css({backgroundColor: ''});
	$('body').trigger('editStart');
}).
blur(function(){
	$(this).attr('readonly', 'readonly').css({backgroundColor: '#eee'});
	$.post('/updateEmail', $('#email').serialize(), function() {
		$('body').trigger('editComplete');
	});
});

$('body').
bind('editStart', function(){
	// "this" is the body element
	console.log('edit started, this =  ' + this.tagName);
	$('.userOperation').attr('disabled', 'disabled');
}).
bind('editComplete', function(){
	// "this" is the body element
	console.log('edit complete, this =  ' + this.tagName);
	$('.userOperation').removeAttr('disabled');		
});

$('#sendButton').click(function(){
	//code to send a message
	alert('Message sent');
});

$('#summaryButton').click(function(){
	//code to generate summary
	alert('Summary created');
});

Now we're getting somewhere. We reduced the number of event sources to just one, so guaranteed less duplication. But it still has some shortcomings.

The code is still bound to a different element than the one we want to operate on. What I mean by that is that the event handlers are in the context of the elements publishing the event and the code in the handlers is typically geared towards the elements that need to react to that event, that is, the this keyword is less useful than in most of your common event handlers.

The pattern of these page-level events is:

$('body').trigger('eventName');

$('body').bind('eventName', function() {
   //eventName happened. React here.
   $('#subscriber1').doStuff();
   $('#subscriber2').doOtherStuff();
   // more...
});

But wait, jQuery has real global events too

I had settled down with using the above style of global events until someone at work pointed out that there's another way of doing this, which unfortunately isn't as well discussed: the custom global events.

Here's our code using global custom events:

$('#email').click(function(){
	$(this).removeAttr('readonly').css({backgroundColor: ''});
	$.event.trigger('editStart');
}).blur(function(){
	$(this).attr('readonly', 'readonly').css({backgroundColor: '#eee'});
	$.post('/updateEmail', $('#email').serialize(), function() {
		$.event.trigger('editComplete');
	});
});

$('.userOperation').bind('editStart', function(){
	// "this" is a .userOperation button
	console.log('edit started, button: ' + this.id);
	$('.userOperation').attr('disabled', 'disabled');
}).bind('editComplete', function(){
	// "this" is a .userOperation button
	console.log('edit complete, button: ' + this.id);
	$('.userOperation').removeAttr('disabled');		
});

$('#sendButton').click(function(){
	//code to send a message
	alert('Message sent');
});

$('#summaryButton').click(function(){
	//code to generate summary
	alert('Summary created');
});

What is great about this type of event is that they are in the context of the subscribing elements, as if these elements were the publishers of the event, much like the majority of the event handling code we write.

They also allow us to move more code next to the other event handler for the subscribing elements, and even chain them all together. As an example, let's modify the event handlers of the #sendButton element to add some different behavior when the editStart event happens.

$('#sendButton').click(function(){
	//code to send a message
	alert('Message sent');
}).bind('editStart', function(){
	// "this" is the #sendButton button
	this.value = 'Send message (please refresh)';
	// change the click event handler.
	$(this).unbind('click').click(function(){
		alert('Sorry, refresh page before sending message');
	});
});

And here is the simplified representation of the global events code.

$.event.trigger('eventName');

$('#subscriber1').bind('eventName', function() {
   //eventName happened. React here.
   $(this).doStuff();
});

$('#subscriber2').bind('eventName', function() {
   //eventName happened. React here.
   $(this).doOtherStuff();
});
//more...

Conclusion

Event-based programming is the usual way we write UI code. By understanding the different types of events that jQuery provides we can allow our UI to grow without getting into a messy nightmare of event handling code scattered all over the place.

Code coverage reports with NCover and MSBuild

2010-02-09T18:11:00Z

I've been doing a lot of static analysis on our projects at work lately. As part of that task we added NCover to our automated build process. Our build runs on Team Build (TFS) and is specified in an MSBuild file.

We wanted to take code metrics very seriously and we purchased the complete version of the product to take full advantage of its capabilities.

Getting NCover to run in your build is very simple and the online documentation will be enough to figure it out. The problem comes when you begin needing to create more and more variations of the reports. The online documentation is a little short on this aspect, especially on how to use the MSBuild or NAnt custom tasks. I hear they plan to update the site with better docs for the next version of the product.

NCover Complete comes with 23 different types of reports and a ton of parameters that can be configured to produce far more helpful reports than just sticking to the defaults.

For example, we are working on a new release of our product and we are pushing ourselves to produce more testable code and write more unit tests for all the new code. The problem is that the new code is a just tiny fraction of the existing code and the metrics get averaged down by the older code.

The key is to separate the code coverage profiling (which is done by NCover while it runs all the unit tests with NUnit) from the rendering of the reports. That way we only run the code coverage once; and that can sometimes take a good chunk of time to produce the coverage data. Rendering the reports is much quicker since the NCover reporting engine can feed off the coverage data as many times as we need, very quickly.

Once we have the coverage data we can choose which report types we want to create, the thresholds for sufficient coverage (or to fail the build), which assemblies/types/methods we want to include/exclude from each report and where to save each of them.

Example

To demonstrate what I just described in practice, I decided to take an existing open source project and add NCover reporting to it. The project I selected was AutoMapper mostly because it's not very big and has decent test coverage.

I downloaded the project's source code from the repository and added a file named AutoMapper.msbuild to its root directory. You can download this entire file but I'll go over it piece by piece.

We start by just importing the MSBuild tasks that ship with NCover into our script and declaring a few targets, including one to collect coverage data and one to generate the reports. I added the NCover tasks dll to the project directory tools/NCoverComplete.

<Project DefaultTargets="RebuildReports" 
  xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
  <UsingTask  TaskName="NCover.MSBuildTasks.NCover" 
        AssemblyFile="$(ProjectDir)tools\NCoverComplete\NCover.MSBuildTasks.dll"/>
  <UsingTask  TaskName="NCover.MSBuildTasks.NCoverReporting" 
        AssemblyFile="$(ProjectDir)tools\NCoverComplete\NCover.MSBuildTasks.dll"/>

  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <BuildDir>$(MSBuildProjectDirectory)\build\$(Configuration)</BuildDir>
    <NUnitBinDirectoryPath>$(MSBuildProjectDirectory)\tools\NUnit</NUnitBinDirectoryPath>
  </PropertyGroup>

  <Target Name="RebuildReports" DependsOnTargets="RunCoverage;ExportReports" >
    <Message Text="We will rebuild the coverage data than refresh the reports." 
          Importance="High" />
  </Target>

  <Target Name="RunCoverage" >
    <!-- snip -->
  </Target>

  <Target Name="ExportReports" >
    <!-- snip -->
  </Target>
</Project>

Now let's look closely at the target that gathers the coverage data. All it does is tell NCover (NCover console, really) to run NUnit over the AutoMapper.UnitTests.dll and save all the output to well-known locations.

<Target Name="RunCoverage" >
  <Message Text="Starting Code Coverage Analysis (NCover) ..." Importance="High" />
  <PropertyGroup>
    <NCoverOutDir>$(MSBuildProjectDirectory)\build\NCoverOut</NCoverOutDir>
    <NUnitResultsFile>build\NCoverOut\automapper-nunit-result.xml</NUnitResultsFile>
    <NUnitOutFile>build\NCoverOut\automapper-nunit-Out.txt</NUnitOutFile>
    <InputFile>$(BuildDir)\UnitTests\AutoMapper.UnitTests.dll</InputFile>
  </PropertyGroup>

  <NCover ToolPath="$(ProgramFiles)\NCover"
    ProjectName="$(Scenario)"
    WorkingDirectory="$(MSBuildProjectDirectory)"   
    TestRunnerExe="$(NUnitBinDirectoryPath)\nunit-console.exe"

    TestRunnerArgs="$(InputFile) /xml=$(NUnitResultsFile) /out=$(NUnitOutFile)"

    AppendTrendTo="$(NCoverOutDir)\automapper-coverage.trend"
    CoverageFile="$(NCoverOutDir)\automapper-coverage.xml"
    LogFile="$(NCoverOutDir)\automapper-coverage.log"
    IncludeTypes="AutoMapper\..*"
    ExcludeTypes="AutoMapper\.UnitTests\..*;AutoMapper\.Tests\..*"
    SymbolSearchLocations="Registry, SymbolServer, BuildPath, ExecutingDir"
  />
</Target>

Of special interest in the NCover task above are the output files named automapper)-coverage.xml and automapper-coverage.trend, which contain the precious coverage data and historical trending respectively. In case you're curious, the trend file is actually a SQLite3 database file that you can report directly from or export to other database formats if you want.

Also note the IncludeTypes and ExcludeTypes parameters, which guarantee that we are not tracking coverage on code that we don't care about.

Now that we have our coverage and trend data collected and saved to files we know, we can run as many reports as we want without needing to execute the whole set of tests again. That's in the next target.

<Target Name="ExportReports" >
  <Message Text="Starting Producing NCover Reports..." Importance="High" />
  <PropertyGroup>
    <Scenario>AutoMapper-Full</Scenario>
    <NCoverOutDir>$(MSBuildProjectDirectory)\build\NCoverOut</NCoverOutDir>
    <RptOutFolder>$(NCoverOutDir)\$(Scenario)Coverage</RptOutFolder>
    <Reports>
      <Report>
        <ReportType>FullCoverageReport</ReportType>
        <OutputPath>$(RptOutFolder)\Full\index.html</OutputPath>
        <Format>Html</Format>
      </Report>
      <Report>
        <ReportType>SymbolModuleNamespaceClass</ReportType>
        <OutputPath>$(RptOutFolder)\ClassCoverage\index.html</OutputPath>
        <Format>Html</Format>
      </Report>
      <Report>
        <ReportType>Trends</ReportType>
        <OutputPath>$(RptOutFolder)\Trends\index.html</OutputPath>
        <Format>Html</Format>
      </Report>
    </Reports>
    <SatisfactoryCoverage>
      <Threshold>
        <CoverageMetric>MethodCoverage</CoverageMetric>
        <Type>View</Type>
        <Value>80.0</Value>
      </Threshold>
      <Threshold>
        <CoverageMetric>SymbolCoverage</CoverageMetric>
        <Value>80.0</Value>
      </Threshold>
      <Threshold>
        <CoverageMetric>BranchCoverage</CoverageMetric>
        <Value>80.0</Value>
      </Threshold>
      <Threshold>
        <CoverageMetric>CyclomaticComplexity</CoverageMetric>
        <Value>8</Value>
      </Threshold>
    </SatisfactoryCoverage>

  </PropertyGroup>

  <NCoverReporting 
    ToolPath="$(ProgramFiles)\NCover"
    CoverageDataPaths="$(NCoverOutDir)\automapper-coverage.xml"
    LoadTrendPath="$(NCoverOutDir)\automapper-coverage.trend"
    ProjectName="$(Scenario) Code"
    OutputReport="$(Reports)"
    SatisfactoryCoverage="$(SatisfactoryCoverage)"
  />
</Target>

What you can see in this target is that we are creating three different reports, represented by the Report elements and that we are changing the satisfactory threshold to 80% code coverage (down from the default of 95%) and the maximum cyclomatic complexity to 8. These two blocks of configuration are passer to the NCoverReporting task via the parameters OutputReport and SatisfactoryCoverage, respectively.

The above reports are shown in the images below.

Focus on specific areas

Let's now say that, in addition to the reports for the entire source code, we also want to keep a closer eye on the classes under the AutoMapper.Mappers namespace. We can get that going with another reporting target, filtering the reported data down to just the code we are interested in:

<Target Name="ExportReportsMappers" >
  <Message Text="Reports just for the Mappers" Importance="High" />
  <PropertyGroup>
    <Scenario>AutoMapper-OnlyMappers</Scenario>
    <NCoverOutDir>$(MSBuildProjectDirectory)\build\NCoverOut</NCoverOutDir>
    <RptOutFolder>$(NCoverOutDir)\$(Scenario)Coverage</RptOutFolder>
    <Reports>
      <Report>
        <ReportType>SymbolModuleNamespaceClass</ReportType>
        <OutputPath>$(RptOutFolder)\ClassCoverage\index.html</OutputPath>
        <Format>Html</Format>
      </Report>
      <!-- add more Report elements as desired -->
    </Reports>
    <CoverageFilters>
      <Filter>
        <Pattern>AutoMapper\.Mappers\..*</Pattern>
        <Type>Class</Type>
        <IsRegex>True</IsRegex>
        <IsInclude>True</IsInclude>
      </Filter>
      <!-- include/exclude more classes, assemblies, namespaces, 
      methods, files as desired -->
    </CoverageFilters>

  </PropertyGroup>

  <NCoverReporting 
    ToolPath="$(ProgramFiles)\NCover"
    CoverageDataPaths="$(NCoverOutDir)\automapper-coverage.xml"
    ClearCoverageFilters="true"
    CoverageFilters="$(CoverageFilters)"
    LoadTrendPath="$(NCoverOutDir)\automapper-coverage.trend"
    ProjectName="$(Scenario) Code"
    OutputReport="$(Reports)"
  />
</Target/>

Now that we have this basic template our plan is to identify problem areas in the code and create reports aimed at them. The URLs of the reports will be included in the CI build reports and notification emails.

It's so easy to add more reports that we will have reports that will live for a single release cycle or even less if we need it.

I hope this was helpful for more people because it did take a good amount of time to get it all sorted out. Even if you're using NAnt instead of MSBuild, the syntax is similar and I'm sure you can port the idea easily.

How to detect the text encoding of a file

2010-01-27T01:18:00Z

Today I needed a way to identify ANSI (Windows-1252) and UTF-8 files in a directory filled with files of these two types. I was surprised to not find a simple way of doing this via a property of method somewhere under the System.IO namespace.

Not that it's that hard to identify the encoding programmatically, but it's always better when you don't need to write a method yourself. Anyway, here's what I came up with. It detects UTF-8 encoding based on the encoding signature added to the beginning of the file.

The code below is specific to UTF-8 but shouldn't be too hard to extend the example to detect more encodings.

public static bool IsUtf8(string fname){
  using(var f = File.Open(fname, FileMode.Open)){
    var sig = new byte[Encoding.UTF8.GetPreamble().Length];
    f.Read(sig, 0, sig.Length);
    return sig.SequenceEqual(Encoding.UTF8.GetPreamble());
  }
}

Maybe I just looked in the wrong places. Does anyone know a simpler way in the framework to accomplish this?

On ALT.NET and patience

2010-01-19T20:42:00Z

There ALT.NET bashing season is on full steam. Ian Cooper has a thorough post about it.

To my recollection, ALT.NET was formed by people that shared very similar tastes on what represents good development tools, practices, and methodologies. This group of people, just by the simple fact that they decided to get together under one roof to discuss these ideas, showed that they are constantly and decidedly trying to become better at what they do.

But when you take the step to form a new community or movement (or whatever else you want to call it) you can't easily control who jumps on board or who jumps ship - and you shouldn't even try to.

Inevitably the original idea started to attract many different kinds of participants, which I'm going to roughly distribute in the below four categories (I was tempted to use the term personas, but … never mind.)

I'm here to help
- I like to teach,
- to write,
- to contribute to OSS,
- coordinating UGs and events
Those who like to complain
A very minor percentage of those know how to externalize their criticism in a constructive way. Unfortunately the majority limit their contributions to rants and trolling.
That's probably the only group of people that I'd try to weed out if I could (but I can't; and we shouldn't).
Those who want to learn
- They want to hear about other ideas,
- to figure out how to bring better practices to their work,
- they have a specific problem and they're seeking opinions or answers.
Heliotropic migrants
The ones who want to be linked to (and hops on) every new, shiny thing for commercial reasons. There's always this type of people. They need to latch on to what could be the next big thing for the sake of their own livelihood. There's nothing wrong with that, by the way.

Some people just can't put up with the other types. Some folks go ballistic with people on #4, others can't stand the whiners in #2. Some don't tolerate repeated or trivial questions from folks that are just trying to learn.

In the midst of all this, it becomes hard to connect #1 and #3, which I think is the ultimate reason for ALT.NET existence.

Frankly speaking, I think I've personally danced around in all these four categories but I find myself most of the time in #3 and some other times in #1. I do apologize for my ventures in #2 – it's hard to avoid.

So, if you dabble in the ALT.NET waters, let me just ask you to exercise a little bit of patience. We all still have a lot to learn and there's very good indications that some of those lessons are permeating the .NET development community — from the individual developer to the big Enterprise, Inc.

Let's no try to change the world with a single swing of the bat. Changing one constructor method at a time will get us further. In the end, the idea is simply to more efficiently produce more maintainable and reliable software.

Oh, no. My TortoiseSVN overlays are missing

2010-01-05T09:13:00Z

It's a matter of time. Good were the days when almost no application knew how to put overlays on your file icons in Explorer. These days it seems this is the coolest thing ever and virtually all file system type of utilities want to add their own.

Sooner or later you will install some utility and not notice anything different. But after the next reboot, poof, your TortoiseSVN overlays are gone. And, depending on how much time elapsed between the utility installation and that reboot, you may not have the slightest clue of what happened. Reinstalling TSVN won't fix it

TFS Power tools, Dropbox, Mozy, stop breaking my TSVN overlays

I should not blame these applications for a Windows shell limitation. To be fair, TSVN is the greater offender of them all.

It seems that the shell only supports 15 different icon overlays and TSVN creates 9 of those. After 15 the shell starts ignoring the extra ones. The trick is that Windows chooses the first 15 alphabetically from their entries in the system registry.

I love simple fixes

The fix is rather obvious; just make sure the overlays you want to be active are registered alphabetically before the ones you can live without.

Open the registry editor and go to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers and look at all the child keys in there. It will be obvious that, if you want to preserve the TSVN overlays like me, you need to keep the ones starting with Tortoise* before the other ones.

If you look at the image below you'll see that I changed my entries by prefixing the undesirable ones with z_, following someone else's suggestion.

After that change you just need to kill and restart explorer.exe using Task Manager (or logoff or reboot the machine depending on your tolerance to pain.)

I believe this is a common problem so I hope this tip helps somebody.

Language Envy - C# needs Ranges

2010-01-02T10:55:00Z

As soon as I started learning Ruby, a few years ago, I got immediately hooked on its Range class. I could not believe I had been programming in .NET without them for so long.

I like to think of range objects as the specification for a for loop, packaged in an object that can be passed around. That's not the whole story, though. Ranges also represent sequences or intervals, which can be queried for intersection or containment. See the following Ruby sample code.

#declare a Range object
summer_months = 6..9
#enumerate it
summer_months.each {|m| puts "#{Date.new(2000, m, 1).strftime('%B')} is a Summer month." }
#other handy features
summer_months.include? 7 # ==> true
summer_months.to_a # ==> [6, 7, 8, 9]  (converted to array)

I needed that in C#

That was back when the CLR 2.0 was just about to be released and I ended up writing my own Range class. I have used this class in a handful of projects since then and I'm still surprised that we don't have it in the standard .NET class library. The closest thing I'm aware of is the method System.Linq.Enumerable.Range(int, int), which is rather limited (it only enumerates integers one by one).

Here's the code that I came up with, which has served me well for many years. First an abstract base class. I'll omit parts of the code for brevity but I'll give you a link for the complete source at the end.

public abstract class RangeBase<T> : IEnumerable<T> where T : IComparable
{
  public T Start { get; set; }
  public T End { get; set; }

  protected RangeBase(T start, T end)
  {
    // ... snip ...
  }

  protected abstract T GetNextItem(T currentItem);

  public IEnumerator<T> GetEnumerator()
  {
    T item = Start;

    while (true)
    {
      if (item.CompareTo(End) > 0)
        break;

      yield return item;

      item = GetNextItem(item);
    }
  }


  IEnumerator IEnumerable.GetEnumerator()
  {
    return GetEnumerator();
  }

  public bool Intersects(RangeBase<T> otherRange)
  {
    // ... snip ...
  }

  public bool Contains(RangeBase<T> otherRange)
  {
    // ... snip ...
  }

  public bool Contains(T element)
  {
    return (Start.CompareTo(element) <= 0) && (End.CompareTo(element) >= 0);
  }
}

There's also a generic concrete type and a bunch of the more common implementations for convenience.

public class Range<T> : RangeBase<T> where T : IComparable
{
  public Func<T, T> GetNext { get; private set; }

  public Range(T start, T end, Func<T, T> getNext)
    : base(start, end)
  {
    GetNext = getNext;
  }

  protected override T GetNextItem(T currentItem)
  {
    return GetNext(currentItem);
  }
}

public class Int32Range : RangeBase<int>
{
  public Int32Range(int start, int end) : base(start, end){}
  protected override int GetNextItem(int currentItem)
  {
    return currentItem + 1;
  }
}

public class Int64Range : RangeBase<long> { /* ... snip ... */ }
public class DayRange : RangeBase<DateTime> { /* ... snip ... */ }
public class HourRange : RangeBase<DateTime> { /* ... snip ... */ }
//...etc...

Coding with Ranges

With the above classes I can write code that is similar in functionality to the Ruby version.

//declare a range of numbers
var summerMonths = new Int32Range(6, 9);
//enumerate it
foreach(var m in summerMonths) 
  Console.WriteLine(new DateTime(2000, m, 1).ToString("MMMM") + " is a Summer month.");
//other handy features
summerMonths.Contains(7); // ==> true
summerMonths.Contains(new Int32Range(7, 8)); // ==> true
summerMonths.ToArray(); // ==> [6, 7, 8, 9]  (using LINQ extensions)

We can also use the generic Range type to create less orthodox iterations, like a sequence of dates that repeat every other week:

var startDate = new DateTime(2010, 1, 1);
var endDate = startDate.AddMonths(3);
var appointmentDates = new Range<DateTime>(startDate, endDate, d => d.AddDays(14));
appointmentDates.ToArray(); 
// ==> [ 1/1/2010, 1/15/2010, 1/29/2010, 
//          2/12/2010, 2/26/2010, 3/12/2010, 3/26/2010 ]

The complete source for these classes and even some unit tests can be found here.

Other implementations

Of course I was not the first to implement a Range class in C#. A quick search yielded at least a couple of articles with different approaches to the same goal.

Another indication that ranges are a popular data structure is the fact that F# has them too. With luck we will see ranges in a future version of the .NET framework. Oh, and since we are wishing for things. let's hope they introduce range literals in C# at that same time.

2009 Visual Summary

2009-12-24T18:19:00Z

If you've been reading this blog in 2009, here's a good, speed-of-light recap. And, since I avoid writing about the blog itself or blogging in general, that's all I'm going to say about it.

(Created with Wordle)

Guided Tour: jQuery - Array wannabes

2009-12-23T05:13:00Z

This post is part of a series called the Guided Tours.

In this second installment we are still looking inside the jQuery code. Trust me, even if it's hard to digest, you can still learn enough if you focus on a little bit at a time.

The code we are interested in today is the following.

//from jQuery 1.3.2
get: function( num ) {
	return num === undefined ?

		// Return a 'clean' array
		Array.prototype.slice.call( this ) : 

		// Return just the object
		this[ num ];
},

That's the code for the command jQuery.fn.get(index), which returns the element at the given index or the entire array if the index is omitted.

The JavaScript idiom that is really interesting in this function is that strangely long function call Array.prototype.slice.call( this ).

That line is needed because we need to return an array and, even though they look like one, the jQuery objects aren't arrays. And they aren't alone in that.

If it walks like a duck...

The Array object is one that we can't avoid becoming familiar with in JavaScript. They are everywhere. Data is passed to functions as arrays. Data is returned in arrays. Or are they?

Aside from jQuery objects there are at least two other important occurrences of data structures that are used like arrays but really aren't: the arguments variable and the DOM NodeList collections.

The arguments variable is the list of parameters passed to the current function and the NodeList is what is returned from members of the the DOM API such as document.getElementsByTagName() or element.childNodes. Both of these types have a length property and expose their items with indices, like arguments[1] or elements[0].

But don't let this small coincidence fool you. As soon as you stop paying attention and try to use another array method, like push, shift, join you'll have your dreams shattered and a TypeErrorto handle.

Help me, jQuery

To solve the above problem and return a real array object instead of the jQuery object itself, the code used the technique we highlighted.

Array.prototype.slice.call( this )

The idea is to use the array.slice() instance method to create a new array. The slice method returns a chunk of the array and it takes two optional parameters (the boundaries) that, when omitted, make the function return a copy of the array itself.

I've written about the prototype object and how to invoke functions with call in previous posts, so I won't repeat myself here. I'll just add a reminder that the this object in the get method is the jQuery instance we're working with.

What's going on in call( this ) is that slice is being invoked as if it was a method of the jQuery object (note: the jQuery object does have a method called slice but it does not return an array.)

You may be wondering how can we pass a jQuery object to slice.call() and not get any errors inside the method implementation. Well, it works because the slice method was built to be generic and it only needs that the current object has a length property and items in indexed positions. That's Duck Typing at work.

A Freebie

There's a small variation of this technique that you may come across in JavaScript as well.

[].slice.call( this )

It calls the same slice method but in a tad more wasteful manner because a new Array instance is created each time just to provide access to its slice method.

Well, that's it. I hope you don't scratch your head any longer when you see an expression like XYZ.prototype.someMethod.call(obj) from now on.

Guided Tour: jQuery - guard and default operators

2009-12-09T10:50:00Z

This post is part of a series called the Guided Tours.

I'm sure I'm not alone when I say that one of the best ways to improve our coding skills is by reading code written by someone else. Sometimes we don't realize how lucky we are to have so much source code at our fingertips, namely Open Source Software.

The guided tours

With this post I'll start another unbound series where I highlight some interesting piece of code that I studied. I'll share my notes and do my best to explain what I learned from it.

jQuery: Eating the elephant one bite at a time

I wouldn't dare to start things off with a complete overview of jQuery. It's a massive chunk of JavaScript and I'm afraid there isn't an easy entry point in the source code.

I chose to find parts of it that are relatively easy to explain separately from the rest and that contain something worth explaining. I'll do at least a few of those from jQuery but my plan is to not keep this series tied to jQuery or even JavaScript.

The code under the microscope

We're going to take a look at jQuery.fn.text(), which returns the textual content of all the elements in the jQuery wrapped set, combined in a single string.

Here's the code from jQuery version 1.3.2.

text: function( text ) {
  if ( typeof text !== "object" && text != null )
    return this.empty().append( 
	   (this[0] && this[0].ownerDocument || document).createTextNode( text ) 
	);

  var ret = "";

  jQuery.each( text || this, function(){
    jQuery.each( this.childNodes, function(){
      if ( this.nodeType != 8 )
        ret += this.nodeType != 1 ?
          this.nodeValue :
          jQuery.fn.text( [ this ] );
    });
  });

  return ret;
},

The text() function can be called with or without arguments, so initially it tries to detect if a string argument was passed to it, in which case it will be made the content of the elements in the jQuery object.

Be aware that in all methods defined inside jQuery.fn the value of this will be the current jQuery object.

The first thing that caught my attention was the following expression:

(this[0] && this[0].ownerDocument || document)

In the context of the code it's expected to return a DOM document object, but it's a boolean expression, isn't it? What gives?

Well, yes, it is a boolean expression. That leads me to explain a subtle but powerful difference between boolean operators in JavaScript to many other languages you may be more used to.

Guard and Default operators

The way I like to describe the boolean operators && and || is: They return the operand that short-circuited and resolved the expression. To put in a different way, when the JS interpreter detects that one of the operands has a value that makes the remainder of the comparison irrelevant, it stops right there and that operand (not necessarily true or false) becomes the result of the boolean expression.

Truthy and Falsy: In the context of a boolean expression, any value in JavaScript has a boolean meaning. It's actually easy to memorize which mean which. The values that are treated as false are: false, null, undefined, 0, "" (empty string), and NaN. We call them falsy. Everything else is treated as true and we call them truthy.

Here are some examples:

A	B	A && B
`false`	`123`	`false`
`null`	`123`	`null`
`0`	`123`	`0`
`undefined`	`123`	`undefined`
`undefined`	`null`	`undefined`
`123`	`null`	`null`
`123`	`456`	`456`
`123`	`"text"`	`"text"`
`"text"`	`true`	`true`

A	B	A \|\| B
`false`	`123`	`123`
`null`	`123`	`123`
`0`	`123`	`123`
`undefined`	`123`	`123`
`undefined`	`null`	`null`
`123`	`null`	`123`
`123`	`456`	`123`
`123`	`"text"`	`123`
`"text"`	`true`	`"text"`

Because of the above behavior, these boolean operators are often used as Guard or Default operators. The guard operation is commonly used when you want to avoid a null or undefined reference error:

//someObj can be null. text will also be null in that case.
var text = someObj && someObj.toString();

Which is a shorthand for:

var text = null;
if (someObj !== null) {
  text = someObj.toString();
}

The default operation is arguably a much more common occurrence. We see it a lot when functions support optional arguments with default values. When a value is not given for a function parameter, it becomes undefined. We can detect that and give a default value like this:

function addAll(numbersArray, step) {
  step = step || 1;
  var sum = 0;
  for (var i = 0; i < numbersArray.length; i += step) {
    sum += numbersArray[i];
  }
  return sum;
}
addAll([1, 2, 3, 4, 5, 6]); // ==> 21
addAll([1, 2, 3, 4, 5, 6], 3); // ==> 5

In the above example, the step parameter is optional. Not providing it would cause a problem if we hadn't defaulted it to one right at the beginning of the function.

Wow. We sure covered a lot of stuff just to explain a simple boolean expression. The good news is that we will see a lot of that in the jQuery code (or in pretty much any decent JS code base) so it's good to understand it well.

Back to our original expression.

(this[0] && this[0].ownerDocument || document)

Armed with our new understanding we can finally read this expression as: If this.ownerDocument exists I want that, otherwise just give me the global document object. This returned DOM document object will be the owner document of new text value being inserted.

What about the rest of that function

It's funny that a tiny bit of that function became this long post. But the remainder of the function, in its majority, isn't really all that interesting in terms of JavaScript. It's mostly boring DOM navigation, done recursively. If you know how to use the jQuery.each() utility function, you can figure out that code on your own.

Our time here is up and we have a whole lot more of code sightseeing to do.

Test-Driving a new feature for JavaScript

2009-11-13T01:16:00Z

Earlier this week I had a piece of JavaScript that I wanted to like this:

var index = someArray.indexOf(someObject);

The problem there is that the indexOf method of the Array object was introduced in JavaScript 1.6, which isn't implemented in all browsers (actually, IE seems to be the real problem here).

Anyway, thanks to the awesomeness of dynamic typing and prototypeal inheritance in JavaScript, we can fix that ourselves with code similar to the below.

if (!Array.prototype.indexOf) {
  Array.prototype.indexOf = function(item) {
    // implementation goes here
  };
}

Actually, if you're just looking for the final solution you can find it easily with your search engine of choice or skip to the bottom of this article.

But, instead of going through the normal trial and error approach, I chose to flex my TDD muscle and try to create this method using a test-first routine. For this exercise, I chose QUnit as the unit testing framework.

I started with a standard empty testing HTML file where I'll put my test cases and a reference to my-library.js where I'll add this new method.

<html&gt
  <head>
    <title>Tests for mylibrary.js</title>
    <link href="testsuite.css" rel="stylesheet" type="text/css" />
    <script src="jquery.js" type="text/javascript"></script>
    <script src="testrunner.js" type="text/javascript"></script>
    <script src="my-library.js" type="text/javascript"></script>
  </head>
  <body>
    <h1>Tests for mylibrary.js</h1>
    <h2 id="banner">
      <span style="color:#fff;">Result: Red/Green?</span>
    </h2>
    <h2 id="userAgent"></h2>
    <ol id="tests"></ol>
     <!--
        The #main element is like your test fixture. It's like the 
		data for your tests.     
        Whatever exists inside the #main element gets restored 
        before each test.
        Feel free to manipulate the contents of #main in your tests.
      -->
    <div id="main">
    </div>
  </body>
</html>

You can put your test cases in a separate .js file and reference it here but I'll just add the necessary JavaScript to the HTML file itself in this exercise.

Here are the test cases I'm going to support:

Missing items return -1
Existing item is found
Existing item is found with positive starting index
Existing item is not found with positive starting index
Existing item is found with negative starting index
Existing item is not found with negative starting index
Comparison is non-coercive

Let's start with the first test: Missing items return -1. It's a simple value comparison. At this point I do not have anything written yet for the indexOf function, it doesn't even exist if you're on IE. Add the following to the HTML file.

$(function() {
  var list = [11, 22, 33, 44];
  
  module('Array.indexOf');
  
  test('Missing items return -1', function() {
    equals(list.indexOf(1234), -1);
  });

});

When you open the HTML file on IE (I'm using IE8), you'll see this:

Totally expected, but let's try to make this test pass. In the my-library.js file, let's add the simplest code that can satisfy that test.

if (!Array.prototype.indexOf) {
    Array.prototype.indexOf = function() {
      return -1;
    };
}

The outer if is there just to prevent replacing the function if it already exists. The function is clearly incomplete, but that's not the point. The point is that it passes the test:

Great. Time for the second test: Existing item is found. For that one we will need to loop through the items in the array. The array is this in the method. Here's the test, which we add right after the first one.

test('Existing item is found', function() {
  equals(list.indexOf(22), 1);
});

And of course that fails

Time to make it pass.

if (!Array.prototype.indexOf) {
  Array.prototype.indexOf = function(item) {
    for (var i=0; i<this.length; i++) {
      if (this[i] == item) {
        return i;
      }
    }
    return -1;
  };
}

And it passes:

Now let's tackle the third test case: Existing item is found with positive starting index. This one starts to make things interesting. Here's the test.

test('Existing item is found with positive starting index', function() {
  //let's try a few boundary conditions
  equals(list.indexOf(33, 0), 2);
  equals(list.indexOf(33, 1), 2);
  equals(list.indexOf(33, 2), 2);
});

Hmmm. The test passes, as we can see below. Well, that was kind of an accident but I'll leave the test as is because it does test what was specified. Leaving the test will help us if we make changes that break this specification.

The next test case is Existing item is not found with positive starting index. We could write it like this:

test('Existing item is not found with positive starting index', function() {
  equals(list.indexOf(33, 3), -1);
  equals(list.indexOf(33, 1000), -1);
});

And boom! It fails. It should, we don't even have support for that second parameter yet.

Failing it is, pass it we must. First attempt:

if (!Array.prototype.indexOf) {
  Array.prototype.indexOf = function(item, startIndex) {
    for (var i=startIndex; i<this.length; i++) {
      if (this[i] == item) {
        return i;
      }
    }
    return -1;
  };
}

It passes the new test, but it fails another one:

That's actually pretty cool. We would have created a mess if we had just added the second parameter without some regression testing. Hooray for unit tests!

What's happening is that my startIndex defaults to undefined if not passed by the caller. It should default to zero. Easy fix.

if (!Array.prototype.indexOf) {
  Array.prototype.indexOf = function(item, startIndex) {
    startIndex = startIndex || 0;
    for (var i=startIndex; i<this.length; i++) {
      if (this[i] == item) {
        return i;
      }
    }
    return -1;
  };
}

I see the green light!

Our next test case is up: Existing item is found with negative starting index. What we are trying to do here is allow the caller to specify the starting position as an offset from the last item using a negative number. So in a 4-element array, passing -1 means that we start at the last item and passing -3 we start at the second item. See the test.

test('Existing item is found with negative starting index', function() {
  equals(list.indexOf(33, -2), 2);
  equals(list.indexOf(33, -3), 2);
  equals(list.indexOf(33, -1000), 2);
});

Once again it passes by accident.

The next text case will show that it was an accident: Existing item is not found with negative starting index. The test for that is below:

test('Existing item is not found with negative starting index', function() {
  equals(list.indexOf(33, -1), -1);
  equals(list.indexOf(11, -3), -1);
});

It fails:

Making it pass is not that hard, we just need to compute a positive version of that negative start index.

if (!Array.prototype.indexOf) {
  Array.prototype.indexOf = function(item, startIndex) {
    startIndex = startIndex || 0;
    
    if (startIndex < 0) {
      startIndex += this.length;
    }
    
    for (var i=startIndex; i<this.length; i++) {
      if (this[i] == item) {
        return i;
      }
    }
    return -1;
  };
}

Ding, ding, ding! Another passing test for our team.

Lastly, we need to make sure that the Comparison is non-coercive. By that we mean, a number will never equal a string — or generally speaking, the things being compared must be of the same type. Let's get some tests that try to point out tha flaw in our current code.

test('Comparison is non-coercive', function() {
  equals(list.indexOf('22'), -1);
});

This fails because, strictly speaking, 22 and '22' are two different things and we didn't want to match that element like we did.

On to the fix. Can you spot the difference? Try harder.

if (!Array.prototype.indexOf) {
  Array.prototype.indexOf = function(item, startIndex) {
    startIndex = startIndex || 0;
    
    if (startIndex < 0) {
        startIndex += this.length;
    }
    
    for (var i=startIndex; i<this.length; i++) {
        if (this[i] === item) {
          return i;
        }
    }
    return -1;
  };
}

And here is the QUnit report in all its successful glory.

If you've never been exposed to TDD this may have felt awkward but hopefully you noticed that it's more of an evolutionary design approach, as opposed to trying to make it perfect on the first attempt or even reckless patching.

It also left us with a valuable collection of tests that we can execute after making changes to the code, ensuring we didn't break anything by accident.

Talk: Stop Programming JavaScript by Luck

2009-11-10T09:07:00Z

Last Saturday I had the pleasure to present a JavaScript talk at the Iowa Code Camp. The talk was Stop Programming JavaScript By Luck and it tries to highlight some of the most puzzling differences from your mainstream programming language (read: C#, VB, Java.)

I'd like to thank all that came to the talk and the Code Camp organizers for inviting me. Here are the video recording and the slide deck.

The video

And the slide deck.

LG BD390 Blu-ray player and D-Link DIR 655 Router: not friends

2009-11-05T00:33:00Z

A month or so ago I bought a Blu-ray player. I waited a bit to buy one of those because, frankly speaking, the improved image quality and any bonus features in the discs weren't attractive enough for me to replace the DVD player.

I also wanted a networked player that could stream movies from my Netflix queue. To make matters worse, running a CAT-5 cable from my basement (where my wireless router lives) to the bedroom (the BR player's final destination) wasn't really something I was looking forward to.

That's when I did some shopping around and came across the LG BD390 Wi-Fi-enabled Blu-ray player. It supports wireless 802.11n and access to a few online services like YouTube, Netflix and VUDU. It can also find media in my home network.

Note: I know there's always someone that will come suggest taking a look at the PS3 or XBOX can do some or all of that. I'm not a gamer so I didn't want to have a gaming console in my bedroom and deal with issues related to the not being a simple player aspects of the device (like maybe having to buy extra adapters/connectors, remote control, and what-have-you). It's probably a no-brainer if you're into video games. Did I say I do not buy Sony?

Welcome LG BD390

So I went and bought the LG BD390 and installed it where it was supposed to be. I was a little worried about not having the 802.11n router setup yet (it was still on its way) but I decided to give it a shot even on my 5-year old 802.11g router. I thought maybe I wouldn't get HD streaming or choppy video, but at least I would get a feeling about the device's capabilities while I waited for the new router to arrive.

Works great on wireless-G

To my surprise, the LG BD390 worked great over wireless-G. Setup is incredibly easy (the only hard part was really entering the long WPA password using the on-screen keyboard.) It boots up fast. Within 5 minutes from its first power-on it had already found and updated its firmware, I had activated my Netflix streaming and The Office was streaming in HD on my TV.

Best gadget purchase in years. This device will definitely change the way I watch movies and TV series, and listen to music (BTW, since it's easy to upgrade the firmware and other LG products offer Pandora, here's to hoping the BD390 gets that too soon.)

But not so fast. Bad wireless-N surprise.

You'd think that by upgrading my network to wireless-N would only make the whole experience much better, right? Me too.

I upgraded my trusty wireless-G router with a shiny new D-Link DIR 655 wireless-N Gigabit model. It has some interesting features, USB port, decent firmware features (well, read on,) and seems rather popular anyway.

Once I configured it to the exact same network settings as the previous router, I checked the laptops were working fine with it and went straight to enjoy some more streaming on my Blur-ray player. I immediately noticed that the signal strength had dropped from 5 bars to 2, 1, and sometimes no bars at all. Even when a couple of bars were there, it wouldn't even browse my local network.

I even tried using a cheap-o router in repeater mode but it didn't play well with my D-Link router and even the laptops would lose connectivity at random when this thing was active — I ended up returning it.

A month later (and a few lost frustrating hours) later I came across this post on the Amazon reviews for the player. Basically, even though there was a new firmware available, the router insisted in telling me it had the latest one. And it just so happens that the firmware it had (v1.2) had some serious bugs. Short version, many times it would not work at all with the Blu-ray player.

I followed the suggested instructions and things are much better now. I still get a very weak signal but at least I'm able to consistently stream HD content. I hope the next version of the BD390 comes with an external antenna. I might try another router and see if they have a stronger signal — this seems to be a common complaint about this D-Link model.

So if you're in the market for a Blu-ray player I can recommend LG's BD390 but I'd suggest you search the web for any issues with your wireless-N router (unless you're planning to wire it up, in that case I recommended it 100%). If you're buying your router together with the BR player, buy it from a store that you can easily return it in case it doesn't work well with the BR player. On the other hand, if you're looking for a new router, I cannot recommend D-Link's DIR 655.