Vor ein paar Tagen gab es einen albumup-Bugreport — die Galerieanssicht lud nicht vernünftig. Kurz ausprobiert, reproduziert, erstmal ein altes JavaScript-Bundle hochgeladen, was ich noch rumliegen hatte — klappt wieder. Ein Glück, wenn man vergessen hat die kompilierten Files ins Gitignore zu packen.

Heute versuchte ich zu herauszufinden, was da passiert. Der Chrome Task Manager ist dabei immer eine große Hilfe. Der Tab brauchte konstant 150% CPU und fraß immer mehr Speicher. Da war wohl was kaputt!

Normalerweise ist ja git auch sehr hilfreich bei solchen Sachen. Was habe ich wohl kurz vor dem letzten Live-Deployment kaputt gemacht? Ich ging alle Commits durch und fand… nichts. Am Galerie-Code hatte ich schon länger nicht mehr gearbeitet. Weil ich sonst absolut keine Idee mehr hatte, dachte ich, ich fange mal an ein paar Zahnräder aus dem System zu entfernen, um den Fehler einzugrenzen. Also einen Development-Build mit webpack durchgeführt, ohne Uglify und anderen Optimierungen. Tatsache, es funktioniert. Also erstmal einen grumpy Tweet abgesetzt und weiterprobiert.

In der Developer Console kam jedenfalls folgende Meldung:

Interessant, was? Hier muss man dazu sagen, dass die Meldung da schon länger ist und ich sie immer ignorierte, weil alles ja weiter funktionierte und ein kurzer Blick auf den Code den endlosen Loop nicht sofort erkennen ließ. Außerdem ist es ja nur eine Warning.

Tatsächlich ist es nun aber so, dass Vue im Development-Mode die Loops erkennt, abbricht und mit einer Warning versieht — damit hat man zwar ein paar rote Zeilen im Inspektor, dafür funktioniert die App aber an sich gut weiter. Im Production-Mode hingegen fehlt die Warning und alles läuft fröhlich im Kreis, bis der Browser stockt und der Macbook-Lüfter aufheult. Schade!

Irgendwie hatte es jedenfalls beim vorletzten Deployment ein Dev-Build auf den Server geschafft, was aber ganz glücklich war, denn der funktionierte wenigstens gut. Erst als ich vor ein paar Tagen aufräumte und einen vernünftigen kleinen Build auf den Server schob, ging alles kaputt.

Der Loop kam übrigens durch diese Zeilen Code:

displayFolders() {
    let folders =  this.$store.state.folders;
 
    const collator = new Intl.Collator(
        undefined, 
        {numeric: true, sensitivity: 'base'}
    );

    folders.sort(function(a, b) {
        return collator
            .compare(a.display_name, b.display_name);
    });

    return folders;
}

Die Funktion ist eine Computed Property, die jedes mal neu berechnet wird, wenn sich this.$store.state.folders ändert… und leider hab ich wohl vergessen, dass .sort ja den Array direkt sortiert und damit natürlich den State direkt ändert, was dazu führt, dass die Funktion erneut aufgerufen wird, was dazu führt, dass der State direkt geändert wird, was dazu führt, dass die Funktion aufgerufen wird…

Der Fix war auch erstmal relativ easy:

    let folders =  clone(this.$store.state.folders);

(Ja, das sollte eher in einen Getter, etc etc, mit Immutability wär dir das nicht passiert, etc etc)

Die Moral von der Geschichte: Danke Vue für hilfreiche Fehlermeldungen, die man aber auch nicht ignorieren sollte.

2      11. April 2018

Ende Januar berichte ich hier, wie ich mir keine M100 kaufte — ein paar Monate, nachdem ich mir die M5 kaufte und zurück schickte, weil sie mir nicht so richtig zusagte.

Auch wenn ich den Post mit den Worten “Warum denke ich überhaupt über Kameras nach, wenn die Bearbeitung immer so eine Mammutaufgabe ist? 🙈” abschloss, kümmerte ich mich natürlich nicht drum, viele Fotos zu bearbeiten, sondern recherchierte weiter, was die Welt der spiegellosen Kameras für mich bereit hält.

Zuerst war da die Fuji X-A5-Ankündigung. 599€ inklusive einem Objektiv mit brauchbarer Brennweite, man kann Fotos machen, es gibt einen Mikrofon-Jack, ja warum nicht. Ich lieh mir sogar Chris’ X-T20 für ein Wochenende, um mal zu schauen, wie mir Fuji so liegt. So richtig begeistert war ich nicht, was nicht zuletzt am schlechten Wetter (oder Berlin) lag — mittlerweile gab es aber sowieso Gerüchte, dass Canon noch vor Ende Februar eine neue Spiegellose ankündigen wird. Etwas verwirrt, da die M5, M6 und M100 jetzt ja so Schlag auf Schlag kamen, harrte ich also aus und verfolgte täglich die neusten Entwicklungen bei CanonRumors.

Tatsächlich wurde die EOS M50 angekündigt. Neuer Sensor, Überall-Hinklapp-Display und, man mag es kaum glauben, es ist immerhin Canon: 4k-Video. In 24 FPS! Dazu kommt der von mir sehr gewünschte Mikrofon-Eingang. Das klang für mich erstmal viel zu gut um wahr zu sein. Als der Preis bekannt wurde, war ich noch überraschter. Nur 579€. Das ist weniger als die Hälfte von dem, was mich die M5 vor 5 Monaten gekostet hätte.

Ich bestellte direkt im Canon Store vor. Zunächst nur das Kit, Body-only gab es nicht. Dazu noch bei Calumet (support your local dealer!) und Amazon, als es da auch zwei Wochen später verfügbar war. Am 27. März sollte geliefert werden. Am Ende wurde es tatsächlich ein Body aus dem Canon Store, da Calumet mir kein Lieferdatum nennen konnte und Amazon das Lieferdatum einen Tag vor Erscheinen um zwei Wochen nach hinten verschob.

(Ja, ich bekam erst das Kit, bestellte den Body hinterher, da der am Release-Tag auch im Shop freigeschaltet wurde — der kam direkt am nächsten Tag an.)

Mittlerweile war ich ein bisschen mit der Kamera unterwegs (Low-Light-Performance bei einer Rathausführung und ein normaler sonniger Kurzurlaub) und hier sind, ungeordnet, meine ersten Gedanken:

Autofokus

Der Autofokus funktioniert echt gut. Dual Pixel hält, was es verspricht. Es ist ein bisschen schade, dass der Augen-Autofokus nur in Kombination mit so einem “Zone”-Autofokus geht, ich würde mir wünschen, dass man den auch mit dem “ich hab einen AF-Punkt in der Mitte”-Modus kombinieren könnte.

Über den Touchscreen kann man den AF-Punkt mit dem Finger verschieben, was ganz praktisch ist. Auch während man durch den Sucher schaut — hier sollte man einstellen, dass nur ein Teil des Screens dafür benutzt wird, ansonsten verstellt man sich ständig mit der Nase den Autofokus. Insgesamt passierte es mir ein paar mal, das der Punkt nicht da war, wo er hinsollte. Hätte gerne noch eine Möglichkeit ihn ganz fix zu setzen.

Displays

Kann man nicht meckern. Das Klappdisplay klappt überall hin, der elektronische Sucher ist auch in Ordnung — bisher benutze ich ihn aus Gewohnheit noch mehr. Tatsächlich hatte ich das hintere Display oft in der “Schutzstellung” und hab nur den Sucher verwendet, auch mal ganz schön, wenn man nicht ständig kontrolliert, wie das Bild aussieht.

Die Umschaltung zwischen Display und EVF funktioniert problemlos, mit dem typischen Delay halt. Ist okay. Ich hab mir die manuelle Umschaltung trotzdem auf einen Knopf gelegt.

Bedienung

Ja, es ist eine Einsteigerkamera. Abgesehen von den Spielzeug-DSLRs/Point and Shoots ist es wohl eine der billigsten Kameras, die Canon im Angebot hat. Tatsächlich merkt man das aber nur an ein paar Sachen, wie zum Beispiel, dass es viel zu wenig Knöpfe und Räder gibt, und dass die vorhandenen viel zu klein sind. Naja.

An das meiste kann man sich gewöhnen, dass man nicht Blende und Belichtungskorrektur mit zwei einzelnen Rädern ändern kann, nervt allerdings schon etwas.

Eine weitere Einschränkung scheint zu sein, dass man die Kamera nur über einen versteckten SCN-Szenenmodus in einen Silent Mode stellen kann, wo nur der elektronische Shutter benutzt wird und sie damit… ihr ahnt es… silent wird. Da kann man aber nur umständlich hin navigieren und hat dämliche andere Optionen drin. Warum ist das nicht einfach eine Option im Drive-Menü?

Videos

Full HD bis 50 FPS, 4K in 24 FPS, da kann man sich nicht beschweren. Doch natürlich kommt letztes mit einem kleinen Catch, wir wären ja sonst nicht bei Canon (und — naja — nicht im Niedrigpreissegment): Wenn man in den 4K-Modus geht hat man zusätzlich zum 1,6-fach-Crop nochmal einen 1,5-fachen Extra-Crop. Besser wäre es natürlich ohne, aber man kann damit leben. Mit dem EF-M 11-22mm kommt man da auf etwa 26mm, das reicht gerade noch für ein Selfie — besser war das bei dem Camcorder, den ich zwischendurch hatte, auch nicht.

Tatsächlich habe ich die Video-Funktion noch nicht genug benutzt, um irgendetwas dazu sagen zu können.

Akkuleistung

Eine Sache, mit der man natürlich jetzt leben muss. Canon gibt circa 300 Bilder pro Akkuladung an, vielleicht stimmt das sogar. Egal, einfach immer zwei oder drei dabei haben, dann ist man auf der sicheren Seite. Aktuelle, teure, spiegellose sind da mittlerweile weiter (die Sony A9 soll echt gute Akkus haben!), aber wir sind hier ja Einsteigerklasse.

Geil wäre es, wenn man die Kamera wenigstens per USB-Akku laden könnte. Leider scheint das nicht so einfach zu sein, das zu integrieren, daher hat Canon hier natürlich, wie bei allen anderen Kameras, darauf verzichtet. Schade.

Gewicht

Geil! Man merkt fast nicht, dass man sie dabei hat.

Crop

Das Crop-Life nervt mich ziemlich. Also vor allem, weil ich kein Objektiv mehr habe, was nicht viel zu lang ist am Crop. Mein 40mm-Pancake ist schon grenzwertig, 50mm, 85mm, 70-200mm. Erst vor ein paar Monaten verkaufte ich mein 28mm/1.8, weil ich dachte, dass ich eh nie wieder eine Crop-Kamera besitzen werde. Falsch gedacht!

Für die M50 hab ich nun das oben erwähnte 11-22mm, an und für sich, so für Draußen und Licht ist das auch ganz toll, bei einer Wanderung durch das Hamburger Rathaus hätt ich mir aber doch öfter etwas mehr Lichtstärke gewünscht — hatte das 16-35mm/2.8L aber nicht dabei.

(Letzteres könnte ich natürlich allgemein als weites Objektiv dran benutzen, aber es wiegt mehr als die Kamera und das ist ja auch nicht im Sinne des Erfinders)

Im Laufe des Jahres soll wohl noch ein 32mm/1.4 oder so kommen, das klingt an sich schonmal gut. Mal sehen, wie teuer es wird.

Bildqualität

Bisher bin ich ganz zufrieden. Jetzt, wo ich mir die Bilder mal genau angucken kann, weil Lightroom CC auch das neue CR3-Format versteht, habe ich nichts groß auszusetzen. Farblich sieht das alles aus wie aus der 6D, bei wenig Licht rauscht es aber schon spürbar mehr — schon überraschend, wieviel Vorsprung der alte 6D-Sensor da noch hat, nur weil er etwas größer ist.

Ich halte euch natürlich, wie beim Macbook, auf dem Laufenden, was sich noch ergibt und verbleibe mit einem positiven Ersteindruck. Die spiegellose Technik ist mittlerweile auf jeden Fall so weit, dass ich mich auf den ersten Vollformat-Aufschlag von Canon freue, der hoffentlich spätestens 2019 kommt. So lange greife ich aber auch noch sehr gerne zur 6D. Wiegt zwar etwas mehr, aber man hat dafür auch was in der Hand.

3      11. April 2018

Nebenbei bauen Flo, Pablo, Hannah und ich ja immer noch an albumup.com — mittlerweile haben wir auch ein paar zahlende Kunden. Um mal ein bisschen Fahrt aufzunehmen, dachten wir uns, dass es eine gute Idee wäre, ein bisschen Content zu erstellen und die Seite über einen Blog etwas aufzuwerten. Einerseits als Ort, an dem man unsere Historie (Startup Weekend 2015 bis jetzt) nachvollziehen kann und andererseits eine Quelle für interessante Fotografen-Inhalte!

Da Flo noch an einer anderen Baustelle bastelt, dachte ich mir, ich löse das Problem mal schnell. Kann ja nicht so schlimm sein, kurz einen Blog einrichten. Was sich daraus entwickelte, ist ein wochenlanger Leidensweg, der natürlich nicht zuletzt auf meinen endlosen Perfektionismus zurück zu führen ist.

Zu allererst dachte ich natürlich, ich richte einfach fix ein WordPress ein. Was soll’s. Kurz installiert und versucht unter albumup.com/blog zum Laufen zu kriegen. Vergeblich. Also — das Problem hier war, dass ich das WordPress natürlich nicht ins /public-Verzeichnis von unserer Lumen-App packen wollte, es sollte schon ein eigener nginx-vhost sein, halt per Proxy auf /blog umgemünzt. So richtig hatte WordPress aber keinen Bock auf den Proxy-Kram, vor allem das Backend ging gar nicht.

Naja. Um ehrlich zu sein hatte ich eh keine Lust auf WordPress.

Da ich vor Jahren schonmal was mit Cockpit gemacht hatte, war das mein nächster Gedanke. Kurz die nötigen Dateien ins /public-Verzeichnis geworfen (da bröckelte schon mein erster Vorsatz) und angeguckt. Leider sah ich nichts. Die aktuelle Version von Cockpit ist eine PHP 7.1-App. Geil! Also, an sich. Schade leider für mich, da meine lokale VM, in der albumup liegt, immer noch auf PHP 5.6 basiert. Aber ich wollte das ja eh mal umziehen…

Minuten später hatte ich also eine PHP 7.1-VM (albumup hat eine halbwegs funktionierende Ansible-Config, juchu). Ich war schon kurz davor, kurzerhand den Live-Server umzustellen, schaute mir zur Sicherheit aber doch nochmal alles ganz genau an. Tja. Leider hat eine Dependency von Lumen ein Problem mit 7.1. Furchtbar.

Mein nächster Gedanke: Okay, update ich halt Lumen. Direkt wieder verworfen, denn Lumen nervt mich eigentlich eh, quasi seit damals, als ich mich dafür entschied, keine Laravel-App daraus zu machen. Warum nicht kurz eine frische Laravel-App generieren, die paar Dateien rüberkopieren und albumup PHP 7.1-ready machen, wäre das nicht toll?

Nachdem ich einen Abend damit verbrachte und leider nicht fertig wurde, entschied ich mich beim nächsten gemeinsamen Abend dafür, das erstmal beiseite zu legen und mich aufs Grundthema zu konzentrieren: Ein Blog für albumup. Doch was?

Kirby? Irgendwas in mir wehrte sich dagegen, noch ein weiteres Kirby aufzusetzen, bevor Kirby 3 fertig ist.

Statamic? Kostet zu viel Asche.

Hugo, Jekyll, andere Static Site Generatoren? Ich hätte schon gern ein Web-Interface.

Diverse andere CMS-/Blog-Systeme hatten entweder keinen Bock auf PHP 5.6 oder sahen viel zu kompliziert aus für einen einfachen Blog.

Nach ausgiebiger Suche fand ich Grav, setzte es auf, ärgerte mich pausenlos über das absolut hässliche Backend und passte das Template an. Das ganze Ding mag ja ein okayes CMS sein, aber für einen einfachen Blog war mir das alles viel zu unübersichtlich. Furchtbar. Ich bekam es zwar recht schnell fertig, war aber mega unzufrieden.

Im abschließenden Gespräch meinte Flo, warum wir es nicht einfach über Markdown-Files im Git machen. Puh. Gute Frage. Also klar, ich hatte da auch schonmal drüber nachgedacht, aber ich wollte ja zum Einen, ha ha ha, nicht so viel Zeit investieren (eigene Logik zum Darstellen der Posts, etc etc) und zum anderen eigentlich gern ein Web-Backend um die Posts zu editieren.

Jetzt kann man sich schon denken, was passiert ist. Durch die absolute Unzufriedenheit mit meiner Grav-Lösung (die ja auch wieder eine zusätzliche, zu pflegende, Software darstellt) entschied ich mich dafür, doch eben die homebrew Markdown-Lösung zu bauen. Nach ca. 45 Minuten war das fertig.

Rechnet man da jetzt noch anderthalb Stunden fürs Styling dazu, die ich ins Grav-Template investierte (was ich zum großen Teil übernehmen konnte) hätte ich das ganze Ding also in nicht mal drei Stunden abfrühstücken können, statt mich an insgesamt drei Abenden um Gott und die Welt zu kümmern — oder mich halt einfach mit WordPress auf blog.albumup.com zufrieden geben können.

Herrje.

(Aktuell ist der Blog noch nicht online, jetzt fehlt nur noch der Content!)

5      9. April 2018

Weil ich das Tool im Büro schon öfter brauchte, aber nichts passendes fand, nahm ich mir mal eine Stunde Zeit und baute es! Und weil ich gerade Lust hatte, einen Screencast dazu aufzunehmen, dachte ich mir, es wäre vielleicht ganz witzig, das auch in einer Stunde durchzuziehen.

Daraus entstanden sind nun vier 15-Minuten-Häppchen, die ich einfach alle auf einmal hier verlinke, weil ich echt keine Lust habe, da jetzt jede Woche einen rauszuhauen, meine Zielgruppe der Leute, die anderen gerne beim Coden-und-Labern zugucken/hören ist nämlich ziemlich klein, fürchte ich.

Wozu das Ding überhaupt? Es passiert relativ häufig im Büro, dass ich mir Prozesse für Dinge ausdenke, die aber nirgens notiere. Das kann alles sein, angefangen vom Deployment einer Webseite (ja, ich wünschte, ich würde in einer Welt leben, in dem jedes Kundenprojekt einfach den gleichen standardisierten Deployment-Prozess hat), bis hin zu “Auf Seite XYZ einen neuen Download einfügen, welche drei Variablen muss ich anpassen”. Falls man mal krank wird, oder vergesslich, wäre es natürlich toll wenn man das mal aufgeschrieben hätte.

Leider fehlte mir dazu bisher das Tool. Also klar, ich könnte das in Things aufschreiben, aber damit ist es unteilbar und nach jedem abhaken müsste es wieder “resetted” werden. Ein Google Doc ist auch blöd, da kann man nichts abhaken. Im Redmine haben wir zwar Checklists, aber für jedes abarbeiten einer Checklist ein neues Issue anlegen ist auch dämlich. Daher nun dieses super simple Checklist-Tool, welches es natürlich auch bei Github gibt.

Das Feature-Set ist überschaubar: Anlegen und editieren von Checklisten. Diese können abgehakt werden und das wird sogar noch dokumentiert, wenn man auf Speichern klickt. So kann man z.B. auch nachvollziehen, wer jetzt das Deployment versaut hat — wenn man das möchte. Wer den Screenshot im Github mit dem Endergebnis im Video vergleicht, wird erkennen, dass ich doch nochmal eine Stunde investiert habe um zumindest ein bisschen Bootstrap-Styling einzufügen.

10      3. April 2018

Vierte und vorerst letzte Folge meines Screencasts zum Thema hej.world-Editor. Diesmal optimiere ich den Bilderpool etwas und bin damit erstmal Feature-Complete. Jetzt wird erstmal die Fuerteventura-Galerie fertig gemacht!

0      26. March 2018
Youtube-Empfehlung

Red Curtain Show

Willkommen zu meiner neuen Reihe die tollsten Youtube-Channel im Internet. Heute: Red Curtain Show. Adrian und Michel sind eingefleischte Musical-Fans und die Videos sind witzig und leben vor allem von der Chemie zwischen den beiden! Manchmal gibts auch Interviews und Kram. Wahrscheinlich nur für Musical-Fans interessant, aber so einer bin ich nunmal!

0      23. March 2018
Impressum / Datenschutz