Ein benutzerfreundlicheres OpenLayers 3 – Bericht vom CodeSprint in Schladming, Österreich

In der vergangenen Woche (29.03. – 05.04.) trafen sich zehn Entwickler verschiedener Firmen zu einem CodeSprint in Schladming, Österreich, der unter dem Motto „OpenLayers 3 benutzerfreundlicher machen“ stand.

Gruppenfoto der beteiligten Entwickler

Gruppenfoto der beteiligten Entwickler
A. Hocevar, B. Harrtell, P. Pridal, V. Malaret, G. Beraudo, É. Lemoine (oben v.l.n.r.), M. Jansen, T. Schaub, B. van den Eijnden, T. Sauerwein (unten v.l.n.r.)

An dieser Stelle möchten wir die Arbeiten während dieses CodeSprints vorstellen:

  • Zu etwa der Hälfte aller in OpenLayers vorhandenen Methoden wird nun in der API-Dokumentation ein einführender Satz erscheinen, der Sinn und Zweck der jeweiligen Methode erläutert. Bis zum Release der nächsten Version (Ende April/Anfang Mai) werden wir anstreben, alle Methoden mit mehr Prosatext zu dokumentieren.
  • Im Rahmen einer umfassenden Diskussion zur Schnittstelle nach außen (API) haben wir sehr viele Methoden als ’stabil‘ gekennzeichnet und wo es sinnvoll erschien, ist die API auch um Hilfsmethoden ergänzt worden (etwa um die Arbeit mit verschiedenen Projektionen zu vereinfachen: z.B. ol.proj.fromLonLat()). Im Nachgang zum Sprint konnten auch tiefgreifende Veränderungen an der API umgesetzt werden. Hier ist beispielsweise die vereinfachte Vector-API und das Entfernen von unspezifischem Code (etwa two-way-binding und binäre Formate) zu nennen.
  • Es wurden weitere Prosadokumente dem Projekt beigesteuert: Ein FAQ-Dokument sowie Tutorials, die erläutern, wie OpenLayers mit eigenem Code kompiliert oder eigene Standalone OpenLayers-Builds erzeugt werden können. Ein Migrationsdokument für User der Version 2.x wurde begonnen, ist jedoch noch nicht vollständig. Um eigene OpenLayers-Builds zu erzeugen, wurde ebenfalls begonnen, einen Web-Service zu entwickeln, der einen eigenen Build komfortabel auf Knopfdruck bereitstellt. Auch hier ist mit einer Veröffentlichung parallel zum nächsten Release zu rechnen.
  • Screenshot des Build-Tools

    Screenshot des Build-Tools

  • Die Homepage und die API-Dokumentation werden zukünftig in einem einheitlichen Look erscheinen und auch die Inhalte der Homepage und des README-Dokuments wurden überarbeitet, um sich schneller zurechtzufinden.
  • Die Beispiele wurden grundlegend überarbeitet. Alle werden nunmehr via eines Templates erzeugt, so dass die Beispiele konsistent in Layout und Aufbau sind. Des Weiteren erscheint unterhalb des Beispiels ein formatierter Block, der den Quelltext des Beispiels aufführt. Jener kann via Knopfdruck in die Zwischenablage kopiert oder alternativ (ebenfalls via) Knopfdruck in einen jsFiddle übernehmen werden. So wird das Editieren des Beispiels enorm vereinfacht.
  • Beispiele sind um sinnvole Funktionen ergänzt worden

    Beispiele sind um sinnvolle Funktionen ergänzt worden

  • Wenn notwendige Bedingungen, damit Methoden wie erwartet funktionieren (sogenannte assertions) nicht erfüllt sind, so wird OpenLayers nun in jedem Fall eine hoffentlich hilfreiche Fehlermeldung ausgeben. Diese soll das Eingrenzen des ursächlichen Fehlers vereinfachen. Noch in OpenLayers v3.4.0 wurde hier in einem solchen Fall nur ein teilweise unspezifischer Fehler geworfen, der keine weiteren Informationen enthielt.
  • Neben der automatisierten Testsuite existieren nun ebenfalls automatisierte Testcoveragewerte (istanbul-js und coveralls). Testcoverage beschreibt vereinfacht, wie hoch die Abdeckung des Quelltextes der Bibliothek (Funktionen, Bedingungen etc.) durch Tests ist. Wir wissen nun also nicht nur (etwa bei Pull Requests via Github), dass unsere Tests der Bibliothek erfolgreich absolviert wurden, sondern zusätzlich, welche Bereiche der Bibliothek bereits gut mit Tests abgedeckt sind und wo noch Verbesserungsbedarf besteht.
    HTML TestCoverage-Report

    HTML TestCoverage-Report

    Auswertung der Coverage Informationen für Pull Requests

    Auswertung der Coverage Informationen für Pull Requests

    Bereits bevor wir konkrete Zahlen zu tatsächlicher Testcoverage hatten, wussten wir z.B., dass die verschiedenen Renderer der Bibliothek zu wenige Tests aufweisen. Hier haben wir nun seit dem Sprint die Möglichkeit, tatsächliche Renderingergebnisse (sprich etwa grafische Representationen von geographischen Features) mit Referenzbildern zu vergleichen.
  • Noch nicht in den Hauptentwicklungszweig zurückgeflossen sind die Arbeiten, die bezüglich des Zeichnens von Linien und Polygonen mittels WebGL gemacht wurden. Hier muss vermutlich zunächst noch mehr Arbeit investiert werden, bevor diese Änderungen zurückfließen können. Die Ergebnisse sind jedoch bereits schon jetzt bemerkenswert!
  • Via WebGL gerenderte Linien und Polygone

    Via WebGL gerenderte Linien und Polygone

  • Auch einige bereits länger bestehende Pull Request von anderen Beitragenden haben wir gereviewt, kommentiert und ggf. in den Hauptentwicklungszweig zurückfließen lassen.
  • Für weitere und detaillierte Informationen können alle erfolgten Änderungen/Changesets des CodeSprints diesem Link entnommen und der offizielle Bericht des Events auf dem OpenLayers Blog nachgelesen werden.

Fazit: Es ist viel geschafft worden auf dem CodeSprint und das Projekt konnte einiges von dem Drive in die Zeit nach Schladming hinüberretten, wie es zahlreiche nachfolgende Änderungen im Repository belegen.

Ausdrücklich bedanken möchten wir uns bei den Sponsoren des Events, die entweder Entwickler entsendet haben oder aber via finanzieller Unterstützung zum Gelingen beitrugen: Boundless, Camptocamp, FOSSGIS e.V., Klokan TechnologiesPlanet Labs, Sweco und auch terrestris.