Towards Enhanced User Interaction to Qualify Web Resources for Higher-Layered Applications

By the way, there are some more photos of the conference:

Photos of the DW10@IARIA

I had my presentation and session chair on Valentine day: Towards Enhanced User Interaction to Qualify Web Resources for Higher-layered Applications.

Some impressions:

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.

In this contribution we present our adaption of information quality aspects to qualify Web resources. We selected knowledge-related iq-criteria and take it now as tool to implement iq-mechanisms stepwise into the qKAI framework. We exemplify some criteria of information quality like relevance, accuracy or response time and then derive assessment methods for certain iq-criteria enabling rich, game-based user interaction and semantic resource annotation.

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