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.

i recently got an email from a rails developer who was using silverlight on a site to display high-quality media.  what?! you though silverlight was a windows-only technology? blasphemy!  you see, silverlight is a client-technology, which means as long as it can be served up to the browser (and the user has the plugin), the server can be your own custom version of l337hax0r web edition or whatever.  now, there are advantages of using internet information services on windows and some integration with asp.net, but that's not what this post is about.  on to the issue at hand will you...

so the email...he was getting an error message:

ActionController::RoutingError (No route matches "/player.xaml" with {:method=>:get}):

now i'm not incredibly familiar with what web server configuration he is running (although he is running netbeans/mongrel), but it got me thinking of 2 things.  first, maybe he needed to add a mime mapping.

for silverlight, the following MIME map is for .xaml files: .xaml: application/xaml+xml

but then i also thought that it might be something of some files moved around and such.  i deduced from his note that an expression encoder template was being used as he mentioned he moved the javascript files to the javascripts directory of his rails application.  for those who don't know, rails is an MVC pattern web framework.  when creating a rails application you get a few different folders created for you (note: i'm just talking rails foo command here).  a lot of the work is done in controllers/models/views folder but there is also a folder called public.  within there are your typical images and javascripts type folders.  basically you can think of public mapping to "/" for static files.

now most rails applications probably wouldn't want all the encoder output to be dumped into /public as-is.  if developers are anything like me (OCD about project folder organization), then you want *.js to be in one place, etc.  i suspected that my reader put all the encoder files in the /public/javascripts folder.  this would be fine and should work okay.  but lets say you want some organization.

for example, i want to put my .js files in /public/javascripts, my jpg/pngs in /public/images and i'm going to create a folder for my xaml and a folder for media (wmv).  great, so we move all the files around then we run the Default.html page.  nothing happens.  why?  well a few things need to change if you move things around.

first, you need your hosting page (in this case right now it is Default.html) to reference the right path to the javascript locations.  so in our example we'd modify (in Default.html) lines like:

<script type='text/javascript' src="Silverlight.js"></script>
<script type='text/javascript' src="BasePlayer.js"></script>

to this:

<script type='text/javascript' src="javascripts/Silverlight.js"></script>
<script type='text/javascript' src="javascripts/BasePlayer.js"></script>

noting that of course there are more than just these two files.  now if we run the application it would still fail.  this is for two reasons, both of which are in StartPlayer.js.  the first is on or about line 8 of the script:

   1:   

   2:   

   3:   

   4:  function get_mediainfo(mediainfoIndex) {

   5:      switch (mediainfoIndex) {        

   6:   

   7:          case 0:

   8:              return  { "mediaUrl": "CodeTripSample.wmv",

   9:                        "placeholderImage": "CodeTripSample_Thumb.jpg",

the next is on or about line 24:

  22:  function StartPlayer_0(parentId) {

  23:      this._hostname = EePlayer.Player._getUniqueName("xamlHost");

  24:      Silverlight.createObjectEx( {   source: player.xaml', 

these both need to map to the right references of where that content has moved...so noting my above folder changes (images/javascripts/media/xaml) my StartPlayer.js file now starts like this:

   1:   

   2:   

   3:   

   4:  function get_mediainfo(mediainfoIndex) {

   5:      switch (mediainfoIndex) {        

   6:   

   7:          case 0:

   8:              return  { "mediaUrl": "media/CodeTripSample.wmv",

   9:                        "placeholderImage": "images/CodeTripSample_Thumb.jpg",

  10:                        "chapters": [               

  11:                                    ] };                                                                

  12:                            

  13:          default:

  14:               throw Error.invalidOperation("No such mediainfo");

  15:       }

  16:  }

  17:   

  18:  function StartWithParent(parentId, appId) {

  19:      new StartPlayer_0(parentId);

  20:  }

  21:   

  22:  function StartPlayer_0(parentId) {

  23:      this._hostname = EePlayer.Player._getUniqueName("xamlHost");

  24:      Silverlight.createObjectEx( {   source: 'xaml/player.xaml', 

and all is well -- my rails app starts and my silverlight content is loaded.  my resulting rails app structure looks like this:

simple enough, but if you move things around you might not have known where you need to change things.  you may wonder why you don't have to change the MediaElement in the player.xaml file.  well, if you are using an expression encoder template, the Url of that element is controlled by the StartPlayer.js mediaUrl attribute being passed to the player.

so if you have static information for your rails app this would probably work fine for you, but i suspect your rails application might be using views and such.  so you'd probably want to ensure you are modifying the appropriate view in views/layouts to ensure the javascript reference is correct, etc.

hope this helps.

i was peripherally listening to the macworld keynote today waiting for something that would interest me.  i read all the rumors about a sub-compact laptop and was hoping for the best.  i am not a lover of widescreen laptops.  i love my 14" lenovo and all other standard sizes before that.  i've always felt that when you get into the widescreens, it no longer becomes a notebook, but a portable...i want the lightweight but powerful notebook.  to that end i use a lenovo thinkpad and a macbook pro (15").  i like them both...a lot.  for my daily typing i find i'm more comfortable on the lenovo keyboard...it has that tactile response akin to a 1985 ibm keyboard...for me it works.  but i love the overall industrial design, display and weight of my macbook.  at macworld, i was hoping for the announcement of the 13" macbook pro.  i like the macbook current design, but wanted a more powerful machine and an aluminum case (maybe even colored like their ipod lines).  but alas, steve seemed to be catering to the super lightweight class of design.

at a cost of USD $1800 as a base price, i feel they introduced something cool and priced it out.  for me it isn't even compelling enough to look at for that price (the solid state one is over USD $3000).  i know people say that the lack of an optical drive is no big deal because you rarely use it.  i used to think that too until i tried to use a laptop without one.  especially being ultra portable, i would have considered macbook air for a travel machine, but would want to watch DVDs, etc. (why not itunes movies you ask -- well, because i have my own DVDs and i like DVD extras and the ability to get new releases).  also the lack of ethernet is a bit troubling.  i use wireless all the time and i think rarely plugin, but i look to the times when i do plug in and would be frustrated that i would have to carry an ethernet dongle there.  when it is all said and done, the macbook air is cool looking and i can't wait to stop by an apple store and mess around with one, but for me, the features aren't there to make it worth the investment.  maybe i'll wait 3 months for jobs to screw the early adopters and reduce the price.

i wish it was a 13" macbook pro.  i love a lot of my macbook pro now, just wish that power was harnessed in the size of the macbook.  is that so hard?  if that would have been the announcement, i would have snuck out to a 'meeting' and gotten one today.