Symphonious

It seems that the world of Java on Mac is always full of drama and gnashing of teeth and Chris Adamson has just the article to really kick it into full gear: Mustang for Mac PPC… any point now?

Sadly, I'm inclined to believe that Chris may well be right - the Java 1.6 release for PPC is likely to be a less than wonderful release as Apple focuses it's efforts on the Intel release. It's a given that the Intel release will be better than the PPC release just due to the fact that they now get all Sun's optimizations for free.

The good news for Mac Java developers is that this means that Java on Intel Mac is going to be pretty awesome. Apple can now devote most of their development time to polishing the Mac specific features and optimizing the OS specific bottle-necks. The Java 1.5 release on Intel is already a lot more comparable to performance of Java on Windows - partly from the optimizations they get from Sun and partly just because of the faster chips. Overall, I'm really looking forward to seeing what Apple's Mustang release is like - I expect it to be pretty impressive, and that makes a nice change when talking about Apple's Java releases.

Jason Calacanis' entry on Wikipedia considering adding a WYSIWYG editor to make it easier for people to contribute strikes a chord close to my heart. The argument that a WYSIWYG editor will cause more work for administrators is quite valid - making it easier for people to contribute will mean more contributions that need to be reviewed and checked. On the other hand though, the benefit of a WYSIWYG editor isn't just that more people will contribute, but that domain experts in fields other than computing will be able to and be more inclined to contribute. For Wikipedia, that's a pretty huge benefit - the people who know most about a subject will be more likely to actually be writing the Wikipedia article on that subject.

There is a proposal to do a "semi-WYSI" that is what will probably come to Wikipedia. A "semi-WYSI" would have only a handful of features and it would translate the edited text into Wiki markup (as opposed to HTML) for users.

A semi-WYSI, or rather a WYSIWYG editor configured to allow just the operations that add value and not those that make articles overly complex, is an excellent compromise between the two viewpoints. Even better, it actually makes it easier for people to learn to use the WYSIWYG editor and get to contributing. Less time is wasted on formatting and more on writing great content. That said, there's no reason this couldn't be done with HTML instead of wiki syntax, and the HTML editors are generally better than wiki syntax editors. It's not like it's hard to convert wiki syntax to HTML…

It's census time in Australia and for the first time this year, you can complete the census online. Surprisingly, the eCensus is actually very well done. It supports Windows 95 and above and Mac OS 8.5 and above on IE, Netscape or Firefox - and that's just the official specs. I didn't think to run it through the HTML validator but I'd assume it would work quite well in pretty much any reasonably modern browser and a whole bunch of not so modern browsers.

What's more, the form was simple, straight-forward and had a clean, clear design. All up it took me about 10 minutes to complete the census online. Sadly, I still need to fight the Australian Tax Office's Windows-only, fully standalone eTax program, for which none of the above praise applies.

A while back it was pointed out that the cool little footnotes plugin I wrote was always using the same ID names to link back and forth. It incremented the number of each footnote in a post, but started again from 1 for the next post. The problem with this of course is that on the main page all the posts are combined together and the footnote links wind up jumping to the wrong place.

Fortunately, I managed to convince Doug1 that it was a worth project and yesterday he fixed the problem for me. Now the footnote IDs have the current milliseconds appended which makes them "unique enough". I can't really see me, as the only author of this blog, adding two footnotes to different posts at the exact same millisecond.

Sadly, I still need to fight WordPress to stop it converting the links to be absolute so that they work in newsreaders too.

1 - Who doesn't blog often enough↩

I just stumbled across something interesting that I probably should have realized before. With TDD, the first thing you should do when you get assigned a bug to fix is write a test that reproduces it. This morning I was good and did just that, but surprisingly the test passed.

Now normally when your test passes straight off, it means you didn't write it correctly and you need to fix the test. In this case though I could confirm manually that the bug simply didn't happen - a classic works for me. Drop back into bugzilla and mark the bug WFM and I suddenly realized I could prove that it works correctly by pointing to the test.

So now, we have a closed bug and a passing test that will make sure it never comes back. The normal inclination I have is that the test passed straight off so it didn't have value and shouldn't be committed, but that's not true. Writing a new test for an area we didn't have a clear acceptance test1 for before is a really good thing and should be preserved. Better yet, I can point to that test in the bugzilla case and if someone disagrees they can change the test to show the problem and reopen the bug.

1 - I'd written the acceptance test first to verify the problem but didn't have a need to drill down to integration and atomic tests.↩