Preperation of Expert Talk | German Guide hinzugefügt
parent
a782e4d8f3
commit
3fdc9d237f
1 changed files with 164 additions and 0 deletions
164
Preperation-of-Expert-Talk-%7C-German-Guide.md
Normal file
164
Preperation-of-Expert-Talk-%7C-German-Guide.md
Normal file
|
|
@ -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" <<HTML/JS>>
|
||||||
|
}
|
||||||
|
|
||||||
|
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
|
||||||
Loading…
Add table
Reference in a new issue