thekua.com@work

As a developer, there’s a tension between doing things consistently and knowing when to make change. Consistency generally means it’s easier to understand – there’s only one pattern for people to learn and then the next time they see something like it they have a pretty good guess at how it’s going to work.

People also generally learn by copying – and therein lies the problem for inexperienced developers. They look at what’s there, figure it’s better to follow the established pattern and then to add just one more thing. Generally it doesn’t really matter what it is – another branch to a if statement, another parameter to a method, another function to class, or another (ugh!) static call.

Responsible, experienced developers know where the inflection point is – where the right thing to do is to refactor the code, and to avoid adding just one more thing.

Comments(1)

One of the interesting side effects of using SmartGWT is losing the ability for people to select text on the page. SmartGWT has some pretty nifty widgets and the one to use when you want text selectable is HTMLPane. Be careful not to confuse this with GWT’s own HTMLPanel

Comments(0)

It’s almost three weeks ago I presented at USI2010 (Universite du SI). Organised wonderfully by the Octo consulting company, the conference’s tag line, “The Annual meeting of Geeks and Bosses” captures a really good essence. Mix over conferences and events are important to ensure that communities don’t silo themselves in ways that prohibit their growth. The complexity and chaos community clearly demonstrated the value of idea cross-pollination between between professions with their think tank, the Santa Fe Institute. This event is definitely the seeds of something good like this.

To add to the mix, I had the opportunity to present my session on Building the Next Generation of Technical Leaders here. This is the first conference I’ve been to where the majority of the session were not in English. This made me think a lot about how memes spread, and how quickly this affects how adaptable a community is.

I think it is wonderful for this conference to invite speakers from non-French speaking backgrounds, as I hope that it helped seed some more ideas into a community where translating text into a local language hinders the uptake of new ideas. I know that it is much more difficult for people to understand a language other than their native tongue and I can only admire those French people willing to strike up a conversation with me during the conference where my study of the French language is what tourist books teach.

The conference was very well run and although I would like to comment much more on the presentations since most of them were in French. If you understand French, and you find yourself near Paris, then I think it’s an excellent one to attend.

Comments(0)

In ant, it’s pretty easy to use the ant task get to download something for you. Apparently it’s not something most maven users do (probably because they end up doing something like an ant=run). Even though maven has in-built web communications (this is how it often is found downloading the interweb), it wasn’t easy finding out how to download something not in a maven repository (without having to deploy artefacts into a maven repository which I understand is the “maven way”).

Anyway, after sometime, here’s the plugin configuration I used to do the download. Note that we’re using Maven 2.1.0 (and it could have changed in the latest version).

The following plugin will download configuration.jar and artifact.jar from the web directory http://host/pathToArtifact and drop it into a folder called target/downloadedFiles. This does this at the start of the maven lifecycle (note the phase it is attached to below).

<plugin>
	<groupId>org.codehaus.mojo</groupId>
	<artifactId>wagon-maven-plugin</artifactId>
	<version>1.0-beta-3</version>
	<executions>
		<execution>
			<phase>validate</phase>
			<goals>
				<goal>download</goal>
			</goals>
			<configuration>
				<url>http://host/pathToArtifact</url>
				<includes>
					configuration.jar, artifact.jar
				</includes>
				<toDir>target/downloadedFiles</toDir>
			</configuration>
		</execution>
	</executions>
</plugin>

Some limitations is that it won’t fail if it can download some of the artifacts and not others.

Comments(0)

One of the many issues I had (have) with Maven is finding out how to use an appropriate plugin. The site documentation is normally pretty obscure, and examples are sparse. One of the activites we needed to do recently is to turn our war artifact into something that would run standalone. I’d normally use something like jetty for this but I didn’t find a way to easy bundle jetty and refer to the war within the same classpath (and still have things work).

Another tool I stumbled across was winstone (Hudson uses this beast). Wrapping this up seemed pretty easy enough. Note that the configuration below is used to start a war that won’t have dynamic JSP compilation. If you do, you can add a useJasper=true configuration and add the appropriate maven dependencies for jasper to ensure they’re available.

The result of this plugin will effectively build an executable jar, that you simply start up.

Need to add these dependencies:

Given that your project is a war package as well

<plugin>
	<groupId>net.sf.alchim</groupId>
	<artifactId>winstone-maven-plugin</artifactId>
	<executions>
		<execution>
			<goals>
				<goal>embed</goal>
			</goals>
			<phase>package</phase>
		</execution>
	</executions>
	<configuration>
		<filename>executableWebApplication.jar</filename>
	</configuration>
</plugin>

You will find this artifact built in your standard target directly.

Comments(0)

I’ve been working on some performance testing profiling and in trying to diagnose a fix, we found one particular method was being called constantly. Searching for usages (static analysis) tells me who could possibly call the method we were inspecting, but we were interested in the runtime invocations. Since this was quite deep in the code, I used the power of dynamic proxies to do this.

I’ve rebuilt the code here:

Source:

package com.thekua.examples;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

public class TraceBackProxy implements InvocationHandler {
    public static interface CallingMethodListener {
        void notify(String method);
    }

    private final Object wrapped;
    private final CallingMethodListener listener;

    private TraceBackProxy(Object wrapped, CallingMethodListener context) {
        this.wrapped = wrapped;
        this.listener = context;
    }

    public static Object wrap(Object target, CallingMethodListener context) {
        Class targetClass = target.getClass();
        return Proxy.newProxyInstance(targetClass.getClassLoader(),
                targetClass.getInterfaces(), new TraceBackProxy(target, context));
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] arguments) throws Throwable {
        String callingMethod = findCallingMethod(method);
        listener.notify(callingMethod);
        return method.invoke(wrapped, arguments);
    }

    private String findCallingMethod(Method method) {
        try {
            throw new RuntimeException();
        } catch(RuntimeException e) {
            StackTraceElement[] elements = e.getStackTrace();
            int callingMethodIndex = findIndexOfMethod(elements, method) + 1; // caller is next one down in stack
            return elements[callingMethodIndex].getMethodName();
        }
    }

    private int findIndexOfMethod(StackTraceElement[] elements, Method method) {
        for (int i = 0; i < elements.length; i++) {
            StackTraceElement current = elements[i];
            // does not cope with overloaded or duplicate method names
            if (current.getMethodName().equals(method.getName())) {
                return i;
            }
        }
        throw new IllegalStateException("Something went wrong and couldn't find method in stacktrace");
    }
}

Test:

package com.thekua.examples;

import org.junit.Test;

import static org.hamcrest.core.Is.is;
import static org.hamcrest.core.IsEqual.equalTo;
import static org.junit.Assert.assertThat;

public class TraceBackProxyTest {

    public static interface SomeRole {
        void doStuff();
    }

    public static class TestSubject implements SomeRole {
        public boolean called;

        @Override
        public void doStuff() {
            called = true;
        }
    }

    @Test
    public void shouldStillDelegate() {
        TestSubject target = new TestSubject();
        SomeRole action = (SomeRole)TraceBackProxy.wrap(target, new TestOnlyListener());

        action.doStuff();

        assertThat(target.called, is(true));
    }

    public static class TestOnlyListener implements TraceBackProxy.CallingMethodListener {
        String lastCalledMethod;

        @Override
        public void notify(String method) {
            lastCalledMethod = method;
        }
    }

    @Test
    public void shouldFindCallingMethod() {
        TestOnlyListener listener = new TestOnlyListener();
        SomeRole action = (SomeRole) TraceBackProxy.wrap(new TestSubject(), listener);

        action.doStuff();

        assertThat(listener.lastCalledMethod, equalTo("shouldFindCallingMethod"));
    }
}

Note that your mileage may vary since it probably won’t work when you have duplicate method names across classes, or overloaded methods on the same. It proved useful for me and hope it helps you.

Comments(2)

You want to ensure reusing functionality does not have any other side effects in other places that might be using it.

Make the static instance explicit by introduce a static instance encapsulating any static state and delegate items to it. Use the instance.

Imagine you had this sort of code (below) and there’s dozens of use throughout a codebase. Static imports make it easy for people to simply increment a count, but in order to use the Counter, you have no assurance nothing else will try to use it.

public class Counter {
  static int totalCount;

  public static void count() {
    totalCount++;
  }
}

The following transformations will help you keep existing clients happy:

• Introduce new method (instance level)
• Introduce global instance
• Delegate static method to new method (instance level)
• Turn static state into instance state

The final result is below (note that this code is not thread-safe and not designed for concurrent programs, but is there to demonstrate the result of the refactoring steps):

public class Counter {
   private static final Counter INSTANCE = new Counter();

   private int totalCount;

   public static void count() {
     INSTANCE.recordCount();
   }

   public void recordCount() {
     totalCount++;
   }
}

Now we had a bit more of a complex example, but this refactoring helped us move to the right direction of using instances where possible, instead of sharing global state.

Comments(0)

Just like a certain number of speakers, Maven seems to divide developers into two camps:

1. Those who like it; and
2. Those who loathe it

I try to be objective as much as possible about tools, so let’s explore what Maven is and what it’s good for.

What’s Maven all about?
Maven has two major responsibilities (with a handful of minor ones). These two are:

1. Library dependency management – Anyone who’s worked on a java project will know the large number of libraries you might end up with. Part of this is the JDKs inability to solve some of the simplest programming problems (solved with Apache Commons, various logging frameworks, etc). Maven was one of the first successful attempts at fixing this, focusing on applications on what version of libraries they’d like with its dependencies automatically resolved.
2. Build lifecycle tool – Maven provides a standard set of fixed build lifecyles with hooks for each step in the lifecycle should you need to extend it.

Why was Maven developed?
To better understand Maven’s design, let’s look at the context developers built it in. Maven sprung forth out of the growing complexities in the Java Apache community. New Apache projects started off almost all the time and there was no “standard” way of building, or creating them. More than that, many Apache projects built on the work of other projects and managing the versioning of libraries started to become an onerous task.

Each Apache project characteristically depended on several other projects although generated its own single distributable (i.e. jar, war, etc).

Maven helped simplify these by assuming a default project structure, a default build lifecycle common to all many Apache projects.

Where is Maven most useful?
If you’re on a project that is similar to a single Apache project (a single distributable with a single set of unit tests) then you’ve hit Maven’s sweet spot.

Where does Maven start to break?
Here are some of the situations I’ve faced where Maven is not the best tool for the job:

• When one team is producing a number of artefacts, you find yourself needing to work around the Maven structure, often with resorting to “Pom Inheritence”. You have to do ugly things like maven installs before hand.
• If you need to do anything more complex than the standard build, then you start to obfuscate the build process. Strange things like different processes running under different profiles (whether or not the build is running on a build server or not) can be very confusing for lots of people.
• Maven adds more complexity to your development environment as you rely on either a public artefact server, or need to set up an internal one. Whilst this seems simple, it is yet another environmental factor that affects how you develop, and its external nature adds variability to projects that often cause false negative build failures.

What other situations would your recommend using Maven or not?

Comments(8)

The pace of the conference and the speakers drinks event on Thursday night meant that I missed the first session on the final day. It’s a shame since I think Joe Armstrong would have been good to listen to. I look forward to reading anyone’s report of that session in the blogosphere.

Track: The Concurrency Challenge – Session: Embracing Concurrency at Scale

I really appreciated this speaker for being very pragmatic and conscious about helping people think more explicitly about tradeoffs. He encouraged people to actively think about what solution is most appropriate considering there is always some trade off.

This session resonated another one of those ideas that we use “models” all the time and that models are inherently limited by simplifying things. As the speaker said, “There are many models in science, all of them wrong but some of them useful.” He used time as an example in that there are many ways of looking at it although we have a tendency to want to structure it linearly. “When you admit time is a difficult problem, you will have problems with multiple actors”.

He talked about the ideas that we like convenient mechanisms (such as distributed transactions) because they’re easy to grok and we’re comfortable with those ideas but because they have implicit state, you’re throwing away the value of distributed systems. He went on to talk about how we’re taught about the goodness of ACID properties (particularly around database-centric applications). The alternative he presents is BASE (Basic, Availability, Soft State, Eventual Consistency). There’s apparently a paper on this found here (ACM login required). He referenced Pat Helland’s alternative definition of the acronym, Associative, Commutative, Idempotent and Distributed.

Once again, he emphasises the importance of making the decision on alternatives an explicit one and there is a real tradeoff. This was yet another time someone talked about the CAP theorem that describes three different system properties but you can only guarantee two of them. It’s great as a reminder and highly recommend you read about it as a refresher.

He talks about the world being Eventually Consistent and that “We shouldn’t try to model a world more perfect than it actually is”. He gave a number of examples of using this in practice, and there are ways to make sure that you try to do this. One such example was a Shopping Cart situation where a service should tell the “stock to decrement by 1″ instead of “reduce stock from 99 to 98″. I think this is just another example of good OO (tell, don’t ask).

Track: Solution – Session: Scenario Driven Development

Our own Ben Butler Cole ran this session that attracted a huge audience considering it was running in the Solution Track. Ben attempted to help people understand how to use Scenario based testing instead of alternatives such as exhaustive acceptance testing or story based acceptance testing as the regression suite.

I think the audience were largely sceptical but Ben’s views align very similarly to the things I’ve seen on projects, particularly when doing development using stories. One of the misunderstandings about automated testing and stories is that everyone always views stories as additive. For me, you not only have stories that add functionality, you also have stories that change functionality (replace) and stories that also cause functionality to disappear. I tend to think the set of tests also goes hand in hand – if you’re deleting functionality, you should be deleting existing tests as well, or if you’re changing tests, you should be changing existing tests.

I think part of the problem is that stories are kind of fractal in nature and the scenarios that Ben talked about were like at an epic level (maybe even a use case level). What is interesting is how you go about enhancing, maintaining that scenario over time and how the team works around those scenarios – something we unfortunately only got a taster for in the hour.

I heard a lot of people still come away with lots of interesting insights and I would highly recommend everyone go and listen to Ben speak even if it’s just to hear him present. Totally worth it.

Track: The Concurrency Challenge – Session: Modelling Concurrency with Actors in Java – Lessons learned from Erjang

This session was fairly packed out, I guess given the hype of people working with or wanting to work with Erlang. This presenter’s take was interesting because in order to better understand concurrency and Erlang, this guy decided to implement an interpreter on top of the JVM (instead of simply playing around with the language).

The premise behind his talk was that Object Orientation as a paradigm brought with it plenty of productivity and that Actor-based modelling was going to be the thing to give us the next boost. Whilst I admire his premise, I don’t necessarily agree. I don’t think we’re all that good (as an industry) as implementing Object Orientation. I do think things like the JVM have helped raise the abstraction level so that we don’t need to think as much about the lower level memory management (although you have a memory leak in these languages if you’re not careful).

He spent a long time fascinating all the language geeks with his ability to run a simply Erlang program on top of his project, Erjang (Erlang on the JVM) but I really wanted to hear about the lessons learned from programming instead of the technical details of writing an interpreter on the JVM, something he spent a majority of the time on. I don’t think there were very many interesting bits other than designing parts of a system with different ideas. As he said, “Imagine treating parts of system as different actors with different responsibilities?” to which I was thinking, “That’s what good Object Orientation is about. Treating objects playing different roles with the right set of (small) responsibilities”. Nothing new unfortunately.

Track: How do you want to test that? – Session: Performance Testing at the Edge
This session brought a lot of mixed reactions. I agree that the start of it seemed a little bit commercial, talking about their product and the complexities of performance testing. I like discussing the importance of performance testing for applications because it’s one of those things that are often neglected and really not treated very well. This presenter eventually got around to talking about some of these aspects, but like many of the talks still ended up being fairly late in the talk.

I think that this speaker had a lot of great things to say and although much of it was very common sense, didn’t give people an impression about how they could go about doing it well. They had some interesting approaches to monitoring performance such as running it on the same set of dedicated hardware (that wasn’t even a replica of production). This has a trade off of being able to compare results over time which they had some interesting graphs, although it is at a cost of being a proper representative sample of what the software might actually run on.

I found that some of the good things he talked about were similar to the talk that Alistair and I had, although it still sounded like the performance testing team was a predominantly split responsibility that worked orthogonally to the actual development team. It also sounds like there was a big cultural barrier that they have been trying to break down by getting developers to write performance tests and have some more ownership.

The crowd also had a lot of scepticism about convincing a business to invest in the automation of performance testing.

Comments(0)

Keynote: Ralph Johnson on Living and working with aging software
The final keynote of the conference kicked off the second day of QCon and presented to us by Ralph Johnson of the Gang of Four fame and whose students contributed to Fowler’s timeless Refactoring book.

Ralph was asking about the number of people who work on systems they created (versus systems that other created) and then argued about the meaning of maintenance programmer arguing for software evolutionists instead. Whilst I agree that no one likes to be labelled a maintenance programmer, changing the name doesn’t really matter.

I like the different perspectives that Ralph brought. He talked about Software Capital as about truly understanding how the software works. Code is one example of this, but actually there are many other things that go into understanding how the software works. He argues that the right sort of documentation (and other artefacts) that helps understand how the software works is another part of Software Capital. As a result, you also need the people around the software to help keep the story alive.

My observations of various organisations also backs up some of the things that he says such as, the larger a system gets, the more likely you need some form of documentation and social structure around the software.

I think a lot of people didn’t like Ralph’s keynote because he talked about refactoring as if it was a new idea and, unfortunately this audience is one that has been exposed to these ideas for a long time.

Track: Beyond Tools and Technologies
I spent the rest of my time on the track that I was speaking at later that day. The first talk of the day was Martin Fowler whose talk, “What are we programming for?” brought the tiny room to a stand still. The room was so full (although it was a small room) that they had to turn people away.

Martin used the talk to highlight the importance of going beyond acting like hired guns and actually thinking about how to use the skills for something good. He asked people to consider the essence of the firms that they work for and whether or not they are benefiting humanity.

Rebecca Parsons, ThoughtWorks’ CTO then talked about the importance of team diversity in her talk, “How to avoid ‘We never even thought of that’!” She talked about the role that diversity played in creating innovations in science and how too much of the “sameness” creates problems with creating too many assumptions. I like the idea of a balancing tradeoffs of not enough diversity leading to problems in teams and too much diversity to the point that the team don’t share the same vocabulary.

After the lunch break, I ran my session, “Building the next generation of Technical Leaders“. I was very happy with the turnout and had some great feedback from the participants. It’s an issues I think is sorely neglected in our industry and has a huge impact on the team effectiveness.

The next session was run by our Director of Social Engagement (Jeff Wishnie) and Merrick Schaefer of Unicef discussing the importance that technology has on developing countries and the significant impact it can have on the lives. They talked about the Rapid FTR project that is being developed to help capture information about children who’ve been separated from their parents with hope of quickly reconnecting them, and at worst, giving them legal status by registering them with an agency such as Unicef.

The final session of the day rounded out with Mick Blowfield with a presentation titled, “IT in a Low Carbon Future“.

Whilst there were many other potentially interesting sessions, I was really happy to hear about the issues that go beyond just Tools and Technology.

Comments(0)