Use the space bar or arrow keys to navigate.

Enjoy!

Creating a HTML document:

• type “doctype” and hit tab, you’ll see a dropdown to select the doctype
• type html and hit ctrl + shift + <
• inside the html tags, type “head” and hit tab
• inside the generated “head” element and after the title, type “link” and hit tab to generate a stylesheet reference
• then type “scriptsrc” and hit tab, this will generate a link to an external script
• for a regular script tag inside the HTML body, type “script” and hit tab

To be continued…

So I thought hey, I’m a developer, so let’s see what I can do with those directions and a bit of java code… I documented the result in the little video below and also created a small google code project at http://code.google.com/p/java-location-data-converter. Right now it is just a JUnit test that generates a CSV file which you can then use to e.g. visualize the data with OpenHeatMap (http://www.openheatmap.com). If you have an iPhone and are curious to inspect your location data, check out the the directions to inspect the data.

And if you’re also a java developer, check out my code as a starting point.

Have fun!

iPhone location data visualized from Nils Preusker on Vimeo.

Client restletClient = new Client(new Context(), Protocol.HTTP);
Reference resourceRef = new Reference("THE URL...");
resourceRef.addQueryParameter("key", "value");
Request request = new Request(Method.POST, resourceRef);

Response response = restletClient.handle(request);
String responseAsText = response.getEntityAsText();

Oh, and you’ll want to add the following dependencies to your maven pom.xml (if you’re using maven…):

...
<dependency>
  <groupId>org.restlet.jee</groupId>
  <artifactId>org.restlet</artifactId>
</dependency>
<dependency>
  <groupId>org.restlet.jee</groupId>
  <artifactId>org.restlet.ext.json</artifactId>
</dependency>
<dependency>
  <groupId>org.restlet.jee</groupId>
  <artifactId>org.restlet.ext.httpclient</artifactId>
</dependency>
<dependency>
  <groupId>org.restlet.jee</groupId>
  <artifactId>org.restlet.ext.xstream</artifactId>
  <version>2.0.1</version>
</dependency>
<dependency>
  <groupId>org.restlet.jee</groupId>
  <artifactId>org.restlet.ext.xml</artifactId>
</dependency>
...

First we’ll launch postfix by typing the following in a terminal:

sudo postfix start

To verify it runs, you can use telnet:

telnet localhost 25

You should then see some output like this

...
Connected to localhost.
Escape character is '^]'.
...

Hit Ctrl-] to get to the telnet> prompt and type “quit” to exit. Next, we’ll make sure postfix starts when the system boots by calling launchctl load with the -w option:

sudo launchctl load -w /System/Library/LaunchDaemons/org.postfix.master.plist

To undo, you can simply use launchctl unload -w. You will probably get an output like

org.postfix.master: Already loaded

because postfix is already running. However, postfix should now always be launched at start-up. Finally, we should add the following lines to the /System/Library/LaunchDaemons/org.postfix.master.plist file:

<key>RunAtLoad</key>
<true/>
<key>OnDemand</key>
<false/>

That’s it, you’re done. Hope someone found this post useful!

After months of intense work, Activiti 5.0 is here. Check out Tom Bayens’ blog or our blog post at BPM-Guide for more details or simply go to http://activiti.org/download.html and get started right away.

While you’re at it, make sure to have a look at activiti-cycle, which we’ve spent a lot of our time on at camunda lately.

Enjoy!

This behavior can have unfortunate side effects in applications. Especially remote applications that work path based and interact with different operating systems can run into problems here.

I came across this when I tried to access a subversion repository that contained file names with German umlauts from my Mac. I am running subversion 1.6.5 and when I check out a file with an umlaut in its name, executing “svn stat” will list the file twice, once as missing (with an ‘!’) and once as unversioned (with a ‘?’). A search in the collabnet discussion forums finally confirmed that this is a know issue. The following links provide some documentation:
http://www.opensimwiki.net/index.php/SVN
http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames

However, the subversion issues are just one specific bug. For application developers it is important to know that Unicode equivalence is a term to keep in mind. The wikipedia article (http://en.wikipedia.org/wiki/Unicode_equivalence) mentions a bug in the samba protocol due to different representations of Unicode characters.

So, next time you come across an issue that involves a Mac and umlauts, Unicode equivalence might be the term to look for.

Is a serialVerionUID required on abstract classes?

My first thought: No way! If the serialVersionUID is used by the serialization mechanism to check whether some serialized data is compatible with a serializable class, abstract classes (that will never be instantiated, and thus, never be serialized directly) don’t need one! The problem is that the entire inheritance tree is checked when a class is de-serialized — and that includes abstract base classes. A simple example illustrates the problem:

If we have an abstract base class …

import java.io.Serializable;

public abstract class Base
implements Serializable {}

… and a sub-class that declares a serialVersionUID …

public class Sub extends Base {
    private static final long serialVersionUID =
      -7913545780181427623L;
}

… and we create an instance of the sub-class and serialize it to a file …

...
Sub sub1 = new Sub();
try {
    FileOutputStream fout = new FileOutputStream("sub.dat");
    ObjectOutputStream oos = new ObjectOutputStream(fout);
    oos.writeObject(sub1);
    oos.close();
} catch (Exception e) {
    e.printStackTrace();
}

… and then we change the base class by e.g. adding an int field …

import java.io.Serializable;

public abstract class Base
implements Serializable {
    int a = 0;
}

… and try to de-serialize the sub-class …

Sub sub2 = null;
// Load the file and de-serialize the object
try {
    FileInputStream fin = new FileInputStream("sub.dat");
    ObjectInputStream ois = new ObjectInputStream(fin);
    sub2 = (Sub) ois.readObject();
    ois.close();
} catch (Exception e) {
    e.printStackTrace();
}

… we’ll get a “java.io.InvalidClassException”.

If we do the same thing, but define a serialVersionUID in the abstract base class, the exception would not occur. The reason for this is, that if a serialVersionUID is not explicitly declared, the JVM will calculate a default one, “based on various aspects of the class” [1]. This is a great mechanism, at first glance it even seems to be better than creating the id manually — if the class changes, these changes are automatically reflected in the generated id. But, this mechanism can differ based on the VM If you would run this example on one VM and then try to de-serialize the same “sub.dat” file with a different VM, without modifying the base class, it is possible that you would get an “InvalidClassException”, simply because the VM uses a different mechanism to calculate the default serialVersionUID. This is why it is recommended to manually declare the serialVersionUID.

However, this also means that, if we change a serializable class and thereby make it incompatible with previously serialized instances, we have to update the serialVersionUID!

Now if we think about software maintenance and data integrity, there should be a way to migrate existing serialized data to new versions of the serializable class. I’d be interested to know if there is an official recommendation for this, but didn’t investigate further yet.

It would also be interesting to see how OR-mapping frameworks fit into the picture. There is an interesting thread on using Serializable and what to do with the serialVersionUID in the hibernate JIRA: http://opensource.atlassian.com/projects/hibernate/browse/HBX-964

I’d be interested to know what others think about this, so please feel free to comment!

[1] http://java.sun.com/javase/6/docs/api/java/io/Serializable.html

org.springframework.beans.factory.BeanCurrentlyInCreationException:
Error creating bean with name 'repositoryService': Requested bean
is currently in creation: Is there an unresolvable circular
reference?

The problem is that rather than having to declare all of jBPM’s services in your application context — like it used to be up to jBPM 4.2 —, the new spring integration provides access to them through the Process Engine. All you need in your application context is this:

<bean id="springHelper">
  <property name="jbpmCfg" value="PATH TO YOUR jbpm.cfg.xml">
</property>
</bean>
<bean id="processEngine" factory-bean="springHelper"
factory-method="createProcessEngine" />

Now you can inject the processEngine into your classes and retrieve jBPM’s services like this:

processEngine.getExecutionService() …
processEngine.getRepositoryService() …
…