BloGTK: Blogging on the Train

In this blog post I will explain how this post is written while riding on the train.

I commute a lot. Every working day I ride the train. A single trip takes one hour. This is a nice amount of time to get things done. Reading a book, practicing a code Kata or pondering the big questions in life. Now I can add blogging to this list.

Seeing that I spend a lot of time in a train, it seemed a nice way to create a greater supply of post. Although a promise is made to introduce Internet in trains by the end of the year, I have no Internet connection while I am on the train. So it is not possible to connect to the blogger site and manage my posts.
So I started a search for a blogging client. The search was over quickly. I found BloGTK in the repository.

Unfortunately that version is using a package which is not available in Ubuntu 10.04 - Lucid Lynx. Luckily building from source was a breeze.

So this is the first of many posts while riding the train.

Estimating Collisions in URL Shortening

In this blog post I estimate the time before the first collision for URL shorteners such as bit.ly occurs.

Increasing tweet density

In this post I will summaries the various ways in which I will increase the number of tweets over time.

In a previous blog post, I outlined reasons to start using twitter. Although the reasons I stated there are still valid, it does not help you to tweet regularly.

Since I started twittering, the density of my tweets fluctuated. In this blog post I will outline various ways to produce a steadier stream of tweets. It will be a reminder for myself, if I every find myself in calmer tweet weather.

List of regular tweet opportunities:

• Tweet what you are reading.
• Tweet what you are pondering
• Tweet new admissions to your blog
• Tweet your experiences as a commuter

Although the list isn't very long, it is a start for a steadier twitter stream. Let's find out how it will hold up against time.

Pitfalls of Reflection

In this post I will discuss a pitfall of the use of reflection in Java. Specifically how reflection can obscure and even change the semantics of a piece of code.

What is wrong with the following example of JavaBean naming convention?

public Boolean isCorrect() {
    /* implementation not shown. */
}

Did you spot the capital B on the Boolean return type? According to the JavaBean naming convention the property does not fall under the special rules for booleans and should be named accordingly.

public Boolean getCorrect() {
    /* implementation not shown. */
}

Although there is a sleight syntactic difference, the apparent semantic difference is non-existent. According to William Shakespeare:

A rose by any other name would smell as sweet

Enter reflection. By using reflection it is possible to perform hugely different behaviour depending on the name of a method. The following whimsical example is a clear demonstration of this fact.

Class aClass = ReflectedClass.class;
Method method;
try
{
    method = aClass.getDeclaredMethod("isCorrect");
    protect(Planet.EARTH);
}
catch (NoSuchMethodException e)
{
    destroy(Planet.EARTH);
}

So one of the pitfalls of reflection is the hidden semantics associated with code. Stated in other words: the influence of code can not be inferred by the syntactic definition of that code.

Qwickie: a usefull eclipse plugin for Wicket Development

In this post I will introduce Qwickie, a usefull eclipse plugin for Wicket Development.

In my daily work I develop software applications. As a web framework we use Wicket, a component based framework with a clear separation of the presentation and the logic.

The connection you between presentation and logic is made via "wicket:id"'s. (See the wicket examples page how this is done.) I found myself executing the following behavioural pattern or it's inverse a lot.

1. Seek a wicket:id in a webpage
2. Find corresponding wicket:id in the code

Recently I came across a nice little eclipse plugin which speeds up this pattern. It is named Qwickie, and it facilitates the following use cases:

• Navigate from java code elements to the corresponding html element via wicket:id
• Show the corresponding html fragment from the java code element

Both actions are performed by clicking the wicket:id while holding down the ctrl button. This shaves off time following the association between presentation and logic.

Google Code as Maven Repository

In this post I will explain how to set up a Google code project as a maven repository.

I like Maven. The fact that I can checkout some code and let Maven figure out all the dependencies is wonderful. I know that there are developers out there who will criticize Maven. But in my opinion, a lot of the critique is not really justified.

I also like Google code project hosting. It is very easy to start a project on Google code and have a mature environment for software development.

When I was looking around for a way to publicize my own artefacts I came across the idea of using project hosting on Google code as a maven repository. Because It took me a while to get everything up and running, I will outline the steps I had to take.

As a precondition, I assume a you have a Google code project where you can submit to and a working maven project.

1. Add the Java.net maven repository.
   
   We will be using a plugin which is found on the java.net maven repository.
   

   
     
       maven2-repository.dev.java.net
       Java.net Repository for Maven
       http://download.java.net/maven/2/
     
   
   

   
   
2. Add the wagon-svn plugin
   
   We are going to use the wagon-svn plugin which will do all the heavy lifting for us. Make sure to use the latest version.
   

   
   
       
         org.jvnet.wagon-svn
         wagon-svn
         1.9
       
     
   
   

   
   
3. Come up with a naming scheme.
   
   We are going to create repositories in the svn tree. I propose the following convention. Create a maven directory at the top of the svn tree. This directory will contain a repo directory and a snapshot-repo.
   
   This can be configured in the following way.
   

     
       
         minimal-examples-repository
         Maven Repository for minimal-examples
         svn:https://minimal-examples.googlecode.com/svn/maven/repo
       
       
         minimal-examples-snapshot-repository
         Maven Repository for minimal-examples (snapshot)
         svn:https://minimal-examples.googlecode.com/svn/maven/snapshot-repo
         false
       
     
   

   
   

Now we are all set to start deploying! By running the command maven deploy, the svn-wagon plugin will deploy the artifacts to the repository. The first time you will have to accept the certificate that the Google code project return.
Furthermore, you will have to authenticate yourself with your username and password which are known to the Google code project. You can take up this information in your ~/.m2/settings.xml, so you do not have to enter this information all the time.

  
    minimal-examples-repository
    my_username
    my_password
  
  
    minimal-examples-snapshot-repository
    my_username
    my_password
  

This wraps up the set up for using a Google code project as a Maven repository.

Observation on Binary Trees

In this post I will proof the following observation:

Let \(T\) be a binary tree, \(I\) the number of internal nodes and \(L\) the number of leaves in \(T\) then

\[
L = I + 1
\]

We will proof this fact by observing the following. Every binary tree can be "grown" by replacing leaves with trivial binary tree.

Assume to the contrary that not every binary tree can be grown by replacing leaves with trivial binary trees. Then there must exist a smallest binary tree which can not be grown in such a way. Call it \(C\).
Notice that both subtrees of \(C\) are smaller binary trees. Because \(C\) was the smallest tree which could not be grown, both subtrees can be grown.
But the following description grows \(C\).

1. Take trivial binary tree
2. On the left leaf use the description for the left subtree of \(C\)
3. On the right leaf use the description for the right subtree of \(C\)

This contradicts the fact that \(C\) was the smallest such tree. We are forced to drop the assumption that there exist a binary tree which could not be grown. Therefore all binary trees can be grown.

Now for the trivial binary tree is is clear that

\[
L = I + 1
\]

And when a leaf is grown both \(L\) and \(I\) go up by 1, maintaining the equality. From the above observations one can conclude that the equations hold for all binary trees.