gizmodo reports (and i confirm the link...although everyone is downloading it now so it is sloooowww) that the samsung sgh-i607 aka blackjack now has a windows mobile 6 update available.

one disappointment (for me at least) is that the updater doesn't work on vista.  argh.  gotta find me an XP box now.

the leaders of the arizona .net user group have convinced scott guthrie that phoenix is nice in march (and it is...spring training baby!) and he should visit.  they've organized a super user group meeting and you can find information on when/where here.  it will be hosted at scottsdale center for the arts, which is a pretty killer facility.  i'd recommend carpooling and not messing with the no parking signs (those scottsdale folks like to watch those meters).

having ScottGu come to phoenix immediately after MIX08 is a great thing for the community.  if you couldn't make it to MIX, you'll be able to see some new things from scott in what no doubt will be an exciting, new and learning experience.  there are some great things coming out of his group at MIX and this event in phoenix is a must see.  i'm sure he'll cover some great new web stuff, updates on silverlight and we'll all be enlightened by how he still manages to stay close to the code while serving a growing army in the developer division!  be sure to block your calendar now!

i know scott won't be able to cover everything, so we'll ensure that the code trip will cover some of the gaps.  be sure to subscribe to the feed to know when we'll be coming back through phoenix -- we'll be updating it soon!

recently i came across a feed entitled '.aspx considered harmful' and natural i paused.  for those who don't know .aspx is a known file extension for web pages generally using asp.net technology.  i think the title was a little misleading but it did the job -- got me to read it :-)

john had made a suggestion in conversation that a blog engine (must have been the topic of conversation) shouldn't produce urls that end in .aspx.  basically, in a nutshell john is pointing out that technology changes and while you might be .aspx one day you might be .php the next.  valid point.  where i think his argument breaks down for me is in the two reasons he points out why this is 'harmful': futureproofing and style.

futureproofing

let me take on futureproofing first.  john's assertion is:

"The technology that produces the name, never mind the version of that technology, is a variable that need not, and should not, be exposed. If links are pointing to foo.asp, and your upgraded blog engine produces foo.aspx, you broke those links. That’s unnecessary and avoidable."

for me that is a pretty big leap.  aside from the fact it puts a lot of weight on the technology implementers to forever future-proof their technologies (web ones being in question here).  i'm definitely not disagreeing that you need to do your best effort to future-proof information...that is what makes internet information so valuable...it's longevity.  i disagree with the assertion that file extensions are the cause of problems -- it is more like sloppy editors.  the point here is to respect the permalink.  i'm in the camp of 'who cares' when it comes to file extensions.  if an author of content is moving from one platform to another, it is their responsibility to respect the permalink to the information.  i may have bookmarks, etc. that i rely on.  don't 404 me bro!  john does point out that the new asp.net mvc pattern can help things like this for eliminating .aspx in the url.  i guess i'd be quick to point out that it doesn't solve the problem at all posed in the futureproofing note.  so now i have 'clean' urls...great, what if i now move to a framework that doesn't support mvc/rest-esque url patterns?  i'm just as screwed.  i'll say it again, respect the permalink. 

i'll take an example from one of my colleagues.  dave bost hosted his blog on an asp.net technology for a long time.  he built up a lot of those harmful .aspx things over time.  when dave decided to learn some new technologies, he decided to move to a php-based blog engine.  wow, those dangerous .aspx are going to leave some nasty end trails moving to php.  or not.  you see, this would be more of a move from an older microsoft technology to a newer one.  this is moving from microsoft to non-microsoft.  what would he do?  dave knew he had to respect the archive he had.  so users who may have bookmarked a url to http://davebost.com/blog/archive/2007/06/14/Gadgets-and-Snipping-Tool.aspx will not have lost the information.  see dave.  see dave respect the permalink.  thanks dave.  if you click that link above you'll notice that you'll end up at http://davebost.com/blog/2007/06/14/gadgets-and-snipping-tool which is the current url.  having .aspx wasn't harmful because the author of the content was responsible to ensure that permalink wasn't lost.  now i'm not saying it was drop-dead simple, in fact i don't know how dave decided to do it, but he did.  his readers (and search engine archives) will not be lost because he moved to a different technology.  it didn't matter what the endpoint extension of the url was.  didn't matter at all.

style

on the context of style, john writes:

"Names without extensions are cleaner and simpler. Why does that matter? I guess if you think of URLs as constructs generated by machines for machines, then it doesn’t, because machines don’t care about style. But I believe that even when they’re machine-generated, URLs are for people too. We read, cite, and exchange them. Their structure and content conveys meaning in ways that warrant thoughtful analysis. Elements that don’t convey meaning, and that detract from clarity, should be omitted."

again, here i'll disagree (of course, or what is the point on writing this post).  whenever i see comments like these i always slow down and defer to the mother-in-law factor.  you see, we in technology have a tendency to think that things must make sense.  users generally don't care.  they want things to work.  when they bookmark things they want them to be there.  when they search, they want to find.  etc.  with regard to style, i think it seems a bit nitpicky.  for me content is king.  why should i care what the url is as long as the content i'm looking for/reading/consuming somehow is valid to me.  does it make it less valid because the url looks technical?  look at facebook.  my profile page is http://www.facebook.com/profile.php?id=584375671.  sure, that url does nothing to tell me what profile i'm about to see.  it would be cool, i guess, to see http://www.facebook.com/profile/timheuer, but i don't really care.  you see i can easily ensure my content says view my facebook profile.  there, do you see the url muck?  no, you see a hyperlink to something that i've described.  and when you click it you know what you are getting...so who cares about the url?

john's note about 'elements that don't convey meaning, and that detract from clarity, should be omitted' is something i disagree with.  to *something* they have meaning.  look at yahoo.  this url http://news.yahoo.com/s/ap/20080118/ap_on_go_pr_wh/economy_stimulus goes to an article about president bush and some tax stuff.  should the url have been http://news.yahoo.com/Bush-wants-fast-tax-aid-to-boost-economy?  who knows.  i'm sure there is a content management system behind their solution that is at 'fault' for creating the url.  whatever the reason, i don't care -- the content is king.  i can see somewhat john's point that we can't always blame technology like i just did.  sure a content management system should be able to let me name whatever i want.  but i guess that is a technologist thinking again and not my mother-in-law...she just wants to read the article.

another piece of evidence to this is a commenter on john's blog:

"If I see a file of the form http://example.com/path/to/file.rss I expect the result to be an RSS feed." source

wow!?  i think i'm going to ask my dad tonight if he knows what .rss is.  that is a technologist thinking if i ever saw one.  another commenter notes that urls are brands:

"Absolutely. URLs are brands, permanently on display for every webpage. The user wants to know what the page is about, not what technology you’ve used to put it together." source

i agree with the first statement here.  it is why i blog on timheuer.com and not blogs.msdn.com -- this is my brand.  i would argue 'root brand' is important here.  the user wants to know *where* they are reading the information.  they will remember their own context of the content.  i'll take the yahoo link above as an example.  having news.yahoo.com is critical because it is their brand and reminds me of where it is.  but i won't take the time to really record the rest of the url.  i'll either bookmark it for later if it is interesting or in passing i'll mention to someone 'i read an article on yahoo about bush and tax aid, you should search for it.'  that is how we talk now.  'just google it' is a common phrase.  we use things like tinyurl, shrinkster, etc. to shorten urls for us to make them easier to send. 

urls aren't the only place where this is.  would john suggest that we do away with .exe, .app? 

you see to me, the technology isn't harmful.  the style of implementing human readable urls isn't harmful (or sometimes isn't even helpful), but respecting the permalink is critical...no matter what technology is used.  it matters not what the address bar says, but rather that i can find it when i search for it and when i save a reference to it.

feedreader, my sharepoint web part originally built for sharepoint 2003, has been consumed by quite a few people (which i think is cool -- it is a rare moment when a lowly d00d like me can fill a gap).  while sharepoint 2007 has better built-in support for syndicated feeds (actually 2003 did already with the xml web part), i still think feedreader has some advantages that can be leveraged.

a while back i put feedreader on codeplex, an open source sharing ground.  i used the microsoft public license so anyone can download, alter, and profit from the code.  i did this because i was getting feature requests weekly as well as some of the problematic issues that i never fixed (namely proxy server support needs to be better).  i thought to myself that there way better developers out there than me and can actually help out.  i wanted to prove my own theory wrong.

well, there wasn't a ton of contributions (more work items though), but over the past month i got another one of those requests.  and just the other day, the rss feed from my codeplex project source code check-ins delivered this to me:

1) Added the code that jdenicola suggested in the codeplex discussion forum to fix the object reference... error. The error is caused by the cache being empty. Which is weird since the PartCacheWrite line is being called, but when it reads it doesn’t return anything. Might be environmental, but I didn’t spend too much time trying to figure it out.
2) Changed the cache key from this.Parent.ClientID to this.ClientID (neither key affected the results of PartCacheRead)
3) Moved the assignment of the graphic to the web part code from the .dwp. This fixed the display of the icon at the top right in the title bar, but it still didn’t display the graphic in the web part library. Could be a SharePoint bug not reading the property. The properties PartImageSmall and PartImageLarge are obsolete. I used TitleIconImageUrl and CatalogIconImageUrl (but still couldn’t get the catalog icon image to show up)
4) Repackaged it in a .wsp for WSS 3.0. I included a new manifest file, a couple .ddf’s, and some stsadm commands to handle the install/upgrade from a build event.
5) Added .snk files so assemblies could be strong named and added to the GAC
6) Added setting for "Expand Headline Descriptions by Default" which, when checked, will expand the item descriptions when the page first loads instead of showing them as collapsed (assuming the headline descriptions are not hidden)
7) Added a div tag with a class called sg-item-description surrounding the item descriptions which the user can overload to control the look (background color, border, text size, etc.) of the description

sweet.  a contribution...and a good one at that.  several things were fixed and a few added.  the contributor, ryan mcintyre really stepped up because he saw some things he could fix and leverage for his own benefit as well.  i should also note that flickr4writer also got some contributions from josh holmes a few months back as well.  it is cool to see some progress on something i hadn't had the time to work on and to that i say 'thank you' to ryan for making feedreader a better experience!

finally want to try out that feature to debug your apps and step into System.Web.dll?  it has arrived.

shawn burke has all the blow-by-blow details on setting it up.