Then I get the call: their archive isn't working, can I investigate. Their archive is a web application frontend to an IMAP server storing archived email data. Simple, effective, and as of last week, broken.

Dig, dig, Google, dig.

Eventually I find the culprit: Torque was depending on an obscure logging framework, which was in turn depending transitively on an obscure incomplete implementation of javamail called geronimo-spec-javamail. This was pulled in alongside javamail as shipped by Sun.

Two competing incompatible implementations of javamail in the same application in the world of Java == fail.

Fast forward a week. Another application that is up and running fine is suddenly reported as not working. All the application does is create an email with a velocity template, and send the mail. That's it. But Velocity depends transitively on an obscure logging framework, which recently decided for no clear reason would not longer work from within a web application.

When you spend more time tracking down obscure sudden failure cases than you do producing actual code, you know you've reached the tipping point of failure.

Java logging frameworks must die.

No, you don't.

Your code needs to throw properly formatted, meaningful exceptions. And your code needs to catch these exceptions as appropriate, and act properly on the failure cases. And that is it.

Yes, there are reasons to log. If you need to log each hit to a webserver, a log makes perfect sense. If you are saving performance related data at regular intervals, that makes sense. But if you are spitting out random obscure unintelligible data at points buried within your code, your logs make no sense, and you're wasting your time, and your client's money.

Intertwined with the misguided need for logging is the typical Java practice of keeping unstructured property files. What's wrong with unstructured property files? Try make a spelling mistake in one.

It doesn't work. It should work. But it doesn't. Desperately you enable every bit of logging you can possibly find, looking for a clue in the reams and reams of unintelligible rubbish streaming past as to what you did wrong. Time ticks past, deadline pressure looms, manhours are burned, all for a spelling mistake that made your setting cease to exist.

There is an irony in that a language with such a rich history of structure should have so much code layered on top of it whose sole purpose is to rip out that structure. Unstructured property files. Unstructured beans produced by Spring. Unstructured logging.

All of this ill-discipline is like attaching a bungee cord around one's waist and attempting to run. You get going quickly, but each step becomes harder and harder. Eventually you stumble and fall backwards, and you are doomed to never get anywhere.

The architects of Java have spent a decade and a half relentlessly adding, adding, adding to Java. Java needs a brutal spring clean if it is to survive as a language, and I believe that the java logging frameworks should go first.

Or more specifically, I didn't see the disclaimer, and that makes it the best disclaimer ever.

In May.

Better late than never.

Any device whose "on" switch doesn't work, is a broken device indeed.

But this alone doesn't make it worthy of mention on Stupid. That honour is bestowed on the following advice:

Most new phones allow charging with the USB cable. With some phones, you also have the option to select whether you want to allow USB charging. If you're trying to charge with USB, make sure that your phone supports USB charging and that the option is switched on.

You have a phone with a potentially flat or faulty battery that won't turn on. You have a USB cable, but you cannot be sure that the USB cable is actually charging the phone, because the option to be sure is only accessible when the phone is on.

Genius.

Ever had one of those days when you need to install a software package, and within minutes of the download, your blood is boiling so much that you want to hurl your monitor out of the window?

If you have, chances are the software you are using has failed the Fuse Test, and chances are good that you will end up throwing the software out in disgust and trying something else.

So, software developers: how do you avoid lighting the fuse and giving your end users a heart attack? Read and learn.

Let us start with installation. Download the version for MacOSX, which downloads as a standard DMG file, a disk image format common with MacOSX software installation. So far, pretty standard stuff. Mount the image, and copy the Spark package across to the Applications folder. Plain sailing so far. Run the application, and you get an opening login screen, and here is where the problems start.

You are asked to provide a username, a password, and a server. Username and password are not a problem, but the server? Here there are options. Do they want the name of the server only? If so, How do I express the port number (which in this case is not standard), or the fact that the server might be an SSL server? Do I represent the server as a servername and port separated by a colon? Or do I express the server as a URL? No idea, but there is a potential solution to this: the "accounts" button.

Accounts gives me the same options: username / password / server. There is no option to specify the port, and no option to turn enable or disable SSL, so the most logical solution is to try the URL form, and I try xmpp://server:61222. Once filled in, I click on "create account", and a "busy" status bar appears to show the software is thinking about something.

Hang on a second. Why is the software thinking about something? Have I typed something in incorrectly? Let me click the cancel button and try again. Oops, no cancel button, just a button that says "close" which closes the window and loses everything I have entered.

@$&#*(!

At this point, the software fails the fuse test.

Of course the software developer is probably picking holes in the above story already. "It says 'Create account', and that means it is trying to create the account on the server!". Are you sure? Does it not perhaps mean to create an account entry within the client? After all, the button I pressed to get to this dialog was called "Accounts", and that implies more than one.

The reason this makes no sense is the precedent established by other similar software packages. Apple's iChat application contains a button called "Accounts", which leads you to a process where you express the username, the password, and the server for each chat account you plan to connect to.

If your software works differently to other packages out there, make this fact very clear to your end users.

Of course the software developer is not obligated to implement the same features as found in other applications. However the developer is obliged to make it very clear exactly what the end user is expected to do, and this is achieved using explanatory text within the dialog boxes. In the case of Spark, there is no explanatory text at all apart from a vague "create a new chat account". Does this mean create a new chat account on the server you tried to connect to, or does it mean create a new chat account within the list of accounts on the client?

Throw your end users a bone: Use plain text to explain to the user what they should be expected to do.

While I type this, Spark is still "busy" trying to "create account". By this point you would have expected a timeout of some kind, or some kind of clue that what you attempted was not successful. No such luck. So I click on "close" and try an alternative approach.

Going back to the main login screen, I try and enter the username, password, and XMPP URL of the server, and I click "login". Instantaneously, I receive the message "invalid username or password". That is an immediate clue that something further is broken - neither the net connection, nor the XMPP server, nor the LDAP server that backs everything, is that fast. This is evidence of further breakage:

Handle your exceptions!

Confirmation of the breakage comes about when you change the name of the server from an XMPP URL to just the name and port of the server, separated by a colon. Once this change is made, Spark successfully logs into the server. What this means is that when the name of the server is incorrect, as the servername would be if an URL was provided instead of a DNS name, the message "Invalid username or password" is shown, instead of the real error, "Servername does not exist".

This shows that the developer has interpreted any and all connection errors as the single catchall and highly inaccurate message "Invalid username or password".

Don't send users on wild goose chases by giving them vague or misleading error messages!

No doubt at this point the software developer has pointed out that old chestnut: RTFM, or Read The Manual. It is off to the website to check out the "documentation" section, and see in more detail just what Spark can or cannot do. As of this writing that means here, where the end user is offered the option to read the "Readme and License" or the "Changelog". No manual. Ok, let's try the README file. It boils down to the sentence "Further information can be found on the Spark website", which is a bizarre claim, I am on the Spark website already!

As a designer of software myself, it is only fair that I tell the people who wrote Spark as to the various usability problems that I as an end user have encountered in the software. After all, it could be that they simply don't know of the problems their end users face. So I register with their JIRA installation, only to discover I as an end user cannot add new issues to their issue tracking system.

At this point the package is doomed. If the simple task of logging in is too much for the package to handle, I have no faith that the actual chat is likely to work without the wasting of time and additional elevated blood pressure.

Move Spark to Trash.

Problem solved.

Developers: if you want to avoid having your pride and joy unceremoniously dumped into the trash, then be considerate towards your end users. Your end users are the reason your software exists: be kind to them, and they will be kind to you by using and buying support for your software.

However Zoom airlines goes to some considerable trouble to ensure that customer service is as far removed from the customer as humanly possible.

Do yourself a favour: Don't ever put yourself in a position where you need to contact Zoom Airlines customer support. The easiest way to do that, is to just not book the ticket in the first place.

Here you encounter your first problem - you need a username and password to continue. If you don't have a username and password, you are doomed to their contact us page. If you do have a username and password it is a moot point - the login form is incorrectly flagged as being non-editable, and the login button is missing, making login impossible.

So you head off to the phone, and use one of the contact details you find in their contact us section.

It however quickly becomes apparent that Zoom airlines offers reservations, flight information, and lost luggage options only. If you have any other business with the airline, your call is not welcome.

So, trying the reservations people, it was ascertained that:

- Despite capturing the full name and contact details of the person who made the booking and the payment (me), that person is not allowed to gain access to information about the booking.

- The service agent refused to put the call through to a manager.

- The service agent refused to divulge details of Zoom's webmaster, to which the login problems could be reported, confidently and repeatedly asserting that because the website worked for them, the website should therefore automatically work for everybody else.

- The service agent refused to identify which web browser she was using, citing the "data protection act".

Getting nowhere with this service agent, next stop was the reservations line in Canada. The question this time round was what the contact details of customer services were.

It turns out customer service goes out of its way to ensure that you cannot contact them via email, nor can you contact them by phone. In this age of the internet, your options are limited to fax, or by post, to an address not listed on their website.

If you have a complaint with Zoom in the UK, you had better be patient, and you can post your letters to:

Zoom Airlines
Suite 3-4 Skypark 1
8 Elliot Place
Glasgow
G38 EP
United Kingdom

Or save yourself the trouble and just don't fly Zoom.

If you want such a day, try and get an Eclipse RCP application to deploy via Java Web Start.

If you would like to know all the reasons why your attempt to get this working will fail, read on.

Eclipse seems to come to the party with a special launcher capable of being cranked up using Java Web Start. Sounds promising, until you try to use it.

java.lang.NullPointerException
at java.util.Hashtable.put(Unknown Source)
at org.eclipse.equinox.launcher.WebStartMain.basicRun(WebStartMain.java:77)
at org.eclipse.equinox.launcher.Main.run(Main.java:1173)
at org.eclipse.equinox.launcher.WebStartMain.main(WebStartMain.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Launcher.java:1205)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1151)
at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:998)
at com.sun.javaws.Launcher.run(Launcher.java:105)
at java.lang.Thread.run(Unknown Source)


The cause is this quality piece of code. Notice the unhandled error condition:

String fwkURL = searchFor(framework, null);
if (fwkURL == null) {
//MESSAGE CAN"T FIND THE FWK
}
allBundles.remove(framework);
System.getProperties().put(PROP_FRAMEWORK, fwkURL);


Google finds lots of people asking about the problem. Nobody yet has posted a solution.

Of course the solution is to find this bug and fix it, but Eclipse won't let you get away with that without a fight.

Java Web Start has a strong security model. In order for the application to be allowed any kind of meaningful access to the disk or network, the code needs to be signed by a trusted code signing certificate. Responsible stuff. If it worked.

The guys at Eclipse have included corrupted digital signatures in their released jars in Eclipse v3.3. The error you get is this:

java.lang.SecurityException: Invalid signature file digest for Manifest main attributes

The guys at Sun have stepped in to ensure failure by forgetting to include functionality into the jarsigner tool to either replace or remove a signature.

So even if you could find a solution to the Java Web Start NullPointerException, you wouldn't get that far because the lack of signed jars would sink you long before that.

For a project that has such a strong pedigree, this amounts to some seriously bumbling on the part of the Eclipse guys. Codesigning is a big deal: for a major release to be shipped with broken signatures, and for those broken signatures to remain unfixed in subsequent point releases amounts to a serious failure of oversight.

If you want to get this to work, make sure some of these bugs get fixed:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=213715
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213698
https://bugs.eclipse.org/bugs/show_bug.cgi?id=169691
http://forum.java.sun.com/thread.jspa?threadID=5140289&tstart=615

The installer contains a fatal flaw: it requires direct access to the internet, with no support for a proxy, before it will work properly. That pretty much renders the software useless in virtually all practical environments.

Installers that download from the net are by and large an exercise in making a simple problem into an unnecessarily complicated one, and are generally just dumb. If you are writing an installer, and you want your installer to access the net, please just don't, for sake of the rest of us with real work to do.

I have tried to come up with a number of analogies to explain what is wrong with relying purely on a firewall, but none explains it so clearly as this image that come through my inbox a day or two ago.

(This image arrived with no credit attached, if it is yours, add a comment so it can be credited properly)

I don't know about you, but an advert for an Experian credit report is not news.

Is this the end of the clean simple interface for facebook?

Congratulations KLM for achieving this feat in July.

The awarding of the Hat Trick is only given if the airline is responsible for the initial flight being late. Air France would have achieved the same feat in June, but their problems were the fault of weather, so it doesn't count.

Oh the joy.

In line with our policy of continuous improvement, please note that the SARS eFiling service will be unavailable during the following times:

Whilst the times above have been set aside, we will endeavor to minimise the offline duration as much as possible. We apologise for any inconvenience you may experience.

Monthend.

Great time for downtime guys.

iTunes Plus offers higher quality encoded digital music, with no DRM, for an extra 30c per song.

Paid the extra money within a heartbeat, and the DRM worries are a thing of the past.

I can now play the music I paid for.

Brand new Apple TV, repeat the installation process, and what do you know? The new one is as broken as the old one was.

It got better.

While at the Apple Store, they sold me an AppleCare Protection Plan, which my pinky toe told me I am going to need. According to the instructions, you have to register your AppleCare online.

No worries, go to http://www.apple.com/uk/support/register and follow the prompts.

One of the prompts asks you for the country - the UK, where the AppleCare Protection Plan was bought.

What follows is the message "Our records indicate that the service you are trying to use is not available in your location".

Or in English, "Our support service is broken, just like our Apple TV".

So why the rant?

Apple represented a dying breed of companies who believed that technology is an enabling thing that makes people's lives easier. But now it seems they are falling into the same trap of general sloppiness that blights the computer industry and the internet the world over.

I've seen the future, and it no longer works.