DevelopmentReadingsAPI - Versionsgeschichte

Markusbloch: Ersetzung von Forum-Links mit Vorlage Link2Forum

2017-03-19T19:24:26Z

Ersetzung von Forum-Links mit Vorlage Link2Forum

← Nächstältere Version		Version vom 19. März 2017, 21:24 Uhr
Zeile 4:		Zeile 4:
	Diese Seite beschreibt ein Konzept für ein API für Readings in FHEM. Diese Seite dokumentiert den aktuellen Stand der Diskussion.		Diese Seite beschreibt ein Konzept für ein API für Readings in FHEM. Diese Seite dokumentiert den aktuellen Stand der Diskussion.

	Ausgangspunkt ist ~~[http://forum.fhem.de/index.php/topic,~~21247~~.0.html~~ dieser Thread].		Ausgangspunkt ist {{Link2Forum\|Topic=21247\|LinkText=dieser Thread}}.

	== Ausgangssituation ==		== Ausgangssituation ==

Krikan: Kategorie:Development (Archive) zugeordnet

2016-10-19T12:12:30Z

Kategorie:Development (Archive) zugeordnet

← Nächstältere Version		Version vom 19. Oktober 2016, 14:12 Uhr
Zeile 1:		Zeile 1:
	~~[[Kategorie:Development]]~~

	== Abstract ==		== Abstract ==
Zeile 67:		Zeile 66:
	* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.		* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.
	* Think big, start small: vermutlich bringen wir nur etwas zu Wege, wenn wir nicht gleich den großen Wurf anstreben, sondern mit einem Aspekt beginnen (de facto Readings) und dabei stets das gesamte Zielbild im Auge halten.		* Think big, start small: vermutlich bringen wir nur etwas zu Wege, wenn wir nicht gleich den großen Wurf anstreben, sondern mit einem Aspekt beginnen (de facto Readings) und dabei stets das gesamte Zielbild im Auge halten.

			[[Kategorie:Development (Archive)]]

Ntruchsess: /* Anforderungen an das API */ Anmerkung 'CommandSetReading'

2014-11-24T12:17:56Z

Anforderungen an das API: Anmerkung 'CommandSetReading'

← Nächstältere Version		Version vom 24. November 2014, 14:17 Uhr
Zeile 36:		Zeile 36:
	#* Es soll möglich sein einen aus den Werten von Readings, Attributen und Internals abgeleiteten Wert abzufragen		#* Es soll möglich sein einen aus den Werten von Readings, Attributen und Internals abgeleiteten Wert abzufragen
	#* die Zugrunde liegenden Werte (Readings, Attribute und Internals) sollen beliebigen Devices zuordenbar sein. Es soll z.B. ermöglicht werden mehrere getrennte Analoge Ausgabedevices zu einem einzigen RGB-Wert zu aggregieren.		#* die Zugrunde liegenden Werte (Readings, Attribute und Internals) sollen beliebigen Devices zuordenbar sein. Es soll z.B. ermöglicht werden mehrere getrennte Analoge Ausgabedevices zu einem einzigen RGB-Wert zu aggregieren.
	#* Sofern die Abbildevorschrift bijektiv ist, soll es möglich sein durch Setzen des abgeleiteten Wertes die zugrunde liegenden Größen zu verändern. Readings sind per definitionem nur aus dem Gerät selbst heraus und nicht in das Gerät hinein veränderbar. Oder wollen wir zulassen, dass Readings manipuliert werden können? Welchen Anwendungsfall gibt es dafür?		#* Sofern die Abbildevorschrift bijektiv ist, soll es möglich sein durch Setzen des abgeleiteten Wertes die zugrunde liegenden Größen zu verändern. Readings sind per definitionem nur aus dem Gerät selbst heraus und nicht in das Gerät hinein veränderbar. Oder wollen wir zulassen, dass Readings manipuliert werden können? (Warum gibt es ein 'CommandSetReading' in der bestehenden fhem-api?). Welchen Anwendungsfall gibt es dafür?
	#* Es soll möglich sein eine Benachrichtigung zu erhalten, wenn sich dieser abgeleitete Wert ändert (ggf. mit Verzicht auf Änderungen von Internals die ja keine Events auslösen).		#* Es soll möglich sein eine Benachrichtigung zu erhalten, wenn sich dieser abgeleitete Wert ändert (ggf. mit Verzicht auf Änderungen von Internals die ja keine Events auslösen).
	#* Es soll sich die Bedeutung eines abgeleiteten Wertes ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).		#* Es soll sich die Bedeutung eines abgeleiteten Wertes ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).

Ntruchsess: /* Anforderungen an das API */

2014-11-24T10:16:06Z

Anforderungen an das API

← Nächstältere Version		Version vom 24. November 2014, 12:16 Uhr
Zeile 43:		Zeile 43:
	#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.		#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.
	#* Es soll sich der Wertebereich ermitteln lassen. Ein Wertebereich könnte zur sinnvollen Skalierung analoger Werte (z.B. Slider) benutzt werden.		#* Es soll sich der Wertebereich ermitteln lassen. Ein Wertebereich könnte zur sinnvollen Skalierung analoger Werte (z.B. Slider) benutzt werden.
	#* Es soll möglich sein mehrere Sets von Abildungsvorschriften konfigurativ hinterlegen zu können. Damit können unterschiedliche Schnittstellen oder Frontends parallel nutzbar gemacht werden. Unterschiedliche Frontends benötigen z.B. RGB-Werte in unterschiedlichen Formaten auf ggf. auf einen oder mehrere Kanäle abgebildet. -> Widerspricht das nicht dem Standardgedanken? Sollte es nicht eine Weise geben, wie RGB-Werte bereit gestellt werden, und der Kunde sollte diese dann in das eigene Format bringen?		#* Es soll möglich sein mehrere Sets von Abildungsvorschriften konfigurativ hinterlegen zu können. Damit können unterschiedliche Schnittstellen oder Frontends parallel nutzbar gemacht werden. Unterschiedliche Frontends benötigen z.B. RGB-Werte in unterschiedlichen Formaten auf ggf. auf einen oder mehrere Kanäle abgebildet. -> Widerspricht das nicht dem Standardgedanken? Sollte es nicht eine Weise geben, wie RGB-Werte bereit gestellt werden, und der Kunde sollte diese dann in das eigene Format bringen? <- Wenn beide Seiten einer Schnittstelle jeweils ihrem eigenen Standard genügen, dann muss man dazwischen übersetzen.
	# Nichtfunktionale Anforderungen		# Nichtfunktionale Anforderungen
	#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.		#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.

Neubert am 22. November 2014 um 08:18 Uhr

2014-11-22T08:18:40Z

Herrmannj: /* Erste Überlegungen */ Kunden geändert. Der Kunde sollte nach Typ, nicht nach Transportweg (ie ws) Klassifiziert werden

2014-11-21T23:04:37Z

Erste Überlegungen: Kunden geändert. Der Kunde sollte nach Typ, nicht nach Transportweg (ie ws) Klassifiziert werden

← Nächstältere Version		Version vom 22. November 2014, 01:04 Uhr
Zeile 63:		Zeile 63:
	* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.		* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.
	* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").		* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").
	* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB, DBLog, MQTT, ~~websocket (z.B. SmartVisu)~~ sind Kunden.		* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB, DBLog, MQTT, smartVisu, mobile Clients sind Kunden.
	* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.		* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.

Ntruchsess: /* Erste Überlegungen */

2014-11-21T22:51:49Z

Erste Überlegungen

← Nächstältere Version		Version vom 22. November 2014, 00:51 Uhr
Zeile 63:		Zeile 63:
	* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.		* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.
	* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").		* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").
	* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB ~~und~~ DBLog sind Kunden.		* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB, DBLog, MQTT, websocket (z.B. SmartVisu) sind Kunden.
	* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.		* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.

Ntruchsess: /* Zielsetzung */ pro-Argumente für Attribute und Internals

2014-11-21T22:44:58Z

Zielsetzung: pro-Argumente für Attribute und Internals

← Nächstältere Version		Version vom 22. November 2014, 00:44 Uhr
Zeile 25:		Zeile 25:
	Gehören Attribute und Internals wirklich hierher?		Gehören Attribute und Internals wirklich hierher?
	* Internals sind device-intern und normalerweise nicht für Dritte gedacht. Wenn etwas 'öffentlich' und auswertebar sein soll gehört es womöglich in ein Reading oder Attribut.		* Internals sind device-intern und normalerweise nicht für Dritte gedacht. Wenn etwas 'öffentlich' und auswertebar sein soll gehört es womöglich in ein Reading oder Attribut.
			* manche Devices legen aus der Definition abgeleitete Werte in Internals ab. Auch diese sollten externen Schnittstellen einheitlich zugänglich gemacht werden können.
	* Attribute sind für den Endanwender gedacht. Was gibt es hier zu Standardisieren ausser den möglichen Werten?		* Attribute sind für den Endanwender gedacht. Was gibt es hier zu Standardisieren ausser den möglichen Werten?
			* Eine externe Schnittstelle kennt die FHEM-interne Struktur nicht, soll aber ggf. trotzdem vereinheitlichen Zugriff auf die Konfiguration (= die Attribute) bekommen können.

	Frühere Ansätze sind [[DevelopmentInterfaces\|Interfaces]] und [[DevelopmentGuidelines\|Guidelines]] und [https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ diese Diskussion].		Frühere Ansätze sind [[DevelopmentInterfaces\|Interfaces]] und [[DevelopmentGuidelines\|Guidelines]] und [https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ diese Diskussion].

Ntruchsess: /* Anforderungen an das API */ -> Anforderung mehre parallele Konfiguration zu unterstützen hinzugefügt

2014-11-21T22:36:17Z

Anforderungen an das API: -> Anforderung mehre parallele Konfiguration zu unterstützen hinzugefügt

← Nächstältere Version		Version vom 22. November 2014, 00:36 Uhr
Zeile 40:		Zeile 40:
	#* Es soll möglich sein, physikalische Größen in andere Einheitensysteme umrechnen zu können (z.B. K in °C, °C in °F, l im cbm, ...).		#* Es soll möglich sein, physikalische Größen in andere Einheitensysteme umrechnen zu können (z.B. K in °C, °C in °F, l im cbm, ...).
	#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.		#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.
	#* Es wurde die Anforderung genannt, dass sich der Wertebereich ermitteln lassen sollte. Mir ist nicht klar, ob dies für Readings erforderlich ist (es wäre für Settings erforderlich).		#* Es wurde die Anforderung genannt, dass sich der Wertebereich ermitteln lassen sollte. Mir ist nicht klar, ob dies für Readings erforderlich ist (es wäre für Settings erforderlich) -> ein Wertebereich könnte zur sinnvollen Skalierung analoger Werte (z.B. Slider) benutzt werden.
			#* Es soll möglich sein mehre Sets von Abildungsvorschrifen konfigurativ hinterlegen zu können. Damit können unterschiedliche Schnittstellen oder Frontends parallel nutzbar gemacht werden. Unterschiedliche Frontends benötigen z.B. RGB-Werte in unterschiedlichen Formaten auf ggf. auf einen oder mehrere Kanäle abgebildet.
	# Nichtfunktionale Anforderungen		# Nichtfunktionale Anforderungen
	#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.		#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.

Justme: /* Zielsetzung */

2014-11-21T22:05:12Z

Zielsetzung

← Nächstältere Version		Version vom 22. November 2014, 00:05 Uhr
Zeile 22:		Zeile 22:

	Es soll ein API eingeführt werden, das einen bzgl. Syntax und Semantik standardisierten Zugriff auf Readings, Attribute und Internals erlaubt.		Es soll ein API eingeführt werden, das einen bzgl. Syntax und Semantik standardisierten Zugriff auf Readings, Attribute und Internals erlaubt.

			Gehören Attribute und Internals wirklich hierher?
			* Internals sind device-intern und normalerweise nicht für Dritte gedacht. Wenn etwas 'öffentlich' und auswertebar sein soll gehört es womöglich in ein Reading oder Attribut.
			* Attribute sind für den Endanwender gedacht. Was gibt es hier zu Standardisieren ausser den möglichen Werten?

	Frühere Ansätze sind [[DevelopmentInterfaces\|Interfaces]] und [[DevelopmentGuidelines\|Guidelines]] und [https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ diese Diskussion].		Frühere Ansätze sind [[DevelopmentInterfaces\|Interfaces]] und [[DevelopmentGuidelines\|Guidelines]] und [https://groups.google.com/forum/#!searchin/fhem-users/fhem$20standards/fhem-users/fGUMddl2Br0/w99_8GHMxEMJ diese Diskussion].

← Nächstältere Version		Version vom 22. November 2014, 10:18 Uhr
Zeile 36:		Zeile 36:
	#* Es soll möglich sein einen aus den Werten von Readings, Attributen und Internals abgeleiteten Wert abzufragen		#* Es soll möglich sein einen aus den Werten von Readings, Attributen und Internals abgeleiteten Wert abzufragen
	#* die Zugrunde liegenden Werte (Readings, Attribute und Internals) sollen beliebigen Devices zuordenbar sein. Es soll z.B. ermöglicht werden mehrere getrennte Analoge Ausgabedevices zu einem einzigen RGB-Wert zu aggregieren.		#* die Zugrunde liegenden Werte (Readings, Attribute und Internals) sollen beliebigen Devices zuordenbar sein. Es soll z.B. ermöglicht werden mehrere getrennte Analoge Ausgabedevices zu einem einzigen RGB-Wert zu aggregieren.
	#* Sofern die Abbildevorschrift ~~bidirektional eineindeutig~~ ist, soll es möglich sein durch Setzen des abgeleiteten Wertes die zugrunde liegenden Größen zu verändern.		#* Sofern die Abbildevorschrift bijektiv ist, soll es möglich sein durch Setzen des abgeleiteten Wertes die zugrunde liegenden Größen zu verändern. Readings sind per definitionem nur aus dem Gerät selbst heraus und nicht in das Gerät hinein veränderbar. Oder wollen wir zulassen, dass Readings manipuliert werden können? Welchen Anwendungsfall gibt es dafür?
	#* Es soll möglich sein eine Benachrichtigung zu erhalten, wenn sich dieser abgeleitete Wert ändert (ggf. mit Verzicht auf Änderungen von Internals die ja keine Events auslösen).		#* Es soll möglich sein eine Benachrichtigung zu erhalten, wenn sich dieser abgeleitete Wert ändert (ggf. mit Verzicht auf Änderungen von Internals die ja keine Events auslösen).
	#* Es soll sich die Bedeutung eines abgeleiteten Wertes ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).		#* Es soll sich die Bedeutung eines abgeleiteten Wertes ermitteln lassen (Temperatur, Schaltzustand, Länge, Füllmenge, ...).
Zeile 42:		Zeile 42:
	#* Es soll möglich sein, physikalische Größen in andere Einheitensysteme umrechnen zu können (z.B. K in °C, °C in °F, l im cbm, ...).		#* Es soll möglich sein, physikalische Größen in andere Einheitensysteme umrechnen zu können (z.B. K in °C, °C in °F, l im cbm, ...).
	#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.		#* Es sollen Formatierungen unterstützt werden (globaler Default, Default je physikalischer Größe, individuell je Geräteklasse, individuell je Gerät), z.B. Temperaturen grundsätzlich in °C mit einer Nachkommastelle, Uhrzeiten grundsätzlich in 24-Stunden-Notation oder in AM/PM-Schreibweise.
	#* Es ~~wurde die Anforderung genannt, dass~~ sich der Wertebereich ermitteln lassen ~~sollte~~. ~~Mir ist nicht klar, ob dies für Readings erforderlich ist (es wäre für Settings erforderlich) -> ein~~ Wertebereich könnte zur sinnvollen Skalierung analoger Werte (z.B. Slider) benutzt werden.		#* Es soll sich der Wertebereich ermitteln lassen. Ein Wertebereich könnte zur sinnvollen Skalierung analoger Werte (z.B. Slider) benutzt werden.
	#* Es soll möglich sein ~~mehre~~ Sets von ~~Abildungsvorschrifen~~ konfigurativ hinterlegen zu können. Damit können unterschiedliche Schnittstellen oder Frontends parallel nutzbar gemacht werden. Unterschiedliche Frontends benötigen z.B. RGB-Werte in unterschiedlichen Formaten auf ggf. auf einen oder mehrere Kanäle abgebildet.		#* Es soll möglich sein mehrere Sets von Abildungsvorschriften konfigurativ hinterlegen zu können. Damit können unterschiedliche Schnittstellen oder Frontends parallel nutzbar gemacht werden. Unterschiedliche Frontends benötigen z.B. RGB-Werte in unterschiedlichen Formaten auf ggf. auf einen oder mehrere Kanäle abgebildet. -> Widerspricht das nicht dem Standardgedanken? Sollte es nicht eine Weise geben, wie RGB-Werte bereit gestellt werden, und der Kunde sollte diese dann in das eigene Format bringen?
	# Nichtfunktionale Anforderungen		# Nichtfunktionale Anforderungen
	#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.		#* Kein Modul soll das API unterstützen müssen, damit althergebrachte Module ohne Anpassungen weiterfunktionieren.
Zeile 63:		Zeile 63:
	* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.		* Wir brauchen für die Formatierungen einen Speicher für die globalen Defaults und die Geräteklassen- und Geräte- und Readings-spezifischen Überschreibungen.
	* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").		* Die allgemeinen Zugriffsmethoden können in RTypes.pm eingefügt werden. So was wie RUnit($hash, "desired-temp").
			* Wie wäre es, erst die Zugriffsmethoden zu definieren? Z.B. RUnit, RValue, RValue(..., $unit), RType, ...? Das macht es griffig. Ich meine damit, dass die Kunden sagen, was sie brauchen, und wir daraus das API definieren.
	* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB, DBLog, MQTT, smartVisu, mobile Clients sind Kunden.		* Wir müssen darüber nachdenken, welche Kunden das API hat und was es denen nutzen soll. FHEMWEB, DBLog, MQTT, smartVisu, mobile Clients sind Kunden.
	* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.		* Zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.
			* Think big, start small: vermutlich bringen wir nur etwas zu Wege, wenn wir nicht gleich den großen Wurf anstreben, sondern mit einem Aspekt beginnen (de facto Readings) und dabei stets das gesamte Zielbild im Auge halten.