Software für Münz-Sammler

[jwerner]

Hallo,


ich habe eine kleine Münzsammlung geeerbt. Dadurch steige ich nun in diese Hobby ein.

Da ich ausserdem beruflich Software programmiere, bin ich dabei, ein Programm für das Inventarisieren einer Sammlung zu erstellen.

Bei Interesse würde ich das Programm zur Verfügung stellen.

Wer an der Entwicklung teilnehmen möchte (über Feedback freue ich mich sehr!), kann folgende Webseite besuchen:

http://www.diggin-data.de/wiki/wiki/run.php?iRequest=wiki/ViewPage&iPage=ProjektCoinCollector

Das ist eine sog. WikiWiki-Webseite, in der Sie selbst recht einfach Wünsche, Anregungen, Kommentare usw. für das neue Programm eintragen können.

Mich würde insbesonders interessieren, ob der angedachte Aufbau einer Sammlung im Programm so praxisgerecht wäre.

Besteht ausserdem Nachfrage an einem Mechanismus, mit dem man Münzen seiner Sammlung per Klick aus dem Programm auf einer Kleinanzeigen-Webseite veröffentlichen kann?

Die erzielten Verkaufspreise könnten in die Software zurückfliessen, so das vielleicht eine Bewertungsdatenbank wächst?

Ich bin gespannt auf Ihr Feedback!


Viele Grüsse aus Wiesbaden


Joachim Werner

 

[Raphael]

Willkommen im Forum.

Soll es eine globale Münzenverwaltung sein oder auf ein Gebiet spezialisiert? DM, Euro, Weltmünzen, FP's ...?

Es gibt bei den Erhaltungsangaben auch Zwischenstuffen, vz vz- ...

 

[jwerner]

Hallo Raphael,

Soll es eine globale Münzenverwaltung sein oder auf ein Gebiet spezialisiert? DM, Euro, Weltmünzen, FP's ...?

Das ist eine schwierige Frage. Ich persönlich sammle nur deutsche 5er und 10er DM-Gedenkmünzen sowie Numisblätter.

Ich würde das Programm gern so schreiben, dass auch andere Gebiete erfasst werden können. Dazu müsste man (wir?) sich aber wahrscheinlich überlegen, ob man alle Gebiete in eine "riesige" Tabelle einordnen kann, oder ob man für einzelne Sammelgebiete individuelle Module (=Tabellen, Ansichten) erstellt.

Es gibt bei den Erhaltungsangaben auch Zwischenstuffen, vz vz- ...

Hängt das evtl. auch mit verschiedenen Sammelgebieten zusammen?

Viele Grüsse,

Joachim Werner

 

[Janek.Schumann]

Da ich mich selbst mit PHP auskenne, habe ich mal eine Frage zu der Oberfläche:

Was erstellt das PHP GTK+ eigentlich? Das sieht mir nicht nach "gültigem" HTML aus, sondern nach einem Java-Applet, welches da erstellt wird.

Gehe ich da recht in der Annahme?



Das Problem, was ich bei einem solchen Projekt sehe, ist nicht unbedingt der Aufwand (der durchaus sehr hoch ist!) oder die Datenbasis (welche auch erstmal eingegeben werden muss!), sondern eher bei den Benutzern.

Viele Programme, und das meine ich ganz allgemein, haben extrem grosse Defizite beim (H)UI-Design. Die Benutzergemeinde dieses Forums ist hier glaube ich ein ganz gutes Beispiel:

Wie haben Benutzer von jung bis alt. Wir haben Sammler, die wenig mit Computern arbeiten und welche, die hauptberuflich damit umgehen.
Aber was noch viel wichtiger ist: Gerade das sammeln von Münzen ist auch für Menschen mit Behinderungen (welcher Art und Ausmasse auch immer) attraktiv. Man kann es nicht jedem recht machen, aber es sollte eigentlich kein Problem darstellen z.B. Menschen mit Sehschwächen zu berücksichtigen. Irgendwo sind sicherlich Grenzen, aber ich kenne kaum eine Seite, die diese Grenzen auch nur ansatzweise erreichen.

Und genau hier haben wir, oder genauer gesagt ich, bei Deiner Lösung Probleme. Ich würde jetzt einfach mal behaupten, das man z.B. mit einem Textbrowser diese Seite nicht besuchen kann. Oder irre ich? (Gerade bei evt. späteren Gedanken an die Kommerzialisierung )


Auch wenn es schwer fällt: Ich würde auf plain-HTML ohne Tabellen setzen.

Immer eine gute Anlaufstelle: Bobby


Wir hatten ja schon öfters solche Projekte hier vorgestellt bekommen und auch immer fleißig diskutiert, aber ich glaube, wenn ich mich jetzt recht erinnere, das wir in der Richtung noch gar nichts erörtert haben, oder?!
Aber das ist, wie ich finde, ein wichtiges Thema was leider all zu oft unter den Tisch fällt.

-------------

EDIT: Ok... PHP GTK ist nicht für Webseiten. Aber dann ist das ja noch schlimmer.

Dann würde ich lieber auf C setzen, als auf PHP. Aus diversen, wie ich finde naheliegenden, Gründen.

 

[jwerner]

Hallo Herr Schumann,

Da ich mich selbst mit PHP auskenne, habe ich mal eine Frage zu der Oberfläche:

Was erstellt das PHP GTK+ eigentlich? Das sieht mir nicht nach "gültigem" HTML aus, sondern nach einem Java-Applet, welches da erstellt wird.

Gehe ich da recht in der Annahme?

Die Programmiersprache PHP benutzt die GTK+-Bibliothek, die die sog. "Fenster"-Funktionen bereitstellt. Daraus ergibt sich dann ein "Windows"-Programm. Das hat erstmal nichts mit HTML oder Webseiten zu tun.

Für die Listen-Erstellung erzeuge ich momentan noch HTML. D.h. eine Liste (z.B. Dubletten, Fehlliste) wird als HTML-Datei generiert, die man dann im Browser betrachten und ausdrucken kann. PDF-Dateien wären jedoch auch kein Problem und garantieren ein besseres Drucklayout (Seitenumbrüche...).

Viele Programme, und das meine ich ganz allgemein, haben extrem grosse Defizite beim (H)UI-Design.

Deshalb habe ich schon mal Bilder der Ansichten und Eingabemasken in meine Wiki-Webseite gestellt (s.mein erstes Posting oben). Jeder, der Interesse an dem Programm hat, kann dort Anregungen und Kritik reinschreiben.

Auch wenn es schwer fällt: Ich würde auf plain-HTML ohne Tabellen setzen.

Ich denke, in einem Sammel-Programm passieren recht viele Dinge, die von Klicks auf irgendwelche Listen oder Felder abhängen. Beispiel: ich wähle ein Sammelgebiet, und es sollen dann alle zugeörigen Münzen in der nächsten Liste angezeigt werden.
In einer HTML-Anwendung dauern diese Abläufe einfach länger. Ausserdem müsste man beim Benutzer einen Webserver installieren...

Ich hoffe, diese technischen Infos gehen nicht zu weit ins Detail?

Viele Grüsse,

Joachim Werner

 

[Janek.Schumann]

[...]Ich denke, in einem Sammel-Programm passieren recht viele Dinge, die von Klicks auf irgendwelche Listen oder Felder abhängen. Beispiel: ich wähle ein Sammelgebiet, und es sollen dann alle zugeörigen Münzen in der nächsten Liste angezeigt werden.
In einer HTML-Anwendung dauern diese Abläufe einfach länger. Ausserdem müsste man beim Benutzer einen Webserver installieren... [...]

Ich denke hier müssen wir ins Detail gehen ...

Ich gehe erstmal auf mein Hauptargument ein:

Eine Webseite ist durch die einfache Informationsdarstellung leicht durch weitere Produkte verarbeitbar und somit in allen Formen umwandelbar. Bei einer Client-Anwendung habe ich diesen Vorteil nicht, ausser man stellt APIs, oder andere Schnittstellen, zur Verfügung, was ich mangels Interesse von dritten bzgl. Weiterentwicklung erst bei sehr bekannten (und guten) Programmen als lohnenswert erachten würde.
Auch der Einsatz der Maus ist kritisch. Generell gilt: es muss auch ohne gehen!



Zum Thema Technik:

GTK ist an sich ok. Dagegen sage ich nix, da es nur wenige andere Möglichkeiten gibt. Ich halte nur den Einsatz von PHP als Sprache in diesem Anwendungsbereich (eigentlich generell für Client-Anwendungen) für sehr fragwürdig. Ich denke hier gibt es wesentlich bessere, vor allem performantere Möglichkeiten.

Alternativ zu GTK kann man Java verwenden. Ich muss gestehen, das ich kein Java-Fan bin, aber theoretisch möglich ist es. Und vermutlich auch nicht die schlechteste Lösung, wenn man plattformunabhängig sein möchte.

Was die Geschwindigkeit bei einer Webseiten angeht, muss ich bei der Performance stark wiedersprechen. Eine Seite wird mittels PHP in maximal 1 Sekunde erstellt, und dann ist das schon eine extrem grosse Seite! (Ausser sie ist schlecht programmiert, aber das kann alles langsam machen )

Ein grosser und, wie ich finde extrem wichtiger, Punkt bei dem Thema der Applikation, ist die Datenbasis der Münztypen.
Es ist auf hösste Masse unpraktisch, wenn bspw. 50 Leute jeder für sich den gleichen Münztyp eintippern muss. Hier liegen die Vorteile bei einer Webseite.
Ist diese Datenbasis erstmal geschaffen, muss das nicht unbedingt stimmen. Das gebe ich zu. Problematisch ist hier die Verteilung der Daten. ...

Alles nicht so einfach.



Was die Installation eines Webservers angeht, so würde ich die Vorteile einer zentralen Anlaufstelle nutzen und damit wird die Installation beim "Kunden" unnötig.

[...]


Wenn, und das ist das Problem ALLER hier vorgestellter Programme, man etwas dauerhaftes schaffen will, muss man sich VORHER Gedanken über solche Sachen machen. Ich will hier mal ein paar Stichpunkte geben:
- ganz wichtig: Die Datenbankstruktur. Hier habe ich bisher noch keinen praktikablen Ansatz gesehen, weil dies sehr schwer zu realisieren ist.

- Erweiterbarkeit oder Anpassbarkeit an neue Wünsche, Anforderungen etc.

- Verteilung von Daten (neue Daten, geänderte, doppelte, ... )

- zentrale Datenhaltung kombiniert mit lokalen Repositories

- Datensicherheit


Wenn diese, vor allem der erste und evt. der zweite, Punkte geklärt sind, ist die Umsetzung fast egal.

Ich erinnere hier mal an eine sehr vorteilhafte Technik namens SOAP. Bzw. dessen Hauptverwendung: Webservices.

Welche Technik zur Verwendung kommt, um die Daten anzuzeigen, ist dann egal. Jeder kann das nutzen, was er will, hauptsache alle benutzen den selben Service. Die Schnittstellen zu einem solchen Service sind eigentlich in jeder Programmiersprache vorhanden.



Die Ausprogrammierung macht normalerweise gerade mal 10-15% des Programms aus. Fast der gesammte Rest ist Planung im Vorfeld.

-----------------

Aber lassen wir diese Diskussion. Wir haben schon so viele Projekte dieser Art gesehen, das langsam der Glaube daran auf der Strecke geblieben ist.

 

[Raphael]

...
-----------------
Aber lassen wir diese Diskussion. Wir haben schon so viele Projekte dieser Art gesehen, das langsam der Glaube daran auf der Strecke geblieben ist.

Dies war auch meine Überlegung. Ich habe die Datenbasis bereits geschaffen (bereits über 10.000 Münzen) und der Rest (Anwendung) ist nur noch ein Vergnügen.

Ich habe es einfach nicht geschafft, 2-3 Sammler auf einen Nenner zu bringen. Jeder hat nun mal seine Vorstellungen, aber es gilt den kleinsten gemeinsamen Nenner zu finden.
Bitte eines nicht vergessen! Man kann eine Software realisieren, aber ihr habt nicht die Daten, die der Sache das Leben einhauchen!

 

[jeggy]

Ich würde PHP/XSL/MySQL dafür verwenden und dies als
Online-Applikation konzipieren.

Wenn so etwas auch offline auf Windows laufen soll, gibt es ja Microweb.
Das funktioniert hervorragend. Für einen Münzensammler-Software
allemal performant genug.

Java hat zu lange Entwicklungszyklen und ist anfälliger als das robuste PHP.

Ich bin seit über 10 Jahren professionell als Softwareentwickler tätig.
Diese Technik imponiert mir und ich verwende sie für diverse Projekte.

Gruss,
jeggy

 

[Janek.Schumann]

Ich würde PHP/XSL/MySQL dafür verwenden und dies als
Online-Applikation konzipieren. [...]

Ich muss gestehen, das ich hier ein paar Defizite habe.

Wie läuft das grob ab?? (Ich habe seit deinem post mal versucht die W3C-Referencen zu lesen, aber in der Zeit natürlich nur grob überflogen )


MySQL <-> PHP -> XML <-> XSL -> Client?

EDIT: Ich formuliere um: Die Daten aus der DB liegen in XML-Form vor, welche mittels XSL, und dadurch entsprechend definierte Grammatiken, in HTML (?) transformiert werden, welches der Client dann bekommt. Das PHP ist eigentlich nur noch dazu da, um Interaktionen und Dynamlik (gerade bei den DB-Abfragen) zu realisieren.

Ist das so in etwa richtig?

PS: Verdammt... über sowas wollte ich eigentlich auf dem Seminar mit dir sprechen...

 

[jeggy]

Ich muss gestehen, das ich hier ein paar Defizite habe.

Wie läuft das grob ab?? (Ich habe seit deinem post mal versucht die W3C-Referencen zu lesen, aber in der Zeit natürlich nur grob überflogen )


MySQL <-> PHP -> XML <-> XSL -> Client?

EDIT: Ich formuliere um: Die Daten aus der DB liegen in XML-Form vor, welche mittels XSL, und dadurch entsprechend definierte Grammatiken, in HTML (?) transformiert werden, welches der Client dann bekommt. Das PHP ist eigentlich nur noch dazu da, um Interaktionen und Dynamlik (gerade bei den DB-Abfragen) zu realisieren.

Ist das so in etwa richtig?

OK, hier ein bisschen "Kauderwelsch"

Ja, Daten z.B. für die Seitentexte werden in XML-Dateien auf dem Filesystem gelagert, Massendaten in der Datenbank. PHP erzeugt aus den DB-Daten temporäres XML und führt das zusammen mit dem statischen XML dem XSLT-Prozessor zu. Dieser parst das XML und ein event-basiertes XSL-Stylesheet wandelt alles in z.B. HTML um, welches dem Client serviert wird.

Vorteil: Strikte Trennung von Daten und Layout, XSL-Templates sind gut wiederverwendbar.

Man kann auch noch einen Schritt weitergehen und Layout-Definitionen in ein weiteres XML setzen, das mittels spezieller definierter Tags (im XSL definiert) das Layout bestimmt. Damit kann man dann eine einfache Layout-Sprache bauen, die individuell anpassbar ist. XSL kann auch für die Transformation ein bisschen Logik verarbeiten - das ist auch sehr nützlich, um zu komplexe Daten-Aufbereitung zu vermeiden. Weiterhin kann man verschiedene Stylesheets bauen für unterschiedliche Ausgaben - so kann z.B. das eine Stylesheet Browser-HTML rendern, das andere erstellt Output für PDAs oder Mobiltelefone etc.

Mittels XML-Schemata (Reglementierung der Daten) kann das XML auch auf Sachbearbeiter-Ebene mit einem High-Level-Editor gepflegt werden, falls gewünscht.

Insgesamt eine recht leistungsfähige Angelegenheit.

PHP bereitet Daten auf, verarbeitet Anfragen und hält Session-Daten etc. auf dieser Ebene hat man mit dem Frontend nichts zu tun, was sehr vorteilhaft ist.

Natürlich sind diese Techniken nur so gut wie die Architektur, die man verwendet und selber aufbaut. Je schlauer diese ist, desto mehr Effizienz kommt dann hinten dabei raus. Aber ist das nicht überall so?

Gruss,
jeggy