Vorgeschichte
Manch einer wird es vielleicht wissen, beruflich bin ich Programmierer und Supporter in einer kleinen Firma bei mir in der Nähe.
Da mir dieser kreative Vorgang ein gutes Gefühl gibt (meistens zumindest), und ich auch andere Programmiersprachen und Techniken erlernen möchte, habe ich angefangen ein kleines privates Projekt zu starten.
Zunächst stand ich vor der Frage, was ich überhaupt machen möchte. Da ja das deejaying eines meiner Hobbys ist, wollte ich zunächst eine Verwaltungssoftware für DJs schreiben.
Die nächste Entscheidung, die ich treffen musste, war die Wahl der Programmiersprache, der Entwicklungsumgebung (IDE) und der Datenbank. Ich habe mich für das Microsoft Visual Studio 2005 Express als IDE und C# als Programmiersprache entschieden, weil zu dieser Zeit VS Express kostenlos wurde und ich es in Zukunft auch beruflich brauchen werde. Als Datenbank habe ich mich damals für sqlite entschieden, da es eine kleine und performate SQL-Datenbank ist, die ohne Datenbankserver auskommt.
Ich hab dann mal einfach unbedarft angefangen, aber ich merkte schnell, dass ich doch mehr Grundkenntnisse benötige. So habe ich erst Mini-Applikationen wie eine simple ToDo-Liste erstellt.
Irgendwann zu dieser Zeit wollte ich aus der Abhängigkeit zu Microsoft raus, d.h., Windows aufgeben und zu Linux wechseln. Das hat zwar einige Zeit gedauert, aber privat bin ich fast nur noch ausschließlich mit Linux (Debian) unterwegs. Damit hat sich aber auf einen Schlag VS Express und C# erledigt. Es gibt zwar unter Linux mono, aber so ganz ist es mit dem .NET-Framework nicht kompatibel.
Also begann meine Suche erneut, diesmal nach einer IDE und einer Sprache, die plattformunabhängig ist, so dass ich sowohl unter Linux, wie auch Windows entwickeln, aber auch die Anwendung ausführen kann.
In einem solchen Fall wird meist Java als erstes genannt. Und da ich mir früher schon mal Sun Microsystems entwickelte objektorientierte Programmiersprache, die aber eine installierte Runtime benötigt (ähnlich wie C# das .NET-Framework benötigt). Der Vorteil ist, dass es diese Runtime für verschiedene Betriebssysteme gibt und sie unter jedem Betriebssystem fast die gleichen Möglichkeiten bietet.
Im Moment ist es so, dass Eclipse von vielen Entwicklern als IDE für Java bevorzugt wird. Ich hab es mir mal angeschaut, komme damit aber nicht zurecht. Wie gesagt, hatte ich schon Erfahrung mit Netbeans. Vor allem der integrierte GUI-Builder gefällt mir ganz gut.
In Sachen Datenbank habe ich mich auch um entschieden. Ich hatte schon früher damit Kontakt, aber bisher noch nie etwas damit ausprobiert. Die Rede ist von Objekt-Datenbanken. Im Gegensatz zu relationalen Datenbanken gibt es in Objekt-Datenbanken keine Tabellen im eigentlichen Sinne. Stattdessen werden die Objekte als solches gespeichert. Das hat zwei gravierende Vorteile. Zum einen soll diese Art von Datenbank performater sein, wenn es um den Zugriff auf viele Verknüpfungen geht (ok ist bei meiner kleinen Anwendung nicht entscheidend), und zum anderen fällt die Schicht weg, in der ein Objekt in eine SQL-Anweisung bzw. ein Datensatz in ein Objekt umgewandelt werden muss, da die Objekte einfach so gespeichert werden. Es war aber hauptsächlich die Neugier, wie eine Datenbank ohne Tabellen auskommt. Etwas zu können, was die meisten anderen nicht können, kann sich später als Vorteil erweisen. Ich bin eh überzeugt, dass relationale Datenbanken deswegen vorherrschen, weil die meisten Entwickler und Administratoren eben nur diese Datenbanken gelernt haben.
Konkret habe ich mich für db4o (database for objects) entschieden, ist wohl die bekannteste kostenlose Objekt-Datenbank mit gutem Support für Java und C#.
Mampf die Rezeptverwaltung
Da ich mich sowohl in Sprache wie auch in die neue Datenbank einarbeiten muss, habe ich die Verwaltungssoftware für DJs erst mal bei Seite geschoben. Das wäre für den Anfang einfach zu umfangreich, und ich würde schnell die Motivation verlieren, da ich kein Ende sehe. Also musste ein neues Projekt her. Das zu finden war auch nicht schwer. Ein weiteres meiner Hobbys ist das Kochen. Ich koche viel und gern und lasse mich oft von fremden Rezepten inspirieren. Meistens wandle ich diese aber ab.
Blöd ist meist nur, wenn man unzählige Kochbücher und Zeitschriften hat, und vielleicht 5 Rezepte aus einem Buch/Heft interessant sind. Da verliert man schnell den Überblick und sucht sich tot. Also liegt da nichts näher eine Rezeptverwaltung zu schreiben. Klar, am Anfang wird es mühsam sein, seine Rezepte einzutragen, aber wenn man sie mal hat, gestaltet sich die Suche wesentlich einfacher.
Die Rezeptverwaltung wird „mampf“ heißen, und wenn sie mal fertig ist, als Freeware erhältlich sein. Wann es so weit sein wird, kann ich absolut nicht sagen. Das hängt davon ab, wie viel Zeit und vor allem Lust ich privat habe. Im Moment habe ich wieder Lust, daher tut sich etwas. Geht aber schleppend voran, weil ich ja auch gerade erst lerne, wie was funktioniert.
Bisher Geplante Features:
Erfassen, Bearbeiten, Löschen von Rezepten
Erfassen, Bearbeiten, Löschen von Stammdaten (Arten, Unterarten, Zubereitungsarten, Region, Zutaten, Mengeneinheiten)
Suchfunktion mit Filtern
Drucken der Rezeptliste
Drucken einzelner Rezepte
Es gibt aber schon mal Screenshots von der vorläufigen Oberfläche, wie es später mal aussehen könnte:
Im Moment arbeite ich an den Stammdaten. Das sind kleine Module, mit denen Daten verwaltet werden, die man später für die Erfassung eines Rezepts benötigt. Als Beispiel nehme ich mal Zutaten. Viele Zutaten verwendet man ja immer wieder in verschiedenen Rezepten. Es wäre also unsinnig in jedes Rezept manuell z.B. „Olivenöl“ einzutragen. Zum einen wäre es sehr umständlich, zum anderen würde es Fehler in der späteren Suchfunktion provozieren, denn man kann „Olivenöl“, „Olivenoel“ oder „olivenöl“ schreiben, und für die Anwendung wären das drei verschiedene Zutaten. So erstellt man die Zutat in den Stammdaten, und kann sie in ein Rezept einfach aus einer Liste übernehmen:
Letzte Kommentare