📝 "🎉 Updated IHK Projektdokumentation and added JS Optimization Report (backend/static/js)"
This commit is contained in:
@ -167,7 +167,7 @@ Die Technische Berufsausbildungsstätte (TBA) am Standort Berlin verfügt über
|
||||
|
||||
Das bestehende 'Reservierungssystem' - wenn man es nun so nennen kann - basierte auf einem analogen Whiteboard, welches neben den Druckern positioniert war. Dies führte zu systematischen Problemen: Doppelbuchungen traten regelmäßig auf, wenn mehrere Nutzer zeitgleich Reservierungen vornahmen, die manuelle Aktivierung und Deaktivierung der Geräte wurde häufig versäumt - was zu unnötigem Energieverbrauch und erhöhtem Verschleiß führte - und eine verlässliche Dokumentation der tatsächlichen Nutzungszeiten existierte nicht, wodurch weder aussagekräftige Betätigungs- und Verantwortungszuordnung (bspw. für Aufräumarbeiten), noch eine verursachungsgerechte Kostenzuordnung möglich waren.
|
||||
|
||||
Ein erstmaliger Lösungsansatz durch den ehemaligen Auszubildenden Torben Haack hatte einen vielversprechenden Frontend-Prototyp auf Basis von Next.js hervorgebracht. Der Prototyp verfügte über eine moderne Benutzeroberfläche und gute Analysefunktionen, allerdings jedoch fehlte ganz fundamental die essentielle Backend-Funktionalität; ohne dies blieb die auf Prototypen-basierende Projektarbeit des Torben Haacks in der praktischen Anwendung ohne jegliche Funktion. Ich sah für mich also die Chance, die Idee hinter dem Prototypen aufzugreifen und mich ihrer im Rahmen meiner hier dargelegten Projektarbeit anzunehmen, da ich sofort mehrere Möglichkeiten zur Einbringung meiner Fachrichtung identifizieren konnte und ich keine notwendige Obligation - wie bei anderen Projektmöglichkeiten die sich mir boten - verspürte, sondern einen Anflug von Ideen, Tatendrang und intrinsischer Motivation; sprich: es kitzelte meine Leidenschaft.
|
||||
Ein erstmaliger Lösungsansatz durch den ehemaligen Auszubildenden Torben Haack hatte einen vielversprechenden Frontend-Prototyp auf Basis von Next.js hervorgebracht. Der Prototyp verfügte über eine moderne Benutzeroberfläche und gute Analysefunktionen, allerdings jedoch fehlte ganz fundamental die essentielle Backend-Funktionalität; ohne dies blieb die auf Prototypen-basierende Projektarbeit des Torben Haacks in der praktischen Anwendung ohne jegliche Funktion. Nach erfolgter IHK-Genehmigung meines Projektantrags entdeckte ich diesen ungenutzten Prototyp und erkannte das Potenzial, ihn als Basis für meine Projektarbeit zu nutzen. Die Möglichkeit, mehrere Aspekte meiner Fachrichtung einzubringen, weckte meine intrinsische Motivation – im Gegensatz zu anderen verfügbaren Projektoptionen, die eher pflichtgemäßen Charakter hatten.
|
||||
|
||||
## 1.2 Ableitung der Projektziele
|
||||
|
||||
@ -243,13 +243,13 @@ Technische Berufsausbildungsstätte bot dabei die vorhandene
|
||||
Infrastruktur und – wenn auch manchmal zögerliche – fachliche
|
||||
Unterstützung durch die Ausbildungsleitung.
|
||||
|
||||
Die Zusammenarbeit mit Torben Haack erfolgte in Form einer sequenziellen
|
||||
Weiterentwicklung; ein Umstand, der sich aus der zeitlichen Versetzung
|
||||
unserer Ausbildungsphasen ergab. Da Herr Haack seine Ausbildung bereits
|
||||
abgeschlossen hatte und ich erst nach offizieller IHK-Zulassung mit der
|
||||
Projektarbeit beginnen durfte, konnte ich auf seinen Frontend-Prototyp
|
||||
aufbauen und diesen zu einer Gesamtlösung erweitern – eine Konstellation,
|
||||
die sich als Segen und Fluch zugleich erweisen sollte.
|
||||
Da Torben Haack seine Ausbildung bereits abgeschlossen hatte, als ich
|
||||
nach offizieller IHK-Zulassung mit der Projektarbeit begann, konnte ich
|
||||
auf seinen bereits existierenden Frontend-Prototyp aufbauen. Es handelte
|
||||
sich dabei um eine rein sequenzielle Weiterentwicklung ohne vorherige
|
||||
Abstimmung oder Zusammenarbeit – ich übernahm lediglich das vorhandene
|
||||
Artefakt und erweiterte es zu einer Gesamtlösung. Diese Konstellation
|
||||
erwies sich als Segen und Fluch zugleich.
|
||||
|
||||
Die organisatorischen Rahmenbedingungen wurden maßgeblich durch die
|
||||
konzerninternen Sicherheitsrichtlinien und IT-Governance geprägt.
|
||||
@ -355,10 +355,10 @@ unterteilt, wobei jeder Sprint seine eigenen Herausforderungen und
|
||||
|
||||
### Sprint 1 (15.-19. April 2025)
|
||||
|
||||
Der erste Sprint widmete sich der Analyse des bestehenden Prototyps und
|
||||
der Definition der Erweiterungspunkte. Die Evaluierung der
|
||||
Frontend-Codebasis offenbarte eine solide, wenn auch stellenweise
|
||||
überkomplexe Struktur. Die Spezifikation der erforderlichen
|
||||
Der erste Sprint widmete sich der Analyse des vorgefundenen Prototyps und
|
||||
der Definition der Erweiterungspunkte. Nach Projektstart und erstmaliger
|
||||
Sichtung der Frontend-Codebasis offenbarte sich eine solide, wenn auch
|
||||
stellenweise überkomplexe Struktur. Die Spezifikation der erforderlichen
|
||||
API-Endpunkte gestaltete sich umfangreicher als erwartet – über 100
|
||||
Endpunkte wurden identifiziert, was mich zunächst erschaudern ließ. Der
|
||||
kritische Meilenstein dieses Sprints war die erfolgreiche Etablierung
|
||||
@ -440,9 +440,8 @@ auch die strikte Offline-Anforderung des Projekts – ein Umstand, der
|
||||
sich als Segen erwies.
|
||||
|
||||
Als Betriebssystem stand zunächst eine Entscheidung zwischen OpenSUSE
|
||||
und NixOS im Raum – wir hatten uns bereits gedanklich auf NixOS
|
||||
festgelegt, da es durch seine deklarative Konfiguration für diesen
|
||||
Einsatzzweck prädestiniert schien. Letztendlich entschied ich mich doch
|
||||
und NixOS im Raum – NixOS schien durch seine deklarative Konfiguration
|
||||
für diesen Einsatzzweck prädestiniert. Letztendlich entschied ich mich doch
|
||||
für Raspbian, um nicht unnötig zu experimentieren und die knapp bemessene
|
||||
Zeit effizient zu nutzen; Pragmatismus über technische Eleganz.
|
||||
|
||||
@ -671,7 +670,7 @@ Wechsel der Systemarchitektur von einer verteilten zu einer
|
||||
konsolidierten Lösung.
|
||||
|
||||
Ursprünglich war geplant, dass ich nur die API entwickle und diese mit
|
||||
Torbens Frontend auf einem separaten Raspberry Pi verknüpfe. Diese
|
||||
dem existierenden Frontend auf einem separaten Raspberry Pi verknüpfe. Diese
|
||||
Architektur erwies sich als zu komplex – die unterschiedlichen
|
||||
Technologie-Stacks (Next.js vs. Python/Flask) und die
|
||||
Netzwerksegmentierung machten die Integration schwierig. Die
|
||||
|
Reference in New Issue
Block a user