Rob Relyea just posted up a little piece that details the three different approaches developers can take to code their Avalon applications. I'm not sure if he was working on it prior to this, but there was a question in the Avalon NG earlier today about how a Delphi person can code Avalon applications and this answers that perfectly.

Basically, because Avalon is “just” another CLR API, you can always code against it with any language that runs on the CLR (2.0). However, when it comes to XAML you have a couple different options depending on your language's support for the CodeDom and MSBuild.

Mimeo.com has just announced we've closed on another $9mil in funding. We're also one of two hundred companies nominated for the Red Herring 100. Exciting times for the company as we're really hitting our stride and beginning to find that we've done a good job establishing ourselves as a dependable name in the industry.

On the development front we went to beta a couple weeks ago with our newest application bits which we've spent the past eight months or so developing from the ground up based on what we learned about our business needs in the past four years. The new code-base is one hundred percent .NET with the exception of a few third party components which we've either P/Invoke'd, added COM wrappers for or simply execute as stand alone executables (ugly, i know, but that's image ripping software for ya).

After we deliver this major upgrade, we're going to be able to focus on small deliverables that simply extend our offering with tremendous value add for our customers. I look forward to that because long projects like this often leave you longing for a sense of completion. We will return to agile development methodologies and a personal goal of mine is to make sure that the longest projects for the next few years last no more than two months average for even the most signifigant upgrades.

This sounds like a great chance for a select few individuals who have the right stuff. When opportunities like these arise I begin to wish I wasn't so darn committed to my current company. :\

Here's a tidbit of info that will hopefully help some people out. It took me a couple stabs at Google keyword combinations to find the answer. Basically the problem was that we're taking user input in an HTML page which can include Unicode characters and need to pass that on the query string to an ASP.NET handler for processing. What was happening is that when the data was got to ASP.NET the Unicode characters seemed to have been stripped out. Now, being a very Unicode concious person I'm wondering why the heck this could possibly happen considering I've got my <globalization requestEncoding="utf-8" responseEncoding="utf-8"> in the web.config. It dawned on me relatively quickly that these only control HTTP content, not the URL encoding which is entirely handled by the browser. Therefore the problem had to be that the client wasn't encoding the URL properly. Next we found the client script that was building the URL, but it was using the escape function to properly encode any invalid characters (or so we thought, read on...). Next, I checked the URL being sent to the server using IEHttpHeaders and the character was encoded as %E9 (é was the unicode character in question btw). Well %E9 is the ISO-Latin encoding. The Unicode encoding is supposed to be %u00E9. The problem is that the escape function is locked into a basic functionality which doesn't truly leverage proper Unicode encoding (see appendix B of the EMCAScript specification). A new set of URI encoding/decoding functions were introduced with ECMAScript which handle Unicode. The one that takes escape's place is called encodeURIComponent. Needless to say we quickly did a replace in all files on our ECMAScript codebase to eradicate the undesireable encoding behavior of the legacy escape function.

This is a great idea and I'm definitely interested in entering, but unfortunately it's only open to Canadian contestants. When's the North American version coming?