First, we introduce some background regarding the qKAI application framework. In Section 2 follows what we see as prerequisite to utilize Open Content for higher-layered applications. Section 3 gives an overview of the qKAI application frameworks’ system design. Section 4 offers some more details concerning the qKAI hybrid data layer as one system level of the 4-tier design. Section 5 shows further services and components, Section 6 exemplifies use cases and further application scenarios. At least this contribution ends up with a conclusion and future work in Section 7.

But there are more aspects to know about it, which I am going to write a about taking Subversion (SVN) as an example. One of it is lowering the barrier of committing code and enabling to maintain flow. First we have to distinguish between centralized and decentral VC. I will limit this post to the first.

If you have ever seen developers working without VC you might probably know what mess it is, them copying working revisions to a dedicated directory, delving further into curring edge one and then eventually figuring out what they have to revert to from one of these folders – for minutes. A VC saves a good amount of time sparing the developer bookkeeping about the changes he made. Most importantly, without VC more than a few developers couldn’t work on a common code base without overwriting each one’s changes, synchronizing those history-folders and a good amount of coordination. With VC sharing changes (and reverting to a former changeset) becomes feasible.

Management or QA can see what was changed by whom, when and in which context. Thus they’re able to transparently track progress and account revision transitions to tickets, roadmaps and milestones without the often referring to the programmers.
In SVN this can even be automatically done by establishing hooks – scripts to be run on given actions, such as the ‘commit’.

Software engineering wouldn’t be that easy as it is with VC. Novice programmers are inclined to keep their throphies, working functions for example, and drag them from revision to revision in commented-out parts of source files. In most cases this happens due to lack of understanding VC fullfills archival purposes: At any given time it is possible to revert parts of the code to a former revision, and reading them is possible, too.

Indeed that archival aspect is important in staging, where staging is the intermediate process to deploying an experimental/development version of a product to production systems. Should something go wrong a revert to a well-known working revision can occur. Even more importantly, errors can be tracked down to the small subset of code which actually has changed since last version.

Given common code-base updating systems becomes trivial: A revision is agreed upon to be promoted to a version to be deployed. On a systems that version is now checked-out and any upgrade scripts run (which should be versioned, too). The aspects earlier described in mind, some even version-control configuration directories.

A central versioning system enables usage of tools such as continuous integration, style-check and so on. As soon as code gets committed hooks can be utilized to trigger a build, test or check.
And, such hooks can be used to run a check whether coding styles have been applied by the committor – if not, the code can get rejected from being written to the shared code-base as long as the novice does not correct the violations. Because this is done automatically, by a “machine”, no one from the team (or the QA) seems educational. Without losing face the coder can fix his mistake silently and preserve motivation.

When faced with the challenge to paint a blank page or in our case, append to existing code, one has to overcome a virtual barrier. This barrier is said to be the exact opposite of the state called flow, which to achieve is desired in the pursuit of efficiency. VC utilized right can lower that barrier down to flow significantly:
Being able to get back to a working revision creates the feeling of safety and control, eliminating the need for explicitely storing and reading obsolete code or switching to update tickets or roadmaps maintains focus. Every commit becomes a small reward and updating to changes of others visualizes parallel and organized working of the group. With continuous integration and automatic (dev/staging) deployment one’s effords seem to have immediate consequences – which help keeping up motivation and everything the flow of productive working.

Yet assigning tasks not too hard and not to trivial is still the complementary challenge of the team leader.

These are “code lines” only, whatever CLOC means by that. Unit tests have not been counted as well as code within comments and the documentation.

Since the first version (revision 863), written by Jan Hein, the distribution changed a lot. Here is another visualization, again only “code lines” count:

In the next few days the amount of C/C++ code will double as our MySQL customizations will be extended. Most probably JSP will vanish in favour of Java and it could happen that the SQL code amount will stall where it is and a lot of Flex will be checked in.

We have about 12 design patterns in use, most of them have been introduced since revision 863.

But, as a future contributor to qKAI you don’t need to be afraid of mastering all the languages. Indeed you have the freedom to stick to two or three you know the best. That’s how everyone started and you can see where qKAI is now…

The specification of information units can be found here: http://qkai.org/spec/2008/10/

The Wikipedia Extractor prototype is available under http://qkai.org/WikipediaExtractor

This time I will write about Maven, which – as Monika already revealed – we utilize to generate (and publish) a simple documentation page. I do see Maven as a mean to conserve and reproduce a process such as building the application and packaging it. Someone who is new to “all this” will most probably forget about byte-code enriching, converting charsets or simply running tests and integration tests. By Maven a “mvn package” is as easy to remember as it preserves the convenience to not forget about running one of the steps mentioned above.
And, should the process be extended no present developer will even have the opportunity to omit eventual new steps; should one go his knowledge does not get lost.

An widely used alternative is Ant. We have decided not to use it primarily as it lacks the ability to resolve and download dependencies, which our current tool is able to. (See Ivy for Ant as dependency manager downloading from Maven repositories.)
By the time I wrote my thesis I have had to spend about a week to dig through qKAI’s dependencies, figure out which package requires another and how to update the clique in case of the errors I experienced.

Today we can even introduce new tools such as PMD or JDepend without burdening someone with installation, configuration or familiarization. A quick “notice the new reports on our page” at the distribution list suffices.

How we managed to automatically provide modified third party code and how we incorporated Maven with continuous integration is another topic. Such as enforcing coding styles and what we used Subversion’s scripts for. So, stay tuned.

Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project’s build, reporting and documentation from a central piece of information. (http://maven.apache.org/)

With Maven we got a nice project documentation now – available under http://docs.qkai.org. Especially the API section is work in progress and will be enhanced by and by.