Skip to content

The eclipse setup

Ok, so if Eclipse is the tools of your choice, what should you install?

Version handling

For subversion, use the subclipse plugin from tigiris. I have been having som problems of merging branches back to trunk, and sometimes it gets out of sync, but it works ok.

If you have problems, download and install tortoise, and use that for merging and branching.


Use the M2 plugin from Sonatype.


I do some PHP development on my spare time for a friend´s site. For that, I use the PDT plugin.

PDT is already available in Eclipse Helios. Just choose to install new software (from the ”Help” menu), and choose the Helios update site. Choose software and then scroll down to PDT.

Posted in Tools.

Tagged with , , , .

Java forum 10/11

New testing framework:


Java packaging

Shrink Wrap

Test environment in the cloud:

Steam Cannon

Posted in JavaForum.

Tagged with , , .

Writing a good, selling, CV

Writing a good, selling CV isn’t just about describing your earlier assignments and what Java API:s you know fluently. You need to sell yourself. Here are a couple of good tips.

I will not go in on how to structure the CV, I assume you have some kind of template to begin with. But the structure should have the basic format of an introduction to who you are, the technologies you know, and your assignment history.

The introduction

First of all, you need to identify your strengths. What is it that buyers of consultancy services should notice about you, to make their eyebrow raise just that extra millimeter to make them choose you over the other 50 or so CV:s the buyer has in the stack?
So begin with writing down your strengths and what message that you want to deliver with your CV. Are you an expert in pair programming? Are you the perfect Scrum master that isn’t afraid of getting your hands dirty?

Change the heading of your introduction from “Introduction” to something more unique. And don’t be modest.

After you have changed the heading, fill out the introduction with your strengths. It is important that you describe your strengths in combination with what it means for the buyer. Write it in a format like “because of my… makes me…”, e.g “Since I have deep knowledge in Java EE and JBoss, I will hit the ground running.” Keep doing that for all of your strengths. N.B. don’t write more that 3-4 strengths.

The assignment summary

Make sure that the descriptions of what you have done in your earlier assignments are aligned with the message you want to come across in your summary. If it is TDD expert you want to sell yourself as, make sure your TDD experience shows clearly in the assignment descriptions.

Describe the latest two or three assignments. Keep the rest very brief, just a sentence or two. The whole CV shouldn’t be more than maximum 5 pages.

Some short pointers:

  • Write in first person, not third, i.e. I did this and that, not Mikael Brodd did this and that.
  • Short sentences.
  • Avoid “but” and “not”.
  • Write with a positive feeling.
  • Have guts. Dare to use a couple of stronger words in your description of yourself, e.g. “I am passionate about…”.
  • Make sure that just the relevant information is listed. Remove everything else.

Summing up

The CV is not an exception to the laws of rhetorics. Introduction – Body – Summary works here as well. Make sure you know what you are good at and make that shine throuh the whole CV. And make sure to describe what your strengths mean to a buyer. If you do that, your CV is in good shape for the next time you need a new assignment.

Posted in Sales.

Tagged with , .

Know me, like me, trust me

Being an IT-consultant is not just about creating great software, it is also about finding the great assignments. That means sales. Every IT-consultant need to know something about selling themselves and their colleagues. This is what I learnt in today’s half day seminar.

Being an IT-consultant, you need to understand the customer’s needs, identify what needs to be done and find your own commitment to the assignment. Be an advisor to the customer, not a used cars salesman.

7 out of 10 customers changes supplier due to the fact that the customer feels that the supplier has lost interest in them, a lack of commitment. So you need to make the customer feel that you are committed to them, that you care about them. Don’t forget to build your network during your assignments, and regularly meet with, perhaps the top 25 of your contacts.

Try to get proactive recommendations. A proactive recommendation is for instance at the end of an assignment, when summarizing, an idea could be to ask if there is another project/department/organization that they know of that are doing something similar to the project you attended. If so, try to get recommended to attend that, or get to speak with them. Make sure that you can use someone as reference.

90% of decision made, are made by the gut feeling, and not by logics. But after we have made the decision, we tend to justify the decision with logical reasons.

IT-consultants, especially engineers, are good on describing characteristics when describing why a customer should by from them. But looking on the statement above, if 90% of the decisions are made by listening to feelings, we need to get better on describing the effect of the characteristic instead.

Consider the single mom that wanted to buy a new car in the beginning of the 80’s, when Saab had invented the turbo. The car salesman says “this Saab is something for you, it is equipped with a turbo!”. The single mom does not understand what that means.
So the sales man explains that it means that it has more horse powers. The single mom does not understand why she needs that.
So the really good car salesman says “I have the car for you, this Saab is equipped with a turbo. That means that you will get more horse power, which means that you can make safer overtaking”. The really good salesman has explained the meaning of the characteristic. In Swedish it is called E(genskap), F(ördel), I(nnebörd).

The first meeting with the customer

Make sure that you come prepared. Know the basic facts about the customer, size, number of employees, who is the CEO, etc.
Prepare questions so that you can find out the following

  • Are you speaking with the person that is capable of making decisions, the decision-maker?
  • Find out why the customer wants to do the project/build the system. How will it become useful for them?
  • Do they have a budget for the project/system?
  • What is the time plan? When will the make the decision?
  • Next step – when will we meet again or when can I call you?

Show commitment – lean slightly forward, use paper and pen. Listen to what the customer says. Keep the initiative. It is you that are running the meeting, since you want to get the answers to the five bullets above.

Introduction (5 min.)

Be polite, make an impression. Express your gratefulness for having the opportunity to be there. Go through the agenda of the meeting. Then run the elevator pitch.

The needs assessment (35 min.)

Ask questions that leads to answers of the five bullets above, decision-maker, usefulness, budget, time plan, next meeting.

Begin with open-ended questions, “why”, “how”, “can you describe…”. These type of questions gets the customer speaking. Then you can use more specific questions, “would you be interested in…”, “do you plan to…”. Then use closed questions, that easily can be answered with a yes or no answer.

Presentation (10 min.)

Describe what you can do for the customer, who you help (other customers), what benefits you can offer, references, success story, a sample of what you can deliver. Adapt the presentation to what you have learnt during the needs assessment

Wrap-up (10 min.)

Describe the current situation, describe the improvements you have heard that the customer needs, describe the time plan.

Posted in Sales.

Tagged with , .

The Pragmatic Programmer – from journeyman to master

The Pragmatic Programmer – from journeyman to master, written by Andrew Hunt and David Thomas in 1999, is one of all of these must-have-read books. But do you really need to read it?

The book contains loads of tips within system development, ranging from how you should act and be as a professional, what tools to use, how to program, to how to manage projects.

The book can be read from cover to cover, but is really intended to be an encyclopedia, where you look up the tip that suits the current situation where you need help.

It is quite clear that the book has been around for more than 10 years, as some of the tips feels outdated. For instance, in the tips about running a project, agile or XP per se isn’t mentioned, but you can feel the essence of them both in the writing. The tools mentioned in the book can feel a bit old, as for instance for unit testing, but there are also tools that never get old, e.g cygwin.
The book needs updating, but loads of the tips are very useful today as well, and as a senior developer, you should be practicing most of them.

So do you really need to read the book? Yes. I definitely recommend this book to not so senior developers, and also senior developers will find useful tips in the book as well.

Posted in Books.

Unit tests with Mockito

Mockito is a nice unit testing framework for Java. Looks very similar to easyMock, and the early versions of Mockito built upon easyMock. I used Mockito for creating unit tests with Wicket, mostly for handling server calls. Per Lundholm has written a blog about Mockito and Wicket.

I haven’t really gone into the depths of Mockito yet, but anyway…
Mockito follows the pattern

  1. Choose class that is giong to be mocked.
  2. Choose method that is going to be mocked.
  3. Decide what is supposed to happen when the mocked method is called.
  4. Validate that the mocked method actually has been called (unneccessary if you are making a stub).

First, I created an @Before method that initializes the class that will be mocked. This is only neccessary if it is always the same class that should be mocked.

public void setUp() {
mockedIfc = mock(serverInterface.class);
MySession session = (MySession) tester.getWicketSession();

”tester” in the example above is an instance of Apache WicketTester.

Next, you create a test case. In this test case I am expecting that an exception will be thrown.

public void testCreatePreviewPageException() {
   MyDocument doc = new MyDocument();
   PreviewPage previewPage = new PreviewPage(coc);

   when(mockedIfc.getPreviewForDocuemnt(doc)).thenThrow(new DocumentNotFoundException());
   tester.assertContains("No preview exist for Document");

First, create some temporary test data. After that, decide the behaviour of the mocked method. In this case, it is decided that ”when method getPreviewForDocument(doc) is invoked, then throw DocumentNotfoundException()”.Very clear and obvious code.
The code becomes this obvious by a static import of org.mockeito.Mockito.*.

Next, let Apache WicketTester start the page (PreviewPage). The page then calls the server with getPreviewForDocument(). Mockito awakens and returns a new DocumentNotFoundException(). Ths test asserts that an error message has been rendered on the page.

The last verification is actually unneccessary, since we got the expected exception, we do not need to verify that the method has been called.

Posted in Programming, Test, Wicket.

Tagged with , , .

JPA entities can be persisted anytime

You can never be really sure of when a ”managed” object (managed by a JPA implementation) will be stored.

The tricky part could be a situation when you need to get data from the database and compare the result to a managed entity of the same type. If the compared entity is is changed, ”dirty”, it is most likely that the JPA implementation stores the changes before the database access occurs.

In my case, I had a managed entity that had a changed attribute. As the attribute had a unique constraint in the database implementation, I wanted to know if the attribute was ok to use without persisting and getting a JPA-exception. But, that isn’t possible as when I made a SELECT, JPA persisted the entity. The solution is to check the attribute before the entity is changed.

Posted in Programming.

Tagged with , .

WicketTester creates a new session if the session object is changed

When a Wicket application is tested with JUnit, and the WicketSession is needed, please be observant on the bug in Wicket 1.4. The bug creates a new session object if the old session object is changed.


public class MySession extends AuthenticatedWebSession {

private static final long serialVersionUID = 4684212806282900843L;
private MyCustomObject customObject;

public MySession (Request request) {
this.customObject = new MyCustomObject();

public void setHomePageInstance(HomePage homePageInstance) {
this.homePageInstance = homePageInstance;

To unit test this class a session is needed. It seems obvious to initialize a session object in the @Before-method. Here is an example.

public class SecurityTest {
protected static WicketTester tester;

public void setUp() {
tester = initTesterOmniUser();
// Set HomePage instance
MySession session = (MySession ) tester.getWicketSession();
session.setHomePageInstance(new HomePage());

public void testSearch() {
//setUp is already run. Submit button requires a session
tester.executeAjaxEvent("searchPanel:searchForm:formSubmitButton", "onclick");

In the above example the unit test testSearch needs a session object. But because of the bug, a new session object (instance) is created when the attribute in the session is changed (on the row session.setHomePageInstance(new HomePage()); ).
Read more about te bug here.
To work around the bug, add the row tester.setupRequestAndResponse(); before the attribute is changed. Example:

public void setUp() {
tester = initUser();
// Set HomePage instance
MySession session = (MySession ) tester.getWicketSession();
session.setHomePageInstance(new HomePage());

Posted in Wicket.

Tagged with , .

Bootstrapping projects – recruitement

A lot of things needs to be right if the project will succeed. One of them is that you need the ”right” people in your team. So who are they?

A good analogy is that they should be ”T-shaped”. I.e. they should have specialist knowledge in some areas, and they should also have some knowledge of the rest. This broad experience (but not so deep) is neccessary to have the persons in your team being able to help each other finishing user stories.

Look for instance at a developer. When all development is done on a story, but the story itself isn’t done yet, the developer should feel comfortable enough to help the others finishing the story, even if it is not the persons main line of work. He could help with fixing test data, pair program with a GUI-developer, etc. This is very important to get a good feeling in the team.

When recruiting people to your team, make it clear how your Scrum team is working.

  • The kind of follow-up that is done (daily stand-up, planning meetings, etc.)
  • Where the Scrum board is and how it is used
  • How estimation of user stories is done (story points, T-shirt sizing, etc)
  • How user stories are broken down to activitites (if at all)

It is also important to clarify your expectations from the person when in the team. Think about details as for instance

  • Meeting (be on time, bring calendar and note book)
  • Company policies, how to behave, etc
  • Commitment
  • etc

    If the person doesn’t agree on your way of doing things, may it be right or wrong, it doesn’t matter how good he/she is. You will always end up in discussions of why certain things are done, instead of them just being done.

    One idea is to create a recruitment scenario. In the scenario you describe a fictious project, together with a couple of questions you want the recrutee to answer. If you are recruiting a programmer, why not add a programming assignment? You could perhaps do some pair programming at the interview so that you get a feeling of how the recruitee thinks about programming.

    The recruitee naturally gets the scenario in advance, so that he/she can be prepared.

    Posted in Bootstrapping projects.

    Tagged with , .

    All that’s mine is yours…

    A situation that very often occurs in a team is misunderstandings about who is responsible for the development enviroment, e.g. things like test servers, correct test data, continous build server and so on, if you don’t have a person appointed.

    So, who’s job is it?

    In a large company there are usually policies that describes what tools to use. But it is seldom easy to get started. Just for the test environment, you need control over things like

    • Version of operative system
    • Type and version of web browser(s)
    • Type and version of web server
    • Type and version of application server (or servlet containers as Tomcat)
    • Type and version of database
    • Version of the built system
    • Version of test data

    In Scrum, it is the job of the team to solve all environement issues. But not all people are suited to do the environment stuff, and there can be a lot of stuff to do. In such a case a recommend letting those who work a little more dedicated to a role handle the environment that they need. So the testers are responsible for keeping the test environment up to date, having correct and enough test data, know what version of the system they test, know how to install the system to the test environment, etc. Of course it is ok to ask others for help.

      Make sure that you make this clear in the beginning of the project to save some time and headache.

      Posted in Leadership, Organization, Test.

      Tagged with , , .