Schlüsseltechnologie

By Xyrillian NoisesTechnology

Schlüsseltechnologie episodes

August 21, 2025STP077: Liste von Listen
Als der inoffizielle Wikipedia-Vorlesepodcast sehen wir es als unsere Pflicht, eine Eigenheit dieser anzusprechen: nämlich Listen von Listen, obwohl es uns eigentlich um Listen im Speicher geht.
Shownotes
Rückbezüge:
fundamentale Datenstrukturen siehe STP071: Felder/Listen, assoziative Datenfelder (Maps), Graphen
Frage: Wie stellt man solche Datenstrukturen im Speicher dar? Gibt es darauf überhaupt die eine richtige Antwort?
algorithmische Komplexität siehe STP029: Liste mit n Elementen ausdrucken in O(n), aber sortieren in O(n log(n)) bis O(n^2)
Speicherallokation siehe STP047 und Speicherschutz siehe STP019: Bezug wird gleich klar werden
Listen kann man als verkettete Liste darstellen
klassisches Studienobjekt in Erstsemester-Datenstrukturen-Vorlesungen
intuitiv verständlich: Parallele zu segmentierten Halsketten
wahlweise einfach oder doppelt verkettet
effiziente Operationen: Einfügen am Ende, Entfernen am Ende
ineffiziente Operationen: Einfügen in der Mitte, Wahlzugriff/Suche
Vergleichstabelle mit Darstellung der Zeiteffizienz
alles in allem durchwachsene Performance -> geht es besser?
alternative Strategie: interne Darstellung der Liste als balancierter Baum (oder evtl. "ausgeglichener Baum")
außerdem Link auf die englische Wikipedia, die nicht nur unbalancierte, sondern auch balancierte Bäume zeigt
kann nur sortierte Listen darstellen
Idee: Wurzelknoten hat das Median-Element, dann der linke Ast alle kleineren und der rechte Ast alle größeren Elemente
im Grunde alle gängigen Operationen mittelschnell: Wahlzugriff/Suche, Einfügen an beliebigen Stellen, Entfernen von beliebigen Stellen (Änderungen erfordern im Allgemeinen ein Austarieren des Baumes)
große Variation von Implementationsstrategien für dieses Balancieren -> hier nicht
verkettete Listen und balancierte Bäume sehen auf dem Papier ziemlich effizient aus, haben aber in ihrer reinen Form pathologisch schlechtes Speicherverhalten
hoher Platzverbrauch: z.B. bei einfach bzw. doppelt verketteten Listen muss zu jedem Element müssen noch eine bzw. zwei Speicheradressen abgelegt werden
hohe Allokationslast: wenn nicht eine Arena oder ein vergleichbarer Small Object Allocator verwendet wird
schlechte Lokalität: beim Durchlaufen nachfolgender Elemente werden im schlimmsten Fall ständig unterschiedliche Speicherseiten getroffen, was fortlaufend Seitenfehler verursachen kann
in der Praxis mit Abstand dominante Implementationsstrategie: dynamische Felder
Beobachtung: Einfügen oder Löschen an beliebigen Stellen wird kaum gemacht; man hängt eher mehrmals ans Ende an und sortiert dann, falls nötig
Idee: Optimieren auf Einfügen am Ende bei möglichst optimalen Speicherverhalten
Umsetzung: einfaches Feld (ein fortlaufendes Stück Speicher, in dem mehrere Elemente hintereinander abgelegt werden) mit aktuellem Füllstand N und Kapazität K
Einfügen ans Ende: normalerweise einfach N erhöhen; wenn N nicht in K passt, größeren Speicher reservieren, alles hinüberkopieren und die alten Speicherallokation verwerfen
Löschen vom Ende: einfach N reduzieren, keine Deallokation erforderlich
Einfügen am Anfang oder in die Mitte: alle Elemente dahinter nach hinten verschieben
nahezu optimales Speicherverhalten von dynamischen Feldern begründet ihre Dominanz
Platzverbrauch: neben der Speichergröße der Elemente selber nur zwei Zahlen (N und K)
Allokationslast: Vergrößern geht für gewöhnlich in exponentiellen Schritten und wird damit für wachsende Listen immer seltener nötig
Lokalität: lineare Suche durch die Liste geht linear durch den Speicher hindurch -> folgende Speicherseiten können vom Prozessor oft schon auf Verdacht vorgeladen werden
trotzdem: die anderen Datenstrukturen haben auch ihre Berechtigung (z.B. modifizierte balancierte Bäume als Basis für Datenbank-Indizes)
Xyrill will auch noch auf analoge Weise über Maps und Graphen reden -> weiter in STP079
58 min
August 21, 2025STP077: Liste von Listen
Als der inoffizielle Wikipedia-Vorlesepodcast sehen wir es als unsere Pflicht, eine Eigenheit dieser anzusprechen: nämlich Listen von Listen, obwohl es uns eigentlich um Listen im Speicher geht.
Shownotes
Rückbezüge:
fundamentale Datenstrukturen siehe STP071: Felder/Listen, assoziative Datenfelder (Maps), Graphen
Frage: Wie stellt man solche Datenstrukturen im Speicher dar? Gibt es darauf überhaupt die eine richtige Antwort?
algorithmische Komplexität siehe STP029: Liste mit n Elementen ausdrucken in O(n), aber sortieren in O(n log(n)) bis O(n^2)
Speicherallokation siehe STP047 und Speicherschutz siehe STP019: Bezug wird gleich klar werden
Listen kann man als verkettete Liste darstellen
klassisches Studienobjekt in Erstsemester-Datenstrukturen-Vorlesungen
intuitiv verständlich: Parallele zu segmentierten Halsketten
wahlweise einfach oder doppelt verkettet
effiziente Operationen: Einfügen am Ende, Entfernen am Ende
ineffiziente Operationen: Einfügen in der Mitte, Wahlzugriff/Suche
Vergleichstabelle mit Darstellung der Zeiteffizienz
alles in allem durchwachsene Performance -> geht es besser?
alternative Strategie: interne Darstellung der Liste als balancierter Baum (oder evtl. "ausgeglichener Baum")
außerdem Link auf die englische Wikipedia, die nicht nur unbalancierte, sondern auch balancierte Bäume zeigt
kann nur sortierte Listen darstellen
Idee: Wurzelknoten hat das Median-Element, dann der linke Ast alle kleineren und der rechte Ast alle größeren Elemente
im Grunde alle gängigen Operationen mittelschnell: Wahlzugriff/Suche, Einfügen an beliebigen Stellen, Entfernen von beliebigen Stellen (Änderungen erfordern im Allgemeinen ein Austarieren des Baumes)
große Variation von Implementationsstrategien für dieses Balancieren -> hier nicht
verkettete Listen und balancierte Bäume sehen auf dem Papier ziemlich effizient aus, haben aber in ihrer reinen Form pathologisch schlechtes Speicherverhalten
hoher Platzverbrauch: z.B. bei einfach bzw. doppelt verketteten Listen muss zu jedem Element müssen noch eine bzw. zwei Speicheradressen abgelegt werden
hohe Allokationslast: wenn nicht eine Arena oder ein vergleichbarer Small Object Allocator verwendet wird
schlechte Lokalität: beim Durchlaufen nachfolgender Elemente werden im schlimmsten Fall ständig unterschiedliche Speicherseiten getroffen, was fortlaufend Seitenfehler verursachen kann
in der Praxis mit Abstand dominante Implementationsstrategie: dynamische Felder
Beobachtung: Einfügen oder Löschen an beliebigen Stellen wird kaum gemacht; man hängt eher mehrmals ans Ende an und sortiert dann, falls nötig
Idee: Optimieren auf Einfügen am Ende bei möglichst optimalen Speicherverhalten
Umsetzung: einfaches Feld (ein fortlaufendes Stück Speicher, in dem mehrere Elemente hintereinander abgelegt werden) mit aktuellem Füllstand N und Kapazität K
Einfügen ans Ende: normalerweise einfach N erhöhen; wenn N nicht in K passt, größeren Speicher reservieren, alles hinüberkopieren und die alten Speicherallokation verwerfen
Löschen vom Ende: einfach N reduzieren, keine Deallokation erforderlich
Einfügen am Anfang oder in die Mitte: alle Elemente dahinter nach hinten verschieben
nahezu optimales Speicherverhalten von dynamischen Feldern begründet ihre Dominanz
Platzverbrauch: neben der Speichergröße der Elemente selber nur zwei Zahlen (N und K)
Allokationslast: Vergrößern geht für gewöhnlich in exponentiellen Schritten und wird damit für wachsende Listen immer seltener nötig
Lokalität: lineare Suche durch die Liste geht linear durch den Speicher hindurch -> folgende Speicherseiten können vom Prozessor oft schon auf Verdacht vorgeladen werden
trotzdem: die anderen Datenstrukturen haben auch ihre Berechtigung (z.B. modifizierte balancierte Bäume als Basis für Datenbank-Indizes)
Xyrill will auch noch auf analoge Weise über Maps und Graphen reden -> weiter in STP079
58 min
July 31, 2025STP076: Debugging
Die Zeiten, in denen wie von Grace Hopper "actual bugs" in Computern gefunden werden, sind wohl weitestgehend vorbei. Trotzdem ist Debugging bis heute eine Sache, um die man in der IT nicht herumkommt.
ShownotesWikipedia definiert den Begriff:
Als Debuggen (dt. Entwanzen) oder Fehlerbehebung bezeichnet man in der Informatik den Vorgang, in einem Computerprogramm Fehler oder unerwartetes Verhalten zu diagnostizieren und zu beheben. Die Suche von Programmfehlern (sogenannten Bugs) ist eine der wichtigsten und anspruchsvollsten Aufgaben der Softwareentwicklung und nimmt einen großen Teil der Entwicklungszeit in Anspruch. Ein guter Programmierer muss daher auch das Debuggen beherrschen und umgekehrt: Nicht jeder gute Programmierer ist auch ein guter Debugger.
Xyrill hat eine Anekdote: Firefox im Hotel-WLAN hängt beim Starten vier Minuten
nicht dramatisch, könnte man auch hinnehmen (oder halt auf einen anderen Browser wechseln)
Xyrill war aber in der Stimmung, zu debuggen
Kategorie 1: Werkzeuge zum Mitlauschen
traceroute (bzw. tracert unter Windows): Nachverfolgung der Netzwerkroute zu einem bestimmten Ziel anhand von Ping-Paketen mit begrenzter TTL; stark variable Pings oder plötzliche Anstiege des Pings deuten auf ein Problem an dem entsprechenden Hop hin
tcpdump und Wireshark: Mitschneiden aller Netzwerkpakete, die über ein Netzwerk-Interface versendet oder empfangen werden (evtl. mit Suchmuster, z.B. "nur auf Port 80" oder "nur für Ziel-/Quelladresse 192.168.0.1")
mitmproxy et al: Fangnetz für HTTP-Anfragen und -Antworten, die von einem Prozess geschickt und empfangen werden (quasi wie tcpdump, aber einige Netzwerkschichten höher); super zum Reverse-Engineering von webbasierten APIs
mal nicht Netzwerk: strace listet alle Syscalls (Systemrufe) auf, die ein Prozess während seiner Lebenszeit macht (siehe Beispiel unten)
zurück zum Hotel-WLAN-Beispiel: strace zeigt Timeout bei DNS-Anfrage zum eigenen Hostnamen jeweils 2x nach 120s
Grund für diese Anfragen bleibt unklar, aber die Lösung ist eindeutig: expliziter Eintrag für den eigenen Hostnamen in /etc/hosts, um die DNS-Abfrage zu umgehen
Kategorie 2: Werkzeuge zum Nachverfolgen
printf-Debugging: im Programmcode vorrübergehend Befehle einbauen, die zu sinnfälligen Zeitpunkten Logmeldungen ausdrucken, insb. beinhaltend den aktuellen Zustand von bestimmten Variablen (sprich: transiente Form von Logging, siehe STP032)
Debugger wie gdb: Ausführung eines Programms bis zum Moment des Crashs oder bis zu benutzerdefinierten Haltepunkten; dann schrittweise Ausführung bzw. Inspektion von Variablen (flexibler als printf-Debugging, aber erfordert direkten Zugriff auf den Prozess)
Profiler wie valgrind: Ausführung eines Programms und währenddessen Erfassung von Statistiken zu Laufzeit- und Speichernutzung, um Speicherzugriffsfehler oder Ineffizienzen aufzudecken
Kategorie 3: Werkzeuge zum Zurückverfolgen
Bisektion z.B. mit git bisect: Aufspüren derjenigen Änderung in einem Versionsverwaltungssystem, die eine bestimmte Verhaltensänderung (z.B. einen Bug oder einen Performance-Einbruch) ausgelöst hat
Beispiel einer strace-Ausgabe für den Befehl mv /tmp/foo /tmp/bar (stark verkürzt):
$ strace mv /tmp/foo /tmp/bar
execve("/usr/bin/mv", ["mv", "/tmp/foo", "/tmp/bar"], 0x7fff820357b0 /* 67 vars */) = 0
... (ca. 60 Zeilen an Setup-Phase der libc und anderer Shared Libraries ausgelassen) ...
ioctl(0, TCGETS, {c_iflag=ICRNL|IXON|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
renameat2(AT_FDCWD, "/tmp/foo", AT_FDCWD, "/tmp/bar", RENAME_NOREPLACE) = -1 EEXIST (File exists)
openat(AT_FDCWD, "/tmp/bar", O_RDONLY|O_PATH|O_DIRECTORY) = -1 ENOTDIR (Not a directory)
newfstatat(AT_FDCWD, "/tmp/foo", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/tmp/bar", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
geteuid() = 1001
faccessat2(AT_FDCWD, "/tmp/bar", W_OK, AT_EACCESS) = 0
renameat2(AT_FDCWD, "/tmp/foo", AT_FDCWD, "/tmp/bar", 0) = 0
lseek(0, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
close(0) = 0
close(1) = 0
close(2) = 0
exit_group(0) = ?
+++ exited with 0 +++
59 min
July 10, 2025STP075: Prozessorarchitekturen im Vergleich
Nach einer sehr deutlichen Einordnung der Aufnahmezeit kommen wir im Wesentlichen zu den Unterschieden zwischen x86 und ARM. Natürlich wird auch geklärt, was das ist. Gegen Ende gibt es noch ein paar Meinungen und Weissagungen zum Thema KI.
Shownotes
Rückbezug STP011: grundsätzliche Beschreibung von Maschinensprache
siehe Beispiel unter dem obenstehenden Link
Maschinensprache ist spezifisch für die Prozessorarchitektur, genauer die Befehlssatzarchitektur (instruction set architecture, ISA)
heutzutage relevante ISA
x86: PCs, Notebooks, Server, Supercomputer, Apple Macs bis 2020
ARM: Smartphones, Tablets, Apple Macs seit 2020, Einplatinencomputer (SBC) wie Raspberry Pi
Embedded: AVR, MIPS, etc.
Hochleistungsrechnen: neben x86 noch Power und SPARC
Neuentwicklungen: RISC-V, LoongArch
Warum ist die Wahl der ISA wichtig?
ISA beschreibt nominal, wie ein CPU die Bits in einer ausführbaren Binärdatei (sprich: die kodierte Form der Maschinensprache) zu interpretieren hat
daraus als Konsequenz Festlegung von Hardware-Parametern wie der Adressbreite oder der Anzahl und Größe der verfügbaren Register
Designentscheidungen in der ISA wirken sich auf die maximal erreichbare Performance und auf die Energieeffizienz aus
klassischerweise Gegenüberstellung zweier verschiedener Design-Philosophien: Complex Instruction Set Computing (CISC) und Reduced Instruction Set Computing (RISC) (die Grenzen verschwimmen aber in der Praxis)
historischerweise war CISC die Domäne großer CPU-Hersteller, die sich ein kompliziertes Design leisten konnten, um dem Programmierer Arbeit abzunehmen (z.B. Intel); und RISC die Domäne kleiner CPU-Hersteller, die aus möglichst wenig Arbeitseinsatz möglichst viel erreichen wollten
Was steht in einem Maschinencode-Befehl drin?
grundsätzlich eine Operation, die ausgeführt wird (z.B. "Addition zweier 64-Bit-Zahlen")
als Quellen für Argumente und Ziel für das Ergebnis: entweder Register, Speicher oder Immediate-Argumente
Beispiel CISC: 20 verschiedene Ausführungen des ADD-Befehls in x86-64
Beispiel RISC: 2 verschiedene Ausführungen des ADD- bzw. ADDI-Befehls in RISC-V (RV32I)
wenn RISC wie bei RISC-V eine Load/Store-Architektur verwendet, muss man also im Zweifelsfall Argumente erst aus dem Speicher in Register laden
dadurch tendenziell mehr Maschinencode, aber weniger Komplexität in der CPU
Abwägungen zwischen Energieeffizienz (ARM) und Performance (x86)
aktueller ARM-Befehlssatz (A64) hat durchgängig 4 Byte große Befehle, was das Dekodieren vereinfacht; x86-Befehle haben eine variable Breite zwischen 1 und 15 Byte
x86 hat eine lange Pipeline, um u.a. die komplexen Befehle in kleinere Teilschritte (Micro-Operations) zu zerlegen oder bestimmte häufige Befehlssequenzen in effizientere Gruppen (Macro-Operations) zu fusionieren und damit die Performance zu steigern; ARM-Prozessoren machen das nicht und sparen dadurch Energieaufwand
x86 hat für bestimmte Rollen designierte Spezialregister, die je nach Befehl feste Bedeutungen haben; ARM (und RISC allgemein) verwendet für fast alles 31 General-Purpose-Register
57 min
June 19, 2025STP074: Literatur: Vom Mythos des Mann-Monats, Teil 2
Beim letzten Mal war zuviel Buch für zu wenig Zeit übrig. Daher nun die Fortsetzung mit zwar gelegentlich etwas angestaubten, im Großen und Ganzen aber sinnvollen, Vorschlägen zur Organisation von Softwareentwicklung.
ShownotesFortsetzung aus STP068. Wir lesen weiterhin die englische Erstausgabe von 1975, die im Internet Archive digitalisiert wurde.
Kapitel 4: Aristokratie, Demokratie und System-Design
Brooks beschreibt als Leitmotiv die Kathedrale von Reims, die von acht Generationen von Baumeistern errichtet wurde, aber trotzdem eine beachtliche gestalterische Kohärenz aufweist, da die nachfolgenden Generationen das ursprüngliche Design ungewöhnlich stark respektieren: "Das Ergebnis verkündet nicht nur die Herrlichkeit Gottes, sondern auch seine Macht, gefallene Menschen von ihrem Stolz zu befreien."
Kontrast nicht nur zu den meisten anderen Kirchenbauten, sondern auch zu Programmsystemen
dort aber nicht wegen Mehrgenerationalität, sondern wegen Vielstimmigkeit
These: konzeptionelle Integrität ist die wichtigste Eigenschaft im System-Design (vgl. STP006: Unix-Philosophie)
Vorteil: bessere Verwendbarkeit und Erlernbarkeit
Umsetzung: das Design sollte von einigen wenigen Architekten kontrolliert werden, die im Interesse des Benutzers handeln; doch hieraus drei Problemstellungen
Problem 1: Folgt hieraus nicht eine aristokratische Klassengesellschaft von wenigen Vordenkern und bauendem Fußvolk?
nein, auch auf der Implementationsebene gibt es viele interessante Entscheidungen zu treffen
Brooks zitiert einen Aphorismus aus der Kunst: "Form befreit.", sprich: Kreativität erwächst aus dem Umgang mit Beschränkungen
in der Architektur geht es darum, was man dem Nutzer präsentiert (das "Was")
in der Bauphase geht es darum, wie man dieses Verhalten erreicht (das "Wie")
es ist absolut gewollt, dass die Erbauer auch Designideen vorschlagen und auf Beschränkungen hinweisen; nur entscheiden sie nicht final über das Design
Problem 2: Wie verhindert man, dass die Architekten von den Zwängen der Realität abgekoppelt im Elfenbeinturm davonschweben?
Xyrill bringt eines seiner Lieblings-Schimpfwörter ins Spiel: "Architektur-Astronaut"
Lösung dieselbe wie für das dritte Problem
Problem 3: Wie stellt man sicher, dass die Erbauer mit allen wichtigen Details des Designs vertraut gemacht werden?
Lösung: die Erbauer frühzeitig in den Design-Prozess involvieren, Ideen aufnehmen, Designvorschläge auf praktische Umsetzbarkeit abklopfen etc.
Vergleich mit der Errichtung eines Gebäudes: man kann die Erbauer nicht erst einstellen, wenn der Plan fertig ist, weil in der Software-Entwicklung immer noch vieles explorativ und nicht nach Standard-Muster abläuft
Kapitel 5: Das Problem des zweiten Systems ("Second-System Effect")
in diesem Dialog zwischen Architekt und Erbauer stellen sich viele Ideen des Architekten als unpraktikabel heraus und werden verworfen... bis zum nächsten Mal
Szenario: das erste System war erfolgreich, der Architekt hat Prestige und Erfahrung gewonnen
"Dieses zweite ist das gefährlichste System, dass man jemals entwirft." -> Second-System Effect
beim dritten und vierten System hat man dann mehr Erfahrung, was tatsächlich funktioniert und was nur auf dem Papier gut aussieht
Xyrill legt Wert darauf, dass seine jüngeren Kollegen früh ihre eigenen Komponenten alleine entwerfen, damit sie dann auch in die Probleme ihrer eigenen Design-Entscheidungen reinlaufen und daraus lernen
der vorgeschlagene Lösungsansatz ist leider etwas antiquiert: "Eine Disziplin, die dem Architekten die Augen öffnen wird, ist es, jeder kleinen Funktion einen Wert zuzuweisen: Fähigkeit X ist nicht mehr wert als M Bytes Speicher und N Mikrosekunden pro Aufruf. Diese Werte dienen als Richtschnur für die ersten Entscheidungen und während der Implementierung als Leitfaden und Warnung an alle."
nicht realisitisch in Zeiten, wo die meisten Programmierer offenkundigerweise noch nie einen Profiler verwendet haben oder auch nur ein Gefühl für ihre eigene Ressourcenvergeudung haben
Kapitel 6: Weitergabe von Informationen ("Passing the Word")
Wie stellt eine Gruppe von 10 Architekten sicher, dass ihre Entwürfe von 1000 Mitarbeitenden berücksichtigt und von allen Benutzern verstanden werden?
gute Dokumentation ist erforderlich: Handbücher für die Benutzer, Architekturpläne für die Erbauer
Qualitäten guter Dokumentation
vorzugsweise aus der Feder von nur ein oder zwei Personen -> Fokus auf konzeptionelle Integrität
Beschreibung sowohl des definierten Verhaltens als auch der Grenzen der Definiertheit
Definitionen in formaler Notation und/oder präziser Sprache, um Lücken und Widersprüche im Design möglichst früh aufzudecken
Anti-Pattern: Definition eines Systems durch sein eigenes Verhalten
führt zu Bug-für-Bug-Kompatibilität (siehe STP050) bzw. Ossifikation (siehe STP056): inhaltliche Widersprüche zwischen der ursprünglichen Implementation, späteren Revisionen sowie später abgeleiteten Spezifikationen
gutes Pattern: Spezifikation maschinenlesbar darstellen, damit die Erbauer die Konformität ihrer Implementation mit der Spezifikation automatisch prüfen können
aktuelles Beispiel: formale Spezifikation von Schnittstellen mittels OpenAPI
Wie erarbeitet man Designs? Vorschlag von Brooks:
Meetings zwischen den Architekten und involvierten Erbauern, in denen das Problem vorgestellt und mehrere Designideen gesammelt werden
dann Erarbeitung von detaillierten Designentwürfen mit Pro-/Kontra-Analyse
daraus entweder sofortiger Konsens oder Entscheidung eines Chefarchitekten
klingt offensichtlich, ist aber im agilen Zeitalter selten anzutreffen
noch eine kleine Anmerkung am Rande: auch Kurzabsprachen am Telefon sollten dokumentiert werden :)
Kapitel 7: Warum ist der Turm zu Babel gefallen?
Woran können Projekte scheitern?
unklare Zielstellung
nicht genug Personal
nicht genug Material/Budget
nicht genug Zeit
unzureichende Technologien
ineffektive Kommunikation
Wie sollen Teams kommunizieren? Neben direkten Gesprächen z.B. via Telefon und Gruppengesprächen z.B. in Meetings wird ein Arbeitsbuch vorgeschlagen.
nicht ein konkretes Dokument, sondern eine Struktur für alle Dokumente im Projekt
die Dokumentation am Ende geht aus den Memos am Anfang hervor, also gleich richtig machen
Memos sollen durchnummeriert werden, damit man später darauf Bezug nehmen kann (wir fühlen uns an RFCs erinnert) -> Arbeitsbuch ergibt sich als Baumstruktur aller Memos (wir fühlen uns an Hypertext erinnert, und in der Tat wird Douglas C. Engelbart am Rande erwähnt)
Brooks diskutiert dann praktische Unterschiede zwischen Papier und Microfiche, die heutzutage keine Relevanz mehr haben (aber ein Nachteil: die Verteilung aktualisierter physischer Seiten sorgte dafür, dass die Erbauer mitbekamen, wo sich wann was ändert)
D. L. Parnas von der Carnegie-Mellon-Universität hat eine noch radikalere Lösung vorgeschlagen. Seine These lautet, dass ein Programmierer am effektivsten ist, wenn er von den Details der Konstruktion von Systemteilen, die nicht seine eigenen sind, abgeschirmt wird, anstatt ihnen ausgesetzt zu sein. Dies setzt voraus, dass alle Schnittstellen vollständig und genau definiert sind. Dies ist zwar ein solider Entwurf, aber in der Abhängigkeit von seiner perfekten Ausführung ist eine Katastrophe vorprogrammiert. Ein gutes Informationssystem deckt Schnittstellenfehler auf und regt zu deren Korrektur an.
Xyrill stimmt voll und ganz zu: sorgfältiges Gegenlesen der Meeting-Minutes der benachbarten Teams ist zwar extrem zeitaufwändig, verhindert aber regelmäßig katastrophale Design-Entscheidungen
Organisationsstruktur: Brooks hält eine baumförmige Organisationsstruktur für unausweichlich (mehrere Vorgesetzte für einen Angestellten = Chaos) und schaut darauf, was jedes Team haben sollte
Produzent ("Producer"): stellt das Team zusammen, verteilt Arbeit, definiert Ziele und Zeitpläne, kommuniziert außerhalb des Teams
Architekt bzw. technischer Leiter ("Technical Director"): entwirft das Design und entwickelt es fortlaufend weiter, kommuniziert innerhalb des Teams
drei Optionen, wie diese Rollen verteilt sein können
Option 1: Produzent und Architekt sind dieselbe Person
nur für kleine Teams gangbar, bis etwa 3-6 Personen
"Denker sind rar; Macher sind rarer; und Denker-Macher sind am rarsten."
Option 2: Produzent als Chef, Architekt als seine rechte Hand
funktioniert nur, wenn der Produzent die technische Autorität des Architekten akzeptiert
Xyrill hat lange in einem derartigen Zweierteam als Architekt gearbeitet und weiß, dass es funktionieren kann; kommt aber extrem auf die interpersonelle Dynamik des Duos an
Option 3: Architekt als Chef, Produzent als seine rechte Hand
findet Brooks am besten; Xyrill ist geneigt, zuzustimmen
Noch mehr
Es gibt noch acht weitere Kapitel, die wir irgendwann™ mal besprechen werden.
1 hr 10 min
May 29, 2025STP073: Was aus Holz
Diesmal vieleicht doch eher aus Interesse denn aus Resignation. Wieder geht's um Holz. Allerdings noch nicht so weit, wie Xyrill sich das zuerst vorgestellt hatte.
Shownotes
Rückbezug STP072: Programmierung besteht aus Algorithmen und Datenstrukturen, Holzbau besteht aus Materialien (siehe STP053) und Fertigungstechniken (diesmal)
Als Beispiel die Herstellung einer Leimholzplatte (z.B.: Tischplatte, Schrankseite, Wandverkleidung, …) aus Schnittholz. Wir gehen die Technologie durch und Besprechen dabei auch die Maschinen. Hierbei hauptsächlich stationäre Werkstattmaschinen im Gegensatz zu Handmaschinen: https://blog.schneidbrettguru.de/wann-ist-ein-holzschneidebrett-wirklich-gut-gemacht/
Schritt 1: Auftrennen
heute praktisch immer mit der Kreissäge, besonders für große Querschnitte praktisch wegen Schiebeschlitten, beim Auftrennen Auftrennblatt
Schritt 2: Abrichten
mithilfe einer sogenannten Abrichthobelmaschine
plan machen und Winkelkante erstellen
Schritt 3: Aushobeln
Herstellung von parallelen Flächen zu den bisher abgerichteten mittels Dickenhobelmaschine
Exkurs Fügen:
Stumpfe Fuge: glatte Flächen
Gefälzte Fuge: mit einfachem Falz
Nut-Spund
Nut-Feder
Kronenfuge
Die profilierten Verbindungen werden mit einer Tischfräsmaschine hergestellt, eventuell auch mit einer Oberfräse.
Schritt 4: Verleimen
In userem Fall einfach mit Weißleim, weil Leime ca. 5 Einzelsendungen sind
Pressen mit Zwingen oder mechanischen Pressen
Schritt 5: nochmal Aushobeln
jetzt aber die ganze Platte mit einem Mal, eventuell auch vorher abrichten
Schritt 6: nochmal Winkelkante
jetzt aber die ganze Platte mit einem Mal
Schritt 7: Formatzuschnitt
wieder mit der Formatkreissäge, jetzt aber die ganze Platte und mit einem Feinschnittblatt
1 hr 12 min
May 08, 2025STP072: Der Datentypeneisberg
Auch heute geht es mit Rost und Kaffee weiter, allerdings mit grundsätzlicheren Datentypen. ttimeless wird von besonders winzigen Datentypen überrascht und Xyrill formuliert Gedanken darüber, warum Struktur das Handeln bestimmen sollte.
Shownotes
Rückbezug STP071: anhand von JSON haben wir die sichtbaren Datentypen besprochen
heute tauchen wir unter die Wasseroberfläche ab und schauen auf Typen, die man eher im Speicher als in einer Datei sieht
Einwurf Kombinatorik: Wieviele mögliche Werte haben die vorgenannten Typen (sofern nicht unendlich)? (wir schreiben K(T) für die Kardinalität des Typs T)
Boolean: K(bool) = 2 (true oder false)
Zahlen: K(T_N) = 2^N Werte für Zahltypen mit N Bits (z.B. 256 für i8 oder 65536 für u16), weil jedes Bit zwei Werte hat, die unabhängig voneinander gewählt werden können
Listen fester Länge: K([T; N]) = K(T)^N für K(T) mögliche Werte des Elementtyps T und Länge N
Listen variabler Länge: K(Vec) = ∞ bis auf praktische Platzbeschränkungen
Listen wirken sich auf die Kardinalität also wie eine Potenzierung aus
Gibt es auch andere Rechenoperationen? -> algebraische Datentypen
Produkttypen: Gesamttyp P enthält je einen Wert von Typ T_1, T_2, ..., T_N, somit K(P) = K(T_1) * K(T_2) * ... * K(T_N)
in Rust: entweder als Tupel (geordnete Folge von Werten, die mit Zahlenindizes bezeichnet sind), z.B. type Vector3D = (f64, f64, f64), oder als Strukturtypen (ungeordnete Menge von Werten, die mit Namen bezeichnet sind, z.B. struct Person { first_name: String, last_name: String })
in JSON: Tupel als Listen, Strukturtypen als Objekte (beim Einlesen muss die Elementzahl bzw. die Namen der Elemente geprüft werden)
Summentypen: Gesamttyp S enthält entweder einen Wert vom Typ T_1 oder T_2 oder ... oder T_N, somit K(P) = K(T_1) + K(T_2) + ... + K(T_N)
in Rust: Enumerationstyp, z.B. enum ParseResult { Ok(DataStructure), Err(ParseError) }
in JSON: keine klare Konvention, Serialisierung in Rust erzeugt ein Objekt mit einem Eintrag, die nach der jeweiligen Variante benannt ist (z.B. {"Ok": ...})
sehr kleine Spezialfälle: Gibt es Datentypen, die kleiner als bool sind?
Produkttyp mit null Feldern (in Rust struct Empty {}): nur ein möglicher Wert (1 ist das neutrale Element der Multiplikation)
in JSON kann man das als null serialisieren
in Rust kommt dies im Summentyp enum Option { Some(T), None } vor; None ist hier im Prinzip eine Kurzschreibweise für None(Empty)
Summentyp mit null Varianten (in Rust enum Impossible {}): keine möglichen Werte (0 ist das neutrale Element der Addition)
in JSON nicht darstellbar (keine Werte haben keine Serialisierung)
in Rust kommt so ein Typ in Funktionen vor, die kein Ergebnis liefern (z.B. quit())
nützlicher, als es zunächst erscheint, sobald Monomorphisierung ins Spiel kommt
Abendgedanken: Warum das ganze Gerede über Datentypen?
angewandte Programmierung besteht aus zwei (verwandten) Teildisziplinen: Algorithmen (das Wie, der Rechenteil) und Datenstrukturen (das Was, der Speicherteil)
Xyrill hält Datenstrukturen für das Fundament; die Wahl der Algorithmen muss an zweiter Stelle kommen
vergleichbarer Ansatz in klassischen Software-Design-Lehrbüchern wie SICP und HtDP
49 min
April 17, 2025STP071: Das Periodensystem der Datentypen
Offenbar gibt es unterschiedliche Ergebnisse, wenn verschiedene Datentypen für die gleichen Dinge verwendet werden. Wir fangen heute mal damit an, zu verstehen, welche Datentypen es denn überhaupt gibt. Außerdem geht es scheinbar um Kaffee und Rost.
Shownotes
JSON: ein populäres Format für die Serialisierung von Daten
Serialisierung: "Abbildung von strukturierten Daten auf eine sequenzielle Darstellungsform", insb. auf Bytefolgen wie in einer Datei oder einer Datenübertragung im Netzwerk
JSON ist bekannt dafür, nicht erfunden, sondern "entdeckt" worden zu sein
außerdem relativ minimal: nur sechs verschiedene Grundstrukturen
aber trotzdem relativ universell: damit unser Ausgangspunkt für die Kartografierung der Welt der Datentypen
außerdem Gegenüberstellung mit dem Typvorrat von Rust (einer zeitgenössischen Programmiersprache mit einem detaillierten Typsystem)
atomare Datentypen: einzelne Werte (C++ nennt sie "Plain Old Data" (POD), Perl nennt sie "Skalare")
Boolean: ein Bit (wahr oder falsch)
Typvorrat in Rust: bool
in JSON: true oder false
Zahlen: in verschiedenen Bitgrößen, mit oder ohne Vorzeichen, Ganzzahl oder Fließkommazahl
Typvorrat in Rust: u8/i8, u16/i16, u32/i32, u64/i64, u128/i128, usize/isize, f32, f64
in JSON: wie gewohnt ausgeschrieben (z.B. 42, -23.5) oder in wissenschaftlicher Notation (z.B. 7.297e-3 oder -6.022E23)
Zeichenfolgen: nicht wirklich unteilbar, aber wird für gewöhnlich als einzelner Wert verstanden
Typvorrat in Rust: String (UTF-8), OsString (Kodierung gemäß Zeichentabelle des Systems) und andere
in JSON: als Zeichenkette mit Anführungszeichen und mit Escape-Sequenzen für nicht druckbare Zeichen (z.B. "Mit freundlichen Grüßen\nErika Mustermann")
fehlender Wert: in JSON null (heißt woanders vielleicht auch nil)
Typvorrat in Rust: siehe später
Listen: ein abgeleiteter Datentyp
deswegen vorhin "atomar": der Typ einer Liste bestimmt sich aus dem Typ der Elemente (in statisch typisierten Programmiersprachen ist z.B. "Liste von 8-Bit-Zahlen" etwas anderes als "Liste von Strings" oder "Liste von Listen von Strings")
Typvorrat in Rust:
mit variabler Länge: Vec, wobei X für den Typ der Elemente steht (Beispiele zu oben: Vec, Vec, Vec>); der Name "Vec" deutet auf die Struktur im Arbeitsspeicher hin
mit fester Länge: [X; N], wobei N für die Anzahl von Elementen steht
in JSON: kommagetrennte Liste der Elemente in eckigen Klammern (z.B. [42, 23])
Unterschiede zu Rust:
JSON ist nicht statisch typisiert und hat nur einen Listentyp, der alle möglichen Elemente enthalten kann und beliebig lang sein kann (z.B. [42, "Hallo", []])
assoziative Datenfelder: ein anderer abgeleiteter Datentyp
enthält nicht einzelne Elemente, sondern Paare von Schlüssel und Wert; ermöglicht schnellen Zugriff auf einen Wert anhand seines Schlüssels
heißt je nach Programmiersprache bzw. Datenformat "Objekt", "Map", "Dictionary" etc.
Typvorrat in Rust: unter anderem HashMap, wobei K der Schlüsseltyp ("key") und V der Werttyp ("value") ist; der Name "HashMap" deutet auf die Struktur im Arbeitsspeicher hin
in JSON: kommagetrennte Liste von Wertpaaren in geschweiften Klammern, die Wertpaare jeweils mit Doppelpunkt getrennt; der Schlüssel muss ein String sein (z.B. {"Karo": 9, "Herz": 10, "Pik": 11, "Kreuz": 12})
wiederum Unterschied zu Rust: Werte verschiedener Typen dürfen gemischt werden
Damit ist alles beschrieben, was JSON kann, doch es gibt so viel mehr! Beispiele für abgeleitete Datentypen:
Mengen ("Sets"): wie Listen, aber ohne definierte Ordnung
in Rust: HashSet; der Name "HashSet" deutet auf die Struktur im Arbeitsspeicher hin
Graphen: Netzwerke von Knoten mit Kanten dazwischen (z.B. Straßenkarte: Kreuzungen = Knoten, Straßen = Kanten)
in Rust: kein entsprechender Typ in der Standardbibliothek
ähnlich wie bei Listen und assoziativen Datenfeldern viele verschiedene Implementationsstrategien, aber bei Graphen gibt es keinen "Standardansatz"
Außerdem ist JSON relativ restriktiv in der Auswahl an PODs. Andere Serialisierungsformate unterstützen zum Beispiel Datums- oder Zeitangaben, Referenzen auf externe Dateien etc.
im Gespräch erwähnt
Hörtipp: Douglas Crockford bei CoRecursive zur Entstehung von JSON
Lehrbuch: Structure and Interpretation of Computer Programs
1 hr 3 min
March 27, 2025STP070: Blitzgespräche
Manche Dinge geben keine ganze Folge her. Dies ist der Versuch, ein paar davon zusammenzufassen: Wie definiert sich ein Geek? Bringt es etwas, den Computer aus und wieder einzuschalten? Und rechnet es sich vielleicht in umgekehrtem Polnisch besser?
Shownotes
im Intro erwähnt:
Eternal September
Im Dunkeln ist alles viel aufregender
Talk Nr. 1: Geek Code
Primärquelle (Version 3.12, Stand vom 5. März 1996): https://web.archive.org/web/20090220181018/http://geekcode.com/geek.html
vordergründig: eine kompakte Notation zur Selbstbeschreibung von Geeks durch eine Menge von Attributen und Interessen
Beispiel: das Attribut d beschreibt den eigenen Dresscode (d++ für den Anzugträger, d- für Jeans und T-Shirt, !d für nackt etc.)
diverse Modifier, z.B. $ für "damit verdiene ich Geld" oder > für ein persönliches Entwicklungsziel
Beispiel: C++ alleine ist "ich kenne mich gut mit Computern aus", C++>$ ist "...und möchte damit Geld verdienen"
Xyrill fühlt sich an die Grammatik agglutinierender Sprachen erinnert
Parallele zum Jargon File (siehe STP050): Geek Code ist ein Produkt seiner Zeit und Subkultur mit veralteten Debatten (z.B. interessiert sich heute noch jemand für Babylon 5 oder Akte X?) tendenziösen Einschätzungen (z.B. vgl. h--- mit r+++)
Kann es sowas heute nochmal geben?
Wahrscheinlich schwierig, man bräuchte zu viele Subkategorien.
Passt wahrscheinlich nicht für die heutigen visuell dominierten Medien (YouTube, TikTok, Instagram etc.).
Vielleicht für Dating?
Talk Nr. 2: Ist was dran an "try turning it off and on again"? Ja! Hierzu eine Kurzeinführung in Kombinatorik:
ein Speicher mit einem Bit kann zwei Zustände annehmen (klar)
ein Speicher mit zwei Bit kann 2 * 2 = 4 Zustände annehmen
Beispiel/Analogie: UI mit zwei Checkboxen
aber nur, wenn die Bits voneinander unabhängig sind
Beispiel: UI für Ticketkauf, Checkbox 1 = "ist Kind", Checkbox 2 = "ist Rentner"
von vier Zuständen ist einer ungültig: Kinder können nicht Rentner sein
kombinatorische Explosion: bei mehr Bits exponentiell mehr mögliche Zustände, die meisten davon ungültig
Programmfehler oder "kosmische Strahlung" können dazu führen, dass ungültige Zustände erreicht werden
"Aus- und Wiederanschalten" ist die ultimative Form des Zurücksetzens in einen gültigen Zustand
Talk Nr. 3: Umgekehrte polnische Notation
Wie schreibt man mathematische Ausdrücke?
Infix-Notation: die klassische Schreibweise für mathematische Ausdrücke, bei der Operatoren zwischen ihren Operanden stehen
Problem: Operationsreihenfolge muss entweder per Konvention ("Punkt vor Strich") oder durch Klammern klargestellt werden (Bsp. 2 * 3 + 5 = (2 * 3) + 5 ≠ 2 * (3 + 5))
Polnische Notation: Operatoren stehen vor ihren Operanden (Bsp. + * 2 3 5 bzw. * 2 + 3 5)
hier technisch gesehen keine Klammern notwendig (außer um Menschen das Lesen zu erleichtern, Bsp. + (* 2 3) 5 bzw. * 2 (+ 3 5))
Umgekehrte polnische Notation (RPN): Operatoren stehen hinter ihren Operanden (Bsp. 2 3 * 5 + bzw. 2 3 5 + *)
Warum würde man das machen wollen?
RPN entspricht dem Betriebsmodus eines Kellerautomaten (siehe STP021)
Kellerautomaten kann man extrem günstig in Hardware implementieren (d.h. mit sehr wenig Code, mit sehr wenig Prozessorregistern, mit wenig Speicher)
Praxisbeispiel: Forth
Praxisbeispiel: HP-12C
1 hr
March 06, 2025STP069: Anatomie einer GUI
Wer hat sich nicht schon einmal über schlechte Benutzeroberflächen geärgert? Aber wer wiederum hat sich Gedanken gemacht, warum diese Oberflächen so sind, wie sie sind, oder wie das Ganze überhaupt zustande kommt?
Shownotes
Rückbezug zu STP008 (2D-Grafik) und STP010 (3D-Grafik): dort besprochen die grundsätzliche Methodik zum Zeichnen mit Pixeln, aber wer zeichnet hier eigentlich?
Infografik zum Rendering-Ablauf unter Linux, mit Display-Manager (bzw. heutzutage Wayland-Compositor) und Desktop-Shell
unter Windows war früher alles in explorer.exe, heute gibt es den Desktop Window Manager dafür
Thema heute: Wie baut man als Anwendungsprogramm seine GUI zusammen?
klassischer Ansatz: GUI-Toolkit; Programmbibliothek mit vorgefertigten Steuerelementen (Texteingabefeld, Knopf, Checkbox, Listenansicht), siehe Beispielbilder im verlinkten Artikel
neumodischer Ansatz: Darstellung einer Programmoberfläche mit einer Webbrowser-Engine (z.B. Electron); somit Verwendung von Webtechnologien (HTML, CSS und JavaScript) an Stelle (im Wortsinne) eines GUI-Toolkits
bis dahin, dass selbst die Interface-Elemente von Computerspielen mittlerweile quasi mit einem Webbrowser gerendert werden (Beispielprodukt)
eine Variation von STP022: Webentwickler gibt es wie Sand am Meer
Wie baut man so ein GUI-Toolkit? Retained Mode vs. Immediate Mode
Retained Mode: die Grafikbibliothek behandelt die Steuerelemente als langlebige Objekte, die vom Programm über die Zeit manipuliert werden
Immediate Mode: beim Zeichnen jedes Einzelbildes muss das Programm die gewünschten Steuerelemente neu deklarieren; Grafikbibliothek speichert nur wenig Zustand (z.B. aktuelle Cursorposition oder noch nicht verarbeitete Eingabeereignisse)
Unterschiede:
Retained Mode ist intuitiver (aus Entwicklersicht)
Retained Mode führt oft zu einer Duplikation von Zustandsverwaltung (z.B. speichert das Checkbox-Steuerelement ein Bit, ob es angehakt ist; und der Applikationscode selber speichert ein gleichlautendes Bit, ob die entsprechende Funktion aktiviert ist)
Immediate Mode ist flexibler (z.B. gibt eine direkte Möglichkeit, die Standard-Steuerelemente noch mit einzelnen Zeichenbefehlen zu erweitern)
Immediate Mode kann resourcenschonender sein (z.B. geringerer Speicherverbrauch, weil nicht sichtbare Steuerelemente weniger wahrscheinlich im Speicher gehalten werden)
Immediate Mode kann auch mehr Ressourcen verbrauchen (z.B. weil jedes Einzelbild neu gerendert werden muss, auch wenn sich meist in weiten Teilen gar nichts ändert)
Mischform: React-artige GUI-Toolkits arbeiten im Retained Mode, aber alle Aktualisierungen führen zu einer kompletten Neudeklaration der betroffenen Steuerelemente; diese Deklaration wird dann mit den vorhandenen Steuerelementen abgeglichen
Layoutstrategien: Wie werden Steuerelemente gegeneinander angeordnet?
Ziel: ein Arrangement von Steuerelementen soll z.B. auf Änderungen der Fenstergröße sinnfällig reagieren
Beispielbild aus der Dokumentation zu QGridLayout -> bei Änderungen der Höhe des Fensters sollen die beiden oberen Zeilen gleichbleiben und nur die unterste Zeile wachsen
explizite Deklaration durch den Programmentwickler mühselig: stattdessen berechnen Steuerelemente selbst bestimmte Eigenschaften wie "minimale Größe", "maximale Größe", "sinnvolle Größe" oder "wieviel profitiere ich von Wachstum"
Layoutstrategien bei Webseiten und Webapplikationen
anhand des Textflusses, z.B. Eingabefelder und Links/Schaltflächen innerhalb von Mengentext (in anderen GUI-Toolkits unüblich; das Web ist durch seine Dokumentenorientierung hier besonders)
für alles andere bis ca. 2013: tabellenbasierte Layouts mit manuell (z.B. per JavaScript) berechneten Größen; in der Praxis frustrierend und fehleranfällig
seit 2013: Flexbox für Layout von Elementen mit dynamischer Größe nebeneinander bzw. in Form eines Textflusses
seit 2017: Grid für Layout von Elementen, die sich in ein dynamisches Raster einfügen
außerdem seit 2009/2010: CSS Media Queries zum Umschalten zwischen Layouts auf Basis von Eigenschaften des Endgerätes (Bildschirmgröße und -ausrichtung, Maus- oder Touch-Bedienung, Dark Mode oder Light Mode, etc.)
zum Weiterhören: Pentaradio vom März 2024: "UI: Hui oder pfui?"
1 hr 11 min

About Schlüsseltechnologie

From the publisher's feed

Die IT hat unser Leben in den letzten Jahrzehnten von Grund auf verändert. Aber wie funktioniert sie wirklich? Das möchte ttimeless mal erklärt bekommen. Zum Glück hat Xyrill Antworten.

Share Schlüsseltechnologie

Sign up to save your podcasts

Schlüsseltechnologie

Schlüsseltechnologie episodes

About Schlüsseltechnologie

More shows like Schlüsseltechnologie

Freak Show

Lage der Nation - der Politik-Podcast aus Berlin

Logbuch:Netzpolitik