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.)

Am 22. November 2012 verfasste ich folgende Stichpunkte für einen Post, den ich irgendwann mal veröffentlichen wollte:

- touch mittlemäßig - oft vertouche ich mich, manchmal gehts garnich, manchmal dann 2 seiten auf einmal, vielleicht lernt man es - für tastatur und dictionary aber super - hätte gerne weiter hardwaretasten, gerne zusätzlich und touch zum umblättern deaktivieren - etwas schwerer, display fühlt sich rauer an - licht gut, aber ungleichmäßig und eher blau als paperwhite - umblättren fühlt sich langsamer an

Heute, fast zweieinhalb Jahre und einige Lesestunden später, kann ich sagen, dass all diese Stichpunkte auch weiterhin zutreffen.

(Aus der Reihe: "Philipp räumt seinen Drafts-Ordner auf")

watched.li statusblog:

Ignoring Seasons and Statistics

Hey, long time no see!

After struggling with myself for months how to advance this little side project I decided that’s okay to add new features to the “old” code instead of rewriting everything from scratch.

So the first two new features landed today:

Wisst ihr noch, wie ich vor ein paar Monaten über mein Problem mit Web-Entwicklung schrieb? Nach dem Post war ich zwar total motiviert, jetzt endlich damit anzufangen, watched.li mit Yii 2 neu zu implementieren, ein paar Tage später war aber auch schon wieder alles vorbei.

Gestern konnte ich mich dann endlich dazu überwinden, mir den alten Code wieder anzuschauen, räumte etwas auf und stellte fest, dass das alles gar nicht so kacke ist, wie ich dachte. Ich war wohl auch schon vor drei Jahren ein okayer Programmierer.

Jedenfalls implementierte ich gestern nun zwei kleine neue Features und fühle mich jetzt, wo der Druck, alles neu bauen zu müssen, weg ist, doch wieder motiviert noch mehr zu machen. Ich freue mich.

Vielleicht ist an dem guten alten Spruch "Never rewrite code from scratch" doch was dran.

Da ich ja gerne alles, was ich so mache, archiviere, benutzte ich seit einigen Jahren Tweetnest um meinen Tweets ein alternatives zuhause zu geben, falls Twitter mal alles abschaltet. Irgendwann gab es Serverprobleme, alles ging kaputt und ich war immer zu faul, Tweetnest zu reparieren, da ich ja auch noch 3200 Tweets Zeit hatte, alles wieder zum Laufen zu bekommen.

Naja. Im Laufe der Zeit löste sich das Problem quasi von selbst, denn Twitter fing an einen Archiv-Export anzubieten.

Vor ein paar Tagen zeigte Markus jedenfalls, wie er sein Twitter-Archiv automatisch up-to-date hält und in einem Git-Repository ablegt. Das fand ich gut und habe es daher ebenfalls so aufgesetzt. Sehr cool!

(Ich musste das Script, allerdings noch etwas anpassen, da ich auf meinem Server rvm benutzen muss, da Debian so eine alte Ruby-Version hat -- die Pfade zu den Binaries müssen also mit $HOME/.rvm/wrappers/ruby-2.2.0/ beginnen.)

Falls ihr euch mal gefragt habt, wie groß Island eigentlich ist.

Update: Natürlich beachtete ich bei diesem kurzen Mockup nicht, dass Karten kacke sind. Hier gibt es eine richtigere Karte. Ändert im großen und ganzen aber auch nicht viel.

Der aktuelle heiße Scheiß im Frontend-Business heißt ja React. Da ich mit Angular nie so richtig warm geworden bin und Facebook vor ein paar Wochen React Native vorstellte, fand ich, dass es an der Zeit war, mich mal damit zu beschäftigen.

Das Problem

In der Firma benutzen wir Redmine zum Ticket-Verwalten und Zeiterfassen. Leider fand ich bisher keine wirklich komfortable Möglichkeit, das damit zu erledigen. Alle Plugins, Mac- und iPhone-Apps gefielen mir nicht so gut, daher passiert es oft, dass ich mir Zeiten einfach in mein Notizbuch schreibe und dann manuell übertrage.

Letzte Woche kam mir die Idee, dass ich ja eine App machen könnte, mit der man ganz leicht Zeiten aufnehmen kann. Die kann den ganzen Tag auf dem iPad geöffnet sein, welches dann immer im Blickfeld herumliegt. Vielleicht löst das dann das Problem, dass ich vergesse das ich ja tracken sollte.

Die Lösung

(In Wirklichkeit stehen da natürlich echte Task-Namen und nicht nur zufällige Buchstaben.)

Wie ist denn React nun?

Die Entwicklung machte im Großen und Ganzen Spaß und ging auch relativ schnell. Das ganze Konzept von React gefällt mir sehr gut, die Dokumentation ist okay und man findet auch schon allerhand Lösungen bei Stackoverflow.

Probleme?

Mein Hauptproblem ist eigentlich, dass React nicht so gut mit fastclick.js funktioniert und man daher nicht um dieses 300ms-Delay auf Touchgeräten herum kommt. Also, es gibt schon ein paar React-Module mit denen man das Anscheinend nachbauen kann, die waren aber hässlicher als "Einfach nur fastclick.js einbinden". Da muss ich nochmal nachforschen.

Ein zweites Schönheitsproblem ist, dass React keine onClick-Handler ausführt, wenn ein Element -webkit-overflow-scrolling: touch hat. Da die Task-Liste auf der linken Seite eben genau so funktioniert, ist das etwas schade.

Etwas verwirrend fand ich zunächst, dass React ja wirklich nur ein Tool für die "View"-Ebene ist. Es gibt daher keine wirklichen Vorschriften, wie man jetzt seine Datenquellen zu bauen hat. Einerseits ist das natürlich eine schöne Freiheit, andererseits erzeugt es natürlich auch zusätzliche Denkarbeit, wie man nun sein Model-Layer aufbaut. (Mit Flux gibt's da auch eine Empfehlung von Facebook)

Ansonsten lief alles gut, aber wie man sieht, ist es ja auch nur ein sehr kleines Projekt.

Browserify

Da ich natürlich nicht nur eine Sache gleichzeitig angucken kann, probierte ich auch noch Browserify aus um den ganzen Kram zusammenzupacken.

Meine bisherigen Erfahrungen mit Dependency-Managern im Frontend beschränkten sich auf Bower und RequireJS -- das gefiel mir alles überhaupt nicht damals. Mit Browserify kann ich nun npm benutzen und muss nicht zwei Stunden googlen, wie denn die RequireJS-Syntax funktioniert. Klare Empfehlung!

Fazit

React hat erstmal einen wesentlich besseren Eindruck auf mich gemacht, als Angular. Browserify ist RequireJS in gut. Ein Samstagabend halbwegs sinnvoll und spaßig verbracht!

Für die Neugierigen: Den Code gibt's natürlich auf GitHub!

Spätestens nach dem Kauf verschiedener Fotobücher von Paul Ripke im letzten Jahr wuchs in mir das Verlangen selber ein Fotobuch zu gestalten. Glücklicherweise hatte ich, weil wir im letzten Jahr echt viel unterwegs waren, eine Menge Fotos und so baute ich Ende letzten Jahres in unendlich lang wirkenden Indesign-Sessions mein erstes Buch zusammen.

Ich spielte etwas mit der Bildaufteilung rum, würde viele Sachen wieder genauso machen, manche Sachen lasse ich vielleicht beim nächsten Mal. Insgesamt bin ich aber sehr zufrieden und es fühlt sich ziemlich gut an, die Fotos zum Anfassen zu haben. Mit Blurb bin ich so mittel-zufrieden -- die Druckqualität ist okay. Mehr kann man zum Preis von 70€ für 220 Seiten aber wohl auch nicht erwarten.

Na, macht ihr auch brav eure Backups?

Backups sind ja nur vernünftig, wenn sie automatisiert passieren. Daher habe ich in den letzten Wochen mal meine Scripte überarbeitet und bin zu einem ganz zufriedenstellenden Ergebnis gekommen.

Das einzige was mir jetzt noch fehlt ist:

• Sync meiner Fotos zu Amazon Glacier. Leider ist die Glacier-Sync-App von meiner Synology kacke.
• Sync der Dropbox auf die NAS, leider ist die Dropbox-App von meiner Synology kacke.
• Sync der letzten Server-Backups auf die NAS, um sie nicht nur in der Cloud zu haben, das habe ich aber einfach noch nicht implementiert

Sobald ich das alles umgesetzt habe, bräuchte ich dann noch eine weitere USB-Platte, die ich mit der NAS-Backup-Platte in regelmäßigen Abständen tausche und irgendwohin bringe, um noch ein Off-Site-Backup zu haben.

Jetzt seid ihr dran! Steckt mal eure Time Machine Platte an, die seit 57 Tagen darauf wartet, mal wieder zu backuppen oder holt euch einen Backblaze Account. (Dieser Post wird im Gegensatz zu vielen Podcasts nicht von Backblaze gesponsort.)

Ich glaube, es dürfte mittlerweile 10-15 Jahre her sein, dass ich meine ersten Zeilen PHP-Code schrieb. Damals war alles so einfach — man hatte ein paar Dateien mit Code, HTML, CSS und <font>-Tags, alles quer gemischt.

Außerdem gab es keine riesigen Diskussionen, ob PHP nun supergeil, okay, total bescheuert, oder die Ausgeburt der Hölle ist. Also, wahrscheinlich gab es die Diskussionen, aber sie interessierten mich nicht. Ich fand PHP, sah das es genug Tutorials und Dokumentation gab und lernte es einfach, weil es mir am einfachsten erschien.

(Ruby und Python waren damals einfach noch nicht in meinem Blickfeld, Perl verstand ich nicht)

Webentwicklung im Jahre 2015, Symbolfoto

Heute hat sich das geändert. Die Stimmen gegen PHP werden immer mehr, ich ließ mich davon beeinflussen und wurde unsicher. Im Rahmen eines Kundenprojektes beschäftigte ich mich mit NodeJS und fand das auch ziemlich gut, fand aber einige Punkte, die mich störten (Javascript, die Datenbank-Wrapper sind alle komisch, die Template-Engines sind alle komisch).

Dazu kommt, dass viele moderne Webapps Single-Page-Apps sind, dafür gibt es aktuell auch mindestens fünftausend Javascript-Libraries.

Und haben wir schon über Datenbanken gesprochen? SQL ist scheiße, NoSQL ist die Zukunft! Oder auch nicht. Jeder hat hier eine andere Meinung.

Wenn man sich die aktuelle Webentwicklungs-Landschaft so anguckt, könnte man denken, es ist unmöglich etwas zu bauen, ohne mindestens zwölf verschiedene Javascript-Libraries, zwei CSS-Preprocessors und eine fancy Programmiersprache mit MVC-Framework und richtig geiler Asset-Pipeline zu benutzen. Achja, und NoSQL. NoSQL!

Weil ich natürlich auch hip und modern sein will gucke ich mir die meisten Dinge auch an und versuche damit rumzubasteln, meistens merke ich aber auch, dass am Ende doch alles scheiße ist.

Klar stecken in den meisten Produkten tolle Ideen, selten lassen sie sich aber so gut verallgemeinern, wie die Entwickler das andachten und was am Ende dabei rauskommt ist dann wunderschöner, aber sehr speziell geformter Hammer, der nur bei wenigen Nägeln weiterhilft (Ich liebe die Hammer-Nagel-Metapher).

Puh. Insgesamt nervt mich die Situation seit mittlerweile mehr als einem Jahr. Placescore baute ich damals in NodeJS — einmal mit MongoDB, bis ich feststellte, dass es sich nicht dafür eignet (oder ich zu dumm bin) und dann nochmal mit Postgres, glücklich war ich dabei aber auch nicht.

Statt nun weiter frustriert zu sein, entschied ich mich, mir jetzt erstmal Yii 2.0 anzugucken und watched.li damit weiterzuentwickeln. PHP 5.4, MySQL und serverseitig gerenderte Templates.

Das fühlt sich jetzt zwar etwas rückschrittlich an, aber ich glaube, es ist besser, überhaupt etwas zu machen als Monate lang wegen zu großer Auswahl in Schockstarre zu verfallen.

Wenn ihr es nun bis hier her geschafft habt, macht nicht den gleichen Fehler wie ich. Lasst euch nicht frustrieren von der Auswahl und den tausenden Meinungen da draußen. Entscheidet euch für das Werkzeug, was euch am besten in der Hand liegt (selbst wenn es PHP ist) und baut, was ihr bauen wollt.

Viele Grüße,
Philipp