Immer noch ärgerlich: das Audible eigene Dateiformat, was sich nur mit den Audible Software-Playern abspielen läßt. Einziger Vorteil: die Kapitelnavigation.

Nun gibt es Möglichkeiten die Audible-Formate nach mp3 zu konvertieren. Am einfachsten geht das mit dem “alten” 4er Format (Datei-Endung .aa). Für dieses gibt es noch einen DirectShow-Filter (AudibleMediaPlayerFilter.exe) über den sich mit Programmen wie Goldwave oder anderen direkt ein grosses MP3-File erzeugen läßt.

Wie ich erst gestern gefunden habe, gibt es Programme die aus .aa oder .aax auch noch die Kapitel Informationen extrahieren, da diese auch vergleichsweise einfach (weil unverschlüsselt) auszulesen ist.

Damit kann man dann ein .cue Sheet für MP3DirectCut erstellen e voila schon hat man kapitelweise geschnittene MP3s aus dem langen Hörbuch gemacht.

Ein einfacher Converter, der Zeilen im Format HH:MM:SS einliest und ein fertiges CUE-File schreibt, sieht in Java so aus:

    public void convert(String[] args) {
        try {
            PrintStream cue = new PrintStream(new File(args[0]+".cue"));
            BufferedReader r = new BufferedReader(new InputStreamReader( new FileInputStream(args[0]),"Cp1252"));
            String line;
            String name = new File(args[0]).getName();
            String title = args[1];
            String artist = args[2];

            name = name.substring(0,name.lastIndexOf("."));
            cue.format("PERFORMER \"%3$s\"\r\n" +
            		"TITLE \"%2$s\"\r\n" +
            		"FILE \"%1$s.mp3\" MP3\r\n",name,title,artist);
            int i = args.length>3?Integer.parseInt(args[3]):1;
            while( ( line = r.readLine() ) != null ) {
                String p[] = line.split(":");
                int m = Integer.parseInt(p[0])*60 + Integer.parseInt(p[1]);
                int s = Integer.parseInt(p[2]);
                cue.format("  TRACK %1$02d AUDIO\r\n" +
                		"    TITLE \"(Track %1$02d)\"\r\n" +
                		"    INDEX 01 %2$02d:%3$02d:00\r\n" +
                		"",i,m,s);
                i++;
            }
            r.close();
            cue.close();
        } catch( Exception e) {
            e.printStackTrace();
        }
    }

Dieses CUE-File läßt sich in MP3DirectCut als Projekt laden und mit “Split save …” werden die einzelnen MP3-Files erzeugt, gleich mit richtigem Namen und ID3 Tags.

Meine Lösung: Komplett per Firewire auf den Rechner, dann mit x.264 komprimieren und nun als MKV speichern. Der Inhalt erschließt sich so aber immer noch nicht.

Da viel mir ein, dass miniDV ja einen DateCode schreibt, zu jeder Aufnahme also weiss, wann sie gemacht wurde. Etwas Googeln liefert das Tool DVDate, was diese Daten ans Licht bringt.

Damit lassen sich Szenen auffinden und man hat auch wieder die Information, wann etwas aufgenommen wurde.

Die Idee: erzeuge eine OGM Kapitel Datei und eine SRT Untertitel Datei und packe das Ganze mit mkvmerge in eine einzige MKV Datei.

Ein kleiner Converter in Java erzeugt die beiden Files. Einfach die Scenen als Text exportieren und den Converter mit “java -jar ChapConvert.jar bla_scn.txt” auf rufen und schon werden die Files erzeugt.

Zuvor sollte man allerdings den Scene-Editor von DVDate nutzen und die Scenen benennen. Mindestens eine Zeitstempel mit “%D” ist Pflicht. Wer sich die Mühe macht echte Namen zu vergeben, findet die Namen als Kapitelname und auch in den Untertiteln wieder.

Hier gibt das ChapConvert.jar

Verschiedene IDE Integrationen versprechen Abhilfe. Die Spring Tool Suite (STS) kann beispielsweise einen Abhängigkeitgraphen anzeigen, allerdings erlebt man eine Enttäuschung wenn man dies mit einem auch nur halbwegs ernsthaften Projekt versucht.Das Ergebnis ist enttäuschend: man sieht schlicht nichts, das Layout der Beans ist starr und die Kanten, die die Abhängigkeiten darstellen, laufen wild durch den Graphen. Man kann nicht mal erkennen, welcher Knoten mit welchem verbunden ist.

Die Möglichkeiten mit einem Graph zu arbeiten und so Übersicht zu erzeugen fehlt komplett. Wenn man hier den Luxus eines Werkzeugs wie yEd gewohnt ist, der vielfältige Möglichkeiten bietet, ist die Lösung schnell gefunden:

Man generiert einen Graphen im graphml Format, um ihn dann mit yEd bearbeiten zu können. Das ist, mit einem Satz gesagt, das was die angehängte Klasse tut.

Der Spring-Context wird mit Spring selbst gelesen und analysiert und dann wird ein graphml File ausgegeben. Dieses muss zu Beginn mindestens einmal durch einen Layout-Algorithmus (am besten Hierachisch), weil sonst alle Knoten übereinander liegen.

Mit einer Property-Datei kann man die Knoten noch automatisch einfärben, um bestimmte Knotentypen zu unterscheiden.

Den Quellcode gibts hier SpringDependencyGraphGenerator.

Mit dem yEd lassen sich mit dem fertigen Graphen auch noch weitere nützliche Dinge anstellen. So kann man z.B. ganz leicht Untergraphen erzeugen, die nur Vorgänger oder nur die Nachfolger eines Knotens zeigen.

Wie schlecht die Bilder mit STS werden können zeigt dieser Ausschnitt:

Einen Graphen der mit yEd layoutet wurde sieht man unten. Mit Hilfe der Vorgänger-Funktion sind in einem zweiten Bild nochmal die Abhängigkeiten einer DataSource herausgestellt.

Für eigene Projekte und insbesondere auch für das Einarbeiten in fremde Projekte ist es da sehr nützlich, wenn man genau sieht, was auf der Datenbank so alles passiert.

Hier hilft das Tool log4jdbc-remix sehr gut weiter, weil es sowohl alle Anfragen als auch die Ergebnisse mitschreiben kann. Es lassen sich auch eigene LogFormatter integrieren und selbst der Umgang mit mehreren Datenbanken ist in der neusten Release 0.2.8 kein Problem.

Da ich selbst auch schon über ein paar kleinere Probleme gestolpert bin, kann ich ausserdem den guten Entwickler-Support unterstreichen: Jedesmal hat Tim, der Owner des Projekts, sehr schnell reagiert und das Problem beseitigt oder einen Patch übernommen.

Mit dem Kauf der Lampen ging allerdings der Spass erst los …Bei uns im Haus gibt es nämlich viele solcher Halogenlampen als Einbauleuchten in der Decke. Das erste, was ich feststellen mußte, war, dass die neuen LEDs die Normmasse gar nicht einhalten.

Was bei manchen Leuchten nicht sonderlich stört, ist bei Einbauleuchten u.U. fatal, weil die LEDs schlicht nicht reinpassen.

Das nächste Ärgernis ist der eigentlich erwünschte geringe Energieverbrauch! Meinst sind bei Halogenbeleuchtungen nämlich elektronische Trafos verbaut (Schaltnetzteile), die eine gewisse Mindestleistungsabnahme benötigen. Wird zuwenig Strom verbraucht, dann beginnt die Spannung zu schwanken und die Netzteile laufen gefahr mit der Zeit zerstört zu werden.

Eingebaute LED Leuchtmittel quittieren solche Spannungsschwankungen mit einem hässlichen Flackern, schlimmer wie jede Neonröhre. Also musste ich auch noch die Netzteile austauschen, die freilich in der Zwischendecke versteckt und nur mit erhöhtem Aufwand zu erreichen waren.

Bleibt noch, dass LEDs immer noch nicht dimmbar sind und auch die Lichtfarbe – auch die sogenannten Warmweissen – leider nicht mit dem angenehmen Licht einer Halogenlampe mithalten können.

Soviel zum Thema Ernergiesparlampen / LEDs.

Leider fühlt sich auch Hector in keiner Weise so an wie man es von konventioneller Datenbank-Programmierung gewohnt ist. Das Java-API ist nach meinem Geschmack “gewöhnungsbedürftig” um es einmal diplomatisch auszudrücken.

Dabei gibt mit Spring-JDBC (oder neuerdings mit Spring-Data) längst gute Beispiele wie man es gut machen kann. Jetzt kann man natürlich einwenden, dass diese “alten” Ansätze für SQL-Datenbanken gemacht sind und sich daher nicht für NoSQL Lösungen eignen, aber wenn man zweimal hinsieht, dann merkt man schnell, dass das gar nicht stimmt.

Der Unterschied bei der Sicht auf die Daten besteht meiner Meinung nach im Wesentlichen im Datenmodell, oder in der Art wie man zum Datenmodell kommt: entweder klassisch relational und normalisiert, oder Abfrage-Orientiert und de-normalisiert.

Wenn das Datenmodell aber steht, ließe sich mit den Daten eigentlich genauso arbeiten wie mit SQL-Datenbanken: über eine Abfrage-Sprache. Im Falle von Cassandra ist das CQL. Parallelen gibt es mit Keyspace = Database, ColumnFamily = Tabelle, und Column / Row genug. Die Einschränkungen / Erweiterungen con CQL sind eben der Datenbank geschuldet (z.B. kein Join) und stören erst mal nicht, wenn man sich für das NoSQL Modell entschieden hat.

Jetzt gibt es mit Cassandra-JDBC sogar einen JDBC-Treiber für Cassandra, der auch CQL über JDBC in jeder Java-Anwendung verfügbar macht. Man sollte also meinen alles Handwerkzeug in Händen zu halten, um “vernünftig” arbeiten zu können.

Leider ist dem im aktuellen Release 1.0.5 (Dez 2011) von Cassandra nicht so.

Die Umsetzung ist etwas lückenhaft, so dass praktisch bei jeder anderen Anwendung (außer “Hello World”) Probleme auftreten.

Spalten sind nicht löschbar

Will man eine Spalte löschen, dann wird man im normalen SQL ein UPDATE … Feldname = NULL verwenden, was aber beide Spaltenorientierten Cassandra mit CQL nicht funktioniert. Dort muss stattdessen die Spalte selbst gelöscht werden mit DELETE Column(s) FROM ColumnFamily WHERE …

Unnötig umständlich wie ich finde. Man ist gezwungen UPDATES auf Rows in ein UPDATE und ein DELETE Statement aufzuspalten, wenn man einen Teil der Spalten löschen will. Gerade weil Cassandra aber kein festes Schema mit beliebig vielen Spalten, die auch nicht notwendigerweise gefüllt sein müssen, unterstützt, ist dies doppelt ärgerlich.

Selects auf NULL-Spalten funktionieren nicht

Wie schon erwähnt wird man in einer Cassandra Persistenz sicher häufig auf Rows treffen, bei der nicht alle Spalten mit Werten belegt sind. Statt bei einer CQL Anfrage dann aber NULL, oder zumindest in der JDBC Darstellung NULL bzw. den passenden Default zu liefern, stolpert man über eine Exception. Man kann gar keine Spalten abfragen, die nicht gesetzt sind.

Unzureichende Expression-Language

Cassandra kennt zwar bestimmte Typen Spalten. Allerdings liefert CQL kaum ausreichen Ausdrucksmöglichkeiten mit diesen Typen umzugehen. Man kann nicht einmal einen Timestamp erzeugen, ausser den nackten Long-Wert direkt einzugeben, um nur ein Beispiel zu geben. Dies erschwert die Formulierung von Abfragen wiederum unnötig. Man hätte leicht bestehende Implementierungen von ELs adaptieren können, um halbwegs verwendbare Ausdrücke in CQL einsetzen zu können.

PreparedStatements funktionieren nicht

In JDBC ist es eigentlich der Normalfall PreparedStatements zu nutzen. Nicht nur weil man dem Server Gelegenheit gibt, die Anfragen zu optimieren, auch Injection wird damit wirkungsvoll verhindert. Leider unterstützt Cassandra 1.0.5 solche Anfragen bislang nicht. Der JDBC-Treiber bietet sie dennoch an.

Wie man in der Beschreibung und im Quellcode nachlesen kann, werden die Bindings jedoch schon auf der Clientseite aufgelöst und dann zum Server geschickt. Damit könnte man leben, wenn das wenigstens funktionieren würde. Leider ist auch hier die Implementierung fehlerhaft, sodass oft genug die Bindung schlicht falsch ist und der Server die Anfrage mit einem Fehler quittiert.

Fazit

Will man Cassandra einsetzen, hat man sich so an das eine oder andere zu gewöhnen (oder wieder zu gewöhnen). Und damit meine ich nicht in erster Linie die Art der Datenmodellierung. Ich jedenfalls fühlte mich in mancher Hinsicht um eine paar Jahre in die Vergangenheit zurück versetzt, als man mit Oracle noch per Oracle Call Interface (OCI) sprechen musste. Aber wenns denn Cassandra sein muss …

Das Update von Serendipity auf die neuste Version war eh überfällig, also warum nicht gleich umsteigen auf WordPress. Sieht einfach hübscher aus und kann mehr.

Leider ging der Import der Daten nicht so einfach wie gedacht.

Zwar gibt es hier von Snowulf einen Importer und noch ein Update zur 1.5 hier. Aber zum einen muss man das Readme genau lesen und sich trauen, das SQL direkt anzuwenden auch wenn die WP Version nicht mehr stimmt, zum anderen sind dann immer noch nicht alle Inhalte mirgiert.

Der erste Importversuch wurde gleich mittendrin abgebrochen, weil der Nutzernamen im Import schon vergeben war und das Import-Script das nicht abfängt. Leider waren die Kategorien aber schon importiert.

Dann wurde die mehrsprachigen Artikel nicht übernommen. Okay das waren hier nur 4 und da konnte man das Englische manuell rüberziehen.

Aber es geht auch die Hierarchie der Kommentare verloren. Und die Formatierung von Quellcode geht in WP auch ganz anders (zum Glück aber besser, nur umstellen muss man trotzdem).

Noch eine gute Quelle ist hier zu finden. Dort wird auch beschrieben was man tun muss damit die alten Permlinks wieder funktionieren. Allein die Post-IDs konstant zu halten reicht natürlich nicht, weil die Links von s9y ganz anders aussehen und sich mit den Standard-Einstellungen von WP auch nicht nachbilden lassen.

Leider nutzt der Autor zum Umschreiben der URL eine Konfiguration lighttpd, was bei Apache2 natürlich nicht passt. Mit etwas PHP bekommt man das aber auch in der Griff. Nur die Feed-URL sind hier jetzt noch nicht gerade gezogen, aber ich befürchte soviele Abbonnenten hab ich gar nicht

Naja jetzt ist’s geschafft und vielleicht lebt dadurch das Blog wieder etwas auf.

der neue Polanski Film “Der Gott des Gemetzels”. Herrlich anzuschauen, absolute Empfehlung ein “Kammerspiel” im Kino mit tollen Charakteren, einer langsamen Entwicklung hin zum kompletten “Gemetzel” wirklich sehenswert. Von Constantin Film.

Die Persistenz ist – nach dem neusten Trend “back to the roots” – nur noch mit dem JdbcTemplate von Spring gemacht. Da kann man wieder richtiges SQL schreiben und weiß auch genau was passiert (bei Hibernate war ich mir nicht immer so ganz sicher).

Als es dann ans Testen ging und ich mir Gedanken um die Testabdeckung machte, fiel mir auf, dass das was bei if-Anweisungen oder bedingter Zuweisung im Java-Code als “missed 2 of 4 branches” an gemeckert wurde, an vielen Stellen in den Where-Clauses der SQL-Statements genauso auftritt.

Die Coverage in Java war also bei mancher Methode auf 100% aber das SQL-Statement ließ viele Varianten von ResultSets zu je nach dem, was man für Testdaten verwendet und welche konkreten Parameter man bindet.

Wie also läßt sich die SQL-Coverage messen?

SQL tracen

Zunächst einmal ist es nützlich die SQL-Statement mitschrieben zu lassen, die tatsächlich ausgeführt werden inklusive der aktuell gebundenen Parameter. Hierfür kann man Tools wie http://code.google.com/p/log4jdbc-remix/ bzw. http://code.google.com/p/log4jdbc/ verwenden. Diese JDBC-Treiber arbeiten als Proxy und werden einfach “zwischen” die Applikation und den echten Treiber “gehängt”. Dadurch wird es einfach möglich alle SQL-Statements die man bei Ablauf einer Testsuite an die Datenbank schickt mitzuschreiben.

Aber leider weiss man damit immer noch nicht, ob man nun alle möglichen “Zweige” aller Where-Bedingungen aller SQL-Statements durchlaufen hat.

SQL Rules und QAShrink

SQL Rules und QAShrink sind zwei Tool, die genau darüber Aufschluss geben können. Sie sind in der Lage ein gegebenes SQL-Statement zu analysieren nach der “Full Predicate Coverage” Methode. Es werden also Regeln erzeugt, die alle Verzweigungen oder Varainten die ein SQL-Statement erzeugen kann, berücksichtigt.

Dabei werden nicht nur Where-Bedingungen in Betracht gezogen, sondern natürlich auch Joins oder Group By-Klauseln. SQLRules zeigt zu einen einzelnen Statement diese Rules an, so dass man sich anschauen kann, welche möglichen “Pfade” zur Ergebnisfindung durchlaufen werden können.

Regeln anwenden

Im nächsten Schritt lassen sich diese Regeln dann gegen einen Testdatenbestand anwenden / testen. Als Ergebnis bekommt man eine Aussage, ob die betreffende Regel verwendet wurde oder nicht, also ob dieser Pfad bei den zugrunde gelegten Daten durchlaufen wurde oder nicht. Das ist genau die SQL-Coverage die man braucht.

Das andere Tool QAShrink kann dieses Prinzip gleich auf eine ganze Liste von SQL-Statements anwenden. Es erzeugt dann Aussagen bzgl. der Coverage der SQL-Statements und der Vollständigkeit bzw. der Redundanz der Testdaten.

Auf diese Weise kann man also ziemlich schnell herausfinden, welche Testdaten überflüssig und welche noch zu ergänzen sind, um – bei gegebener Liste der SQL-Statements – die SQL-Coverage möglichst hoch zu machen.

Zusammenfassung

Das Vorgehen zum Erreichen einer möglichst hohen SQL-Coverage läßt sich also so zusammenfassen:

1. Mit einem JDBC-Proxy Treiber erzeugt man eine Liste von konkreten SQL-Abfragen, die von einer TestSuite mit hoher Code-Coverage erzeugt wird.
2. Die Liste der SQL-Statemant füttert man in QAShrink und läßt sie gegen den gleichen Testdatenbestand wie die TestSuite laufen.
3. Anhand der Ergebnisse kann man den Testdatenbestand so lange um Datensätze ergänzen, bis eine optimale SQL-Coverage erreicht ist.

Links zu den Tools:
http://in2test.lsi.uniovi.es/sqltools/sqlrules/
http://in2test.lsi.uniovi.es/sqltools/qashrink/

Ich selbst bin auch nicht unbedingt ein Freund von „graphischer Programmierung“ oder geschwätzigem XML, was fast schon Programmiersprache sein will, aber in fast jeder
Hinsicht unhandlicher ist als eine „normale“ Programmiersprache wie Scala oder Java.

Aus diesem Grund reizte mich die Idee einen alternativen Ansatz zu versuchen. Da ich, wie gerade schon erwähnt, kein Freund von „in XML programmieren“ bin, sollte die
Beschreibung des „Prozesses“ – das Prozessmodell – in Java erfolgen.

Hier bietet sich das State-Pattern an, welches eine Prozessablauf mit Hilfe von Zustandsobjekten und einem Kontext beschreibt. Konkret werden also nur Interfaces bzw. abstrakte Basisklassen benötigt, die von einem konkreten Prozess implementiert
werden. Dazu der „Contract“ der den Ablauf / die Semantik beschreibt und schon kann ein „Prozess“ statt in XML in Java geschrieben werden.

Allerdings kann man nun einwenden, dass das normale Ausführungsmodell einer JVM mit Threads nicht die gleichen Vorteile bietet wie eine Workflow-Engine.

Inspiriert von den Ansätzen von Dalma und Javaflow oder auch den Arbeiten von Doug Lea (FJTasks) ist aber auch auf einer Java VM mehr möglich, als einfach für jeden Prozess
und jede seiner Nebenläufigkeiten einen neuen Thread zu starten.

Würde man das tun, wären diese bei den eingangs genannten Anforderungen sicher bald aufgebraucht (viele Prozessinstanzen, womöglich viele davon nur wartend).

Auch mit der Skalierbarkeit haben viele Workflow-Engines gewisse Probleme, weil sich die Arbeit schlecht über einen Cluster verteilen läßt. Aber auch hier gibt es im Standard
Java gute Lösungansätze, wie z.B. GridGain.

Ein weiterer Aspekt, den Workflow-Engine bedienen, ist Prozesspersistenz. Prozesse, die auf der Engine ablaufen, lassen sich persistieren. Damit ist der Ablauf unterbrechbar, wiederherstellbar und nachvollziehbar. Wenn allerdings Prozesse normale durch normale Java-Objekte dargestellt werden, dann lassen sie sich auch mit einfachen ORM Mitteln persistieren.

Zu guter letzt sind die meisten Prozesse immer auf irgendwelche Services angewiesen, die von ihnen aufgerufen werden, oder Calls an die Prozesse absetzen. Hierzu soll
für das Java basierende Prozessmodell ein Container /Application-Server zum Einsatz kommen. Meine Wahl fiel auf Spring, wobei sicher auch andere Lösungen denkbar wären.

Das Rezept für meine Workflow-Engine lautet also:

• Prozesse sind Java-Klassen, die nach dem State-Pattern einen Ablauf implementieren.

• Diese Klassen sind typischerweise Spring-Beans, die vom Container „Services“ konsumieren.

• Die Klassen sind Serializable und damit „Remoting“-fähig für GridGain.

• Die Klassen tragen (optional) Persistenz-Annotationen, welche die Engine dafür nutzt den Prozesszustand zu persistieren.

Heraus kommt eine Lösung,

• die hochskalierbar ist, weil Prozesse über GridGain auf einem Cluster von Nodes verteilt werden können.

• die den gewohnten Komfort einer IOC-Umgebung genießt, bei der nach Belieben „Services“ genutzt werden können (natürlich nicht nur Webservices).

• die den Prozesszustand nach jedem Prozessschritt mit Hilfe eines Persistenzproviders wie z.B. Hibernate persistiert.

• die Prozesse einfach als Java-Programm beschrieben, welches mit einfachsten Mitteln und voller IDE Untersützung entworfen werden kann.

Besonders den letzten Punkt möchte ich noch einmal unterstreichen: Man kann es gar nicht hoch genug bewerten, wie viele Vorteile sich allein dadurch ergeben, dass man in
der gewohnten Umgebung arbeiten kann:

• kein Lernen einer Prozessbeschreibungssprache (in XML).

• alle Möglichkeiten und Konstrukte einer Programmiersprache wie Java.

• die gewohnte IDE.

• simples Debuggen und Testen (noch besser zu unterstützen durch Mocks und eine spezielle Engine, die ein lokales Debuggen direkt ermöglicht).

• Einfachstes Wiederverwenden von vorhandenem Code oder vorhandenen Services (meist sind keinerlei „Wrapper“ oder „Adapter“ notwendig).

Wie die Lösung konkret aussieht, werde ich wohl heute nicht mehr zusammenschreiben, deshalb wird’s demnächst hier ne Fortsetzung geben …

]]> http://cogito-ergo-blog.de/blog/2009/07/28/workflow-engine-einmal-anders/feed/ 0