Long time no see!

Took a bit of time to update

• my social networks: goodbye Google+, Twitter and Bitbucket; hello Mastodon and LinkedIn
• my resume: I’m not working as a developer anymore
• the CSS: because I’m still a developer at heart 😉

The S2 Geometry Library is a spherical geometry library originally made by Google, released under the Apache License (Version 2.0), which is very useful for manipulating regions on the sphere (commonly on Earth) and indexing geographic data. I use it in several of my personal toy projects, both on desktop and on Android.

Sadly, it is/was hosted on Google Code, but Google Code is closing. The project has had no activity since 2011 and looks abandoned, so I had little hope to see it migrate somewhere else. Too bad for such a useful project!

But the beauty of Free and Open Source Software is that anyone is free to fork the code to fit his needs. And that’s what I did.

I’ve put the sources on Github, who hopefully won’t close in the near future. I have changed the build system to use Gradle instead of Ant, but the core of the library hasn’t changed.

The continuous integration is provided by Travis CI.

The binaries are published on Bintray, so using them in your Gradle or Maven build is dead easy.

For Gradle, add the following repository in your build.gradle:

repositories {
  maven {
    url "http://dl.bintray.com/jnegre/maven"
  }
}

Then reference the artifact you need:

dependencies {
  compile 'org.jnegre.google:s2-geometry:1.2'
}

If you’re using Maven, add the repository in your settings.xml:

<?xml version="1.0" encoding="UTF-8" ?>
<settings xsi:schemaLocation='http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd'
xmlns='http://maven.apache.org/SETTINGS/1.0.0' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
  <profiles>
    <profile>
      <repositories>
        <repository>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
          <id>bintray-jnegre-maven</id>
          <name>bintray</name>
          <url>http://dl.bintray.com/jnegre/maven</url>
        </repository>
      </repositories>
      <id>bintray</id>
    </profile>
  </profiles>
  <activeProfiles>
    <activeProfile>bintray</activeProfile>
  </activeProfiles>
</settings>

Then add the dependency in your pom.xml:

<dependency>
  <groupId>org.jnegre.google</groupId>
  <artifactId>s2-geometry</artifactId>
  <version>1.2</version>
  <type>jar</type>
</dependency>

(I suspect the Maven developers are paid by the hard disk manufacturers to have such verbose file formats.)

Did I mention the fact that this library works perfectly well on Android? Because it does.

Gosh, I love Open Source!

I’ve always been a big fan of static websites, for mainly two reasons: simplicity and security. Simplicity, because why have a complex software on the server when the content is updated at most once or twice a month? Security, because the most secure lines of code are the ones that have never been written.

In 2002, nothing was really existing to easily generate a static website, so I wrote an Eclipse plugin, Stylo Plume, to help me accomplish this. And since the year was 2002, and I was working a lot with XML and XSL, I used XSLT.

Fast forward 13 years later. I still think a static website is what I need, but I’m getting tired of XSLT, and I really don’t feel like testing and potentially fixing my plugin with Java 8 and the Eclipse 4 branch. So I started looking at some static site generators, and I stumbled upon a post from Tom Preston-Werner that sums up nicely my feelings:

I already knew a lot about what I didn’t want. I was tired of complicated blogging engines like WordPress and Mephisto. I wanted to write great posts, not style a zillion template pages, moderate comments all day long, and constantly lag behind the latest software release. Something like Posterous looked attractive, but I wanted to style my blog, and it needed to be hosted at the domain of my choosing. For the same reason, other hosted sites (wordpress.com, blogger.com) were disqualified.

Tom Preston-Werner is the creator of Jekyll, and after 2 weeks to migrate the source of my site, I can say that I’m now a happy user.

Do you feel hungry? Do you speak French?

If the answer to both questions is “yes”, I’ve added a bunch of recipes: Tarte à la tomate, Egg in the basket and Encornets à ma façon.

Bon appétit !

This summer, I went on vacation to a place that was not covered by OpenStreetMap, so I became a small OpenStreetMap contributer and mapped the surroundings. Here’s the list of software that I used on my Android devices.

To gather GPS data, I used OSM Tracker for Android, available both in Google Play and via F-Droid. It’s a nice GPS tracker with fast Points of Interest (POI) placement shortcuts. It should be able to upload traces directly to OSM, but this functionality always crashed with me; uploading the generated traces (.gpx) with the website worked once I renamed the files to remove non-ASCII characters.

To edit the map, I used Vespucci, which is also available both in Google Play and via F-Droid. It’s fine for relative small edits, but for larger one you’d better use the Flash-based Potlatch 2. Another useful application to edit details such as the name of roads or POIs is OSMapTuner (see update), available in Google Play.

OpenFixMap (in Google Play) was very helpful to flag errors on the map. You’ll have to use an editor to fix them.

A more comprehensive list can be found on OpenStreetMap’s wiki: Android software supporting OpenStreetMap. Happy hacking mapping!

Update: I’ve just found another editor for POIs, Mapzen POI Collector. It can add POIs and has a much nicer user interface. However, it is limited to the most common types of POI, so if you have very special needs, it’s not for you.

Deploying your artifacts to a remote Maven repository with Gradle is possible, but the official documentation is rather thin at the time of this writing. Worse, it tells you to use a version of wagon-ssh that ignores the provided password and prompt for it at the command line (use gradle -i to see its message).

So, without further ado, here is a build.gradle that uploads its artifact via scp with a password. It has been tested with Gradle 1.0-milestone-6.

apply plugin: 'java'
apply plugin: 'maven'

configurations {
    deployerJars
}

repositories {
    mavenLocal()
    mavenCentral()
}

dependencies {
    //the one and only version that works
    deployerJars 'org.apache.maven.wagon:wagon-ssh:1.0-alpha-3'
}

uploadArchives {
    repositories.mavenDeployer {
        configuration = configurations.deployerJars
        uniqueVersion = false
        String username = 'me'
        String password = 'secret'
        repository(url: 'scp://repos.mycompany.com/releases') {
            authentication(userName: username, password: password)
        }
        snapshotRepository(url: 'scp://repos.mycompany.com/snapshots') {
            authentication(userName: username, password: password)
        }
    }
}

Of course, in a real world scenario, it would be wiser to get the username and password from your gradle.properties or any other non-public file.

Gradle is a very flexible and powerful build tool, allowing an extremely concise build file for conventional projects and letting you do whatever crazy thing your project requires using a Groovy DSL. I’ve been following its development for the last two years, and I introduced it to replace a legacy Ant based build system at my work about a year ago.

As far as I know, Building and Testing with Gradle, written by Tim Berglund and Matthew McCullough and published by O’Reilly, is the first book published on this topic.

The first chapter will guide you through the installation process and the use of the Gradle from the command line. I’m not sure someone willing to use Gradle needs that kind of information. It will also show you the shorter build file possible for a Java project, containing only 18 non-whitespace characters: compare this with Maven…

The second chapter is were the serious stuff begins. It presents the basic unit of Gradle build files: tasks. The two lifecycle phases, configuration and execution, are explained. You’ll also learn how to use their rich API and how to simply write your own tasks. If you’re used to the complexity of Maven, be prepared for a shock as this is dead simple and way conciser.

The third chapter shows how Gradle can leverage your existing Ant files and custom tasks. This particularity of Gradle allows a step-by-step migration from Ant.

The fourth chapter compares Maven and Gradle. Gradle takes the best ideas from Maven (and others): convention over configuration, consistently named artifacts and a solid dependency management with the same central repositories. It drops what makes Maven so painful to use: tons of XML, a rigid lifecycle and more generally its lack of flexibility.

The fifth chapter is about testing. The integration of JUnit, TestNG, Spock, Geb and EasyB will be rapidly shown.

The sixth and last chapter is focused on multiproject (or multimodule) builds. Once again, the tremendous flexibility of Gradle makes it bend to your needs rather than imposing its standards on you.

This is a short book with fewer than a hundred pages, read in a couple of hours, and full of code samples. It is an introduction to Gradle, not a complete reference guide: it will show you the power and the simplicity of Gradle, and - I hope - will convince you to give Gradle a try.

The Brother HL-2250DN is a laser printer with both a USB and an Ethernet interface. It understands PCL6, so I knew I could use it with my Ubuntu 10.10 box without too much troubles.

Here’s how to configure your computer to enjoy the Ethernet interface. One doesn’t buy a network printer to use USB, right?

First, one need to get the IP address of the printer. You could get it from your router, or you may just ask the printer. To print the settings of your printer, do the following:

1. Switch on the printer;
2. Wait till the printer is ready;
3. Press “Go” three times in less than 2 seconds.

The IP address will be on the third page.

Now, on your Ubuntu box:

1. Go to System / Administration / Printing;
2. Click on the “Add” button;
3. Select “LPD/LPR Host or Printer” on the left;
4. On the right, enter the printer’s IP address;
5. The name of the queue is “PCL_P1”;
6. When asked for a driver, pick “Generic PCL 6/PCL XL Printer - CUPS+Gutenprint v5.2.6 Simplified”.

And voilà!

I had to parse in Java an rather big XML document that was looking something like that:

<root>
	<child1>
		<a>I need this element</a>
		<b>but not this one</b>
		<c>this one is also irrelevant</c>
	</child1>
	<child2>
		<a></a>
		<b></b>
		<c></c>
	</child2>
	<!-- and so on to fill more than 4 Mo -->
</root>

There are hundreds of first level child nodes, but each one only has a few children.

Given any child node, I had to get one of its own children by its name. I had two options:

• iterate over the list of children, and check each one to see if it’s the one I am looking for (5 lines of code);
• or be lazy and use a very simple XPath expression (1 line of code).

Being lazy, and since the context nodes were having only a few child nodes, I decided to go with XPath. I knew there would be some overhead, but it shouldn’t be very big, right?

Wrong.

My code wasn’t doing anything fancy, but it took 40 seconds to complete. Being curious about the overhead introduced by XPath, I replaced it by a bunch of node.getChildNodes(). The total time dropped to 0.1 second.

I wrote a small benchmark to illustrate this problem. It boils down to these two methods:

/**
 * Returns the direct child of parent with the given name using XPath
 */
private static Node getChildXPath(Node parent, String name) throws Exception {
	return (Node)xpath.evaluate(name, parent, XPathConstants.NODE);
}

/**
 * Returns the direct child of parent with the given name using getChildNodes()
 */
private static Node getChildDom(Node parent, String name) throws Exception {
	NodeList list = parent.getChildNodes();
	for(int i=0; i<list.getLength(); i++) {
		Node child = list.item(i);
		if(child.getNodeType() == Node.ELEMENT_NODE && name.equals(child.getNodeName())) {
			return child;
		}
	}
	return null;
}

The full code is available on github.

On my linux box with OpenJDK 1.6.0_20, I got the following results:

Children were found using DOM in 2 ms
Children were found using XPath in 4016 ms

Lesson learned: javax.xml.xpath is slow as hell, even for very simple expressions.

This web site is still built with XSL using my good old Eclipse plugin Stylo Plume. Everything was OK for the past years, but a few weeks ago I wanted to redesign the news section on the home page, to add individual links to each announcement. I wanted something a bit like a blog, but without comments and fully in static html (no server-side PHP/Java/whatever).

In order to do so, I needed to add a new functionality to Stylo Plume, namely to enhance the dir:// protocol to be able to list sub-directories recursively. So 8 years after the last release, I searched in a bunch of old hard drives to recover my ancient CVS server and put the code in Mercurial. A public repository is now available on Bitbucket.

Release 0.2.0 is out today, it includes the modification to the dir:// protocol and the replacement of Xalan by the XML stack included in the JVM.

Oh, and there’s even an Atom feed for the news, now!