OOP und Flow Design sind wie Yin und Yang

Je mehr ich in meinen Projekten Flow Design mithilfe der Event Based Components anwende, umso mehr stelle ich fest, dass auch die konventionelle Objektorientierte Programmierung sehr gut in das Konzept passt.

Das merke ich gerade besonders bei meinem "Talisa" Projekt. Seit einigen Tagen bastle ich intensiv an der Parser-Funktionalität.

Im Groben funktioniert das ja so, dass man drüben eine Zeichenkette reinsteckt und am anderen Ende kommt ein vollständiger abstrakter Syntaxbaum heraus. Sich das als Flow vorzustellen, ist eine Wohltat für die Hirnzellen. Und so habe ich das auch aufgebaut. Bis ich an den Punkt kam, als es darum ging, die Token-Liste zu parsen. Das ist alles andere als trivial, wenn man es ordentlich machen will.

Natürlich wollte ich das auch erst pur im Flow Design Stil angehen. Aber als ich begann, einen kleinen Plan zu schmieden, wie ich das am Besten umsetze ("Also erst müsste es dort hin fließen, dann kommt das dort hinein, dann ... Mist, da brauche ich wieder shared state, dann geht das wieder dort hin ... oh Gott!"), resignierte das Hirn schnell, indem es zu verstehen gab: "Boa, nee ... das ist doch nicht Dein Ernst, oder?! Das ist voll kompliziert, darüber nachzudenken! OOP fühlt sich hier viel besser an!"

Tatsächlich hatte ich auf Anhieb eine bessere Vorstellung von einer Lösung im OOP-Stil. Zwar noch nicht konkret, aber ich wusste, wie ich meine sogenannte "FlowPattern"-Komponente am liebsten verwenden möchte. Aber diese OOP-Komponente steckt völlig isoliert in meiner Flow-Komponente mit der Bezeichnung "Create_Flow_Ast". (Der verlinkte Quellcode ist noch völlig Work-In-Progress. Wie gesagt, ich bastle gerade noch am Parser.)

Ich hatte auch schon des öfteren vergessen, dass ich mich in einer einzelnen Flow-Komponente befinde, aufgrund der Isolierung. ;-)

Wann verwende ich(!) Flow Design und wann OOP?

Ja, die Betonung liegt hier auf "ich", weil es bei anderen Entwicklern wieder ganz anders sein kann. Die Liste kann aber als grobe Orientierung dienen, falls man noch nicht so das Gefühl dafür hat.

Flow Design:

• Beliebige rohe Daten müssen in abstrakte Datenstrukturen gebracht werden. Und dies kann in mehreren Etappen erfolgen.
• Man verwendet Closed-Source Komponenten oder fremden Code. Den sollte man sauber in eine Flow-Komponente stecken.
• Man kann sich sehr gut vorstellen, bestimmte Bereiche seines Codes asynchron ablaufen zu lassen. ➜ Diese Komponenten sollten in isolierte Flow Einheiten gesteckt werden!
• Es geht allgemein um Threads und asynchrone Verarbeitung? ➜ Flow, Flow, Flow und nochmal Flow! Ich kann das nicht oft genug betonen, weil Threads echt fies sein können. Ich bin schon oft ein Opfer von ihnen geworden. (So verrückt kann man gar nicht immer denken, welche Schlupflöcher diese "Biester" immer wieder finden. *g*)
  Daher: Jegliche Funktionalität von Threads getrennt halten. Threads isoliert halten und nur durch Flow-Eingänge und -Ausgänge an die zu erledigenden Aufgaben führen!
• Wann immer man vor seinem geistigen Auge einen Flow erkennen kann. Wenn das Lösen eines Problems durch Flow Design geradezu natürlich und einfach erscheint ... wenn das Nachdenken nicht sonderlich anstrengt, sondern im Gegenteil, es einen regelrecht mitreißt! Warum dann seine Zeit und Energie mit OOP verschwenden?

OOP:

• Die Verarbeitung ist komplexer und lässt sich eher umständlich und unübersichtlich als Flow beschreiben.
• Die Lösung für ein Problem ist in sich geschlossen, untrennbar und atomar. Warum soll man hier auf OOP verzichten?
• Man hat etwas Hierarchisches, was irgendwie verarbeitet werden will.
• Die Usability (aus Entwicklersicht) kann durch Verwenden von OOP deutlich verbessert werden. (Siehe mein "FlowPattern"-Beispiel von oben.)
• Es ist nicht beabsichtigt bzw. nicht sinnvoll, Funktionalitäten innerhalb der Komponente asynchron ablaufen zu lassen. (Wieder mein "FlowPattern" als Beispiel: Es ist weder sinnvoll, noch beabsichtigt, irgendwelche Threads innerhalb dieser Komponente hantieren zu lassen. Das wäre mehr als gefährlich!) Somit kann man getrost OOP nutzen, wenn ein gegebenes Problem dadurch leichter zu lösen ist.
• Wann immer man vor seinem geistigen Auge eine Interaktion von Objekten erkennen kann. Wenn das Lösen eines Problems durch OOP geradezu natürlich und einfach erscheint ... wenn das Nachdenken nicht sonderlich anstrengt, sondern im Gegenteil, es einen regelrecht mitreißt! Warum dann seine Zeit und Energie mit Flow Design verschwenden?

Abschließend noch einige Zitate von Bruce Lee, die man auf die Essenz dieses Beitrags gut projizieren kann:

"An der Kampfkunst ist nichts Geheimnisvolles. Nimm die Dinge wie sie sind: Schlage, wenn du schlagen mußt, tritt, wenn du treten mußt."

"Der leichte Weg ist auch der richtige Weg."

"Meine Bewegungen sind einfach, direkt und nicht-klassisch."

Bildquelle "Yin Yang": Wikipedia;
Zitatquelle: http://www.bruce-lee-jeet-kune-do.de/bruce-lee/zitate.html

Project Talisa

Eines vorweg: Project Jessica ist nicht tot! Es liegt vorerst nur auf Eis.


Project Talisa?
Hierbei handelt es sich um den Versuch, eine IDE für Flow Design orientierte Software zu erstellen.
Die Basis bzw. der gemeinsame Nenner wird die "Flow-Beschreibungssprache" von Ralf Westphal sein.

Eine konkrete Idee, wo die Reise hingehen wird, habe ich aber noch nicht direkt. Es wird sich entwickeln.
Aber was mir so vorschwebt, sind automatisch generierte Diagramme und Quellcode Dateien.
Importieren von Quellcode Dateien soll später auch mal möglich sein. Und natürlich auch das direkte Bearbeiten des Flows im Diagramm.
Eine art Simulationsmodus schwebt mir da auch noch vor. Eventuell sogar eine Flow Analyse oder so.

Am Ende will ich mit der IDE meinem Ziel näher kommen, Software zu modellieren. (Bitte nicht mit UML Modellierung verwechseln! Das ist zu sehr vorbelastet und man denkt dabei an "umständlich" und "kompliziert". Man sollte eher an das Modellieren von 3D Grafik Modellen denken. *g*)

Was ich bei dem Projekt anders machen will, als bei Jessica

Weniger faseln, sondern mehr coden! Ich schreibe zwar auch sehr gerne (zu gerne sogar), aber davon entsteht leider keine Software. Das ärgert mich zwar selber, aber ich muss da Prioritäten setzen.

Es gibt nix Perfektes! Der Tatsache muss ich einfach immer wieder ins Auge blicken! Ich will es nicht wahr haben, aber so ist es. Ich will immer alles perfekt machen, aber das lähmt ungemein. Die Gedanken kreisen ständig um Kleinigkeiten. Man kommt sich vor, als ob man versucht Ort und Impuls von Quantenteilchen gleichzeitig bestimmen zu wollen. Aber es funktioniert nicht.
In der Softwareentwicklung ist es das Selbe. Man kann zwar versuchen, ein Optimum zu erreichen, aber man wird immer irgendwelche Kompromisse eingehen (müssen), die einfach "hässlich" sind.
Und so werde ich mich auch nicht zu sehr damit belasten, eine Perfektion zu erreichen. Wie es wird, so wird es. Hauptsache, es gibt was Funktionierendes. Das bringt mich zum nächsten Punkt ...

Ship early and often! Mal sehen, ob ich das einhalten kann. (Hier spielen ja auch die Faktoren "Zeit" und "Motivation" eine Rolle.)
Man kann das aber auch so an vielen Open Source Projekten beobachten. Erfolgreich sind die Projekte, wo es schnell vorwärts geht. Auch diese Projekte sind oft weit weg von "Perfekt", aber man kann die Evolution erkennen. Da ist was in Bewegung und man weiß, dass man für das nächste Release nicht erst ein Jahr warten muss. Um das zu erreichen, muss man bereit sein, die Illusion der Perfektion hinter sich zu lassen.

Wird gefrickelt? Schon möglich. Das heißt, es gibt keinen direkten Plan, wie ich bei dem Projekt vorgehe. Es ist auch möglich, dass ich eventuell das Rad neu erfinde, weil ich eine gewisse Technologie noch nicht verstanden habe und es in meinen Augen einfach schneller geht, wenn ich es für meine Bedürfnisse selbst implementiere.

Kurzum: Ich will auch für mich persönlich schnell Features haben, die ich produktiv nutzen kann. Zudem sehe ich das Projekt als Experiment, wie eine neu IDE aussehen könnte und was für Möglichkeiten realisierbar sind.


Warum der Name "Talisa"?
Aus dem selben Grund, wie ich das andere Projekt "Jessica" genannt habe. Ein Name, wie z.B. Flow(er)IDE oder sowas, klingt irgendwie abgedroschen und hat man irgendwie schon mal gehört. Ein einfacher femininer Name passt. Wer will, kann ja bei der Google Bildersuche mal nach Talisa suchen. ^^


Bleibt eigentlich nur noch zu sagen, dass man das Projekt bei GitHub findet.
(Dank "GitHub for Windows" habe ich Git nun auch halbwegs im Griff. *g*)

Tja, dann guck mer mal. ;-)

Project Jessica - Datenverwaltung

Ein wesentlicher Aspekt der Software wird die Datenverwaltung sein.
Ich habe lange überlegt, ob ich eine fertige Datenbanklösung nehme oder etwas Eigenes entwerfe, was exakt auf meine Bedürfnisse zugeschnitten ist.
Mir wurde empfohlen, vielleicht besser eine bestehende dokumentenorientierte Datenbanklösung zu verwenden. MongoDB wirkte auf mich erstmal sehr attraktiv und ausgereift. Aber dieses Datenbanksystem bringt standardmäßig ca. 65 MB auf die Waage. Da stehen noch keine Nutzerdaten drin. Das ist der gewöhnliche Overhead.
Das ist mir ein bisschen schwergewichtig.
Ich hatte mich auch mal umgesehen, was es sonst noch so für NoSQL-Datenbanken gibt. Da gibt es ja enorm viele. Stichprobenartig habe ich mir auch mal die ein oder andere genauer angesehen. Da hat jede so ihre Vor- und Nachteile. Die eine ist kommerziell, die andere vom Background her zu kompliziert, zu schwergewichtig, hat keine offizielle .NET-API, oder, oder, oder.
Ich möchte damit nicht die Leistung der Datenbankentwickler schmälern, die da sehr viel Zeit und Know-How investiert haben. Ich brauche aber eher was Einfaches, speziell Zugeschnittenes, ohne generischen full fledged Datenbank-Wrapper.

Eine Kleinigkeit hatte ich nämlich vergessen zu erwähnen: Jessica soll keine umfangreiche Installation erfordern oder sich ins System einnisten, um zu funktionieren. Sie soll portabel sein.
Entpacken ... ausführen ... glücklich sein! ^_^

Alle relevanten Daten, die sie im Laufe ihres Lebens anlegen muss, landen in einem einfachen Unterverzeichnis direkt neben "ihr".
Das hat, wie ich finde, mehrere Vorteile:

• Man weiß, wo sich die Daten befinden. Oft ist es schwierig, bei anderer Bildverwaltungssoftware, den Ort der erzeugten Daten zu lokalisieren. (Vielleicht befinden sie sich im AppData-Verzeichnis oder doch woanders?!)
• Man kann leichter experimentieren. So benennt man nur den Datenordner um, startet die Software neu und sie verhält sich so, als würde sie zum allerersten mal gestartet. Danach könnte man diesen "Testordner" wieder löschen ... nennt den anderen Ordner wieder so wie vorher ... startet Jessica und alles ist so, als wäre nie etwas gewesen.
• Es sind ganz einfach vollständige Backups möglich. Das ergibt sich auch durch den zweiten Punkt.
• Bilder und Software zusammen mitnehmen. Zum Beispiel, wenn man auf einer externen Festplatte seine ganzen Bilder hat, könnte man dort auch die Jessica inklusive ihrer Daten drauf kopieren. Woanders könnte man dann die Bilder problemlos mit der voll eingerichteten Software betrachten, vorführen oder organisieren.

Solche Dinge, wie die Sache mit den Backups oder so, kann man auch direkt in die Software integrieren. Auf lange Sicht soll sie sehr DAU-freundlich sein.

Nun zur eigentlichen Datenverwaltung:

Ich versuche die Sache pragmatisch anzugehen. Ich möchte in erster Linie (Medien)-Dateien verwalten. Punkt.

Jede Datei besitzt ja von Haus aus einen Dateiname. Diese Datei kann auch noch in einem Ordner liegen. Zusätzlich gibt es zu jeder Datei mögliche Tags bzw. Schlagworte.

(Klar, diverse Medienformate haben noch viel mehr Metadaten zu bieten. Aber die interessieren mich am Anfang eher weniger, weil ich ja kein Profi-Fotograf bin. Wenn aber die Software soweit ist, dass sie z.B. nach Tags exakt filtern kann, werden auch noch andere Metadaten hinzukommen.)

Es gilt also erstmal strikte Komplexitätsreduktion und Fokus auf das Wesentliche:

• Dateinamen
• Dateinamenerweiterungen
• Ordnernamen
• Tags

Nach diesen Dingen soll am Anfang gesucht werden können. Das wäre dann so ähnlich, wie es bei Picasa der Fall ist.

Nun habe ich mich die letzten Tage (bzw. Wochen) immerzu mit diesem Aspekt gedanklich auseinandergesetzt. Ich habe recherchiert und bin dabei immer wieder auf B-Trees gestoßen. Diese Struktur scheint sich bei Datenbanken durchgesetzt zu haben. Eine Implementation für C# habe ich auch gefunden.

Es gibt aber noch eine Sache, die mich doch sehr beschäftigt:
Wie kann man effizient nach Dateien oder allgemein nach Stichworten suchen? Wie organisiert man sowas strukturell?
Das Einfachste wäre ja, man sortiert sie alphabetisch. Das Problem ist aber, dass man im seltensten Fall eine Datei alphabetisch sucht. Man sucht ja eine Datei viel öfter nach ihrem ungefähren Wortlaut. Gerade, weil man nicht mehr genau weiß, wie sie hieß.
Also kann man IMHO nicht einfach alphabetisch sortieren und danach indizieren. Man müsste jeden Buchstabe von einem Dateiname indizieren.
Um das anschaulicher zu machen, habe ich einige Grafiken angefertigt, mit denen ich ein Beispielszenario durchgehe.

Nehmen wir mal an, es gibt ein Bild, welches "Jessica" heißt. (Der Einfachheit halber verzichte ich hier auf Dateiendungen.)
Schematisch dargestellt, teilt sich der Name in folgende Buchstaben auf:

Jeden Buchstabe würde ich einzeln indizieren, sodass jeder Buchstabe auf die Datei verweist.
Hierzu müssen aber redundante Buchstaben entfernt und eine alphabetische Ordnung hergestellt werden. Wie ich mir das vorstelle, sieht man im nächsten Bild in der obersten Reihe:

Die oberste Reihe kann man sich wie eine Liste bzw. wie ein Dictionary vorstellen. In einem Suchfeld könnte ich einen der Buchstaben aus der obersten Reihe eingeben und bekäme als Suchergebnis mindestens auch die "Jessica"-Datei angeboten.
An jedem Buchstabe aus der obersten Reihe könnte wieder eine Liste oder eine Graph-Struktur hängen. In der Struktur sind dann wieder Buchstaben hinterlegt, welche auf die "Jessica"-Datei verweisen.
Die Pfeile geben eine valide Buchstabenfolge wieder, mit der man die "Jessica"-Datei finden kann.
Gebe ich also "ICA" in das Suchfeld ein, bekomme ich als logische Konsequenz die "Jessica"-Datei angezeigt, weil diese Buchstaben in der Reihenfolge im Dateiname vorkommen.
Würde ich aber "ICAB" eingeben, so bekäme ich die Datei nicht angezeigt, weil diese Buchstabenfolge nicht im Name vorkommt. Nach dem Knoten "A" kommt nix mehr. Beim Buchstabe "S" gibt es zwei mögliche Wege, bedingt durch das doppelte Auftreten dieses Buchstaben im Name.

Wie sieht das Ganze aus, wenn ein Dateiname hinzukommt? Um das ganze interessanter zu machen, habe ich einen Name gewählt, der sich mit "Jessica" überschneidet. Die andere Datei heißt "Jennifer".

Zur besseren Unterscheidung sind die Knoten von "Jennifer" blau.
Das folgende Bild zeigt die alphabetische Anordnung aller Knoten inklusive der Knoten von "Jessica":

Das Gebilde sieht schon interessanter aus. Buchstaben, welche beide Namen gemeinsam haben, habe ich anders eingefärbt, um sie besser hervorzuheben.
Nun ist der Graph schon bei zwei Namen so umfangreich geworden. Logisch! Gerade am Anfang würde er immer stark anwachsen, weil es sehr wahrscheinlich ist, dass es bestimmte Buchstaben- und Zeichenkombinationen noch nicht gibt. Das Wachstum wird sich aber abschwächen, je mehr Dateinamen es gibt. Pro Knoten wird es dann nur mehr Indexverweise geben. Das Auffinden einer beliebigen Datei sollte aber verhältnismäßig schnell gehen. In dem obigen Beispiel müsste man im schlechtesten Fall 3 Buchstaben eingeben, um eine Datei eindeutig zu finden. Im besten Fall reicht ein Buchstabe. Ein Knoten referenziert aber immer eine exakte Indexmenge. Das heißt, die Resultate könnten sofort abgerufen werden. Das würde sicher erstmal viel Redundanz verursachen. Aber vielleicht ließe sich da später noch was optimieren.
Eine Möglichkeit fiele mir schon ein. In dem obigen Beispiel bräuchte man nur 3 getrennte Index-Cluster und nicht für jeden Knoten einen eigenen.

Ich hätte zumindest keine Idee, wie man sonst effizient nach bestimmten Dateien anhand von Wortfragmenten suchen will.
Ich müsste das einfach mal in der Praxis ausprobieren und dann sehen, ob mir das überhaupt Vorteile bringt.
Vielleicht habe ich mich auch komplett in eine Sackgasse verrannt. Erst recht, weil ich schon zu lange über diese Problematik nachdenke und dadurch noch nix umgesetzt habe.

Vielleicht sollte ich mich mit diesem Aspekt der Datenverwaltung noch gar nicht heiß machen. Ob ich am Ende eine eigene Verwaltung implementiere oder doch ein bestehendes Datenbanksystem verwende, kann im Grunde noch offen bleiben. Die Architektur soll auf jeden Fall so aufgebaut sein, dass dieser Aspekt jederzeit ausgetauscht werden kann.

Strategisch günstiger wird es sein, wenn ich das Projekt von ganz oben beginne: beim User Interface.
Vor allem hätte man dadurch schon am Anfang sichtbare Fortschritte. Wenn dann erst mal das Gefühl für die Usability da ist, wächst der Rest so allmählich hinein.

Als nächstes werde ich also erstmal Mockups skizzieren, wie ich mir das GUI vorstelle. Dann habe ich auch ein Gerüst, wenn ich das in XAML kodiere. Ein Mockup ist schnell mal verworfen oder verändert.

Bis dann.

Project Jessica - Vorbereitung

Wie wird die Versionierung aussehen?
Ist das "Big Picture" nach meinem Empfinden erreicht, bekommt Jessica die Version 1.0.
Die Schritte dahin werden in Iterationen zerlegt. Und Iterationen werden in Slices zerlegt.

Angenommen, es gibt die Version 0.3.2, dann heißt das, es ist die 3. Iteration mit dem 2. Slice auf den Weg zum "Big Picture".

Definition "Iteration"
Eine Iteration beinhaltet eine Funktionalität, mit der man schon etwas Sinnvolles anfangen kann. "Sinnvoll" ist natürlich relativ. Im Falle von Jessica ist der erste Schritt insofern sinnvoll, weil ich ein oder mehrere Ordner importieren kann und mir ALLE gefundenen Bilder angezeigt werden können, bzw ich durchscrollen kann.

Definition "Slice"
Ein Slice ist ein kleines Häppchen auf den Weg zur ersten sinnvollen Funktionalität. Nur für sich genommen ist ein Slice nicht sinnvoll. Um beim obigen Beispiel zu bleiben, ist es nicht sinnig, wenn ich einen Ordner importieren könnte, aber es würde nix angezeigt werden.
Aber der Slice ist wichtig, um die Komplexität aus Entwicklersicht zu reduzieren und um die Motivation zu erhalten.


Wie viele Iterationen oder Slices es geben wird, steht noch nicht fest. Das hängt von der Komplexität des angestrebten Features ab.

Das Repository
Vorgestern habe ich das Git-Repository bei GitHub eingerichtet.
Man findet es dort: https://github.com/SachsenCoder/Jessica

Mit der Schritt-für-Schritt-Anleitung von GitHub war das Einrichten sehr einfach. Ich hatte nur lokal ein kleines Problem mit der "Git Bash", weil die Konsole kein UTF-8 darstellen wollte. (Mein Nachname hat ja das "ö" an zweiter Stelle.)
Naja, ich habe mich dann für die Git Extensions entschieden. Das Tool nutzte ich auch sonst ganz gerne für meine lokalen Repositories. Damit war das UTF-8 Problem auch gelöst. ^^

Wie geht es weiter?
Gestern hatte ich die echte Jessica vektorisiert: http://fav.me/d4n56c4
(Sowas brauchte ich auch mal wieder. Das hat was Entspannendes.)

Als nächstes werde ich erstmal ein paar Spikes entwerfen. Das betrifft einmal das GUI und die "Datenbank".
Datenbank deshalb in Anführungsstrichen, weil ich erstmal selber eine Idee testen will. Eine richtige universelle Datenbank wird das nicht und ist auch gar nicht beabsichtigt.
Wie ich mir das vorstelle, wird in einem weiteren Beitrag beschrieben.
Die Spikes werde ich auch in das Repository packen. Die gehören immerhin zur Entwicklung dazu. ;-)

Bis dann! :-)

Project Jessica - Vorstellung

Ich muss mich jetzt quasi outen, da es sonst für Außenstehende keinen Sinn ergeben würde, weshalb gerade ich eine solche Software brauchen sollte.

Ich besitze ca. 269 Tausend Mediendateien (Videoclips und Bilder zusammen) verteilt auf etwa 3.713 Ordnern mit fast 310 GB, kann mich nur schwer von einem Bild trennen, aber fotografiere selber so gut wie gar nicht.

Die große Preisfrage:
Wie komme ich zu so einer menge Material? Wer oder was bin ich? ;-)

Ich glaube, ich bin ein Bildermessie oder sowas. Ich denke manchmal, dass das echt schon krankhaft ist.
So habe ich z.B. einen Ordner, wo nur Bilder von deviantArt drin sind ... ca. 16 Tausend Bilder, rund 21,9 GB überwiegend High-Quality. Alles manuell runtergeladen. (Gott, wenn ich mir das mal auf der Zunge zergehen lasse. Die Tabs vom Google Chrome Browser haben da schon des öfteren den Geist aufgegeben, weil zu viele HQ Bilder gleichzeitig geöffnet waren. Und die Flash-Instanzen schlugen auch noch zu Buche. Ich glaube, der Chrome Browser selber ist da auch schon mal komplett abgeschmiert. *g*)
Oder meine Sammlung weiblicher Promis: 21.343 Dateien verteilt auf 448 Ordner (ca. 10,8 GB).

Da bin ich natürlich scharf auf gute Bildverwaltungsprogramme, denn es werden sicher nicht weniger Bilder. Eher noch mehr.
So manches Tool kam mit der Menge gar nicht zurecht, weil das nur auf wenige Bilder ausgelegt war. (So in der Größenordnung von wenigen Hundert bis Tausend oder so. Also, was der Otto Normaluser so mit seiner Digicam produziert.)
Andere Tools brechen zusammen, wenn man mal um die 30 Tausend Bilder als Slideshow in zufälliger Reihenfolge abspielen lassen will. -.-
Oder beim Photoshop Elements Organizer: Das Tool machte Anfangs wirklich einen guten Eindruck. Mal um die Tausend Bilder in einen Katalog eingelesen. Ging ganz gut. Vor allem die Filtermöglichkeiten und die Smartalben hatten mich erstaunt. Sowas wollte ich schon immer mal haben. Also hatte ich es gewagt: Er sollte meinen ganzen Bestand einlesen. "ACH DU SCHANDE! Was ist denn jetzt los?" sagte ich so zu mir. Da hat der mir echt einen modalen Progressdialog angedreht, wo es nur die Möglichkeit zum Abbrechen gab. Naja, muss es eben so sein. Ich glaube, der war fast den halben bis dreiviertel Tag damit beschäftigt, die Medien einzulesen. Wäre ja alles nicht so schlimm gewesen, wenn er das im Hintergrund gemacht hätte. Als er denn dann endlich fertig war, hat er mir erstmal gesagt, was er alles nicht einlesen konnte. Das präsentierte er mir in einem winzigen Dialog in einer noch winzigeren Listbox, wo ich mir dann die fehlgeschlagenen Dateien ansehen konnte. Gut, vielleicht waren da wirklich ein paar Beschädigte dabei. Oder es handelte sich zum Teil auch um Zip-/Rar-Archive. Soviel ich noch weiß, hat er mal aufgrund der fehlerhaften Dateien den Vorgang mittendrin abgebrochen. Da hatte ich dann letztlich immer nur eine Hand voll Ordner gleichzeitig eingelesen. Das hat er einigermaßen verkraftet. Aber selbst der restliche Umgang mit der Datenmenge hat keinen Spaß gemacht. Immer wieder wurde man vom GUI abgehalten, etwas zu tun, weil es blockierte. Das war eine sehr grausige Software (für meine Bedürfnisse).
Tja, meine bisherigen Favoriten sind Picasa und die Windows Live Fotogalerie. Die kommen spielend mit großen Datenmengen klar. Aber denen mangelt es massiv an komfortablen Verwaltungsfunktionen, wie ich sie gerne hätte.

Nun wollte ich eigentlich warten, bis diese Tools irgendwann mal Smartalben oder mächtige Filtermöglichkeiten haben. Aber da kann ich vielleicht noch lange warten. Entweder wollen das wirklich nicht viele Leute, oder sie wissen gar nicht, was Smartalben sind.

Nein, jetzt reicht's! Ich brauche die Features sehr bald. Ich will endlich mal Ordnung in meine Bild- und Videoclip-Bestände bringen!
Also gibt es nur eine Lösung: Selber machen!
Jene Software wird auf den Name Jessica hören!

Jessica - Die Bildverwaltungssoftware für anspruchsvolle Sammler

Wird meine Software am Ende
auch mal so attraktiv sein,
wie die echte Jessica?

Warum gerade der Name "Jessica"?
Wenn ich den Name höre, muss ich unweigerlich an Jessica Alba denken. ^_^
Und das wird mir immer vor Augen halten, dass meine Software "Jessica" auch sexy und menschlich werden soll! Mit "menschlich" meine ich hier speziell die Mensch-Maschine-Interaktion. Software und Hardware sollten sich doch dem Menschen anpassen und nicht umgekehrt. Aber das werde ich im weiteren Verlauf noch genauer erläutern, was mir da so vorschwebt.
Generell werde ich versuchen, neue Pfade zu beschreiten. Ob mir das gelingen wird, weiß ich nicht. Aber die Vision ist an der Stelle wichtig und dass man darauf hin arbeitet. Warum sollte man sich mit weniger zufrieden geben? Was Microsoft, Apple, Google & Co. entwickeln, ist doch nicht das Ende der Fahnenstange an Möglichkeiten.

The Big Picture
OK, nun das "Big Picture". Ich glaube, das kann man wörtlich nehmen, bei dem, was die Jessica am Ende alles können soll:

"100 Bilder? 100.000 Bilder? 1.000.000 Bilder oder noch mehr? ... Die Menge spielt für mich keine Rolle!"
Es liegt auf der Hand, dass Jessica spielend mit beliebig vielen Bildern umgehen können soll. Das ist soweit nix Besonderes, denke ich. Ich denke mir, Picasa und die Windows Live Fotogalerie können das auch.

"Was? Du suchst altmodische, statische Alben? Bei mir sind die Alben intelligent, dynamisch und beliebig kombinierbar!"
Hier wird es schon interessanter. Das soll nämlich so ein Killer-Feature werden.
Es wird nach wie vor möglich sein, ein statisches Album anzulegen, wenn man denn unbedingt möchte. Aber bei der Jessica sollen solche Alben intern nur Smartalben mit einer fixen Bildermenge sein. Da wird es aus struktureller Sicht keinen Unterschied geben.
Aber die Stärken sollen sich erst offenbaren, wenn man die Bilder detailliert mit Tags beschrieben hat. Heutige Tools ermöglichen zwar auch, seine Bilder ausführlich zu taggen ... ja, man sagt sogar, je ausführlicher ein Bild getagged ist, desto besser findet man es wieder. Das hatte ich auch immer gedacht. Daher hatte ich damals auch begonnen, meine Bilder sehr ausführlich zu taggen.
Dann wollte ich natürlich mit den Filtermöglichkeiten spielen: Zeige mir die Bilder, welche Tag "X" haben, aber nicht Tag "Y" ... zusätzlich können hier noch Bilder reinfallen, welche Tag "M" haben, aber auf keinen Fall dürfen Bilder angezeigt werden, welche Tag "P" haben.
Bei sowas stößt man bei der gängigen Software schnell an seine Grenzen und ist dann sehr enttäuscht. Da nützen ja die ganzen detaillierten Tags nix, wenn ich nicht exakt das rausfiltern kann, was ich will.

Die Smartalben sollen aber noch mehr können: Man soll vorher Filterregeln für die Smartalben festlegen können. (Soweit nix Besonderes.) Also z.B.: Enthält Tag "X", aber nicht Tag "Y". Dann soll es möglich sein, ein beliebiges Bild in dieses Album zu ziehen, woraufhin die Tags von dem Bild so angepasst werden, dass sie logisch in dieses Smartalbum passen. Das soll aber nur optional geschehen. Denn es kann ja auch die Möglichkeit geben, dass dieses Bild zur fixen Menge hinzugefügt werden soll. Vielleicht löse ich das so, dass da bei dem Smartalbum dann diese zwei Möglichkeiten aufblubbern, wenn man die Bilder darauf zieht.

"Mit mir wirst du keine Tagging-Probleme mehr haben!"
Neben normalen Tags soll es auch hierarchische Tags geben. Diese soll man so handhaben können, als würde man mit richtigen Ordnern arbeiten. Man soll somit Tags verschieben, kopieren und umbenennen können. Alles soll sich unmittelbar auf die Dateien übertragen, welche die betroffenen Tags besitzen.
Es soll auch möglich sein, bestehende Tags, die hierarchisch angeordnet sind, importieren zu können. Dabei soll das Trennzeichen keine Rolle spielen. Für hierarchische Tags nimmt ja heutzutage jede Software ein anderes Format. Die einen verwenden den Slash, die anderen den Backslash, wieder andere einen Bindestrich, etc.
Jessica soll mit jedem denkbaren Format umgehen können. Ebenso soll es möglich sein, in jedes beliebige Tag-Format zu exportieren. Denn, wenn ich einmal ein Bild getagged habe, möchte ich das nie wieder taggen müssen, nur weil eine andere Software mit dem Format nicht klar kommt.
Bei Bildern, wo man die Tags nicht direkt einbetten kann, werden sie extern abgelegt und verwaltet.

"Im Vollbildmodus und bei den Slideshows bekommst du das zu sehen, was du wirklich willst und wie lange!"
Es ist ja wirklich deprimierend. Es gibt so viele Bilder, welche selbst die Full-HD Auflösung locker übersteigen. Sieht man sie sich dann im Vollbildmodus an, hat man trotzdem nur zwei Möglichkeiten: Entweder so im Ganzen zu betrachten, oder rein zu zoomen und dann wie ein irrer hin und her zu scrollen, um den ein oder anderen Bereich in seiner vollen Detailtiefe zu sehen. Und beim nächsten mal geht das gleiche Spiel von vorne los.
Warum kann man die relevanten Bereiche des Bildes nicht markieren und speichern? Und wenn man beim nächsten mal wieder das Bild ansieht, kann man durch einfache Maus- oder Tastatureingaben die Bereiche sofort anspringen. Oder man baut sich so etwas wie eine Collage aus den verschiedenen Ansichten und kann diese ebenso einfach abrufen. Das alles wird nur als Projektionsinformation gespeichert und nicht als neues Bild.
Dann die Slideshows: Ich frage mich, warum die manchmal so wenige Optionen haben. Bei manchen Programmen gibt es eine Shuffle-Funktion, aber keine "Endlos"-Funktion. Oder umgekehrt. Bei Jessica soll es mindestens Beides geben. Und warum kann man das Intervall nicht für jedes Bild individuell setzen?
Mir schwebt da so eine art "Aufnahme"-Funktion vor. Während ich die Bilder manuell betrachte, soll einfach alles Mögliche aufgezeichnet werden. Verweildauer auf einem Bild ... Pan und Zoom, etc. Danach soll man auch noch die Möglichkeit haben, die "Aufnahme" zu bearbeiten, um uninteressante Stellen zu entfernen oder zu modifizieren. Und hinterher kann das dann als Slideshow wiedergegeben werden. Bei dem Ganzen werden immer nur Parameter gespeichert und keine richtigen Filme aufgenommen! Das ist mir wichtig, um keinen unnötigen Platz zu verschwenden.

"Du musst nicht warten, bis ich mit einer Aufgabe fertig bin, um weiter arbeiten zu können!"
Das verstehe ich unter Performance einer Software!
Einen Algorithmus empfindet man doch nur dann als zu langsam, wenn man nicht eher weiter arbeiten kann, bis er durchgelaufen ist. Bei Jessica sollen bei langwierigen Operationen Previews und Platzhalter existieren, mit denen man aktiv weiter arbeiten kann, als wäre der Prozess schon abgeschlossen. Man stelle sich langwierige Kopieroperationen oder Dateimodifikationen vor. Sowas dauert eben lange. Aber es steht ja vorher fest, wie das Resultat aussehen soll. Nur die Durchführung dauert seine Zeit.
Was sicher auch langwierig sein kann, ist die Durchführung der Smartalben.
Wird die Software während eines langwierigen Prozesses geschlossen, wird beim nächsten Start fortgesetzt. So, wie das Picasa auch bei der Gesichtserkennung macht.

"Ich kann auch Dinge rückgängig machen!"
Es soll so etwas wie eine Undo-Funktion geben. Z.B., wenn man Bilder versehentlich ins falsche Album gezogen hat, soll man das wieder rückgängig machen können.

"Ich hinterlasse einen menschlichen Eindruck!"
Das Ziel soll es sein, sich dem Benutzer menschlich mitzuteilen. Das soll erreicht werden, indem weitgehend technische Begriffe vermieden werden. Sämtliche Mitteilungen sollen leger und ungezwungen wirken.

"Und noch einige Kleinigkeiten ..."
Videos sollen ebenso wie Bilder zu verwalten sein. Bei gif-Bildern sollte man die Animation abspielen können. (Auch keine Selbstverständlichkeit bei den ganze Programmen, die es da so gibt.)

Herausforderungen und mögliche Schwierigkeiten
Wie schon erwähnt, handelt es sich bei dem "Big Picture" nur um eine sehr grobe Vorstellung von der endgültigen Software. Die meisten Dinge werden sich inkrementell entwickeln. Wenn dann so das typische Empfinden kommt, wie "Cool wäre es, wenn [...] möglich wäre.", dann werde ich überlegen, dies einzubauen.
Eine Herausforderung werden sicher die ganzen grafischen Spielereien und insgesamt das User Interface werden. Aber ich vertraue hier mal voll und ganz auf die Möglichkeiten der WPF:

Das Longterm-Goal wird sein, dass ich beim User-Interface keinerlei Logik-Code in der Codebehind-Datei habe. Es soll ja am Ende alles strikt nach MVVM ausgerichtet sein.

Schwierigkeiten könnte ich mir bei den Smartalben vorstellen und bei der ganzen Tagging-Problematik.
Ich werde womöglich auch keine typische Datenbank als Backend verwenden, da ich hier starke Performance-Probleme durch die Abfragen erwarte. (Es käme für mich, wenn überhaupt eine konventionelle Datenbank verwendet werden würde, nur SQLite in Frage, da man hier nix vorher installieren muss.)
Nein, ich werde mir selber ein System ausdenken, was für die Anforderungen genau zugeschnitten ist.

Der erste Schritt
... fängt erstmal klein an, um überhaupt eine Basis zu schaffen.
Am Anfang soll es möglich sein, einen (oder mehrere) Ordner mit Bildern zu wählen, welcher beim nächsten Programmstart automatisch geladen wird. Die erfassten Bilder sollen auch schon mal in einer Liste dargestellt werden. (Thumbnails werden zunächst noch nicht gespeichert. Die Bilder werden erstmal direkt geladen.)
Bei dem Schritt versuche ich auch schon ein bisschen das UI so halbwegs zu designen. (Von den Farben her und eventuell auch die Schriftart und Größe. Geplant ist auch ein sehr dezentes Hintergrundbild: http://fav.me/d2e1eo8. Dieses würde ich mit Inkscape "abpausen", um schärfere Konturen zu haben. Mit der Erlaubnis des Urhebers würde ich das dann in meine Software einbauen. ;-))

Probleme sehe ich hier eventuell bei dem Darstellen der Bilder. Ich habe da noch keine Vorstellung, wie die WPF mit sehr vielen Bildern intern umgeht. Unter Windows Forms hätte ich jedes Bild einfach manuell ausgelesen, direkt auf eine Oberfläche gezeichnet und das Bild dann wieder freigegeben.
Hier wird sich sowieso die Frage stellen, ob ich mein eigenes Steuerelement erzeuge, oder ein UserControl in Verbindung mit dem Image-Element besser ist.

Nun ja, das muss ich dann mal sehen.

Als nächstes käme dann die Vorbereitung des Projekts ...