dogfood

Tag: WebDev

Was war. KW#41

Things I did.

Die Planungen der Woche mussten umgeschmissen werden, nachdem ein für Mittwoch geplantes Briefing von Kundenseite aus, um eine Woche verschoben werden musste und ich damit kurzfristig 2–3 Tage zur fast freien Verfügung hatte.

Einen Tag schmiss ich gepflegt weg, als ich mich um fehlenden Festplatten-Platz meines Desktop-Macs kümmerte (nur noch 18GB frei), um das XCode-Update (7GB) zu installieren.

Das Problem ist das völlig verkorkste Festplatten-Management unter OS X:

  • Der Finder zeigt unter „xxx GB verfügbar“ irrerweise nicht den tatsächlich verfügbaren Festplattenplatz an, sondern eine Zahl, die belegten, aber „löschbaren“ Festplattenplatz dazu addiert. Bei diesem “löschbaren” („cancellable“) Platz scheint sich um Backups, Caches und iCloud-Dateien zu handeln. Einen „Knopf“ zum Löschen gibt es nicht. Angeblich soll sich das System selber darum kümmern.

    Die tatsächliche Größe des freien Festplattenplatz erfährt man nur durch andere Tools oder per Kopfrechnen bei den Festplatteninfos: Festplattenkapazität minus Benutzter Platz.

  • Selbst nach „harten“ Löschen (am Papierkorb vorbei) zB. der 60GB Musik, wurde der unbelegte Festplattenplatz nicht größer. Nach einem Neustart schrumpfte der freie Festplattenplatz gar auf 7GB, ehe er im Laufe von 5 Minuten wieder auf 18 GB anwuchs – bar jeder Logik.

  • Der eigentliche Übeltäter ist die Time Machine, Apples Backup-System. Auch wenn er angeblich nur 7GB „backupen“ wollte – einige Minuten nach Ende des Backups waren dann plötzlich 150GB Festplatte frei.


Donnerstag, Freitag, Samstag habe ich mit Lesen von „Fachartikeln“ verbracht. Siehe unten.

Am Freitag habe ich für ein privates Projekt mit dem Endziel „React“ mal in die Themen MariaDB, ORM und Node.js reingeschnuppert und einen ersten Durchstich gemacht. Beim Evaluierung des Node.js-ORMs „Sequelize“ tauchte „LoopBack“ auf dem Radar auf und lockte mit großer Mächtigkeit und den magischen Worten „API-Endpoints“ auf – eine Evaluierung am Montag zeigte aber die Unbrauchbarkeit. LoopBack 4 sollte realistischerweiser nur mit TypeScript verwendet werden, und das ist mir im Kontext meines Endziels, zu weit aus dem Fokus raus.

Things I read.

Bereits am Donnerstag verbloggt, aber es treibt mich immer noch herum: Programming as Theory Building, ein Papier von Peter Naur von 1985. Demnach ist Code von Software nur ein „Artefakt“ der eigentlichen Arbeit eines Programmierers: dem Aufbau eines Verständnisses für die zu bewältigenden Problemen, den Anforderungen, den erforderlichen Funktionen und den Weg, den man beschreitet, kurz: dem Aufbau eines theoretischen Verständnisses der zu bauenden Software.

Dieser Blickwinkel hat Konsequenzen wie man mit Teammitgliedern/Kunden über das Software-Produkt spricht und wie man es dokumentiert. Anstatt sich in der Kleinteiligkeit von Code-Zeilen zu verlieren, gilt es Ideen, Ansätze und Motivation zu beschreiben.

1985 geschrieben, trifft er aber genau einer der Schmerzpunkte die ich als Frontendler mit der Zusammenarbeit von Designern habe, die auch 2019, kein „Theory Building“ entwickeln, sondern Photoshop- oder Sketch-Dateien liefern. Ich darf dann raten, ob die 512px breite Spalte fix 512px oder 50% der Viewportbreite eines Tablets breit sein soll – weil des Designers Liefergegenstand nur eine Zustandsbeschreibung eines Viewports liefert, aber nicht die übergeordnete Idee des Designers vermittelt, was er sich dabei gedacht hat.


Zu meiner Überraschung schneite in meiner Twitter-Timeline der Hinweis rein, dass Sass, der CSS-Transpilator, in der ersten Oktober-Woche das einschneidendste Update der letzten fünf Jahre erfuhr – und keiner meiner abonnierten Frontend-Mailinglisten hielt es bis heute für nötig darauf hinzuweisen.

Sass hat sich in seiner neuesten Version ein Modul-System angelacht – vorerst nur auf der „führenden“ Sass-Implementierung Dart-Sass (Libsass und damit Node-Sass hinken hinterher).

Dies wird IMHO das Arbeiten mit Sass auf komplett neue Beine stellen – aber zu meiner Überraschung herrscht in der Frontend-Szene Schweigen im Walde. Ein Artikel bei css-tricks.com mit schlappen 5 Kommentaren. Totentanz dagegen bei Reddit und Stackoverflow.

Mit dem neuen Modul-System über den Befehl @use will Sass Partials bzw Module so kapseln, wie man es von JS-Modulen gewohnt ist – also kein globaler Zugriff auf Dinge die in den Partials stattfinden, sondern nur explizit deklarierter Zugriff.

Per Bauchgefühl bin ich recht begeistert, denn mein Gros an Bezahlarbeit findet in sehr großen Projekten statt und der Einzug eines Scopes für Sass, hört sich auf dem Papier gut an. Aber nach Lesen der Dokumentation habe ich exakt null Gefühl für die tatsächliche Implementierung (wie verändern sich Projektstrukturen?) und den tatsächlich relevanten Vorteilen.

Macht JS-artiges Scoping Sinn für CSS und dem „scope-losen“ HTML-Markup? Was macht SCSS-Scoping mit custom properties oder Scopes wie Shadow DOM und <style scoped>? Da hätte ich mir vom Sass-Team etwas mehr Hinweise auf sinnvolle Anwendungen in der freien Wildbahn gewünscht – man komme mir bitte nicht mit „Theming“.

Things I watched.

Am Samstag lief den ganzen Tag der Stream des japanischen Auslandssender „NHK World“, die die Taifun Hagibis-Sondersendungen aus dem Inlandsfernsehen übernahmen und auf englisch simultan übersetzten.

Ich habe mir On-Air-Designs angesehen und einige Übersetzungs-App angesehen, die über die Handy-Kamera eingeblendete japanische Schriftzeichen „live“ ins Deutsche übersetzten.

  • In Japan ist der Farbcode für höchste Gefahrenstufe nicht Rot, sondern Violett und dann Schwarz.
  • Japanische Moderatoren tragen fast ausnahmslos Nadelstreifenanzüge.
  • Wenn ein*e Moderator*in auf etwas an einer Videowall zeigen will, dann wird nicht ein normaler Zeigestab genommen, sondern ein Stab mit einem dicken Bommel am Ende.
  • Das japanische Schriftsystem wird problemlos sowohl horizontal als auch vertikal eingesetzt – ein Traum für das Screendesign.

Am Sonntag habe ich die erste Folge von „Doom Patrol“ auf Amazon gesehen – nach der gleichnamigen Comic-Serie von DC. Heute habe ich die Folgen 2+3 gesehen. Ich denke, man tut gut daran, die ersten drei Folgen am Stück zu sehen, da erst die dritte Folge den vorherigen Folgen einen Zusammenhalt gibt. Auf der anderen Seite ist es eine Form der Vergeudung (oder Minutenschinderei) für jenen Zusammenhalt fucking drei Stunden zu brauchen.

Abschließendes Urteil steht noch aus – ich habe parallel mir das erste Trade-Paperback der Serie aus der Grant Morrison-Ära geholt, auf die sich auch die TV-Serie beziehen soll. Inhaltlich fängt es noch wüster an und zeichnerisch ist das dunkelstes US-Comic-Mittelalter.

Things I listened to.

Hinter der Paywall, hat die „Financial Times“ eine schöne Serie: „Life of a Song“, in der die FT auf die Geschichte eines Lieds und seiner Cover-Versionen eingehen. Diesmal ist es Sittin’ On The Dock of the Bay“ von Otis Redding.

Der Artikel hat mir noch stärker die Größe dieses Titels offenbart. Otis Redding verstarb bei einem Flugzeugunglück kurz bevor er die Produktion von „The Dock of the Bay“ abschließen konnte. Es war Steve Cropper, der aus den einzelnen Aufnahmen, den Song zusammen bastelte. Das ikonische Pfeifen am Ende war nur ein Improvisorium von Redding, der für diese Stelle später noch einen Text schreiben wollte.

Wie perfekt das Original, mit seinem depressiven Text ist, erkennt man an den zahlreichen zerschellten Cover-Versionen. Die blutleere Version von Willie Nelson und Waylong Jennings, die Kasperle-Version von T-Rex und Gloria Jones, die mit Rod-Stewart-Mayonaise zugekleisterte Variante oder die Vergewaltigung durch das Tom Jones-Vibrato (Props für die Einbindung von Steve Cropper) oder das testosteron-getriebene, bemühte „Method Acting“-Cover von Justin Timberlake (auch hier Props für die Einbindung von Steve Cropper).


Zur Entgiftung von den ganzen katastrophalen Cover-Versionen, hier eines der besten Cover der Musikgeschichte überhaupt: Tom Petty und Freunde mit „While My Guitar Gently Weeps“ bei der posthumen Aufnahme von George Harrison in die Rock & Roll Hall of Fame. Der schüchterne Junge an der Gitarre neben Tom Petty ist Dhani Harrison, der Sohn von George. Im hinteren Teil des Covers rückt dann Prince in den Vordergrund, der eines meiner Lieblings-Gitarren-Solos derart abfackelt, dass dem Harrison-Sohn die Freunde nur so aus den Augen sprüht. (Und Tom Petty ist sowieso die Idealbesetzung für den Gesang)

Watching: “A Branch in Time – a story about revision histories”

Gesehen: der Vortrag von der RubyConf.au „A Branch in Time – a story about revision histories“ von Tekon Süleyman.

Auf der Basis einer fiktiven Geschichte einer Entwicklerin, verdeutlicht Süleyman, welche zentrale Rolle Git in Projekten einnimmt – nicht nur als bloßes Source-Verwaltungs-Werkzeug, sondern idealerweise als Dokumentation, warum bestimmte Dinge im Code so umgesetzt worden sind, wie sie umgesetzt wurden. Das ist eine weitaus weniger banale Frage, als es sich für Außenstehende anhört.

Süleyman dockt seine Geschichte und Vorschläge an ein Thesenpapier von Peter Naur an: „Programming as Theory Building“ (PDF).

Programmieren ist demnach nicht die Produktion von Code, sondern der Aufbau einer Theorie oder eines Gedankenmodells, wie die Software zu arbeiten hat. Code ist demnach nur ein Artefakt/Ausdruck dieser Denkprozesse.

Software-Projekte werden fast nur noch iterativ (in kleinen Schritten) entwickelt. Schritt für Schritt wird innerhalb des Teams das oder die Gedanken-Modelle entwickelt. Aber es gibt keine Prozesse und kein Format, um die entwickelten Modelle expressis verbis niederzuschreiben und dann weiter zu entwickeln. Stattdessen handelt es sich um „institutional knowledge“, also eine Art kollektives Wissen, dass sich entwickelt.

An dieser Stelle ist Code der Ausdruck für eine konkrete Umsetzung: “was ist wie umgesetzt worden”. Git kann und sollte an dieser Stelle die Rolle spielen, die Motivation und Abwägungen, also das „warum ist es so umgesetzt worden“, zu dokumentieren. Für Git Commits gilt daher der Leitsatz: „Capture the why, not the what“.

Naur geht in seinem Papier so weit, und spricht von einem Sterben der Software, wenn das Entwicklungsteam aufgelöst wird. Mit dem Verschwinden des kollektiven Wissens, schwindet auch die Wartbarkeit der Software.


IMHO setzt der Zerfall von Software schon sehr viel früher ein: wenn unter Zeitdruck und/oder Komfort Abkürzungen genommen werden. Das Wissen wird statt eines „nachschlagbaren“ (dokumentierten) Kollektiv-Wissens, zu einem individuellen Wissen, zu einem Herrschafts-Wissen.

Es fängt mit Petitessen an. Aber wenn der Damm löchrig ist, ist der Dammbruch nicht weit.

Code-Reviews können nicht mehr sauber geführt werden, weil der zu prüfende „Soll-Zustand“ für den Reviewer nicht mehr nachzuvollziehen ist. Die Code-Review verkommt zu einem menschlichen Linting-Prozess.

Es schleichen sich immer stärkere Inkonsistenzen ins Projekt rein, weil es keine eindeutige Referenz mehr gibt, sondern mehrere entstanden sind. Es gibt mangels eindeutiger Referenz keinen Konsens mehr, was richtig oder falsch ist, sondern nur noch mehr oder weniger kompetente Interpretationen.

Das Entwicklungstempo wird abnehmen. Entwickler, die einen anderen Teilausschnitt des „kollektiven Wissens“ haben, werden den Code falsch interpretieren oder andere Rahmenbedingungen bzw. Maßstäbe anlegen und Probleme mit dem Bestandscode bekommen.

Ich weiß nicht, wie dieser Kreislauf rückgängig zu machen ist.

© 2019 Kai Pahl

Theme basiert auf „Lingonberry“ von Anders NorenNach Oben ↑