Rudeltippen – Tippspiel für die WM 2014

Anfang 2012 hab ich begonnen aus der Not heraus ein eigenes Fußball-Tippspiel umzusetzen: Rudeltippen – Ein Tippspiel auf Basis des Play Framework und Twitter Bootstrap.

rudelscreen

In den letzten zwei Jahren habe ich die Idee immer wieder weiter entwickelt und das Projekt als meine persönliche Fortbildung in Sachen Web-Entwicklung genutzt: Page-Loading Optimierung, Caching, Web-APIs, Proxy-Server Tuning, etc. Alles, was einem bei der heutigen Web-Entwicklung über den Weg läuft, habe ich im Rahmen der Weiterentwicklung einmal angefasst. Heute, habe ich die Version 2.2.0 veröffentlicht. Mit an Board, alles Notwendige für die WM 2014.

rudelscreen-2

Mit dem Sprung von Version 2.0.0 auf 2.2.0 war hauptsächlich ein Frontend-Update verbunden. Die alte Version lief noch auf Twitter Bootstrap 2 und ich wollte vor allem den Mobile First Ansatz von Twitter Bootstrap 3 in Rudeltippen einziehen lassen.

Rudeltippen steht zum freien Download auf GitHub zur Verfügung.

Warum man Assets ohne Protokoll ausliefern sollte

Ein bekanntes Problem beim Arbeiten mit assets ist die unterschiedliche Auslieferung via HTTP (http://) bzw. HTTPS (https://). Schon die kleinste Mischung führt zum Browserfehler und zeigt im Zweifel im Browser an, dass die Verschlüsselung nicht durchgängig ist. Will man nicht. Die Lösung für das Problem ist einfach – Assets sollten ohne Angabe des Protokoll ausgeliefert werden.

Aus

wird dann

Der größte Vorteil daran ist, dass der Browser die Assets nun automatisch mit dem Protokoll aufruft, mit dem die Webseite aufgerufen wurde.

Schaut man sich einmal ein CDN wie BootstrapCDN an, so bekommt man dort eine entsprechende URL bereits standardmäßig.

via

UPDATE
Wie auch im verlinkten Quellartikel erwähnt, hat mich Jens gerade via Twitter auf Probleme bei der lokalen Bearbeitung hingewiesen.

Jens hat natürlich recht. Für die lokale Bearbeitung ohne Webserver ist das Fehlen eines Protokolls für die Assets natürlich eher suboptimal.

Batch-Verarbeitung von Hibernate beschleunigen mit flush und clear

Vor kurzem musste ich einige Text-Dateien auslesen und den Inhalt via Hibernate in eine MySQL-Datenbank schreiben. Relativ einfache Sache, möchte man denken: Datei auslesen, die einzelnen Zeilen verarbeiten und persistieren. In Summe handelte es sich um ca. 38.000 Zeilen mit relativ einfach strukturiertem Inhalt. Der komplette Import-Prozess war schnell geschrieben, brauchte aber relativ lange bis alle Zeilen in der Datenbank gespeichert warten. Um genau sein, braucht der komplette Prozess rund 5 Minuten. Für drei Text-Dateien mit wenig Inhalt war dies definitiv zu lange. Eine erste Analyse der SQL-Statements brachte keine neuen Informationen, außer das der Prozess für die ganzen Statements wirklich 5 Minuten braucht.

Die Hibernate-Dokumentation brachte nicht nur die Lösung, sondern auch gleich das Problem zum Vorschein: You’re doing it wrong! Gleich im ersten Satz findet man den Hinweis, dass man Mist gebaut hat.

Der gezeigte Code wird im Zweifel zu einer OutOfMemoryException oder zu einer sehr sehr schlechten Performance führen. Und irgendwie sah das genauso aus, wie der Bockmist, den ich erstellt hatte.

Warum ist das so und wie kann man es besser machen?
Hibernate speichert neue Entitäten zunächst im First-Level bzw. Session- Cache zwischen. Den First-Level Cache müssen alle Anfragen an Hibernate durchlaufen, er ist obligatorisch. Innerhalb dieses Caches hält Hibernate die Objekte unter seiner Obhut, bevor es diese in die Datenbank commited. Nun ist der Cache an dieser Stelle nicht besonders groß – was er auch gar nicht sein muss – und kann nur wenige Inhalte aufnehmen. Bevor Hibernate im obigen Beispiel auch nur eine Entität an die Datenbank weiter gegeben hat, fängt es an im Speicher aufzuräumen, bis letztendlich kein Platz mehr vorhanden ist. Dieses “Aufräumen” führt letztendlich zu einem großen Performanceverlust.

Hibernate bietet nun mehrere Möglichkeit wie man die Batch-Verarbeitung beschleunigen kann, oder besser gesagt, wie man sie richtig macht. Die erste Variante ist die Definition der Batch-Size bzw. des JDBC-Batching.

Mit dieser Option erzwingt man einen commit bei einer bestimmten Anzahl von Entitäten. Beim Erreichen des Schwellwerts wird ein flush und clear ausgeführt.

Eine weitere Option ist das programmatische Ausführen eines flush und clear nachdem man eine bestimmte Anzahl von Entitäten bearbeitet hat. In meinem Fall führte die Ausführung von flush und clear zu einer erheblichen Performance-Steigerung. Der komplette Prozess dauerte anstatt 5 Minuten, nun nur noch 5 Sekunden.

Was man beim Bloggen heutzutage alles beachten muss

Als ich 2004 zum ersten Mal mit dem Bloggen angefangen habe, war die Sache an sich relativ einfach. WordPress heruntergeladen, installieren, fertig. Ich kann mich daran erinnern, dass gerade die Diskussion gestartet wurde, ob denn überhaupt und wenn ja in welcher Form Blogs ein Impressum benötigen. Aber zu diesem Zeitpunkt mit minimalistischem Aufwand ein Teil der „Blogosphäre“ zu werden stand nichts mehr im Wege.

Die Frage nach dem Impressum ist im Jahre 2013 definitiv mit einem „Ja!“ zu beantworten. Mehr noch, möchte man sich nicht in ein juristischen Minenfeld bewegen und schon gleich nach der Veröffentlichung des ersten Beitrags die erste Abnahme dem Briefkasten entnehmen (so zumindest der gefühlte Eindruck), klickt man sich besser noch eine Datenschutzerklärung und, sofern nötig, auch noch gleich den passenden Disclaimer.

In diesem Sinne: auf einen guten Neustart!

Pragmatische Ansichten zu Java und Web-Technologien.