Even a chimp can write code

Wednesday, November 30, 2005

New Jersey: It Always Smells Like This

The great state of New Jersey is in search of a new tourism slogan. That has also given amateur comedians their 15 words of fame. Incidentally, the state hired a consulting firm and doled out a quarter of a million dollars for "New Jersey: We'll win you over". Acting governor Richard Codey rejected that for being too negative. Subsequent to that, the state was inviting suggestions from the general public.

Now if you wanted to see some of the candidates, you'd probably go to a news site (maybe not). So I figured we'd take a look at some of the ones I found amusing:

  • Bada Bing! Choose New Jersey

  • New Jersey: Most of our elected officials have not been indicted

  • New Jersey: At least it's not West Virginia

  • New Jersey: You got a problem with that?

  • New Jersey: Why should death end your voting rights?

  • New Jersey: It's not as bad as it smells


The contest is now closed. Don't you wish you knew earlier?

Email this | Bookmark this

Tuesday, November 22, 2005

Peter Drucker, RIP

I never thought I'd be admitting this, but I really miss New England sometimes. The one downside of being away from the Boston area is that you don't reliably get to listen to WBUR or WRNI, the excellent NPR news stations of Boston and Rhode Island, respectively.

Peter Drucker died last week at age 95. So when I heard the news, I looked up WBUR's website for some bit of news, or tribute to the great man. Sure enough, Tom Ashbrook's December 2004 interview with Drucker was featured prominently.

If you've never heard of Drucker or fail to understand the significance of this "loss", I'd advise you to listen to the interview. For the rest of us, Peter Drucker's contributions are so numerous, it would be insulting to list but a few of them. He leaves us richer for the knowledge he shared with us.

Email this | Bookmark this

Wednesday, November 09, 2005

Proof that Natural Selection really works

If you needed any proof that Natural Selection really works, look no further than the election results from Dover, PA. At the polls, voters yesterday booted out eight of the nine Dover Area School Board members — all Republicans — who last year engineered the inclusion of intelligent design in the curriculum. That decision by the school board gave Dover the unique distinction of being the first school district in America to order the introduction of intelligent design in school curricullum. The policy required students to hear a statement about intelligent design before learning about evolution. The statement says Charles Darwin's theory is "not a fact" and has inexplicable "gaps."

Talk about learning the hard way!

Email this | Bookmark this

Monday, November 07, 2005

DLL search order during loading

On Windows, LoadLibrary has most affinity for the directory from where application was loaded. Thus, if you have foo.dll in the %windir%/system32 folder and another copy in the same directory as your application, when foo.dll is referenced from that application, the version co-located with the application is always loaded.

This MSDN article talks in more detail about DLL search order.

For managed code dependencies, the Global Assembly Cache always prevails; the local assembly in application directory will not be picked up if there is an existing (or newer with policy) copy in the GAC.

Tags:

Email this | Bookmark this

Saturday, November 05, 2005

RE: Simpler Urls Get Used More Than Hideous Ones

Rob Relyea blogs about how simple URLs (i.e. those without too many parameters) are more popular with people than more complex ones. Certainly, this is undeniable. I wanted to comment on his post but couldn't (didn't want to register). Besides, I like to hear myself speak as much as the next guy, so I figured a post was in order.

Apart from simple URLs being easier for humans to remember and type, I believe search engines are a big part of why simple URLs are so universally used and linked to. And since it is easy to link to simple URLs, more people link to them and they rank higher with search engines.

Search engines employ bots to locate and crawl through your web pages. These bots use the same means as do those of us using the garden variety browser to read web pages. The bots read pages and follow links on those pages and so on ad infinitum. Google, for instance, says:
We're able to index dynamically generated pages. However, because our web crawler could overwhelm and crash sites that serve dynamic content, we limit the number of dynamic pages we index. In addition, our crawlers may suspect that a URL with many dynamic parameters might be the same page as another URL with different parameters. For that reason, we recommend using fewer parameters if possible. Typically, URLs with 1-2 parameters are more easily crawlable than those with many parameters.

There is another problem with indexing dynamic content requiring multiple request parameters: bots getting lost on web sites with infinite number of links or listings. Say, I maintained a calendar application on my website where I enter my meetings and appointments. If my calendar's timeline has no upper limit to it, you can theoretically navigate from Nov 2005 to Dec 2005 to Jan 2006 and so on for centuries. Only those dates in the not so distant future will have events in them. These are palatable for search engines. Other dynamically generated pages will be nearly empty. A typical bot would be wasting considerable time mired in this black hole. So it is only natural that search engine bots are disinclined to index pages where data comes from a backend database.

Also for corporations moving their applications to the web, it makes sense to have links that aren't tightly coupled with the technology used in the backend. I have personally made decisions like this in past projects. For instance, using a URL format like http://www.amazon.com/gp/product/B00006AVRK/104-9835185-4567919 is much better than http://www.amazon.com/gp.jsp?product=B00006AVRK&id=104-9835185-4567919. This is because if you move from using JSP/Struts/Java to ASP/C# or Perl, you don't have to comb through your content and change all URLs. You'd also have to inform partners and others who link to you, notifying them of the change. Now, who wants to sign up for that job? Keeping the URLs neutral really pays off. Plus, search engine bots have no idea the information they are indexing is coming from a database. I am willing to bet this is why Amazon and others employ this form of URL rewriting.

Email this | Bookmark this

Resources in Windows Presentation Foundation applications

I've been wanting to blog about the application files and resources story in WPF, but couldn't get to it thus far. Recently I responded to a newsgroup question on how WPF (Avalon) handles resources, and figured that would make a good blog post until the WinFX SDK content for this goes online.

Update [Apr 2009]: If you came here looking for resources and URIs in Silverlight, then you will find this post helpful. Note that Silverlight does not support pack URIs. If you're curious about resources in WPF or even as a historical perspective of what we enabled in the resource resolution and loading space in WPF before we created the subset in Silverlight, then read on.

Background
Resources are non-executable data deployed with an application. They may take the form of images displayed in the UI or message strings for error messages. The .NET Framework provides built-in support for creating, localizing, packaging and deploying resources. You can create resources in a .resx or a .resources file. The .resx resource file format consists of XML entries to specify objects and strings. If your application has an image, the binary form of that image is serialized into the .resx file. But although a .resx file can be edited via a text editor, it cannot directly be added to an application executable or satellite assembly. You must first convert it to a .resources file using a tool like ResGen.exe and add the .resources file into the assembly. The GenerateResource task in MSBuild handles the conversion of .resx to .resources at build time. In your WinForms project, you'd specify the EmbeddedResource build action for .resx files.
For e.g.

<EmbeddedResource Include="myResources.resx"/>

How we do it in Avalon
In Windows Presentation Foundation, the resource definition and loading model is different from the WinForms model. First, we do not require you to create .resx files. You merely indicate your resources in the project file and the WPF build system will take care of the rest. Second, unlike with .NET resources which have resource ids, in WPF you need to reference a resource in XAML via a Uri. WPF also supports the multi-lingual user interface (MUI) assembly model where language-neutral resources go into the main assembly and language-specific resources go into corresponding language-specific satellite assemblies. For these purposes, a new set of resource build actions were created. These are the Resource and Content build actions. Both these build actions target application files that are known at compile time.

Resource
If a file is denoted 'Resource' in the project file, upon build, that file is embedded into the application assembly. Whether main or satellite assembly, depends on whether you've set the 'Localizable' meta-data. The default is main assembly.
For e.g.

<Resource Include="AmateurDictators/RoderickSpode.jpg"/>

The ResourcesGenerator task in the WPF MSBuild system (in Microsoft.WinFX.targets) creates a single .resources file for all Resources specified in the project. In a localized application, the application will load the resource from the appropriate satellite assembly based on the locale of the computer where it is running. In a future post I will talk about the resource fallback logic in WPF.

Content
If a file is denoted as 'Content' with the appropriate 'CopyToOutputDirectory' meta-data set to 'Always' or 'PreserveNewest', the file is treated as loose application content and is copied to the build output directory, residing alongside the application assembly.
For e.g.

<Content Include="Drones/GussyFink-Nottle.png">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</Content>

Regardless of whether you denote a file as 'Resource' or 'Content', you can access it in markup and code via a simple relative Uri. For e.g.

<Image Source="AmateurDictators/RoderickSpode.jpg" />
<Image Source="Drones/GussyFink-Nottle.png" />

During build, a mapping of all Content files in an application is created. At runtime, when confronted with a relative Uri, the loading mechanism knows if the object is a loose Content file or a Resource embedded in the application assembly.

Files at site of origin
If you do not want to be bound by the restrictions of having your application resources declared at compile time, there is another option for you. No, this doesn't involve using fully qualified Uris to reference resources over the internet. Although, that is indeed supported. WPF provides you with an abstraction for the application's conceptual site of origin i.e. the location from where the application was deployed. For instance, if your application was launched from http://nerddawg.blogspot.com, then your application's site of origin is http://nerddawg.blogspot.com. To access an image at images/AuntDahlia.gif at that location, you would specify in markup:

<Image Source="pack://siteoforigin:,,,/images/AuntDahlia.jpg" />

You can use the same Uri in code. For more on the Pack Uri syntax, see the Appendix in the XPS spec. I will provide more details in a future post.

Choosing one over the other
You would choose to mark a file as Resource if:

  • your file is localizable i.e. images with text in them, fonts or text files

  • you don't expect to replace the file once the application has been built

  • you don't want to deal with the task of managing and deploying the file separately from the application i.e. you want to be able to move the application around without having to worry about moving several associated files


And, you would choose to mark a file as Content if:

  • your file is not localizable

  • you want the flexibility of replacing the file after the application assemblies have been built

  • you want to be able to have the file download on demand (i.e. not with the application assembly)

  • WPF cannot load a file of this type when it is embedded into the application assembly e.g. HTML content rendered in a Frame, media files


Finally, you would choose the site of origin notation if:

  • your file is not localizable

  • you want the flexibility of replacing the file after the application assemblies have been built

  • you want to be able to have the file downloaded only when requested

  • you don't know the contents of the file (or you don't really have the file) when you build the application

  • your file is very large and you don't want that to affect the application download time e.g. large media files

  • WPF cannot load a file of this type when it is embedded into the application assembly e.g. HTML content rendered in a Frame, media files


There is currently no support for strongly typed 'Resource' and 'Content' files in the WPF project templates. 'EmbeddedResources' are supported, however, they cannot be referenced via Uris.

Tags:

Email this | Bookmark this