Das finde ich nämlich sehr spannend. Eine ganz kurzer Überblick. Wir sind im Herbst letzten Jahres auf DeSpace 7.3 umgestiegen. Wir gehen sehr iterativ vor. Wir haben also nicht gesagt, wir lösen alles vorher, sondern wir haben jetzt beinahe wöchentlich einen Release gemacht, wo wir immer Stück für Stück uns dem

annähern. Wir haben Updates auf 7.4 und 7.5 gemacht. Auch da zwischendrin integrieren wir die die Issues vom Offensors-Projekt. Tipps und Misses. Was hat gut funktioniert? Was war nervig? Die anfänglichen Sachen sind sehr einfach. Also die Daten, da ändert sich gar nichts. Die Datenbank, sofern sie nicht Änderungen haben,

migriert sich automatisch. Ich glaube, für Spezialfälle gibt es heute, ich mache noch einen Vortrag, wenn jemand die Datenbank stark abweicht. Formulare, da gibt es ein Tool in DeSpace 7, das zu migrieren. Das haben wir nicht genutzt. Wir haben manuell migriert, weil wir das zum Anlass genommen haben, das auch noch mal zu überarbeiten. Und wir haben uns dann mit ein paar selbstgeschriebenen

XSLT-Skrips beholfen. Migration von vorhandenen Anpassungen. Also wir hatten ein DeSpace 6, das zum Teil auch stark customisiert war. Das war anstrengender. Die Backend-Sache, das geht noch relativ einfach. Da hat sich nicht so viel geändert. Das Frontend muss man logischerweise

alles neu machen in Angular, womit wir auch bei Anpassungen der Benutzeroberfläche wären, mit Angular und Bootstrap. Das ist zwar eine Sache, wo man sich neu einarbeiten muss, das lohnt sich aber und macht eigentlich sehr gute Laune, weil, wenn man vorher viele von Ihnen vielleicht von der JSP-UI oder der XML-UI kommen, dann ist das das ist sehr gut. Man hat großen Spaß daran, damit zu arbeiten. Das

ist besser dokumentiert. Da kann man sich informieren. Das macht gute Laune. Wir sind also immer noch bei den Hits. Jetzt kommen wir zwei Misses. Anfangs und gibt es immer noch. Die Rest-Schnittstelle und die Angular-UI sind ja ganz neu und in dem Stadium finden sich natürlich noch viele Bugs.

Es nutzen noch nicht so viele Leute produktiv. Wir haben also sehr viele Bugs gefunden, die von unseren Nutzerinnen gemeldet wurden, die wir selber gefunden haben. Dann haben wir viele Issues auch geschrieben auf dem Source-Projekt. Viele dort wiedergefunden, unsere Probleme dort auch wiedergefunden, dass die auch andere schon hatten, haben dann viele Fixes getestet.

Und natürlich die Funktionalität war anfangs noch unvollständig. Das hat sich jetzt ziemlich verbessert mit dem 7.5-Release. Das ist eigentlich das erste, wo man sagen kann, jetzt ist das meiste abgedeckt und soll ja, wie wir gehört haben, mit 7.6 eigentlich vollendet werden, diese Sache. Jetzt kommen wir zu dem ersten großen Misses.

Die Performance war anfangs zu unserer großen Überraschung sehr, sehr schlecht. Ich habe jetzt mal hier auch unsere schlechten Daten publiziert. Das ist so ein Google-Speedtest. Links ist eine ganz frühe Version, die wir hatten. Da schneiden wir sehr schlecht ab. Jetzt ist die aktuelle. Da sind wir ein bisschen besser. Das ist, wenn das Ganze mal geladen ist und man also, man kann das bisschen differenzieren. Wenn man mal im Arbeiten ist, dann geht das relativ schnell.

Aber diese erste, diese erste Ladezeit von These Days, bis das einmal startet, das Angular, das ist sehr, das ist fast unzumutbar gewesen am Anfang. Jetzt ist es ein bisschen besser und ich erkläre gleich, warum. Das ist eigentlich, ich verrate unser Server-Setup, weil das sowas ist, was ich immer gerne bei anderen lese.

Wir haben ein relativ großes Backend und das andere dann haben wir ein bisschen schmaler aufgestellt. Backend, Datenbank, Solar, das läuft perfekt so und beim Frontend haben wir uns verschätzt. Weil unser erster Gedanke war so, das macht ja eigentlich nichts, außer JavaScript ausliefern und das stimmt nicht. Das ist also der einzige Server, der richtig viel arbeitet, ist das Frontend bei uns und das müssen wir mal noch erhöhen.

Und der Grund, warum das so, warum das so langsam war, findet sich in, das nennt sich Server-Side Rendering in diesem Angular Universal. Und was das macht, es liefert eben nicht nur JavaScript-Dateien aus, sondern das rendert das alles schon mal vorher und die These Days-Doku sagt, na das brauchen wir zur Search Engine Optimierung. Ob das ein guter Trade-Off war, weiß ich nicht.

Und dem kann man beikommen, indem man einfach mehrere Frontend-Instanzen macht. Wir machen jetzt vier, wir nutzen dieses vorgegebene Tool, dieses TM2-Node-Tool. Man kann aber natürlich, wenn man zum Beispiel mit Docker arbeitet, das auf Docker-Ebene machen.

Das hat einen großen Performance Boost gebracht, das lohnt sich auf jeden Fall. Ein weiteres Feature war, ein weiteres Problem war, wir haben festgestellt, dieses Main.js, das hier ausgeliefert wird, das ist gigantisch. Da sind viele Sachen drin, man kann das mit dem Fall so Tools dann auch mal sich ansehen und visualisieren lassen. Da sind viele Sachen drin, die gar nicht gebraucht werden. Da komme ich gleich nochmal drauf und dann kann man natürlich mit Caching-Abhilfe schaffen.

Die einfache Sache ist, auf der Proxy-Ebene zu caching mit Apache oder Nginx, das klappt schon mal und ist ein gewisser Gewinn. Und jetzt mit Angular 7.5 gibt es so auf Angular-Ebenen ein Cache, da fanden wir die Ergebnisse mittelmäßig. Und zwar, das liegt auch daran, dass es eben mehrere Frontend-Instanzen gibt und der Cache ist dann jeweils auf der einzelnen Instanz.

Deswegen ist der Effekt so ein bisschen geschmälert. Wenn Sie den Cache auf der Einfrage an Instanz 1 stellen und die nächste kommt auf Instanz 2, dann ist der Cache da gar nicht vorhanden. Insofern haben wir da nicht so den großen Gewinn davon messen können. Ich habe mir das illustriert, dieses Main.js, das war am Anfang gigantisch in 7.4, das waren so 4,5 MB.

Und wir haben dann tatsächlich, da kommen wir jetzt zu dieser Deep Space Community, das passt halb weg, er hat mich mal eingeladen, diesem Deep Space Developer Meeting teilzunehmen. Das ist öffentlich, da kann jeder teilnehmen und das kann ich auch sehr empfehlen, das ist sehr spannend.

Und wir haben das dann mal da vorgebracht, dieses Problem und das ist da diskutiert worden und das ist tatsächlich, die haben das auch anerkannt und haben an Lösungswegen gearbeitet und im Laufe der Zeit sieht man, das hat sich fast halbiert. Man hat viel unnützem Code rausgeworfen, man hat auch ein paar architektonische Veränderungen gemacht. Das ist jetzt nur so ein Beispiel, wie das tatsächlich kleiner geworden ist und dadurch auch ein bisschen haben wir an Geschwindigkeit gewonnen.

Jetzt haben wir ein zweites Thema, das ist jetzt ein direktes Entwicklungsthema, im Anschluss kommen auch noch zwei rein konzeptuelle Themen. Das ist so ein bisschen, wo bringen wir unseren eigenen Code unter? Das ist so die Frage, wir machen viele Anpassungen, wo machen wir diese Anpassungen?

Wie lesen wir nachher unsere eigenen, also wie finden wir das wieder, was wir eigentlich gemacht haben im Vergleich zu dem, was vom Open Source Projekt kam und wie mercht man effizient das Open Source Projekt? Das ist auch ein großes Thema, aber das macht man relativ häufig, vielleicht wird das später, wenn das Projekt wieder ein bisschen ruhiger wird, nicht ganz so häufig, aber im Moment haben wir das sehr oft gemacht. Und die vorgegebene Antwort von DeSpace war so ein bisschen, da im Frontend,

nutzt doch bitte die Seams und im Backend nutzt diese Maven Overlay Module. Und das ist erstmal eine verständliche Antwort, also verständlich, warum man auf diese Idee kommt. Wir fanden das aber relativ untraktisch dann, weil wenn man dann das Open Source Projekt reinmertscht,

dann mertscht das natürlich ohne irgendwelche Konflikte, weil man hat ja nichts geändert an den Pfeils und nachher muss ich Hand für Stück für Stück jedes Pfeil durchgehen und gucken, habe ich an dem vielleicht geändert, muss ich dann diese Änderung in meinen überlagerten Pfeils oder in meinen Seam übernehmen, das fanden wir extrem untraktisch. Und wir sind dann dazu übergegangen, das einfach direkt auf den Original Pfeils zu machen.

Wir sind also, wir haben im Backend einfach im normalen Source Code geändert, wir haben im Frontend das Seam ganz minimal gemacht und haben das meiste in den Original Dateien überschrieben. Und jetzt die Frage ja, wie finde ich denn dann noch, was ich gemacht habe? Das Lesen ist auch einfach, weil man einfach dieses SkipDiff Tool nutzen kann. Ich weiß nicht, viele kennen das vielleicht sowieso schon.

Man kann einfach die Differenzen zwischen dem Upstream, das ist jetzt bei uns der Main Branch und unser Deposit Ones Def Branch, hier können wir mal die Short Statistics, da sieht man mal, wie viel wir geändert haben, die Anzahl der Dateien und der Zeilen, das ist nicht alles Programmcode, das wir geschrieben haben, vieles ist auch Konfigurationscode.

Und dann kann man sich das einfach mit Name Only, bekommt man eine Liste der Dateien, sieht man also das, was man sonst gehabt hätte, wenn man das in irgendwelche überlagerten Verzeichnisse im Datei-System gesehen hätte, sieht man so ganz einfach, man kann das ein bisschen, sich ein kompaktes Summary anzeigen lassen, dann sieht man noch, was ist in das Datei, die haben wir neu hinzugefügt, wie viele Zeilen haben wir hinzugefügt gelöscht.

Das war so ein bisschen die Entscheidung, die wir getroffen haben, dass wir nicht diese Mechanismen nutzen, sondern einfach direkt im Open Source Code arbeiten und das hält sich sehr bewährt, gerade wenn man oft das Open Source Projekt merken will. Und jetzt komme ich zu zwei konzeptuellen Themen und das eine ist schon zweimal aufgekommen heute in dem Vortrag von Werte Reisigant am Anfang und jetzt in dem Vortrag von Stefan Elig.

Wie bringt man eigentlich Features im Open Source Projekt unter? Und das würde mich auch interessieren, wie das andere machen. Wir haben für zwei Features bezahlt, also das haben wir nicht selber gemacht, sondern wir haben den Library Code in dem Fall beauftragt. Zwei Sachen, die uns abgegangen sind am Anfang, war das Typeface Submission Form

und war die Tablettenkontrolle. Und das hat einmal sehr gut funktioniert und einmal mäßig gut. Das liegt nicht an der Codearbeit, sondern das liegt an dem, kam das Open Source Projekt an oder nicht. Und also ein Grund, warum das erste gut ankam, ist das Typeface Submission Form. Das war was, das gab es schon in Deep Space 6 und deswegen wurde das auch prioritär behandelt.

Und die Tablettenkontrolle, die gab es so nicht offiziell und die ist so ein bisschen im Review-Prozess gestrandet und hat keine Reviewerinnen gefunden und ist immer noch nicht integriert und ist jetzt gerade so auf Deep Space 8 verschoben worden. Und ich habe da ein bisschen im Nachgang mit dem Tim Donahue gechattet und mir mal erklären lassen,

was macht man eigentlich, um Sachen unterzubringen. Ich lese das jetzt nicht vor, die Sache ist, man sucht im Vorfeld die Diskussion entweder in diesem Entwicklertreffen, das ich also empfehlen kann, wo ich jetzt öfter teilgenommen habe. Es gibt auch noch dieses Decat Meeting, das mir nicht so bekannt ist und auch noch dieses Searing Group.

Ich weiß nicht, inwieweit die anderen Meetings offen sind. Also das Developer Meeting ist auf jeden Fall offen, die anderen sind auch. Decat ist offen, Searing ist nicht offen, genau. Und das würde mich vielleicht als Diskussion nachher interessieren, ob da andere von euch die Diskussion gesucht haben in diesen Foren oder wie es euch geht mit Unterbringern von Features im Open Source Projekt.

Weil man will ja, außer es ist so eine Spezialsache, nicht die Sachen nur im eigenen Refo haben, sondern auch einmal um was zur Community beizutragen, aber natürlich anders auch als Eigennutz. Ich will das nicht immer nur alleine pflegen, sondern ich will, dass das von der Community auch mitgepflegt wird. Also durchaus auch eigennützig das im Open Source Projekt unterzubringen.

Und jetzt habe ich keinen Plan mit der Zeit. Ist das noch gut in der Zeit? Und jetzt ist es? Ich habe keine Uhr irgendwie. Okay, wunderbar. Genau, ein letztes konzeptuelles Thema sind die Entities. Das würde mich auch interessieren, wie das andere Einrichtungen umsetzen.

Ich habe mein Fragezeichen versehen. Wir haben das uns bisher nur angeguckt. Wir haben das noch nicht umgesetzt, aber wir haben ein paar Demos selber aufgesetzt und das ausprobiert. Die tolle Sache ist erstmal, dass ermöglicht es, unsere Domain natürlich viel besser abzubilden. Aber wir verkaufen es uns mit einem großen Zuwachs an Komplexität.

Einmal im technischen Betrieb für die Entwicklung und den Betrieb, aber dann auch für die Redaktion im Haus und auch für die Komplizierenden, die was einreichen wollen. Die Implementierung ist im Moment noch relativ unvollständig und fehleranfällig. Also wir haben einige Probleme gefunden. Es ist noch nicht alles da, was man sucht. Und wir testen das sehr zurückhaltend, Schritt für Schritt einzuführen.

Also mit der Orkid-Integration muss man eigentlich fast die Personen einführen. Und das ist auch etwas, wo ich den Gewinn am ehesten sehe. Und dann gucken wir Zeitschriften und Schriften rein, Research Funding, Zeitschriften und Schriften rein. Das ist eigentlich eine einfache Sache. Da hat man eine Zeitschrift und eine Ausgabe und einen Jahrgang vielleicht.

Wir haben dann uns angeguckt, was es tatsächlich gibt in unseren Repositorien. Und so einfach ist das dann gar nicht. Das ist dann auch noch etwas, was ich ganz gerne interessieren würde, wie andere das sehen. Und dann bin ich eigentlich schon durch mit meiner gemischten Thementüte.

Und ich kann entweder Fragen entgegennehmen oder ich stelle Fragen, wie andere das mit dem integrieren in der Community machen.