From 3fdc9d237f817b0b83addaf66b959c860734a405 Mon Sep 17 00:00:00 2001 From: Underflow Date: Wed, 9 Apr 2025 23:17:57 +0200 Subject: [PATCH] =?UTF-8?q?Preperation=20of=20Expert=20Talk=20|=20German?= =?UTF-8?q?=20Guide=20hinzugef=C3=BCgt?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...eration-of-Expert-Talk-%7C-German-Guide.md | 164 ++++++++++++++++++ 1 file changed, 164 insertions(+) create mode 100644 Preperation-of-Expert-Talk-%7C-German-Guide.md diff --git a/Preperation-of-Expert-Talk-%7C-German-Guide.md b/Preperation-of-Expert-Talk-%7C-German-Guide.md new file mode 100644 index 0000000..f2691f2 --- /dev/null +++ b/Preperation-of-Expert-Talk-%7C-German-Guide.md @@ -0,0 +1,164 @@ +# Teil 1: Fachgespräch +## Einsatz und Begründung der Technologien: Verständnis zu den verwendeten Frameworks, Tools und Architektur und warum sie gewählt wurden + + - Vue.js als Frontend-Framework und Rust als Backend-Framework + - Git für Repo-Management, Bruno für API, Woodpecker für CI, Miro für Retro und Designs/Konzepte, Drawio für Diagramme + - Architektur Frontend-Backend Kommunikation durch REST-API's + +## Architektur-Überblick: Verständnis über die Gesamtarchitektur des Projekts (z. B. Schichten, Abhängigkeiten) + +[FE: Mockups](https://miro.com/app/board/uXjVIIUnWr0=/?userEmail=wollenberg.niklas@gmail.com&track=true&utm_source=notification&utm_medium=email&utm_campaign=add-to-team-and-board&utm_content=go-to-board&lid=6wzznu0o8wz9) + +## Stärken/Schwächen des Projekts: Kritische Auseinandersetzung mit Codequalität, Testabdeckung und Pipeline-Design und Wartbarkeit. + +- Codequalität kritisch auf Grund von neuem Framework und neuen Entwicklern im Frontend +- Tests grundsätzlich eher weniger vorhanden (FE und BE) als gewünscht auf Grund von fehlender Logik etc. +- Deployment Pipeline noch nicht voll funktionsfähig, weil Woodpecker ist falsch konfiguriert ist +- Rust tendenziell weniger wartbar, auf Grund von steiler Lernkurve und teilweise Inselwissen + +## Lernprozess & Zukunftsperspektive Einsicht in gewonnene Erkenntnisse und realistische Ideen zur Weiterentwicklung + +- Mehr "Investition" in Lernbereitschaft und Zeitaufwand +- Weniger Talk, mehr Code +- Use-Case Ideen umsetzen, später zusätzliche Ideen implementieren + +## Fachsprache & Klarheit: +Verwendung präziser Begriffe, um komplexe Konzepte verständlich zu erklären. + +- Wir _sind_ professionell + +## Fach- und Abnahmegespräch: Alle sind beteiligt, kein ausgeprägtes "Inselwissen" + +- Wir _sind_ experten + +# Teil 2: Monitoring + +CPU, RAM, Speicherplatz auf dem host wird gemonitored + +Datenbank, Get Post updates and delete wird gemonitored + +Prometheus und Grafana + + +## Sie können ausgewählte Messedaten erfassen, speichern und über die Konsole ausgeben. + +- Nein + +## Sie legen mindestens einen Schwellenwert fest. + +- Nein, nicht applicable + +## Sie überprüfen mindestens einen Schwellenwert. + +- Nein, s. o. + +## Die Messdaten werden in einer Logdatei gespeichert + +- Nein s. o. + +## Die auf dem Server eingeloggten Nutzer werden ebenfalls geloggt + +- Nein s. o. + + +## Sie haben eigene kleine Funktionen definiert. + +- Ja siehe Rust + +## Sie haben den Programmcode lesbar und verständlich gestaltet. + +- Ja, siehe Code + +## Sie haben das Programm für die umgesetzten Anforderungen getestet. + +- Wir testen nach den Anforderungen von Michael hier handelt es sich aber um Software Anforderung nicht um explizite Test-anforderungen + +## Sie haben einen automatisierten Test implementiert. + +- Ja siehe Rust + +## Sie haben ein Klassendiagramm oder Verteildiagramm ihrer Software erstellt. + +``` +@startuml +!theme vibrant +' Deployment diagram for PeerGrade + +skinparam componentStyle rectangle + +node "Client Browser" { + artifact "Web UI" <> +} + +node "Web Server\n(Vite + Vue)" { + artifact "Frontend App" +} + +node "API Server\n(Rust Backend)" { + artifact "Rust REST API" + node "Docker Container" { + node "Postgres Database Server " { + artifact "User DB" + } + node "Redis/Cache" { + artifact "Cache DB" + } + } +} + + +node "LDAP Server\n(School LDAP)" { + artifact "LDAP Directory" +} + +' Connections +"Client Browser" --> "Frontend App" : HTTP (User Access) +"Frontend App" --> "Rust REST API" : REST API Calls +"Rust REST API" --> "User DB" : SQL Queries +"Rust REST API" --> "LDAP Directory" : LDAP Authentication + +' Role-based flow +note right of "Rust REST API" + • Verifies credentials (PeerGroup or LDAP) + • Retrieves role data + • Sends user-specific data +end note + +note right of "Frontend App" + • Renders UI based on role + • Admin-only pages visible to: - Teachers - Admins +end note +@enduml +``` + + + + + + + + + +Should have + +Zwei Module (Monitoring / Alarm) die miteinander arbeiten, sind realisiert und getestet. +Ein zweistufiges Alarmsystem (Soft- und Hardlimit) für mindestens zwei Messdaten und deren Schwellenwerte sind umgesetzt. +Sie können eine E-Mail mit entsprechender Warnung versenden. +Die Module sind verständlich strukturiert. Sie erstellen eine Hilfe, die mit dem Parameter „h“ aufgerufen werden kann. +Die Steuerung des Programms (z. B. Auswahl der zu prüfenden Messdaten) erfolgt über die Parameter beim Programmaufruf oder über die interaktive Abfrage in der Konsole. +Der Programmcode ist leicht erweiterbar durch: +eine gute Programmstruktur(Module, kleine Funktionen), +selbsterklärenden Programmcode, +aussagekräftige Namen der Variablen und Funktionen sowie +sinnvolle Kommentare. +Sie haben drei automatisierte Tests implementiert. +Could have + +Zwei Module (Monitoring / Alarm), die miteinander arbeiten, sind realisiert und getestet. +Ein zweistufiges Alarmsystem (Soft- und Hardlimit) für mindestens zwei Messdaten und deren Schwellenwerte ist umgesetzt. Die E-Mails werden versendet, die Logindaten werden aus einer Datei gelesen. +Sie nutzen für die Festlegung der Schwellwerte(Hard-/Softlimits) und für die Login- Daten eine INI-Datei, die Sie mit Hilfe des Standardmoduls configparser auslesen. Die Steuerung des Programms (z. B. Auswahl der zu prüfenden Messdaten) erfolgt über die Parameter beim Programmaufruf oder über eine INI-Datei. Sie bieten dem Nutzer eine Hilfe (help-Texte) für die Kommandozeilenparameter an. +Sie haben fünf automatisierte Tests implementiert. +Sie entwickeln Ihre Module so, dass sie unabhängig vom Betriebssystem laufen. Testen Sie Ihre Module unter Windows und Linux. + + +# Part 3 \ No newline at end of file