Symphonious

I've been trying to get the dates in my comments feed to show up correctly with all the right time zone stuff and so on, but even though I'm pretty certain the feed is reporting the right time and time zone, NetNewsWire seems convinced that the comment was made in the future. So can someone confirm for me that the date 2006-10-25T20:28:58+10:00 refers to 8:28pm (and 58 seconds) on the 25th of October 2006 in a time zone that is +10 hours from GMT. Thus if my time zone is also +10 hours from GMT the date should mean 8:28pm local time on the 25th of October 2006.

Why is it that NetNewsWire reports the entry's date as the 26th of October 2006?

UPDATE: The actual feed has a plus character before the 10:00 as required by the RFC. Something along the chain in WordPress stripped it out. The feed validator says the feed is correct.

UPDATE 2: This is confirmed as a NetNewsWire bug. Sigh.

I'm in the middle of doing platform testing for EditLive! 6.0 which involves setting up and testing a huge array of OS, browser and JVM combinations to run through and manually verify that everything is working as it should be. Normally this is hard enough to do, but at the moment it seems every tech company has either just released a new version or is about to. We've got FireFox 2.0, IE 7, Windows Vista beta, OS X Leopard beta, Java 6 beta, OS X Java 6 beta, Office 2007 beta and who knows what Linux and Solaris is going to do to me.

To keep things moving, you wind up installing multiple things on the fly. Right now I have an intel Mac Mini installing OS X Leopard, Vista installing on a VM image1, and my laptop testing out FireFox 2.02. There are way too many large installers flying around the network and pretty much all available hard drives are pegged for one reason or another.

Speaking of FireFox 2.0 - it's the latest member of my OS X installer hall of shame. This is what FireFox's dmg comes up looking like:

If only that picture of the applications folder was actually a link to the folder it would be perfect. Instead it gives the impression that you should drag the big fox on to the picture of the applications folder. Sigh. On the plus side, they don't seem to have broken anything we depend on. We've obviously been testing out the betas prior to know, but you never know what's going to change when the final release comes out. We spent quite a bit of time trying to find work arounds to bugs in IE 7 that caused problems with our Windows only editor only to find that when the final release came out it all worked perfectly. It's always better when it works that way though - every so often you get a bug introduced in the final release version and it blind sides you.

Anyway, installs are starting to finish again and FireFox 2.0 on Mac seems to be working out pretty well.

1 - You have no idea how slow that is…↩

2 - in fact, this post is a part of that testing…↩

The back button has been a great challenge for a lot of modern web applications and WYSIWYG editors are certainly no exception. Way back before I can remember, someone had the fantastic idea of preserving content entered into text fields and restoring it if the user hit the back button to return to the page. Unfortunately, with the advent of WYSIWYG editors, this was generally lost because the browser reruns the JavaScript in the page again, providing no indication that the user was returning to the page. I could be wrong, and I'd love to hear of other examples, but I don't believe there is a WYSIWYG editors available today that preserves content when the user hits the back button. I find it somewhat interesting that despite the huge amount of user angst this causes1, there doesn't seem to be a lot of interest in solving the problem.

Similarly interesting is the Ephox engineering team's fascination with monkeys.

One night I must have been pondering this2 before falling asleep because in the middle of the night I awoke with a solution for this perplexing back button issue racing through my mind. An hour or so working on a proof of concept and it was clear that it really could work. Andy came along and worked out all the details3, refining the raw concepts in some pretty neat ways and generally weaving the code magic that he does and now EditLive! is the first4 WYSIWYG editor that works correctly with the back button5. You can check it on in the EditLive! 6.0 beta.

While track changes gets all the fanfare, this has to be my favorite feature that we've ever added to EditLive! I know longer live in fear of accidentally clicking a link or hitting backspace when the editor doesn't have focus6.

You may be wondering what this has to do with monkeys. It turns out that while I was explaining this great idea to Brett, I started by mentioning that I was dreaming. Brett didn't care about what the idea was, he just wanted to know if there was a monkey in the dream. Naturally I said there was and from then on the monkey got all the credit for coming up with the back button solution and any other great idea the engineering team has had. Stupid monkey…

In the end, I think what I really like about this feature is that users will never notice it - it will save them from experiencing major data loss countless times and they won't even know. It will just work the way they expect it to. Could there be a better user interface for a feature?

1 - not least of all to me considering how much time I spend using WYSIWYG editors in a browser↩

2 - the back button problem, not the fascination with monkeys↩

3 - like how to make it work in practice on 4 different OS's, and who knows how many browsers↩

4 - at least that we know of, let me know if you know of another one↩

5 - it also works with the forward button incidentally.↩

6 - who decided backspace should be a shortcut for back in browsers anyway??↩

Since cruise control doesn't use a bug tracker - it only provides email lists and I don't currently have access to my email - I'll just report this bug here and maybe someday along the way they'll discover it and fix the problem.

Anyway, my beef is that the cruisecontrol webapp doesn't work with lynx because it uses a ridiculous JavaScript system to trigger new builds. Now, normally I don't use lynx as a browser because it tends to be pretty limited, but it would be nice to be able to trigger a build remotely without having to manually parse HTML files and find the URL to ping to get a build to start. At the time I was SSH'd through two machines and then using Hamachi to get access to the actual build machine so it was a little bit difficult to use a standard browser at a reasonable speed.

Sigh.

I haven't fully investigated all the details and combinations, but it appears that if you use the cache_archive_ex parameter to specify the Jars for an applet and at least one of them has a specified version, any that don't have a version get ignored. So for instance, if you have cache_archive_ex="editlivejava.jar;6.0.0.1,footnotes.jar" editlivejava.jar will be downloaded and used correctly, but footnotes.jar will be ignored.

Additionally, any jars specified in the cache_archive parameter get ignored (probably unless they have a matching version in the cache_version parameter).

If you want to have a mix of versioned jars and unversioned jars, you need to put the versioned jars into the cache_archive_ex parameter, and the unversioned jars into the archive parameter. Then they all seem to come through.

Apologies to any Ephox employees who tried to felt the effects of this today on one of our internal systems - it caused any advanced API plugins to stop working. A new build should be pushed out soon that fixes it.