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! :-)
Sonntag, 22. Januar 2012
Donnerstag, 19. Januar 2012
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
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 ...
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? |
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 ...
Dienstag, 17. Januar 2012
Die Aufwärmphase vor der Projektvorstellung
Eigentlich hatte ich zwar im letzten Beitrag versprochen, dass ich als nächstes das erste Projekt vorstellen werde. Aber ich wollte erstmal noch meine Vorgehensweise bei allen kommenden Projekten erklären.
Mir kommt es ja auf Konsistenz an, die ich bei allen Projekten anstrebe.
Die Vorstellung der Projekte
Jedes Projekt wird nach folgendem Schema vorgestellt werden:
- The Big Picture
Unter dieser Überschrift werde ich meine Vorstellung von der zu entwickelnden Software präsentieren. Was soll sie am Ende mindestens können? Was sind meine persönlichen "must-have"-Features? Es wird eben ein grober Überblick gegeben, um Appetit zu wecken. ;-) - Herausforderungen und mögliche Schwierigkeiten
Jedes Projekt wird das ein oder andere Feature enthalten, was ich so noch nie zuvor implementiert habe. Das könnte also Schwierigkeiten machen oder eben sehr knifflig sein. Diese möglichen Stolpersteine werde ich hier aufzählen. - Der erste Schritt
Jedes Projekt fängt erstmal klein an. Daher definiere ich unter diesem Punkt die Features der ersten Iteration.
Gemeinsamkeiten aller Projekte
- Sie tragen einen weiblichen Name. (Die Erklärung, weshalb das so ist, habe ich ja schon im letzten Beitrag geschrieben.)
- Die Root-Bezeichnung meiner Namespaces wird entweder die Initialen CGO oder SachsenCoder tragen.
Ich tendiere aber zu SachsenCoder. Das erscheint mir weltweit eindeutiger zu sein. - Die Projekte werde ich bei github veröffentlichen. (Hoffentlich klappt das auch alles so. Ich habe bisher nur lokale Git-Repositories verwendet. *g*)
Innerhalb der github-Umgebung werde ich primär alle Texte auf Englisch verfassen. Das macht sich besser, falls doch mal jemand an dem Projekt mitmachen will. So ist es dann wenigstens international verständlich. (Auch, wenn mein Englisch sicher nicht ganz so erstklassig ist. *g*) - Alle Projekte werden als Basis .NET-Framework 4.0 verwenden.
- Die Sprache selber wird C# sein. (Das ist die einzige Sprache, dessen Syntax mir wirklich gut gefällt!)
- Alle Projekte werden im AppKata-Stil aufgezogen und nach der Spinning-Strategie angegangen. Das heißt, es gibt viele überschaubare Iterationen auf den Weg zum Big Picture und darüber hinaus. Jede Iteration soll einen kleinen, aber echten Nutzen hervorbringen. Jede Iteration wird je nach Komplexität in unterschiedlich kleine Slices aufgeteilt, damit ich/man von den Anforderungen nicht gleich erschlagen wird und ein Problem zeitnah gelöst werden kann.
Ich halte dieses Vorgehen für unerlässlich, um die Motivation aufrecht zu halten. - Spätestens nach jeder Iteration (oder dem ein oder anderen Slice) werde ich öffentlich darüber reflektieren, wie es gelaufen ist. Stellten sich die voraussichtlichen Schwierigkeiten wirklich als Hürde heraus? Wenn ja, warum? Wenn nein, warum nicht? Ist die Motivation noch gegeben oder steuere ich auf eine Lustlosigkeit zu? Bin ich mit der entwickelten Lösung zu Frieden? Entspricht sie den gegebenen Anforderungen? Gibt es Möglichkeiten der Verbesserung? Kann ich diese Verbesserungen umsetzen oder komme ich da an eine Know-How-Barriere?
Diese Art der Reflektion soll mir dabei helfen, die Sachen, die ich da entwickelt habe, nochmal bewusst zu machen. Es soll auch verhindern, dass ich in eine "Frickel"-Ebene abdrifte. - Die Entwicklung wird weitgehend gebloggt werden. Das heißt, die Lösungsfindung mache ich quasi öffentlich. So, als wenn ich laut denke oder jemanden meinen Lösungsweg erkläre. (Sicher werden mir dabei auch selber eventuelle Denkfehler auffallen.) Zudem gibt es anderen die Möglichkeit, die Entwicklung von Anfang an nachzuvollziehen. (Kann ja sein, dass am Ende wirklich geile Tools dabei rauskommen. Dann ist es doch fantastisch, wenn gerade sowas verständlich dokumentiert ist. Das ist ja im Open-Source-Bereich nicht selbstverständlich.)
Unter'm Strich soll die Entwicklung einen professionellen Charakter bekommen.
Montag, 16. Januar 2012
Endlich mal was auf die Beine stellen!
Mit der Überschrift möchte ich mir selbst einen mentalen Arschtritt verpassen. Es ist ja nun schon fast ein Jahr her, als ich meinen letzten Blog-Post veröffentlicht habe. Und so kann ich nicht gleich mit der Tür ins Haus fallen, sondern muss erstmal den Leser auf das Kommende einstimmen.
Eigentlich habe ich noch viele Blog-Post-Entwürfe rumliegen, die alle davon handeln sollten, dass die Event-Based-Components doch nicht so prickelnd sind, wie man sie sich vorstellt.
Die Ironie daran ist eigentlich die, dass mir kaum ein ernsthafter Kritikpunkt einfallen wollte. Die einzige ernsthafte Kritik, die mir eingefallen ist, ist die schlechtere Code-Navigierbarkeit innerhalb von Visual Studio. (Z.B. beim Debuggen. "Gehe zu Definition" wird da nicht so schön funktionieren.)
Auch sollte man bei den EBC stehts eine visuelle Abbildung synchron zum Code mitführen. Da ist eben etwas Disziplin gefragt.
Und das war es eigentlich auch schon. Alles andere sind eher gravierende Vorteile gegenüber den herkömmlichen Praktiken, die so in aller Munde sind. (Wenn man ehrlich zu sich selber ist, merkt man das auch.)
Ich stellte das bei meiner "Micro-Pattern-Trilogie" auch fest. Man konnte alles schön voneinander getrennt halten. Aber sie waren zu schwergewichtig und brachten zu viel Rauschen mit. Damit war das Ding für mich gestorben.
Nun hat sich in der Zeit aber sehr viel getan. Die EBC sind sehr schlank, flexibel und aussagekräftiger geworden. EBC sind nun viel mehr ein Implementationsdetail. Der eigentliche Überbegriff für das Ganze heißt nun ganz einfach "Flow-Design". Es ist einfach ein Paradigma, wie man ein Business-Problem ganz einfach angehen kann. Wie das am Ende in der Programmiersprache XYZ umgesetzt wird, spielt keine Rolle. Die Art, wie es am schönsten in C# umgesetzt werden kann, ist eben das, was sich EBC nennt. (Wobei das eigentlich keinen extra Name bräuchte. Zumal ja die heutigen EBC kaum noch was mit der Ursprungsdefinition zu tun haben.)
Hierfür möchte ich noch zwei hervorragende Videos zu der neuen und erfrischenden Art der "Flow-Based"-Entwicklung vorstellen.
Das erste Video hatte ich damals live mitverfolgt. Das fand ich besonders motivierend, weil die alte EBC-Denke dort quasi gar nicht mehr auftaucht. Das zeigt sich besonders darin, dass es in der normalen Form keine Substantive mehr gibt. Es gibt also keine "Täter" mehr, wie z.B. einen "UserRegistrator" oder ähnliche abenteuerliche Gebilde, wo man letztlich nicht weiß, was er alles tut.
Stattdessen gibt es "Tätigkeiten", also echte "Funktionseinheiten". Eine Funktionseinheit könnte z.B. "Register_User" heißen. So benennt man dann z.B. auch die Klasse. Das ist das, was mir an dem neuen Konzept am Besten gefällt! Benennt man eine Klasse nach ihrer Funktion in der Verbform, ist definitiv klar, was sie tut. Im besten Fall tut sie nur diese eine Sache! Bei einem "UserRegistrator" weiß man leider nicht genau, was er alles tut. Da steckt die Funktionalität in einzelnen Methoden, welche eventuell weitreichende Abhängigkeiten haben, die gar nix mehr mit dem eigentlichen Kontext zu tun haben. Und das verleitet dazu, dass man Verantwortlichkeiten mischt.
Das zweite Video zeigt quasi an einem praktischen Anwendungsfall, wie der Entwicklungsprozess mit "Flow-Design" aussieht. Hier kommt auch gut zur Geltung, dass ein "Flow-Design" wunderbar evolviert.
Soviel erstmal zu der kleinen Einführung.
Um zum Ausgangspunkt zurückzukommen: Ich muss (und will) endlich mal ein privates Projekt auf die Beine stellen! Unter Zuhilfenahme von "Flow-Design".
Projektideen habe ich da mehr als genug:
Eigentlich habe ich noch viele Blog-Post-Entwürfe rumliegen, die alle davon handeln sollten, dass die Event-Based-Components doch nicht so prickelnd sind, wie man sie sich vorstellt.
Die Ironie daran ist eigentlich die, dass mir kaum ein ernsthafter Kritikpunkt einfallen wollte. Die einzige ernsthafte Kritik, die mir eingefallen ist, ist die schlechtere Code-Navigierbarkeit innerhalb von Visual Studio. (Z.B. beim Debuggen. "Gehe zu Definition" wird da nicht so schön funktionieren.)
Auch sollte man bei den EBC stehts eine visuelle Abbildung synchron zum Code mitführen. Da ist eben etwas Disziplin gefragt.
Und das war es eigentlich auch schon. Alles andere sind eher gravierende Vorteile gegenüber den herkömmlichen Praktiken, die so in aller Munde sind. (Wenn man ehrlich zu sich selber ist, merkt man das auch.)
Ich stellte das bei meiner "Micro-Pattern-Trilogie" auch fest. Man konnte alles schön voneinander getrennt halten. Aber sie waren zu schwergewichtig und brachten zu viel Rauschen mit. Damit war das Ding für mich gestorben.
Nun hat sich in der Zeit aber sehr viel getan. Die EBC sind sehr schlank, flexibel und aussagekräftiger geworden. EBC sind nun viel mehr ein Implementationsdetail. Der eigentliche Überbegriff für das Ganze heißt nun ganz einfach "Flow-Design". Es ist einfach ein Paradigma, wie man ein Business-Problem ganz einfach angehen kann. Wie das am Ende in der Programmiersprache XYZ umgesetzt wird, spielt keine Rolle. Die Art, wie es am schönsten in C# umgesetzt werden kann, ist eben das, was sich EBC nennt. (Wobei das eigentlich keinen extra Name bräuchte. Zumal ja die heutigen EBC kaum noch was mit der Ursprungsdefinition zu tun haben.)
Hierfür möchte ich noch zwei hervorragende Videos zu der neuen und erfrischenden Art der "Flow-Based"-Entwicklung vorstellen.
Das erste Video hatte ich damals live mitverfolgt. Das fand ich besonders motivierend, weil die alte EBC-Denke dort quasi gar nicht mehr auftaucht. Das zeigt sich besonders darin, dass es in der normalen Form keine Substantive mehr gibt. Es gibt also keine "Täter" mehr, wie z.B. einen "UserRegistrator" oder ähnliche abenteuerliche Gebilde, wo man letztlich nicht weiß, was er alles tut.
Stattdessen gibt es "Tätigkeiten", also echte "Funktionseinheiten". Eine Funktionseinheit könnte z.B. "Register_User" heißen. So benennt man dann z.B. auch die Klasse. Das ist das, was mir an dem neuen Konzept am Besten gefällt! Benennt man eine Klasse nach ihrer Funktion in der Verbform, ist definitiv klar, was sie tut. Im besten Fall tut sie nur diese eine Sache! Bei einem "UserRegistrator" weiß man leider nicht genau, was er alles tut. Da steckt die Funktionalität in einzelnen Methoden, welche eventuell weitreichende Abhängigkeiten haben, die gar nix mehr mit dem eigentlichen Kontext zu tun haben. Und das verleitet dazu, dass man Verantwortlichkeiten mischt.
Das zweite Video zeigt quasi an einem praktischen Anwendungsfall, wie der Entwicklungsprozess mit "Flow-Design" aussieht. Hier kommt auch gut zur Geltung, dass ein "Flow-Design" wunderbar evolviert.
Soviel erstmal zu der kleinen Einführung.
Um zum Ausgangspunkt zurückzukommen: Ich muss (und will) endlich mal ein privates Projekt auf die Beine stellen! Unter Zuhilfenahme von "Flow-Design".
Projektideen habe ich da mehr als genug:
- Ein Bildverwaltungsprogramm
Das soll so in die Richtung wie Picasa oder die Windows Live Fotogalerie gehen. Aber mein Programm soll flexiblere und besser anpassbare Slideshows ermöglichen. Auch soll es mit sehr vielen Dateien mühelos umgehen können. (Das ist nicht immer selbstverständlich bei den Lösungen, die es da so gibt.) Aber das eigentliche Killerfeature sollen ja Smartalben sein! Die vermisse ich nach wie vor in Picasa und bei der Windows Live Fotogalerie. (Der Photoshop Elements Organizer bietet zwar Smartalben an, aber die kann man nicht schachteln.) Generell sollen alle erdenklichen Filtermöglichkeiten möglich sein ... beliebig komplex. Was die Software in erster Linie nicht bieten soll, sind diverse Social-Features und Bildbearbeitungsfunktionen. Gesichtserkennung ist auch erstmal nicht geplant. (Das sind aber Sachen, die per Flow-Design leicht nachrüstbar sein sollten.) Die Verwaltungsaspekte sollen hier im Vordergrund stehen. - Einen Editor und Player für interaktive Stories
Sowas finde ich einfach "nice to have". ;-)
Ich stelle mir das so vor, dass man einfach beginnt, eine Geschichte zu schreiben. Und während dieses Vorgangs kann man dann intuitiv die dynamischen Aspekte der Storie festlegen. (Charaktere, Handlung, Interaktion, etc.) Man soll nicht schon vorher wissen müssen, was man alles braucht oder was dynamisch werden soll, wenn man eine solche Geschichte beginnt. Ein Tool, was so in die Richtung geht, aber in meinen Augen noch nicht so richtig den Punkt getroffen hat, ist z.B. Twine. Das fühlt sich noch zu sehr nach Scripting an. Und übersichtlich ist das bei komplexeren Stories auch nicht gerade. Oder wenn noch Variablen ins Spiel kommen. Oder wenn man seine Charaktere im Blick behalten will, etc. - Ein Tool für einfachere Softwareentwicklung
Davon träumt sicher jeder Softwareentwickler! ;-D
Ehe ich da viel dazu erzähle ... ich denke da an eine Mischung aus Code Bubbles und FlowStone. Quasi ein Softwaremodellierungstool. - Eine Wuala-Alternative
Denn Wuala unterstützt ja keinen Speichertausch mehr. :-( - Ein Automatisierungstool
Ja, sowas Ähnliches wie FinalBuilder. Nur nicht so Feature-Complete und universell wie dieses Tool derzeit zu sein scheint. Einfach ein Tooling, was meine kleinen Automatisierungsanforderungen komfortabel erfüllt. (Ein bisschen Templating, d.h. Platzhalter durch echte Werte ersetzen; Dateiverwaltungskram; Commandline-Tools ausführen; etc.) Das Tool könnte "nebenbei" entstehen. Je nachdem, welche Automatisierung ich gerade gebrauchen könnte.
Tja, an Ideen mangelt es nicht. Ich will aber realistisch sein: Das Softwareentwicklungstool und die Wuala-Alternative wird es voraussichtlich nicht (sofort?) geben. Das entwickelt man auch mit Flow-Design nicht mal eben so in der knappen Freizeit.
Bei den anderen Programmen sehe ich da aber schon realistische Ziele.
Was alle Programme (hoffentlich) gemeinsam haben werden, ist Folgendes:
- Ein modernes, einfach zu handhabendes (G)UI. Heutzutage muss man wirklich keine hässlichen GUIs mehr hinnehmen oder einem User anbieten. Die Tools für Mac OS sehen immer so stylisch aus. Warum sollte das nur Mac OS exklusiv sein?
- Jedes Tool versuche ich penibel im Flow-Design-Stil zu entwickeln. Also erst der grafische Entwurf und dann der Code. (Das wird für mich eine disziplinarische Herausforderung werden, weil ich sonst alles gleich im Code entworfen habe.) Als Tool für die Diagramme werde ich hier yEd verwenden.
- Sie werden frei wie "Freibier" und sicher auch frei wie "frei veränderbar" sein. ;-)
Ich verfolge kein finanzielles Interesse. Die Tools entwerfe ich, weil ich sie sehnlichst brauche. Ich will nicht länger warten, bis sie mal irgendjemand irgendwann programmiert. Und warum sollte ich die Tools am Ende nicht anderen zur Verfügung stellen?
Was erwarte ich von dem Vorhaben?
- In erster Linie, wie bereits erwähnt, brauche ich die Tools, weil mir die existierenden Lösungen nicht das bieten, was ich wirklich brauche. (Oder weil andere Lösungen zu komplex und/oder zu teuer sind.)
- Ich will meine Fähigkeiten als Entwickler ausbauen, sodass mir die Flow-Design-Methodik in Fleisch und Blut übergeht. Ich möchte nicht mehr in die alte OOP-Denke verfallen.
- Kann es für den Arbeitsmarkt bessere Referenzen geben, als selbst entwickelte Software inklusive Dokumentation von deren Entstehungsprozess?
- Ich möchte eben auch einfach mal in der Freizeit etwas Produktives machen. Bisher bin ich nur auf Arbeit wirklich produktiv und entwerfe Software. Aber da hat man eben immer den Zeitdruck; muss die Anforderungen so umsetzen, wie sie gefordert sind und die resultierenden Tools bringen einem selbst keinen Nutzen. Es ist eben irgendwie einfach nur Arbeit, die man macht. (Es macht zwar trotzdem Spaß, aber so richtig kann man sich irgendwie nicht entfalten.) Ich will einfach auch mal selber die Anforderungen definieren und Tools entwickeln, die mir persönlich sehr viel bringen. Und das ohne BWLer im Rücken, aus deren Sicht es ja keine Probleme gibt und alles "straight forward" ist. Ohne BWLer, für die Softwareentwicklung nur ein notwendiges, unberechenbares Übel in der Kostenkalkulation ist.
- Das Flow-Design verspricht eigentlich echte Wiederverwendbarkeit, da es nur Input- und Outputabhängigkeiten gibt. Ich hoffe, dass ich da auch viele Funktionseinheiten in anderen Projekten verwenden kann.
Was sind die persönlichen Herausforderungen und Risiken für mein Vorhaben?
- Durchhaltevermögen! Das ist definitiv die größte Herausforderung der ich mich stellen muss. Ich weiß schon jetzt, dass es sicher Phasen geben wird, wo ich mal definitiv keinen Bock haben werde, irgendwas zu programmieren. Ich denke, das ist aber ganz natürlich. Man ist schließlich kein Roboter. Ich hoffe nur, dass solch eine Phase nicht dauerhaft eines meiner Vorhaben zerstört!
- Durch meine hohen Anforderungen an die Usability werde ich endlich mal gezwungen, mich mit Drag & Drop, (dynamischen) Kontextmenüs und sonstigen GUI-Spielereien auseinanderzusetzen. Auch, was die prinzipielle Gestaltung der Oberfläche anbelangt. Da muss ich selber hartnäckig bleiben und darf mich nicht zu schnell mit einer ungewollten Lösung abfinden. Daher muss ich vorher penibel meine exakte Vorstellung dokumentieren und mich dran halten.
- Ich muss mir einheitliche Konventionen schaffen und mich penibel dran halten! Auf Arbeit ertappe ich mich oft, dass ich mit diesem Grundsatz breche. Oft aus Bequemlichkeit oder Zeitdruck.
Was gibt es sonst noch zu wissen?
- Ein Framework zu benutzen, ist für mich ein notwendiges Übel, um schnell Resultate zu bekommen. Für mich gibt es im Entwicklungsprozess aber nix Schlimmeres, als vor Problemen zu stehen, die mit dem Framework zu tun haben. Die Probleme entstehen, weil man oft nicht genau weiß, wie man ein Framework richtig benutzt. Oder man steht vor einem merkwürdigen Verhalten, was man nicht versteht und nicht nachvollziehen kann. (Das ist die Bug- und Fehlerquelle Nummer eins.) Daher meide ich auch den exzessiven Gebrauch von Framework-Features, die ich nicht verstehe oder nachvollziehen kann. Da erfinde ich das Rad lieber neu und weiß dann wenigstens, wie es funktioniert. Das werde ich auch bei meinen Projekten so handhaben. Mit der Strategie bin ich bisher sehr gut gefahren. (Außerdem ist es DAS, was mir überhaupt am Programmieren gefällt: Wenn man mal selber etwas implementieren kann und es hinterher noch tadellos funktioniert.)
- Ich werde nach Möglichkeit offene Libraries für Programmteile verwenden, wo ich selber einfach nicht die Zeit oder das nötige Know-How habe, um eine solche Funktionalität selber zu implementieren. (Z.B. Gesichtserkennung oder sowas.)
- Um meine grafischen Fähigkeiten etwas zu schulen, werde ich mich dieser Quelle bedienen:
http://2dgameartforprogrammers.blogspot.com/
Da dreht sich zwar alles um Spielegrafik, aber gerade was die Shading-Grundlagen anbelangt, kann man das Wissen sicher auch universell für GUIs einsetzen. - Die Codenamen meiner Projekte werden weibliche Vornamen tragen!
Ich habe lange überlegt, wie ich meine Projekte nennen könnte. Zuerst dachte ich an Tierbezeichnungen. Aber fast jede Software trägt ja irgendwie eine Tierbezeichnung als Codename. (Ubuntu & Co. lässt grüßen. *g*)
Davon will ich mich abgrenzen. Software ist in meinen Augen in jeder Hinsicht weiblich und nicht tierisch! ;-) Und vor allem möchte ich Namen für meine Software haben, die man sich auch gut merken und aussprechen kann. (Schließlich werden diese Namen ein Bestandteil des Namespaces. Da möchte ich keine cryptischen Bezeichnungen drin haben. *g*)
Im nächsten Beitrag werde ich dann sicher mein erstes Projekt vorstellen. Da bin ich selber sogar schon ganz gespannt drauf. :-D
Abonnieren
Posts (Atom)