I will for sure miss the massive input and inspiration this conference gives me and enables me to keep up-to-date on everything that is happening in the Java Community. This year’s conference is also special since it is the first time Oracle is hosting the show. It feels like a good idea to co-host it with Oracle Develop and I hope it will be a success to be continued. Next year, I will definitely be attending, one way or the other…!

Tweet This Post

Tweet This Post

So far, nothing new. The practice of a short stand-up synchronization meeting is pretty well established and non-disputed.

What if you have a team that is distributed not only in distance, but also over different time zones?

Which time zone should be used as basis for determining when to have the meeting? Usually the project it ends up being run by the project manager’s (*) watch. That means that the team in the other end probably will have the meeting in the afternoon. A pretty usual distributed team setup in Europe nowadays are something like this:

Europe: Project manager, architect, test manager
Offshore (China or India): Lead developer, developers, testers

That means that the largest part of the team, the team that actually are doing most of the work are having the daily scrum at a less optimal time of the day than the project management. I think that to really succeed with distributed agile development, you have to let the team decide how to work even if this implies awkwardly timed daily scrums for the project management. Of course, this applies to other aspects of the development process as well.

(*) …or Scrum Master if you prefer…

Tweet This Post

JNI WARNING: method declared to return 'Ljava/nio/ByteBuffer;' returned 'Ljava/nio/ReadWriteDirectByteBuffer;'
... ;.nativeAsBuffer ('Ljava/nio/ByteBuffer;' not found)

The simple workaround is to add the following to the onCreate method of your main activity:

ByteBuffer dummy = ByteBuffer.allocate(0); dummy = null;

This way the classloader is “forced” to load ByteBuffer. This is not needed when running on a device, only the emulator as it seems.

Tweet This Post

If you are setting up the development environment for Google Nexus One in Linux by following the instructions on Android Developers you will probably notice that the the device is not listed in vendor id table. One could believe that it could be the same ID as HTC since it essentially is a HTC device, but that is not so. Google has given it a vendor id of its own (’18d1′). Why it is not listed here is a mystery, but anyhow; this is how you solve it:

Add the following line to /etc/udev/rules.d/51-android.rules
(If the file does not exist, create it.)

SUBSYSTEM=="usb", SYSFS{idVendor}=="18d1", MODE="0666"

Restart udev:

sudo reload udev

Then unplug/plug the device, and you should be able to see the device by running

adb devices

Tweet This Post

The solution is as simple as you would expect when you have used NetBeans for a while. Add the following to the build.xml file in the project root (replace the dummy values for the signjar target):

<target name="-pre-jar">
   <copy todir="${build.classes.dir}">
      <fileset dir="${external.libs.dir}">
         <include name="*.jar"/>
      </fileset>
   </copy>
</target>
<target name="-post-jar">
   <zip update="true" destfile="${dist.apk}">
      <zipfileset dir="${external.libs.dir}" includes="*.so" prefix="lib/armeabi"/>
   </zip>
   <zip destfile="tmp.apk">
      <zipfileset src="${dist.apk}">
         <exclude name="META-INF/*.*" />
      </zipfileset>
   </zip>
   <move file="tmp.apk" tofile="${dist.apk}" />
   <signjar jar="${dist.apk}" alias="alias" storepass="secret" keypass="secret2" keystore="my_keystore"/>
</target>

You also need to add external.libs.dir=<your lib folder> to you <project root>/nbproject/project.properties file.

Now you can install the resulting .apk file using adb install or by running/debugging directly from NetBeans. Remember to follow the tip for asset-files in a previous post if you have that kind of resources.

Tweet This Post

The solution is:

1. Go into nbproject/project.properties and add ‘assets.available=true‘

Voila! You will now be able to run, debug and step through your code as you would expect.

Tweet This Post

The Limited WIP Society is a great place to start finding information about Kanban.  You can also find lots of useful information at http://www.crisp.se/kanban.

Tweet This Post

After a discussion with a colleague at a coffee break this morning, I decided to try out Google App Engine. The getting started guide is a great place to start. It gives you a great walk-through setting up the development environment and creating a sample application. Since I am no big fan of Eclipse, I installed the Google App Engine Plugin for NetBeans. After resolving a small issue regarding path settings (see solution here), it was up and running perfectly.

Next steps will be to figure out what changes that has to be made to my existing applications to be able to deploy them on app engine. Probably the server side of YouOweMe will be the first candidate. Or maybe the KanbanFX server. I haven’t decided yet…

Tweet This Post

At first, I was skeptical to the whole idea thinking it would generate an overload of noise for a couple of weeks until dying slowly like most initiatives to share knowledge within companies. But after having thought about it, I really hope that will not happen. It is actually a brilliant way of building a knowledge base within the company. Everyone who has tried to establish some form of knowledge exchange know how hard it is to get people to contribute.

But by “hiding” it behind some familiar technology like twitter, people actually contribute without knowing it. If you think about it, only the things people are interested in will be posted and discussed in such a forum. People will only put energy in discussions they have strong feelings for. The things most people have feelings for are probably pretty relevant things for your organization. And it is by default fully searchable with the newest items most visible.

So with my limited experience of yammer (have used it two days), I will conclude that it is actually a good thing. Now we just have to hope that it does not die a silent death when it is not that new-and-cool anymore…

Tweet This Post