Just published an article on JavaScript in professional software projects at http://it-republik.de/jaxenter/news/JavaScript-EE-062649.html. It’s in German, but hopefully still an interesting read for some of you!
Most of you have probably read about the fact that the iPhone stores location related information in a local file. The file is transferred to the computer every time the iPhone is connected and synced via iTunes. If you’re interested in visualizing the data, there is an application called iPhone tracker available at http://petewarden.github.com/iPhoneTracker. The authors of the software, Alasdair Allan and Pete Warden, didn’t only decide to open source their work, but also wrote up quite a bit of documentation about the data and how to access it. They promise that “none of your data ever leaves your machine” but go on to “recommend inspecting the source code if you’re a developer, or even just relying on the directions that allow you to inspect the data using standard database tools.”
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.
Since I keep forgetting how to do this, here is a code snippet to POST parameters to some URL using Restlet 2:
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> ...
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!
The Mac OS file system —Mac OS Extended (Journaled)— stores umlaut characters as two separate letters (i.e. ‘a’ and ‘¨’). This is referred to as NFD or Normalization Form D with canonical decomposition (see “Unicode Standard Annex #15 – Unicode Normalization Forms”, http://unicode.org/reports/tr15/#Norm_Forms).
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.
jBPM has just been released in version 4.3 and the spring integration has been changed. If you used to have an application that uses the spring integration of previous versions of jBPM, this might lead to exceptions like this:
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() … …
Have you ever seen an exception like this:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'XY' defined in class path resource [applicationContext.xml]: Instantiation of bean failed; nested exception is org.springframework.beans. BeanInstantiationException: Could not instantiate bean class [XY]: Constructor threw exception; nested exception is java.lang.LinkageError: You are trying to run JAXB 2.0 runtime (from jar:file:/.../WEB-INF/lib/jaxb-impl-2.1.8.jar!/com/sun/ xml/bind/v2/model/impl/ModelBuilder.class)but you have old JAXB 1.0 runtime earlier in the classpath (at jar:file: /.../WEB-INF/lib/jaxb-impl-1.0.4.jar!/com/sun/xml/bind/ WhiteSpaceProcessor.class) Please remove the JAXB 1.0 runtime for 2.0 runtime to work correctly.
Well, I have, several times… and the task of having to figure out which library causes this dependency conflict seemed unresolvable pretty scary at first! Luckily, there is the m2eclipse plug-in with its excellent dependency graph. So if you are using Eclipse, whether you are actually using m2eclipse to manage your project or not, just the dependency graph makes it worth having a look at it. I still run my maven tasks on the command line, but have m2eclipse installed, just to be able to use the graph.
After identifying which library is causing the dependency conflict, all you have to do is to add an “exclude” node to that dependency in your pom.xml. In the above case, this snipped did the trick:
<dependency> <groupId>...</groupId> <artifactId>...</artifactId> <version>...</version> <exclusions> <exclusion> <artifactId>jaxb-impl</artifactId> <groupId>javax.xml</groupId> </exclusion> ... </exclusions> </dependency>
I noticed that there isn’t a whole lot of useful information about Java and Snow Leopard (OS X 10.6) out there on the web. Maybe this is because there isn’t a whole lot to say about it. Snow Leopard comes with Java 6 (1.6.0_15 that is) only, which means that the links that still exist in the
/System/Library/Frameworks/JavaVM.framework/Versions/
directory all point to “CurrentJDK”, which points to “1.6″. The thing is that Snow Leopard ships with a 32 bit version and a 64 bit version of the VM (Virtual Machine), 64 bit being the default one. The Java Preferences app shows this nicely:
And that is the big news about it, since a 32 bit version of java 6 didn’t previously exist for OS X.
Now I’ve previously had to tweak Eclipse to use the 1.5 VM (see “Java Versions on Mac OS X“), and now it just works. I’m assuming that this is because of the “mixed mode”:
$ java -version java version "1.6.0_15" Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode)
…so the VM would automatically detect if an application should be executed in 64 or 32 bit mode and then start the correct VM. I still need to investigate how this actually works. Anyway, the good news is that java and eclipse seems to be working better with Snow Leopard. I’ll write more on this as I continue working with it, for now here is an interesting post on the topic:
http://blog.zvikico.com/2009/09/eclipse-java-and-snow-leopard.html
If you ever wonder which ports are open on your OS X machine, or whether e.g. jboss is still running, this command will help you:
$sudo lsof -Pi | grep -i "listen"
FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
Man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man
I keep running into the problem that different projects I’m working on require different versions of maven. I have two versions installed, maven 2.0.6 in /usr/share/maven-2.0.6 and maven 2.0.9 in /usr/share/maven. To find out which version of maven you are running, open a terminal and type the following
$ mvn --version Maven version: 2.0.9 Java version: 1.6.0_07 OS name: "mac os x" version: "10.5.6" arch: "x86_64" Family: "mac"
In this case, maven 2.0.9 is running, so we’ll see how to switch to maven 2.0.6. First we need to know where the maven executable, or in this case, the symbolic link to the executable is located:
$ which mvn /usr/bin/mvn
Next, we’ll use ls to check where the symbolic link is pointing:
$ ls -l /usr/bin/mvn lrwxr-xr-x 1 root wheel 24 Apr 24 14:26 /usr/bin/mvn -> /usr/share/maven/bin/mvn
Finally, if you have different maven versions installed, you can switch between them by overwriting the symbolic link:
$ sudo ln -fhsv /usr/share/maven-2.0.6/bin/mvn /usr/bin/mvn
After providing your password, the symbolic link should now be pointing to the maven 2.0.6 executable. To doublecheck, type
$ mvn --version
The output should be something like this
Maven version: 2.0.6
