David Anderson observed five core properties to be present in each successful implementation of Kanban. These have become know as the Principles of Kanban.

First adopt the foundational principles…

1. Start with what you do now
2. Agree to pursue incremental, evolutionary change
3. Respect the current process, roles, responsibilities & titles

Then use the Five Core Properties…

1. Visualize the Workflow
2. Limit Work in Progress
3. Manage Flow
4. Make Process Policies Explicit
5. Improve Collaboratively—using models & the scientific method

To get started:

1. Walk the line—Staple yourself to an item and follow its steps through its life.
2. Visualize the workflow—Draw the flow of steps that are taken as a sequence of columns. Use common sense to merge columns.
3. Track all work—For a couple of weeks, put all work as individual items on the board, and track them as they progress.
4. Limit Work in Progress—After some time, and using common sense, put limits on some columns (and swim lanes, if you have them) to increase flow and throughput. Tighten up the limits over time, until it starts hurting. Use the pain to trigger a conversation on how to get rid of the pain while maintaining the limit. Repeat.

Quite a few interesting sessions today:

Google Knowledge Graph

With the Knowledge Graph, Google is trying to give a new dimension to its flagship product: Search.
Users should be able to have a conversation with search, and search should anticipate on a user’s interests by showing related topics.
So search needs to understand the context of searches, in other words: it needs to understand the world. This is where Knowledge Tree comes in handy.
Knowledge Tree is a hugh graph with semantic data about real world entities and their relations. This data has been gathered from Wikipedia, Google+ and many other sources.
The complete tree is viewable and downloadable at freebase.com.

Freebase Api

If you don’t feel like writing your query logic by yourslef, Google also offers a (free) Rest api:
Freebase Api
The following services are offered, many of them have their own JQuery plugin as well:

• autocomplete
• semantic tagging
• entity collections
• geosearch collections
• topical weblinks

Dart: new features

The Dart programming language has been around a few years already. It is Google’s scalable and typesafe alternative for Javascript. It can run in its own VM, in a special version of Chrome, or it can be compiled into Javascript.

During the last year quite a couple of new features have been added. Here are some highlights:

Mixins
Metadata
Lazy loading of libraries
Futures
streams

Also nice: you can try out Dart in realtime on try.dartlang.org

Dart’s performance has been enhanced: native Dart now runs many times faster than Javascript, thanks to, amongst others, utilization of SimD instructions by the Dart VM.

“Chrome DevTools Revolution”

The DevTools in Chrome Canary have been updated with quite a few cool features. It should even be possible now to use Chrome DevTools as your only IDE: inline editing of Javascript and styling was already possible, but now it is also possible to save the edited code to disk (using Ctrl-S).

If you are using an IDE and have edited a source file, Chrome can now detect file system changes and refresh automatically.

Sass support has been added to Chrome DevTools. So you can trace a styling all the way to the Sass reference that defines it, inside Chrome Devtools.
And also here it is possible to automatically reload the page when a sass file has been changed.

A lot of support was added for profiling Javascript:

• Timeline: a view to quickly see which method takes the most cpu cycles
• FlameChart: a view with the same purpose but a different layout
• Canvast profiling: a view showing which paint actions take the most time
• Object allocation tracking: a memory profiler for javascript
• Layout trashing details: a tool that can show inefficiencies or redundant Dom tree building
• and more ..

Portable Native Client

This is Google’s solution to let you run C++ code inside your browser. Actually that was already possible with Native Client, but Portable Native Client makes it easier to create C++ apps that will run on both Arm and x86 architectures.

Obviously Google needed to do a lot to prevent this from being a security risk. So the C++ code needs to be compiled with a custom compiler, which will create a .pexe file; this file runs inside a ‘native client process’ with ‘software fault isolation’. What this means is that Chrome will scan the code before running it, to check for illegal instructions and for illegal access of certain memory regions.
Apart from that, native client code can only be used in applications inside Chrome Webstore.
This all should make Native Clients safe to use.

The advantage of Native Clients is obviously their performance: they run at 80% or 90% of the speed of a fully native application.

But the question is of course: why go through so much trouble, why not just download a fully native application to your cellphone or laptop?
I guess the answer is that such a thing is not possible on Chromebooks. Google is trying hard to make Chrome the universal platform to run all your applications. And with Native Client, you can now get enough performance to run games as well.

Today was the first day of the Google IO conference in San Francisco. I was lucky enough to be able to attend so I can share some (personal) highlights of the day.

In the keynote Google showed some of their latest developments:
It is now possible to upload a batch of pictures to your online storage and let Google decide which are the best ones to keep. For instance when you’ve been on holiday and have taken 600 pictures, too many to show to anybody, Google can propose a selection after doing some intelligent analysis:
It can filter pictures if they are dupicates or if they are unclear. But it also recognizes if pictures contain some of your (Google+) relations, which would make them more interesting. Even more cool: with the help of some machine learning and a lot of training, Google can now estimate if a picture is pretty or not.
Another cool feature: Google will recognize if you have multiple pictures of the same person in the same scene. Based on some intrapolation algorithm, it can generate new pictures in that scene. Some examples were shown and they were actually really good.

Voice recognition was added Chrome (desktop and Chromebook only) so you can give spoken commands to let it do searches. Not really new, but what makes it special is that integration was added with Google Knowledge Tree, a giant graph database which contains semantic relations between entities.
What this means is that Chrome might understand what you mean when you say something like: “Send Misja an e-mail with the shortest route from here to Amsterdam”. This does require that Misja is one of your Google+ contacts. Chrome will infer that ‘here’ refers to your current location.

And there were many more announcements. You can see the full keynote speech here.

In the afternoon there was a choice of about 60 different presentations. Obviously too many to watch or to describe. Here are a few brief highlights:

Google has added App Script support to Google Forms.
App Script support was already present in Gmail and Google Sheets and it enables you to write macro’s or other logic in Javascript. The Javascript can access and manipulate the document you are working on, it can use all Google Api’s and connect to databases.
Now it can also be used in Google Forms. Quite useful if you want to add form validation for instance.
You can try it out here

Google Compute Engine, Google’s cloud service, has gotten some useful pricing options for small businesses. The cheapest one can host your application already for less than 2 cents per hour. There’s not much use for buying your own server anymore if cloud computing becomes so cheap ..

Like all software, Deployit plugins should be build automatically, deployed and tested whenever possible. Below I will explain how to setup continuous integration and testing for Deployit plugins. The general idea is that if you’re creating a larger set of plugins for Deployit, it makes sense to try to build and deploy them as often as possible so you can catch errors early. We found that it is really easy to create plugins that work fine in isolation but fail when they are deployed together. Luckily it is also easy to catch these kinds of errors as I will show below.

This work is part of a larger effort to describe and explain Deployit. I’ve written a previous blog you can find here: http://blog.xebia.com/2013/03/24/scripting-deployit/.
Code for the examples and plugins can be found on GitHub:
git clone git://github.com/jvermeir/DeployitBlogs.git
cd DeployitBlogs
git checkout ec6b748.

I’ve borrowed heavily from work I did with my colleague Joris de Winne.

I will use a couple of plugins that define a new host type. They serve only to show how the build and test process works so please ignore their contents. In the source tree you can find them in the ‘citest/test’ directory. Each plugin comes with a buildAndCopy.sh script that does no more than copy a jar file to the plugins directory so it can be picked up by Deployit.

To run the examples you’ll need a shell and change to the directory named ‘citest’ in ‘DeployitBlogs’, the root of a project on GitHub I’ve described in a previous post.

The build and deploy script is started by typing

./basicDeployitStartupTest.sh p1

which will do a clean install of Deployit, copy the plugin named p1 and finally start Deployit to find out if it still works. The script will log messages about the steps it takes, i.e.:

findAndTerminateDeployitProces
installDeployit
copyPluginsFromDistribution
buildAndCopyPlugins
validate

The first step is to find and terminate a Deployit process that may already be running on the test server. This is done by looking for a Java process that runs Deployits main class com.xebialabs.deployit.DeployitBootstrapper, and then terminating this process. This may fail of course, meaning you’ll get errors later on.

Next, installDeployit() removes a previous version and unzips the Deployit server archive. The archive I’ve used is not the standard distribution but a version that was created from an existing install. Deployit needs a couple of answers when it starts for the first time, so all I did was run the installer, answer the questions, stop Deployit and zip the full directory into a new installer file that is unzipped by the installDeployit() method. So for this step to work you’ll have to do the same and store the results in $ROOTDIR/resources/deployit-$DEPLOYIT_VERSION-server-setup.zip. Refer to the script to find out where the shell variables should point to.

The third step, copyPluginsFromDistribution(), copies all default plugins from the available-plugins directory to the plugins directory so we can use all of Deployits features. You can change this if you don’t need all plugins for your use case. The third line in this method uses Linux find to copy even more plugins that are neither part of the standard distribution nor of your project. An example could be the weblogic plugin. These plugins should be copied in the lib directory under citest.

The fourth step, buildAndCopyPlugins(), builds a list of plugins you want to test and copies them to the plugins directory. The function takes a list of plugin names separated by a blank in a variable called $PLUGIN_NAMES. It then loops over this list and calls a script named buildAndCopy.sh that should reside in the root directory of each plugin. The sample plugins in test/success show how this works. In the real world you might start a Jenkins build, copy an artifact from a repository or call Maven.
The only requirement is that a build should log to the console and print a line with the text ‘BUILD FAILURE’ if something goes wrong.

Finally validate() tries to start Deployit and waits for the message “You can now point your browser to” to appear in the console log. The method checks every 5 seconds for a minute and reports the result.

To experiment you can use the two sets of plugins provided in the test/success and test/failure directories.
./basicDeployitStartupTest.sh p1
deploys a single plugin named p1 from test/success. This test should report success.
./basicDeployitStartupTest.sh -p test/failure p1 p2
should report failure because it tries to deploy the same plugin twice. This takes a while because the test keeps looking for a success message but an error is logged in stead. There’s some room for improvement here, I guess.

We’ve successfully used a predecessor of this script to keep a grip on a project with a large set of plugins defining many custom types. We ran the script as a Jenkins job triggered by a commit on Subversion. In our setting it proved a useful tool to catch type definition errors early on.

A few years ago I was asked by one of our customers to help them make better use of their integration layer. Ever since then me and my team have been working on a framework in support of that. This is the fourth in a series of blogs on the development of our framework, and discusses the features it provides. The one that was announced last time, about building blocks, is momentarily postponed.

So far I’ve discussed the goals & challenges surrounding the development activities, but I’d like to focus more on the framework itself now, and what it brings to those that are using it.

As soon as a new party (be it service consumer or service provider) connects to our framework, it can profit directly from the wealth of functionality we deliver out-of-the-box. These ‘generic features’ are exactly what one would expect from a (logical) ESB, and are partly based on the Expanded Enterprise Service Bus Pattern.

As our project was scrum driven, features were developed only when they were needed. Sometimes, during the design & build phase, we discovered a better way of doing things, and sometimes the problem a feature was supposed to address was solved in a completely different way, outside of our scope. But in the end we managed to implement about 20 features, which can roughly be divided into five types: routing, robustness, security, transformation and data storage.

Routing

One of our main objectives is to get messages from A to B without A having to know where B is currently residing. To do this, we make extensive use of the WS-Addressing standard. One of the components in our framework, the routing service, uses the information in the message headers to decide what the next hop will be (hop in this case being another framework component). Most of the times a message is delivered to the backside as soon as it enters the integration layer, something we call simple routing.

However, as soon as some special activity needs to be performed (like data model transformation for example), the message is detoured to one of the framework components not connected to the outside world. We classify those as intermediate services, and they are agnostic of nature – which means they have no clue about the context in which they are called. The necessary information for the message to continue its path is part of the addressing headers as well, making this advanced routing.

A special kind of advanced routing is distribution, which makes it possible to send one message to several subscribers at the same time, using WS-Notification in its most basic form. Finally prioritized routing is a feature which makes sure that a message gets ahead of the rest so to speak – very useful when dealing with a customer waiting for service at a counter while there’s also a bulk load being processed.

Robustness

Of course it’s of eminent importance that nothing goes wrong when delivering the message, or that when it does we can at least deal with the situation (exception management). First thing that happens when we receive a message is that we check to see if it complies with the industry & design standards we enforce (technical validation). Sometimes the consumer/publisher doesn’t want to wait for the (functional) answer but still wants to be informed if his message was technically valid, in which case we send him a response stating just that (technical acceptance).

Two of our features deal with peak load: throttling makes sure the integration layer only takes in what it can handle, while buffering guarantees we don’t overwhelm the applications we connect to. Similar to the second one is postponed delivery which is used when we know beforehand the backside is not available.

But by far the most important of these types of feature is guaranteed delivery. We played around with a bidirectional variant (using WS-RM) but finally settled on an unidirectional implementation, meaning that before we send the message we first store it, and if we receive an HTTP error code we send it again.

Last (and actually least, as it’s hardly used) it’s also possible to have syntactic validation of outgoing messages. But as we like to follow Postel’s law (also known as the robustness principle) we feel it’s the consumer’s responsibility to make sure the message was valid to begin with (you can imagine this took some selling from our part). The only exception is when the payload is altered by the framework.

Security

Every application that wants to connect to the integration layer needs to make itself known using the WS-Security UsernameToken (authentication). For most of the services we expose that’s enough, in a few rare cases such an application has to have explicit permission (authorization).

Not used internally (only when we receive requests from certain external customers) is integrity, where we demand that certain parts of the message headers and payload are signed.

Transformation

Given the fact that not all applications connected to the framework ‘speak the same language’ (as mentioned in the previous blog), there’s an evident need for data model transformation – one of our most used features. A lot less popular is the split feature, which makes it possible to divide a big message into smaller parts.

Data storage

The last few features play a more supportive role to the ones already mentioned. We provide logging to be used during testing & bug-finding sessions and persistence when there’s a need to store the complete message. The latter is frequently used in combination with resending (which is necessary for the guaranteed delivery feature described above), but also in case of auditing requirements.

Conclusion

Most of these features have been around since the first version of our framework, and have proven their generic qualities over time. In a few cases we had to make some alterations and even now there are one or two features which we might implement differently in the future. There’s also a list of additional features but it’s rather short, which I take as a sign that what we have here is pretty complete.

That’s number four; next time I’ll talk a bit about the more specific deliverables we provide our project teams.

Two days ago, I read the book Toyota Kata by Mike Rother. Like most management books, the central message is hammered home by repetition. Some people, like me, may find that a bit annoying. That does not make this book any less a must read though. If you’re interested in making Lean/Agile really work in your organization without running the risk of organizational gravity eroding all your hard efforts over time, this book has the answer on how to do that. I’ll be incorporating the concepts of the Toyota Kata in my consulting from now on. Empower yourself. Read this book now! Or at least check out my summary of it.

All I wanted to do was create a number of plugins and examples for Deployit using the different techniques available. While working on examples I was frustrated by having to clean up remainders of previous attempts, so following in the footsteps of greater men than my humble self (most notably professor Knuth who created TeX so he could finish writing a series of books on computer science) I first wrote a script to create junk in the Deployit repository and then get rid of it in one sweeping go.

I’ve placed my code on Github (git clone git://github.com/jvermeir/DeployitBlogs.git).
To try out the examples you’ll need Deployit 3.8.4 (the version I used, but I’m quite sure it’ll work fine with other versions as well). I’ve installed the server and cli in a directory referenced by an environment variable $DEPLOYIT_HOME. I’m using *nix style variable and scripts in my examples. If you insist on using Microsoft you can always download Cygwin or change the examples yourself. After checking out the sources and installing Deployit, $DEPLOYIT_HOME should contain the following folders:
deployit-3.8.4-server
deployit-3.8.4-cli
DeployitBlogs

DeployitBlogs contains a directory named tools that for now holds no more than a couple of scripts, most notably three scripts named utils.py, cleanup.cli and deploy.cli. In src/test you’ll find a dar file I’m using to try out my scripts and plugins (deps.dar was build from another example I hope to explain later, for now it’s not important; all it does is copy some files and print a message to the console).
Utils.py isn’t really a script but a plugin. It is supposed to be placed in $DEPLOYIT_HOME/cli/ext, but that can become rather tedious very quickly if you’re going through lots of versions, so I left the script in the tools directory and created a symbolic link to it so the cli will pick up new versions when it is restarted. Create a link in $DEPLOYIT_HOME/cli/ext:
cd $DEPLOYIT_HOME/deployit-3.8.4-cli/ext
ln -s $DEPLOYIT_HOME/DeployitBlogs/tools/utils.py utils.py

One more piece of setup is necessary: create two test environments that are required by the scripts in examples I hope to discuss later. Open the Deployit client interface and create two environments named ‘localenv’ and ‘AnotherLocalEnv’. They should contain a overthere.SshHost named ‘local’ and ‘AnotherLocalHost’ respectively. I defined both hosts with default settings and a username of ‘deployit’, but the username doesn’t (yet) matter for the examples. It should exist though, so in my case Deployit just connects to localhost as user ‘deployit’ to run the scripts.

The scripts in cleanup.cli and deploy.cli are no more than convenience wrappers that make it easier to test new versions of the plugin. After some command line input checking all they do is call one of the functions defined in utils.py.
cleanup.cli is used as follows:
$DEPLOYIT_HOME/deployit-3.8.4-cli/bin/cli.sh -username admin -password admin -f $DEPLOYIT_HOME/DeployitBlogs/tools/deploy.cli -- $DEPLOYIT_HOME/DeployitBlogs/tools/src/test/deps.dar localenv

The command above starts the cli, connects using default credentials, starts the script named in the -f parameter and passes the two parameters following the double dash to the script.

To avoid even more typing I created a shell script d.sh that does no more than run the command line above. It takes the environment name as a parameter like this:
d.sh localenv

To call the cleanup script use:
c.sh deps

With all these details out of the way we can discuss the utils.py script.
utils.py is read by the cli when it is started. Each method in the script is available from the cli command line, but there are two main entry points:
def deployApp(fileName, environmentName):
def deleteApp(appName):

These are the methods that are called from deploy.cli and cleanup.cli respectively.

deployApp is nothing more than a straightforward deployment of an application from a dar file, like explained in the cli guide (climanual.html) you can find in the server/doc/html directory (open the file and search for ‘Performing deployments’).
Before it deploys an app from a DAR archive, deployApp calls deleteApp to erase all traces of previously imported or installed versions from each environment.
DeleteApp calls undeployApps (see picture below) to find all versions of the app and undeploys them so they can be subsequently deleted by the call to deleteVersions.
deleteVersions works like undeployApps: get a list of stuff to delete, loop and delete each version using repository.delete().

Main methods of utils.py

If you’re interested in the details you can clone the repo at
git clone git://github.com/jvermeir/DeployitBlogs.git
cd DeployitBlogs/
git checkout 94ff4af

The code for this blog is located in the ‘tools’ directory.

With all the big-data postings, now something about traditional SQL, running at DB2 9. We had created a web-application, that was basically a view for a database. The application displayed content of a database after the user would enter search parameters, or everything when no parameter was entered. The database contained a few hundred-thousands records. All in all very simple.
The software worked fine at our test-environment. But when we deployed the software into production, it would hardly ever display data. In the logs we found frequent locking errors as follow:

15:23 ERROR (org.hibernate.engine.jdbc.spi.SqlExceptionHelper) – DB2 SQL Error: SQLCODE=-911, SQLSTATE=40001, SQLERRMC=68, DRIVER=4.1

Searching the web revealed what that error meant: a deadlock or timeout has occurred. We knew the same database was also accessed by another application, Activiti running processes written in BPMN. The processes in the Activiti-engine only inserted a few records per minute, so we didn’t expect that application having a big influence. Yet how can a few inserts per minute have such a big impact?
After some talking to a DBA’er and doing our own experimentation we found out about the problem, which will describe here.

As said the other application was an Activiti that executed processes (to be exact: process-definitions in BPMN). At several steps in the process, Java code was executed by the Activiti’s delegate mechanism. That java code would insert data into our database.

A DB2-DBA’er told us, when you’d insert a new record during a database-transaction, that record was locked until you would release the transaction by issuing a commit or rollback. Of course we already knew that. However, he also told use that other transactions could still be influenced by that lock: a SELECT without or with broad WHERE clause would have to wait until the first transaction finished. The reason for that: DB2 not just locks the record, but a part of the tablespace where that record happens to be inserted into.

While inserting that data would take very little time, the execution of the whole process-execution could take 5 to 20 seconds. The reason for the long duration: part of the steps involved invoking other webservices, that were not always quick to respond. Since only at the end of the process a commit was performed, a lock existed for part of the database for up to 20 seconds. So this means our console couldn’t return any data if the other process was still busy, as shown below:

Time Process a(ctiviti) Process c(onsole) 1 INSERT something INTO mytable Process a is good to go 2 SELECT * FROM mytable Process c has to wait for process a 3 INSERT something INTO myothertable Process c still has to wait 4 commit Process a commits, finally process c can continue 5 commit Process c is now also finished

We tried out by searching in our console on primary keys. Then our console would respond immediately, as expected: because then only a lock of a small part of the table is needed.

To get around the problem, we decided to commit from within each delegate, basically after each step in the process. We checked of course with the product-owner: for consistency having some data visible during the execution of the process wasn’t a problem.
DB2 doesn’t support nested transaction, so in our delegate a new dbsession had to be opened (and closed):

EntityManagerFactoryImpl entityManagerFactory = (EntityManagerFactoryImpl) Persistence.
    createEntityManagerFactory(properties.getProperty("myunitname");
sessionFactory = entityManagerFactory.getSessionFactory();
Session session = sessionFactory.openSession();
session.getTransaction().begin();
...
session.getTransaction().commit();
session.close();

Note: if you use Spring-transactions, Spring will do the above boilerplate for you.

Now locks were held for a much shorter time. After this change, our console behaved normally.

The behavior of the process as listed before was in fact desired in the first place. After all writes, a flush statement existed in the original code. On DB2 that statement would indeed cause the data to be written to disk, but the data wouldn’t be visible until the commit was performed.

As a software developer you’re using dependency management to handle dependencies on your project; include frameworks and libraries to your project. If you’re a Java developer you’re probably using Maven. When you’re not using Maven you’re probably using one of the more versatile build tools like Ant or Gradle, both can use Ivy for dependency management. Either way, you’re not putting binaries (jars) in your source control repository.

How about your FitNesse acceptance suite? Since it’s all software and all belongs to the project, you probably want to have the same standards when executing the acceptance test suite. It’s really not that different from executing your regular (unit) tests.

In this blog I’ll explain how to launch a FitNesse suite from Maven. I’ll also elaborate on how to get FitNesse to recognize the dependencies required to launch the application. A future post will be dedicated to the FitNesse/Ivy combo.

Launching FitNesse from Maven

When you start integration FitNesse through Maven, there are a few challenges ahead:

1. Maven has a limited set of scopes in which you can define dependencies (compile, test, runtime)
2. Maven is using a fixes set of execution phases.
3. I’d like to start FitNesse in 2 modes: interactive and non-interactive.

Since FitNesse is about acceptance tests it makes sense to execute those in the integration-test phase. The integration-test phase is executed after the package stage. In interactive mode I’m not interested in a package, so I’ll launch FitNesse from the test stage directly. The way to make this possible is by using profiles.

FitNesse in interactive mode

First things first: in order to do anything with FitNesse we need to include the dependency. To start FitNesse we’ll use the runtime scope:

<dependencies>
  <!-- project dependencies go here ... -->
  <dependency>
    <groupId>org.fitnesse</groupId>
    <artifactId>fitnesse</artifactId>
    <version>20121220</version>
    <scope>runtime</scope>
  </dependency>
</dependencies>

This goes in the normal dependency section.

Now let’s look at the profile. As said before, for interactive editing I’d like to start FitNesse from the test phase.

<profiles>
  <profile>
    <id>fitnesse</id>
    <build>
      <plugins>
        <plugin>
          <artifactId>maven-antrun-plugin</artifactId>
          <version>1.6</version>
          <executions>
            <execution>
              <id>start-fitnesse</id>
              <phase>test</phase>
              <configuration>
                <tasks>
                  <echo taskname="fitnesse" message="Starting FitNesse..." />
                  <java classname="fitnesseMain.FitNesseMain" classpathref="maven.runtime.classpath" fork="true">
                    <arg line="-p 8000" />
                    <arg line="-d ." />
                  </java>
                </tasks>
              </configuration>
              <goals>
                <goal>run</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </build>
  </profile>
</profiles>

Mind the classpathref attribute on the Java tag. It’s referencing the runtime classpath definition from Maven. That easy.

This will allow you to start FitNesse using the following command:

$ mvn -Pfitnesse test

Quite okay, right? You can start the wiki in stand-alone mode and use it as, well, a wiki.

Maven support in FitNesse

Now let’s see if we can make FitNesse import some dependencies through Maven. The dependencies are stated in the pom.xml file, so it makes no sense duplicating those. Since dependencies change over time it’s quite labour intensive to manage them by hand it FitNesse. The way to go is to include the maven-classpath-plugin. This plugin needs to be loaded along with the FitNesse binary, so FitNesse can make use of it. Let’s include it in the profile, then the profile definition looks like this:

<profiles>
  <profile>
    <id>fitnesse</id>
    <build>
      <plugins>
        <plugin>
          <artifactId>maven-antrun-plugin</artifactId>
          <version>1.6</version>
          <executions>
            <execution>
              <id>start-fitnesse</id>
              <phase>test</phase>
              <configuration>
                <tasks>
                  <echo taskname="fitnesse" message="Starting FitNesse..." />
                  <java classname="fitnesseMain.FitNesseMain" classpathref="maven.runtime.classpath" fork="true">
                    <arg line="-p 8000" />
                    <arg line="-d ." />
                  </java>
                </tasks>
              </configuration>
              <goals>
                <goal>run</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </build>
    <dependencies>
      <dependency>
        <groupId>org.fitnesse.plugins</groupId>
        <artifactId>maven-classpath-plugin</artifactId>
        <version>1.6</version>
        <scope>runtime</scope>
      </dependency>
    </dependencies>
  </profile>
</profiles>

That’s it for the dependency. Now let’s tell FitNesse about it. In a file named plugins.properties (in the same directory where your POM is located) we can define the plugin:

# plugins.properties: Configuration for FitNesse
SymbolTypes = fitnesse.wikitext.widgets.MavenClasspathSymbolType

We’ll define our dependencies from a wiki page, hence define the plugin as SymbolType.

Now let’s relaunch FitNesse (Ctrl-C to terminate the running instance). It gives a message saying the plugin is loaded:

 [fitnesse] Starting FitNesse 20121220... (Selenium 2.29.1)
      FitNesse (v20121220) Started...
          port:              8000
          root page:         fitnesse.wiki.FileSystemPage at ./FitNesseRoot
          logger:            none
          authenticator:     fitnesse.authentication.PromiscuousAuthenticator
          page factory:      fitnesse.responders.PageFactory
          page theme:        bootstrap
          page version expiration set to 0 days.
          Custom symbol types loaded:
              fitnesse.wikitext.widgets.MavenClasspathSymbolType

All that has to be done now is including the Maven classpath in hierarchy of the test suite. In a wiki page, define:

!pomFile pom.xml

If you save the file you should see a lot of “classpath” entries show up on the page.

By default it will load the test scope (this is not related to the fact that we started FitNesse from the test phase). The plugin will display all dependencies.

One remark: why did I add the FitNesse dependency to the project dependencies and the plugin to the profile dependencies? You’ll need the fitnesse jar once you start executing tests. The plugin is not able to enable profiles at this moment. In practice this is hardly a problem.

Running integration tests

Executing FitNesse as part of the build cycle basically follows the same scheme. Let’s put it in a profile that’s active by default. This adds some flexibility in that the profile can be disabled to prevent the tests from running (for a local build or something).

<profiles>
  <!-- fitnesse profile omitted for clearity -->
  <profile>
    <id>fitnesse-integration</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <build>
      <plugins>
        <plugin>
          <artifactId>maven-antrun-plugin</artifactId>
          <version>1.6</version>
          <executions>
            <execution>
              <id>start-fitnesse-integration</id>
              <phase>integration-test</phase>
              <configuration>
                <tasks>
                  <echo taskname="fitnesse" message="Starting FitNesse..." />
                  <java classname="fitnesseMain.FitNesseMain" classpathref="maven.runtime.classpath" fork="true" failonerror="true">
                    <arg line="-p 8001" />
                    <arg line="-c FitNesse.SuiteAcceptanceTests?suite&amp;amp;format=text" />
                    <arg line="-d ." />
                  </java>
                </tasks>
              </configuration>
              <goals>
                <goal>run</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </build>
    <dependencies>
      <dependency>
        <groupId>org.fitnesse.plugins</groupId>
        <artifactId>maven-classpath-plugin</artifactId>
        <version>1.6</version>
        <scope>runtime</scope>
      </dependency>
    </dependencies>
  </profile>
</profiles>

Where I put FitNesse.SuiteAccceptanceTests it should point to your acceptance suite. The -c option is used to execute a command from the command line. The commands have the same format as the URL would have when you execute it in interactive mode. Hence the ?suite&format=text.

Now the integration tests are executed autoamtically when you perform a mvn install.

Note: if your application is a webapp, you can choose to launch it in the pre-integration-test phase and shut it down in the post-integration-test phase. The de-facto web server to use is Jetty, but that’s out of the scope of this blog. In the Xebium project, you can find a complete example of a POM file.

Dealing with Maven Home

By default Maven will look in $HOME/.m2/ for its settings.xml. When you have your settings on a different location you need to have the M2_HOME environment variable set to that location. The Maven classpath plugin takes into account the M2_HOME variable as of version 1.6.

There’s an intersting low-level class in the Android SDK called Looper. Each app has at least one, because it powers the UI Thread. You can create Android apps perfectly fine without ever using Looper yourself, but it’s an interesting thing, so let’s take a look under the bonnet.

Structural overview of Android’s Looper API.

The visible building blocks are Looper, Handler and Message. Behind the scenes, there’s MessageQueue. Each Looper is tied to a single Thread, and each Thread has at most one Looper. The Looper is accessed primarily through the Handler class.

Handler has the methods through which you obtain message instances and submit them to the message queue of the associated looper. Once your message is at the front of the queue, the Handler is also the object to process that message. You can implement the message processing behaviour either by subclassing Handler and overriding the handleMessage(..) method, or by creating the Handler with an implementation of the Handler.Callback interface.

Messages have five public fields. The int what defines the message type. It allows a single Handler (or Handler Callback) to handle multiple kinds of messages using a switch construct. The two ints arg1 and arg2 and the object obj are free format arguments that you can use however you see fit. The replyTo field is outside the scope of this blog post.

What about ExecutorService?

Java 1.5 introduced the util.concurrent package and, with it, the Executor framework. This framework is included in the Android SDK and the Looper is similar in purpose to a SingleThreadExcecutor, albeit clearly less versatile: you can’t use Callable‘s and Futures, you can’t change your mind about the chosen ExecutorService implementation or tune the queue length.

You might therefore ask “Why reinvent the wheel?”.

The reason is that Looper has a different performance profile. Recall that the UI thread is powered by a Looper. What you can’t tell from the diagram shown earlier is that the Message objects are kept in an object pool and used over and over. This means that, if you choose the message payload right, a looper can run indefinitely without creating garbage collector load.

The gold standard for a UI is to refresh sixty times per second. This gives the user the smoothest scrolling. Had the UI Thread been built on top of an executor service, the garbage collector load would have made such a refresh rate impossible and the user wouldn’t have been scrolling smoothly for very far.

Putting Looper to use

The most common use of the Looper API is as a means to hop onto the main thread from a background thread. This is how the onProgress() and onPostExecute() methods of AsyncTask are implemented.

class HandlerSample implements Handler.Callback {

  private final Handler mHandler = new Handler( Looper.getMainLooper(), this );
  private static final int MSG_TYPE_A = 1;
  private static final int MSG_TYPE_B = 2;

  /** E.g. a sensor callback or an IntentService. */
  void someMethodThatRunsInTheBackground() {

    // Background processing goes here...

    // The obtainMessage() and sendMessage() methods are thread-safe and can
    // be called without external synchronization.
    Message msg = mHandler.obtainMessage( MSG_TYPE_A, resultObj );
    mHandler.sendMessage( msg );
  }

  /** Invoked on the UI Thread, by means of Looper.getMainLooper(). */
  @Override public void handleMessage( Message msg ) {
    switch (msg.what) {
      case MSG_TYPE_A:
        // Processing goes here
        break;
      case MSG_TYPE_B:
        // Processing goes here
        break;
    }
  }
}

Incidentally, if you ever need to check whether the current thread is the Main thread, simly test ( Looper.myLooper() == Looper.getMainLooper() ). This can be a useful complement to StrictMode.

Using your own Looper

Besides the main looper, it’s perfectly possible to create your own Looper and do message processing in a background thread. By nature, this is a low-level construct and not all apps need it. Peripheral I/O is a good candidate for handling in this manner, for example, talking Bluetooth to an Arduino.

To begin using a looper, you need to call Looper.prepare() and Looper.loop() on the Thread that will do the looping. The call to loop() doesn’t return; from the moment you call this method, your thread is processing messages until the quit() method is called on its Looper.

class BackgroundLooper extends Thread implements Handler.Callback {

  /** Careful: this field will be null for some time after start(). */
  public Handler handler;

  @Override public void run() {

    Looper.prepare();

    handler = new Handler( Looper.myLooper(), this );

    Looper.loop();
  }

  @Override public void handleMessage(Message msg) { /* ... */ }
}

The SDK includes HandlerThread to take the boiler plate off your hands and make all this a bit easier.

Remarks

• When using Handler, make sure you enqueue messages with the one of the send() methods and not with the dispatchMessage(..) method. The latter comes first in an alphabetically sorted autocompletion pop-up, and you wouldn’t be the first person to call the wrong method .
• If you create a Handler with a constructor that doesn’t take a Looper argument it will use the current thread’s Looper, throwing an Exception if there is none. I think it’s better to be explicit, and always use an initializing constructor with either Looper.getMainLooper() or Looper.myLooper() as an argument.
• The MessageQueue is seldom used directly, but you can get it from the Looper to add an IdleHandler to it.
• Be careful when you hold on to managed objects such as Activities and Views in a background service. Just like with AsyncTask, you can get into all kinds of trouble if you refer to a UI element that is no longer valid.
• When you call Looper.quit(), the looper exits as soon as it can. It finishes processing the current message, but it doesn’t process any other messages left in its queue. If you want the looper to finish processing the remaining messages, put a “poison pill” message on the queue that tells your Handler to quit() its looper.

I’ve taken up sketchnoting recently, and I love it! So, what is sketchnoting? Why is it useful? And how do you get started?

The answer to the first question is pretty straight-forward: Sketchnoting is a way of note taking that involves not just notes, but also sketches. Mike Rohde, the godfather of sketchnoting, defines it as taking rich visual notes, mixing handwriting and drawing to create a more appealing set of notes. And that’s exactly what it is.

To me, sketchnoting is appealing, because as it turns out I’ve been doing it for the past decade, thinking I should really structure my “mind maps” more like Tony Buzan‘s. Then, I saw an awesome TEDx vid by Rachel Smith from The Grove Consultants and encountered The Sketchnote Army. It dawned on me that what I’d been doing had a name, was not as strange and uniquely “me” as I’d previously thought, and it was gaining momentum as a cool thing to do at conferences and meetings. I decided to get better at sketchnoting and went looking for ways to do so. I joined a Meetup group by Petra Hegenbart. Never made it to one of those meetups, but in the online discussions we had leading up to the meetups, Petra mentioned an online Rockstar Scribe course by Alphachimp. I enrolled in the course and subsequently read The Sketchnote Handbook by Mike Rohde.

And now, I’m hooked. I’ve developed the sort of passion for sketchnoting that keeps you in a continuous flow. I _love_ to sketchnote, and feel like I _have_ to do it. Now, in and of itself, the fact that I think it’s fun is probably not enough reason for you to try your hand at it. So what is?

The main reason to start sketchnoting, in my opinion, would be that it allows for true active listening, where you engage with a topic in a holistic way allowing you to focus your attention and fully immerse yourself in a subject, be it a talk at a conference, a meeting or a group discussion. If you show what you’re doing to the people around you, e.g. by drawing your notes on a whiteboard, flip chart or projector, sketchnoting can contribute to a highly interactive and adaptive meeting. There is something about seeing the group discussion being drawn as they speak that captures people’s imagination and holds their attention in a way that just doesn’t seem to happen with a Powerpoint, Keynote or even a Prezi.

So, how do you start? That’s the beauty of sketchnoting: You’re probably ready to start right now. Just get some paper and your favorite pen and you are ready to go. Just start listening for metaphors and models in the conversations around you and draw those images combined with carefully calligraphed text. If you’re like me though, you like to select “the best” gear for everything, including sketchnoting. If that’s you, this is my kit:

• Analog Sketchnoting
• Paper: Moleskine, A4, A3, flip chart, plotter paper.
• Markers: Black, grey, one color. I prefer 0.7 ArtLine fine liners, Edding 345 grey markers, and Stabilo felt pens for color.
• Tape: Masking, Duck, Scotch.
• Digital Sketchnoting
• Computer: Wacom Intuos 5 Tablet + Sketchbook Pro.
• iPad: Pogo Connect Stylus + Sketchbook Pro.

Any way your structure your notes is fine, but there are a few common layouts you could use to get started. A two- or three-column spread with a header and footer, for example. Or a nine-box layout with the main topic in the center (yes, just like a mind map!). Basically, any page layout you find in a magazine or on a website might be useful.

I’ve done two presentations/workshops on sketchnoting so far. One at Xebia, the other at Agile Holland. Both were very successful in that most, if not all, participants have now taken up sketchnoting, have bought the book, and are having entirely too much fun!