Jay Harris is Cpt. LoadTest

a .net developers blog on improving user experience of humans and coders
Home | About | Speaking | Contact | Archives | RSS
Filed under: Tools

Microsoft has announced that the upgrade to Internet Explorer 7 will be “high priority” in Windows Update, essentially forcing the upgrade on XP users everywhere (news.com). Microsoft has released a toolkit to disable automatic delivery of the browser upgrade, however this is a pro-active path; if a user does nothing, they are going to get the new version. My poor grandma (Usability: What Would Grandma Do?), who has no idea about any of this, is getting the upgrade. If you have Windows XP, and you have an internet connection, you pretty much are destined for this upgrade.

Now, I don’t think that is entirely a bad thing. Far too many people just blindly use this paperweight we call a computer. They don’t read manuals, they don’t educate themselves on this thing, they just start pressing buttons. When they get a phishing email about “Your bank account has been compromised. Please send me your account number and password so that I can fix it,” they reply with their credentials. “Click here and win an iPod” and they click. “Check out this email attachment of dancing babies” and they get yet another virus. Because of this we have to monkey-proof computers, and add far too many security checks on systems, and overall make developer-life a little more painful. So, I think this is a good thing. Yeah, I drank the Microsoft kool-aid, but I’m all for this automated upgrade to help make up for the swiss cheese that is Internet Explorer 6. I’m going to continue using Firefox as my browser, anyway, but if this makes my OS a little more secure…good!

But what does this mean to us, the development / testing community? Test now. Test often. In a few short months a few million people will unknowingly get IE7, and at that time we will no longer have any excuse about whether or not our systems work. Our stuff needs to work on IE7-Day. So download the beta, and start testing your web apps to make sure everything still works. Microsoft hasn’t been too browser-compliant in the past, and other than competition from Firefox I don’t see a lot of reason that they would start, so there is good reason to suspect things might break. Start testing now, or you will be scrambling in a few months when your help desk lights up like a Christmas tree.

Friday, July 28, 2006 8:30:43 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] - Trackback

Filed under: ASP.Net | Programming

Many .Net developers that have experience in presentation-layer development have previous exposure to this one, but to those who haven’t, I must share: Request.ApplicationPath is evil! Request.Application path should never be used. Ever. I hate it!

It’s misgivings are most commonly exposed when concatenating strings to the end of it to create a URL of some sort.

sURL = Request.ApplicationPath & “/someDirectory/somePage.aspx”

This is evil. Neither will work in all situations due to the method’s inconsistency with trailing slashes.

If the application root is in a sub-directory, say “http://server/myRoot/index.aspx”, then the appPath is “/myRoot”. Note: there is no slash at the end, and the above sURL gets a value of “/myRoot/someDirectory/somePage.aspx”.

If the application root is not in a sub-directory, say “http://server/index.aspx”, then the appPath is “/”. Note: there is a slash at the end, and the above sURL gets a value or “//someDirectory/somePage.aspx”. In this case, rather than requesting “http://server/someDirectory/somePage.aspx”, wonderful Internet Explorer requests “http://somedirectory/somePage.aspx”. (I don’t fault IE for this. I commend it. It is actually one of the few cases where IE doesn’t kludge together a band-aid for Developer mistakes.)

So, don’t use Request.ApplicationPath. Ever. With no exception. You could make a method, perhaps MyUtilities.ApplicationPath, that checks to see if the return contains a trailing ‘/’, and if it does, give it the axe. This will turn your domain-root appPath to an empty string. Use your new method rather than Request.ApplicationPath, and all will be well with the world. But, don’t do it! Don’t make a new method. That just continues the evilness.

Use Page.ResolveURL(”~/someDirectory/somePage.aspx”) or the counterpart Control.ResolveURL if you want it to be relative to the control’s location. This is the only scenario you should use. ApplicationPath is evil!

Wednesday, July 26, 2006 8:19:23 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [4] - Trackback

Filed under: Mush | Xbox

In yet another post on the Xbox 360 and associated games and accessories, I am excited about the upcoming game lineup for Xbox Live Arcade. Contra has to be one of the coolest video games in the history of video games. I lost weeks of my life to that game. In addition, Frogger, Galaga, Dig Dug, Pacman, Defender, Sonic, and Street Fighter have all been announced. I’m going to be glued to my television, with nostalgia oozing out of my pores, once these things hit XBLA.

It is a bit old news by now, but this is all from E3. You can read all about it on microsoft.com.

Sunday, July 2, 2006 8:28:56 AM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] - Trackback