Lessor app is out

The Lessor app just made it to the Android market. Check it out!

Published with Blogger-droid v1.7.4

Android Tutorial GOTO Århus

Link to files at the Android Tutorial, GOTO Århus 2011:

https://docs.google.com/#folders/0B_C0TFg2y2ezYTYyMTlmM2MtYzY0ZC00OGIwLWFlNTctYTFmMTJiYWQ5OTlk

Or if you do not have a google account:

http://dl.dropbox.com/u/20657490/androidtutorial.zip

And the slides:

http://dl.dropbox.com/u/20657490/GOTO_android_tutorial_presentation.pdf

A solution for Hands-On 1-5 (minus extras):

http://dl.dropbox.com/u/20657490/androidtutorialsolution.zip

Wicket Webinar

Did a webinar on Apache Wicket recently for Dansk IT - slides are here...

It is an odd way of presenting. You are basically just looking at your screen while talking - not much in the way of interaction with the audience. On the other hand, it is a fairly easy way to reach people you would normally not get out to because of geography so it will probably not be the last time I try this.

Don't Think - Just Write Tests, Right ?

I gave a brief talk on Continuous Integration at the local Java User Group a few weeks ago and I happened to mention that although I value automated regression testing very much I do not think it gives you any real guarantees that your software is error free.

I think this provoked some in audience a bit - I got questions along the line of "why do you hate unit testing so much?" and I realized that I unwittingly had stepped on some toes there. Sorry guys, I hope we are still friends.

Yes, I am a sceptic but for the record: I don't hate unit testing and I certainly do not think that people who do unit testing are idiots.

What I do have a problem with are when people set up their test suite, complete with red light for errors, green light for no errors - and then conclude the following:

• Red light: there is a bug in the application code
• Green light: there are no bugs in the application code

I think this assumption is incredibly naive and will try to explain why.

Your test system consists of two components: The application code and the test code itself (junit test cases, mocking etc.). Software bugs can be present in either component. This should be a known fact to anyone who have been working seriously with automated testing.

Consequently, red light means you have either

• A bug in your application code
• OR you have a bug in your test code!

I admit that this is very useful information and it also gives you an idea about where the problem lies - it is either in the code being tested or in the test itself.

Green light on the other hand is much more tricky. Really, all it tells you is that

1. You have no bugs anywhere...
2. OR .. you have a bug in your application code but the test that was supposed to cover it is faulty as well!
3. OR .. you have a bug in your application code that is not covered by a test

When we see the green light we want to believe that we are dealing with case #1 - no bugs. But we really have no way of knowing this for sure.

Case #2 is fairly common in large test systems and is generally detected by someone else down the line - either QA or the end user. How do know that your test code is error free anyway? Are you writing unit tests to test your unit tests? And if so, are you also testing the test code that is testing the original test code... ?

This brings us to case #3 which has to do with test coverage. Yes, you can minimize the case 3 bugs by writing more tests. There is a catch, however: All the new test code you write could potentially have bugs, thus introducing more of the case #2 scenarios.

If you have ten lines of test code for every line of application code it means that there is a ten times higher risk of bugs in your test code. There is some powerful mathematics working against us in our attempt to achieve a full, error-free test coverage.

Integration testing is a way to test more lines of application code with less lines of test code but the same principle applies: As your test suite grows, so does the likelihood of having bugs in the test suite.

All this doesn't mean that you should stop doing automated testing. What is does mean is that you should look at your test results with a certain amount of scepticism. A failed test means you have a problem - either with your application code or your tests. No failed tests just means that there are potential undetected problems out there. And the way to solve these problems may not be to just blindly write more test code. Don't fire your QA people just yet.

SFTP in Java with JSch Using Private Key Authentication

JSch is an excellent library for ssh in Java. One bad thing is that there is no real documentation - or rather, the source itself is the documentation. And the good news is of course that the source code is available along with a nice collection of examples.

I recently had to use SFTP from a Java application and it did take some source-diving to figure out exactly how it works (specifically to get the parameters for JSch.addIdentity right). It turned out to be rather straight-forward:

    ...

    private void execute() throws JSchException, SftpException {
        JSch jSch = new JSch();
        final byte[] prvkey = readMyPrivateKeyFromFile(); // Private key must be byte array
        final byte[] emptyPassPhrase = new byte[0]; // Empty passphrase for now, get real passphrase from MyUserInfo

        jSch.addIdentity(
            "myusername",    // String userName
            prvkey,          // byte[] privateKey 
            null,            // byte[] publicKey
            emptyPassPhrase  // byte[] passPhrase
        );
        Session session = jSch.getSession("myusername", "hostname.com", 22);
        UserInfo ui = new MyUserInfo(); // MyUserInfo implements UserInfo
        session.setUserInfo(ui);
        session.connect();
        Channel channel = session.openChannel("sftp");
        ChannelSftp sftp = (ChannelSftp) channel;
        sftp.connect();

        final Vector files = sftp.ls(".");
        for (Object obj : files) {
            // Do stuff with files
        }
        sftp.disconnect();
        session.disconnect();
    }

    ...

The MyUserInfo class must implement the UserInfo interface. There are a number of good examples of this in the jsch distribution.

Lean and Metaphors

A criticism of Lean Software Development is hard to find. While I think it offers a number of useful ideas and tools, I am somewhat sceptic towards the widespread use of metaphors from manufacturing found in Lean Software Development: An Agile Toolkit.. and elsewhere.

Metaphors are powerful in the way that they allow us to transfer insights from one area of experience to another. However, for these insights to be valid it is required that the metaphor has the same characteristics and dynamics as the system it is supposed to model. Or to put it more bluntly: Lean will solve all your problems to the extent that your software development organisation is like a manufacturing plant...

It is not all bad, though. The assembly line model may fail to capture all aspects of software development - but it does bring issues such as queues and waste into focus and provide a framework for discussing and adressing them. So even if Lean is not the final answer to everything it remains a useful tool for certain applications.

However, if software development is a field in its own right why do we then always have to use metaphors and analogues to describe it? It is clear that there is much to be learned from viewing software development as .. well, software development.

.NET Class Generation - Delegating Object Properties

In a recent assignment I had the need for a dynamically generated class that - among other things - could be generated with a field of arbitrary type and delegate the properties of said field. In other words something like

public class MyWrapperClass : MyParentClass
{
private ObjectType _WrappedObject;

public ObjectType WrappedObject
{
    set { _WrappedObject = value; }
}

public string Field1
{
    get { return _WrappedObject.Field1; }
}

public int Field2
{
    get { return _WrappedObject.Field2; }
}

// ... other stuff
}

where ObjectType can be any type and MyParentClass is a base class.

Fortunately, .NET reflection and class generation is pretty straight-forward. Generating the class itself requires an assembly, module etc.:

AppDomain appDomain = Thread.GetDomain();
AssemblyName assemblyName = new AssemblyName();
assemblyName.Name = "MyAssembly";
AssemblyBuilder assemblyBuilder
= appDomain.DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.Run);
ModuleBuilder moduleBuilder = assemblyBuilder.DefineDynamicModule("MyModule");
TypeBuilder typeBuilder
= moduleBuilder.DefineType("MyWrapperClass", TypeAttributes.Public);
typeBuilder.SetParent(typeof(MyParentClass));

The field holding our wrapped object must be declared to be the same type as the object to be wrapped

private ObjectType _ObjectToBeWrapped

This can be done with the following code:

Type objectType = wrappedObject.GetType();
FieldBuilder wrappedObjectField
= typeBuilder.DefineField("_WrappedObject", objectType, FieldAttributes.Private);

We will also need a setter for the object

public ObjectType WrappedObject { set { _WrappedObject = value; } }

And this requires some IL code generation:

// Create property ObjectToBeWrapped
PropertyBuilder wrappedObjPropertyBuilder
  = typeBuilder.DefineProperty("WrappedObject", PropertyAttributes.None,
  objectType, null);

// Create property setter
MethodBuilder wrappedObjSetBuilder =
  typeBuilder.DefineMethod("set_WrappedObject", MethodAttributes.Public,
  null, new Type[] { objectType });
ILGenerator wrappedObjSetILG = wrappedObjSetBuilder.GetILGenerator();
wrappedObjSetILG.Emit(OpCodes.Ldarg_0);
wrappedObjSetILG.Emit(OpCodes.Ldarg_1);
wrappedObjSetILG.Emit(OpCodes.Stfld, wrappedObjectField);
wrappedObjSetILG.Emit(OpCodes.Ret);
wrappedObjPropertyBuilder.SetSetMethod(wrappedObjSetBuilder);

Note that the "set { value = .. }" notation actually corresponds to a method "set_MyProperty(object value) {...", much like Java-style getters & setters.

Now for the fun bit: Create a getter for each property in the wrapped object. We iterate through the properties and generating a getter method works much like the setter above.

foreach (PropertyInfo propertyInfo in objectType.GetProperties())
{
  string name = propertyInfo.Name;
  if (IgnoreProperty(name))
  {
     continue;
  }
  PropertyBuilder propertyBuilder =
     typeBuilder.DefineProperty(name, PropertyAttributes.None,
     propertyInfo.PropertyType, null);

  MethodBuilder getBuilder =
     typeBuilder.DefineMethod("get_" + name, MethodAttributes.Public,
     propertyInfo.PropertyType, Type.EmptyTypes);

  ILGenerator getILG = getBuilder.GetILGenerator();
  getILG.Emit(OpCodes.Ldarg_0);
  getILG.Emit(OpCodes.Ldfld, wrappedObjectField);
  getILG.Emit(OpCodes.Call, propertyInfo.GetGetMethod());
  getILG.Emit(OpCodes.Ret);

  propertyBuilder.SetGetMethod(getBuilder);
}