Have you ever had a problem with ajax requests caching in Internet Explorer. I have, and recently I came across a nicer solution than I have traditionally used. In the past, I have used a unique parameter on the url to keep IE from caching previous requests to the same url, like so:

Here is a "new and shiney" presentation for running Django on Jython. It's based on my experiences with the DjangoJython tutorial.

As is discussed in the slide deck, and hence the subtitle of the presentation, much could be helped by more careful reading of documentation. Well, moments ago, I decided that I hadn't checked out django-jython 1.1. Well.... turns out many more problems could have been helped by using this later version. Sweet!

In Ubuntu 9.10, they removed Java 5 from the update repositories for Karmic because Java 5 was end of lifed in Oct. 09. This has made it more cumbersome for the Java 5 user on Karmic. Luckily, cumbersome is still pretty easy.

Sometimes you want Maven to compile your code with a different JDK than is the one assigned to your JAVA_HOME. For instance, I have code in a project that I'm working on that only compiles on Java 1.5. My JAVA_HOME, however, is 1.6. So, how do we specify the JDK for Maven?

Sometimes you need to install a security certificate for authentication to work for certain services -- services that are accessed by your java application that requirement a secure connection. For instance, needing to authenticate against an LDAP server from one of our apps, we had to run a little InstallCert.java on all JDKs used to run the app.

In developing an email notification system recently, we became interested in code acting differently depending on what environment we were in. A potentially good solution for this is environment-based dependency injection. This means that different Spring beans, for instance, will be used depending on the environment, ie dev, test, etc. This is useful for something like emailing, because we may not want real emails hitting the mail server in dev or test environments, but we do in prod. With some Spring constructs, it's pretty easy.

Often when coding, we use a single local variable multiple times, overwriting the value many times. It is considered good practice to move the variable out of the looping overwrite and into the smallest scope of code that is run once. But, this makes the code a little bit less concise. So, how useful is it, anyway? I wanted to run a few little tests and see if there's really a noticable difference in performance.

EasyMock is a great tool for separating external dependencies from unit tests. There is a learning curve to learning the mock method of testing, and unfortunately, EasyMock does not give very good prompts when you do something wrong. The exception messages are actually quite cryptic. This article is meant to be a crude mapping of exception output and the behavior that might have caused it. At least, this is a log of many of my experiences with EasyMock and how I usually get into the messes I do. It is quite possible that the same exception output could be had via different behavior. It's also important to note that I'm not trying to show how to create meaningful tests here (I don't even show full tests half the time), only help figure out how mysterious EasyMock exceptions were thrown. These experiences were documented on EasyMock 2.2 and 2.4.

On Ubuntu 9.04, Jaunty, Compiz comes running out of the box on the mid-level preset for desktop effects. These effects and generally beautiful and pleasing, but a couple of the apps that I use are Java-based and have some compatibility issues with Compiz. At least for my apps, I've found a way around this issue.

For unit testing purposes, I often want to set field values in objects so that I can setup for the test conditions. One of most annoying things about testing is the urge to change code design for just the sake of testing -- especially if it's in a way that is considered less safe, like exposing elements or lessening accessibility. (This is not to say that trying to test code can reveal certain code smells and prompt refactoring). I, myself, have a number of setter methods with this comment prepended: "// for test only comments". Stinkers! Well, sometimes enough becomes enough. So, here's a way to set any field on an object w/o exposing it. This is done via reflection.