Thomas Sundberg

March 22, 2015

A Gradle plugin written in Java

Filed under: Automation, Gradle, Java, Tools — Tags: , , , , — Thomas Sundberg @ 15:28

Gralde is a build automation system. You write your build script in Groovy. This is different compared to other build system such as Ant or Maven. They both use xml. Using Groovy instead of xml gives you a lot of benefits. You have an entire programming language at your disposal. This mean that you can easily customize the build behaviour.

If you, however, want to be able to do the same thing in many projects, it may be a good idea to write a plugin that you can refer to from other projects. I will show you, step by step, how to implement a Hello World Gradle plugin.


February 28, 2015

When is it automated?

I had a discussion about an automation task that I have implemented the other day.

The task is about automating the deployment of a web application on top of a JBoss. The application is old and we are not allowed to do any improvements at the moment. The instruction is, deploy it as it is at the moment. You will be allowed to do improvements later when you are able to deploy the application smothly.


Gall’s law

Filed under: Software development — Tags: , , , , — Thomas Sundberg @ 15:50

I saw a wonderful reference on Twitter the other day. It quoted something called Gall’s law.

I looked it up and noticed that this seems to be a valid reference made by Dr. John Gall in a book from 1975.


February 16, 2015

Which artifacts do you want when you build a system?

A Continuous Integration, CI, server builds a system every time a change has been detected in the version control system. This is a very common practice and something good. We are able to catch many silly mistakes early. The question is, what should the CI server build? Which artifact should the build produce?


January 30, 2015

BDD with Cucumber-JVM at GeeCON TDD 2015

This blog post is the same as the example I presented at GeeCON TDD in Poznan, Poland, January 2015. It is a step-by-step example that I hope you will be able to follow and implement yourself.

But before I begin with the implementation, let me reason about why you should care about BDD.

Behaviour Driven Development, BDD, is a way to try to bridge the gap between developers, who can read code, and people who are less fluent in reading code. Cucumber is not a tool only for acceptance testing. It is a communication tool where you can express examples in plain text that anyone can read. These examples can also be executed. They are the outcome from discussions between stakeholders, developers and testers.

Given this, the technical part of BDD that I will show you is the less important part. The most important part is the conversations that occurs and defines the application that should be implemented.


December 31, 2014

How do you recruit a good developer?

You are recruiting a new software developer to your team. How can you decide that this candidate is a good candidate?

The only good way I know is to work together. And do it for some time, preferably a few weeks.


November 30, 2014

Hard code first

Filed under: Programming — Tags: , , — Thomas Sundberg @ 20:38

I came across this tweet the other day:

“Novice engineers have not yet grokked this: the number of modes or options in your system is the *exponent* in how hard it is to maintain.” by @zooko.

This is very true. The more options a system has, the harder it is to understand, maintain and use. This is one of the reasons why I usually always try to hard code things like parameters to scripts in my first iteration.

Hard coding is something that some of my colleagues sometimes have a hard time to accept. It happens that the argument is “I don’t like hardcoded things”. I can understand that point of view and I extract parameters when I have got one use case working with a hard coded solution. But I don’t do it before I have something working.


October 24, 2014

Removing the auto generated class header in IntelliJ IDEA

Filed under: Tools — Tags: , , , — Thomas Sundberg @ 15:58

My weapon of choice when it comes to editors is without question IntelliJ IDEA. It is great and behaves as I want and usually expects. It has, however, one feature that I find annoying and that I always remove.

IDEA will automatically insert a header with my user name and the date when I created a new class. I use version control so this information is never important. Adding a user name implies code ownership. Code ownership is against one principle I think is very important, collective code ownership. It is a core principle in XP with the goal to make sure that every developer feels that it is ok to work on all code in a project.

The header IDEA inserts used to include where to find it so you easily could find and modify it. Today, when I set up a new environment at a new customer, I noticed that the template had changed. It didn’t tell me where to find the template. It looked like below:

* Created by ${USER} on ${DATE}.


October 23, 2014

An email marketing system built using test first and Cucumber-JVM

This is the example I implemented at JDD 2014 in Krakow, Poland at my Cucumber-JVM tutorial.

It is a (baby) step by step tutorial. The purpose for me taking baby steps is that you should be able to follow and implement the same things. Be prepared to spend some time with the implementation, it will probably take you a few hours.

Before we dive into the example, let me define what I am aiming for. My goal is to show you how an example (or specification if you want) can be executed. The example is written in plain text and is used to automate the testing of the system I will create. These executable examples can later be relied upon for regression testing and a living documentation.


September 20, 2014

Making life easier with a multi module Maven project

Filed under: Automation, Maven — Tags: , , , — Thomas Sundberg @ 00:02

Working with slow modules in Maven is a problem. People will not build the module as often as they need and they will therefore not find problems as early as they could.

A solution could be to separate some of the slow stuff to a separate module. One separation can be to have a specific module for slow tests. This will, however, not solve the problem, that the module is too slow.

A solution to the problem could be to only include it in the execution when you invoke a specific Maven profile. This would separate the execution of a slow module from the execution of the rest, fast, modules.

Let me implement a simple example with two modules. There is the first module, the application, that we always want to build. It has fast unit tests and it is therefore not hindering to execute it often. Then there is the second module, the acceptance tests. It requires you to fire up your application before it can be executed. It is therefore dead slow. As a developer you will probably only want to execute the acceptance test module now and then.

Let me show you one way to achieve this.


Older Posts »

The Silver is the New Black Theme. Create a free website or blog at


Get every new post delivered to your Inbox.

Join 65 other followers