Sperrobjekt Weblog

Ist schon wieder zehn Tage her, aber der Vollständigkeit halber schreibe ich noch ein paar Zeilen zum zweiten Treffen der JavaScript-User Group RheinMainJS. Wir trafen uns in angenehmer Umgebung bei Seibert Media (im fünften Stock des Wiesbadener Luisenforums) - ohne Ortskenntnis nicht ganz einfach zu finden, weil das Luisenforum hauptsächlich ein Einkaufszentrum beherbergt.

Knapp 25 Teilnehmer verfolgten mit Interesse die beiden Vorträge des Abends. Zunächst ließ uns Konstantin Filtschew an seinen - nicht immer positiven - Erfahrungen mit Appcelerator Titanium teilhaben und kam zu dem Ergebnis, dass bei komplexeren Anwendungen native Entwicklung unbestreitbare Vorteile hat. Im Anschluss stellte Christian Bäuerlein das Projekt Instantnavi vor, eine browserbasierte Turn-by-turn-Navigation auf JavaScript-Basis.

Es folgte, wie sollte es anders sein, der gemütliche Teil des Abends mit Diskussionen, Socializing und kühlen Getränken. Mir hat das Treffen sehr viel Spaß gemacht, vor allem weil wieder so viele JS-Entwickler teilgenommen und ihre Erfahrungen eingebracht haben. In Zukunft wollen wir unsere Treffen in etwa alle acht Wochen veranstalten, der nächste Termin wäre demnach Anfang Februar 2013 (ist noch nicht fix!). Aktuelle Informationen findet ihr auf unserer Google+-Seite.

Oder ihr werft einen Blick auf unsere neue RheinMainJS-Webseite, die ich auf Basis von node.js, Express und Foundation 3 kurz vor dem Treffen noch schnell erstellt habe. Die Domain dafür stellt freundlicherweise Sebastian Fastner zur Verfügung, gehostet ist die Seite bei Uberspace. Der Quellcode der Seite liegt übrigens auf GitHub, Contributions via Pull Request (Beispiel) sind sehr willkommen

PS: Sollten wir eins der nächsten Treffen wieder bei Seibert Media ausrichten, seht euch unbedingt diese Wegbeschreibung an!

Heute wird die DFL-Mitgliederversammlung, also Vertreter der 36 Vereine aus 1. und 2. Bundesliga, über das Konzept "Sicheres Stadionerlebnis" (PDF bei faz.net) abstimmen. Was zunächst nur die Vereine der beiden höchsten deutschen Ligen direkt betrifft, beunruhigt auch so genannte unterklassige Vereine. In einem gemeinsamen Offenen Brief appellieren der SV Waldhof Mannheim und seine Fanverbände

an die Vertreterinnen und Vertreter aller 36 Profi-Fußballvereine der 1. und 2. Bundesliga, am 12.12.2012 nicht den Anträgen des Antragspakets „Sicheres Stadionerlebnis“ zuzustimmen, sondern stattdessen das intensive Gespräch und den regelmäßigen Austausch mit ihrer Fanbasis zu suchen.

Auch beim letzten Auswärtsspielsieg in Worms machten sowohl die Mannschaft als auch die Fans beider Lager, letztere durch 12-minütiges Schweigen, klar, dass es "ohne Stimme keine Stimmung" in den Stadien mehr gibt.

"Mein sicheres Stadionerlebnis" vollständig lesen

Vor elf Tagen hat die Zeit Online mit einem kleinen Hackday ihr Content-API gelauncht. Die Zeit Online ist damit wohl die erste deutsche (Wochen-)Zeitung, die eine solche Programmierschnittstelle anbietet. International bieten z. B. der britische Guardian, die New York Times und USA Today einen ähnlichen Zugang zu ihren Inhalten an. Eine ausführliche Liste findet sich hier.

Da ich a) leider nicht beim Hackday in Berlin dabei sein konnnte und b) keine Idee für einen "Hack" hatte, hatte ich zunächst nur etwas mit dem API Explorer herumexperimentiert. Mein erster Eindruck war durchaus positiv, und bereits in den ersten Tagen wurden die ersten Apps geschrieben, die auf die Inhalte der Zeit zugreifen. Gelungene Beispiele sind etwa diese Visualisierung von Zeit-Artikeln auf einer Weltkarte oder diese Autorensuche in Sozialen Netzwerken.

Kurze Zeit später spülte mein Feedreader dann diesen Comicstrip herein, gezeichnet von Randall Munroe für seinen populären und genialen Webcomic xkcd. Im "Calendar of Meaningful Dates" zeigt die Größe eines Datums an, wie häufig es in englischsprachigen Büchern seit dem Jahr 2000 genannt wurde. Als Quelle gibt Munroe den Google Books Ngram Viewer an, mit dessen Hilfe sich übrigens auch Abfragen über deutschsprachige Bücher durchführen lassen.

Mir war sofort klar, dass sich ein solcher Kalender mit dem Zeit API nachbauen lassen müsste - und das sogar mit "Live-Daten". Also habe ich mich in den letzten Tagen zwischendurch daran gemacht, diese Idee umzusetzen. Die Anwendung, die auf Symfony2 basiert, fragt im Hintergrund (per Cronjob) bei der Zeit nach Artikeln, die ein Datum - z. B. "23. Mai" - enthalten, und speichert die Anzahl der Treffer. Anhand dieser wird nun die Kalenderdarstellung berechnet. Natürlich werden die Resultate gecachet, um die Server der Zeit zu schonen Und so sieht das Ergebnis aus, das unter http://calendarofmeaningfuldates.sperrobjekt.de/ zu finden ist:

Das ist natürlich nicht ganz so hübsch wie der handgezeichnete xkcd-Comic, dafür aber aktueller. Fährt man mit der Maus über ein Datum, wird rot die zugehörige Anzahl der Treffer angezeigt. Ein Klick leitet auf die Suchergebnisse bei Zeit Online weiter. Warum dort dann jeweils etwas mehr Treffer erzielt werden, kann ich nicht nachvollziehen; das Verhältnis der Daten untereinander scheint aber zu stimmen. Weil die Anwendung eben ein schneller "Hack" ist, sind solche Kleinigkeiten IMHO zu verschmerzen.

Die Ergebnisse sind übrigens auch ganz interessant: Am häufigsten genannt wird der 1. Januar, wie überhaupt der erste und letzte Tag jedes Monats häufiger auftaucht als die übrigen Tage. Drei Daten stellen eine Ausnahme dar: Der 17. Juni, der 20. Juli sowie der 11. September. Letzterer tritt auch im Original groß hervor. Der 17. Juni war bis zur Wende der Tag der Deutschen Einheit, und das Archiv der Zeit reicht ja zurück bis 1946. Aber was ist mit dem 20. Juli? Hat jemand für dieses Datum eine Erklärung? Mir ist bisher noch keine überragende Begebenheit für diesen Tag eingefallen.

Hier geht's direkt zum Calendar of Meaningful Dates - German ZEIT Edition.

Um mich an die immer noch gültige Barcamp-Regel Nr. 2 zu halten …

Blogge über das BarCamp.

… hier nun mein Nachbericht zum Barcamp RheinMain 2012 in Wiesbaden, dem mittlerweile vierten Barcamp in der Rhein-Main-Region.

Die Location

Die Wiesbadener Location in der Hochschule RheinMain war von allen bisherigen Barcamp-Locations in Rhein-Main die beste, und das nicht nur, weil ich in knapp 30 Minuten gemütlich zu Fuß hinschlendern konnte. Auch die Sessionräume passten von der Größe und der Aufteilung her. Ganz besonders wichtig fand ich die große Halle, in der es Kaffee und andere wichtige Getränke gab, in der das Essen serviert wurde, in der sich die Co-Working-Spaces präsentierten, in der auch Sessions abgehalten wurden, und in der sich alle Teilnehmer immer wieder trafen, sich austauschen und ausruhen konnten. Denn die Gespräche mit den anderen Teilnehmern sind bei Barcamps mindestens genauso unverzichtbar wie die Sessions selbst.

So verbrachte ich am Samstag auch mehr Zeit mit persönlichen Gesprächen als in Sessions. Nicht dass die Themen nicht interessant gewesen wären, aber mir war der Sinn irgendwie mehr nach direktem Dialog und Austausch. Und ich habe es genossen, zumal ich neben vielen alten Bekannten auch neue Menschen und Ansichten kennengelernt habe. So muss das auch sein auf einem Barcamp.

"Nachbericht Barcamp RheinMain in Wiesbaden" vollständig lesen

Geben wir es ruhig zu, der PHP-Code von Serendipity ist nicht mehr State of the Art, sondern zum großen Teil noch auf dem Stand von PHP 4. Dass dieser Code immer noch sehr zuverlässig funktioniert, und ob und wie mit dem aktuellen Stand umzugehen ist, soll hier nicht das Thema sein. Ich möchte hier auf die Entwicklung von Serendipity-Plugins eingehen, die nicht umsonst in einem eigenen Repository leben. Deren Qualität lässt sich mithilfe von Unit Tests sicherstellen.

PHPUnit für Plugins

Auch wenn die Grundfunktionalität von Serendipity durch Unit Tests abgedeckt ist: Die Plugin-Entwicklung ist bisher nicht so einfach zu testen. In meinen letzten Projekten waren Unit Tests mit PHPUnit ein zunehmend zentraler Bestandteil der Entwicklung. Entweder damit ich nachträglich sicherstellen konnte, dass Klassen und Methoden bei Veränderungen und Refactoring noch taten, was sie tun sollten; oder weil ich testgetrieben entwickelte, das heißt zuerst die Unit Tests und dann erst den zu testenden Code schrieb. Dieses Vorgehen möchte ich nicht mehr missen, und es hat mich gestört, dass es bei der Entwicklung von Serendipity-Plugins nicht ohne Weiteres möglich war.

Daher habe ich mich hingesetzt und PHPUnit so in meine lokale Serendipity-Installation, die ich zum Entwickeln verwende, integriert, dass ich einzelne (Event-)Plugins separat testen kann. Die spezifischen Herausforderungen ließen sich recht schnell überwinden:

• In Serendipity werden Plugins stark getrennt vom Core über Event-Hooks ausgeführt. Diese Hooks müssen natürlich einzeln getestet werden können.
• Viele Variablen sind als global deklariert oder werden per Referenz "herumgereicht". Das erfordert einige Workarounds, die heute dank Dependency Injection und ähnlichen Entwurfsmustern zum Glück überflüssig sind.
• Data Fixtures: Um Serendipity für die Tests "hochzufahren", wird eine Datenbankverbindung benötigt. Mir ist es bisher nicht gelungen, eine der unter Database Testing aufgeführten Methoden umzusetzen. Besser gesagt: Ich war einfach zu faul und habe die nötigen Daten in einer SQLite-Datenbank hinterlegt.

"PHPUnit für die Entwicklung von Serendipity-Plugins" vollständig lesen