The principal causes of the grounding and loss of Cork were

• Total reliance was placed on electronic navigation. No second system of navigation was used to verify positions obtained from the GPS
• Total reliance was placed on the chart, even though the survey source data was very old (ndlr 150 years old!!) – Warnings regarding GPS positions and chart accuracy were disregarded, even though they clearly indicated that the charts were unreliable
• The position of the reef on the chart was inaccurate, approximately 1000m east of the charted position
• The navigation light and the Racon beacon were not working. (Warnings on the chart advised that the aids to navigation within Indonesian waters may be missing, unlit or out of position)
• The electronic charts did not appear to contain the warnings that were shown on the borders of the largest scale paper chart, which should have alerted the skipper to the fact that Gosong Mampango was almost a mile to the east of its charted position
• When the light and Racon beacon were not raised visually or on the radar no precautions were taken

Conclusions: read the charts warnings, cross-check an electronic position, pass 10 miles away from a waypoint, 1 mile is too close…

1. Session events i.e. Type-NONE events are sent to all outstanding watch handlers. Node events are not.
   Let’s say you invoked getChildren(“/foo”, ze_watcher), if later the client gets disconnected, both the default watcher and ze_watcher will receive a watch event NONE/Disconnected. But only ze_watcher will receive a NodeChildrenChanged event.
2. Watches are one-time triggers, but session events do NOT remove a watcher.
   In other words, still with our getChildren example, if  a disconnection occurs, ze_watcher will eventually receive 3 events: Disconnected, SyncConnected and finally NodeChildrenChanged. This will happen without having to set any new watcher.
3. If the invocation of a (synchronous or asynchronous) method fails, the watcher is not set.
   For instance if getChildren(“/foo”, ze_watcher) failed because the client is disconnected, ze_watcher won’t be notified of futur events.

Patrick Hunt confirmed this on the ZooKeeper mailing list and added further details.

So now you have a working Git repo, fine. The only concern is how git-svn handles tags. Each SVN tag is converted into a branch, not a tag. For instance, tag 1.2 becomes git branch tag/1.2. git-svn might have a good reason for doing it but this is a bit disturbing to me, especially when you have dozens of tags polluting your ‘git branch’ output.
So I intended to convert all these branches into real tags, and delete them. Here is the command I came up with:

$ git-for-each-ref refs/remotes/origin/tags | cut -d / -f 5- |
while read ref
do
git tag -a "$ref" -m"say farewell to SVN" "refs/remotes/origin/tags/$ref"
git push origin ":refs/heads/tags/$ref"
git push origin tag "$ref"
done


Here is my use case: every new feature I code for ODE has a JIRA id. It’s a good practice to mention this identifier in your commit messages, so that people can quickly know which issue this commit refers to, and eventually consult the JIRA page to get all the information related to it.  Some tooling might even be built around this simple practice: for instance JIRA will index all the commits refering to a given issue.

Back to our case, so as I develop this new feature on my local Git branch, it happens that this JIRA id is rarely in my commit messages. Either because I forget, either because at the time of the commit I’m thinking to squash it later, etc. So when it comes to push these commits, I need to rebase my branch in interactive mode and manually edit each commit to prepend the JIRA id. Quite painful actually when you have a dozen of commits.

git-filter-branch makes that job in one single command:

$git-filter-branch --msg-filter "sed -e 's/.*/ODE-415: &/'" HEAD~8..

The argument is evaluated in the shell with the original commit message on standard input; its standard output is used as the new commit message. Nice..

No need to say that git-filter-branch should be use with care. The original refs, if different from the rewritten ones, will be stored in the namespace refs/original/.

Here is the problem. I couldn’t understand why the following XML document does not validate against the given schema.

	Something went wrong.

After some investigations and with some friends’ eyes, we figured out that the elementFormDefault attribute was the cause of our troubles. In the XML document the element is in the “ode” namespace but the XML schema sets the elementFormDefault attribute to unqualified. As Michael Kay put it, it “means that you want locally-declared elements like [reason] to be in no namespace.”

Even if “unqualified” is the default value, in most schemas, elements are qualified and I didn’t pay attention to that detail :/

So how does a valid document look like? One could be:

	Something went wrong.

There is no default namespace, so unqualified elements default to no namespace.

Another valid instance document of that schema may look like:

	Something went wrong.

The xmlns=”" declaration overrides the previous default namespace.

This article discusses in more details the raison d’être of qualified/unqualified elements.

I am still to be convinced that unqualified elements could be useful, but now I know that Axis2 generates schemas with unqualified elements and for now on I will make no assumptions on the value of that attribute!

ps: if you know why the XML names get down-cased by the Google syntax highlighter for WordPress, drop me a line please.

It’s dated October 2nd, so forgive me if you have already read it, I’m catching up on my to-read backlog.

YouTube – Wassup 2008.