See this reference resource for further reading.

UPDATE

From a modeling perspective it makes more sense to add another item for item_1 in table_2 – but with a different timestamp which is the range primary key attribute. See this updated version.

• http://www.chromium.org/chromium-os/poking-around-your-chrome-os-device
• http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-series-5-chromebook

Der Hardware-Switch für den Developer-Modus ist Geräte-abhängig; die Anleitung bezieht sich auf das Samsung Serie 5 Chromebook.

Das Upgrade lief bis kurz vor Ende reibungslos, dann meldete der Update-Manager Probleme mit dem Flash Plugin-Installer (ein Schelm, wer Böses dabei denkt). Eventuell lag es daran, dass während der Installation die Verbindung zum WLAN getrennt worden ist. Jedenfalls schloss der Installationsvorgang mit einem Fehlerreport bzgl. des Flash-Installers ab und führte den Aufräumen-Schritt nicht mehr aus. Auf das Senden eines Problemberichts musste ich aufgrund der fehlenden Verbindung zum WLAN verzichten. Ich konnte diese auch nicht mehr vor dem Neustart wiederherstellen.

Nach einem Reboot startete ich direkt danach wieder den Update-Manager, der mir mitteilte, dass eine vorher stattgefundene Installation nicht vollständig abgeschlossen werden konnte. Richtig – aber wenig beruhigend. Der Update-Manager installierte und entfernte dann einige Pakate erfolgreich – ein neuerliches Aufrufen zeigte einen bekannten und erfreulichen Zustand: “Es gibt keine Aktualisierungen, die installiert werden können”. Ende gut, alles gut? Ob das erwähnte Entfernen von Paketen äquivalent zum Aufräumen-Schritt des Aktualisierungsvorgangs war, bleibt jedenfalls unklar.

Folgende Maßnahme werde ich vor einer nächsten Aktualisierung vornehmen: Deinstallation der Pakete flashplugin-installer und flashplugin-downloader

Der Launcher macht direkt einen wesentlich besseren Eindruck, er reagiert umgehend auf Maussteuerung (“Berühren” des linken Bildschirmrands) und verschwindet auch schnell wieder. Vertikales Scrollen funktioniert reibungslos. Das wirkt insgesamt wirklich flüssig(er) auf meiner Hardware* als noch in 11.04. Das Einblenden über die Meta- alias Windows-Taste scheint mir allerdings die effizientere Methode.

Die Auswahl an mitgelieferten Themes ist sehr reduziert, Human wird nicht mehr default angeboten (überhaupt noch?), Standard ist Ambiance. Damit kann ich mich arrangieren; es wirkt insgesamt konsistent. Völlig unsinnig, da inkonsistent, ist die wechselnde Positionierung der Buttons zur Fensterkontrolle (Maximieren, Minimieren, Schließen). Im Max-Modus befinden sie sich links, im Größen-angepassten Modus rechts. Über die Unsinnigkeit des Wechsels auf die linke Seite hatte sich seinerzeit Alexander Johannesen deutlich geäußert.

Was mir fehlt, ist das einfache Erstellen von Startern und das Hinzufügen in den Launcher, also Rechtsclick auf den Desktop -> Starter erstellen und per Drag and Drop auf den Launcher ziehen. Der Desktop heißt im übrigen auch wieder “Desktop”, nicht mehr “Arbeitsfläche”. Hoffentlich bleibt es jetzt dabei. Ebenso fehlt die Möglichkeit, Mini-Apps wie eine Temperaturanzeige Panels hinzuzufügen bzw. dort anzulegen.

Hände weg vom CompizConfig Settings Manager

… jedenfalls, wenn man ein ganz normaler User ist wie ich, der einfach einmal etwas ausprobiert (ja, RTFM – beim nächsten Mal). Die Veränderung von 2-3 Einstellungen zu Fenstereffekten im ansehnlichen GUI ließ den Desktop einfrieren. Das ist inakzeptabel und hat auch nichts damit zu tun, vorher Anleitungen gelesen oder nicht gelesen zu haben. Nach einem forcierten Neustart waren Launcher und Top-Panel verschwunden. unity --reset und unity --reset-icons brachten keine erfolgreiche Rekonstruktion, so dass ich zu “Ubuntu 2D” wechseln musste. Ärgerlich.

Fazit bis dato: Unity ist besser geworden, ist aber meines Erachtens deshalb noch nicht ausgereift, weil die genannten nützlichen Features fehlen und die wechselnde Links-Rechts-Positionierung der Fensterkontrolle ein echter Usablity-Bug ist. Speziell die Individualisierungsmöglichkeit des Desktops ist heute eine klare Erwartung. Das Hin und Her zwischen “Desktop” und Arbeitsfläche” ist auch nicht gerade Ausdruck einer klaren Idee – jedenfalls im Localization-Team. Dass ich von nun an Unity verwende, ist nicht sicher. Eventuell bleibt es bei der Nutzung von Gnome (jetzt in Version 3.2). Bei allem Gemecker zu letztendlich Kleinigkeiten, die den Desktop betreffen, muss ich aber wieder betonen, dass es großartig ist, dass es Linux, Ubuntu und all die anderen Distributionen gibt. Danke dafür!

p.s. Wer einen ersten Eindruck vom Look and Feel gewinnen möchte, sollte sich einfach http://www.ubuntu.com/tour/ anschauen.

* Thinkpad T61 14″, 2GB RAM, Intel® Centrino® T8300 Duo @ 2,4GHz, Nvidia Quadro NVS 140M

1. Increase of code coverage in the unit tests (quality aspect)
2. Introduction of a memcached based MySQL result cache (performance aspect)

The code coverage ratio (and IMO the lines coverage ratio is the crucial one) is a core KPI in unit testing. A perfect scenario provides 100% successful tests touching 100% of the lines of the tested code (assuming the tests are written seriously). The tool of choice in PHP is PHP_CodeCoverage maintained by Sebastian Bergmann. Sebastian is also the creator of PHPUnit. It’s no surprise that both tools integrate seamlessly. In order to generate an HTML code coverage report while running PHPUnit tests just pass option --coverage-html followed by the target location where you want to store the report files.

I have published the code coverage report generated while running QuaaxTM’s tests/AllTests.php on the project’s homepage: http://quaaxtm.sourceforge.net/report/index.html. The total lines coverage ratio is 97.27%, and it is 98.30% for the src directory where the Topic Maps constructs implementations such as TopicImpl or TopicMapsImpl are located.

Why the ratio is not 100%? For several reasons; the most important ones explained in the following:

1. The abstract root class ConstructImpl for example defines a lot of method stubs declared as protected, e.g. see ConstructImpl::_hasVariant(). The actual implementation is located in NameImpl::_hasVariant(). Having the protected stubs in ConstructImpl allows function calls from any Topic Maps construct implementation (as all of them extend ConstructImpl) – but not from outside! The tradeoff is that none of those stubs is touched in the unit tests. As ConstructImpl is an abstract class only creating a mock object which extends ConstructImpl would allow testing those stubs. However, what’s the value of having successful assertNull‘s here?
2. Private constructors in helper classes CharacteristicUtils and VocabularyUtils basically cannot be accessed.
3. Further, certain edge case exceptions are not triggered (e.g. the unsuccessful execution of a START TRANSACTION statement in class Mysql) – and it seems that PHP_CodeCoverage has still some minor bugs: E.g. I really cannot explain why the closing brace in ScopedImpl::_getBindingTable() remains untouched.

The main new feature in version 0.7.0 is the memcached based QuaaxTM MySQL result cache. It’s a common server side caching practice to store MySQL result data in memcached in order to return that data from RAM for a specified period – and thus avoid database reads. If the caching period has expired data will be fetched from MySQL and stored in memcached again. In QuaaxTM Mysql::_get() provides this storage gateway (enhanced for unit tests in MysqlMock::_get()). Interestingly Amazon has recently annonced ElastiCache “[...] a distributed, in-memory cache that can be accessed using the popular Memcached protocol.“.

Result caching has to meet two conditions:

1) The cache has to be enabled. The result cache is implemented as a (PHP)TMAPI feature and therefore is simply enabled by passing the specific feature string “http://quaaxtm.sourceforge.net/features/result-cache/” – a URI – as first parameter and the Boolean true as second parameter in TopicMapSystemFactory::setFeature(). Consequently, set false to disable the feature.

2) Using the result cache has to be allowed. Just enabling the cache and – once cached – letting the getters return data from memcached will cause serious problems in merging procedures as some of those getters are also used in TopicImpl::mergeIn() and/or TopicMapImpl::mergeIn(). If data has been updated on database level since caching time this will result in corrupt Topic Maps data as the result cache won’t be updated or invalidated on database updates (static caching). In order to avoid complex and therefore error-prone status setting (regular vs. merging) I decided to introduce an internal API to establish sound caching control. Let’s have a look at the following example in AssociationImpl (represents an association):

public function getRoles(Topic $type=null)
{
return $this->_getRoles($type, true);// set result cache permission to true
}

protected function _getRoles(Topic $type=null, $resultCacheAllowed=false)
{
// code goes here
}

The public AssociationImpl::getRoles() – required by PHPTMAPI – represents the external API while the protected AssociationImpl::_getRoles() represents the internal one. Obviously, _getRoles() is used in merging procedures or any QuaaxTM internal operations which just let parameter $resultCacheAllowed having the default value false (by – again – defining _getRoles() in ConstructImpl as protected method stub all extending classes can access this function).

Currently, the result cache is only implemented in AssociationImpl::getRoles(), AssociationImpl::getRoleTypes(), and TopicMapImpl::getAssociations(). Rollout is on the roadmap. However, it is not necessary to implement the result cache in all PHPTMAPI-getters as most of the Topic Maps constructs implementations come with a property holder which serves as a runtime cache. The implementation rule was that if a construct property is represented in the construct representing database table the property holder will be implemented. The property holder e.g. holds the literal values of an occurrence and is passed in the constructors. This means that after having constructed OccurrenceImpls via TopicImpl::getOccurrences() OccurrenceImpl::getValue() won’t require a database read but will return the value from the property holder. Updates on properties have effect on both layers, database and property holder (dynamic caching).

The following cache scenario holds for associations now:

1. TopicMapImpl::getAssociations() will return the associations data from memcached after initial retrieval from database
2. AssociationImpl::getRoles() will also return the association roles data from memcached after initial retrieval from database
3. RoleImpl::getPlayer() and RoleImpl::getType() then will fetch the needed data for constructing the respective TopicImpl from the property holder

A second call for TopicMapImpl::getAssociations() in runtime won’t even require memcached access. Initially retrieved data will also be stored in a class member and then returned from that runtime cache. The same caching feature is implemented in TopicMapImpl::getTopics(). Cache invalidation is available for both caches (semi-dynamic caching).

Both efforts, increasing the code coverage in the unit tests as well as introducing a server side caching layer using a widespread mature technology like memcached have pushed QuaaxTM another step towards becoming a serious Topic Maps engine for production environments on the LAMP stack. Stay tuned.

Mit folgendem Vorgehen konnte ich meinen Workspace inkl. SVN wiederherstellen:

1. In den Metadatenordner der Projekte wechseln: cd workspace/.metadata/.plugins/
2. Alle Metadaten der Projekte entfernen: rm -rf org.eclipse.core.resources/ (via http://letsgetdugg.com/2009/04/19/recovering-a-corrupt-eclipse-workspace/)
3. Projekte einzeln über File -> Import -> Existing Projects into Workspace importieren (via http://forum.ubuntuusers.de/topic/eclipse-svn-subversive-import-existing-projec/#post-2485358).

Auch Projekte unter Versionskontrolle mit SVN können danach wieder einwandfrei bearbeitet und mit dem Repository synchronisiert werden.