add german version for some docs

Author: marco.mueller

_sftbuildguides/deguide.md _sftbuildguides/guide_de.md_sftbuildguides/deguide.md renamed to _sftbuildguides/guide_de.md

@@ -25,4 +25,6 @@ Für die optionale LED-Anzeige:
 
 Für die optionale Soundausgabe:
 * Mikrocontroller (kann der gleiche sein wie für die LED-Anzeige)
-* kleiner Lautsprecher
+* kleiner Lautsprecher
+
+<img src="/assets/images/impressions_from_working_on_sft/hardware_components.png" alt="drawing" width="500"/>

_sftbuildguides/guide_en.md

@@ -0,0 +1,4 @@
+---
+title: 'Guide ENG'
+---
+work in progress

_sftcomponents/0_project_structure_de.md

@@ -0,0 +1,58 @@
+---
+title: 'Projektstruktur DE'
+---
+
+Worum geht es beim Smart Football Table?
+
+## Vision
+
+Die Idee wurde beim Tischkicker spielen geboren: Wäre es nicht cool, wenn ein Computer die Tore erkennt und nicht man selbst den Spielstand händisch anpassen müsste?
+Erste Überlegungen führten schliesslich zu konkreten Plänen und ersten Versuchen mit einer eigenen Webcam. 
+
+Perspektivisch gesehen ist eine Lösung, die sich die Analysen merkt, spielerbezogen auswerten kann und für
+einen Nichtentwickler ohne Probleme oder Kosten aufbaubar sind unser nächstes Wunschergebnis.
+
+## Vorgaben und Ziele
+
+Von Beginn an haben wir uns auf folgende Vorgaben geeinigt:
+
+* Das Projekt ist Open Source und transparent
+* keine modifizierenden oder spielgefühl-verändernde Eingriffe in den Kickertisch
+* Modell des Kickers soll egal sein
+* Die Kosten aller Anschaffungen sind niedrig zu halten
+* Ein Nachbau ist einfach
+
+Nicht alle Punkte können wir aktuell vollumfänglich einhalten.
+Der Nachbau ist aufgrund nicht vollständiger Skripte und einem fehlenden einfachen Startbutton aktuell ohne technisches Knowhow und etwas Geduld nicht machbar.
+
+Während der Arbeit am Projekt wurden regelmässig neue MVPs erarbeitet.
+Zu Beginn sollte nur ein Ball erkannt werden, die erste Kamerabefestigung war ein simpler Holzrahmen.
+Nach und nach haben wir aber festgehalten, was in einem ersten vorzeigbaren Stand vorhanden sein sollte:
+
+* Ballerkennung mit Kamera
+* Erkennung von Toren
+* Berechnung der Ballgeschwindigkeit
+* aufbereitete Darstellung in Web-Oberfläche
+* Visuelles Signal durch angesteuerten LED-Streifen
+* Soundausgabe
+
+Diesen Stand haben wir, natürlich mit unterschiedlicher Perfektion und Finalisierung, mittlerweile erreichen können und
+das Projekt auf einer Produktmesse aufbauen und vorzeigen können.
+
+<img src="/assets/images/impressions_from_working_on_sft/sft_messe.jpg" alt="drawing" width="200"/>
+
+## Team
+
+Wir sind drei Personen, was sich als angenehme Teamgrösse herausgestellt hat.
+Jede Person bringt ihre eigenen Kernkompetenzen mit, sodass wir, neben einem bereits vorhandenen Wissen über Agilität und
+Software Engineering auch jeden Bereich im Projekt (Frontend, Backend) gut abdecken können.
+
+## Zeitrahmen
+
+Da es sich komplett um ein privates Projekt handelt, gibt es zwar leider kein Budget, aber auch keinen Zeitrahmen.
+Wir arbeiten daran, weil es Spass macht und sind deshalb auch nicht in regelmässiger Form an der Entwicklung.
+
+## Aktueller Stand
+
+Der aktuelle Stand kann im GitHub-Repository und den hier folgendenen Dokumenten nachvollzogen werden. Kurzgesagt sind wir mit den oben gelisteten Punkten zwar nicht
+komplett fertig, der aktuell vorhandene Stand kann aber diese Punkte abdecken.

_sftcomponents/0_project_structure_en.md

@@ -0,0 +1,5 @@
+---
+title: 'Project Structure ENG (wip)'
+---
+
+work in progress 

_sftcomponents/1_architecture_de.md

@@ -0,0 +1,58 @@
+---
+title: 'Architektur DE'
+---
+
+Eine Übersicht über die verschiedenen Bestandteile, die SFT ausmachen.
+
+## Übersicht
+
+Das folgende Architekturbild zeigt eine Übersicht über die Bestandteile des SFT-Projekts:
+
+![architecture](/modules/smart-football-table/architecture/SmartFootballTable_Architecture.png){:class="img-responsive"}
+
+Eine schlanke Architektur mit wenigen "Point of Failures" war von Beginn an das Ziel des Projekts.
+Es gibt keinen Grund, dies bei der kleinen Anzahl an Services anders zu lösen.
+
+Das Herzstück stellt der MQTT-Broker da. Jeder Service kommuniziert über MQTT.
+Damit stellt der Broker auch das kritischste ELement dar; fällt er aus, funktioniert die Anwendung nicht mehr.
+Um den Broker finden sich dann die Services mit ihrer dedizierten Aufgabe, sei es das Kameramodul, welches sich um die Ballerkennung kümmert oder die Soundausgabe.
+
+Auf diese Weise können auf simple Art und Weise weitere Services angebunden (oder auch entfernt) werden. Solange sie mit MQTT kommunizieren können ist eine Anbindung problemfrei möglich.
+
+## Komponenten
+
+Insgesamt sind zurzeit folgende Komponenten teil von SFT:
+
+* MQTT-Broker
+* Ball-Erkennung (Kamera + OpenCV, in Python) -> [GitHub-Link](https://github.com/smart-football-table/smart-football-table-detection)
+* Analyse der erkannten Ballpositionen (in Java) -> [GitHub-Link](https://github.com/smart-football-table/smart-football-table-cognition)
+* simple UI für die Anzeige der Analyse (in Angular) -> [GitHub-Link](https://github.com/smart-football-table/smart-football-table-ui)
+* ein kleiner Service zur Soundausgabe (in Bash gelöst) -> [GitHub-Link](https://github.com/smart-football-table/smart-football-table-sound)
+* Steuerung der LED-Leiste (in Java mit Microcontroller) -> [GitHub-Link](https://github.com/smart-football-table/smart-football-table-ledcontrol)
+
+## Containerisierung mit Docker
+
+Jeder Service läuft in einem Docker-Container (mit Ausnahme von der Ball-Erkennung in Python, da aktuell die Freigabe des Videos nach aussen noch nicht funktioniert).
+Mithilfe einer übergreifenden docker-compose-Konfiguration kann die Anwendung auf diese Weise systemunabhängig schnell und einfach hochgefahren werden.
+
+## Submodule in Git
+
+Ein zentrales Repository, welches die Services als Submodule hinterlegt, vereinfacht das Sicherstellen einer lauffähigen Anwendung.
+Die Subdmodule sind dabei auf einen bestimmten Commit verlinkt, um einen gleichen Stand sicherzustellen.
+
+## Gründe sowie Vor- und Nachteile dieser Architektur
+
+Der Schnitt der Services auf die oben beschriebene Art und Weise basiert auf einigen Annahmen, welche wir getroffen haben:
+
+* Module sollen unabhängig voneinander entwickelt werden können, ebenso unabhängig voneinander auch refactored werden.
+* Dabei hilft Entkopplung: Unabhängig voneinander arbeiten zu können war eine Grundlage für die getroffenen Architekturentscheidungen. Dafür bedarf es nicht zwangsweise Microservices.
+* Quereffekte in hoher Zahl wie beispielsweise das Wegbrechen von Modulen sollen selten auftreten können. Noch wichtiger: Ein Teilausfall soll keinen Komplettausfall nach sich ziehen (mit genannter Ausnahme des Brokers. Bei einem Totalausfall kann aber fast immer beim Broker nachgesehen werden und das Problem ist gefunden).
+
+## Technologieauswahl
+
+Eine Frage, die aufkommen kann, ist: Warum wurden für die verschiedenen Module so viele verschiedene Technologien gewählt?
+Auch wenn es eine valide Option ist, einfach eine Sprache wie Java zu wählen, haben wir uns an folgenden Gedanken gehalten:
+
+*Welches Werkzeug passt zu meinem Problem bzw. zu meinem Team und dessen Fähigkeiten?*
+
+Die erhöhte Komplexität durch verschiedene Werkzeuge wird in unseren Augen erfolgreich kompensiert durch die bessere Anpassungsfähigkeit der Werkzeuge an das Problem. Sofern im Team mit den gewählten Technologien umgegangen werden kann gibt es keinen Grund, sich durch eine Standardisierung einzuschränken.

_sftcomponents/architecture.md _sftcomponents/1_architecture_en.md_sftcomponents/architecture.md renamed to _sftcomponents/1_architecture_en.md

@@ -1,7 +1,8 @@
 ---
-title: 'Architecture'
+title: 'Architecture ENG (wip)'
 ---
 
+(work in progress)
 The system behind SFT became large really fast. Rethinking the architecture happens way more often than thought. This post explains the actual solution.
 
 ## Overview

_sftcomponents/2_mqtt_de.md

@@ -0,0 +1,9 @@
+---
+title: 'MQTT DE'
+---
+
+Bla
+
+## Bla
+
+Bla Bla

_sftcomponents/mqtt.md _sftcomponents/2_mqtt_en.md_sftcomponents/mqtt.md renamed to _sftcomponents/2_mqtt_en.md

@@ -1,5 +1,5 @@
 ---
-title: 'MQTT'
+title: 'MQTT ENG (wip)'
 ---
 
 Find out about the reason for MQTT and the different messages used.
@@ -10,6 +10,11 @@ For communication between different parts in the system MQTT is used. As seen in
 the system publishes/subscibes to a broker. With this setup, messages in different topics can trigger different
 reactions. For example, this is used to inform the UI about a new score.
 
+Handy controls
+
+Schwierigkeit: was ist mit den vereinbarten Contracts? MQTT-Topics können nicht einfach ausgetauscht werden, ohne nicht alle zu benachrichtigen, die Zuhören. Aber: Woher weiß ich überhaupt, wer alles auf das Topic lauscht?
+--> Kommunikation wird entgegen üblicher Annahmen noch viel wichtiger, wenn so wie hier entkoppelt wird
+
 ## MQTT messages
 
 | topic                      | Description                                               | Example payload          | Comment    |

_sftcomponents/3_ball_detection_de.md

@@ -0,0 +1,13 @@
+---
+title: 'Ballerkennung DE'
+---
+
+Bla
+
+## Bla
+
+Bla Bla
+
+<img src="/assets/images/impressions_from_working_on_sft/camera_holder.jpg" alt="drawing" width="200"/>
+
+<img src="/assets/images/impressions_from_working_on_sft/camera_holder_attached.jpg" alt="drawing" width="200"/>

_sftcomponents/ball-detection.md _sftcomponents/3_ball_detection_en.md_sftcomponents/ball-detection.md renamed to _sftcomponents/3_ball_detection_en.md

@@ -1,5 +1,5 @@
 ---
-title: 'Ball Detection'
+title: 'Ball Detection ENG (wip)'
 ---
 
 ## Smart Football Table - Detection