Code monkey loves it

http://www.youtube.com/watch?v=5W_wd9Qf0IE

Creative Zen Neeon 2 (2GB)

My wife bought the Creative Zen Neeon 2 (2GB) on Saturday for a mere $99 (AUD) from MYER. Shopbot and MyShopping were listing the same player from $179 to $226 at various online retailers so it all seems like a great deal from a big department store! 2GB is by no means huge but for the price you can't go wrong.

The sound quality on this device using the supplied earbuds is quite good with a nice range. We had the bass boost turned on initially and had to turn it off because some songs were distorting slightly. Bass response was still great.

The user interface isn't bad once you get used to it (my wife isn't a technophile and she cottoned on in no time) and the thumb wheel works quite well. I don't have huge hands but my hand did start getting tired after playing with the thing for a while. The unit has volume controls and a record button one side and a play/pause/power button on the other side with the thumb wheel. Neither of us have used the iPod wheel before so I guess we don't know what we're missing out on--and don't care!

The Zen plays MP3, WMA, and WAV formats. It also plays video but the video has to be transcoded using the supplied software. Images are viewable as JPGs. The radio reception was a little iffy and was coming in quite fuzzy while the FM radio on my mobile phone had crystal clear reception right beside the Zen. I haven't tried the line-in function yet. The display was nice and bright and the shiny black surface of the case didn't show too many fingerprints.

Without installing the software suite, we connected up to a USB 2.0 port off a Windows XP computer and were able to start copying files immediately. Transfer time wasn't exactly fast but nothing to complain about. The internal folder structure on the device is extremely logical and you could probably copy other files onto the player for moving to and fro. We also connected the device to a Windows Vista computer using slower USB 1.0 ports but the player wasn't recognised and we didn't persevere.

The unit came with earbuds, a USB cable, a line-in cable (1/8"), a lanyard, a DVD with a user manual and software, a printed user manual, and some stickers. The battery is built-in and presumably not user-serviceable. I'm pretty sure this thing has a 1-year warranty.

I don't think I'd pay full-price for a player of this size but at $99 the iPod and variants don't really compare.

VPC MAC Address Conflict

After experiencing intermittent network issues with his VPC, one of my work colleagues was forced to contact our helpdesk extraordinaire to resolve the issue. We use a base VPC (.vmc + .vhd) as the foundation for our individual developer environments and the problem was traced back to the same MAC address being used by multiple VPCs. By repeatedly copying the same .vmc file, a number of us ended up with VPCs sharing a common MAC address.

A MAC address uniquely identifies a NIC at the hardware level (right down at the bottom of the network stack) and is set in the factory. The VPC world in which we live, however, means we're no longer dealing with physical hardware all the time and, as you probably know, multiple software NICs can be added to a VPC quite easily.

As a result, Microsoft Virtual PC generates a new MAC address whenever a new VPC is created and a software NIC is assigned. A VPC's MAC address is stored in the .vmc file, which is actually a valid XML file (open the file in Notepad or an XML editor). Once generated, the VPC's MAC address is stored in an element called "ethernet_card_address" and stays that way until it's either manually changed or the .vmc file is replaced.

Until we encountered this issue, we were saving both the .vmc and .vhd files as part of our development environment "base image"; had we stored only the .vhd file(s), we'd be forced to create a new .vmc file when creating a new environment. Creating a new .vmc file is a simple task and doing so would have avoided the problem encountered by my colleague. The alternative to deleting the .vmc file is to simply delete the value contained in the ethernet_card_address element of the .vmc file. Virtual PC will generate a new MAC address the next time the VPC is started.

It should be noted that while our individual VPCs now employ NICs with unique MAC addresses, the base machine was part of a workgroup and was therefore not sysprep'd. We join our VPCs to our dev domain after copying the base image.

Closing Tag Identifier

I often see HTML comments used to relate a closing tag to its opening tag; when a DIV or some other container tag contains enough content to make viewing the entire block without scrolling impossible, I think this makes perfect sense.

For example:

<div id="myTag">
</div> <!-- end myTag -->

This is also sometimes helpful with C-like languages that use braces to delimit blocks of code.

Although modern development tools highlight closing tags and braces, HTML code in particular isn't always read within one of these tools (View-->Source in IE opens the source code in Notepad, for instance).

To assist, I think it would be helpful to have the option of attributing a closing tag with the same id used by the opening tag:

<div id="myTag">
</div id="myTag">

Our fancy editors would keep the opening/closing ids in sync and browsers could safely ignore the additional attribute.

In practice, this works quite nicely with the caveat that a page built like this is invalid.

My "Cubicle" Rocks!!!

I recently reconfigured things at work...

Must-Have Web Development Tools

• IEDevToolbar (like FF's Web Developer toolbar for IE)
  http://www.microsoft.com/downloads/details.aspx?FamilyID=E59C3964-672D-4511-BB3E-2D5E1DB91038&displaylang=en
  
• Fiddler (a reverse HTTP proxy, inspect headers, view traffic)
  http://www.fiddlertool.com/
  
• Firebug (inspect and modify web pages, debug Javascript, view network stats)
  http://www.getfirebug.com/
  
• Firefox Live HTTP Headers (view HTTP headers)
  http://livehttpheaders.mozdev.org/
  
• Firefox Modify Headers (change your IP address, among other things)
  http://modifyheaders.mozdev.org/
  
• Firefox User Agent Switcher (change your browser user agent string)
  http://chrispederick.com/work/user-agent-switcher/
  
• Firefox Web Developer Toolbar (inspect and dynamically modify web pages)
  http://chrispederick.com/work/web-developer/
  
• .NET Reflector (inspect .NET assemblies)
  http://www.aisto.com/roeder/dotnet/
  
• .NET Resourcer (inspect and edit resource files)
  http://www.aisto.com/roeder/dotnet/
  
• Page Saver (save an entire web page as an image)
  http://pearlcrescent.com/products/pagesaver/
  
• SysInternals (Inspect everything Windows with Filemon, Regmon, PsTools)
  http://www.microsoft.com/technet/sysinternals/default.mspx
  
• The Regulator (edit and test regular expressions)
  http://regulator.sourceforge.net/
  
• WinMerge (compare and merge files and directories)
  http://winmerge.org/
  
• Wireshark (sniff traffic and inspect the lot across various protocols)
  http://www.wireshark.org
  
• YSlow (determine why web pages are slow to load)
  http://developer.yahoo.com/yslow/
  

ASP.NET Fragment Caching in MOSS

I've noticed an odd happening with fragment caching in MOSS 2007: a user control declared in a master page will not be cached but when that same user control is wrapped in a second user control and the wrapper control is declared in the master page, the wrapped control caches as expected.

Things look like this:

Masterpage:

<%@ Register tagprefix="CustomControls" tagName="Container" src="~/UserControls/Container.ascx" %>
<%@ Register TagPrefix="CustomControls" TagName="ToCache" Src="~/UserControls/ToCache.ascx" %>
<CustomControls:Container id="container" runat="server"/>
<CustomControls:ToCache ID="toCache" runat="server"/>

Container.ascx:

<%@ Register tagprefix="CustomControls" tagName="ToCache" src="~/UserControls/ToCache.ascx" %>
<CustomControls:ToCache id="toCache" runat="server" />

The resulting HTML looks like this:

<body>
<div id=”container”>
<div id=”toCache”>... </div> // This caches
</div>
<div id=”toCache”>... </div> // This won’t cache
</body>

The ToCache.ascx user control sets a simple @OutputCache directive in the markup and I can't see anything that would limit output caching in the master page, the hosting .aspx page, or the web.config.

I haven't ripped this apart and tried it in a clean site but I'm definitely experiencing this behaviour within the context of the wa.com development environment. I know MOSS controls (and somehow enhances) output caching but I have yet to look into how this works--as far as I know, I'm using the default output caching configuration.

Update: I wonder if this has anything to do with the control being hosted in a master page instead of an aspx page layout. Slim chance...

Disabling the "Reply to All" email button

Gotta love it when the CEO sets the technology direction in your office... (the identities of those involved in this memo have been obscured but this is a genuine email). Guess that's the final nail in the coffin for Outlook on my desktop.

Surely there's a Dilbert strip for this?

From: xxx
Sent: Thursday, 21 June 2007 10:25 AM
To: All Staff
Subject: Disabling the "Reply to All" email button

The CEO has requested that Corporate IT disable the “Reply to All” button for all staff in order to assist with email and time management.

We will trial this for a few weeks and then I will seek feedback on how effective this has been and request executive directors to bring the feedback to the executive management team for discussion.

The process will happen progressively over the next few days.

Thanks

xxx
Executive Director

Units of Time

One thousandth of a second = 1 millisecond (ms)
One millionth of a second = 1 microsecond (µs)
One billionths of a second = 1 nanosecond (ns)

See http://www.wilsonmar.com/1clocks.htm for great discussion about time in a networked world.

Visual Studio 2005 Debugger Won't Break

Ever encounter a situation where the Visual Studio 2005 debugger absolutely refuses to break? I ran up against this problem this afternoon (yet again) and it took me a moment to discover the reason why.

Here's the scenario:

• A standard user control with a code-behind file is hosted in an insignificant ASPX page;
• The user control code-behind is doing some work to render the control and also has a handler method subscribing to a button click event;
• The relevant assemblies are built in debug mode and are deployed to a separate development server along with the associated markup files;
• The assemblies on the server are the same version as those on the development workstation;
• The application is configured as it should be in IIS and the debug attribute on the web.config's compilation element is set true;
• The VS 2005 remote debugger is installed and running on the dev server;
• The VS 2005 "client" is attached to the remote server's ASP.NET worker process (w3wp.exe in this case);
• Two breakpoints are set on the user control code: one on Page_Load and one on the button click handler;
• Browsing to the host page doesn't cause the debugger to break (except intermittently, sometimes following an iisreset)...

Inspecting the two breakpoints reveals nothing out of the ordinary; symbols are loaded and the debugger is breaking every so often, just for kicks. The code itself is executing happily, it seems.

Here's the problem:

The user control in question had an OutputCache directive set to cache the control for sixty minutes. Removing this little devil resulted in a slap of the forehead and allowed the debugger to break as expected.

The OutputCache directive prevents the control being added to the control tree of the hosting page at runtime; ASP.NET loads an existing version from the cache instead of executing the control code.

...kind of a silly problem since the debugger gives you no inidication the control is loading from the cache but it's all too easy to forget about this sort of thing!!! The golden rule I usually try to apply is to hold off on performance tuning until the very end of the development/testing process and this should generally include large-scale caching. Obviously this doesn't apply in a maintenance situation.

[Update: a few additional tips...

• Double-check the deploy location of your assembly; if it's in the GAC you can deploy to the bin directory until the cows come home but ASP.NET will continually load the assembly from the GAC. Either remove the GAC'd assembly or deploy to the GAC (you can also deploy PDB files to the GAC but you need to drop them under gac_msil using the command line).
• Once you've attached the debugger, bring up the Modules window (Debug -> Windows -> Modules); locate your assembly and verify whether symbols have been loaded and the location where the assembly was loaded.]