Ben's Quarters adventures in application development ...

I have three pieces of software from Apple installed on my computer.  iTunes, Quicktime and the Apple Software Update service.  Safari is installed on a virtual machine, but I digress.

Every few weeks, the Apple Software Update service pops open a window telling me updates for iTunes/Quicktime are available.  I like to keep my software up to date, but the updates for these programs are ridiculous.  The entire application needs to be downloaded for the update.  This amounts to around 80 MBs.  Then, because the entire program is being installed, the installation (er, I mean "update") takes an additional minute or two, and finally a system reboot is required for changes to take effect.

This entire process is wrong in so many ways.  The download should only be a delta / diff download consisting of what's actually changed.  Instead of an 80 megabyte download, it should be a few megs at the most.  It shouldn't take so long for the update to be applied, and a required system reboot doesn't make sense.  iTunes and Quicktime are just applications -- not system applications or DLLs that can't be updated while Windows is running.  Something is not designed correctly with this software if files cannot be updated while Windows is running.  Perhaps the system reboot requirement wouldn't be necessary if the update was just the changed bits and not the entire application.

These applications are mostly insignificant to me, so dealing with this update process is a pain when I need to close all my applications for the required reboot.

On a related note, the Apple Software Update service shows "Updates" and "New Software" in its UI window.  iTunes and Quicktime show up under "Updates".  Safari shows up under New Software since it's not installed on this computer.  No problem there, however, normally a checkmark next to Safari shows up by default.  I need to uncheck the box or else new software will be installed.  This, to me, is a somewhat dirty business practice.  Software update programs shouldn't be trying to slip new applications onto people's computers.  I recall seeing the Safari icon on the desktop of friend's computer recently.  He didn't know what the icon was and had never heard of Safari.  He does have iTunes installed on his computer though.  Hmm... I wonder if there's a connection there??

I was working on a web page where I wanted to add a link to take the visitor to the default document of the folder this particular page is in.  This page (e.g. page1.aspx) was in a folder (e.g. folder1).  I actually knew the default document in this folder was index.aspx, and could have just set the link's HREF to "index.aspx", but wanted to make this a little more generic so it didn't matter what the default document was.  Just to be clear, the location of the page I was putting this link on looked like:

http://www.example.com/folder1/page.aspx

Initially, I set the link's HREF to:

"../folder1/"

This worked well.  It would navigate the visitor to:

http://www.example.com/folder1/

But then I needed to copy page.aspx to another folder (e.g. folder2).  So the page was going to exist in both folder1 and folder2.  Once I copied page.aspx to folder2, I could have manually edited the link to:

"../folder2/"

This didn't have a very generic feel to it and I would always need to remember to change the HREF if I needed to copy the page again to other folders.  So I decided to make this link a server side HyperLink control and create some fairly simple .NET code that would determine what the current folder the page was in by parsing the URL and setting the link's HREF so it would take the visitor to the default document of the directory the page was in.  Once the .NET code determined the folder the page was in, it ended up setting the HyperLink's NavigateUrl to something similar to:

HyperLink1.NavigateUrl = "~/folder1/";
       - or even -
HyperLink1.NavigateUrl = "~/folder2/";

The worked well, but I was surprised when I looked at the HTML source to see what the HREF resolved to.  It essentially looked like:

<a id="HyperLink1" href="./">Go to the root of this folder</a>

As you can see, a HREF of "./" is the default document or root of the current folder!  Instead of running this .NET code I created to parse the URL and determine the current folder name, all that's needed is just statically setting the HREF to "./".  This gave me flashbacks to the old DOS days where running a simple DIR command (in a directory other than root) always results in the first two lines being:

<DIR> .
<DIR> ..

The "." DIR refers to the current folder and the ".." DIR refers to the parent folder.  You can still see this today by opening up a command prompt and running DIR.

It's also worth mentioning that you can use "./" when redirecting a visitor in server side code:

Response.Redirect("./");

I'm sure I'll now start finding lots of places to sprinkle "./" HREFs in!