Fix: Shorted Logo

00_preamble.tex

@@ -14,17 +14,17 @@
     \vspace{1cm}
     
     \begin{center}
-        \includegraphics[width=0.6\textwidth]{images/preamble/logo.png} \\
         \vspace{1.5cm}
-        
         \textbf{\Huge DIPLOMARBEIT} \\
         \vspace{1cm}
         \textbf{\huge AlumniHub} \\
+        \vspace{0.75cm}
+        \textit{\Large Plattform für den Absolventenverein des SZ HTL HAK Ungargasse} \\
         \vspace{0.5cm}
-        \textit{\Large Plattform für den Absolventenverein des SZ HTL HAK Ungargasse}
+        \includegraphics[width=0.25\textwidth]{images/preamble/logo-short.png} \\
     \end{center}
 
-    \vspace{1.75cm}
+    \vspace{2.5cm}
 
     \begin{minipage}[t]{0.5\textwidth}
         \textbf{Verfasser:} \\

02-Allgemein.md

@@ -198,7 +198,7 @@ Table: Aufgabenverteilung Adam Gaiswinkler
 ### Meilensteine
 
 | #   | Datum          | Beschreibung                                                                                                                                                                                                                                                                                                                              |
-| :-- | :------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| :-- | :------------- | --------------------------------------------------------- |
 | _1_ | _19.09.2025_ | Fertigstellung und Abgabe des Diplomarbeitsantrags.                                                                                                                                                                                                                                                                              |
 | _2_ | _30.10.2025_ | [cite_start]Server-Setup mit SSH-Zugriff [cite: 83][cite_start], CMS-Grundkonfiguration (Oqtane) im SZU-Design [cite: 69, 83][cite_start], Implementierung der Eingabemaske und API für das Anmeldetool [cite: 137] [cite_start]sowie Erstellung der DSGVO-Richtlinien [cite: 38] [cite_start]und Backupstrategie[cite: 55, 62]. |
 | _3_ | _27.11.2025_ | [cite_start]Entwicklung grafischer Auswertungen für Anmeldedaten [cite: 120] [cite_start]und Integration der OAuth-Authentifizierung zum automatisierten Abruf von Profildaten[cite: 78, 148].                                                                                                                                   |
@@ -293,14 +293,14 @@ Table: Projektumfelder und deren Bewertung
 ## Risikoanalyse
 
 | #   | Bezeichnung        | Beschreibung                                                                                                                      | Wahrscheinlichkeit (%) | Auswirkung (%) | Risikowert |
-| :-- | :----------------- | :-------------------------------------------------------------------------------------------------------------------------------- | :--------------------: | :------------: | :--------: |
+| :-- | :----------------- | :-------------------------------------------------------- | :-------: | :-------: | :-----: |
 | 1   | Infrastruktur      | [cite_start]Instabilität oder Fehlkonfiguration der Cloud-Server (Hetzner CX22), die den Live-Betrieb unterbrechen[cite: 45, 51]. |           60           |       90       |    5400    |
 | 2   | Datenverlust       | [cite_start]Kritischer Ausfall der Datenbank ohne erfolgreiche Wiederherstellung durch automatisierte Backups[cite: 51, 62].      |           15           |       95       |    1425    |
 | 3   | DSGVO-Verstoß      | [cite_start]Fehlende Konformität bei der Speicherung personenbezogener Daten oder beim Opt-In-Verfahren[cite: 38, 39, 128].       |           10           |      100       |    1000    |
 | 4   | Sicherheitslücke   | [cite_start]Unbefugter Zugriff auf das System durch Schwachstellen in der VPN- oder SSH-Verbindung[cite: 83].                     |           15           |       85       |    1275    |
 | 5   | API-Schnittstellen | [cite_start]Ausfall oder Inkompatibilität externer Dienste wie LinkedIn OAuth oder Brevo Mailservice[cite: 74, 78].               |           30           |       50       |    1500    |
 | 6   | Performance        | [cite_start]Beeinträchtigung der Systemleistung bei steigenden Zugriffszahlen in Phase 2[cite: 44, 46].                           |           40           |       40       |    1600    |
-| 7   | Wiederherstellung  | [cite_start]Überschreitung des geplanten Disaster-Recovery-Zeitraums von 24 Stunden[cite: 51, 66].                                |           25           |       70       |    1750    |
+| 7   | Wieder-herstellung  | [cite_start]Überschreitung des geplanten Disaster-Recovery-Zeitraums von 24 Stunden[cite: 51, 66].                                |           25           |       70       |    1750    |
 | 8   | Oqtane-Integration | [cite_start]Komplexität bei der Entwicklung und Einbindung benutzerdefinierter CMS-Module[cite: 69, 72].                          |           30           |       45       |    1350    |
 | 9   | Dokumentation      | [cite_start]Lückenhafte technische Dokumentation erschwert die Wartung durch den Absolventenverein[cite: 155].                    |           20           |       30       |    600     |
 

03-Diplomarbeitsbuch-individueller-teil-Adam-Gaiswinkler.md

@@ -2,9 +2,9 @@
 
 # Adam Gaiswinkler
 
-## 1. Einleitung des individuellen Teils
+## Einleitung des individuellen Teils
 
-### 1.1 Motivation
+### Motivation
 
 Zu Beginn des Projekts war meine persönliche Motivation überschaubar. Wie viele Schulprojekte startete auch AlumniHub zunächst als eine Pflichtaufgabe – ich war zwar von Anfang an dabei, jedoch ohne besonders großes Interesse am Thema. Das Projekt war zu Beginn eine von vielen schulischen Anforderungen, und ich sah es zunächst nicht als etwas, mit dem ich mich wirklich identifizieren würde. Die Aufgabenstellung klang zwar interessant, aber der persönliche Bezug fehlte noch.
 
@@ -14,69 +14,71 @@ Genau in diesem Moment begann mein Interesse zu wachsen. Je mehr Verantwortung i
 
 Die technische Herausforderung, eine moderne Webanwendung mit Blazor und ASP.NET umzusetzen, sowie die Möglichkeit, ein echtes System für eine reale Organisation zu entwickeln, wurden zur echten Motivation. Die Aufgabenstellung bot mir die Chance, theoretisches Wissen aus dem Unterricht in einem praxisnahen Umfeld anzuwenden und gleichzeitig einen konkreten Mehrwert für den Absolventenverein zu schaffen. Rückblickend war die Teamverkleinerung – obwohl sie damals als Problem wahrgenommen wurde – einer der wichtigsten Faktoren für meine persönliche Entwicklung im Rahmen dieses Projekts.
 
-### 1.2 Individuelle Themenstellung
+### Individuelle Themenstellung
 
 Entwicklung des Anmeldetools und Hall-of-Fame-Moduls für Oqtane, Integration in das bestehende CMS-System, Responsive UI-Entwicklung mit Blazor und ASP.NET Core
 
-### 1.3 Teamrolle
+### Teamrolle
 
 Developer, Tester der eigenen Module
 
-### 1.4 Untersuchungsanliegen
+### Untersuchungsanliegen
 
 Modulentwicklung mit Blazor und ASP.NET Core, Integration eigenständiger Module in die Oqtane-Architektur, Entwicklung reaktiver Benutzeroberflächen mit Blazor-Komponenten, Responsive UI-Design mit Bootstrap und eigenem CSS, PDF-Generierung mit QuestPDF, Fehlerbehebung und Optimierung der mobilen Darstellung
 
-### 1.5 Persönlicher Aufgabenbereich
+### Persönlicher Aufgabenbereich
 
 Der persönliche Aufgabenbereich umfasste die Entwicklung der beiden zentralen CMS-Module der Plattform: das Anmeldetool für Veranstaltungen sowie das Hall-of-Fame-Modul. Beide Module wurden als eigenständige, wiederverwendbare Oqtane-Module konzipiert und vollständig in C# und Blazor implementiert. Neben der technischen Umsetzung lag ein besonderer Fokus auf der Benutzerfreundlichkeit, der responsiven Darstellung und der nahtlosen Integration in das bestehende CMS-System.
 
-### 1.6 Abgrenzung der Arbeit
+###  Abgrenzung der Arbeit
 
 Das Datenbankdesign sowie die Infrastruktur und das Server-Setup waren nicht Teil meines persönlichen Aufgabenbereichs und wurden von anderen Teammitgliedern verantwortet. Mein persönlicher Anteil beschränkt sich auf die Entwicklung der Anwendungsschicht, konkret auf die Implementierung der beiden CMS-Module – das Anmeldetool und das Hall-of-Fame-Modul – sowie deren Integration in das bestehende System.
 
-## 2. Technologien
+## Technologien
 
 In diesem Kapitel werden die Technologien und Werkzeuge vorgestellt, die für die Entwicklung des Anmeldetools, des Hall-of-Fame-Moduls und des Oqtane-Themes eingesetzt wurden. Die Beschreibungen sind dabei so gestaltet, dass sie auch für Leserinnen und Leser ohne technischen Hintergrund verständlich sind.
 
-### 2.1 C# und ASP.NET Core
+### C# und ASP.NET Core
 
 C# ist eine moderne Programmiersprache von Microsoft, die besonders für die Entwicklung von Webanwendungen und Softwaresystemen geeignet ist. Sie ist klar strukturiert, gut lesbar und weit verbreitet in der professionellen Softwareentwicklung. ASP.NET Core ist ein Framework – also eine Art Werkzeugkasten – das auf C# aufbaut und die Entwicklung von Webseiten und Webanwendungen vereinfacht [@aspnet_core_docs]. Es stellt vorgefertigte Bausteine bereit, sodass man nicht alles von Grund auf neu programmieren muss. Für AlumniHub bildete ASP.NET Core die technische Grundlage aller entwickelten Module.
 
-### 2.2 Blazor
+### Blazor
 
 Blazor ist ein Framework, das es ermöglicht, interaktive Weboberflächen direkt in C# zu entwickeln [@blazor_docs]. Normalerweise werden solche Oberflächen – also alles, was der Benutzer auf dem Bildschirm sieht und mit dem er interagiert – mit einer anderen Programmiersprache namens JavaScript umgesetzt. Blazor erlaubt es, dasselbe in C# zu schreiben, was die Entwicklung vereinheitlicht und übersichtlicher macht. Konkret bedeutet das: Wenn ein Benutzer beispielsweise auf den „Zusagen"-Button klickt, reagiert die Seite sofort und aktualisiert sich automatisch – ohne dass die gesamte Seite neu geladen werden muss.
 
-### 2.3 Oqtane
+### Oqtane
 
 Oqtane ist ein Content-Management-System (CMS) – also eine Software, mit der Webseiten und deren Inhalte verwaltet werden können, ähnlich wie WordPress oder Typo3 [@oqtane_framework_site]. Das Besondere an Oqtane ist, dass es vollständig auf Blazor und C# aufbaut und eine modulare Architektur besitzt: Man kann eigene Erweiterungen – sogenannte Module – entwickeln und in das System einbinden, ohne den Kern der Software verändern zu müssen [@oqtane_docs_dev]. Für AlumniHub wurde Oqtane als Grundlage gewählt, weil es Benutzerverwaltung, Seitenstruktur und viele weitere Standardfunktionen bereits mitbringt und somit viel Entwicklungsaufwand spart.
 
-### 2.4 Bootstrap und CSS
+### Bootstrap und CSS
 
 CSS (Cascading Style Sheets) ist die Sprache, mit der das Aussehen einer Webseite festgelegt wird – also Farben, Schriftarten, Abstände und das Layout. Bootstrap ist eine fertige Sammlung von CSS-Regeln und Hilfsmitteln, die von Twitter entwickelt wurde und kostenlos verfügbar ist [@bootstrap]. Der große Vorteil von Bootstrap ist, dass es sogenanntes Responsive Design einfach umsetzbar macht: Die Webseite passt sich automatisch an verschiedene Bildschirmgrößen an – egal ob Desktop, Tablet oder Smartphone. Für AlumniHub wurde Bootstrap als Basis verwendet, ergänzt durch eigenes CSS für das individuelle Erscheinungsbild der Plattform.
 
-### 2.5 QuestPDF
+### QuestPDF
 
 QuestPDF ist eine kostenlose Open-Source-Bibliothek – also eine fertige Programmsammlung – die es ermöglicht, PDF-Dokumente direkt aus C#-Code heraus zu erstellen [@questpdf]. Anstatt ein PDF manuell zu gestalten, beschreibt man im Code wie das Dokument aussehen soll, und QuestPDF generiert daraus automatisch eine fertige PDF-Datei. Im Hall-of-Fame-Modul wurde QuestPDF eingesetzt, um jedem Absolventen zu ermöglichen, sein eigenes Profil als visuell ansprechendes PDF herunterzuladen.
 
-### 2.6 Gitea
+### Gitea
 
 Wenn mehrere Personen gemeinsam an einem Softwareprojekt arbeiten, braucht man ein System, das alle Änderungen am Code nachverfolgt und verhindert, dass sich Änderungen verschiedener Personen gegenseitig überschreiben. Dieses Konzept nennt sich Versionskontrolle. Gitea ist eine selbst gehostete Plattform für genau diesen Zweck – ähnlich wie GitHub, aber auf einem eigenen Server betrieben [@gitea_about]. Jede Änderung am Code wird als sogenannter „Commit" gespeichert, sodass man jederzeit nachvollziehen kann, wer wann was geändert hat, und bei Bedarf auf eine ältere Version zurückwechseln kann.
 
-### 2.7 Entwicklungsumgebung
+### Entwicklungsumgebung
 
 Eine Entwicklungsumgebung – auch IDE (Integrated Development Environment) genannt – ist ein Programm, das Entwicklerinnen und Entwickler beim Schreiben von Code unterstützt. Sie bietet unter anderem Funktionen wie automatische Vervollständigung, Fehlererkennung und integrierte Debugging-Werkzeuge, die das Auffinden und Beheben von Fehlern im Code erleichtern.
 
 Zu Beginn des Projekts wurde Visual Studio 2022 auf Windows verwendet. Visual Studio 2022 ist die führende Entwicklungsumgebung von Microsoft für .NET-Projekte und bietet eine umfangreiche Unterstützung für ASP.NET Core und Blazor. Im Laufe des Projekts erfolgte jedoch ein Wechsel von Windows auf macOS. Da Visual Studio 2022 auf Mac nicht mehr verfügbar ist – Microsoft hat die Mac-Version eingestellt – wurde als Ersatz JetBrains Rider eingesetzt [@jetbrains_rider]. JetBrains Rider ist eine next-generation IDE von JetBrains, die plattformübergreifend funktioniert und eine moderne Entwicklungsumgebung für .NET-Projekte auf macOS bietet. Der Umstieg auf JetBrains Rider ermöglichte es, die Entwicklung auf dem neuen System ohne größere Unterbrechungen fortzusetzen.
 
-### 2.8 Plattformwechsel: Windows zu macOS
+### Plattformwechsel: Windows zu macOS
 
 Ein besonderer Aspekt der Entwicklung war der Wechsel von Windows auf macOS während des Projektverlaufs. Unter Plattform versteht man in der Softwareentwicklung das Betriebssystem, auf dem eine Anwendung läuft – also etwa Windows, macOS oder Linux. Dieser Wechsel brachte spezifische Herausforderungen mit sich, da Oqtane primär für Windows entwickelt wurde. Obwohl Oqtane grundsätzlich auch auf macOS und Linux lauffähig ist, ist die Unterstützung für diese Plattformen veraltet und nicht vollständig angepasst. In der Praxis bedeutete das: Der Code ließ sich teilweise nicht fehlerfrei kompilieren – also in ein lauffähiges Programm umwandeln – und Oqtane startete zunächst nur mit Fehlermeldungen. Durch den Einsatz von JetBrains Rider als IDE konnten diese Probleme weitgehend gelöst werden, da JetBrains Rider eine bessere plattformübergreifende Integration bietet als die ursprünglich verwendete Entwicklungsumgebung.
 
-## 3. Module
+## Module
 
-### 3.1 Entwicklung des Oqtane Themes
+### Entwicklung des Oqtane Themes
 
-#### 3.1.1 Ziel des Themes
+#### Ziel des Themes
+
+\ 
 
 Im Rahmen des Projekts AlumniHub wurde ein eigenes Theme für das Content-Management-System Oqtane entwickelt. Ziel dieser Entwicklung war es, das Standarddesign von Oqtane vollständig durch eine projektspezifische Benutzeroberfläche zu ersetzen, die den Anforderungen des Absolventenvereins der HTL Ungargasse entspricht. Das Standardtheme von Oqtane ist funktional, jedoch generisch gehalten und bietet keinen Bezug zur Schule oder zum Projekt. Aus diesem Grund wurde frühzeitig die Entscheidung getroffen, ein vollständig eigenes Theme zu entwickeln, das sowohl optisch als auch technisch auf die Bedürfnisse der Plattform zugeschnitten ist.
 
@@ -84,11 +86,15 @@ Das visuelle Design orientiert sich dabei am bestehenden Erscheinungsbild der of
 
 Neben der visuellen Gestaltung standen auch technische Anforderungen im Mittelpunkt. Das Theme sollte auf unterschiedlichen Endgeräten – sowohl auf Desktop-Computern als auch auf Smartphones und Tablets – zuverlässig und benutzerfreundlich funktionieren. Responsive Design war daher von Anfang an eine zentrale Anforderung. Darüber hinaus sollte das Theme vollständig in die Oqtane-Architektur integriert sein, sodass alle Standardfunktionen des CMS wie Benutzerverwaltung, Seitenverwaltung und Modulintegration weiterhin ohne Einschränkungen genutzt werden können.
 
-#### 3.1.2 Technische Umsetzung
+#### Technische Umsetzung
+
+\ 
 
 Als technische Grundlage diente die Theme-Architektur von Oqtane. Das Layout wurde in einer zentralen Razor-Datei (`Theme.razor`) definiert, welche von der Basisklasse `ThemeBase` erbt. Durch diese Vererbung stehen im Theme automatisch zentrale Funktionen des Frameworks zur Verfügung, darunter der Seitenzustand (`PageState`), Navigationsdaten, Systemeinstellungen sowie Informationen über den aktuell angemeldeten Benutzer. Dies ermöglicht eine tiefe Integration des Themes in das CMS, ohne dass zusätzliche Schnittstellen oder externe Datenzugriffe notwendig sind.
 
-##### 3.1.2.1 Navigationsleiste
+##### Navigationsleiste
+
+\ 
 
 Ein zentrales Element des Themes ist die fixierte Navigationsleiste am oberen Rand der Seite. Sie ist in drei klar voneinander getrennte Bereiche gegliedert: Auf der linken Seite befindet sich das Logo der HTL Ungargasse, das als visuelles Erkennungsmerkmal der Schule dient und beim Klick zur Startseite führt. In der Mitte werden die Navigationspunkte der Plattform angezeigt, die dynamisch aus der Seitenstruktur des CMS generiert werden. Auf der rechten Seite befinden sich die Benutzerfunktionen, also Login, Registrierung und bei angemeldeten Benutzern ein Link zum eigenen Profil.
 
@@ -116,7 +122,9 @@ Durch diesen Ansatz werden ausschließlich die für Benutzer relevanten Inhaltss
 ![Abbildung 4.2: Filterlogik der Oqtane-Navigation] (./images/06-Adam/navigationsfilter_v2.svg)
 *Abbildung 4.2: Filterlogik zur Bereinigung der Oqtane-Navigation (Theme.razor)* Dies reduziert den Wartungsaufwand erheblich und stellt sicher, dass die Navigation stets dem aktuellen Stand der Plattform entspricht.
 
-##### 3.1.2.2 Responsive Design und Burger-Menü
+##### Responsive Design und Burger-Menü
+
+\ 
 
 Da die Plattform auch auf mobilen Endgeräten genutzt werden soll, war die Umsetzung eines responsiven Layouts eine wichtige Anforderung. Auf Desktop-Geräten werden alle Navigationspunkte direkt in der Navigationsleiste angezeigt. Auf kleineren Bildschirmen wie Smartphones oder Tablets würde dies jedoch zu Platzproblemen führen, da die Anzahl der Navigationspunkte die verfügbare Breite überschreiten kann.
 
@@ -124,49 +132,65 @@ Aus diesem Grund wurde für mobile Endgeräte ein sogenanntes Burger-Menü imple
 
 Die technische Umsetzung des Burger-Menüs basiert auf einer CSS-Checkbox-Lösung. Das Öffnen und Schließen der Sidebar wird über den Zustand einer versteckten Checkbox gesteuert, der mittels CSS-Selektoren ausgewertet wird. Dieser Ansatz ermöglicht eine funktionsfähige mobile Navigation ohne den Einsatz zusätzlicher JavaScript-Frameworks oder komplexer Logik. Die gesamte Darstellungslogik – also welche Elemente auf welcher Bildschirmgröße sichtbar sind – wird über CSS Media Queries gesteuert, die zwischen der Desktop- und der mobilen Ansicht unterscheiden.
 
-##### 3.1.2.3 Pane-Struktur
+##### Pane-Struktur
+
+\ 
 
 Für den Inhaltsbereich der Plattform wurden mehrere sogenannte Panes definiert. Panes sind in Oqtane Platzhalter-Bereiche innerhalb eines Themes, in die später Module oder Inhalte eingefügt werden können. Durch die Definition mehrerer Panes mit unterschiedlichen Breiten und Positionen können Seiten sehr flexibel und ohne Änderungen am Theme-Code strukturiert werden.
 
 Im entwickelten Theme stehen unter anderem folgende Panes zur Verfügung: ein vollbreiter Bereich oben (`Top 100%`), ein linker Bereich (`Left 50%`), eine rechte Seitenleiste (`Right Sidebar 33%`) sowie ein vollbreiter Bereich am unteren Rand (`Bottom 100%`). Diese Struktur ermöglicht es, Seiten sowohl ein- als auch mehrspaltig aufzubauen, je nach den Anforderungen des jeweiligen Inhalts.
 
-##### 3.1.2.4 Weitere Integrationen
+##### Weitere Integrationen
+
+\ 
 
 Neben Navigation und Layout wurden weitere Funktionen in das Theme integriert. Die Cookie-Consent-Komponente von Oqtane wurde eingebunden, sodass beim ersten Besuch der Plattform ein Hinweis zur Verwendung von Cookies angezeigt wird. Diese Funktion ist über die Site-Einstellungen von Oqtane steuerbar, das Theme rendert lediglich die entsprechende Komponente.
 
 Darüber hinaus wurde das ControlPanel von Oqtane integriert, das Administratorinnen und Administratoren direkten Zugriff auf Verwaltungsfunktionen bietet. Login- und Registrierungsoptionen werden über den `SettingService` aus den Site-Einstellungen geladen, sodass diese Funktionen ohne Anpassungen am Code aktiviert oder deaktiviert werden können.
 
-#### 3.1.3 Herausforderungen
+#### Herausforderungen
+
+\ 
 
 Die eigene Implementierung der Navigation über `PageState.Pages` und eine LINQ-basierte Filterlogik erwies sich als die richtige Entscheidung. Sie löste nicht nur das Problem der fehlenden Anpassbarkeit der Standardkomponente, sondern brachte gleichzeitig einen wesentlichen Mehrwert: Die Navigation ist vollständig wartungsfrei. Werden im CMS neue Seiten angelegt, erscheinen diese automatisch im Menü – ohne dass eine einzige Zeile Code angepasst werden muss. Zudem ermöglichte dieser Ansatz die vollständige Kontrolle über das Erscheinungsbild des Burger-Menüs, was mit der Standardkomponente nicht möglich gewesen wäre.
 
-### 3.2 Anmeldetool
+### Anmeldetool
 
-#### 3.2.1 Ziel des Moduls
+#### Ziel des Moduls
+
+\ 
 
 Das Anmeldetool wurde entwickelt, um Mitgliedern des Absolventenvereins eine einfache und strukturierte Möglichkeit zu bieten, sich zu Veranstaltungen und Treffen an- oder abzumelden. Ziel des Moduls ist es, den organisatorischen Aufwand bei der Planung und Verwaltung von Treffen deutlich zu reduzieren und gleichzeitig eine benutzerfreundliche Oberfläche für alle Beteiligten bereitzustellen.
 
 Das Modul wurde als zusätzliche Funktionserweiterung in das bestehende Content-Management-System integriert. Es ermöglicht sowohl die Verwaltung der Veranstaltungen auf Seiten der Organisatoren als auch eine intuitive Interaktion für die Teilnehmerinnen und Teilnehmer. Durch den Einsatz moderner Webtechnologien konnte dabei eine reaktionsschnelle und geräteübergreifend nutzbare Lösung geschaffen werden.
 
-#### 3.2.2 Frontend (Eingabemaske)
+#### Frontend (Eingabemaske)
+
+\ 
 
 Die Benutzeroberfläche des Anmeldetools wurde mithilfe von Blazor realisiert, einem Framework der ASP.NET-Technologieplattform, das die Entwicklung interaktiver Weboberflächen in C# ermöglicht. Die Eingabemaske wurde als eigenständige Blazor-Komponente implementiert, die flexibel in verschiedene Seiten der Anwendung eingebettet werden kann.
 
 Beim Aufruf der Seite wird dem Benutzer zunächst eine kurze Beschreibung der jeweiligen Veranstaltung angezeigt. Im Anschluss stehen zwei klar gekennzeichnete Schaltflächen zur Verfügung: Zusagen zur Bestätigung der Teilnahme sowie Absagen zur Ablehnung. Die Schaltflächen wurden farblich differenziert gestaltet – eine grüne Hervorhebung signalisiert die Zusage, eine rote Darstellung steht für die Absage. Diese Gestaltung orientiert sich an etablierten Designkonventionen moderner Webanwendungen und verbessert die intuitive Bedienbarkeit erheblich. Darüber hinaus wurde besonderer Wert auf eine responsive Darstellung gelegt, damit das Tool sowohl auf Desktop-Geräten als auch auf Smartphones und Tablets problemlos genutzt werden kann.
 
-#### 3.2.3 API-Schnittstelle
+#### API-Schnittstelle
+
+\ 
 
 Die Anbindung des Anmeldetools an das bestehende CMS erfolgt über klar definierte Schnittstellen innerhalb der ASP.NET-Architektur. Die Komponente kommuniziert mit dem Backend, um Veranstaltungsdaten abzurufen sowie Anmelde- und Absagestatus der Teilnehmenden zu übermitteln und zu persistieren.
 
 Die Datenübertragung erfolgt nach dem Prinzip der sauberen Komponentenarchitektur: Die Blazor-Komponente ist als eigenständige Einheit konzipiert, die über Parameter und Rückruffunktionen mit übergeordneten Seitenkomponenten kommuniziert. Diese Struktur gewährleistet eine klare Trennung zwischen Darstellungslogik und Datenzugriff und erleichtert zukünftige Erweiterungen der Schnittstelle erheblich.
 
-#### 3.2.4 Datenauswertung
+#### Datenauswertung
+
+\ 
 
 Die im Anmeldetool erfassten Daten bilden die Grundlage für die Verwaltung und Auswertung von Veranstaltungsteilnahmen. Organisatoren können auf Basis der gespeicherten An- und Abmeldungen die Teilnehmerzahlen einsehen und die Planung entsprechend anpassen.
 
 Die Architektur des Moduls ist bereits auf zukünftige Erweiterungen ausgelegt. Geplante Erweiterungen umfassen eine übersichtliche Teilnehmerliste mit Namen und Anmeldestatus, die Möglichkeit, eine maximale Teilnehmeranzahl je Veranstaltung festzulegen sowie eine direkte Speicherung und Auswertung der Anmeldedaten in einer Datenbank. Durch diese Erweiterungen soll das Anmeldetool künftig nicht nur als Interaktionselement für Teilnehmer, sondern auch als vollwertiges Verwaltungswerkzeug für Veranstaltungsorganisatoren dienen.
 
-#### 3.2.5 UX-Überlegungen (User Experience)
+#### UX-Überlegungen (User Experience)
+
+\ 
 
 Ein zentraler Aspekt bei der Entwicklung des Anmeldetools war die Benutzerfreundlichkeit der Oberfläche. UX (User Experience) bezeichnet dabei die Gesamtheit aller Erfahrungen, die ein Benutzer bei der Interaktion mit einer Anwendung macht – von der visuellen Gestaltung über die Bedienbarkeit bis hin zur allgemeinen Zufriedenheit mit dem System. Die Module wurden so gestaltet, dass Benutzerinnen und Benutzer die Funktionen ohne zusätzliche Schulung verwenden können. Eine klare Struktur, eine intuitive Bedienung sowie ein konsistentes Erscheinungsbild innerhalb des bestehenden Systems standen dabei im Vordergrund.
 
@@ -174,15 +198,19 @@ Während der Testphase wurden mehrere visuelle Darstellungsprobleme identifizier
 
 Diese Maßnahmen stellen einen ersten Schritt in der kontinuierlichen Verbesserung der mobilen Benutzeroberfläche dar. Weitere Feinabstimmungen sind geplant, um das Anmeldetool langfristig als stabile, benutzerfreundliche und geräteübergreifend konsistente Lösung zu etablieren.
 
-### 3.3 Hall of Fame
+### Hall of Fame
 
 Das Hall-of-Fame-Modul ist ein zentrales Modul der AlumniHub-Plattform. Es dient dazu, ehemalige Absolventinnen und Absolventen der HTL Ungargasse sichtbar zu machen und ihre beruflichen Werdegänge zu präsentieren. Das Modul wurde als eigenständiges, wiederverwendbares Oqtane-Modul entwickelt und ermöglicht es registrierten Benutzerinnen und Benutzern, sich selbst mit einem persönlichen Profil einzutragen.
 
-#### 3.3.1 Benutzeroberfläche
+#### Benutzeroberfläche
+
+\ 
 
 Die Benutzeroberfläche des Moduls besteht aus mehreren Komponenten, die zusammen eine vollständige und benutzerfreundliche Verwaltung der Hall-of-Fame-Einträge ermöglichen.
 
-##### 3.3.1.1 Übersichtsseite (Index.razor)
+##### Übersichtsseite (Index.razor)
+
+\ 
 
 Die Hauptseite der Hall of Fame ist die erste Seite, die Besucherinnen und Besucher zu sehen bekommen. Sie zeigt alle veröffentlichten Einträge in einem responsiven Kartenlayout. Auf Desktop-Geräten werden die Karten in drei Spalten nebeneinander dargestellt, auf kleineren Bildschirmen passt sich das Layout automatisch an und zeigt die Karten einspaltig untereinander an.
 
@@ -192,7 +220,9 @@ Jede Karte enthält das Foto der jeweiligen Person als großes Vorschaubild im o
 
 Für angemeldete Benutzerinnen und Benutzer wird im oberen rechten Bereich der Seite ein zusätzlicher Button angezeigt. Hat die Person noch keinen eigenen Eintrag erstellt, erscheint ein „Eintragen"-Button. Existiert bereits ein Eintrag, ändert sich der Button automatisch zu „Mein Eintrag", über den der bestehende Eintrag bearbeitet werden kann. Administratorinnen und Administratoren sehen zusätzlich Warnhinweise bei gemeldeten Einträgen sowie einen Lösch-Button bei jedem Eintrag.
 
-##### 3.3.1.2 Detailseite (Details.razor)
+##### Detailseite (Details.razor)
+
+\ 
 
 Die Detailseite zeigt einen einzelnen Hall-of-Fame-Eintrag in seiner vollständigen Form. Das Layout ist zweispaltig aufgebaut: Auf der linken Seite befindet sich das Foto der Person, eingebettet in einen unscharfen Bildhintergrund, der dasselbe Foto in einer größeren, weichgezeichneten Version als Hintergrund verwendet. Dieser Effekt verleiht der Seite eine moderne und ansprechende Optik. Das eigentliche Foto ist dabei als klar umrandetes Porträtbild in der Mitte des linken Bereichs positioniert.
 
@@ -200,7 +230,9 @@ Auf der rechten Seite werden zunächst eine Breadcrumb-Navigation („Hall of Fa
 
 Am unteren Rand der Seite befinden sich je nach Konfiguration des Eintrags bis zu vier Buttons. Der „PDF Vorschau"-Button öffnet einen modalen Dialog mit einer vollständigen Vorschau des generierten PDFs sowie einem „Herunterladen"-Button. Der „Zurück"-Button führt zurück zur Übersichtsseite. Falls die Person einen optionalen Link hinterlegt hat, wird zusätzlich ein „Webseite besuchen"-Button angezeigt, der die Besucherin oder den Besucher direkt zur externen Webseite der Person führt. Für eingeloggte Benutzer gibt es außerdem einen „Melden"-Button, über den ein Eintrag gemeldet werden kann.
 
-##### 3.3.1.3 Edit-Seite (Edit.razor)
+##### Edit-Seite (Edit.razor)
+
+\ 
 
 Die Edit-Komponente dient sowohl zum Erstellen eines neuen Eintrags als auch zum Bearbeiten eines bestehenden. Das Formular ist klar strukturiert und enthält alle notwendigen Felder für einen vollständigen Hall-of-Fame-Eintrag.
 
@@ -215,7 +247,9 @@ Der folgende Lebenszyklus zeigt die möglichen Zustände eines Eintrags und die
 ![Abbildung 4.1: Lebenszyklus eines Hall-of-Fame-Eintrags] (./images/06-Adam/hall_of_fame_lebenszyklus_v4.svg)
 *Abbildung 4.1: Lebenszyklus eines Hall-of-Fame-Eintrags*
 
-##### 3.3.1.4 Meldefunktion
+##### Meldefunktion
+
+\ 
 
 Die Meldefunktion ermöglicht es angemeldeten Benutzerinnen und Benutzern, einen Hall-of-Fame-Eintrag zu melden, wenn dieser unangemessene oder falsche Inhalte enthält. Durch Klicken auf den „Melden"-Button auf der Detailseite öffnet sich ein kleines Popup-Fenster, in das der Meldegrund eingetragen werden kann. Nach dem Absenden wird die Meldung in der Datenbank gespeichert und im Admin-Modul angezeigt. Administratorinnen und Administratoren können dort alle eingegangenen Meldungen einsehen und bei Bedarf den betreffenden Eintrag löschen oder freigeben.
 
@@ -224,7 +258,9 @@ Die Meldefunktion ist dabei nicht direkt im Hall-of-Fame-Modul implementiert, so
 ![Abbildung 6.1: Ablauf des globalen Reporting-Systems] (./images/06-Adam/reporting_sequence_diagram.svg)
 *Abbildung 6.1: Ablauf des globalen Reporting-Systems (Sequenzdiagramm)*
 
-##### 3.3.1.5 PDF-Export
+##### PDF-Export
+
+\ 
 
 Der PDF-Export ist eine besondere Funktion des Hall-of-Fame-Moduls. Er ermöglicht es Benutzerinnen und Benutzern, ihren Eintrag als visuell ansprechendes PDF-Dokument herunterzuladen. Die PDF-Generierung wird über die Open-Source-Bibliothek QuestPDF in der Community-Edition realisiert.
 
@@ -232,7 +268,9 @@ Das generierte PDF folgt einem Glasmorphismus-Design und ist im Format DIN A4 ge
 
 Die PDF-Vorschau kann direkt auf der Detailseite über den „PDF Vorschau"-Button geöffnet werden. Es öffnet sich ein modaler Dialog, der das generierte PDF in einer Vorschau anzeigt. Über einen „Herunterladen"-Button kann das PDF direkt auf das Gerät gespeichert werden.
 
-#### 3.3.2 Datenmodell
+#### Datenmodell
+
+\ 
 
 Das Modul verwendet zwei Entitäten, die in der Datenbank als Tabellen abgebildet werden.
 
@@ -280,7 +318,9 @@ Table: Entität HallOfFameReport
 
 Der Fremdschlüssel zu `SZUAbsolventenvereinHallOfFame` ist mit kaskadierendem Löschen konfiguriert, sodass beim Löschen eines Eintrags automatisch alle zugehörigen Meldungen entfernt werden. Zwischen den beiden Entitäten besteht eine 1:n-Beziehung: Ein Eintrag kann beliebig viele Meldungen besitzen.
 
-#### 3.3.3 Datenbankmigrationen
+#### Datenbankmigrationen
+
+\ 
 
 Die Datenbankstruktur wird über Entity Framework Core Migrationen versioniert verwaltet [@ef_core_migrations].
 
@@ -294,7 +334,9 @@ Table: Datenbankmigrationen im Hall-of-Fame-Modul
 
 > **Hinweis:** Version `01.00.00.01` wurde im Entwicklungsprozess übersprungen, da eine fehlerhafte Migration erstellt und anschließend wieder gelöscht werden musste.
 
-#### 3.3.4 Implementierungsdetails und Problemlösungen
+#### Implementierungsdetails und Problemlösungen
+
+\ 
 
 Während der Entwicklung traten mehrere technische Herausforderungen auf, die im Folgenden zusammen mit ihren Lösungen beschrieben werden.
 
@@ -314,11 +356,13 @@ Karten hatten ursprünglich unterschiedliche Höhen durch variierende Beschreibu
 
 Die ursprünglich fest codierten Sortierrichtungen wurden durch einen Toggle-Button neben dem Sortier-Dropdown ersetzt, der mit einem dynamischen Pfeil-Icon zwischen aufsteigender und absteigender Sortierung umschaltet. Die Sortierlogik ist in einer berechneten Eigenschaft gekapselt, die Suche und Sortierung kombiniert.
 
-## 4. Übergangslösung & Probleme
+## Übergangslösung & Probleme
 
-### 4.1 Übergangslösung (Sommer 2025)
+### Übergangslösung (Sommer 2025)
 
-#### 4.1.1 Gründe & Technische Umsetzung
+#### Gründe & Technische Umsetzung
+
+\ 
 
 Da AlumniHub zum Zeitpunkt des ersten Absolvententreffens im Sommer 2025 noch nicht vollständig fertiggestellt war und das Hosting von Oqtane auf dem Hetzner-Server zu unerwarteten technischen Problemen geführt hatte, wurde im Team die Entscheidung getroffen, eine eigenständige Übergangslösung zu entwickeln. Diese sollte pünktlich zur Veranstaltung einsatzbereit sein und die wichtigsten Funktionen abdecken: die Möglichkeit für Absolventinnen und Absolventen, ihre Teilnahme am Treffen zu bestätigen oder abzusagen, sowie die Möglichkeit, direktes Feedback zum Diplomprojekt AlumniHub abzugeben.
 
@@ -330,7 +374,9 @@ Für die Verarbeitung von Zu- und Absagen zum Absolvententreffen wurden zusätzl
 
 Das Backend der Lösung, das für die Verarbeitung der Formulardaten und den Versand von Bestätigungs-E-Mails zuständig war, wurde von einem Teammitglied entwickelt und war nicht Teil des eigenen Aufgabenbereichs. Es wurde mit Node.js und dem Framework Express umgesetzt und auf einem virtuellen Server bei Hetzner Cloud gehostet.
 
-#### 4.1.2 Differenzen zur finalen Lösung
+#### Differenzen zur finalen Lösung
+
+\ 
 
 Im direkten Vergleich zur finalen AlumniHub-Plattform unterscheidet sich die Übergangslösung in mehreren wesentlichen Punkten. Während AlumniHub auf dem vollständigen CMS Oqtane basiert und eine umfangreiche Funktionspalette bietet – darunter Benutzerverwaltung, Hall of Fame, Anmeldetool, Datenauswertung und ein individuelles Theme – beschränkte sich die Übergangslösung bewusst auf das absolut Notwendige.
 
@@ -338,9 +384,11 @@ Es gab keine Benutzerkonten und keine Authentifizierung. Jede Person, die die Se
 
 Diese bewusste Reduktion auf das Wesentliche war jedoch kein Nachteil, sondern eine pragmatische Entscheidung: Die Lösung musste schnell funktionieren und zuverlässig sein – und das war sie. Nach dem Absolvententreffen wurde die Seite nicht einfach abgeschaltet, sondern zu einer reinen Feedback-Seite für das Diplomprojekt umfunktioniert. Über diese Seite konnten Interessierte – darunter Lehrkräfte, Mitschülerinnen und Mitschüler sowie externe Besucher der Präsentation – weiterhin direktes Feedback zum Projekt abgeben. Die Seite blieb so lange in Betrieb, bis die vollständig entwickelte AlumniHub-Plattform diese Funktion nativ übernahm.
 
-### 4.2 Probleme
+### Probleme
 
-#### 4.2.1 Technische Probleme
+#### Technische Probleme
+
+\ 
 
 Eine der größten technischen Herausforderungen im gesamten Projektverlauf war der Zeitdruck, der insbesondere im Vorfeld des ersten Absolvententreffens spürbar war. Da AlumniHub zu diesem Zeitpunkt noch nicht einsatzbereit war, musste die Übergangslösung in sehr kurzer Zeit konzipiert, entwickelt und in Betrieb genommen werden. Dieser Zeitdruck führte dazu, dass keine ausreichende Zeit für gründliches Testen oder für die Umsetzung zusätzlicher Funktionen blieb.
 
@@ -350,7 +398,9 @@ Ein weiteres technisches Problem betraf das Hosting von Oqtane auf dem Hetzner-S
 
 In den letzten Monaten des Projekts wurde daher ein Wechsel des Hosting-Anbieters vorgenommen. Statt Hetzner wird die Plattform nun bei LiveDesign gehostet, einem österreichischen Unternehmen, das sich auf Hosting, Webdesign und individuelle Webservices spezialisiert hat [@livedesign]. LiveDesign betreibt seine Datacenter ausschließlich in Österreich und bietet eine zuverlässige Infrastruktur für CMS-Systeme wie Oqtane. Durch diesen Wechsel konnten die bestehenden Stabilitätsprobleme behoben und der Betrieb der Plattform deutlich verbessert werden.
 
-#### 4.2.2 Kontakt mit Oqtane- und Hetzner-Support
+#### Kontakt mit Oqtane- und Hetzner-Support
+
+\ 
 
 Im Verlauf des Projekts wurde sowohl der Support von Oqtane als auch der Support von Hetzner kontaktiert, um Hilfe bei den aufgetretenen technischen Problemen zu erhalten.
 
@@ -358,15 +408,17 @@ Der Kontakt mit dem Oqtane-Support erfolgte über GitHub Issues sowie per E-Mail
 
 Auch der Hetzner-Support wurde bezüglich der Serverprobleme kontaktiert. Die Anfragen bezogen sich auf die Serverkonfiguration und mögliche Ursachen für die Instabilität beim Betrieb von Oqtane. Auch hier führten die Rückmeldungen nicht zu einer vollständigen Lösung des Problems. Die Erfahrung zeigte, dass bei der Nutzung spezialisierter Frameworks auf externen Hosting-Plattformen mit eingeschränktem Support gerechnet werden muss und eine intensive Eigenrecherche oft unumgänglich ist.
 
-#### 4.2.3 Organisatorische Probleme
+#### Organisatorische Probleme
+
+\
 
 Neben den technischen Herausforderungen gab es auch auf organisatorischer Ebene ein zentrales Problem, das den Projektverlauf im Sommer 2025 erheblich beeinflusste. Während der Sommermonate war die aktive Mitarbeit innerhalb des Teams sehr ungleich verteilt. Ein Großteil der Teammitglieder war urlaubsbedingt nicht oder nur eingeschränkt erreichbar und beteiligte sich in dieser Zeit kaum am Projekt. Nur ein kleiner Teil des Teams arbeitete in dieser Phase aktiv weiter und trieb den Fortschritt voran.
 
 Diese Situation führte zu einer deutlichen Ungleichverteilung der Arbeitsbelastung. Wenige Personen mussten in dieser Zeit deutlich mehr Verantwortung übernehmen als ursprünglich geplant, was zu Frustration und Verzögerungen führte. Im Nachhinein zeigt sich, dass klarere Absprachen und verbindlichere Vereinbarungen zu Beginn des Sommers dazu beigetragen hätten, diese Situation zu vermeiden oder zumindest abzumildern.
 
-## 5. Learnings
+## Learnings
 
-### 5.1 Technisch
+### Technisch
 
 Das Projekt hat auf technischer Ebene wertvolle praktische Kenntnisse vermittelt, die über den schulischen Rahmen hinausgehen. Der konsequente Einsatz von Git zur Versionskontrolle war dabei eine der wichtigsten Erfahrungen. Durch die tägliche Arbeit mit Branches, Commits und Merges wurde ein tiefes Verständnis für kollaborative Softwareentwicklung aufgebaut. Es wurde deutlich, wie wichtig aussagekräftige Commit-Nachrichten, regelmäßige Commits und eine saubere Branch-Struktur für die Zusammenarbeit im Team sind.
 
@@ -374,37 +426,37 @@ Im Bereich Responsive Design wurden durch die praktische Umsetzung des Themes un
 
 Auch der Umgang mit JavaScript zur Steuerung von UI-Elementen wurde durch die Arbeit am Projekt verbessert. Die Implementierung der Overlay-Steuerung in der Übergangslösung sowie die Menü-Logik im Theme haben gezeigt, wie JavaScript gezielt und effizient eingesetzt werden kann, um eine bessere Benutzererfahrung zu schaffen.
 
-### 5.2 Methodisch
+### Methodisch
 
 Auf methodischer Ebene hat das Projekt gezeigt, wie wichtig eine klare und verbindliche Aufgabenverteilung von Beginn an ist. In Phasen, in denen nicht klar war, wer welche Aufgaben übernimmt, entstanden Lücken und Verzögerungen. Eine strukturiertere Planung mit klar definierten Zuständigkeiten hätte in solchen Situationen geholfen, den Überblick zu behalten und die Arbeit effizienter aufzuteilen.
 
 Darüber hinaus hat sich gezeigt, dass regelmäßige Team-Meetings ein wichtiges Werkzeug für den Projekterfolg sind. In Phasen, in denen der Austausch im Team spärlicher war, dauerte es länger, bis Probleme erkannt und gelöst wurden. Kurze, regelmäßige Abstimmungen hätten dazu beigetragen, den aktuellen Stand besser zu kommunizieren und gemeinsam schneller auf Hindernisse zu reagieren.
 
-### 5.3 Persönlich
+### Persönlich
 
 Auf persönlicher Ebene war die wichtigste Erkenntnis aus diesem Projekt die Bedeutung von Eigeninitiative. In einem größeren Teamprojekt kann man sich nicht immer darauf verlassen, dass andere Aufgaben erledigen oder Entscheidungen treffen. Gerade in den Phasen, in denen nicht alle Teammitglieder aktiv waren, hat sich gezeigt, dass proaktives Handeln entscheidend ist, um das Projekt voranzubringen. Diese Erfahrung hat das Bewusstsein dafür gestärkt, Verantwortung nicht nur für den eigenen Bereich, sondern auch für das Gesamtprojekt zu übernehmen und bei Bedarf auch Aufgaben außerhalb des ursprünglich geplanten Bereichs zu übernehmen.
 
-## 6. Testen & Qualitätssicherung
+## Testen & Qualitätssicherung
 
-### 6.1 Funktionstests der Module
+### Funktionstests der Module
 
 Alle entwickelten Module – das Anmeldetool und das Hall-of-Fame-Modul – wurden manuell auf ihre korrekte Funktionsweise getestet. Dabei wurden sämtliche Benutzeraktionen systematisch durchgegangen, darunter das An- und Abmelden zu Veranstaltungen, das Erstellen, Bearbeiten und Veröffentlichen von Hall-of-Fame-Einträgen, das Hochladen von Bildern sowie die Melde- und Löschfunktionen. Fehler und unerwartetes Verhalten wurden dokumentiert und im Anschluss behoben.
 
 Beim Anmeldetool wurde insbesondere geprüft, ob die Zusage- und Absage-Buttons korrekt reagieren und der Status unmittelbar in der Oberfläche angezeigt wird. Beim Hall-of-Fame-Modul lag ein besonderer Fokus auf dem Bild-Upload: Es wurde getestet, ob die Größenbeschränkung von 5 MB korrekt greift, ob die Vorschau sofort erscheint und ob ungültige Dateiformate abgelehnt werden. Auch die Duplikatprüfung – also die Sicherstellung, dass pro Person nur ein Eintrag erstellt werden kann – sowie die Eigentümerprüfung wurden gezielt getestet.
 
-### 6.2 Theme-Tests
+### Theme-Tests
 
 Das entwickelte Oqtane-Theme wurde auf verschiedenen Browsern und Geräten getestet, um eine konsistente Darstellung sicherzustellen. Getestet wurde unter anderem auf aktuellen Versionen von Chrome, Firefox und Safari sowie auf mobilen Geräten mit unterschiedlichen Bildschirmgrößen. Ein besonderer Fokus lag dabei auf der korrekten Darstellung des Burger-Menüs auf mobilen Endgeräten sowie auf der Funktionsfähigkeit der dynamischen Navigation.
 
-### 6.3 Usability-Tests
+### Usability-Tests
 
 Neben den technischen Tests wurde die Plattform auch von weiteren Personen – darunter Mitschülerinnen und Mitschüler sowie Lehrkräfte – auf ihre Benutzerfreundlichkeit geprüft. Das Feedback aus diesen Tests floss in die weitere Entwicklung ein und führte unter anderem zu Anpassungen in der Darstellung und Bedienung einzelner Elemente.
 
 Ein häufiges Feedback war, dass die Unterscheidung zwischen Zusage und Absage auf den ersten Blick nicht immer sofort klar war. Daraufhin wurden die Schaltflächen farblich deutlicher gestaltet – Grün für die Zusage, Rot für die Absage – und die Beschriftungen präzisiert. Solche Rückmeldungen aus echten Nutzertests sind wertvoll, weil Entwicklerinnen und Entwickler ihre eigene Anwendung oft anders wahrnehmen als Personen, die das System zum ersten Mal sehen.
 
-## 7. Fazit und Ausblick
+## Fazit und Ausblick
 
-### 7.1 Zielerreichung
+### Zielerreichung
 
 Rückblickend auf das Projekt AlumniHub lässt sich festhalten, dass die zentralen Ziele meines individuellen Aufgabenbereichs erfolgreich umgesetzt wurden.
 
@@ -416,7 +468,7 @@ Das **Theme** wurde von einem anderen Teammitglied entwickelt und ist ebenfalls
 
 Insgesamt bin ich mit dem erreichten Stand zufrieden – insbesondere angesichts der Herausforderungen durch die Teamverkleinerung, den Plattformwechsel von Windows auf macOS und die technischen Probleme mit dem ursprünglichen Hosting.
 
-### 7.2 Ausblick
+### Ausblick
 
 Für die Weiterentwicklung der Plattform gibt es mehrere sinnvolle nächste Schritte. Im Bereich des Anmeldetools wäre die Implementierung einer vollständigen Teilnehmerliste mit direkter Datenbankanbindung der wichtigste nächste Schritt. Ergänzend dazu sollte die Möglichkeit geschaffen werden, maximale Teilnehmerzahlen pro Veranstaltung festzulegen, sodass Organisatoren die Kapazität von Treffen besser steuern können.
 

05-Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md

@@ -36,10 +36,10 @@ Ein wesentlicher Teil meiner Arbeit lag in der Bereitstellung der technischen Ba
 
 \ 
 
-Zusätzlich zur Infrastruktur habe ich drei zentrale Module für den Alumnihub entworfen und implementiert:
+Zusätzlich zur Infrastruktur habe ich drei zentrale Module für den AlumniHub entworfen und implementiert:
 
-1.  **Anmeldetool (EventRegistration)**: Ein Modul zum verwalten von Anmeldungen für Veranstaltungen. Es ermöglicht die einfache Erstellung von Einladungen zu Veranstaltungen und die Verwaltung von Anmeldungen.
-2.  **Reporting System**: Ein generisches System zur Meldung von Inhalten, das nach dem *Open-Closed-Prinzip* entworfen wurde, um eine einfache Erweiterbarkeit für alle anderen Module zu bieten.
+1.  **Anmeldetool (EventRegistration)**: Ein Modul zum Verwalten von Anmeldungen für Veranstaltungen. Es ermöglicht die einfache Erstellung von Einladungen sowie die Verwaltung von Anmeldungen.
+2.  **Reporting-System**: Ein generisches System zur Meldung von Inhalten, das nach dem *Open-Closed-Prinzip* entworfen wurde, um eine einfache Erweiterbarkeit für alle anderen Module zu bieten.
 3.  **Schwarzes Brett (BlackBoard)**: Ein Community-Modul für den Austausch von Informationen, inklusive eines automatisierten E-Mail-Digest-Systems zur Nutzerbenachrichtigung.
 
 
@@ -60,11 +60,11 @@ Das Ziel des Anmeldetools ist die effiziente Organisation von Vereinsveranstaltu
 - **Teilnehmerliste**: Für jede Veranstaltung muss eine Übersicht der Rückmeldungen (Anmeldungen/Absagen) für Administratoren einsehbar sein.
 - **Statistische Auswertung**: Die Rückmeldungen sollen grafisch (z. B. als Tortendiagramm) aufbereitet werden, um die Planung zu erleichtern.
 
-#### Globales Reporting System
+#### Reporting-System
 
 \ 
 
-Das Reporting System dient der Qualitätssicherung von Benutzerinhalten über alle Module hinweg.
+Das Reporting-System dient der Qualitätssicherung von Benutzerinhalten über alle Module hinweg.
 
 - **Inhalte melden**: Benutzer müssen die Möglichkeit haben, unangemessene Einträge (z. B. am Schwarzen Brett) zu melden. Dabei muss ein Grund für die Meldung angegeben werden können.
 - **Generische Schnittstelle**: Das System muss so entworfen sein, dass beliebige andere Module (z. B. Hall of Fame) die Meldefunktion ohne Änderungen am Kern des Reporting-Systems einbinden können.
@@ -117,7 +117,7 @@ Table: Wesentliche Use Cases der entwickelten Module
 Es ist zu beachten, dass es sich hierbei um eine Auswahl handelt und nicht alle Use Cases der Module abgebildet werden.
 
 
-## Technisches Umfeld
+## Technologien
 
 Mein Aufgabenbereich umfasst einerseits die Entwicklung eigener Module, sowie das Bereitstellen des Services.
 
@@ -127,18 +127,18 @@ Mein Aufgabenbereich umfasst einerseits die Entwicklung eigener Module, sowie da
 
 \ 
 
-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:
+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 Laufe 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, es basiert auf .NET 8.0 und wird nicht so aktiv gewartet.
 - Umbraco
-  > 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!
+  > Bei Umbraco muss viel in der Admin-Oberfläche vom 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
-  > 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.
+  > Dieses CMS ist der Platzhirsch. Es wird von der DNN Foundation gewartet und arbeitet mit dem Dotnet Framework, welches nicht unter Linux läuft. 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.
+  > Oqtane wirkt sehr modular und flexibel, auch innerhalb von Modulen kann man 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.
 
-Insbesondere 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.
 
 #### Entscheidungsfindung restliche Infrastruktur
 
@@ -152,7 +152,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 erlangt 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-basiierte Systeme. In der Linux-Welt 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.
 
 ### Beschreibung und Architektur von Oqtane
 
@@ -170,17 +170,17 @@ Ein Modul in Oqtane besteht aus vier Projekten:
 
 - 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 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 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 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.
+- 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).
+  - 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).
 
 ### Zusammenspiel der Infrastruktur
 
-In diesem Kapitel erkläre ich wie die ausgewählten Komponenten zusammenspielen.
+In diesem Kapitel erkläre ich, wie die ausgewählten Komponenten zusammenspielen.
 
 #### NginX as Reverse Proxy
 
@@ -189,12 +189,12 @@ In diesem Kapitel erkläre ich wie die ausgewählten Komponenten zusammenspielen
 NginX fungiert in unserer Infrastruktur als `Reverse Proxy`. Ein Reverse Proxy nimmt Anfragen aus dem Internet entgegen und leitet sie an interne Server (wie Kestrel) weiter. Dies bietet mehrere Vorteile:
 
 - **Sicherheit**: Die interne Applikation ist nicht direkt dem Internet ausgesetzt.
-- **SSL-Terminierung**: NginX übernimmt die rechenintensive Verschlüsselung (HTTPS), während die Applikation dahinter über einfaches HTTP kommuniziert.
-- **Statische Inhalte**: NginX kann statische Dateien (Bilder, CSS) effizienter ausliefern als ein Applikationsserver.
+- **SSL-Terminierung**: Nginx übernimmt die rechenintensive Verschlüsselung (HTTPS), während die Applikation dahinter über einfaches HTTP kommuniziert.
+- **Statische Inhalte**: Nginx kann statische Dateien (Bilder, CSS) effizienter ausliefern als ein Applikationsserver.
 
-Wir verwenden NginX für die SSL Terminierung. Das Zertifikat wird von Let's Encrypt bereit gestellt und mittels HTTP-Challenges und dem Certbot auf dem Server aktualisiert.
+Wir verwenden Nginx für die SSL-Terminierung. Das Zertifikat wird von Let’s Encrypt bereitgestellt und mittels HTTP-Challenges und dem Certbot auf dem Server aktualisiert.
 
-Hier ist ein Auszug der NginX-Konfiguration (`nginx.conf`) für den Alumnihub:
+Hier ist ein Auszug der NginX-Konfiguration (`nginx.conf`) für den AlumniHub:
 
 ```nginx
 server {
@@ -215,7 +215,7 @@ server {
 }
 ```
 
-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.
+Oqtane selbst 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
 sequenceDiagram
@@ -243,7 +243,7 @@ Zusätzlich gab es einen Administrationszugang zu den Servern, welcher über SSH
 
 Table: SSH Zugänge in den unterschiedlichen Umgebungen
 
-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.
+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
 
@@ -251,7 +251,7 @@ Die VPN basierten Zugänge sind tendenziell schwieriger zu finden und auszunutze
 
 \ 
 
-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 ist ein kostenloses und quelloffenes Web-Framework, welches es ermöglicht, 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:
 
@@ -265,9 +265,9 @@ Blazor hat mehrere Hosting-Modelle:
 
 Table: Vergleich der Blazor Hosting-Modelle
 
-Im Rahmen dieser Diplomarbeit haben wir und für den RenderModus Interactive Server entschieden. Dieser Modus ist für Oqtane die Standardeinstellung und bietet eine gute Balance zwischen Leistung und Benutzerfreundlichkeit. Das ist für unseren Anwendungsfall auch die Empfehlung von Oqtane selbst. [@oqtane_docs_rendermodes]
+Im Rahmen dieser Diplomarbeit haben wir uns für den Rendermodus Interactive Server entschieden. Dieser Modus ist für Oqtane die Standardeinstellung und bietet eine gute Balance zwischen Leistung und Benutzerfreundlichkeit. Das ist für unseren Anwendungsfall auch die Empfehlung von Oqtane selbst. [@oqtane_docs_rendermodes]
 
-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. 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-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. 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 separaten Code-Behind-Datei. Inline-C#-Code wird mithilfe von `@`-Zeichen markiert. Hier ist ein Beispiel für einen einfachen Counter:
 
 ```razor
 <h1>Counter</h1>
@@ -289,7 +289,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 Beispiel (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.
@@ -338,7 +338,7 @@ In den folgenden beiden Kapiteln wird das Dependency Inversion Principle und das
 
 \ 
 
-Das Dependency-Inversion-Principle (DIP / auf Deutsch: Abhängigkeits-Umkehr-Prinzip) ist eines von den fünf `SOLID` Prinzipien in der Softwareentwicklung.
+Das Dependency-Inversion-Principle (DIP / auf Deutsch: Abhängigkeits-Umkehr-Prinzip) ist eines der fünf SOLID-Prinzipien in der Softwareentwicklung.
 
 Das DIP unterscheidet zwischen high-level und low-level Modulen.
 
@@ -444,15 +444,15 @@ Gitea, das Versionskontrollsystem dieser Diplomarbeit, hat einen Continuous-Inte
 
 Man kann definieren auf welcher Änderung im Git Repository die Pipeline losgetreten wird (Keyword: `on`) und entweder eigene Kommandos aufreihen, oder auf bestehende `actions` zurückgreifen, welche dann der Reihe nach ausgeführt werden (Keyword: `jobs`).
 
-Die meisten Pipelines sind folgendermaßen Aufgebaut:
-Clone -> Checkout -> Submodule Checkout (optional) -> Dependencies einrichten (zum Beispiel das dotnet SDK) -> Build ausführen. -> Release erstellen und Artefakte veröffentlichen (z.B. in Registries). Aber man kann auch andere Dinge tun, z.B. mithilfe von Künstlicher Intelligenz Code und Dokumentation überprüfen.
+Die meisten Pipelines sind folgendermaßen aufgebaut:
+Clone -> Checkout -> Submodule-Checkout (optional) -> Dependencies einrichten (zum Beispiel das dotnet SDK) -> Build ausführen -> Release erstellen und Artefakte veröffentlichen (z. B. in Registries). Aber man kann auch andere Dinge tun, z. B. mithilfe von künstlicher Intelligenz Code und Dokumentation überprüfen.
 
 Anwendungen von Gitea Actions bei dieser Diplomarbeit:
 
-- **APT-Package Repository**: Zum Bauen von Oqtane und allen Modulen, verpacken in ein .deb Paket und in die Registry pushen.
-- **Interfaces Projekt**: Zum Bauen vom Interfaces-Projekt, verpacken in ein NuGet Paket und in die Registry pushen. Die Versionierung des NuGet-Pakets erfolgt dabei automatisiert über Git-Tags, was eine konsistente Verknüpfung zwischen Quellcode-Stand und Paketversion sicherstellt.
-- **ursprünglich: oqtane.framework**: Zum bauen und Verpacken in einen Docker Container und in die Registry pushen.
-- **PM Repository**: Zum automatischen Überprüfen der Dokumente, unter anderem, mithilfe von KI, wie zum Beispiel Gemini.
+- **APT-Package Repository**: Zum Bauen von Oqtane und allen Modulen, Verpacken in ein .deb-Paket und Pushen in die Registry.
+- **Interfaces-Projekt**: Zum Bauen vom Interfaces-Projekt, Verpacken in ein NuGet-Paket und Pushen in die Registry. Die Versionierung des NuGet-Pakets erfolgt dabei automatisiert über Git-Tags, was eine konsistente Verknüpfung zwischen Quellcode-Stand und Paketversion sicherstellt.
+- **ursprünglich: oqtane.framework**: Zum Bauen und Verpacken in einen Docker-Container und Pushen in die Registry.
+- **PM Repository**: Zum automatischen Überprüfen der Dokumente unter anderem mithilfe von KI, wie zum Beispiel Gemini.
 
 Ein Beispiel für eine Konfiguration einer Gitea Action:
 
@@ -492,7 +492,7 @@ jobs:
             ./alumnihub/opt/alumnihub/Packages/*.nupkg
 ```
 
-Die Konfiguration führt teilweise vorgefertigte Actions aus, wie zum Beispiel das Einrichten des .NET SDKs oder das Erstellen eines Releases. Aber es werden auch eigene Skripte ausgeführt, wie zum Beispiel das Bauen des .deb Pakets. Dieses ist im Repository unter `./run-build.sh` zu finden. Dieses Skript ist für die Automatisierung des Build-Prozesses zuständig und kümmert sich um das Kompilieren der Anwendung, das Erstellen des Debian-Pakets und das Hochladen in die Registry. Abgelegt ist es im APT-Package Repository unter `./gitea/workflows`.
+Die Konfiguration führt teilweise vorgefertigte Actions aus, wie zum Beispiel das Einrichten des .NET SDKs oder das Erstellen eines Releases. Aber es werden auch eigene Skripte ausgeführt, wie zum Beispiel das Bauen des .deb-Pakets. Dieses ist im Repository unter `./run-build.sh` zu finden. Dieses Skript ist für die Automatisierung des Build-Prozesses zuständig und kümmert sich um das Kompilieren der Anwendung, das Erstellen des Debian-Pakets und das Hochladen in die Registry. Abgelegt ist es im APT-Package-Repository unter `./gitea/workflows`.
 
 ### Debian Paket
 
@@ -525,7 +525,7 @@ Durch diesen Prozess wird sichergestellt, dass jede Version der Software eindeut
 
 ### Scrum
 
-Zum verwalten des Projektes haben wir uns an den Grundprinzipien von Scrum orientiert, um flexibel auf Änderungen reagieren zu können. Die Arbeit wurde in 14-tägige Sprints unterteilt.
+Zum Verwalten des Projektes haben wir uns an den Grundprinzipien von Scrum orientiert, um flexibel auf Änderungen reagieren zu können. Die Arbeit wurde in 14-tägige Sprints unterteilt.
 
 - **Sprint Planning**: Zu Beginn jedes Sprints wurden die Aufgaben aus dem Product Backlog in das Sprint Backlog übernommen.
 - **Dailies/Weekly**: Wir hielten wöchentliche Treffen ab, um den Fortschritt zu synchronisieren und Blocker zu identifizieren.
@@ -567,7 +567,7 @@ Als schlanke und selbst gehostete Open-Source-Alternative zu Plattformen wie Git
 
 \ 
 
-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. [@gitea_docs]
+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 komfortabel. Dies ermöglichte eine saubere Trennung der verschiedenen Projektkomponenten. [@gitea_docs]
 
 #### Issues
 
@@ -613,13 +613,13 @@ Gitea fungierte zusätzlich als Register für Pakete und Container-Images. Selbs
 
 ### 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.
+Eine C#-Solution, welche einige für den Admin-Einsatz geschriebene Module beinhaltet. Dieses Modul besteht aus drei Teilmodulen: einem Modul für den Versand von Rundmails, eines für die Einstellung der Token-Lebenszeit bei Tokens, welche per E-Mail 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.
+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
 
@@ -629,20 +629,20 @@ Das Mass Mailer Modul ist eine administrative Erweiterung für den Alumnihub, di
 
 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), sowie die Möglichkeit die Zustell-, Öffnungs- und Klickraten zu beobachten. Das Limit von 300 E-Mails pro Tag stellt uns jedoch in der kostenlosen Variante vor eine Herausforderung.
 
-`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 Mailversand 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.
 
 #### 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 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.
+Das Token-Lifetime-Modul wurde geschrieben, um die Token-Lebenszeit konfigurierbar zu machen. Notwendig war das, um die Passwort-Reset-Links im initialen Mailversand länger gültig sein zu lassen. Durch das `Batch-Processing` war es möglich, dass eine Mail erst Tage nach Erstellen des Links hinausgeschickt wird, und bei einer Standard-Ablaufdauer von zwei Tagen sind manche Links schon ungültig, bis sie den Mailserver 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. [@andrewlock_token_lifetime] 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:
+Es gibt zwei 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. [@race_conditions_pdf] 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. [@race_conditions_pdf] 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.
+- `die saubere Lösung`: Eine Änderung im Kern von Oqtane. Also wird in unserem Fork von Oqtane die Konfigurationslogik für die Token-Lifetime 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. [@race_conditions_pdf] Der initiale Grund dagegen ist, dass wir ein weiteres Git-Repository zu warten haben (den Fork vom Oqtane.Framework), welches jetzt nicht mehr mit Upstream commitgleich 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.
 
@@ -650,7 +650,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 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.
+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 ein globales Reporting-System entschieden.
 
 Angestrebt wurde folgender Ablauf für das Melden eines Eintrags:
 
@@ -672,11 +672,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 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.
+Im oben dargestellten Ablaufdiagramm werden das Reporting-Component und der Reporting-Handler 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 selbst verantwortlich, sondern müssen nur das Reporting-System einbinden.
 
 Darüber hinaus erfüllt dieses Design das **Open/Closed Principle**: Das Reporting-System ist offen für Erweiterungen (neue Module können einfach andocken), aber geschlossen für Modifikationen (der Kern des Reporting-Systems muss nicht für jedes neue Modul geändert werden).
 
-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. Die Versionierung folgt dabei strikt den Git-Tags im Repository, was eine saubere Release-History ermöglicht. Dieses NuGet-Paket wird dann in jedem notwendigen Modul als Dependency hinzugefügt und damit kann man Modulübergreifend auf die Services und das `IReportingComponent` 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. Die Versionierung folgt dabei strikt den Git-Tags im Repository, was eine saubere Release-History ermöglicht. Dieses NuGet-Paket wird dann in jedem notwendigen Modul als Dependency hinzugefügt, und damit kann man modulübergreifend auf die Services und das `IReportingComponent` zugreifen.
 
 Die Implementierung des `IReportingComponents` stellt nur eine Property (`ReportType`, welche den TypeName der Razor Komponente zurückliefert, damit `DynamicComponent` sie laden kann) und eine Methode (`ConstructParameterList`, welche das Parameter Dictionary erstellt. Nur zwecks Typensicherheit eingefügt) bereit. Mit dem `DynamicComponent` von Razor ist es möglich, per C# Code unterschiedliche Komponenten zu rendern und damit auch die per DI injizierte Klasse.
 
@@ -788,13 +788,12 @@ Detailansicht: Die Details-Komponente bietet eine fokussierte Ansicht des Eintra
 
 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 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
+- **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 personifizierte E-Mail-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.
 
-#### Reporting System
+#### Integration des Reporting-Systems
 
 \ 
 
@@ -812,11 +811,11 @@ Auf der Serverseite folgt das Modul dem etablierten Muster mit einem `BlackBoard
 
 ### 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-zeitverzug) gekommen. Hätte ich mich vor dem Start der Diplomarbeit mit dem Deployment von Oqtane auseinander gesetzt, dann wäre das in [Fehlende Dokumentation](#fehlende-dokumentation) beschriebene Problem früher aufgekommen und der Zeitverzug wäre nicht so groß, oder noch ganz vermeidbar gewesen.
+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 einzurichten gewesen, das Deployment in der Cloud von Hetzner war jedoch geplagt von Problemen. Im Zeitraum von Mai bis Oktober hatten wir keine laufende Produktivumgebung. Dadurch sind wir mit dieser Diplomarbeit auch in [Zeitverzug](#arbeitszeiteinschätzung-zeitverzug) gekommen. Hätte ich mich vor dem Start der Diplomarbeit mit dem Deployment von Oqtane auseinandergesetzt, dann wäre das in [Fehlende Dokumentation](#fehlende-dokumentation) 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 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.
+Nachdem ich mich von Anfang an vollkommen 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 weiterer Folge 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 zwei Personen vor dem 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.
 
 ### Arbeitszeiteinschätzung (Zeitverzug)
 
@@ -828,7 +827,7 @@ 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.
+- `Fehlende oder nur schlechte Dokumentation von Oqtane`: Einige Probleme im Deployment wurden in langer und mühseliger Arbeit auseinandergebrochen und in weitere immer kleinere Probleme unterteilt. Dadurch, dass wir alle keine Erfahrung mit der Entwicklung und dem Deployment von ASP.NET-Core-Anwendungen hatten und die Dokumentation doch schlecht war, blieb uns manchmal nichts anderes übrig, als mit WireShark den Netzwerktraffic mitzuschneiden und nebenbei im Git-Repository die geloggten Codezeilen zu finden und so das Framework von innen heraus kennenzulernen. Dadurch hatte ich dann nach einer Einarbeitungszeit von vier Monaten ziemlich jede Stelle im Sourcecode von Oqtane gesehen und finde mich umso 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.
 
@@ -853,13 +852,13 @@ 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](#sec:continuous-integration) Pipeline) am Tag der Besprechung zu vermeiden.
 
-# Fazit
+## Fazit
 
-Die Entwicklung des Alumnihubs auf Basis von Blazor und Oqtane war eine Reise geprägt von technischer Tiefe, organisatorischen Herausforderungen und wertvollen Erkenntnissen über moderne Software-Architektur. Rückblickend lässt sich festhalten, dass die Wahl des .NET-Stacks sowohl die erwarteten Stärken als auch unerwartete Hürden mit sich brachte.
+Die Entwicklung des AlumniHubs auf Basis von Blazor und Oqtane war eine Reise geprägt von technischer Tiefe, organisatorischen Herausforderungen und wertvollen Erkenntnissen über moderne Software-Architektur. Rückblickend lässt sich festhalten, dass die Wahl des .NET-Stacks sowohl die erwarteten Stärken als auch unerwartete Hürden mit sich brachte.
 
 Technisch gesehen haben sich die statische Typisierung von C# und das integrierte Dependency Injection Framework als äußerst wertvolle Werkzeuge erwiesen. Sie haben die Entwicklung komplexer, modularer Strukturen – wie des generischen *Reporting Systems* – erheblich vereinfacht und für eine hohe Konsistenz gesorgt. Dennoch zeigt der Vergleich zu anderen Stacks wie React und Go, dass Architektur-Vorteile nicht exklusiv an ein einzelnes Ökosystem gebunden sein müssen. Die Erfahrung mit Protobufs in anderen Kontexten verdeutlicht, dass eine sprachenagnostische Typisierung oft flexibler ist, ohne die Bindung an ein spezifisches Framework-Ökosystem zu erzwingen. .NET bleibt jedoch eine absolut valide und stabile Wahl für Projekte dieser Größenordnung.
 
@@ -869,5 +868,5 @@ In organisatorischer Hinsicht war die Verkleinerung des Teams ein Wendepunkt. Tr
 
 Persönlich bleibt vor allem die fünfmonatige Auseinandersetzung mit der Deployment-Problematik im Gedächtnis. Dass die Lösung für eine komplexe Infrastruktur-Hürde schließlich in einem unerwarteten Moment außerhalb der Arbeitsumgebung – fast schon ironisch – auftauchte, unterstreicht eine wichtige Lektion für jeden Entwickler: Beharrlichkeit ist notwendig, aber oft braucht es auch den nötigen Abstand, um den entscheidenden Blickwinkel zu finden.
 
-Abschließend lässt sich sagen, dass der Alumnihub nicht nur eine funktionsfähige Plattform für den Absolventenverein darstellt, sondern für mich persönlich als Beweis für die Bedeutung von technischer Neugier, architektonischer Weitsicht und der Fähigkeit zur kritischen Selbstreflexion dient.
+Abschließend lässt sich sagen, dass der AlumniHub nicht nur eine funktionsfähige Plattform für den Absolventenverein darstellt, sondern für mich persönlich als Beweis für die Bedeutung von technischer Neugier, architektonischer Weitsicht und der Fähigkeit zur kritischen Selbstreflexion dient.
 (Mehr dazu unter [Learnings](#sec:kh-learnings))