Sportics Technologien

Alles nur eine Frage der Kennzahlen

sportics — Mon, 08 Feb 2010 21:57:57 +0000

Genau genommen ist der Sport eine Ansammlung von gemessenen, geschätzten oder berechneten Werten. Eigentlich also nichts anderes wie Unternehmensbilanzen, Börsenkurse, Wahlbarometer oder große Blutbilder. Also haben wir es im Kern auf Kennzahlen und ihre Werte reduziert. Sportics 2.0 basiert bei der Abbildung von Sportarten und den dort geplanten oder erzielten Leistungen also schlicht auf Kennzahlen. Ist das wirklich so einfach? Konzeptionell ja, aber in der Umsetzung muss man dann doch ein paar Sachen bedenken. Es gibt diese feinen Unterschiede. Will man hier mittelfristig Aufwand sparen, muss man am Anfang ein wenig mehr Zeit in die Grundlagen investieren. Manager mit 5-Jahresverträgen machen so etwas sicher ungern oder gar nicht, weil der ROI sich erst nach der eigenen Legislaturperiode entsprechend positiv darstellt. Nutzer und Kunden sind auch immer ein wenig ungehalten, weil es hier und da in Teilbereichen doch schon was gibt, was auf den ersten Blick besser aussieht und mehr bietet. Das stimmt. Dinosaurier waren auch cool. Nun sind sie nicht mehr da.

Für Sportics haben wir ein Konzept aufgebaut, dass Sportarten konfigurativ abbildet. Aber nicht nur Sport, sondern auch Leistungsdiagnostik oder die Umgebung, in der man Sport treibt. Das sorgt für Verwirrung im Team, aber nur so lange, bis die Gehirnbahnen sich neu sortiert und stabilisiert haben.

Betrachtet man nur das Ergebnis (manch einer bezeichnet das ja als den Nabel der Welt) einer sportlichen Leistung ist es trivial. Aber wenn man nun auch noch die Leistungsdaten haben möchte, die so während des Sports gemessen werden, wird es zunehmend komplizierter. Ein Ergometer beispielsweise pustet alle 100ms gemessene Werte raus. Ein iPhone alle 3 Sekunden etwas brauchbares. Wenn man dann noch bedenkt, dass es 24 Läufer gibt oder den modernen Fünfkampf, dann wird es ein wenig tricky. Alle sollen ja schliesslich ein Recht auf ein Sporttagebuch haben – egal ob mit Sportcomputer oder konventionell per Hand geführt.

Na und dann kommen da nicht nur die unterschiedlichen metrischen Systeme hinzu, sondern auch die unterschiedlichen Maßeinheiten. Ein Läufer misst sein Tempo gerne in min/km. Ein Ruderer tut dies in min/500m. Das macht es nicht einfacher.

Aber letztendlich lässt sich der ganze Kram auf Kennzahlen und ihre Werte reduzieren. Dann speichert man den Kram auf Basis von SI-Einheiten und präsentiert die Werte so wie es der Sportler in der Sportart und in seinem Einheitensystem erwartet. Das ist alles..

Sport ist komplex

4048fk — Wed, 23 Dec 2009 21:46:21 +0000

Schuhe an und los. Diese Einfachheit hatte einen Charme, dem ich nicht widerstehen konnte als ich 2001 mit dem Laufen begonnen habe. Eine Sportart, die man in fast jeder Lebenssituation und an jedem Ort machen kann. Es gibt kaum Ausreden, die den inneren Schweinehund maskieren können. Aber natürlich wachsen auch hier die Ansprüche. Das bleibt fast gar nicht aus. Die Jogginghose ist irgendwie doof. Das Schlabbershirt stört, sobald du mehr als 10 Minuten ohne Gehpause durchlaufen kannst. Und wenn du dir dann noch die Expertenmeinungen zum Thema Laufschuhe reinziehst, dann wird’s zunehmend variantenreicher. Jeder schwört auf sein Equipment, seine Sportphilosophie und Salben. Der eine dehnt vorher, der andere hinterher, dem dritten ist das Gedehne viel zu schwuchtelig und der vierte dehnt sogar im Laufen. Nun nimmt man das, was im Mikrokosmos „Laufen“ schon zu einer gewissen Komplexität führt und überträgt das auf all die andern wunderbaren, wundersamen, einfachen und komplizierten Sportarten. Dann wird’s richtig komplex.

Da wäre es dann naiv zu glauben, dass diese fachliche Komplexität mal eben schnell technisch abgebildet werden kann, um alle glücklich zu machen. Egal ob „dirty hack“ oder „sauber konstruiert“. Das technische Modell ist entweder am Anfang schon recht mächtig oder es degeneriert dahin. Das ist eines der vielen Probleme in der Konstruktion komplexer Systeme. Aber nun: Einfach kann ja jeder…

Modell orientiert, nicht Modell getrieben

Bei der Entwicklung von Sportics reden wir einmal von der alten und einmal von der neuen Welt. Die alte Welt ist das, was derzeit größtenteils sichtbar da ist. Einfach angefangen und immer wieder was dran geschraubt. Das war das Vorgehen. Das musste es sein aufgrund vieler Constraints, denen wir uns zu fügen hatten. Aber es bringt einem etwas wertvolles, etwas sehr wertvolles. Etwas, dass dir kein Studium, kein Wikipedia, kein Buch und kein altkluger Besserwisser geben kann: Erfahrung. Die haben wir also genommen, um die neue Sportics Welt aufzubauen. Für die neue Sportics Welt arbeiten wir deutlich stärker Modell orientiert. Ich persönlich bin ein großer Freund der Modell getriebenen Entwicklung. Genau genommen ist diese ja schon existent. Der Quellcode, egal ob Java, C#, Scala, Groovy, Brainfuck, Assembler oder Porolog ist nur ein Modell, wenngleich ein sehr formales. Aber die Vision der automatischen Modelltransformationen auf Basis von SysML, UML und Co ist eben noch eine Vision oder nur in Form einer festen Verdrahtung mit einem Hersteller und seinem Werkzeug möglich. Aber dennoch ist der Grundgedanke mehr als wertvoll: Spezifizier und entwickele dein System, indem du mit Modellen arbeitest, die du immer weiter verfeinerst und kontinuierlich referenzierst. Die normale Sprache alleine ist ungeeignet für diese Dinge. Dabei ist es völlig egal, ob du den Text in ein Wiki eintippst, als Word oder PDF Dokument schreibst, dich mit DocBook abmühst oder wohlformulierte TeX Kommandos verwendest.

Der Sportler und sein Sport

Der Sportler uns sein Sport bilden natürlich das Zentrum von Sportics und damit auch zentrale Entities im Sportis Domänenmodell. Die folgende Abbildung zeigt einen Ausschnitt des Sportics Domänenmodells. Der Sportler (Ahtlet) und die Sporteinheit (SportUnit), die Aktivität, bilden dabei zentralen Elemente.

Auszug des Domänenmodells rund um den Sportler

Das Kennzahlen Prinzip

Die Sporttagebücher basieren auf einem Kennzahlen Konzept. Alles, was „irgendwie“ zahlenmässig im Sport gemessen, geschätzt oder berechnet werden kann, wird als Kennzahl definiert. Die Ausprägung einer Kennzahl wiederum ist abhängig von der Sportart, die sich für dies Kennzahl interessiert. Ein schönes Beispiel ist das Tempo. Das Tempo interessiert den Läufer als min/km (oder auch übertragen auf ein anderes metrisches System). Den Ruderer interessiert dieser Wert aber lediglich in der Ausprägung min/500m. Davon gibt es noch unzählige andere Beispiele. Wir haben diese Anforderungen über ein hoch flexibles Kennzahlensystem abgedeckt, um hier technisch gut aufgestellt zu sein. Im Review merkt man dann „Und wie bilden wir die Mukkibude ab?“. Tzja, wieder ein neues Problem, was gelöst werden muss, ohne das Konzept zu zerbrechen. Aber auch das konnten wir lösen in der „neuen Sportics Welt“

Es muss nicht immer XML sein

skohlmann — Mon, 23 Nov 2009 19:51:59 +0000

In Beispielen für Datenübertragungen findet sich häufig eine Serialisierung der Daten in eine XML Applikation. Dieser Eintrag soll zeigen, dass XML nicht immer die erste Wahl sein muss. Es soll das Bewusstsein erweitern nicht immer das Erstbeste zu verwenden, was einem in den Sinn kommt.

Für das Sportics Realtime Telemetry API wurde bewusst auf XML verzichtet. Der Grund: Realtime Telemetry Clients arbeiten auf reduzierter Hardware wie z.B. Mobiltelefonen und haben eine instabile Funkanbindung des Netzwerkes (z.B. Sportics J2ME Applikation). In solchen Umgebungen ist XML nicht die erste Wahl. Die Daten werden nicht kompakt genug repräsentiert.

Ein Realtime Telemetry Datensatz besteht aus einer Menge von Messwerten zu einem bestimmten Zeitpunkt. Ein Messwert hat immer auch eine beschreibende Kennung. Mehrere solcher Datensätze werden zu einem Snap zusammengeführt. Ein Realtime Telemetry Client schickt einen solchen Snap z.B. alle 2 Minuten an den Realtime Telemetry Server.

In XML kann ein solcher Datensatz wie folgt dargestellt werden:

Es fällt auf, dass ein solches Format sehr viel redundanten Overhead produziert. Dieser kann durch kürzere Namen reduziert werden. Dabei geht allerdings die sprachliche Wiedererkennung verloren.

Kompakter, aber auch schwieriger zu lesen. Es ist im Übrigen ein Irrglaube, dass das JSON Format kompakter ist. In der obigen Notation ist es grösser.

Eine weitere Möglichkeit der Reduktion ist auf allgemeine Namen für XML Elemente zu verzichten. An deren Stelle wird der Wert des t-Attributes verwendet:

Ein ungewöhnliche Schreibweise, aber durchaus machbar. Bei diesem Aufbau wird ein entsprechendes JSON Dokument im Übrigen kleiner als sein XML Pendant. Hierzu folgt weiter unten eine Grafik aus realen Messwerten.

Es geht noch kompakter. Bei Sportics haben wir uns bei dem Realtime Telemetry API gegen SOAP Webservices entscheiden. Der Grund ist einfach: nicht alle Zielgeräte verfügen über SOAP Webservices Support. SOAP Webservices von Hand nachzuprogrammieren ist keine Kleinigkeit. Stattdessen haben wir uns für ein REST API entschieden. Dies vereinfachte die Kommunikationsschnittstelle und auch den Aufwand für die Implementierung auf Clientseite. Zwar wird auch in der REST Literatur viel mit JSON und XML gearbeitet, aber dies muss nicht sein.

Bei den Messwerten setzen wir statt dessen auf das CSV-Format nach RFC 4180. Im CSV-Format wird der oben beschriebene Datensatz wie folgt notiert:

    tme,lon,hrt
    123456789,12.5675256,78
    123457813,12.5675456,79

Noch kompakter ist kaum möglich. Das API schreibt noch einige Dinge vor, beispielsweise muss ein Header vorhanden sein und jede Zeile nach der Headerzeile muss so viele Spalten haben wie die Headerzeile. Ansonsten verwirft der Server die Daten und liefert eine Fehlermeldung.

Die abschliessende Frage lautet: Um wieviel kleiner ist die CSV-Notation?

Aus den realen Daten von einigen tausend Datensätzen lässt sich folgendes Bild genenüber der CSV Notation ermitteln:

die XML Notation ist um ca. den Faktor 2 grösser
die JSON Notation ist um den Faktor 1,5 grösser

In absoluten Zahlen:

CSV	XML	JSON
2.791.662	5.831.791	4.361.462

Ein Bild beschreibt mehr als 500 Worte:

Eine immanente Eigenschaft der IT

4048fk — Thu, 19 Nov 2009 05:05:56 +0000

Klick auf’s Bild zur Vergrößerung

Da hoffen wir doch mal, dass diese Erkenntnis und die daraus resultierenden Erfahrungen Sportics zu Gute kommen.

Der Dritte im Bunde

sportics — Wed, 18 Nov 2009 08:07:09 +0000

Mit dem Sportics Technologie Blog haben wir den dritten (und vermutlich letzten) Sportics Blog in’s Leben gerufen. Die technologischen Dinge hinter Sportics interessieren sicher nur einen Teil der Sportics Nutzer. Wie groß der Anteil ist? Keine Ahnung! In jedem Fall ist es jedoch sinnvoll das, was wir zum Thema „Engineering“ hier und da mal loswerden wollen in einem gesonderten Blog abzulegen. Dieser Blog geht also weniger auf das „Was“, sondern mehr auf das „Wie“ und das „Womit“ ein.