Über Lang(weilig)e Artikel und Zeit.

Es ist ja schon fast obligatorisch, dass hier im Blog alle paar Jahre Warteschleifenmusik gespielt wird.

„Hinter den Kulissen geht einiges vor“ wäre momentan zumindest einer Nominierung für den lame excuse award würdig. Denn: so richtig viel passiert eigentlich nicht. Wir schreiben 2021, seit bald einem Jahr ist die Mehrheit bei mir in der Arbeit im HomeofficeMobile-Work-Modus – mit allen Vor- und Nachteilen: Das Pendeln fällt weg, man muss keine Hosen tragen und obwohl ich die Ruhe und obwohl ich es durchaus schätze, in Stille und deutlich konzentrierter (im starken Kontrast zum Großraumbüro) arbeiten zu können (bzw. zu dürfen, ein Privileg, das nicht alle haben), bin ich nach rund 8 Stunden gefühlt platter als sonst.

Ein Faktor ist sicher auch, dass man die meiste Zeit auf Glasscheiben starrt und sich nicht mehr erheben muss, um in Räumen über Dinge zu sprechen. Die einzig wahren Bildschirmpausen gibt es eigentlich nur, wenn man sich etwas zum Trinken holt oder dieses wieder wegbringen muss – selbst dabei die Wege kürzer als sonst und die Kaffeeecke als Hort der Sozialisierung fällt auch weg. Immerhin: Es gab den Vorschlag einer „virtual coffee corner“, oder dass man MS Teams auch mal in der Mittagspause zum „distant socializing“ verwenden kann. Leider (oder zum Glück) können Headset und Webcam reale Team- und Sozialkontakte nicht ersetzen.

Aber um das soll es nicht gehen. Gehen… Ja, ich habe gemerkt, dass ich mich tagsüber deutlich weniger bewege, deswegen wurde die Pendelzeit durch anderweitige Bewegung ersetzt: im Sommer auf zwei Rädern, jetzt im Winter (wenn auch nicht ganz so regelmäßig) auf zwei Beinen. Nicht nur für den Körper, sondern auch für den Geist. Ohne nochmals abschweifen zu wollen: Mein Bastelzimmer ist nun auch mein Mobiles-Arbeiten-Büro, das etwas grüner, ergonomischer und (noch) vollgestopfter mit Technik ist. Trotzdem hat es ein bisschen den „Abstreif- bzw. hier-mache-ich-was-ich-will-Effekt“ verloren. Zugegeben: Das ist Klagen auf dem verdammt hohen Niveau, aber diese 15 m² werden wohl nicht die gleichen wie vor 2020 sein.

Deshalb und weil meine aktuelle Tätigkeit in und für die Arbeit mitunter anstrengend ist, bleibt – neben den anderen Dingen des Lebens – oft nicht mehr viel Zeit und Lust für Hobbys übrig.

Aber nun endgültig zurück zum eigentlichen Thema: Hinter den Kulissen geht zumindest ein bisschen etwas vor sich. Irgendwo habe ich gelesen, dass man sich zur Bewältigung von Prokrastination mit zwei Projekten beschäftigen sollte: Wenn man eines vor sich her schiebt, kann man am anderen weiterarbeiten. Zwei? Naja, eher zwanzig. Das Problem ist: viele interessante Dinge, ab einem bestimmten Punkt kommt man nicht weiter: „der nächste bitte!“ und wieder ein Projekt das man „später“ weiter/fertig machen will.

In Hinblick auf die Veröffentlichung fände ich es sehr unbefriedigend, nur halbwegs in sich geschlossene Themen zu haben. Einfach nur Schaltplan und Layout rauszuhauen kann funktionieren, aber das ist nicht mein Anspruch. Mein Ziel ist es, die Entstehung mit Designentscheidungen zu erklären, ein bisschen auf die Funktionsweise einzugehen und – was ich u. a. im Studium wahnsinnig vermisst habe: (mögliche) Probleme/Fehler finden, verstehen, beseitigen und dann evtl. sogar einer nicht in der Sache bewanderten Person erklären zu können. Ich würde sogar wagen zu behaupten, dass das eine mitunter wichtige Kompetenz für einen Entwickler ist (auch weil man durchaus in die Situation kommt, Vorgesetzten oder Kunden überzeugen zu müssen, warum man etwas teurer als unbedingt nötig machen will, warum die Entwicklung länger dauert, obwohl es schon „funktioniert“, etc…).

8 Abschnitte und noch immer nicht am Ziel? Jetzt aber: Da ich momentan einmal mehr den Artikel für den VBus-Decoder überarbeite (Verbesserungsvorschläge eines Lesers, Fehler in der Schaltung), stellt sich mir die Frage: wie kann man einen Artikel „würdevoll“ historisch wachsen lassen und gleichzeitig nur korrekte Informationen präsentieren (Schaltpläne, Teilelisten, Oszillogramme), ohne die Erkenntnisse aus Unzulänglichkeiten und Fehlern zu verlieren? Zugleich sollte die Artikellänge aber nicht abschreckender als unbedingt nötig werden (12 A4-Seiten für den VBus-Decoder-Artikel sind ordentlich), aber unnötiges Geklicke in einer Artikelserie vermieden werden.

Etwas richtig cleveres ist mir noch nicht eingefallen. „Wasch mich, mach mich aber nicht nass“ passt hier wohl am besten.

Folgende Möglichkeiten sehe ich:

  1. Vollchronologischer Aufbau: oben alt, unten neu – viel zu lesen
  2. Pro Entwicklungsphase eine Seite, ähnlich wie ein Blog
  3. TL;DR-Prinzip: Aktuellste Informationen oben, alte Versionen/Schritte wie in einem Changelog unten
  4. Eine Basisseite, mehrere Artikel/Seiten für die Varianten (beim VBus z. B.: PC-Version, Nano, Pi) mit integrierter Historie
  5. Eine Basisseite aller Varianten, Historie auf Unterseite(n)
  6. Radikalkur: nur noch den aktuellsten Stand, keine Historie

Jede Option hat Vor- und Nachteile. Die „Geschichte“ der Entwicklung möchte ich aus oben genannten Gründen eigentlich nicht ganz weglassen, eine Radikalkur wird es deshalb mit großer Wahrscheinlichkeit nicht geben.

Auch wenn Kommentare hier leider sehr selten sind: Was meint ihr? Ihr seid die Zielgruppe, also wie hättet ihr es am gerne? Einfach in die Kommentare packen oder schreibt einfach eine Mail. Ich freue mich über jeden Vorschlag!

15 Jahre

Wenn die Chronik nicht lügt, gibt es hobbyelektronik.org nun seit 15 Jahren. Wie doch die Zeit vergeht.

Zum Geburtstag gibt es deshalb auch eine kleine Neuerung: Das Wiki ist jetzt wieder auf einer aktuelleren Version und hat auch einen neuen Anstrich bekommen. Auf großen Bildschirmen nimmt es nun zwar nicht mehr die gesamte Breite ein, dafür passt es nun auf kleinen Bildschirmen besser. Insgesamt sollte die Lesbarkeit nun verbessert sein.

Ein netter Nebeneffekt ist, dass die Seite (gefühlt) etwas schneller reagiert.

Fehlt etwas oder ist was kaputt? Gefällt es euch nicht? Bitte gebt mir einfach Bescheid 🙂

Reibung

Ohmannohmann, damit hätte ich nicht gerechnet.

Die Installation vom Wiki hat schon länger ein Update nötig, 1.25 liegt auch schon länger auf dem Server, aber unbenutzt. Nun habe ich mich mal wieder dran gewagt. Die absolute Minderheit gab es aktualisiert im Repository von Mediawiki, die Mehrheit nicht. Zwar würde die Seite auch ohne die anderen Erweiterungen halbwegs funktionieren, aber wenn man sich einmal an Komfort gewöhnt hat, will man ihn nicht wieder abgeben.

Die Anzeige der aktuellsten WordPress-Posts habe ich selber mal gehackt. Das gibt es in dieser Form nicht zum herunterladen. Den Code habe ich auf die neue Extension-API angehoben und noch ein paar mehr Funktionen eingebaut. Nun muss man nur noch den Ort der Config-Datei und den externen Basispfad angeben. Über Parameter im Pseudo-HTML-Tag lassen sich Optionen mitgeben. Die Auswahl von Kategorien muss ich noch implementieren. Wenn das funktioniert, wird der Code freigelassen.

MathJax – schöne Formeln! Nur leider ist das Sammelsurium aus über 30000 PNG-Dateien eine Seuche. Aufgrund der Clustergröße macht das aus Netto 10 MB stolze 150 MB. Durch den Overhead von FTP dauert der Upload gefühlt Stunden, dafür dass es im Endeffekt nur von einer Minderheit genutzt wird (standardmäßig spuckt es entweder HTML oder SVG aus) – absoluter Bullshit. Also die ganzen Dateien in eine Zip geworfen und ein PHP-Script geschrieben, das sie – aufgerufen mit dem Pfad als Parameter – wieder ausspuckt. Die Javascript-Datei, die auf die Bilder linkt angepasst und fertig ist der Lack. Ja, Zip ist dafür nicht ideal aber gut genug, bis mir etwas besseres einfällt.

Dann wäre da noch Highslide. Was für ein instabiles Flickwerk – nicht Highslide selbst, sondern die Integration. Die Bilder werden über reguläre Ausdrücke aus dem fertigen HTML extrahiert, anhand des Dateinamens (oder Links) die „Vollversion“ ermittelt und dann mit search & replace (genau genommen regex replace callback) ersetzt. Das ist so ziemlich das inkompatibelste was man machen kann. Dementsprechend habe ich das bei jedem kleinen Update patchen dürfen. Jetzt will ich es – wenn möglich – ein bisschen eleganter implementieren. Zur Not von Null weg.

GeSHi Syntax Highlight. Aktuell noch das größere Sorgenkind. MediaWiki hat 2015 auf Pygments umgestellt. Schön für sie und vermutlich die Performance aber hier gibt’s leider kein Python. Richtigen Ersatz habe ich noch nicht gefunden. Aber die Suche geht weiter.

Vielleicht schaffe ich das Update ja bis zum Geburtstag von der Homepage Anfang April.

Übrigens, als Randnotiz: die Homepage ist teurer geworden. Lt. Hetzner durch den starken Dollar – org-Domains werden durch die ICANN verwaltet und dadurch in USD gehandelt. Statt 12,90 Euro sind es jetzt 15,35 Euro im Jahr. Bringt einen nicht um aber immerhin eine Steigerung von 19 %. Dafür könnten sie ja zumindest Cronjobs und/oder Python in den kleineren Tarifen freischalten 😉