A huge amount of the items that flow through my news reader come from Robert Scoble’s shared items feed. Most I skip, but there’s enough good stuff in there that makes it well worth reading. It keeps me abreast of a much wider range of topics than I would normally read.

The trouble is, Robert doesn’t seem to have as low a tolerance level for crap in feeds that I do. Generally I’ll unsubscribe from a feed if it has:

Technology is a funny thing – we spend so much time and effort trying to make things as simple and efficient as possible for our users that we sometimes lose track of the big picture and wind up making things worse. This is particularly a problem when developing components for other’s to intgrate, rather than a product that ships directly to end users. When another developer is between you and the end user a few fairly unique dynamics come into play:

I’ve been keeping an eye on OpenSocial since it’s initial annoucement with some interest but also a healthy dose of skepticism. I’m still wondering why anyone would want to support open social. It doesn’t give you any integration between systems – all it provides is potential access to the OpenSocial widgets that 3rd party developers make.

Now, if we look at the 3rd party widgets from FaceBook you’d be doing your users a great favor by not supporting OpenSocial. I’m yet to find any FaceBook “application” (I use the term with great disdain) that doesn’t do whatever it takes to sign up new users, usability and user experience be damned.

Maybe I’m just a spoil sport but I think project code names are the most ridiculous concept. I’ve never seen a code name help clarify things – they only ever cause confusion. Compare:

Hey Joe, how’s the schedule looking for futzbist?

with:

Hey Joe, how’s the schedule looking for the next EditLive! release?

The argument is of course that everyone gets to know the project code name so it’s a nice shorthand for the project – but for how long do they remember them? How far back can you name Java, Ubuntu, Debian or even OS X releases? Did Puma come before or after Cheetah? What was the Tiger release? And what’s in the stray alley cat release?

Is it just me (quite possible) or is the standard JSON validator for JavaScript unable to handle quotes (") in strings? Specifically, shouldn’t the JSON below be considered valid?

{“name”:"""}

It throws a parseJSON error when run through the validator but executes perfectly as JavaScript and seems to match the specification for strings in JSON. It’s frustrating because even though the data is coming straight from the server so it’s as trustworthy as it can get, I still think it’s incredibly poor form to execute data without first validating it.

With all the complaining about Apple not having shipped JDK 6 with Leopard it’s nice that someone has actually stopped whining and started coding. So kudos to Landon Fuller for actually doing something useful. Of course, he hasn’t really gotten anywhere because porting Java is an awful lot of work, but if nothing else he’ll understand why it takes Apple so long.

It also means we can start the timer to see if the open source model can actually bring Java 6 to OS X faster than Apple can.

For those who both use EditLive! and were very quick to upgrade to Leopard, you might want to grab the latest early access build of EditLive! With old builds on Tiger, our toolbar didn’t respond well to the darker background color:

(Click for full size version)

Fortunately, Apple introduced some new rendering styles for buttons with Leopard that we could leverage to get a much nicer, much more OS X look:

The rumors of Java 5 being horribly broken beyond all usability on Leopard are, quite frankly, bullshit. It’s faster, has better integration with the OS, the Aqua L&F is significantly improved, it has full support for 64 bit and a huge raft of bug fixes and miscellaneous improvements. Everyone’s pointing to an uninformed rant on JavaLobby which as it’s key example actually highlights a major improvement to the Aqua L&F – the JOptionPane icons should use the application icon, not some obscure artwork that’s not used anywhere else in the system. The new dialogs actually allow you to look more like native app, not less. It’s even explained in the release notes – heck, the old implementation was probably reported as a bug against Tiger.

My first thought when I heard that the Leopard blue screens being were by Unsanity’s APE was “and that’s why only fools use hacks like that”. So it was with some surprise that I read John Gruber’s article on the issue this morning and discovered that the Logitech driver installs APE. Moments before I’d installed the Logitech driver…

Turns out my decision to do an archive and install to get rid of left over cruft from all the software that I’ve tried was a pretty wise one – I’ve had the Logitech drivers installed for quite some time, so most likely I would have run into the “blue screen of foolishness”.

I was silly enough to open my work email this morning, only to discover that the Apple Java-Dev list had broken out into the age old Java on OS X argument. First up here’s what people have reported1:

• Java 6 is not included with Leopard.
• The previous Java 6 DP which was pulled from ADC a while back does not run on Leopard.
• Upgrading to Leopard from a system with the Java 6 DP installed can cause some frustrating issues with switching Java versions.
• Apparently Java 5 is much faster on Leopard.
• Java 5 looks different with quite a few tweaks to the Aqua L&F.
• Some fonts don’t look right in Java 5 on Leopard because it uses the Sun 2D graphics pipeline instead of the Quartz pipeline. The Sun 2D pipeline doesn’t support sub-pixel antialiasing. You can override the default and there’s a few other conditions that trigger the Quartz pipeline to be used by default.
• Java 5 supports 64bit on Intel Core 2s (but not PPC). There seemed to be some problem with it when using the Java tools in /usr/bin though – can’t say I followed that discussion too carefully.
• Lots of documentation is coming, but not much is available yet.

Pretty sure that’s the Java on Leopard wrap up, the other 150 emails to the list were just the usual gnashing of teeth about Apple abandoning Java and how Apple will lose so much business if they don’t get Java 6 out yesterday etc etc etc. Of course, Apple’s doing better than it ever has before and JavaOne was full of people using Macs – without Java 6 – so it would seem it’s all just talk and insignificant numbers of people are actually leaving OS X. As a fresh twist, this time round people are talking of porting OpenJDK to OS X themselves and finally freeing themselves from the evil clutches of Apple! Apparently no one has told them that Java 6 isn’t available from OpenJDK either – it will become Java 7 and is quite some way from that yet. I think it’s a safe bet that Apple will have Java 6 out long before even a reasonable uncertified port of OpenJDK is available for OS X.

I’m writing up three proposals for the O’Reilly Web 2.0 conference. I think the content is compelling enough but I’m not overly hopeful that any will be accepted because it turns out I really struggle with writing session abstracts. This is actually the first conference I’ve submitted proposals too so hopefully I’ll get better (and faster!) at it with a bit more practice. In a lot of ways I’m actually more interested in just getting practice at submitting proposals than actual speaking at the conference – the timing of the conference is bad, but can be worked around.

If you’re using the scp or ssh tasks with ant, you may run into a problem where part way during the upload or never disconnecting after the command completes for the ssh task. There are a couple of possible causes:

1. The scp problem is almost certainly caused by using ant 1.7.0 or below and jsch 0.1.30 or above. You could upgrade to the latest nightly of ant1 but it’s probably easier to just drop back to jsch 0.1.29 which is what ant was developed against and works nicely. Bug 41090 contains the gory details.
2. If the command you’re executing with the ssh task starts a background service or otherwise leaves a process running, that may be the cause of the problem. You can add ‘shopt -s huponexit’ to your /etc/profile, .bashrc or somewhere like that. I must admit, I’m somewhat vague on the exact details of what that does but the basic idea seems to be to signal any background processes that bash is exiting and then not wait for them to complete (which allows your ssh connection to close). If you’re starting a server they’ll probably ignore the hup signal it sends and if not, use the nohup command.

Hopefully that will be the last I’ll see of that issue.