Kevin Daly

Last DotNetJunkies post

For the last couple of years I've been conscious of the fact that my online efforts are spread over the web with little rhyme or reason.

It seems inherently silly to have a personal web site and have my actual blog hosted elsewhere.
So, in order to move closer to providing a One-Stop Shop For All Your Kevin Daly-related Needs (er...), and also to um,  sort-of-you-know-what-I-mean "unify the brand", I've created a blog on my web site at http://www.kevdaly.co.nz/weblog.
It also gives me complete control over content and format, so from now on everything is my fault.
That is where I'll be posting in future (I've copied some past posts over to the new blog for convenience. But I won't be doing that with this one because that would be stupid, eh).

I'd like to give a big "thank you" to Donny and the Dotnetjunkies team for hosting my ramblings for the past few years, it's much appreciated.

That's all Ladies and Gentlemen.

Off Topic: Riverbend has posted again

This has nothing to do with anything technical or even geeky, but there is a wider world, the one that actually matters.

Those who have been following the blog of the Iraqi who writes as Riverbend will be pleased to know she has posted again, covering her family's escape to Syria.
I'm relieved to know they got out, and filled with sadness and cold rage that they and so many others had to.

Go read Riverbend's latest now, and then everything else on her blog.

Then study war no more.

Tip for NZ Daylight Saving changes

Those of us working in New Zealand will probably be aware (or should be aware) that our government in its wisdom decided on very short notice (on the principle that Anything I Don't Understand Isn't Important) to extend daylight saving from this year, basically to squeeze more money out of the tourists.

The updates for Windows are mostly available, but there is nevertheless room for uncertainty about whether any given machine has been patched.

A nice feature added to the DateTime structure in .NET 2.0 is the IsDaylightSavingTime method, which enables the following expression which can be run on any machine in the NZ timezone to test whether the daylight saving patch has been applied:

new DateTime(2007,9,30,3,0,0).IsDaylightSavingTime()

So there you go.

Productivity

Thought for the day: If I thought lines of code were truly a useful measure of productivity, I'd stop using the ternary operator.

But I won't.

Community Server 2.1 and newMediaObject - (Windows Mobile 5 app CAB link now included)

(Updated 11:07 pm with info about service packs)

In a recent post I mentioned the MetaWeblogAPI's newMediaObject method and the fact that it's finally beginning to be supported by popular blog hosting tools.

Well, a few days ago I went ahead and released version 2.1 of Diarist, with support for uploading image files (jpeg, gif or png...you didn't honestly want tiff did you? from a mobile device?) to blog hosting sites that support newMediaObject.

(I didn't post anything about it at the time because I'm sure that Dotnetjunkies readers are sick of me posting about Diarist updates. I'd write some "How-to"'s but I'm still exhausted from writing code...).

Anyway, this is just a piece of information for people who are hosting their own Community Server 2.1 sites: apparently newMediaObject support was released late last year as an add-on, which you can get here if you don't already have it and haven't installed/don't want to install Service Pack 2 or later.
It was also included in in Service Pack 2 (I think they're up to Service Pack 3 now)

I hope you find that helpful.

Now I'll return to carefully avoiding any British blogs that might contain references to the final episode of Life On Mars (which I won't see for about another year) (...unless some wise company offers me a job over that side of the world, in which case I'll have to get it on DVD. But I digress. Even more than usual).

Update: Thursday, 26/04/2007

Users of Windows Mobile 5 devices or later may be wondering why I'm not using either the image picker or the camera capture dialog.

The first reason (which applies to both) is that the current program is designed to run on both Windows Mobile 5 (or 6) and Windows Mobile 2003 (which doesn't include either of those options).
Regarding the camera capture dialog specifically, the other reason is that I completely forget about it until Jason Barile reminded me.

I've decided however that these omissions create an unnecessarily crappy experience for users of Windows Mobile 5 and later, so I'm planning to make a separate version available for those lucky bast people.

Unfortunately I don't have any way to test the camera functionality in emulation, so I'll probably just go with adding the image picker for now.

 Update: Thursday night

It turns out I didn't need to fork the project at all, or even subclass the main form as I was considering at one time.
One delegate did the trick...I'll post the updated code soon and also some discussion of the coding issues.

Update: Even later on Thursday night (updated a little more subsequently)

Aaarrrggh!!!. I've decided to shelve the image picker support on the  Pocket PC version, at least using a single project for WM2003 and WM5: I found that it bloated the CAB file by almost 200K extra by insisting on deploying the new dlls ) ...not worth it for a pretty picker, especially for people running WM2003 who can't  use it anyway.

When I get around to it I'll create a Windows Mobile 5-only version, I think I know the reason for the bloat issue with the single-project-and-deployment approach.

Update: Wednesday 2/5 (Last update, I promise)

I've created a Windows Mobile 5-only version that includes the visual image picker (er...). I'll update the site before too long with appropriate links, but in the meantime you can get it here.

newMediaObject

A common requirement for blogging applications (and one I haven't implemented) is the ability to upload images to a blog.

The MetaWeblogAPI does provide a mechanism to do this: the newMediaObject method.

Unfortunately this was until recently notable for the fact that precious few blogging engines implemented it (which is why I haven't done anything about it).

...But now, well, things are changing: recent releases of both Community Server and dasBlog for example do reportedly implement it. The fly in the ointment is the inertia of installed software: how to know if any given installation you're interacting with implements it or not.
It's not reasonable to expect the user to know, and do we want them to find out by trial and error?

It's a tough one, and if anyone has any good ideas on the subject please feel free to contact me and let me know.

Expression Web and Blend to be included in MSDN Premium subscription

Excellent news this morning from Somasegar.

Thanks to the Microsoft Expression blog for the heads up.

Now I just have to bite my nails for a while hoping Expression Blend is released before my MSDN subscription expires...

Diarist 2 for Pocket PC released

(UPDATE 07/04/2007: Another refresh. This time thanks go to Stefan Stranger for noticing that nothing was happening when adding a blog where it was selected from a list of several hosted on the same site. When I checked I found the event handler had got unhooked at some stage. So embarrassing.)

(UPDATE 04/04/2007:The version I posted last night did not handle VGA displays correctly, as Juan Gomez alerted me this morning. I've now posted an updated version of the CAB file)

This version is updated for (and requires) .NET Compact Framework 2.

Unfortunately I've had to drop Blogger  support (I think I've warned everybody enough about that now), but there is a nice collection of new features.

Read more about it here, or just go to my web site to download it.

Or alternatively of course, you could just do something else completely. It's entirely up to you, I won't mind.

Now I can put some serious time into WPF and other nifty things.

The WPF/E CTP is finally available

(and the site is up for real this time).

Go here for the details.

There's also an interview with Joe Stegman on Channel 9 here.

Now I'll step out of the way while the multitudes rush to make vitriolic if poorly-reasoned Flash comparisons.

Personally, I think this is cool (despite the JavaScript).

Posting from Windows Live Writer

Hopefully this will work with DNJ - it will be very handy if it does, since the rich editor used in Community Server 1.0 does not appear for IE7 Beta 3, so it always defaults to a simple Textarea control, which is not an optimal experience (Firefox displays the fancy text editor but it doesn't work).

So if WLW works I'll be doing a bit more posting :-)

Trying to post from Word 2007 Beta 2

WinFS Morphs into The Late WinFS

I was quite keen on the idea of a relational file store.
Oh well.

Someone having a little trouble with user agent strings?

I've been running IE7 Beta 2 for a couple of weeks now, and I have to say I like it more the more I use it (but not in a weird way you understand).
So anyway, today I thought I'd visit the Google Calendar site, since I'm interested in the API...and what do I see but a message saying "Sorry, Google Calendar doesn't currently support your browser". Clicking the Cancel option to ignore the message I soon found that Google Calendar appears to support my browser quite happily, so it looks like a case of unsophisticated handling of the user agent string.

But wait, there's more: when I came to write this post I found myself confronted not with the usual nifty editing tool but a simple Textarea control. Since I have reason to believe that IE7 Beta 2 has no particular trouble with the contenteditable attribute (I was trying it a few days ago), it looks like Community Server has the same problem as Google
(I'm reminded of ASP.NET 1.x, which would happily class any non-Microsoft browser as "downlevel"...but Microsoft at least have learned).

The status of client script in internet applications

With all the buzz (and to some extent, let's be honest, hype) apart the newly sexy and relabelled AJAX, I'm beginning to wonder about the continuing applicability of some of the design principles I have applied to web applications for the past 6 years.
When contrasting the new "Javascript sexy" world with the previous "Javascript crappy" one, many people speak as if the only reason we shied away from script-heavy web applications was that they were to say the least difficult to debug. That is of course not the whole story - it's easy to forget the browser story a few years ago was much worse than it is now, with IE and Netscape offering two completely different DHTML models and other browsers going their own strange way. So things are much better now if for no other reason than that everybody understands "getElementById" (one of the last reasons for browser sniffing involves AJAX and will be greatly mitigated by IE7, but that's another story)
But there was yet another issue: aside from those browsers that didn't have support for any version of Javascript let alone a DOM (I recall at one point using the not entirely helpful argument that their users probably didn't have any money anyway), towards the turn of the century it became common practice for organisations to block or disable Javascript for security reasons.
That led to the logical conclusion: if you want to expose your site or application broadly on the public internet, you can't assume that Javascript will be available.
Hence the rule: No mission-critical client script. The ASP.NET validators exemplify this approach: by default they will be triggered on the client, but the server-side validation is always triggered in any case, so that even if Javascript is blocked the control still works (or if it doesn't, it's for a different reason).
And that's the way we've approached things in an online world where client script may or may not be enabled: we've had to treat it as something that improves the user experience where it's available, but without which the application still functions. 

AJAX-enabled applications could be designed the same way, but I can confidently predict that the non-AJAX user experience will be much more painful than if the UI were designed with full page refreshes in mind, since the design choices that would normally be made to mitigate the limitations of that approach are likely not to have been made, or may simply not be practical without providing two different versions of the site. In other words, everything that is unpleasant and cumbersome about a non-AJAX web application is likely to be even more so for AJAX applications being used er, without AJAX.
To give a roughly analogous example: you may recall when framesets were in vogue (before they were recognised as evil), we had the element to contain markup to display typically for browsers that did not support framesets or had them disabled. Now, let's be honest: how often was this feature used in a way much more helpful than the following:

It appears that your browser does not support frames, or has them disabled. Shame.

Sooooooooooooooo...I'd be very interested to hear what people think: have we finally moved on to a stage where it can safely be assumed for most purposes that client script will be enabled?

Atlas setup blues

I downloaded the Atlas April 2006 CTP this morning, intending to then grab the newly released Control Toolkit.

No such luck: when I tried to run AtlasSetup.msi it failed with an error about a corrupt cab file. I tried again, to no avail.
Subsequently I tried downloading it at different speeds, and then from a different machine (and tried installing on that machine).

I got the same error every time.

So currently, despite the fact that it looks to be very cool and useful, my verdict on Atlas from my own perspective is: It doesn't work (because it can't work if I can't install it).
Very disappointing. 

Update

I've now tried installing on a third machine with no betas or CTPs installed, and I still get the same error: "The cabinet file '_28942B4D9DE730210E7C27BD4FBAD377' required for this installation is corrupt and cannot be used. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package."
I downloaded the file again from that machine, with the same result.

By way of clarification, I was not suggesting that this release of Atlas doesn't work per se, I simply mean that for whatever reason it doesn't work for me.

Development implications of UMPC

So, the hype has come and gone,and now we are temporarily left with nothing but the whining of people complaining that a UMPC makes a crappy iPod...

As I mentioned previously in my recent Geekzone post, Alex Yakhnin has astutely identified the reasons why Windows Mobile/Compact Framework developers are well-placed to take advantage of the UMPC platform (or form factor, or whatever we choose to call it). So anyway, I didn't set out today to indulge in a self-referential link-fest, so it's about time I said something new.

The point I want to make today is that the arrival (sort of) of UMPC devices underlines in big red, um, underlines something that Microsofties have been telling us for a while: it's time to make ourselves resolution-independent. This doevetails quite well with the message that accompanies Avalon  WPF loveliness: we have to ensuure that our content will look good at any size, at any resolution. We can no longer afford to regard the display area as a fixed surface upon which we display visual elements as we see fit. From now on the Windows developer must borrow habits of thought from the web developer, and assume the same flexibility. Our content will be displayed on devices with drastically varying resolutions (compare standard PC with UMPC), and with Vista will be resized, flowed, and generally played with. These are factors we must take into account if we want to avoid producing what would in many cases become junk UI.

Those who regard this prospect with something not unlike excitement will in all probability prosper, whereas those who cling to the certainties of the fixed design surface might as well look for a place in the museum of development of history with all the people who thought there'd never be any call for colour or non-textual UI in a business application.

A brief thought on REST vs. SOAP in the case of the Amazon Web Services

The web services exposed by Amazon.com are undoubtedly among the more successful examples of publicly accessible web services.

Amazon provide both a SOAP and a REST (or pseudo-REST) interface to their API, which means that a great number of client platforms (and developer preferences) catered for. It also provides a fun arena for developer religious wars :-).
Tim O'Reilly reported back in 2003 that 85% of the Amazon API  access was via the RESTful interface. I have no idea whether that is still the case (I suspect there may have been some increase in SOAP use by Java developers owing to improvements in platform support, but I expect that to be offset by more .NET developers using the REST approach, for reasons I'll give below) - however I do know that it has little to do with the intrinsic merits of SOAP or  developer acceptance of it.

I'm pretty confident that most .NET developers on approaching the Amazon API would have gone straight to the WSDL, generated themselves a proxy, and proceeded from there. And if you're designing an application for Windows or a mobile device, that's a reasonable thing to do. You have easy programmatic access, and you get back a nice strongly-typed response. Databinding the returned objects was a bit of a problem owing to the lack of properties to bind to (I suspect that problem may have gone away with .NET 2, but I'll need to experiment), but still, working with the API this way seemed the natural thing to do.

However, the truth is that a great number (probably the majority) of applications that use the Amazon API are web applications. If they are returning content to be displayed on the screen, the simplest way to return that content is actually as an XML document that can be transformed to HTML by an XSLT stylesheet (or you can use one of the Amazon stylesheets if you don't want a lot of control over the output). XML in that case is a better choice, which means that for the average suck-something-out-of-Amazon-and-stick-it-on-a-web-page scenario, REST is a more logical choice, because it actually saves you a lot of work (unless you don't like XSLT).

This is completely different from the reason I assume hardly anybody (if that) uses the SOAP version of the Flickr API: in that case it's simply because Flickr does not, as far as I can tell (and I'm not alone in this), provide a WSDL file...so unless you want to create your own (gee, that's sooo much fun), you can forget about generating a proxy - and let's face it, using SOAP without one is only marginally less horrible than working with XML-RPC.

New Site

I now once again have a non-blog presence online: www.kevdaly.co.nz.

Currently there isn't much there, but I intend (no really, cross my heart and swear to get really drunk otherwise) to post a few articles and things before long.
Importantly for those who have an interest in my mobile blogging work, it means there's once again a download site for Diarist.

And just a reminder: the latest version fully supports MSN Spaces (and Blogger Atom support should be fixed as well).
It's currently a very sparse download page without anything in the way of explanatory text, but I'll deal with that shortly.

Yet more on Diarist with MSN Spaces

OK, I've been trying it for a few days now, and it's definitely working fine now without trying to use the local network setting - so I'm confident that that was simply a business-as-usual Connection Manager glitch connected with the fact that I was using it at one point while the device was cradled and I was getting screen shots of the configuration screen.

Which is a long-winded way of saying that if you're interested, contact me and I'll send you the latest version to try.

About the new-look MSDN Subscriber Downloads area: am I the only person who really, really hates that incredibly slow, unresponsive treeview?

In other news: I've been testing my RSS generation code with both RSS Bandit and SharpReader lately. Once I've got my site up I'll be using it to provide notifications of software updates (as mentioned previously).

Diarist and MetaWeblog for MSN Spaces

Update 11:08 pm - the problem below did recur - it looks very much like the Harrier decided I was using a local network connection, so I set my local network settings to also be Telecom CDMA, and that seems to have taken care of it. I'll keep testing for another day or two to make sure.

The blogging API for MSN Spaces went live today (-ish...depending on your time zone).
I naturally tested it with Diarist - there was a bug I had to correct before the SSL would work (actually it was a bug in CF 1.0, but it requires a workaround). It looks as if everything's OK...for a while I was getting errors trying to connect from my Harrier (just saying it couldn't connect to the remote server), but I'm not getting them now so unless there's a recurrence I'll put it down to "transient network conditions" (TNC, if you must).
Other than those initial hiccups (and with my fingers crossed against a recurrence of the last) I'm quite pleased: things like dates and categories that often have issues worked perfectly right away.

In addition to fixing the SSL issue, I've also changed the default address for Blogger via Atom to be https (they seem to have finally got around to requiring that while I wasn't looking), and to avoid too much inconvenience with changes like that in future I've made API addresses that default (such as Blogger)  editable.
In addition I've added a menu option for MSN Spaces, so people won't have to key in the address.

I'll make the Spaces-friendly version available as soon as it's fully tested and I'm confident it won't suddenly fall over, but for the next week or two you'll have to ask me for a copy via the Contact form and I'll email you the CAB file - the plug gets pulled on my free hosting on www.aspxconnection.com tomorrow, so there won't be anywhere to download from until I've made alternative arrangements (as soon as possible).

For the same reason I've removed the download links and images from some of the posts I've made here, since they were linked to the same site.
When my hosting is taken care of I'll tidy up and republish some of the better ones as proper articles on the new site.