Hier ein paar Bilder der Führung. 

Eines der dunkelsten Kapitel der Bamberger Geschichte sind die Hexenverfolgungen, denen im 17. Jahrhundert Hunderte von Bürger:innen zum Opfer fielen. Die Jagd auf Hexen und Hexer beschränkte sich keineswegs, wie gängige Klischees glauben machen wollen, auf rothaarige Frauen oder ältere Mütterchen, sondern erfasste Männer und Frauen aus allen sozialen Schichten bis hinauf zu Bamberger Bürgermeistern. Wer einmal im „Trudenhaus“, dem Bamberger Hexengefängnis, landete, der war schon so gut wie verloren.

~Geschichte für alle e.V.

Zusammen mit dem Verein Geschichte Für Alle e.V. wollen wir euch kurz vor Halloween die Möglichkeit bieten, die dunkle Vergangenheit Bambergs kennenzulernen. Im Rahmen einer kostenlosen Stadtführung könnt ihr die Geschichte der brutalen Hexenverfolgungen erforschen. Die Führung findet am Sonntag, 29.10 ab 16:00 statt. Da die Kapazität der Führung begrenzt ist, ist eine Anmeldung notwendig; Plätze werden nach dem first-come, first-served Prinzip vergeben. Die Kosten der Führung übernimmt Feki.de, sodass ihr einfach nur Interesse mitbringen müsst. Im vergangenen Sommersemester hat sich die Hexenführung bereits als sehr beliebt herausgestellt, schnell sein lohnt sich also.

Bitte achtet auf wettergerechte Kleidung und Schuhe.

Anmeldung abgeschlossen

Seit ihrer Gründung im Jahr 2000 hat die Website Feki.de das studentische Leben bereichert und sich im Laufe der Jahre kontinuierlich weiterentwickelt. Von den Nutzungszwecken bis hin zur Entwicklung und Aktualisierung wurden zahlreiche Veränderungen vorgenommen. Im zweiten Teil des Devlogs werden wir die faszinierende Historie der Website erforschen und wertvolle Erfahrungen daraus ziehen, die für die Entwicklung einer modernen Website von Bedeutung sind.

💡 Wieso gibt es die Website überhaupt?

In den frühen 2000er Jahren war das Internet noch relativ neu, und viele Organisationen, einschließlich der Universität Bamberg, hatten noch wenig Erfahrung mit Online-Auftritten. Einige engagierte Studenten bemerkten, dass wichtige Informationen für Neulinge an der Universität nur schwer oder gar nicht auf der offiziellen Website der Universität zu finden waren. Daher entstand die Idee, eine eigene Website zu erstellen, die nicht nur diese Informationen leicht zugänglich macht, sondern auch zusätzliche Dienste für die Studierenden anbietet, die in der realen Welt eingeschränkt verfügbar waren, wie zum Beispiel einen Mensaplan, eine HiWi-Jobbörse oder ein Forum.

🚀 Version 1.0

Natürlich waren die Ambitionen zu Beginn noch bescheiden, aber mit der ersten Version der Website, die im Oktober 2000 online ging, waren bereits einige Elemente vorhanden. Dazu gehörten Neuigkeiten zu aktuellen Themen für Studierende, Inhalte zum Studium und Leben in Bamberg, ein Terminkalender und Bilder von Events.

Feki.de zum Launch der ersten Website 2000 (Quelle Waybackmachine)

Was jedoch rückblickend besonders interessant ist, ist die Funktionsweise der Website zu dieser Zeit, da sie einen spannenden Überblick über ihre Entwicklung bietet.

Die Website wurde mit dem Tool Macromedia Dreamweaver erstellt, das damals ein weit verbreitetes Programm war, mit dem HTML-Seiten nach dem WYSIWYG-Prinzip relativ einfach erstellt werden konnten. Darüber hinaus wurde serverseitiger Code geschrieben, der in unserem Fall mit Java Server Pages (JSP) implementiert war und zum Beispiel das aktuelle Wetter oder die Navigation geladen hat. Im Wesentlichen wurde die gesamte Website jedoch selbst geschrieben, ohne Verwendung eines Frameworks oder ähnlicher Hilfsmittel.

Eine Sache, die jedoch heute viele erfahrenere IT-Experten erschrecken würde, ist, wie Aktualisierungen der Daten oder der Website damals durchgeführt wurden - nämlich alles manuell! Die Website selbst war auf einem Server gespeichert, ähnlich wie in einem Ordner auf dem PC, und über FTP (File Transfer Protocol), ein damals weit verbreitetes Protokoll, um auf Ordner eines Servers zuzugreifen (heutzutage nur noch selten genutzt), erreichbar. Um Änderungen vorzunehmen, musste man also die Website über FTP herunterladen bzw. synchronisieren, Änderungen am eigenen PC vornehmen (z. B. eine neue HTML-Seite für einen Artikel und einen Teaser mit Verlinkung auf der Startseite hinzufügen) und dann wieder auf den Server hochladen. Genauso lief es auch bei anderen Code-Updates usw. ab. Nur wenige Inhalte wie Umfragen wurden in einer Datenbank gespeichert, bei denen nur der Code geändert, aber nicht die Daten manuell eingetragen werden mussten.

Version 1.1: Erste Style Verbeserung 2001 (Quelle Waybackmachine)

Als Laie könnte man vielleicht denken, dass es nicht so schlimm ist, aber das eigentliche Problem tritt auf, wenn man etwas falsch macht und die Seite sofort nicht mehr funktioniert oder Daten beschädigt werden können. Noch schlimmer ist es, wenn zwei Personen gleichzeitig Änderungen vornehmen und eine der Änderungen überschrieben und potenziell sogar verloren geht.

Um diese Probleme zu umgehen, wurde zunächst eine Regel eingeführt, dass nur geschulte Mitglieder, meist aus der IT, den Code direkt ändern dürfen. Später wurde dann etwas Besseres eingeführt: Subversion - ein Code-Versionsverwaltungsprogramm. Damit konnte endlich sichergestellt werden, dass keine Änderungen verloren gehen. Es war zwar immer noch nicht perfekt sicher, aber zumindest deutlich besser als zuvor.

Version 1.2: Größere Style Verbeserung 2002

Ein weiteres interessantes Problem war, dass der RAM des Servers immer voller wurde, je länger der Server lief. Zu der Zeit hatte der Server nur 8 GB RAM, daher war es sehr wahrscheinlich, dass der Server nach längerer Laufzeit einfach nicht mehr funktioniert. Aus diesem Grund wurde der Server jede Nacht einfach neu gestartet. Grundsätzlich keine schlechte Idee, aber der aktuelle Server bleibt teilweise sogar länger als 1 Jahr online, da mittlerweile so viele Dinge auf dem Server laufen, die auch aufeinander aufbauen, und beim Neustart immer wieder etwas nicht korrekt funktioniert.

Im Laufe der Jahre wurden neue Features zur ersten Website hinzugefügt, wie zum Beispiel ein Forum, das zu der Zeit viel für das Verbreiten von Gossip genutzt wurde, oder eine verbesserte Jobbörse. Die Website hat in den 9 Jahren mehrere Redesigns bekommen, die jedoch nur wenig am Aufbau geändert haben. Nur die Einführung einer neuen Menüstruktur (UNIleben, EINleben, ÜBERleben, Feki.de ERleben) war "revolutionär", hat jedoch wenig an den Inhalten und der Struktur geändert.

Version 1.3: Letzte Style Verbeserung 2007

Letztendlich war den meisten Mitgliedern jedoch schon ab 2006 klar, dass etwas Neues her muss. Die erste Idee war, die neue Website mit JSF (JavaServer Faces) - Codename JOSEF - umzusetzen, ein Web-Framework, das die Erstellung von Benutzeroberflächen erleichtern soll. Jedoch hatte dies nur wenig Erfolg im IT-Ressort und wird auch heute nur noch wenig genutzt. Die zweite Idee, die etwas später von einem Mitglied hauptsächlich im Alleingang ausprobiert wurde, war OpenCMS. Damit war auch die erste Überlegung, nicht die komplette Seite selbst zu schreiben, sondern ein vorgefertigtes CMS (Content Management System) zu nutzen, in dem mithilfe von Plugins oder Modulen neue Funktionen integriert werden können. Hier war jedoch der Enthusiasmus recht gering, besonders weil eine Alternative zu OpenCMS deutlich beliebter war: Joomla! (hatte zu der Zeit ein nach Google Trends Kopf an Kopf-Rennen mit dem heute sehr viel weiter verbreiteten Wordpress).

🥳 Version 2.0

Der gesamte Code für diese Version ist hier zu finden: https://gitlab.feki.de/web/nepal

Nach dem entscheiden für die Technologie ging es nun darum, alle Komponenten aus der alten Webseite in Joomla zu erstellen und danach die Daten zu migrieren. Zusätzlich sollte auch ein neues Design her, das in Kooperation mit einer Marketingagentur entwickelt wurde.

Feki.de 2.0 im Jahr 2012

Codename für diese Website lautete diesmal NEPAL (NEw Page At Last), das Projekt wurde 2007 gestartet und hatte ca. 10 Leute im IT-Team, davon 4 fest dabei. Die Entwicklung wurde dabei vorwiegend an 15 gemeinsamen Wochenenden durchgeführt, weil es noch nicht so viele Möglichkeiten gab, online gemeinsam zu Arbeiten. Für die Migration waren dann auch der gesamte Verein und die Interessierten an insgesamt 8 Inhaltsübertragungen involviert.

Die Entwicklung war diesmal etwas anders, weil einerseits der Code von Anfang an in einem Subversion Repository gespeichert war, und andererseits, weil aller Code als Erweiterungen für Joomla geschrieben war. Insgesamt gab es hier allerdings nur drei wirkliche Besonderheiten:

1. Joomla hatte zu der Zeit noch kein RBAC (Role-Based-Access-Control), also dass Nutzer eine Rolle bekommen können und dadurch bestimmte Rechte bekommen. Da so ein Tool sehr viele Sicherheitslücken schaffen kann, wurde dafür ein Plugin gekauft. Der Prozess für die Initialisierung des gekauften Moduls war aber ziemlich bizarr, da der Code verschlüsselt gespeichert und erst beim starten des Servers entschlüsselt und geladen wurde.
2. Wegen der Modul- und Model-View-Controller Struktur von Joomla hatte jede einzelne Komponente ziemlich viele unterschiedliche Dateien, was die Einarbeitung und das erstellen von neuen Modulen ziemlich verkompliziert hat.
3. Die Updates der Module wurden erreicht, indem das jeweilige Module als Archiv verpackt und auf der Website hochgeladen wurde. Tatsächliche Autmoatisierung gab es hier auch noch nicht

Nachdem dann die Entwicklung fertig war, ging es an die Inhaltsübertragung. Das war insgesamt ein ziemlich großes Verfangen, weil alle aktiven Artikel, Forumsbeiträge und Jobangebote seit 2001 aus der aktuellen Version übertragen werden sollten. Und das eigentlich größte Problem: Da viele Inhalte nicht in der Datenbank gespeichert waren und das Datenbankschema der Joomla seite nicht sehr Import-freundlich war, musste fast alles per Hand per copy-paste erledigt werden.

Doch auch das war nach einigen Treffen endlich erledigt, und die neue Website konnte im Juli 2009 inklusive Sektempfang live gelaunched werden!

Leider war dann aber auch bei sehr vielen Entwicklern die Luft raus, und an der Seite hat sich in den nächsten Jahren, außer inhaltlich, wenig bis gar nichts verändert. Und dazu gehören leider auch die Sicherheitsupdates. Es wurde noch geschafft, bis Joomla 2.5 upzudaten, allerdings waren danach die notwendigen Änderungen so groß, dass sich kein Team gefunden hat, welches das in Angriff nehmen wollten. Das Problem dabei zeigte sich dann auch schon Anfang 2014, als plötzlich immer mehr russische Links in Artikeln aufgetaucht sind. Vermutlich wurde dabei eine Sicherheitslücke ausgenutzt, um den Inhalt der Artikel zu bearbeiten. Eine neue Webseite war bereits in Arbeit, daher wurde im Juli 2014 in einer schnellen Aktion auf die neue Website umgestellt. Da aber wie schon gesagt viele der Artikel problematische Links enthalten haben, wurden hier die Inhalte nicht mehr komplett übertragen.

🤩 Version 3.0

Der Code dieser Version wird nach Release der Version 4.0 ebenfalls veröffentlicht!

Feki.de 3.0 im Jahr 2014 - Noch ein wenig anderer Style als heute (Quelle Waybackmachine)

Wie bereits im vorgegangen Abschnitt erklärt, wurde diese Version in einer ziemlich schnellen Aktion Mitte 2014 veröffentlicht, da die Joomla-Webseite einigen Sicherheitslücken ausgesetzt war. Begonnen hat die Entwicklung an der Drupal-basierten aber bereits im November 2012, mit dem Codename "P.E.N.I.S." (steht für "Planung und Entwicklung der neuen Internetseite") - ja, da haben sich einige wohl sehr ins Zeug gelegt, um dieses Akronym hinzubekommen.

Aber wieso wurde überhaupt Drupal gewählt? Wordpress war zu dieser Zeit zwar schon sehr viel weiter verbreitet, allerdings ist es deutlich schwieriger und unintuitiver, eigene Funktionen bei Wordpress hinzuzufügen. Es ist sehr viel mehr auf Plugins ausgelegt, die von vielen Wordpress-Nutzern verwendet werden können, als eigene Module zu schreiben.

Die Entwicklung wurde dabei großteils bei 1-2 wöchentlichen "Taskburningdays" unternommen, teilweise wurde dabei auch versucht, nach "Scrum" zu arbeiten, allerdings hat das nicht sehr lange durchgehalten. Scrum ist für Unternehmen eine super Sache, allerdings war bereits zu erwarten, dass das Prinzip für ehrenamtliche Arbeit nicht sehr gut funktionieren würde. Jede Person hat eine unterschiedliche Menge an Zeit, die aufgewandt werden kann, regelmäßige Treffen sind aufgrund der unterschiedlichen Stundenpläne und Freizeitgestaltung nicht wirklich möglich. Besonders die Daily Meetings, welche bei Scrum ein Gefühl von konstantem Fortschritt geben, fallen dabei komplett weg. Nichtsdestotrotz ging die Entwicklung ziemlich zügig voran und die Website stand nach etwa 1,5 Jahren soweit, dass der Wechsel von 2.0 zu 3.0 im Juli 2014 durchgeführt werden konnte. Dieser lief dabei auch sehr viel entspannter ab, da alle Inhalte mit Skripten übertragen werden konnten.

Die Architektur der Website war ziemlich ähnlich wie bei Joomla, mit eigenen Modulen für die Jobbörse, Terminkalender, und einigen Modulen der Drupal-Community wie dem Forum oder den Artikeln. Drupal selbst ist sehr viel auf dem Konzept der nodes ausgelegt. Jeder Inhalt auf der Webseite sollte eigentlich als Node erstellt sein, was es dann anderen Modulen erlaubt, diese beliebig zu erweitern. Allerdings wurde dieses Konzept nicht unbedingt so genutzt wie es eigentlich gedacht ist, wodurch es zu Einschränkungen in der Benutzbarkeit der Website kam. Beispielsweise werden Jobangebote nicht als Node erstellt, wodurch die integrierte Suche von Drupal nicht genutzt werden kann. Die fehlende Integration mit den Funktionen von Drupal rührt allerdings auch daher, dass die Einbindung der gewollten Funktionen beispielsweise der Jobbörse mit der Möglichkeit, Angebote zu reaktivieren oder ähnliches, viel Einarbeit in das Framework braucht, aber auch teilweise eine komische Verbindung zwischen Code Entwicklung und Admin interface besteht, da bei der Live-Website jederzeit neue Inhaltstypen erstellt oder bestehende angepasst werden können.

Das Projekt- und Entwicklungsmanagement allerdings hat einen großen Schub bekommen, da der Code nun in GitLab gespeichert und die Aufgaben mit Issues verteilt und dokumentiert wurden. Außerdem sind die einzelnen Module in einzelnen Repositories gespeichert und mit Git-Submodules im Haupt-Repository eingebunden, was die Übersicht deutlich erhöht hat. Das Deployment der Website wurde nun mit Jenkins automatisiert und vereinfacht. Auf dem Server wurden die Webseiten von Feki.de nun mit Proxmox und in einzelnen Virtuellen Maschinen organisiert.

Es wurden mit der Zeit nur wenige Änderungen an der Hauptseite gemacht, hauptsächlich waren die auf Bugfixes oder kleine (visuelle) Verbesserungen fokussiert. Die größte Umstellung passierte im September 2020, bei der eine komplett neue Serverarchitektur entwickelt wurde. Diese basiert nun auf Docker-Containern, die mit Docker Swarm organisiert werden statt virtuellen Maschinen. Im Laufe der Umstellung ist auch aufgefallen, dass die Organisation der verschiedenen Module nicht wirklich den best practices der Drupal Installation entsprechen, weswegen das Main Repository zu einem Composer Projekt umgestellt wurde, bei dem alle Module als Dependencies installiert werden. Dadurch konnten Updates der Offiziellen Module sehr viel einfacher gemacht werden. Die Website wird in GitLab CI/CD Pipelines zu einem Nginx und einem PHP Docker Image gebaut, welche im Anschluss automatisch deployed werden und Migrations automatisch ausgeführt. Die Downtime des Servers bei Updates geht dabei auf wenige Sekunden zurück.

Environments in GitLab

Im Zuge der Aktualisierung des Servers kamen dabei auch die Diskussionen zu einem Update der Website auf, da Drupal 7, wie schon im ersten Devlog erwähnt, bald nicht mehr unterstützt wird. Die erste Idee war, relativ wenig Aufwand zu betreiben und auf Drupal 8 zu updaten, nach genauerem Hinschauen viel aber recht schnell auf, dass dieser Aufwand ziemlich hoch werden würde da bisher kaum die best practices genutzt wurden, welche ab Drupal 8 stärker forciert werden. Danach begann die Suche nach Alternativen, wobei zuerst Django in Frage kam, da Python generell eine beliebte Programmiersprache ist. Letztendlich ist es aber die Kombination aus Strapi und Next.js geworden, die genaueren Hintergründe dazu findet ihr im ersten Devlog.

🕵️ Takeaways

Zusammenfassend kann man sagen, dass sich die Technologien für Websites mit der Zeit sehr stark verändert haben, dabei hat sich besonders viel vereinfacht und die Open-Source Community hat einen sehr starken Einfluss. Es ist ein großer Vorteil, dass die Entwicklung interaktiver Websites mittlerweile nur noch von dem eigenen Engagement und nicht vom Budget abhängt. Dass viel Engagement notwendig ist, zeigt sich aber bei uns besonders, da wir als ehrenamtlicher Verein komplett von intrinsischer Motivation abhängen. Die Konsequenz dabei zeigt sich stark darin, dass sich die Hauptfunktionen unserer Website schon seit mehr als 15 Jahren kaum verändert haben, obwohl sich in der Zeit natürlich sehr viel anderes getan hat. Das spiegelt sich leider auch in den Nutzern der Website dar, obwohl die Studierendenzahlen sich nicht allzu stark verändert haben.

Um diesen Umstand zu verbessern, haben wir uns für die kommende Website vorgenommen folgende Verbesserungen vorzunehmen, um unserem Vereinsziel (Förderung der Kommunikation zwischen Studierenden und der Studierendenhilfe) wieder näherzukommen.

1. Zentrale Funktion - Echtzeit Suche: Finde alle Inhalte der Website in kürzester Zeit und mit vielen Konfigurationen
2. Interaktion auf der Website fördern: Studiumsbereich erweitern, Bewertungs und Kommentaroptionen bei verschiedensten Inhalten
3. Bessere User Experience: Vereinfachung der Erstellung neuer und Verwaltung bestehender Inhalte durch Studierende oder Bamberger Unternehmen.
4. Anpassbarkeit: Passe dir die Startseite nach deinem Belieben an, damit du immer direkt über Dinge informiert bist, die dich interessieren
5. Neue Dienste: Viele Ideen für Dienste auf der Website stehen schon lange auf der Liste, konnten aber bisher noch nicht umgesetzt werden. Wir hoffen endlich, euch wieder mehr neue Dienste anbieten zu können
6. Einfacherer Einstieg in die Entwicklung: Damit wir alle unsere Ziele erreichen können, wollen wir die Entwicklung der Website so einfach gestalten wie nur möglich, damit auch Programmier-Neulinge leicht einsteigen können.

Damit wir all diese Ziele erreichen können, brauchen wir aber auch deine Unterstützung und Feedback! Egal ob du Interesse am Design, Programmieren, Projektmanagement oder Inhaltserstellung hast, du kannst mit uns gemeinsam das Studierendenleben in Bamberg bereichern, deine eigenen Ideen einbringen und auch viele Erfahrungen sammeln, die dir später im Berufsleben alle Türen öffnen!