Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
wiki:software:beuthbot:berichte:ws2020:zwischen [19.11.2020 12:05] Alexis Popovski [Tools] |
wiki:software:beuthbot:berichte:ws2020:zwischen [23.11.2020 14:34] (aktuell) Robert Xaver Halwaß |
||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
====== Zwischenbericht WS2020/21 ====== | ====== Zwischenbericht WS2020/21 ====== | ||
- | + | <pagebreak> | |
- | ====BeuthBot Project Group==== | + | {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:projektgruppe}} |
- | + | < | |
- | * Lukas Danke | + | {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:einleitung}} |
- | * Robert Halwaß | + | < |
- | * Rim Khreis | + | {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:tools}} |
- | * Alexis Popovski | + | < |
- | * Dennis Walz | + | {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:organisation}} |
- | + | <pagebreak> | |
- | ==== Gliederung ==== | + | {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:vorgefundener-stand}} |
- | + | < | |
- | * Einleitung | + | {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:probleme}} |
- | * Tools | + | <pagebreak> |
- | * Organisation | + | {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen: |
- | * Vorgefundener Stand | + | < |
- | * Aktueller Stand | + | {{page>:wiki:software:beuthbot:berichte:ws2020:zwischen:aktueller-stand}} |
- | * Bisher aufgetretene Probleme | + | |
- | * Geplante Aufgaben | + | |
- | + | ||
- | + | ||
- | ==== Einleitung ==== | + | |
- | Chatbots sind ein logisches Produkt der heutigen Automatisierungsära. Sie können theoretisch für fast jedes Unternehmen nützlich sein, da ein erheblicher Teil von Benutzeranfragen ähnlich sind und wiederholt gestellt werden. Mit der schnellen Entwicklung des maschinellen Lernens, stellen Chatbots ein relevantes und aktuelles Thema dar, welches immer beliebter und nachgefragter wird. Weshalb also nicht auch ein Chatbot der Beuth Hochschule für Technik Berlin? Entwickelt von Studenten, für Studenten. Somit können nicht nur die Mitarbeiter des Studierendenservice entlastet, sondern auch kleine bis große Fragen der Studenten schnell beantwortet werden. Ein intelligenter Chatbot, der per Text und Sprache bedient werden kann, mittels künstlicher Intelligenz antwortet und vielen Features, wie z.B. sich vom Chatbot an wichtige Abgabetermine erinnern zu lassen. | + | |
- | ==== Tools ==== | + | |
- | In diesem Kapitel werden alle Tools aufgelistet und beschrieben, | + | |
- | + | ||
- | === Jitsi === | + | |
- | Jitsi ist ein OpenSource Video-Conferencing-Tool, | + | |
- | + | ||
- | === Telegram === | + | |
- | Telegram ist ein kostenloser, | + | |
- | + | ||
- | === Discord === | + | |
- | Discord ist ebenfalls ein kostenloser Onlinedienst mit Chat-, Sprachkonferenz- und Videokonferenz-Funktion. Das Projektteam nutzt Discord, um sich, nach den wöchentlichen Treffen mit dem Dozenten, nochmal untereinander auszutauschen und auch an anderen Wochentagen zusammenzutun um sich zu organisieren. | + | |
- | + | ||
- | === Jira === | + | |
- | Jira ist eine von Atlassian entwickelte Webanwendung, | + | |
- | + | ||
- | === GitHub === | + | |
- | + | ||
- | GitHub ist ein netzbasierter Dienst zur Versionsverwaltung für Software-Entwicklungsprojekte. Er wird für die Zusammenführung der Arbeitsergebnisse des Projektteams genutzt. | + | |
- | + | ||
- | === Ziemer' | + | |
- | Im Wiki befindet sich eine große Sammlung an Berichten, Dokumentationen und Information zum BeuthBot und die Arbeit der vorherigen Semester an diesem. Diese große Ansammlung dient dem Projektteam zur Einarbeitung in das Projekt bzw. dem BeuthBot, aber auch zur Inspiration, | + | |
- | + | ||
- | + | ||
- | === IDEs === | + | |
- | Im folgenden werden die verschiedensten Entwicklungsumgebungen aufgelistet, | + | |
- | * Visual Studio Code | + | |
- | * WebStorm / PHPStorm (Jetbrains Produkte) | + | |
- | + | ||
- | === Sonstiges === | + | |
- | + | ||
- | == Postman == | + | |
- | Postman ist ein Programm zum Entwickeln, aber auch zum Testen von bereits bestehenden REST API's. Mit diesem Tool kann das Projektteam die Antwort auf ihre Anfragen überprüfen. | + | |
- | + | ||
- | ==== Organisation ==== | + | |
- | Jede Woche (Donnerstag 10:00) findet zwischen den Studierenden und dem Dozenten eine Rücksprache in Form eines Videochats mittels Jitsi statt. | + | |
- | Bei diesem Treffen werden die Ergebnisse der letzten Woche besprochen, mögliche Unklarheiten geklärt und Ziele für die folgende Woche gesetzt. | + | |
- | + | ||
- | Zur allgemeinen Kommunikation außerhalb der wöchentlichen Rücksprachen zwischen Studierenden und Dozent wird Telegram verwendet, um kleinere Fragen zu klären, welche nicht bis zum nächsten Rücksprachetermin warten können. Da der BeuthBot zum Start des Projektes nur Telegram unterstütze, | + | |
- | + | ||
- | Zur privaten Kommunikation unter den Studierenden wird Discord verwendet. Discord bietet den Vorteil, dass sowohl Text-Chat als auch Voice- und Video-Chat möglich ist. Dies bietet viel Flexibilität bei der Kommunikation innerhalb des Teams. Der Server wird privat gehostet, dadurch ist der Datenschutz hier ebenfalls gewährleistet. Viele der Studierenden haben auch bereits Erfahrung bei der Verwendung von Discord, wodurch keine lange Einarbeitungszeit notwendig war. Zusätzlich wurde sich auch dafür entschieden, | + | |
- | + | ||
- | + | ||
- | ==== Vorgefundener Stand ==== | + | |
- | Der Beuthbot besteht aus mehreren ineinandergreifenden Microservices, | + | |
- | * Bot | + | |
- | * Gateway | + | |
- | * Registry | + | |
- | * Services | + | |
- | + | ||
- | === Bot === | + | |
- | Hierbei handelt es sich um eine Abstraktion der verfügbaren Chatbots unterstützter Messaging-Dienste. Der Nutzer interagiert mit diesem Microservice, | + | |
- | + | ||
- | === Gateway === | + | |
- | Das Gateway stellt das Herz des BeuthBots dar. Der Bot informiert das Gateway mit der vom User empfangenen Nachricht, nutzt dann NLP Microservices, | + | |
- | + | ||
- | === Registry === | + | |
- | Nachdem die Absicht des Nutzers analysiert worden ist, informiert das Gateway die Registry, um die Informationen zu erhalten, die der Nutzer benötigt. Darauffolgend verteilt die Registry die Anfrage an den entsprechenden Service. | + | |
- | + | ||
- | === Service === | + | |
- | Die Services liefern die seitens des Nutzers angefragten Daten. So liefert bspw. Der MensaService Informationen zu aktuellen Menüs, welche via diverser Parameter gefiltert warden (etwa nur vegetarische Gerichte). | + | |
- | + | ||
- | === API === | + | |
- | Die Mikroservices kommunizieren untereinander mittels einer API. Sie basiert auf einem Response-Objekt, | + | |
- | + | ||
- | <uml> | + | |
- | @startuml | + | |
- | actor " | + | |
- | rectangle " | + | |
- | package " | + | |
- | rectangle " | + | |
- | rectangle " | + | |
- | database " | + | |
- | package " | + | |
- | rectangle " | + | |
- | rectangle " | + | |
- | } | + | |
- | package " | + | |
- | rectangle " | + | |
- | rectangle " | + | |
- | rectangle " | + | |
- | } | + | |
- | package " | + | |
- | rectangle " | + | |
- | database " | + | |
- | } | + | |
- | } | + | |
- | + | ||
- | U -down-> TGB | + | |
- | + | ||
- | GW -left-> TGB | + | |
- | TGB -right-> GW | + | |
- | + | ||
- | GW -left-> DC | + | |
- | DC -right-> GW | + | |
- | + | ||
- | GW -down-> RE | + | |
- | RE -up-> GW | + | |
- | + | ||
- | DC -right-> RA | + | |
- | RA -left-> DC | + | |
- | + | ||
- | DBC -right-> MDB | + | |
- | MDB -left-> DBC | + | |
- | + | ||
- | GW -left-> DBC | + | |
- | DBC -right-> GW | + | |
- | + | ||
- | RE -left-> CA | + | |
- | CA -right-> RE | + | |
- | + | ||
- | RE -up-> MS | + | |
- | MS -down-> RE | + | |
- | + | ||
- | RE -up-> WS | + | |
- | WS -down-> RE | + | |
- | + | ||
- | RE -up-> DBMS | + | |
- | DBMS -down-> RE | + | |
- | + | ||
- | DBMS -down-> DBC | + | |
- | DBC -up-> DBMS | + | |
- | @enduml | + | |
- | </ | + | |
- | + | ||
- | + | ||
- | ==== Aktueller Stand ==== | + | |
- | + | ||
- | === Der Bot war ständig nicht erreichbar === | + | |
- | Der Bot läuft via docker-compose in einer VM. Immer wenn der Bot nicht erreichbar war, startete er neu sobald sich jemand in die VM einloggte und war dann auch wieder erreichbar. Der Grund dafür war, dass docker-compose so konfiguriert war, dass die Container zwar neu starten sollten, aber nicht sofort wenn sie abstürzten (sondern in diesem fall dann eben beim Login durch einen docker-user). | + | |
- | + | ||
- | Der Lösung bestand entsprechend in der Änderung der Configuration nach „restart-always“. https:// | + | |
- | + | ||
- | === Gateway funktionierte nicht ohne Telegram-ID === | + | |
- | Bei ersten Experimenten ist aufgefallen, | + | |
- | + | ||
- | Durch eine Anpassung des Gateways bei der User-Abfrage wird eine valide Telegram-ID nicht vorausgesetzt. https:// | + | |
- | + | ||
- | === Continous Deployment === | + | |
- | Zuvor musste man um eine neue Version des BeuthBots zu deployen, musste manuell die neuste Version von GitHub gepullt werden und der Docker-compos-Befehl ausgeführt werden. | + | |
- | + | ||
- | Mithilfe eines Selfhosted-Runners welcher auf dem BeuthBot-Server installiert wurde, ist es jetzt möglich diesen Prozess zu automatisieren. Sobald ein Git-Commit mit einem Versions-Tag gepusht wird, wird dies vom Runner erkannt und der Deploy-Prozess wird angestoßen. https:// | + | |
- | + | ||
- | === Text 2 Speech Recherche === | + | |
- | * Say.js | + | |
- | * https:// | + | |
- | * https:// | + | |
- | * Web Speech API | + | |
- | * https:// | + | |
- | * Text2Speech | + | |
- | * https:// | + | |
- | + | ||
- | === Speech 2 Text Recherche === | + | |
- | + | ||
- | == Mozilla Voice STT (DeepSpeech) == | + | |
- | + | ||
- | https:// | + | |
- | https:// | + | |
- | * Opensource | + | |
- | * Offline nutzbar | + | |
- | * Viel Dokumentation | + | |
- | * Deutsches Modell | + | |
- | * WER: 15% | + | |
- | * Zukunft ungewiss | + | |
- | + | ||
- | == Kaldi == | + | |
- | https:// | + | |
- | http:// | + | |
- | * Opensource | + | |
- | * Offline nutzbar | + | |
- | * Deutsche Modelle | + | |
- | * WER: 8,44% | + | |
- | + | ||
- | == Wav2Letter == | + | |
- | https:// | + | |
- | * Opensource | + | |
- | * Offline nutzbar | + | |
- | * Deutsche Modelle | + | |
- | * WER: 4% | + | |
- | + | ||
- | == Espresso == | + | |
- | https:// | + | |
- | * Opensource | + | |
- | * Offline nutzbar | + | |
- | * Kein deutsches Modell | + | |
- | + | ||
- | == Nvidea OpenSeq2Seq == | + | |
- | https:// | + | |
- | * Opensource | + | |
- | * Offline nutzbar | + | |
- | * Kein Deutsches Modell | + | |
- | + | ||
- | == WER Vergleich 2017 == | + | |
- | * Google (8%) | + | |
- | * Microsoft (5.9%) | + | |
- | * IBM (5.5%) | + | |
- | * Apple (5%) | + | |
- | * Baidu (16%) | + | |
- | * Hound (5%) | + | |
- | + | ||
- | Quelle: | + | |
- | https:// | + | |
- | + | ||
- | + | ||
- | ==== Bisher aufgetretene Probleme ==== | + | |
- | === Vorüberlegung: Save-Storage / Moodle Integration=== | + | |
- | + | ||
- | Eine initiale Feature-Idee für dieses Semester war es, dem Bot eine Moodle-Integration zu implementieren, | + | |
- | + | ||
- | ===Problem 1: Login=== | + | |
- | + | ||
- | Damit user-bezogene Daten abgerufen werden können muss der User sich in Moodle via username + passwort einloggen. Dieser Login kann nicht über die Chatbot-Funktionalitäten erfolgen, da Messenger in der Regel keine Passwort-Eingabe ermöglichen, | + | |
- | + | ||
- | Lösung: Es benötigt ein Webformular, | + | |
- | + | ||
- | ===Problem 2: Speicherung des Tokens=== | + | |
- | + | ||
- | Der BeuthBot ist ein Studierenden-Projekt. Es gibt derzeit keinen Production-Server, | + | |
- | + | ||
- | Gefahren: | + | |
- | - Böswilliger Entwickler (programmiert daten-abfluss) | + | |
- | - Gutwilliger Entwickler (macht Programmierfehler) | + | |
- | - Böswilliger Admin (transferiert/ | + | |
- | - Gutwilliger Admin (dupliziert/ | + | |
- | - Böswilliger Nutzer (nutzt sicherheitslücken / programmierfehler) | + | |
- | + | ||
- | ==Lösung 1: Das User-Token wird nur im RAM abgelegt== | + | |
- | Das Token wird so nie auf die Festplatte geschrieben | + | |
- | - [x] Böswilliger Entwickler (programmiert daten-abfluss) | + | |
- | - [✓] Gutwilliger Entwickler (macht Programmierfehler) | + | |
- | - [✓] Böswilliger Admin (transferiert/ | + | |
- | - [✓] Gutwilliger Admin (dupliziert/ | + | |
- | - [✓] Böswilliger Nutzer (nutzt sicherheitslücken / programmierfehler) | + | |
- | + | ||
- | Nachteil Lösung 1: Die Usability leidet stark, wenn der User sich ständig neu einloggen muss, weil der Bot die Credentials beim Neustart vergisst. Vor allem für Erinnerungs-Features ist das ein Showstopper. | + | |
- | + | ||
- | ==Lösung 2: Das User-Token wird nur persistiert, | + | |
- | Die Daten werden beim Speichern mit einem One-Time-Token verschlüsselt. Beim nächsten Start des Dienstes werden die Daten entschlüsselt und die persistente Kopie gelöscht | + | |
- | - [x] Böswilliger Entwickler (programmiert daten-abfluss) | + | |
- | - [✓] Gutwilliger Entwickler (macht Programmierfehler) | + | |
- | - [x] Böswilliger Admin (transferiert/ | + | |
- | - [✓] Gutwilliger Admin (dupliziert/ | + | |
- | - [✓] Böswilliger Nutzer (nutzt sicherheitslücken / programmierfehler) | + | |
- | + | ||
- | Nachteil Lösung 2: Der One-Time-Key muss auch irgendwie gespeichert werden. Da dieser auch für die Anwendung zugänglich sein muss liegt er gewissermaßen neben der verschlüsselten Datei. Ein cleveres One-Time-Verfahren kann hier zwar dafür sorgen, dass fremder Zugriff auf die Daten nicht unbemerkt bleibt - Gerade Backups können auf diese Art ganz gut abgesichert werden indem der Key dort nicht gespeichert wird. Ein echter Schutz der Daten ist aber nicht gegeben, spätestens der böswillige Admin wird einen Weg finden das Verfahren zu manipulieren | + | |
- | + | ||
- | ==Fazit: Wir haben uns gegen eine Speicherung von User-Credentials entschieden, | + | |
- | + | ||
- | + | ||
- | + | ||
- | ==== Geplante Aufgaben ==== | + | |
- | + | ||
- | ^ ID ^ Name ^ Priorität | + | |
- | | 1 | Fix: Gateway funktioniert nicht ohne Telegram-ID | + | |
- | | 2 | Rasa Update auf 2.0 | 1 | 1 | + | |
- | | 3 | Common Definitions und Funktionen für Bot-Messenger-Clients in Library zusammenfassen | + | |
- | | 4 | Discord ChatBot Implementation | + | |
- | | 5 | ErinnerungsFeature Command & Erinnerung | + | |
- | | 6 | ErinnerungsFeature - Scrape Beuth Termine | + | |
- | | 7 | Speech To Text | 2 | 3 | + | |
- | | 8 | Text To Speech | + | |
- | | 9 | ErinnerungsFeature - Scrape Moodle iCal export (https:// | + | |
- | | 10 | Cross Platform Erkennung + Datenbank “telegram_id” zu one:many relation | + | |
- | | 11 | Begrüßungsnachricht in Chatbot-Clients (listen auf erst-kontakt) + Nachricht von Server | + | |
- | | 12 | Website mit Präsentation aller BeuthBot-Resourcen (Wiki, Telegram, Discourse, Github) und Implmentation Chatbot | + | |
- | | 13 | Universelles Scraper & Download | + | |
- | | 14 | Personalliste Gesamtverzeichnis | + | |
- | + | ||
- | + | ||
- | <uml> | + | |
- | @startuml | + | |
- | + | ||
- | actor " | + | |
- | rectangle " | + | |
- | rectangle " | + | |
- | rectangle " | + | |
- | package " | + | |
- | rectangle " | + | |
- | rectangle " | + | |
- | database " | + | |
- | package " | + | |
- | rectangle " | + | |
- | rectangle " | + | |
- | } | + | |
- | package " | + | |
- | rectangle " | + | |
- | rectangle " | + | |
- | rectangle " | + | |
- | } | + | |
- | package " | + | |
- | rectangle " | + | |
- | database " | + | |
- | } | + | |
- | package " | + | |
- | rectangle " | + | |
- | rectangle " | + | |
- | rectangle " | + | |
- | rectangle " | + | |
- | } | + | |
- | + | ||
- | } | + | |
- | + | ||
- | U <-down-> TGB | + | |
- | U < | + | |
- | U <-> WSB | + | |
- | + | ||
- | GW <-> TGB | + | |
- | GW <-> DCB | + | |
- | GW <-> WSB | + | |
- | + | ||
- | GW < | + | |
- | + | ||
- | GW < | + | |
- | + | ||
- | GW < | + | |
- | + | ||
- | GW < | + | |
- | + | ||
- | DC <-> RA | + | |
- | + | ||
- | DBC <-> MDB | + | |
- | + | ||
- | RE <-> CA | + | |
- | + | ||
- | RE <-> MS | + | |
- | + | ||
- | RE <-> WS | + | |
- | + | ||
- | DBMS <-> RE | + | |
- | + | ||
- | DBMS <-> DBC | + | |
- | + | ||
- | SC <-> W2L | + | |
- | SC <-> SJS | + | |
- | W2L <-> W2LM | + | |
- | + | ||
- | @enduml | + | |
- | </ | + | |
- | + | ||
- | | BOT-12: Rasa 2.0 Update | + | |
- | | Um die neusten Funktionen und Fixes von Rasa zu benutzen, ist ein Update von Version 1.6 auf 2.0 notwendig. | + | |
- | | Zustänidigkeit | + | |
- | | Initiale Schätzung | + | |
- | | Programmiersprachen | + | |
- | | Frameworks/ | + | |
- | | Services | + | |
- | | Abhängigkeiten | + | |
- | | Anforderungen | + | |
- | | Tasks | * BOT-124: docker-compose.yml anpassen\\ * BOT-61: Chatito Kompatibiltät testen\\ * BOT-62: Config Anpassen\\ * BOT-63: Duckling updaten\\ * BOT-64: Modell neu trainieren\\ * BOT-116: Performance | + | |
- | + | ||
- | + | ||
- | + | ||
- | | BOT-30: Chatbot Library: Vereinheitlichung der Kommunikation von Javascript Chatbots mit dem Gateway | + | |
- | | Problem: Derzeit muss jede Anwendung, die den BHT-Bot als Chatbot implementieren möchte selbst implementieren, | + | |
- | | Initiale Schätzung | + | |
- | | Technologien | + | |
- | | Abhängigkeiten | + | |
- | | Anforderungen | + | |
- | | Tasks | * BOT-33 Library Usage Dokumentieren \\ * BOT-34 Library in Discord Bot integrieren \\ * BOT-35 Library in Telegram Bot integrieren \\ * BOT-36 Library in Website integrieren \\ * BOT-31 Common Funktionalität / Use Cases identifizieren \\ * BOT-32 Typescript Library für Bot erstellen | + | |
- | + | ||
- | + | ||
- | + | ||
- | | BOT-37: Discord Integration des BHT-Bot | + | |
- | | Discord ist eine weit verbreitete Kommunikatinsplattform, | + | |
- | | Initiale Schätzung | + | |
- | | Technologien | + | |
- | | Abhängigkeiten | + | |
- | | Anforderungen | + | |
- | | Tasks | * BOT-38 NodeJS Chatbot erstellen \\ * BOT-39 Docker Container + Compose für Container erstellen \\ * BOT-40 Bot Usage dokumentieren \\ * BOT-41 Bot Account anlegen für release (https:// | + | |
- | + | ||
- | + | ||
- | | BOT-43: Erstellung eines Common-Frameworks für (Content-)Services | + | |
- | | Services im BHT-Bot kommunizieren alle über REST-Schnittstellen. Diese sind alle als Express-Anwendung mit JSON-Kommunikation implementiert, | + | |
- | | Initiale Schätzung | + | |
- | | Technologien | + | |
- | | Abhängigkeiten | + | |
- | | Anforderungen | + | |
- | | Tasks | * BOT-44 Common Code, Features, Entitäten identifizieren -> Use Case ableiten \\ * BOT-45 Typisiertes Javascript Framework erstellen \\ * BOT-46 Framework einbinden in Weather Service \\ * BOT-47 Framework einbinden in Mensa Service \\ * BOT-48 Framework einbinden in Reminder Service \\ * BOT-108 Framework dokumentieren \\ * BOT-117 Request History implementieren - Nutzung enforcen | + | |
- | + | ||
- | + | ||
- | | BOT-49: User-Messenger-Service: Nachricht proaktiv, requestunabhängig an Clients senden | + | |
- | | Der BHT-Bot kann bisher nur passiv auf Anfragen warten und diese dann beantworten. Zur Implementierung von asymmetrischer bzw. request-unabhängiger Kommunikation benötigt der Bot einen neuen Service, der als Schnittstelle für diese Art von Kommunikation dient. | + | |
- | | Initiale Schätzung | + | |
- | | Technologien | + | |
- | | Abhängigkeiten | + | |
- | | Anforderungen | + | |
- | | Tasks | * BOT-50 Websocket Registry für ChatBotClients \\ * BOT-51 REST-Service für Nachrichtenversand \\ * BOT-52 Implementation der Websocket-Registrierung in Common-Library für Chatbots \\ * BOT-53 Implementierung der Common-Library-Websocket-Registrierung in TelegramBot \\ * BOT-54 Implementierung der Common-Library-Websocket-Registrierung in DiscordBot \\ * BOT-56 Dokumentation Usage Service \\ * BOT-110 Deployment / Release | + | |
- | + | ||
- | + | ||
- | | BOT-55: Erinnerungs-Service: | + | |
- | | Erinnerungen schedulen zu können ist ein typischer, weil praktischer, | + | |
- | | Initiale Schätzung | + | |
- | | Technologien | + | |
- | | Abhängigkeiten | + | |
- | | Anforderungen | + | |
- | | Tasks | * BOT-57 Rasa Anbindung " | + | |
- | + | ||
- | + | ||
- | | BOT-82: Termin-Scraper, | + | |
- | | Es gibt Termine, an die wollen alle Studierenden typischerweise erinnert werden, als auch Termine, von denen die Universität möchte, dass die Studierende sich daran erinnern. Typische Beispiele hierfür sind Rückmeldefristen und (Beuth-eigene) Feiertage. \\ Durch einen Webscraper sollen solche Termine aus (öffentlichen) Quellen automatisch bezogen und dann an alle Studierenden ausgespielt werden. \\ Auch wenn dieses Feature für die meisten Studierenden interesssant sein dürfte, muss es eine Möglichkeit zum Opt-Out geben. Ggf. ist sogar angezeigt, dass ein Opt-In erfolgt, was allerdings den Nutzen des Features, vor allem aus Universitätssicht, | + | |
- | | Initiale Schätzung | + | |
- | | Technologien | + | |
- | | Abhängigkeiten | + | |
- | | Anforderungen | + | |
- | | Tasks | * BOT-83 Prüfen ob Opt-In (nötig ist) oder Opt-Out (möglich ist) \\ * BOT-84 Quellen mit relevanten Terminen zusammentragen - auf Scrapebarkeit achten \\ * BOT-85 Scraping (mittels Scapring-Service) implementieren \\ * BOT-86 Termine aus Scraping in Erinnerungs Datenbank überführen \\ * BOT-87 Rasa Direktive Opt-In oder Opt-Out implementieren \\ * BOT-88 Error-Reporting implementieren, | + | |
- | + | ||
- | + | ||
- | | BOT-89: Moodle iCal import als Erinnerungen | + | |
- | | Moodle ist die zentrale Online-Lernplattform der Beuth Hochschule. Kurse, die in Moodle verwaltet werden erhalten in der Regel Abgabetermine für Aufgaben, die während des Semesters fällig werden. Oftmals stehen diese Abgabetermine bereits zu Beginn des Semesters in Moodle fest und können dort in einer Kalenderansicht betrachtet werden. \\ | + | |
- | | Initiale Schätzung | + | |
- | | Technologien | + | |
- | | Abhängigkeiten | + | |
- | | Anforderungen | + | |
- | | Tasks | * BOT-90 Import Moodle Rasa Direktive \\ * BOT-91 Moodle iCal Download via zentralem Scaper Service \\ * BOT-92 iCal Parsing und Persistierung als (sinnvolle) Erinnerung \\ * BOT-111 Feature Release \\ * BOT-113 Hilfe-Texte in (Chat)BHT-Bot help-command / willkommensnachricht | + | |
- | + | ||
- | + | ||
- | + | ||
- | | BOT-13: Speech To Text (STT) || | + | |
- | | Es soll ermöglicht werden, dass Benutzern neben Textnachrichten auch mittels Sprachnachrichten mit dem BeuthBot kommunizieren können. Dabei sollen die Sprachnachrichten mittels eines neuen Services in Text übersetzt werden und dann wie andere Textnachrichten verarbeitet werden. Hierzui sollen 3 bekannte STT-Frameworks (Kaldi, Mozilla Voice STT und Wav2Letter) getestet und vergleichen werden. Basierend darauf soll eine Entscheidung getroffen werden, welches Framework schlussendlich in der Production-Environment verwendet werden soll. Das Framework wird dann in Form eines neuen Micro-Services in den BeuthBot integriert. | + | |
- | | Zuständigkeit | + | |
- | | Initiale Schätzung | + | |
- | | Programmiersprachen | + | |
- | | Frameworks/ | + | |
- | | Services | + | |
- | | Abhängigkeiten | + | |
- | | Anforderungen | + | |
- | | Tasks | * BOT-69: WAV2Letter testen\\ * BOT-70: Mozilla Voice testen \\ * BOT-73: Kaldi testen\\ * BOT-71: Framework aussuchen\\ * BOT-122: Micro-Service erstellen \\ * BOT-123: Sprachnachricht in WAV umwandeln | + | |
- | + | ||
- | + | ||
- | + | ||
- | | BOT-23: Komponente zur Umwandlung von Text in Sprache (TTS) || | + | |
- | | Neben der bereits vorhandenen Funktion Textnachrichten vom Beuthbot zu erhalten, sollen Nutzer die Möglichkeit bekommen ebenfalls Sprachnachrichten zu empfangen. Hierfür wird eine Komponente zur Konvertierung von Text in Sprache (Eng: „Text-To-Speech (TTS)) benötigt. Dieses Feature soll dem Nutzer in künftigen, dem Beuthbot hinzugefügten, | + | |
- | | Initiale Schätzung | + | |
- | | Technologien | + | |
- | | Abhängigkeiten | + | |
- | | Anforderungen | + | |
- | | Nice to Haves | Sprachgeschwindigkeit und Stimme des Sprechers sind konfigurierbar | + | |
- | | Tasks | * BOT-24 Recherche nach geeignetem Tool (TTS) \\ * BOT-25 Eigene Implementierung (TTS) \\ * BOT-98 Integration in Beuthbot | + | |
- | + | ||
- | + | ||
- | + | ||
- | | BOT-75: Begrüßungsnachricht | + | |
- | | Neue Benutzer des BeuthBots sollen mit einer Begrüßungsnachricht empfangen werden. Diese Nachricht soll die Features des BeuthBots vorstellen und einen Shortcut nennen, welchen die Benutzer verwenden können, wenn sie Hilfe benötigen. Mit dem Shortcut | + | |
- | | Initiale Schätzung | + | |
- | | Technologien | + | |
- | | Abhängigkeiten | + | |
- | | Anforderungen | + | |
- | | Tasks | * BOT-93 Client\\ * BOT-94 Server | + | |
- | + | ||
- | + | ||
- | + | ||
- | | BOT-74: Webseite | + | |
- | | Um eine komplette Übersicht für alle genutzten BeuthBot-Resourcen zu haben, soll eine Webseite zur Präsentation dieser Ressourcen erstellt werden. Zu den Ressourcen zählen das Ziemer' | + | |
- | | Initiale Schätzung | + | |
- | | Technologien | + | |
- | | Abhängigkeiten | + | |
- | | Anforderungen | + | |
- | | Tasks | * BOT-76 Webseite Einrichten\\ * BOT-77 Infos zum Wiki\\ * BOT-78 Infos zu Telegram\\ * BOT-79 Infos zu Discord\\ * BOT-80 Infos zu GitHub\\ * BOT-81 Implementation Chatbot | + | |
- | + | ||
- | + | ||
- | + | ||
- | | BOT-11: Universeller Scraper & Download | + | |
- | | Der Beuthbot soll einen „universellen“ Web-Scraper beinhalten, der als Grundlage für künftige Features dienen soll, die für konkrete Scraping-Funktionalitäten vorgesehen sind. Aufgrund der hohen Diversität an Datenstrukturen unterschiedlicher Webseiten, soll dieser möglichst abstrakte Funktionalitäten zur Extrahierung von Datensätzen bieten. | + | |
- | | Initiale Schätzung | + | |
- | | Technologien | + | |
- | | Abhängigkeiten | + | |
- | | Anforderungen | + | |
- | | Tasks | * BOT-26 Recherche nach geeignetster Methode (HTML-JSON) | + | |
- | + | ||
- | + |