Compare commits
13 Commits
7e533e67c9
...
ef35a13a4f
| Author | SHA1 | Date | |
|---|---|---|---|
| ef35a13a4f | |||
| b70e514a09 | |||
| 870b8a8da9 | |||
| 8e45423242 | |||
| 968d16592c | |||
| 0baccc63d7 | |||
| 86df0be0f4 | |||
| 96d0d50e4e | |||
| ab8d146b3c | |||
| 4da2d616a4 | |||
| 7b6a6ec35b | |||
| 1dd5df5ba8 | |||
| fb756a9b76 |
@@ -40,33 +40,33 @@ In diesem Kapitel werden die Technologien und Werkzeuge vorgestellt, die für di
|
||||
|
||||
### 2.1 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. 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.
|
||||
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 ist ein Framework, das es ermöglicht, interaktive Weboberflächen direkt in C# zu entwickeln. 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.
|
||||
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 ist ein Content-Management-System (CMS) – also eine Software, mit der Webseiten und deren Inhalte verwaltet werden können, ähnlich wie WordPress oder Typo3. 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. Für AlumniHub wurde Oqtane als Grundlage gewählt, weil es Benutzerverwaltung, Seitenstruktur und viele weitere Standardfunktionen bereits mitbringt und somit viel Entwicklungsaufwand spart.
|
||||
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
|
||||
|
||||
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. 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.
|
||||
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 ist eine kostenlose Open-Source-Bibliothek – also eine fertige Programmsammlung – die es ermöglicht, PDF-Dokumente direkt aus C#-Code heraus zu erstellen. 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.
|
||||
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
|
||||
|
||||
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. 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.
|
||||
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
|
||||
|
||||
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 ist eine next-generation IDE von Google, 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.
|
||||
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
|
||||
|
||||
@@ -282,7 +282,7 @@ Der Fremdschlüssel zu `SZUAbsolventenvereinHallOfFame` ist mit kaskadierendem L
|
||||
|
||||
#### 3.3.3 Datenbankmigrationen
|
||||
|
||||
Die Datenbankstruktur wird über Entity Framework Core Migrationen versioniert verwaltet.
|
||||
Die Datenbankstruktur wird über Entity Framework Core Migrationen versioniert verwaltet [@ef_core_migrations].
|
||||
|
||||
| Migration | Versionsnummer | Inhalt |
|
||||
|--------------------|----------------|--------|
|
||||
@@ -348,7 +348,7 @@ Ein weiteres technisches Problem ergab sich durch den Wechsel von Windows auf ma
|
||||
|
||||
Ein weiteres technisches Problem betraf das Hosting von Oqtane auf dem Hetzner-Server. Die Einrichtung und der Betrieb von Oqtane auf dem Server bereiteten unerwartete Schwierigkeiten, die den regulären Entwicklungsfortschritt verlangsamten. Da dieser Bereich nicht zum eigenen Aufgabengebiet gehörte, konnten die genauen Ursachen nicht vollständig nachvollzogen werden. Die Probleme wirkten sich jedoch auf den gesamten Zeitplan des Projekts aus und waren mitverantwortlich dafür, dass AlumniHub zum Zeitpunkt des ersten Treffens noch nicht fertig war.
|
||||
|
||||
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 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.
|
||||
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
|
||||
|
||||
@@ -423,25 +423,3 @@ Für die Weiterentwicklung der Plattform gibt es mehrere sinnvolle nächste Schr
|
||||
Langfristig könnte die Plattform um eine automatische E-Mail-Benachrichtigung erweitert werden, die Mitglieder an bevorstehende Veranstaltungen erinnert. Auch eine Exportfunktion für die Anmeldedaten – beispielsweise als CSV oder PDF – wäre für die Vereinsverwaltung hilfreich.
|
||||
|
||||
AlumniHub bietet als Plattform eine solide Grundlage, die in den kommenden Jahren kontinuierlich erweitert werden kann, um den Absolventenverein der HTL Ungargasse langfristig digital zu unterstützen.
|
||||
|
||||
## 8. Quellen
|
||||
|
||||
Microsoft: ASP.NET Core Documentation. https://learn.microsoft.com/en-us/aspnet/core/ [Zugriff: 17.03.2026]
|
||||
|
||||
Microsoft: Blazor Documentation. https://learn.microsoft.com/en-us/aspnet/core/blazor/ [Zugriff: 17.03.2026]
|
||||
|
||||
Microsoft: Entity Framework Core – Migrations. https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/ [Zugriff: 17.03.2026]
|
||||
|
||||
Oqtane Framework: https://www.oqtane.org/ [Zugriff: 17.03.2026]
|
||||
|
||||
Oqtane Developer Documentation: https://docs.oqtane.org/ [Zugriff: 17.03.2026]
|
||||
|
||||
QuestPDF Open Source Library: https://www.questpdf.com/ [Zugriff: 17.03.2026]
|
||||
|
||||
Bootstrap Framework: https://getbootstrap.com/ [Zugriff: 17.03.2026]
|
||||
|
||||
Gitea – Open Source Git Service: https://about.gitea.com/ [Zugriff: 17.03.2026]
|
||||
|
||||
LiveDesign – Hosting, Design & Branding: https://livedesign.at/ [Zugriff: 17.03.2026]
|
||||
|
||||
JetBrains Rider: https://www.jetbrains.com/rider/ [Zugriff: 17.03.2026]
|
||||
@@ -213,7 +213,7 @@ Der Umfang des Backups besteht aus zwei zentralen Komponenten:
|
||||
|
||||
Damit wird eine vollständige Sicherung der Webseite ermöglicht, da bei einer reinen Datenbanksicherung wichtige Anwendungsdateien fehlen würden.
|
||||
|
||||
```mermaid
|
||||
``` {.mermaid width=80% height=70%}
|
||||
%%| filename: flowchart-backup-system
|
||||
%%| fig-cap: Ablaufdiagramm des Backup-Systems
|
||||
graph TD
|
||||
@@ -527,7 +527,7 @@ Der zentrale Zweck besteht darin, einen Anreiz für aktives Engagement im Verein
|
||||
|
||||
Die Entwicklung erfolgte als eigenständiges Oqtane-Modul, wodurch eine nahtlose Integration in die bestehende VereinsWebseite gewährleistet wird. Das Modul nutzt dabei die vom Framework bereitgestellten Mechanismen für Authentifizierung, Autorisierung, Datenbankzugriff und Dateiverwaltung. Die Architektur folgt etablierten Entwurfsmustern wie dem Repository-Pattern, Dependency Injection und dem Service-Layer-Muster. Das kumulative Premium-System mit vollständigem Audit-Trail stellt sicher, dass alle Statusänderungen transparent und nachvollziehbar sind. Die modulare Struktur erlaubt eine einfache Erweiterung um zusätzliche Funktionen, ohne die bestehende Codebasis grundlegend verändern zu müssen.
|
||||
|
||||
```mermaid
|
||||
``` {.mermaid width=80% height=70%}
|
||||
%%| filename: architecture-premium-module
|
||||
%%| fig-cap: Architektur des Premium-Bereich-Moduls
|
||||
graph TD
|
||||
@@ -786,7 +786,7 @@ private bool IsUserPremium(System.Security.Claims.ClaimsPrincipal user)
|
||||
}
|
||||
```
|
||||
|
||||
```mermaid
|
||||
``` {.mermaid width=80% height=70%}
|
||||
%%| filename: flowchart-premium-access
|
||||
%%| fig-cap: Zugriffsprüfung für Premium-Inhalte
|
||||
flowchart TD
|
||||
|
||||
@@ -334,7 +334,7 @@ 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.
|
||||
|
||||
#### Dependency Inversion Principle [@ms_dependency_inversion][@logrocket_dependency_inversion]
|
||||
#### Dependency Inversion Principle [@ms_dependency_inversion] [@logrocket_dependency_inversion]
|
||||
|
||||
\
|
||||
|
||||
@@ -438,7 +438,7 @@ architecture-beta
|
||||
|
||||
```
|
||||
|
||||
### Continuous Integration
|
||||
### Continuous Integration {#sec: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.
|
||||
|
||||
@@ -449,16 +449,50 @@ Clone -> Checkout -> Submodule Checkout (optional) -> Dependencies einrichten (z
|
||||
|
||||
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 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.
|
||||
|
||||
# Gitea Actions YAML einfügen und erklären
|
||||
Ein Beispiel für eine Konfiguration einer Gitea Action:
|
||||
|
||||
```yaml
|
||||
name: build-debian-package
|
||||
on:
|
||||
push:
|
||||
tags:
|
||||
- "*"
|
||||
|
||||
jobs:
|
||||
build:
|
||||
name: Build the debian package
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: "Git clone"
|
||||
run: git clone ${{ gitea.server_url }}/${{ gitea.repository }}.git .
|
||||
- name: "Git checkout"
|
||||
run: git checkout "${{ gitea.sha }}"
|
||||
- name: "Submodules auschecken"
|
||||
run: git submodule update --init
|
||||
- name: "Dotnet SDK einrichten"
|
||||
uses: actions/setup-dotnet@v4
|
||||
with:
|
||||
dotnet-version: "10.0.x"
|
||||
- name: "Configure nuget source"
|
||||
run: dotnet nuget add source --name DAV --username kocoder --password ${{ secrets.REGISTRY_TOKEN_KOCODER }} https://git.kocoder.xyz/api/packages/Diplomarbeit-Absolventenverein/nuget/index.json --store-password-in-clear-text
|
||||
- name: "Build .deb"
|
||||
run: ./run-build.sh "${{ gitea.ref_name }}" "./alumnihub" "Release"
|
||||
- name: "Upload .deb"
|
||||
run: curl --user kocoder:${{ secrets.REGISTRY_TOKEN_KOCODER }} --upload-file ./alumnihub.deb https://git.kocoder.xyz/api/packages/Diplomarbeit-Absolventenverein/debian/pool/trixie/main/upload
|
||||
- name: "Create release"
|
||||
uses: akkuman/gitea-release-action@v1
|
||||
with:
|
||||
files: |-
|
||||
./alumnihub.deb
|
||||
./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`.
|
||||
|
||||
### Debian Paket
|
||||
|
||||
@@ -539,31 +573,39 @@ Ein Repository bildet den zentralen Speicherort für einen Projektteil. In Gitea
|
||||
|
||||
\
|
||||
|
||||
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. [@gitea_docs][@gitea_issue_tracker]
|
||||
{ width=70% }
|
||||
|
||||
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. [@gitea_docs] [@gitea_issue_tracker]
|
||||
|
||||
#### 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. [@gitea_docs][@gitea_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. [@gitea_docs] [@gitea_pull_requests]
|
||||
|
||||
#### 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. [@gitea_docs][@gitea_actions]
|
||||
{ width=70% }
|
||||
|
||||
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. [Siehe Abschnitt \ref{sec:continuous-integration}] [@gitea_docs] [@gitea_actions]
|
||||
|
||||
#### Releases
|
||||
|
||||
\
|
||||
|
||||
{ width=70% }
|
||||
|
||||
Ü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. [@gitea_docs]
|
||||
|
||||
#### 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. [@gitea_docs][@gitea_packages]
|
||||
{ width=70% }
|
||||
|
||||
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. [@gitea_docs] [@gitea_packages]
|
||||
|
||||
### Kommunikation
|
||||
|
||||
@@ -579,9 +621,13 @@ Eine C#-Solution, welche einige Module, welche für den Admineinsatz geschrieben
|
||||
|
||||
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
|
||||
##### 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.
|
||||
\
|
||||
|
||||
{ width=70% }
|
||||
|
||||
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.
|
||||
|
||||
@@ -667,7 +713,7 @@ Die Kommunikation zwischen dem Client und dem Server erfolgt über einen REST-AP
|
||||
|
||||
\
|
||||
|
||||
```mermaid
|
||||
``` {.mermaid width=50%}
|
||||
%%| filename: erd-event-registration
|
||||
%%| fig-cap: ER Diagramm des Event Registration Moduls
|
||||
erDiagram
|
||||
@@ -706,8 +752,6 @@ erDiagram
|
||||
|
||||
\
|
||||
|
||||
# TODO: Bild vom Grafen hier einfügen
|
||||
|
||||
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 JS-Interop-Layer ist zwar standardmäßig in Oqtane-Modulen vorgesehen, wurde jedoch in diesem Modul zum ersten Mal angepasst und produktiv eingesetzt. Der Ablauf der grafischen Darstellung gestaltet sich wie folgt:
|
||||
@@ -716,7 +760,9 @@ Um die Brücke zwischen dem C#-basierten Blazor-Frontend und der JavaScript-Bibl
|
||||
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.
|
||||
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.
|
||||
|
||||
{ width=40% fig-pos=H }
|
||||
|
||||
### Schwarzes Brett
|
||||
|
||||
@@ -726,16 +772,15 @@ Das Modul "Schwarzes Brett" dient als digitale Anschlagtafel für den Absolvente
|
||||
|
||||
\
|
||||
|
||||
{ latex-placement="ht" }
|
||||
|
||||
<!-- ![Detailansicht eines Eintrags auf dem Schwarzen Brett][img-ref] -->
|
||||
|
||||
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. Für die Eingabe und Formatierung der Texte wird auf die von Oqtane standardmäßig bereitgestellten Rich-Text-Editoren zurückgegriffen, was eine konsistente Nutzerführung im gesamten CMS gewährleistet. Ergänzt wird dies durch Metadaten wie Erstellungsdatum und Autor.
|
||||
{ width=70% fig-pos=H }
|
||||
|
||||
<!-- [img-ref]: BlackBoard-Details.png "Detailansicht eines Eintrags auf dem Schwarzen Brett" -->
|
||||
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. Für die Eingabe und Formatierung der Texte wird auf die von Oqtane standardmäßig bereitgestellten Rich-Text-Editoren zurückgegriffen, was eine konsistente Nutzerführung im gesamten CMS gewährleistet. Ergänzt wird dies durch Metadaten wie Erstellungsdatum und Autor.
|
||||
|
||||
{ width=70% fig-pos=H }
|
||||
|
||||
#### Automatisierter E-Mail-Digest
|
||||
|
||||
@@ -755,13 +800,15 @@ Um die Mitglieder regelmäßig über neue Inhalte zu informieren, wurde ein auto
|
||||
|
||||
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.
|
||||
|
||||
{ width=70% fig-pos=H }
|
||||
|
||||
#### 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.
|
||||
|
||||
## Learnings
|
||||
## Learnings {#sec:kh-learnings}
|
||||
|
||||
### Produktion != Staging
|
||||
|
||||
@@ -793,7 +840,7 @@ Um das Projektziel dennoch zu erreichen, wurde der Zeitplan im Herbst 2025 massi
|
||||
`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) [@bentley1985programming]
|
||||
> [@bentley1985programming]
|
||||
> Diese Diplomarbeit liefert weitere Evidenz, dass diese Faustregel stimmt.
|
||||
|
||||
### Sprints und Meetings (in Zukunft ja asynchron)
|
||||
@@ -808,6 +855,19 @@ 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.
|
||||
- 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.
|
||||
|
||||
\pagebreak
|
||||
# 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.
|
||||
|
||||
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.
|
||||
|
||||
Ein zentraler Aspekt der Reflexion betrifft den Entwicklungsprozess. Die Erkenntnis, dass eine strikte Review-Kultur und eine frühzeitige CI/CD-Automatisierung essenziell sind, kam erst im Verlauf des Projekts voll zum Tragen. Initial fehlende Strukturen führten dazu, dass Module oft unreflektiert hochgeladen wurden, was die Qualitätssicherung erschwerte. Für zukünftige Projekte wäre ein „Automation-First“-Ansatz die oberste Priorität.
|
||||
|
||||
In organisatorischer Hinsicht war die Verkleinerung des Teams ein Wendepunkt. Trotz der gestiegenen individuellen Arbeitslast führte das „Downsizing“ zu einer signifikant höheren Identifikation mit dem Projekt und einer gesteigerten Effizienz. Die klarere Verantwortung jedes einzelnen Mitglieds sorgte für eine Dynamik, die im größeren, weniger fokussierten Team nicht erreicht werden konnte.
|
||||
|
||||
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.
|
||||
(Mehr dazu unter [Learnings](#sec:kh-learnings))
|
||||
@@ -1,3 +1,6 @@
|
||||
\usepackage{float}
|
||||
\floatplacement{figure}{H}
|
||||
\raggedbottom
|
||||
\usepackage{etoolbox}
|
||||
\makeatletter
|
||||
\patchcmd{\LT@array}{\tabskip\z@}{\tabskip\fill}{}{}
|
||||
@@ -12,7 +15,9 @@
|
||||
|
||||
\usepackage[hyphens]{url}
|
||||
\usepackage[hidelinks]{hyperref}
|
||||
\setlength{\emergencystretch}{3em} % Prevent overfull lines
|
||||
\usepackage[htt]{hyphenat}
|
||||
\usepackage{microtype}
|
||||
\setlength{\emergencystretch}{5em} % Increased to solve overfull lines
|
||||
|
||||
\usepackage{tocloft}
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 508 KiB After Width: | Height: | Size: 208 KiB |
BIN
images/05-Konstantin/BlackBoard-Overview.png
Normal file
|
After Width: | Height: | Size: 227 KiB |
BIN
images/05-Konstantin/Brevo.png
Normal file
|
After Width: | Height: | Size: 105 KiB |
BIN
images/05-Konstantin/EventRegistration-PieChart.png
Normal file
|
After Width: | Height: | Size: 12 KiB |
BIN
images/05-Konstantin/GiteaActions-Overview.png
Normal file
|
After Width: | Height: | Size: 90 KiB |
BIN
images/05-Konstantin/GiteaActions-Releases.png
Normal file
|
After Width: | Height: | Size: 124 KiB |
BIN
images/05-Konstantin/GiteaIssues-TaskBoard.png
Normal file
|
After Width: | Height: | Size: 459 KiB |
BIN
images/05-Konstantin/GiteaPackageRepository.png
Normal file
|
After Width: | Height: | Size: 195 KiB |
BIN
images/05-Konstantin/ReportSystem-HandleReport.png
Normal file
|
After Width: | Height: | Size: 168 KiB |
23
sources.bib
@@ -257,3 +257,26 @@
|
||||
year = {2024},
|
||||
urldate = {2026-03-19}
|
||||
}
|
||||
@online{jetbrains_rider,
|
||||
title = {JetBrains Rider},
|
||||
url = {https://www.jetbrains.com/rider/},
|
||||
author = {{JetBrains}},
|
||||
year = {2026},
|
||||
urldate = {2026-03-17}
|
||||
}
|
||||
|
||||
@online{oqtane_framework_site,
|
||||
title = {Oqtane Framework},
|
||||
url = {https://www.oqtane.org/},
|
||||
author = {{Oqtane Foundation}},
|
||||
year = {2026},
|
||||
urldate = {2026-03-17}
|
||||
}
|
||||
|
||||
@online{oqtane_docs_dev,
|
||||
title = {Oqtane Developer Documentation},
|
||||
url = {https://docs.oqtane.org/},
|
||||
author = {{Oqtane Foundation}},
|
||||
year = {2026},
|
||||
urldate = {2026-03-17}
|
||||
}
|
||||
|
||||