Leserbriefe Dezember 2022

Keine Probleme mit Smart Contracts

(Blockchain: Rechtliche Fallstricke bei Smart Contracts; iX 10/2022, S. 88)

Alles, was durch Smart Contracts zur Ausführung gebracht wurde, kann man durch erneute Smart Contracts auch wieder aufheben und für ungültig erklären. Nur ungeschehen kann man sie halt nicht machen, und das ist auch gut so. Die Revisionssicherheit ist doch ein Riesenvorteil der Blockchain.

Ich sehe auch nicht, wo da die Beziehung zwischen Menschen nicht vorhanden sein soll. Smart Contracts führen sich nicht selbstständig aus, denn schließlich kostet so eine Transaktion ja Geld, und das muss ja von jemandem investiert werden.

Smart Contracts sind lediglich ein weiteres technisches Mittel, um Verträge zu schließen. Genau wie das Telefon oder Webseiten im Internet.

Bingo-Bongo!, aus dem iX-Forum

Managementaufgabe: Human Firewall

(Editorial: Raus aus der Inbox; iX 11/2022, S. 3)

Ich sitze im mittleren Management (früher war ich mal Programmierer, mein eigentlicher Traumjob) und wache darüber, dass E-Mails, PowerPoint, Excel, MS Teams, Slack und Meetings weitgehend von der Entwicklung abgehalten werden. Weil einer ja noch die richtige, wertschöpfende Arbeit machen muss. Auch wenn alle gerne und überall mitreden, mitbestimmen, mitkontrollieren und mitberichten wollen.

All diese Tools haben Hochkonjunktur. Die wunderbare Welt des Micromanagements. Zu Homeoffice-Zeiten zum Exzess getrieben. Alle halbe Stunde ein neues Meeting. Wenn man auf 15 Minuten verkürzt, könnte man doppelt so viele in der Woche schaffen. Und während den Meetings wird gemailt, gechattet, Excel-Tabellen ausgefüllt und PPTs gelesen, aber nicht zugehört.

Bin froh, wenn ich bald in Rente gehe. Dann fang ich wieder zu programmieren an. Ohne Management.

Kartoffel4711, aus dem iX-Forum

Memory Unsafe durch Zig als Programmiersprache

(JavaScript: JS-Runtime Bun versus Node.js und Deno; iX 10/2022, S. 74)

Ein ganz anderes Problem, das Bun hat, ist, dass es in Zig geschrieben wurde und augenscheinlich nicht wirklich darauf geachtet wurde, Memory Safe zu arbeiten. Daher ist es aus Sicherheitssicht wahrscheinlich keine gute Idee, Bun irgendwo laufen zu lassen – das sieht man alleine daran, wie häufig irgendwelche SEGFAULTs auftreten.

Ich muss dem Projekt aber zugutehalten, dass sie, nachdem ich sie auf das Problem hingewiesen habe, das Beheben dieses zu einer ihrer wichtigsten Prioritäten erklärt haben. Ich bin aber trotzdem skeptisch, ob sich das bei einer so großen Codebasis überhaupt noch nachträglich reparieren lässt.

Max Bruckner, Karlsruhe

Nicht notwendigerweise so schlimm

(Softwareentwicklung: Cloud-natives Java mit Quarkus, Mandrel und Jib; iX 11/2022, S. 62)

Der Artikel suggeriert, dass wir ein Problem mit Java in Containerumgebungen haben. Das sehe ich etwas differenzierter: Auch viele Nicht-Java-Workloads sind durchaus etwas größer, zum Beispiel Datenbanken. Hier gibt es kein prinzipielles Problem.

Nur wenn sehr kleinteilig zerlegt werden soll, so wie dies bisher zum Beispiel mit Go oder Node.js geht, dann wird die JVM etwas sperrig. Containerumgebungen sind dann die Lösung, so eine Architektur überhaupt betreiben zu können. Aber nur weil eine Containerumgebung das kann, bedeutet es nicht, dass sie es voraussetzt.

Also ein sehr interessanter Artikel – wenn dieser Wunsch aus Applikationsarchitektursicht aufkommt.

Kai Schwebke, Bad Teinach-Zavelstein

Ergänzungen und Berichtigungen

Buchmarkt: Mysterium Metaversum; iX 11/2022, S. 150

Der Autor des Artikels ist nicht Tam Hanna, sondern Jürgen Seeger.

Die iX-Redaktion behält sich Kürzungen und auszugsweise Wiedergabe der Leserbriefe vor. Die abgedruckten Zuschriften geben ausschließlich die Meinung des Einsenders wieder, nicht die der Redaktion.