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