Skip to content

Versionierte Konfigurationsfiles

Software ist nicht perfekt und wird auch ständig weiter entwickelt. Das führt dazu, dass bestimmt Konfigurationen der Software sehr viele Generationen überleben müssen. Problem dabei ist, dass durch neue Erkenntnisse Defaults geändert werden, neue Parameter notwendig werden, und dass es eben generell schwer ist den Benutzer bei Upgrades zu unterstützen:
  • Welche Parameter müssen hinzugefügt werden
  • Welche Defaults haben sich geändert
  • Für welche Version ist die Konfiguration
Eine gute Möglichkeit ist es einen Versions-Identifier in den Dateien mitzuführen, und bei jeder (nicht kompatibler) Änderung diesen hochzuzählen. Anwendungen haben dann die Möglichkeit entweder den Start zu verweigern, bis das Konfigurationsfile angepasst wurde, oder sich wie die alte Version der Anwendung zu verhalten. Welche alternative Strategien existieren? Nun eine Möglichkeit ist die Konfiguration der Anwendung zu trennen in Defaults (vom Hersteller) und Änderungen (installationsspezifisch). Damit kann der Hersteller neue Defaults ausliefern und muss nicht ermitteln welche Parameter der Anwender geändert haben möchte. Der Nachteil dabei ist allerdings, dass der Anwender sich natürlich auf bestimmte Defaults verlassen hat, und wenn diese geändert werden (typisches Beispiel: der Default für einen wenig benutzen Netzwerk Server wird von "on" auf "off" gendert. Der Anwender hatte in seiner Konfiguration die Option nicht überschrieben, da der Default ja OK war. Nach einem Update der Software kommt es zu einem Funktionalitätsverlust, weil der Benutzer nicht dazu agehalten wurde, sich über die geänderte Sematik zu informieren. Somit bleibt so oder so nur eine ausführliche Dokumentation der Änderungen. Üblicherweise geschieht dies in Release Notes, die zu umfangreichsind um die wichtigen von den unwichtigen Informationen zu trennen. Deswegen ist für den Anwender dabei hilfreich eine Versionsnummer zu sehen, die sein File aktuell hat, die von der Anwendung erwartet wird, und welche Änderungen dazu notwendig sind. Continue reading "Versionierte Konfigurationsfiles"

Einladung: JUGS-Talklet "Das Java Performance Modell" am 26. Januar 2006

Über den E-Mail Verteiler der Java-User-Group Stuttgart (JUGS) kam folgende Einladung rein:
Einladung zu einem
Vortrags- und Diskussionsabend
am Donnerstag, 26. Januar 2006, 18.30 Uhr
im Hörsaal H35 der Universität Hohenheim
Wegbeschreibung: http://www.jugs.org/anfahrt-hohenheim.html Titel: Das Java Performance Modell Referentin: Angelika Langer
Abstract In jeder Programmiersprache gibt es Prinzipien, die beschreiben,
wieviel Zeit ein bestimmtes Sprachkonstrukt beim Ablauf kosten wird. Diese Korrelation zwischen den Sprachmitteln und ihrer Performance bezeichnet man als Performance-Modell.
Continue reading "Einladung: JUGS-Talklet "Das Java Performance Modell" am 26. Januar 2006"

Nicht-Funktionale Anforderungen

Randy Miller siniert über den Begriff non-functional requirements. Er bevorzugt den Begriff Quality of Service Requirements, und ich kann hier nur zustimmen. Nicht-Funktionale Anforderungen war für mich schon immer ein sehr irreführender Name: Das Verhalten von Anwendungen in Last Situationen, die Benutzerfreundlichkeit und vor allem auch die Skalierbarkeit, Erweiterbarkeit und Einbindung in Sicherheitsinfrastruktur ist ein wesentlicher Bestandteil von Software, der oftmals bei der Erstellung von Custom Inhouse Lösungen vergessen wird. Dabei kann man auch nicht mehr von funktionieren sprechen, wenn die Software unbenutzbar langsam ist, oder unverhältnismäßig hohe Betriebskosten verursacht. Randy Miller ist Teil des Microsoft Teams welches das Microsoft Solution Framework für Agile Software Prozesse entwickelt. (In diesem Zusammenhang möchte ich übrigens noch auf die Umfrage hinweisen, welche Sprachen werden bei Ihnen im Unternehmen für punktuelle Lösungen oder für das Custom Development eingesetzt?)