Gigabit networks with low quality cables

I have 2 computers attached to a Gigabit switch and both these computers have NICs that support 1 GBPS speed. However, I noticed that transferring files between them was slow so when I inspected the speeds I saw that one of them was operating at 100MBPS and the other at 1GBPS.

At first I went into the driver config setup and fiddled around with half and full duplex to see if that would make a difference. After a bit more research I found a comment that a network cable might be the culprit and that some network cables (e.g. Cat 5) do not support speeds over 100MBPS. I didn't believe that could possibly be the problem but it was easy to test so I switch the cables and the slow speed moved with the cable. So replacing the cable did the trick. Apparently Cat 5e and Cat 6 are what you need to get the higher speeds.

I'm now transferring data at 10 times the original speed.

Mouse without Borders

Do you have 2 or more PC's on your desk that each have their own keyboard and mouse? Do you want to control it all from one keyboard and mouse without using a KVM and have the mouse float from one monitor to the next and allow copy and paste between them? Then Mouse without Borders is for you:

http://aka.ms/MouseWithOutBorders

I've been using it for a few days now to link my two desktops together and it's working very well. The only hiccough is that I need to sign in to my primary computer first and then the secondary computer second (with its keyboard) if I want them to work together. After that it's all controlled from the primary keyboard and mouse. If I sign in in the other order then I have to use their own keyboards and mice to control them.

Collection was modified; enumeration operation may not execute.

This .Net error typically occurs when the underlying collection is modified during enumeration. For example if you remove items from the collection while enumerating the collection.

It can also happen when you're accessing a collection while adding to the collection. See if you can see the bug in the following code which is in the Menus accessor in a singleton object.

if (_Menus == null)
{
    lock (lockObj)
    {
        if (_Menus == null)
        {
            _Menus = new List<MenuItem>();
            _Menus.Add(new MenuItem
            {
                Link = "/mylink",
                AnchorText = "MyText",
                TitleText = "My Title"
            });
            // ... add more items
        }
    }
}
return _Menus;

Note above that we are correctly doing the double null check. Also, not visible in the code we have marked the _Menus item as volatile to prevent the compiler from removing the seemingly redundant double null check.

Here is the fixed code:

if (_Menus == null)
{
    lock (lockObj)
    {
        if (_Menus == null)
        {
            List<MenuItem> tempMenus = new List<MenuItem>();
            tempMenus.Add(new MenuItem
            {
                Link = "/mylink",
                AnchorText = "MyText",
                TitleText = "My Title"
            });
            // ... add more items
           _Menus = tempMenus;
        }
    }
}
return _Menus;

The solution, as demonstrated, is to create a locally scoped temporary collector and build that before assigning it to the _Menus variable. That way all other requests for this object will hold on the lock until this has completed building and then won't attempt to build it because it already exists as determined by the second null check.
 

 

Creating a composite key in your container

If you need to create a composite key (for a dictionary for example) where the natural key could come from multiple sources a standard technique is to prepend the source to the natural key to ensure that it is unique. However, this can still cause duplicate keys so to solve this problem you should always add a delimiter between any concatenations that you do.

The problem is easily illustrated by looking at how files are managed in folders. Typically the composite key is the fully directory path and file name which identifies the file you are looking for. The delimiter is the backslash.

Say you had 2 files: bat.txt and mybat.txt

Let's say that they were in 2 directories:
c:\temp\somy and c:\temp\so
i.e.
c:\temp\somy\bat.txt
and
c:\temp\so\mybat.txt

Without those backslashes we would have:
c:tempsomybat.txt
and
c:tempsomybat.txt
giving us the same key.

So in code you may have:

public void AddItem(string source, string itemName,
  object data, Dictionary<string, object> myDictionary)
{
     string compositeKey = source + "+" + itemName;
     myDictionary.Add(compositeKey, data);
}
 

Disable thumbs.db in Win7

Notes for self on how to do this.

1. Start Local Group Policy Editor.
   1. From start menu type gpedit.msc and hit enter.
2. Navigate the left pane:
   1. User Configuration
   2. Administrative Templates
   3. Windows Components
   4. Windows Explorer
3. On right hand side find:
   1. Turn off the caching of thumbnails in hidden thumbs.dg files
   2. Double click this item.
   3. Change value to Enabled

Other notes:

Might need to log off and log on again.

Will not delete existing thumbs.db file.

 

Time taken for Google to de-index 301 redirect pages

I changed a bunch of the URL's on a site that's in the Alexa to 100,000 - i.e. a moderately busy site that the Google bot visits every day. The old URL's now do a 301 redirected to the new structure. At the time that I did the switch over and every day for the next 60 days I took a snapshot of how many URL's where indexed by Google in each section. I used the following search command in Google:
inurl:/old/folder/pattern site:mysite.com
I entered the number of URL's into a spreadsheet for each of 3 folder patterns. Each pattern started off with 13, 18, and 87 URL's in Google's index. The objective of the exercise was to see how long it would take Google to de-index these pages. Here is a chart of the results:

The folder pattern with 87 URL's is shown against the right axis and the other two against the left.
Expectations:
My expectation was that as soon as Google found the new URL's (it found almost all of them within 5 days) that it would rapidly de-index the old URL's. Remember that I'm telling Google that this is a permanent (301) not temporary (302) redirect.
Actual results:

1. It took around 55 days to naturally de-index all the pages. Much longer than I was expecting.
2. The de-indexing for the 2 smaller collections of pages was linear.
3. The de-indexing for the larger collection of folders was sudden and this happened after 48 days.

There are other techniques for de-indexing pages from Google. For example, Google's Webmaster Tools has a place for you to enter the URL's you want to remove and you can also add the pattern to your robots.txt file which might have de-indexed them faster. The objective of this exercise was not to rapidly de-index those pages but to see how Google naturally de-indexed them over time when given a 301 redirect directive.
My surprise is how long it took to do that.
I'm not going to show a chart of the indexing of the new URL's because it's exactly as you would expect with the line rising rapidly up to the previous values. As I mentioned, 93% of the new links had been indexed within 5 days of them appear on the site and 100% had been indexed by day 13.

Loading a web page in a browser

Tony Gentilcore has just written a good post on How a web page loads and why blocking needs to take place when scripts and CSS load. I'm hoping that he's going to follow this up with a post on the SPDY protocol which looks pretty interesting for a faster web.

Google say that SPDY is an experiment with protocols for the web. Its goal is to reduce the latency of web pages.

At the time of writing this the third draft of the specification for SPDY could be found here.

One of the advantages that SPDY provides is that the resources needed by the page (JavaScript, images, CSS etc.) can be sent to the client in a compressed header and requested by the client before the client parses the HTML.

There's no indication if Google are going to push this specification yet because it's still experimental. One of the great advantages about owning an increasingly popular browser (Chrome) and a couple of popular web sites is that you can define the transport layer when your users are using your software end-to-end.