wiki.ziemers.de

ziemer's informatik Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Zuletzt angesehen:
wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-preambel

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung 		Vorhergehende Überarbeitung
wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-preambel [24.11.2020 14:21]
Robert Xaver Halwaß 		wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-preambel [25.11.2020 02:12] (aktuell)
Lukas Danke
Zeile 2: Zeile 2:
  
 ===== Präambel =====  ===== Präambel ===== 
-Neben einigen wünschen der Projektleitung konnte die Projektgruppe eigene Schwerpunkte in die Feature Planung einbringen. Die nachfolgende Feature-Planung ist ein resultat der folgenden Überlegungen+Neben einigen Wünschen der Projektleitung konnte die Projektgruppe eigene Schwerpunkte in die Feature Planung einbringen. Die kommende Feature-Planung ist ein Resultat der folgenden Überlegungen
  
 ==== Content First ==== ==== Content First ====
-Der BHT-Bot besteht bisher aus lediglich zwei Services, die Content zur Verfügung stellen: Mensa- und Wetter-Service. Aufgrund der Covid19-Pandemie findet keine Präsenzveranstaltungen an der Hochschule statt und in Folge dessen hat die Mensa geschlossen, der Bot-Service ist entsprechend auch eingestellt. Defakto kann der BHT-Bot damit derzeit ausschließlich das Wetter ansagen. Für uns ist es daher umso wichtiger dieses Semester neuen Content zu erzeugen bzw. nutzbare Features in den BHT-Bot zu integrieren, damit dieses Projekt überhaupt eine Daseinsberechtigung bekommt. +Der BHT-Bot besteht bisher aus lediglich zwei Services, die Content zur Verfügung stellen: Mensa- und Wetter-Service. Aufgrund der Covid19-Pandemie finden keine Präsenzveranstaltungen an der Hochschule statt und in Folge dessen hat die Mensa geschlossen, der Bot-Service ist entsprechend auch eingestellt. Defakto kann der BHT-Bot damit derzeit ausschließlich das Wetter ansagen. Für uns ist es daher umso wichtiger dieses Semester neuen Content zu erzeugen bzw. nutzbare Features in den BHT-Bot zu integrieren, damit dieses Projekt überhaupt eine Daseinsberechtigung bekommt. 
  
 ==== Hands-On & Dokumentation ==== ==== Hands-On & Dokumentation ====
-Wenn man neu in ein Projekt kommt gibt es viel Dokumentation aufzuarbeiten, als auch undokumentierte Zustände zu entdecken. Wir hatten Gelegenheit den BHT-Bot in einem Hands-On Workshop von Lukas Dankwerth aus SoSe2020 zu bekommen. Im Workshop haben wir uns beispielsweise angeschaut a) Warum der Bot eine Telegram-ID braucht in allen Requests b) Dass der Bot derzeit zwei fast identische Datenbankservices hat, die zusammengeführt werden könnten c) Dass die Services derzeit inkonsistenzen aufweisen, die bis zu essentiellen Debugging-Strategien wie der Request-History reichen, die nicht gepflegt wurde d) Dass Dokumentation auf verschiedene Projekte und Plattformen verteilt wurde.+Wenn man neu in ein Projekt kommt gibt es viel Dokumentation aufzuarbeiten, als auch undokumentierte Zustände zu entdecken. Wir hatten Gelegenheit den BHT-Bot in einem Hands-On Workshop von Lukas Dankwerth aus SoSe2020 vorgestellt zu bekommen. Im Workshop haben wir uns neben all dem Guten, was die letzten Semester geschaffen haben (danke vor allem für die docker-compose zentralisierung der infrastruktur!) beispielsweise angeschaut a) Warum der Bot eine Telegram-ID braucht in allen Requests b) Dass der Bot derzeit zwei fast identische Datenbankservices hat, die zusammengeführt werden könnten c) Dass die Services derzeit inkonsistenzen aufweisen, die bis zu essentiellen Debugging-Strategien wie der Request-History reichen, die nicht gepflegt wurde d) Dass Dokumentation auf verschiedene Projekte und Plattformen verteilt wurde.
  
 Ohne einen persönliche Hands-On-Workshop ist eins der größten Probleme um ins Projekt zu finden, dass es verschiedene Stellen gibt, an denen Dokumentation, Code, Infrastruktur, etc. verteilt ist, aber keine zentrale Stelle, die als "Single Point of truth" registerartig auf die weiteren Quellen verweist. Ohne einen persönliche Hands-On-Workshop ist eins der größten Probleme um ins Projekt zu finden, dass es verschiedene Stellen gibt, an denen Dokumentation, Code, Infrastruktur, etc. verteilt ist, aber keine zentrale Stelle, die als "Single Point of truth" registerartig auf die weiteren Quellen verweist.
Zeile 16: Zeile 16:
 ==== Redundanter Code / Wartbarkeit der Microservices ==== ==== Redundanter Code / Wartbarkeit der Microservices ====
 Beim Studium der einzelnen Services wurde sichtbar, dass fast ausnahmslos jeder Service des BHT-Bot die gleiche Grundstruktur hat: Alle Services stellen eine JSON-REST-Schnittstelle zur Verfügung, die via NodeJS + Express Framework implementiert ist. Vergleicht man die Services, sieht man, dass insbesondere Services, die Inhalte ausspielen sollen einer identischen Struktur folgen (müssen), dies aber individuell handhaben. Dadurch ist der Boilerplate Code für jeden Service unnötig hoch und zugleich ist das Warten der Services bei Änderung von globalen Schnittstellen mit hohem individuellen Aufwand verbunden. Wir wollen diese Common-Funktionalitäten identifizieren und in zentralen Bibliotheken bzw. Frameworks bündeln. Beim Studium der einzelnen Services wurde sichtbar, dass fast ausnahmslos jeder Service des BHT-Bot die gleiche Grundstruktur hat: Alle Services stellen eine JSON-REST-Schnittstelle zur Verfügung, die via NodeJS + Express Framework implementiert ist. Vergleicht man die Services, sieht man, dass insbesondere Services, die Inhalte ausspielen sollen einer identischen Struktur folgen (müssen), dies aber individuell handhaben. Dadurch ist der Boilerplate Code für jeden Service unnötig hoch und zugleich ist das Warten der Services bei Änderung von globalen Schnittstellen mit hohem individuellen Aufwand verbunden. Wir wollen diese Common-Funktionalitäten identifizieren und in zentralen Bibliotheken bzw. Frameworks bündeln.
 +
 +Bei allem was wir tun und Planen gilt die alte Pfadfinder-Regel: "Hinterlasse das Camp immer aufgeräumter, als du es vorgefunden hast". Das beinhalte tbeispielsweise auch die Wartung bzw. Updates von bestehenden Dependencies wie express-js oder Rasa-NLP.
  
 ==== Qualitätsmanagement ==== ==== Qualitätsmanagement ====
Zeile 28: Zeile 30:
  
 {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-tabelle}} {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-tabelle}}
 +
 +{{ :wiki:software:beuthbot:berichte:ws2020:zwischen:gantt_final.png |}}
  
 ===== Architektur ===== ===== Architektur =====
Zeile 33: Zeile 37:
  
 Dies bedeutet für den BHT-Bot: Dies bedeutet für den BHT-Bot:
- - Alle Features werden als Microservice-Architektur konzipiert +  * Alle Features werden als Microservice-Architektur konzipiert 
- - Microservices werden via Docker Container betrieben +  * Microservices werden via Docker Container betrieben 
- - Docker Container werden via docker-compose orchestriert +  * Docker Container werden via docker-compose orchestriert 
- - Microservices kommunizieren via REST-Schnittstellen innerhalb des Docker-Network +  * Microservices kommunizieren via REST-Schnittstellen innerhalb des Docker-Network 
- - Services werden in Javascript geschrieben +  * Services werden in Javascript geschrieben 
- - Libraries und Frameworks werden in Typescript geschrieben+  * Libraries und Frameworks werden in Typescript geschrieben
 {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-diagramm}} {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-diagramm}}
 <pagebreak> <pagebreak>
 ===== Aufgaben Spezifikation ===== ===== Aufgaben Spezifikation =====
 {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-features}} {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:geplanter-stand-features}}
wiki/software/beuthbot/berichte/ws2020/zwischen/geplanter-stand-preambel.1606224061.txt.gz · Zuletzt geändert: 24.11.2020 14:21 von Robert Xaver Halwaß

Seiten-Werkzeuge