[HBF] Brausoftware

[Peter Wiedermann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hallo braugemeinde

meiner meinung nach ist es an der zeit mit der entwicklung der struktur
der datenbank (die grundlage unserer arbeit) zu beginnen.
hier muessen auch leute mitarbeiten die keine ahnung von
software(entwicklung) haben, denn was wir in diesem stadium brauchen ist
brauerfahrung. es muss moeglichst viel wissen in die datenbank abgebildet
werden koennen...

ich habe dazu ein grobes (habe nicht ganz so viel zeit
reingesteckt, schliesslich weiss ich ja nicht ob ich
ueberhaupt mit rueckmeldungen rechnen kann) gerust der struktur
beschrieben, um die folgenden diskussionen etwas konkreter zu gestalten.

es geht hauptsaechlich darum vorschlaege fuer weitere eigenschaften der
objekte  zu liefern. zb was koennte hopfen noch charakterisieren ausser
dessen name und seiner bitterung...

hier also einmal ein entwurf:
http://geldspeicher.entenhausen.at/brauware/



um noch auf die letzte mail von hubert einzugehen:

> 6.) Java ist nicht mein Fall, wozu der Umweg über eine VM, wenn's mit Tools
> wie QT von Trolltech viel effizienter und schneller geht? Heute macht bei
> größeren Projekten QT das Rennen VOR Java -- Java ist doch überholt ;-);-)
> Aber wenn alle, die Java vorschlagen, auch wirklich Java-Programmierer sind,
> wird's schon gehen. Wichtig ist, dass sich niemand der Illusion hingibt,
> dass irgend jemand extra für dieses Projekt eine neue Programmiersprache
> lernt! Nachdem es in Deutschland sehr viele Unix-KDE Entwickler gibt, hätte
> ich erwartet, dass QT mehr Echo findet, aber scheinbar trinken und brauen
> die KDE Entwickler kein Bier.

also eines kann niemand bestreiten: aus der sich des programmierers hat
java das klarste (und genialste) sprachliche konzept (auch im
verlgeich zu c++... jaja jetzt kommt gleich ein smalltalk einwurf.. ich
meine eher von "applikationstechnisch gesehenen" praxisnahen sprachen).
geht man also an die arbeit eine applikation zu entwickeln muss man sich
natuerlich die rahmenbedingungen ansehn.
effizienz gibt es naemlich auf beiden seiten. auf der des programmierers
und auf der des benutzers.
zweifelsohne wird eine qt-app dem benutzer ein schnelleres programm
liefern... die frage ist nur ob dieser geringe geschwindigkeitsvorteil in
unserm fall wirklich ins gewicht faellt...
und eben ab hier kann es jetzt meinungsverschiednheiten geben.
ich bin der meinung das wir in diesem fall mit java keine groben nachteile
fuer die user ins spiel bringen wuerden...

gut sud
peter

====================================================
Peter Wiedermann <peter.wiedermann at gmx.at>
gpg public key: http://geldspeicher.entenhausen.at
====================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE95m81NCZnZhPzqWURAv6zAJ9IxqEtGYI1M16HuE/n/VJyAFSRDwCdHHG2
j+TFSKc7tcXWxMmDkrF6e+Y=
=QRdu
-----END PGP SIGNATURE-----