onli blogging

Ob im Tagesjob oder für eigene Projekte, welche Abhängigkeiten (Module, Gems, libs, …) für Projekte gewählt wurden hat einen massiven Einfluss auf die spätere Entwicklung und besonders die Instandhaltung der Software. Während ich mir zu Beginn dazu kaum Gedanken gemacht habe, ist mittlerweile fast schon ein Regelwerk im Kopf entstanden. Teils aus der Mischung der positiven und den schmerzhaft negativen Erfahrungen, teils aus offiziellen Regeln für Qualitätskriterien auf der Arbeit.

So denke ich derzeit:

0. Ist die Abhängigkeit notwendig?

Die oberste Direktive für Notwendigkeit ist Aufwandsminimierung. Nur wenn sie insgesamt Aufwand minimiert kann eine Abhängigkeit positiv wirken. Also nur wenn sie etwas umsetzt, was mit eigenen Code nicht gegangen wäre oder viel Arbeit gekostet hätte. Entsprechend ist die erste Frage, ob die Abhängigkeit funktionell sinnvoll und wie notwendig sie ist.

Warum diese Aufwandsperspektive? Weil jede Abhängigkeit potentiell Folgearbeit bedeutet. Wann immer eine neue Version herauskommt, die Anpassungen am eigenen Code einfordert, muss nur wegen der Abhängigkeit Arbeit investiert werden. Und das ist dann praktisch immer verlorene Arbeitszeit, die das Projekt an sich nicht weiterbringt. Aber es kann auch andersherum sein: Wenn durch die Einbindung einer Abhängigkeit eine stete Folgearbeit ausgelagert werden kann, wie die Anpassung an eine sich immer wieder ändernde API, spricht viel für die Einbindung. Das Szenario ist aber selten.

Ein Beispiel für diese Überlegungen ist der MF2-Parser, den wir für Webmentions in Serendipity eingebunden haben. Da war ich am Zögern, ob so viel fremder Code notwendig ist, könnte man das HTML doch auch auf anderem Wege parsen. Aber der offizielle MF2-Parser ist im Zweifel exakter und vermeidet dann Arbeit, wenn sonst der eigene Code für die verschiedenen Web­men­tion-For­ma­te immer wieder angepasst werden müsste. Er war auch der empfohlene Weg der Umsetzung, daher schlug ich seine Einbindung vor.

Die Erwartungshaltung der benötigten Folgearbeit variiert hier stark je nach Entwicklungssprache und dann nochmal je nach Nische innerhalb der Sprache, ist sie groß genug. Um ein paar Erfahrungswerte zu teilen: Javascript samt Node ist berüchtigt für die kurze Halbwertszeit und den wahnsinnigen geforderten Aufwand; bei Flutter beziehungsweise Dart gab es da noch keine etablierte Kultur, sondern variierte es wohl je nach Entwicklerhintergrund; Module für Ruby und PHP (hier im Gegensatz zur Sprache selbst) sind normalerweise respektvoll.

1. Welche Abhängigkeiten hat die Abhängigkeit?

Es empfiehlt sich einen Blick auf die Abhängigkeiten der Abhängigkeit zu werfen. Je mehr das sind, desto eher können durch sie neue Probleme entstehen. Ob das Interaktionen mit dem eigenen Code sind oder, wahrscheinlicher, wegbrechende oder sich ändernde Projekte Probleme verursachen, die dann über die Abhängigkeit an das eigene Projekt weitergegeben werden.

2. Wie beliebt ist die Abhängigkeit?

Die Beliebtheit kann durch das jeweilige Empfehlungssystem transportiert werden, wie die Sterne bei Github, oder durch Artikel, die das Modul vorstellen und loben. Beliebtheit ist erstmal positiv, die Weisheit der Masse wird nicht völlig unberechtigt ein Projekt hervorheben. Und viel Aufmerksamkeit kann die Chance erhöhen, dass bei einem Einschlafen der Entwicklung sich ein Nachfolgeprojekt bildet.
Gleichzeitig kann Beliebtheit negative Auswirkungen haben, wenn die Entwickler durch einen Nutzeransturm überfordert werden, die gefühlte Popularität ihnen zu Kopf steigt oder schlicht durch die Masse an Anforderungen der Projektfokus verlorengeht.

Gleichzeitig gibt es immer wieder gute Module, die von der Masse ignoriert werden. Oder das technisch bessere Folgeprojekt, das zwar beliebt ist, aber weniger als das früher etablierte. Die Inertia der Masse ist hier eben auch ein Thema. Daher ist Beliebtheit ein Faktor, aber ein schwacher.

3. Ist die Dokumentation brauchbar?

Die Brauchbarkeit der Dokumentation würde ich sehr viel höher hängen. Brauchbarkeit ist hier bewusst gewählt, statt Umfang. Ich habe mehrfach sehr umfangreiche Dokumentation erlebt, die aber überhaupt nicht hilfreich war, weil sie die aufkommenden Nutzungsfragen einfach nicht beantwortete.

Ein gutes Readme kann völlig ausreichen, solange es den Umgang mit der gebotenen API sauber erklärt. Wobei bei vielen Projekten eine ausführlichere Beschreibung der Optionen in einer dedizierten Dokumentation erstrebenswert ist.

4. Wann war das letzte Update?

Das Datum des letzten Updates bestimmt, ob ein Projekt wirklich aktiv ist oder nicht.

Das darf wieder nicht überbewertet werden. Manche Projekte sind stabil und fertig, sie brauchen nur seltene Anpassungen und das lange vergangene Datum des letzten Updates bedeutet kein brach liegendes Projekt, sondern ein stabiles. Genauso kann ein kürzliches Update und ein hohes Updateinterval auf Instabilität und fehlende Entwicklerdisziplin hindeuten. Aber es gibt hier eine gesunde Balance, die das Ideal wäre.

5. Wie viele offene Bugreports und Pullrequests gibt es?

Hier kommt es wieder stark auf den Kontext an.

Ein übervoller Bug- oder Issuetracker ist erstmal ein Alarmsignal. Blöd sind auch sich aufstauende Pullrequests. Beides zeichnet das Bild eines überforderten Projekts, bei dem Probleme der Nutzer nicht angegangen werden.

Aber man darf diesen Faktor auch nicht überbewerten. Bei einem sehr beliebten Projekt beispielsweise werden fast zwangsläufig sehr viele Nutzerberichte zu Problemen zusammenkommen, die kein Entwicklerteam der Welt alle ordentlich bearbeiten kann. Wenn trotzdem auf wichtige Beiträge geachtet wird, die Entwicklung trotzdem läuft, dann ist der volle Bugtracker fast ein gutes Zeichen: Denn dann wurde kein Bot eingesetzt, der automatisch Bugreports schließt, was immer eine feindselige Haltung zur Nutzerschaft auslöst und wichtige Berichte ungesehen verschwinden lässt.

Genauso können sich bei alten Projekten Berichte ansammeln, die nicht wirklich angegangen werden können, die aber auch nicht unpassend sind und daher lange aufbleiben. Wieder, solange die Software und die Entwicklung trotzdem läuft ist das völlig okay.

6. Wie redet der oder reden die Maintainer mit Nutzern?

Das ist fast das wichtigste: Wichtiger als der Zustand des Issuetrackers in absoluten Zahlen ist das Verhalten der Entwickler darin. Werden Nutzer für ihre Berichte abgekanzelt, oder werden sie ernstgenommen und angehört? Werden Nutzer beleidigt, ihre Bugreports ohne verständlichen Grund geschlossen, fehlt einfach Freundlichkeit und Respekt sollte man sich soweit Fernhalten wie möglich.

Dabei lohnt sich auch ein Blick darauf, wer antwortet. Eine häufige Projektkonfiguration ist der erfahrene und freundliche Originalentwickler, dem aber die Zeit fehlt, und dann gibt es eine Nummer 2, die im Bugtracker viele Anfragen beantwortet. Dem Originalentwickler gegenüber wird diese Person immer nett sein, aber es besteht dann leider die Tendenz, gegenüber Nutzern respektlos zu antworten. Wird das geduldet, und wie weit ist diese Entwicklung vorangeschritten? Das wird viel darüber verraten, ob vom Originalentwickler dem Projekt noch Aufmerksamkeit geschenkt wird.

Auch wenn man selbst in diesen Projektkommunikationsmitteln nicht aktiv teilnehmen will ist das ein wichtiger Faktor, denn es wird darüber bestimmen wie gut und verständlich Antworten auf Nutzerfragen sind, ob das Projekt Nutzungsprobleme angeht und ob bei der Weiterentwicklung der Nutzer bedacht wird. Und ein vernünftiger, freundlicher Maintainer gleicht fast alle anderen möglichen Schwachpunkte eines Projektes wieder aus, denn seine Handlungen werden mittelfristig der Einstellung gleichen.

7. Wie wurde mit inkompatiblen Änderungen umgegangen?

Der Einfluss des Maintainers kumuliert im Umgang mit Breaking Changes. Also Änderungen der Abhängigkeit, die Änderungen am eigenen Code erfordern.

Um die Wichtigkeit des Aufwandsmanagements nochmal klarzumachen hilft vielleicht diese Perspektive: Das eigene Team hat X Mann. Wieviele Leute entwickeln an all den Abhängigkeiten? Wieviele entwickeln an der Grundsprache, wenn z.B. wie bei Flutter Google hunderte oder tausende Entwickler beschäftigt? Jeweils sind es viel mehr, also kann das eigene Team die investierte Arbeit der anderen nicht kontern. Das Projekt kann nur erfolgreich sein, wenn das nicht notwendig ist, wenn eben inkompatible Änderungen vermieden werden.

Daher sind sind sie immer ein großer Negativpunkt. Aber manchmal sind Anpassungen an der Schnittstelle eines Moduls schwer zu vermeiden. Sind sie selten genug, werden die nötigen Änderungen gut erklärt und verständlich gerechtfertigt sind sie natürlich akzeptierbar. Auch hilft es, wenn die Versionsnummer nach Semantic Versioning angehoben wird, zumindest in Ökosystemen, bei denen die Updatetools darauf ausgelegt sind. Dann werden wenigstens Aktualisierungszeitpunkte samt ihren Migrationen etwas besser wählbar.

Aber alleine die Nummer korrekt anzuheben reicht eben nicht. Wenn Änderungen einfach so gemacht werden, ohne Rücksicht, ist es Zeit zu rennen. Wenn beispielsweise vorher eine Funktion auf zwei Arten aufgerufen werden konnte, und jetzt eine davon wegfällt nur weil der Maintainer das schöner findet, hat er die Bodenhaftung verloren. Klar, vereinfacht das wesentlich seinen eigenen Code und Aufwand und erklärt er es entsprechend kann auch sowas mal okay sein. Aber grundsätzlich sollte Abwärtskompatibilität eine große Priorität haben. Einfach, weil sonst Abhängigkeit um Abhängigkeit Änderungen einfordern und die verfügbare Arbeitsleistung des eigentlichen Projekts für diese Pflege aufgefressen wird.

Besonders klares Zeichen sind Sprüche wie "Ich muss mich nicht rechtfertigen", wenn bei kaputtmachenden Änderungen der Grund erfragt wird, oder wenn beim Versuch die Problematik zu erklären mit emotionaler Manipulation dem Nutzer die Schuld für das Problem gegeben wird, ein Ansprechen der Problematik zu Aggressionen führt. Beides habe ich wirklich gesehen, kürzlich erst wieder. Von solchen Projekten kann man gar nicht genug Distanz wahren.

Ein weiteres Beispiel, dass Arbeit als Entwickler auch eine soziale Komponente hat.

Man kann diese Regeln ignorieren und Glück haben, man kann ihnen folgen und trotzdem von unnötigen Änderungen gepiesackt werden. Aber ich glaube, grundsätzlich sind sie kein schlechter Ansatz und recht umfassend.
Gibt es etwas, was ich übersehen habe oder was ihr anders seht?

Diese Woche fand ich besonders erwähnenswert:

That time Reddit banned me for developing an app. Nachbeben von Reddits faktischer API-Ab­schal­tung.

Beachtenswert sind die Clean Air Kits. Das sind mit PC-Lüftern umgesetzte Cor­si-Ro­sen­thal-Box­en, was wiederum ein Konzept ist, bei dem ein Rechteck auf einer Seite Lüfter hat, ansonsten einen Boden und an den vier restlichen Seiten Luftfilter. Völlig logisch dabei der Gedanke, dass es bei Luftreinigung weniger um die theoretische Filterleistung geht als vielmehr um Filterleistung im Wechselspiel mit der bewegten Luftmenge, wobei die theoretische Filterleistung bei entsprechend großer bewegter Luftmenge auch geringer sein darf. Also, völlig logisch, und doch war mir das bisher nicht klar gewesen.

Lidl’s Cloud Gambit: Europe’s Shift to Sovereign Computing beschreibt sehr positiv die Bemühungen Lidls in Richtung Cloud. Dabei wird allerdings Gaia-X ebenfalls positiv erwähnt, was angesichts Scaleways Bescheibung in Full steam ahead towards a true multi-cloud offering to deliver on broken promises wahrscheinlich nicht stimmen kann.

Stimmen kann Scrum, XP & Co. – warum keiner mehr agil arbeiten will. Mit Einschränkungen des Titels, die aber der Artikel auch abbildet. Denn meiner Erfahrung nach wollen sehr viele agil arbeiten. Wo es aber Widerstand gibt, auch bei mir, waren die bürokratischen und zeitraubenden Rituale von Scrum. So verhinderte ich mehr als einmal die Einführung von täglichen Statustreffen, zugunsten der eigenen und der Teamproduktivität.

Positive erste Eindrücke kommen von COSMIC Alpha Released! Here’s what people are saying. Ich freue mich auf jeden Fall über den Impuls für Linux Desktoplandschaft.

Und zum Abschluss einen Artikel zum Zeitgeschehen, dem ich voll zustimme: Wie rechte Rhetorik und symbolische Maßnahmen die Demokratie gefährden.

Bond sucht Blofeld, dieser ist in den Alpen und bedroht von da die Welt, was Bond durch einen Bund mit einer Verbrecherorganisation und einer Begegnung mit einer schönen Frau rausbekommt.

For thee the hammer on the anvil rings - was ein Umbruch. Nicht nur, dass Poesie zitiert wird. George Lazenby als Bond ist eine Revolution. Immer noch ein Frauenheld, lässt er sich auf eine völlig ein. Immer noch oft im Kampf mit Schergen des Oberbösen, zeigt er mindestens einmal Angst und Verzweiflung. Woraufhin ihn mit der fantastischen Diana Rigg eine Frau rettet, in einer Actionszene sie das Auto fährt, später beim Skifahren sie Stunts wie er durchzieht. Wahnsinn! Und auch wie der Oberböse gezeichnet wird: Telly Savalas ist großartig als Blofeld, was den Bösewicht aus dem Vorgänger wieder aufnimmt, aber eben ganz anders. Nicht mehr als Karikatur. Bösewicht zwar, aber mit Dingen wie Eitelkeiten für einen Adelstitel, regulären Gesprächen und eigener Beteiligung an Actionszenen.

Keine Bond-Gadgets diesmal, eine Besonderheit – wohl weil der Film eben kein Klamauk sein will (aber genau deswegen hätte er sich auch an ein paar Stellen Bonds reingeschnittene Kommentare sparen sollen). Geblieben ist, dass die Schauspieler öfter überdeutlich im Studio in Hintergründe hineingesetzt wurden. Neue Macke: Die Kämpfe werden seltsam zerschnitten. Dafür werden nicht mehr merklich Actionszenen künstlich beschleunigt, um sie dramatischer wirken zu lassen. Ein guter Tausch, Grundlage für sehr gute Stunts.

Ganz klar der beste Film der Reihe bis hierhin; wenn nicht überhaupt, dann mindestens der interessanteste.

Während Villanelle sich durch Europa mordet, jagt Eve für den britischen Geheimdienst die psychopathische Mörderin und ihre Auftraggeber. Doch als sich die Wege der beiden Frauen kreuzen scheint sich da ein sexuelles Interesse zu entwickeln, aus der einseitigen Recherche wird ein Katz- und Mausspiel mit wechselnden Rollen.

Die Serie Killing Eve ist überaus brutal und verherrlicht ohne Zweifel Serienmörder. Gleichzeitig ist das ganze irgendwo zwischen einem spannenden Thriller und einer schwarzen Komödie, bzw wechselt die Serie immer wieder den Ton. Dadurch kann man sie gleichzeitig nicht ernstnehmen (und so ihre Brutalität ertragen) und doch mitfiebern.

Sandra Oh spielt dabei die driftende Eve sehr viel überzeugender, als ihr Hintergrund mit Grey's Anatomy als große Rolle vermuten ließ – rein von der Art der Serie bewertet, durchaus möglich, dass sie schon dadrin so gut war. Aber es ist Jodie Comers Villanelle, wodurch die Serie wirklich gewinnt. Ihr Charakter ist auf herrliche Art gleichzeitig körperlich attraktiv und fürchterlich abstoßend mörderisch, aber in den ersten drei Staffeln auch mit einem passend dunklen Humor wirklich lustig. Und dabei meist gekleidet wie ein Paradiesvogel. Dazu passt die von Fiona Shaw gespielte Carolyn, die Eve auf Villanelles Fährte setzt. Denn sie ist ähnlich makaber und abnormal, aber das graue Gegenteil eines Paradiesvogels.

Drei Probleme hatte ich mit der Serie. Leichte Spoiler.
Erstens ist gerade Villanelle, aber sind auch einige der auftretenden anderen Mörder, arg unverwundbar. Da gibt es meist keine ordentliche Inszenierung für Kämpfe, nie Erklärungsversuche für die Erfolgsquote und körperliche Überlegenheit, keine Probleme mit zu versteckenden Leichen oder ermittelnder regulärer Polizei. Dieser Aspekt der Serie wirkt nach einer kurzen Weile hingeschludert, der Versuch offensichtlich, es durch die Zurschaustellung von Brutalität zu übertünchen.
Zweitens wird das Hin- und Her zwischen Eve und Villanelle schnell nervig. Was beim ersten mal noch funktioniert, ist schon bei der ersten Wiederholung ein klares Zeichen schlechter Schreibe, einzig der Versuch die Serie in den bestehenden Bahnen weiterzubetreiben erklärt das Verhalten ihrer Figuren an den vielen Wendepunkten. Auch wenn ihre Verbindung natürlich keine gesunde sein kann ist ihre Sabotage durch die Schreiber eben genau das, eine als künstliche Entscheidung der Serienmacher erkennbare, was richtig schlecht ist.
Drittens ist die vierte und letzte Staffel verhunzt. Von ihrem Beginn an, als (siehe Punkt zwei) Eve und Villanelle trotz eines gegenteiligen Endes der dritten Staffel erklärungslos wieder verfeindet sind; zum komplett verschwundenen Humors Villanelles und Carolyns plötzlichem Herumgesülze zu einer abrupten, unbefriedigenden und unmotivierten Endszene funktionieren da viele der Eckpunkte nicht mehr – das Ende erinnert in seiner Verfehltheit gar an Dexter. Und das ist echt schade, denn die grundsätzliche Idee und Rahmenhandlung für die letzte Staffel war ordentlich, das hätte ein gutes Ende werden können.

Anschaubar, aber die vierte Staffel sollte man sich sparen. Das Ende der dritten war auch noch das bessere Serienende.

Diese Woche fand ich besonders erwähnenswert:

Beginnen soll Frontend ohne FOMO: ein Erfahrungsbericht. Es war mir eine persönliche Bestätigung, dass der Autor nach einer Annäherungsphase an die moderne Webentwicklung eine distanzierte Position gefunden hat. Immerhin hatte ich von seinen Artikeln vor vielen Jahren doch einiges gelernt.

Es gibt wichtige Positivbeispiele für Freie Software in der Schule: Das Gymnasium Edenkoben setzt voll auf Linux.

Benedikt schildert seine Erfahrungen in Vor 10 Jahren endete meine längste Blogpause. Im Grunde geht es dabei um die Motivation zum Bloggen.

Und genau das bespricht auch Warum wir (immer noch) bloggen, mit ben_ von anmutunddemut. Auch da erkenne ich einzelne Ideen und Überzeugungen wieder, wobei ihr gemeinsamer Hintergrund natürlich sehr speziell ist. Auf jeden Fall sehr hörenswert, gerade für Blogger und an Blogs interessierte.

Wir sehen immer wieder die Gefahren von Googles Quasimonopol, das der Internetgigant durchaus auch gegen Konkurrenz einsetzt: Last night Organic Maps was removed from the Play Store without any warnings or additional details due to "not meeting the requirements for the Family Program".

Mittlerweile voll etabliert und damals ein wichtiger Schritt: Celebrating 6 years since Valve announced Steam Play Proton for Linux. Wobei auf Gamingseiten immer noch Ewiggestrige rumlaufen, die Linux spieletauglichkeit nicht mitbekommen haben. Da ist noch was zu tun.

Es war FrOSCon 2024, verlinkt ist ein Messebericht. Bei dem Blick auf die Vorträge merke ich, warum ein Besuch nicht unbedingt nötig war, andererseits wäre es bestimmt doch wieder interessant und nett geworden.

Diese Woche und noch am Laufen ist die Gamescom, wozu es viele Berichte gibt, wie GC24: Avowed angespielt -- Action-RPG mit Obsdian-Handschrift. Ich bin sehr gespannt, ob mir nach The Outer Worlds ein 3D-Rol­len­spiel von Obsidian wieder gefallen kann. Immerhin spricht mich das Universum von Pillars of Eternity mehr an, gerade nach dem tollen zweiten Teil der Serie.