[HBF] Brausoftware

[Hanghofer Hubert]

Liebe Braugemeinde,
werte Programmentwickler,

ich habe alle Resourcen, die ich zur Verfügung stellen kann unter der GNU
General Public License freigegeben und auf
http://www.netbeer.org/bin/ gespeichert. In der README Datei des
Source-Paketes sind nochmal meine Ziele zusammengefasst.

Aus Zeitmangel habe ich jetzt wenig Möglichkeiten, daran weiterzuarbeiten,
trete aber gerne einer Mailingliste bei, falls jemand eine organisiert
(bitte nicht diesen Absender aufnehmen, sondern "brew at netbeer dot co dot
at").

Noch ein paar Stellungnahmen bzw. persönliche Meinungen zu diversen Fragen
und Diskussionspunkten (habe von hier aus keinen Zugriff auf alle Mails und
muss leider frei -ohne Autorenverweise- zitieren):

1.) Pellets 45 können bei der IBU Berechnung genauso berücksichtigt werden
wie grüne, ungetrocknete Hopfendolden: einfach den entsprechenden
Alphasäurewert eingeben. Dieser wird bei P45 vom Händler angegeben (wenn
nicht, Händler wechseln!), bei grünem Hopfen nimmst Du 1/6 des erwarteten
Alphawertes. Ich habe das bei einem Green-Ale heuer so gemacht - passt
perfekt!

2.) Wozu Excel-Tabellen für Software-Entwicklung?
  a) Quelle für Formel- und  Funktionsprototypen bzw. Berechnungsschemata.
  b) Zum Debugging - Verifizierung des Programm-Outputs.

3.) Datenbank: Sehr sinnvoll. Die Installation von MySQL ist ein Kinderspiel
(...na ja, fast ;-), es gibt ein C und ein sehr gutes PHP-Interface, läuft
stabil und hervorragend, sogar unter Windows ;-) und ist FREI verfügbar. Der
Programmieraufwand ist nicht hoch, da man mit wenigen Grundfunktionen
auskommt. Die Komplexität liegt im Server verborgen, nicht im
Client-Interface.

Besonders interessant wäre eine Export-Option, mit der Eure erfolgreichen
Kreationen in eine online-Datenbank übertragen werden können (eine Art CDDB
für die Brauer-Community). PHP-MySQL ist heute Webstandard und eine
Anbindung ist sicher unproblematisch. Notfalls kann ich sowas auf
www.BierIG.org einrichten.

4.) Datenbankstruktur: Tabellen für Hopfen, Malz, Hefe?, Rezepte,
Systemkonstanten ...??

5.) Eine Software braucht nicht mehr berechnen zu können als eine
Tabellenkalkulation -- was zählt bzw. eindeutig für eine
Software-Implementierung spricht, sind:
Datenbankanbindung, Berechnungen müssen nicht in einer Richtung laufen (man
könnte z.B. wahlweise die Schüttung vorgeben oder das gewünschte
Biervolumen), BEDIENUNGSFREUNDLICHKEIT. --Erschreckend wenige User können
mit Excel wirklich umgehen und ohne Makroprogrammierung oder Aufspaltung in
x Registerblätter ist kaum eine benutzerfreundliche Schnittstelle
realisierbar.

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.

7.) Warum ein Library in C? Sieht man von den Skriptsprachen ab, ist C im
open-source Bereich die verbreitetste Programmiersprache. Für jede
Architektur gibt es C-Compiler. C-Quellcode nach dem ANSI-Standard ist daher
de facto plattformunabhängig und 100% portierbar. Für die Implementierung
von Braufunktionen kommt man mit ANSI-C aus. Werden für Anbindung von z.B.
Mess- und Regeltechnik plattformabhängige I/O-Routinen benötigt, dürfen
diese natürlich nicht ins Basis-Library, sondern müssen ausgelagert werden.

Freie Compiler:
C/C++: http://gcc.gnu.org/
Windows Version: http://www.mingw.org/


Bitte um Verständnis, dass einige Punkte weit vom Kernthema dieses Forums
abweichen. Bis jetzt hat sich noch niemand beschwert, aber vielleicht
sollten programmiertechnische Details wirklich ausgelagert werden. Ich habe
dafür leider keine Resourcen frei.

Was andererseits die Benutzerschnittstelle bzw. -Anforderungen betrifft,
sollte meiner Meinung nach das HBF in jedem Fall 100% eingebunden bleiben,
denn Ihr alle seid die potenziellen Anwender.

Allzeit gut Sud!

Hubert Hanghofer
www.netbeer.org
www.BierIG.org