There’s an intersting low-level class in the Android SDK called Looper. Each app has at least one, because it powers the UI Thread. You can create Android apps perfectly fine without ever using Looper yourself, but it’s an interesting thing, so let’s take a look under the bonnet.
Barend Garvelink
A useful technique that I reinvent every once in a while is conditionally ignoring JUnit tests. Unit tests are supposed to be isolated, but occasionally you hit something that makes assumptions about the environment, such as code that executes a platform-specific shell command or (more commonly) an integration test that assumes the presence of a database. To keep such a test from breaking unsuspecting builds, you can @Ignore it, but that means you have to edit the code to run the test in a supported environment.
Proper Maven projects put their integration tests in a separate source folder called src/it/java and put an extra execution of the maven-surefire-plugin into their pom.xml, tied to the integration-test phase of the Maven build lifecycle. This is Maven’s recommended way of setting these up. It ties in beautifully with the pre-integration-test and post-integration-test phases that can be used to set up and tear down the environmental dependencies of the integration test suite, such as initializing a database to a known state. There is nothing wrong with this approach, but it’s a bit heavy handed for the simplest of cases.
In these simple situations it’s easier to just keep the integration tests in the src/test/java directory and run them along with all your other tests. However, you still need a way to trigger them only when the right environment is present. This is easily dealt with by writing your own JUnit TestRunner and some custom annotations, as shown below.
I previously blogged about shell scripting JSON with Node.js. In this post, I’ll demonstrate how to achieve the same thing with jsawk. The way these things go, I didn’t find out about jsawk until after I wrote my post about shell scripting with Node. It’s good to know both 
.
Jsawk, as the name implies, aims to be for json what awk is for structured plain text. It’s rather useful, as it saves a lot of setup/boilerplate compared to the node.js scripts I’ve shown before.
I’m currently in a project team working on an application that stores much of its data in CouchDB. One of the lovely things about Couch is its RESTful API. It’s all simple HTTP and JSON, easy to understand and easy to program to.
One aspect where this interface isn’t so readily accessible is in shell scripting. There’s curl to handle all the HTTP stuff we could ever need, but to transform a JSON structure or extract information from it proved less straightforward. We can cover simple cases with grep and awk, but JSON is complex enough that we (or, well, I) wouldn’t want to. If the documents were XML, we could have used xpath and xslt to do our heavy lifting. There is to my knowledge no equivalent to xmlstarlet for JSON to reliably handle these chores.
We solved our shell scripting problem and the solution is dead obvious, Read more
Update, 26-02: Brian Demers from Sonatype pointed out in the comments that Maven 2.0.10 and later are forwards-compatible with changes in the metadata format. If your Maven 2 version is one of the recommended versions on the download page, you will not have this problem.
Two days, in fact. Yesterday evening, after my colleagues went home, I brought down our Nexus 1.8.0.1 instance to upgrade it to 1.9 without interrupting their work. The download page for Nexus 1.9 contains the following instruction:
Sonatype has changed how the lucene indexes are stored on disk, it is required that users reindex all repositories in their nexus server to start benefitting from the changes (and for search to work properly).
Inconspicuous enough. Furthermore, clicking through from the change overview to the full change log reveals:
[NEXUS-3849] – Add full support for the new maven 3 snapshot metadata
What it doesn’t reveal is that the rebuild metadata command in the repository administration screen, which would appear to be proper housekeeping at a time when you’re reindexing the repositories, now generates Maven 3 style metadata and inadvertently breaks compatibility with Maven 2 (update: older versions). This is where the fun begins.