Anmelden
(Bild: fizkes/Shutterstock.com)
Im Sommer 2025 veranstaltet die the native web GmbH eine eintägige Konferenz zum Thema professionelle Web- und Cloud-Entwicklung.
Das Jahr 2024 ist noch nicht ganz vorüber, aber es neigt sich allmählich dem Ende entgegen. Für meine Kolleginnen und Kollegen der the native web GmbH [1] und mich bedeutet das, dass in diesem Jahr nur noch ein paar wenige Posts in diesem Blog und auch Videos auf YouTube vor uns liegen, bevor wir uns in den Weihnachtsurlaub verabschieden werden. Es bedeutet aber auch, dass wir bereits fleißig mit der Planung für das kommende Jahr beschäftigt sind.
Was Sie im nächsten Jahr genau erwartet, das verrate ich Ihnen heute noch nicht im Detail, aber ich möchte zumindest schon einmal ein paar Worte über das vergangene Jahr verlieren.
Rückblickend war 2024 für uns ein großartiges Jahr. In den vergangenen elf Monaten haben wir sage und schreibe 26 Blogposts geschrieben, 47 Videos veröffentlicht, fünf Livestreams veranstaltet und 36 Webinare im Rahmen unserer tech:lounge Masterclass durchgeführt. Und ganz gleich, was wir gemacht haben – eine Sache war immer gleich: Ihr Feedback!
Sie haben uns in so vielen Kommentaren, E-Mails, Telefonaten, persönlichen Gesprächen, auf Discord und sogar per Post (!) geschrieben und gesagt, wie ungemein wichtig unsere Videos und Artikel für Sie sind: für lebenslanges Lernen, für kontinuierliche Weiterbildung, für den Alltag. Sie haben uns mitgeteilt, dass wir Sie mit unserem Content unterstützt haben, sich weiterzuentwickeln, endlich den neuen Job zu bekommen, anderen weiterzuhelfen und vieles mehr.
Das macht uns unglaublich stolz und wir sind sehr dankbar für dieses Feedback, denn es zeigt uns, dass das, was wir machen, nicht einfach nur das nächste x-beliebige Content-Schnippsel im Internet ist, sondern dass wir wirklich etwas zum Guten bewirken können und einen positiven Einfluss auf Ihr Leben haben. Das ist alles andere als selbstverständlich. Und darüber bin ich sehr froh.
Lebenslanges Lernen ist gerade in der IT ein wichtiges Thema. Nur wer sich dauerhaft und kontinuierlich weiterbildet, wird auch nachhaltigen Erfolg in der Softwareentwicklung haben. Deshalb haben wir uns auch für das kommende Jahr einiges vorgenommen. Was das alles im Detail sein wird, möchte ich an dieser Stelle noch nicht verraten, aber zwei Neuigkeiten möchte ich doch schon mit Ihnen teilen.
Zum einen werden wir im Sommer 2025 zum ersten Mal seit der Pandemie wieder eine Vor-Ort-Veranstaltung durchführen: Wir werden eine kleine, schnuckelige, eintägige Konferenz rund um das Thema der professionellen Web- und Cloud-Entwicklung bei uns in Freiburg im Breisgau veranstalten. Vom Morgen bis in den späten Abend hinein wird es am 4. Juli 2025 um Themen wie Architektur, Algorithmen, Protokolle, Skalierbarkeit und Ausfallsicherheit gehen.
Da wir die Veranstaltung direkt neben unserem Büro abhalten, ist das auch die perfekte Gelegenheit, meine Kolleginnen und Kollegen (und natürlich auch mich) einmal persönlich kennenzulernen. Wie das bei Veranstaltungen in der Realität leider so ist, ist der Platz natürlich begrenzt, das heißt, die Teilnahme ist auf 150 Personen limitiert. Ein Ticket kostet 399 Euro (zuzüglich 19 % Umsatzsteuer), und Sie können es ab sofort auf unserer Website buchen [2], um bei der tech:lounge Live! vor Ort dabei sein zu können. Und natürlich würde ich mich sehr freuen, Sie dort begrüßen zu dürfen!
Das ist jedoch noch nicht alles. Pünktlich zum Jahresende haben wir noch ein ganz besonderes Spezialangebot für Sie: Wir haben uns überlegt, dass wir auch im kommenden Jahr wieder Webinare anbieten werden, und zwar 24 Stück. Normalerweise kostet ein einzelnes Webinar 179 Euro, und ein Dreierpaket kostet 399 Euro. Bei 24 Webinaren wären das also insgesamt über 4.200 Euro.
Weil wir aber wissen, dass viele von Ihnen regelmäßig bei unserer tech:lounge Masterclass zu Gast sind, bieten wir Ihnen bis zum 31. Dezember dieses Jahres an, die Teilnahme an allen 24 Webinaren, die im kommenden Jahr stattfinden werden, für lediglich 999 Euro zuzüglich 19 % Umsatzsteuer zu buchen. Das sind über 75% Rabatt, und damit möchten wir Ihnen für Ihre Treue und auch für das Vertrauen danken, das Sie in den vergangenen Monaten und Jahren in uns gesetzt haben. Auch hier wissen wir, dass das alles andere als selbstverständlich ist.
Wir nennen dieses Angebot tech:lounge 360°, denn – und das ist anders als bisher – alle 24 Webinare folgen einem durchgängigen roten Faden. Das bedeutet, wir werden ab März bis einschließlich Dezember gemeinsam eine komplette Anwendung entwickeln. Dabei sind nicht nur alle möglichen Themen enthalten, wie zum Beispiel Konzeption, Modellierung, Architektur, Entwicklung, APIs, Services, Deployment, Operations, Data-Management, UIs und vieles mehr, sondern wir fügen das alles auch noch zu einem einzigen, großen, durchgängigen praktischen Beispiel zusammen.
So können Sie innerhalb eines Jahres praxisnah verfolgen, wie nach und nach eine moderne und skalierbare Web- und Cloud-Anwendung entsteht. All das in über 80 Stunden Training, verteilt auf 24 Termine, für gerade einmal 999 Euro. Auch das Ticket hierfür können Sie ab sofort auf unserer Website buchen [3]. Es lohnt sich jedoch, schnell zu sein: Das vergünstigte Angebot gilt nur bis zum 31. Dezember 2024, danach gelten die regulären Konditionen und Preise. Auch hier würde ich mich natürlich sehr freuen, Sie begrüßen zu dürfen!
PS: Einen letzten Livestream für dieses Jahr wird es in ungefähr zwei Wochen übrigens auch noch geben, nämlich am 12. Dezember, wie immer ab 18 Uhr auf unserem YouTube-Kanal [4].
URL dieses Artikels:
https://www.heise.de/-10159636
Links in diesem Artikel:
[1] https://www.thenativeweb.io/
[2] https://techlounge.io/
[3] https://techlounge.io/
[4] https://www.youtube.com/@thenativeweb
[5] mailto:rme@ix.de
Copyright © 2024 Heise Medien
Vom gewöhnlichen LLM zur menschenähnlichen KI
(Bild: von DALL-E generiert)
Sind große Sprachmodelle tatsächlich kurz vor dem Erreichen eines menschlichen Niveaus, wie in einigen Publikationen und YouTube-Kanälen behauptet?
In derzeitigen Diskussionen über generative Künstliche Intelligenz werden häufig Begriffe wie Künstliche Superintelligenz (ASI – Artificial Super Intelligence) und Allgemeine Künstliche Intelligenz (AGI – Artificial General Intelligence) verwendet. Sie erwecken den Eindruck, dass wir mit den heutigen großen Sprachmodellen (LLMs) kurz vor der Erreichung von ASI oder AGI stehen. Laut IBM ist "künstliche Superintelligenz (ASI) ein hypothetisches, softwarebasiertes künstliches Intelligenzsystem (KI) mit einem intellektuellen Umfang jenseits menschlicher Intelligenz. Auf der grundlegendsten Ebene verfügt diese superintelligente KI über hochmoderne kognitive Funktionen und hochentwickelte Denkfähigkeiten, die fortschrittlicher sind als die eines jeden Menschen."
Ich vertrete jedoch eine andere Perspektive. Obwohl LLMs bedeutende Fortschritte in der Verarbeitung und Generierung natürlicher Sprache gemacht haben, sind sie im Wesentlichen ausgeklügelte statistische Modelle, die im Mustererkennen glänzen. Sie sind durch die begrenzte Menge an qualitativ hochwertigen verfügbaren Trainingsdaten eingeschränkt. Wenn wir die leicht zugänglichen Daten erschöpfen, wird es für Unternehmen wie OpenAI oder Anthropic zunehmend schwieriger, wie in der Vergangenheit erhebliche Fortschritte in Geschwindigkeit und Wissen ihrer Modelle zu erzielen.
Wie würde also eine wirklich menschenähnliche KI aussehen? Eine authentisch intelligente Maschine würde mehrere Schlüsselmerkmale aufweisen:
Proaktivität
Anstatt sich ausschließlich auf große Mengen an vorhandenen Daten zu verlassen, sollte eine KI die Fähigkeit haben, proaktiv neues Wissen und Erfahrungen durch selbstlernende Mechanismen zu suchen. Dies beinhaltet das Initiieren von Interaktionen mit anderen Maschinen und Menschen, um Informationen in Echtzeit zu erwerben. Eine wirklich intelligente Maschine würde nicht passiv statische Daten verarbeiten, sondern aktiv mit ihrer Umgebung interagieren, um ihr Verständnis zu erweitern.
Autonomes Verhalten
Autonomie ist essenziell, damit eine KI wirklich ihre Umgebung erkunden und mit ihr interagieren kann. Eine intelligente Maschine sollte in der Lage sein, unabhängige Entscheidungen über ihre Handlungen und zukünftigen Richtungen zu treffen, ohne ständige menschliche Führung. Diese Autonomie ermöglicht es der KI, sich in komplexen, dynamischen Umgebungen zurechtzufinden und sich an neue Situationen und Herausforderungen anzupassen, wenn diese auftreten.
Emotionale Intelligenz
Während Emotionen bei Menschen komplex und nicht vollständig verstanden sind, könnte die Einbeziehung von Elementen, die Emotionen wie Neugier und Zufriedenheit analog sind, die Fähigkeit einer KI verbessern, zu erkunden und zu lernen. Neugier treibt die Suche nach neuem Wissen an und veranlasst die KI, neuartige oder "interessante" Themen zu untersuchen.
Sensoren und Aktoren
Die physische Interaktion mit der Umwelt ist entscheidend, damit eine KI erfahrungsbasiertes Wissen erlangen kann. Ausgestattet mit Sensoren und Aktoren kann eine KI ihre Umgebung wahrnehmen und Aktionen ausführen, die die Welt beeinflussen. Diese Verkörperung ermöglicht es der KI, aus direkter Erfahrung zu lernen und Informationen zu erwerben, die in bereits vorliegenden Datensätzen nicht vorhanden sind.
Denken, Meta-Denken und Reflexion
Fortgeschrittene kognitive Prozesse wie Denken und Selbstreflexion sind unerlässlich, damit eine KI aus ihren Erfahrungen, einschließlich Misserfolgen, lernen kann. Durch die Analyse vergangener Handlungen und Ergebnisse kann die KI ihr Verhalten anpassen, um die zukünftige Leistung zu verbessern.
Während aktuelle KI-Technologien beeindruckende Fortschritte gemacht haben, erfordert die Erreichung echter AGI oder ASI die Überwindung signifikanter Hürden:
Die Reise hin zu menschenähnlicher KI besteht nicht nur darin, Modelle zu skalieren oder Daten zu erhöhen, sondern erfordert ein grundlegendes Umdenken, wie KI-Systeme lernen, interagieren und denken. Indem wir uns auf Proaktivität, Autonomie, emotionale Intelligenz, physische Verkörperung und fortgeschrittene kognitive Prozesse konzentrieren, können wir der Entwicklung von KI näher kommen, die nicht nur menschliche Fähigkeiten nachahmt, sondern auch auf wirklich intelligente und autonome Weise mit der Welt interagiert.
Nur indem wir diese facettenreichen Herausforderungen angehen, können wir hoffen, das volle Potenzial der Künstlichen Intelligenz zu realisieren und den Weg für Maschinen zu ebnen, die wirklich denken, lernen und vielleicht eines Tages ein Bewusstsein ähnlich dem unseren besitzen.
URL dieses Artikels:
https://www.heise.de/-10039060
Links in diesem Artikel:
[1] mailto:map@ix.de
Copyright © 2024 Heise Medien
(Bild: Natalia Hanin / Shutterstock.com)
Das OpenJDK entwickelt sich rasant weiter. Die Anzahl der JEPs pro halbjährlichen Release steigt. Java gehört auch mit 30 Jahren noch nicht zum alten Eisen.
Für das OpenJDK 24 [1] sind aktuell (Stand: 20.11.2024) schon 24! (in Worten: vierundzwanzig) JEPs eingeplant. Das passt nicht nur zur nächsten Release-Nummer. Das ist auch ein neuer Rekord, seit die Entwicklung 2018 auf die halbjährlichen Release-Zyklen umgestellt wurde. Und die Zahl kann sogar noch weiter wachsen. Denn erst am 5. Dezember startet die Rampdown Phase One mit dem Feature Freeze für die nächste Version. Und weil es diesmal so viele JEPs (JDK Enhancement Proposals) sind, werden wir hier schon mal einen ersten Blick auf die aus Developer-Sicht interessantesten Punkte werfen, die aktuell eingeplant sind. Weitere Details können über die jeweiligen JEPs nachvollzogen werden.
In einem späteren Post schauen wir uns dann die restlichen Features an. Vielleicht kommen ja sogar noch welche hinzu. Wir dürfen also gespannt sein, was in den nächsten zwei Wochen passieren wird.
JEP 485 – Stream Gatherers
Nach zwei Previews erfolgt nun die Finalisierung. Die in Java 8 eingeführte Stream API unterstützt jetzt das Hinzufügen eigener Intermediate Operationen. Dadurch können Daten in Streams nun auf bessere, optimierte Art und Weise transformiert werden als mit den wenigen fest eingebauten Intermediate Operationen bisher. Somit können Stream Pipelines ab sofort flexibler und ausdrucksstärker implementiert werden. Das OpenJDK liefert auch gleich einige neue Operationen mit: fold, mapConcurrent, scan, windowFixed und windowSliding. In Zukunft können relativ einfach weitere folgen.
JEP 484 – Class-File API
Hier erfolgt nun ebenfalls nach zwei Previews die Finalisierung des neuen Standards zum Parsen, Generieren und Transformieren von Java-Bytecode (Class Files) basierend auf der Spezifikation der Java Virtual Machine. In Zukunft können alle JDK-Komponenten auf diese Standard-API migriert werden. Schlussendlich können die JDK-Entwickler dann die interne Kopie und damit die Abhängigkeit zur Drittanbieter-Bibliothek ASM entfernen.
JEP 488 – Primitive Types in Patterns, instanceof, and switch (Second Preview)
Es geht in diesem zweiten Preview um die Erweiterung des Pattern Matching, sodass primitive Datentypen wie int, byte und double in allen Pattern-Kontexten verwendet werden dürfen, also beim instanceof und im switch. Entwickler haben dadurch weniger Limitierungen und Sonderfälle und können primitive und Referenzdatentypen auch im Kontext von Type Patterns oder als Komponenten in Record Patterns austauschbar verwenden. Seit der ersten Preview gibt es keine Änderungen, die JDK-Entwickler wollen aber weiteres Feedback sammeln.
JEP 499 - Structured Concurrency (Fourth Preview)
Bei der Bearbeitung von mehreren parallelen Teilaufgaben erlaubt Structured Concurrency die Implementierung auf eine besonders les- und wartbare Art und Weise. Alternativ konnten Entwickler für diesen Zweck bisher die Parallel Streams, den ExecutorService oder reaktive Programmierung einsetzen. Alles sehr mächtige Ansätze, die aber gerade einfache Umsetzungen unnötig kompliziert und fehleranfällig machen. Structured Conncurrency behandelt Gruppen von zusammengehörigen Aufgaben als eine Arbeitseinheit, wodurch die Fehlerbehandlung sowie das Abbrechen der Aufgaben vereinfacht und die Zuverlässigkeit sowie die Beobachtbarkeit erhöht werden. Änderungen zur letzten Preview gibt es keine. Die Macher des OpenJDK wünschen sich vielmehr weitere Rückmeldungen aus der "realen" Welt.
JEP 487 – Scoped Values (Fourth Preview)
Einführung eines Gültigkeitsbereichs, sodass unveränderliche Daten sowohl in den Aufrufen innerhalb eines Threads als auch in Child-Threads geteilt und verwendet werden können. Scoped Values lassen sich einfacher nachvollziehen, verfolgen aber ähnliche Ziele wie ThreadLocal-Variablen. Sie haben auch einen geringeren Platz- und Zeitbedarf, insbesondere wenn sie zusammen mit virtuellen Threads (JEP 444 [2]) und Structured Concurrency (JEP 480 [3]) verwendet werden. Eine Änderung gibt es diesmal: Die Methoden callWhere() und runWhere() wurden aus der Klasse ScopedValue entfernt. Ihre Funktionalität kann aber noch über ein Objekt der Klasse Carrier aufgerufen werden, welches die Methode where() von ScopedValue zurückliefert. Dadurch wird die API vollständig fluent. Die Funktion call() liefert übrigens ein Ergebnis, während die Prozedur run() nichts zurückgibt.
JEP 489 – Vector API (Ninth Incubator)
Die Vector API ist der Dinosaurier unter den JEPs und nun schon das neunte Mal als Inkubator dabei. Seit Java 16 taucht sie regelmäßig in den Releases auf. Es geht dabei um die Unterstützung der modernen Möglichkeiten von SIMD-Rechnerarchitekturen mit Vektorprozessoren. Single Instruction Multiple Data (SIMD) lässt viele Prozessoren gleichzeitig unterschiedliche Daten verarbeiten. Durch die Parallelisierung auf Hardwareebene verringert sich beim SIMD-Prinzip der Aufwand für rechenintensive Schleifen. Der Grund für die lange Inkubationsphase hängt mit der Abstimmung mit dem Projekt Valhalla zusammen. Man wartet auf die Reformen am Typsystem (JEP 401: Value Classes and Objects [4]). Die Entwickler des JDK wollen vor der Finalisierung der Vector API die derzeitigen wertbasierten Klassen (Referenztypen) in Value Classes (ohne Objektidentität) umwandeln. Das kann noch etwas dauern, denn für das OpenJDK 24 sind die Value Types bisher noch nicht auf dem Plan. Aber immerhin hat Brian Goetz (Java Language Architekt bei Oracle) im Sommer 2024 angekündigt, dass sie beim Projekt Valhalla nach 10 Jahren den Durchbruch in der Implementierung geschafft haben. Hier könnte also mit dem OpenJDK 25 vielleicht schon die erste Preview auftauchen.
JEP 486 – Permanently Disable the Security Manager
Der Security Manager wurde häufig zur Absicherung von clientseitigem Java-Code (Rich-Clients, Applets), aber nur selten für die Server-Seite verwendet. Zudem ist seine Wartung teuer. Mit Java 17 (2021) wurde er als Deprecated for Removal markiert. Nun wird er intern ausgebaut. Er kann jetzt nicht mehr aktiviert werden und andere Klassen der Java-Plattform verweisen nicht mehr darauf. Diese Änderung wird aber vermutlich keine Auswirkungen auf die große Mehrheit der Anwendungen, Bibliotheken und Tools haben. In einer der zukünftigen Java-Versionen wird die Security Manager API endgültig entfernt.
JEP 492 – Flexible Constructor Bodies (Third Preview)
In Konstruktoren dürfen Anweisungen nun bereits vor einem expliziten Konstruktoraufruf (super() oder this()) erscheinen. Diese Anweisungen dürfen zwar nicht auf die zu konstruierende Instanz verweisen, können jedoch Parameter validieren bzw. transformieren oder auf Felder der Oberklasse zugreifen. Die Initialisierung von Feldern vor dem Aufruf eines anderen Konstruktors macht die Klasse zuverlässiger, wenn beispielsweise Methoden überschrieben werden.
JEP 494 – Module Import Declarations (Second Preview)
Dadurch lassen sich jetzt in Java alle exportierten Packages eines Moduls auf einmal importieren. Das vereinfacht die Wiederverwendung modularer Bibliotheken. Es ist übrigens nicht erforderlich, dass der importierende Code selbst in einem Modul enthalten ist. Bei dieser zweiten Preview gibt es zwei Erweiterungen. Einerseits wurden Beschränkungen bei den transitiven Abhängigkeiten vom Modul java.se (eine Art Aggregator-Modul ohne eigene Packages/Klassen) zu java.base aufgehoben. Dadurch kann man nun mit dem Import dieses einen Moduls die gesamte API von Java SE importieren. Außerdem ist es jetzt möglich, dass sogenannte Type-Import-on-Demand-Deklarationen (z. B. import java.util.*) vorherige Modul-Import-Deklarationen überdecken. Wenn beispielsweise die Module java.base und java.sql importiert werden, gäbe es eine Unklarheit beim Verwenden der Klasse Date. Die gibt es als java.util.Date und als java.sql.Date. Durch die on-demand-Deklaration import java.util.* wird in dem Fall java.util.Date verwendet.
JEP 495 – Simple Source Files and Instance Main Methods (Fourth Preview)
Das Ziel ist, Anfängern den Einstieg in Java zu erleichtern und erfahrenen Entwicklerinnen und Entwicklern die Möglichkeit zu geben, kleine Anwendungen einfach bauen und ausführen zu können. Anfänger wie auch Fortgeschrittene müssen sich somit nicht mit den für große Programme konzipierten Sprachfunktionen auseinandersetzen. In dieser vierten Preview soll weiter Feedback gesammelt werden. Unter Beibehaltung der bestehenden Java-Toolchain und nicht mit der Absicht, einen separaten Dialekt für Java einzuführen, lassen sich in simplen Java Source Files, die nur eine vereinfachte main-Methode (ohne Klassen-Deklaration) enthalten, einfache, skriptartige Programme erstellen. Dazu kommt die leichtere Verwendung von Standardein- und -ausgabe durch die neuen statischen Methoden print(), println() und readln() der Klasse java.io.IO. Diese wird zum Teil automatisch importiert, womit die Funktionen einsatzbereit sind.
URL dieses Artikels:
https://www.heise.de/-10051629
Links in diesem Artikel:
[1] https://openjdk.org/projects/jdk/24/
[2] https://openjdk.org/jeps/444
[3] https://openjdk.org/jeps/480
[4] https://openjdk.org/jeps/401
[5] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: jakkaje879/Shutterstock.com)
Die Bücher des Bloggers Dotnet-Doktor sind passend zum Release avon.NET 9.0 auf dem aktuellen Stand.
Pünktlich zum Release von .NET 9.0 [1] ist es mir auch dieses Jahr wieder gelungen, dass meine .NET-Bücher auf dem RTM-Stand (Release to Manufacturing) verfügbar sind:
Die Bücher gibt es in gedruckter Form (Print-on-Demand), im PDF-Format und als Kindle-E-Book.
(Bild: IT-Visions.de [6])
URL dieses Artikels:
https://www.heise.de/-10032056
Links in diesem Artikel:
[1] https://www.heise.de/news/Microsoft-NET-9-0-bringt-Breaking-Changes-und-neue-KI-Bibliothek-10031831.html
[2] https://it-visions.de/buch/N9U
[3] https://it-visions.de/buch/CSC13
[4] https://it-visions.de/buch/EFC13
[5] https://it-visions.de/buch/BLA90
[6] http://www.it-visions.de/NET9buecher
[7] https://net.bettercode.eu/?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link
[8] https://net.bettercode.eu/index.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link#programm
[9] https://net.bettercode.eu/tickets.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link
[10] mailto:mdo@ix.de
Copyright © 2024 Heise Medien
(Bild: erstellt mit KI (Dall-E) von iX-Redaktion)
Ein neuronales Netz von Grund auf selbst zu entwickeln, trägt enorm zum Verständnis von KI bei. Das richtige Buch hilft, diesen Wunsch zielführend umzusetzen.
Manchen mag es heute so gehen wie mir vor acht Jahren: Ich wollte unbedingt mein eigenes neuronales Netz bauen, hatte jedoch von Künstlicher Intelligenz ungefähr so viel Ahnung wie eine Kuh vom Fahrradfahren. Zum Glück gibt es Bücher, mit denen man sich weiterbilden kann. Das große Problem besteht in der Regel allerdings darin, ein Buch zu finden, das auch wirklich weiterhilft: Es soll praktisch sein, aber auch die grundlegende Theorie vermitteln. Es darf nicht zu akademisch sein, sondern sollte alltagstauglich bleiben. Es soll dies, es sollte das, es sollte jenes.
Damals stieß ich dann durch Zufall auf ein außergewöhnlich gutes Buch, das mir sehr geholfen hat, ein fundiertes Verständnis und eine gute Vorstellung von neuronalen Netzen zu bekommen. Und ich habe im Anschluss tatsächlich mein erstes neuronales Netz gebaut. Dieser Blogpost eignet sich vor allem für diejenigen, die den gleichen Wunsch haben wie ich damals.
Was eine Künstliche Intelligenz ist, davon hatte ich schon seit meiner Kindheit eine recht genaue Vorstellung: Für mich war das immer ein Computer, der mithilfe seiner Schaltkreise "denken" kann. Einer, der in der Lage ist, Menschen und seine Umwelt zu verstehen, zu lernen, logische Schlüsse zu ziehen, und so weiter. Geprägt wurde diese Vorstellung bei mir ganz klar durch den berühmten Roman von Arthur C. Clarke und den gleichnamigen Film von Stanley Kubrick: "2001: Odyssee im Weltraum [1]".
Der darin vorkommende Computer HAL 9000 ist für mich der Inbegriff von Künstlicher Intelligenz, und ich habe als Kind davon geträumt, eines Tages mit einem solchen Computer interagieren zu können. Oder noch besser, eines Tages selbst einen solchen Computer zu entwickeln. Insofern sind Arthur C. Clarke und Stanley Kubrick in gewissem Sinne mitschuldig daran, dass ich den Weg in die Informatik eingeschlagen habe. Tatsächlich hat HAL bis heute nichts von seiner Faszination auf mich verloren, im Gegenteil. Allerdings bin ich mir nicht mehr so sicher wie damals, ob ich ihn in der Realität wirklich haben wollen würde …
Der Punkt ist: So wie es mir damals ging, geht es Ihnen vielleicht heute auch. Soll heißen: Vielleicht tragen auch Sie schon seit einer Weile den Wunsch mit sich herum, eine eigene Künstliche Intelligenz zu entwickeln. Es muss ja vielleicht nicht gleich ein Supercomputer à la HAL 9000 sein, aber so ein kleines, schnuckeliges neuronales Netz wäre vielleicht doch ganz cool. Die gute Nachricht ist: Das ist gar nicht so schwer, wie Sie vielleicht denken.
Die zweite gute Nachricht ist: Neuronale Netze sind die Grundlage von so vielem heutzutage, dass es ungemein praktisch ist, zu verstehen, wie sie funktionieren. Also nicht nur, sie anwenden zu können, sondern wirklich zu begreifen, was ein neuronales Netz ist, warum es auf eine gewisse Art aufgebaut wird, wie und warum es funktioniert, und so weiter. Ich bin der festen Überzeugung, dass es, trotz all der KI-Frameworks wie TensorFlow, Keras, PyTorch & Co., die das Anwenden von Künstlicher Intelligenz sehr einfach machen, eine sehr gute Idee ist, auch zu verstehen, wie das Ganze überhaupt funktioniert.
Nun ist das Problem, dass es kaum gute Literatur oder andere Quellen gibt. Entweder sind die Materialien, die man findet, viel zu akademisch und mathematisch oder sie streifen die Grundlagen und die zugrunde liegende Theorie nur kurz und konzentrieren sich auf die Anwendung. Ersteres sind zum Beispiel die von Stanford verfügbaren Online-Kurse, und Letzteres sind die ganzen Bücher mit Titeln wie "Keras: Machine-Learning in der Praxis" oder "Einführung in die KI mit TensorFlow".
(Bild: O'Reilly)
Genau an diesem Punkt stieß ich vor vielen Jahren auf ein fantastisches Buch: Es hieß "Make Your Own Neural Network" und stammte aus der Feder von Tariq Rashid. Das Wort "Buch" ist hier fast schon zu hoch gegriffen: Es war eher eine umfangreiche Broschüre, da der Autor es damals selbst verlegt hatte, ohne einen professionellen Verlag dahinter. Dem Inhalt hat das jedoch keinen Abbruch getan, im Gegenteil: Ich war sehr beeindruckt, wie anschaulich und greifbar er erklärt hat, wie man ein eigenes neuronales Netz entwickelt, und zwar wirklich von Grund auf, also ohne die genannten Frameworks, aber eben auch ohne dafür Mathematik studiert haben zu müssen.
Im vergangenen Juni stellte ich nun fest, dass O’Reilly das Ganze als Buch herausgebracht hat. Da der Vertrieb von O’Reilly im deutschsprachigen Raum vom dpunkt.verlag übernommen wird, und mein Unternehmen (the native web [3]) mit diesem wiederum eine Kooperation hat, habe ich die Neuausgabe als Rezensionsexemplar kostenlos zur Verfügung gestellt bekommen. Das heißt jedoch nicht, dass ich das Buch schönreden muss: Ich teile hier ganz unabhängig meine Meinung und sage, was mir an dem Buch gefällt und was nicht. Ich werde nicht dafür bezahlt, und es gibt keine Vereinbarung, dass ich das Buch in den Himmel loben müsste. Ich sage das nur deshalb so explizit dazu, um offen, ehrlich und transparent zu sein, denn das ist uns sehr wichtig.
Die Frage lautet also nun: Wie fangen Sie an, wenn Sie ein eigenes neuronales Netz bauen möchten? Eigentlich ist das ganz klar: Zuerst einmal müssen Sie einige grundlegende Konzepte kennenlernen. Sie müssen wissen, welche Arten von neuronalen Netzen es gibt: Es gibt Netze, die versuchen, einen konkreten Wert vorherzusagen, und solche, die versuchen, einen gegebenen Wert zu kategorisieren, oder genauer gesagt, zu klassifizieren. Natürlich gibt es noch weitere Arten, aber das sind die beiden grundlegenden Typen.
Dann stellt sich die Frage: Was ist überhaupt ein Neuron? Wie ist es intern aufgebaut und wie funktioniert es? Was ist eine Aktivierungsfunktion? Wie formt man aus einzelnen Neuronen eine Schicht und daraus wiederum ein Netz? Wie lernt ein solches Netz überhaupt, was es tun soll? Und so weiter.
Es gibt also viele Fragen, die noch gar nicht darauf abzielen, wie man ein neuronales Netz schlussendlich baut, sondern erst einmal darauf, zu verstehen, was überhaupt die Bauteile eines solchen Netzes sind. Das Schöne ist: Um das zu erklären, braucht man nicht viel. Im Prinzip reichen ein Blatt und ein Stift aus, um das Ganze aufzumalen, und die Mathematik, die man benötigt, hat man (und das meine ich ernst) weitestgehend bereits in der Grundschule gelernt.
Viel mehr als Addition, Multiplikation und ein bisschen lineare Gleichungen ist es in weiten Teilen nämlich nicht. Wenn man es effizient machen möchte, braucht man vielleicht noch die Matrizenmultiplikation, aber auch das ist am Ende nur eine Kombination von Addition und Multiplikation. Und das Einzige, wofür man tatsächlich etwas mehr Mathematik benötigt, ist das eigentliche Lernen oder Trainieren der Netze mit dem sogenannten Backpropagation-Algorithmus, für den man dann Ableitungen braucht.
Aber auch das ist kein Universitätswissen, sondern Schulstoff der gymnasialen Oberstufe. Mit anderen Worten: Jede Schülerin und jeder Schüler der 11. Klasse bringt das Wissen und das mathematische Handwerkszeug mit, das man für neuronale Netze im Wesentlichen braucht.
Vielleicht mag das jetzt nach viel klingen. Tatsächlich ist es aber gar nicht so umfangreich, denn Tariq Rashid beschreibt das alles im ersten Kapitel des Buches auf gerade einmal 90 Seiten. Auch das klingt vielleicht viel, aber zum einen sind dort viele Beispiele und Abbildungen enthalten (die übrigens in Farbe gedruckt sind, was ich schön finde), und zum anderen nimmt er sich wirklich viel Zeit für die Erklärungen, sodass man gut folgen kann.
Um es anders zu formulieren: Nach 90 anschaulichen, gut verständlichen und kurzweiligen Seiten haben Sie die komplette Basis verstanden, wie neuronale Netze arbeiten – von einfachen Netzen bis hin zu den Transformern in modernen Sprachmodellen, denn auch diese basieren letztlich auf neuronalen Netzen, wenn auch sehr komplexen. Aber 90 Seiten, das war’s.
Das heißt, wenn Sie all das kennengelernt haben, dann haben Sie ein intuitives Grundverständnis dafür, was ein neuronales Netz ist und wie und warum es funktioniert. Vielleicht wird das Ganze ein wenig ernüchternd wirken, denn es ist keine dunkle Magie oder etwas Mystisches: Es sind nur ein paar mathematische Formeln. Im Prinzip so etwas wie
f(x) = x^2
in komplexerer Form. Allein das ist aus meiner Sicht schon eine durchaus wichtige Erkenntnis, denn genauso wenig, wie diese einfache Funktion ein Bewusstsein hat oder die Weltherrschaft anstrebt, macht das irgendeine andere mathematische Formel, selbst wenn sie komplexer ist und mit mehr Variablen arbeitet. Verstehen Sie mich dabei bitte nicht falsch: Damit will ich mitnichten sagen, dass von Künstlicher Intelligenz keine Gefahr ausgehen könnte, aber das typische Schreckensszenario à la
"Wir werden alle sterben, weil die KI sich selbstständig macht."
ist Blödsinn. Die KI an sich, oder das neuronale Netz an sich, ist letztlich einfach nur eine komplexe Formel, nicht mehr und nicht weniger.
Nun muss man das Ganze natürlich auch umsetzen können. Genau das passiert im zweiten Kapitel des Buches, auf insgesamt rund 70 Seiten: Dort erklärt Tariq Rashid zuerst im Schnelldurchlauf die Programmiersprache Python. Ob Sie das Ganze letztlich in Python oder in einer anderen Sprache nachbauen, ist für das Verständnis nebensächlich – mit Python wird es Ihnen jedoch leichter gemacht, wenn Sie später doch mit Frameworks arbeiten möchten, da die meisten davon für Python verfügbar sind.
Python als Sprache selbst hat keinerlei besondere Eigenschaften, die sie besonders gut für Künstliche Intelligenz geeignet machen. Es liegt viel eher am Ökosystem drumherum. Für den Anfang ist das jedoch relativ egal, ich selbst habe das Ganze damals mit JavaScript auf der Basis von Node.js umgesetzt.
Nach dieser kurzen Einführung ist das zweite Kapitel dann im weiteren Verlauf ziemlich geradlinig: Sie müssen einfach das, was Sie in Kapitel 1 gelernt haben, in Programmcode umsetzen. Das ist vor allem eine Fleißaufgabe und hat wenig mit Verständnis zu tun, denn die notwendige gedankliche Vorarbeit haben Sie in Kapitel 1 schon lange geleistet. Natürlich stellt sich die spannende Frage: Wie gut ist denn ein neuronales Netz, das man selbst baut?
Um das beurteilen zu können, braucht man ein konkretes Beispiel. Der Autor verwendet dafür den MNIST-Datensatz, eine Sammlung von handgeschriebenen Ziffern, die als Einzelbilder vorliegen. Damit trainiert er dieses erste Netz. Ziel ist es, mit möglichst hoher Erkennungsrate vorherzusagen, welche Ziffer auf einem gegebenen Bild zu sehen ist. Er erreicht mit diesem ersten Netz ohne weitere Optimierung eine Erfolgsrate von rund 97 %.
Das finde ich schon ziemlich beeindruckend. Natürlich mussten die Daten dafür vorbereitet werden, aber auch das erklärt Rashid ausführlich und anschaulich, sodass man versteht, dass es normal ist, dass Daten für eine KI immer in der einen oder anderen Form aufbereitet werden müssen.
Die übrigen 40 Seiten des Buches sind relativ schnell abgehakt: Im dritten Kapitel geht es noch um die Frage, wie man das Training verbessern könnte, das ist aber wirklich nur ein Ausblick. Das vierte und letzte Kapitel gibt dann eine Einführung, wie man das Ganze mit PyTorch umsetzen könnte, einfach weil Sie in der Praxis vermutlich eher mit einem solchen Framework arbeiten werden, als alles von Hand zu programmieren. Trotzdem – und das war mein Punkt am Anfang dieses Blogposts – ist es hilfreich zu wissen, wie das Ganze unter der Haube zusammenhängt und funktioniert. Im Anhang gibt es dann noch eine kurze Einführung in die Analysis, weil vielleicht doch nicht jede Entwicklerin und jeder Entwickler eine Ableitung "mal eben so" berechnen kann.
Und das ist dann das gesamte Buch mit seinen rund 250 Seiten. Das Erstaunliche dabei ist, dass eigentlich nur die ersten 160 Seiten wirklich wichtig für den Einstieg und das Verständnis sind. Der Rest ist eher eine nette Beigabe. Wenn Sie sich vertieft mit der Anwendung beschäftigen möchten, würde ich Ihnen ohnehin ein anderes Buch nahelegen, nämlich "Deep Learning illustriert [4]" von Jon Krohn, Grant Beyleveld und Aglaé Bassens, das ich vor rund einem Jahr vorgestellt und besprochen habe.
So oder so: Ich wünsche Ihnen viel Spaß und Erfolg bei Ihrem ersten eigenen neuronalen Netz!
Tariq Rashid
Neuronale Netze selbst programmieren: Ein verständlicher Einstieg mit Python [5]
O'Reilly, 2. Auflage 2024
448 Seiten
ISBN (Print): 978-3-96009-245-2
[Anmerkung d. Red.: Der dpunkt.verlag als Herausgeber des Buches ist wie heise online Teil der heise group]
URL dieses Artikels:
https://www.heise.de/-10002704
Links in diesem Artikel:
[1] https://de.wikipedia.org/wiki/2001:_Odyssee_im_Weltraum
[2] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[3] https://www.thenativeweb.io/
[4] https://www.youtube.com/watch?v=rE2xwBBZflA
[5] https://dpunkt.de/produkt/neuronale-netze-selbst-programmieren-2/
[6] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: erstellt mit KI (Dall-E) durch iX)
Version 2.0 bricht mit vielen ehemaligen Idealen des Deno-Projektes. Doch ist das gar nicht so schlimm, da Deno dadurch erst massentauglich wird.
Seit über vier Jahren veröffentlichen wir annähernd jede Woche ein neues Video auf dem YouTube-Kanal meines Unternehmens [1], und im Laufe der Zeit habe ich dabei auch die eine oder andere Einschätzung zu der einen oder anderen Technologie abgegeben. Dabei gehe ich nicht leichtfertig vor, sondern mache mir im Vorfeld intensiv Gedanken, welche Technologien in der Zukunft funktionieren könnten und welche eher nicht, worauf der Markt anspringen wird und worauf eher nicht, und so weiter. Ohne mich selbst loben zu wollen, würde ich sagen, dass ich ein passables Händchen dafür habe, zukünftige Trends und Entwicklungen frühzeitig zu erkennen und entsprechend vorherzusagen. Trotzdem liege auch ich natürlich gelegentlich daneben.
Das kann zum einen passieren, wenn mir aller Sorgfalt zum Trotz doch eine Fehleinschätzung unterläuft, weil ich zum Beispiel einen wesentlichen Aspekt nicht gesehen habe. Das kann aber auch passieren, weil sich manche Technologien im Laufe der Zeit dermaßen stark verändern, dass ich sie nach einer Weile eigentlich neu bewerten und meine bisherige Meinung gegebenenfalls revidieren muss. Und genau das ist heute der Fall: Heute müssen wir nämlich einmal über die neu erschienene Version 2 von Deno [2] sprechen.
Wer unsere Videos schon länger verfolgt, weiß, dass die ersten Videos zu Deno fast auf den Tag genau vier Jahre zurückliegen. Ausgangspunkt war damals der Vortrag von Ryan Dahl auf der JSConf EU 2018 mit dem Titel "Ten Things I Regret About Node.js [3]". Dazu habe ich damals eine erste Einschätzung [4] abgegeben: Im Unterschied zu vielen anderen konnte ich seiner Argumentation nicht viel abgewinnen. Daran hat sich bis heute nichts geändert: Ich fand seinen Vortrag, um ehrlich zu sein, inhaltlich schwach und die genannten Argumente dürftig.
Die damalige Ankündigung von Deno wirkte auf mich maßlos überzogen. Ja, es gab ein oder zwei interessante Aspekte, wie das konsequente Nutzen der V8-Sandbox, aber es gab genug Punkte, die bereits damals überholt, irrelevant oder einfach nicht durchdacht waren. Oft habe ich danach kritisiert, wie sich Ryan Dahl verhalten hat: Wäre es ihm wirklich darum gegangen, die Welt für JavaScript-Entwicklerinnen und -Entwickler zu verbessern, hätte er sich (aus meiner Sicht) eher wieder bei Node.js engagieren sollen, statt das JavaScript-Ökosystem nun auch auf dem Server zu fragmentieren.
Außerdem wirkte die ganze vorgeschobene Reue auf mich wie ein Vorwand, um im Hintergrund ein Unternehmen aufzubauen – was natürlich völlig legitim ist, aber für meinen Geschmack nicht transparent genug kommuniziert wurde. Insgesamt war mir der Vortrag zu pathetisch, zu viel Drama, zu viel Show und zu wenige echte Argumente. Kurz gesagt: Ich hielt Deno damals vor allem für heiße Luft.
Tja, und was soll ich sagen? Seit der Ankündigung vor immerhin sechs Jahren ist Deno eher gefloppt. Ja, es hatte sicherlich einen gewissen Einfluss auf die Weiterentwicklung von Node.js, aber dieser dürfte doch überschaubar gewesen sein. Im Gegenzug hat Deno jedoch die Fragmentierung von JavaScript auf dem Server [6] eingeleitet, was inzwischen mit Bun noch schlimmer wurde. Apropos Bun: Auch davon hört man abseits einer sehr kleinen und überschaubaren Community nichts, und auch hier wird mir zu viel Show gemacht und zu wenig geliefert. Bis hierhin bleibt Deno für mich also vor allem viel Show, viel Gerede, wenig Substanz und vor allem eines – unnötig.
Das Interessante dabei ist, dass vieles von dem, was Ryan Dahl damals groß angekündigt hat, sich letztlich als nicht sonderlich schlaue Idee erwiesen hat, wie beispielsweise seine große Kritik an der vermeintlich ach so "bösen" package.json-Datei, in der in Node.js die Abhängigkeiten verwaltet werden. Was wurde nicht alles gesagt, was an npm schlecht sei, warum das alles ein grundlegender Designfehler sei, und so weiter. Das alles müsse man nun besser machen (und "besser" hieß vor allem anders). Turns out: npm ist sicherlich nicht perfekt, aber um Welten besser, als Ryan Dahl es damals dargestellt hat. All die Ansätze, die Deno seitdem versucht hat, um Abhängigkeiten anders zu verwalten, haben am Ende nur eines bewirkt: Inkompatibilität und – ironischerweise – neue Probleme.
Weil irgendwann dann auch das Team hinter Deno gemerkt hat, dass es keine gute Idee ist, das bestehende JavaScript-Ökosystem komplett zu ignorieren und auszuschließen, hat man bei Deno dann eine Kehrtwende vollzogen und eine provisorische Unterstützung für npm integriert. Und plötzlich war Deno nicht mehr eine völlige Insellösung, sondern man konnte immerhin ein bisschen damit arbeiten. Trotzdem funktionierte vieles nicht. Deshalb wurde die Kompatibilität zu npm und übrigens auch zu Node.js nach und nach weiter ausgebaut, denn man merkte, dass der Umstieg unattraktiv ist, wenn praktisch alle Basis-APIs fehlen, sie anders heißen oder anders funktionieren.
Deno hat sich also nach und nach von vielen seiner vermeintlichen Ideale abgewendet und versucht nun, 90 Prozent all dessen zu unterstützen, was angeblich so schlecht und fehlerhaft gewesen sei. Das gipfelte Anfang Oktober in der Veröffentlichung von Deno 2.0 [7].
Das war für mich Grund genug, meine Meinung noch einmal auf den Prüfstand zu stellen. Und ich muss sagen, ich muss einiges revidieren: Deno 2 ist die erste Version von Deno, die wirklich interessant ist, weil es endlich mehr als nur eine akademische Fingerübung darstellt, und eine Menge interessanter Punkte bietet, die es als möglichen Ersatz für Node.js positionieren könnten. Der Zeitpunkt dafür ist sogar günstig, denn bei Node.js häufen sich die Probleme: Es entwickelt sich zwar weiter, aber es gibt zu viele angefangene Baustellen und es wird immer chaotischer. Deshalb war der Titel eines unserer Videos vor rund sechs Monaten auch schon: "Node 22, lass uns Freunde bleiben [8]". Auf gut Deutsch: Ich habe keine Lust mehr auf eine Beziehung mit dir, ich mache Schluss!
Und da kommt nun eben Deno 2 ins Spiel. Das Besondere an Deno 2 ist, dass das Team dahinter sich große Mühe gegeben hat, die mangelnde Kompatibilität zu Node.js und npm zu überwinden. Ab Deno 2 ist es nun möglich, Deno als echtes Drop-in-Replacement zu nutzen. Das Versprechen lautet: Alles, was in Node.js läuft, läuft auch in Deno. Das gilt für kleine und große Anwendungen und bezieht viele Frameworks wie Next.js, Astro, Remix, Angular, SvelteKit und mehr ein – alles läuft out of the box. Aber Deno ist nicht einfach eine 1:1-Kopie von Node.js geworden, sondern ist in gewissem Sinne inzwischen "das bessere Node".
Denn Deno bringt (nicht erst seit Version 2) eine Reihe von Features mit, von denen Node.js nur träumen kann: native TypeScript-Unterstützung (die gibt es in Node.js inzwischen, allerdings ist sie noch sehr rudimentär), ein eingebauter Formatter, ein integrierter Linter, ein Type-Checker, ein Test-Framework, ein Compiler, ein sinnvolles Sicherheitskonzept, bei dem nicht jeglicher Code aus dem Internet ungefragt mit Full-Trust läuft, und so weiter. All das fehlt Node.js seit nunmehr 15 Jahren. Und dabei ist das Ganze in Deno auch noch sehr schnell und durchdacht umgesetzt.
Ein Beispiel: In Deno muss TypeScript-Code nicht von Hand kompiliert werden, das erledigt Deno automatisch, sobald die Anwendung gestartet wird. Aus Performance-Gründen wird dabei allerdings auf die Typprüfung von TypeScript verzichtet, es sei denn, sie wird explizit mit dem Parameter --check angefordert. Bei der Ausführung von Tests hingegen ist die Typprüfung standardmäßig aktiv. Das ergibt Sinn: Während der Entwicklung, wenn es nicht auf das letzte Quäntchen Performance ankommt, hat man die gewünschte Typsicherheit, bei der Ausführung dafür eine möglichst gute Performance. Und das Schöne ist, dass das Test-Framework in Deno bereits enthalten ist, es muss also nichts zusätzlich installiert werden.
Node.js bietet ein paar Aspekte davon inzwischen zwar ebenfalls, aber es hat sehr lange gedauert, und es kommt weder vom Umfang noch von der Integration an Deno heran. Und Deno endet hier nicht: Das Test-Framework geht beispielsweise deutlich weiter als das von Node, denn Deno kann direkt auch die Code-Coverage berechnen, Benchmarks ausführen und mehr.
All diese Funktionen, um Tests auszuführen, Code-Coverage zu ermitteln und Benchmarks durchzuführen, sind im Deno-Binary von Haus aus enthalten. Man braucht also nur ein einziges Tool, um all diese Dinge nutzen zu können. Darüber hinaus ist zum Beispiel aber auch noch ein Formatter integriert, der nicht nur JavaScript und TypeScript, sondern auch HTML, CSS und YAML formatiert. Ein umfangreicher Linter ist ebenfalls enthalten, eine integrierte Lösung zum Ausführen von Tasks, ein Dokumentationsgenerator und ein Compiler, um echte Binaries zu erzeugen. Letzteres ist bei Node.js zwar in der Theorie auch möglich [9], jedoch dermaßen umständlich gelöst, dass es absolut keinen Spaß macht, das Feature zu nutzen.
Deno enthält außerdem einen Webserver, Unterstützung für Jupyter-Notebooks und vieles mehr – und all das in einer einheitlichen und aufeinander abgestimmten Form, während man bei Node alles mühsam zusammensuchen und von Hand konfigurieren muss. Und das ist am Ende das, wodurch Deno 2 besonders auffällt: Einfachheit und "it just works".
Hat man beispielsweise eine Anwendung, die npm-Module verwendet, muss man bei Deno kein "npm install" mehr ausführen. Deno lädt die benötigten Module beim ersten Start der Anwendung automatisch herunter und cacht sie lokal. Das funktioniert so gut und transparent im Hintergrund, dass man beim Entwickeln nach einer halben Stunde vergessen hat, dass man jemals "npm install" ausführen und sich mit einem node_modules-Verzeichnis oder einer Lock-Datei herumschlagen musste. Und das alles geht dabei auch noch unglaublich schnell – jeder Package-Manager, den ich bisher unter Node.js gesehen habe, kann da im Vergleich einpacken. Das ist wirklich gut gelöst, und das ist der Eindruck, den Deno 2 hinterlässt: Es wirkt wie Node.js, aber neu durchdacht.
Vielleicht war Deno 1 in den vergangenen sechs Jahren so gesehen einfach nur ein Proof of Concept: Ein nicht schöner, aber notwendiger Prototyp, um herauszufinden, wohin die Reise eigentlich gehen soll, und Deno 2 ist nun die echte erste Version.
Und da muss ich ganz ehrlich meinen Respekt aussprechen, denn Deno 2 ist eine sehr gelungene zweite Version. Auf einmal macht es wieder Spaß, mit TypeScript zu entwickeln, weil man nicht hundert verschiedene Dinge installieren und konfigurieren muss, sondern einfach nur einen Editor öffnet, ein paar Zeilen schreibt und ausführt. Und formatiert. Und testet. Und so weiter. Und all das, ohne auch nur ansatzweise irgendetwas dafür installieren zu müssen.
Im Vergleich dazu, wie sich Node.js aktuell anfühlt, ist das ein großer Schritt nach vorn. Es fühlt sich endlich wieder modern und zeitgemäß an. Und insofern muss ich sagen: Sobald die passende Laufzeitumgebung da ist, macht TypeScript auf einmal wieder eine Menge Spaß. Danke, Deno 2!
URL dieses Artikels:
https://www.heise.de/-9987604
Links in diesem Artikel:
[1] https://www.youtube.com/@thenativeweb
[2] https://deno.com/blog/v2.0
[3] https://www.youtube.com/watch?v=M3BM9TB-8yA
[4] https://www.youtube.com/watch?v=7oeR1GcVK3Y
[5] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[6] https://www.youtube.com/watch?v=WLklm8JQbjo
[7] https://www.heise.de/news/JavaScript-Runtime-Deno-2-0-nimmt-es-mit-Node-js-auf-9976092.html
[8] https://www.youtube.com/watch?v=GH8gSl-z9Wg
[9] https://www.youtube.com/watch?v=6ThplMUASJA
[10] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: erstellt mit KI (Dall-E) von iX-Redaktion)
Viele Softwareprojekte sprengen sowohl den zeitlichen als auch den finanziellen Rahmen und liefern dann nachher trotzdem nicht das gewünschte Ergebnis. Warum?
Wussten Sie, dass ungefähr 75 Prozent aller Softwareprojekte scheitern? Entweder dauern sie länger als ursprünglich geplant oder sie kosten mehr als erwartet (oder beides) und liefern trotzdem nicht das gewünschte Ergebnis. Das bedeutet, sie verfehlen das eigentliche Ziel. Da stellt sich natürlich die Frage: Woran liegt das eigentlich und was kann man als Team beziehungsweise als Unternehmen machen, um das bei eigenen Projekten zu vermeiden?
Bevor ich im Folgenden tiefer in das Thema einsteige, vorweg noch ein kleiner Hinweis: Die 75 Prozent sind natürlich nicht in Stein gemeißelt. Je nachdem, welche Studie man zurate zieht, sind es mal mehr, mal weniger Prozent. Aber selbst wenn es "nur" 50 Prozent wären, hieße das immer noch, dass jedes zweite Softwareprojekt Probleme hat. Und wenn man sich dann einmal überlegt, wie viel in unserer heutigen modernen Welt von Software abhängt, dann ist das so oder so schon ganz schön viel. Insofern: Nehmen Sie die 75 Prozent bitte nicht wortwörtlich, sondern als Tendenz und als ungefähre Größenordnung.
Warum also scheitern so viele Softwareprojekte und sprengen häufig zeitliche und finanzielle Rahmen? Das ist eine durchaus spannende Frage, denn an der eigentlichen Planung kann es kaum liegen: Teams und Unternehmen verbringen häufig sehr viel Zeit damit, sich Gedanken über die richtige Technologie zu machen. Da wird dann gerne wochen- oder gar monatelang diskutiert, ob nun zum Beispiel .NET oder Go vorzuziehen sei, ob React oder Web-Components die bessere Wahl sei, ob man eine SQL- oder eine NoSQL-Datenbank nehmen sollte, ob man MQTT brauchen wird oder nicht, und so weiter. Mit anderen Worten: Es wird viel Zeit mit der Evaluation und Auswahl von Technologien verbracht und daran sind üblicherweise viele kluge Köpfe beteiligt. Daher ist es eher unwahrscheinlich, dass dies das Problem ist.
Allerdings liegt es häufig auch nicht an der gewählten Architektur. Denn auch hier wird in der Regel sehr ausführlich und sorgfältig diskutiert: Es werden die Vor- und Nachteile von Monolithen, Microservices und Co. verglichen, es wird über REST, GraphQL und gRPC debattiert und architektonische Entscheidungen werden selten leichtfertig getroffen, sondern erst nach sorgfältiger Abwägung vieler Argumente. Auch die Architektur ist also häufig nicht das eigentliche Problem.
Am ehesten gerät als Nächstes dann der verwendete Entwicklungsprozess in Verdacht. Doch hier gibt es gar nicht dermaßen viele Unterschiede, wie man häufig zunächst meinen würde, denn viele Teams nutzen einfach Scrum, allein schon deshalb, weil sie Teil eines größeren Unternehmens sind und Scrum dort fest gesetzt ist. Bei Scrum im Speziellen und Agilität im Allgemeinen kann man zwar einiges falsch machen [2], aber andererseits gibt es auch immer wieder Teams, die erfolgreich agil arbeiten und bei denen man den Eindruck hat, dass Agilität verstanden wurde. Trotzdem bleibt die Softwareentwicklung am Ende oft eher mittelprächtig. Selbst wenn der Prozess nicht optimal ist, scheint er dennoch nicht das Hauptproblem zu sein.
Bleibt die Entwicklung an sich: Hier arbeiten in der Regel allerdings auch viele erfahrene und kompetente Menschen, die sich mit der gewählten Technologie gut auskennen. Wer sich beispielsweise für .NET, Web-Components und den SQL Server entscheidet, stellt in der Regel auch sein Team entsprechend so auf, dass es aus Menschen besteht, die mit diesen Technologien möglichst vertraut sind. Doch auch das garantiert erfahrungsgemäß nicht, dass die Softwareentwicklung später tatsächlich im Zeit-, Budget- und Funktionsrahmen bleibt. Wenn es also auch nicht an der Entwicklung selbst liegt – was bleibt dann noch?
Hier kommt ein Thema ins Spiel, das unglaublich gerne übersehen wird: Das Problem in der Softwareentwicklung sind in der Regel nämlich nicht die technischen Faktoren. Damit will ich nicht sagen, dass es keine technischen Schwierigkeiten gäbe, wie eine weniger geeignete Architektur oder unzureichendes technologisches Wissen. Tatsächlich ist das aber selten das Hauptproblem. Viel häufiger ist es so, dass vor lauter Technologie etwas anderes vernachlässigt wird – nämlich die Fachlichkeit. Ich kann gar nicht sagen, wie viele Teams ich schon kennengelernt habe, die technologisch topfit waren, die aber leider absolut keine Ahnung davon hatten, worum es in ihrem Projekt inhaltlich eigentlich ging.
Das merkt man immer, wenn man wie ich als externer Berater zu einem solchen Team stößt und die erstbeste Verständnisfrage stellt, wenn dann alle große Augen machen, niemand antworten kann (weil niemand die Antwort weiß) und man dann gesagt bekommt, dass diese Frage noch nie jemand gestellt hätte. Und es handelt sich dabei nicht um exotische Fragestellungen, sondern oft um elementare Grundlagen. Zum Beispiel bei einem Team, das Software für die Personalabteilung entwickelt, die Frage:
"Wie sieht der Prozess für eine Einstellung aus?"
Wenn schon diese Frage niemand beantworten kann, wie soll ein Team dann eine Software entwickeln, die dieses Thema adäquat und zielgerichtet digital abbildet? Um es kurz zu machen: Das kann nicht funktionieren!
Mit anderen Worten: Softwareentwicklung ist kein Selbstzweck. Wir als IT-Branche entwickeln Software nicht deshalb, weil es so toll ist, Software zu entwickeln, sondern weil wir ein tieferliegendes fachliches Problem lösen wollen. Damit eine Software ein Problem adäquat und zielgerichtet lösen kann, muss man jedoch als Entwicklerin oder Entwickler das zugrunde liegende fachliche Problem überhaupt erst einmal verstehen. Das heißt, man muss wissen, worum es geht, welche Prozesse es gibt, was die Rahmenbedingungen sind, wie der Kontext aussieht, um welche Daten es geht und was das alles im Detail für die Menschen bedeutet.
Das sind Fragen, die häufig nicht gestellt werden. Es wird einfach davon ausgegangen, dass das nicht so wichtig sei, dass sich das schon im Laufe der Zeit von selbst ergeben würde, dass es genüge, wenn der Product Owner Bescheid wisse und so weiter. Doch immer wieder stellt sich heraus, dass das nicht funktioniert.
Das führt dann dazu, dass in einem Team weder eine gemeinsame Sprache noch ein gemeinsames Verständnis der fachlichen Thematik existiert. Es wird zwar viel geredet, aber oft aneinander vorbei, weil niemand das Gegenüber wirklich versteht. Und anstatt nachzufragen, werden implizite Annahmen getroffen, und man lebt zu lange in dem Glauben, man wüsste, worum es eigentlich ginge. Wenn zwei Leute am selben Thema arbeiten und keine gemeinsame Sprache und kein gemeinsames Verständnis haben, wird es jedoch schwierig. Es werden unterschiedliche Begriffe für dasselbe Konzept genutzt, ohne zu wissen, ob wirklich alle das Gleiche meinen. Oder es wird ein Begriff verwendet, der von allen unterschiedlich interpretiert wird, was aber niemandem auffällt. Man bewegt sich in einer schwammigen, unklaren sprachlichen Blase und nimmt das als völlig normal hin.
Und dann wundert man sich, dass nach zwei Jahren nicht das herauskommt, was jemand anderes sich zwei Jahre zuvor vorgestellt hat. Ganz ehrlich: Es ist naiv anzunehmen, dass das jemals hätte funktionieren können. Ist es erst einmal so weit gekommen, muss nachgebessert werden. Das kostet Zeit und Geld. Und damit dauert es auf einmal länger und kostet mehr als geplant. Da man nach zwei Jahren aber nicht einfach alles über den Haufen werfen möchte, arbeitet man eher an den Symptomen als an den Ursachen.
Das heißt, wenn mit falschen Grundkonzepten gestartet wurde, bleiben diese nun erhalten, weil man sie nicht mehr überarbeiten kann, da der Aufwand dafür zu hoch wäre. So entsteht Software, die von vornherein nicht passend ist, und man startet von Anfang an mit einer Lösung, bei der alle insgeheim wissen, dass man es eigentlich viel besser hätte machen können. Nur spricht das niemand laut aus. Stattdessen kommt dann irgendjemand daher und sagt:
"Ich hab's Euch ja prophezeit: Wir hätten damals doch auf Go statt .NET setzen sollen, aber das wollte ja keiner hören!"
Und alle stehen da, nicken betroffen und denken:
"Ja, stimmt, wenn wir heute noch mal neu anfangen könnten, dann wäre alles besser!"
Aber der Punkt ist: Es wäre nur kurzfristig besser, weil man wieder ohne Altlasten auf der "grünen Wiese" starten würde, aber langfristig würde man wieder dieselbe, nicht passende Software entwickeln, weil man erneut nicht verstanden hat, was das zugrunde liegende fachliche Problem ist. Man tauscht quasi die Technologie, aber die Technologie war nie das Problem. Ich glaube, es war Albert Einstein, der (sinngemäß) einmal gesagt hat:
"Immer wieder dasselbe zu tun und ein anderes Ergebnis zu erwarten, ist die Definition von Dummheit."
Wenn wir das doch aber wissen – warum versuchen wir als Branche dann immer und immer wieder, Software ohne fachliches Verständnis zu entwickeln?
Wenn wir also bessere Software entwickeln wollen, wenn wir Software in kürzerer Zeit fertigstellen wollen, dann müssen wir weniger über Technologie und viel mehr über Fachlichkeit sprechen. Wir müssen sicherstellen, dass alle am Projekt Beteiligten von Anfang an ein gemeinsames Verständnis der Thematik haben. Damit sage ich nicht, dass wir nicht mehr über Technologien sprechen sollten. Damit sage ich auch nicht, dass jede Entwicklerin und jeder Entwickler zum absoluten Fachexperten werden muss. Aber es hilft, wenn zumindest ein solides Grundwissen vorhanden ist, weil man ein Feature viel passgenauer umsetzen kann, wenn man versteht, was es macht, wer es verwendet, welchem Zweck es dient und so weiter. Die Frage ist also: Wie schafft man es, eine solche gemeinsame fachliche Sprache und ein gemeinsames Verständnis im Team zu etablieren?
Tatsächlich ist das gar nicht so schwierig, wie man vielleicht glaubt, es ist eher nur zeitaufwendig. Das Fundament von allem ist eine gute Kommunikation, in der man sich über die Fachlichkeit austauscht: Es wird erklärt, es werden Verständnisfragen gestellt, Dinge werden hinterfragt. Und zwar übergreifend über alle im Team beteiligten Disziplinen hinweg. Also echte interdisziplinäre Zusammenarbeit und kein disziplinäres Schubladendenken.
Und es gibt so viele Hilfsmittel dafür: Das fängt beim aktiven und aufmerksamen Zuhören an, geht über kritisches Mitdenken und Nachfragen, dazu gehören Empathie, echte Neugier und ehrliches Interesse. Es gibt Werkzeuge wie Domain-driven Design, Design Thinking, das Arbeiten mit Events, das Beschäftigen mit Semantik, mit natürlicher Sprache und vieles mehr. Was all diese Punkte jedoch gemeinsam haben, ist, dass sie keine technischen Hilfsmittel sind.
Das heißt, die eine essenzielle Voraussetzung ist, dass man aus der bequemen technologischen Komfortzone herauskommt, in der man es sich seit Jahren gemütlich gemacht hat, und dass man den Sprung ins kalte Wasser wagt, sich die Blöße gibt, einzugestehen, dass man von der Fachlichkeit keine Ahnung hat – aber ehrlich interessiert ist und neugierig auf das, was da in einer neuen Welt vor einem liegt. Diesen Schritt zu machen, ist ungemein wichtig, aber er fällt vielen unglaublich schwer.
Und das liegt nicht daran, dass Entwicklerinnen und Entwickler nicht wollen würden. Sondern es liegt daran, dass das in vielen Aspekten mit dem bricht, was man in der Ausbildung gelernt hat. Plötzlich sind nicht mehr Daten und Objekte die wesentlichen Konstrukte, um einen Sachverhalt zu strukturieren. Plötzlich sind es Geschäftsprozesse und Abläufe. Es ist der Wandel von einer rein statischen, datengetriebenen Welt hin zu einer dynamischen, prozessgetriebenen Welt. Denn wir schreiben Software nicht, um Daten zu verwalten. Wir schreiben Software, um Prozesse abzubilden. Dass dafür Daten benötigt werden, versteht sich von selbst. Aber Daten spielen in dieser Welt nicht die erste Geige, genauso wenig wie die Technologie die erste Geige spielen sollte, sondern eben die Fachlichkeit. Es geht nicht um Daten, sondern um Prozesse. Das, was Software lebendig macht, sind nicht die Daten, sondern die Funktionen. Und das ist die entscheidende Änderung in der Perspektive.
Betrachten Sie die Welt als eine Ansammlung von Daten, die verwaltet werden müssen, dann wird Ihre Software letztlich immer nur Excel mit einer mehr oder weniger anderen Bedienoberfläche sein, die die Anwenderinnen und Anwender nicht wirklich in ihren Aufgaben und Intentionen unterstützt. Um das nämlich zu erreichen, müssen Sie die Intentionen verstehen, Sie müssen die Abläufe und die Prozesse verstehen. Denn nur dann können Sie die Prozesse adäquat in Ihrer Software abbilden und Menschen das Leben vereinfachen. Und darum geht es letztlich bei der Softwareentwicklung: Das Leben von Menschen in irgendeiner Form angenehmer, sicherer, komfortabler – im weitesten Sinne irgendwie "besser" zu machen. Und Technologie ist dafür ein notwendiges Werkzeug, ein Mittel zum Zweck. Aber Technologie ist kein Selbstzweck.
Wenn Sie mehr über diese Sichtweise auf die Welt der Softwareentwicklung erfahren möchten, habe ich abschließend noch zwei Tipps für Sie: Erstens, schauen Sie sich das Video "CRUD? Bloß nicht! [3]" an. Und zweitens: Raffen Sie sich auf, die rein technologische Komfortzone zu verlassen und stürzen Sie sich in die zuvor genannten Themen, um der Fachlichkeit einen höheren Stellenwert zu geben. Holen Sie sich im Zweifelsfall Unterstützung von außen, um das Vorgehen zu beschleunigen, aber egal ob mit oder ohne: Das Wichtigste ist, dass Sie den ersten Schritt in dieser Richtung machen. Viel Erfolg!
URL dieses Artikels:
https://www.heise.de/-9979648
Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] https://www.youtube.com/watch?v=iQK620MY_48
[3] https://www.youtube.com/watch?v=MoWynuslbBY
[4] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: erstellt mit KI (Dall-E) von iX-Redaktion)
Die umfangreiche Serie mit Blogbeiträgen zu .NET 8.0 und den Neuerungen in C# 12 geht zwei Monate vor dem Release von .NET 9.0 zu Ende.
In den letzten 40 Wochen habe ich Ihnen jede Woche ein neues Feature aus .NET 8.0 vorgestellt. Es gab kleinere und größere Neuigkeiten in der Programmiersprache C#, der .NET-Basisklassenbibliothek und dem .NET Software Development Kit (SDK).
Auch wenn ich nicht alle neuen Features vorgestellt habe, möchte ich diese Serie nun enden lassen und mich in den kommenden Wochen darauf konzentrieren, meine Fachbücher zu C# [1], Blazor [2] und Entity Framework Core [3] auf den Stand von .NET 9.0 zu bringen.
.NET 9.0 ist seit dieser Woche im Stadium "Release Candidate 2" [4] und mit einer "Go-Live"-Lizenz ausgestattet. Die fertige Version soll am 12. November 2024 erscheinen. Die oben genannten Bücher will ich bis dahin auf dem aktuellen Stand haben, sodass diese wie in den Vorjahren pünktlich zum Erscheinungstermin verfügbar sind.
Aktuell gibt es von mir das Buch .NET 9.0 Update [8], das auf dem Stand des Release Candidate 2 ist und auf 170 Seiten die Neuerungen gegenüber .NET 8.0 beschreibt.
.NET 8.0 hat noch Long-Term Support bis zum November 2026. Es besteht also kein Zwang, auf .NET 9.0 zu wechseln. Das kommende .NET-Release wird mit Standard-Term Support von Microsoft von November 2024 bis Mai 2026 mit Updates versorgt werden. Zwischenzeitlich ist für November 2025 dann .NET 10.0 geplant.
Ab Dezember plane ich eine neue Blogserie mit den Neuerungen aus .NET 9.0.
URL dieses Artikels:
https://www.heise.de/-9977510
Links in diesem Artikel:
[1] https://it-visions.de/Csharpbuch
[2] https://it-visions.de/Blazorbuch
[3] https://it-visions.de/EFCorebuch
[4] https://www.heise.de/news/Jetzt-schon-einsetzen-NET-9-0-Release-Candidate-2-mit-Go-Live-Lizenz-9974342.html
[5] https://net.bettercode.eu/?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link
[6] https://net.bettercode.eu/index.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link#programm
[7] https://net.bettercode.eu/tickets.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link
[8] https://www.it-visions.de/buch/n9U
[9] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: erstellt mit KI (Dall-E) von iX)
Das WebAssembly System Interface (WASI) wird durch Microsoft nun mit einem eigenen SDK unterstützt – aber weiterhin im Status "experimentell".
Das WebAssembly System Interface (WASI) ist ein Standard, um WebAssembly-Bytecode-basierte Anwendungen plattformneutral außerhalb des Webbrowsers zu betreiben. WASI wurde am 27. März 2019 erstmals öffentlich bekanntgegeben [1] und wird in einer Untergruppe der WebAssembly-Gruppe beim W3C [2] (World Wide Web Consortium) standardisiert.
Schon seit dem 25. März 2022 bot Microsoft eine experimentelle Implementierung für WASI-basierte Anwendungen mit .NET 7.0 – zunächst aber nur in einem GitHub-Repository eines Microsoft-Mitarbeiters [3].
Seit .NET 8.0 ist das Projekt als experimenteller Workload für das .NET SDK verfügbar.
Den Workload installiert man folgendermaßen:
FreshRSS dotnet workload install wasi-experimentalEine neue WASI-basierte Konsolenanwendung legt man danach an mit
dotnet net wasiconsoleoder in Visual Studio:
(Bild: Screenshot (Holger Schwichtenberg))
Folgender Code zeigt eine Konsolenanwendung, die einige Systeminformationen ausgibt:
// WASI-Demo (C) Dr. Holger Schwichtenberg, 2022
Console.WriteLine(System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription + "' sagt 'Hallo' via WebAssembly/WASI!");
Console.WriteLine("OS Description: " + System.Runtime.InteropServices.RuntimeInformation.OSDescription);
Console.WriteLine("OS Architecture: " + System.Runtime.InteropServices.RuntimeInformation.OSArchitecture);
Console.WriteLine("OS Version: " + System.Environment.OSVersion);
Console.WriteLine("Machine Name: " + System.Environment.MachineName);
Console.WriteLine("Current User: " + System.Environment.UserDomainName + "\\" + System.Environment.UserName);
Console.WriteLine("Process Path: " + System.Environment.ProcessPath);
Console.WriteLine("Current Directory: " + System.Environment.CurrentDirectory);
Console.WriteLine("Process ID: " + System.Environment.ProcessId);
Console.WriteLine("64 Bit: " + System.Environment.Is64BitProcess);
Console.WriteLine("Working Set: " + System.Environment.WorkingSet);
foreach (var d in System.Environment.GetLogicalDrives())
{
Console.WriteLine("Drive: " + d);
}
Das WASI-Projekt im folgenden Code basiert auf einer normalen .NET-8.0-Konsolenanwendung mit dem RuntimeIdentifier wasi-wasm:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<RuntimeIdentifier>wasi-wasm</RuntimeIdentifier>
<OutputType>Exe</OutputType>
<PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>
</Project>
Beim Übersetzen (siehe nächste Abbildung) entsteht nicht nur eine DLL, sondern auch eine WebAssembly-Bytecode-Datei (.wasm), die ca. 11 MB groß ist.
Diese .wasm-Datei enthält die komplette WASI-Anwendung inklusive .NET-Laufzeitumgebung; die DLL ist zur Laufzeit ebenso wenig wie die Installation der .NET Runtime zur Ausführung notwendig. Allerdings kann man eine .wasm-Datei bisher in keinem der üblichen Betriebssysteme direkt starten; man benötigt eine WASI-Laufzeitumgebung wie Wasmtime von der Bytecode Alliance [4] oder Wasmer [5].
Die nächsten Abbildungen zeigen die Ausführung mit Wasmtime, das für Windows in einer rund 10 MB großen .exe-Datei geliefert wird. Man sieht, dass die Anwendung in einer Sandbox läuft und derzeit auch noch vom Betriebssystem und Benutzer "Browser" spricht, auch wenn gar kein Browser im Spiel ist. Die Prozess-ID ist immer 42. Das WASI SDK von Microsoft erlaubt auch die Verwendung von ASP.NET Core, das heißt, man kann eine Webserver-Anwendung auf Basis von WebAssembly-Bytecode schreiben.
(Bild: Screenshot (Holger Schwichtenberg))
(Bild: Screenshot (Holger Schwichtenberg))
URL dieses Artikels:
https://www.heise.de/-9962217
Links in diesem Artikel:
[1] https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/
[2] https://github.com/WebAssembly/WASI/blob/main/Charter.md
[3] https://github.com/SteveSandersonMS/dotnet-wasi-sdk
[4] https://github.com/bytecodealliance/wasmtime
[5] https://wasmer.io
[6] https://net.bettercode.eu/?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link
[7] https://net.bettercode.eu/index.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link#programm
[8] https://net.bettercode.eu/tickets.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link
[9] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: Generated by OpenAI DALL E)
Um technische Schulden systematisch zu dokumentieren und zu verwalten, eignen sich Technical Debt Records (TDRs).
Zur Abwechslung geht es diesmal weder um Microcontroller noch um KI, sondern um Softwarearchitektur, genauer gesagt um technische Schulden und ihre Dokumentation. In der heutigen schnelllebigen Softwareentwicklung stehen Teams vor der Herausforderung, kontinuierlich neue Funktionen bereitzustellen und gleichzeitig die Codequalität zu erhalten. Dabei entstehen oft Kompromisse, die wir als Technical Debt (Technische Schulden) bezeichnen. Um diese systematisch zu dokumentieren und zu verwalten, lassen sich Technical Debt Records (TDRs) nutzen. Dieser Artikel erläutert die Bedeutung von TDRs und stellt ein Werkzeug vor, das die Erstellung von TDRs vereinfacht.
Softwarearchitektinnen und -architekten nutzen heutzutage ADRs (Architecture Design Records), wenn sie Architekturentscheidungen festhalten wollen. ADRs haben sich in einer Vielzahl von Projekten als Micro-Architekturdokumente etabliert. Sie unterliegen der Versionskontrolle und liegen damit in der Codebasis. Was für Architekturentscheidungen gilt, lässt sich auch für technische Schulden nutzen.
Ein Technical Debt Record (TDR) ist ein strukturiertes Dokument, das Details über technische Schulden in einem Softwareprojekt festhält. Technische Schulden entstehen, wenn Entwicklerinnen und Entwickler kurzfristige Lösungen wählen, die sich zwar schnell implementieren lassen, aber langfristig zu erhöhtem Wartungsaufwand, schlechterer Performance oder anderen Nachteilen führen. TDRs bieten eine klare Übersicht über bestehende technische Schulden, deren Auswirkungen und die Maßnahmen zu ihrer Behebung.
Technische Schulden können, wenn sie unkontrolliert bleiben, erhebliche negative Auswirkungen auf ein Projekt haben:
Durch die systematische Dokumentation mittels TDRs können Teams diese Schulden frühzeitig erkennen, priorisieren und gezielt angehen, bevor sie unkontrollierbar werden.
Es ist somit essenziell, technische Schulden zu dokumentieren. Technical Debt Records bieten hierbei verschiedene Vorteile für die Projektbeteiligten.
Für Entwickler:
Für Architekten:
Für Tester:
Damit die Beschreibung von Technical Debt Records nicht nur theoretisch bleibt, soll das konkrete Beispiel im folgenden Kasten zur Veranschaulichung dienen. Es geht um eine veraltete Authentifizierungsbibliothek. Hat das zugehörige TDR schon ein paar Stufen des Workflows durchlaufen, könnte es sich so präsentieren.
Ein gut strukturiertes TDR-Template ist entscheidend für die effektive Dokumentation technischer Schulden. Ein Werkzeug (siehe weiter unten) generiert TDRs mit folgenden Feldern:
Das sind auf den ersten Blick sehr viele Aspekte. Doch keine Sorge, die Dokumentation dieser Felder erfolgt inkrementell im Lebenszyklus der dokumentierten technischen Schuld. Den augenblicklichen Zustand und damit den Workflow eines TDR beschreibt das Feld state.
Das State-Feld spiegelt den Workflow wider, also wie Entwickler technische Schulden handhaben sollten. Es hilft dabei, den Fortschritt bei der Bearbeitung der Schuld zu verfolgen und sicherzustellen, dass keine Schulden unbeachtet bleiben. Die definierten Zustände sind:
Diese Zustände ermöglichen es Teams, den Status jeder technischen Schuld klar zu definieren und entsprechende Maßnahmen zu ergreifen.
Beim ersten Identifizieren einer technischen Schuld können einige Felder noch leer bleiben:
Durch diese schrittweise Ergänzung bleibt die Dokumentation stets aktuell und reflektiert den Fortschritt bei der Behebung der technischen Schulden.
Die Dokumentation technischer Schulden würde dann an Akzeptanz verlieren, wenn die Dokumentation technischer Schulden sich als manuell und aufwendig erweist. In diesem Fall könnte es auch passieren, dass Entwickler Felder vergessen, umbenennen oder wichtige Felder ignorieren.
Der TDR-Generator ist ein Go-basiertes Werkzeug, das die Erstellung von Technical Debt Records in verschiedenen Formaten automatisiert. Es unterstützt Markdown, Plain ASCII, PDF und Excel und erleichtert somit die Integration in unterschiedliche Entwicklungs- und Dokumentationsprozesse.
Werkzeugunterstützung für TDRs hat sich auch schon bei ADRs bewährt. So lassen sich Schablonen generieren, mit deren Hilfe Architektinnen und Architekten die technischen Schulden beschreiben. Dementsprechend weist der TDR-Generator folgende Vorteile auf:
Der TDR-Generator ist auf GitHub verfügbar. Sie können das Repository hier [1] finden.
Zur Installation bedarf es folgender Schritte:
git clone git@github.com/ms1963/TechnicalDebtRecords.gitgo mod init technical_debt_generatorgo get github.com/phpdave11/gofpdf && go get github.com/xuri/excelize/v2go build generate-td.goWer möchte, kann aber auch einfach make im Quellcodeverzeichnis aufrufen. Dadurch erfolgt die Kompilation automatisch über das mitgelieferte Makefile. Voraussetzung ist allerdings in jedem Fall die vorhergehende Installation des go-Compilers [2].
Das Programm lässt sich über die Kommandozeile mit verschiedenen Optionen ausführen.
Verfügbare Optionen:
-format: Gibt das Ausgabeformat an. Mögliche Werte sind markdown, ascii, pdf, excel. Standard ist markdown.-output: (Optional) Gibt den Dateinamen für die Ausgabe an. Wenn nicht angegeben, wird ein Standardname verwendet.-empty: (Optional) Erstellt ein leeres TDR mit Platzhaltern, ohne nach Eingaben zu fragen.--help oder -h: Zeigt die Hilfsnachricht mit Nutzungshinweisen an.Beispiele:
./generate-td -format markdown./generate-td -format pdf -output mein_td_record.pdf./generate-td -format excel -empty./generate-td --helpUm die Nachverfolgung und Zusammenarbeit zu erleichtern, sollten TDRs in ein Versionskontrollsystem wie Git oder SVN eingecheckt werden. Dies ermöglicht:
Beispiel für Git:
git add technical_debt_record.mdgit commit -m "Add TDR für veraltete Authentifizierungsbibliothek"git push origin mainDurch die Einbindung von TDRs in das Versionskontrollsystem bleibt die Dokumentation stets aktuell und für alle Teammitglieder zugänglich.
Technical Debt Records (TDRs) sind ein effektives Instrument zur Verwaltung technischer Schulden in Softwareprojekten. Sie bieten Transparenz, erleichtern die Priorisierung und unterstützen strategische Entscheidungen zur Verbesserung der Codequalität und Systemarchitektur. Der vorgestellte TDR-Generator vereinfacht die Erstellung dieser wichtigen Dokumente und integriert sich nahtlos in bestehende Entwicklungs- und Versionskontrollprozesse.
Indem Teams TDRs konsequent verwenden und in ihre Workflows integrieren, können sie die negativen Auswirkungen technischer Schulden minimieren und die langfristige Gesundheit und Wartbarkeit ihrer Softwareprojekte sicherstellen.
Wie erwähnt, finden Sie das beschriebene Werkzeug in einem GitHub-Repository [3].
URL dieses Artikels:
https://www.heise.de/-9876115
Links in diesem Artikel:
[1] https://github.com/ms1963/TechnicalDebtRecords/
[2] https://go.dev/doc/install
[3] https://github.com/ms1963/TechnicalDebtRecords/
[4] mailto:who@heise.de
Copyright © 2024 Heise Medien
(Bild: Marian Weyo/Shutterstock.com)
Es sollte selbstverständlich sein, Menschen nicht auszuschließen – doch in der IT wird genau das ständig gemacht. Ab 2025 gelten in der EU andere Regeln.
Ich bin mir ziemlich sicher, dass Sie diesen Artikel aus einem von zwei Gründen angeklickt haben. Entweder, weil Sie dachten:
"Ja, Accessibility ist wirklich ein leidiges Thema, und es kostet tatsächlich furchtbar viel, sich damit auseinanderzusetzen. Endlich spricht das mal jemand aus!"
Oder weil Sie dachten:
"Was ist das denn für eine Aussage? Natürlich kostet Accessibility Geld, aber das darf doch nicht der Maßstab sein, sich nicht mit dem Thema zu beschäftigen."
Nun, soll ich Ihnen etwas verraten? Wenn einer dieser beiden Gedanken Ihnen tatsächlich durch den Kopf gegangen ist, habe ich Sie erfolgreich auf eine falsche Fährte geführt, denn beide Interpretationen des Titels treffen nicht zu. Doch wie ist der Titel dann tatsächlich gemeint?
Vorweg möchte ich klarstellen: Natürlich kostet Accessibility Geld. Es ist definitiv aufwendiger, sich Gedanken um Barrierefreiheit zu machen, die entsprechenden Konzepte zu erlernen und diese letztlich angemessen zu implementieren und zu testen, als dies einfach zu ignorieren. Dieses Argument ist zunächst einmal legitim. Die entscheidende Frage aber ist, und das ist der zweite Punkt, den ich bereits angedeutet habe: Darf man die Entscheidung, ob man beispielsweise eine Webseite für Menschen mit Behinderungen zugänglich macht, allein auf Basis von wirtschaftlichen Überlegungen treffen? Oder ist das nicht vielmehr ethisch fragwürdig?
Letztlich handelt es sich dabei um keine technische, sondern eine philosophische Frage. Es geht um Ethik und Moral, um persönliche Überzeugungen, vielleicht sogar um die eigene Betroffenheit. Wer selbst eine Behinderung hat oder Menschen im nahen Umfeld kennt, die betroffen sind, wird vermutlich anders über dieses Thema denken als jemand, der meint, Menschen mit Behinderungen seien eine marginale Gruppe, die keine Rolle spielt.
Der entscheidende Punkt ist: Ganz gleich, welche Meinung Sie zu der Frage haben, wie viel man in Accessibility investieren sollte – ab dem kommenden Jahr stellt sich diese Frage schlichtweg nicht mehr. Ab dem 28. Juni 2025 haben Sie in vielen Fällen nämlich keine Wahl mehr. Denn ab diesem Datum tritt die neue EU-Richtlinie European Accessibility Act (EAA) in Kraft. Der EAA verpflichtet Sie, für bestimmte Produkte und Dienstleistungen Barrierefreiheit umzusetzen – unabhängig davon, ob Sie das wollen oder nicht.
Zu diesen Produkten und Dienstleistungen zählen unter anderem Webseiten. Die Liste ist jedoch viel länger und enthält viele allgemeine Kategorien, was bedeutet, dass sie vielseitig interpretierbar ist. Wenn man das ernst nimmt, betrifft der EAA am Ende viele Bereiche, in denen sich plötzlich jemand mit Accessibility beschäftigen muss. Dazu gehören neben Webseiten auch mobile Apps, E-Books, Self-Service-Terminals wie Geldautomaten oder Fahrkartenautomaten, Getränkeautomaten und vieles mehr. Auch "digitale Dienstleistungen" wie E-Commerce-Websites, Online-Shops, Online-Zahlungen und der Transportsektor, beispielsweise Buchungssysteme, sind betroffen. Die Anforderungen an all diese Systeme? Der EAA fordert eine einfache und effiziente Gestaltung, insbesondere in Bezug auf die Bedienbarkeit und den Zugang zu Informationen.
Warum sollten Sie sich für den EAA interessieren? Ganz einfach: Weil er ab dem 28. Juni 2025 als einheitlicher Standard in der gesamten Europäischen Union gilt. Wenn Sie also Software oder Hardware auf den Markt bringen, die zu den genannten Kategorien gehört und den Anforderungen des EAA nicht entspricht, drohen empfindliche Geldstrafen – und dann wird fehlende Accessibility richtig teuer. Die Geldstrafen fallen nämlich nicht gerade gering aus. Wer bereits dachte, die DSGVO sei teuer, wird vom EAA noch einmal überrascht werden.
Es wird deutlich, dass es der EU ernst damit ist, das Thema Accessibility zu fördern. Ich sehe bereits, wie sich viele darüber ärgern und sagen werden:
"Warum wird das jetzt gesetzlich vorgeschrieben?"
Doch darauf gibt es eine einfache Antwort. Zum einen ist das Ganze gar nicht so neu, wie Sie vielleicht gerade denken. Es gab auch bisher schon gewisse Verpflichtungen zur Barrierefreiheit, allerdings betraf das hauptsächlich den öffentlichen Sektor, insbesondere Behörden. Dennoch gab es bereits entsprechende Regelungen, die nun erweitert werden: In Deutschland beispielsweise das Behindertengleichstellungsgesetz (BGG) und die Barrierefreie Informationstechnik-Verordnung (BITV 2). In der EU stellt seit 2018 die Web Accessibility Directive konkrete Anforderungen an Webseiten und Apps öffentlicher Stellen.
Zudem gibt es die Behindertenrechtskonvention der Vereinten Nationen, die zwar keine technischen Maßnahmen fordert, aber doch eine allgemeine Zielsetzung vorgibt. Die EU hält sich unter anderem an diese Vorgaben, und die Mitgliedsstaaten waren und sind verpflichtet, Barrierefreiheit zu fördern. Das Einzige, was sich nun ändert, ist, dass sich diese Regelungen nicht mehr nur auf den öffentlichen Sektor beziehen, sondern auch auf die Privatwirtschaft und eine breitere Palette von Produkten. Die EU verfolgt damit das Ziel, die technischen Maßnahmen innerhalb der Mitgliedsstaaten zu harmonisieren, um unterschiedliche nationale Regelungen zu vermeiden.
Persönlich finde ich es traurig, dass es solche Gesetze und die Androhung von hohen Strafen braucht, um Veränderungen anzustoßen. Sollte das nicht von selbst passieren, weil es das Richtige ist? In welcher Welt ist es in Ordnung zu sagen:
"Wir ignorieren die Bedürfnisse und Anforderungen einer ganzen Gruppe von Menschen, nur weil es Geld kostet?"
Natürlich verstehe ich, dass das täglich so abläuft, aber das macht es nicht weniger falsch. Und natürlich weiß ich auch, dass meine rhetorische Frage überflüssig ist, denn offensichtlich passiert der Wandel nicht von selbst, sonst wäre der EAA nicht notwendig. Dennoch finde ich es bedauerlich.
Was mich daran besonders ärgert, ist, dass Accessibility oft als Thema betrachtet wird, das nur wenige Menschen betrifft und keine Rolle im Alltag der meisten spielt. Beides ist falsch. Es betrifft nicht nur wenige Menschen. Vielleicht denken Sie bei "Menschen mit Behinderung" an jemanden, der sehbehindert oder blind ist. Doch es gibt viele Abstufungen dazwischen. Ich zum Beispiel bin zwar nicht blind, aber ich habe sehr schlechte Augen. Ohne Kontaktlinsen oder Brille bin ich im Alltag stark eingeschränkt, und ich kann außerdem auch nicht dreidimensional sehen. Mein Gehirn hat es nie gelernt, aus den Bildern beider Augen ein räumliches Bild zu konstruieren. Alles, was ich sehe, ist flach wie ein Foto, weshalb ich Entfernungen nicht einschätzen kann. Hinzu kommt, dass es mir mit zunehmendem Alter schwerer fällt, kleine oder kontrastarme Schriften zu lesen. Früher war das einfacher.
Und so gibt es viele Menschen, die nicht perfekt sehen können: Sei es wegen einer hohen Dioptrien-Zahl, einer Rot-Grün-Sehschwäche, Farbenblindheit oder anderen Einschränkungen. Und das betrifft nicht nur das Sehen. Auch der Hörsinn lässt mit dem Alter nach. Wir können im jungen Alter sehr hohe Frequenzen hören, die später nicht mehr wahrgenommen werden. Das bedeutet nicht, dass jemand vollständig gehörlos sein muss, um eine Einschränkung zu erleben. Schon eine leichte Verschlechterung des Gehörs kann problematisch sein, wenn man auf sprachbasierte Systeme angewiesen ist. Und auch diesen Menschen würde eine bessere Accessibility helfen.
Gleiches gilt für einfache Sprache oder Menschen, die aufgrund einer Verletzung, beispielsweise eines gebrochenen Arms, nicht gut mit einer Maus umgehen können. Daher ist es nicht stichhaltig zu sagen, Accessibility betreffe nur wenige Menschen. Stattdessen sollten wir uns eher fragen: Wie wenige Menschen haben keinerlei Einschränkungen in ihren Sinneswahrnehmungen? Sollten wir Webseiten tatsächlich immer so gestalten, als ob alle Nutzer perfekt sehen und hören können? Oder wäre es nicht besser, wenn wir es ermöglichen, zum Beispiel ein anderes Design mit höherem Kontrast zu wählen? Oder wenn wir Audio und Video standardmäßig mit Untertiteln oder Transkriptionen anbieten würden?
Bevor Sie nun sagen, "das braucht doch niemand", denken Sie einmal kurz nach: Warum sind eigentlich fast alle Kurzvideos untertitelt? Ganz einfach: Viele Menschen schauen sich diese Videos unterwegs an, zum Beispiel im Bus oder in der Bahn, oft ohne Kopfhörer. Das zeigt, dass es oft auch einfach Situationen gibt, in denen man dankbar für visuelle Unterstützung ist, weil man den auditiven Kanal nicht nutzen kann. Mit anderen Worten: Sollte es nicht unsere moralische Verpflichtung sein, dafür zu sorgen, dass Inklusion stattfindet und wir niemanden ausschließen? Ich finde: Ja.
Tatsächlich ist es auch gar nicht so schwierig, dabei den ersten Schritt zu machen. Gerade bei Webseiten bietet es sich an, sich mit semantischem HTML zu beschäftigen, was keine willkürliche <div>-Suppe ist, sondern dazu beiträgt, die Seite strukturell zu gliedern. Das erleichtert Screenreadern die Arbeit und ist daher eine Verbesserung. Dasselbe gilt für ARIA-Attribute, die es seit Jahren in HTML gibt, die aber kaum jemand kennt, geschweige denn einsetzt. Und natürlich wird es auch immer Situationen geben, in denen man an Grenzen stößt. Das sollte aber kein Grund sein, es nicht zumindest zu versuchen und so gut wie möglich umzusetzen. Eine bessere Nutzung von semantischem HTML führt übrigens nicht nur zu einer Verbesserung für Screenreader, sondern auch zu einer besseren Verständlichkeit der Seite für Suchmaschinen.
Um einmal ein Gefühl dafür zu bekommen, wie schwierig es ist, sich in der digitalen Welt zurechtzufinden, wenn man nicht sehen kann, aktivieren Sie doch einfach einmal die Bedienungshilfen auf Ihrem Smartphone, zum Beispiel die VoiceOver-Funktion bei iOS. Ich meine, wie schwer kann es schon sein, ein Gerät, das Sie jeden Tag unzählige Male nutzen, quasi "blind" zu bedienen? Ohne das "Erlebnis" vorwegnehmen zu wollen: Ich persönlich fand es erschreckend, wie schlecht das insgesamt funktioniert. Und dabei ist das System von Apple noch eines der besten auf dem Markt.
Dennoch habe ich nicht lange durchgehalten, bevor ich das Gefühl hatte, mein Telefon aus dem Fenster werfen zu wollen. Es ist erstaunlich, wie groß die Einschränkung tatsächlich sein kann. Dass ein Unternehmen mit einem Marktwert von über drei Billionen US-Dollar keine bessere Lösung bietet, finde ich enttäuschend. Genau deshalb brauchen wir leider doch Gesetze wie den EAA, damit sich etwas bewegt.
Für mich ist die wichtigste Erkenntnis dieses Themas: Wir alle müssen uns viel mehr mit Barrierefreiheit und Inklusion beschäftigen. Denn aktuell haben es Menschen, die nicht perfekt sehen oder hören können, in der digitalen Welt sehr viel schwerer, als man gemeinhin glaubt. Und je mehr das Digitale in unseren Alltag eindringt, desto wichtiger wird es, niemanden zurückzulassen. Accessibility ist so gesehen also weit mehr als nur ein technisches Thema – es ist eine gesamtgesellschaftliche Aufgabe. Und wir als Entwicklerinnen und Entwickler haben die Chance, mit relativ wenig Aufwand einen signifikanten positiven Unterschied zu machen. Und den sollten wir nutzen.
Wenn Sie von all dem nicht überzeugt sind, dann gilt ab dem kommenden Jahr der European Accessibility Act – und spätestens dann wird niemand mehr fragen, ob Sie Accessibility für sinnvoll erachten oder nicht. Dann sind Sie dazu verpflichtet. Aber wie schön wäre es, wenn möglichst viele Menschen von sich aus erkennen, dass es eigentlich freiwillig geschehen sollte – weil es das Richtige ist. In diesem Sinne möchte ich diesen Beitrag mit dem kleinen Appell beenden: Lassen Sie uns alle dazu beitragen, die Welt zu einem etwas besseren Ort zu machen für all jene, die es im Alltag ohnehin schon unnötig schwer haben.
PS: Übrigens, auch wir bei the native web [4] machen dabei definitiv nicht alles richtig, ich möchte uns nicht auf ein Podest stellen. Unsere aktuelle Website ist sicherlich kein Vorzeigeprojekt, aber das wird sich in der nächsten Version ändern.
URL dieses Artikels:
https://www.heise.de/-9939623
Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] https://enterjs.de/accessibility.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_ejs_access.empfehlung-ho.link.link
[3] https://enterjs.de/accessibility.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_ejs_access.empfehlung-ho.link.link
[4] https://www.thenativeweb.io/
[5] mailto:mai@heise.de
Copyright © 2024 Heise Medien
(Bild: fizkes/Shutterstock.com)
Die the native web GmbH veranstaltet ab dem 11. November 2024 insgesamt zwölf Webinare zu den Themen Performance, Clean Code, Security und Architektur.
Im Herbst richtet die the native web GmbH [1] insgesamt zwölf Webinare aus den Themenbereichen Performance, Clean Code, Security und hexagonale Architektur aus.
Die Webinare finden ab dem 11. November jeweils montags, mittwochs und freitags von 9.00 Uhr bis 12.30 Uhr statt und vermitteln die aktuellen Themen der zeitgemäßen Softwareentwicklung auf anschauliche und verständliche Art in Theorie und Praxis. Die Themenauswahl umfasst sowohl grundlegende als auch fortgeschrittene Themen.
Performante Anwendungen entwickeln (Details anzeigen [2])
Cleaner Code, hohe Qualität (Details anzeigen [3])
Sichere Software entwickeln (Details anzeigen [4])
Hexagonale Architektur (Details anzeigen [5])
Die Webinare werden als Livestream durchgeführt, sodass man einfach und bequem teilnehmen kann – ganz gleich, ob von zu Hause oder aus dem Büro. Für Fragen steht ein Chat zur Verfügung.
Der Preis beträgt 179 Euro pro Webinar. Wer drei Webinare aus einem Themenbereich als Paket bucht, erhält etwa 25 Prozent Rabatt gegenüber der Einzelbuchung, der Preis beträgt dann 399 Euro. Darüber hinaus gelten noch einmal günstigere Konditionen für Teams. Alle Preise verstehen sich jeweils zuzüglich 19 Prozent Umsatzsteuer.
Im Preis enthalten ist neben der Teilnahme am Livestream auch der Zugriff auf die Aufzeichnung des Webinars und die Codebeispiele.
Alle weitergehenden Informationen und eine Buchungsmöglichkeit finden sich auf der Webseite der tech:lounge Masterclass [6].
URL dieses Artikels:
https://www.heise.de/-9870380
Links in diesem Artikel:
[1] https://www.thenativeweb.io/
[2] https://www.thenativeweb.io/techlounge/developing-performant-applications
[3] https://www.thenativeweb.io/techlounge/clean-code-high-quality
[4] https://www.thenativeweb.io/techlounge/developing-secure-software
[5] https://www.thenativeweb.io/techlounge/hexagonal-architecture
[6] https://www.techlounge.io/
[7] mailto:mai@heise.de
Copyright © 2024 Heise Medien
(Bild: Erstellt mit Dall-E von iX-Redaktion)
Viele Konzerne wollen das Homeoffice abschaffen. Die Politik hingegen diskutiert über ein gesetzlich verankertes Recht darauf. Was spricht dafür, was dagegen?
Finger weg vom Homeoffice! Dieser Titel ist so wunderbar zweideutig: Einerseits kann man ihn als Warnung verstehen, bloß nicht erst mit dem Homeoffice anzufangen. Andererseits lässt sich dieser Titel auch als Aufforderung deuten, das inzwischen doch weit verbreitete Homeoffice nicht anzutasten oder es in Frage zu stellen. Im Sinne von:
"Nehmt uns bloß nicht unser lieb gewonnenes Homeoffice weg!"
Und genau dieser Titel spiegelt auch wunderbar die derzeitige gesellschaftliche Lage wider: Auf der einen Seite gibt es zahlreiche Konzerne, die das Homeoffice am liebsten wieder komplett abschaffen würden. Auf der anderen Seite steht die Politik, die derzeit immerhin darüber nachdenkt, ob es nicht ein gesetzliches Recht auf Homeoffice geben sollte. Und bei so viel Hin und Her, so viel Pro und Contra, stellt sich natürlich die Frage: Wer hat denn nun eigentlich recht? Was haben wir wirklich Positives vom Homeoffice? Und welche negativen Aspekte bringt es möglicherweise mit sich? Und genau um diese Fragen geht es im heutigen Blogpost.
Bevor wir richtig loslegen, noch eine kleine Ankündigung in eigener Sache: In den vergangenen beiden Blogposts hatte ich gefragt, ob Interesse besteht, dass ich einmal den von uns bei the native web [1] gelebten Entwicklungsprozess vorstelle. Da das Feedback sehr positiv war, wundern Sie sich jetzt vielleicht, dass es heute nicht um diesen Prozess geht. Der Grund, warum wir heute nicht über unseren Prozess sprechen, ist ganz einfach: Wir glauben, dass eine umfassende Beschreibung den Umfang eines Blogposts deutlich übersteigen würde, zumal es sicherlich zahlreiche Fragen dazu geben wird.
Daher wollen wir uns für dieses Thema mehr Zeit nehmen und veranstalten am kommenden Mittwoch, 25. September, um 18 Uhr einen Livestream, in dem wir uns unserem Prozess ausführlich widmen können. Wenn Sie diesen Livestream nicht verpassen wollen, rufen Sie ihn jetzt schon einmal auf [2] und aktivieren Sie dort die Erinnerung, damit YouTube Sie rechtzeitig daran erinnern kann. Alternativ können Sie den Termin natürlich auch ganz klassisch in Ihren guten, alten Kalender eintragen. Und damit zurück zum eigentlichen Thema.
Homeoffice ist für die meisten Menschen, die in der IT-Branche tätig sind, etwas, das im größeren Stil erst seit der Corona-Pandemie existiert. Klar, auch davor war es je nach Unternehmen möglich, mal den einen oder anderen Tag von zu Hause zu arbeiten, aber die Regel war das sicherlich nicht. Tatsächlich ist das bei uns, also bei the native web, ein wenig anders. Wir arbeiten seit unserer Gründung im Jahr 2012 vollständig remote – zu 100 Prozent. Das heißt, bei uns gab es de facto noch nie etwas anderes als Homeoffice.
Sowohl meine Kolleginnen und Kollegen als auch ich schätzen die Vorteile dieser Arbeitsweise sehr: Homeoffice bietet uns allen eine viel höhere Flexibilität im Alltag. Man kann zwischendurch einkaufen gehen, man kann einen Spaziergang machen oder mit dem Hund rausgehen, man kann bei den Hausaufgaben helfen, als Familie gemeinsam zu Mittag essen, man spart sich die Zeit, die sonst für das Pendeln draufgeht, und vieles mehr. Kurz gesagt: Man hat eine ganz andere Lebensqualität.
Aber das Arbeiten von zu Hause aus hat nicht nur Vorteile. Es kann schnell zur sozialen Isolation führen. Es kann dazu führen, dass man, wenn es an Selbstdisziplin und Eigenverantwortung mangelt, den Job vernachlässigt. Es kann zu Konflikten in der Partnerschaft führen, weil man zwar körperlich, aber nicht gedanklich zu Hause ist. Es kann zu Schwierigkeiten kommen, wenn das Privatleben und die beruflichen Anforderungen miteinander kollidieren. Kurz gesagt: Homeoffice ist nicht zwangsläufig ein Zuckerschlecken, sondern kann auch sehr anstrengend werden.
Hinzu kommt, dass Homeoffice natürlich nicht für jede Branche gleichermaßen geeignet ist: Was in der Softwareentwicklung sehr gut funktionieren kann, wird in IT-Berufen, die auf Spezialhardware wie Roboter oder Ähnliches angewiesen sind, schon schwieriger. Und über Berufe außerhalb der IT müssen wir an dieser Stelle gar nicht erst sprechen: Es ist zum Beispiel völlig illusorisch anzunehmen, dass jemand in der Gastronomie oder in der Pflege von zu Hause arbeiten könnte. Im Gegenteil, dort ist die physische Präsenz oft unerlässlich. Daher beziehe ich mich im Folgenden ausschließlich auf die IT-Branche, und alle Aussagen, die ich treffe, sollten in diesem Kontext verstanden werden.
Und damit kommen wir zu einem Punkt, der seit etwa zwei Jahren immer wieder heiß diskutiert wird: nämlich die Pflicht, ins Büro zurückzukehren. Das ist ja etwas, was vor allem die größeren Tech-Konzerne gerne fordern. Wobei, um fair zu bleiben, nicht nur die Großen betroffen sind: Solche Forderungen gibt es auch im kleineren Rahmen, nur führt das dann eben nicht zu so vielen Schlagzeilen. Ein krasses Negativbeispiel sind Elon Musk und Tesla. Im Sommer 2022 stellte Musk den Tesla-Mitarbeiterinnen und -Mitarbeitern ein Ultimatum [4]: Entweder sie kehren ins Büro zurück oder sie kündigen. Wenn man sich ansieht, wie Musk generell mit seinen Angestellten umgeht, wird schnell klar, dass ihm völlig egal ist, wer jemand ist oder welche Aufgabe jemand im Unternehmen übernimmt: Wer nicht zurückkommt, wird eben entlassen, immerhin hatte man ja die Wahl. Sinngemäß: "Dein Problem, wenn Du Dich (aus seiner Sicht) falsch entschieden hast."
Nun ist es vielleicht nicht so, dass jedes Unternehmen, das die Rückkehr ins Büro fordert, direkt so hart vorgeht. Aber immer wieder hört man von Unternehmen, in denen das Thema "zu Hause arbeiten versus im Büro anwesend sein" für Spannungen sorgt. Für mich stellt sich dabei die Frage: Warum fordern so viele Unternehmen die Rückkehr ins Büro? Ich habe dazu meine eigene Theorie. Natürlich weiß ich nicht, ob sie zutrifft, und ich will auch nicht jedem Unternehmen pauschal unterstellen, dass es so ist. Aber ich kenne genug Firmen, bei denen ich mir gut vorstellen kann, dass meine Theorie ziemlich genau die Gründe trifft, warum die Rückkehr ins Büro gefordert wird.
Meine Theorie lautet: Es geht um fehlende Kontrolle. Viele Führungskräfte, die ich im Laufe der Zeit kennengelernt habe, denken: Wenn jemand nicht vor Ort ist, kann man sie oder ihn auch nicht kontrollieren. Und wenn jemand nicht vor Ort ist, woher soll man dann wissen, ob diese Person auch wirklich arbeitet? Und nur um das klarzustellen: Ich will hier nicht alle Führungskräfte über einen Kamm scheren. Es gibt auch viele fähige und gute Vorgesetzte, aber es gibt eben auch schwarze Schafe.
Persönlich halte ich von dieser Argumentation übrigens überhaupt nichts. Die bloße Tatsache, dass jemand im Büro körperlich anwesend ist, bedeutet noch lange nicht, dass diese Person tatsächlich arbeitet. Man kann, und das sage ich aus eigener Erfahrung, auch sehr intensiv im Internet surfen, an privatem Code arbeiten, Spiele spielen und so weiter, und dabei so tun, als sei man schwer beschäftigt. Wer das Ganze noch auf die Spitze treiben will, kann sich mit zwei oder drei Kolleginnen und Kollegen einen Konferenzraum buchen. Denn wer im Konferenzraum wild diskutiert, muss ja arbeiten, oder? Dass hinter verschlossener Tür vielleicht lediglich die Bundesliga-Ergebnisse vom Wochenende besprochen werden, darauf kommt natürlich niemand.
Der Punkt ist: Körperliche Anwesenheit und tatsächliches Arbeiten sind zwei völlig unterschiedliche Dinge. Und wenn ein Unternehmen Zweifel daran hat, dass jemand arbeitet, nur weil die Person nicht physisch präsent ist, dann ist das aus meiner Sicht kein Problem von "Homeoffice ja oder nein", sondern von fehlendem Vertrauen. Und wenn es eigentlich um fehlendes Vertrauen geht, dann liegt das tatsächliche Problem sehr viel tiefer.
Wenn man den Menschen, mit denen man zusammenarbeitet, nicht vertrauen kann, wird das auch nicht besser, wenn sie vor Ort sind. Dann hat man lediglich die Illusion von Kontrolle. Aber fehlendes Vertrauen ist ein gravierendes, fundamentales Problem für die Zusammenarbeit. Und ich glaube, und das ist meine Theorie, dass die meisten Unternehmen, die so vehement die Rückkehr ins Büro fordern, ein großes Vertrauensproblem in ihrer Unternehmenskultur haben. Es ist aber so viel einfacher, die Symptome zu bekämpfen, indem man fordert, die Leute sollen doch bitte zurück ins Büro kommen, als sich mit den eigentlichen Ursachen auseinanderzusetzen und zu fragen, warum das Vertrauen eigentlich fehlt.
Das Problem dabei ist, dass man Vertrauen nicht anordnen kann. Ich kann nicht befehlen, dass plötzlich Vertrauen herrscht. Es gibt keine Technologie und kein Tool, das mir dabei wirklich helfen kann. Vertrauen muss gegeben werden, es kann nicht eingefordert werden. Und ich weiß, dass es Menschen gibt, die anderen mit einem großen Vertrauensvorschuss begegnen, und andere, die sagen, dass man sich Vertrauen erst verdienen muss. Beide Ansichten sind für mich in Ordnung, aber es müssen eben beide Seiten (das Unternehmen und die Mitarbeiterinnen und Mitarbeiter) ihren Beitrag leisten, damit langfristig eine vertrauensvolle Zusammenarbeit möglich ist.
Was schafft denn Vertrauen? Aus meiner Sicht als einer der Geschäftsführer von the native web gibt es einen zentralen Punkt, den ich immens wichtig finde und der auch essenziell für unsere Unternehmenskultur ist: Vertrauen entsteht vor allem dann, wenn man sich gehört und wertgeschätzt fühlt. Wenn man merkt, dass das Gegenüber die eigenen Anliegen ernst nimmt und sich auch ernsthaft bemüht, Verbesserungen vorzunehmen, zu unterstützen und zu helfen.
Deswegen sage ich jeder neuen Mitarbeiterin und jedem neuen Mitarbeiter am ersten Tag, dass sie oder er alles, was merkwürdig, ineffizient oder unlogisch erscheint, jederzeit offen ansprechen kann. Nur so besteht die Chance, dass Dinge verbessert werden, die bislang vielleicht niemandem aufgefallen sind oder die niemand hinterfragt hat. Natürlich kann es sein, dass einer neuen Mitarbeiterin oder einem neuen Mitarbeiter etwas auffällt, das einen nicht sofort ersichtlichen tieferen Sinn hat. Aber auch das ist nicht schlimm: Wird es angesprochen, gibt es im Zweifelsfall eine gute Erklärung, warum die Dinge so sind, wie sie sind. Es gibt also entweder einen Lerneffekt (was gut ist) oder es führt zu einer Verbesserung (was ebenfalls gut ist).
Und das gilt nicht nur für technische und organisatorische Prozesse, sondern auch für alles andere. Ich möchte, dass meine Kolleginnen und Kollegen jederzeit zu mir kommen und sagen können:
"Hey Golo, mich bedrückt etwas."
oder:
"Mich beschäftigt etwas."
Natürlich mache auch ich Fehler, aber ich bemühe mich zumindest stets, auf solche Anliegen einzugehen, einen Rat zu geben oder etwas zu verändern. Außerdem frage ich oft auch von mir aus nach, wenn ich den Eindruck habe, dass jemand nicht so gut gelaunt ist wie sonst oder ich anderweitig das Gefühl habe, dass etwas nicht stimmt. Ich spreche die Person dann im Einzelgespräch an und frage, ob alles in Ordnung ist. Oft stellt sich heraus, dass alles okay ist, manchmal jedoch entsteht ein wertvolles Gespräch. Für mich ist es wichtig, auf Augenhöhe und mit Respekt miteinander umzugehen, denn das schafft eine vertrauensvolle Atmosphäre. Und das ist etwas, was wir bei the native web meiner Meinung nach ganz gut hinbekommen.
Allerdings reicht Vertrauen allein nicht aus, damit Remote-Arbeit gut funktioniert. Es braucht noch etwas anderes. Und das habe ich vorhin schon kurz erwähnt, als ich über die Vor- und Nachteile des Homeoffice gesprochen habe, nämlich Selbstdisziplin und Eigenverantwortung. Gerade weil die physische Komponente im Homeoffice fehlt, ist es wichtig, dass man sich selbst organisiert und Verantwortung übernimmt.
Wenn ich zum Beispiel an einem Problem festhänge, kann ich nicht einfach zur Kollegin oder zum Kollegen am Nachbartisch gehen und um Hilfe bitten. Ich bin erst einmal auf mich allein gestellt. Natürlich kann ich versuchen, jemanden zu erreichen, aber je nachdem, womit die anderen gerade beschäftigt sind, klappt das nicht immer sofort. Dann darf ich mich jedoch nicht einfach zurücklehnen und stundenlang nichts tun, sondern muss konstruktiv nach einer Lösung suchen. Als Vorgesetzter ist mir persönlich dabei aber gar nicht so wichtig, ob die Lösung am Ende klappt. Mir ist vielmehr die Initiative wichtig. Es ist völlig in Ordnung, wenn mir dann jemand sagt:
"Ich habe dies und das und jenes ausprobiert, aber es hat aus diesen und jenen Gründen nicht funktioniert."
Dann weiß ich nämlich: Die Person hat sich bemüht. Und das zeigt mir, dass mein Gegenüber die Arbeit ernst nimmt, auch wenn es in dieser Situation vielleicht einfacher gewesen wäre, nichts zu tun. Und das wiederum weiß ich zu schätzen.
Insofern ist das mit dem Vertrauen eine gegenseitige Angelegenheit: Meine Kolleginnen und Kollegen müssen mir vertrauen können und ich muss ihnen vertrauen können. Das ist jedoch der Punkt, der in vielen Unternehmen fehlt: gegenseitiges Vertrauen, das auf Respekt, Menschlichkeit und auf einem Umgang auf Augenhöhe basiert. Wenn dieses Vertrauen aber gegeben ist, dann spielt es keine Rolle, ob man remote oder vor Ort arbeitet. Wenn es jedoch fehlt, dann hilft es auch nicht, die Leute zurück ins Büro zu zwingen. Dann liegt das Problem viel tiefer, denn die Teamzusammenstellung oder die Arbeitskultur passt irgendwo nicht.
Dieses Vertrauen und dieser gegenseitige Respekt sind die Basis für so vieles im Unternehmensalltag. Ein Beispiel: Wir bei the native web kommunizieren viel schriftlich über Slack (also asynchron). Und es kommt vor, dass ich am Wochenende oder mitten in der Nacht eine Idee habe und diese in Slack schreibe. Nun gilt aber: Nur weil ich am Wochenende schreibe, erwarte ich von meinen Kolleginnen und Kollegen keine sofortige Antwort. Es ist völlig in Ordnung, wenn ich erst am Montagmorgen eine Antwort bekomme. Nichts ist jemals so dringend, dass ich jemanden am Feierabend, am Wochenende oder gar im Urlaub stören würde. Und das Interessante dabei: Gerade weil wir diese Grenzen respektieren, bekomme ich oft sogar am Wochenende oder abends noch eine Antwort, obwohl ich explizit geschrieben habe, dass es nicht eilig ist. Das Paradoxe ist also: Weil ich nichts fordere, wird viel eher gegeben. Und das schätze ich sehr.
Der Punkt ist aber: Mir ist jedes Mal, wenn ich dann doch schon vor Montagmorgen eine Antwort bekomme, klar, dass das keine Selbstverständlichkeit ist, dass das etwas Besonderes ist, das ich wertzuschätzen weiß und wofür ich dankbar bin. Und das äußere ich dann auch. Denn mir ist wichtig, das zu respektieren. Und eigentlich sollte all das überhaupt nicht erwähnenswert sein, aber leider sieht die Praxis in vielen Unternehmen anders aus.
Meine Rolle als Vorgesetzter sehe ich dabei nicht darin, das Team anzuführen, wie das in vielen Unternehmen der Fall ist. Ich sehe meine Aufgabe eher darin, das Team zu schützen und auf mein Team aufzupassen. Ich bin also weniger der Löwe, der mit Gebrüll vorneweg rennt und einen auf "Big Boss" macht, sondern vielmehr bin ich die Entenmama, die aufpasst, dass keinem ihrer Küken etwas passiert. "Fürsorge" ist, denke ich, hier das passende Wort. Es ist vielleicht nicht die verbreitetste Art von Management, aber es ist zumindest meine.
Und aus genau dieser Perspektive heraus hatten wir übrigens auch sehr lange keine Zeiterfassung. Wir haben immer mit Vertrauensarbeitszeit gearbeitet, und bei uns hat noch niemals jemand Überstunden gemacht. Das ist in zwölf Jahren noch kein einziges Mal vorgekommen. Natürlich kommt es vor, dass man mal ein oder zwei Stunden länger macht, weil man noch etwas fertigstellen möchte, aber: Ich sehe das eher wie eine Einladung zum Essen unter Freunden. Mal zahlt der eine, mal der andere, aber am Ende gleicht sich das aus. Genauso deshalb ist es auch völlig in Ordnung, wenn jemand mal früher Schluss macht. Es wird auch wieder Tage geben, an denen es länger dauert, und solange sich das ausgleicht, und beide Seiten fair miteinander umgehen, ist das okay.
Deshalb bin ich auch kein Freund des EuGH-Urteils zur verpflichtenden Zeiterfassung, weil es die Falschen trifft: Unternehmen wie wir, die schon vorher freiwillig darauf geachtet haben, dass niemand zu viel arbeitet, müssen sich nun mit zusätzlicher Bürokratie herumschlagen. Diejenigen, die ihre Mitarbeitenden knechten und ausbeuten wollen, werden trotzdem Mittel und Wege finden, das auch weiterhin zu tun. Aber sich aufzuregen, bringt an der Stelle leider nichts.
Nun habe ich Slack bereits mehrfach erwähnt. Es ist für uns das wichtigste Kommunikationsmittel, weil wir darüber schreiben, telefonieren und Videokonferenzen abhalten können. Aber das Wichtigste ist nicht das Tool an sich, sondern die Asynchronität. So kann jeder konzentriert arbeiten und wird nicht ständig unterbrochen. Aber ohne Selbstdisziplin und Eigenverantwortung von allen Beteiligten funktioniert asynchrone Kommunikation nicht.
Wir bei the native web sind ein Beispiel dafür, wie Homeoffice als dauerhaftes Modell gut funktionieren kann. Das Entscheidende dabei ist nicht, dass wir gerade Slack verwenden oder dass wir eine elektronische Zeiterfassung nutzen. Das Wichtige ist, dass es uns seit zwölf Jahren gelingt, die richtigen Menschen zusammenzubringen und eine vertrauensvolle Zusammenarbeit zu schaffen. Und das ist meiner Meinung nach der eigentliche Schlüssel, den man braucht, damit Homeoffice im großen Stil funktionieren kann. Denn wenn dieses Vertrauen nicht gegeben ist, dann wird es schwierig, und zwar völlig unabhängig davon, ob man remote oder vor Ort arbeitet.
Wenn Sie mich nun fragen, wie die Zukunft der Remote-Arbeit in der IT-Branche aussieht, muss ich ehrlich sagen: Ich weiß es nicht. Einerseits sehe ich großes Potenzial, das Ganze noch viel weiter auszubauen. Andererseits bin ich mir unsicher, ob allzu viele Unternehmen bereit sein werden, diesen Weg zu gehen und ein Stück ihrer (vermeintlichen) Kontrolle abzugeben. Vertrauen ist etwas, das aktiv gepflegt werden muss. Es passiert nicht einfach so. Man muss die richtigen Menschen zusammenbringen, die entsprechende Kultur etablieren und selbst mit gutem Beispiel vorangehen. Was die Politik sich dazu ausdenkt oder welche Technologien morgen in Mode sind, spielt dabei letztlich keine Rolle. Es ist am Ende immer eine Frage der Menschen. Deshalb weiß ich auch nicht, wie sich die Branche als Ganzes entwickeln wird, weil es keine Frage der Branche ist, sondern eine Frage, die jedes Team für sich selbst beantworten muss.
URL dieses Artikels:
https://www.heise.de/-9868729
Links in diesem Artikel:
[1] https://www.thenativeweb.io/
[2] https://www.youtube.com/live/sORcUbCOnBw
[3] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[4] https://www.heise.de/news/Elon-Musk-an-seine-Tesla-Fuehrungskraefte-Schluss-mit-Homeoffice-oder-Kuendigung-7129308.html
[5] mailto:rme@ix.de
Copyright © 2024 Heise Medien
Ein Raspberry Pi 4 ist über ein Adapterboard mit dem CrowView Note verbunden. Auf dem Bildschirm ist Raspberry Pi OS zu sehen.
(Bild: Elecrow, Screenshot und Bearbeitung: heise online)
Es schaut aus wie ein Notebook, besitzt aber keine CPU. Das CrowView Note benutzt stattdessen SBCs wie Raspberry Pi, Nvidia Jetson Nano als Schaltzentrale.
Wer den Tastatur-PC Raspberry Pi 400 [1] erworben hat, muss selbst für einen Bildschirm und eine Maus sorgen. Das Produkt bietet eine Tastatur mit integriertem Raspberry Pi 4 und Anschlussmöglichkeiten für eine Maus und einen Bildschirm. Sollte bald ein Raspberry Pi 500 erscheinen, dürfte es sich bezüglich seiner Spezifikation ähnlich wie der Vorgänger präsentieren.
Elecrow erweitert das Konzept des Raspberry Pi 400 um einen Bildschirm und ein Trackpad. Das Produkt CrowView Note kommt als Notebook mit Bildschirm und Tastatur inklusive Touchpad, aber ohne eigenen Prozessor daher. Zu diesem Zweck dient stattdessen ein über eine Brücke anschließbarer Raspberry Pi oder Nvidia Jetson Nano. Die Aufgaben des Mainboards übernehmen also SBCs (Single Board Computers). Man kann auch ältere Raspberry Pis anschließen, etwa über Kabel. Ob sich weitere SBCs mit dem Notebook vertragen, habe ich nicht getestet. Die Chance dafür dürfte hoch sein. Escrow gibt jedenfalls an, folgende Hardware zu unterstützen:
Aktuell läuft eine Kickstarter-Kampagne zum CrowView Note [2], später kommt das Gerät in den regulären Handel.
(Bild: Elcrow)
Möglicherweise bringt der Hersteller auch noch weitere Bridges (kleine Boards zum Anschluss von SBCs) auf den Markt, sollten viele Kunden das wünschen. Die Bridges beziehungsweise Adapterboards für Raspberry Pi werden in die linke Seite und in die Frontseite des CrowView Note eingesteckt und erlauben den bequemen Anschluss des jeweiligen SBC ganz ohne Kabel. Möglich ist auch die Verbindung eines Smartphones oder Tablets mit dem CrowView Note. Darüber hinaus kann das Gerät als externer 14-Zoll-Monitor für Geräte jeder Art über ein Mini-HDMI-Kabel oder USB-C-Kabel fungieren. Wer die Bridge – zwei kleine Boards – für den Raspberry Pi 4 oder 5 mit einem Gehäuse einsetzen möchte, muss darauf achten, dass das Gehäuse Zugriff auf die vorderen und linken Anschlüsse gewährleistet. Sollte dies nicht der Fall sein, kann man eins der vielen Gehäusemodelle für 3D-Drucker entsprechend modifizieren. Die Bridges sind übrigens nicht im Lieferumfang enthalten, sondern separat erhältlich. Pro Board beziehungsweise Brücke verlangt der Hersteller einen Obolus von 5 Euro.
Zusätzlich lässt sich das Quasi-Notebook mit diversen Spielekonsolen kombinieren.
Natürlich ist das CrowView Note nicht die einzige Alternative, um mit SBCs zu arbeiten.
Da das hier vorgestellte Notebook, wie erwähnt, Bildschirm, Tastatur und Trackpad bereits mitbringt, dürfte diese Variante jedoch die bequemste sein – speziell, wenn Mobilität gewünscht ist.
Das getestete CrowView Note verfügt über einen 14-Zoll-Monitor mit IPS-Panel und Full-HD-Auflösung (1920 × 1080 Pixel). Als abgedeckten Farbraum gibt der Hersteller 100 % sRGB an; als maximale Helligkeit 300 cd/m². Die Bildwiederholrate beträgt 60 Hz, mit Support für variable Refreshraten (VRR). Auf der linken Seite lassen sich die oben erwähnten Bridges für SBCs anschließen, alternativ auch über Kabel oder Adapter. Auf der rechten Seite stehen ein Anschluss für das Netzteil, ein Kopfhörerausgang sowie eine USB-C- und eine USB-A-Schnittstelle zur Verfügung. Eine USB-Schnittstelle unterstützt Power Delivery (PD) für das Aufladen externer Geräte mit 5V/5A. Zudem liefert Elecrow ein 12V/4A-Netzteil mit. Stereo-Lautsprecher sind ebenso wie ein Mikrofon im CrowView Note integriert.
Es existieren also zusammengefasst folgende Schnittstellen:
Links:
Rechts:
Ein eingebauter Akku bietet 5000 mAh Ladekapazität. Ohne eingeschalteten Bildschirm benötigt das Gerät rund zwei Watt, ansonsten acht Watt Leistung. Die Arbeitszeit hängt natürlich vom Leistungsbedarf des verwendeten SBC ab; bei einem Raspberry Pi 5 sind es bis zu drei Stunden. Wer das Gerät lediglich als externen Monitor nutzt, dürfte mit einer Batterieladung bei einer Laufzeit um 5 Stunden landen. Als positiv empfand ich das geringe Gewicht (1147 g) und die angenehme Größe des CrowView (33,4 cm × 22,2 cm × 1,75 cm), womit man es leicht transportieren kann. Das CrowView Note lässt sich bis zu 180 Grad aufklappen.
Dass das CrowView Note überwiegend aus Kunststoff gefertigt ist, wirkt sich auf die Qualität des Gehäuses nur marginal aus. Es macht einen recht robusten Eindruck. Anders ausgedrückt: Es tut, was es soll.
(Bild: Elecrow)
Neben den offensichtlichen Einsatzgebieten wie Office, Gaming und Entertainment bietet sich auch der Einsatz für Programmierung an, nicht nur für Embedded-Software. Wer Audio hören und seine Umwelt beschallen möchte, kann dies über die zwei eingebauten Stereo-Lautsprecher tun. Natürlich lässt sich davon kein Klang erwarten, der einem hochpreisigen Hi-Fi-System Konkurrenz machen kann. Speziell die schwachen Bässe fallen auf. Als externes Display lässt sich das Produkt genauso nutzen wie als Standalone-Gerät für SBCs.
Der Bildschirm ist matt und lässt sich gut zum Arbeiten verwenden. Bei sehr hellem Tageslicht kommt er zwar an seine Grenzen, leichtet aber im Regelfall ausreichend hell. Die Tastatur ist aus meiner subjektiven Perspektive gut bedienbar. Zum Anschluss von Endgeräten oder SBCs an das Notebook kann man Mini-HDMI oder einen USB-C-Eingang nutzen.
Das Trackpad des Review-Modells ließ wegen fehlenden Druckpunkts kein Drag-and-Drop oder das Scrollen von Bildschirminhalten zu. Laut Aussage des Herstellers sei dies lediglich ein Problem des Vorserien-Prototyps, das bei den ausgelieferten Geräten nicht mehr auftreten soll.
Ein kleiner Hinweis in Sachen Tastatur: Auf dem getesteten Vorserien-Testgerät befindet sich eine US-Tastatur. Die hilfsbereite Mitarbeiterin Annie Xie von Escrow hat während des Tests mitgeteilt, dass Elcrow das Gerät künftig auch mit deutscher Tastatur ausliefern will.
Wer auf das OSD (On-Screen-Display) zugreifen will, um Display-Einstellungen anzupassen, kann dies über Funktionstasten bewerkstelligen. Eine dieser Funktionstasten erlaubt das Umschalten zwischen verschiedenen Geräten. Das ist zum Beispiel wichtig, wenn ein SBC über Mini-HDMI angeschlossen ist und ein weiteres externes Gerät wie ein Smartphone über USB-C/DP (DisplayPort). Insofern verhält sich das CrowView Note wie ein KVM-Switch.
Entwickler von Embedded-Software oder auch anderer Anwendungen für SBCs wie dem Raspberry Pi profitieren vom CrowView Note. Das ist nicht nur dessen Mobilität geschuldet, sondern auch der Tatsache, dass dieses Gerät es auf bequeme Art ermöglicht, diverse SBCs anzuschließen und damit zu experimentieren. Beim Entwickeln, Testen und Debuggen erweist es sich als Vorteil, direkt mit Entwicklungs- und Testwerkzeugen über grafische Bedienoberflächen auf dem SBC arbeiten zu können, zum Beispiel mit Visual Studio Code und den Add-ons PlatformIO oder TinyGo.
Für das mobile Arbeiten mit dem CrowView Note dient einfach ein Smartphone, Tablet oder anderes mobiles Gerät als WLAN-Access-Point für den Netzwerkzugriff. Wer den Raspberry Pi 400 zu schätzen gelernt hat, dürfte sich leicht mit dem CrowView Note anfreunden, zumal dieser zusätzlich Bildschirm und Trackpad mitbringt. Bis auf den SBC und die Bridge bedarf es keinerlei weiterer Hardware. Insgesamt lassen sich alle benötigten Gerätschaften leicht verstauen und transportieren.
Das Produkt CrowView Note ist ein sehr preisgünstiges Gerät, das SBC-Nutzern mit Mobilitätsanforderungen eine geeignete Lösung verschafft, sich aber auch gut für den stationären Betrieb eignet. Die Idee, ein Notebookgehäuse inklusive Tastatur, Monitor und Maus mit einem SBC zu kombinieren, ist innovativ und bietet einige Vorteile, die das CrowView Note gut ausspielen kann. Der anvisierte Verkaufspreis von etwa 169 Euro ist auf jeden Fall gerechtfertigt.
Wer das Gerät erwerben möchte, kann dafür die noch laufende Kickstarter-Kampagne [3] nutzen. Der Preis beträgt 118 Euro (Early Bird) beziehungsweise 127 Euro (KickStarter-Preis). Nach Ende der Kampagne schlägt das Produkt mit rund 40 Euro mehr zu Buche (169 USD / Euro).
URL dieses Artikels:
https://www.heise.de/-9861699
Links in diesem Artikel:
[1] https://www.heise.de/tests/Raspberry-Pi-400-im-Test-Kleiner-Computer-fuer-Einsteiger-und-Bastler-4967904.html
[2] https://www.kickstarter.com/projects/elecrow/crowview-note-empowering-your-device-as-a-laptop/description
[3] https://www.kickstarter.com/projects/elecrow/crowview-note-empowering-your-device-as-a-laptop?lang=de
[4] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: cybrain/Shutterstock.com)
Es ist nun möglich, .NET-Anwendungen in eine Containerdatei zu veröffentlichen – ohne Dockerfile und ohne Bereitstellung in Docker.
Seit .NET 7.0 kann man bereits mit dotnet publish einen Docker-Container erstellen, ohne dass man dafür zuvor ein Dockerfile (eine zusätzliche Textdatei) bereitstellen muss.
Ein mit .NET 7.0 per Option PublishProfile=DefaultContainer erstellter Docker-Container wurde automatisch in Docker als aktiver Container bereitgestellt.
In .NET 8.0 gibt dazu noch eine Zusatzoption: -ContainerArchiveOutputPath. Diese erlaubt es, eine Container-Datei (tar.gz) zu erstellen, ohne sie direkt als aktiven Container bereitzustellen:
dotnet publish -p PublishProfile=DefaultContainer\
-p ContainerArchiveOutputPath=t:\meinblazorimage.tar.gz\
-p:ContainerBaseImage=mcr.microsoft.com/dotnet/aspnet:8.0-alpineFolgender Code zeigt das komplette Beispiel:
function New-TempDirectory {
$parent = [System.IO.Path]::GetTempPath()
[string] $name = [System.Guid]::NewGuid()
New-Item -ItemType Directory -Path (Join-Path $parent $name)
}
docker --version
# Tempordner erzeugen und dahin wechseln
New-TempDirectory | cd
# Projekt anlegen (hier: Blazor SSR)
dotnet new blazor -n BlazorImContainer
# In den Ordner wechseln
cd .\BlazorImContainer\
#region Programmcode in Startseite austauschen mit Informationen über Umgebung, .NET- und OS-Version sowie Prozess
$indexpage = @'
@page "/"
<PageTitle>Index</PageTitle>
<h1>Liebe Leser*innen,</h1>
<p>diese Blazor Web App (Blazor Static SSR) läuft
@if (System.Environment.GetEnvironmentVariable("DOTNET_RUNNING_IN_CONTAINER")=="true")
{ <text><b>im Container </b></text> }
else
{ <text>nicht im Container </text> }!</p>
<p>
.NET-Version: @System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription<br>
Betriebssystem: @System.Runtime.InteropServices.RuntimeInformation.OSDescription<br>
Prozess: @System.Diagnostics.Process.GetCurrentProcess().ProcessName<br>
Prozessidentität: @System.Environment.UserDomainName\@System.Environment.UserName<br>
IsPrivilegedProcess: @System.Environment.IsPrivilegedProcess</p>
<hr>
Umgebungsvariablen:
<ul>
@foreach(System.Collections.DictionaryEntry e in System.Environment.GetEnvironmentVariables())
{
<li>@e.Key: @e.Value</li>
}
</ul>
'@
$indexpage | Set-Content "components/pages/home.razor"
#endregion
# Container-Build-Paket hinzufügen (neu seit .NET 7.0, wird nicht mehr explizit gebraucht in .NET 8.0!!!)
#dotnet add package Microsoft.NET.Build.Containers --prerelease
# Veröffentlichen als Containerdatei (neu seit .NET 8.0)
dotnet publish -p PublishProfile=DefaultContainer -p ContainerArchiveOutputPath=t:\meinblazorimage.tar.gz -p:ContainerBaseImage=mcr.microsoft.com/dotnet/aspnet:8.0-alpine
# dann irgendwann: Laden in Docker
docker load --input t:\meinblazorimage.tar.gz
# Das ging schon in .NET 7.0
# Veröffentlichen als Container, alle MSBuild-Properties nach PublishProfile=DefaultContainer sind optional
#dotnet publish --os linux --arch x64 -c Release -p:PublishProfile=DefaultContainer -p:ContainerImageName=meinblazorimage #-p:ContainerBaseImage=mcr.microsoft.com/dotnet/aspnet:7.0-alpine
# Start des Containers (in getrennten Prozess, weil sonst dieser hier blockiert ist)
Start-Process powershell { docker run -it --rm -p 5000:8080 blazorimcontainer }
# optionaler Aufruf des Browsers zur Kontrolle
Start-Process "http://localhost:5000"
URL dieses Artikels:
https://www.heise.de/-9867463
Links in diesem Artikel:
[1] https://net.bettercode.eu/?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link
[2] https://net.bettercode.eu/index.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link#programm
[3] https://net.bettercode.eu/tickets.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_bcc_net.empfehlung-ho.link.link
[4] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: erstellt mit Dall-E durch iX-Redaktion)
Viele Entwicklerinnen und Entwickler leiden unter Scrum, doch kaum jemand wehrt sich gegen dessen Einsatz im Unternehmen. Woran liegt das?
Vor zwei Wochen habe ich einen Blogpost veröffentlicht, der die Frage behandelte, warum niemand mehr agil arbeiten möchte [1]. Und was soll ich sagen: Der Blogpost hat anscheinend einen Nerv getroffen. Das zugehörige Video auf YouTube [2] erreichte innerhalb der ersten 24 Stunden fast 19.000 Aufrufe. Das ist gut und gerne das fünf- bis zehnfache dessen, was wir normalerweise erwarten. Anders als sonst nahmen die Aufrufe am zweiten Tag nicht ab – im Gegenteil, sie stiegen weiter an. Inzwischen sind wir bei über 80.000 Aufrufen, und wenn wir in ein paar Tagen wieder nachsehen, werden wir voraussichtlich die Marke von 100.000 Aufrufen überschritten haben. Doch das ist noch nicht alles: Wir haben für das Video auch über 2.000 Likes und mehr als 400 Kommentare erhalten.
Auch der eingangs erwähnte Blogpost kann sich sehen lassen, mit inzwischen mehr als 600 Kommentaren. Kurz gesagt: Wir sind überwältigt. Damit hätten weder meine Kolleginnen und Kollegen noch ich selbst bei diesem Thema gerechnet, zumal es nicht das erste Mal war, dass wir Scrum & Co. kritisiert haben. Die Resonanz war dieses Mal jedoch einfach gigantisch, und dafür möchte ich mich als allererstes ganz herzlich bedanken!
Wir haben uns überlegt, dass es aufgrund des hohen Anklangs sinnvoll wäre, noch einen zweiten Teil des Blogposts zu schreiben. Dafür war es uns aber wichtig, alle Kommentare (also insgesamt über 1.000 Stück) zu lesen, um ein umfassendes Bild aller Meinungen zu erhalten. Irgendwann habe ich dann auch aufgehört, auf die Kommentare zu antworten, das war zeitlich einfach nicht mehr machbar, aber ich habe sie zumindest tatsächlich alle gelesen. Das ist auch der Grund, warum vergangene Woche kein Blogpost und kein Video veröffentlicht wurden: Wir waren einfach noch nicht so weit, und es kamen täglich jede Menge weitere Kommentare hinzu, sodass wir uns entschieden haben, noch eine Woche abzuwarten. Heute, rund zwei Wochen später, ist es nun aber so weit, und hier ist nun der besagte zweite Teil.
Wenn man sich diese über 1.000 Kommentare anschaut, fällt auf, dass die meisten in eine bestimmte Richtung gehen. Die Mehrheit der Kommentare stammt von Entwicklerinnen und Entwicklern, die beklagen, dass Scrum vom Management zweckentfremdet wird, um mehr Kontrolle auszuüben. Scrum wird also nicht so eingesetzt, dass sich ein Team damit selbst organisiert, wie es bei agilen Methoden eigentlich vorgesehen ist, sondern es wird als Projektmanagement-Werkzeug verwendet, dem alles andere untergeordnet wird.
Statt "Individuals and Interactions over Processes and Tools [4]" (wie es im agilen Manifest formuliert ist) passiert genau das Gegenteil: Scrum dominiert als Prozess alles. Dadurch wird Agilität im Keim erstickt, weil sie offensichtlich nicht gewünscht ist. Die traurige Wahrheit ist, dass in vielen Unternehmen nicht einmal Fake Agile vorherrscht, sondern eine schlimmere Variante: Dark Agile. Dabei geht es nur darum, auf dem Papier gut auszusehen, während Scrum in Wirklichkeit als Kontroll- und Steuerungsinstrument missbraucht wird. Genau das habe ich im letzten Blogpost als die schlimmste Variante beschrieben, wie man Agilität falsch leben kann.
Auffällig war auch, dass sich praktisch alle Beschwerden auf Scrum bezogen haben. Kaum jemand kritisierte Extreme Programming (XP) oder Kanban. Es ging immer nur um Scrum. Das führt uns zu dem, was ich im letzten Blogpost als den "agil-industriellen Komplex" bezeichnet habe, nämlich die Geldmacherei mit Zertifikaten und dergleichen. Nur sieht das Ganze in der Realität offenbar noch schlimmer aus, als ich es auf Basis meiner eigenen Erfahrung angenommen habe.
Fairerweise muss man jedoch sagen, dass Scrum oft nicht das eigentliche Problem ist. Viele Kommentatoren wiesen darauf hin, dass die Ursache tiefer liegt, nämlich bei einem Management, das ohne Realitätsbezug agiert und dem Kunden das Blaue vom Himmel verspricht, um mehr Umsatz und Gewinn zu machen. Dass dafür ausgerechnet Scrum herangezogen wird, verwundert wenig: Mit XP würde das nämlich nicht funktionieren, weil XP sich nicht um den organisatorischen Rahmen kümmert, sondern um den Entwicklungsalltag. XP bietet konkrete Best Practices, um Qualität und Effizienz zu steigern.
Deswegen finde ich persönlich XP auch weitaus sympathischer als Scrum: Es ist konkret, praxisorientiert und nicht so ein Pseudo-Blabla für Möchtegern-Manager. Dennoch kann man Scrum nur bedingt die Schuld geben. Denn wenn das Management keine Kontrolle abgeben will, wird es mit jeder Methode schwierig, positive Veränderungen herbeizuführen. Mit Scrum lässt sich das nur eben besonders gut verschleiern.
Etwas anderes ist uns aber auch noch aufgefallen: Viele Entwicklerinnen und Entwickler klagen über ihre Situation, aber kaum jemand unternimmt etwas dagegen. Wenn man genauer hinschaut, merkt man jedoch rasch, dass viele schlicht aufgegeben haben. Der Mut und die Kraft, sich gegen das Management oder die Prozesse zu wehren, sind einfach nicht mehr vorhanden.
Das finde ich persönlich sehr traurig. Softwareentwicklung kann so ein kreatives und schönes Feld sein, aber wenn das durch Kontrollsucht und Gier kaputt gemacht wird, ist das wirklich schlimm. Aber genau darüber müssen wir heute einmal sprechen: Was können Sie machen, wenn Ihnen auffällt, dass in Ihrem Unternehmen etwas schiefläuft, weil Scrum zwar auf dem Papier verwendet wird, sich aber alles nach dem genauen Gegenteil von Agilität anfühlt?
Bevor Sie jetzt sagen
"Das hat doch alles keinen Sinn, es ändert sich ohnehin nichts!"
lassen Sie mich eins sagen: Natürlich kann ich Ihnen nicht garantieren, dass sich etwas ändern wird, wenn Sie versuchen, das Thema anzugehen. Aber ich kann Ihnen mit Gewissheit sagen, dass sich rein gar nichts ändern wird, wenn Sie es nicht zumindest versuchen. Anders gesagt: Wenn Sie den Kopf in den Sand stecken, haben Sie schon verloren, bevor das Rennen überhaupt begonnen hat.
Ich kann nachvollziehen, dass es oft leichter ist, den Mund zu halten, insbesondere wenn Sie denken, dass Ihre Geschäftsführerin oder Ihr Geschäftsführer entgegengesetzter Meinung ist. Aber es gibt einen wichtigen Punkt: Nicht jeder Manager oder jede Managerin ist gleich. Sicherlich setzen manche Scrum durchaus bewusst so ein, wie es in den Kommentaren beschrieben wurde, aber andere wissen vielleicht gar nicht, dass es besser laufen könnte, oder ahnen nicht, wie unzufrieden Sie und Ihre Kolleginnen und Kollegen sind. Das werden Sie nur herausfinden, wenn Sie es versuchen.
Und übrigens: Auch ich bin Geschäftsführer und Manager, aber wir bei the native web [5] machen trotzdem kein Scrum. Tatsächlich bin ich sogar derjenige bei uns, der sich mit Abstand am stärksten dagegen wehrt. Anstelle von Scrum haben wir einen eigenen agilen Prozess entwickelt, der für uns gut funktioniert und sehr anders abläuft als Scrum, aber dennoch auf den Prinzipien des agilen Manifests basiert.
Es ist dabei aber wichtig zu verstehen, dass nicht jeder Prozess automatisch zu jedem Team passt. Der richtige Prozess hängt immer von den jeweiligen Umständen ab, und was heute sinnvoll ist, kann übermorgen schon nicht mehr passend sein. Deshalb sollte man den Status quo regelmäßig hinterfragen. Das ist daher übrigens auch eine der ersten Sachen, die ich neuen Kolleginnen und Kollegen bei uns sage:
"Wenn dir bei uns etwas auffällt, sprich das bitte sofort offen und ehrlich an. Entweder gibt es eine gute Begründung, warum wir etwas so handhaben, oder wir überlegen, ob wir etwas ändern sollten."
Denn, ganz im Sinn des agilen Manifests: Prozesse und Werkzeuge sollen die Menschen unterstützen, nicht umgekehrt. Deshalb stelle ich unseren Prozess auch nicht als Allheilmittel dar – denn er funktioniert für uns, aber das heißt nicht, dass er für Sie und Ihr Team genauso gut passt. Das hängt einfach zu sehr von den individuellen Anforderungen ab.
Aber werden wir konkret: Angenommen, Sie sind der Meinung, dass der Prozess in Ihrem Unternehmen ineffizient oder bürokratisch ist, dass er wenig agil ist und Sie aber gerne agil arbeiten würden. Vielleicht haben Sie das Gefühl, dass es oft nur darum geht, dass jemand in der Hierarchie über Ihnen auf dem Laufenden gehalten wird, und die typischen Scrum-Artefakte wie Sprints und Dailys sind verzerrt. Beispielsweise dauern Ihre Sprints zwei Monate, Sie haben mehrere Product Owner, aber keinen Scrum Master, das Daily ist ein klassisches Statusmeeting, und die Retrospektive läuft immer nach dem gleichen Schema ("was läuft gut, was läuft schlecht, was ändern wir") ab. Und dann wird auch noch in Stunden und Minuten geschätzt, statt in Story Points. Falls Ihnen das bekannt vorkommt, habe ich noch eine passende Videoempfehlung [6] für Sie.
Zusammenfassend lässt sich also sagen, dass Sie überzeugt sind, dass sich etwas ändern muss. Die gute Nachricht ist: Sie sind wahrscheinlich nicht allein. Die schlechte: Genauso wie die anderen schweigen Sie höchstwahrscheinlich. Warum? Nun, ganz einfach: Die meisten haben schlicht und ergreifend Angst. Denn obwohl oft gesagt wird, dass man sich den Job in der Entwicklung praktisch aussuchen könne, möchte trotzdem niemand negativ auffallen und deshalb womöglich gar den Job verlieren. Viele geben das nicht gerne zu, aber es ist die Wahrheit: Die meisten haben schlichtweg Angst.
Allerdings ist das kein Grund, sich zu schämen. Angst davor zu haben, aus einer sicheren Gruppe auszubrechen und sich als Einzelkämpfer gegen das System zu stellen, ist völlig normal. Wenig überraschend ging mir das früher genauso. Auch ich wollte nicht derjenige sein, der ständig schlechte Nachrichten überbringt, und auch ich hatte kein Interesse daran, meinen Job zu verlieren. Also habe ich mich (viel zu) oft zurückgehalten.
Das Problem dabei: All das führt zu einem Dilemma. Denn Sie wissen, dass es richtig wäre, etwas zu sagen, Dinge zu hinterfragen und vielleicht Verbesserungsvorschläge zu machen, aber die Angst hält Sie zurück. Das führt zu Unzufriedenheit, und dann passiert es vielleicht eines Tages, dass eine Kollegin genau das ausspricht, was Sie schon lange stört. Doch anstatt ihr beizuspringen, schweigen Sie – weil Sie nicht negativ auffallen wollen. Und vielleicht verlässt diese Kollegin nach ein paar Monaten das Unternehmen, man weiß nicht so genau, ob freiwillig oder nicht, aber noch Jahre später erinnern Sie sich gut an sie und denken:
"Eigentlich hätte ich damals den Mund aufmachen müssen."
Wie das immer so ist mit dem Wörtchen "eigentlich". Das bedeutet: Sie brauchen Mut. Genauso wie man bei einer heiklen Situation auf der Straße Zivilcourage braucht, braucht man Mut, um das Richtige zu tun. Natürlich kann es sein, dass Ihre Kritik Ihnen so negativ ausgelegt wird, dass Sie Ihren Job verlieren. Aber fragen Sie sich einmal selbst, ob Sie wirklich dauerhaft in einem Unternehmen arbeiten wollen, das Ihre Meinung so wenig wertschätzt und respektiert? Und was ist, wenn Sie tatsächlich nicht die einzige Person sind, die so denkt? Es ist unwahrscheinlich, dass ein Unternehmen ein ganzes Team entlassen würde, nur weil mehrere Mitarbeitende die Prozesse hinterfragen.
Wichtig ist auch, zu versuchen, die Perspektive des Managements zu verstehen. Ich würde nämlich unterstellen, dass viele Managerinnen und Manager ihren Job grundsätzlich gerne gut machen möchten und daher grundsätzlich ein offenes Ohr für Ihr Anliegen haben sollten, wenn es denn richtig formuliert wird. Deshalb sollten Sie signalisieren, dass es Ihnen um eine gemeinsame Verbesserung der Situation geht. Versuchen Sie, das Management nicht zu konfrontieren, sondern nach Lösungen zu suchen, die alle Beteiligten mittragen können. Denn wenn es Ihnen gelingt, sachlich und mit guten Argumenten zu überzeugen, erhöhen sich Ihre Chancen, ernst genommen zu werden.
Sachlichkeit ist dabei das oberste Gebot. Bereiten Sie sich gut vor, haben Sie Argumente und Fakten parat und überlegen Sie, wie Sie möglichen Einwänden begegnen können. Wenn Sie sachlich bleiben, werden Sie als professionell wahrgenommen, und das erhöht die Wahrscheinlichkeit, dass Ihre Vorschläge ernst genommen werden. Besonders hilfreich kann es dabei sein, mit konkreten Zahlen zu argumentieren. Wenn Sie belegen können, wie viel Zeit oder Geld durch ineffiziente Prozesse verloren geht und wie Ihre Vorschläge diese verbessern könnten, wird es schwieriger, Ihre Argumente abzulehnen. Die implizite Annahme ist: Zahlen lügen nicht – und das ist für das Management oft ein entscheidendes Kriterium.
Wählen Sie außerdem auch den richtigen Zeitpunkt, um das Thema anzusprechen. Überraschende, ad-hoc vorgebrachte Kritik wird weniger erfolgreich sein als ein geplantes Gespräch. Vielleicht wäre eine Retrospektive der richtige Ort, um das Thema anzusprechen.
Letztlich kann ich Ihnen aber natürlich nicht garantieren, dass Ihre Bemühungen erfolgreich sein werden. Manchmal muss man auch kleine Schritte gehen und sich mit Kompromissen zufriedengeben. Wenn Sie jedoch nichts tun, wird sich – wie anfangs schon erwähnt – garantiert nichts ändern. Resignieren Sie also nicht. Und falls Sie wirklich an den Punkt kommen, wo Sie das Gefühl haben, dass es sich nicht mehr lohnt zu kämpfen, dann bleiben Ihnen immer noch zwei Optionen: Zum einen können Sie dann immer noch versuchen, sich mit der Situation zu arrangieren und das Beste daraus zu machen. Doch wenn auch das nicht klappt, dann bleibt Ihnen letztlich nur noch die Option, das Unternehmen zu verlassen und sich ein Umfeld zu suchen, das besser zu Ihnen passt.
Falls Sie jetzt denken
"Golo, ich hätte mir insgesamt konkretere Tipps gewünscht"
dann verstehe ich das. Aber leider gibt es keine allgemeingültigen Lösungen, weil so viel von den jeweiligen Umständen abhängt. Deshalb lautet meine Hauptbotschaft: Seien Sie mutig! Versuchen Sie, Missstände anzugehen, indem Sie sie offen und ehrlich ansprechen. Suchen Sie sich Gleichgesinnte und versuchen Sie, eine Lösung zu finden, die alle – einschließlich des Managements – mittragen können. Bleiben Sie sachlich und bereiten Sie sich vor. Tun Sie alles in Ihrer Macht Stehende, um einen besseren Prozess zu etablieren.
Das Einzige, was Sie nicht tun sollten, ist, sich nur zu beklagen. Denn das garantiert, dass sich nichts ändern wird.
URL dieses Artikels:
https://www.heise.de/-9860999
Links in diesem Artikel:
[1] https://www.heise.de/blog/Scrum-XP-Co-warum-keiner-mehr-agil-arbeiten-will-9846824.html
[2] https://www.youtube.com/watch?v=iQK620MY_48
[3] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[4] https://agilemanifesto.org/
[5] https://www.thenativeweb.io/
[6] https://www.youtube.com/watch?v=CdnP30NEKqk
[7] mailto:who@heise.de
Copyright © 2024 Heise Medien
(Bild: Pincasso/Shutterstock.com)
Die iterate=>RUHR ist eine zweitägige Community-Konferenz mit Vorträgen zu .NET, KI, agilen Arbeitsweisen, Softwarearchitektur und -qualität.
Die iterate=>RUHR [1] ist eine zweitägige, vom Just Community e.V. veranstaltete Entwicklerkonferenz in Essen mit ehrenamtlichen Vorträgen zu .NET, KI, agilen Arbeitsweisen, Softwarearchitektur und -qualität. Die Konferenz richtet sich an .NET-Entwicklerinnen und -Entwickler sowie Personen, die interessiert sind an sauberem Code, effizientem Arbeiten und modernen Methoden.
Eine Anmeldung [2] ist jeweils gesondert für die Workshops (ab 149 Euro) und die Konferenz (ab 69 Euro) möglich, oder preisgünstig als Kombi-Buchung (ab 199 Euro). Mit dem Rabattcode ITR-ITV-10-P erhalten interessierte Blogleserinnen und -leser 10 Prozent Nachlass auf das Ticket.
Das Programm:
Freitag, 27.09.2024, gibt es Workshops [3] zu folgenden Themen:
Samstag, 28.09.2024, Konferenztag mit deutschlandweit bekannten Sprechern [4] zu folgenden Themen [5]:
Weitere Informationen zur Konferenz finden sich auf der iterate=>RUHR [6]-Website und das Anmeldungsformular ist unter it-visions.de [7] verfügbar.
URL dieses Artikels:
https://www.heise.de/-9861829
Links in diesem Artikel:
[1] https://iterate.ruhr/
[2] https://it-visions.de/Apps/IterateRuhr/Anmeldung
[3] https://iterate.ruhr/workshops/
[4] https://iterate.ruhr/speaker/
[5] https://iterate.ruhr/sessions/
[6] https://iterate.ruhr/
[7] https://it-visions.de/Apps/IterateRuhr/Anmeldung
[8] mailto:map@ix.de
Copyright © 2024 Heise Medien
This is a quality-focussed release for the 1.24.x series meant to provide a good product to people blocked on PHP 7.4, while we will increase the requirements to PHP 8.1+ from the next release.
A few highlights ✨:
This release has been made by @Alkarex, @math-GH and newcomer @pando85
Full changelog:
(Bild: Mega Pixel / shutterstock.com)
Entwicklerinnen und Entwickler können nun die Ordner /bin, /obj und /publish unter einem Ordner zusammenfassen.
Eine neue Einstellung in .NET 8.0 ermöglicht die Zusammenfassung der bisherigen Ordner /bin, /obj und /publish unterhalb eines gemeinsamen Oberordners, standardmäßig /artifacts.
Das wird durch das Hinzufügen eines Eintrags in der Datei Directory.Build.props erreicht:
<ArtifactsPath>$(MSBuildThisFileDirectory)artifacts</ArtifactsPath>
(Bild: Screenshot (Holger Schwichtenberg))
Diese Datei kann man per Kommandozeilenbefehl anlegen:
dotnet new buildprops --use-artifacts
(Bild: Screenshot (Holger Schwichtenberg))
Hinweis: In Preview 3 hieß dieser neue Ordner standardmäßig noch /.artifacts (mit führendem Punkt), seit Preview 4 nur /artifacts (ohne Punkt). Da Microsoft inzwischen zu der Erkenntnis gelangt ist, dass in den meisten .gitignore-Dateien für .NET "artifacts" schon ausgeschlossen ist, verwendet man nun die neue Schreibweise ohne Punkt.
Während man in Preview 3 das neue Ausgabeverzeichnis noch per Projektdateieintrag aktivieren konnte (<UseArtifactsOutput>true</UseArtifactsOutput>) braucht man nun zwingend eine eigenständige Datei Directory.Build.props mit diesem Inhalt im Projekt oder auf Projektmappenebene.
URL dieses Artikels:
https://www.heise.de/-9840689
Links in diesem Artikel:
[1] https://www.heise.de/blog/Neu-in-NET-8-0-1-Start-der-neuen-Blogserie-9574680.html
[2] https://www.heise.de/blog/Neu-in-NET-8-0-2-Neue-Anwendungsarten-9581213.html
[3] https://www.heise.de/blog/Neu-in-NET-8-0-3-Primaerkonstruktoren-in-C-12-0-9581346.html
[4] https://www.heise.de/blog/Neu-in-NET-8-0-4-Collection-Expressions-in-C-12-0-9581392.html
[5] https://www.heise.de/blog/Neu-in-NET-8-0-5-Typaliasse-in-C-12-0-9594693.html
[6] https://www.heise.de/blog/Neu-in-NET-8-0-6-ref-readonly-in-C-12-0-9602188.html
[7] https://www.heise.de/blog/Neu-in-NET-8-0-7-Optionale-Parameter-in-Lambda-Ausdruecken-in-C-12-0-9609780.html
[8] https://www.heise.de/blog/Neu-in-NET-8-0-8-Verbesserungen-fuer-nameof-in-C-12-0-9616685.html
[9] https://www.heise.de/blog/Neu-in-NET-8-0-9-Neue-und-erweiterte-Datenannotationen-9623061.html
[10] https://www.heise.de/blog/Neu-in-NET-8-0-10-Plattformneutrale-Abfrage-der-Privilegien-9630577.html
[11] https://www.heise.de/blog/Neu-in-NET-8-0-11-Neue-Zufallsfunktionen-9637003.html
[12] https://www.heise.de/blog/Neu-in-NET-8-0-12-Eingefrorene-Objektmengen-9643310.html
[13] https://www.heise.de/blog/Neu-in-NET-8-0-12-Leistung-von-FrozenSet-9649523.html
[14] https://www.heise.de/blog/Neu-in-NET-8-0-14-Neue-Waechtermethoden-fuer-Parameter-9656153.html
[15] https://www.heise.de/blog/Neu-in-NET-8-0-15-Geschluesselte-Dienste-bei-der-Dependency-Injection-9662004.html
[16] https://www.heise.de/blog/Neu-in-NET-8-0-16-Neue-Methoden-fuer-IP-Adressen-9670497.html
[17] https://www.heise.de/blog/Neu-in-NET-8-0-17-Zeitabstraktion-fuer-Tests-mit-Zeitangaben-9675891.html
[18] https://www.heise.de/blog/Neu-in-NET-8-0-18-Ein-Zeitraffer-mit-eigenem-FakeTimeProvider-9683197.html
[19] https://www.heise.de/blog/Neu-in-NET-8-0-19-Razor-HTML-Rendering-in-beliebigen-NET-Anwendungen-9691146.html
[20] https://www.heise.de/blog/Neu-in-NET-8-0-20-Neue-Code-Analyzer-fuer-NET-Basisklassen-9706875.html
[21] https://www.heise.de/blog/Neu-in-NET-8-0-20-Neue-Code-Analyzer-fuer-ASP-NET-Core-9710151.html
[22] https://www.heise.de/blog/Neu-in-NET-8-0-22-Neues-Steuerelement-OpenFolderDialog-fuer-WPF-9722901.html
[23] https://www.heise.de/blog/Neu-in-NET-8-0-23-Verbesserungen-fuer-ZipFile-zur-Arbeit-mit-Dateiarchiven-9722920.html
[24] https://www.heise.de/blog/Neu-in-NET-8-0-24-HTTPS-Proxies-bei-HttpClient-9722968.html
[25] https://www.heise.de/blog/Neu-in-NET-8-0-25-Resilienz-im-HTTP-Client-9763586.html
[26] https://www.heise.de/blog/Neu-in-NET-8-0-26-Anpassung-der-Resilienz-im-HTTP-Client-9773126.html
[27] https://www.heise.de/blog/Neu-in-NET-8-0-27-Konfigurierbare-Namenskonventionen-in-System-Text-Json-8-0-9784360.html
[28] https://www.heise.de/blog/Neu-in-NET-8-0-28-Erweiterung-fuer-die-Deserialisierung-von-JSON-Objekten-9790704.html
[29] https://www.heise.de/blog/Neu-in-NET-8-0-29-Verbesserungen-fuer-den-JSON-Source-Generator-9798297.html
[30] https://www.heise.de/blog/Neu-in-NET-8-0-30-Neue-Datentypen-in-System-Text-Json-8-0-9808793.html
[31] https://www.heise.de/blog/Neu-in-NET-8-0-31-Erweiterte-Serialisierung-in-System-Text-Json-8-0-9814260.html
[32] https://www.heise.de/blog/Neu-in-NET-8-0-32-Weitere-Neuerungen-in-System-Text-Json-8-0-9821053.html
[33] https://www.heise.de/blog/Neu-in-NET-8-0-33-Erweiterung-des-AOT-Compilers-9829857.html
[34] https://www.heise.de/blog/Neu-in-NET-8-0-34-Verbesserte-Ausgaben-beim-Kompilieren-9837144.html
[35] https://net.bettercode.eu/
[36] https://net.bettercode.eu/index.php#programm
[37] https://net.bettercode.eu/tickets.php
[38] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: sommart sombutwanitkul/Shutterstock.com)
Die Kommandozeilenbefehle dotnet publish und dotnet pack erstellen nun standardmäßig ein Release-Build.
Die Befehle dotnet publish und dotnet pack führten vor .NET 8.0 im Standard eine Debug-Kompilierung durch und man musste immer explizit angeben, dass man eine Release-Kompilierung wünscht.
Beide Befehle führen nun in .NET 8.0 im Standard eine Release- statt einer Debug-Kompilierung durch.
Die Debug-Kompilierung bleibt weiterhin möglich und ist auf Wunsch nutzbar durch
dotnet publish -c debugbeziehungsweise
dotnet pack -c debug
URL dieses Artikels:
https://www.heise.de/-9840333
Links in diesem Artikel:
[1] https://www.heise.de/blog/Neu-in-NET-8-0-1-Start-der-neuen-Blogserie-9574680.html
[2] https://www.heise.de/blog/Neu-in-NET-8-0-2-Neue-Anwendungsarten-9581213.html
[3] https://www.heise.de/blog/Neu-in-NET-8-0-3-Primaerkonstruktoren-in-C-12-0-9581346.html
[4] https://www.heise.de/blog/Neu-in-NET-8-0-4-Collection-Expressions-in-C-12-0-9581392.html
[5] https://www.heise.de/blog/Neu-in-NET-8-0-5-Typaliasse-in-C-12-0-9594693.html
[6] https://www.heise.de/blog/Neu-in-NET-8-0-6-ref-readonly-in-C-12-0-9602188.html
[7] https://www.heise.de/blog/Neu-in-NET-8-0-7-Optionale-Parameter-in-Lambda-Ausdruecken-in-C-12-0-9609780.html
[8] https://www.heise.de/blog/Neu-in-NET-8-0-8-Verbesserungen-fuer-nameof-in-C-12-0-9616685.html
[9] https://www.heise.de/blog/Neu-in-NET-8-0-9-Neue-und-erweiterte-Datenannotationen-9623061.html
[10] https://www.heise.de/blog/Neu-in-NET-8-0-10-Plattformneutrale-Abfrage-der-Privilegien-9630577.html
[11] https://www.heise.de/blog/Neu-in-NET-8-0-11-Neue-Zufallsfunktionen-9637003.html
[12] https://www.heise.de/blog/Neu-in-NET-8-0-12-Eingefrorene-Objektmengen-9643310.html
[13] https://www.heise.de/blog/Neu-in-NET-8-0-12-Leistung-von-FrozenSet-9649523.html
[14] https://www.heise.de/blog/Neu-in-NET-8-0-14-Neue-Waechtermethoden-fuer-Parameter-9656153.html
[15] https://www.heise.de/blog/Neu-in-NET-8-0-15-Geschluesselte-Dienste-bei-der-Dependency-Injection-9662004.html
[16] https://www.heise.de/blog/Neu-in-NET-8-0-16-Neue-Methoden-fuer-IP-Adressen-9670497.html
[17] https://www.heise.de/blog/Neu-in-NET-8-0-17-Zeitabstraktion-fuer-Tests-mit-Zeitangaben-9675891.html
[18] https://www.heise.de/blog/Neu-in-NET-8-0-18-Ein-Zeitraffer-mit-eigenem-FakeTimeProvider-9683197.html
[19] https://www.heise.de/blog/Neu-in-NET-8-0-19-Razor-HTML-Rendering-in-beliebigen-NET-Anwendungen-9691146.html
[20] https://www.heise.de/blog/Neu-in-NET-8-0-20-Neue-Code-Analyzer-fuer-NET-Basisklassen-9706875.html
[21] https://www.heise.de/blog/Neu-in-NET-8-0-20-Neue-Code-Analyzer-fuer-ASP-NET-Core-9710151.html
[22] https://www.heise.de/blog/Neu-in-NET-8-0-22-Neues-Steuerelement-OpenFolderDialog-fuer-WPF-9722901.html
[23] https://www.heise.de/blog/Neu-in-NET-8-0-23-Verbesserungen-fuer-ZipFile-zur-Arbeit-mit-Dateiarchiven-9722920.html
[24] https://www.heise.de/blog/Neu-in-NET-8-0-24-HTTPS-Proxies-bei-HttpClient-9722968.html
[25] https://www.heise.de/blog/Neu-in-NET-8-0-25-Resilienz-im-HTTP-Client-9763586.html
[26] https://www.heise.de/blog/Neu-in-NET-8-0-26-Anpassung-der-Resilienz-im-HTTP-Client-9773126.html
[27] https://www.heise.de/blog/Neu-in-NET-8-0-27-Konfigurierbare-Namenskonventionen-in-System-Text-Json-8-0-9784360.html
[28] https://www.heise.de/blog/Neu-in-NET-8-0-28-Erweiterung-fuer-die-Deserialisierung-von-JSON-Objekten-9790704.html
[29] https://www.heise.de/blog/Neu-in-NET-8-0-29-Verbesserungen-fuer-den-JSON-Source-Generator-9798297.html
[30] https://www.heise.de/blog/Neu-in-NET-8-0-30-Neue-Datentypen-in-System-Text-Json-8-0-9808793.html
[31] https://www.heise.de/blog/Neu-in-NET-8-0-31-Erweiterte-Serialisierung-in-System-Text-Json-8-0-9814260.html
[32] https://www.heise.de/blog/Neu-in-NET-8-0-32-Weitere-Neuerungen-in-System-Text-Json-8-0-9821053.html
[33] https://www.heise.de/blog/Neu-in-NET-8-0-33-Erweiterung-des-AOT-Compilers-9829857.html
[34] https://www.heise.de/blog/Neu-in-NET-8-0-34-Verbesserte-Ausgaben-beim-Kompilieren-9837144.html
[35] mailto:rme@ix.de
Copyright © 2024 Heise Medien
