Wednesday 23 September 2009

Banking fail (+ cell phone rant)

Disclaimer: I'm going to go off on a rant that will at first have nothing to do with banks, but bear with me, I'll get there in the end.

First off, just to make something clear: I hate and despise cell phones. They're the bane of the 21st century. Everybody seems to have one of these things, sometimes even more than one, and they seem to be using it all the time, in every annoying way possible. And don't get me started on the annoying ringtones. Oh god, the ringtones, they make me want to punch someone in the face.

I could keep on ranting about it for pages and pages, but I have to get to the banks sometime before the end of the month.

Even though most of the people I know are aware of the fact that I loathe cell phones, my current employer still wanted me to have a cell phone so I would be reachable. I don't want to be reachable. If you want to contact me, send me an email. I really like the asynchronous nature of email against the synchronous nature of cell phones. So I said - give me a cell phone and pay for a subscription - hoping that that would make them back out. Unfortunately that plan kinda backfired and I now am the proud owner of a company cell phone.

The subscription they provide allows for a certain fixed amount of call minutes for both professional and personal use. Everything above that amount needs to be payed by the employee. Because I tend to forget the cell phone (and if I haven't forgotten it, it probably isn't charged) I've consistently had a monthly amount due of 0 euros. This month was the first time that I actually needed to pay for going over the fixed amount. I had to pay the incredible amount of 43 eurocents!

So I opened up my online banking application, proceeded to fill in all the required fields and pressed sent. And what do I get: the amount you entered is too low! Oh please, are you bloody kidding me? They have a fully ajax-enabled form, but they can't warn me that the amount is too low when I fill in that field, which incidentally is the first field on the bloody form? I don't know why there should even be a threshold value, I'm doing all the work and everything is handled electronically. I guess it would probably be possible to do the transfer if I'd physically go to the bank and ask a teller to do it, but that would be an even bigger waste of time and money for all parties involved.

So now I'm sitting here with a bill for 43 eurocents (paper and postage alone probably costs more) and my bank won't let me pay it because the amount is too low! It's like I'm trapped in a catch-22. I've explained my quandary to the HR manager and she's going to try and find a solution with the telecom provider. I wonder what it will be.

Canon MEAP engrish: I can has fail?

Sometimes it shows that Canon MEAP is made in Japan. So every now and then I get to enjoy some prime examples of engrish. Last week I was experimenting with MEAP IMI, got a stacktrace and encountered something that made me go WTF?

com.canon.meap.imi.OperationFailureException: This bundle has initialize.
    at com.canon.meap.csee.imi.IMIImpl.initialize(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.canon.meap.imi.IMI.initialize(Unknown Source)
    at be.aca.wizard.applet.AcaWizardApplet.start(Unknown Source)
    at com.canon.meap.csee.avs.AppletEventDispatcher.run(Unknown Source)
    at java.lang.Thread.startup(Unknown Source)
   
I'm still trying to figure out what the exception exactly means: already initialized, not correctly initialized, ...

Sunday 20 September 2009

Error message fail!

I just tried to watch the video of Drew Barrymore in Jay Leno's Reasonably-Priced Electric Ford Focus "Race Car" in this post on the Jalopnik site, but that resulted in total fail:


Don't know what the cause is (apparently: null), maybe you can only watch it in the USA or so and not from Spain where I'm currently on holiday, but it sure is something that I should submit to The Daily WTF.

Tuesday 8 September 2009

Java profiling on OSX

Not so long ago I needed to profile a small application to check why a simple WebDAV listing call using Slide took 20 seconds. It turned out to be a network IO problem caused by a blocking readline call on the response stream. I usually tend to use JProfiler for finding out these kind of things, because it is very good at what it does. But because it is a paying application and my company doesn't provide me with a license, I have to keep my eyes open for alternatives (you can't keep working with trial licenses and Mailinator addresses aren't allowed when registering).

So when the Eclipse Test & Performance Tools Platform Project, TPTP in short, appeared on my radar thanks to DZone I decided to try it out. Since I'm using Eclipse as my primary Java IDE this profiling plugin seemed a perfect fit, but little did I know. In Eclipse I opened Help > Install New Software... and added the http://eclipse.org/tptp/updates/ URL as a new software site to download TPTP. After downloading, agreeing to some licenses and an Eclipse restart I was ready to use my newly acquired profiler, or ... maybe not.

I was getting all kinds of different errors, but mostly NullPointerExceptions and some Incompatible Platform messages. After some looking around it was StackOverflow to the rescue: even though TPTP is already at version 4.3 there still isn't a TPTP Agent Controller for OSX. You've gotta be kidding me! How is it possible that they leave such a large group of Java developers, the ones that use OSX, out in the cold. It gets even better, you can't even open the TPTP 4.3 release notes page in Safari without getting a Javascript pop with the message: Sorry but this page isn't currently viewable in Safari. WTF!

So my little excursion away from JProfiler came to a screeching halt and I had to return to my tried and trusted JProfiler once again. One day I'll have to convince the big cheeses to get me a license.

Update 9 september 2009: it looks like I'm not the only one complaining: Green's Opinion

Monday 7 September 2009

Load testing gotcha nr. 1: logging

This will be a first in, hopefully, a series of short but important things to keep in mind when load testing. So without further ado:

Load Testing Gotcha nr. 1

Logging is a good thing, but too much will kill you, your performance and ultimately your server. So use it wisely young Padawan.


Logging and certainly good contextual logging is always nice when things go wrong, but during load testing it should be turned off or as low as possible. The reasoning behind this is that logging, certainly on the more verbose levels will impose a hard to ignore load on your CPU/Memory and certainly on your disk(s).

This extra load will influence the request/response times of your tests. So when your log level is set too high and doesn't reflect your production settings, your load tests won't be representative and can't be reliably used too predict production server behavior under load.

As far as I can tell there are only two reasons to load test using a more verbose log level:
  1. You're actually suspecting your logging of being a performance bottleneck and as such you want to do some load tests at different verbosity levels to study the impact of your logging.
  2. Your application is failing at certain load levels and you need more detailed logging to home in on the cause of the failure.
So this is my (current) view on logging and load testing. I also think that this view isn't only applicable on load testing alone, but should also be kept in the back of your mind during application development. What I want to say with this is that you always have to think carefully about what to log on which logging level.

And one extra free piece of advice: never, ever, use XML as a logging format. I have encountered it once or twice in the wild as a consultant and it will use about 30% more disk space than non-XML logging (possibly even more depending on the length of your tags) and isn't exactly human-readable unless you're name is Neo and you're living in the Matrix.

Another easy WebDAV test server

In the previous week I discovered another easy way to set up a WebDAV test server: Atlassian Confluence. This is a pretty neat wiki product that also exposes its contents via WebDAV. The Devoxx guys even used it to make their whole website.

To set up a new Confluence server you first have to download one of the fully functional 30-day trial editions here. After downloading you just unpack the file to reveal a standalone Tomcat server and then you'll need follow the installation instructions. In short this means:
  • checking your Java installation: version and home directory
  • setting a confluence.home value in /confluence/WEB-INF/classes/confluence-init.properties to a valid path somewhere on your disk
  • make sure you don't have port conflicts
  • start Confluence by starting the standalone Tomcat instance from the bin directory: ./catalina.sh start
  • browse to http://localhost:8080
  • follow the setup wizard you're presented with and remember the username and password you enter
After this you'll have a WebDAV server listening at http://localhost:8080/plugins/servlet/confluence/default. You'll have to authenticate using basic authentication with the credentials you entered in the setup wizard. By default there won't be much data available, but this can be easily solved by creating some spaces in Confluence and adding some pages to the spaces.