Coding in an absurd reality

Mensen hebben een slechte intuïtie voor wanneer iets 'toevallig' is. Ik kan er honderden voorbeelden van bedenken, maar eentje uit persoonlijke ervaring spreekt waarschijnlijk meer tot de verbeelding.

Afgelopen vrijdag belde mijn vriendin een autoverhuurder om een Ford Transit te huren, om zaterdag haar spullen van haar studentenkamer naar mijn appartement te verhuizen. De transportboer in kwestie had er geen meer, maar had er nog wel een die een slagje groter (en duurder) was. Eerst maar de buurman gebeld, die helaas ook net de laatste 6 kuubs Transit de deur uit gedaan had. De eerste uitlener van ingeblikte verbrandingsmotoren weer gebeld en de groter versie gehuurd, spullen vlot verhuisd en tadaa, het samenwonen is een feit.

Dat is echter bijzaak. Het interessante is dat mijn vriendin opmerkte: wel toevallig, dat ze allebei net die Transit's niet meer hebben. Toen dacht ik: nee, dat is helemaal niet toevallig. Elkaar beconcurrerende autoverhuurders die goed bezig zijn, zullen samen precies zoveel wagens hebben als ze kunnen verhuren. Als je vrijdag belt en ze hebben nog ruime keus, dan zou ik snel een efficiënter verhuurbedrijf in de buurt beginnen.

De nog interessantere vervolgvraag is: waarom wekken dit soort situaties een gevoel van 'toevalligheid' op? Waarom komt het gevoel boven dat de situatie onwaarschijnlijk is en dat het universum samenspant om je te begunstigen of te benadelen? Is het omdat de patroonherkennende machinerie in ons hoofd gewoon niet verwacht dat alles in zo'n simpele, elegante verklaring samenvalt? Dat het berekend is op de chaos van de jacht, van het overleven in een natuur met ontzettend veel onvoorspelbare factoren en dat het gewoon niet is voorbereid op de onszelf begunstigende structuur die millenialang vooruitziend samenleven tot stand heeft gebracht?

A thorn in the side of every GWT developer must be the ridiculous URLs it produces. Please, come and visit our wonderful webapp at ... very attractive... Of course, you can have http://company.com/thisapp/ redirect there, but still.

Fortunately, there is an easy way to shorten the URL, as explained in this not so aptly named thread in the Google Groups group on GWT. If you choose a decent module name, you end up with
http://company.com/module/Module.html, which is acceptable.

If you use the maven-gwt plugin to build your project, you need to modify both the compile targets and the run target to

code:

1 2 3 4

<compileTargets> <value>Module</value> </compileTargets> <runTarget>Module/Module.html</runTarget>

Today I was researching the obstacles I would encounter while upgrading the Resin Application Server from 2.1 to 3.1. One of the things that came up was that OpenSSL support is no longer supported in the open source version: you would have to buy a license to enable the JNI bindings to OpenSSL.

However, JSSE is also supported as the SSL connection handler, so I decided to find out what was involved in switching from OpenSSL to JSSE. That proved to be quite easy, with a Java 6 JDK that already includes a configured JSSE library. The largest problem was converting the certificate + key to a Java keystore. For everyone that may one day have to solve this problem:

First put the certificate and the key in a pkcs12 keystore:

code:

1	openssl pkcs12 -export -out dev.pkcs12 -in dev.crt -inkey dev.key

then convert the keystore to a JKS keystore, using the Java keytool:

code:

1 2	keytool -importkeystore -srckeystore dev.pkcs12 -srcstoretype PKCS12 -destkeystore dev.keystore

This example involves a self-signed certificate; if you need to include CA certificaties or certificate chains, the process is slightly more complicated, but probably not very, as you can use openssl to perform all the hard steps. If I encounter any problems when I do that, I will let you know .

On a sidenote: Java keystores are terrible things and I dread the moments when I discover they are once again inevitable in reaching a certain goal.

I needed to parse some text that looked like

code:

1 2 3 4 5 6 7

fieldname: value anotherfieldname: anothervalue etc: somemore ---------- repeatedfieldname: newvalue mayalsobeanotherfieldname: withanothervalue ==========

The regex previously used was

with singleline and multiline flags enabled (using the Jakarta Oro PCRE compatible library).

However, it was found that some customers think their middle name is ' ----------' (even though there isn't a form anywhere on the website where one can select that), which breaks the code splitting the text above. However, a simple solution exists: to match only ten dashes or equal signs on a single line, while still capturing the groups, you can use

I think moving a single character four places is quite an elegant bugfix

Last week it struck me that I've never really used exceptions in Java properly, despite having written thousands of lines of Java code over the last three years. Of course I have written plenty of try-catch blocks, logged, chained and wrapped exceptions in my own custom exceptions, but ultimately, I hardly ever use them like they were intended: as a replacement for result codes and a means to easily propagate 'failures' up the stack. Instead of using exceptions, I often use result objects that simply wrap the actual result object, together with a boolean indicating whether the call was succesfull and an optional failureMessage.

The question that immediately followed is: why? Why has it taken me so long to realize the way in which exceptions are meant to be used? I think the problem is twofold:

• The name feels wrong and
• Nonlocal behaviour is hard to grasp

The first one is simply this: when a method fails, this often isn't exceptional. For instance, someone requests the order with ID 1529, but no order with that ID exists. The method fails and I could throw an 'OrderDoesNotExistException', but that just feels wrong, because the situation simply isn't exceptional. I think this can be mitigated by simply changing the name of such a custom Exception to 'OrderDoesNotExistFailure' or the even simpler 'OrderDoesNotExist'.

The second is a more subtle problem, which I think has to do with the fact that code is easier to understand when you handle the result of a method call immediately, even if that consists only of 'inspect the boolean in the wrapped object and branch'. When throwing an exception, the flow continues somewhere far from the original method call and this is less intuitieve. However, one can develop an intuition for it, if one properly designs the use of exceptions beforehand. And that is the ultimate problem: I've never thought deeply enough about the way one should/could use exceptions.