Fiona & Rails an der Freie Universität Berlin

Transkript

1 Fiona & Rails an der Freie Universität Berlin Evaluation einer stufenweisen Migration auf Rails Mattis Neiling UG L&F, München 3./4. April 2008

2 Fiona & Rails: Old School vs. New School (1) Dynamische Seiten-Generierung statt statischem Export Neue Systemarchitektur (Hardware, Lizenzen, ) fully fledged Programmiersprache (Ruby on Rails) statt proprietärer <npsobj>-syntax Dynamische Websites mit CMS aus einem Guss (statt CMS+PM/Java+PHP+Perl ) Anbindung an CMS über den Infopark Rails Connector und außerdem wird Infopark langfristig den statischen Export ablösen (?!). 2

3 Fiona & Rails: Old School vs. New School (2) Old School vs. Rails: Die Freie Universität evaluiert eine stufenweise Migration. Abzuwägen bleiben funktionelle und architektonische Vor- und Nachteile. Migration der bestehenden Sites: Möglicher Zeitplan: Start mit Pilot-Website Sprachenzentrum Weitere Pilot-Websites und Applikationen (z.b. Kalender) Eigenes Plugin für Rails entwickeln Migration site by site 3

4 Domains & Konfigurierbarkeit im CMS Jede Domain ist eigenständige Website im CMS (ca. 50 Domains) Z.B. Eigener Layoutsatz, CSS etc. Leserecht der Redakteure auf diese Website beschränkt Interne Links nur innerhalb der Website => Jede Domain bekommt eigene Rails-App Konfiguration von Teilbereichen über custom-layouts Z.B. Home, Bildstreifen, Navigation, News- und Terminordner, => Konfigurationsobjekt(e) im CMS dafür anlegen Layoutanpassungen Einige spezielle Layouts, z.b. für spez. Vorlagen, Kalender, => Migration in Rails-Apps 4

5 Rails Prototyp Sprachenzentrum (1) Überschaubare Website statische Seiten ca Objekte 5 eigenständige Bereiche wenig Traffic (ca Pages/Day) & Umfangreiche Medienreferenzdatenbank über Objekte aufwändig beim Export (TE) 5

6 Rails Prototyp Sprachenzentrum (2) Migration der statischen Seiten Konfiguration: Pfad-basiert in der Rails-App (Kopfzeile, Bildstreifen, ) Dynamische Elemente: Navigation, Inhaltsbereich und rechte Seite Verschiedene Vorlagen-abhängige Views Inhalts-Layouts Erfahrungen Umsetzung einfacher als mit <npsobj>-syntax, schlanker Code Viele Requests an die NPS-Datenbank ( Requests für eine Html-Seite!) Antwortzeit 1-5s auf VM mit 1GB RAM Minimale Verbesserung durch Änderungen im CMS möglich (z.b. Navigation über Sortierschlüssel-Felder steuern) (Vorläufiger) Bottleneck ist Fiona DB-Schema/Rails Connector 6

7 Rails Prototyp Sprachenzentrum (3) Medienreferenzdatenbank Wie statische Seite, einige spezielle Views Listenansicht mittels geführter Suche Erfahrungen Umsetzung ist einfach Suche mit wenig Code eingebunden (derzeit PHP-Lösung) Antwortzeit/Performanz muss beim Entwickeln berücksichtigt werden Rails Connector ist stabil, aber langsam Migration? Realistisch, wenn der Rails Connector effizienter wird Performanzverbesserung mit Fiona erwartet (DB-Schema-Anpassung) 7

8 Erfahrungen und Offene Fragen Redaktionsabläufe müssen ggf. angepasst werden Inhaltsausgabe stärker an Vorlagen koppeln Konfiguration über Objekte/Felder statt Layouts Navigation über Sortierschlüssel (da object attributes) Es gibt keine einfachen Layoutanpassungen mehr Test-Environment für Fiona & Rails aufbauen Wie kann Caching sinnvoll genutzt werden? z.b. CMS Notification für Page-Cache-Bereinigung Hofstadters Gesetz: Du brauchst immer mehr Zeit, als du am Anfang annimmst, auch dann, wenn du Hofstadters Gesetz berücksichtigst. Die Migration zu Fiona & Rails ist in jedem Fall ein Neubeginn 8

9 Offene Fragen in der Diskussion mit Infopark Objektpfad in URL statt ID (insb. im Redaktionssystem!) (Wishlist Eintrag 11180) Mandantenfähigkeit, z.b. mehrere Rails-Apps an Fiona ankoppeln (Wishlist Eintrag 11184) Beachtung der Leserechte im Preview (Wishlist Eintrag 11187) Migrationssupport auf Rails (Wishlist Eintrag 11188) Unterstützung von Spiegelobjekten in Rails Kooperation / Integration von PM-Applikationen Performanz, Performanz und nochmals Performanz 9

10 Vielen Dank! Freie Universität Berlin Center für Digitale Systeme Ihnestrasse 24 Dr. Mattis Neiling 030 /