Learning Language Categories

In this blog post I will advocate to learn new language categories instead of new languages.

Every once in a while you find a post on a forum addressing the question which new language should one learn. Notable examples can be found by googling. Here is a sample:

• What programming language should I learn?
• 10 Programming Languages You Should Learn Right Now
• What programming language should I learn?

In my opinion, growing as a developer is not about specific languages. If this was the case then why does nobody suggest C# if one knows Java or vice versa? Seldom is such an advice given. But if it is all about learning languages then this advice should surface as often as any other advice.

I think that language categories are more important then languages. One reason to learn a new language is to broaden your horizon. By seeing new solution to old problems your problem solving toolbox grows. Even if it is not possible to apply the language directly it often is possible to adopt the idea. By going beyond a language category barrier, the novelty and creativity with which problems can be solved grow enormously.

So the next time the question "Which language should I learn next" is asked, go ahead and advice to learn a new language category.

Launch Configurations in Eclipse

In this post I point out where Eclipse is storing the launch configurations.

After a fresh install of my laptop I wanted to restore the launch configurations of Eclipse. After some searching I finally found the location. I am reporting it here for future reference.

The eclipse launch configurations can be found in your workspace at

.metadata/.plugins/org.eclipse.debug.core/.launches

Null Object Pattern

In this post I will summarise the Null Object Pattern.

The null object pattern is a means to forgo null checks. The following example will be used to explain how the null object pattern can be used to reach this goal.

public Person getPerson()
 {
  return person;
 }

 public void showName()
 {
  Person person = getPerson();
  String name = "unknown";
  if (person != null)
  {
   name = person.getName();
  }
  System.out.println("name: " + name);
 }

In my opinion a few there are thing wrong with this code.

• Different call flow. Because of the null check there are two possible paths through this code. If this is the only point at which this occurs, it would not be a big problem. But
• Caller is responsible. The caller is made responsible to check if the returned value is correct. By placing the burden at the callers side probably means a lot of duplicate boilerplate code in checking for null values.
• Error prone. You only have to forget the null check once and it will blow up in your face with a NullPointerException.

The null object pattern is a means to remedy these points. In the following example I refactored the original code.

class UnknownPerson extends Person
{
 @Override
 public String getName()
 {
  return "unknown";
 }

}

 public Person getPerson()
 {
  if (person == null)
  {
   return new UnknownPerson();
  }
  return person;
 }

 public void showName()
 {
  Person person = getPerson();
  System.out.println("name: " + person.getName());
 }

With the introduction of the UnknownPerson all the mentioned problems are solved.

• Same call flow. The calling code does not have to differentiate between a null value and a legitimate value
• Callee is responsible. The callee is now responsible to check if the returned value is defined. By placing the burden at the callee side there is a single check so no duplication of code. So
• Less error prone. Because the null check is in a single location there are less oppertunities for making a mistake.

This summarises the null object pattern.

Introduction to Software Development - Part 2

In this blog I will outline the second instalment of the introduction to software development I had with a friend of mine.

In a previous post I told the story of introducing software development to a friend. In this second run, we took on a little project to hone our developing skills.

We looked into Mancala. It is a game in which stones get sown around the board. The exercise was meant to develop a feel for architecture.

We had a lot of discussion about responsibilities. Which object should be responsible for a certain task? I think that the question of responsibility is a very good to get your bearing while developing an application.

In the subsequent meeting we will finish this little project.

Introduction to Software Development

In this blog I will outline how I introduced a friend to the art and craft of software development.

A friend of mine got interested in software development, but was not quit sure how to start. Because I have a strong opinion what constitutes "good" software development skills, I offered to guide him in his explorations in software development. This blog summarizes the first day of guidance.

In my opinion a software developer is not tied down to a single language. But an aspiring developer has to start somewhere. The language choice was made on two grounds: my own familiarity with languages and it's popularity in the field. We settled for Java.

After downloading the appropriate software development kit and setting up the PATH variable we could really start. I created the conical "Hello World!"-example using only a rudimentary text editor and the command line. We build upon the example by introducing the following concepts

• Introduction of a package
• Separation of source- and class-files
• Introduction of the classpath
• Objects

After this bare-boned example we set out to install an integrated development environment. I loaded the die in favor of Eclipse. After downloading and installing Eclipse I challenged my friend to reproduce the command line example. By emphasizing steps which are easer with the help of the IDE, my friend quickly reproduced the afore mentioned example. The following step was the introduction of test driven development. I showed my friend how a test can be used to guide the development of a new feature. Afterwards I explained him the virtues of test with respect to refactoring. The example was extended by writing test and constantly refactoring, thereby introducing the following concepts.

• Inheritance
• Method overloading
• Interfaces
• Abstract classes

The next step was to introduce version control. My friend could easily motivate the need for some form of version control. In the end we settled for subversion as our version control system. We downloaded a subversion client and extended the PATH variable. I showed him how the command line can be used to version a file, but we quickly installed a Subclipse. Along the way we created a google code project which now hosts are first steps. Guided by tests and committing our progress we enhanced the example with

• Commit often, Commit Early
• Command line arguments
• Alternate output streams
• Mocking

In the end I showed my friend coding katas. The main goal was to introduce a means to hone his programming skills without my presence. The secondary goal was the introduction of maven as build to. We agreed to do an other session. As a homework assignment my friend would do a kata a day, or more if he likes to. I pointed out "Head First Java" as a good book to learn Java.

This wraps up the summary of the software introduction I gave to a friend.

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.