Sunday, December 12, 2010

user.js scripts for browser (firefox & chromium)

I wrote a Greasemonkey script for a friend: Disable keyboard input. As strange as it sounds, the goal is to let someone navigate with a mouse but not use they keyboard to enter stuff. The user suffers Alzheimer's disease.

I found out by accident that chrome also supports firefox greasemonkey user.js. It treats them as extensions. Now chromium doesn't seem to have a GUI to manage the installed scripts, and as it changes the script's file name upon installation, I had to use grep to find the proper file. On linux, that particular installation went under:


Stop the browser, delete the directory and restart the browser to get the extension removed.

Intellij issues on Ubuntu 64 bits with encrypted /home

Kept running into strange index issues with my Intellij 9 and 10 installations. The system/log/idea.log file was filled with:

java.lang.RuntimeException: java.lang.IllegalArgumentException: can't position buffer to offset 43716
Caused by: java.lang.IllegalArgumentException: can't position buffer to offset 43716


java.lang.IndexOutOfBoundsException: off=1006632960 key.owner.length()=17582

I seem to have fixed the issue by moving the IDEA config and caches into a non encrypted partition.

$ diff -u /usr/local/lib/idea/bin/ /usr/local/lib/idea/bin/
--- /usr/local/lib/idea/bin/ 2010-12-10 15:50:01.916136005 +0100
+++ /usr/local/lib/idea/bin/ 2010-12-10 15:50:44.096136000 +0100
@@ -10,13 +10,13 @@
# Note for Windows users: please make sure you're using forward slashes. I.e. c:/idea/system

# path to IDEA config folder. Make sure you're using forward slashes

# path to IDEA system folder. Make sure you're using forward slashes

# path to user installed plugins folder. Make sure you're using forward slashes

# Maximum file size (kilobytes) IDEA should provide code assistance for.

See also and

Thursday, December 9, 2010

Git svn tree corruption

I use git over svn for all my subversion projects. This morning I hit the following problem:

$ git svn rebase
error: garbage at end of loose object 'd0df538270dcaf65a232fb4127b7c59212420129'
fatal: object d0df538270dcaf65a232fb4127b7c59212420129 is corrupted
diff-index HEAD --: command returned error: 128

Mmm no backup accessible right now, and no way I am pulling remotely a git svn for this 7 years old tree.

First let's find information on the commit.

$ mv .git/objects/d0/df538270dcaf65a232fb4127b7c59212420129 ../d0df538270dcaf65a232fb4127b7c59212420129
$ git fsck --full
broken link from tree 066ce753000ca9e1cfbd07a709cac4c7c3e5da47
to tree d0df538270dcaf65a232fb4127b7c59212420129
dangling tree 866d5ac672d6ef4009319e176f195fd01697165c
missing tree d0df538270dcaf65a232fb4127b7c59212420129

What does the previous tree contains ?

$ git ls-tree 066ce753000ca9e1cfbd07a709cac4c7c3e5da47
100755 blob 888ed870384e87dad0642199b4d7d938246946a8 xxx1
100755 blob 346bd13c9ba0d15046af891ccc88aa225d3c7ee3 xxx2
100755 blob 2eef3f1f2985ff1d9cdd4a23c8ebca54a9af1010 xxx3
100644 blob 6a501e34ee0fb197fa6770b2a8cc40cdf276607a xxx4
100755 blob fe61ef5d88201a7502057a2ff5fdd45db44f5075 xxx5
040000 tree 38354b54d3dca537d9c7c9d9ec1668c0c7287bc9 ddd1
040000 tree 50be3bfee5b37fc97b379ae04fe961a212a70a32 ddd2
040000 tree 6b108f1b534bb9465c2e31efe51d06fb05499376 ddd3
040000 tree 532a6da6ece3151b43a1cd0fd174fdadb071e402 ddd4
040000 tree 45363718750ed5142fad1d7be311581748057297 ddd5
040000 tree d0df538270dcaf65a232fb4127b7c59212420129 ddd6
040000 tree b77d3e9240185ed148727e01d4d03ad726411724 ddd7
040000 tree 8b69621e177132f3dc822c427501f1921f39bbe1 ddd8

Didn't help much.

In that SVN tree, my history is pretty linear. I try to find the commit before or after the one that fails:

$ git log --raw | grep svn+ssh | tail -1 | cut -d '@' -f 2
fatal: unable to read destination tree (d0df538270dcaf65a232fb4127b7c59212420129)
4321 20108eba-4dfa-0310-bbc5-8f3fd2a08cff

Log fails to find the full history, and I now know which commits maps to the broken tree: 4320: the one before the last succesffuly logged commit (4321).

Let's verify:

$ git svn find-rev r4320
$ git show 4e0264e69a5289c5ac5c461085c900009c90c5b9
fatal: unable to read destination tree (d0df538270dcaf65a232fb4127b7c59212420129)

Now let's just fetch some versions around that commit and replace our broken tree file.

$ svn clone svn+ssh:// -r 4318:4322 xxx2.git
$ mv xxx2.git/.git/objects/d0/df538270dcaf65a232fb4127b7c59212420129 .git/objects/d0/

Check the commit ?

$ git show 4e0264e69a5289c5ac5c461085c900009c90c5b9

git svn rebase now works !

Thursday, November 11, 2010

Opendata @ Trafikanten, answer strategies

Obviously (and unfortunately) Trafikanten isn't willing to cooperate to open up their data.

I have to answer them within about 10 days and I am left with different strategies:

  1. abandon
  2. confrontation
  3. negotiate
  4. workaround

The first question one has to ask oneself is of course whether to abandon or not. Is this worth our time? I will have to ponder that.

The second option is go on with the confrontation. It's clear to say that now, using lawyers to defend themselves, Trafikanten isn't currently very open for negotiation. Hard to say who caused the situation, and it's not even important. It's just a fact. I am pretty sure I can find arguments to counter their answer, or even find things that as a public company they are obliged to do causing them problems. I am not very interested in that, and I would prefer negotiation/cooperation.

Cooperation, a WIN/WIN solution would have been the best. Making Trafikanten truly a leader in open data in Norway, finding a gradual path that leads for opening their data little by little. It might be possible. But right now I don't know. The tone is set and probably hard to change and they've made it clear they didn't want to help small companies nor their users. But I am optimist by nature, so why not?

As for the last solution, workaround, I am also sure I can find a technical solution that solves my issue independently of them. Trafikanten has a public API, and I can probably build the DB of the interesting data based on it. It might be completely inefficient, maybe illegal, incomplete, but I will sure be able to gather part of this data.

Friday, November 5, 2010

Open Trafikanten data, update

A little update after my latest encouraging post:


It doesn't seem that Trafikanten is ready to open some of its data. They are on the defensive now... I have 3 weeks to answer what I can answer to that mail.

Too bad. I think we could have worked towards an open and better service for Norway.

Thursday, September 16, 2010

Open Trafikanten data, a better future ?

Bjørn started a Facebook group to push for open communications from Trafikanten and NSB. I am all for it.

Last year I tried to get access to similar information from Trafikanten and Ruter. I didn't manage to get anything.

Here's a few extract from communications I had with them.

Wednesday, September 15, 2010

The sad state of Java decompilers

There are no good complete Java decompilers it seems. And this is sad.

Wednesday, August 25, 2010

Minimalist groovy BDD framework, from executable documentation to readable tests

In many projects, my target customers are other developers, not an end user that write prose. I am a developer. I don't write documentation, I write code, documented code.

When it comes to testing, I like the BDD approach. I've tested various BDD frameworks (easyb, cucumber, spock...). But I wasn't completely satisfied for various reasons (setup complexity, issues, maintainability, toolchain).

So I've gone back from executable documentation to readable tests. And I have settled on my own framework. Framework is a big name, you will see. In combination with mockito and a few coding conventions, it's the 1% that give me the 99% that I am looking for.

Tuesday, July 13, 2010

Migrating from Android JF1.5 to CM6 (Froyo) on my G1/ADP1

My notes regarding my upgrade of Android 1.5 to 2.2 on my G1/ADP1. Also how I manually imported /data after failing to rerun my 1.5 OS.

Wednesday, February 3, 2010

A glimpse of the workflow around the Linux stable tree

Found this small fun to watch. Notice how using scripts and aliases can make things quite fast.

Reminds me when I was using quilt to manage extra patches on top of cruisecontrol (about 6 years ago...).

Groovy/java/maven: ultra short coding cycles, not

The whole Java (maven, groovy, gradle, ...) experience starts pissing me off more and more. I want to write code with ultra short compile/test cycles.

Monday, January 11, 2010

To wean

the unix way

2. To detach from that to which one is strongly habituated or devoted

$ grep /etc/hosts localhost

Saturday, January 9, 2010

Deleting large amount of emails from gmail make your account unaccessible for several minutes.

My Gmail account has been too slow lately. As it approached 90% size, I tried to reduce its size, by deleting old mailing list emails.

I deleted 3 times more than ~50 k emails, and each time, my account became unavailable for several minutes (about 30), including through IMAP! Got several errors on the web page (16 or 17 and 67 if I recall properly).

You've been warned. Plan ahead if you try to do the same thing :)

Final words: I am now down to 57% gmail usage. Need to find or write a tool to be able to identify the culprits. Maybe some kind of FUSE IMAP file system to reuse something like baobab (aka for Gnome) ?