Accessing native libraries from java

I have been toying around with a small Java project where I have had for long the need to access information about Windows (tm) controlled windows from my Java application. Also I sought after the ability able to use Window's own 'native' graphical libraries.

For long I thought I would be doomed to write my own native methods in c++/c# and use JNI to access them from Java. I haven't coded c++ for years. Thus the project stalled badly and I didn't pay attention to it for almost a year.

However yesterday I ran into some nice looking libraries that would make it much more easier for me. Both of them have kind of a similar approach where a native library can be exposed to java by creating an interface class with some native methods. The native libraries return and parameter types are automatically marshalled by the libraries too.

Of course there is some manual stuff that needs to be done, but both of them look quite nice and enable one to do quite nice things. For example have you ever seen a java window like this:

Shaped Window Demo from JNA's site

JNA (Java Native Access) seems to be more finished, has support for native libraries of Linux (x86), Mac OS X (PPC and x86), and w32+gcc and has more features than NLink. But be sure to check both!

Blog reopened!

Here and now I reopen my blog after being in the blogging void for over a half a year. Welcome back.

We had some problems with the blogging software Pebble at the open source commonity LaughingPanda which hosted my blog some time ago. We decided to drop pebble and the blogs from LaughingPanda and people started moving migrate their blogs elsewhere in the blogosphere. However I didn't seem to have the time for that then.

Coding Dojo - time to refactor?

Yesterday we held a coding dojo at our office. This time we were supposed to code a sudoku game (without GUI). There were some new things that were tried, like having a product owner, and dividing the coding time to iterations. This time we had a group of 14 or so a good many more than in the previous one I attended where only 6 people were around.

To tell you the truth, this coding dojo session was very much alike the previous one I attended, with the exception that more people was present. Again a lot of time was spent on discussing elementary TDD issues. This is good and bad thing. TDD is such a good programming mindset that it is good to discuss about it in depth. However the Coding Dojo should not be solely about TDD. The Dojo should be about learning, but unfortunately I don't think I picked up too many new things from this session (the retrospective on how to improve the dojo was good though! :) ).

The reason the discussions revolved around the exact same topics was partly due, in my opinion, to the fact that the project was started from scratch and everything had to rediscovered once again (test naming conventions, test granularity). I also think that the simplistic coding challenges we have had encourage the same discussions too.

Don't get me wrong. I think TDD fundamentals are very important and everybody (even the most seasoned TDD practicioners) should take a frequent look at how they implement the fundamentals. However as even for the TDD I would like to have varied discussions on many of the more specific topics we haven't yet touched - mocking, GUI testing, test separation, acceptance tests, data tests etc.

I think it would great if we coded something that could be used in the contexts of the dojo. Creating something useful would probably align the mindset of the attendees a bit and the discussions would be probably a little different. --- Since this time didn't find a timer to keep time for the programming pair, I suggest that we write an eclipse plugin (or ruby app or whatever) to do that. This is not too hard of a programming challenge, and might pose also some more real life problems and techniques for the attendees to talk about.

As Bas Vodde pointed out the code we produced was not really of good quality and almost looked like legacy code (atleasts the tests) already immediately after being written. I think this was partly due that people were not reflecting on what they had written or what the previous pair had done. It takes disclipine to refactor and in a such a short time frame it takes even more. One might want to make progress (and there's even time pressure for it) during one's turn and not just refactor the previous pairs code. It's human, but some more attention might be spent on that. In the retrospective we had we talked about having more time for the pair (like 10 minutes for the pair and then change the pair fully), that would probably be better since the pair would have time to refactor their code.

One more point. For future dojo's I think it would be imporant at the beginning of the dojo (or on the dojo announce page) to set objectives for the session so that everybody would know what's important for the session. All the dojo's I've been in have had implicintly been about TDD, but the dojos could have some other goal/topic too like learning Eclipse RCP, pair programming, refactoring (we could have project we start to refactor) or oo principles (open-closed principle etc).

Daily Team Builds

This year I was again at the JAOO conference in Denmark. Even though I didn't blog anything from the site there were many things I picked up from there.

However, the idea for the practice titled in this blog post came to being from a discussion we were having together with Jakub, a collegue of mine from Reaktor, about agile teaming aspects at our hotel's bar. Jakub had an idea about having the team members reporting their 'daily build' status during the Daily Standup/Scrum meetings.

The 'Daily Team Build' goes as follows. Each of the team members would in turn show out either a red or green card. Green card would mean that the member is doing fine (has a good feeling, nothing major is bugging, has been productive). Red card on the other hand means that there has been major blockers, stress, useless meetings or something else that is causing the team member trouble. The Red card portrays something that the team (and the possible scrum master) should solve as soon as possible to get the team members productive. If the card were red the member should also write on the card why the card is red, so that we can keep track of things that have been bugging us.

The cards would then be posted on some visible place to show how has the team been. Cards show out a status of the team during each of the iterations days. Like a continuous integration build, you don't want your team build to show red. If there's some red then there's something urgent to fix.

I think this is a very good supporting practice because:

• Issues that hinder the team's productivity back are made visible, thus helping in continuous improvement.
• Feedback is given about changes in the team's environment.
• It provides very valuable information for the team's retrospectives/reflection workshops.
• It helps to spot recurrent and time-dependent problems (for instance problems during sprint planning, end-of-sprint problems).

Here's a picture of the Team Build for our team's ongoing sprint.