dogfood

Tag: WebDev

Was war. KW#48

Things I did.

Letzte Woche hatte ich Urlaub. Letzten Sonntag bin ich für drei Tage nach St. Peter-Ording (präziser: „Bad St. Peter“) gefahren, wo es mir vor zwei Jahren so gut gefallen hatte und was damals für meine „emotionale Hygiene“ so wichtig war. Diesmal bin ich nicht ganz so geflasht zurückgekommen.

  • Dieses Jahr lag der Urlaub ca. vier Wochen später. Diese vier Wochen zwischen Ende Oktober und Ende November machen bei den Läden/Restaurants vor Ort einen großen Unterschied. Viele Läden haben geschlossen oder ihre Öffnungszeiten verändert. Google Map is shit und die Websites der Geschäfte/Restaurants sind nur manchmal hilfreich.
  • Das Wetter war ein gelangweiltes Grau in Grau. So gut wie kein Wind – für Windstille bin ich eigentlich nicht an die Nordsee gefahren. So gut wie keine Sonne. Temperaturen im Niemandsland zwischen kalt und warm.
  • Drei Tage waren für Alltags-Detox zu wenig. Erst am dritten Tag fingen der Kopf an, den Alltag loszulassen – aber dann war auch schon Abfahrt. Mein Fehler.

Grundsätzlich bleibt aber die Landschaft geil – Spazierengehen durch die endlosen Weiten des Wattenmeers und Salzwiesen ohne eine Menschenseele zu treffen.

St. Peter Bad, Wattenmeer

Things I worked on.

Vor und nach dem Kurzurlaub hatte ich zwei Websites eines Kunden zu aktualisieren. Anlass war der Umzug des Geschäftssitzes. Für mich war das vor allem der Tritt in den Allerwertesten, endlich mit einem Vorhaben fortzufahren, was schon seit einem Jahr auf meiner To Do-Liste steht: das Umschwenken von (Kunden-)Websites weg von cloudbasierenden Webschriften von Typekit hin zu selbst gehosteten Schriften.

Typekit ist vor Jahren von Adobe übernommen worden. 2018 hat Adobe dann den Wechsel der Preisstruktur von Typekit weg, hin zu dem überteuerten Adobe Cloud-Rip-Off angekündigt, der für mich irgendwann 2020 in Kraft treten würde. Seit dem habe ich bei etlichen Schriftenbundles von „Design Cuts“ zugeschlagen, um ein Portfolio an Webfonts aufzubauen – nur für die Umstellung der Sites fand ich noch keine Zeit.

Die Umstellung der ersten Website nahm viel Zeit in Anspruch. Die Site ist 2004 entstanden und das Projekt wurde von mir fast auf den Tag genau, vor fünf Jahren, 2014, auf Grunt umgestellt – mit all den Problemen die es zB mit SCSS inzwischen macht. Grunt hat, ähnlich wie Gulp, inzwischen das Ende seiner Lebenszeit erreicht. Deswegen habe ich den Scope „Umstellung auf eigene Webfonts“ zu „Wechsel auf einen ’zukunftssicheren‘ (YMMV) Task-Runner“ aufgebohrt.

Als Frontend-Entwickler rauscht über Twitter und Newsletter immer eine gewisse Nachrichtenlage über angesagte Frontend-Dinge vorbei. Daraus entstand bei mir der Eindruck, dass WebPack in Sachen Task-Runner „state of the art“ sei und begann am Tag vor dem Urlaub, dieses mal anzutesten und Grunt raus- und Webpack rein zu schmeissen.

Am frühen Abend bekam ich dann die Kinnlade nicht mehr geschlossen – so erstaunt war ich über das Ergebnis, dass WebPack als Task Runner für Dinge jenseits eines JavaScript-Fokus im Grunde genommen nur ein notdürftiger Hack ist. Das für mich so offensichtliche Ergebnis, entsprach so gar nicht dem Bild, den viele Artikel im Frontend-Bereich vermitteln. Im Nachhinein erkläre ich es mir damit, dass viele Entwickler im Bereich der JS-Frameworks wie React, Vue, Angular & Co. mit WebPack einen Hammer bekommen haben und damit nur noch Nägel zum Reinschlagen sehen.

Meine Probleme mit der WebPack-Verwendung außerhalb der JS-Welt, zB für SCSS/CSS, Templating oder Assets-Verwaltung, erklären sich aus dem Aufbau von WebPack. Vereinfacht funktioniert WebPack so:

  1. WebPack arbeitet anhand einer selbst erstellten Konfigurationsdatei
  2. Dort werden Dateien werden als „Entrypoints“ eingetragen.
  3. Aus jeder als Entrypoint abgelegten Datei, extrahiert WebPack einen „Dependency Tree“ und holt sich alle weitere Dateien, die als „Abhängigkeit“ im Entrypoint verlinkt/importiert wurde. Diese Dateien werden in einem Workflow reingekippt. Je nach Dateinamen/-Endung/-Ort kann ein eigener Workflow aufgezogen werden.
  4. Der Workflow ist eine Abfolge von in der Konfiguration eingetragenen Modulen, die die reingekippten Dateien bearbeiten. Z.B. bei SCSS: mache aus SCSS-Inhalt einen CSS-Inhalt. Transformiere den CSS-Inhalt mit Autoprefixer.
  5. Das Endprodukt jedes Entrypoints ist eine JavaScript-Datei, die die Summe der durch den Workflow bearbeiteten, abhängigen Dateien enthält.

Die Betonung liegt auf: jede als Entrypoint abgelegte Datei produziert exakt eine Javascript-Datei. Ja, auch wenn ich eine SCSS-Datei als Entrypoint ablege und durch einen CSS-Workflow jage, ist das Endprodukt eine Javascript-Datei. Diese enthält CSS-Anweisungen, die in einem WebPack-Wrapper verpackt sind – wenig hilfreich.

Also muss am Ende des Workflows ein weiteres Modul eingehängt werden: MiniCssExtractor – der extrahiert aus der produzierten JS-Datei den CSS-Code und schreibt ihn in eine CSS-Datei.

Damit produziert WebPack also zwei Dateien: eine CSS-Datei und eine nutzlose JS-Datei. Um diese los zu werden, muss noch mal ein Modul am Ende des Workflows eingehängt werden, damit die nicht benötigte JS-Datei gelöscht wird – im Gegensatz zum MiniCssExtractor gibt es aber hier kein etabliertes Standard-Modul, sondern ein halbes Dutzend von irgendwelchen händisch zusammengeklöppelten WebPack-Modulen.

Genau diese Geschichte mit dem MiniCssExtractor und dem JS-File-Remove-Modul ist für mich die Quintessenz des WebPack-Missverständnisses. Es ist kein Task Runner, sondern ein JS-Module-Bundler. Fair enough, steht ja auch drauf. Aber das so viele das Ding als Task Runner vergewaltigen, hat mich schon verblüfft.

Selbst WebPack, 2012 gestartet, scheint das Task Runner-Thema erst jetzt auf den Schirm zu bekommen. Der MiniCssExtractor wurde im Mai 2019 Nachfolger des ExtractTextWebpack-Moduls, das im März 2018 durch Umstellungen in Webpack 4 gegen die Wand gefahren wurde. Das Problem mit der Produktion einer nicht benötigten JS-Datei soll irgendwann 2020 mit Webpack 5 behoben werden.

Aus Frontend-Sicht handelt man sich mit WebPack als Task Runner eine wackelige Plattform und eine hohe Abhängigkeit von der Weiterentwicklung notwendiger WebPack-Modulen ein (s.o., das Desaster rund um ExtractTextWebpack in WebPack 4). Man wechselt also seine Grunt-/Gulp-Abhängigkeit gegen WebPack-Fesseln ein.

An jenem Abend wurde mir dann klar, dass es nur einen Weg gibt, um die Abhängigkeiten zu reduzieren und flexibel zu bleiben: npm-Skripts.

npm basiert auf „pures“ NodeJS. Eingehängte Module können Shell- oder NodeJS-Skripts sein. Es werden keine speziellen Wrapper gebraucht, um sie für einen Grunt- oder Gulp-Task Runner lauffähig zu machen.

Dieser „Down to the Metal“-Ansatz stärkt zu dem das Kennenlernen der Shell und den grundlegenden NodeJS-Modules zB rund um das Datei-System.

Bookmarks

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.

© 2020 Kai Pahl

Theme basiert auf „Lingonberry“ von Anders NorenNach Oben ↑