Learning how to migrate highly connected Django models from integer primary keys to UUID primary keys.

Here are some easy steps I try to do on every Java-project I’m working on. They are based upon what I’ve seen as major problem sources in different code bases, and should be fairly easy to apply - at least on new code. Tooling The first steps are to enable some basic tooling that can help us keep the project a bit of better shape. All of these comes with a cost, namely build time, but it’s totally worth it.

If you try to build your java-app with gradle against JDK8,and you error out on the tests being run, then this is most likely due to Gradle using ASM4.x for test-detection. This has been fixed in Gradle 1.10 by using ASM5-beta to scan for tests, instead of 4.x as used in previous versions. If you are unable to upgrade to Gradle 1.10 for some reason, you can apply the following trick to skip the scanning of tests, and just include them manually.

This last year I’ve been working on systems that integrate with a master ERP-system over SOAP. As with all thing enterprise, things tends to get a bit messy. Most interactions with the SOAP-interface requires the user to specify a lot of identifactors for other objects. In our system, most of these are represented as Long-instances. A naive implementation of this does not a happy programmer make. A typical service for talking through the SOAP may look a bit like this.

Using automated dependency injection has made the life of a developer a bit easier, or so it seems for a while. Maybe a bit too easy. In this post I’ll describe some of the mess this can lead to, and what you should do to avoid it, or fix it if it has already happened. The examples and mentioned libraries are Java-based, but most languages have something similar. What is dependency injection?

A little python snippet for creating dot-representation of the dependencies in a java app. Let this little baby chew on your target/classes dir and you will get a dot-file on stdout. #!/usr/bin/env python import re import os import sys from os.path import join, basename LIB_REG_EXP = re.compile('[,+L#][a-z][A-Za-z0-9/]+') PACKAGE_FILTER = '' CLASS_PREFIX_REMOVE = '' if len(sys.argv) > 2: PACKAGE_FILTER = sys.argv[2] if len(sys.argv) > 3: CLASS_PREFIX_REMOVE = sys.argv[3] def get_class_dependecies(class_file_contents): libraries = set(map(lambda x: x.

I’m quite fascinated by how quickly code rots and becomes a mess, despite the programmers best intentions. A lot could be fixed by testing and and refactoring more often, but it always seems to come second to getting shit done, and does sometimes have unintended effects. For some reason I see this more often in Java code than in other languages. Maybe it’s because of its class-madness creating deep nested code (try to trace a call through Jersey, I dare you.

So, banking data is quite interesting. If one could get a hold of your credit card transactions in an easy way, that would be sweet. But, its not that easy. My bank, DNBNor, has a feature that you can download either an excel document, or a CSV formatted dump of the transactions against one of your accounts on a monthly basis. The programmers choice would be CSV, but I found the CSV exports to be spotty, so excel it it.

Word cloud of my thesis so far. I guess you might be able to guess what I’m writing about :-)

If you are running Apache 2 with mpm-itk and mod_wsgi on a debian system, you’re a bit out of luck performance wise. From the MPM-ITK documentation: mpm-itk is based on the traditional prefork MPM, which means it’s non-threaded; in short, this means you can run non-thread-aware code (like many PHP extensions) without problems. On the other hand, you lose out to any performance benefit you’d get with threads, of course; you’d have to decide for yourself if that’s worth it or not.