Dem ein oder anderen, der einen Blick in die Island-Galerien geworfen hat, wird vielleicht die Karte aufgefallen sein, die dort eingebaut ist.

Bereits während des Urlaubs dachte ich, dass ich in die kommenden Galerien eine neue Spielerei einbauen will. Nach reichlicher Überlegung (fünf Minuten) fiel die Wahl auf eine animierte Karte, die zeigt, wo wir uns an den verschiedenen Tagen aufgehalten haben.

Dank meiner Daten aus Moves und der Karte, die Hannah bereits vor dem Urlaub angefertigt hatte, war das ja kein Problem.

Also, Schritt 1: Die Karte als SVG erstellen, die Route eintragen, die Pins reinwerfen und sich ein bisschen über Adobe Illustrator aufregen.

Danach recherchiert man dann ein bisschen, wie man das eigentlich macht. Ich für meinen Teil fragte einfach Daniel, denn ich erinnerte mich, dass er sowas schonmal machte.

Eigentlich ist es ganz einfach. SVG-Pfade haben die Methoden getTotalLength() und getPositionAtLength(), mit denen man einerseits die gesamte Länge (ha! Wer hätte das gedacht) und andererseits die Koordinaten an jeder Stelle des Pfades bekommen kann.

Damit ist es dann schonmal kein Problem mehr ein Auto an dem Pfad “entlangfahren” zu lassen. Den Pfad nur teilweise zu zeichnen geht auch, mit etwas CSS-Gefrickel, welches ich natürlich bei css-tricks.com fand.

Schritt 2: Daniel fragen, wie man sowas macht, etwas googeln und einen Prototyp bauen.

Sehr zufrieden schaute ich mir ein paar Stunden später das Produkt meiner Arbeit an. Das Auto fuhr schön auf der Karte herum, die PINs ploppten auf und zeigten beim Hovern einen Tooltip an.

Nun wollte ich die Karte in meine Live-Galerie integrieren und schaute es nochmal zur Sicherheit in verschiedenen Browsern an. So als Profi-Webentwickler macht man das ja.

Safari - fast keine Probleme.

Internet Explorer - Egal.

Firefox. Arghl. Nichts funktioniert.

Nach etwas Recherche konnte ich dann feststellen, dass der Firefox wohl bei .getTotalLength() ein Problem hat (zumindest bei meiner SVG) — auch die tolle SnapSVG-Library funktionierte dafür nicht. Einbinden musste ich sie trotzdem, denn auch der Rest war im Firefox nicht so richtig funktional. Die Länge kodierte ich dann einfach hart.

Außerdem unterstützt der Firefox anscheinend keine CSS-Transforms für SVG-Elemente. Nachdem sich die Aufregung gelegt hatte, band ich dann noch GSAP ein, eine schöne JS-Animation-Library. Weitere 100kb.

Wegen dem Firefox musste ich also Libraries im Wert von 150kb einbinden. Tolle Sache. Zum Glück ist das Gesamtkonstrukt (Libraries + Karte + Kleinkram) immer noch wesentlich kleiner als jedes einzelne Bild in der Galerie, von daher ist das wohl egal.

Schritt 3: Den Firefox hassen, alles neu machen und releasen.

In drei einfachen Schritten zum animierten Glück! So einfach ist das. Webentwicklung macht Spaß, bis man seinen Chrome verlassen muss.

(Danke an Hannah für die Karte und das Auto, Daniel für den Stups in die richtige Richtung und an den Chrome, weil er einfach funktioniert)

(Den vollständigen Source-Code findet ihr, wenn ihr auf die Island-Galerie geht, View source in eurem Browser klickt und nach der karte.js sucht. Er ist zu hässlich, als das ich ihn hier präsentieren wollen würde)

Wie schon oft erwähnt, bin ich seit langer Zeit (mindestens seitdem es von Facebook gekauft wurde) auf der Suche nach einer Alternative für Moves.

Bisher blieb diese leider erfolglos und nicht zuletzt wegen des Kommentars von Nils unter meinem letzten Post, entschied ich mich dafür es halt selber in die Hand zu nehmen.

Leider ist das alles nicht so einfach, denn Infos wie man seine App nun perfekt dazu bringt im Hintergrund weiter die Location zu holen und dabei vielleicht noch etwas energiesparend zu sein sind spärlich gesäht. Oder ich bin zu schlecht im Googeln.

Abgesehen davon bedeutet vernünftiges Ausprobieren dann auch immer einen Tag warten und am Ende gucken, ob sich etwas bei der Aufzeichnung verbessert hat.

Seit ein paar Tagen feile ich also Abends an der Implementierung, gucke es mir am nächsten Tag an und hoffe, dass es besser wird.

Mein aktueller Status: Ganz okay! Teilweise gibt's natürlich noch viel Rauschen, vor allem wenn ich mich an einer Position befinde. Dagegen komm ich sicher mit komplizierten Filteralgorithmen an. Andererseits hört er manchmal doch einfach so auf zu tracken, da muss ich nochmal gucken.

Falls jemand Tipps hat, gerne her damit. Ansonsten probiere ich einfach weiter rum. Weitere Ergebnisse dann wie immer hier im Blog und später auf Github!

"Let's do a apt-get update && apt-get upgrade to install a lot of fancy security updates!".

Well, somehow in this process my nginx got updated from 1.6.2 to 1.8.0 (I'm using dotdeb packages. I don't know why they made such a big jump?). The result were blank pages for my PHP scripts, without any errors, even after activating all debug switches I found.

After googling for my favorite key words "nginx php-fpm blank page no errors" and trying some things I fixed everything with this line in my PHP location block in the nginx configuration:

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Maybe the nginx update overwrote the default fcgi_params file that's included by default, or it's not nginx' fault after all and PHP-FPM changed its behaviour. Whatever. Its fixed now and I hope the next update will be smoother. Like the 2000 updates before.

I'll confess: I'm a var_dump-debugger.

But sometimes it comes in really handy to have a real debugger at hand. Unfortunately it took me some time to figure out what I need to do to allow the Xdebug in my virtual environment to talk to PHPStorm. There are a lot of tutorials, but all I read miss one critical thing:

ssh -R 10000:localhost:10000 vagrant@funnyvagrantvm.local

Yes. Assuming your xdebug.remote_port is 10000, you'll have to open a SSH tunnel from your host machine to your virtual machine. (Maybe you don't need this if you configured your VM in a more open way, then all the other tutorials may be enough.)

Bonus content: My xdebug.ini:

zend_extension=xdebug.so
xdebug.remote_enable = 1
xdebug.remote_connect_back = 0
xdebug.remote_port = 10000
xdebug.remote_autostart = 1
xdebug.idekey = phpstorm
xdebug.max_nesting_level = 250

Especially xdebug.remote_autostart is nice when you need to debug your integration tests that test against your HTTP API.

Die große Leserumfrage, die ich letzte Woche startete, fand erfreulicherweise rege Beteiligung. Ohne viel Reden hier die Auswertung der insgesamt 61 Antworten:

Danke für die Antworten!

RSS scheint also, zumindest was meinen Blog angeht, noch nicht besonders tot zu sein. Vielleicht sollte ich auch mal wieder versuchen einen RSS-Reader zu benutzen.

Hallo liebe Leser,

seit langem beschäftigt mich die Frage, wie ihr euch eigentlich über neue Beiträge in diesem Blog benachrichtigen lasst. Wie wir alle wissen ist RSS ja tot. Wenn ich ab und zu hier mal was umbaue, dann vergesse ich zum Beispiel oft, dass es im Feed dann vielleicht kaputt ist, weiß aber am Ende auch nicht wie wichtig das jetzt ist.

Daher nun die große Umfrage:

Wie checkt ihr archiv.knuspermagier.de?

• Per RSS-Feed. Oldschool!
• Per Twitter!
• Per Facebook
• Ich gehe in unregelmäßigen Abständen auf archiv.knuspermagier.de und gucke, ob's was neues gibt
• Ich habe den archiv.knuspermagier.de Brieftauben-Service abonniert
• Ich lese diesen Blog nicht und kam nur durch die Suchanfrage "RSS ist tot Brieftauben" auf diesen Blogpost

Bitte kommentiert! (Oder schreibt mir bei Twitter oder eine E-Mail)

Das letzte Wochenende verbrachten wir zu großen Teilen auf dem Startup Weekend. Gemeinsam mit Flo, Pablo und Hannah baute ich dort album up, ein kleines Tool für Dropbox-affine Fotografen.

Der aktuelle Stand ist natürlich noch nicht komplett fertig und benutzbar, wir werden es aber in den nächsten Wochen gemeinsam weiterbauen.

Einen etwas ausführlicheren Bericht findet ihr in Hannahs Blog, oder in der aktuellen Spezial-Folge von uswief.

Yes, I’m a bit late to the game but last weekend I decided to finally get in touch with WatchKit. My first project will be developing an App for Better, the (still unreleased) spendings tracking app I talked about multiple times.

Goal

My goal is to have a quicker way to add spendings. Open the app, choose the category and the amount, done. Also I want to have a glance that shows the total amount of the current month.

First steps

Adding a WatchKit component to your app is quite easy as Xcode does provide a nice template. I immediately switched to Interfacebuilder and added a WKTableView for the categories to the first controller.

I added some mock data to the generated InterfaceController.m and ran the App for the first time. Success! That went easier than expected.

My next challenge was to find out how to get the data flowing between the iPhone and the Watch. At first I tried to get MMWormhole to work. I followed the instructions and created App Groups and Entitlements and stuff, but it still wasn’t doing anything.

One roundtrip to StackOverflow later I discovered [WKInterfaceController openParentApplication:reply:] which seemed to be good enough for my use case. Unfortunately it did not work either.

Well, the problem was that the data that should be transferred must comply to the NSCopying protocol. Of course. How could I forget this?

Very unlike me I directly used the method that gets some models from Core Data to produce the data that’s transferred to the app. Usually I would work with some dummy data… that would have saved some time in this case.

Buttons, Buttons, Buttons

First controller done, next up: The controller to add a new spending. For the first try I settled with a pretty standard numpad button layout. The buttons on the lock screen are not much bigger, so I think it should work…

If it gets to tedious I’ll add another step with recent spendings that can be added again. I use the feature quite often in the iPhone app.

But at first I have to find time to implement this, so stay tuned for the next post!

Just a quick note, because all my searching only resulted in code how to change the attributes of the... displayed text (by setting textView.attributedText):

You can set the attributes that should be applied to all new text in the UITextView by setting textView.typingAttributes.

Easier than expected! (And turns out: looking at the documentation would have helped faster.)