Es ist 16:21 und ich sitze hier alleine mit Tilo in der Firma. Ist schon irgendwie witzig, wenn die Firma nur von einem Azubi und einem Praktikanten besetzt ist 
Ich hab’ bis jetzt die zweite Java-Klasse geschrieben (Debugversion des JSONObjectBuilder) und mich weiter mit jQuery und sIFR beschäftigt und ‘ne Menge über CSS-Selektoren gelernt.
Gleich gehts ins langverdiente Wochenende und heute abend wird Stoffies Geburtstag gefeiert.
Heute war wieder mal Minimalbesetzung. Detlef hat sich trotz Krankheit ins Büro geschleppt, wahrscheinlich will er alle anstecken, das war nicht so ganz ersichtlich. Wir haben kurz über den JSONObjectBuilder geredet und Performance-Schwachstellen erkannt und Detlef hat mir gezeigt, wie’s schneller geht Morgen werd’ ich dann noch ne Debug-Version der Klasse schreiben, die bei Bedarf Fehleingaben erkennt und entsprechen reagiert. Da diese Fehlerbehandlung aber wieder teuer ist, wird es eben zwei Klassen geben. Eine für den Entwicklungsprozess und eine für den Produktiveinsatz.
Den Rest des Tages hab’ ich mich mit jQuery beschäftig. jQuery ist eine JavaScript Library, die für den Einsatz im Browser gedacht und entwickelt wurde.
Um jQuery zu benutzen musst du es hier runterladen und die folgende Zeile in den head-Tag deines XHTML-Dokumentes übernehmen:
<script src="jquery.js" type="text/javascript"/>
Fertig 
Die wohl wichtigste Funktion von jQuery hört auf den Namen $ und wird wie folgt benutzt:
$("#headline")
macht im Grunde dasselbe wie document.getElementById(“headline”), allerdings mit zwei wichtigen Unterschieden.
Will man beispielweise auf alle h3-Elemente innerhalb eines Elements mit der ID “top” einen Clickhandler legen gäbe es drei verschiedene Wege:
<h3 onclick="javascript:clickhandler();">...</h3>
function init() {
var top = document.getElementById("top");
var h3s = top.getElementsByTagName("h3");
for(var i=0; i<h3s.length; i++) {
h3s[i].onclick = clickhandler;
}
}
$("#top h3").click(clickhandler);
Möglichkeit #1 hat denselben Nachteil wie die Nutzung des style-Attributes für CSS-Befehle. Layout und Struktur werden vermengt. Und man muss kein Genie sein, um zu sehen welche der letzten beiden Möglichkeiten die einfachere ist 
Heute waren wir das erste Mal zuwenig Leute zum Kickern, und dafür braucht man eigentlich nur vier. Detlef, Marco und Moritz sind immer noch krank. Andi und Tobi waren bei einem Meeting. Oliver hatte frei. Andreas hat diese Woche Berufsschule und Jörg gings dann nachmittags auch noch schlecht, also isser nach Hause gegangen Der harte Kern waren Barbara, Anika, Tilo und ich. Mein Arbeitstag war auch ziemlich unproduktiv. Morgens hab’ ich meine JSONObjectBuilder-Klasse noch etwas überarbeitet und dann Detlef per Mail geschickt. Bis da ein Feedback zurückkommt (wahrscheinlich incl. Verbesserungsvorschlägen) werd’ ich mir mal sIFR genauer angucken und damit rumspielen.
Um nicht auf meinen eigenen Wohnzimmer-Server angewiesen zu sein, bin ich mit meinem Blog umgezogen. Von der alten Addresse wird man nun automatisch weitergeleitet.
Habe heute morgen meine Arbeit am Palava-Framework, um genau zu sein an der JSON-Serialisierung, beendet und wurde prompt von Detlef mit einer neuen Aufgabe versorgt. Für einen aktuellen Auftrag, den wir gerade an Land ziehen konnten, sollte ich sowas wie eine Machbarkeitsstudie durchführen, obwohl das Wort hier eigentlich Overkill ist. Der Kunde will auf seiner Seite, die wir ihm bauen sollen , diverse Überschriften in bestimmten Schriftarten haben. Ich sollte also recherchieren, inwiefern es möglich ist, in (X)HTML-Seiten eigene Schriften zu benutzen bzw. einzubetten.
Auf folgende Möglichkeit bin ich gestoßen:
@font-face {
font-family: “Frutiger”;
src: url(frutiger.eot), url(frutiger.pfr);
}
h1.frutiger {
font-family: “Frutiger”;
font-size: 150%;
}
Also per CSS eine Schrift deklarieren, die dann bei Bedarf vom Webserver geladen wird. Klingt erstmal gut, allerdings gibts nur zwei verschiedene Formate, die unterstützt werden:
.eot vom IE (ab Version 4.0) und .pfr für Netscape. Gecko-basierte Browser verstehen diese CSS-Anweisung gar nicht.Weil es auf proprietären Technologien basiert, wurde es bereits in CSS 2.1 aus der Spezifikation entfernt.
Nächster Schritt war die Suche nach alternativen Lösungsansätzen. Da haben wir (Anika, Oli & ich) uns zusammengesetzt und mal drüber nachgedacht und sind auf folgende Sachen gekommen:
Alternative #1
GIFs bzw. PNGs mit dem jeweiligen Text und der entsprecheneden Schrift erzeugen und einbetten. Allerdings nicht per Hand, weil sich die Inhalte ja ständig ändern, also müsste man die Bilder vom Backend generieren lassen. Für PHP gibts da beispielsweise schön Libraries, die sowas anbieten. Allerdings kann man den Text dann nicht selektieren und so richtig schnell wird das auch nicht sein.
Alternative #2
Einen Flashfilm erstellen, der als Parameter eine Schriftart (bzw. deren Name) und den zu rendernden Text erhält und das dann darstellt. Dann wäre der Text schonmal selektierbar, allerdings müsste mann den Flashfilm auch skalieren können, falls man mal eine kleinere Schriftgröße nehmen will, bzw. die Position verändert und an der Stelle dann weniger Platz hat.
Alternative #3
So ähnlich wie #1, allerdings erstellt das Backend keine statischen Bilder, sondern SVGs. Also xml-basierte Vektorgrafiken, deren Präsentation dann der Browser übernimmt. Und da liegt dann auch schon der Haken: SVG unterstützen z.B. Firefox und der IE nicht nativ, sonder nur per Plugin. Schade, denn Vektorgrafiken kann man gut skalieren ohne dass sie an Schärfe verlieren und erzeugen weniger Overhead und Traffic als Flash und Bilder.
Alternative #4
Als wir Flash als Variante in Betracht gezogen hatten, kam Anika eine Erinnerung an eine kleine Technologie, die das Problem bereits auf diese Weise gelöst hat. Des Rätsels Lösung heisst sIFR (sprich: siffer) und steht für “Scalable Inman Flash Replacement”. Besteht technisch aus einer JavaScript-Implementierung, die nach dem Seitenladen, dem Dom-Tree traversiert und nach bestimmten class-Attributen sucht. Diese Elemente, werden dann durch einen Flashfilm derselben Größe, mit der im CSS/Script-Bereich deklarierten Schrift gerendert. sIFR ist mittlerweile bereits in Version 3 erhältlich, hat also schon einige Stunden Bugfixing intus. Für nähere Informationen sei euch die offizielle Website ans Herz gelegt und damit man sich auch was drunter vorstellen kann, hier eine Beispielseite.
Detlef? Krank.
Moritz? Krank.
Oliver? Krank.
Anika? Krank.
Marco? Krank.
Tobi? Noch (!) gesund.
Andreas?Berufsschule.
Ihr seht, wir sind heute dünn besiedelt. Im Montags-Meeting waren wir heute nur zu fünft (Jörg, Andi, Tobi, Tilo und ich). Die ersten paar Stunden war ich damit beschäftigt, mein bereits funktionierendes Programm zu verstehen (JSONObjectBuilder). War im Grunde nur ein kleiner Denkfehler von mir. Also jetzt kann man mit Hilfe meiner Klasse aus einem POJO (Plain Old Java Object) ein JSONObject bauen. Das klappt auch soweit alles ganz gut, wenn man die korrekte “Syntax” bzw. Reihenfolge der Methodenaufrufe einhält. Da fehlt jetzt noch die Fehlerbehandlung.
Irgendwie hab’ ich’s geschafft, dass meine Klasse (JSONObjectBuilder) genau das macht, was sie soll. Klingt ja erstmal ganz gut. Aber nach meinem Verständnis dürfte es nicht funktionieren. Am Montag werd’ ich also damit beschäftigt sein, herauszufinden, wieso mein Programm das tut was es tut. Ich würd’s “Unconscious Prorgamming” nennen.
Nach drei Tagen recherchieren, testen und rumspielen habe ich gestern mit Detlef über meine Ergebnisse und meine weiteren Aufgaben gesprochen. Um etwas auszuholen:
Palava besteht, wie gesagt, aus einem PHP Frontend und einem Java Backend. Beide kommunizieren über ein selbstgeschriebenes textbasiertes Protokoll. In der aktuellen Version werden vier verschiedene Formate unterstützt: Text, XML, JSON und PHP. Im Moment läuft der Großteil über PHP. Soll heißen: Java erzeugt aus den konkreten Objekten, die übermittelt werden sollen, PHP-konforme Strings, die dann wiederum von PHP mit eval() in PHP-Objekte umgeformt werden. Ähnlich läuft es mit JSON, nur das der eingehende String mit json_decode() in ein Objekt überführt wird. Beide Verfahren sind sehr unflexibel, wenn es darum geht auf Backend-Seite weitere Informationen in ein Objekt zu packen. Java unterstützt nicht, wie etwas ActionScript 3, das Konzept der “Dynamic Objects”, bei denen man zur Laufzeit, ohne Deklaration in der Klasse einem Objekt Attribute und sogar Funktionen zuweisen kann. Optimale Lösung für das Java-Backend wäre also ein Objekt, das alle Informationen meines ursprünglichen Objektes (das es zu senden gilt) in typisierter Form enthält und zusätzlich nach der Instanziierung modifizierbar ist. Hier kommt die json.org-Library ins Spiel. Dort gibt es eine Klasse namens JSONObject, die so etwas wie einen manipulierbaren JSON-String repräsentiert. Intern arbeitet diese Klasse mit einer HashMap<String, Object>, also einer Liste bestehend aus Schlüssel/Werte-Paaren. Diese Map kann beim Initialisieren durch eine andere Map, via Reflexion (getter/public member) oder eben zur Laufzeit mit Daten gefüllt werden. Man hat also ein dynamisch manipulierbares Objekt, das man zu einem Zeitpunkt, vorzugsweise beim Versenden ans Frontend, mit seiner toString()-Methode in einen JSON-String umwandeln kann.
Meine Aufgabe besteht nun darin, eine Klasse zu schreiben (JSONObjectBuilder), mit dessen Hilfe ein Objekt sich selbst möglichst effizient und nachvollziehbar in ein JSON-Objekt überführt. Weil allerdings bisher mit JSON-Strings gearbeitet wurde, kam nur der JSONWriter zum Einsatz. Also muss ein Interface definiert werden, dass dann sowohl der JSONWriter als auch meine JSONObjectBuilder-Klasse implementieren müssen. Und alle Objekte bauen dann auf diese Interface-Methoden auf, ohne wissen zu müssen, ob sie zu einem JSON-String oder zu einem JSONObject werden.
Was das Praktikum betrifft war ich heute mal eher unproduktiv, dafür habe ich mich endlich dazu durchgerungen meinen Antrag auf Zulassung zur Abschlussprüfung abzugeben. Danach wollte ich noch meine QM-Klausur abholen und hab’ prompt Steps und Prof. Dr. Schiele getroffen. Steps und ich wollten wohl beide die gleiche Betreuerin . Steps hat auch gleich sein Thema eingereicht (Entwicklung eines Frameworks zur Analyse, Synthese und Visualiserung von Graphen oder so ähnlich). Mein vorläufiger Arbeitstitel heißt: Einsatz genetischer Algorithmen zur automatischen Beschriftung von Kartenmaterial. Wie gesagt nur der vorläufige Arbeitstitel, irgendwann demnächst besucht mich Prof. Dr. Schiele hier bei Cosmocode und wir besprechen die Details bzw. vereinbaren weitere Termine. Vielleicht hat ja Detlef (mein Chef) noch bessere Ideen. Wir werden sehen.
