Embedded Derby

The trivial issues are the one that drive you nuts because you waste too much time for something that should have taken 2 minutes at most.

Today I was fighting with a spring application that uses hibernate to talk to an embedded derby database.

So simple.

Because I am getting a java null pointer exception when I am trying to save an entity I decided to empty the embedded derby database directory so I could start fresh and make sure that this was not the issue. Again simple.

I started to have all sorts of issues in my spring application logs telling me that it could not create the database (I have the property for derby set to create=true).

All I needed to do was to the delete the directory itself and not just the content.

An hour wasted searching on Google and no one was as dumb as I and posted anything about this issue.


Continuous deployment

This article is a must read:


The discipline and the level of automation to be able to continuously deploy new code is inspiring.

It may sound impossible to do right now but I think that once you start taking the first step on this path you will not want to go back. This is a lot more fascinating than the current type of testing I see done on my code. It is also more fascinating to think that you can deploy new code easily all the time than having to go through all the paperwork that I am seeing all the time.


Learning Python

Learning Python is a lot more fun than I anticipated.

I think that the fun comes from a no expectation mentality and that everything I do with python is currently simple and helps greatly to automate some boring tasks.

I am not sure that I can complain about the fact that from one version to an other the changes are sometimes drastic and being able to understand and find the differences is sometimes more work that I would like. This issues comes from the fact that RHEL5 has Python 2.4 and that my other platforms have Python 2.7.

Today I was trying to understand how to pass a datetime to a xmlrpc server and some functionality was introduced in 2.5 (allow_datetime). It took me 20-30 minutes to understand why it was not working on RHEL5.

As any good learning I am making many errors in small scripts so I hopefully avoid when the real apps come around.

Taking Advantage

I was listening to the Animoto CEO on a building 43 interview and Brad Jefferson struck me when he was explaining that they are excited about everything that is happening. For him, HD TVs are good for his business because people will want to watch their photos in a cool video on them. The new cheap digital boxes that you can attach to your TV is good for his business. Even photo books are good for him because he wants to offer his product to those people selling photo books so they can offer 2 products instead of 1. Everything that was thrown at him was basically good for his business in one way or an other.

I have to think like that and get moving on all these positive challenges that are available to me and will allow me to do good business.

We have complicated systems, great! There is a need for more automation so I have more code to do.

We have complicated rules on how and when we can do changes, great! More automation or systems that can simplify the user interaction with all these rules and help them navigate in all of it.

There are many possibilities and we can’t look at them as an other layer of problems. These challenges allows us to better serve our users/customers and have more business. It is a lot more fun to look at it this way and go for it.

How to do a SVN Dump from a remote repo

Found this great article on how to hack your way to do a SVN dump from a remote repo. I had never use the svnsync command but this allows you to make the remote repo a local one and you can easily use it to create your dump file. Very useful when you have lost admin access to the original server and you need to migrate to a new SVN server.

Quick command list:

  • svnadmin create temprepo
  • echo ‘#!/bin/sh’ > temprepo/hooks/pre-revprop-change
  • chmod +x temprepo/hooks/pre-revprop-change
  • svnsync init file://temprepo https://server/svn/origrepo
  • svnsync sync temprepo
  • svnadmin dump temprepo > dumpfile

Copy the dump file over to the new SVN server and on it:

  • svnadmin load reponame < dumpfile

A quick word of warning because the UUID will change with this process so doing “svn sw” on existing working copy might prove to be challenging.

How to find the jdk version used to compile a java class

I spent a little bit of time to figure out how to find the jdk version used to compile a java class. On the site stackoverflow they have a great example of java code that can get this information. Unfortunately that did not resolve my problem so I will have to hunt down a bit more on why I get this:

Exception in thread “main” java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)