Javascript

Das Problem

Wer Anfang der 2010er Jahre (oder gar noch früher) Web-Applikationen entwickelt hat, kam wohl um die Programmiersprache PHP nicht ganz herum. So verwendeten auch wir zu dieser Zeit PHP bei der Erstellung des neuen Projekts iPROT. Erste Frontend Frameworks wie Backbone.js oder Angularjs waren zwar gerade entstanden, wir vertrauten aber auf Bewährtes und bauten die Logik hauptsächlich auf der Server-Seite in PHP.

Natürlich kam auch jQuery zum Einsatz. Es war in dieser Zeit, in der sich nicht alle Browser an den HTML-Standard hielten (sprich IE), eine Riesenerleichterung für die Frontend-Entwicklung. Ja es funktionierte so gut, dass wir immer mehr jQuery-Code ergänzten, was die Sache irgendwann unübersichtlich werden ließ.

Als ich kürzlich die Zeilen

Waiting for 1.2.3.4

und dann noch

Transferring from 1.2.3.4

in der Status-Zeile des Firefox Browser las wurde ich etwas unrund. Die aufgerufene Seite (http://snowhow.info) hatte ich selbst entwickelt und ganz sicher keinen Link auf http://1.2.3.4 eingebaut. Irgendwie schaute die Seite auch anders aus, aber nicht wesentlich. Also den Quellcode der Seite studiert und da steht es: Vor der head-Anweisung hat jemand Javascript-Code aus einer anderen Domain eingeschleust:

Das Problem

Bei snowhow verwenden wir WordPress als Content-Management-System. Die Benutzer-Accounts für die snowhow User werden auch in WordPress verwaltet. Warum? Das System ist sehr weit verbreitet, die User-Verwaltung sollte also ausgereift sein (ge-hashte Passwörter, Passwort per E-Mail zurücksetzen).

Außerhalb von WordPress als CMS setzen wir auf Nodejs und MongoDB. Die aufgezeichneten Freeride-Tracks und Skitouren kommen als GeoJSON direkt in die MongoDB und können dort via räumlicher Suche gefunden werden, herrlich unkompliziert. Aber wie kann der Nodejs-Server (express) auf die Authentifizierung von WordPress zugreifen?

Das Problem

App-Entwicklung mit Cordova funktioniert großartig. Beim Aufzeichnen von GPS Tracks stößt man aber an die Grenzen der Technologie, da es keine Möglichkeit gibt, einen Prozess zu starten, der nicht automatisch vom System beendet werden kann. Dazu benötigt man ein Plugin…

Ein Android Service

Mit ein wenig Java Kenntnissen ist es einfach einen Hintergrund-Dienst (Service) als Plugin für Cordova zu realisieren. Android kann den Service zwar auch beenden, startet ihn aber sofort wieder, wodurch das GPS tracking fortgesetzt wird. Einen Haken gibt es bei der Sache allerdings: Die Kommunikation zwischen Plugin und der Web-app ist schwierig. Die vorhandene Schnittstelle über den Callback-Context funkioniert (nach meinem Wissen) nicht, da der Service abgekoppelt läuft.

Ein Problem, das vermutlich mehrere Entwickler haben, die in einer Web-Applikation mit Javascript auf ein backend zugreifen: Entwicklet wird auf der lokalen Maschine, das backend liegt (zum Entwickeln) auf einem anderen Server.

Browser lassen HTTP-Requests in Javascript von localhost auf eine andere Domain nicht zu (hier gilt die same origin policy). Auf den Seiten des Mozilla Developer Network wird sehr übersichtlich erklärt, wie man diese Einschränkung sicher umgehen kann. Da wir im content der requests json verschicken müssten unsere Zugriffe recht aufwändig als preflighted requests behandelt werden.

ich sags gleich, ein steiniger Weg.

Die Anforderung

Zum Zweck der analogen Archivierung musste ich für ein aktuelles Projekt (CHES) eine moderne HTML-Seite (mit mehreren Canvas-Elementen) in eine druckbare Form bringen. Mit CSS-Anweisungen ist es mir nicht gelungen, nur in zwei modernen Browsern ein halbwegs vergleichbares Layout zu Papier zu bringen. Mit viel Javascript ging es eher in diese Richtung, aber im dritten Browser war dann auch da wieder alles anders.

In der Karte im Viel-Falter Projekt sollte zu den gekachelten Rasterlayern ein weiterer Layer mit der Biotop-Kartierung von Tirol dazukommen. Da die gesamte Vektor-Geometrie mit über 200 MB im GeoJSON Format zu Buche schlägt, muss der Datensatz auf die Ausmaße aktuellen Ansicht (BoundingBox) eingeschränkt werden. Einigermaßen überrascht stellte ich fest, dass es hierzu (fast) keine fertige Lösung gibt. Hier mein Weg:

PostGIS

Da der Vektordatensatz aus vielen kleinen Polygonen besteht eignet er sich wunderbar für Einschränkungen anhand der aktuellen BoundingBox. Postgresql in Kombination mit PostGIS macht diese Berechnungen sehr einfach und mit einem räumlichen Index auch sehr schnell. Also war der erste Schritt den Vektordatensatz im Shapefile Format in die Postgresql Datenbank zu importieren.