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.