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.
Des Öfteren werde ich gefragt, wann ich denn mal wieder etwas über Serien schreibe. Ich finde das immer ziemlich komisch, denn wann schrieb ich denn hier groß mal was über Serien? Ich schrieb mal einen Abschiedspost zu House, das war es dann aber auch.
Naja. Ich würde auf jeden Fall gerne den Wünschen nachkommen, das Problem ist aber, dass ich das einfach nicht kann, weil ich kein großer Review-Schreiber bin. Ich habe keine Lust mir Notizen zu machen und bis ich eine Serie fertig habe, habe ich das meiste auch schon wieder vergessen.
Das Einzige, was ich vielleicht schaffe ist ein kurzer Zweizeiler, wie etwa:
Schaute gestern Daredevil fertig. Dreizehn sehr gute Folgen, die allerdings teilweise ganz schön brutal werden. Freue mich auf die nächste Staffel und kann es uneingeschränkt empfehlen.
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")
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.
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!
