From 6485ed6149479949da97418065669dcd08949e24 Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Sat, 7 Mar 2026 14:15:43 +0000
Subject: [PATCH 01/22] Update
 Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md

---
 ...beitsbuch-individueller-teil-Konstantin-Hintermayer.md | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index df95490..36f2de6 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -73,7 +73,10 @@ Im Package Projekt findet man Skripte zum Debuggen und Releasen eines Moduls. Un
 - Beim Debug werden die DLLs, PDBs und statischen Assets wie Skripte und Stylesheets der 3 anderen Projekte in den bereits gebauten Oqtane.Server `oqtane.framework/oqtane.server/bin/debug/net10.0/...` kopiert.
 - Beim Release wird ein NuGet-Paket erstellt und unter oqtane.framework/oqtane.server/Packages abgelegt. Dort abgelegte NuGet-Pakete werden beim nächsten Start des Oqtane Servers installiert (DB Migrationen werden gemacht und die Pakete entpackt).
 
-## Systemarchitektur (Postgres / Oqtane / Nginx )
+## Systemarchitektur (Postgres / Oqtane / Nginx)
+
+In diesem Kapitel erkläre ich wie die ausgewählten Komponenten zusammenspielen. Wir verwenden NginX als Reverse Proxy, welcher bei uns die SSL Terminierung macht. Das Zertifikat, welches verwendet wird, wird von Let's Encrypt bereit gestellt und mitels HTTP-Challanges und dem Certbot auf dem Server aktualisiert und verwaltet. Oqtane selber läuft als Systemd-Service im Kestrel Backend. Kestrel ist ein kleiner Webserver, welcher in das ASP.NET Core Framework eingebaut worden ist. Oqtane (bzw. der ASP.NET Core Server "Kestrel") hört auf der Loopback IP und Port 5000. Damit ist Oqtane nur durch NginX erreichbar. PostgreSQL ist die Datenbank in dem System: Sie hört wieder auf der Loopback IP und Port 5432.
+
 ```mermaid
 architecture-beta
     group server(server)[Server]
@@ -88,6 +91,9 @@ architecture-beta
     nginx:R <--> L:oqtane
     oqtane:R <--> L:db
 ```
+
+Zusätzlich gab es einen Administrationszugang zu den Servern, welcher über SSH möglich war. Dieser wurde für die Installation und Konfiguration der einzelnen Komponenten verwendet. Bei Hetzner war dieser Zugang nur über eine Wireguard VPN erreichbar. Bei der Schule war dieser Zugang direkt (über einen Hight-Port) möglich. Und bei LiveDesign war dieser Zugang wieder über eine VPN geregelt. Anfänglich mit SSL VPN, später mit einem IPSEC / Strongswan.
+
 ## Websockets und HTTP 1.1 
 
 

From e57e821ead3083092209954d74d818d1044e728e Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Sat, 7 Mar 2026 15:56:54 +0000
Subject: [PATCH 02/22] KH: Blazor beschreibung

---
 ...dividueller-teil-Konstantin-Hintermayer.md | 46 ++++++++++++++++++-
 1 file changed, 44 insertions(+), 2 deletions(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index 36f2de6..dc3f9df 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -49,7 +49,6 @@ Es war von Anfang an klar, dass es ein SQL basiertes System wird, da wir im Team
 
 
 # Technologie
-## Entwicklung mit ASP.NET (Was ist Blazor? / Was ist Razor? / Kestrel)
 ## Was ist Oqtane? Architektur von Oqtane?
 Oqtane ist ein Framework und CMS zur Entwicklung von Webseiten mithilfe von ASP.NET und Blazor. [^5] Ein Oqtane-System besteht aus mehreren Komponenten.
 
@@ -94,8 +93,51 @@ architecture-beta
 
 Zusätzlich gab es einen Administrationszugang zu den Servern, welcher über SSH möglich war. Dieser wurde für die Installation und Konfiguration der einzelnen Komponenten verwendet. Bei Hetzner war dieser Zugang nur über eine Wireguard VPN erreichbar. Bei der Schule war dieser Zugang direkt (über einen Hight-Port) möglich. Und bei LiveDesign war dieser Zugang wieder über eine VPN geregelt. Anfänglich mit SSL VPN, später mit einem IPSEC / Strongswan.
 
-## Websockets und HTTP 1.1 
+## Entwicklung mit ASP.NET (Was ist Blazor? / Was ist Razor? / Kestrel)
+### Blazor [^7]
+Blazor ist ein kostenloses und quelloffenes Web-Framework, welches es Möglich macht, Benutzeroberflächen für Web-Browser basierend auf C# and HTML zu erstellen. Es wird von Microsoft als teil des ASP.NET Core Frameworks entwickelt. 
 
+Blazor hat mehrere Hosting-Modelle:
+- Blazor Web App: Hier wird die Web App als Teil einer ASP.NET Core Anwendung bereitgestellt. Hier gibt es mehrere Render Modi:
+  - Static Server: Die Komponente wird serverseitig "gerenderet" und besitzt keine Interaktivität. Das istder Default `RenderMode`
+  - Interative Server: Die Komponente wird serverseitig "gerendert", diesmal ist sie jedoch interaktiv. Das bedeutet: Man kann mithilfe von C# den Zustand der Seite dynamisch bearbeiten. Diese Zustandsänderungen werden serverseitig bearbeitet. Hierbei kommunizieren Server und Client mithilfe von SignalR über WebSockets miteinander.
+  - Interactive WebAssembly: Die Komponente wird clientseitig, also im Browser, "gerendert". Damit der Blazor C# Code auch im Browser ausgeführt werden kann wird dieser in WebAssembly kompiliert.
+  - Interactive Auto: Im `Interactive Auto` Modul wird bei dem initialen Besuch der Website der `Interactive  Server` Modus gewählt und im Hintergrund wird der WebAssembly-Build heruntergeladen, damit bei weiteren Besuchen der Seite der `Interactive WebAssembly` Modus gewählt werden kann.
+- Hybrid: Dieser Modus ist der einzige, welcher nicht innerhalb einer Blazor Web App läuft, sondern in einem WebView einer Nativen App. Dabei wird innerhalb des Mutterprozesses, ganz ohne WebServer. Das ganze Funktioniert in WPF und WinForms Apps und in nativen mobilen Apps für Android und iOS mithilfe von .NET MAUI.
+
+Razor-Komponenten (in dieser Arbeit, sowie Umgangssprachlich, auch oft nur Komponenten genannt) sind der Grundbaustein für Blazor Web Apps. Sie bestehen aus HTML, welches mit der Verwendung von inline C# beeinflusst werden kann. Das Blazor stellt sicher, dass das gerenderte Markup aktualisiert wird, wenn sicher der Status der Komponente ändert. Dieser Code kann entweder vollständig in einer .razor Dateil liegen, oder in einer seperaten Code-Behind-Datei und der benutzer einer partiellen Klasse. Inline C# Code wird mithilfe von dem `@`- Zeichen markiert. Hier ist ein Beispiel für einen einfachen Counter:
+
+```razor
+<h1>Counter</h1>
+
+<p>Count: @count</p>
+
+<button @onclick="Increment">Increment</button>
+
+@code 
+{
+    private int count = 0;
+
+    private void Increment()
+    {
+        count++;
+    }
+}
+```
+
+Mit`@count` in Zeile 3 wird der Wert der Variablen count in den `<p>` Tag mit eingebaut. Mit `@onclick="Increment"` in Zeile 5 wird die onclick Property vom `<button>`Tag auf die Increment Methode im C# Code. Der `@code` Block in Zeile 7 ist der C# Code, welcher diese Komponente dynamisch macht. Hier ist die Variable count definiert und die Methode Increment, welche dieser Komponente interaktiv macht. 
+
+Razor hat auch eine Reihe an Keywords wie zum Beipsiel (nur Auszugsweise, bzw. die die wir verwendet haben):
+- namespace: Gibt den aktuellen Namespace in der Razor Datei ein
+- inherits: Gibt die Superklasse der generierten C# Klasse an.
+- using: Gibt die im C# Code benutzen/verfügbaren Namespaces an
+- foreach: Für Wiederholungen im Markup
+- if: Für verzweigungen im Markup
+
+[^7]: https://en.wikipedia.org/wiki/Blazor
+
+### SignalR
+### Kestrel
 
 ## Dependency injection
 

From d59aa847f19ef7e9f9a428155a4115bdcd3f325e Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Tue, 10 Mar 2026 08:49:23 +0000
Subject: [PATCH 03/22] Kommunikations zwischen FE und BE, SignalR, Produktion
 != Staging und Teamleitung und Downsing

---
 ...dividueller-teil-Konstantin-Hintermayer.md | 20 ++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index dc3f9df..11dbadd 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -136,8 +136,11 @@ Razor hat auch eine Reihe an Keywords wie zum Beipsiel (nur Auszugsweise, bzw. d
 
 [^7]: https://en.wikipedia.org/wiki/Blazor
 
-### SignalR
-### Kestrel
+### Kommunikations zwischen Front und Backend
+Wie Front- und Backend miteinander interagieren hängt hauptsächlich vom Render Modus ab. Oqtane kann auf verschiedene Arten betrieben werden. Hierbei ist es dem Modulentwickler ziemlich egal, welche Art der Kommunikation (WebSockets, HTTP Long-Polling, REST) verwendet wird. 
+
+#### SignalR
+SignalR ist eine Libary aus für das ASP.NET Framework, welche es möglich macht Server zu Client komminikation zu betreiben. Oqtane verwendet im `Interactive Server (SignalR)` Render-Modus verwendet wird.
 
 ## Dependency injection
 
@@ -270,10 +273,17 @@ Anwendungen von Gitea Actions bei dieser Diplomarbeit:
 ## Kommunikation
 
 # Learnings
-## Probleme mit Oqtane
-## Arbeitszeiteinschätzung (Zeitverzug)
-## Teamleitung (Motivation / Downsizing)
+
 ## Produktion != Staging
+
+Ein Learning, welches doch relativ schnell aufkam ist im Bereich der IT eigentlich kein unbekanntes. Wir hatten dieses Learning relativ bald, im Frühling 2025, als die ersten Probleme mit dem Deployment von Oqtane aufkamen. Oqtane war zwar in unserer Entwicklungsumgebung sehr einfach zum einrichten gewesen, das Deployment in der Cloud vom Hetzner war jedoch geplagt von Problemen. Im Zeitraum von Mai bis Okober hatten wir keine laufende Produktivumgebung. Dadurch sind wir mit dieser Diplomarbeit auch in [Zeitverzug](#Arbeitszeiteinschätzung-und-verzug) gekommen. Hätte ich mich vor dem Start der Diplomarbeit mit dem Deployment von Oqtane auseinander gesetzt, dann wäre das in [Probleme mit Oqtane](#Probleme mit Oqtane) beschriebene Problem früher aufgekommen und der Zeitverzug wäre nicht so groß, oder noch ganz vermeidbar gewesen.
+
+## Teamleitung (Motivation / Downsizing)
+
+Nachdem ich mich von Anfang an volkommen in das Deploymentproblem von Oqtane gestürzt habe, habe ich meine Rolle als Teamleitung etwas schleifen gelassen. Dadurch fehlte bei einigen Teammitgliedern initial die Identifikation mit dem Projekt und in weitererfolge auch die Motivation an diesem Projekt mitzuarbeiten. Nachdem im Verlauf des Frühlings und über den Sommer von der hälfte des Teams trotz Besprechungen und Mahnungen keine Beiträge zu dem Projekt kamen haben Hr. Prof. Gürth und ich uns dazu entschieden uns von 2 Personen vor unterschreiben des Projektantrages zu trennen. Grund dazu war die Angst, die mangelnde Motivation zieht das restliche Team mit hinunter. Wir wollten uns trotz des Downsizings nicht an Funktionalitäten sparen und haben uns für das nächste halbe bis dreiviertel Jahr einen ziemlich strikten Zeiplan vorgenommen.
+
+## Arbeitszeiteinschätzung (Zeitverzug)
+
 ## Sprints und Meetings (in Zukunft ja asynchron)
 
 # Modules

From 02ad58b97b40af0e769c38e08aafd47b6ef6c3d7 Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Tue, 10 Mar 2026 18:59:00 +0000
Subject: [PATCH 04/22] =?UTF-8?q?Arbeitszeiteinsch=C3=A4tzung?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...dividueller-teil-Konstantin-Hintermayer.md | 22 ++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index 11dbadd..6614115 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -280,10 +280,30 @@ Ein Learning, welches doch relativ schnell aufkam ist im Bereich der IT eigentli
 
 ## Teamleitung (Motivation / Downsizing)
 
-Nachdem ich mich von Anfang an volkommen in das Deploymentproblem von Oqtane gestürzt habe, habe ich meine Rolle als Teamleitung etwas schleifen gelassen. Dadurch fehlte bei einigen Teammitgliedern initial die Identifikation mit dem Projekt und in weitererfolge auch die Motivation an diesem Projekt mitzuarbeiten. Nachdem im Verlauf des Frühlings und über den Sommer von der hälfte des Teams trotz Besprechungen und Mahnungen keine Beiträge zu dem Projekt kamen haben Hr. Prof. Gürth und ich uns dazu entschieden uns von 2 Personen vor unterschreiben des Projektantrages zu trennen. Grund dazu war die Angst, die mangelnde Motivation zieht das restliche Team mit hinunter. Wir wollten uns trotz des Downsizings nicht an Funktionalitäten sparen und haben uns für das nächste halbe bis dreiviertel Jahr einen ziemlich strikten Zeiplan vorgenommen.
+Nachdem ich mich von Anfang an volkommen in das Deploymentproblem von Oqtane gestürzt habe, habe ich meine Rolle als Teamleitung etwas schleifen lassen. Dadurch fehlte bei einigen Teammitgliedern initial die Identifikation mit dem Projekt und in weitererfolge auch die Motivation an diesem Projekt mitzuarbeiten. Nachdem im Verlauf des Frühlings und über den Sommer von der hälfte des Teams trotz Besprechungen und Mahnungen keine Beiträge zu dem Projekt kamen, haben Hr. Prof. Gürth und ich uns dazu entschieden uns von 2 Personen vor unterschreiben des Projektantrages zu trennen. Grund dazu war die Angst, die mangelnde Motivation zieht das restliche Team mit hinunter. Wir wollten uns trotz des Downsizings nicht an Funktionalitäten sparen und haben uns für das nächste halbe bis dreiviertel Jahr einen ziemlich strikten Zeiplan vorgenommen.
 
 ## Arbeitszeiteinschätzung (Zeitverzug)
 
+Ein wesentliches Learning aus dem Projektverlauf war die Diskrepanz zwischen der initialen Planung und dem tatsächlichen Aufwand. Ursprünglich wurde der Zeitaufwand für das Aufsetzen der Infrastruktur und die Einarbeitung in das Oqtane-Framework auf etwa drei Wochen geschätzt. In der Realität nahm dieser Prozess jedoch mehrere Monate in Anspruch.
+
+Es gibt mehrere Gründe dafür:
+- `Fehlende oder nur schlechte Dokumentation von Oqtane`: Einige Probleme im Deployment wurden in langer und mühseliger Arbeit auseinander gebrochen und in weitere immer kleinere Probleme unterteilt. Dadurch, dass wir alle keine Erfahrung mit der Entwicklung und dem Deployment von ASP.NET Code Anwendungen hatten und die Dokumentation doch schlecht war, blieb uns manchmal nichts anderes übrig als mit WireShark den Netzwerktraffic mit zu schneiden und nebenbei im Git Repository die geloggten Zeilen Code zu finden und so das Framework von innen heraus kennen zu lernen. Dadurch hatte ich dann nach einer Einarbeitungszeit von 4 Monaten ziemlich jede Stelle im Sourcecode von Oqtane gesehen und finde mich um das schneller zurecht.
+- `Team-Konsolidierung`: Durch das notwendige Downsizing des Teams mussten Aufgaben neu verteilt werden, was die individuelle Arbeitslast erhöhte und die Konzentration auf die Kernentwicklung zeitweise verzögert hat.
+- `Abhängigkeit von der Infrastruktur`: Dadurch, dass wir bis in den Oktober / November hinein nicht wussten, ob wir weiter bei Oqtane bleiben können, haben die anderen Teammitglieder nicht mit der sinnvollen Entwicklung ihrer Module starten können. Zitat: "Und was wenn wir am Ende doch noch das CMS umstellen müssen?" => Auch wenn der Auftrag war, mit der Modulentwicklung zu starten war die Motivation meiner Teammitglieder nicht so hoch. Selbst wenn sie nicht direkt von der Infrastruktur mit der Ausführung ihrer Aufgaben abhängig waren, motiviert waren sie wegen der Umstände auch nicht.
+  
+Reaktion auf den Verzug:
+Um das Projektziel dennoch zu erreichen, wurde der Zeitplan im Herbst 2025 massiv gestrafft. Durch die Umstellung auf einen strikteren 14-tägigen Sprint-Rhythmus und die Priorisierung von Core-Funktionalitäten (MVP-Ansatz) konnte der Rückstand teilweise aufgeholt werden.
+
+
+> Fazit: Die Erfahrung zeigt, dass gerade bei "Nischen-Frameworks" wie Oqtane ein deutlich höherer Puffer für die Einarbeitungs- und Infrastrukturphase (Faktor 2 bis 3 der ursprünglichen Schätzung) eingeplant werden muss.
+
+`90% fertig, oder fertig?`: Es gibt einige "Regeln", wie: das `Paretoprinzip`, `Hofstadter’s Law` und die `90-90 Regel`. Letztere wurde im Jahr 1985 von Jon Bentley in einer Kolumne "Programming pearls" veröffentlicht. Ausgeschrieben lautet sie:
+> [Rule of Credibility] The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
+(Jon Bentley. 1985. Programmimg pearls. Commun. ACM 28, 9 (Sept. 1985), 896–901. https://doi.org/10.1145/4284.315122) [^8]
+Diese Diplomarbeit liefert weitere Evidenz, dass diese Faustregel stimmt.
+
+[^8](https://dl.acm.org/doi/10.1145/4284.315122)
+
 ## Sprints und Meetings (in Zukunft ja asynchron)
 
 # Modules

From 46808af2b7e260bbf2966e5bc0dabd71bf7739a5 Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Tue, 10 Mar 2026 20:47:34 +0000
Subject: [PATCH 05/22] Update
 Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md

---
 ...sbuch-individueller-teil-Konstantin-Hintermayer.md | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index 6614115..84d42d1 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -306,6 +306,17 @@ Diese Diplomarbeit liefert weitere Evidenz, dass diese Faustregel stimmt.
 
 ## Sprints und Meetings (in Zukunft ja asynchron)
 
+Ein zentrales Problem in unserer ursprünglichen Arbeitsweise war die Kopplung von Besprechungsterminen mit festen „Commit-Deadlines“ (dem Ende des aktuellen Sprint zyklusses). Da wir uns einmal pro Woche für sechs Stunden am Stück trafen, entstand ein destruktives Muster:
+
+- Der "Last-Minute-Commit"-Druck: In den Stunden unmittelbar vor dem Meeting wurden Aufgaben unter Zeitdruck abgeschlossen, um im Meeting Fortschritte präsentieren zu können. Dies führte dazu, dass unfertiger oder unzureichend getesteter Code („Quick and Dirty“) in das Repository gepusht wurde.
+- Fehlende Review-Kultur: Da die Commits erst kurz vor dem Meeting eintrafen, blieb dem restlichen Team keine Zeit für fundierte Code-Reviews. Die Besprechungszeit wurde somit für die Fehlersuche statt für strategische Planung genutzt.
+- Ineffizienz: Lange Präsenz-Meetings blockierten wertvolle Entwicklungszeit, ohne die technische Qualität zu steigern.
+
+Lösungsansatz: Meetings und Besprechungen asynchron zueinander setzen.
+- Asynchrone Daily-Updates: Statusberichte erfolgen schriftlich (z. B. in Gitea Issues oder YouTrack), nicht mehr in stundenlangen Call-Marathons. Das nimmt den zeitlichen Druck vom einzelnen Entwickler. Oder zumindest in kurzen Commitnachrichten, welche am Ende des Tages automatisch an alle Teammitglieder zum überblick gesendet werden (eventuell mit @username tagging, um eine Person nochmal genau anzusprechen)
+- Review-First-Policy: Ein Feature gilt erst dann als „fertig“, wenn es einen asynchronen Code-Review-Prozess durchlaufen hat. Das Meeting dient nur noch der Klärung von Blockern, nicht der Präsentation von Code. Das war eigentlich schon von Anfang an in unserer `Definition of Done` festgelegt worden.
+- Entkoppelung von Meeting und Deadline: Meetings sollten der Synchronisation dienen, während die Abgabe von Arbeitspaketen kontinuierlich (Continuous Integration) erfolgen muss, um Lastspitzen (in der [Gitea Actions](#Continuous Integration) Pipeline) am Tag der Besprechung zu vermeiden.
+
 # Modules
 ## Mass Mailer
 ## Event Registration

From 978f5579fba031466c7670fc4f9797460e3b0ce2 Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Tue, 10 Mar 2026 21:03:16 +0000
Subject: [PATCH 06/22] Update
 Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md

---
 ...eitsbuch-individueller-teil-Konstantin-Hintermayer.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index 84d42d1..5bf5add 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -319,5 +319,14 @@ Lösungsansatz: Meetings und Besprechungen asynchron zueinander setzen.
 
 # Modules
 ## Mass Mailer
+
+Das Mass Mailer Modul ist eine administrative Erweiterung für den Alumnihub, die es dem Vorstand ermöglicht, personalisierte Rundschreiben an alle registrierten Mitglieder zu versenden. Da die Pflege der Mitgliederdaten direkt im CMS erfolgt, bietet dieses Modul eine nahtlose Integration ohne den Export von CSV-Listen in externe Newsletter-Tools.
+
+Integration von Brevo
+
+Für den tatsächlichen Versand der E-Mails nutzen wir den Cloud-Dienst Brevo. Dieser bietet eine zuverlässige Zustellung (hohe Reputation der Mailserver), stellt uns jedoch in der kostenlosen Variante vor eine Herausforderung: nur 300 EMails pro Tag.
+
+`Batch-Processing`: Mails werden nicht sofort ("Fire and Forget") versendet, sondern in eine Versandwarteschlange geschrieben. Nachdem schon die Notifications Infrastruktur, welche sich auch um den Mail versand kümmert, ins Framework eingebaut worden ist, nutzen wir diese geleich und `schedulen` unsere EMails. Immer 100 Mails alle 24 Stunden bis alle Ziele die Mails erhalten haben. Das Limit von 100 / Tag ist konservativ sehr niedrig angesetzt, damit funktionen wie Passwort Reset Mails nicht (leicht) dadurch beeinflusst werden können.
+
 ## Event Registration
 ## Schwarzes Brett
\ No newline at end of file

From 4df7cc1cf781ba2e485c897ae51495ad005fbd9d Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Fri, 13 Mar 2026 20:25:37 +0000
Subject: [PATCH 07/22] New: Token Lifetime

---
 ...dividueller-teil-Konstantin-Hintermayer.md | 21 ++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index 5bf5add..16eee90 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -318,7 +318,12 @@ Lösungsansatz: Meetings und Besprechungen asynchron zueinander setzen.
 - Entkoppelung von Meeting und Deadline: Meetings sollten der Synchronisation dienen, während die Abgabe von Arbeitspaketen kontinuierlich (Continuous Integration) erfolgen muss, um Lastspitzen (in der [Gitea Actions](#Continuous Integration) Pipeline) am Tag der Besprechung zu vermeiden.
 
 # Modules
-## Mass Mailer
+
+## Admin Modules
+
+Eine C#-Solution, welche einige Module, welche für den Admineinsatz geschrieben worden sind beinhaltet. Dieses Modul besteht aus 3 Teilmodulen. Einem Modul für den Versand von Rundmails, eines für die Einstellung von der Token Lebenszeit bei Tokens, welche per EMail verschickt werden und eines, welches das Reporting-System übernimmt.
+
+### Mass Mailing
 
 Das Mass Mailer Modul ist eine administrative Erweiterung für den Alumnihub, die es dem Vorstand ermöglicht, personalisierte Rundschreiben an alle registrierten Mitglieder zu versenden. Da die Pflege der Mitgliederdaten direkt im CMS erfolgt, bietet dieses Modul eine nahtlose Integration ohne den Export von CSV-Listen in externe Newsletter-Tools.
 
@@ -328,5 +333,19 @@ Für den tatsächlichen Versand der E-Mails nutzen wir den Cloud-Dienst Brevo. D
 
 `Batch-Processing`: Mails werden nicht sofort ("Fire and Forget") versendet, sondern in eine Versandwarteschlange geschrieben. Nachdem schon die Notifications Infrastruktur, welche sich auch um den Mail versand kümmert, ins Framework eingebaut worden ist, nutzen wir diese geleich und `schedulen` unsere EMails. Immer 100 Mails alle 24 Stunden bis alle Ziele die Mails erhalten haben. Das Limit von 100 / Tag ist konservativ sehr niedrig angesetzt, damit funktionen wie Passwort Reset Mails nicht (leicht) dadurch beeinflusst werden können.
 
+### Token Lifetime
+
+Das Token Lifetime Modul wurde geschrieben, um die Token-Lebenszeit konfigurierbar zu machen. Notwendig war das, um die Passwort Reset Links im initialen Mail versand länger gultig sein zu lassen. Durch das `Batch Processing` war es Möglich, dass eine Mail erst Tage nach erstellen des Links hinaus geschickt wird und bei einer Standard Ablaufdauer von 2 Tagen sind machne Links schon ungültig, bis sie den Mail Server erreichen. Ziel war es, die Änderung der Lebenszeit für Administratoren im User Interface im Admin Bereich möglich zu machen.
+
+Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
+- `der Workarround`:  Ein eigenes Modul, welches in seiner `Server/Startup.cs` die benötigten Werte korrekt setzt. Das hat den Vorteil, dass wir keine Änderungen im CMS selbst haben, sondern nur unsere eigene Erweiterung dafür schreiben. Andererseits könnte durch die undeterminischte Ladereihenfolge eine `race-condition` auftreten. Darüberhinaus haben wir keinen gleichzeitigen Zugriff auf appsettings.json und den IServiceProvider in dem wir die Konfiguration setzen müssen. => Nachdem wir in der Konfigurationsphase auch noch keinen Datenbankzugriff haben, können wir die Werte nicht aus der DB Laden, sondern müssen auf eine Text Datei zurückgreifen.
+- `die saubere Lösung`:  Eine Änderung im Kern von Oqtane. Also implementieren wir in unserem Fork von Oqtane die Konfigurationslogik für die Tokenlifetime. Hier könnte die Konfigurationslogik direkt in `OqtaneServiceCollectionExtensions.cs` hinzufügen, hier werden auch alle anderen Oqtane Spezifischen Configurationen gesetzt. Das hat den Vorteil, dass der Code aufgeräumter und sauberer ist und die `race-condition` verhindert werden kann. Der initiale Grund dagegen ist, dass wir ein weiteres Git Repository zum warten haben (den Fork vom Oqtane.Framework), welches jetzt nicht mehr mit Upstream Commit-gleich ist.
+
+`Der Workarround` ist die Möglichkeit für die wir uns zuerst entschieden haben, allerdings haben wir uns im Nachhinein noch umentschlossen und wollen `die saubere Lösung` implementieren. 
+
+((Quellen einfügen: Configure Token for Email versand und Race Conditions beschreiben.))
+
+### Reporting System
+
 ## Event Registration
 ## Schwarzes Brett
\ No newline at end of file

From a535e73c3f5e128dd319848621ae0bd426352650 Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Fri, 13 Mar 2026 21:23:30 +0000
Subject: [PATCH 08/22] New: Reporting System

---
 ...dividueller-teil-Konstantin-Hintermayer.md | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index 16eee90..302eaa9 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -347,5 +347,51 @@ Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
 
 ### Reporting System
 
+Eine weitere Anforderung der Diplomarbeit war es Einträge in Modulen wie der `Hall of Fame`, dem `Schwarzen Brett` und dem Premium Bereich (`Engineer Applications`) melden zu können. Am Anfang war es wichtig, dass jeder Schnell vorrankommt, allerdings haben wir die Kommunikation Teamintern ein wenig verschlafen und dadurch ein paar Funktionen doppelt geschrieben. Dadurch kam es zu inkonsistenzen in der Verwendung der Reporting Systeme. 
+
+Angestrebt wurde folgender Ablauf für das Melden eines Eintrags:
+```mermaid
+sequenceDiagram
+    participant Module
+    actor User
+    participant ReportingComponent
+    participant ReportingHandler
+    User->>+Module: View: Entity
+    User->>+ReportingComponent: Report current Entity
+    
+    rect rgba(0, 0, 0, 0)
+    ReportingComponent->>+User: Ask for reason
+    User->>-ReportingComponent: Enters Reason
+    end
+    
+    ReportingComponent->>+ReportingHandler: New Report (includes entity and reason)
+    ReportingComponent->>-User: Done
+```
+
+Im oben dargestellten Ablaufdiagram werden das ReportingComponent und der ReportingHandler vom Reporting System über Dependency Injection bereitgestellt, nicht vom Modul selbst. Dadurch erreichen wir eine bessere Trnnung und halten das S in SOLID ein: `Single responsibility`. Die Module sind jetzt nicht mehr für das Reporting selber verantwortlich, sondern müssen nur das Reportings System einbinden.
+
+Damit DI funktioniert muss der DI Consumer (`also das Modul, welches das Reporting System einbinden möchte`) das Interface zur Kompilierzeit sehen. Um das zu erreichen haben wir eine neue Klassenbibliothek erstellt: Sie heißt Interfaces wird per Gitea Actions automatisch in ein Nuget Paket gebaut und in der `Gitea Actions Nuget Registry` veröffentlicht. Dieses Nuget Paket wird dann in jedem Modul installiert und damit kann man Modulübergreifend auf die Services und das IReporting Component zugreifen.
+
+Die Implementierung des IReportingComponents stellt nur eine Property (`ReportType`, welche den TypeName der Razor Komponente zurückliefert, damit Dynamic Component sie laden kann) und eine Methode (`ConstructParameterList`, welche das Parameter Dictionary erstellt. Nur zwecks Typensicherheit eingefügt) bereit. Mit dem Dynamic Component von Razor ist es möglich, per C# Code unterschiedliche Komponenten zu rendern.
+
+```razor
+@inject IReportUI ReportingComponent
+
+<DynamicComponent Type="@ReportingComponent.ReportType" Parameters="@ReportingComponent.ConstructParameterList(_item, RenderModeBoundary)"/>
+
+@code {
+  private IReportable _item;
+}
+```
+
+IReportUI muss auch bereitgestellt werden, dass passiert im Startup.cs des Reporting Moduls (Admin Modul)
+
+```c#
+if (!services.Any(s => s.ServiceType == typeof(IReportUI)))
+{
+    services.AddScoped<IReportUI, ReportComponent>();
+}
+```
+
 ## Event Registration
 ## Schwarzes Brett
\ No newline at end of file

From 1c1949381b1adc578cd20e16f8cc184523e45ea9 Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <kocoder@noreply.git.kocoder.xyz>
Date: Fri, 13 Mar 2026 21:33:44 +0000
Subject: [PATCH 09/22] Update: Reporting System

---
 ...individueller-teil-Konstantin-Hintermayer.md | 17 +++++------------
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index 302eaa9..70c7a75 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -347,7 +347,7 @@ Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
 
 ### Reporting System
 
-Eine weitere Anforderung der Diplomarbeit war es Einträge in Modulen wie der `Hall of Fame`, dem `Schwarzen Brett` und dem Premium Bereich (`Engineer Applications`) melden zu können. Am Anfang war es wichtig, dass jeder Schnell vorrankommt, allerdings haben wir die Kommunikation Teamintern ein wenig verschlafen und dadurch ein paar Funktionen doppelt geschrieben. Dadurch kam es zu inkonsistenzen in der Verwendung der Reporting Systeme. 
+Eine weitere Anforderung der Diplomarbeit war es Einträge in Modulen wie der `Hall of Fame`, dem `Schwarzen Brett` und dem Premium Bereich (`Engineer Applications`) melden zu können. Am Anfang war es wichtig, dass jeder schnell vorrankommt, allerdings haben wir die Kommunikation Teamintern ein wenig verschlafen und dadurch ein paar Funktionen doppelt geschrieben. Dadurch kam es zu inkonsistenzen in der Verwendung der unterschiedlichen Reporting Systeme. Deswegen haben wir uns am Ende für eine globales Reporting System entschieden.
 
 Angestrebt wurde folgender Ablauf für das Melden eines Eintrags:
 ```mermaid
@@ -368,11 +368,11 @@ sequenceDiagram
     ReportingComponent->>-User: Done
 ```
 
-Im oben dargestellten Ablaufdiagram werden das ReportingComponent und der ReportingHandler vom Reporting System über Dependency Injection bereitgestellt, nicht vom Modul selbst. Dadurch erreichen wir eine bessere Trnnung und halten das S in SOLID ein: `Single responsibility`. Die Module sind jetzt nicht mehr für das Reporting selber verantwortlich, sondern müssen nur das Reportings System einbinden.
+Im oben dargestellten Ablaufdiagram werden das ReportingComponent und der ReportingHandler vom Reporting System über Dependency Injection bereitgestellt, nicht vom Modul selbst. Dadurch erreichen wir eine bessere Trennung der Zuständigkeiten und halten das S in SOLID ein: `Single responsibility`. Die Module sind jetzt nicht mehr für das Reporting selber verantwortlich, sondern müssen nur das Reportings System einbinden.
 
-Damit DI funktioniert muss der DI Consumer (`also das Modul, welches das Reporting System einbinden möchte`) das Interface zur Kompilierzeit sehen. Um das zu erreichen haben wir eine neue Klassenbibliothek erstellt: Sie heißt Interfaces wird per Gitea Actions automatisch in ein Nuget Paket gebaut und in der `Gitea Actions Nuget Registry` veröffentlicht. Dieses Nuget Paket wird dann in jedem Modul installiert und damit kann man Modulübergreifend auf die Services und das IReporting Component zugreifen.
+Damit DI funktioniert muss für den DI Consumer (`also das Modul, welches das Reporting System einbinden möchte`) das Interface zur Kompilierzeit zur Verfügung stehen. Um das zu erreichen haben wir eine neue Klassenbibliothek erstellt: Sie heißt Interfaces wird per Gitea Actions automatisch in ein Nuget Paket gebaut und in der `Gitea Actions Nuget Registry` veröffentlicht. Dieses Nuget Paket wird dann in jedem notwendigen Modul als dependency hinzugefügt und damit kann man Modulübergreifend auf die Services und das IReporting Component zugreifen.
 
-Die Implementierung des IReportingComponents stellt nur eine Property (`ReportType`, welche den TypeName der Razor Komponente zurückliefert, damit Dynamic Component sie laden kann) und eine Methode (`ConstructParameterList`, welche das Parameter Dictionary erstellt. Nur zwecks Typensicherheit eingefügt) bereit. Mit dem Dynamic Component von Razor ist es möglich, per C# Code unterschiedliche Komponenten zu rendern.
+Die Implementierung des IReportingComponents stellt nur eine Property (`ReportType`, welche den TypeName der Razor Komponente zurückliefert, damit Dynamic Component sie laden kann) und eine Methode (`ConstructParameterList`, welche das Parameter Dictionary erstellt. Nur zwecks Typensicherheit eingefügt) bereit. Mit dem Dynamic Component von Razor ist es möglich, per C# Code unterschiedliche Komponenten zu rendern und damit auch die per DI injezierte Klasse.
 
 ```razor
 @inject IReportUI ReportingComponent
@@ -384,14 +384,7 @@ Die Implementierung des IReportingComponents stellt nur eine Property (`ReportTy
 }
 ```
 
-IReportUI muss auch bereitgestellt werden, dass passiert im Startup.cs des Reporting Moduls (Admin Modul)
-
-```c#
-if (!services.Any(s => s.ServiceType == typeof(IReportUI)))
-{
-    services.AddScoped<IReportUI, ReportComponent>();
-}
-```
+Die Bereitstellund des Moduls geschieht im `AdminModules` Modul.
 
 ## Event Registration
 ## Schwarzes Brett
\ No newline at end of file

From 0d4ccdaa477ad1ed1af68231b7321ba18b368888 Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Tue, 17 Mar 2026 12:43:06 +0000
Subject: [PATCH 10/22] Individueller Teil - Konstantin Hintermayer: Korrektur
 1/x

---
 ...dividueller-teil-Konstantin-Hintermayer.md | 144 +++++++++++-------
 1 file changed, 87 insertions(+), 57 deletions(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index 70c7a75..9e03833 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -5,10 +5,12 @@ gitea: none
 
 ## 1. Einleitung des individuellen Teils
 
-In diesem Abschnitt wird meine persönliche Aufgabenstellung im Rahmen des Projektes (`Alumnihub`) beschrieben. 
+In diesem Abschnitt wird meine persönliche Aufgabenstellung im Rahmen des Projektes (`Alumnihub`) beschrieben.
 
 ### Auftrag / persönliche Aufgabenstellungen
+
 Meine Zuständigkeiten und Verantwortlichkeiten:
+
 - Product Owner
 - Infrastruktur
 - Entwicklung
@@ -25,56 +27,61 @@ Lernen von ASP.NET und der Entwicklung mit Blazor und Oqtane. Ich habe Interesse
 - Use Cases
 
 ## 3. Technische Grundlagen
-Mein Aufgabenbereich umfasst einerseits die Entwicklung eigener Module, sowie das Bereitstellen des Services. Als Betriebssystem habe ich mich für Linux entschieden, einfach, da ich mit Linux im Serverumfeld die meisten und besten Erfahrungen gemacht habe. 
 
-(Diese Entscheidung wurde gemeinsam getroffen:)
-Auch steht die Wahl der Programmiersprache und des CMS an. Nachdem wir im Unterricht fast ausschließlich mit C# entwickelt haben und nicht in eine komplett unbekannte Entwicklungsumgebung abdriften wollten, haben wir uns für Webentwicklung mit ASP.NET Core 9 und (Upgrade im Lauf der Diplomarbeit auf .NET Core 10) dem CMS Oqtane entschieden. Auch hier gab es einige Kandidaten:
+Mein Aufgabenbereich umfasst einerseits die Entwicklung eigener Module, sowie das Bereitstellen des Services. Als Betriebssystem habe ich mich für Linux entschieden, einfach, da ich mit Linux im Serverumfeld die meisten und besten Erfahrungen gemacht habe.
+
+Auch steht die Wahl der Programmiersprache und des CMS an. Nachdem wir im Unterricht fast ausschließlich mit C# entwickelt haben und nicht in eine komplett unbekannte Entwicklungsumgebung abdriften wollten, haben wir uns für die Webentwicklung mit ASP.NET Core 9 (Upgrade im Lauf der Diplomarbeit auf .NET Core 10) und dem CMS Oqtane entschieden. Auch hier gab es einige Kandidaten:
+
 - Piranha CMS
-  >Piranha erscheint auf den ersten Blick nicht so flexibel wie Oqtane, basiert auf .NET 8.0 und wird nicht so aktiv gewartet.
+  > Piranha erscheint auf den ersten Blick nicht so flexibel wie Oqtane, es basiert auf .NET 8.0 und wird nicht so aktiv gewartet.
 - Umbraco
-  >Viel Arbeit mit Partials, welche in der Admin Oberfläche geschieht, aber sehr gut dokumentiert. Im großen und ganzen wirkt Umbraco nicht so flexibel.
+  > Viel Arbeit mit Partials, welche in der Admin Oberfläche geschieht, aber sehr gut dokumentiert. Im Großen und Ganzen wirkt Umbraco nicht so flexibel.
 - DNN / Dot Net Nuke
-  >Platzhirsch. Kennt man, wird von der DNN Foundation gewartet. Arbeitet mit dem Dotnet Framework, welches nicht unter Linux läuft. Und ein Windows Server würde ich ich nicht einfach so ins Internet, abgesehen von den Lizenzkosten, die das kosten würde.
+  > Platzhirsch. Kennt man, wird von der DNN Foundation gewartet. Arbeitet mit dem Dotnet Framework, welches nicht unter Linux läuft. Und ein Windows Server würde ich ich nicht einfach so ins Internet, abgesehen von den Lizenzkosten, die das kosten würde.
 - Oqtane
-  >Schlecht dokumentiert, auf den ersten Blick sehr modular und flexibel. 
+  > Oqtane wirkt auf den ersten Blick sehr modular und flexibel, die schlechte Dokumentation ist erst im Nachhinein aufgefallen.
 
-Am Ende haben wir uns für das Oqtane Framework trotz seiner schlechten Dokumentation entschieden.
+Aufgrund seiner sehr hohen Flexibilität, haben wir uns am Ende für Oqtane entschieden.
 
-Im Bereich der Datenbanken musste ich mir ein paar Fragen stellen. 
-1. Auf welche Art Datenbank setzen wir? SQL, NoSQL, Graph, ... 
-2. Mit welcher speziellen implementiereung bekommen wir Support und haben Wissen im Team?
-3. Ist das auserkorene System kompatibel mit dem CMS auf dem wir aufbauen?
+Im Bereich der Datenbanken musste ich mir ein paar Fragen stellen:
 
-Es war von Anfang an klar, dass es ein SQL basiertes System wird, da wir im Team nur mit SQL-basierten Systemen erfahrungen haben. Außerdem unterstützt unser CMS (Oqtane) nur SQL basierte Systeme. In der Linuxwelt kommen jetzt nur noch ein paar Datenbanken in die Auswahl: PostgreSQL, MySQL / MariaDB, SQLite. Da ist die Wahl auf PostgreSQL gefallen. Grund dafür war meine Vorerfahrung mit diesem DBMS, welche ich im Nebenjob errungen habe.
+1. Auf welche Art Datenbank setzen wir? SQL, NoSQL, Graph, ...
+2. Mit welcher speziellen Implementierung bekommen wir Support und bei welcher haben wir Vorwissen im Team?
+3. Ist das auserkorene System kompatibel mit dem CMS, auf dem wir aufbauen?
 
+Es war von Anfang an klar, dass es ein SQL-basiertes System wird, da wir im Team nur mit SQL-basierten Systemen Erfahrungen haben. Außerdem unterstützt unser CMS (Oqtane) nur SQL-basierte Systeme. In der Linuxwelt kommen jetzt nur noch ein paar Datenbankmanagementsysteme in die Auswahl: PostgreSQL, MySQL / MariaDB, SQLite. Da ist die Wahl auf PostgreSQL gefallen. Grund dafür war meine Vorerfahrung mit diesem Datenbankmanagementsystem, welche ich in meinem Nebenjob errungen habe.
 
 # Technologie
+
 ## Was ist Oqtane? Architektur von Oqtane?
+
 Oqtane ist ein Framework und CMS zur Entwicklung von Webseiten mithilfe von ASP.NET und Blazor. [^5] Ein Oqtane-System besteht aus mehreren Komponenten.
 
 In dieser Diplomarbeit fokussieren wir uns hauptsächlich auf `Themes` und `Modules`, aber es gibt auch `Language Packs` und `Pure Extensions`. [^6]
 
-Ein `Module` (Modul) soll neue Funktionalitäten in das CMS hinzufügen und ein `Theme` soll die ganze Gestaltung der Website (die Shell) festlegen. [^6]
+Ein `Module` (Modul) soll neue Funktionalitäten in das CMS hinzufügen und ein `Theme` soll die ganze Gestaltung der Webseite (die Shell) festlegen. [^6]
 
 [^5]: https://www.oqtane.org/#about
+
 [^6]: https://docs.oqtane.org/dev/extensions/index.html
 
 ### Architektur eines Moduls
-Ein Modul in Oqtane besteht aus 4 Projekten. Server, Client, Shared und Package.
 
-Im Server-Projekt liegt Sourcecode, welcher serverseitig ausgeführt werden soll. In der Praxis bedeutet das: alle Repositories, Controller, Manager, Migrationen und Server-Services (entwickelt nach einem Interface definiert im Client) und Server-Startuplogik.
+Ein Modul in Oqtane besteht aus vier Projekten:
 
-Im Client-Projekt liegen Code und Razor-Komponenten für den Client. Also Client-Staruplogik, Client-Services (+ Inferfaces dafür, die Services hier sollen lediglich die Server-Services über HTTP aufrufen), Ressourcendateien (.resx), die Komponenten / das User Interface und die Moduldefinitionen für jedes Modul.
+- Im Server-Projekt liegt Sourcecode, welcher serverseitig ausgeführt werden soll. Dazu gehören unter anderem alle Repositories, Controller, Manager, Migrationen und Server-Services und Server-Startuplogik.
 
-Im Shared-Projekt wird geteilter Sourcecode abgelegt, der server- und clientseitig verwendet wird. In der Praxis bleibt es hierbei bei den EntityFramework-Modellen zum Speichern der Daten im Arbeitsspeicher.
+- Im Client-Projekt liegen Code und Razor-Komponenten für den Client. Also Client-Startuplogik, Client-Services, Ressourcendateien (.resx), die Komponenten / das User Interface und die Moduldefinitionen für jedes Modul.
 
-Im Package Projekt findet man Skripte zum Debuggen und Releasen eines Moduls. Und die NuGet-Spezifikation.
-- Beim Debug werden die DLLs, PDBs und statischen Assets wie Skripte und Stylesheets der 3 anderen Projekte in den bereits gebauten Oqtane.Server `oqtane.framework/oqtane.server/bin/debug/net10.0/...` kopiert.
-- Beim Release wird ein NuGet-Paket erstellt und unter oqtane.framework/oqtane.server/Packages abgelegt. Dort abgelegte NuGet-Pakete werden beim nächsten Start des Oqtane Servers installiert (DB Migrationen werden gemacht und die Pakete entpackt).
+- Im Shared-Projekt wird geteilter Sourcecode abgelegt, der server- und clientseitig verwendet wird. In der Praxis bleibt es hierbei bei den EntityFramework-Modellen zum Speichern der Daten im Arbeitsspeicher.
+
+- Im Package Projekt findet man Skripte zum Debuggen und Releasen eines Moduls und die NuGet-Spezifikation.
+  - Beim Debug werden die DLLs, PDBs und statischen Assets wie Skripte und Stylesheets der drei anderen Projekte in den bereits gebauten Oqtane.Server `oqtane.framework/oqtane.server/bin/debug/net10.0/...` kopiert.
+  - Beim Release wird ein NuGet-Paket erstellt und unter oqtane.framework/oqtane.server/Packages abgelegt. Dort abgelegte NuGet-Pakete werden beim nächsten Start des Oqtane Servers installiert (Datenbank Migrationen werden gemacht und die Pakete entpackt).
 
 ## Systemarchitektur (Postgres / Oqtane / Nginx)
 
-In diesem Kapitel erkläre ich wie die ausgewählten Komponenten zusammenspielen. Wir verwenden NginX als Reverse Proxy, welcher bei uns die SSL Terminierung macht. Das Zertifikat, welches verwendet wird, wird von Let's Encrypt bereit gestellt und mitels HTTP-Challanges und dem Certbot auf dem Server aktualisiert und verwaltet. Oqtane selber läuft als Systemd-Service im Kestrel Backend. Kestrel ist ein kleiner Webserver, welcher in das ASP.NET Core Framework eingebaut worden ist. Oqtane (bzw. der ASP.NET Core Server "Kestrel") hört auf der Loopback IP und Port 5000. Damit ist Oqtane nur durch NginX erreichbar. PostgreSQL ist die Datenbank in dem System: Sie hört wieder auf der Loopback IP und Port 5432.
+In diesem Kapitel erkläre ich wie die ausgewählten Komponenten zusammenspielen. Wir verwenden NginX als Reverse Proxy, welcher bei uns die SSL Terminierung macht. Das Zertifikat, welches verwendet wird, wird von Let's Encrypt bereit gestellt und mittels HTTP-Challenges und dem Certbot auf dem Server aktualisiert und verwaltet. Oqtane selber läuft als Systemd-Service im Kestrel Backend. Kestrel ist ein kleiner Webserver, welcher in das ASP.NET Core Framework eingebaut worden ist. Oqtane (bzw. der ASP.NET Core Server "Kestrel") hört auf der Loopback IP und Port 5000. Damit ist Oqtane nur durch NginX erreichbar. PostgreSQL ist die Datenbank in dem System: Sie hört wieder auf der Loopback IP und Port 5432.
 
 ```mermaid
 architecture-beta
@@ -83,29 +90,32 @@ architecture-beta
     service db(database)[PostgreSQL] in server
     service oqtane(server)[Oqtane] in server
     service nginx(server)[NginX] in server
-    
-    service internet(cloud)[Internet] 
+
+    service internet(cloud)[Internet]
 
     internet:R <--> L:nginx
     nginx:R <--> L:oqtane
     oqtane:R <--> L:db
 ```
 
-Zusätzlich gab es einen Administrationszugang zu den Servern, welcher über SSH möglich war. Dieser wurde für die Installation und Konfiguration der einzelnen Komponenten verwendet. Bei Hetzner war dieser Zugang nur über eine Wireguard VPN erreichbar. Bei der Schule war dieser Zugang direkt (über einen Hight-Port) möglich. Und bei LiveDesign war dieser Zugang wieder über eine VPN geregelt. Anfänglich mit SSL VPN, später mit einem IPSEC / Strongswan.
+Zusätzlich gab es einen Administrationszugang zu den Servern, welcher über SSH möglich war. Dieser wurde für die Installation und Konfiguration der einzelnen Komponenten verwendet. Bei Hetzner war dieser Zugang nur über eine Wireguard VPN erreichbar. Bei dem Schulserver war dieser Zugang direkt (über einen Hight-Port) möglich. Und bei LiveDesign war dieser Zugang wieder über eine VPN geregelt. Anfänglich mit SSL VPN, später mit einem IPSEC / Strongswan.
 
 ## Entwicklung mit ASP.NET (Was ist Blazor? / Was ist Razor? / Kestrel)
+
 ### Blazor [^7]
-Blazor ist ein kostenloses und quelloffenes Web-Framework, welches es Möglich macht, Benutzeroberflächen für Web-Browser basierend auf C# and HTML zu erstellen. Es wird von Microsoft als teil des ASP.NET Core Frameworks entwickelt. 
+
+Blazor ist ein kostenloses und quelloffenes Web-Framework, welches es möglich macht Benutzeroberflächen für Web-Browser, basierend auf C# and HTML, zu erstellen. Es wird von Microsoft als teil des ASP.NET Core Frameworks entwickelt.
 
 Blazor hat mehrere Hosting-Modelle:
-- Blazor Web App: Hier wird die Web App als Teil einer ASP.NET Core Anwendung bereitgestellt. Hier gibt es mehrere Render Modi:
-  - Static Server: Die Komponente wird serverseitig "gerenderet" und besitzt keine Interaktivität. Das istder Default `RenderMode`
-  - Interative Server: Die Komponente wird serverseitig "gerendert", diesmal ist sie jedoch interaktiv. Das bedeutet: Man kann mithilfe von C# den Zustand der Seite dynamisch bearbeiten. Diese Zustandsänderungen werden serverseitig bearbeitet. Hierbei kommunizieren Server und Client mithilfe von SignalR über WebSockets miteinander.
-  - Interactive WebAssembly: Die Komponente wird clientseitig, also im Browser, "gerendert". Damit der Blazor C# Code auch im Browser ausgeführt werden kann wird dieser in WebAssembly kompiliert.
-  - Interactive Auto: Im `Interactive Auto` Modul wird bei dem initialen Besuch der Website der `Interactive  Server` Modus gewählt und im Hintergrund wird der WebAssembly-Build heruntergeladen, damit bei weiteren Besuchen der Seite der `Interactive WebAssembly` Modus gewählt werden kann.
-- Hybrid: Dieser Modus ist der einzige, welcher nicht innerhalb einer Blazor Web App läuft, sondern in einem WebView einer Nativen App. Dabei wird innerhalb des Mutterprozesses, ganz ohne WebServer. Das ganze Funktioniert in WPF und WinForms Apps und in nativen mobilen Apps für Android und iOS mithilfe von .NET MAUI.
 
-Razor-Komponenten (in dieser Arbeit, sowie Umgangssprachlich, auch oft nur Komponenten genannt) sind der Grundbaustein für Blazor Web Apps. Sie bestehen aus HTML, welches mit der Verwendung von inline C# beeinflusst werden kann. Das Blazor stellt sicher, dass das gerenderte Markup aktualisiert wird, wenn sicher der Status der Komponente ändert. Dieser Code kann entweder vollständig in einer .razor Dateil liegen, oder in einer seperaten Code-Behind-Datei und der benutzer einer partiellen Klasse. Inline C# Code wird mithilfe von dem `@`- Zeichen markiert. Hier ist ein Beispiel für einen einfachen Counter:
+- Blazor Web App: Hier wird die Web App als Teil einer ASP.NET Core Anwendung bereitgestellt. Dabei gibt es mehrere Render Modi:
+  - Static Server: Die Komponente wird serverseitig gerendert und besitzt keine Interaktivität. Es ist der standardmäßige `RenderMode`
+  - Interactive Server: Die Komponente wird serverseitig gerendert, diesmal ist sie jedoch interaktiv. Das bedeutet, man kann mithilfe von C# den Zustand der Seite dynamisch bearbeiten. Diese Zustandsänderungen werden serverseitig bearbeitet. Hierbei kommunizieren Server und Client mithilfe von SignalR über WebSockets miteinander.
+  - Interactive WebAssembly: Die Komponente wird clientseitig, also im Browser, gerendert. Damit der Blazor C# Code auch im Browser ausgeführt werden kann, wird dieser in WebAssembly kompiliert.
+  - Interactive Auto: Im `Interactive Auto` Modul wird bei dem initialen Besuch der Website der `Interactive  Server` Modus gewählt und im Hintergrund wird der WebAssembly-Build heruntergeladen, damit bei weiteren Besuchen der Seite der `Interactive WebAssembly` Modus gewählt werden kann.
+- Hybrid: Dieser Modus ist der Einzige, welcher nicht innerhalb einer Blazor Web App läuft, sondern in einem WebView in einer Nativen App. Dabei wird innerhalb des Mutterprozesses, ganz ohne WebServer, der C# und Razor-Code ausgeführt. Das Ganze funktioniert in WPF und WinForms Apps und in nativen mobilen Apps für Android und iOS mithilfe von .NET MAUI.
+
+Razor-Komponenten (in dieser Arbeit, sowie umgangssprachlich, auch oft nur Komponenten genannt) sind der Grundbaustein für Blazor Web Apps. Sie bestehen aus HTML, welches mit der Verwendung von inline C# beeinflusst werden kann. Das Blazor stellt sicher, dass das gerenderte Markup aktualisiert wird, wenn sich der Status der Komponente ändert. Dieser Code kann entweder vollständig in einer .razor Datei liegen, oder in einer seperaten Code-Behind-Datei. Inline C# Code wird mithilfe von `@`- Zeichen markiert. Hier ist ein Beispiel für einen einfachen Counter:
 
 ```razor
 <h1>Counter</h1>
@@ -114,7 +124,7 @@ Razor-Komponenten (in dieser Arbeit, sowie Umgangssprachlich, auch oft nur Kompo
 
 <button @onclick="Increment">Increment</button>
 
-@code 
+@code
 {
     private int count = 0;
 
@@ -125,29 +135,34 @@ Razor-Komponenten (in dieser Arbeit, sowie Umgangssprachlich, auch oft nur Kompo
 }
 ```
 
-Mit`@count` in Zeile 3 wird der Wert der Variablen count in den `<p>` Tag mit eingebaut. Mit `@onclick="Increment"` in Zeile 5 wird die onclick Property vom `<button>`Tag auf die Increment Methode im C# Code. Der `@code` Block in Zeile 7 ist der C# Code, welcher diese Komponente dynamisch macht. Hier ist die Variable count definiert und die Methode Increment, welche dieser Komponente interaktiv macht. 
+Mit`@count` in Zeile 3 wird der Wert der Variablen count in den `<p>` Tag mit eingebaut. Mit `@onclick="Increment"` in Zeile 5 wird die onclick Property vom `<button>`Tag auf die Increment Methode im C# Code gesetzt. Der `@code` Block in Zeile 7 ist der C# Code, welcher diese Komponente dynamisch macht. Hier ist die Variable count und die Methode Increment definiert, welche dieser Komponente interaktiv macht.
 
-Razor hat auch eine Reihe an Keywords wie zum Beipsiel (nur Auszugsweise, bzw. die die wir verwendet haben):
-- namespace: Gibt den aktuellen Namespace in der Razor Datei ein
+Razor hat auch eine Reihe an Keywords, wie zum Beipsiel (nur Auszugsweise, bzw. die die wir verwendet haben):
+
+- namespace: Gibt den aktuellen Namespace in der Razor Datei an.
 - inherits: Gibt die Superklasse der generierten C# Klasse an.
 - using: Gibt die im C# Code benutzen/verfügbaren Namespaces an
 - foreach: Für Wiederholungen im Markup
-- if: Für verzweigungen im Markup
+- if: Für Verzweigungen im Markup
 
 [^7]: https://en.wikipedia.org/wiki/Blazor
 
-### Kommunikations zwischen Front und Backend
-Wie Front- und Backend miteinander interagieren hängt hauptsächlich vom Render Modus ab. Oqtane kann auf verschiedene Arten betrieben werden. Hierbei ist es dem Modulentwickler ziemlich egal, welche Art der Kommunikation (WebSockets, HTTP Long-Polling, REST) verwendet wird. 
+### Kommunikation zwischen Front- und Backend
+
+Wie Front- und Backend miteinander interagieren hängt hauptsächlich vom Render Modus ab. Oqtane kann auf verschiedene Arten betrieben werden. Hierbei ist es dem Modulentwickler ziemlich egal, welche Art der Kommunikation (WebSockets, HTTP Long-Polling, REST) verwendet wird.
 
 #### SignalR
-SignalR ist eine Libary aus für das ASP.NET Framework, welche es möglich macht Server zu Client komminikation zu betreiben. Oqtane verwendet im `Interactive Server (SignalR)` Render-Modus verwendet wird.
 
-## Dependency injection
+SignalR ist eine Library aus dem ASP.NET Framework, welche es möglich macht, Server zu Client Kommunikation zu betreiben. Oqtane verwendet SignalR im `Interactive Server (SignalR)` Render-Modus.
+
+## Dependency Injection
 
 ### Dependency Inversion Principle [^1]
+
 Das Dependency-Inversion-Principle (DIP / auf Deutsch: Abhängigkeits-Umkehr-Prinzip) ist eines von den fünf `SOLID` Prinzipien in der Softwareentwicklung.
 
 Das DIP unterscheidet zwischen high-level und low-level Modulen.
+
 - Die High-Level-Module beschreiben die Applikations- / Businesslogik, ohne direkt mit den Low-Level-Modulen zu interagieren, sondern lediglich auf Abstraktionen. [^3]
 - Die Abstraktionen sollen nicht von Implementierungsdetails abhängig sein, sondern die Low-Level-Implementierung sollen gemäß der Abstraktionsschicht implementiert werden. [^3]
 
@@ -155,26 +170,29 @@ Ausgangslage ist eine Softwarearchitektur im Direct-Dependency-Graph-Modell.
 
 ```mermaid
 architecture-beta
-    service a(mdi:package-variant-closed)[Klasse A] 
+    service a(mdi:package-variant-closed)[Klasse A]
     service b(mdi:package-variant-closed)[Klasse B]
 
     a:R --> L:b
 ```
+
 Bei diesem Beispiel ist die Klasse A ein high-level Modul, welches direkt auf die Klasse B referenziert, was das DI-Prinzip verbietet.
 Das Problem dabei: Die einzelnen Klassen sind eng gekoppelt, was das Austauschen von B mit einer anderen Klasse unmöglich macht. Genau dieses Problem wird vom DIP gelöst.
 
 ```mermaid
 architecture-beta
-    service a(mdi:package-variant-closed)[Klasse A] 
+    service a(mdi:package-variant-closed)[Klasse A]
     service b(mdi:package-variant-closed)[Klasse B]
     service ib(mdi:car-clutch)[Interface B]
 
     a:B --> T:ib
     ib:R <-- L:b
 ```
+
 Das High-Level-Modul ruft lediglich eine Abstraktion eines Low-Level-Moduls auf, welche von einem, oder mehreren Low-Level-Modulen implementiert wurde. Für das High-Level-Modul ist es hier egal, welches Low-Level-Modul die Implementierung bereitstellt. Dadurch erhält man einen viel modulareren Aufbau in der Software. Die einzelnen Module sind auch leichter austauschbar und testbar. Genau diese Modularität macht Dependency Injection möglich.
 
 ### Microsoft Dependency Injection Framework
+
 Dependency Injektion ist in .NET genau so wie Konfiguration, Protokollierung und das Optionsmuster ins Framework integriert. [^4]
 
 Alle Dependencies werden in einem `Service-Container` zur Verwaltung registriert. .NET hat einen eingebauten `Service-Container` (eine Implementierung des `IServiceProvider`). [^4]
@@ -182,6 +200,7 @@ Alle Dependencies werden in einem `Service-Container` zur Verwaltung registriert
 Das Dependency Injection Framework verwaltet alle Instanzen. Nach Bedarf werden Instanzen erstellt, oder wieder entsorgt (sofern das Service nicht mehr gebraucht wird). Beim Instanziieren einer Klasse werden alle im Konstruktor erwarteten Dependencies bereitgestellt, bzw. selbst instanziiert und dannach bereitgestellt. [^4]
 
 Hier ein Beispiel aus der Dokumentation von Microsoft: [^4]
+
 ```c#
 HostApplicationBuilder builder = Host.CreateApplicationBuilder(args);
 
@@ -217,9 +236,10 @@ public sealed class Worker(IMessageWriter messageWriter) : BackgroundService
     }
 }
 ```
+
 Das ist ein simples Beispiel, welches Teile des DI Frameworks zeigt. Wir haben einen Service (Klasse Worker), ein Dependency (Klasse MessageWriter) und eine Abstraktionsebene, von dem Dependency (Interface IMessageWriter).
 
-Bei Programmstart wird zuerst manuell der `Service-Container` erstellt, dannach alle Module registriert (entweder als HostedService, oder als Modul mit einer spezifischen Lifetime (Scoped, Transient, Singleton)). 
+Bei Programmstart wird zuerst manuell der `Service-Container` erstellt, dannach alle Module registriert (entweder als HostedService, oder als Modul mit einer spezifischen Lifetime (Scoped, Transient, Singleton)).
 
 Mit dem Aufruf von `builder.Build()` wird intern ein Dependency Graph erstellt und mit `host.Run()` wird versucht die Klasse Worker zu instanziieren und zu starten. Nachdem Worker ein Dependency auf IMessageWriter hat, wird über den zuvor erstellten Dependency-Graph die Implementierung von IMessageWriter gesucht. Jetzt wird MessageWriter instanziiert und dem Konstruktor von Worker übergeben, damit seine Dependencies befriedigt werden.
 
@@ -227,7 +247,7 @@ So sieht der Abhängigkeitsgraph bei diesem Beispiel aus.
 
 ```mermaid
 architecture-beta
-    service a(mdi:package-variant-closed)[Worker] 
+    service a(mdi:package-variant-closed)[Worker]
     service b(mdi:package-variant-closed)[MessageWriter]
     service ib(mdi:car-clutch)[IMessageWriter]
 
@@ -266,10 +286,15 @@ Anwendungen von Gitea Actions bei dieser Diplomarbeit:
   > Zum automatischen Überprüfen der Dokumente, unter anderem, mithilfe von KI, wie zum Beispiel Gemini.
 
 # Projektmanagement
+
 ## Scrum
+
 ## YouTrack
+
 ## Gitea (mit Issues)
+
 ## Git
+
 ## Kommunikation
 
 # Learnings
@@ -287,20 +312,21 @@ Nachdem ich mich von Anfang an volkommen in das Deploymentproblem von Oqtane ges
 Ein wesentliches Learning aus dem Projektverlauf war die Diskrepanz zwischen der initialen Planung und dem tatsächlichen Aufwand. Ursprünglich wurde der Zeitaufwand für das Aufsetzen der Infrastruktur und die Einarbeitung in das Oqtane-Framework auf etwa drei Wochen geschätzt. In der Realität nahm dieser Prozess jedoch mehrere Monate in Anspruch.
 
 Es gibt mehrere Gründe dafür:
+
 - `Fehlende oder nur schlechte Dokumentation von Oqtane`: Einige Probleme im Deployment wurden in langer und mühseliger Arbeit auseinander gebrochen und in weitere immer kleinere Probleme unterteilt. Dadurch, dass wir alle keine Erfahrung mit der Entwicklung und dem Deployment von ASP.NET Code Anwendungen hatten und die Dokumentation doch schlecht war, blieb uns manchmal nichts anderes übrig als mit WireShark den Netzwerktraffic mit zu schneiden und nebenbei im Git Repository die geloggten Zeilen Code zu finden und so das Framework von innen heraus kennen zu lernen. Dadurch hatte ich dann nach einer Einarbeitungszeit von 4 Monaten ziemlich jede Stelle im Sourcecode von Oqtane gesehen und finde mich um das schneller zurecht.
 - `Team-Konsolidierung`: Durch das notwendige Downsizing des Teams mussten Aufgaben neu verteilt werden, was die individuelle Arbeitslast erhöhte und die Konzentration auf die Kernentwicklung zeitweise verzögert hat.
 - `Abhängigkeit von der Infrastruktur`: Dadurch, dass wir bis in den Oktober / November hinein nicht wussten, ob wir weiter bei Oqtane bleiben können, haben die anderen Teammitglieder nicht mit der sinnvollen Entwicklung ihrer Module starten können. Zitat: "Und was wenn wir am Ende doch noch das CMS umstellen müssen?" => Auch wenn der Auftrag war, mit der Modulentwicklung zu starten war die Motivation meiner Teammitglieder nicht so hoch. Selbst wenn sie nicht direkt von der Infrastruktur mit der Ausführung ihrer Aufgaben abhängig waren, motiviert waren sie wegen der Umstände auch nicht.
-  
+
 Reaktion auf den Verzug:
 Um das Projektziel dennoch zu erreichen, wurde der Zeitplan im Herbst 2025 massiv gestrafft. Durch die Umstellung auf einen strikteren 14-tägigen Sprint-Rhythmus und die Priorisierung von Core-Funktionalitäten (MVP-Ansatz) konnte der Rückstand teilweise aufgeholt werden.
 
-
 > Fazit: Die Erfahrung zeigt, dass gerade bei "Nischen-Frameworks" wie Oqtane ein deutlich höherer Puffer für die Einarbeitungs- und Infrastrukturphase (Faktor 2 bis 3 der ursprünglichen Schätzung) eingeplant werden muss.
 
 `90% fertig, oder fertig?`: Es gibt einige "Regeln", wie: das `Paretoprinzip`, `Hofstadter’s Law` und die `90-90 Regel`. Letztere wurde im Jahr 1985 von Jon Bentley in einer Kolumne "Programming pearls" veröffentlicht. Ausgeschrieben lautet sie:
+
 > [Rule of Credibility] The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
-(Jon Bentley. 1985. Programmimg pearls. Commun. ACM 28, 9 (Sept. 1985), 896–901. https://doi.org/10.1145/4284.315122) [^8]
-Diese Diplomarbeit liefert weitere Evidenz, dass diese Faustregel stimmt.
+> (Jon Bentley. 1985. Programmimg pearls. Commun. ACM 28, 9 (Sept. 1985), 896–901. https://doi.org/10.1145/4284.315122) [^8]
+> Diese Diplomarbeit liefert weitere Evidenz, dass diese Faustregel stimmt.
 
 [^8](https://dl.acm.org/doi/10.1145/4284.315122)
 
@@ -313,6 +339,7 @@ Ein zentrales Problem in unserer ursprünglichen Arbeitsweise war die Kopplung v
 - Ineffizienz: Lange Präsenz-Meetings blockierten wertvolle Entwicklungszeit, ohne die technische Qualität zu steigern.
 
 Lösungsansatz: Meetings und Besprechungen asynchron zueinander setzen.
+
 - Asynchrone Daily-Updates: Statusberichte erfolgen schriftlich (z. B. in Gitea Issues oder YouTrack), nicht mehr in stundenlangen Call-Marathons. Das nimmt den zeitlichen Druck vom einzelnen Entwickler. Oder zumindest in kurzen Commitnachrichten, welche am Ende des Tages automatisch an alle Teammitglieder zum überblick gesendet werden (eventuell mit @username tagging, um eine Person nochmal genau anzusprechen)
 - Review-First-Policy: Ein Feature gilt erst dann als „fertig“, wenn es einen asynchronen Code-Review-Prozess durchlaufen hat. Das Meeting dient nur noch der Klärung von Blockern, nicht der Präsentation von Code. Das war eigentlich schon von Anfang an in unserer `Definition of Done` festgelegt worden.
 - Entkoppelung von Meeting und Deadline: Meetings sollten der Synchronisation dienen, während die Abgabe von Arbeitspaketen kontinuierlich (Continuous Integration) erfolgen muss, um Lastspitzen (in der [Gitea Actions](#Continuous Integration) Pipeline) am Tag der Besprechung zu vermeiden.
@@ -338,10 +365,11 @@ Für den tatsächlichen Versand der E-Mails nutzen wir den Cloud-Dienst Brevo. D
 Das Token Lifetime Modul wurde geschrieben, um die Token-Lebenszeit konfigurierbar zu machen. Notwendig war das, um die Passwort Reset Links im initialen Mail versand länger gultig sein zu lassen. Durch das `Batch Processing` war es Möglich, dass eine Mail erst Tage nach erstellen des Links hinaus geschickt wird und bei einer Standard Ablaufdauer von 2 Tagen sind machne Links schon ungültig, bis sie den Mail Server erreichen. Ziel war es, die Änderung der Lebenszeit für Administratoren im User Interface im Admin Bereich möglich zu machen.
 
 Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
-- `der Workarround`:  Ein eigenes Modul, welches in seiner `Server/Startup.cs` die benötigten Werte korrekt setzt. Das hat den Vorteil, dass wir keine Änderungen im CMS selbst haben, sondern nur unsere eigene Erweiterung dafür schreiben. Andererseits könnte durch die undeterminischte Ladereihenfolge eine `race-condition` auftreten. Darüberhinaus haben wir keinen gleichzeitigen Zugriff auf appsettings.json und den IServiceProvider in dem wir die Konfiguration setzen müssen. => Nachdem wir in der Konfigurationsphase auch noch keinen Datenbankzugriff haben, können wir die Werte nicht aus der DB Laden, sondern müssen auf eine Text Datei zurückgreifen.
-- `die saubere Lösung`:  Eine Änderung im Kern von Oqtane. Also implementieren wir in unserem Fork von Oqtane die Konfigurationslogik für die Tokenlifetime. Hier könnte die Konfigurationslogik direkt in `OqtaneServiceCollectionExtensions.cs` hinzufügen, hier werden auch alle anderen Oqtane Spezifischen Configurationen gesetzt. Das hat den Vorteil, dass der Code aufgeräumter und sauberer ist und die `race-condition` verhindert werden kann. Der initiale Grund dagegen ist, dass wir ein weiteres Git Repository zum warten haben (den Fork vom Oqtane.Framework), welches jetzt nicht mehr mit Upstream Commit-gleich ist.
 
-`Der Workarround` ist die Möglichkeit für die wir uns zuerst entschieden haben, allerdings haben wir uns im Nachhinein noch umentschlossen und wollen `die saubere Lösung` implementieren. 
+- `der Workarround`: Ein eigenes Modul, welches in seiner `Server/Startup.cs` die benötigten Werte korrekt setzt. Das hat den Vorteil, dass wir keine Änderungen im CMS selbst haben, sondern nur unsere eigene Erweiterung dafür schreiben. Andererseits könnte durch die undeterminischte Ladereihenfolge eine `race-condition` auftreten. Darüberhinaus haben wir keinen gleichzeitigen Zugriff auf appsettings.json und den IServiceProvider in dem wir die Konfiguration setzen müssen. => Nachdem wir in der Konfigurationsphase auch noch keinen Datenbankzugriff haben, können wir die Werte nicht aus der DB Laden, sondern müssen auf eine Text Datei zurückgreifen.
+- `die saubere Lösung`: Eine Änderung im Kern von Oqtane. Also implementieren wir in unserem Fork von Oqtane die Konfigurationslogik für die Tokenlifetime. Hier könnte die Konfigurationslogik direkt in `OqtaneServiceCollectionExtensions.cs` hinzufügen, hier werden auch alle anderen Oqtane Spezifischen Configurationen gesetzt. Das hat den Vorteil, dass der Code aufgeräumter und sauberer ist und die `race-condition` verhindert werden kann. Der initiale Grund dagegen ist, dass wir ein weiteres Git Repository zum warten haben (den Fork vom Oqtane.Framework), welches jetzt nicht mehr mit Upstream Commit-gleich ist.
+
+`Der Workarround` ist die Möglichkeit für die wir uns zuerst entschieden haben, allerdings haben wir uns im Nachhinein noch umentschlossen und wollen `die saubere Lösung` implementieren.
 
 ((Quellen einfügen: Configure Token for Email versand und Race Conditions beschreiben.))
 
@@ -350,6 +378,7 @@ Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
 Eine weitere Anforderung der Diplomarbeit war es Einträge in Modulen wie der `Hall of Fame`, dem `Schwarzen Brett` und dem Premium Bereich (`Engineer Applications`) melden zu können. Am Anfang war es wichtig, dass jeder schnell vorrankommt, allerdings haben wir die Kommunikation Teamintern ein wenig verschlafen und dadurch ein paar Funktionen doppelt geschrieben. Dadurch kam es zu inkonsistenzen in der Verwendung der unterschiedlichen Reporting Systeme. Deswegen haben wir uns am Ende für eine globales Reporting System entschieden.
 
 Angestrebt wurde folgender Ablauf für das Melden eines Eintrags:
+
 ```mermaid
 sequenceDiagram
     participant Module
@@ -358,12 +387,12 @@ sequenceDiagram
     participant ReportingHandler
     User->>+Module: View: Entity
     User->>+ReportingComponent: Report current Entity
-    
+
     rect rgba(0, 0, 0, 0)
     ReportingComponent->>+User: Ask for reason
     User->>-ReportingComponent: Enters Reason
     end
-    
+
     ReportingComponent->>+ReportingHandler: New Report (includes entity and reason)
     ReportingComponent->>-User: Done
 ```
@@ -387,4 +416,5 @@ Die Implementierung des IReportingComponents stellt nur eine Property (`ReportTy
 Die Bereitstellund des Moduls geschieht im `AdminModules` Modul.
 
 ## Event Registration
-## Schwarzes Brett
\ No newline at end of file
+
+## Schwarzes Brett

From 3949ff6c19771c1e1d87ea45e5ae96875df38915 Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Tue, 17 Mar 2026 12:52:29 +0000
Subject: [PATCH 11/22] Umschreiben der CMS Vergleiche

---
 ...beitsbuch-individueller-teil-Konstantin-Hintermayer.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index 9e03833..aeebd71 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -35,13 +35,13 @@ Auch steht die Wahl der Programmiersprache und des CMS an. Nachdem wir im Unterr
 - Piranha CMS
   > Piranha erscheint auf den ersten Blick nicht so flexibel wie Oqtane, es basiert auf .NET 8.0 und wird nicht so aktiv gewartet.
 - Umbraco
-  > Viel Arbeit mit Partials, welche in der Admin Oberfläche geschieht, aber sehr gut dokumentiert. Im Großen und Ganzen wirkt Umbraco nicht so flexibel.
+  > Bei Umbraco muss viel in der Admin Oberfläche von dem CMS gearbeitet werden, im Großen und Ganzen wirkt dieses CMS nicht so flexibel. Die Dokumentation wirkt auf den ersten Blick sehr gut!
 - DNN / Dot Net Nuke
-  > Platzhirsch. Kennt man, wird von der DNN Foundation gewartet. Arbeitet mit dem Dotnet Framework, welches nicht unter Linux läuft. Und ein Windows Server würde ich ich nicht einfach so ins Internet, abgesehen von den Lizenzkosten, die das kosten würde.
+  > Dieses CMS ist der Platzhirsch. Es wird von der DNN Foundation gewartet, arbeitet mit dem Dotnet Framework, welches nicht unter Linux läuft. Und ein Windows Server ist im Betrieb teurer und in der Absicherung aufwändiger.
 - Oqtane
-  > Oqtane wirkt auf den ersten Blick sehr modular und flexibel, die schlechte Dokumentation ist erst im Nachhinein aufgefallen.
+  > Oqtane wirkt auf sehr modular und flexibel, auch innerhalb von Modulen kann man auf alle funktionen des ASP.NET Core Frameworks verwenden. Die Dokumentation wirkt nicht besonders gut, aber ausreichend. Die enthaltenen Fehlinformationen und mangelnden Anleitungen für den Betrieb mit Linux sind erst im Nachhinein aufgefallen.
 
-Aufgrund seiner sehr hohen Flexibilität, haben wir uns am Ende für Oqtane entschieden.
+Insbesondere aufgrund seiner sehr hohen Flexibilität, haben wir uns am Ende für Oqtane entschieden.
 
 Im Bereich der Datenbanken musste ich mir ein paar Fragen stellen:
 

From 7d22c3281f626bb60368fdb7d8a16735dd31b881 Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Wed, 18 Mar 2026 10:54:01 +0000
Subject: [PATCH 12/22] New: Dependency Injection Grundlagen & Einleitung

---
 ...dividueller-teil-Konstantin-Hintermayer.md | 22 ++++++++++++++++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index aeebd71..c36feec 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -81,7 +81,7 @@ Ein Modul in Oqtane besteht aus vier Projekten:
 
 ## Systemarchitektur (Postgres / Oqtane / Nginx)
 
-In diesem Kapitel erkläre ich wie die ausgewählten Komponenten zusammenspielen. Wir verwenden NginX als Reverse Proxy, welcher bei uns die SSL Terminierung macht. Das Zertifikat, welches verwendet wird, wird von Let's Encrypt bereit gestellt und mittels HTTP-Challenges und dem Certbot auf dem Server aktualisiert und verwaltet. Oqtane selber läuft als Systemd-Service im Kestrel Backend. Kestrel ist ein kleiner Webserver, welcher in das ASP.NET Core Framework eingebaut worden ist. Oqtane (bzw. der ASP.NET Core Server "Kestrel") hört auf der Loopback IP und Port 5000. Damit ist Oqtane nur durch NginX erreichbar. PostgreSQL ist die Datenbank in dem System: Sie hört wieder auf der Loopback IP und Port 5432.
+In diesem Kapitel erkläre ich wie die ausgewählten Komponenten zusammenspielen. Wir verwenden NginX als Reverse Proxy, welcher bei uns die SSL Terminierung macht. Das Zertifikat, welches verwendet wird, wird von Let's Encrypt bereit gestellt und mittels HTTP-Challenges und dem Certbot auf dem Server aktualisiert und verwaltet. Oqtane selber läuft als Systemd-Service im Kestrel Backend. Kestrel ist ein kleiner Webserver, welcher in das ASP.NET Core Framework eingebaut worden ist. Oqtane (bzw. der ASP.NET Core Server "Kestrel") hört auf der Loopback IP und Port 5000. Damit ist Oqtane nur durch NginX erreichbar. PostgreSQL ist die Datenbank in dem System: Sie hört wieder auf der Loopback IP und Port 5432. In der folgenden Grafik ist das System Schematisch dargestellt.
 
 ```mermaid
 architecture-beta
@@ -98,7 +98,15 @@ architecture-beta
     oqtane:R <--> L:db
 ```
 
-Zusätzlich gab es einen Administrationszugang zu den Servern, welcher über SSH möglich war. Dieser wurde für die Installation und Konfiguration der einzelnen Komponenten verwendet. Bei Hetzner war dieser Zugang nur über eine Wireguard VPN erreichbar. Bei dem Schulserver war dieser Zugang direkt (über einen Hight-Port) möglich. Und bei LiveDesign war dieser Zugang wieder über eine VPN geregelt. Anfänglich mit SSL VPN, später mit einem IPSEC / Strongswan.
+Zusätzlich gab es einen Administrationszugang zu den Servern, welcher über SSH möglich war. Dieser wurde für die Installation und Konfiguration der einzelnen Komponenten verwendet. Der SSH Service ist in jeder Umgebung anders erreichbar gewesen. 
+
+| Umgebung   | Administrationszugang |
+| ---------- | --------------------- | 
+| Hetzner    | Wireguard             |
+| Schule     | Highport              |
+| LiveDesign | IPSEC VPN             |
+
+Die VPN basierten Zugänge sind tendenziell schwieriger zu finden und auszunutzen, während die Lösung in der Schule mittels Highport den SSH Service öffentlich erreichbar macht. Durch den `Highport` ist der SSH Service schwieriger zu finden. Zur Authentifizierung mit SSH verwenden wir SSH-Keys, da diese durch ihre komplexität sicherer sind, als Passwörter.
 
 ## Entwicklung mit ASP.NET (Was ist Blazor? / Was ist Razor? / Kestrel)
 
@@ -157,6 +165,14 @@ SignalR ist eine Library aus dem ASP.NET Framework, welche es möglich macht, Se
 
 ## Dependency Injection
 
+Dependency Injection ist ein Entwurfsmuster, bei dem die Abhängigkeiten eines Objekts nicht von diesem selbst erzeugt, sondern von außen „injiziert“ werden.
+
+Wie der Software-Architekt Martin Fowler, der den Begriff im Jahr 2004 maßgeblich prägte, beschreibt, geht es im Kern darum, die Erzeugung von Objekten von deren Nutzung zu trennen [^9]. Anstatt dass eine Klasse ihre Hilfsobjekte mittels des new-Operators selbst instanziiert, werden ihr diese meist über den Konstruktor zur Verfügung gestellt. 
+
+In den folgenden beiden Kapiteln wird das Dependency Inversion Principle und das Microsoft Dependency Injection Framework genauer vorgestellt.
+
+[^9]: https://martinfowler.com/articles/injection.html
+
 ### Dependency Inversion Principle [^1]
 
 Das Dependency-Inversion-Principle (DIP / auf Deutsch: Abhängigkeits-Umkehr-Prinzip) ist eines von den fünf `SOLID` Prinzipien in der Softwareentwicklung.
@@ -328,7 +344,7 @@ Um das Projektziel dennoch zu erreichen, wurde der Zeitplan im Herbst 2025 massi
 > (Jon Bentley. 1985. Programmimg pearls. Commun. ACM 28, 9 (Sept. 1985), 896–901. https://doi.org/10.1145/4284.315122) [^8]
 > Diese Diplomarbeit liefert weitere Evidenz, dass diese Faustregel stimmt.
 
-[^8](https://dl.acm.org/doi/10.1145/4284.315122)
+[^8]: https://dl.acm.org/doi/10.1145/4284.315122
 
 ## Sprints und Meetings (in Zukunft ja asynchron)
 

From 05125e8b86305d52ff7673b9356b584b5a56ae1e Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Wed, 18 Mar 2026 11:44:55 +0000
Subject: [PATCH 13/22] Quellen: Tokenlifetime und E-Mail Tippfehler und
 Workaround tippfehler

---
 ...dividueller-teil-Konstantin-Hintermayer.md | 24 +++++++++++--------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index c36feec..fe9db48 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -98,10 +98,10 @@ architecture-beta
     oqtane:R <--> L:db
 ```
 
-Zusätzlich gab es einen Administrationszugang zu den Servern, welcher über SSH möglich war. Dieser wurde für die Installation und Konfiguration der einzelnen Komponenten verwendet. Der SSH Service ist in jeder Umgebung anders erreichbar gewesen. 
+Zusätzlich gab es einen Administrationszugang zu den Servern, welcher über SSH möglich war. Dieser wurde für die Installation und Konfiguration der einzelnen Komponenten verwendet. Der SSH Service ist in jeder Umgebung anders erreichbar gewesen.
 
 | Umgebung   | Administrationszugang |
-| ---------- | --------------------- | 
+| ---------- | --------------------- |
 | Hetzner    | Wireguard             |
 | Schule     | Highport              |
 | LiveDesign | IPSEC VPN             |
@@ -167,7 +167,7 @@ SignalR ist eine Library aus dem ASP.NET Framework, welche es möglich macht, Se
 
 Dependency Injection ist ein Entwurfsmuster, bei dem die Abhängigkeiten eines Objekts nicht von diesem selbst erzeugt, sondern von außen „injiziert“ werden.
 
-Wie der Software-Architekt Martin Fowler, der den Begriff im Jahr 2004 maßgeblich prägte, beschreibt, geht es im Kern darum, die Erzeugung von Objekten von deren Nutzung zu trennen [^9]. Anstatt dass eine Klasse ihre Hilfsobjekte mittels des new-Operators selbst instanziiert, werden ihr diese meist über den Konstruktor zur Verfügung gestellt. 
+Wie der Software-Architekt Martin Fowler, der den Begriff im Jahr 2004 maßgeblich prägte, beschreibt, geht es im Kern darum, die Erzeugung von Objekten von deren Nutzung zu trennen [^9]. Anstatt dass eine Klasse ihre Hilfsobjekte mittels des new-Operators selbst instanziiert, werden ihr diese meist über den Konstruktor zur Verfügung gestellt.
 
 In den folgenden beiden Kapiteln wird das Dependency Inversion Principle und das Microsoft Dependency Injection Framework genauer vorgestellt.
 
@@ -364,7 +364,7 @@ Lösungsansatz: Meetings und Besprechungen asynchron zueinander setzen.
 
 ## Admin Modules
 
-Eine C#-Solution, welche einige Module, welche für den Admineinsatz geschrieben worden sind beinhaltet. Dieses Modul besteht aus 3 Teilmodulen. Einem Modul für den Versand von Rundmails, eines für die Einstellung von der Token Lebenszeit bei Tokens, welche per EMail verschickt werden und eines, welches das Reporting-System übernimmt.
+Eine C#-Solution, welche einige Module, welche für den Admineinsatz geschrieben worden sind beinhaltet. Dieses Modul besteht aus 3 Teilmodulen. Einem Modul für den Versand von Rundmails, eines für die Einstellung von der Token Lebenszeit bei Tokens, welche per E-Mail verschickt werden und eines, welches das Reporting-System übernimmt.
 
 ### Mass Mailing
 
@@ -372,22 +372,26 @@ Das Mass Mailer Modul ist eine administrative Erweiterung für den Alumnihub, di
 
 Integration von Brevo
 
-Für den tatsächlichen Versand der E-Mails nutzen wir den Cloud-Dienst Brevo. Dieser bietet eine zuverlässige Zustellung (hohe Reputation der Mailserver), stellt uns jedoch in der kostenlosen Variante vor eine Herausforderung: nur 300 EMails pro Tag.
+Für den tatsächlichen Versand der E-Mails nutzen wir den Cloud-Dienst Brevo. Dieser bietet eine zuverlässige Zustellung (hohe Reputation der Mailserver), stellt uns jedoch in der kostenlosen Variante vor eine Herausforderung: nur 300 E-Mails pro Tag.
 
-`Batch-Processing`: Mails werden nicht sofort ("Fire and Forget") versendet, sondern in eine Versandwarteschlange geschrieben. Nachdem schon die Notifications Infrastruktur, welche sich auch um den Mail versand kümmert, ins Framework eingebaut worden ist, nutzen wir diese geleich und `schedulen` unsere EMails. Immer 100 Mails alle 24 Stunden bis alle Ziele die Mails erhalten haben. Das Limit von 100 / Tag ist konservativ sehr niedrig angesetzt, damit funktionen wie Passwort Reset Mails nicht (leicht) dadurch beeinflusst werden können.
+`Batch-Processing`: Mails werden nicht sofort ("Fire and Forget") versendet, sondern in eine Versandwarteschlange geschrieben. Nachdem schon die Notifications Infrastruktur, welche sich auch um den Mail versand kümmert, ins Framework eingebaut worden ist, nutzen wir diese geleich und `schedulen` unsere E-Mails. Immer 100 Mails alle 24 Stunden bis alle Ziele die Mails erhalten haben. Das Limit von 100 / Tag ist konservativ sehr niedrig angesetzt, damit funktionen wie Passwort Reset Mails nicht (leicht) dadurch beeinflusst werden können.
 
 ### Token Lifetime
 
 Das Token Lifetime Modul wurde geschrieben, um die Token-Lebenszeit konfigurierbar zu machen. Notwendig war das, um die Passwort Reset Links im initialen Mail versand länger gultig sein zu lassen. Durch das `Batch Processing` war es Möglich, dass eine Mail erst Tage nach erstellen des Links hinaus geschickt wird und bei einer Standard Ablaufdauer von 2 Tagen sind machne Links schon ungültig, bis sie den Mail Server erreichen. Ziel war es, die Änderung der Lebenszeit für Administratoren im User Interface im Admin Bereich möglich zu machen.
 
+Technisch bedeutet das, dass die standardmäßig vorkonfigurierten `DataProtectionTokenProviderOptions` explizit konfiguriert werden müssen. [^10] Der ASP.NET Core `UserManager`, welcher das generieren der Tokens übernimmt, verwendet einen `DataProtectorTokenProvider` und dieser wiederum kann mithilfe der `DataProtectionTokenProviderOptions` konfiguriert werden.
+
 Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
 
-- `der Workarround`: Ein eigenes Modul, welches in seiner `Server/Startup.cs` die benötigten Werte korrekt setzt. Das hat den Vorteil, dass wir keine Änderungen im CMS selbst haben, sondern nur unsere eigene Erweiterung dafür schreiben. Andererseits könnte durch die undeterminischte Ladereihenfolge eine `race-condition` auftreten. Darüberhinaus haben wir keinen gleichzeitigen Zugriff auf appsettings.json und den IServiceProvider in dem wir die Konfiguration setzen müssen. => Nachdem wir in der Konfigurationsphase auch noch keinen Datenbankzugriff haben, können wir die Werte nicht aus der DB Laden, sondern müssen auf eine Text Datei zurückgreifen.
-- `die saubere Lösung`: Eine Änderung im Kern von Oqtane. Also implementieren wir in unserem Fork von Oqtane die Konfigurationslogik für die Tokenlifetime. Hier könnte die Konfigurationslogik direkt in `OqtaneServiceCollectionExtensions.cs` hinzufügen, hier werden auch alle anderen Oqtane Spezifischen Configurationen gesetzt. Das hat den Vorteil, dass der Code aufgeräumter und sauberer ist und die `race-condition` verhindert werden kann. Der initiale Grund dagegen ist, dass wir ein weiteres Git Repository zum warten haben (den Fork vom Oqtane.Framework), welches jetzt nicht mehr mit Upstream Commit-gleich ist.
+- `der Workaround`: Ein eigenes Modul, welches in seiner `Server/Startup.cs` die benötigten Werte korrekt setzt. Das hat den Vorteil, dass wir keine Änderungen im CMS selbst haben, sondern nur unsere eigene Erweiterung dafür schreiben. Andererseits könnte durch die undeterminischte Ladereihenfolge eine `race-condition` auftreten. [^11] Darüberhinaus haben wir keinen gleichzeitigen Zugriff auf appsettings.json und den IServiceProvider in dem wir die Konfiguration setzen müssen. => Nachdem wir in der Konfigurationsphase auch noch keinen Datenbankzugriff haben, können wir die Werte nicht aus der DB Laden, sondern müssen auf eine Text Datei zurückgreifen.
+- `die saubere Lösung`: Eine Änderung im Kern von Oqtane. Also implementieren wir in unserem Fork von Oqtane die Konfigurationslogik für die Tokenlifetime. Hier könnte die Konfigurationslogik direkt in `OqtaneServiceCollectionExtensions.cs` hinzufügen, hier werden auch alle anderen Oqtane Spezifischen Configurationen gesetzt. Das hat den Vorteil, dass der Code aufgeräumter und sauberer ist und die `race-condition` verhindert werden kann. [^11] Der initiale Grund dagegen ist, dass wir ein weiteres Git Repository zum warten haben (den Fork vom Oqtane.Framework), welches jetzt nicht mehr mit Upstream Commit-gleich ist.
 
-`Der Workarround` ist die Möglichkeit für die wir uns zuerst entschieden haben, allerdings haben wir uns im Nachhinein noch umentschlossen und wollen `die saubere Lösung` implementieren.
+`Der Workaround` ist die Möglichkeit für die wir uns entschieden haben, allerdings ist das nicht die schönste Lösung. Eine eventuell nachfolgende Diplomarbeit kann an dieser Stelle ansetzen und `die saubere Lösung` implementieren.
 
-((Quellen einfügen: Configure Token for Email versand und Race Conditions beschreiben.))
+[^10]: https://andrewlock.net/implementing-custom-token-providers-for-passwordless-authentication-in-asp-net-core-identity/#changing-the-default-token-lifetime
+
+[^11]: https://www.cs.umd.edu/projects/syschat/raceConditions.pdf
 
 ### Reporting System
 

From 7970ec6a9d1e529b6019aad75071053019b28948 Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Wed, 18 Mar 2026 12:26:49 +0000
Subject: [PATCH 14/22] Update: TOC / Struktur in dem Buch

---
 ...dividueller-teil-Konstantin-Hintermayer.md | 170 +++++++++---------
 1 file changed, 89 insertions(+), 81 deletions(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index fe9db48..341e48a 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -7,7 +7,7 @@ gitea: none
 
 In diesem Abschnitt wird meine persönliche Aufgabenstellung im Rahmen des Projektes (`Alumnihub`) beschrieben.
 
-### Auftrag / persönliche Aufgabenstellungen
+### 1.1 Auftrag / persönliche Aufgabenstellungen
 
 Meine Zuständigkeiten und Verantwortlichkeiten:
 
@@ -17,18 +17,26 @@ Meine Zuständigkeiten und Verantwortlichkeiten:
 - Auswertungen
 - Schwarzes Brett
 
-### Motivation
+### 1.2 Motivation
 
 Lernen von ASP.NET und der Entwicklung mit Blazor und Oqtane. Ich habe Interesse an dem Thema Webentwicklung. Privat entwickle ich schon seit Jahren viel mit React.JS.
 
 ## 2. Anforderungen an das entwickelte Modul bzw. die Funktionalität
 
+### 2.1 Modulanforderungen / funktionale Anforderungen
+
+### 2.2 Infrastrukturanforderungen / nicht‑funktionale Anforderungen
+
 - funktionale / nicht‑funktionale Anforderungen
 - Use Cases
 
-## 3. Technische Grundlagen
+## 3. Technisches Umfeld
 
-Mein Aufgabenbereich umfasst einerseits die Entwicklung eigener Module, sowie das Bereitstellen des Services. Als Betriebssystem habe ich mich für Linux entschieden, einfach, da ich mit Linux im Serverumfeld die meisten und besten Erfahrungen gemacht habe.
+Mein Aufgabenbereich umfasst einerseits die Entwicklung eigener Module, sowie das Bereitstellen des Services.
+
+### 3.1 Auswahlverfahren
+
+#### 3.1.1 Entscheidungsfindung CMS
 
 Auch steht die Wahl der Programmiersprache und des CMS an. Nachdem wir im Unterricht fast ausschließlich mit C# entwickelt haben und nicht in eine komplett unbekannte Entwicklungsumgebung abdriften wollten, haben wir uns für die Webentwicklung mit ASP.NET Core 9 (Upgrade im Lauf der Diplomarbeit auf .NET Core 10) und dem CMS Oqtane entschieden. Auch hier gab es einige Kandidaten:
 
@@ -43,6 +51,10 @@ Auch steht die Wahl der Programmiersprache und des CMS an. Nachdem wir im Unterr
 
 Insbesondere aufgrund seiner sehr hohen Flexibilität, haben wir uns am Ende für Oqtane entschieden.
 
+#### 3.1.2 Entscheidungsfindung restliche Infrastruktur
+
+Als Betriebssystem habe ich mich für Linux entschieden, einfach, da ich mit Linux im Serverumfeld die meisten und besten Erfahrungen gemacht habe.
+
 Im Bereich der Datenbanken musste ich mir ein paar Fragen stellen:
 
 1. Auf welche Art Datenbank setzen wir? SQL, NoSQL, Graph, ...
@@ -51,9 +63,7 @@ Im Bereich der Datenbanken musste ich mir ein paar Fragen stellen:
 
 Es war von Anfang an klar, dass es ein SQL-basiertes System wird, da wir im Team nur mit SQL-basierten Systemen Erfahrungen haben. Außerdem unterstützt unser CMS (Oqtane) nur SQL-basierte Systeme. In der Linuxwelt kommen jetzt nur noch ein paar Datenbankmanagementsysteme in die Auswahl: PostgreSQL, MySQL / MariaDB, SQLite. Da ist die Wahl auf PostgreSQL gefallen. Grund dafür war meine Vorerfahrung mit diesem Datenbankmanagementsystem, welche ich in meinem Nebenjob errungen habe.
 
-# Technologie
-
-## Was ist Oqtane? Architektur von Oqtane?
+### 3.2 Beschreibung und Architektur von Oqtane
 
 Oqtane ist ein Framework und CMS zur Entwicklung von Webseiten mithilfe von ASP.NET und Blazor. [^5] Ein Oqtane-System besteht aus mehreren Komponenten.
 
@@ -65,7 +75,7 @@ Ein `Module` (Modul) soll neue Funktionalitäten in das CMS hinzufügen und ein
 
 [^6]: https://docs.oqtane.org/dev/extensions/index.html
 
-### Architektur eines Moduls
+#### 3.2.1 Architektur eines Moduls
 
 Ein Modul in Oqtane besteht aus vier Projekten:
 
@@ -79,7 +89,7 @@ Ein Modul in Oqtane besteht aus vier Projekten:
   - Beim Debug werden die DLLs, PDBs und statischen Assets wie Skripte und Stylesheets der drei anderen Projekte in den bereits gebauten Oqtane.Server `oqtane.framework/oqtane.server/bin/debug/net10.0/...` kopiert.
   - Beim Release wird ein NuGet-Paket erstellt und unter oqtane.framework/oqtane.server/Packages abgelegt. Dort abgelegte NuGet-Pakete werden beim nächsten Start des Oqtane Servers installiert (Datenbank Migrationen werden gemacht und die Pakete entpackt).
 
-## Systemarchitektur (Postgres / Oqtane / Nginx)
+### 3.3 Zusammenspiel der Infrastruktur
 
 In diesem Kapitel erkläre ich wie die ausgewählten Komponenten zusammenspielen. Wir verwenden NginX als Reverse Proxy, welcher bei uns die SSL Terminierung macht. Das Zertifikat, welches verwendet wird, wird von Let's Encrypt bereit gestellt und mittels HTTP-Challenges und dem Certbot auf dem Server aktualisiert und verwaltet. Oqtane selber läuft als Systemd-Service im Kestrel Backend. Kestrel ist ein kleiner Webserver, welcher in das ASP.NET Core Framework eingebaut worden ist. Oqtane (bzw. der ASP.NET Core Server "Kestrel") hört auf der Loopback IP und Port 5000. Damit ist Oqtane nur durch NginX erreichbar. PostgreSQL ist die Datenbank in dem System: Sie hört wieder auf der Loopback IP und Port 5432. In der folgenden Grafik ist das System Schematisch dargestellt.
 
@@ -108,9 +118,9 @@ Zusätzlich gab es einen Administrationszugang zu den Servern, welcher über SSH
 
 Die VPN basierten Zugänge sind tendenziell schwieriger zu finden und auszunutzen, während die Lösung in der Schule mittels Highport den SSH Service öffentlich erreichbar macht. Durch den `Highport` ist der SSH Service schwieriger zu finden. Zur Authentifizierung mit SSH verwenden wir SSH-Keys, da diese durch ihre komplexität sicherer sind, als Passwörter.
 
-## Entwicklung mit ASP.NET (Was ist Blazor? / Was ist Razor? / Kestrel)
+### 3.4 Entwicklung mit ASP.NET
 
-### Blazor [^7]
+#### 3.4.1 Blazor [^7]
 
 Blazor ist ein kostenloses und quelloffenes Web-Framework, welches es möglich macht Benutzeroberflächen für Web-Browser, basierend auf C# and HTML, zu erstellen. Es wird von Microsoft als teil des ASP.NET Core Frameworks entwickelt.
 
@@ -155,15 +165,11 @@ Razor hat auch eine Reihe an Keywords, wie zum Beipsiel (nur Auszugsweise, bzw.
 
 [^7]: https://en.wikipedia.org/wiki/Blazor
 
-### Kommunikation zwischen Front- und Backend
+#### 3.4.2 Kommunikation zwischen Front- und Backend
 
-Wie Front- und Backend miteinander interagieren hängt hauptsächlich vom Render Modus ab. Oqtane kann auf verschiedene Arten betrieben werden. Hierbei ist es dem Modulentwickler ziemlich egal, welche Art der Kommunikation (WebSockets, HTTP Long-Polling, REST) verwendet wird.
+Wie Front- und Backend miteinander interagieren hängt hauptsächlich vom Render-Modus ab. Oqtane kann auf verschiedene Arten betrieben werden. Hierbei ist es dem Modulentwickler ziemlich egal, welche Art der Kommunikation (WebSockets, HTTP Long-Polling, REST) verwendet wird. SignalR ist eine Library aus dem ASP.NET Framework, welche es möglich macht, Server zu Client Kommunikation zu betreiben. Oqtane verwendet SignalR im `Interactive Server (SignalR)` Render-Modus.
 
-#### SignalR
-
-SignalR ist eine Library aus dem ASP.NET Framework, welche es möglich macht, Server zu Client Kommunikation zu betreiben. Oqtane verwendet SignalR im `Interactive Server (SignalR)` Render-Modus.
-
-## Dependency Injection
+### 3.5 Dependency Injection
 
 Dependency Injection ist ein Entwurfsmuster, bei dem die Abhängigkeiten eines Objekts nicht von diesem selbst erzeugt, sondern von außen „injiziert“ werden.
 
@@ -173,7 +179,7 @@ In den folgenden beiden Kapiteln wird das Dependency Inversion Principle und das
 
 [^9]: https://martinfowler.com/articles/injection.html
 
-### Dependency Inversion Principle [^1]
+#### 3.5.1 Dependency Inversion Principle [^1]
 
 Das Dependency-Inversion-Principle (DIP / auf Deutsch: Abhängigkeits-Umkehr-Prinzip) ist eines von den fünf `SOLID` Prinzipien in der Softwareentwicklung.
 
@@ -207,7 +213,7 @@ architecture-beta
 
 Das High-Level-Modul ruft lediglich eine Abstraktion eines Low-Level-Moduls auf, welche von einem, oder mehreren Low-Level-Modulen implementiert wurde. Für das High-Level-Modul ist es hier egal, welches Low-Level-Modul die Implementierung bereitstellt. Dadurch erhält man einen viel modulareren Aufbau in der Software. Die einzelnen Module sind auch leichter austauschbar und testbar. Genau diese Modularität macht Dependency Injection möglich.
 
-### Microsoft Dependency Injection Framework
+#### 3.5.2 Microsoft Dependency Injection Framework
 
 Dependency Injektion ist in .NET genau so wie Konfiguration, Protokollierung und das Optionsmuster ins Framework integriert. [^4]
 
@@ -279,9 +285,7 @@ architecture-beta
 
 [^4]: https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection/overview
 
-# Continuous Integration
-
-## Automatisierter Build und Release Prozess mithilfe von Gitea Actions.
+### 3.6 Continuous Integration
 
 Gitea, das Versionskontrollsystem dieser Diplomarbeit, hat einen Continuous-Integration-System eingebaut. Im Kern ist es baugleich zu den GitHub-Pipelines. Man kann im `.gitea/workflow` Ordner `.yml` Dateien ablegen, welche dann das Verhalten der Workflows definieren.
 
@@ -301,72 +305,29 @@ Anwendungen von Gitea Actions bei dieser Diplomarbeit:
 - PM Repository:
   > Zum automatischen Überprüfen der Dokumente, unter anderem, mithilfe von KI, wie zum Beispiel Gemini.
 
-# Projektmanagement
+### 3.7 Debian Paket
 
-## Scrum
+TODO
 
-## YouTrack
+## 4 Projektmanagement
 
-## Gitea (mit Issues)
+### 4.1 Scrum
 
-## Git
+### 4.2 YouTrack
 
-## Kommunikation
+### 4.3 Gitea (mit Issues)
 
-# Learnings
+### 4.4 Git
 
-## Produktion != Staging
+### 4.5 Kommunikation
 
-Ein Learning, welches doch relativ schnell aufkam ist im Bereich der IT eigentlich kein unbekanntes. Wir hatten dieses Learning relativ bald, im Frühling 2025, als die ersten Probleme mit dem Deployment von Oqtane aufkamen. Oqtane war zwar in unserer Entwicklungsumgebung sehr einfach zum einrichten gewesen, das Deployment in der Cloud vom Hetzner war jedoch geplagt von Problemen. Im Zeitraum von Mai bis Okober hatten wir keine laufende Produktivumgebung. Dadurch sind wir mit dieser Diplomarbeit auch in [Zeitverzug](#Arbeitszeiteinschätzung-und-verzug) gekommen. Hätte ich mich vor dem Start der Diplomarbeit mit dem Deployment von Oqtane auseinander gesetzt, dann wäre das in [Probleme mit Oqtane](#Probleme mit Oqtane) beschriebene Problem früher aufgekommen und der Zeitverzug wäre nicht so groß, oder noch ganz vermeidbar gewesen.
+## 5 Module
 
-## Teamleitung (Motivation / Downsizing)
-
-Nachdem ich mich von Anfang an volkommen in das Deploymentproblem von Oqtane gestürzt habe, habe ich meine Rolle als Teamleitung etwas schleifen lassen. Dadurch fehlte bei einigen Teammitgliedern initial die Identifikation mit dem Projekt und in weitererfolge auch die Motivation an diesem Projekt mitzuarbeiten. Nachdem im Verlauf des Frühlings und über den Sommer von der hälfte des Teams trotz Besprechungen und Mahnungen keine Beiträge zu dem Projekt kamen, haben Hr. Prof. Gürth und ich uns dazu entschieden uns von 2 Personen vor unterschreiben des Projektantrages zu trennen. Grund dazu war die Angst, die mangelnde Motivation zieht das restliche Team mit hinunter. Wir wollten uns trotz des Downsizings nicht an Funktionalitäten sparen und haben uns für das nächste halbe bis dreiviertel Jahr einen ziemlich strikten Zeiplan vorgenommen.
-
-## Arbeitszeiteinschätzung (Zeitverzug)
-
-Ein wesentliches Learning aus dem Projektverlauf war die Diskrepanz zwischen der initialen Planung und dem tatsächlichen Aufwand. Ursprünglich wurde der Zeitaufwand für das Aufsetzen der Infrastruktur und die Einarbeitung in das Oqtane-Framework auf etwa drei Wochen geschätzt. In der Realität nahm dieser Prozess jedoch mehrere Monate in Anspruch.
-
-Es gibt mehrere Gründe dafür:
-
-- `Fehlende oder nur schlechte Dokumentation von Oqtane`: Einige Probleme im Deployment wurden in langer und mühseliger Arbeit auseinander gebrochen und in weitere immer kleinere Probleme unterteilt. Dadurch, dass wir alle keine Erfahrung mit der Entwicklung und dem Deployment von ASP.NET Code Anwendungen hatten und die Dokumentation doch schlecht war, blieb uns manchmal nichts anderes übrig als mit WireShark den Netzwerktraffic mit zu schneiden und nebenbei im Git Repository die geloggten Zeilen Code zu finden und so das Framework von innen heraus kennen zu lernen. Dadurch hatte ich dann nach einer Einarbeitungszeit von 4 Monaten ziemlich jede Stelle im Sourcecode von Oqtane gesehen und finde mich um das schneller zurecht.
-- `Team-Konsolidierung`: Durch das notwendige Downsizing des Teams mussten Aufgaben neu verteilt werden, was die individuelle Arbeitslast erhöhte und die Konzentration auf die Kernentwicklung zeitweise verzögert hat.
-- `Abhängigkeit von der Infrastruktur`: Dadurch, dass wir bis in den Oktober / November hinein nicht wussten, ob wir weiter bei Oqtane bleiben können, haben die anderen Teammitglieder nicht mit der sinnvollen Entwicklung ihrer Module starten können. Zitat: "Und was wenn wir am Ende doch noch das CMS umstellen müssen?" => Auch wenn der Auftrag war, mit der Modulentwicklung zu starten war die Motivation meiner Teammitglieder nicht so hoch. Selbst wenn sie nicht direkt von der Infrastruktur mit der Ausführung ihrer Aufgaben abhängig waren, motiviert waren sie wegen der Umstände auch nicht.
-
-Reaktion auf den Verzug:
-Um das Projektziel dennoch zu erreichen, wurde der Zeitplan im Herbst 2025 massiv gestrafft. Durch die Umstellung auf einen strikteren 14-tägigen Sprint-Rhythmus und die Priorisierung von Core-Funktionalitäten (MVP-Ansatz) konnte der Rückstand teilweise aufgeholt werden.
-
-> Fazit: Die Erfahrung zeigt, dass gerade bei "Nischen-Frameworks" wie Oqtane ein deutlich höherer Puffer für die Einarbeitungs- und Infrastrukturphase (Faktor 2 bis 3 der ursprünglichen Schätzung) eingeplant werden muss.
-
-`90% fertig, oder fertig?`: Es gibt einige "Regeln", wie: das `Paretoprinzip`, `Hofstadter’s Law` und die `90-90 Regel`. Letztere wurde im Jahr 1985 von Jon Bentley in einer Kolumne "Programming pearls" veröffentlicht. Ausgeschrieben lautet sie:
-
-> [Rule of Credibility] The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
-> (Jon Bentley. 1985. Programmimg pearls. Commun. ACM 28, 9 (Sept. 1985), 896–901. https://doi.org/10.1145/4284.315122) [^8]
-> Diese Diplomarbeit liefert weitere Evidenz, dass diese Faustregel stimmt.
-
-[^8]: https://dl.acm.org/doi/10.1145/4284.315122
-
-## Sprints und Meetings (in Zukunft ja asynchron)
-
-Ein zentrales Problem in unserer ursprünglichen Arbeitsweise war die Kopplung von Besprechungsterminen mit festen „Commit-Deadlines“ (dem Ende des aktuellen Sprint zyklusses). Da wir uns einmal pro Woche für sechs Stunden am Stück trafen, entstand ein destruktives Muster:
-
-- Der "Last-Minute-Commit"-Druck: In den Stunden unmittelbar vor dem Meeting wurden Aufgaben unter Zeitdruck abgeschlossen, um im Meeting Fortschritte präsentieren zu können. Dies führte dazu, dass unfertiger oder unzureichend getesteter Code („Quick and Dirty“) in das Repository gepusht wurde.
-- Fehlende Review-Kultur: Da die Commits erst kurz vor dem Meeting eintrafen, blieb dem restlichen Team keine Zeit für fundierte Code-Reviews. Die Besprechungszeit wurde somit für die Fehlersuche statt für strategische Planung genutzt.
-- Ineffizienz: Lange Präsenz-Meetings blockierten wertvolle Entwicklungszeit, ohne die technische Qualität zu steigern.
-
-Lösungsansatz: Meetings und Besprechungen asynchron zueinander setzen.
-
-- Asynchrone Daily-Updates: Statusberichte erfolgen schriftlich (z. B. in Gitea Issues oder YouTrack), nicht mehr in stundenlangen Call-Marathons. Das nimmt den zeitlichen Druck vom einzelnen Entwickler. Oder zumindest in kurzen Commitnachrichten, welche am Ende des Tages automatisch an alle Teammitglieder zum überblick gesendet werden (eventuell mit @username tagging, um eine Person nochmal genau anzusprechen)
-- Review-First-Policy: Ein Feature gilt erst dann als „fertig“, wenn es einen asynchronen Code-Review-Prozess durchlaufen hat. Das Meeting dient nur noch der Klärung von Blockern, nicht der Präsentation von Code. Das war eigentlich schon von Anfang an in unserer `Definition of Done` festgelegt worden.
-- Entkoppelung von Meeting und Deadline: Meetings sollten der Synchronisation dienen, während die Abgabe von Arbeitspaketen kontinuierlich (Continuous Integration) erfolgen muss, um Lastspitzen (in der [Gitea Actions](#Continuous Integration) Pipeline) am Tag der Besprechung zu vermeiden.
-
-# Modules
-
-## Admin Modules
+### 5.1 Admin Modules
 
 Eine C#-Solution, welche einige Module, welche für den Admineinsatz geschrieben worden sind beinhaltet. Dieses Modul besteht aus 3 Teilmodulen. Einem Modul für den Versand von Rundmails, eines für die Einstellung von der Token Lebenszeit bei Tokens, welche per E-Mail verschickt werden und eines, welches das Reporting-System übernimmt.
 
-### Mass Mailing
+#### 5.2 Mass Mailing
 
 Das Mass Mailer Modul ist eine administrative Erweiterung für den Alumnihub, die es dem Vorstand ermöglicht, personalisierte Rundschreiben an alle registrierten Mitglieder zu versenden. Da die Pflege der Mitgliederdaten direkt im CMS erfolgt, bietet dieses Modul eine nahtlose Integration ohne den Export von CSV-Listen in externe Newsletter-Tools.
 
@@ -376,7 +337,7 @@ Für den tatsächlichen Versand der E-Mails nutzen wir den Cloud-Dienst Brevo. D
 
 `Batch-Processing`: Mails werden nicht sofort ("Fire and Forget") versendet, sondern in eine Versandwarteschlange geschrieben. Nachdem schon die Notifications Infrastruktur, welche sich auch um den Mail versand kümmert, ins Framework eingebaut worden ist, nutzen wir diese geleich und `schedulen` unsere E-Mails. Immer 100 Mails alle 24 Stunden bis alle Ziele die Mails erhalten haben. Das Limit von 100 / Tag ist konservativ sehr niedrig angesetzt, damit funktionen wie Passwort Reset Mails nicht (leicht) dadurch beeinflusst werden können.
 
-### Token Lifetime
+#### 5.3 Token Lifetime
 
 Das Token Lifetime Modul wurde geschrieben, um die Token-Lebenszeit konfigurierbar zu machen. Notwendig war das, um die Passwort Reset Links im initialen Mail versand länger gultig sein zu lassen. Durch das `Batch Processing` war es Möglich, dass eine Mail erst Tage nach erstellen des Links hinaus geschickt wird und bei einer Standard Ablaufdauer von 2 Tagen sind machne Links schon ungültig, bis sie den Mail Server erreichen. Ziel war es, die Änderung der Lebenszeit für Administratoren im User Interface im Admin Bereich möglich zu machen.
 
@@ -393,7 +354,7 @@ Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
 
 [^11]: https://www.cs.umd.edu/projects/syschat/raceConditions.pdf
 
-### Reporting System
+#### 5.4 Reporting System
 
 Eine weitere Anforderung der Diplomarbeit war es Einträge in Modulen wie der `Hall of Fame`, dem `Schwarzen Brett` und dem Premium Bereich (`Engineer Applications`) melden zu können. Am Anfang war es wichtig, dass jeder schnell vorrankommt, allerdings haben wir die Kommunikation Teamintern ein wenig verschlafen und dadurch ein paar Funktionen doppelt geschrieben. Dadurch kam es zu inkonsistenzen in der Verwendung der unterschiedlichen Reporting Systeme. Deswegen haben wir uns am Ende für eine globales Reporting System entschieden.
 
@@ -435,6 +396,53 @@ Die Implementierung des IReportingComponents stellt nur eine Property (`ReportTy
 
 Die Bereitstellund des Moduls geschieht im `AdminModules` Modul.
 
-## Event Registration
+### 5.5 Event Registration
 
-## Schwarzes Brett
+### 5.6 Schwarzes Brett
+
+## 6 Learnings
+
+### 6.1 Produktion != Staging
+
+Ein Learning, welches doch relativ schnell aufkam ist im Bereich der IT eigentlich kein unbekanntes. Wir hatten dieses Learning relativ bald, im Frühling 2025, als die ersten Probleme mit dem Deployment von Oqtane aufkamen. Oqtane war zwar in unserer Entwicklungsumgebung sehr einfach zum einrichten gewesen, das Deployment in der Cloud vom Hetzner war jedoch geplagt von Problemen. Im Zeitraum von Mai bis Okober hatten wir keine laufende Produktivumgebung. Dadurch sind wir mit dieser Diplomarbeit auch in [Zeitverzug](#Arbeitszeiteinschätzung-und-verzug) gekommen. Hätte ich mich vor dem Start der Diplomarbeit mit dem Deployment von Oqtane auseinander gesetzt, dann wäre das in [Probleme mit Oqtane](#Probleme mit Oqtane) beschriebene Problem früher aufgekommen und der Zeitverzug wäre nicht so groß, oder noch ganz vermeidbar gewesen.
+
+### 6.2 Teamleitung (Motivation / Downsizing)
+
+Nachdem ich mich von Anfang an volkommen in das Deploymentproblem von Oqtane gestürzt habe, habe ich meine Rolle als Teamleitung etwas schleifen lassen. Dadurch fehlte bei einigen Teammitgliedern initial die Identifikation mit dem Projekt und in weitererfolge auch die Motivation an diesem Projekt mitzuarbeiten. Nachdem im Verlauf des Frühlings und über den Sommer von der hälfte des Teams trotz Besprechungen und Mahnungen keine Beiträge zu dem Projekt kamen, haben Hr. Prof. Gürth und ich uns dazu entschieden uns von 2 Personen vor unterschreiben des Projektantrages zu trennen. Grund dazu war die Angst, die mangelnde Motivation zieht das restliche Team mit hinunter. Wir wollten uns trotz des Downsizings nicht an Funktionalitäten sparen und haben uns für das nächste halbe bis dreiviertel Jahr einen ziemlich strikten Zeiplan vorgenommen.
+
+### 6.3 Arbeitszeiteinschätzung (Zeitverzug)
+
+Ein wesentliches Learning aus dem Projektverlauf war die Diskrepanz zwischen der initialen Planung und dem tatsächlichen Aufwand. Ursprünglich wurde der Zeitaufwand für das Aufsetzen der Infrastruktur und die Einarbeitung in das Oqtane-Framework auf etwa drei Wochen geschätzt. In der Realität nahm dieser Prozess jedoch mehrere Monate in Anspruch.
+
+Es gibt mehrere Gründe dafür:
+
+- `Fehlende oder nur schlechte Dokumentation von Oqtane`: Einige Probleme im Deployment wurden in langer und mühseliger Arbeit auseinander gebrochen und in weitere immer kleinere Probleme unterteilt. Dadurch, dass wir alle keine Erfahrung mit der Entwicklung und dem Deployment von ASP.NET Code Anwendungen hatten und die Dokumentation doch schlecht war, blieb uns manchmal nichts anderes übrig als mit WireShark den Netzwerktraffic mit zu schneiden und nebenbei im Git Repository die geloggten Zeilen Code zu finden und so das Framework von innen heraus kennen zu lernen. Dadurch hatte ich dann nach einer Einarbeitungszeit von 4 Monaten ziemlich jede Stelle im Sourcecode von Oqtane gesehen und finde mich um das schneller zurecht.
+- `Team-Konsolidierung`: Durch das notwendige Downsizing des Teams mussten Aufgaben neu verteilt werden, was die individuelle Arbeitslast erhöhte und die Konzentration auf die Kernentwicklung zeitweise verzögert hat.
+- `Abhängigkeit von der Infrastruktur`: Dadurch, dass wir bis in den Oktober / November hinein nicht wussten, ob wir weiter bei Oqtane bleiben können, haben die anderen Teammitglieder nicht mit der sinnvollen Entwicklung ihrer Module starten können. Zitat: "Und was wenn wir am Ende doch noch das CMS umstellen müssen?" => Auch wenn der Auftrag war, mit der Modulentwicklung zu starten war die Motivation meiner Teammitglieder nicht so hoch. Selbst wenn sie nicht direkt von der Infrastruktur mit der Ausführung ihrer Aufgaben abhängig waren, motiviert waren sie wegen der Umstände auch nicht.
+
+Reaktion auf den Verzug:
+Um das Projektziel dennoch zu erreichen, wurde der Zeitplan im Herbst 2025 massiv gestrafft. Durch die Umstellung auf einen strikteren 14-tägigen Sprint-Rhythmus und die Priorisierung von Core-Funktionalitäten (MVP-Ansatz) konnte der Rückstand teilweise aufgeholt werden.
+
+> Fazit: Die Erfahrung zeigt, dass gerade bei "Nischen-Frameworks" wie Oqtane ein deutlich höherer Puffer für die Einarbeitungs- und Infrastrukturphase (Faktor 2 bis 3 der ursprünglichen Schätzung) eingeplant werden muss.
+
+`90% fertig, oder fertig?`: Es gibt einige "Regeln", wie: das `Paretoprinzip`, `Hofstadter’s Law` und die `90-90 Regel`. Letztere wurde im Jahr 1985 von Jon Bentley in einer Kolumne "Programming pearls" veröffentlicht. Ausgeschrieben lautet sie:
+
+> [Rule of Credibility] The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
+> (Jon Bentley. 1985. Programmimg pearls. Commun. ACM 28, 9 (Sept. 1985), 896–901. https://doi.org/10.1145/4284.315122) [^8]
+> Diese Diplomarbeit liefert weitere Evidenz, dass diese Faustregel stimmt.
+
+[^8]: https://dl.acm.org/doi/10.1145/4284.315122
+
+### 6.4 Sprints und Meetings (in Zukunft ja asynchron)
+
+Ein zentrales Problem in unserer ursprünglichen Arbeitsweise war die Kopplung von Besprechungsterminen mit festen „Commit-Deadlines“ (dem Ende des aktuellen Sprint zyklusses). Da wir uns einmal pro Woche für sechs Stunden am Stück trafen, entstand ein destruktives Muster:
+
+- Der "Last-Minute-Commit"-Druck: In den Stunden unmittelbar vor dem Meeting wurden Aufgaben unter Zeitdruck abgeschlossen, um im Meeting Fortschritte präsentieren zu können. Dies führte dazu, dass unfertiger oder unzureichend getesteter Code („Quick and Dirty“) in das Repository gepusht wurde.
+- Fehlende Review-Kultur: Da die Commits erst kurz vor dem Meeting eintrafen, blieb dem restlichen Team keine Zeit für fundierte Code-Reviews. Die Besprechungszeit wurde somit für die Fehlersuche statt für strategische Planung genutzt.
+- Ineffizienz: Lange Präsenz-Meetings blockierten wertvolle Entwicklungszeit, ohne die technische Qualität zu steigern.
+
+Lösungsansatz: Meetings und Besprechungen asynchron zueinander setzen.
+
+- Asynchrone Daily-Updates: Statusberichte erfolgen schriftlich (z. B. in Gitea Issues oder YouTrack), nicht mehr in stundenlangen Call-Marathons. Das nimmt den zeitlichen Druck vom einzelnen Entwickler. Oder zumindest in kurzen Commitnachrichten, welche am Ende des Tages automatisch an alle Teammitglieder zum überblick gesendet werden (eventuell mit @username tagging, um eine Person nochmal genau anzusprechen)
+- Review-First-Policy: Ein Feature gilt erst dann als „fertig“, wenn es einen asynchronen Code-Review-Prozess durchlaufen hat. Das Meeting dient nur noch der Klärung von Blockern, nicht der Präsentation von Code. Das war eigentlich schon von Anfang an in unserer `Definition of Done` festgelegt worden.
+- Entkoppelung von Meeting und Deadline: Meetings sollten der Synchronisation dienen, während die Abgabe von Arbeitspaketen kontinuierlich (Continuous Integration) erfolgen muss, um Lastspitzen (in der [Gitea Actions](#Continuous Integration) Pipeline) am Tag der Besprechung zu vermeiden.

From 6b5c524f36ea9cb3cf4cfef4cde17edad2810b5d Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Wed, 18 Mar 2026 12:44:34 +0000
Subject: [PATCH 15/22] Update: Motivation

---
 ...omarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index 341e48a..065cecd 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -19,7 +19,9 @@ Meine Zuständigkeiten und Verantwortlichkeiten:
 
 ### 1.2 Motivation
 
-Lernen von ASP.NET und der Entwicklung mit Blazor und Oqtane. Ich habe Interesse an dem Thema Webentwicklung. Privat entwickle ich schon seit Jahren viel mit React.JS.
+Gegenstand der Diplomarbeit ist die Entwicklung modularer Webanwendungen mit Blazor und Oqtane. Aufbauend auf fundierten Kenntnissen in der Fullstack-Entwicklung (React, Node.js, Golang), fokussiert sich die Arbeit auf die Architekturvorteile des .NET-Stacks. Besonders im Fokus stehen die Konsistenz durch statische Typisierung sowie das Zusammenspiel modularer Komponenten in verteilten Systemen.
+
+Mein Untersuchungsanliegen: Inwieweit optimiert die Integration von Blazor und dem Oqtane-Framework die Konsistenz und Wartbarkeit modularer Web-Architekturen im Vergleich zu den für mich gewohnten Technologie-Stacks (React/Node.js)?
 
 ## 2. Anforderungen an das entwickelte Modul bzw. die Funktionalität
 

From a9d2d3626b8c1b8c9c6aded6ad54f87fd86fadc7 Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Wed, 18 Mar 2026 17:36:12 +0000
Subject: [PATCH 16/22] New: Projektmanagement: Git und Gitea

---
 ...dividueller-teil-Konstantin-Hintermayer.md | 60 +++++++++++++++++--
 1 file changed, 56 insertions(+), 4 deletions(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index 065cecd..32926d1 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -19,7 +19,7 @@ Meine Zuständigkeiten und Verantwortlichkeiten:
 
 ### 1.2 Motivation
 
-Gegenstand der Diplomarbeit ist die Entwicklung modularer Webanwendungen mit Blazor und Oqtane. Aufbauend auf fundierten Kenntnissen in der Fullstack-Entwicklung (React, Node.js, Golang), fokussiert sich die Arbeit auf die Architekturvorteile des .NET-Stacks. Besonders im Fokus stehen die Konsistenz durch statische Typisierung sowie das Zusammenspiel modularer Komponenten in verteilten Systemen.
+Gegenstand der Diplomarbeit ist die Entwicklung modularer Webanwendungen mit Blazor und Oqtane. Aufbauend auf fundierten Kenntnissen in der Fullstack-Entwicklung (React, Node.js, Golang), welche privat bei diversen Projekten gesammelt worden ist, fokussiert sich die Arbeit auf die Architekturvorteile des .NET-Stacks. Besonders im Fokus stehen die Konsistenz durch statische Typisierung sowie das Zusammenspiel modularer Komponenten in verteilten Systemen.
 
 Mein Untersuchungsanliegen: Inwieweit optimiert die Integration von Blazor und dem Oqtane-Framework die Konsistenz und Wartbarkeit modularer Web-Architekturen im Vergleich zu den für mich gewohnten Technologie-Stacks (React/Node.js)?
 
@@ -311,15 +311,67 @@ Anwendungen von Gitea Actions bei dieser Diplomarbeit:
 
 TODO
 
-## 4 Projektmanagement
+## 4 Projektmanagement & Tools
 
 ### 4.1 Scrum
 
 ### 4.2 YouTrack
 
-### 4.3 Gitea (mit Issues)
+### 4.3 Git
 
-### 4.4 Git
+Git fungierte im Rahmen dieser Diplomarbeit als zentrales Werkzeug zur Versionskontrolle und Koordination sämtlicher Entwicklungsschritte. Die wichtigste Komponente stellt dabei der Commit dar, welcher als eindeutiger Snapshot des Projektzustands dient und über eine spezifische Commit-SHA (Secure Hash Algorithm) referenziert werden kann. Um eine lückenlose Nachvollziehbarkeit zu gewährleisten, wurde für jeden abgeschlossenen Arbeitsschritt ein eigener Commit erstellt.
+
+Im Gegensatz zu zentralisierten Systemen wie SVN, welches wir im Unterricht beigebracht bekommen haben, speichert Git die vollständige Historie eines Projekts lokal auf dem Rechner jedes Beteiligten. Dies ermöglicht nicht nur ein Offline-Arbeiten, sondern bietet auch eine hohe Ausfallsicherheit.
+
+Der Workflow in Git basiert auf drei Hauptbereichen:
+
+1. Working Directory: Der aktuelle Zustand der Dateien auf der Festplatte.
+2. Staging Area (Index): Eine Zwischenebene, in der Änderungen für den nächsten Snapshot vorgemerkt werden.
+3. Repository (HEAD): Der dauerhafte Speicher der versionierten Stände (Commits).
+
+Eines der mächtigsten Features von Git ist das Branching. Es erlaubt es, isolierte Entwicklungszweige zu erstellen, um neue Features oder experimentelle Analysen zu implementieren, ohne die Stabilität des Hauptzweigs `main` zu gefährden.
+
+Sobald eine Änderung erfolgreich getestet wurde, wird sie durch einen Merge wieder in den Hauptzweig integriert. Sollten dabei widersprüchliche Änderungen an denselben Dateizeilen auftreten, unterstützt Git den Nutzer bei der Auflösung dieser sogenannten Merge-Konflikte.
+
+Für die Sicherung und Zusammenarbeit wurde im Rahmen dieser Arbeit Remote-Repositories auf einer Gitea Instanz verwendet. Durch die Befehle push und pull wird der lokale Stand mit dem Server synchronisiert. Dies gewährleistet eine konsistente Datenbasis und dient gleichzeitig als kontinuierliches Backup des Projektfortschritts.
+
+### 4.4 Gitea
+
+Als schlanke und selbst gehostete Open-Source-Alternative zu Plattformen wie GitHub oder GitLab wurde für die Verwaltung der Repositories Gitea eingesetzt. Hauptgrund für die Benutzung von Gitea war meine bereits aufgesetzte Instanz, welche schon mehrere Jahre in verwendung war und mit der es im Team auch schon Erfahrungen gab. Gitea bietet neben der reinen Git-Verwaltung essenzielle Werkzeuge für den Software-Lebenszyklus, wie ein integriertes Issue-Tracking, Code-Reviews über Pull-Requests sowie eine Benutzerverwaltung, und unterstützt somit die strukturierte Umsetzung der Diplomarbeit im Team.[^12]
+
+#### 4.4.1 Repositories
+
+Ein Repository bildet den zentralen Speicherort für einen Projektteil. In Gitea wurden separate Repositories für die einzelnen Module und Themes, das Oqtane Framework, Skripte, die Dokumentation angelegt. Ein zusätzliches Repository bindet alle übrigen Quellcode-Repositories als Submodule ein, das macht die Einrichtung einer neuen Entwicklungsumgebung sehr kompfortabel. Dies ermöglichte eine saubere Trennung der verschiedenen Projektkomponenten. [^12]
+
+#### 4.4.2 Issues
+
+Zur Aufgabenplanung und Fehlerverfolgung wurde das integrierte Issue-System genutzt. Jede anstehende Aufgabe oder entdeckte Schwachstelle wurde als „Issue“ erfasst, einem Verantwortlichen zugewiesen und mit Labels (z. B. „Bug“, „Feature“ oder „Dokumentation“) versehen. Dies half dabei, den Überblick über den Projektfortschritt zu behalten und die Anforderungen aus dem Lastenheft strukturiert abzuarbeiten. [^12][^13]
+
+#### 4.4.3 Pull Requests
+
+Um die Qualität des Codes zu sichern, wurden Änderungen nicht direkt in den Hauptzweig eingespielt, sondern über Pull Requests eingereicht. Ein Teammitglied konnte so die Änderungen eines anderen sichten, kommentieren und bei Bedarf Korrekturen anfordern. Erst nach einer erfolgreichen Überprüfung wurde der Code in den main-Branch gemergt. [^12][^14]
+
+#### 4.4.4 Actions
+
+Gitea Actions wurden eingesetzt, um CI/CD-Pipelines (Continuous Integration / Continuous Deployment) zu realisieren. Bei jedem Push oder Pull Request wurden automatisierte Skripte ausgeführt, die das Projekt bauten. Dies reduzierte manuelle Fehlerquellen erheblich. Außerdem konnten wir mithilfe von CI/CD den Release Prozess einmalig festlegen und automatisieren, ohne bei jedem Update manuell den selben Prozess wiederholt durchgehen zu müssen. Das APT-Package Projekt enthält die CI/CD Konfiguration für das bauen von Oqtane, der Module und Themes, sowie das verpacken in ein APT Paket und dem veröffentlichen aller Pakete als eingenes Gitea Release. [^12][^15]
+
+#### 4.4.5 Releases
+
+Über die Release-Funktion wurden wichtige Meilensteine der Diplomarbeit festgeschrieben. Hierbei wird ein spezifischer Git-Tag mit einer Versionsnummer versehen und die dazugehörigen Binärdateien, Pakete und Dokumente archiviert. So lässt sich jederzeit auf einen stabilen, abgabebereiten Stand des Projekts zugreifen. [^12]
+
+#### 4.4.6 Package Repositories
+
+Gitea fungierte zusätzlich als Register für Pakete und Container-Images. Selbst erstellte Artefakte, wie das Debian Paket für die Bereitstellung der Anwendung, wurden direkt in der Gitea-Instanz versioniert gespeichert. Dadurch waren alle notwendigen Komponenten für das Deployment an einem zentralen Ort verfügbar und abrufbar. Gitea selbst unterstützt verschiedenste Pakettypen. Darunter fallen unteranderem NuGet- und Debianpakete. Für beide haben wir in dieser Arbeit verwendung gefunden. [^12][^16]
+
+[^12]: https://docs.gitea.com/
+
+[^13]: https://docs.gitea.com/installation/comparison#issue-tracker
+
+[^14]: https://docs.gitea.com/usage/pull-request
+
+[^15]: https://docs.gitea.com/usage/actions/overview
+
+[^16]: https://docs.gitea.com/usage/packages/overview
 
 ### 4.5 Kommunikation
 

From f14d39be25d81f762a26e661444be2a23538496c Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Wed, 18 Mar 2026 17:57:01 +0000
Subject: [PATCH 17/22] New: EventRegistration Modul

---
 ...dividueller-teil-Konstantin-Hintermayer.md | 22 +++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index 32926d1..cf0bcd7 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -452,6 +452,28 @@ Die Bereitstellund des Moduls geschieht im `AdminModules` Modul.
 
 ### 5.5 Event Registration
 
+Dieses Modul ermöglicht es Administratoren und Absolventen, Veranstaltungen zu erstellen, auf der Seite zu veröffentlichen und zu verwalten, während Mitglieder ihre Teilnahme direkt über das Portal bestätigen oder absagen können. Dieses Modul dient der organisatorischen Unterstützung von Absolvententreffen und anderen Vereinsaktivitäten. Dieses Modul wurde gemeinsam mit Adam Gaiswinkler geschrieben, wobei er sich um die Darstellung der Events im Frontend gekümmert hat, während ich mich der Infrastruktur im Hintergrund angenommen habe.
+
+#### 5.5.1 Backend und Datenhaltung
+
+Die serverseitige Implementierung basiert auf dem Repository-Pattern des Oqtane-Frameworks. Hierbei kommen zwei zentrale Repositories zum Einsatz:
+
+Das `EventRepository` verwaltet die Metadaten der Veranstaltungen wie Name, Beschreibung, Datum und Ort.
+Das `ResponseRepository` speichert die Rückmeldungen der Benutzer. Ein Eintrag verknüpft dabei die UserId mit der EventId und dem Status der Rückmeldung.
+Die Kommunikation zwischen dem Client und dem Server erfolgt über einen REST-API-Controller `EventRegistrationController`, der sicherstellt, dass nur autorisierte Benutzer Änderungen vornehmen oder detaillierte Statistiken einsehen können.
+
+#### 5.5.2 Statistik und Visualisierung
+
+Ein wesentlicher Teil der administrativen Ansicht ist die Visualisierung der Anmeldezahlen. Hierfür wurde eine Integration von Chart.js realisiert, um den aktuellen Stand der Rückmeldungen grafisch aufzubereiten.
+
+Um die Brücke zwischen dem C#-basierten Blazor-Frontend und der JavaScript-Bibliothek Chart.js zu schlagen, wurde ein dedizierter Interop-Service implementiert. Der Ablauf der grafischen Darstellung gestaltet sich wie folgt:
+
+1. Datenaufbereitung: In der Edit-Komponente werden alle Rückmeldungen zu einem Event geladen und nach ihrem Typ, oder beliebigen anderen Merkmalen aggregiert.
+2. JS-Interop: Über die `CreateChart`-Methode der Interop-Klasse wird die JavaScript-Funktion `createChart` in der `Module.js` aufgerufen. Dabei werden die aggregierten Daten, Beschriftungen und Konfigurationsoptionen übergeben.
+3. Canvas-Rendering: Die JavaScript-Logik erzeugt dynamisch ein HTML5-canvas-Element innerhalb eines Container-Divs und initialisiert daraufhin die Chart.js-Instanz, welche ein übersichtliches Pie-Chart mit den Registrierungsstatistiken rendert.
+
+Durch diese Trennung bleibt die Geschäftslogik im C#-Code, während für die performante und ansprechende Darstellung auf etablierte Web-Technologien zurückgegriffen wird.
+
 ### 5.6 Schwarzes Brett
 
 ## 6 Learnings

From fd61a18141c0302566843e9954e483aefc2908c1 Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <kocoder@noreply.git.kocoder.xyz>
Date: Wed, 18 Mar 2026 17:59:23 +0000
Subject: [PATCH 18/22] =?UTF-8?q?Update:=20=C3=9Cberschriftsnummerierung?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...ch-individueller-teil-Konstantin-Hintermayer.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index cf0bcd7..5d2799a 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -381,7 +381,7 @@ Gitea fungierte zusätzlich als Register für Pakete und Container-Images. Selbs
 
 Eine C#-Solution, welche einige Module, welche für den Admineinsatz geschrieben worden sind beinhaltet. Dieses Modul besteht aus 3 Teilmodulen. Einem Modul für den Versand von Rundmails, eines für die Einstellung von der Token Lebenszeit bei Tokens, welche per E-Mail verschickt werden und eines, welches das Reporting-System übernimmt.
 
-#### 5.2 Mass Mailing
+#### 5.1.1 Mass Mailing
 
 Das Mass Mailer Modul ist eine administrative Erweiterung für den Alumnihub, die es dem Vorstand ermöglicht, personalisierte Rundschreiben an alle registrierten Mitglieder zu versenden. Da die Pflege der Mitgliederdaten direkt im CMS erfolgt, bietet dieses Modul eine nahtlose Integration ohne den Export von CSV-Listen in externe Newsletter-Tools.
 
@@ -391,7 +391,7 @@ Für den tatsächlichen Versand der E-Mails nutzen wir den Cloud-Dienst Brevo. D
 
 `Batch-Processing`: Mails werden nicht sofort ("Fire and Forget") versendet, sondern in eine Versandwarteschlange geschrieben. Nachdem schon die Notifications Infrastruktur, welche sich auch um den Mail versand kümmert, ins Framework eingebaut worden ist, nutzen wir diese geleich und `schedulen` unsere E-Mails. Immer 100 Mails alle 24 Stunden bis alle Ziele die Mails erhalten haben. Das Limit von 100 / Tag ist konservativ sehr niedrig angesetzt, damit funktionen wie Passwort Reset Mails nicht (leicht) dadurch beeinflusst werden können.
 
-#### 5.3 Token Lifetime
+#### 5.1.2 Token Lifetime
 
 Das Token Lifetime Modul wurde geschrieben, um die Token-Lebenszeit konfigurierbar zu machen. Notwendig war das, um die Passwort Reset Links im initialen Mail versand länger gultig sein zu lassen. Durch das `Batch Processing` war es Möglich, dass eine Mail erst Tage nach erstellen des Links hinaus geschickt wird und bei einer Standard Ablaufdauer von 2 Tagen sind machne Links schon ungültig, bis sie den Mail Server erreichen. Ziel war es, die Änderung der Lebenszeit für Administratoren im User Interface im Admin Bereich möglich zu machen.
 
@@ -408,7 +408,7 @@ Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
 
 [^11]: https://www.cs.umd.edu/projects/syschat/raceConditions.pdf
 
-#### 5.4 Reporting System
+#### 5.1.3 Reporting System
 
 Eine weitere Anforderung der Diplomarbeit war es Einträge in Modulen wie der `Hall of Fame`, dem `Schwarzen Brett` und dem Premium Bereich (`Engineer Applications`) melden zu können. Am Anfang war es wichtig, dass jeder schnell vorrankommt, allerdings haben wir die Kommunikation Teamintern ein wenig verschlafen und dadurch ein paar Funktionen doppelt geschrieben. Dadurch kam es zu inkonsistenzen in der Verwendung der unterschiedlichen Reporting Systeme. Deswegen haben wir uns am Ende für eine globales Reporting System entschieden.
 
@@ -450,11 +450,11 @@ Die Implementierung des IReportingComponents stellt nur eine Property (`ReportTy
 
 Die Bereitstellund des Moduls geschieht im `AdminModules` Modul.
 
-### 5.5 Event Registration
+### 5.2 Event Registration
 
 Dieses Modul ermöglicht es Administratoren und Absolventen, Veranstaltungen zu erstellen, auf der Seite zu veröffentlichen und zu verwalten, während Mitglieder ihre Teilnahme direkt über das Portal bestätigen oder absagen können. Dieses Modul dient der organisatorischen Unterstützung von Absolvententreffen und anderen Vereinsaktivitäten. Dieses Modul wurde gemeinsam mit Adam Gaiswinkler geschrieben, wobei er sich um die Darstellung der Events im Frontend gekümmert hat, während ich mich der Infrastruktur im Hintergrund angenommen habe.
 
-#### 5.5.1 Backend und Datenhaltung
+#### 5.2.1 Backend und Datenhaltung
 
 Die serverseitige Implementierung basiert auf dem Repository-Pattern des Oqtane-Frameworks. Hierbei kommen zwei zentrale Repositories zum Einsatz:
 
@@ -462,7 +462,7 @@ Das `EventRepository` verwaltet die Metadaten der Veranstaltungen wie Name, Besc
 Das `ResponseRepository` speichert die Rückmeldungen der Benutzer. Ein Eintrag verknüpft dabei die UserId mit der EventId und dem Status der Rückmeldung.
 Die Kommunikation zwischen dem Client und dem Server erfolgt über einen REST-API-Controller `EventRegistrationController`, der sicherstellt, dass nur autorisierte Benutzer Änderungen vornehmen oder detaillierte Statistiken einsehen können.
 
-#### 5.5.2 Statistik und Visualisierung
+#### 5.2.2 Statistik und Visualisierung
 
 Ein wesentlicher Teil der administrativen Ansicht ist die Visualisierung der Anmeldezahlen. Hierfür wurde eine Integration von Chart.js realisiert, um den aktuellen Stand der Rückmeldungen grafisch aufzubereiten.
 
@@ -474,7 +474,7 @@ Um die Brücke zwischen dem C#-basierten Blazor-Frontend und der JavaScript-Bibl
 
 Durch diese Trennung bleibt die Geschäftslogik im C#-Code, während für die performante und ansprechende Darstellung auf etablierte Web-Technologien zurückgegriffen wird.
 
-### 5.6 Schwarzes Brett
+### 5.3 Schwarzes Brett
 
 ## 6 Learnings
 

From 53e6ca0205511e31295d2aef78de81528e45d1be Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Wed, 18 Mar 2026 20:03:45 +0000
Subject: [PATCH 19/22] New: Schwarzes Brett

---
 ...dividueller-teil-Konstantin-Hintermayer.md | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index 5d2799a..eb107d1 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -476,6 +476,33 @@ Durch diese Trennung bleibt die Geschäftslogik im C#-Code, während für die pe
 
 ### 5.3 Schwarzes Brett
 
+Das Modul "Schwarzes Brett" dient als digitale Anschlagtafel für den Absolventenverein. Mitglieder können hier Gesuche, Angebote oder allgemeine Informationen veröffentlichen. Es stellt eine zentrale Informationsdrehscheibe dar, die den informellen Austausch innerhalb des Vereins fördern soll.
+
+#### 5.3.1 Struktur und Anzeige
+
+Die Anzeige der Einträge erfolgt in einer responsiven Grid-Ansicht (Index-Komponente), wobei jeder Eintrag als Karte (Card) dargestellt wird. Dieses Design sorgt für eine übersichtliche Präsentation auch bei einer größeren Anzahl von Mitteilungen.
+
+- Bilderunterstützung: Das Modul nutzt die Oqtane-interne Dateiverwaltung. Wenn ein Bild für einen Eintrag hochgeladen wurde, wird dieses über einen Image-Proxy skaliert und als Vorschaubild angezeigt. Fehlt ein Bild, wird ein konsistenter Platzhalter verwendet, um das visuelle Gleichgewicht der Grid-Ansicht zu wahren.
+- Detailansicht: Die Details-Komponente bietet eine fokussierte Ansicht des Eintrags mit vollständiger HTML-Beschreibung, die über einen Rich-Text-Editor gepflegt werden kann. Ergänzt wird dies durch Metadaten wie Erstellungsdatum und Autor.
+
+#### 5.3.2 Automatisierter E-Mail-Digest
+
+Um die Mitglieder regelmäßig über neue Inhalte zu informieren, wurde ein automatisierter `Cronjob` implementiert. Dieser Job läuft im Hintergrund des Oqtane-Frameworks und führt folgende Schritte aus:
+
+- Filterung: Der Job identifiziert alle Einträge, die seit dem letzten Versand erstellt wurden. 
+- Zielgruppenselektion: Es werden alle Benutzer identifiziert, die der Rolle "Absolventen" angehören.
+- Zusammenstellung: Für jeden dieser Benutzer wird eine personalsierte Email-Notification generiert, welche eine Zusammenfassung der neuen Einträge enthält.
+- Versand: Die generierten Notifications werden in die Warteschlange der Notification-Infrastruktur eingereiht und sukzessive versendet.
+Integration des Reporting-Systems
+
+
+#### 5.3.3 Reporting System
+Ein wichtiges Merkmal des Schwarzen Bretts zur Sicherstellung der Inhaltsqualität ist die Anbindung an das globale Reporting-System (siehe 5.4). In der Detailansicht wird über Dependency Injection die IReportUI-Komponente eingebunden. Mithilfe der DynamicComponent von Blazor wird die Melde-Funktion nahtlos in die Oberfläche des Moduls integriert. Dadurch können unangemessene Inhalte direkt von Benutzern gemeldet werden.
+
+#### 5.3.4 Technischer Hintergrund
+
+Auf der Serverseite folgt das Modul dem etablierten Muster mit `einem BlackBoardRepository` für den effizienten Datenbankzugriff und einem `BlackBoardController` für die API-Bereitstellung. Die Implementierung des Scheduled Jobs als HostedServiceBase ermöglicht eine tiefe Integration in die Oqtane-Infrastruktur bei gleichzeitig geringem Ressourcenverbrauch. erbarkeit des Moduls gewährleistet.
+
 ## 6 Learnings
 
 ### 6.1 Produktion != Staging

From bc9835567dbe3325592ccab30223e976813e3ca9 Mon Sep 17 00:00:00 2001
From: Konstantin Hintermayer <me@kocoder.xyz>
Date: Wed, 18 Mar 2026 20:04:21 +0000
Subject: [PATCH 20/22] Update
 Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md

---
 Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index eb107d1..1bd8add 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -501,7 +501,7 @@ Ein wichtiges Merkmal des Schwarzen Bretts zur Sicherstellung der Inhaltsqualit
 
 #### 5.3.4 Technischer Hintergrund
 
-Auf der Serverseite folgt das Modul dem etablierten Muster mit `einem BlackBoardRepository` für den effizienten Datenbankzugriff und einem `BlackBoardController` für die API-Bereitstellung. Die Implementierung des Scheduled Jobs als HostedServiceBase ermöglicht eine tiefe Integration in die Oqtane-Infrastruktur bei gleichzeitig geringem Ressourcenverbrauch. erbarkeit des Moduls gewährleistet.
+Auf der Serverseite folgt das Modul dem etablierten Muster mit einem `BlackBoardRepository` für den effizienten Datenbankzugriff und einem `BlackBoardController` für die API-Bereitstellung. Die Implementierung des Scheduled Jobs als HostedServiceBase ermöglicht eine tiefe Integration in die Oqtane-Infrastruktur bei gleichzeitig geringem Ressourcenverbrauch. erbarkeit des Moduls gewährleistet.
 
 ## 6 Learnings
 

From 43f5104a4e8906e425ddf3e4985c11b89628905a Mon Sep 17 00:00:00 2001
From: KoCoder <me@kocoder.xyz>
Date: Wed, 18 Mar 2026 21:57:53 +0100
Subject: [PATCH 21/22] Fix: Typos and move Sources into the end

---
 ...dividueller-teil-Konstantin-Hintermayer.md | 109 ++++++++++--------
 1 file changed, 58 insertions(+), 51 deletions(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index 1bd8add..bdfa7ad 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -19,7 +19,7 @@ Meine Zuständigkeiten und Verantwortlichkeiten:
 
 ### 1.2 Motivation
 
-Gegenstand der Diplomarbeit ist die Entwicklung modularer Webanwendungen mit Blazor und Oqtane. Aufbauend auf fundierten Kenntnissen in der Fullstack-Entwicklung (React, Node.js, Golang), welche privat bei diversen Projekten gesammelt worden ist, fokussiert sich die Arbeit auf die Architekturvorteile des .NET-Stacks. Besonders im Fokus stehen die Konsistenz durch statische Typisierung sowie das Zusammenspiel modularer Komponenten in verteilten Systemen.
+Gegenstand der Diplomarbeit ist die Entwicklung modularer Webanwendungen mit Blazor und Oqtane. Aufbauend auf fundierten Kenntnissen in der Fullstack-Entwicklung (React, Node.js, Golang), welche privat bei diversen Projekten gesammelt worden sind, fokussiert sich die Arbeit auf die Architekturvorteile des .NET-Stacks. Besonders im Fokus stehen die Konsistenz durch statische Typisierung sowie das Zusammenspiel modularer Komponenten in verteilten Systemen.
 
 Mein Untersuchungsanliegen: Inwieweit optimiert die Integration von Blazor und dem Oqtane-Framework die Konsistenz und Wartbarkeit modularer Web-Architekturen im Vergleich zu den für mich gewohnten Technologie-Stacks (React/Node.js)?
 
@@ -49,7 +49,12 @@ Auch steht die Wahl der Programmiersprache und des CMS an. Nachdem wir im Unterr
 - DNN / Dot Net Nuke
   > Dieses CMS ist der Platzhirsch. Es wird von der DNN Foundation gewartet, arbeitet mit dem Dotnet Framework, welches nicht unter Linux läuft. Und ein Windows Server ist im Betrieb teurer und in der Absicherung aufwändiger.
 - Oqtane
-  > Oqtane wirkt auf sehr modular und flexibel, auch innerhalb von Modulen kann man auf alle funktionen des ASP.NET Core Frameworks verwenden. Die Dokumentation wirkt nicht besonders gut, aber ausreichend. Die enthaltenen Fehlinformationen und mangelnden Anleitungen für den Betrieb mit Linux sind erst im Nachhinein aufgefallen.
+  <<<<<<< HEAD
+  > # Oqtane wirkt auf sehr modular und flexibel, auch innerhalb von Modulen kann man auf alle funktionen des ASP.NET Core Frameworks verwenden. Die Dokumentation wirkt nicht besonders gut, aber ausreichend. Die enthaltenen Fehlinformationen und mangelnden Anleitungen für den Betrieb mit Linux sind erst im Nachhinein aufgefallen.
+  >
+  > Oqtane wirkt auf sehr modular und flexibel, auch innerhalb von Modulen kann man auf alle Funktionen des ASP.NET Core Frameworks verwenden. Die Dokumentation wirkt nicht besonders gut, aber ausreichend. Die enthaltenen Fehlinformationen und mangelnden Anleitungen für den Betrieb mit Linux sind erst im Nachhinein aufgefallen.
+  >
+  > > > > > > > afd1f3b (Fix: Typos and move Sources into the end)
 
 Insbesondere aufgrund seiner sehr hohen Flexibilität, haben wir uns am Ende für Oqtane entschieden.
 
@@ -63,7 +68,7 @@ Im Bereich der Datenbanken musste ich mir ein paar Fragen stellen:
 2. Mit welcher speziellen Implementierung bekommen wir Support und bei welcher haben wir Vorwissen im Team?
 3. Ist das auserkorene System kompatibel mit dem CMS, auf dem wir aufbauen?
 
-Es war von Anfang an klar, dass es ein SQL-basiertes System wird, da wir im Team nur mit SQL-basierten Systemen Erfahrungen haben. Außerdem unterstützt unser CMS (Oqtane) nur SQL-basierte Systeme. In der Linuxwelt kommen jetzt nur noch ein paar Datenbankmanagementsysteme in die Auswahl: PostgreSQL, MySQL / MariaDB, SQLite. Da ist die Wahl auf PostgreSQL gefallen. Grund dafür war meine Vorerfahrung mit diesem Datenbankmanagementsystem, welche ich in meinem Nebenjob errungen habe.
+Es war von Anfang an klar, dass es ein SQL-basiertes System wird, da wir im Team nur mit SQL-basierten Systemen Erfahrungen haben. Außerdem unterstützt unser CMS (Oqtane) nur SQL-basierte Systeme. In der Linuxwelt kommen jetzt nur noch ein paar Datenbankmanagementsysteme in die Auswahl: PostgreSQL, MySQL / MariaDB, SQLite. Da ist die Wahl auf PostgreSQL gefallen. Grund dafür war meine Vorerfahrung mit diesem Datenbankmanagementsystem, welche ich in meinem Nebenjob erlangt habe.
 
 ### 3.2 Beschreibung und Architektur von Oqtane
 
@@ -73,10 +78,6 @@ In dieser Diplomarbeit fokussieren wir uns hauptsächlich auf `Themes` und `Modu
 
 Ein `Module` (Modul) soll neue Funktionalitäten in das CMS hinzufügen und ein `Theme` soll die ganze Gestaltung der Webseite (die Shell) festlegen. [^6]
 
-[^5]: https://www.oqtane.org/#about
-
-[^6]: https://docs.oqtane.org/dev/extensions/index.html
-
 #### 3.2.1 Architektur eines Moduls
 
 Ein Modul in Oqtane besteht aus vier Projekten:
@@ -124,7 +125,7 @@ Die VPN basierten Zugänge sind tendenziell schwieriger zu finden und auszunutze
 
 #### 3.4.1 Blazor [^7]
 
-Blazor ist ein kostenloses und quelloffenes Web-Framework, welches es möglich macht Benutzeroberflächen für Web-Browser, basierend auf C# and HTML, zu erstellen. Es wird von Microsoft als teil des ASP.NET Core Frameworks entwickelt.
+Blazor ist ein kostenloses und quelloffenes Web-Framework, welches es möglich macht Benutzeroberflächen für Web-Browser, basierend auf C# und HTML, zu erstellen. Es wird von Microsoft als teil des ASP.NET Core Frameworks entwickelt.
 
 Blazor hat mehrere Hosting-Modelle:
 
@@ -157,7 +158,7 @@ Razor-Komponenten (in dieser Arbeit, sowie umgangssprachlich, auch oft nur Kompo
 
 Mit`@count` in Zeile 3 wird der Wert der Variablen count in den `<p>` Tag mit eingebaut. Mit `@onclick="Increment"` in Zeile 5 wird die onclick Property vom `<button>`Tag auf die Increment Methode im C# Code gesetzt. Der `@code` Block in Zeile 7 ist der C# Code, welcher diese Komponente dynamisch macht. Hier ist die Variable count und die Methode Increment definiert, welche dieser Komponente interaktiv macht.
 
-Razor hat auch eine Reihe an Keywords, wie zum Beipsiel (nur Auszugsweise, bzw. die die wir verwendet haben):
+Razor hat auch eine Reihe an Keywords, wie zum Beispiel (nur Auszugsweise, bzw. die die wir verwendet haben):
 
 - namespace: Gibt den aktuellen Namespace in der Razor Datei an.
 - inherits: Gibt die Superklasse der generierten C# Klasse an.
@@ -165,8 +166,6 @@ Razor hat auch eine Reihe an Keywords, wie zum Beipsiel (nur Auszugsweise, bzw.
 - foreach: Für Wiederholungen im Markup
 - if: Für Verzweigungen im Markup
 
-[^7]: https://en.wikipedia.org/wiki/Blazor
-
 #### 3.4.2 Kommunikation zwischen Front- und Backend
 
 Wie Front- und Backend miteinander interagieren hängt hauptsächlich vom Render-Modus ab. Oqtane kann auf verschiedene Arten betrieben werden. Hierbei ist es dem Modulentwickler ziemlich egal, welche Art der Kommunikation (WebSockets, HTTP Long-Polling, REST) verwendet wird. SignalR ist eine Library aus dem ASP.NET Framework, welche es möglich macht, Server zu Client Kommunikation zu betreiben. Oqtane verwendet SignalR im `Interactive Server (SignalR)` Render-Modus.
@@ -179,8 +178,6 @@ Wie der Software-Architekt Martin Fowler, der den Begriff im Jahr 2004 maßgebli
 
 In den folgenden beiden Kapiteln wird das Dependency Inversion Principle und das Microsoft Dependency Injection Framework genauer vorgestellt.
 
-[^9]: https://martinfowler.com/articles/injection.html
-
 #### 3.5.1 Dependency Inversion Principle [^1]
 
 Das Dependency-Inversion-Principle (DIP / auf Deutsch: Abhängigkeits-Umkehr-Prinzip) ist eines von den fünf `SOLID` Prinzipien in der Softwareentwicklung.
@@ -217,11 +214,11 @@ Das High-Level-Modul ruft lediglich eine Abstraktion eines Low-Level-Moduls auf,
 
 #### 3.5.2 Microsoft Dependency Injection Framework
 
-Dependency Injektion ist in .NET genau so wie Konfiguration, Protokollierung und das Optionsmuster ins Framework integriert. [^4]
+Dependency Injection ist in .NET genau so wie Konfiguration, Protokollierung und das Optionsmuster ins Framework integriert. [^4]
 
 Alle Dependencies werden in einem `Service-Container` zur Verwaltung registriert. .NET hat einen eingebauten `Service-Container` (eine Implementierung des `IServiceProvider`). [^4]
 
-Das Dependency Injection Framework verwaltet alle Instanzen. Nach Bedarf werden Instanzen erstellt, oder wieder entsorgt (sofern das Service nicht mehr gebraucht wird). Beim Instanziieren einer Klasse werden alle im Konstruktor erwarteten Dependencies bereitgestellt, bzw. selbst instanziiert und dannach bereitgestellt. [^4]
+Das Dependency Injection Framework verwaltet alle Instanzen. Nach Bedarf werden Instanzen erstellt, oder wieder entsorgt (sofern das Service nicht mehr gebraucht wird). Beim Instanziieren einer Klasse werden alle im Konstruktor erwarteten Dependencies bereitgestellt, bzw. selbst instanziiert und danach bereitgestellt. [^4]
 
 Hier ein Beispiel aus der Dokumentation von Microsoft: [^4]
 
@@ -263,7 +260,7 @@ public sealed class Worker(IMessageWriter messageWriter) : BackgroundService
 
 Das ist ein simples Beispiel, welches Teile des DI Frameworks zeigt. Wir haben einen Service (Klasse Worker), ein Dependency (Klasse MessageWriter) und eine Abstraktionsebene, von dem Dependency (Interface IMessageWriter).
 
-Bei Programmstart wird zuerst manuell der `Service-Container` erstellt, dannach alle Module registriert (entweder als HostedService, oder als Modul mit einer spezifischen Lifetime (Scoped, Transient, Singleton)).
+Bei Programmstart wird zuerst manuell der `Service-Container` erstellt, danach alle Module registriert (entweder als HostedService, oder als Modul mit einer spezifischen Lifetime (Scoped, Transient, Singleton)).
 
 Mit dem Aufruf von `builder.Build()` wird intern ein Dependency Graph erstellt und mit `host.Run()` wird versucht die Klasse Worker zu instanziieren und zu starten. Nachdem Worker ein Dependency auf IMessageWriter hat, wird über den zuvor erstellten Dependency-Graph die Implementierung von IMessageWriter gesucht. Jetzt wird MessageWriter instanziiert und dem Konstruktor von Worker übergeben, damit seine Dependencies befriedigt werden.
 
@@ -279,14 +276,6 @@ architecture-beta
     ib:R <-- L:b
 ```
 
-[^1]: https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles#dependency-inversion
-
-[^2]: https://blog.logrocket.com/dependency-inversion-principle/
-
-[^3]: https://www.oodesign.com/dependency-inversion-principle
-
-[^4]: https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection/overview
-
 ### 3.6 Continuous Integration
 
 Gitea, das Versionskontrollsystem dieser Diplomarbeit, hat einen Continuous-Integration-System eingebaut. Im Kern ist es baugleich zu den GitHub-Pipelines. Man kann im `.gitea/workflow` Ordner `.yml` Dateien ablegen, welche dann das Verhalten der Workflows definieren.
@@ -337,7 +326,7 @@ Für die Sicherung und Zusammenarbeit wurde im Rahmen dieser Arbeit Remote-Repos
 
 ### 4.4 Gitea
 
-Als schlanke und selbst gehostete Open-Source-Alternative zu Plattformen wie GitHub oder GitLab wurde für die Verwaltung der Repositories Gitea eingesetzt. Hauptgrund für die Benutzung von Gitea war meine bereits aufgesetzte Instanz, welche schon mehrere Jahre in verwendung war und mit der es im Team auch schon Erfahrungen gab. Gitea bietet neben der reinen Git-Verwaltung essenzielle Werkzeuge für den Software-Lebenszyklus, wie ein integriertes Issue-Tracking, Code-Reviews über Pull-Requests sowie eine Benutzerverwaltung, und unterstützt somit die strukturierte Umsetzung der Diplomarbeit im Team.[^12]
+Als schlanke und selbst gehostete Open-Source-Alternative zu Plattformen wie GitHub oder GitLab wurde für die Verwaltung der Repositories Gitea eingesetzt. Hauptgrund für die Benutzung von Gitea war meine bereits aufgesetzte Instanz, welche schon mehrere Jahre in Verwendung war und mit der es im Team auch schon Erfahrungen gab. Gitea bietet neben der reinen Git-Verwaltung essenzielle Werkzeuge für den Software-Lebenszyklus, wie ein integriertes Issue-Tracking, Code-Reviews über Pull-Requests sowie eine Benutzerverwaltung, und unterstützt somit die strukturierte Umsetzung der Diplomarbeit im Team.[^12]
 
 #### 4.4.1 Repositories
 
@@ -363,16 +352,6 @@ Gitea Actions wurden eingesetzt, um CI/CD-Pipelines (Continuous Integration / Co
 
 Gitea fungierte zusätzlich als Register für Pakete und Container-Images. Selbst erstellte Artefakte, wie das Debian Paket für die Bereitstellung der Anwendung, wurden direkt in der Gitea-Instanz versioniert gespeichert. Dadurch waren alle notwendigen Komponenten für das Deployment an einem zentralen Ort verfügbar und abrufbar. Gitea selbst unterstützt verschiedenste Pakettypen. Darunter fallen unteranderem NuGet- und Debianpakete. Für beide haben wir in dieser Arbeit verwendung gefunden. [^12][^16]
 
-[^12]: https://docs.gitea.com/
-
-[^13]: https://docs.gitea.com/installation/comparison#issue-tracker
-
-[^14]: https://docs.gitea.com/usage/pull-request
-
-[^15]: https://docs.gitea.com/usage/actions/overview
-
-[^16]: https://docs.gitea.com/usage/packages/overview
-
 ### 4.5 Kommunikation
 
 ## 5 Module
@@ -389,25 +368,21 @@ Integration von Brevo
 
 Für den tatsächlichen Versand der E-Mails nutzen wir den Cloud-Dienst Brevo. Dieser bietet eine zuverlässige Zustellung (hohe Reputation der Mailserver), stellt uns jedoch in der kostenlosen Variante vor eine Herausforderung: nur 300 E-Mails pro Tag.
 
-`Batch-Processing`: Mails werden nicht sofort ("Fire and Forget") versendet, sondern in eine Versandwarteschlange geschrieben. Nachdem schon die Notifications Infrastruktur, welche sich auch um den Mail versand kümmert, ins Framework eingebaut worden ist, nutzen wir diese geleich und `schedulen` unsere E-Mails. Immer 100 Mails alle 24 Stunden bis alle Ziele die Mails erhalten haben. Das Limit von 100 / Tag ist konservativ sehr niedrig angesetzt, damit funktionen wie Passwort Reset Mails nicht (leicht) dadurch beeinflusst werden können.
+`Batch-Processing`: Mails werden nicht sofort ("Fire and Forget") versendet, sondern in eine Versandwarteschlange geschrieben. Nachdem schon die Notifications Infrastruktur, welche sich auch um den Mail versand kümmert, ins Framework eingebaut worden ist, wird diese gleich zum `schedulen` unserer E-Mails genutzt. Immer 100 Mails alle 24 Stunden bis alle Ziele die Mails erhalten haben. Das Limit von 100 / Tag ist konservativ sehr niedrig angesetzt, damit funktionen wie Passwort Reset Mails nicht (leicht) dadurch beeinflusst werden können.
 
 #### 5.1.2 Token Lifetime
 
-Das Token Lifetime Modul wurde geschrieben, um die Token-Lebenszeit konfigurierbar zu machen. Notwendig war das, um die Passwort Reset Links im initialen Mail versand länger gultig sein zu lassen. Durch das `Batch Processing` war es Möglich, dass eine Mail erst Tage nach erstellen des Links hinaus geschickt wird und bei einer Standard Ablaufdauer von 2 Tagen sind machne Links schon ungültig, bis sie den Mail Server erreichen. Ziel war es, die Änderung der Lebenszeit für Administratoren im User Interface im Admin Bereich möglich zu machen.
+Das Token Lifetime Modul wurde geschrieben, um die Token-Lebenszeit konfigurierbar zu machen. Notwendig war das, um die Passwort Reset Links im initialen Mail versand länger gultig sein zu lassen. Durch das `Batch Processing` war es möglich, dass eine Mail erst Tage nach erstellen des Links hinaus geschickt wird und bei einer Standard Ablaufdauer von 2 Tagen sind mache Links schon ungültig, bis sie den Mail Server erreichen. Ziel war es, die Änderung der Lebenszeit für Administratoren im User Interface im Admin Bereich möglich zu machen.
 
 Technisch bedeutet das, dass die standardmäßig vorkonfigurierten `DataProtectionTokenProviderOptions` explizit konfiguriert werden müssen. [^10] Der ASP.NET Core `UserManager`, welcher das generieren der Tokens übernimmt, verwendet einen `DataProtectorTokenProvider` und dieser wiederum kann mithilfe der `DataProtectionTokenProviderOptions` konfiguriert werden.
 
 Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
 
-- `der Workaround`: Ein eigenes Modul, welches in seiner `Server/Startup.cs` die benötigten Werte korrekt setzt. Das hat den Vorteil, dass wir keine Änderungen im CMS selbst haben, sondern nur unsere eigene Erweiterung dafür schreiben. Andererseits könnte durch die undeterminischte Ladereihenfolge eine `race-condition` auftreten. [^11] Darüberhinaus haben wir keinen gleichzeitigen Zugriff auf appsettings.json und den IServiceProvider in dem wir die Konfiguration setzen müssen. => Nachdem wir in der Konfigurationsphase auch noch keinen Datenbankzugriff haben, können wir die Werte nicht aus der DB Laden, sondern müssen auf eine Text Datei zurückgreifen.
-- `die saubere Lösung`: Eine Änderung im Kern von Oqtane. Also implementieren wir in unserem Fork von Oqtane die Konfigurationslogik für die Tokenlifetime. Hier könnte die Konfigurationslogik direkt in `OqtaneServiceCollectionExtensions.cs` hinzufügen, hier werden auch alle anderen Oqtane Spezifischen Configurationen gesetzt. Das hat den Vorteil, dass der Code aufgeräumter und sauberer ist und die `race-condition` verhindert werden kann. [^11] Der initiale Grund dagegen ist, dass wir ein weiteres Git Repository zum warten haben (den Fork vom Oqtane.Framework), welches jetzt nicht mehr mit Upstream Commit-gleich ist.
+- `der Workaround`: Ein eigenes Modul, welches in seiner `Server/Startup.cs` die benötigten Werte korrekt setzt. Das hat den Vorteil, dass wir keine Änderungen im CMS selbst haben, sondern nur unsere eigene Erweiterung dafür schreiben. Andererseits könnte durch die undeterministische Ladereihenfolge eine `race-condition` auftreten. [^11] Darüberhinaus ist der gleichzeitigen Zugriff auf appsettings.json und dem IServiceProvider in dem die Konfiguration gesetzt muss. => Nachdem in der Konfigurationsphase auch noch keinen Datenbankzugriff haben, können die Werte nicht aus der DB geladen werden, sondern müssen auf eine Text Datei zurückgreifen.
+- `die saubere Lösung`: Eine Änderung im Kern von Oqtane. Also wird in unserem Fork von Oqtane die Konfigurationslogik für die Tokenlifetime implementiert. In diesem Fall könnte die Konfigurationslogik direkt in `OqtaneServiceCollectionExtensions.cs` hinzugefügt werden, da hier auch alle anderen Oqtane Spezifischen Konfigurationen gesetzt werden. Das hat den Vorteil, dass der Code aufgeräumter und sauberer ist und die `race-condition` verhindert werden kann. [^11] Der initiale Grund dagegen ist, dass wir ein weiteres Git Repository zum warten haben (den Fork vom Oqtane.Framework), welches jetzt nicht mehr mit Upstream Commit-gleich ist.
 
 `Der Workaround` ist die Möglichkeit für die wir uns entschieden haben, allerdings ist das nicht die schönste Lösung. Eine eventuell nachfolgende Diplomarbeit kann an dieser Stelle ansetzen und `die saubere Lösung` implementieren.
 
-[^10]: https://andrewlock.net/implementing-custom-token-providers-for-passwordless-authentication-in-asp-net-core-identity/#changing-the-default-token-lifetime
-
-[^11]: https://www.cs.umd.edu/projects/syschat/raceConditions.pdf
-
 #### 5.1.3 Reporting System
 
 Eine weitere Anforderung der Diplomarbeit war es Einträge in Modulen wie der `Hall of Fame`, dem `Schwarzen Brett` und dem Premium Bereich (`Engineer Applications`) melden zu können. Am Anfang war es wichtig, dass jeder schnell vorrankommt, allerdings haben wir die Kommunikation Teamintern ein wenig verschlafen und dadurch ein paar Funktionen doppelt geschrieben. Dadurch kam es zu inkonsistenzen in der Verwendung der unterschiedlichen Reporting Systeme. Deswegen haben wir uns am Ende für eine globales Reporting System entschieden.
@@ -434,9 +409,9 @@ sequenceDiagram
 
 Im oben dargestellten Ablaufdiagram werden das ReportingComponent und der ReportingHandler vom Reporting System über Dependency Injection bereitgestellt, nicht vom Modul selbst. Dadurch erreichen wir eine bessere Trennung der Zuständigkeiten und halten das S in SOLID ein: `Single responsibility`. Die Module sind jetzt nicht mehr für das Reporting selber verantwortlich, sondern müssen nur das Reportings System einbinden.
 
-Damit DI funktioniert muss für den DI Consumer (`also das Modul, welches das Reporting System einbinden möchte`) das Interface zur Kompilierzeit zur Verfügung stehen. Um das zu erreichen haben wir eine neue Klassenbibliothek erstellt: Sie heißt Interfaces wird per Gitea Actions automatisch in ein Nuget Paket gebaut und in der `Gitea Actions Nuget Registry` veröffentlicht. Dieses Nuget Paket wird dann in jedem notwendigen Modul als dependency hinzugefügt und damit kann man Modulübergreifend auf die Services und das IReporting Component zugreifen.
+Damit DI funktioniert muss für den DI Consumer (`also das Modul, welches das Reporting System einbinden möchte`) das Interface zur Kompilierzeit zur Verfügung stehen. Um das zu erreichen habe ich eine neue Klassenbibliothek erstellt: Sie heißt Interfaces wird per Gitea Actions automatisch in ein Nuget Paket gebaut und in der `Gitea Actions Nuget Registry` veröffentlicht. Dieses Nuget Paket wird dann in jedem notwendigen Modul als dependency hinzugefügt und damit kann man Modulübergreifend auf die Services und das IReporting Component zugreifen.
 
-Die Implementierung des IReportingComponents stellt nur eine Property (`ReportType`, welche den TypeName der Razor Komponente zurückliefert, damit Dynamic Component sie laden kann) und eine Methode (`ConstructParameterList`, welche das Parameter Dictionary erstellt. Nur zwecks Typensicherheit eingefügt) bereit. Mit dem Dynamic Component von Razor ist es möglich, per C# Code unterschiedliche Komponenten zu rendern und damit auch die per DI injezierte Klasse.
+Die Implementierung des IReportingComponents stellt nur eine Property (`ReportType`, welche den TypeName der Razor Komponente zurückliefert, damit Dynamic Component sie laden kann) und eine Methode (`ConstructParameterList`, welche das Parameter Dictionary erstellt. Nur zwecks Typensicherheit eingefügt) bereit. Mit dem Dynamic Component von Razor ist es möglich, per C# Code unterschiedliche Komponenten zu rendern und damit auch die per DI injizierte Klasse.
 
 ```razor
 @inject IReportUI ReportingComponent
@@ -489,14 +464,14 @@ Die Anzeige der Einträge erfolgt in einer responsiven Grid-Ansicht (Index-Kompo
 
 Um die Mitglieder regelmäßig über neue Inhalte zu informieren, wurde ein automatisierter `Cronjob` implementiert. Dieser Job läuft im Hintergrund des Oqtane-Frameworks und führt folgende Schritte aus:
 
-- Filterung: Der Job identifiziert alle Einträge, die seit dem letzten Versand erstellt wurden. 
+- Filterung: Der Job identifiziert alle Einträge, die seit dem letzten Versand erstellt wurden.
 - Zielgruppenselektion: Es werden alle Benutzer identifiziert, die der Rolle "Absolventen" angehören.
 - Zusammenstellung: Für jeden dieser Benutzer wird eine personalsierte Email-Notification generiert, welche eine Zusammenfassung der neuen Einträge enthält.
 - Versand: Die generierten Notifications werden in die Warteschlange der Notification-Infrastruktur eingereiht und sukzessive versendet.
-Integration des Reporting-Systems
-
+  Integration des Reporting-Systems
 
 #### 5.3.3 Reporting System
+
 Ein wichtiges Merkmal des Schwarzen Bretts zur Sicherstellung der Inhaltsqualität ist die Anbindung an das globale Reporting-System (siehe 5.4). In der Detailansicht wird über Dependency Injection die IReportUI-Komponente eingebunden. Mithilfe der DynamicComponent von Blazor wird die Melde-Funktion nahtlos in die Oberfläche des Moduls integriert. Dadurch können unangemessene Inhalte direkt von Benutzern gemeldet werden.
 
 #### 5.3.4 Technischer Hintergrund
@@ -511,7 +486,7 @@ Ein Learning, welches doch relativ schnell aufkam ist im Bereich der IT eigentli
 
 ### 6.2 Teamleitung (Motivation / Downsizing)
 
-Nachdem ich mich von Anfang an volkommen in das Deploymentproblem von Oqtane gestürzt habe, habe ich meine Rolle als Teamleitung etwas schleifen lassen. Dadurch fehlte bei einigen Teammitgliedern initial die Identifikation mit dem Projekt und in weitererfolge auch die Motivation an diesem Projekt mitzuarbeiten. Nachdem im Verlauf des Frühlings und über den Sommer von der hälfte des Teams trotz Besprechungen und Mahnungen keine Beiträge zu dem Projekt kamen, haben Hr. Prof. Gürth und ich uns dazu entschieden uns von 2 Personen vor unterschreiben des Projektantrages zu trennen. Grund dazu war die Angst, die mangelnde Motivation zieht das restliche Team mit hinunter. Wir wollten uns trotz des Downsizings nicht an Funktionalitäten sparen und haben uns für das nächste halbe bis dreiviertel Jahr einen ziemlich strikten Zeiplan vorgenommen.
+Nachdem ich mich von Anfang an volkommen in das Deploymentproblem von Oqtane gestürzt habe, habe ich meine Rolle als Teamleitung etwas schleifen lassen. Dadurch fehlte bei einigen Teammitgliedern initial die Identifikation mit dem Projekt und in weitererfolge auch die Motivation an diesem Projekt mitzuarbeiten. Nachdem im Verlauf des Frühlings und über den Sommer von der hälfte des Teams trotz Besprechungen und Mahnungen keine Beiträge zu dem Projekt kamen, haben Hr. Prof. Gürth und ich uns dazu entschieden uns von 2 Personen vor unterschreiben des Projektantrages zu trennen. Grund dazu war die Angst, die mangelnde Motivation zieht das restliche Team mit hinunter. Wir wollten uns trotz des Downsizings nicht an Funktionalitäten sparen und haben uns für das nächste halbe bis dreiviertel Jahr einen ziemlich strikten Zeitplan vorgenommen.
 
 ### 6.3 Arbeitszeiteinschätzung (Zeitverzug)
 
@@ -534,8 +509,6 @@ Um das Projektziel dennoch zu erreichen, wurde der Zeitplan im Herbst 2025 massi
 > (Jon Bentley. 1985. Programmimg pearls. Commun. ACM 28, 9 (Sept. 1985), 896–901. https://doi.org/10.1145/4284.315122) [^8]
 > Diese Diplomarbeit liefert weitere Evidenz, dass diese Faustregel stimmt.
 
-[^8]: https://dl.acm.org/doi/10.1145/4284.315122
-
 ### 6.4 Sprints und Meetings (in Zukunft ja asynchron)
 
 Ein zentrales Problem in unserer ursprünglichen Arbeitsweise war die Kopplung von Besprechungsterminen mit festen „Commit-Deadlines“ (dem Ende des aktuellen Sprint zyklusses). Da wir uns einmal pro Woche für sechs Stunden am Stück trafen, entstand ein destruktives Muster:
@@ -549,3 +522,37 @@ Lösungsansatz: Meetings und Besprechungen asynchron zueinander setzen.
 - Asynchrone Daily-Updates: Statusberichte erfolgen schriftlich (z. B. in Gitea Issues oder YouTrack), nicht mehr in stundenlangen Call-Marathons. Das nimmt den zeitlichen Druck vom einzelnen Entwickler. Oder zumindest in kurzen Commitnachrichten, welche am Ende des Tages automatisch an alle Teammitglieder zum überblick gesendet werden (eventuell mit @username tagging, um eine Person nochmal genau anzusprechen)
 - Review-First-Policy: Ein Feature gilt erst dann als „fertig“, wenn es einen asynchronen Code-Review-Prozess durchlaufen hat. Das Meeting dient nur noch der Klärung von Blockern, nicht der Präsentation von Code. Das war eigentlich schon von Anfang an in unserer `Definition of Done` festgelegt worden.
 - Entkoppelung von Meeting und Deadline: Meetings sollten der Synchronisation dienen, während die Abgabe von Arbeitspaketen kontinuierlich (Continuous Integration) erfolgen muss, um Lastspitzen (in der [Gitea Actions](#Continuous Integration) Pipeline) am Tag der Besprechung zu vermeiden.
+
+# Quellen
+
+[^1]: https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles#dependency-inversion
+
+[^2]: https://blog.logrocket.com/dependency-inversion-principle/
+
+[^3]: https://www.oodesign.com/dependency-inversion-principle
+
+[^4]: https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection/overview
+
+[^5]: https://www.oqtane.org/#about
+
+[^6]: https://docs.oqtane.org/dev/extensions/index.html
+
+[^7]: https://en.wikipedia.org/wiki/Blazor
+
+[^8]: https://dl.acm.org/doi/10.1145/4284.315122
+
+[^9]: https://martinfowler.com/articles/injection.html
+
+[^10]: https://andrewlock.net/implementing-custom-token-providers-for-passwordless-authentication-in-asp-net-core-identity/#changing-the-default-token-lifetime
+
+[^11]: https://www.cs.umd.edu/projects/syschat/raceConditions.pdf
+
+[^12]: https://docs.gitea.com/
+
+[^13]: https://docs.gitea.com/installation/comparison#issue-tracker
+
+[^14]: https://docs.gitea.com/usage/pull-request
+
+[^15]: https://docs.gitea.com/usage/actions/overview
+
+[^16]: https://docs.gitea.com/usage/packages/overview

From 4559b758a7d7d49ff197dc65855416971717288a Mon Sep 17 00:00:00 2001
From: KoCoder <me@kocoder.xyz>
Date: Wed, 18 Mar 2026 22:17:17 +0100
Subject: [PATCH 22/22] Fix: Broken commit marker

---
 ...dividueller-teil-Konstantin-Hintermayer.md | 23 ++++++++-----------
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
index bdfa7ad..789f679 100644
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -49,12 +49,7 @@ Auch steht die Wahl der Programmiersprache und des CMS an. Nachdem wir im Unterr
 - DNN / Dot Net Nuke
   > Dieses CMS ist der Platzhirsch. Es wird von der DNN Foundation gewartet, arbeitet mit dem Dotnet Framework, welches nicht unter Linux läuft. Und ein Windows Server ist im Betrieb teurer und in der Absicherung aufwändiger.
 - Oqtane
-  <<<<<<< HEAD
-  > # Oqtane wirkt auf sehr modular und flexibel, auch innerhalb von Modulen kann man auf alle funktionen des ASP.NET Core Frameworks verwenden. Die Dokumentation wirkt nicht besonders gut, aber ausreichend. Die enthaltenen Fehlinformationen und mangelnden Anleitungen für den Betrieb mit Linux sind erst im Nachhinein aufgefallen.
-  >
   > Oqtane wirkt auf sehr modular und flexibel, auch innerhalb von Modulen kann man auf alle Funktionen des ASP.NET Core Frameworks verwenden. Die Dokumentation wirkt nicht besonders gut, aber ausreichend. Die enthaltenen Fehlinformationen und mangelnden Anleitungen für den Betrieb mit Linux sind erst im Nachhinein aufgefallen.
-  >
-  > > > > > > > afd1f3b (Fix: Typos and move Sources into the end)
 
 Insbesondere aufgrund seiner sehr hohen Flexibilität, haben wir uns am Ende für Oqtane entschieden.
 
@@ -368,24 +363,24 @@ Integration von Brevo
 
 Für den tatsächlichen Versand der E-Mails nutzen wir den Cloud-Dienst Brevo. Dieser bietet eine zuverlässige Zustellung (hohe Reputation der Mailserver), stellt uns jedoch in der kostenlosen Variante vor eine Herausforderung: nur 300 E-Mails pro Tag.
 
-`Batch-Processing`: Mails werden nicht sofort ("Fire and Forget") versendet, sondern in eine Versandwarteschlange geschrieben. Nachdem schon die Notifications Infrastruktur, welche sich auch um den Mail versand kümmert, ins Framework eingebaut worden ist, wird diese gleich zum `schedulen` unserer E-Mails genutzt. Immer 100 Mails alle 24 Stunden bis alle Ziele die Mails erhalten haben. Das Limit von 100 / Tag ist konservativ sehr niedrig angesetzt, damit funktionen wie Passwort Reset Mails nicht (leicht) dadurch beeinflusst werden können.
+`Batch-Processing`: Mails werden nicht sofort ("Fire and Forget") versendet, sondern in eine Versandwarteschlange geschrieben. Nachdem schon die Notifications Infrastruktur, welche sich auch um den Mail versand kümmert, ins Framework eingebaut worden ist, wird diese gleich zum `schedulen` unserer E-Mails genutzt. Immer 100 Mails alle 24 Stunden bis alle Ziele die Mails erhalten haben. Das Limit von 100 / Tag ist konservativ sehr niedrig angesetzt, damit Funktionen wie Passwort Reset Mails nicht (leicht) dadurch beeinflusst werden können.
 
 #### 5.1.2 Token Lifetime
 
-Das Token Lifetime Modul wurde geschrieben, um die Token-Lebenszeit konfigurierbar zu machen. Notwendig war das, um die Passwort Reset Links im initialen Mail versand länger gultig sein zu lassen. Durch das `Batch Processing` war es möglich, dass eine Mail erst Tage nach erstellen des Links hinaus geschickt wird und bei einer Standard Ablaufdauer von 2 Tagen sind mache Links schon ungültig, bis sie den Mail Server erreichen. Ziel war es, die Änderung der Lebenszeit für Administratoren im User Interface im Admin Bereich möglich zu machen.
+Das Token Lifetime Modul wurde geschrieben, um die Token-Lebenszeit konfigurierbar zu machen. Notwendig war das, um die Passwort Reset Links im initialen Mail versand länger gültig sein zu lassen. Durch das `Batch Processing` war es möglich, dass eine Mail erst Tage nach erstellen des Links hinaus geschickt wird und bei einer Standard Ablaufdauer von 2 Tagen sind manche Links schon ungültig, bis sie den Mail Server erreichen. Ziel war es, die Änderung der Lebenszeit für Administratoren im User Interface im Admin Bereich möglich zu machen.
 
 Technisch bedeutet das, dass die standardmäßig vorkonfigurierten `DataProtectionTokenProviderOptions` explizit konfiguriert werden müssen. [^10] Der ASP.NET Core `UserManager`, welcher das generieren der Tokens übernimmt, verwendet einen `DataProtectorTokenProvider` und dieser wiederum kann mithilfe der `DataProtectionTokenProviderOptions` konfiguriert werden.
 
 Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
 
-- `der Workaround`: Ein eigenes Modul, welches in seiner `Server/Startup.cs` die benötigten Werte korrekt setzt. Das hat den Vorteil, dass wir keine Änderungen im CMS selbst haben, sondern nur unsere eigene Erweiterung dafür schreiben. Andererseits könnte durch die undeterministische Ladereihenfolge eine `race-condition` auftreten. [^11] Darüberhinaus ist der gleichzeitigen Zugriff auf appsettings.json und dem IServiceProvider in dem die Konfiguration gesetzt muss. => Nachdem in der Konfigurationsphase auch noch keinen Datenbankzugriff haben, können die Werte nicht aus der DB geladen werden, sondern müssen auf eine Text Datei zurückgreifen.
+- `der Workaround`: Ein eigenes Modul, welches in seiner `Server/Startup.cs` die benötigten Werte korrekt setzt. Das hat den Vorteil, dass wir keine Änderungen im CMS selbst haben, sondern nur unsere eigene Erweiterung dafür schreiben. Andererseits könnte durch die undeterministische Ladereihenfolge eine `race-condition` auftreten. [^11] Darüber hinaus besteht kein gleichzeitiger Zugriff auf die appsettings.json und den IServiceProvider, in dem die Konfiguration gesetzt werden muss. => Nachdem wir in der Konfigurationsphase auch noch keinen Datenbankzugriff haben, können die Werte nicht aus der Datenbank geladen werden, sondern wir müssen auf eine Textdatei zurückgreifen.
 - `die saubere Lösung`: Eine Änderung im Kern von Oqtane. Also wird in unserem Fork von Oqtane die Konfigurationslogik für die Tokenlifetime implementiert. In diesem Fall könnte die Konfigurationslogik direkt in `OqtaneServiceCollectionExtensions.cs` hinzugefügt werden, da hier auch alle anderen Oqtane Spezifischen Konfigurationen gesetzt werden. Das hat den Vorteil, dass der Code aufgeräumter und sauberer ist und die `race-condition` verhindert werden kann. [^11] Der initiale Grund dagegen ist, dass wir ein weiteres Git Repository zum warten haben (den Fork vom Oqtane.Framework), welches jetzt nicht mehr mit Upstream Commit-gleich ist.
 
 `Der Workaround` ist die Möglichkeit für die wir uns entschieden haben, allerdings ist das nicht die schönste Lösung. Eine eventuell nachfolgende Diplomarbeit kann an dieser Stelle ansetzen und `die saubere Lösung` implementieren.
 
 #### 5.1.3 Reporting System
 
-Eine weitere Anforderung der Diplomarbeit war es Einträge in Modulen wie der `Hall of Fame`, dem `Schwarzen Brett` und dem Premium Bereich (`Engineer Applications`) melden zu können. Am Anfang war es wichtig, dass jeder schnell vorrankommt, allerdings haben wir die Kommunikation Teamintern ein wenig verschlafen und dadurch ein paar Funktionen doppelt geschrieben. Dadurch kam es zu inkonsistenzen in der Verwendung der unterschiedlichen Reporting Systeme. Deswegen haben wir uns am Ende für eine globales Reporting System entschieden.
+Eine weitere Anforderung der Diplomarbeit war es Einträge in Modulen wie der `Hall of Fame`, dem `Schwarzen Brett` und dem Premium Bereich (`Engineer Applications`) melden zu können. Am Anfang war es wichtig, dass jeder schnell vorankommt, allerdings haben wir die Kommunikation Teamintern ein wenig verschlafen und dadurch ein paar Funktionen doppelt geschrieben. Dadurch kam es zu Inkonsistenzen in der Verwendung der unterschiedlichen Reporting Systeme. Deswegen haben wir uns am Ende für eine globales Reporting System entschieden.
 
 Angestrebt wurde folgender Ablauf für das Melden eines Eintrags:
 
@@ -409,7 +404,7 @@ sequenceDiagram
 
 Im oben dargestellten Ablaufdiagram werden das ReportingComponent und der ReportingHandler vom Reporting System über Dependency Injection bereitgestellt, nicht vom Modul selbst. Dadurch erreichen wir eine bessere Trennung der Zuständigkeiten und halten das S in SOLID ein: `Single responsibility`. Die Module sind jetzt nicht mehr für das Reporting selber verantwortlich, sondern müssen nur das Reportings System einbinden.
 
-Damit DI funktioniert muss für den DI Consumer (`also das Modul, welches das Reporting System einbinden möchte`) das Interface zur Kompilierzeit zur Verfügung stehen. Um das zu erreichen habe ich eine neue Klassenbibliothek erstellt: Sie heißt Interfaces wird per Gitea Actions automatisch in ein Nuget Paket gebaut und in der `Gitea Actions Nuget Registry` veröffentlicht. Dieses Nuget Paket wird dann in jedem notwendigen Modul als dependency hinzugefügt und damit kann man Modulübergreifend auf die Services und das IReporting Component zugreifen.
+Damit DI funktioniert muss für den DI Consumer (`also das Modul, welches das Reporting System einbinden möchte`) das Interface zur Kompilierzeit zur Verfügung stehen. Um das zu erreichen habe ich eine neue Klassenbibliothek erstellt: Sie heißt Interfaces wird per Gitea Actions automatisch in ein Nuget Paket gebaut und in der `Gitea Actions Nuget Registry` veröffentlicht. Dieses Nuget Paket wird dann in jedem notwendigen Modul als Dependency hinzugefügt und damit kann man Modulübergreifend auf die Services und das IReporting Component zugreifen.
 
 Die Implementierung des IReportingComponents stellt nur eine Property (`ReportType`, welche den TypeName der Razor Komponente zurückliefert, damit Dynamic Component sie laden kann) und eine Methode (`ConstructParameterList`, welche das Parameter Dictionary erstellt. Nur zwecks Typensicherheit eingefügt) bereit. Mit dem Dynamic Component von Razor ist es möglich, per C# Code unterschiedliche Komponenten zu rendern und damit auch die per DI injizierte Klasse.
 
@@ -423,7 +418,7 @@ Die Implementierung des IReportingComponents stellt nur eine Property (`ReportTy
 }
 ```
 
-Die Bereitstellund des Moduls geschieht im `AdminModules` Modul.
+Die Bereitstellung des Moduls geschieht im `AdminModules` Modul.
 
 ### 5.2 Event Registration
 
@@ -466,7 +461,7 @@ Um die Mitglieder regelmäßig über neue Inhalte zu informieren, wurde ein auto
 
 - Filterung: Der Job identifiziert alle Einträge, die seit dem letzten Versand erstellt wurden.
 - Zielgruppenselektion: Es werden alle Benutzer identifiziert, die der Rolle "Absolventen" angehören.
-- Zusammenstellung: Für jeden dieser Benutzer wird eine personalsierte Email-Notification generiert, welche eine Zusammenfassung der neuen Einträge enthält.
+- Zusammenstellung: Für jeden dieser Benutzer wird eine personalisierte Email-Notification generiert, welche eine Zusammenfassung der neuen Einträge enthält.
 - Versand: Die generierten Notifications werden in die Warteschlange der Notification-Infrastruktur eingereiht und sukzessive versendet.
   Integration des Reporting-Systems
 
@@ -476,7 +471,7 @@ Ein wichtiges Merkmal des Schwarzen Bretts zur Sicherstellung der Inhaltsqualit
 
 #### 5.3.4 Technischer Hintergrund
 
-Auf der Serverseite folgt das Modul dem etablierten Muster mit einem `BlackBoardRepository` für den effizienten Datenbankzugriff und einem `BlackBoardController` für die API-Bereitstellung. Die Implementierung des Scheduled Jobs als HostedServiceBase ermöglicht eine tiefe Integration in die Oqtane-Infrastruktur bei gleichzeitig geringem Ressourcenverbrauch. erbarkeit des Moduls gewährleistet.
+Auf der Serverseite folgt das Modul dem etablierten Muster mit einem `BlackBoardRepository` für den effizienten Datenbankzugriff und einem `BlackBoardController` für die API-Bereitstellung. Die Implementierung des Scheduled Jobs als HostedServiceBase ermöglicht eine tiefe Integration in die Oqtane-Infrastruktur bei gleichzeitig geringem Ressourcenverbrauch.
 
 ## 6 Learnings
 
@@ -519,7 +514,7 @@ Ein zentrales Problem in unserer ursprünglichen Arbeitsweise war die Kopplung v
 
 Lösungsansatz: Meetings und Besprechungen asynchron zueinander setzen.
 
-- Asynchrone Daily-Updates: Statusberichte erfolgen schriftlich (z. B. in Gitea Issues oder YouTrack), nicht mehr in stundenlangen Call-Marathons. Das nimmt den zeitlichen Druck vom einzelnen Entwickler. Oder zumindest in kurzen Commitnachrichten, welche am Ende des Tages automatisch an alle Teammitglieder zum überblick gesendet werden (eventuell mit @username tagging, um eine Person nochmal genau anzusprechen)
+- Asynchrone Daily-Updates: Statusberichte erfolgen schriftlich (z. B. in Gitea Issues oder YouTrack), nicht mehr in stundenlangen Call-Marathons. Das nimmt den zeitlichen Druck vom einzelnen Entwickler. Oder zumindest in kurzen Commitnachrichten, welche am Ende des Tages automatisch an alle Teammitglieder zum Überblick gesendet werden (eventuell mit @username tagging, um eine Person nochmal genau anzusprechen)
 - Review-First-Policy: Ein Feature gilt erst dann als „fertig“, wenn es einen asynchronen Code-Review-Prozess durchlaufen hat. Das Meeting dient nur noch der Klärung von Blockern, nicht der Präsentation von Code. Das war eigentlich schon von Anfang an in unserer `Definition of Done` festgelegt worden.
 - Entkoppelung von Meeting und Deadline: Meetings sollten der Synchronisation dienen, während die Abgabe von Arbeitspaketen kontinuierlich (Continuous Integration) erfolgen muss, um Lastspitzen (in der [Gitea Actions](#Continuous Integration) Pipeline) am Tag der Besprechung zu vermeiden.