ubuntuusers.de

Inyoka-Hackfest in Franken

ubuntuusers.png

Vom 18. bis 20. September fand ein Inyoka-Hacking-Wochenende statt, an dem sich um einige Baustellen von Inyoka gekümmert wurde.

Inyoka ist die Software, die ubuntuusers.de seit 2008 im Hintergrund antreibt. Vor knapp über einem Jahr erfolgte auf Ikhaya ein Aufruf, wer bei der Entwicklung von Inyoka mitmachen wolle. Das große Ziel des Open-Source-Releases ist immer noch nicht erreicht worden und bis es soweit ist, muss noch einiges erledigt werden. Aus diesem Grund trafen sich ein Teil des Teams im beschaulichen Oberfranken um einige Baustellen gemeinsam abzuarbeiten. Nach 2011 war es das zweite Inyoka-Hackfest, das jemals stattfand.

Das Produktive

inyoka_hackfest3.jpg
Fleißig und Konzentriert am Arbeiten…

Redis-Integration

Die größte Änderung, die an dem Wochenende implementiert wurde, ist die zukünftige Nutzung von Redis. Gegenwärtig liegen alle Elemente, wie z.B. Beiträge aus dem Forum oder Wiki-Artikel, welche die Inyoka Syntax verwenden, sowohl im Rohtext als auch im HTML Format in unserer MySQL-Datenbank. Durch die große Anzahl derartiger Einträge haben die entsprechenden Datenbanktabellen mittlerweile eine Größe erreicht, bei welcher Datenbank-Abfragen unnötig verzögert werden. Die ehemaligen Inyoka-Entwickler haben dieses Problem schon frühzeitig erkannt und daher memcached als Cache verwendet. Allerdings liegen die Daten unabhängig vom memcached nach wie vor noch in der Datenbank. Denn was im memcached ist, existiet nur im flüchtigen Arbeitsspeicher – ein Problem, welches wir mit Redis lösen möchten.

Durch die Migration von memached auf Redis werden auch alle Elemente im Cache einen Zeitstempel erhalten. Ist dieser abgelaufen, werden die entsprechenden Elemente neu gerendert und entsprechen so auch dem aktuellen Output unseres Parser. Neuere Designs für bereits bestehende Inhalte kommen so in den Bereich des möglichen; ein Wunsch den unsere Designer schon häufiger geäußert haben. Gleichzeitig haben wir so einen persistenten Cache, der auch nach einem Ausfall eines Servers schnell wieder verfügbar ist, um für unsere Anwender eine gute Performance zu erreichen.

Ein weiterer Vorteil dieser Lösung ist, dass unsere Datenbank deutlich kleiner wird, was die generelle Performance bei Datenbank-Abfragen verbessern sollte. In einem ersten Test schrumpfte ein SQL-Dump der produktiven Datenbank von circa 18GB auf 8,6GB. Dabei wurden die Tabellenschemas nicht geändert, sondern vorerst nur die Felder mit Platzhaltern befüllt. In der Folge kann die gesamte Datenbank zukünftig im Arbeitsspeicher gehalten werden. Die Integration wurde zwar schon implementiert, muss aber noch ausführlich getestet werden. Letzteres wird noch ein wenig Zeit in Anspruch nehmen.

Open-Source-Theme

Das Open-Source-Theme für Inyoka, welches im April 2015 öffentlich wurde, hat ebenfalls einige Änderungen erfahren. So wurden alte Baustellen geschlossen, neue erschaffen und einige Pull-Requests reviewed und gemergt. Als Konsequenz daraus gibt es jetzt etwa eine Portal-Seite, die nicht mehr leer ist, ordentliche Title-Tags in den Unterseiten, wegklickbare Meldungen des Portals und generelle Aufräumarbeiten. Alle Änderungen lassen sich auch im GitHub-Repository nachvollziehen.

Jenkins & kubuntu-de.org

Der Entwicklungsprozess von Inyoka sah bisher so aus, dass es eine Produktiv-Instanz gibt, die unter ubuntuusers.de läuft, und eine interne Staging-Umgebung, die auf dem aktuellen Entwicklungsbranch laufen. Letzterer musste immer manuell auf dem aktuellen Stand gebracht werden, was häufig vergessen wurde und dementsprechend nicht sinnvoll genutzt werden konnte. Mit dem Einsatz von Jenkins soll dieser Prozess automatisiert werden, da man nun bei neuen Commits im Repository ein Deployment durchführen kann. Ebenfalls ließen sich so bei jedem Pull-Request in den Themes und in Inyoka die Tests ausführen, um sicherzustellen, dass man nichts kaputt macht. Auch diese Arbeit wurde im Wesentlichen begonnen und wird in der nächsten Zeit nach und nach eingebunden.

Neben staging – einer VM mit Inyoka auf dem Entwicklungsstand – wurde eine weitere VM eingeführt, in der größere Änderungen getestet werden können, die noch nicht in staging enthalten sind. Diese VM beinhaltet dabei alle Forenbeiträge, Ikhaya-Artikel und Wiki-Artikel aus der Produktivdatenbank. Private Daten wurden hierfür vollständig gelöscht. Nebenbei wurde auch Sentry auf unsere Server-Infrastruktur umgezogen. Dort werden Server-Fehler von Inyoka erfasst und übersichtlich dargestellt.

Neben Inyoka, wurde auch für kubuntu-de.org gearbeitet, wo sich die deutsche Kubuntu-Community findet. Wie im Mai angekündigt ist einiges an Arbeit notwendig, um kubuntu-de.org auf die Server-Infrastruktur vom ubuntu Deutschland e.V. umzuziehen. Auch dieser Punkt wurde angegangen, um diese Baustelle schließen zu können.

Das Unproduktive

Der Hauptzweck des Treffens war zwar das produktive Arbeiten, doch auch das Unproduktive darf nicht fehlen. Neben dem Essen von zahlreichen Pizzen vor Ort, gab es auch noch ein Besuch im Restaurant, um den Hunger der fleißigen Programmierer zu stillen. Auch wurde etwas Bier, Mate und sogar Wasser getrunken. Auf eine statistische Aufbereitung der verschlungenen Ressourcen wurde natürlich nicht verzichtet:

  • 16 0.5L Flaschen Huppendorfer Bier, 3 Flaschen 0.33L Antla Bräu, 3 Flaschen 0.5L Günther Bräu Festbier

  • 13 Flaschen Club Mate

  • ~5L Coca Cola

  • ~10L Wasser mit und ~2L ohne Sprudel

  • ~10 Tiefkühlpizzen

  • 1 große Blechpizza mit diversen Zutaten

  • 4 Tiefkühlbaguettes

  • 1 Packung Snacks

  • 1 Packung Gummi Colafläschchen

  • 1 Mamorkuchen

  • 1.5 große Schüsseln Salat

Mitmachen

Die Arbeit von Inyoka geht zwar weiter voran, um es bald als Open-Source-Software veröffentlichen zu können, doch brauchen wir auch weiterhin Mithilfe. Die Informationen und Kenntnisse aus dem Aufruf zur Mitarbeit vom letzten Jahr sind weitestgehend aktuell und relevant. Wer also Zeit, Motivation und Lernbereitschaft mitbringt, ist weiterhin gerne gesehen.