Entwickler-Interview: Waldissen

Dieses Interview soll einen kleinen Einblick in unseren Arbeitsalltag und in den Projektverlauf aus Sicht des Software-Entwicklers gewähren. In diesem Fall wurde Kevin Meckl interviewt.

Mein Name ist Kevin Meckl, ich bin Senior Developer bei der zdreicom GmbH in Köln. Seit über 10 Jahren beschäftige ich mich mit der Entwicklung von PHP-Anwendungen, TYPO3 und eCommerce-Systemen.

Der Projektmanager hat das Projekt intern mit einem Kick-off Meeting gestartet und hat uns entsprechend gebrieft: das Problem war soweit bekannt. Problemfelder lagen in der alten Technik der Homepage und den verschiedenen Datenbanken, aus denen wir die Inhalte entnehmen mussten. Hauptaufgabe war die Umsetzung des alten Internetauftritts und der Migration der Inhalte in das TYPO3 CMS. Der alte Internetauftritt war in einem eher unbekannten CMS umgesetzt. Die Datenmigration haben wir so umgesetzt, dass sie im damaligen Live-Betrieb jederzeit angestoßen werden konnte.

1. Die wirklich aufwendige Datenmigration – allein schon wegen der vielen unterschiedlichen Datenquellen.
2. Die Konzeption der Datenbankparameter (einfaches Beispiel Sprache) und der Filterfunktion.
3. Die Verwendung der Solr-Suche. Grundsätzlich haben wir sie schon häufiger eingesetzt, aber die Datenindizierung und die Übergabe an das Frontend per JSON API war konzeptionell schon anspruchsvoll.

• Neu-Installation des TYPO3-Systems
• Extension-Entwicklung (Solr)
• Datenmigration
• Benutzerbereich
• Frontend-Umsetzung

Aufgrund der Größe des Projektes und der vielen Beteiligten war verhältnismäßig viel Kommunikation notwendig. Insbesondere fand auch eine enge Zusammenarbeit mit den Frontend-Entwicklern statt. Die Kommunikation und Abstimmungsprozesse liefen gut und reibungslos. Wir nutzen für das Projektmanagement und die Kommunikation GitLab, das hilft uns auch sehr. Die Gespräche mit dem Kunden hat meist der Projektmanager geführt.

Es gab schon eine große Herausforderung – die vielen verschiedenen Datenquellen, aus denen Inhalte migriert werden mussten. Aber diese „Schwierigkeiten“ waren im Vorfeld bekannt.

Zwei Dinge:

1. Die Umsetzung in einem großen Projektteam, die parallele Zusammenarbeit und die gemeinsamen Besprechungen.
2. Die vorherige Seite war gefühlt aus den 90ern/Anfang 2000ern, da Sie aufgrund der enormen Datenmenge lange nicht angepackt wurde. Jetzt ist die Seite state of the art.

Wir haben zusätzlich Push-Notifications umgesetzt. Der Seitenbesucher muss dem Erhalt der Notifications zustimmen. Das geht nun über ein Backend-Modul.

Ja, das stimmt, geringe Ladezeiten erreicht man unter anderem durch das Cashing von Inhalten. Soll die Seite aber stets aktuelle oder nutzerspezifische Inhalte liefern, kann nicht der gesamt Content gecasht werden. Wir haben die Webseite so umgesetzt, dass das Grundgerüst und die Inhalte der Seite gecasht werden, die individuellen Nutzerdaten wie zum Beispiel die Suchanfrage oder Bewertungen werden hingegen live geladen. Das halte ich für eine super Lösung.

Es gab verschiedene Datenquellen, z.B. die der Artikel und Nutzer. Das Auslesen der Artikeldaten haben wir mittels html parsing umgesetzt. Die Nutzerdaten haben wir aus einer PostgreSQL Datenbank in die neue MySQL Datenbank überführt. Dazu war ein dreistufiger Prozess notwendig. Als erstes habe ich die Datenbank hochgefahren und habe den Server lokal aufgesetzt. Dann mussten die Daten in den Feldern ausgelesen und in eine temporäre MySQL überführt werden. Zuletzt haben wir die neuen Datensätze erzeugt und in die finale MySQL Datenbank geschrieben.

Ja, genau. Es handelt sich um eine Open Source Volltextsuchtechnologie, die recht weit verbreitet ist. Wir haben sie als TYPO3-Extension eingebunden. Das Spannende daran war das Zusammenspiel verschiedener Komponenten. Wir mussten konfigurieren, welche Datensätze eingelesen und indiziert werden sollen. Per HTTP-Request werden die Parameter dann an den externen Solr-Service weitergegeben. Letztendlich haben wir  noch den Umbau in JSON-API zur Frontend-Darstellung der Ergebnisse umgesetzt.

Über einen intelligenten Filter. Für den Filter-Algorithmus mussten wir  unterschiedliche Datenbankparameter festlegen. Hier haben wir  uns natürlich an den alten Parametern orientiert. Wir haben aber die Fülle an Parametern verschlankt und geclustert. Ich würde sagen, dass die wichtigsten Parameter die Themen, Zielgruppen und Dokumententypen waren, die wir als Hauptkategorien definiert haben.

Ja, genau. Wir haben eine Mappingtabelle erstellt, die der Kunde als Excel-Tabelle bekommen hat. So konnten wir gemeinsam die neuen Parameter festlegen. Die automatische Zuordnung der alten Parameter zu den neuen Parametern habe ich dann mittels Scripts umgesetzt.

Ja, wir haben die Seite auch als PWA (Progressive Web App) umgesetzt. Wenn der Nutzer zustimmt, bekommt die Seite ein Icon auf dem Screen des Smartphones – wie bei einer App. Daten der Seite werden lokal zwischengespeichert, so dass der Nutzer auch offline auf die Seite zugreifen kann. Da die Seite responsiv ist, funktioniert das sehr gut.

Das Interview führte Dr. Christoph Reintjes, Head of Business Development & Sales der zdreicom GmbH.