Archiv: Januar 2017

Keine Angst, ich werde keine Handlung von Sherlock spoilern, extrem vorsichtige Leute sollten jetzt aber vielleicht doch einfach diese Seite schließen. Denn es kann sein, dass ich erwähne, was nicht vorkommt. Zwar nicht im Detail, aber eben so im Großen und Ganzen.

Insgesamt ist die Serie ja schon ein Phänomen: auf die erste Folge im Sommer 2011 folgten bis heute nur 12 weitere. Das reicht für einige amerikanischen Serien nicht einmal für eine halbe Staffel. Und trotzdem, oder wahrscheinlich gerade deswegen ist Sherlock so beliebt: er nutzt sich nicht so schnell ab.

Andererseits haben die Folgen auch immer gleich Spielfilmlänge und durch die großen Abstände der Veröffentlichung gibt es natürlich jedes Mal einen ungeheuren Druck, etwas besonderes abzuliefern. Wie besonders nun die vierte Staffel war, wird man wahrscheinlich erst mit ein bisschen Abstand sagen können. Fans werden die Staffel eh mehrmals anschauen und irgendwann mit den anderen Folgen vergleichen.

Das ist dieses Mal nur sehr schwer, da jede einzelne der drei Folgen dieses Mal nicht ganz so gut ohne die anderen zwei funktioniert. Spätestens seit der zweiten Staffel gab es immer noch eine Geschichte hinter den Geschichten, in dieser vierten Staffel treten die einzelnen Fälle der Folgen jedoch ein wenig mehr in den Hintergrund und es verbleibt die Gesamtgeschichte.

Das muss man nicht mögen, aber Detektivserien mit einem Hauptdarsteller, der besondere Fähigkeiten hat, gibt es ja wie Sand am Meer. Deshalb finde ich diesen Ansatz gar nicht mal so verkehrt. Zumal in dieser Staffel auch ein paar Eigenheiten der Figur Sherlock Holmes gezeigt werden, die man bisher vermisst hat, wenn man die Bücher kennt. Und auch sonst werden ein paar Geheimnisse gelüftet, die sich in den letzten Staffeln angestaut haben.

Wenn man enttäuscht ist, zeugt das ja auch davon, dass die Macher der Serie überraschen konnten. Das finde ich immer sehr wichtig. Und auch sonst habe ich mich bestens unterhalten gefühlt und werde sicherlich ab morgen auf die Ankündigung warten, wann es mit der nächsten Staffel weiter geht.

Die meisten APIs, mit denen man heute bei der Webentwicklung zu tun hat, sind RESTful und bisher habe ich mich damit beholfen, die Anfänge in PHP und curl zu entwickeln, genügend Beispielcode habe ich in diversen Projekten rumfliegen.

Müssen dann aber komplexere JSON-Strukturen im Body eines POST-Request übergeben und oebendrein auch noch Dateien mit übergeben, kämpft man schon mal mehr mit dem Code als sich mit der API zu beschäftigen. In solchen Situationen können API-Tools für den Mac eine große Hilfe sein.

In der Vergangenheit hatte ich bereits mal Postman und Insomnia ausprobiert. Beide Male nur mit einfachen Beispielen und damals auch in erster Linie um mich mal mit den Tools zu beschäftigen. Heute stand aber tatsächlich oben beschriebene Aufgabe an: JSON-Data per POST im Body übergeben, darunter eine Datei, als Base64-Encoded Parameter.

Dieses Mal habe ich mir einen weiteren Client angeschaut: Paw. Nachdem ich bei diesem Client irgendwann herausgefunden habe, dass man bei den Werten ein Kontextmenü aufrufen kann, taten sich dort sehr einfache Möglichkeiten auf, um gerade die Datei Base64-Encoded dort einzufügen: erst im Finder die Datei Kopieren und dann wird mit dem Kontextmenü eben der Base64-Encoder ausgewählt und die Datei eingefügt. Dabei taucht dann nirgends im Interface der tatsächliche Quelltext auf – also nur, wenn man es explizit im Request selbst anschaut. D.h. man kann jederzeit im Editor noch sehen, dass es sich bei dem Wert um Base64 der Datei handelt, die dort auch nur mit dem Namen angezeigt wird.

Bei den beiden anderen Clients konnte ich das JSON zwar auch einfach per Copy & Paste aus Paw übernehmen, aber die einfache Art und Weise, wie ich die Base64-Encoded-Datei hätte einfügen können, habe ich dort nicht gefunden.

Mein erster Eindruck dieser drei Clients spricht also klar für Paw. Der große Haken ist nur, dass er (inklusive Steuern) gut 63 € kostet, während die anderen beiden Clients kostenlos sind. Alle drei bieten auch irgendwelche Team-Funktionalitäten an, die ich nicht ausprobiert habe. Auch sonst können alle Clients Code generieren, wobei mir Paw dabei auch die meisten Optionen zu haben schien.

So lange ich also nur mit recht einfachen APIs zu tun habe, werde ich im Moment wohl noch auf die Anschaffung von Paw verzichten. Das kann sich aber evtl. bald ändern, da ein weiteres Projekt mit der Anbindung einiger APIs ansteht. Und schön ist dabei auch, dass man bei Paw die Dateien verschlüsselt abspeichern und so mit in das Projekt einchecken kann. So kann man auch schnell man prüfen, ob die Beispielanfragen noch alle funktionieren – und das auch durch Projektmanager oder technisch versierte Kunden überprüfen lassen.

Die SyFy-Serie Incorporated wurde letztes Jahr mit ziemlich viel Vorfreude erwartet – auch von mir. Science-Fiction in einer nahen Zukunft spielend, in der Regierungen von Firmen abgelöst wurden. Das alles klang interessant genug und der Trailer sah ebenfalls vielversprechend aus.

Inzwischen sind sieben Folgen rum und ich muss sagen, dass ich nach dem Ende dieser Staffel nicht mehr weiter schauen werde. Zu langweilig die Story und zu wenig wird erzählt, wie diese Zukunftsgesellschaft insgesamt funktioniert. Die Unterschiede zwischen den verschiedenen Schichten erscheinen viel zu groß, als dass dies so funktionieren könnte, wie es in der Serie gespielt wird.

Der Vollständigkeit halber hier noch der Trailer:

Vor ein paar Jahren habe ich mir einen Farblaserdrucker von Samsung gekauft: CLP-315W. Ab und zu hat der sogar drahtlos funktioniert, was eines meiner Kriterien bei der Anschaffung war. Heute bin ich froh, wenn ich ihn austricksen kann, was anderes als weiße Blätter auszuspucken.

Das liegt auch daran, dass der Toner leer, „abgelaufen“ oder eingetrocknet ist. Ich könnte mir also neuen bestellen. Der kostet aber gut 150,- €! Und da stellt sich dann wieder die Frage, ob sich das überhaupt lohnt, oder ob man erst einmal einen günstigen neuen Drucker ersteht – ich will eigentlich nur ein paar Seiten mit Skizzen für einen Bauantrag ausdrucken.

Dass das zwar finanziell durchaus richtig sein könnte, aber ökologisch eine halbe Katastrophe, kreisen die Gedanken also doch wieder um diese 150,- € für den Toner. Oder doch nur in verbleichtem grau ausdrucken? Ich glaube, ich schaue mal, ob ich am Wochenende in Kalmar einen Copyshop finde. Das wäre eigentlich die vernünftigste Alternative: mit USB-Stick bewaffnet dort vorbei und ein PDF ausdrucken lassen.

Copyshops… Auch so etwas, bei dem ich nicht gedacht hätte, dass ich da nach dem Studium noch mal mit zu tun haben würde.

Für ein neues Projekt stand ich vor der Aufgabe, verschiedene SVG und Beschriftungen in einer besonderen Schriftart zu kombinieren und am Ende als PNG/JPEG zur Verfügung zu stellen. Soweit, so gut, ImageMagick sollte all dieses können und mir auch in Form einer PHP-Bibliothek zur Verfügung stellen.

Da ich das neue MacBook Pro zum Anlass genommen hatte, alles komplett von Neuem zu installieren, war Homebrew zwar schon längst installiert, ImageMagick aber eben noch nicht. Ein paar wenige Befehle später meldete brew install php70-imagick den Vollzug. Blöderweise meckerte PHP trotzdem, dass es die Klasse Imagick nicht kennen würde. Ein Blick in die Ausgabe von phpinfo() ergab zwar, dass die INI-Datei der Extension verarbeitet wurde, ansonsten tauchte aber keine Information zu ImageMagick auf.

Nach ein paar hilflosen Neuinstallationen der Pakete, kam ich mal auf die Idee in die Error-Logs des Apache zu schauen. Und siehe da: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/opt/php70-imagick/imagick.so' - dlopen(/usr/local/opt/php70-imagick/imagick.so, 9): Library not loaded: /usr/local/opt/imagemagick/lib/libMagickWand-6.Q16.3.dylib\n Referenced from: /usr/local/opt/php70-imagick/imagick.so\n Reason: image not found in Unknown on line 0

Wie üblichen in solchen Fällen, googlet man nach der Fehlermeldung und landet unweigerlich bei Stackoverflow. Die Lösung dort sah harmlos genug aus und nach kurzem Anpassen auf meine Zwecke liess ich brew reinstall php70-imagick --build-from-source ausführen. Natürlich mit positivem Ausgang, so dass ich danach endlich mit der eigentlichen Aufgabe fortfahren konnte.

Als dann irgendwann eine erste Version fertig war, sollte diese natürlich auch auf den Staging-Server. Die Skripte dafür waren recht schnell eingerichtet, ein erster Testlauf brachte aber kein Bild zum Vorschein. Auch hier in die Ausgabe von phpinfo() geschaut, wo aber alles danach aussah, als wenn ImageMagick vollständig installiert war.

Unter den unterstützen Formaten tauchte aber SVG nicht auf! Und das, obwohl die Version auf dem Server nur eine Minor-Release älter war, als die, die ich lokal verwendete. Hier war dann die Lösung, zusätzlich noch das Paket imagemagick zu installieren, da dabei wohl etwas mehr enthalten ist, als wenn nur php70-imagick installiert wurde.

Ich freue mich jetzt schon darauf, wenn dieses eigentlich keine Modul irgendwann auch mal beim Kunden installiert werden muss. Aber immerhin kenne ich jetzt schon ein paar Fallstricke und bin so eigentlich gut vorbereitet.