Dazu macht mein kleines Programm nichts anderes als den Text in einen interpretierbaren Raum und ein paar Zeichen die abgeschnitten werden einzuteilen und dann den resultierenden Code als Anweisungen vorzunehmen. Die Anweisungen die der Interpreter versteht bestehen aus Quadrupeln. Ein Jedes Quadrupel besteht aus:

1. Einer Richtung.
2. Dem Rotwert aus dem RGB-Raum
3. Dem Grünwert aus dem RGB-Raum
4. Dem Blauwert aus dem RGB-Raum

Die einzelnen Werte werden sehr einfach ermittelt. Da Java auch Unicode versteht, wird der Modulo von 256 eines jeden Zeichens als Farbwert verwendet. Für die Richtung wird der Module von 4 des Eingabezeichens verwendet, wobei für ein kartesisches Koordinatenmodell gilt:

• 0: Es wird auf der Y-Achse nach oben gewandert.
• 1: Es wird auf der X-Achse nach rechts gewandert.
• 2: Es wird auf der Y-Achse nach unten gewandert.
• 3: Es wird auf der X-Achse nach links gewandert.

Das Ergebnis wird dann als PNG abgespeichert wobei das simple Testprogramm als Eingabe den Zielpfad erwartet. Bei der vorliegenden Konfiguration lässt sich aus allen getesteten Texten ein klarer Trend erkennen; der Graph sinkt. (x+, y-)

Kleine Fabel, Kafka
Text von Göthe
Ausschnitt eines Edgar Wallace Romans (Deutsche Übersetzung)

Das ganze ist natürlich nur ein sehr primitiver Algorithmus aber trotzdem ganz witzig zum herumspielen und so wie die generierten Graphen aussehen wohl zu gebrauchen um einen Levelgenerator zu schreiben. Wer es selbst ausprobieren möchte findet hier das zugehörige Java-Projekt.

Diese sehr einfache Vorschrift bringt schon erstaunliche Strukturen zu Tage wenn man sie nur sechsmal anwendet.

Zwar habe ich zur Zeit wieder viel mit Mathematik, vor allem Logik, im Studium zu tun doch muss ich zu geben, dass mich diese Anwendung nur peripher interessiert. Im Moment möchte ich mich mehr mit fraktaler Geometrie beschäftigen damit es mir möglich ist mehr als nur so simple Anwendungen um zu setzen

Wenn dennoch interessiert wie man obige Vorschrift imperativ umsetzt, kann sich gerne mein dazu gehöriges Java-Projekt anschauen.

Warum schreibe ich über das Phänomen? Weil ich erst in einer Foren-Diskussion lange aber ergebnislos damit beschäftigt war, einen Android-Anfänger davon zu überzeugen sich an die üblichen Techniken beim Android-Programmieren zu halten. Im speziellen wurden folgende Punkte als ekelhaft empfunden und gemieden:

• XML-Layouts
• Das Adapter-Konzept bei ListViews
• Aufteilen von komplexen Auswahlstrukturen auf mehrere Activities, da es der Komponentenstruktur zu wider laufe.

Ich muss zugeben, ich kann die drei Abneigungen gut verstehen. Auf dem Desktop kam es mir zu Anfangs auch seltsam vor für die UI-Programmierung die Sprache zu wechseln. Mir ist nach wie vor WinForms sympathischer als WPF wenn es um C# geht. Und da ich mittlerweile nicht mehr als .Net-Entwickler arbeite, werde ich mir WPF/Silverlight wohl sparen. Für Windows 8 und Metro empfinde ich im Moment JS/HTML5 sowieso interessanter.

Doch in Android gehört es integral dazu. Alle Beispielprogramme von Android verwenden XML-Layouts. Der LayoutInflator wird überall verwendet wo es darum geht, dynamisch View-Elemente zu erstellen.

Manuell den Codebaum mit einem selbst erstellen View-Geflecht zu erweitern sieht man eher selten. Es wirkt auch sehr verkrampft und seltsam wenn plötzlich 20 Zeilen Code in einer Methode stehen, die das selbe leistet wie fünf Zeilen Code mit einer View die per XML erstellt wurde.

Der zweite Punkt war, die starke Fixierung darauf, dass die ListView auch Methoden zur Verfügung stellen solle um Elemente hinzuzufügen. Ich persönlich bin sehr schnell damit zu Rande gekommen, dass ich den Adapter dafür verwende und nicht die View selbst.

Wie der Name schon sagt, kam mir das auch sauberer vor. Immerhin wird so der Controller bzw. der Adapter und die View nicht vermischt. Die View sollte wirklich nicht mehr Aufgaben haben als Events an die jeweiligen Handler weiter zu leiten.

Doch der Punkt den ich am wenigsten nachvollziehen konnte, war die Forderung, dass der Code Komponenten abbilden solle. Davon abgesehen, dass es schwer ist abzugrenzen was eine Software-Komponente ist und was nicht, war es diese Ansicht, dass die View unbedingt alle nötige Logik kapseln müsse.

Das führt m.E. dazu, dass der Code sehr groß und schwer zu warten wird an den Stellen an dem das System etwas anderes erwartet. Ganz einfach weil man um die Gegebenheiten des Frameworks herum arbeiten muss.

Mein erstes Android-Projekt ging ich zu Anfangs auch ähnlich an. Ich wollte eine View-Komponente schreiben, die es dem Benutzer ermöglicht mehrere Bilder hintereinander hinzuzufügen.

Doch da pfuscht einem das System gleich mehrmals:

• Man benötigt Zugriff auf die Activity da man bei einem Image-Picker im onActivityResult darauf reagieren muss.
• Das Auslagern von UI-Elementen in externe Libraries ist unangenehm gelöst. (R-Generierung etc.)

Mein ursprüngliches Ziel konnte ich damals wegen den oben genannten Gründen nicht umsetzen. Denn immer wenn man beginnt gegen die vorgesehene Architektur zu kämpfen, sei es in dem man ein Monster-Menü in eine Klasse packt anstatt sie – wie es mobile UI Patterns empfehlen und Android entworfen wurde – auf mehrere Activities aufzuteilen, geht der Schmerz los.

Seit kurzem praktiziere ich Pain Driven Development, welches besagt die Architektur immer so simpel und angenehm wie möglich zu gestalten. Erst wenn der Schmerz losgeht, wird es geändert.

Damit fahre ich ganz gut und habe endlich angefangen meinen blinden YAGNI-Fleck abzulegen.

Aber um was genau geht es da? Nun ja, in meiner App wird ein selbst geschriebenes JSON/REST-Framework verwendet, dass mit einem Server-Framework interagiert. Als HTTP-Client wurde anfänglich auf den Apache Commons HttpClient gesetzt. Nachdem dieser unglaublich langsam ist im Vergleich zur UrlConnection – in meinen Tests um den Faktor 3,5 – wurde umgestellt.

So weit so gut, doch wo happert’s jetzt? Folgenden Code habe ich verwendet um die Verbindung aufzubauen, die Parameter an den Server zu schicken und dann den resultierenden InputStream zurück zu geben:

				connection = (HttpURLConnection)myAppUrlObj.openConnection();
				connection.setDoOutput(true);
				connection.setDoInput(true);
				connection.setChunkedStreamingMode(0);
				OutputStream stream = connection.getOutputStream();

				authenticateIfPossible(request);

				writer = new OutputStreamWriter(new BufferedOutputStream(stream));
				appendTextParamsOnly(writer, request);
				writer.flush();
				writer.close();

				return connection.getInputStream();

Ich denke der Code ist so weit selbst erklärend. Dieser Code funktioniert auch wunderbar auf Android-Geräten die mit Android 2.2 oder älter betrieben werden. Aber wehe man verwendet ein neueres Model. Bumm: Der Server returniert seltsame Fehlermeldungen. In-Application-Fehlermeldungen, von wegen er kenne meinen Accesskey nicht. Was ist da los?

Nachdem alles mit dem JS-Tester abgeglichen ist, der fröhlich die Nachrichten an den Server schickt und gültige Resultate zurück gibt, ein JUnit-Test auf meiner Java SE VM ohne Probleme ebenfalls ein gültiges Resultat bekommt und dann auch noch die alte HttpClient-Implementierung auf Android 2.3 funktioniert ist es klar wer der Übeltäter ist.

Dann musst ich noch einen Tag warten, denn der Server-Mann sitzt in den Staaten, und dann wurde – bei ihm war es wohl 3 in der Früh – der Fehler gesucht. Schnell war klar, dem Server fehlt etwas. Wireshark meinte zwar, dass gültige Daten weg geschickt wurden, aber offensichtlich stimmte das Encoding nicht.

Schnell die Lösung dazu basteln:

				connection = (HttpURLConnection)myAppUrlObj.openConnection();
				connection.setDoOutput(true);
				connection.setDoInput(true);
				connection.setRequestProperty("Content-type", "application/json;charset=utf-8");
				connection.setChunkedStreamingMode(0);
				OutputStream stream = connection.getOutputStream();

				authenticateIfPossible(request);

				writer = new OutputStreamWriter(new BufferedOutputStream(stream), ENCODING);
				appendTextParamsOnly(writer, request);
				writer.flush();
				writer.close();

				return connection.getInputStream();

Oh Wunder, kaum macht man’s richtig funktioniert es auch …

Im Folgenden geht es um HTML in Verbindung mit JQuery und CSS. Wie es heutzutage üblich sind, baue ich gerade eine mehr oder weniger monströse App die massiv auf JS angewiesen ist. (Das ist allerdings auch keine Website sondern eine Spotify-App)

Mit JQuery gibt es mehrere Template-Frameworks. In meinem Fall sieht ein Template ca. so aus:

<script id="myTmpl" type="text/x-jquery-tmpl">// <![CDATA[
<div class="wunderWuziMitFloatingLeft">
    ${VAL1} ${VAL2}</div>
// ]]></script>

Ich hatte also ein komplexes Template das aus einem DIV bestand, welches in einer Liste floaten sollte. Was ich nicht bedacht hatte: Das verfluchte float zerschießt mir natürlich das restliche Layout das aus lauter absolut und relativ positionierten DIVs bestand.

Lösung? Die wunderWuzi-Klasse floatet jetzt nicht mehr sondern wird als inline-box angezeigt. Problem gelöst.

So wird in diesem Talk davon gesprochen, das eine gute App folgende Eigenschaften haben sollte:

• Fresh – Apps sollen sich immer auf aktuelle Daten beziehen, sie soll “immer Up to Date” sein.
• Psychic – Apps sollen die System-Ressourcen und das Android-Framework verwenden um Informationen über den Benutzer zu verwenden um dem Benutzer Arbeit zu ersparen. In solche Kategorien fallen z.B. Scrobbling und Vorschläge bei last.fm, automatisch in den Energiesparmodus nach 22 Uhr etc.
• Adaptiv – Die App existiert für den Benutzer nur als Kontext in dem er etwas erledigen möchte. Das bedeutet, dass die App niemals schlecht auffallen darf, z.B. wenn viel manuelle Texteingabe verlangt wird oder ähnlich “unmobile” Anforderungen in der UI gestellt werden. Die App soll wie die Unterhose sein: Hübsch wenn man sie sich bewusst anschaut aber im Alltag unsichtbar und bequem.
• Smooth – Die App soll schnell, flüssig und angenehm bzw. responsive reagieren.

Mit dem letzten Punkt möchte ich mich in diesem kleinen Artikel beschäftigen. Doch zu aller erst die Fragen: Wie werden Anwendungen langsam, zäh und warum frieren sie ein?

Normalerweise werden im onCreate einer Activity-Klasse alle Objekte die während der Lebenszeit der Activity verwendet werden müssen initialisiert.

Das sind zum einen die relativ günstigen findView-Aufrufe und auf der anderen Seiten Objekte wie ListView-Adaptars, EventHandler, Code um auf Server zuzugreifen, Code um auf die SQLite-DB zuzugreifen, etc. Die Manigfaltigkeit der Performance-Fresser ist erschlagend groß.

Dazu kommen noch andere Todfeinde der Android-Smoothness:

• Der Garbace Collector, ein Erzschurke dessen Durchlauf mitunter 600ms Zeit kosten kann. Man spricht auch davon, dass er die Welt “anhält”.
• Die versteckten Objektbrüter die den GC in Zugzwang bringen können. (Anonyme Klassen für Event-Handler, foreach-Schleifen die Iterator-Objekte anlegen, etc.)

Doch auf diese Aspekte werde ich im folgenden nicht eingehen, sondern mich auf die onCreate-Problematik stürzen. Zu dem Thema GC und wie man ihn vermeidet sind vor allem Ressourcen zum Thema Spieleentwicklung sehr zu empfehlen. Siehe z.B. (Beginning Android Game Development, Google IO Talks Memory Management, Android Real Time Game Development)

Doch zurück zu onCreate, im folgenden möchte ich ein kleines Framework vorstellen, mit dem ich massive Verzögerungen durch ORMLite -und PageViewer- Instantiierungen schmerzlos gemacht habe.

Dem möchte ich allerdings eine Annahme vorausschicken, und zwar dass es dem Benutzer vollkommen egal ist ob eine Operation 200ms oder 2s dauert, solange die App präsent ist und nicht einfach vor sich hinstockt bis endlich die Activity aufpoppt.

Unter dieser Prämisse sollte klar sein was im onCreate passieren darf:

1. Die Content-View muss gesetzt werden.
2. Die View-Referenzen können gesetzt werden. Wie oben bereits geschrieben, sind die Aufrufe relativ günstig und verzögern den Aufbau der Activity auf meinem schwachbrüstigen Wildfire kaum. (Aufpassen: findView-Aufrufe dürfen nicht in andere Threads ausgelagert werden, weil nur der Thread auf die Referenz zugreifen darf, der sie auch hergestellt hat.)
3. Code anstarten, der die teuren Operationen in einem anderen Thread anstartet.

Schauen wir uns doch einfach ein kleines Code-Beispiel an bei dem es sehr einfach ist die Schnecke zu finden:

public class SlowAppTestActivity extends Activity {
    private ListView lvItems;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        lvItems = (ListView)findViewById(R.id.lvItems);
        ArrayAdapter<String> adapter = new ArrayAdapter<String>(this, R.layout.item, getItems());
        lvItems.setAdapter(adapter);
    }

    public List<String> getItems() {
    	final ArrayList<String> items = new ArrayList<String>();
    	for(int i = 0; i < 35; i++) {
    		items.add(String.format("Number %d and very useful!", i));

    		// simple code to sleep ...
    		try {
    			Thread.sleep(200);
    		} catch(InterruptedException e) {e.printStackTrace();}
    	}

    	return items;
    }
}

Das zugehörige Layout sieht so aus:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:orientation="vertical" >
    <TextView
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:text="Ready!" />
    <ListView
        android:id="@+id/lvItems"
        android:layout_width="fill_parent"
        android:layout_height="fill_parent" />
</LinearLayout>

Also wenden wir jetzt mit dem AsyncTask aus dem Android-Framework die drei Punkte an. Zu erst setContentView und findView-Aufrufe erledigen. Im nächsten Schritt den Code für die asynchrone Ausführung anstarten und im letzten Schritt, wieder im UI-Thread, die UI updaten.

Mit diesen Anpassungen sieht das onCreate nun so aus:

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        lvItems = (ListView)findViewById(R.id.lvItems);

        AsyncTask<Void, Void, ArrayAdapter<String>> task = new AsyncTask<Void, Void, ArrayAdapter<String>>() {

			@Override
			protected ArrayAdapter<String> doInBackground(Void... params) {
				ArrayAdapter<String> adapter = new ArrayAdapter<String>(SlowAppTestActivity.this, R.layout.item, getItems());
				return adapter;
			}

			@Override
			protected void onPostExecute(ArrayAdapter<String> adapter) {
				lvItems.setAdapter(adapter);
			}
		};

		task.execute();
    }

Es steht jedem frei beide Varianten auszuprobieren. Der Unterschied ist enorm. Doch wie kann man diesen Teil sinnvoll abstrahieren um es an mehreren Stellen zu verwenden?

Schauen wir uns, unsere drei Schritte noch einmal an. Der erste Schritt kann genau wie er ist im onCreate bleiben. Hier macht es also keinen Sinn herumzudoktern, dito für den zweiten Schritt. Der dritte Schritt wird schon interessanter, denn es soll etwas asynchron ausgeführt werden.

Im letzten Teil soll wieder etwas synchron im UI-Thread ausgeführt werden. Daraus lassen sich nun zwei Methoden ableiten die wir gleich in ein Interface gießen:

public interface IAsyncWorker {
	public void processAsync();

	public void onAsyncFinish();
}

Jetzt ist klar was passieren soll, aber wer erledigt es? Eine einfache Klasse namens AsyncWorkerLauncher bietet sich dafür an.

public class AsyncWorkerLauncher extends AsyncTask<Void, Void, Void> {
	private final IAsyncWorker worker;

	public static AsyncWorkerLauncher from(IAsyncWorker worker) {
		return new AsyncWorkerLauncher(worker);
	}

	public AsyncWorkerLauncher(IAsyncWorker worker) {
		this.worker = worker;
	}

	@Override
	protected Void doInBackground(Void... params) {
		worker.processAsync();
		return null;
	}

	@Override
	protected void onPostExecute(Void result) {
		worker.onAsyncFinish();
	}
}

Mit diesen paar Zeilen Code kann jetzt unsere Activity umgebaut werden:

public class SlowAppTestActivity extends Activity implements IAsyncWorker{
    private ListView lvItems;

    ArrayAdapter<String> adapter;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        lvItems = (ListView)findViewById(R.id.lvItems);
        AsyncWorkerLauncher.from(this).execute();
    }

    public List<String> getItems() {
    	final ArrayList<String> items = new ArrayList<String>();
    	for(int i = 0; i < 35; i++) {
    		items.add(String.format("Number %d and very useful!", i));

    		// simple code to sleep ...
    		try {
    			Thread.sleep(200);
    		} catch(InterruptedException e) {e.printStackTrace();}
    	}

    	return items;
    }

	@Override
	public void processAsync() {
		adapter = new ArrayAdapter<String>(SlowAppTestActivity.this, R.layout.item, getItems());
	}

	@Override
	public void onAsyncFinish() {
		lvItems.setAdapter(adapter);
	}
}

Und Bumm: Plötzlich haben wir eine Activity die sich tatsächlich smooth anfühlt und deren Code nicht umständlicher zu lesen ist.

Das Projekt findent man übrigens hier: SlowAppTest.

Doch so untriebig war ich dann auch wieder nicht. Seit Oktober 2011 bin ich Programmierer in einem Startup und habe damit die Gefilde der Enterprise-Softwareschmieden verlassen um in die vermeintlich “niederen” Gefilde der Jungunternehmen abzusteigen.

Das tolle daran ist, dass ich jetzt nicht mehr auf JEE oder .Net Enterprise Entwicklung gebunden bin und dementsprechend mit Frameworks arbeiten darf, die auch Spaß machen.

Zu aller erst wäre da Android. Jede Woche arbeite ich mich weiter in dieses Framework hinein, fluche und zürne über Design-Entscheidungen, staune über die Google IO-Präsentationen und hacke Java so viel wie noch nie.

Eines darf ich verraten: Es ist eine Neuentwicklung und ich baue mein Haus auf einer grünen Wiese!

Dazu kommen Javascript bzw. JQuery und HTML5. Up to date, nicht nur in der Freizeit sondern endlich auch beruflich.

Doch um es knackig zusammen zu fassen mit welchen Frameworks ich mich zur Zeit beruflich oder privat beschäftige:

• Play Framework (Java Web-Entwicklung, die Spaß macht!
• Android Framework
• HTML5/Javascript

Doch welche Ideen trage ich mit mir herum die es wert sind umgesetzt zu werden?

• Haushaltsbuch-App: Die Idee ist schnell erklärt, denn dabei handelt es sich um ein Haushaltsbuch das immer dabei ist. Der Grundgedanke ist alle Ausgaben aufzuzeichnen und zwar dann wenn sie passieren. Bonus: Server-Anwendung mit Play-Framework.
• Ernährungs- und Trainingstagebuch-App: Wieder eine simple Anwendungen deren Zweck aus meiner eigenen Faulheit kommt. Ich schaffe es einfach nicht mich aufzuraffen und diese Daten am PC einzutragen oder auch nur in ein Büchlein einzutragen. Denn diese Büchlein neigen dazu nie dort zu sein wo ich sie gerade haben möchte.
• Musikkenner-App: Was soll das sein? Manchmal sitze ich da und browse durch meine MP3-Files und bin absolut unzufrieden. Ich ordne den einzelnen CDs Jahre zu und fühle mich wie jemand, der dumpf in der Vergangenheit wühlt, wenn ich dann doch Musik starte. Also muss neues her! Die Idee: Eine Anwendung schreiben die, die lokale Musikdatenbank scrobbled und dann Vorschläge anhand des vorgefundenen Musikgeschmacks machen. Als nötige Wissensdatenbank könnten dabei Echonest, Yahoo Music oder Musicbrainz herhalten.
• Ein paar Android-Spiele.

Neben diesen Ideen beschäftige ich mich auch damit, auf java-forum.org hilfreich zur Stelle zu sein um durch auftretende Fragen etwas zu lernen. Stackoverflow gehört hier natürlich auch genannt.

As you may know there is a special BAT-file for this purpose in the lib directory of the Ghostscript directory.

If you use the ps2pdf.bat or in a *nix-enviornment the ps2pdf-file there you have to specifiy at least the source- and the destination-file for the command. The command itself writes the parameters in a temp-file in the temp-directory because the authors are frightened to overrun the command buffer in the shell.

This little detail makes it essential for you to correctly set the TEMP and the TMP environment variable. Because if you don’t, you do not know for sure where the variable is pointing to.

In my case I had to figure out why the command did work as a charme when I ran it in a shell but failed when it ran itside a self written Job-Framework.

The log displayed following error message:

Ghostscript 8.60: **** Could not open temporary file ''

and

**** Unable to open the initial device, quitting.

But why did this happen? I don’t know exactly but I think it has to do with the difference between a regular user and a very restricted service-user.
I’m writing this in English because I couldn’t find a good explanation for the problem with ghostscript 8.60. If you search just for ‘Ghostscript **** Could not open temporary file ”’ you’ll get really fast good explanations but sometimes I’m just a blockhead. I hope this short blog article helps somebody.

But after getting the old version running I had to update to version 9.02. Because I use the 64 bit version. I first tried 9.01 but the gswin64c.exe and the gswin64.exe just stopped working with an unexpected error so I switched to the newest version.

But – and that’s a really annoying point – the people from Ghostscript didn’t update the BAT-files. So the environment variables which get set in the gssetgs.bat point to non existing gswin32-exes.

To get this running just change the lines:

if %GS%/==/ set GS=gswin32
if %GSC%/==/ set GSC=gswin32c

if %GS%/==/ set GS=gswin64
if %GSC%/==/ set GSC=gswin64c

And don’t forget to add the needed directories to the path variable when you try to run ps2pdf. In the new version you not only have to add the Ghostscript directories

 %ProgramFiles%\gs\gs9.02\lib
 %ProgramFiles%\gs\gs9.02\bin

You also have to add a directory with a strfind.exe init. In a 64-bit environment that’s:

%windir%\SysWOW64

So to get the new ps2pdf.bat running you have to change the gssetgs.bat file to the following:

@echo off
@rem $Id: gssetgs.bat 6300 2005-12-28 19:56:24Z giles $

rem Set default values for GS (gs with graphics window) and GSC
rem (console mode gs) if the user hasn't set them.

if %GS%/==/ set GS=gswin64
if %GSC%/==/ set GSC=gswin64c

set path=%ProgramFiles%\gs\gs9.02\lib;%ProgramFiles%\gs\gs9.02\bin;%windir%\SysWOW64
set TMP=%YOUR_TEMP%
set TEMP=%TMP%

Die letzten Wochen und Monate waren beinahe vollkommen von meinem Studium und meiner neuen Arbeit ausgefüllt. Doch da ich noch immer viele Wege habe, bin ich auf den Fahrten etwas zum Lesen gekommen. Da ich gerade eine Lehrveranstaltung mit dem Thema Stackbasierte Sprachen besuche, habe ich mir auch gleich die PDF-Version von Thinking Forth gekrallt. Dank meines neuen EBook-Readers, lese ich es jetzt sogar.

Dabei kam mir ein altes .Net-Projekt wieder in Sinn: RSE NonForth, eine Skriptsprache deren Prinzip nahtlos an das von Forth anschließt:

• Kommandos bzw. Words exekutieren Code.
• Der Interpreter ist dumm und bietet außer der Infrastruktur eines Stacks, Dictionaries – quasi Namespaces – und einer Handvoll Primitives zum Nachladen anderer Bibliotheken überhaupt keine Funktionalität.

Dadurch war es sehr leicht möglich – auch ohne akademische Erfahrung – einen funktionierenden Interpreter zu schreiben. Da ich mich bei meiner neuen Stelle für eine Java-Firma entschieden habe – mir persönlich ist .Net nach wie vor sympathischer aber das Unternehmen war wiederum sympathischer als die .Net-Firmen – werde ich das ganze Ding wohl neu in Java schreiben und schon in der ersten Version die Möglichkeit von Chainlets inkludieren.

Chainlets – WTF?

Die Grundidee von Chainlets fußt auf der Vorstellung von untereinander verknüpfbaren Widgets. Also: Warum kann ich z.B. nicht mein Widget dass mir die Übersicht aller Kalendareinträge präsentiert nicht beibringen, dass es den Termin einem beliebigen anderen Widget per Doppelclick übermittelt?

Ganz einfach darum nicht, da es den Widget-Plattformen die ich kenne, wie z.B. die von Windows oder die Vorschläge von W3C, keine Infrastruktur für solche Aufgaben zur Verfügung stellen. Ich habe dann lang herum überlegt wie diese Schnittstelle zu beliebigen anderen Widgets funktionieren könnte und bin zu dem Schluss gekommen, dass dies am einfachsten in einer Stackgetriebenen Umgebung möglich wäre.

So werden die einzelnen Widgets vollkommen von einander entkoppelt und sie können zusammen arbeiten wie es der Programmierer vorsieht. Er muss die einzelnen Widgets nur untereinander verketten.

Damit war auch gleich die Begrifflichkeit gefunden: Chainlets.

Aber Forth …

Forth hat jetzt natürlich einen Nachteil – jedenfalls für so eine Scripting Engine – ich müsste einiges herumdoktoren damit ich beliebige Objekte auf den Stack legen kann. Natürlich könnte das mit Adressen funktionieren zu denen im Bedarfsfall gesprungen aber im Endeffekt entwickelt sich die Vorstellung zu einer gar grausigen Angelegenheit.

Darum schreibe ich einen Interpreter dessen Syntax der von Forth ähnlich ist und deren Philosophie sowie Handling einiges an Ähnlichkeiten aufweist aber dennoch etwas ganz anderes ist.

Jedem der an dieser Stelle keine Ahnung hat wovon ich hier schreibe lege ich folgende zwei Lektüren ans Herz:

• Starting Forth – Eine Einführung die dem interessierten Programmierer eine neue Art des Denkens mithilfe von Forth zeigt.
• Thinking Forth – Ein Buch über das (Kunst-)Handwerk Software Entwicklung mit Forth. (Sehr interessant da hier sehr schön gezeigt wird, dass iterative Modelle wie Scrum schon in den 80ern existierten und von Forth-Codern angewandt wurden.)

Der Aufbau

Ganz grob u. simpel aufgezeichnet wird das System so aussehen:

Dabei sticht ins Auge, dass eine Unterscheidung zwischen Word u. einem so genannten System Word existiert. Der Unterschied ist schnell erklärt: Da in diesem System alle Words immediate sind, wird das Word sobald es in der Queue selektiert wird ausgeführt.

Von dort aus kann es dann aber noch weiter Einfluss auf den Programmfluss nehmen. Ein gutes Beispiel dafür ist z.B. ein IF oder eine Schleife wie +LOOP. Ein IF muss z.B. wissen welche nachfolgenden Words in den eigenen Bereich fallen. Dazu benötigt es mehr Zugriff auf das System also nur den Daten-Stack.

Da aber nicht alle Word so einen Zugriff auf das System benötigen, wie z.B. DUP oder DROP, existieren auch explizit Words die nur Zugriff auf den Stack haben.

Das Diagramm ist schön u. gut aber wie sieht der Ablauf aus?

Soweit so gut. Nun ist es wohl an der Zeit mit dem Schwafeln aufzuhören und mit dem Coden anzufangen.

Dabei geht es zum einen um die übliche Problematik die nicht bedacht wurde und ganz sauber auf die OS-API zurückzuführen sind. Also z.B. bei Dateinamenvergleiche prüft Windows – jedenfalls nicht Windows 7 – nicht auf gleiche Großkleinschreibung, Linux schon. Natürlich vollkommen dämlich und meine Schuld.

Doch dann ein Bug in PHP selbst der wieder nur in Linux auftritt. Die Funktion explode lieferte – ohne ersichtlichen Grund – Nullwerte im resultierenden Array. Was zum Teufel?  Zu aller erst dachte ich, ich wäre der einzige der diesen Fehler “gefunden” hat und darunter leidet doch dann fand ich diesen Eintrag.

Dort wurde das ganze auf doppelte Leerzeichen zurückgeführt die bei mir nicht auftraten da ich anhand eines “/” trenne. Was also tun? Zum einen hätte ich mit Regex drüberfahren können, doch die Implementation von Regex gefällt mir in PHP nicht weswegen ich zu einer simplen For-Schleife mit einer darin enthaltenen If-Abfrage gegriffen habe.

    /**
     * Calls explode with '/' as delimiter on $url and removes every empty
     * string in the resulting array and returns this array.
     * @param string $url
     * @return array(string)
     */
    private function GetUrlParts($url) {
        // I had to use this because on a free linux webserver explode didn't
        // work properly and returned empty fields in the array which lead to
        // errors
        $nonFilteredParts = explode('/', $url);
        $filteredParts = array();
        $filteredIndex = 0;

        for($i = 0; $i < count($nonFilteredParts); $i++) {
            $element = $nonFilteredParts[$i];

            if(strlen($element) > 0) {
                $filteredParts[$filteredIndex] = $element;
                $filteredIndex++;
            }
        }

        return $filteredParts;
    }

Anstatt explode(‘/’, $var) wird nun oben genannte Methode aufgerufen. Funktioniert nun, ist auch schon im Git-Repo eingechecked.