Moin und herzlich Willkommen zu einfach komplex Hi Burkhard,
Moin Moin. So und Hallo Liebe können heute
ist Teil 2 der großen Grundprinzipien der
Softwareentwicklung. Diesmal wollen wir dann wirklich
über die Sam of Python sprechen, die 20 beziehungsweise 19
Guiding Principles, die dort aufgestellt wurden und warum die
nicht nur für die Entwicklung mit Python oder für die
Softwareentwicklung allgemein zuständig sind.
Als kleine Wiederholung würde ich das Board einfach
zusammenfassen und falls nicht, vielleicht erst nochmal die
vorherige Folge, aber dieses Teil 2.
Burkhard, Warum ist das so entscheidend und wichtig, dass
wir darüber sprechen? Ja, ich meine in der letzten
Folge haben wir glaube ich noch auf höherer Flughäfen, Flughöhe,
Weisheiten irgendwie bekannt gegeben.
Diesmal ist es noch ein bisschen niedriger Flughöhe, aber es sind
einfach so, man muss sich, vielleicht kommt das eigentlich,
dass Python, also Python ist ja ne Programmiersprache, total
relevant ist. Auch heute noch existiert schon
ein bisschen länger, heute ist sie so relevant, weil wir das
ganze AIKI Thema in Python abgeriegelt wird durch 2 sehr
bekannte Frameworks die das erlauben, ich nenne die kurz mal
Tensor Flow von Google und Pytorch glaube ich von.
Jetzt muss ich nachdenken, Meter vielleicht nochmal schneiden.
Gerät das Quatsch was ich erzählt hab?
Und bei einer Programmiersprache?
Da werden bestimmte Sachen festgelegt, wie funktioniert ja
und was sie kann und so weiter und sofort und dann gibt es.
Da gibt es natürlich Leute, die Lieben das dann so wie das
funktioniert mit der Programmiersprache und es gibt
auch ganz viele Leute, die kritisieren das, weil sie
irgendwie andere mögen und so weiter da stehen ja auch immer
Leute hinter dir entwickelt haben ne das man auch sagen
Python wurde von Guido von Rossum, ein Holländer quasi
gebaut, der Erschaffer der Sprache Python wurde auch
liebevoll Dictator of Life getauft, also freundlicher
Diktator, wohlwollender Diktator auf Lebenszeit, was die
Entwicklung dieser Sprache angeht und so ein armer Mensch,
der muss natürlich schwerwiegende Entscheidungen
treffen, ja. Nämlich wie diese Sprache
auszusehen hat und welche Features sie bekommt.
Ja, und vielleicht irgendwie auch mal wieder.
Was in der nächsten Version nicht mehr gibt und so weiter
das ist, das ist furchtbar, furchtbar schlimm, glaube ich,
weil das ist so, als würdest du eine Firma führen.
Management muss Entscheidungen treffen, die jetzt aber nicht
nur für 2000 Mitarbeiter, sondern für 20000000 oder
Irgendsowas wichtig sind. Ja, und jeder von diesen
20000000 sind Nutzer dieser Programmiersprache Entwickler
und das sind meistens clevere Leute und die haben auch
ziemlich krasse Meinungen zu allem.
Und die sind auch manchmal gar nicht so zurückhaltend mit ihrer
Meinung. Und da kriegst du beides.
Ja, da kriegst du natürlich Support und Wohlwollen, aber du
kriegst auch viel Kritik rein so.
Aus dieser Not heraus war wieder gerade, dass irgendwie Python in
der Kritik stand wegen des technischen, nervigen, wegen,
dem Aufräumen von Memory Garbage Collection nennt man das also
Müllbereinigung weißt schön, muss nicht aktiv darum kümmern,
die wie Müll, den ich angesammelt habe mit Objekten
und so weiter also quasi Datenmüll, ja wie ich den
bereinigt, das macht das schon alleine und darüber gab es im
Detail ne. Ja, eine, ein Streitgespräch und
viele Nutzer waren da irgendwie wohl ja sehr kritisch unterwegs
und haben mal wieder irgendwie gesagt, es muss sich alles
ändern. Wir müssen alles neu machen, ja
die ganzen Konzepte sind Mist. So man Ruckelte an den
Designgrundlagen so ja aus dieser Zeit kommt das ja und da
gab es n Chancen gibt es immer noch fest im Netz verankert kann
man nachlesen so. Und jetzt kommt der Tim Peters
ins Spiel, der auch einfach ein Urgestein der Python Entwicklung
war, dass auch viele grundsätzliche Beiträge Python
hat er gemacht und so weiter der hat sich darauf eingelassen zu
sagen, OK lass uns doch mal die Grundfesten, die Philosophie,
denke oder sowas von Python hinschreiben, damit wir diese
ganzen Kritiker ein für alle Male irgendwie mal einordnen
können, so denn man kann ja nicht ein System machen was
jedem und allem gerecht ist. Ja das stimmt ja genauso wie in
der Politik. Ja es gibt, deswegen gibt es
verschiedene Parteien, jeder hat, jeder hat irgendwo seine
seine Sache, ja es gibt ja nicht eine Partei die jedem gefällt
so. Das funktioniert nicht so mit
der Programmiersprache auch und dann muss ich noch ein Paar,
dann muss ich so ein paar Weisheiten runter schreiben oder
so ein paar Leitlinien so n Paar soll ich sagen, ja ja, so wie
das Programm einer Wahlprogramm oder irgendwas vielleicht noch
die Parteiprogramme einer Partei, ja.
Und das ist passiert. Ja, und das haben Sie senden
Python genannt, und das hat eigentlich tituliert 19.
Geschrieben und hat die 20. Eigentlich aufgehoben für für
Chefin Self Guido von Rossum, der sollte eigentlich die
unterschreiben, hat er nie gemacht so, deswegen sind 19
geblieben. Und ich finds halt deswegen so
spannend, weil sich hier jemand. Der sehr viel Ahnung hat vom
System, der der, der auch genau so weitreichende Entscheidungen
treffen muss. Ja, der wurde gezwungen quasi
sich mal zu committen und ein paar Leitlinien herauszugeben,
jetzt für Python, ja wie Python funktioniert, was sie
entschieden haben, das Python soll und nicht soll, ja.
Das finde ich total wertvoll. Wenn das mal jemand tut, weil
wir stellen uns halt selber andauernd diese Fragen, ja, wie
entscheide ich was und ob jetzt eine Programmiersprache selber
natürlich das niedrigste Fluglevel so ja, aber es ist
genauso schlimm für Softwareentwickler jetzt ein
großes Software machen ja auch so für uns, ja wir machen ja
große Software, wir müssen ziemlich viele Entscheidungen
treffen. Und wenn ich mir dann aber zum
Beispiel so ein paar Leitplanken hinlege, wenn ich nämlich in
Frage komme, mache ich das ja. Wo ich mich dann einfach
orientiere, ich mich immer gleich orientiere.
Dann komme ich einfacher durchs Leben, sag ich mal.
Ja, und diese Leitplanken selber hinzudichten ist nicht gar nicht
so einfach und es gibt halt sehr clevere Leute in der Historie,
das schon mal gemacht haben und deswegen wollen wir den
angucken, weil langes Vorwort, aber ich will n bisschen die ne,
es gibt ja auch, es gibt ja Kurse für Management und
Entscheidungstreffen und so weiter noch und Löcher sind ja
voll damit, so ja und was machen die versuchen ja auch mal Art
Leitlinien Punkte so ne wie führe ich was ist dir wichtig
und so weiter das musst du dir nicht selber denken.
Zusammen mit Hilfe und so weiter für mich sind das auch
Leitplanken, die nicht nur das Programmieren wichtig sind.
Manchmal nehme ich halt auch, um Entscheidungen zu treffen.
Als Chef einer Firma, denn da ist es genauso kompliziert.
Ja, und da will ich aber kohärent irgendwie eigentlich
agieren, ja, und ich musste mir selber einen Satz hinlegen,
woran ich glaube. Das ist gut, was du jetzt sagst.
Und wenn wir gleich die die Leitprinzipien einmal
durchgehen, wird es auch den Zuhörern klarer, warum die zum
Großteil auch für andere Bereiche Relevanz haben.
Vielleicht schaffen wir 2 bis 3 Minuten pro Leitlinie oder sowas
durchzukommen. Ja genau, war nicht vorhanden
ist, haben wir noch philosophische Folgen hier, ja
OK, prima dann wie gesagt 90 Stück hat schon gesagt 20.
Ist noch von Guido Schaffer von Python zu füllen, hat also bis
heute nicht weiß, vielleicht kommt ja irgendwann mal also
Nummer 1 beautiful is better dann ugly schön ist besser als
hässlich oder? Ja, auf jeden Fall, es ist so
wahr, aber ich finde das ist es wert einfach nochmal
unterschreiben ne bezieht sich hier garantiert auf den auf den
Code ja. Denn man kann schon sagen, es
gibt schönen Code einer lesbaren Code Eleganz im im im
hinschreiben auch schöne Texte, die du lesen kannst.
Da manche finden zum Beispiel Thomas Mann sehr angenehm und
schön als Text zu lesen, weiß ich nicht.
Auf jeden Fall ist es ist ein wahrer Richtlinie, ja schreib
halt gleich schön kurz ja passt super zusammen mit der neuesten
Folge da wo man sich gut überlegen sollte braucht man
hier einen Kommentar und wenn man einen Kommentar braucht ist
dann der Code nicht vielleicht noch zu kompliziert schrägstrich
hässlich? Ja genau genau genau ist glaube
ich sogar weiter als nur jetzt den Text aber schön.
Es geht ne. Also es gibt halt einfach schöne
Lösungen, schöne elegante Konzepte und so weiter das ist
glaube ich sehr allgemein, deswegen auch der also einfach
Versuch einfach schön zu machen. Man muss diese ganzen Dinge so
einen Augenzwinkern nehmen, wie beißen, sich selber nimmt ja
die, also die Autoren sind auch lustige Leute, so ja die sind
immer ein bisschen Spaß dabei gehabt, ja das ist jetzt hier
nicht akademischer Zack zack, ja, ich glaube, dass wir ein
bisschen lustig und Spaß reinzubringen.
Explicit ist better dann implicit.
Das hattest du in der letzten Folge schon mal kurz, das ist
gar nicht so einfach. Punkt auch gleich an zweiter
Stelle, das heißt, hier versucht das nicht zu verstecken, dass
das Verhalten von der Sprache, sondern drückt explizit aus, was
du wirklich willst. Da steht so ein bisschen im
Konkurrenzkampf zu Convention over Configuration, wo man genau
das eigentlich das Gegenteil will, wo man sagt, OK, ich will
nicht alles explizit schreiben müssen, ich möchte, dass wenn
ich nix schreibe, die richtigen Defaults angewendet werden.
Ich weiß nicht, ob es wirklich im Widerspruch steht.
Ich glaube, man muss jetzt auf der Flughöhe gucken, wenn ich ne
Programmiersprache habe, wo ich ja wirklich auf der niedrigsten
Abstraktionsebene unterwegs bin um Sachen auszudrücken, da will
ich vielleicht tatsächlich nicht irgendwie zu viele Sachen dem
Zufall überlassen. Ja und irgendwelche impliziten
Sachen passieren, die irgendwie raus kriege, wenn ich die 40.
Dokumentationsseite lese, ja. Da will ich doch schon relativ
explizit sagen können, was genau jetzt passiert.
So, ja, ich glaube, das ist hiermit gemeint und ich würde
auch nicht meinen, dass jetzt irgendwie Peters oder g.
Von Rom oder irgendwas absprechen würde, dass
Convention over Configuration, was auf einer höheren Flugebene
stattfinden muss, also auf Framework Ebene und so weiter,
dass das ne gute Idee ist, ja, dass das finden die auch ne gute
Idee. Hier geht es darum, dass eine
Sprache explizit genug sein kann, um es auszudrücken.
Ja, ich nehme noch mal das Jura Beispiel vom letzten Mal.
Wenn ich zu wenig Wörter habe in meiner Grammatik, einer Sprache,
um wirklich festzulegen, was exakt ich meine und für Jura ist
das total wichtig, ja, weil es geht ja um Strafen und strafen,
was ich dann hab ich auch ein Problem ne also ich muss schon
in der Lage sein mit meiner Sprache sehr explizit sehr
eineindeutig auszudrücken was hier Phase ist.
So das meint das hier für ne Programmiersprache, ich glaube
das ist für Kommunikation auch unter Menschen ganz allgemein
total relevant, also jedes Gespräch, jede Beziehung
profitiert davon, wenn man explizit.
Und offen, transparent kommuniziert, anstatt Dinge
implizit auszudrücken. Und das dann immer von der
Interpretation des gegenüber abhängig ist.
Ja, was denn tatsächlich nachkommt?
Ja, ich glaube, es gibt es gibt, hier gibt es auch wieder cases,
ne, ich glaube es ist auch gesund, dass man, wenn du beim
Bier zusammensitzen und schnacken irgendwie abends im
Urlaub am Tisch, da wirst du auch ein Paar weglassen und dann
geht es darum, dass die das richtig verstehen, was du da
gerade sagst. Falls du es noch gerade sagen
kannst. Es gibt aber, wie gesagt, es
gibt also die anderen Sachen, wo du irgendwie vielleicht einen
Vertrag irgendwie verhandelt oder irgendwas, wo du es
brauchst, du explizit bist du ja prima, der nächste ist auch.
Irgendwie schön, einfach stimmig.
Es simple is better den komplex also einfach ist besser als
komplex. Genau so einfache Leitlinien,
ne. Also das erinnert quasi jemand
nochmal daran, Probleme nicht zu komplex werden zu lassen.
Ja find nimm doch erst mal die simpelste und naheliegendste
Lösung. Ja viele, viele
Softwareentwickler wünschen sich selber auch erwischt und dabei
an sich simple Nutzer umsetzungsprobleme zu komplex zu
denken, ja weil man vielleicht schon weiterdenkt wo der Nutzer,
also man muss ja nicht alles mit und weiterdenken, so machst dann
einfach erstmal simpel, ja. Könnt ihr Untertitel werden?
Jetzt wo ich gerade gesprochen habe, einfach komplex, ja oder
wir werden das auch ganz schön, also OK gut der Vierte jetzt,
der setzt an am dritten also komplex ist Better denn
complicated, also komplex ist dann doch wieder besser als
kompliziert, dafür müssen wir vielleicht nochmal kurz
auseinanderdividieren, was denn jetzt eigentlich komplex oder
kompliziert jeweils bedeutet, weil ich glaube das wird ja ganz
häufig in einen Topf geschmissen und man überhaupt nicht, das
sind ganz verschiedene Vokabeln für mich auch so, ja, also.
Also total wichtig, wenn man unseren Podcast verstehen will
an sich, der heißt der heißt einfach komplex und nicht
einfach kompliziert, ja. Also wenn was kompliziert ist,
dann habe ich es schlecht gemacht.
Wenn was komplex ist, dann kann ich nichts dagegen tun.
Ne, das ist das ist eine Urgewalt.
Ja, es gibt halt einfach Sachen, die sind komplex, ja so wie
Software und und und also. Diesen deswegen komplex, weil
sie, weil sie vielschichtig ist, weil sie, weil sie abstrakte
Probleme lösen, E zum Beispiel die Biologie unseres Körpers ist
komplex, ja, ist aber nicht kompliziert.
Ja, es ist komplex, weil weil ganz viele ineinandergreifen
muss, damit wir atmen sehen und leben können, ne.
Kompliziert wird es dann, wenn ich schreibe.
So, und deswegen haben wir diesen Podcast einfach komplex.
Also wir versuchen die Komplexität, die nehmen wir an,
die ist so, da kann man nichts machen, wir versuchen sie ganz
einfach darzustellen, ne, ich kann immer irgendwas kompliziert
machen, ne, aber das ist dann halt schlecht so.
Also im besten Fall ist es nicht komplex, sondern ist so
glasklar, schlechtesten falle ist aber komplex, weil das
Problem komplex ist, aber es darf nie kompliziert sein und
wenn ich irgendwas kompliziert mache, dann habe ich selber
verbockt so das meint das so ja also schreib wenn du komplexe
Probleme hast, schreib das so einfach hin, dass maximal
komplex bleibt, aber nie kompliziert wird.
Sau gute Zusammenfassung. Und wenn jemand beim zuhören
hier das Gefühl hat, dass wir das dann doch zu kompliziert
ist, dann lass uns wissen, dann versuchen wir es aufzulösen, ja.
Du, ich hab noch einen Nachtrag, hab ich ganz vergessen von
Picard. Völlig richtig ist n Facebook
damit noch Facebook heute meta Entwicklungsthemen was pytorch
also dieses KI Framework entwickelt hat ja prima genau
prima Nummer 5. Ja da ist mir nicht klar direkt
zum Lesen was das genau bedeutet.
Flat is better than also flach ist besser als verschachtelt
oder sowas. Ja genau hier haben wir das
Thema, hier können wir auch beim letzten Mal aufgreifen, da ging
es um die Datenstrukturen also denke die Datenstrukturen erst
und dann denkt über den Code nach so.
Also die Daten sind wichtig. Bei Datenstrukturen hatten wir
auch eine Folge, haben wir die Möglichkeit auch wieder
verschiedene auszudrücken. Ja, wir können, wir können
Sachen ja ineinander schachteln, wir haben gelernt, es gibt
Objekte mit Key Value und dann kann ich auch Objekte in Objekte
Schachteln, also wenn zu meinem Key Value wieder ein Objekt ist,
dann hab ich wieder ebene Key values und dann kann ich wieder
ne Values machen und so weiter. Ähm, das kann ich beliebig
fortführen in der Software, da gibt es keine Grenzen,
eigentlich ja und und und dieser dieser Lebensspruch, der ist
krass so, ja weil der hilft sich weiter.
Ja ich, ich kann einfach Daten verschiedene Organisieren und
entweder organisiere ich sie mehr auf einem auf einem Level,
dann sind meine Kennwörter schon länger und drücken mehr aus oder
ich organisiere sie in, ich organisiere hierarchisch.
Man kann sich vorstellen wie der Strukturen ne hat, jeder hat das
Problem ja Google Drive, onedrive oder irgendwas, ich
muss ordnerstrukturen anlegen ja mach ich jetzt also ganz viele
Ordner die immer tiefer werden habe ich.
Habe ich ein riesiges Hierarchiesystem, wo ich nach
dem 15. Ordner finde.
Hier ist das Customer PDF was ich suche ja oder bin ich eher
flach unterwegs und hab wenig Hierarchien?
Ne und hier sagt ganz klar fürs Coding für Datenstrukturen
bleibt flach ja geht nicht so tief runter in den Hierarchien
des Macht kriegst Kopfschmerzen ne.
Und total war. Ich kann nicht, ich kann nicht
sagen warum. Es ergibt sich einfach, dass
sich einfach viel Arbeit viel einfacher nachdenken und
arbeiten lässt. Wenn ich meine
Hierarchiestrukturen flacher lasse, als dass ich sie zutiefst
zueinander. Wenn ich auch totaler Fan beim
Dateisystem und sowas wie Google Drive einfach die Suche zu
nutzen aber alles Thema ist jetzt nicht so viel mit dem zu
tun, aber OK hab ich verstanden dann nochmal 6 spars ist better
Dance also weiter ist besser als enger oder dichter so in der
freien Übersetzung wieder genau ich also also Spaß und dann muss
ich immer also hier muss ich auch interpretiert ja gerade
sowieso alles wie ich denke ja keine Ahnung ob ich jetzt hier
den richtigen Ton treffen sich Peter irgendwie überlebt hat
also bei Spaß und denk ich an Mathematik.
Vielleicht die nicht an Matrizen.
Es gibt es gibt sogenannte Base Matrizen und Dennis Matrizen,
also entweder sind die. Übrigens das von der Mathematik.
Ich Hülle ja und entweder fühle ich voll oder ich lass ein
bisschen dünner und drücke n bisschen dünner aus.
Hier ist gesagt, so versuchs halt irgendwie dünner oder
einfacher auszudrücken und macht die Informationen nicht so
dicht. Muss sagen, habe ich so ein
bisschen Schwierigkeiten zu interpretieren.
Ich würde, sagen wir schnell zum nächsten.
Gerade freue ich mich über Kopf und Kragen, reden hier völlig
fair, hat total gut readability Counts ist die Nummer 7,
Lesbarkeit zählt ja. Stimmt nix da, also geht im Code
wieder darum, dass ich einfach das ganze, wenn nicht der
Experte laut deiner Meinung für die entsprechende
Programmiersprache oder die Expertin, dann muss ich in oder
dann bin ich in der Lage diese zu lesen, ohne dass ich noch
Erklärungen für Kommentare nicht richtig ich kurz bevor du den
nächsten vorliest gleich die 2 nächsten bitte vor ich sag doch
auswendig nein Spaß. Muss ich lernen, um Bayer zu
starten? Ne OK genau 10 Gebote, da ist ne
die neuen 10 Gebote gut nochmal 8 special cases and special love
to break the Rules und all Dow practically Beats Purity also
soll ich es zusammen fassen wir zusammen ich glaube es ist auch
ein bisschen Lyrik oder also jetzt nicht gedacht so das ganze
Ding, wir machen es ja auch so ein bisschen jetzt One by One es
liest sich glaube ich wenn alles durch ist aber ich versuche es
mal also Spezialfälle sind nicht speziell genug um die Regeln zu
brechen. Dennoch, also Praktikabilität,
schlägt die Einfachheit ja oder die Reinheit, Reinheit, Purity
Reinheit richtig, ja, OK. Ja, voll gut.
Also ich mag, ich mag das, weil. Hier hat es wieder was mit der,
mit der auch mit einer Weisheit zu tun, die wir das letzte Mal
hatten, mit Consistency. Ja, also ich hab mir ein
gewisses Regelwerk angewöhnt, wie ich was mache.
Mal ganz abstrakt gesprochen und es sollte nicht so viele
Ausnahmen von der Regel geben. Ja oder von den Regeln ne.
Allerdings ist wieder was zu tun mit fertigwerden und 100% und so
weiter ich glaube hier geht es um 100%.
Ja, also klar kann ich mir irgendwie überlegen und dann
sollte ich auch keine Ausnahmen dazu machen, ne?
Aber das Regelwerk wird nicht perfekt sein und Ausnahmen
müssen halt dann passieren, wenn ich nicht schnell genug im
Gehirn bin, um mir was auszudenken, was die Regeln
nicht bricht. Trotzdem Stability ist also das
baut aufeinander auf, ne alle die alle die Sätze die vorher
schon gesprochen werden sind ja auch wahr ja also wenn ich nicht
schaffe in Counts und beautiful und so weiter was auszudrücken.
Was nicht die Regeln bricht, dann brechen sie lieber ja.
Denn Practically ja, das ist wichtig, ja, wollen wir machen
das ja nicht darum, dass wir uns selbst beweihräuchern und
irgendwie tolles Stück Software. Also es gibt, das könnte man
machen, ja, es gibt Leute, die lesen Partituren von Mozart und
brauchen gar nicht hören und haben Spaß daran, dass zu sehen,
wie toll das aussieht, so, ja, ich habe auch Spaß daran, sehr,
sehr clean Code zu lesen, einfach zu lesen habe ich
brauche, ist mir scheiß egal, was macht so, ja, ich freue mich
ja, dass man. Dass man einfach so elegantes
lesen darf, so hast wie Buch H is ja nich so, aber was das hier
sagt ist es geht ja schon um eine Anwendung für den Nutzer am
Ende des Tages. So, ja dann bleib bitte bei 80%
machst, dann machst du halt eine Ausnahme und dafür wirst du aber
fertig. Ja und es wird nicht erst in 10
Jahren fertig und ist dann total beautiful, aber nur für dich,
ja. Ich finde es faszinierend, dass
es diese Art, ja die soll diesen jetzt hier für Python, oder es
gibt ja auch so Manifesto s für verschiedene Themen oder sowas
in der Softwareentwicklung, dass sich da so eine Art und Weise
philosophische Gedanken macht, Beyrich vielleicht Dinge
abschaut et cetera. Ich glaube, das hast du immer
bei diesen Themen, wo so ein bisschen nerdig, ich glaube, die
Physiker sind ja auch so ne Partei, die da, die machen ja
auch so krasse Sachen, Mathematik und so weiter, und
dann stoßen an Grenzen und müssen ständig irgendwas
entscheiden, nachdenken. Die haben das ja auch so ne, die
haben sich ja auch sehr gerne sehr philosophisch unterwegs
coole Bücher von den von den Physikern, die sehr
philosophisch sind, ja auch gut so, ich denke mal 11 und
schuldigung, 10 und 11 sollte ich wieder zusammenbringen, die
gehören wieder zusammen und ich hatte auch schon
Interpretationen, also 10 Aros, shout never pass silently und 11
unless explicitly silenced, also Fehler sollten niemals still,
vorübergehend oder oder auftreten, ohne sich bemerkbar
zu machen. Es sei denn, man möchte das
explizit, dass diese nicht laut geben, sag ich jetzt mal.
Ich muss zuerst dran denken beim 10.
Eine offene Fehlerkultur, ja. Also die ja auch irgendwie ich
Management geprägt wird. Also lieber viele ansprechen,
Fingerpointing und aus den Fehlern lernen und beim nächsten
Mal besser machen. Aber ich hab das Gefühl, es geht
eher darum, dass man irgendwie ne, dass man mitbekommt, wenn
was schief gelaufen ist. Perfekt, genau, du hast ja fast
ja. Ja, das ist das ist, ich weiß
nicht, ob unsere Zuhörer wissen, aber es kann ja total viel
schiefgehen. Software wenn also wir haben ja
immer, wir coden, ja, das nennt man dann ja Coding Times, aber
wenn die Software läuft, Runtime.
Das sind ja ziemlich viele Unbekannte.
Ja, also irgendein Nutzer eröffneten File System sollen
File hochladen, ja in dem Fall ist nur Kauderwelsch kaputt von
innen drin das PDF oder irgendwas ja und dann sollte ich
hoffe dass einlesen und kommt völlig durcheinander und dann
passieren Fehler. Da gibt es 1000, Beispiele, das
und was das hier sagt, ist, wenn was schief geht und das kann 2
Sachen liegen. Entweder du hast halt einfach
verkackt und nicht geplant und eine Software ist Buggy.
Oder du kriegst ja was rein, was völlig unerwartet ist.
So, ich erinnere mich gerade an das Beispiel von, wir hatten mal
ne Folge über Sicherheit mit Klima, Timo genau und der hatte
gesagt, so hier eben wenn auf der Autobahn ein Nummernschild
Detektor ist so ja und jemand hat sich irgendwie n krasses
Nummernschild selber geschrieben, QR Code drauf steht
so ja dann ist das auf jeden Fall irgendwie n Fehler
wahrscheinlich produziert in der Software und im schlimmsten
Falle und jetzt kommt ja im schlimmsten Falle gibt es gar
keinen Fehler sondern wird Silently eingebaut und damit ist
ein Sicherheitsprobleme. Was hier sagt ist, sieht zu,
dass wenn etwas Unerwartetes passiert, es auch wirklich ein
Fehler triggert. Ja, denn in der Software gibt es
ein eigenes System, fast banal, Programmiersprache, Exceptions.
Also es gibt wirklich das Objekt Fehler ja und jetzt kann auch
durchgereicht werden und so weiter und sofort und dann
behandeln oder auch nicht. Ja man kann sagen Shop da ich ja
weiß ich du einer den erwarte ich hier den du brauchst hier
nicht ich behandle dich extra ja.
Es zum Beispiel jetzt nochmal das der Fall Nummernschilder
eingelesen ja und ich erkenne Text der kein Nummernschild ist
und fange diesen Fehler ja und sage OK den zählst du mal als
hier markierst du mal dieses Auto, dann nimmst du die Farbe
auf oder was weiß ich kann ein Fahrer der will dich irgendwie
hier stimmt was nicht so ja. Und wenn man schlecht
programmiert oder ein bisschen fahrig ist, dann kann es schon
sein, dass ein Fehler entsteht. Nirgendwo.
Der löst sich irgendwo Nirvana auf und kriegst nie.
Es wird nur gelobt und nichts so.
Und dann habe ich ein Problem haben Sicherheitsproblem und
auch n ein Anwendungsproblem, weil das funktioniert nicht so
wie man denkt und keiner weiß wie man's debuggen soll, ja
nichts aufgetaucht ist. Also auch sehr wichtig.
Ja stehst du deinen Fehlern könnte man auch sagen auf dem
Großen auf dem großen Platz und lass dich bloß immer alle
Hochpoppen und mal irgendwo hin soll auch als Nutzer oder jetzt
auch im Vertrieb von Surface ist das Nervigste für Anwender und
Anwenderinnen wenn die halt irgendwas nicht funktioniert und
man hat aber gar keine Ahnung warum das denn jetzt nicht
funktioniert. Wie man das erwartet hätte?
Ja, das ist immer besser, da dann Transparenz auch in der
Software zu haben und sagen, hier ging jetzt was schief, dann
kann man darüber sprechen, ich wollte einfach etwas ins Leere
laufen zu lassen, ne du musst die n bisschen die verständlich
sind, aber zum Beispiel ein ganz einfacher Klassiker ne wenn du
sagst Anwendung h die Internetverbindung braucht ja
und du hast halt der Nutzer ist halt irgendwo und hat kein
Internet und macht die auf und es geht einfach nicht das ist
halt nicht schön so für den wer weiß nicht was los ist.
Ja dabei ist total trivialer Fehler hat kein Internet also
dann hilft es auch wenn die Anwendung einfach dann so n.
Mindestens OP so Hey du bist offline so ja ich brauche
Internet sonst kann ich nicht funktionieren als wir neulich
diese diese andere aufnahmeplattform für den
Podcast hier benutzt haben waren wir beide total genervt weil es
hat gehakt das Video und es gab eine Latenz und wir wussten aber
nicht ist das jetzt beeinträchtigt das auch die die
die die die aufnehmen ganz genau völlig Banane ja also wir hatten
einfach keine Ahnung und dann haben wir halt wieder
ausgestellt weil das Programm gesagt hier Video ist
beeinträchtigt Aufnahme läuft hätte vielleicht weitergemacht
so ja also wenn dieser Fehler nicht einfach silently
irgendwie. Nicht behandelt werden, aber wir
wurden halt einfach nicht in Kenntnis gesetzt.
So, ja dann wirst du kennst. Ja, es gibt hier ein Fehler,
dein Video ist Mist, aber Aufnahme läuft.
Kannst du anfangen? Hast recht.
Dann kommen wir zur Nummer 12 von von 19 also geht gut voran
in the Face of ambiguity Review, the Temptation to gets also im
Angesicht von von Mehrdeutigkeit, Widerstehe der
Versuchung zu raten, lass das Bauchgefühl weg oder was könnte
man daraus ziehen? Nee, das heißt, das glaub ich
nicht. Das passt so explizit und
implizit. Ja, im Code willst du explizite
Wege haben, wir die Software sich bewegt.
Ja, Mehrdeutigkeit ist ganz furchtbar im Code, ja wenn
irgendwas wenn irgendwas nicht ganz glasklar ist und es könnte
2 Wege gehen wie du jetzt weiter gehst, dann dann versucht das
nicht zu verraten vom User ja weil jetzt muss nicht passen so
ja versucht das System so zu designen, dass es gar nicht erst
zu mehrdeutigen Würdigkeiten kommt.
Ja, das heißt, das heißt also, wenn das nicht ganz klar ist,
klar ist im Software ein bisschen ja.
Wenn die einen, wenn die Eingabe des Felder nicht so designt
sind, dass du jetzt nicht ganz genau weißt, ist es der oder der
nicht oder irgendsowas. Dann sagen das Eingabefeld neu
Apparat nicht rum, dann nicht irgendwie den ersten A oder
irgendsowas und denke ja könnte schon passen.
So, das ist jetzt Zuhörern einer Software ist so ja ich noch ein
Beispiel, das immer so vorkommt. Du hast zum Beispiel.
Du hast ein Datenbank und basteln Abfrage und erwartet
eigentlich, dass nur genau einen Eintrag in der Datenbank
existiert. Zu dieser Abfrage, zum Beispiel
zu einem User. Ja du erwartest ich quasi einen
finden sollten nur einen geben, ne.
Es könnte aber sein, es gibt irgendeinen Fehler oder so.
Und dann gibt es noch zweimal. Also du machst eine Abfrage und
kommt 2. Zeilen zurück aus der Datenbank,
nicht eine ja, und wenn das so ist, ja dann nicht einfach den
ersten. So wird schon der Richtige sein,
so ja, denn da 2 zurückkommen und erwartest aber nur einen,
dann Rat nicht rum wenn ich das richtige ist, dann musst du
nochmal gucken warum kommen jetzt zurück, das sollte nicht
so sein, ne. Also hör auf, dass also fix das
so ja heißt das irgendwie, es darf nicht mehr deutlich werden
in deinem Codes und bist du irgendwie so von gilt das jetzt
mehr für die Coding Time hast du gesagt oder für die Runtime?
Also muss ich in der Runtime eines Programms dann auch dafür
sorgen, dass wenn der Fall auftritt, dass dann da irgendwo
ne Lösung würde ich sagen ganz klar Coding Timecoding Time
macht, dann macht das ordentlich so dein Ding und mit den Tests
dann gemeinsam, dass man dann rausfindet und übrigens auch
wieder so ein Satz, den kannst du ja auch in anderen Bereichen
ist der war ja also. Also ich will auch mit
Menschlichkeit oder irgendwas. Ja, wenn du zum Beispiel haben
mitarbeitergespräche irgendwas der Mitarbeiter sagt mir
irgendwie sagt mir irgendwas ja und ich habe vielleicht nicht
verstanden und so, das könnt ihr jetzt so meinen, ne trau mich
aber nicht noch mal nachzufragen was da wirklich meint ja dann
speichere ich mir irgendeine Interpretation von dem was
vielleicht hab in meinem Kopf war als Chef, das ist ziemlich
schlecht, vielleicht ja doch nicht so, ja.
Also wenn was wichtig ist und ich habe es nicht verstanden,
dann frag halt. Hakt es ab.
So ja frag halt nochmal nach so ja so wenn ich glaube ganz viel
Kommunikationsprobleme sind dadurch, dass man zu schüchtern
ist oder sowas, weil es einfach nicht macht, ja man redet halt
was der andere gemeint haben könnte, ja.
Aber raten ist vielleicht das Richtige.
So an also. Bisher ist nicht an jeder
Stelle, wenn es drauf ankommt, dann will ich nicht raten.
Ja dann frag ich nochmal nach, dann explizit so und dann hat es
wirklich wirklich richtig oder falsch zu tun, während ein
Bauchgefühl was ich anfangs sagte oftmals also es oftmals
mehrere richtige Weg einfacher. Ich muss mich dann entscheiden,
dass das nicht glaube ich verstanden ja prima.
Gut, ich denke mal nochmal 13 und 14 gehören auch wieder
zusammen. Bitte jetzt wirds schwierig ja
hier wieder auf Englisch OK bisschen Musik anmachen, das ist
so ein bisschen Hintergrund ist machen wir Sousa haben ja wenn
ich das nicht machen muss. Gut Nummer 13 und 14 gehören
auch wieder zusammen. So wie es aussieht.
Und ich versuche es mal ohne den Dreher, sonst korrigiere mich
gerne. Burkhard ja, one and probably
only one way to do it in 14 all so that way may not be the first
unless your dutch so übersetzt jetzt nicht frei übersetzt.
Ja, wir haben tatsächlich auch Übersetzung, die ich vorher
nicht benutzt, es sollte einen und vorzugsweise nur einen
offensichtlichen Weg geben, es zu tun.
Auch wenn dieser Weg anfangs vielleicht nicht offensichtlich
ist, es sei denn, man ist Niederländer.
OK, ich, ich vermute irgendwo zu tun.
Ja du hast richtig vermutet, ich hab ja gesagt, du musst machen,
angucken ist natürlich hier, ist natürlich ein Augenzwinkern so
genau Guido Voss nieder und kommt als Autor der Frage ist
für ihn natürlich am offensichtlichsten wie es zu
sein hat und seinen Schein soll deswegen das ne also auch wenn
dieser vielleicht sie ist, dann sei immer wieder ein Teil dann
nochmal kurz ich hab zwar gelesen aber nicht komplett
erfasst habe. Ja, pass auf.
Genau das hat natürlich noch mehr Tiefgang als nur über
diesen als nur den Guido von Rossum hier irgendwie aufs Korn
zu nehmen. Ich glaube, es heißt so viel wie
wenn du deinen, wenn du deine dein System, also hier, worum
geht es hier eigentlich? Geht die Programmiersprache
Python die in sich schlüssigen, schlüssiges Ding sein soll,
benutzt werden, ne. Das ist ja auch wahr für
Software, die benutzt werden soll von jemand anders.
Also ein Framework baust oder irgendwas.
Ja also ich, ich nehme das für uns total wahr und bar weil wir
irgendeine Local Plattform machen wollen.
Mithilfe derer andere Leute Anwendungen schaffen.
Genau das heißt, wir machen, wir machen, wir machen einen
Werkzeugkasten, der von anderen benutzt werden müssen muss.
Ja, und jetzt beim Werkzeugkasten sollte es
offensichtlich sein, welches Werkzeug ich für welches Problem
in die Hand nehme, aber das meint das so ja.
Ähm, und wenn du schön designt hast.
Und alles wieder Bill ist und alles ne einen gewissen Sinn und
Logik interne ergibt, dann wird das auch irgendwie in sich
schlüssig. Ja und wenn du dann ein Problem
lösen willst das nächste Problem, du hast schon 20
gelöst, sonst kommt das einzige Problem.
Dann wird, wenn das System gut gemacht hast, ist total klar,
wie du es zu tun hast. Auch mit den Werkzeugen, die du
schon geschlafen hast. Ja, findest du halt.
Du Erfindest hat keine Werkzeuge, die immer wieder das
Gleiche machen oder leicht anders sogar, denn erfindest du
quasi eine Lösung, wo du den 2, die du schon gut designt 2
Werkzeuge nehmen kannst. Und das dritte Problem zu lösen
so. Das heißt, das mehr oder weniger
ja und wenn und wenn, wenn es zu, wenn es zu fragwürdig ist
und wenn das Tool zu viel Mittel anbietet, um ein gleiches
Problem lösen zu können und das total fragwürdig ist und nicht
weißt welche soll ich nehmen, ist das besser oder das oder das
ist nicht so gut, das lässt sich nie vermeiden, dass total
schwierig, ja, es gibt immer mehrere Arten und weisen was zu
zu lösen, aber wenn wir quasi deinen.
Ein Framework, irgendwie nen Klaren, so eine Art Denkanstoß
schon gibt wie du es zu tun hast, wenn es in sich irgendwie
schlüssig ist, dann hast du es gut gemacht, sogar das heißt das
was ist denn was ist denn mit powerpoint oder Google Slides
oder pitch.com was auch immer man verwendet.
Du kannst immer textfelder machen.
Und über eine Form legen, um irgendwas in eine Form
reinzuschreiben. Oder du kannst aber direkt in
die Form reinschreiben. Ja nervt mich auch total, weiß
ich aber nicht wollen ist ein Beispiel dafür, dass das nicht
gelungen ist. So, ja, es ist immer wieder in
jeder, es gibt schlimme Probleme auf der Welt, schon klar, aber
es ist es ist in jeder powerpoint meist wild gemischt,
dazwischen textfeldern und Formen eingeschrieben, das gute
Beispiel ja und das ist schlimm vielleicht unter die powerpoint
Jungs Entwickler vielleicht deswegen Schmerzen weil sie
jetzt irgendwas darauf aufbaut, wenn zum Beispiel was ich
automatisch irgendwelche Widgets.
Der sortiert oder irgendwie schon ausrichten möchtest,
kannst du nicht so einfach wieder gucken.
Ist jetzt alleine oder n komischen drin, irgendwas macht
überhaupt keinen Sinn, dass diese Möglichkeiten gibt.
Und wenn es keinen Sinn macht, lass weg, ja.
Wenn man jetzt aber der Guido wäre, dann hätte der eine klare
Meinung, würde sagen, ja, das ist schief gelaufen, ist
historisch gewachsen und muss immer in der Form drin sein.
So ist natürlich gemeint, so, ja.
Aber das ist natürlich, wenn du nicht mit dem Auto von dem Tool
sprichst und hast du nicht gerade am Ärmel und fragst du,
was muss ich machen, dann ja. Die Weisheit ist natürlich,
vielleicht gibt es eine Weisheit dahinter und the way to do.
Aber wenn du nicht, wenn du nicht da ist, dann ist es nicht
abwärts, ja. 15 und 16 gehören wieder zusammen.
Nummer 15 wäre now ist besser never und nummer 16 wäre also
never is often better than right now.
Also jetzt ist besser als nie, das hat man auch schon mal
gehört, das wäre, obwohl niemals manchmal besser ist als jetzt
sofort ja, also über haste nichts überhastetes
wahrscheinlich das zweite und das Erste ist leg los, ja.
Ja, voll. Es ist auch das trifft ja auch
so einen wunden Punkt, so ne für alles Projektmanagement mäßige.
So du hast halt n zum Beispiel ein Feature Quest hast du lösen
sollst. Und zwar du musst.
Das bringt ja nichts anderes. Und dann implementierst du,
merkst, verdammt ich das richtig gut lösen will, dann muss ich
hier und hier auch noch mal L faktorisieren ich muss nicht
anfassen, ja, macht auch Sinn so, ja.
Hab ich jetzt aber keine Zeit zu, ja.
Und ich glaube hier hier sagt es aus so viel wie OK, du hast
schon fast keine Zeit das Feature selber zu machen.
Und ja, du hast erkannt, dass du jetzt hier eigentlich noch was
holen müsstest und sauber einzubauen tuts nicht so ja,
also weil wenn du das jetzt tust, dann wird es nur
schrecklich. Du hast die Tests dafür, nicht
die Zeit die dafür zu schreiben und so weiter das geht halt
irgendwie ja und die Gefahr besteht natürlich, dass wenn du
es heute nicht tust, du wirst nie tun wirst, weil was
passiert, wenn das fertig ist, der nächste, das nächste
Feature, du bist ja im Hamsterrad so ja auch oft, ja
nicht nur wenn wir im Leben oft, wenn wir gerade über Firmen
sind, im Hamsterrad da sind, ständig etwas Neues, so, ja wann
hast du schon die Zeit sagen, so jetzt hab ich irgendwie 3
Stunden Zeit, mal gucken was mache ich denn jetzt lustiges so
ja da kannst du hingehen und wenn ich dir aufgeschrieben hast
kannst du nochmal das gerade schön fixen so ja wenn du noch
auf dem Zettel hast ja aber das heißt das so ja also.
Also bevor du das ganz kurz hin Donnerstag, lass es weg und wenn
es dann halt gar nicht gibt, dann gibt es halt nicht so Pech
gehabt. Ja, es ist ein Stück weit auch
ne priorisierungs Thema was da einfach angesprochen wird.
Auf jeden Fall wird darüber aus was du machen willst.
Priorisierung und das ist dann halt wenn du wenn du Sachen
machst die potenziell lange folgen nach sich ziehen können
ne wenn du musst dir überlegen, also die Grundlage dessen was
wir alles besprechen ist ist an was zu werkeln, was lange lebt
ja es geht hier nicht um irgendein Wegwerfprodukt,
sondern deswegen passt glaube ich die Analogie zu einem zu
einer Betriebsführung, ja. Also wenn du betriebliche
Entscheidungen machst und willst eigentlich den Betrieb noch
irgendwie 20 Jahre irgendwie in der Welt ist.
Dann hat er jede Entscheidung eine Konsequenz.
Ja, und hier geht es um die Konsequenzen, ja, also bevor du
warst in Eile schnell machst, was eigentlich wichtig wäre zu
tun und richtig wäre zu tun, was du dann aber gar nicht umsetzen
kannst. Die Konsequenzen sind schlimmer
als wenn, dann lieber doch nicht so, ja weil vorher lief ja auch
irgendwie schon ne. Das hilft mir halt ganz oft zu
Lebensweisheiten. Ja manchmal.
Man kennt das ja selber, du bist irgendwie, du hast schon das P
im Auge, hast du am besten nicht, ja, lernt man ja auch das
nicht zu bekommen, aber du bist halt irgendwie schon gestresst,
weil du weil einfach viel auf dem Tisch ist und du musst
fertig machen, dann siehst du OK cool das wenn ich das jetzt hier
noch ist, richtig elegant merkst, aber ich habe eigentlich
keine Zeit und jetzt bist du innerlich in so einem Konflikt,
was machst du denn jetzt entscheidest du dich ja, sagst
du jetzt dem Kunden auch nix oder wie?
Ja und dann nochmal die durchlesen und dann weiß man
eigentlich was machen muss aber sag mal welches P hat man da im
Auge. Party des Panik P.
Ach so, alles klar. Gut das Pause B im Auge haben,
dann ganz cool wenn richtig Stress hast du Pause so viel
besser als Panik zu haben das stimmt mal durchatmen, drüber
nachdenken genau. So 17 und 18 gehen wieder hand
in Hand. Na, wobei nicht unbedingt, ja
nicht so wie die anderen, aber ganz schön zusammen machen wir
mal zusammen würde ich sagen, oder was würdest du sagen?
Du bist mir egal, mach du, entscheide f die Implementation
des Hardware explain a bad idea. Und 18 wäre m implementation is
easy to explain, it may be a good idea.
Ja so also ich wieder auf meine Übersetzung, speziell wenn die
Umsetzung schwer zu erklären ist.
Oder die Implementierung würde ich sagen, die Implementierung
schwer zu erklären ist, ist das eine schlechte Idee, wenn die
Implementierung einfach zu erklären ist, kann sie eine gute
Idee sein. Ja, ja, ich liebe, ich liebe
auch diese 2 Punkte und das habe ich schon oft gehört.
Das ist ja auch ein bisschen die im Podcast hier haben.
Es kann ja was Komplexes sein, aber wenn ich nicht in der Lage
bin ist dir zu erklären, relativ einfach.
Dann ist irgendwie, dann ist eine schlechte Idee.
Also ganz oft haben wir ein neues Feature und ich will dir
das erklären, Gerrit und wenn du das sofort verstanden hast, was
er gemacht hat und wie ich es gemacht hab.
Dann könnte es sein, dass es tatsächlich n Maya könnte sein.
Das ist vielleicht eine gute Idee ist.
So muss man nicht nur wenn erklären kann und erstmal auf
den ersten Blick total offensichtlich erscheint, heißt
es noch nicht, dass man vielleicht alle Randbedingungen,
alle Nebenwirkungen und Risiken davon gedacht hat, darf auch
nicht so schnell sein, dass alles gut zu bestellen und
sofort Release zu knallen, ja, das heißt das Maybe.
Aber wenn ich dir schon gar nicht erklären kann, was ich da
gemacht hab, ja ich schon selber mich verhaspel, indem beim beim
Erkläre versuch dessen was ich da getan habe ist auf jeden Fall
auf jeden Fall wert wieder zu löschen.
So dann hab ich irgendwie nichts gemacht oder irgendwas am
nächsten morgen ich s gelöst aber es war 11:30 Uhr, also
nicht 11:30 Uhr morgens sondern PM.
Ja dann muss man dazu stehen sagen kommt das nochmal erst gar
nichts oder jetzt hast du jetzt hast du mich als Beispiel
genommen im überhaupt jetzt hab ich schon groben Plan von von
unserer Software zumindest was die tut was sie kann.
Vielleicht auch zum Teil, wie Dinge implementiert sind.
Ja, aber sehr begrenzt sollte man dann aber jemanden wie mir
erklären können oder dann doch lieber jemanden, der vom Fach
ist. Nee, auch v hier tatsächlich das
Beispiel hakt n bisschen an der Stelle genau, es geht hier, es
geht hier um die Erklärung unter gleichen ja, also ich würde auch
das, also hier geht es natürlich Implementation Software, also
wenn ich im anderen Softwareentwickler nicht
erklären kann, was gab es auf jeden Fall misst ich glaube,
dass man das auch ein Level höher ziehen kann, egal ne wenn
ich wenn ich irgendwas jemandem nicht erklären kann als wenn
sich Wissenschaftler unterhalten und ich kann den.
Die Untersuchungen oder die das Experiment, was ich da gemacht
habe, dem anderen nicht erklären und das versteht, dann war es
ein mistiges Experiment. Der andere müsste das potenziell
verstehen können. Ja, die müssen schon sein, sag
ich mal, was den Inhalt der Erklärung angeht, so das ist,
das heißt schon. Es geht auch um Produkte und
sollte auf dieses, vielleicht kann man vielleicht auch ein
Stück weit übertragen, ne total Wahl für alle möglichen
Bereiche. Genau nicht, kriegst dein
Produkt oder den den Nutzen eines Produkts prägnant und gut
zu erklären, dann muss vielleicht mal ein Produkt
arbeiten, ne genau krasser Weise ist wieviel Startups gibt, sie
schaffen es nicht irgendwie ihr Produkt zu erklären, man
sogenannten Elevator Pitch ja also du sagst du hast 3 Sätze,
sag mal machst du ja und es nicht schaffst, dann hast du
irgendwie, dann musst du dich nochmal machen, dann ist es
nicht so gut so last but not least und 19 sind schon
angelangt. Namesspaces A One hunting great
idea, let's do more of those also Namensräume sind eine
großartige Idee, lasst uns mehr davon machen.
Ja, ja, das ist jetzt ja, das ist total nervig, und das ist
als letztes Ding noch mal so, ich glaube, das war es, glaube
ich, Tim Peters mit Mitgabe an an an dem, was er gerne hätte.
Namensräume Namespaces ist ein Konzept der Software.
In vielen Programmiersprachen gibt es das sehr ausgeprägt, zum
Beispiel E Plus. Und das führt dazu, dass du,
wenn du Namen vergibst, es geht ja auch alles viel um Benamung
in der Software variablennamen Funktionen haben und so weiter
und die Namen lesbar machen wieder ja und und kurz ja wenn
es zu lang ist auch nicht lesbar und so weiter und dann gibt es
das Konzept der Namensräume, dann kannst du ganz oben, das
ist der Namensraum, Users oder irgendsowas ja und darunter gibt
es Variablen und Funktionen, die kannst du dann irgendwie nennen,
die sind alle quasi im Kontext users.
Ja da musst du nicht immer schreiben.
User unterstrich Authenticate oder User was weiß ich.
Ja, was du müsstest, wenn du nicht diesen Kontext gibst.
Und ist das nicht so ausgeprägt mit dem Namen?
Jetzt nicht gerade, was der aktuelle Stand ist so, aber es
ist aber eine gute Idee, wenn du, wenn du wenn du lesbaren Q
schreiben willst, dann ist es nicht schlimm irgendwie Namen
festzulegen, oben und unten in dieser Bubble bewegst du dich
dann halt in Sams Bilder, die kannst du auch wieder
verschachteln. Übrigens wir namentlicher flach,
ja vielleicht besser geht wir sind durch darf ich eine Sache
machen weil es mir irgendwie herzlichen darf ich einmal
komplett vorlesen im August irgendwie wirklich schön ne ja
absolut ich will dich nicht aufhalten o cool dann mach ich
das. Und dann vielleicht auch ich
weiß gar nicht, wieviel Minuten wieder gequatscht haben wir von
mir aus den Sack zu, es sei denn du hast noch fragen, irgendwie,
aber nee, dann sollen das die letzten Worte sein, ich sage
schon mal Tschüss und Burkhard wird euch nochmal die. 19
Grundprinzipien der Softwareentwicklung unter diesen
auf Python vortragen. Ja, ich sag dann auch schon mal
vielen Dank fürs Zuhören und wir spielen dann unser Auto da rein,
während ich vorlese. Ich stelle mir gerade sehr cool
vor, ich nehme mal schwarzer weg.
Wir haben eine morgendliche Aufnahme, dass meine Stimme
nicht nächstes mal abends erst wird.
OK, aber egal, es geht los. Beautiful ist better than ugly,
explicit is better than implicit.
Simple ist besser dann complex complex is better dann
complicated. Flat ist bei dir ned spars is
better dance rehability counts. Special Cases and Special love
break the rules all so practically Beats Purity.
Aros Schütz Never Pass silently unless explicitly silenced.
In the face of ambiguity Review tentation Tues.
Dash one and only one obvious way to do it all that way not p
obvious at first unless your dutch now is better than never.
Olson never is often better than right now.
Ist der Implementation is hard explained the bad idea if the
implementation is easy to explain, it may be a good idea
namespaces one hundred idea it's two of those.
Vielen Dank fürs Zuhören dieser Folge von einfach komplex.
Die Folge gefallen? Dann lass uns doch ne gute
Bewertung da oder Teile die Folge mit jemanden aus seinem
Netzwerk für Kritik zufolge Anregungen und Fragen für neue
Folgen freuen wir uns auf deine Email an Podcast datei.com
Abonniere jetzt unseren Podcast und keine Folge mehr zu
verpassen bis zum nächsten Mal. Tschüss aus Hamburg h.