Ich programmiere weiter fleißig am Online-Portal von EnjoyWork und madiko. Vor zwei Wochen war es mir gelungen, die ersten Versionen meiner REDAXO-AddOns Indexierung und News fertigzustellen. Damit bin ich nun in der Lage, Daten strukturiert in die Datenbank zu schreiben.

Aktueller Schritt ist, mit den eingegebenen Werten weiterzuarbeiten. Konkret geht es mir darum, dass Redakteur:innen über ein Modul die Ausgabe von News mithilfe der zum jeweils hinterlegten Artikel und in der Indexierung ablegten Informationen steuern können.

Eingabe-Logik für Redakteure
bei der Auswahl von News

So sollen natürlich erst einmal nur die News angezeigt werden, die mit “online” markiert sind und das Veröffentlichungsdatum erreicht haben. Auf diese Weise gehen Nachrichten automatisiert online, die vorbereitet wurden. Beziehungsweise werden Meldungen ausgeblendet, die als offline kenntlich gemacht sind.

Dabei folge ich dem inzwischen allgemein zu beobachtenden Standard, dass – anders als in Social Media – auf Internetseiten neueste News oben bzw. am Anfang der Leserichtung im europäischen Raum stehen. Es ist denkbar, auch das von Redakteur:innen steuern zu lassen. Ich verzichte in meiner Programmierung bewusst darauf und gebe das vor. Sollte sich zukünftig ein anderer Trend herauskristallisieren, ist es leicht, das zu ergänzen.

Zudem soll es möglich sein, über das News-Redaktionsmodul zu steuern, welche News aus der Datenbank ausgegeben werden:

• in beschränkter Zahl der Nachrichten (z. B. nur die neusten 3/6/12… oder eben alle),
• News eines spezifischen Typs (z. B. nur Interviews, Fachbeiträge, Blogbeiträge usw.),
• News zu einem gewählten Thema (z. B. Blogbeiträge “Aus der Werkstatt” oder Fachbeiträge zu “Biodiversität” oder einem anderen über die Indexierung vorgegebenen Themenfeld),
• und alle Spielarten in Kombination natürlich…

Das Ganze wird um Fragen zum Design im Frontend ergänzt – also das, was Nutzer:innen des Portals sehen –, beispielsweise

• ob die einzelnen Meldungen als Karte, als Liste oder oder oder dargestellt werden…
• welche Details die Übersicht enthält, ergo ob sie – neben Überschrift und Datum der Veröffentlichung – das Foto, einen Anreißer-Text, die Autor:innen usw. anzeigt,
• ob die Fotos in Graustufen umgewandelt werden,
• wie viele News auf kleinen / mittleren / großen Displays jeweils pro Zeile angezeigt werden.

HEUREKA!
Ein großer Meilenstein ist gemeistert

Diese Vorüberlegungen verdeutlichen die Komplexität der Software-Entwicklung. Es ist an sehr viel zu denken. Alles spielt ineinander und muss von mir in eine logische Reihenfolge zum Abarbeiten in der Applikation gebracht werden. Dabei handelt es sich für die Programmierung des EnjoyWork-Portals noch um eine der leichteren Herausforderungen ;-)

Am Donnerstag gelang es mir dann erstmals, eine Eingabe-Maske für Redakteur:innen so zu programmieren, dass auf die über die AddOns angelegten Datenbank-Tabellen, die -Felder und Datensätze zugegriffen wird. HEUREKA! Was für ein grandioser Erfolg. Ich kann es noch immer nicht glauben. Darauf habe ich so lange schon hingearbeitet.

Den Freitag nutzte ich, um das, was ich als Code-Snippet erarbeitet hatte, auf alle Elemente für die Eingabe-Maske zu übertragen. Fleißarbeit, die hohe Konzentration erfordert. Ich nutzte es zugleich als Übung, die Aufgabe neun Mal zu wiederholen. Damit erhoffe ich mir, dass sich der Ansatz festigt. Spickeln war erlaubt.

Am Freitag Abend konnte ich dann hoch zufrieden aufs Werk der Woche blicken: Wieder ein großer, wichtiger Meilenstein gemeistert auf dem langen Weg zur Online-Plattform von EnjoyWork.

Was waren dabei die Herausfordernungen und wie löste ich sie?

REDAXO Modul “News”:
Eingabe-Maske für Redakteur:innen
im Backend

Das Redaktionsmodul baute ich so auf, dass es “mitlernt” mit den von Redakteur:innen via der AddOns eingegebenen Daten. Die Kunst war, mit der Eingabe-Maske für die Redakteur:innen sowohl auf die Datenbank-Struktur (Tabellen und Spalten) als auch auf die Datensätze zuzugreifen – und das Formular für sie dynamisch zu gestalten.

Dabei war mir wichtig, einen effizienten Ablauf und ein intuitiv zu bedienenden Fragebogen zu programmieren. Dass ich selbst seit vielen Jahrzehnten Redakteurin bin, ist hierbei von enormem Vorteil. Ich kenne die nervtötenden Applikationen von anderen und wusste, worauf ich achten musste. Meine Herausforderung war, meinem hohen Anspruch technologisch gerecht zu werden. Ich bin total glücklich, dass mir das im Modul sogar besser gelungen ist als in den AddOns.*

[ * Letztere hoffe ich nachziehen zu können. Mal schauen, wann ich das JavaScript, das dafür nötig ist, eingebaut bzw. aktiviert bekomme. Da fehlt mir ein Trick, den ich noch nicht durchschaue. Irgendein Zufall wird das sicher auflösen, wenn ich nicht damit rechne. ]

Soweit sinnvoll haben Redakteur:innen im News-Modul gleichwohl die Chance, über das Formular neue Datensätze für die Indexierung anzulegen. Sie müssen dafür nicht ins jeweilige AddOn wechseln, wenn sie dies nicht möchten. So ermögliche ich ihnen, dass sie Daten eingeben, sobald sie im individuellen Arbeitsablauf notwendig werden.

Mithin bleiben sie in ihrem Arbeitsmodus nahe an ihren Bedürfnissen. Das System zwingt sie nicht zu einem Prozess, sondern passt sich flexibel ihren Entscheidungsprozessen an. Sie können ihre Aufgaben im Mono-Tasking fokussiert auf den jeweiligen Arbeitsschritt erledigten. Oder simultan in einem Rutsch.

Ein tief humanistisch-aufgeklärter Ansatz für die Software-Entwicklung also und zentrales Element meiner Hacking-Ethik. Ein Teil der Programmierung, auf den ich stolz bin (sagte sie in aller Bescheidenheit).

Für das Programmieren einer solchen bedienerfreundlichen Eingabe-Maske bringt das eigene Herausforderungen mitsich. Mit YForm habe ich als REDAXO-Entwicklerin ein sehr mächtiges Werkzeug. Doch genau das war die Herausforderung: Zu lernen, wie ich es sinnvoll und effektiv im Backend einsetze.

In meiner ersten Version der Eingabe-Maske baute ich komplett auf mySQL/PHP-Code und Elementen von MForm (einem weiteren kleveren Developer-AddOn von REDAXO). Dabei stieß ich auf ein für mich unlösbares Problem. Ich wandte mich in unserem REX-Slack an die Community. Binnen weniger Minuten bekam ich einen genialen Tipp, der einen anderen Ansatz für die Umsetzung meiner Aufgabe wählte. Also noch einmal zurück auf Anfang und alles mehr oder weniger komplett neu programmieren. Einschließlich der iterativen Prozesse, mit denen ich gelernt habe, die Software nach und nach zusammenzubauen.

Ein Umweg, der sich gelohnt hat. Mein Code ist nun nicht nur deutlich schlanker, er ist zukunftsrobuster und update-sicher, wenn ich beispielsweise später auf PHP 8 umstelle. Zudem wird es einfacher, Weiterentwicklungen im Modul einzubauen, ohne an zu viele Stellen im Quellcode Hand anlegen zu müssen.

Meine Frage hatte zahlreiche Antworten und eine rege Diskussion ausgelöst. Unter anderem wurde mir ins Gewissen geredet, meine Progrämmchen in noch kleinere Häppchen aufzuteilen. Weiterhin wurde mir geraten, meinen Quellcode noch detaillierter zu dokumentieren, als ich es ohnehin schon getan hatte.

Den Zusatznutzen von kleinteiligen, gut dokumentierten Code-Snippets habe ich früh erkannt: Es erleichtert zukünftige Anpassungen. Mal ganz davon abgesehen, dass ich mir für die eigene Programmierarbeit das Handwerk erleichtere. Programm-Schnipsel lassen sich schneller erfassen und somit einfacher remixen und für Neues / Erweiterungen adaptieren.

Davon profitiere ich schlussendlich sogar bei Rückfragen. Auch anderen Entwickler:innen fällt es sehr viel leichter, mir im Coding weiterzuhelfen, wenn ihr Aufwand klein ist, meine Aufgabenstellung und das Progrämmchen zu durchschauen – und das Problem zu erkennen. Die Wahrscheinlichkeit, eine Antwort zu erhalten, die mich direkt weiterbringt (ohne mein Problem noch einmal umständlich erklären zu müssen), steigt also immens. Das ist essentiell für “Open Source”-Projekte und nicht zu unterschätzen!

Übrigens ebenfalls ein guter Grund für Software-Entwickler:innen, sich in Open Source Projekten zu engagieren. Da schlummert ein enormes Verbesserungspotenzial und eine steile Lernkurve.

Bei allen Schwierigkeiten, mit denen ich zu kämpfen habe, fand ich unverhofft einen Lichtblick: Mir wurde aus der REX-Community zurückgemeldet, dass die Qualität meines Codes gut ist und ich inzwischen Maßstäbe für andere setzen kann. Wow! Was für ein schönes Kompliment. Eines das mich besonders freut, da es von Menschen kommt, die ich für ihre Fachkenntnisse und Expertise schätze. Danke! Ihr ahnt nicht, wie mich das in den letzten Tagen durch die schwierigen Phasen getragen und motiviert hat, nicht aufzugeben und weiter an mich zu glauben.

Was mich zurück zur Aufgabe bringt. Beim Umsetzen der Tipps fielen mir eine ganze Reihe Dinge auf, die ich in der AddOn-Programmierung verbessern kann. Beispielsweise feilte ich an einer Vervollkommnung der relationalen Tabellen und der Integration meiner beiden AddOns. Die logische Verknüpfung zweier Datenbank-Tabellen und der darin enthaltenen Datensätze ist kein Hexenwerk. Knifflig ist die Logik im Aufbau der Datenbank-Struktur, die ich vorab leisten musste und die mir hier noch einmal Denksport abverlangte.

Ich habe den Anspruch, ein schlankes System aufzubauen. Das dient einem kleinen digitalen wie nachhaltigen Fußabdruck. Gleichwohl war ich wohl zu “lean” unterwegs und musste “anbauen”. Also sprang ich in der Software-Entwicklung wiederholt zwischen Programmieren des Moduls und Weiterentwickeln der AddOns hin und zurück.

In diesem Prozess wiederum kommt es vor, dass ich an Grenzen stoße – an Grenzen der eigenen Fähigkeiten und zuweilen an Grenzen des Systems. Diese Erkenntnis war ausgesprochen lustig. Bug or Feature? Über meine Fragen im Slack habe ich für die Entwicklung von REDAXO wohl auch den ein oder anderen Impuls gesetzt in den letzten Wochen. :-)) Eine ebenfalls neue Erfahrung für mich. Ich habe quasi ein höheres Level aufgeschaltet. Das gilt es mit zu verarbeiten in meiner Reflexion, was gerade alles passiert und sich emergent entwickelt. Faszinierend!

Ich zählte die Iterationen im Entwicklungsprozess nicht mit. Vermutlich waren es an die 300… Denn in GitHub stehen für die letzten zwei Wochen allein schon 64 commits – und das sind ja nur die, die ich als erfolgreiche Weiterentwicklungen einstufte. Der Teufel steckt im Detail. Meine Lernkurve ist steil. Gleichzeitig empfinde ich den Prozess weiter als zäh und extrem kräftezehrend. Umso wichtiger, die Erfolge zu feiern!

Ausblick & nächster Schritt

Für die Kalenderwoche 28 stand auf dem Programm: Auslesen und sinnvoll Ausgeben der Ergebnisse der Eingabe im Backend. Also das, was Redakteur:innen im Content Management System angezeigt wird und sie in der Pflege der Seite unterstützt – was sich in diesem Fall fundamental von einem “What you see is what you get” (WYSIWYG) unterscheidet.

Meine Idee beim News-Modul ist, dass Redakteur:innen auf einen Blick erfassen können, was sie in die Eingabe-Maske eintrugen – ohne in den Bearbeitungsmodus des Moduls gehen zu müssen. Das erfordert, dass die Datenbank-Einträge aus den diversen Quellen ausgelesen, zusammengesetzt und aus Maschinensprache “zurückübersetzt” werden in für Menschen verständlichen, sinnvollen Text.

Dazu dann mehr im Bericht “Aus der Werkstatt [ KW28 ]”.

Die gewonnene Zeit investiere ich in Bücher. Ich lese zurzeit “Zeitwohlstand für alle” von Stefan Boes – ein großartiges Buch. Dazu spätestens im Herbst mehr.