Torsten Curdt’s weblog

I have never been a big fan of manually compiling and installing packages - especially on OSX. It just can’t be a good thing to scatter files around like that. This is probably just one of the reasons why thousands of other Mac users also chose to use fink or macports to install custom packages. Coming from the debian world I started out with fink and it’s apt-get install. Later I’ve switched to macports because it seem to provide more recent packages. Unfortunately sometimes even macports is a little outdated. But with a few commands you might be able to install a new port anyway.
Read the rest of this entry »

Last year was exciting - full of change and I see even more coming for 2009. So what was 2008 for me? For one I finally “got” twitter and embrace it since. I noticed it means fewer but hopefully also more meaningful blogs posts. Still I’ve got considerably more readers this year. Thanks for listening everyone! The most popular post of 2008 were:

1. Opening UIF files on OSX
2. From subversion to git (part3)
3. From subversion to git (part1)
4. Debugging HTTPS
5. Suunto Gekko with OSX
6. From subversion to git (part2)
7. Where is this java class from?
8. Sending emails from Cocoa
9. Battery Statistics
10. Java classpath and directories

Read the rest of this entry »

Recently James blogged about a nice addition to log4j. The submission even got applied already.

It uses the same “trick” that I had stashed away in my “toblog” folder and almost had forgotten about. Finding out the what jar file a class comes from can be quite useful at times. The straight forward approach is to lookup the resource and go from there.

Class type = yourinstance.getClass();
File jar = new File(type.getClassLoader().getResource(
  type.getName().replace('.', '/') + ".class")
  .toExternalForm()
  .replaceFirst("^[^/]*", "")
  .replaceFirst("!.*", ""));

But a much simpler and faster approach is to use the ProtectionDomain (if available).

Class type = yourinstance.getClass();
File jar = new File(type.getProtectionDomain()
  .getCodeSource().getLocation()
  .toURI());

Really quite simple but useful.

The java classpath and directories has always been quite a sad story. Of course you were always able to pass a directory of classes to the jvm like this:

java -classpath classes Main

But what you usually deal with these days are jars. Often quite a bunch of them. So fair enough - let’s add a directory with jars as well:

java -classpath classes:lib Main

Up until java 5 all you got was a ClassNotFoundException because java did not search for jars but classes in there. It just ignored the jars. So what pretty much everyone ended up doing is providing yet another shell script to build up the classpath and pass it to the jvm via command line. Of course for bigger projects this let to…

java -classpath lib/commons-logging-1.1.1.jar:lib/commons-jci-core-1.0.jar:commons-io-1.2.jar:lib/junit-3.8.2.jar:lib/maven-project-2.0.8.jar:lib/rhino-js-1.6.5.jar: ...

I guess you see where I am going …an unmanageable mess of a command line. But thankfully times have changed. Starting with java 6 (mustang) you can now use wildcards in the classpath:

java -classpath classes:lib/'*' Main

Naturally this means that the order of the jars is implicit. Which in turn means you need to be extra careful when there are classpath clashes. But in general I think this is a nice feature that should have been there from day one …and I just found out about it.

While tuning your server for performance is a good thing it’s not the only thing you should look at. Lately my blog pages felt to be loading a bit slow. Looking at the Safari network timeline it’s obvious that the flickr badge is (at least sometimes) dog slow and prevents the page to build up. The perceived performance suffers. And this has nothing to do with my server at all.

As there really no need for the flickr badge to be up-to-date to the second. I am caching it locally now. A cron script gets a copy and writes it to disk.

$ cat /etc/cron.daily/flickr
#!/bin/sh
curl -s --max-time 120 --connect-timeout 60 \
 'http://www.flickr.com/badge_code_v2.gne?count=3&display=latest&size=s&layout=h&source=user&user=88457640%40N00' \
 | grep -v "flickr_badge_beacon" \
 > /path/to/cache/location/flickr.html

Then then it gets included like this

<script type="text/javascript">
<?php readfile("/path/to/cache/location/flickr.html"); ?>
</script>

As a result the load time decreased from 6.3s down to 1.6s. That’s almost 4x faster. At least in the user’s perception. YSlow is also a great plugin for firefox that helps exactly with this kind of optimizations.

Would probably be a good idea to turn this into a wordpress plugin.