[0:01] Hi, hier ist Stefan. In dieser Podcast-Episode geht es ums Fachgespräch.

[0:05] Wenn du noch mehr Informationen zum Fachgespräch von mir haben willst,

[0:08] dann schau doch mal auf meiner Website vorbei, dasperfektefachgespräch.de.

[0:14] Und jetzt wünsche ich dir viel Spaß mit der Podcast-Episode.

[0:20] Herzlich willkommen zum IT-Berufe-Podcast, dem Podcast rund um die Ausbildung in den IT-Berufen.

[0:25] In dieser Episode gibt es einen Rückblick auf die Fachgespräche

[0:28] zum Fachinformatiker Anwendungsentwicklung im Jahr 2022. Viel Spaß!

[0:37] Hallo und herzlich willkommen zur 177. Episode des IT-Berufe-Podcasts.

[0:43] Mein Name ist Stefan Macke und heute beende ich meine dreiteilige Episodenreihe

[0:48] zum Rückblick auf die Sommerprüfung 2022 für FachinformatikerInnen für Anwendungsentwicklung.

[0:54] Und zwar mit den Fachgesprächen.

[0:56] Wir hatten die Dokus, wir hatten die Präsis, heute kommt der letzte Part, die Fachgespräche.

[1:00] Und das ist einer der Prüfungsteile, der von den Prüflingen am heißesten, am sehnsüchtigsten erwartet wird.

[1:08] Ja, wohl eher nicht. Die meisten haben eher ein bisschen Angst davor.

[1:11] Denn anders als bei der Doku und bei der Präsi, wie ich es schon oft gesagt habe,

[1:14] weiß man halt beim Fachgespräch nicht, was drankommt.

[1:17] Die anderen Artefakte hast du in deiner eigenen Hand, habe ich schon mehrfach erzählt.

[1:20] Fachgespräche, ist ja Glückssache, was die Prüfer und Prüferinnen dich denn wohl fragen werden.

[1:25] Und ich habe das Ganze mal in dieser Sommerprüfung bei uns in den Prüfungen mitgeschrieben, was wir gefragt haben.

[1:32] Mensch, guck mal. Und heute gebe ich dir eine Top Ten ist es nicht.

[1:35] Eine Top X-Liste sind ganz schön viele Fragen, glaube ich.

[1:38] Der am häufigsten gestellten Fragen in unseren Fachgesprächen.

[1:42] Das wird heute etwas anwendungsentwicklungslastiger als die anderen beiden Episoden.

[1:47] Weil logisch, wir wollen natürlich prüfen, ob die Leute coden können.

[1:50] Aber Überraschung, du wirst auch feststellen, dass ganz, ganz viele Fragen mal wieder nichts mit Programmieren zu tun haben.

[1:55] Und diese Fragen sind leider die meist nicht so gut beantwortet werden.

[2:00] Von daher guck dir die am besten an, egal welchen IT-Beruf du lernst.

[2:03] Einige davon können mit großer Wahrscheinlichkeit auch in deinem Fachgespräch drankommen.

[2:07] Und die werde ich dann heute einfach mal durchgehen.

[2:09] Aber wenn du Anwendungsentwickler oder Anwendungsentwicklerin wirst, dann ist das heute genau das Richtige für dich.

[2:13] Da habe ich nämlich, wie gesagt, meine Top X der Fragen, die wir gestellt haben.

[2:17] Vorweg, wie auch bei den letzten Malen, das, was ich heute erzähle, ist wieder meine Erfahrung.

[2:22] Aus den Prüfungen, bei denen ich dabei war.

[2:25] Ich spreche nicht für alle Prüfungsausschüsse in Deutschland.

[2:28] Und vor allem nicht für alle Prüfer und Prüferinnen, die sich da vielleicht Fragen ausdenken.

[2:32] Also von daher, wenn in deiner Prüfung ganz andere Fragen drankommen, dann schreib mich bitte nicht an und sag,

[2:37] Warum wurde ich nicht XY gefragt?

[2:39] Ja, ich weiß es nicht.

[2:40] Ich kann nicht in die Glaskugel schauen.

[2:42] Das sind einfach nur Erfahrungswerte aus der Vergangenheit.

[2:45] Und wie man so schön sagt, aus der Vergangenheit lässt sich nicht eins zu eins ableiten, dass es in der Zukunft auch so ist.

[2:50] Von daher, wenn im nächsten Jahr oder übernächsten Jahr was ganz anderes gefragt wird, dann ist das halt so.

[2:54] Und vor allem auch in deiner konkreten Prüfung.

[2:56] Denn ganz viele Prüfungsausschüsse fragen auch erst mal zu deinem Projekt.

[3:00] Und das kenne ich natürlich nicht.

[3:02] Also kann ich dir dazu auch keine Fragen vorgeben, logischerweise.

[3:04] Aber zumindest bei uns so.

[3:05] Wir fangen auch oft mit dem Projekt an.

[3:07] Wechseln dann aber auch zu allgemeineren Fragen, die eigentlich jeder Prüfling beantworten können muss.

[3:13] Und davon habe ich heute auf jeden Fall ein paar mitgebracht.

[3:15] Ich habe mir auch immer daneben notiert, das muss ich ja sowieso machen, als kleine Dokumentation für die Prüflinge,

[3:22] wenn wir sie am Ende bewerten, ob die Fragen richtig oder falsch beantwortet wurden.

[3:25] Und einen groben Überblick, was fast immer falsch beantwortet wurde, ist, Frage nach dem Stundensatz, laufende Kosten im Projekt,

[3:34] Löschanomalien in Datenbanken, hatten wir ganz, ganz oft, dass das nicht erklärt wurde,

[3:38] Lambda-Ausdrücke, obwohl fast jeder Prüfling die heute benutzt in seinem Code,

[3:42] und Klassiker, generische Klassen.

[3:44] Das wird auch ganz oft benutzt in statisch typisierten Sprachen.

[3:47] List of irgendwas zum Beispiel.

[3:49] Und da können die Leute einfach nicht erklären, was es ist.

[3:51] Also die meisten Fragen, die ich hier mitgebracht habe,

[3:53] also ich habe sie erst mal nur danach gewichtet, quasi wie oft wir sie gefragt haben.

[3:57] Nicht wie oft die dann falsch beantwortet wurden.

[3:59] Das waren jetzt so die Top der falsch beantworteten Fragen gerade.

[4:02] Grundsätzlich solltest du dir alles angucken.

[4:04] Aber die Fragen, die jetzt gleich kommen, sind halt am häufigsten gestellt.

[4:08] Und dann würde ich dir empfehlen, schau sie dir so gut an, die Antworten,

[4:11] dass du sie auch in der Prüfung gut abspulen kannst.

[4:14] Und darum geht es natürlich danach, wirst du bewertet.

[4:17] Wie schon angedeutet, sind da eben auch viele Wirtschaftsfragen dabei.

[4:21] Vermutlich, weil einfach viele Prüflinge zum Anbindungsentwickler oder Anbindungsentwicklerin eben Bock auf Coden haben,

[4:26] was auch gut ist, und dann aber den Wirtschaftsteil leider links und rechts liegen lassen.

[4:30] Und das ist nicht so gut, weil der IT-Beruf ist halt ein Kaufmanager-Beruf.

[4:35] Und das war schon immer so und wird auch so bleiben.

[4:38] Zumindest nach der Neuordnung 2020 sieht das ganz stark so aus.

[4:43] Also von daher guckt ihr unbedingt auch diesen Bereich an.

[4:46] Weil das ist einfach wichtig und es kommen einfach viele Fragen dazu auch im Fachgespräch hoch.

[4:50] Ansonsten kann ich immer wieder nur noch mal zum x-ten Mal sagen,

[4:54] alles was du benutzt in deinem Projekt, das musst du auch erklären können.

[4:58] Es kann nicht angehen, dass du sagst, ja, ich habe Java und JavaScript benutzt,

[5:01] aber du kannst die Problemsprachen nicht abgrenzen.

[5:03] Du weißt nicht die Eigenschaften der einen oder der anderen.

[5:06] Du kannst nicht sagen, wie sie typisiert sind oder was die Unterschiede sind,

[5:09] was die Paradigmen sind und so weiter. Das geht einfach nicht.

[5:12] Du musst dich mit den Sachen auseinandersetzen und sie in Anführungszeichen auf Prüfungsniveau erklären können.

[5:17] Und nicht einfach irgendwas runter, ja, ich sage immer so abfällig, runterrotzen,

[5:21] ohne eigentlich zu verstehen, was du tust. Das geht nicht.

[5:23] Jedenfalls nicht in der Abschlussprüfung.

[5:25] Das kannst du in deinem Tagesjob vielleicht machen.

[5:27] Vielleicht kommst du damit durch bei deinem Chef.

[5:29] Aber bei den Prüfer und Prüferinnen, nee, bitte nicht.

[5:31] Da musst du es erklären können.

[5:33] Und daher ergibt sich ein anderer großer Teil der Fragen von meiner Liste

[5:37] einfach aus den häufigen Projektthemen.

[5:39] Wir haben halt ganz klassisch viel Web-Anwendungen, die entwickelt werden.

[5:42] Da werden RESS-Schnittstellen gebaut, da wird irgendwas abgesichert mit OAuth zum Beispiel.

[5:46] Verschiedene Programmiersprachen, Stichwort Backend und Frontend.

[5:50] Java zum Beispiel und JavaScript sind halt ganz unterschiedlich typisiert.

[5:53] Insbesondere im Frontend wird halt fast immer auf JavaScript gesetzt

[5:56] oder zum Beispiel auch auf TypeScript.

[5:58] Aber dann sollte man auch ein paar Spezifika der Sprache kennen.

[6:00] Das sind so die Basics.

[6:02] Zum Beispiel Frage, wie man Variablen deklarieren kann in JavaScript.

[6:05] Da gibt es ja verschiedene Möglichkeiten.

[6:07] Das kommt auch immer mal wieder hoch, weil das so die Basics der Sprache sind,

[6:11] die man eigentlich können und kennen sollte,

[6:13] wenn man damit eine umfangreiche Anwendung gebaut hat.

[6:15] Na, nach irgendwas müssen wir ja fragen.

[6:17] Und auf der anderen Seite haben wir halt oft Single-Page-Applications heutzutage,

[6:20] die halt so einen großen Stack mitbringen.

[6:22] Und da muss man sich halt auch mal Fragen zur Architektur gefallen lassen,

[6:24] was die Vor- und Nachteile sind, ob es noch Alternativen gibt und so weiter.

[6:27] Also natürlich hinterfragen wir dann auch deine Anwendungen,

[6:31] gucken, was du da gemacht hast und warum du was gemacht hast.

[6:34] Und darauf muss natürlich auch Frage und Antwort stehen.

[6:36] Das heißt, die Fragen, die gleich kommen, sind halt eher allgemeiner Natur.

[6:39] Aber du solltest dich natürlich insbesondere auf alles rund um dein Projekt vorbereiten.

[6:43] Das werden wir natürlich links und rechts auseinandernehmen,

[6:46] weil das ist ja dein Prüfungs, dein Artefakt, was du abgibst am Ende.

[6:51] Und ja, wenn dann noch Zeit ist, wenn du alles gut erklärt hast,

[6:54] dann kommen wir zu diesen, in Anführungszeichen, Standardfragen,

[6:56] die wir jetzt gleich mal einmal durchgehen.

[6:58] Gut, ich habe nicht durchgezählt, wie viele es sind,

[7:01] aber sie passen nicht mehr auf einem Bildschirm, knapp auf zwei bei mir.

[7:04] Es sind relativ viele.

[7:05] Ich weiß noch nicht, ob ich heute alle durchgehe und sauber erklären kann.

[7:08] Bei einigen dauert es nämlich vielleicht ein bisschen lange.

[7:11] Das wäre dann jeweils eine einzelne Podcast-Episode.

[7:13] Aber ich gucke mal, was mir zu den einzelnen Fragen einfällt.

[7:15] Und ja, dann schauen wir mal, was dir das am Ende bringt.

[7:18] Ich habe ja noch ein paar komplette Podcast-Episoden,

[7:20] zum Beispiel direkt zu meiner ersten Frage zum Stundensatz, aufgenommen.

[7:23] Den kannst du dir dann gerne nochmal anhören,

[7:25] wenn du das im Detail dir nochmal draufschaffen willst.

[7:28] Gut, dann starten wir mit meiner Liste.

[7:30] Nummer eins, unangefochten, auf Platz eins.

[7:32] Und ich glaube schon fast seit Jahren ist die Frage nach dem Stundensatz.

[7:36] Und wie könnte so eine Frage aussehen?

[7:38] Es gibt natürlich verschiedene Möglichkeiten, danach zu fragen.

[7:40] Klassiker wäre, erläutern Sie uns doch mal, was in einem Stundensatz enthalten ist.

[7:45] Und dann würden wir erwarten, dass da nicht nur kommt, mein Gehalt.

[7:50] Und das wäre gleich auf mehrfachen Ebenen eine schlechte Antwort.

[7:53] Weil Nummer eins, Azubis kriegen kein Gehalt, sondern eine Ausbildungsvergütung.

[7:57] Nummer zwei, es besteht nicht nur aus der Ausbildungsvergütung,

[8:00] sondern auch aus ganz, ganz vielen anderen Teilen.

[8:02] Insbesondere der Sozialversicherung, die die nächsten großen Brocken ausmacht.

[8:05] Vielleicht, wenn es ein externes Projekt ist, noch ein Gewinnaufschlag, der reinkommt.

[8:09] Dann natürlich noch die ganzen Gemeinkosten, die umgelegt werden müssen und so weiter.

[8:13] Und das sollte man bitte sauber erklären können.

[8:15] Viele Anschlussfragen gehen dann zum Beispiel in den Bereich der einzelnen Bestandteile.

[8:19] Also, wenn wir sowas haben wie die Gemeinkosten,

[8:22] dann kann man schön fragen, was der Unterschied ist zwischen Gemeinkosten und Einzelkosten.

[8:26] Oder fixe und variable Kosten.

[8:28] Also alles, was irgendwie auf Kosten endet.

[8:30] Da kann man natürlich schön einsteigen.

[8:31] Oder Sozialversicherung.

[8:33] Die Frage kommt jetzt auch tatsächlich auf Platz drei schon meiner Liste.

[8:36] Gleichrangig mit der Normalisierung.

[8:38] Weil die Sozialversicherung sollte man halt auch kennen.

[8:40] Und zwar übrigens ganz egal, welchen Beruf man lernt.

[8:42] Weil die zahlen wir alle.

[8:43] Also Sozialversicherung aufzählen können.

[8:46] Und auch, wer sie bezahlt.

[8:48] Denn dadurch wird klar, dass das in den Schnurnsatz eingerechnet werden muss.

[8:50] Wir haben in Deutschland, zumindest Stand jetzt, 2022, fünf Sozialversicherungen,

[8:55] die auch übrigens auf jeder deiner Gehaltsabrechnung stehen müssten.

[8:59] Hört ihr auch gerne dazu nochmal meine Podcast-Episode an.

[9:02] Da gehe ich alle durch.

[9:03] Wir haben die Rentenversicherung, die Krankenversicherung, die Pflegeversicherung, die Unfallversicherung.

[9:08] Und eine bleibt noch übrig.

[9:10] Und das ist die Arbeitslosenversicherung.

[9:12] Das sind die fünf Sozialversicherungen.

[9:14] Und die zahlen wir.

[9:16] Und die zahlen wir hauptsächlich zur Hälfte.

[9:18] Und zur anderen Hälfte zahlt die der Arbeitgeber.

[9:20] Und da der Arbeitgeber die zahlt, zusätzlich zu deiner Ausbildungsvergütung,

[9:23] muss er die natürlich auch mit einkalkulieren.

[9:25] Wenn er dich irgendwem in Rechnung stellt.

[9:27] Weil die Euros dafür, die fahren ja nicht vom Himmel.

[9:30] Die muss er irgendwie erwirtschaften.

[9:31] Ganz kurzer Überblick.

[9:33] Weil ich habe das schon wirklich im Detail in meiner Episode zur Gehaltsabrechnung gemacht.

[9:37] Vier von fünf teilen wir uns hälftig.

[9:40] So ungefähr mit kleinen Ausnahmen.

[9:42] Und die Unfallversicherung trägt der Arbeitgeber komplett sogar.

[9:45] Dafür musst du gar nichts bezahlen.

[9:47] Und das ist sicherlich etwas, was viele Prüflinge so nicht auf die Kette kriegen.

[9:51] Ich würde mir auf Prüfungsniveau dann zum Beispiel noch wünschen,

[9:53] dass du weißt, wie die aktuellen Prozentsätze sind der jeweiligen Sozialversicherung.

[9:57] Aber dann bist du schon auf dem Weg zum Eins-Plus-Kandidat.

[10:00] Wenn du das werden willst, dann schau sie dir auf jeden Fall einmal an.

[10:03] Also, Stundensatz unbedingt angucken.

[10:05] Mache ich nicht im Detail.

[10:06] Eigene Podcast-Episode ist verlinkt in den Shownotes.

[10:08] Die findest du übrigens wie immer unter itberufepodcast.de slash 177.

[10:13] Hör sie dir unbedingt an und auch den Podcast zur Sozialversicherung

[10:16] beziehungsweise zur Gehaltsabrechnung, wo wir das mit durchgehen.

[10:19] Also, diese beiden Sachen kann ich dir uneingeschränkt empfehlen.

[10:22] Unbedingt bitte reinhören, weil die stellen wir in fast jedem Fachgespräch.

[10:26] Und sie werden auch fast immer falsch oder unvollständig beantwortet.

[10:30] Und das ist ganz, ganz schade.

[10:31] Deswegen unbedingt einmal reinhören.

[10:33] So, auf Platz 2 haben wir dann das erste Mal etwas Technisches und zwar Normalisierung.

[10:38] Wir sind ja jetzt im Bereich der Anwendungsentwicklung.

[10:40] Da gehört Programmieren natürlich zum Alltag, aber auch Datenbanken.

[10:44] Irgendwie.

[10:45] Ob man sie jetzt selber erstellt oder abfragt, beides ist wichtig.

[10:48] Und auf Platz 2 meiner Liste ist die Normalisierung,

[10:51] weil wenn man in seinem Projekt eine eigene Datenbank erstellt,

[10:54] wir natürlich auch erwarten, dass sie normalisiert erstellt wird

[10:57] in der üblichen dritten Normalform.

[11:00] Zur Normalisierung habe ich auch schon mehrere Artikel und Podcast-Episoden aufgenommen.

[11:04] Deswegen gehe ich es nicht im Detail durch.

[11:06] Ich höre dir auch die gerne nochmal an.

[11:08] Einmal habe ich sogar häufige Fragen im Fachgespräch, glaube ich, gemacht zur Normalisierung.

[11:11] Und dann auch ein konkretes Beispiel,

[11:13] wie komme ich von einer nicht-normalisierten zu einer normalisierten Datenbank

[11:17] mit den einzelnen Schritten dazwischen.

[11:19] Denn das liefert auch viele weitere Anschlussfragen im Fachgespräch.

[11:22] Zum Beispiel, Klassiker, auf welcher Normalisierungsstufe,

[11:26] also auf welcher Normalisierungsform, Normalform,

[11:29] so, mein Gott, werden die M zu N und auf welcher die 1 zu N Beziehungen aufgelöst.

[11:34] Und, Spoiler, M zu N wird auf der zweiten

[11:36] und 1 zu N wird erst auf der dritten Normalisierungsformherrschaft sein, aufgelöst.

[11:42] Also Normalisierung auch ein Quell vieler, vieler Anschlussfragen

[11:46] mit den verschiedenen Stufen und was dort passiert

[11:51] und Beispielen vor allem auch, damit man sauber erklären kann und so weiter.

[11:54] Also bitte unbedingt drauf schaffen.

[11:55] Wichtiges Thema für alle Anwendungsentwickler und Entwicklerinnen.

[11:58] Und dann kommen auf Platz 4 und 5 erst ein bisschen was zur Programmierung,

[12:04] nämlich einmal die Kapselung und dann die klassische Frage, Klasse versus Objekt.

[12:08] Was ist der Unterschied?

[12:09] Kapselung ist ja eine der zentralen Säulen der Objektorientierung,

[12:13] insbesondere sowas wie, was ist ein Getter und Setter?

[12:16] Was sind Sichtbarkeitsmodifizierer? Wozu benutze ich die?

[12:19] Wie ist die Sichtbarkeit bei den einzelnen Modifizierern und so weiter?

[12:22] Und das zeigt auch ganz viel, ob man Objektorientierung gut verstanden hat oder nicht.

[12:26] Es gibt zwar noch Polymorphie und Vererbung.

[12:28] Und ja, die kommen auch gleich auf der Liste.

[12:30] Aber die Kapselung ist eine schöne Einstiegsfrage, weil das sich so einfach anhört,

[12:35] aber man daran gut festmachen kann, ob die Leute es wirklich verstanden haben.

[12:38] Polymorphie und Vererbung kann ich so lehrbuchmäßig auswendig lernen.

[12:41] Aber Kapselung, was ist denn der Sinn von Gettern und Settern?

[12:44] Warum mache ich das?

[12:45] Und was bringt mir das im Vergleich zu anderen Programmiersprachen?

[12:47] Da kann man auch wieder ganz, ganz viele Anschlussfragen stellen.

[12:49] Sei es so kleine Sachen wie, erklären Sie doch mal Getter und Setter,

[12:52] wie implementiert man das? Warum macht man das?

[12:54] Warum macht man die Sachen nicht public und so weiter?

[12:56] Aber eben auch hin zu größeren Sachen.

[12:59] Theoretisch kommt noch bis zu Designpattern gehen und so weiter an der Stelle.

[13:02] Also das ist immer ein schöner Einstieg.

[13:04] Und deswegen fragen wir das relativ häufig.

[13:06] Genauso oft haben wir allerdings eine weitere klassische Frage gestellt,

[13:10] und zwar grenzen Sie mal Objekt und Klasse ab.

[13:12] Das können recht viele Prüflinge, weil man inzwischen so erwarten kann,

[13:15] dass das eine Standardfrage ist.

[13:17] Es gibt aber immer noch überraschend viele, die es nicht sauber abgrenzen können.

[13:20] Da wird dann irgendwie sowas gesagt wie, eine Klasse enthält ein Objekt.

[13:24] Oder manchmal gibt es da ganz komische Formulierungen.

[13:26] Und ganz kurze Wiederholung, Klasse versus Objekt.

[13:30] Ein Objekt ist ein Ding der realen Welt mit Eigenschaften und Funktionen.

[13:34] Eigenschaften heißen in der Objektorientierung Attribute.

[13:37] Die Funktionen werden Methoden genannt.

[13:39] Und diese Eigenschaften können Werte haben.

[13:42] Und die Funktionen führen halt etwas aus, was man mit diesem Ding tun kann.

[13:46] Es gibt dann eine Klasse.

[13:48] Eine Klasse ist eine Art Bauplan für Objekte.

[13:51] Aus einer Klasse kann ich mehrere Objekte erzeugen,

[13:54] deren Werte, deren Attributwerte sich unterscheiden können,

[13:57] die aber immer alle die gleiche Anzahl an Attributen und Methoden haben.

[14:02] Und so kann ich quasi aus der Klasse beliebig viele Objekte erzeugen.

[14:06] Die nenne ich dann auch Instanz.

[14:08] Instanz und Objekt ist quasi ein Synonym füreinander.

[14:11] Und ich erkläre das immer gerne wie so einen Ikea-Schrank.

[14:14] Wenn ich diese Ikea-Papieranleitung mir wie eine Klasse vorstelle,

[14:17] kann ich mit dieser einen Klasse ganz viele verschiedene Ikea-Schränke zusammenbauen,

[14:22] die zwar alle exakt gleich aussehen,

[14:24] die aber alle individuell eine Ausprägung dieses Schrankes zum Beispiel sind.

[14:29] Das ist ganz grob zusammengefasst das, was man sagen könnte

[14:32] im Fachgespräch zu Klasse versus Objekt.

[14:35] So, nächste Frage auf der Liste ist auch wieder etwas technischer.

[14:38] Ein Lambda-Ausdruck. Was ist das eigentlich?

[14:40] Und vor allem fragen wir das selbstverständlich,

[14:42] wenn wir in Code-Beispielen Lambda-Ausdrücke sehen.

[14:44] Auch alle anderen dürfen das inzwischen erklären können,

[14:46] aber insbesondere wenn man es selber benutzt,

[14:48] dann kann man schon die Uhr danach stellen, wenn man danach gefragt wird.

[14:50] Und ein Lambda-Ausdruck ist so einfach erklärt.

[14:52] Das ist einfach eine anonyme Funktion.

[14:54] Also eine Funktion, die keinen Namen hat.

[14:56] Das war es auch schon.

[14:58] Und jetzt kann man natürlich noch mehr erklären,

[14:59] dass man dann zum Beispiel higher-order-functions daraus zusammenbauen kann,

[15:02] die dann solche Lambda-Ausdrücke als Parameter bekommen.

[15:05] Oder man kann sagen, man kann damit ein bisschen Code abkürzen.

[15:07] Man spart sich ein bisschen Boilerplate-Code,

[15:09] weil man Methoden, Signaturen nicht mehr hinschreiben muss und solche Sachen.

[15:12] Da kann man dann verschiedene Ausführungen noch machen.

[15:14] Aber runtergebrochen auf die Basics ist ein Lambda-Ausdruck einfach nur eine Funktion ohne Namen.

[15:18] Das ist es. Mehr ist es nicht.

[15:20] Schön wäre natürlich, wenn man dann noch zu der Programmiersprache,

[15:23] die man selber benutzt hat, erklären kann, wie die mit Lambda-Ausdrucken umgeht.

[15:26] Ich würde zum Beispiel, wenn ich einen Java-Entwickler oder Entwicklerinnen sitzen habe,

[15:30] fragen, wie das denn genau umgesetzt ist.

[15:32] Weil Lambda-Ausdrücke, also Funktionen,

[15:34] sind nicht einfach in die Sprache eingebaut worden als neuer Datentyp,

[15:37] sondern es ist quasi nur syntaktischer Zucker.

[15:40] Und im Hintergrund wird aus diesen Lambda-Ausdrücken trotzdem weiterhin eine Klasse generiert.

[15:45] Das kann man alles wunderbar erklären, wenn man Java-Entwickler wird.

[15:48] Ansonsten muss man das nicht erklären.

[15:50] Nächster Punkt habe ich eben schon angeteasert.

[15:53] Vererbung und auch die Polymorphie kommen gleich noch drei Fragen drunter.

[15:57] Die darf man natürlich auch rauf und runter erklären können,

[16:00] weil es halt eben Sachen sind, die in Objektorientierung oder anders,

[16:04] die für die Objektorientierung so wichtig sind, die das ja quasi auch so ein bisschen mit definieren.

[16:09] Und da wir das quasi täglich benutzen, wenn wir objektorientiert arbeiten,

[16:12] sollte man diese beiden wichtigen Features erläutern können.

[16:15] Vererbung, ja, kriegen die meisten Azubis eigentlich ganz gut hin.

[16:19] Sagen dann so, ja, aus Basisklassen werden die Attribute und Methoden an die Subklassen vererbt.

[16:25] Da kann man natürlich viele Anschlussfragen stellen.

[16:27] Werden alle Methoden und Attribute vererbt?

[16:29] Nein, nur die sichtbaren natürlich.

[16:31] Dann kann ich auch die Vererbung einschränken.

[16:33] Ja, ich könnte zum Beispiel in Java mit Final verhindern, dass Methoden überschrieben werden können und solche Sachen.

[16:40] Also sowas kann ich tun und fragen als Prüfer.

[16:43] Und bei der Polymorphie allerdings, da tun sich viele Prüflinge immer ein bisschen schwerer, das zu erklären.

[16:48] Bringen das dann auch so ein bisschen mit Vererbung durcheinander oder erklären das immer anhand der Vererbung und so weiter.

[16:52] Also das muss man ein bisschen sauberer abgrenzen.

[16:55] Zu beiden Themen, Vererbung und Polymorphie, habe ich jeweils eine Podcast-Episode schon aufgenommen,

[16:59] eine sehr ausführliche. Hört die gerne nochmal an.

[17:01] Ansonsten kurzer Spoiler zur Polymorphie.

[17:04] Ist halt quasi eine Funktionalität der Poemiersprache, die, ich sag mal, in zwei Ausprägungen kommt.

[17:09] Nummer eins, ich kann überall, wo ein gewisser Datentyp erwartet wird,

[17:13] zum Beispiel, wenn ich eine Variable deklariere oder wenn ich einen Parameter bekomme oder wenn ich einen Rückgabewert irgendwo habe,

[17:18] kann ich dort auch eine Subklasse oder einen Subtypen ganz allgemein erwarten.

[17:23] Also bei einer Klasse zum Beispiel eine Subklasse oder bei einem Interface eine implementierende Klasse.

[17:29] Und das heißt, der Aufrufer sieht nicht, welcher konkrete Typ sich hinter diesem abstrakten Typen, sag ich mal, verbirgt.

[17:38] Abstrakt nicht im Sinne abstrakter Klassen, sondern eben einem Obertyp von etwas.

[17:42] Entweder Interface oder Basisklasse.

[17:44] So, und übrigens, ich habe gleich schon falsch angefangen.

[17:47] Ich würde erst mal erläutern, was Polymorphie eigentlich heißt.

[17:50] Das steht für Vielgestaltigkeit.

[17:52] Und das sieht dann quasi so aus, als würden sich hinter dieser Variable verschiedene Datentypen verbergen.

[17:58] Und die Gestalt dieses Datentyps kann sich verändern quasi.

[18:01] Und das zweite wichtige Feature der Polymorphie ist das sogenannte späte oder dynamische Binden.

[18:06] Das heißt, wenn ich in meiner Vererbungshierarchie zum Beispiel Methoden überschreibe,

[18:10] dann wird zur Laufzeit immer von ganz unten in der Vererbungshierarchie schrittweise nach oben geschaut,

[18:16] wo die erste Implementierung dieser Methode vorliegt, und die wird dann aufgerufen.

[18:20] Und so kann ich quasi mit der Polymorphie einmal definiertes Verhalten in Subtypen überschreiben und verändern.

[18:26] Das macht es so interessant, weil nach außen hin sieht es so aus, als würde ich mit einem Ding arbeiten.

[18:31] In Wirklichkeit arbeite ich aber mit einem abgeleiteten Ding.

[18:34] Und das verhält sich vielleicht ganz anders als das eigentliche Ding.

[18:37] Und das ist ganz interessant.

[18:39] Damit ermögliche ich zum Beispiel eine Erweiterbarkeit in meinem Code,

[18:43] weil ich einfach gegen die Basistypen entwickle,

[18:45] später dann aber Subtypen ergänzend einfach meinem Programm hinzufügen kann.

[18:49] Und das Basisverhalten muss ich dafür gar nicht mehr anpassen.

[18:52] Das wäre so dieses Open-Closed-Principle aus den Solid-Principles,

[18:56] was man zum Beispiel mit Polymorphie und einer konkreten Ausprägung der Vererbung umsetzen könnte.

[19:02] So, dann haben wir als nächstes eine Frage aus dem Datenbankbereich wieder, und zwar Anomalien.

[19:07] Was ist das eigentlich?

[19:08] Wir fragen natürlich auch ganz oft nach Normalisierung.

[19:10] Dann kommen wir immer zu der Frage, warum machen wir den ganzen Quatsch eigentlich?

[19:13] Warum normalisieren wir Datenbanken?

[19:14] Und dann ist die Antwort ja, um Redundanzen zu vermeiden.

[19:16] Und dann ist die Gegenfrage, warum wollen wir denn Redundanzen vermeiden?

[19:19] Und dann ist die Antwort ja, weil Redundanzen zu Anomalien führen können.

[19:22] Und dann ist wieder die Gegenfrage, was sind denn die Anomalien?

[19:25] Und dann kommt die Antwort, zum Beispiel, wenn ich Datensätze mehrfach habe und ich ändere dann den Namen,

[19:31] dann kann ich einen vergessen.

[19:32] Und das ist dann eine so Halb- beziehungsweise Drittelantwort, die wir haben wollen.

[19:36] Denn es gibt drei verschiedene Anomalien und die meisten Prüflinge können leider nur die Änderungsanomalie,

[19:42] die ich gerade beschrieben habe, erklären und vergessen, dass es noch zwei andere gibt

[19:46] und werfen das dann alles irgendwie munter durcheinander.

[19:49] Also zum Beispiel bei der Löschanomalie.

[19:51] Das ist eine der am häufigsten falsch beantworteten Anomalien.

[19:54] Sowas wie, ja, ich habe mehrere Datensätze in der Datenbank und dann lösche ich die, aber ich vergesse einen.

[19:58] So, und das ist leider überhaupt nicht, was die Löschanomalie ist.

[20:01] Ich erkläre es nochmal ganz kurz.

[20:03] Die Änderungsanomalie, das ist die, die die meisten kennen.

[20:07] Ich habe zum Beispiel mehrere Datensätze eines Kunden in meiner Datenbank

[20:10] und jetzt ändert der seinen Namen, weil er zum Beispiel heiratet.

[20:13] Dann muss ich ja alle Datensätze ändern, wo der Name drin steht.

[20:16] Und wenn ich dabei einen vergesse oder sogar mehrere, dann habe ich Inkonsistenz in der Datenbank

[20:20] und das Ergebnis ist, dass ich nicht mehr weiß, wer denn jetzt wirklich heißt.

[20:23] Und dass der Kunde vielleicht den falschen Namen auf seiner Rechnung hat. Und das wäre halt unschön. Wollen wir nicht.

[20:27] Deswegen wollen wir den nur noch ein einziges Mal in der Datenbank haben. Und wenn ich den dann ändere, dann ist er überall geändert.

[20:32] So, und jetzt kommen wir zur Einfüge- und Löschanomalie. Und um die erklären zu können, muss ich nicht an eine normalisierte Datenbank denken, sondern eine

[20:39] nicht-normalisierte Datenbank. Und ich glaube, da tun sich ganz viele Prüflinge einfach schwer damit. Denn die denken automatisch in dritter Normalform. Aber für diese Anomalien

[20:49] muss eine Datenbank nicht normalisiert sein. Sonst würden sie gar nicht mehr auftreten. Wie gesagt, deswegen setzen wir die Datenbank ja in Normalformen um, um diese

[20:56] Anomalien zu vermeiden. Ich will jetzt nicht sagen, dass es die nicht mehr geben kann, in normalisierten Datenbanken. Aber um das Beispiel zu erklären, braucht man eine

[21:04] nicht-normalisierte. Und wir stellen uns einfach mal vor,

[21:06] eine Tabelle, in der Kunden mit ihren Bestellungen

[21:10] zusammen drinstehen. Das heißt, sowas wie Kundennummer, Kundenname, Bestellnummer und, weiß nicht, Bestelldatum. Ja, alles schön in einer Tabelle.

[21:17] Und jetzt ist es so, wenn ich zum Beispiel in dieser Tabelle einen Kunden anlegen will,

[21:21] mache ich irgendwie Insert in diese Tabelle und fülle Kundennummer und Kundennamen.

[21:25] Aber was mache ich denn mit den Spalten Bestellnummer und Bestelldatum?

[21:29] Wenn der noch nie was bestellt hat, dann müsste ich jetzt hier entweder eine Fake-Bestellung eintragen oder ich lasse es einfach leer.

[21:34] Ich setze das Ding einfach auf Null.

[21:36] Und das wäre beides komisch.

[21:38] Und manche Tabellen sind dann so konfiguriert, dass man das einfach nicht kann, weil der Datensatz muss halt vollständig sein. Und dann habe ich

[21:44] ein Problem, weil ich kann den Kunden nicht anlegen, wenn er keine Bestellung aufgegeben hat. Und das wäre vielleicht ein Problem.

[21:51] Und das wäre dann eine Einfüge-Anomalie. Ich kann den Datensatz nicht einfügen, obwohl

[21:56] ich ihn eigentlich anlegen will, weil mir Daten fehlen, die mit dem eigentlichen Datensatz aber gar nichts zu tun haben. Ich will einen Kunden anlegen,

[22:03] brauche aber Bestellungsdaten, weil ich sonst den Kunden nicht anlegen kann. Das wäre doof.

[22:08] So, und in diesem gleichen Beispiel können wir auch die Löschanomalie erklären, die halt so viele Prüflinge immer falsch machen.

[22:13] Stellen wir uns vor, wir haben den Kunden da drin mit seinen Bestellungen und er steht da auch meinetwegen ganz, ganz oft drin. Ist aber auch

[22:17] egal für die Löschanomalie. Wenn ich nämlich jetzt aus dieser Tabelle eine Bestellung zum Beispiel

[22:23] löschen will, dann steht diese Bestellung ja in der gleichen Zeile wie der Kunde.

[22:26] Das heißt, um die Bestellung zu löschen, müsste ich den Kunden mit löschen, weil es ist halt ein einziger, quasi gemeinsamer

[22:33] Datensatz. Und da hätte ich jetzt mehr gelöscht, als ich eigentlich löschen will. Wenn ich nur eine Bestellung lösche, fliegt auch der Kunde mit raus.

[22:40] Das wäre schlecht. Und das wäre eine einigermaßen sinnvolle Erklärung für eine Löschanomalie. Das wollen wir nicht. Und was wäre dann das Ergebnis?

[22:47] Das kann man natürlich dann gleich gut erklären, als guter Prüfling. Wenn wir das normalisieren würden und wir würden Kunden und Bestellungen in ihre eigenen

[22:54] Tabellen verfrachten und die dann mit Schlüsseln aufeinander zeigen lassen, dann können wir zum Beispiel den Kunden löschen, wir können auch die Bestellung löschen,

[23:00] wir können was einfügen, ändern, was auch immer. Haben alles nur noch an einer Stelle und haben keine Abhängigkeiten zwischen diesen

[23:07] Datensätzen, sodass wir munter auch Kunden anlegen können, ohne eine Bestellung anlegen zu können. Das wäre dann das Ergebnis.

[23:14] So, wir bleiben bei Datenbanken. Die nächste Frage auf der Liste ist die nach Kardinalitäten.

[23:19] Welche

[23:20] Beispiele gibt es denn für Kardinalitäten und welche Kardinalitäten gibt es überhaupt in einer Datenbank? Und da ist der Klassiker 1 zu 1, 1 zu n,

[23:27] m zu n. Das können auch die meisten Prüflinge erst mal erklären. Bei den Beispielen wird es dann ganz oft tricky.

[23:33] Und dieses Jahr hatten wir auch schon wieder jemanden, der zum Beispiel gesagt hat, Beispiel für 1 zu 1 Beziehungen ist Postleitzahlort.

[23:39] Also, das zeigt halt einfach, dass sie sich damit in der Praxis noch nie beschäftigt haben. Man kommt ganz schnell darauf, dass das eine

[23:45] m zu n Beziehung ist. Überraschung, falls du das noch nicht wusstest, denn es gibt in Deutschland zumindest, für andere Länder kann ich nicht sprechen,

[23:51] gibt es Orte, die mehrere Postleitzahlen haben.

[23:54] Simples Beispiel, Berlin hat irgendwie, ich weiß nicht, sag ich mal, zehn Postleitzahlen. Der Ort heißt immer Berlin. Auf der anderen Seite gibt es aber auch

[24:02] einen Ort mit mehreren Postleitzahlen. Es gibt aber auch eine Postleitzahl mit mehreren Orten. Also genau das Gegenteil. Und das ist in meinem Heimatort

[24:09] sogar so. Wir haben 49377

[24:12] Vechter. Es gibt aber auch 49377

[24:16] Langförden. Das ist nämlich so ein kleiner Mini-Vorort von Vechter und hat einfach die gleiche Postleitzahl.

[24:20] Also, Postleitzahlort ist eine m zu n Beziehung. Und du legst dir bitte für deine mündliche Prüfung saubere Beispiele für alle drei

[24:28] Kainalitätstypen zurecht. M zu n, 1 zu n gibt es relativ viele.

[24:31] 1 zu 1 ist immer so ein bisschen tricky, weil die gibt es in der Realität gar nicht so oft,

[24:36] dass zu einem Datensatz wirklich nur ein einziger auf der Gegenseite existiert und umgekehrt auch. Ein Beispiel, was man nehmen könnte,

[24:44] eventuell, wäre sowas wie

[24:46] Benutzer und Login.

[24:48] Benutzer in einem Online-System, zum Beispiel Online-Shop oder so, da steht Benutzername und E-Mail und ich weiß nicht, was alle drin.

[24:54] Und in der Login-Tabelle steht Benutzername und Passwort drin. Passwort natürlich gehasht und gesaltet und ich weiß nicht, was. Das ist nur kurz

[25:00] zusammengefasst hier. Und dann kann man noch mal überlegen, warum man die auseinanderzieht. Stichwort Datenschutz und IT-Security und x und y.

[25:07] Und was aber hier dann das Ergebnis ist, zu einem Benutzer gibt es genau ein Login und ein Login gehört zu einem Benutzer.

[25:14] Das ist dann eine echte 1 zu n,

[25:17] 1 zu 1 Beziehung, natürlich nicht 1 zu n.

[25:21] Also such dir gute Beispiele, im besten Fall sogar aus deinem eigenen Projekt, dann wird es nicht so langweilig, weil sonst erklären immer alle zum x-en Mal

[25:27] Artikel und Artikelgruppe ist eine 1 zu n Beziehung.

[25:32] Gut, nächste Frage, die häufig kommt, gerade weil wir so viele Projekte mit mehreren Programmiersprachen haben, ist die Typisierung.

[25:39] Bitte schau dir an, wie deine Programmiersprachen, wenn du welche eingesetzt hast, typisiert sind. Und es gibt zwei Ebenen Typisierung. Einmal

[25:46] statisch und dynamisch, das können die meisten Prüflinge noch erklären.

[25:50] Dynamisch, da muss ich halt keine Datentypen angeben zur Compile-Zeit bei der statischen Typisierung schon. Stichwort Java, String x, muss ich den Datentypen angeben.

[25:59] In zum Beispiel PHP muss ich das nicht, dann mache ich einfach Dollar x, dann habe ich halt eine Variable oder kann ich halt irgendwas rein speichern.

[26:04] Das ist statisch dynamisch. Es gibt auch noch eine zweite Ebene und zwar

[26:08] schwach und stark typisiert und das bringen dann viele durcheinander. Erstmal mit statisch und schwach und irgendwas und dann kommt da so, ja es gibt

[26:16] statische und schwache Typisierung und dann geht alles wild durcheinander.

[26:19] Erstmal statisch dynamisch, muss zur Compile-Zeit der Datentyp feststehen, ja oder nein. Und dann haben wir starke und schwache Typisierung und dabei geht es

[26:27] darum, ob zur Laufzeit

[26:29] Typen eventuell ineinander umgewandelt werden und zwar implizit, ohne dass du das sehen kannst. Und da habe ich zum Beispiel

[26:35] etwas aus PHP mitgebracht, da könntest du so was schreiben wie if

[26:39] Klammer auf, 1, Klammer zu. Und dann fragt man sich so, hä, was ist das denn? In einem if-Statement bei der Bedingung in den Klammern, da muss

[26:48] ja ein boolscher Ausdruck stehen. Also if, true oder false quasi. Und jetzt schreibe ich da einfach eine 1 rein. Wie kann das denn sein?

[26:55] Und das ist genau ein Beispiel für eine schwache Typisierung. In diesem Fall würde nämlich die Programmiersprache die 1

[27:02] umwandeln und zwar implizit, also ohne dass es wirklich hingeschrieben wird, in einen Wahrheitswert, in true oder false.

[27:09] Und jetzt, nagel mich nicht darauf fest, ist es glaube ich so, was alles, alle Zahlwerte, die nicht null sind, werden automatisch in true

[27:16] und null wird in false umgewandelt. Und das wäre es dann. Das heißt aus if 1 würde dann quasi implizit if

[27:23] false und dann würde das halt nie ausgeführt.

[27:25] So, das gibt es dann für verschiedene Datentypen. Man kann zum Beispiel auch Strings dann so umwandeln. Das wäre dann ungefähr so, alles was ein

[27:30] gefüllter String ist, ist true und der leere String ist false. Also dann gibt es verschiedene Regeln dafür.

[27:34] Und wenn die Programmiersprache das macht, dann ist sie schwach typisiert. Wenn sie stark typisiert ist, erlaubt sie solche Scherze nicht. Java zum Beispiel, da

[27:42] könntest du nicht mal hinschreiben if 1, weil da wird der Compiler schon sagen, was machst du denn da? Du brauchst hier einen butschen Ausdruck, das geht so nicht.

[27:48] Ja, und das ist der Unterschied zwischen

[27:51] schwach und stark. So, und jetzt guckst du dir für deine Programmiersprachen an, wie die typisiert sind und Hansfeld, kannst vielleicht auch ein Beispiel nennen

[27:59] aus deiner Praxis, aus dem Code, warum, was, wie ist und was noch die Vor- und Nachteile sind. Das wäre natürlich auch nochmal interessant, wenn du auf

[28:06] einem so Niveau antworten willst.

[28:08] So, nächste Frage. Generische Klassen werden auch in fast jedem Code benutzt.

[28:13] Stichwort aus Java, List of String, List of Integer oder so etwas und die wenigsten Prüflinge können das sauber erklären.

[28:19] Habe ich auch schon mal in einigen Podcast-Episoden was zu gesagt. Hier nochmal ganz kurz zusammengefasst. Generische Klassen stellen

[28:24] generische, also allgemeingültige

[28:27] Algorithmen bereit und zwar unabhängig vom konkreten Datentyp. Das ist etwas, was ich eigentlich nur in statisch typisierten Programmiersprachen brauche.

[28:33] Bei dynamischen Programmiersprachen ist das eigentlich unnötig, denn da gibt es ein Feature, das heißt Duck Typing.

[28:41] Okay, ich

[28:42] hole schon wieder viel zu weit aus, informiere ich darüber, du hörst dir meine andere Podcast-Episode dazu an. Ich würde eigentlich nur sagen, generische Klassen stellen generische

[28:48] Algorithmen bereit für beliebige Datentypen und ich kann die dann

[28:51] parametrieren, zum Beispiel in Java eben List of String und dann funktionieren die eben zur Laufzeit nur noch mit diesem String, den ich da angebe und

[28:58] ich kann dann nicht auf einmal ein Integer da reinpacken, wenn sie so typisiert sind.

[29:02] Okay, warum mache ich das?

[29:04] Code wiederverwenden. Ich möchte nämlich nicht eine String List und eine Integer List programmieren, die

[29:10] 99% des Codes identisch hat, nur dass einmal String und einmal Integer da drin steht, sondern ich möchte diese Liste zum Beispiel ein einziges Mal

[29:17] programmieren und dann mit beliebigen Datentypen arbeiten lassen. Dafür brauche ich generische Klassen.

[29:24] So, nächstes Thema

[29:25] leitet sich so ein bisschen aus den modernen

[29:28] Prüfungs- oder Projektthemen ab und zwar REST-APIs, die ganz oft benutzt werden, weil ich eine Single-Page-App zum Beispiel habe und ich muss mit dem

[29:34] Backend über REST

[29:36] kommunizieren. Da haben wir ganz oft heute die, heute im Jahr

[29:40] 2022, die Frage nach der Absicherung dieser APIs gestellt, weil stellen wir uns mal vor, du hast so eine API,

[29:44] da kann ich irgendwie ein Get drauf machen und dann liefert die mir alle Mitarbeiter mit ihren Gehältern so.

[29:49] Sollte ich das ungesichert im Netzwerk einfach zur Verfügung stellen? Ich glaube nicht. Und da gäbe es dann zumindest mal die Frage danach, was

[29:56] es für Möglichkeiten gibt, die abzusichern und der Klassiker wäre wenigstens ein Basic Auth. Benutzer Passwort, ich muss mich da anmelden, das wäre wohl das

[30:02] absolute Minimum. Wäre aber heutzutage nicht mehr ganz so sinnig, wenn ich mehrere dieser APIs habe, die vielleicht auch unterschiedlich

[30:08] Berechtigungen haben müssen, dann sollte ich das vielleicht nicht mehr mit Basic Auth machen, sondern mit dem

[30:12] Standard, den es inzwischen dafür gibt, und zwar mit OAuth. Und OAuth ist ein, ich sage jetzt mal,

[30:18] kompliziertes Verfahren. So kompliziert jetzt auch nicht, weil das kam schon in der IHK-Prüfung dran, wie der Ablauf da ist. Aber wenn du selber

[30:24] implementierst, ist es relativ kompliziert. Deswegen nutzen wir dafür am besten Frameworks, die uns das abnehmen, damit wir es einfacher haben.

[30:30] Wichtig ist aber, wie OAuth grundsätzlich funktioniert und zwar ist es eine delegierte

[30:35] Authentifizierung. Das heißt, du selber kümmerst dich gar nicht um die Authentifizierung, sondern delegierst das an einen, der das kann.

[30:41] Zum Beispiel, wenn du es im Internet irgendwo findest, an Facebook, an Google, an Twitter oder was auch immer. Immer, wenn du so einen Button siehst,

[30:47] hier, log in mit Google oder sowas, dann delegiert diese Website die Authentifizierung an Google und verlässt sich darauf, dass Google dich

[30:55] authentifiziert und der Website dann übermittelt, jo, Person X hat sich angemeldet, lasse man rein.

[31:00] Und das kann man sich natürlich auch in seinem eigenen Netzwerk nachbauen.

[31:04] Zumindest heutzutage verbreitete Implementierung für so einen OAuth-Server ist Keycloak.

[31:09] Vielleicht hast du das schon mal gehört. Das ist eine Java oder auf Basis von Java entwickelte Software, die quasi delegierte

[31:15] Authentifizierung für deine Projekte anbietet. Dann setzt du dir so einen Server auf, hat halt eine Benutzerverwaltung mit

[31:19] E-Mail-Adressen, Benutzernamen und alles mögliche kann man da eintragen und über diesen Server kannst du dann deine Benutzer an deiner Anwendung

[31:26] sich authentifizieren lassen und das Ganze kannst du natürlich auch für deine REST-APIs machen und schon kann nicht jeder Hans und Franz das Zeug

[31:31] aufrufen. Wäre vielleicht eine gute Idee.

[31:35] Nächster Punkt auf meiner Liste Software-Qualität.

[31:38] Auch schon seit Jahren eigentlich prüfungsrelevant. Jetzt noch mal besonders hervorgehoben durch die Neuordnung der IT-Berufe und inzwischen gibt es ja auch eine

[31:46] neuere ISO-Norm mit mehreren Punkten, die man hier gleich nennen könnte. Ich schmeiß nur mal so ein paar Stichwörter hin, dass du weißt, worum es geht.

[31:52] Da geht es um so was wie

[31:54] Anpassbarkeit, Wartbarkeit, Übertragbarkeit,

[31:58] Benutzbarkeit, Performance.

[32:00] Das sind so verschiedene Oberpunkte aus dem Bereich der Software-Qualität, die du dann auch gerne erklären können darfst oder zumindest erst mal nennen können

[32:07] darfst, sagen könnten, sagen können darfst, wo die stehen. Da gibt es eine ISO-Norm dafür und vielleicht ein, zwei Sachen noch am

[32:14] Beispiel erklären könntest. Das wäre eine gute Sache, denn wir müssen halt bei unserer Software-Entwicklung auch ein bisschen darauf achten, dass sie

[32:19] qualitativ hochwertig ist und da gibt es so viele Ausprägungen dieser Software-Qualität, also mindestens 20 dieser

[32:25] Stichwörter, die du da an der Stelle nennen kannst. Die schau dir bitte unbedingt an.

[32:30] Das ist für unseren Beruf wirklich wichtig.

[32:33] Nächster Punkt ist noch mal wieder völlig unabhängig von der Einbürgerungsentwicklung. Fixe und Variable Kosten.

[32:38] Was ist das? Nummer 1 werden die ganz oft mit Einzel- und Gemeinkosten verwechselt. Danach fragen wir noch häufiger aufgrund des

[32:44] Stundensatzes, wie vorhin schon erwähnt. Gehen wir die ganz kurz mal einmal durch. Fixe und Variable Kosten. Fixe Kosten sind Kosten, die

[32:51] immer anfallen, egal ob ich produziere oder nicht.

[32:55] Variable Kosten fallen nur an, wenn ich produziere.

[32:58] Ein simples Beispiel. Ich baue Tische, dann fallen die Kosten für die Tischbeine nur an, wenn ich auch einen Tisch

[33:04] produziere. Die Miete für meine Tischlerei fällt aber an, egal ob ich da drin einen Tisch produziere oder nicht. Und das wäre der Unterschied

[33:11] zwischen Fix und Variable.

[33:13] Das interessante ist also hier die Produktion. Wenn ich produziere,

[33:17] nur dann fallen diese Kosten an. Das heißt, das sind Variable Kosten. Und Fixe fallen unabhängig von der Produktion an.

[33:24] Einzel- und Gemeinkosten darf man nicht damit durcheinander bringen,

[33:28] auch wenn man alle Kosten in beide Bereiche unterschiedlich einsortieren kann. Es gibt dann quasi für

[33:32] Fix und Variable und Gemein und Einzel jeweils Beispiele, die quasi in die Schnittmenge fallen. Aber das ist jetzt hier irrelevant.

[33:38] Sondern der Unterschied hier ist, dass ich Einzelkosten genau einem

[33:42] Kostenträger zuordnen kann. Und Gemeinkosten kann ich nicht einem Kostenträger zuordnen, sondern muss ich über ein Umlageverfahren quasi auf alle

[33:50] Kostenträger

[33:53] zusammenlegen.

[33:54] Beispiel Tischbein von eben. Wenn ein Tisch genau vier Beine hat, kann ich sagen,

[33:59] diese vier Tischbeine sind exakt diesem einen Tisch zuzuordnen. Die kann ich also diesem Kostenträger-Tisch

[34:05] zurechnen und erhöhe quasi seine Kosten um vier mal Kosten eines Tischbeins. Das ist eindeutig einem Tisch zuordnenbar.

[34:13] Bleiben wir bei dem Beispiel von eben die Miete. Die Miete für meine Produktionshalle kann ich nicht einem Tisch zuordnen, weil im Laufe des Monats

[34:19] werden da vielleicht 127 Tische gebaut. Also ist nicht einer davon zuständig dafür, meine Miete zu zahlen, sondern alle in ihrer Gesamtheit.

[34:26] Und deswegen muss ich die dann umlegen auf die einzelnen Tische.

[34:30] Ganz simples Mini-Verfahren, um das nur mal kurz zu erklären. Ich nehme die Miete,

[34:35] teile die durch die Anzahl meiner produzierten Tische und dann weiß ich, wie viel jeder Tisch zur Miete beiträgt.

[34:40] Ja, ganz vereinfacht dargestellt. Es gibt natürlich noch ein anderes Verfahren, mit dem man das dann richtig macht.

[34:44] Ich glaube, das steht auch noch auf meiner Liste. Ich kann es gerade nicht sehen. Das ist der Betriebsabrechnungsbogen.

[34:49] Damit komme ich nämlich zu diesen Zuschlags-Sätzen, die am Ende dafür benutzt werden, um die Gemeinkosten auf die einzelnen Kostenträger umzurechnen.

[34:57] Wenn ich dann sage, mein Tisch ist jetzt fertig, ich habe viermal das Tischbrei draufgerechnet und weiß jetzt, der Tisch kostet irgendwie 100 Euro,

[35:03] dann kommt da oben noch ein Zuschlags-Satz, zum Beispiel für meine Fertigungsgemeinkosten drauf von, ist jetzt alles ausgedacht, 20 Prozent.

[35:10] Und dann weiß ich, aha, der Tisch kostet schon mal 120 Euro, weil die Gemeinkosten jetzt auch noch draufgeschlagen wurden.

[35:16] Und um zu diesen Gemeinkosten-Zuschlags-Sätzen zu kommen, gibt es das Verfahren des Betriebsabrechnungsbogens.

[35:22] Den darf man auch gerne erläutern können. Zumindest sollte man ihn mal gehört haben und ihn in der Prüfung nennen können.

[35:27] Das wäre schon mal viel wert. Das können auch viele Prüflinge leider nicht oder konnten es dieses Jahr nicht.

[35:32] Gut, kommen wir zurück zu etwas Technischerem. Und zwar, was ist ein Hash-Verfahren?

[35:37] Aus verschiedenen Gründen wird das abgefragt. Wenn wir zum Beispiel Passwörter in der Datenbank abspeichern, werden die gehashed.

[35:43] Oder wenn ich irgendwo eine Authentifizierung mache und dafür ein Passwort übergeben muss, dann wieder gleiches Beispiel, Passwörter werden gehashed.

[35:51] Oder ich lade Dateien runter und hashe die nochmal, um zu gucken, dass sie dann auch richtig sind.

[35:54] Oder irgendjemand hat Security aufgeschrieben, hat was von Signaturen erzählt und dann sollte man auch wissen, was ein Hash ist, weil das ist Teil einer Signatur und so weiter.

[36:02] Also es gibt verschiedene Gründe, warum wir das fragen.

[36:04] Und ein Hash-Verfahren ist ein, ich hatte schon mal eine ganze Episode zu Kryptografie, deswegen hier nur ganz, ganz kurz,

[36:10] ein mathematisches Einwegverfahren, was nicht zurückrechenbar ist.

[36:15] Deswegen nutzt man das auch, um Passwörter zu speichern.

[36:17] Ich kann aus dem Hash das Passwort nicht wieder zurückrechnen.

[36:20] Das ist eine Einwegfunktion und da sollte es so sein, dass es möglichst wenig Kollisionen gibt,

[36:26] denn bei dieser Hash-Funktion wird aus einer unendlich großen Möglichkeitenmenge an Eingangsdaten eine Ausgangsmenge fixer Länge erzeugt.

[36:34] Zum Beispiel kann ein Hash 128 Bit lang sein, dann habe ich zwar sehr, sehr, sehr viele Möglichkeiten, aber eben nicht unendlich viele, wie es da draußen an Daten gibt.

[36:43] Das heißt, es muss zwangsläufig irgendwann zu einer Kollision kommen, was bedeutet, dass zwei unterschiedliche Eingangswerte den gleichen Hash, den gleichen Ausgangswert erzeugen.

[36:54] Und wenn das so wäre, dann wäre das schlecht, denn wofür brauche ich Hash-Verfahren?

[36:58] Beispiel Passwort. Wenn ich das Passwort eingebe, um mich zu identifizieren, lasse ich über dieses Passwort das gleiche Hash-Verfahren laufen wie beim Speichern des Passworts und ich gucke, ob beide Hashes identisch sind.

[37:08] Und wenn ich mich jetzt mit einem ausgedachten Passwort anmelden kann, was zufällig den gleichen Hash produziert, dann kann ich mich halt im System einloggen, obwohl ich das nicht sollte.

[37:16] Und das wäre nicht so gut.

[37:17] Deswegen gibt es noch verschiedene andere Verfahren, die man mit reinfließen lässt, damit das Ganze ein bisschen sicherer in Anführungszeichen wird.

[37:24] Aber das soll jetzt nicht Thema sein. Hört da gerne meine Episode zu Kryptografie oder zu meinen Episoden.

[37:29] Da gibt es schon mehrere, wo ich dann auch Hash-Verfahren erkläre.

[37:32] So, nächster Punkt. Laufende Kosten des Projekts. Das vergessen auch viele Prüflinge oder machen es falsch.

[37:39] Ich glaube, ich hatte in der Episode zu den Projektdokumentationen dazu schon mal was gesagt.

[37:42] Also es kann eigentlich nicht sein, dass ein Projekt keine laufenden Kosten produziert.

[37:47] Du kennst vielleicht den Begriff der EDA-Kosten.

[37:50] Ja, der Server, der stand ja eh im Keller. Da habe ich mein Projekt drauf installiert und fertig. Dafür muss ich nichts bezahlen.

[37:55] Das ist natürlich Quatsch.

[37:56] Also laufende Kosten gibt es immer. Es ist nichts umsonst.

[37:59] Selbst wenn der Server da wirklich schon stand, wird er durch dein Projekt sicherlich irgendwie ein bisschen mehr belastet als vorher,

[38:04] zieht vielleicht ein winziges Mängchen mehr Strom, ist schneller kaputt und muss schneller abgeschrieben werden oder was auch immer.

[38:12] Also Projekte ohne laufende Kosten halte ich persönlich für unmöglich.

[38:15] Schau nochmal genau hin, wenn du so ein Projekt hast. Das kann eigentlich nicht sein.

[38:19] Nächste Frage, wieder ein bisschen kaufmännisch. Lohn und Gehalt.

[38:23] Und ich ergänze nochmal die Ausbildungsvergütung, weil die kommt nämlich auch noch dazu, denn die Azubis kriegen weder Lohn noch Gehalt.

[38:29] Und um das kurz abzugrenzen, Lohn und Gehalt. Gehalt kriege ich quasi für Anwesenheit und Lohn kriege ich für erledigte Arbeit, also für meine Leistung.

[38:37] Das heißt, ganz klassisch, Lohn wird zum Beispiel für produzierte Stück oder zum Beispiel für anwesende Stunden bezahlt.

[38:43] Ich kriege einen Stundenlohn, wenn ich acht Stunden da war, kriege ich achtmal meinen Stundenlohn.

[38:47] Wenn ich nicht komme, kriege ich nichts quasi.

[38:49] Und Gehalt ist etwas, was ich einfach regelmäßig in der gleichen Höhe immer kriege, egal ob ich arbeite oder nicht.

[38:55] Theoretisch kann ich auch einen Monat zu Hause bleiben, ich kriege trotzdem mein Gehalt.

[38:58] Also ich werde nicht auf Basis meiner Arbeitsleistung bezahlt, sondern im Prinzip einfach nur für die Anwesenheit, ganz blöd gesagt, egal ob ich da arbeite oder nicht.

[39:06] So, das ist das eine. Und dann gibt es noch die Ausbildungsvergütung.

[39:10] Das ist etwas Besonderes, weil wir Auszubildenden eigentlich nicht dafür bezahlen, dass sie uns toll Leistung bringen, weil wir sollen sie ja ausbilden.

[39:17] Also sie lernen ja noch.

[39:18] Das heißt, die Ausbildungsvergütung ist eigentlich nur dazu da, damit der Azubi seinen Lebensunterhalt so bestreiten kann und die Ausbildung vernünftig absolvieren kann.

[39:24] Der soll ja jetzt nicht riesengroße Gewinne mitmachen oder sowas, sondern er soll einfach nur seine Ausbildung absolvieren können.

[39:30] Und dabei unterstützen die Unternehmen mit der Ausbildungsvergütung.

[39:34] Von der Idee her ist die Ausbildungsvergütung aber eher dem Gehalt zuzuordnen und nicht dem Lohn.

[39:39] Weil auch wenn du mal einen Tag nicht so toll arbeitest, kriegst du ja trotzdem die gleiche Ausbildungsvergütung jeden Monat.

[39:44] Also eher Gehalt als Lohn ist das Ganze natürlich.

[39:49] So, wenn wir dann wieder zurück zur nächsten Frage kommen, da geht es dann um die Architektur der Anwendungen.

[39:54] Da wird dann oft MVC, MV4M, MVP, MV was auch immer genommen.

[39:58] Und die darf man natürlich dann auch erklären können und auch die Vor- und Nachteile erklären.

[40:02] Also viele Prüflinge sagen, ich habe eine Web-Anwendung mit MVC gemacht und können dann aber gar nicht erklären, warum.

[40:07] Ja, weil das halt jeder macht. Das ist halt blöd.

[40:10] Also wenn du schon so bestimmte benannte Architektur-Modelle benutzt, dann musst du auch erklären können, warum du das gewählt hast und was die einzelnen Buchstaben heißen.

[40:19] Das wäre auch nicht schlecht. MVC, Model-View-Controller. Ganz viele sagen irgendwie Model-View-Control.

[40:25] Weiß ich nicht, wo ein Buch steht, weiß ich nicht. Controller, so kenne ich es nur.

[40:29] Und da solltest du wenigstens erklären können, was der Unterschied ist.

[40:33] Welche Aufgabe haben die Komponenten in ihrem Zusammenspiel?

[40:36] Und wenn du ein in Anführungszeichen exklusiveres Konstrukt benutzt hast,

[40:40] wie zum Beispiel MVVM oder MVP, das ist jetzt nichts, was nie drankommt.

[40:44] Aber der Klassiker aus dem Buch ist halt eher MVC.

[40:48] Und das dann damit einmal abzugrenzen, wäre eine schöne Sache.

[40:51] Das würde ich mir einmal angucken an deiner Stelle,

[40:54] weil da ist die Chance groß, dass man danach vielleicht fragt.

[40:58] Kommen wir mal zurück zu Datenbanken.

[40:59] Das ist das nächste auf der Liste. Redundanzen.

[41:02] Die hatten wir vorhin schon besprochen beim Thema Datenbanken.

[41:04] Und da können eigentlich fast alle Prüflinge auch immer erklären,

[41:08] dass es einfach mehrfach vorhandene Daten der Datenbank sind

[41:11] und dass das schlecht ist wegen den Anomalien.

[41:13] Bla, bla, bla. Da sind wir gerade schon drauf eingegangen.

[41:15] Trotzdem fragen wir es immer mal wieder.

[41:16] Also von daher auch sauber erklären können, bitte.

[41:20] Nächster Punkt REST.

[41:22] Viele Applikationen nutzen REST.

[41:23] Wir hatten das gerade bei OAuth schon.

[41:24] Und sehr wenige Prüflinge können REST vernünftig erklären.

[41:28] Viele sagen einfach, ja, das ist halt so.

[41:29] Ich habe so HTTP gemacht und das ist REST.

[41:31] Sondern das ist es halt nicht.

[41:32] REST ist ein Architekturprinzip mit, sag ich mal, wohl definierten

[41:38] Eigenschaften oder Features, nenne ich es mal, die man da erklären kann.

[41:41] Zum Beispiel die einheitliche Schnittstelle.

[41:43] Ist etwas ganz Wichtiges dabei.

[41:45] Wenn ich zum Beispiel HTTP benutze,

[41:47] dann kann ich mir da nicht eigene HTTP Methoden ausdenken,

[41:49] sondern ich habe get, put, post, delete, um mal vier zu nennen.

[41:53] Ja, ich weiß, es gibt noch mehr.

[41:54] Und jede Ressource kann halt nur über diese sehr reduzierte Anzahl

[41:58] an Methoden abgerufen werden oder mit der interagiert werden.

[42:02] Ich kann mir keine neuen ausdenken.

[42:03] Das heißt, ich muss eigentlich gar nicht lange überlegen,

[42:06] wenn ich es mal mit Java vergleiche, wie die Methoden heißen,

[42:08] die ich aufrufen muss, weil es gibt ja nur eine Handvoll.

[42:11] Und ich darf auch keine anderen benutzen.

[42:12] So das wäre zum Beispiel ein Feature in Anführungszeichen von REST.

[42:15] Und davon gibt es noch ein paar mehr.

[42:17] Und da kann man sich gerne auch mal mit diesen Grundlagen auseinandersetzen.

[42:19] Wenn man dieses so dominierende Architekturprinzip,

[42:22] was in vielen Anbindungen heute eingesetzt wird, benutzt.

[42:25] Darf man auf Prüfungsniveau das durchaus erklären können.

[42:29] Nächster Punkt. Scrum habe ich auch einen ganzen Podcast zugemacht.

[42:32] Da spare ich mir das jetzt hier.

[42:33] Aber du solltest auf jeden Fall die drei Rollen, die drei Meetings,

[42:35] die drei alte Fakten nennen können, wie Scrum grundsätzlich funktioniert,

[42:38] dass es ein agiles Verfahren ist,

[42:40] was die Grundlagen des ergebenden Projektmanagements sind.

[42:42] Also Stichwort agiles Manifest.

[42:44] Auch dazu habe ich schon mal einen Podcast aufgenommen.

[42:46] Das ist so dominant, dieses Vorgehen.

[42:48] Selbst wenn du dein Projekt nach Wasserfall umsetzt.

[42:51] In vielen Unternehmen wird Scrum heute als Standard eingesetzt.

[42:54] Und das solltest du unbedingt erklären können.

[42:58] So, dann kommt jetzt tatsächlich auf dem nächsten Platz

[43:00] der Betriebsabrechnungsbogen, den ich eben schon angeschnitten habe.

[43:04] Und da geht es halt darum, wie du Gemeinkosten

[43:08] zu Zuschlagssätzen umwandelst,

[43:11] die du dann auf die Einzelkosten draufrechnen kannst.

[43:13] So, Grundlagen des Rechnungswesens

[43:14] solltest du auf jeden Fall in der Berufsschule gehabt haben.

[43:17] Und wenn ich dann unbedingt noch mal angucken,

[43:19] weil es halt wichtiges Prüfungswissen ist, wie gerade gesagt.

[43:22] Ganz kurz zusammengefasst, worum geht es da?

[43:25] Ich brauche eine Möglichkeit, um aus meinen Gemeinkosten

[43:27] diese Zuschlagssätze zu bekommen.

[43:28] Also ich muss die irgendwie verteilen.

[43:30] Mein Beispiel von eben wieder Miete.

[43:32] Ich habe zehn Tische produziert.

[43:34] Das heißt, im Prinzip muss jeder Tisch ein Zehntel der Miete einspielen.

[43:37] Sonst sitze ich irgendwann vor der Halle und nicht mehr drin.

[43:41] Das heißt, das wäre so das Einfachste.

[43:43] Und es gibt aber verschiedene Grundlagen,

[43:45] auf deren Basis ich diese Verteilung machen kann.

[43:48] Jetzt gerade war sehr einfach.

[43:49] Anzahl produzierter Stück, geteilt, durch, fertig.

[43:51] Aber wie kann man das noch machen?

[43:53] Ich kann zum Beispiel meine Miete

[43:55] auch aufgrund der Quadratmeterzahl der jeweiligen Bereiche verteilen.

[43:59] Also zum Beispiel mein Vertrieb hat ein kleines Büro,

[44:01] kriegt also weniger Anteil als die große Produktionshalle,

[44:03] die irgendwie 80 Prozent meines Platzes ausmacht.

[44:06] So kann ich mir ja auch vorstellen.

[44:08] Oder weiß ich nicht, meinen Kaffeeverbrauch.

[44:10] Wenn ich den umlegen will, mache ich das vielleicht anhand der Personenzahl.

[44:14] Also IT hat 40 Leute, trinkt also für 40 Leute Kaffee.

[44:17] Produktion hat 20 Leute, trinkt also nur die Hälfte an Kaffee zum Beispiel.

[44:20] Und so verteile ich das dann auf die jeweiligen Stellen.

[44:22] Ja, da gibt es verschiedene Möglichkeiten.

[44:23] Und wie man das dann genau macht und zu den Prozentzahlen kommt,

[44:26] das macht der Betriebsabrechnungsbogen.

[44:29] Nächster Punkt, Anforderungsermittlung.

[44:31] Lasten- und Pflichtenheft haben wir ganz oft,

[44:33] weil es auch sehr oft natürlich Artefakte in den Projektpräsien oder in Doku waren.

[44:37] Und da fragen wir nochmal nach.

[44:38] Und im Prinzip, ich fasse nochmal kurz zusammen,

[44:40] Lastenheft kommt vom Auftraggeber und beschreibt, dass was gemacht werden soll.

[44:45] Und das Pflichtenheft, das kommt vom Auftragnehmer

[44:48] und beschreibt, wie das gemacht werden soll.

[44:50] Also technisch sehr detailliert.

[44:52] Und wichtige Ergänzung, das Pflichtenheft ist Vertragsbestandteil.

[44:55] Dagegen wird am Ende auch die Abnahme gemacht.

[44:57] Und wenn das, was da drin steht, nicht erfüllt ist,

[44:59] ja, dann muss der Kunde auch nicht zahlen.

[45:01] So als kleiner netter Nebeneffekt dieses Pflichtenhefts.

[45:04] Das sollte man erklären können.

[45:07] Dann springen wir nochmal zurück zu Datenbanken.

[45:09] Referenzielle Integrität ist auch ein Feature,

[45:12] insbesondere von oder eigentlich nur von relationalen Datenbanken.

[45:16] Und das darf man auch erklären.

[45:18] Da kommen einige, weil das auch mit Re anfängt

[45:21] und bringen das mit Redundanz durcheinander.

[45:23] Ist es aber nicht. Redundanz, mehrfach vorhandene Daten, referenzielle Integrität.

[45:28] Integrität bedeutet ja, dass etwas in sich stimmig ist

[45:31] und referenziell ist also bezogen auf die Referenzen in der Datenbank.

[45:37] Und was sind Referenzen?

[45:38] Schlüssel, das heißt, meine Schlüsselbeziehungen müssen in sich konsistent sein.

[45:43] Bedeutet ein Schlüssel darf nicht auf einen Datensatz zeigen, den es nicht gibt.

[45:46] Ganz blöd gesagt.

[45:47] Ja, und da gibt es dann verschiedene Möglichkeiten,

[45:49] wie eine Datenbank diese referenzielle Integrität wahren kann.

[45:53] Wenn ich zum Beispiel einen Datensatz lösche, auf den noch ein Fremdschlüssel zeigt,

[45:58] dann kann die Datenbank mir das verbieten und sagen, das geht nicht.

[46:00] Wenn du den löscht, dann zeigt dieser Fremdschlüssel ins Leere.

[46:03] Und das darfst du nicht.

[46:04] Und das wäre eine Möglichkeit.

[46:08] Nächster Punkt Signatur, Signatur nicht im Sinne der elektronischen Signatur.

[46:13] Hatten wir dieses Jahr auch ein, zweimal gleich mit dem Hashwert zum Beispiel abgefragt,

[46:16] sondern die Signatur einer Methode.

[46:19] Und da zählen viele Prüflinge alles Mögliche zur Signatur, was man da so sieht.

[46:23] Also in Java zum Beispiel, irgendwie Private, Static, Final, irgendwas wird alles mit dazu genommen.

[46:29] Und das ist im engeren Sinne aber nicht richtig, sondern zur Signatur einer Methode.

[46:33] Auch dazu habe ich schon mal eine Podcast Episode aufgenommen.

[46:36] Zählt der Name und die Anzahl, Reihenfolge und der Datentyp der Parameter.

[46:42] Also eigentlich nur zwei Sachen, Name und Parameter.

[46:45] Wobei bei den Parametern drei Sachen genannt werden sollten.

[46:48] Anzahl, Reihenfolge und Datentyp.

[46:50] Simples Beispiel.

[46:51] Ich habe eine Addiere Funktion, einmal mit Int und Int und einmal mit Double und Double.

[46:56] Da unterscheidet sich der Datentyp.

[46:58] Aber die Anzahl und die Reihenfolge der Parameter bleibt gleich.

[47:00] Wie gesagt, ich kann es hier nicht ausformulieren.

[47:02] Hör da gerne die andere Podcast Episode rein.

[47:04] Der Rückgabewert insbesondere oder Rückgabetyp ist nicht Teil der Signatur.

[47:09] Auch das erkläre ich in einer anderen Podcast Episode.

[47:11] Und alles andere, Sichtbarkeitsmodifizierer, Static, Final, was es sonst noch so geben kann,

[47:16] Abstract oder was einem noch einfällt, ist alles nicht Teil der Signatur.

[47:20] Warum? Die Signatur wird benötigt, damit der Compiler eindeutig entscheiden kann,

[47:24] welche Methode er aufrufen muss.

[47:27] Und vor diesem Hintergrund kannst du dir selber auch mal überlegen,

[47:29] warum der Rückgabewert dann nicht dazugehören kann zur Signatur.

[47:33] Denn das ist dem Compiler jetzt egal, was da zurückkommt,

[47:35] um zu entscheiden, welche Methode er aufrufen muss, also wo er reinspringen muss.

[47:40] Da interessiert es ihn nicht, was da zurückkommt, um das zu entscheiden.

[47:44] So, ein paar Pünktchen haben wir noch und wir sind kurz vor der Stunde.

[47:46] Ich gebe mal Gas.

[47:48] Nächster Punkt, der auch oft gefragt wurde, Testverfahren.

[47:51] Und da geht es jetzt nicht nur um Black- und Whitebox-Tests.

[47:54] Das ist so das, was gefühlt 99 Prozent der Prüflinge gleich rausballern.

[47:57] Black- und Whitebox, Ende.

[47:58] Wenn man mal nachfragt, was der Unterschied ist,

[47:59] dann wird es schon schwieriger bei einigen Leuten.

[48:02] Aber es gibt noch so viel mehr Testverfahren.

[48:05] Ich habe sogar eine ganz eigene Podcast Episode dazu aufgenommen,

[48:07] was es da noch so gibt.

[48:09] Benutzer-Test, automatisierte Test, Unit-Integration-System-Test fallen mir so ein.

[48:14] Es gibt Smoke-Test, Regression-Test.

[48:17] Es gibt so viele unterschiedliche Arten von Tests.

[48:20] Wie gesagt, dafür habe ich eine eigene Episode aufgenommen

[48:22] und die darf man ruhig erklären können.

[48:24] Vielleicht nicht alle, aber zumindest mehr als Black- und Whitebox-Test.

[48:28] Das sollte man einem Prüfling nach drei Jahren wohl zutrauen.

[48:31] Also von daher, hör da gerne einmal rein,

[48:33] was es da noch so für zusätzliche Testverfahren gibt und was die Vor- und Nachteile sind.

[48:38] Ja, und dann bei Datenbanken gibt es ja auch so ein paar vertiefende Themen,

[48:42] sag ich mal, wie bei der Objektorientierung, Polymorphie.

[48:44] Bei Datenbanken kann man durchaus mal nach Transaktionen zum Beispiel fragen.

[48:48] Auch das hatten wir dieses Jahr ein paar Mal.

[48:49] Eine Transaktion, weil das bringen die Leute meistens durcheinander mit so einer Banktransaktion.

[48:55] Das Beispiel für Transaktion ist ja auch immer Überweisung von Konto A nach B.

[48:58] Und da sagt so der normale Mensch, ja, es ist eine Banktransaktion, da wurde Geld überwiesen.

[49:03] Aber das ist hier nicht gemeint.

[49:05] Das hatten wir jetzt dieses Mal mehrfach, dass es durcheinandergebracht wird.

[49:09] Sondern eine Datenbanktransaktion ist einfach eine Menge zusammengehöriger Datenbankabfragen,

[49:14] die entweder ganz oder gar nicht als Einheit ausgeführt werden.

[49:19] Das definiert eine Transaktion.

[49:21] Und wenn ein Teil dieser Transaktion fehlerhaft ist,

[49:24] dann wird die gesamte Transaktion zurückgerollt.

[49:26] Also alle Befehle, alle Teilbefehle der Transaktion werden wieder rückgängig gemacht.

[49:32] Und das ist ein ganz wichtiges Konzept.

[49:33] Und das Beispiel, was man da oft bringt, ist tatsächlich die Banktransaktion.

[49:38] Weil wenn ich Geld von Konto A auf Konto B übertrage,

[49:41] muss halt, wenn du dir das mal überlegst, wie du das in der Datenbank lösen würdest,

[49:44] Update Konto A minus 100 und Update Konto B plus 100.

[49:48] Und wenn mittendrin das Ding abbricht und nur das erste Update ausgeführt wird,

[49:53] dann sind 100 Euro im Nichts verschwunden.

[49:55] Weil das eine Konto hat jetzt 100 Euro weniger, aber auf dem anderen sind die nie angekommen.

[49:58] Und schon ist Geld verbrannt, in Anführungszeichen. Das kann ja nicht sein.

[50:02] Also von daher, das darf nur ganz oder gar nicht durchgeführt werden.

[50:05] Und dafür brauchen wir eine Transaktion.

[50:07] Und ja, dazu darfst du dir auch die ACID-Kriterien anschauen und erwähnen können.

[50:12] ACID, kurz vorab, ich glaube, ich hatte es schon mal in einer Podcast-Episode, heißt

[50:16] Atomicity, Consistency, Isolation und Durability.

[50:22] Darfst du auch gerne die deutschen Wörter für benutzen.

[50:24] Also Atomarität, Konsistenz, Isolation und Dauerhaftigkeit.

[50:30] Guck dir die unbedingt im Detail an und erklär die.

[50:32] Und dann kriegst du da auch eine sehr gute Note dafür.

[50:35] Nächster Punkt auf der Liste, wieder ein bisschen Code.

[50:37] Async und Await haben wir ganz oft gesehen.

[50:40] Zum Beispiel in C-Sharp-Code.

[50:41] Und ich glaube, inzwischen geht das auch in JavaScript, wenn ich mich recht erinnere.

[50:44] Das ist quasi eine einfache Möglichkeit, asynchron zu programmieren.

[50:48] Das ist sonst nämlich ganz schön schwierig.

[50:50] Und einige Programmiersprachen haben halt was Cooles eingebaut.

[50:53] Zum Beispiel C-Sharp mit Async und Await.

[50:55] Und plötzlich finden wir das irgendwie vor allen möglichen Methoden.

[50:58] Überall steht dann Async, Async, Async.

[51:00] Und beim Aufruf immer Await, Await, Await.

[51:02] Und wenn man dann fragt, warum hast du das da hingeschrieben?

[51:04] Joa, musste ich irgendwie, sonst ging das nicht.

[51:06] Und das ist natürlich dann die schlechte Antwort.

[51:08] Also bitte erklären können, wenn man sowas benutzt, was da…

[51:11] Erstens, warum man das überhaupt macht.

[51:13] Warum das technisch nötig ist.

[51:15] Und zweitens auch, warum das sinnvoll ist.

[51:17] Und kurz zusammengefasst.

[51:19] Asynchroner Code, den benutze ich natürlich hauptsächlich, wenn ich irgendwie ein UI habe.

[51:22] Was einfrieren würde, wenn ich langlaufende Operationen habe.

[51:25] Beispiel, ich klicke irgendwo im UI auf Download.

[51:27] Und der Download dauert 30 Sekunden.

[51:29] Dann würde ich natürlich in der Zwischenzeit mit meiner Applikation weiterarbeiten können.

[51:32] Und nicht 30 Sekunden warten.

[51:34] Das wäre bescheuert.

[51:35] Deswegen brauche ich sowas Asynchrones.

[51:37] Das heißt, der Download läuft im Hintergrund.

[51:39] Und irgendwann ist er dann fertig.

[51:41] Und das wird mir im UI wieder angezeigt, zum Beispiel.

[51:43] Und das programmiert man nicht mal eben so.

[51:45] Indem ich dann zum Beispiel so While True mache.

[51:48] Solange bis der Download fertig ist.

[51:49] Dann friert nämlich das UI ein.

[51:51] Und dafür brauche ich asynchrone Operationen.

[51:53] Das kann ich.

[51:54] Wenn ich das händisch machen würde, müsste ich mir da ganz schön viel zusammen programmieren.

[51:57] Und diese neuen Schlüsselwörter in einem Programmiersprach machen mir das Leben da deutlich einfacher.

[52:02] Das Problem dabei ist wieder, weil das so einfach ist.

[52:04] Schreiben die Leute das einfach hin.

[52:05] Haben aber gar nicht verstanden, warum man das braucht und was da eigentlich passiert.

[52:08] Und das kannst du halt nicht machen.

[52:09] Also bitte erklären können.

[52:11] So, was wir dann auch recht häufig hatten dieses Mal, waren Fehlerarten bei der Programmierung.

[52:16] Da haben dann viele gesagt so, hä, was soll das jetzt sein?

[52:19] Und eigentlich gar nicht überlegt.

[52:20] Und das ist für mich so ein Beispiel für eine Frage.

[52:22] Da muss man mal ein Momentchen drüber nachdenken.

[52:24] Was könnte der Prüfer oder die Prüferin denn wohl damit meinen?

[52:27] Und dann überlege ich mal aus meinem Alltag, was für Fehler gibt es denn da?

[52:30] Ja, Compile-Fehler.

[52:31] Die werden mir rot in der IDI angezeigt.

[52:33] Das wären so die ersten, die mir einfallen.

[52:36] Dann gibt es natürlich auch Laufzeit-Fehler.

[52:38] Oder auch semantische Fehler.

[52:40] Syntax-Fehler zeigt mir der Compiler an.

[52:42] Inhaltliche Fehler, wenn ich es einfach falsch programmiert habe, quasi von der Logik her.

[52:46] Dann wird mir der Compiler das natürlich nicht anzeigen.

[52:48] Das weiß er gar nicht.

[52:49] So, und diese Fehlerarten, die muss ich auch unterschiedlich behandeln.

[52:52] Syntax-Fehler prüft der Compiler.

[52:54] Da muss ich im besten Fall gar nichts machen.

[52:55] Semantische und Laufzeit-Fehler muss ich halt irgendwie durch Unit-Tests zum Beispiel absichern.

[52:59] Dass ich die nicht mache.

[53:00] Oder durch irgendwelche anderen Testverfahren.

[53:02] Und das ist eigentlich der Hintergrund der Frage.

[53:04] Also reicht es, syntaktische Fehler zu verhindern, weil der Compiler die prüft?

[53:08] Nö.

[53:09] Weil ich brauche auf jeden Fall noch Tests, um die ganzen anderen Fehler zu verwenden.

[53:11] Weil das sind nämlich die, die am Ende das Geld kosten.

[53:14] Denn wenn ich einen Syntax-Fehler mache, dann wird das Programm gar nicht übersetzt.

[53:17] Kann ich das eigentlich ausführen?

[53:18] Okay.

[53:19] Also ein Programm syntax-fehlerfrei zu machen, ist relativ einfach.

[53:22] Aber die semantischen Fehler rauszukriegen, das ist das, was interessant ist.

[53:25] Und wo viel Arbeit drin steckt.

[53:27] Eben eigene Testverfahren, eigene Testabteilungen mit Menschen, die sich das angucken und was auch immer.

[53:31] Und deswegen sollte man das durchaus abgrenzen können und die Unterschiede erklären können.

[53:37] So, ich habe auf meiner Liste noch sechs Punkte.

[53:39] Die gehen wir noch ganz fix durch.

[53:41] Wir haben heute schon vier von REST gehört.

[53:43] Da wird natürlich dann auch ganz oft mit HTTP gearbeitet.

[53:46] Auch wenn das nicht zwangsläufig so ist.

[53:47] Ich kann REST auch ohne HTTP machen.

[53:49] Wüsstest du, wenn du dich mit REST auseinandersetzt, dann könntest du das auch gut erklären in der Prüfung.

[53:53] Aber angenommen, du hättest HTTP benutzt, wie 100% der mir bisher bekannten Prüflinge das getan haben.

[53:59] Dann solltest du wenigstens ein bisschen auch was zu HTTP erklären können.

[54:02] Stichwort Status-Codes.

[54:03] Welche gibt es da so?

[54:04] Zum Beispiel den berühmten 404 für not found.

[54:07] Oder eher so auf Klassenebene.

[54:10] Alle 200er-Codes sind erfolgreich.

[54:12] Alle 400er sind Client-Fehler.

[54:14] Also 500er sind Server-Fehler und so weiter.

[54:16] Vielleicht kennst du sogar ein paar spezifische, wie den 404 gerade.

[54:19] Aber was auch ganz interessant ist, sind die HTTP-Methoden.

[54:22] Welche gibt es da?

[54:24] Die klassischen vier CRUD-Operationen.

[54:27] GET, PUT, POST, DELETE solltest du kennen.

[54:29] Gibt aber noch ein paar mehr, die man jetzt nicht so im Standard jeden Tag gebraucht.

[54:33] Also HTTP kennt nicht nur vier Methoden.

[54:35] Es gibt noch mehr.

[54:36] Die darfst du auch gerne kennen.

[54:37] Und eine, die wir dann oft hervorholen in der Prüfung, ist dann zum Beispiel die PATCH-Methode.

[54:42] Und da wird dann ganz oft diese Methode mit PUT oder POST verwechselt.

[54:47] Wir fangen alle mit P an.

[54:48] POST, PUT, PATCH.

[54:49] Machen aber alle ein bisschen was unterschiedliches.

[54:51] Und das ist ganz wichtig.

[54:52] Das POST wäre klassischerweise das CREATE bei CRUD.

[54:56] Das legt etwas Neues an.

[54:58] Das PUT wäre das UPDATE.

[55:00] Das verändert ein bestehendes Ding.

[55:03] Und das PATCH ist jetzt quasi das gleiche wie das PUT.

[55:06] Das verändert ein bestehendes.

[55:08] Aber mit dem Unterschied, dass man beim PATCH nicht das gesamte Ding, was man ändern will, nochmal mitgeben muss, sondern nur die geänderten Werte.

[55:14] Beispiel, ich habe einen Kunden auf meinem Server und dessen Namen möchte ich ändern.

[55:19] Dann könnte ich beim PATCH einfach sagen, komm, PATCH, den Kunden, Name oder neuer Name ist x.

[55:25] Beim PUT müsste ich sagen, neuer Name ist x.

[55:27] Und übrigens, der Vorname ist das und Geburtsdatum ist das und Kundennummer ist das.

[55:32] Also ich muss den gesamten Datensatz nochmal mitgeben.

[55:34] Und ich erkenne auch gar nicht, welche Felder sich jetzt geändert haben.

[55:37] Ich gebe einfach alles mit.

[55:39] Und beim PATCH kann ich wirklich quasi nur das DELTA mitgeben.

[55:42] Das macht den Traffic natürlich deutlich geringer.

[55:44] Und ich kann anhand des Pakets auch einfacher sehen, was denn überhaupt gerade verändert wird.

[55:47] Weil ich nicht einfach 27 ungeänderte Felder noch mit übertragen muss.

[55:53] Nächster Punkt CANBAN.

[55:55] Wird in vielen Abschlussprojekten als Prozess benutzt.

[55:57] Da habe ich erstmal auch kein Problem mit.

[55:59] Aber dann sollte man wenigstens die Basics von CANBAN erklären können.

[56:01] Genau wie du SCRUM kennen darfst.

[56:04] Wenn du selber CANBAN Einsatz setzt, würde ich erwarten, dass du es erklären kannst.

[56:07] Und das geht halt darüber hinaus.

[56:09] Ja, ich habe ein paar Post-its an der Wand geklebt.

[56:11] So, das ist nicht CANBAN.

[56:12] Also mindestens zwei Sachen würde ich mir wünschen.

[56:14] Nummer 1, dass es da diese Spalten gibt.

[56:16] Und dass man die auch je nach gewünschtem Prozess anpassen kann.

[56:20] Dass es nicht immer nur TO DO, DOING, DONE ist.

[56:22] Und dann bin ich fertig.

[56:23] Sondern man kann das tailern quasi auf den eigenen Bedarf.

[56:26] Und in jeder Spalte gibt es dann so ein WORK IN PROGRESS LIMIT.

[56:30] Das finde ich auch ganz wichtig bei diesem Prozess.

[56:32] Ich kann ja was sagen.

[56:33] Joa, ich habe mir jetzt mal 27 Post-its in meine Spalte geklebt und bearbeite die alle parallel.

[56:38] Weil dann habe ich nämlich genau gar keinen Prozess.

[56:40] Dann bringt mir dieses Ding nichts.

[56:42] Wenn ich genauso arbeite wie vorher und ich klebe einfach nur jedes Mal ein Post-it in meine Spalte,

[56:47] dann habe ich nichts gewonnen.

[56:48] Weil der Sinn von CANBAN ist ja, die Arbeit zu visualisieren und auch Flaschenhälse deutlich zu machen.

[56:53] Jetzt mal davon abgesehen, dass ich dann CANBAN für so ein Abschlussprojekt nicht ganz so sinnig finde,

[56:57] weil was bringt mir das jetzt, wenn ich sehe,

[56:59] ich habe einen einzigen Entwickler, der an diesem Projekt arbeitet und der hat einen Flaschenhals.

[57:04] Ja, was mache ich denn dann?

[57:05] Ich kann ja nicht mehr dazunehmen, weil es ist ja ein IHK-Abschlussprojekt.

[57:07] Also ich darf nur einen Entwickler daran arbeiten lassen.

[57:09] Also was bringt mir dann der CANBAN-Prozess?

[57:12] Eigentlich eher nichts.

[57:13] Also so ein kleiner Hint.

[57:15] Also SCRUM und CANBAN für ein Abschlussprojekt, selten geeignet,

[57:19] weil man dafür eigentlich mehrere Leute braucht.

[57:21] Und gut, aber das soll jeder selbst entscheiden.

[57:23] Wenn ihr mir das gut erklärt oder sie, ist das ja in Ordnung.

[57:25] Die meisten Prüflinien können es nicht richtig erklären.

[57:27] Und der ganze Prozess ist an dieser Stelle irgendwie sinnfrei,

[57:31] wenn ich mir dieses VIP-Limit nicht einrichte.

[57:33] Und wenn die Leute dann zum ersten Mal was von VIP-Limit hören,

[57:36] wenn sie im Fachgespräch danach gefragt werden, ja, dann ist das schlecht.

[57:40] Also bitte mit den Basics des von dir gewählten Prozesses auseinandersetzen

[57:43] und denen ein bisschen erklären können.

[57:45] Das wäre schon eine sinnvolle Sache.

[57:48] So, dann haben wir noch ein bisschen was sehr technisches oder sehr konkretes,

[57:51] nämlich TRY-CATCH, Exception Handling in der Programmierung.

[57:54] Da habe ich auch schon mal eine eigene Podcast-Episode dazu aufgenommen.

[57:57] Fehlerbehandlung heißt die.

[57:59] Das können aber auch die meisten Prüflinien sauber erklären,

[58:01] wenn man es auch täglich benutzt.

[58:03] Was dann gerne noch dazu gefragt wird, wofür brauche ich denn ein Finally z.B.?

[58:05] Ein Finally-Block können dann die meisten nicht mehr so richtig erklären.

[58:08] Und hier nochmal der Spoiler.

[58:10] Auch im Catch-Block könnte ja noch eine Exception auftreten.

[58:13] Beispiel, im Catch möchtest du die Exception loggen.

[58:16] Und dein Logging-Framework schmeißt eine Exception, weil die Festplatte voll ist.

[58:19] Ist jetzt relativ unwahrscheinlich, aber könnte trotzdem passieren.

[58:22] Dann wird der Finally-Block auf jeden Fall ausgeführt,

[58:25] auch wenn im Catch irgendein Fehler auftritt.

[58:27] Also, kurz gesagt, Finally wird immer ausgeführt.

[58:30] Egal, ob TRY oder CATCH durchlaufen wird.

[58:32] Und egal, ob auch im Catch-Block noch eine Exception läuft.

[58:36] Finally wird immer, immer, immer ausgeführt.

[58:38] Dafür sorgt die Purni-Sprache.

[58:41] So, wir sind bei den letzten drei.

[58:43] Und da habe ich noch ein bisschen was Wirtschaftliches, und zwar Abschreibungen.

[58:46] Das ist häufig eine Folgefrage zu den Einzel- und Gemeinkosten.

[58:49] Denn, wenn man sowas hat wie, du hast ja noch so ein PC auf dem Schreibtisch stehen.

[58:53] Wer hat den denn eigentlich bezahlt?

[58:55] Das ist so die Einstiegsfrage.

[58:56] Dann sollte man darauf kommen, dass der Kunde das war,

[58:59] weil der ja über die Gemeinkostenzuschläge, die wir in unsere Preise einkalkuliert haben,

[59:05] das uns bezahlt hat, quasi.

[59:07] Und wie kommt man da drauf, dass auch dieser PC in diesen Gemeinkosten drin ist?

[59:11] Ja, über Abschreibungen.

[59:13] Denn diese Büromöbel oder PCs oder Handys oder was auch immer man dann da abschreibt,

[59:18] werden eben auf diesem buchhalterischen Weg in die Gemeinkosten einberechnet.

[59:23] Simpelstes Beispiel wäre, ich kaufe irgendwie einen Rechner für 400 Euro.

[59:27] Dann kann ich den genau in dem Jahr ja direkt mit der kompletten Summe abschreiben.

[59:31] Ich glaube, aktuell ist die Grenze irgendwie bei 800 irgendwas Euro.

[59:34] Wenn ich teurere Sachen kaufe, muss ich die ja über mehrere Jahre abschreiben.

[59:38] Also über ihre Nutzungsdauer hinweg.

[59:40] Wenn ich einen PC für 3000 Euro kaufe, und der wird üblicherweise drei Jahre genutzt,

[59:45] ganz simples Beispiel, würde ich halt die nächsten drei Jahre jeweils 1000 Euro dieses PCs abschreiben.

[59:50] Und das würde dann halt über meine Gemeinkostenumlage in den Preisen meiner Produkte landen.

[59:56] So würde das ja funktionieren.

[59:58] Und dadurch, dass der Endkunde diesen Preis bezahlt für das Produkt,

[1:00:01] hat letztlich er mir meinen Arbeits-PC bezahlt.

[1:00:05] So ist die Logik dahinter.

[1:00:09] So, letzter, sorry, vorletzter Punkt, das hat mich jetzt etwas überrascht.

[1:00:13] Da hätte ich jetzt durchaus gedacht, dass wir das häufiger gefragt haben,

[1:00:16] war aber dieses Jahr ausnahmsweise mal nicht so.

[1:00:17] Sonst würde das, glaube ich, mit ganz oben stehen.

[1:00:20] Datenschutz. Ja, ganz interessant, wie wenig Prüflinge, die wir gefragt haben,

[1:00:25] das auch wirklich sauber erklären konnten.

[1:00:26] Ich wiederhole es noch mal.

[1:00:27] Datenschutz ist der Schutz personenbezogener Daten

[1:00:30] natürlicher Personen vor dem Missbrauch durch Dritte.

[1:00:33] Und dazu gehören alle Daten,

[1:00:36] die irgendwie zu einer identifizierbaren Person gehören.

[1:00:40] Zum Beispiel auch eine IP-Adresse oder eine E-Mail-Adresse.

[1:00:43] Und aber leider nicht, oder das heißt leider, aber nicht der Stundensatz.

[1:00:47] Das Gehalt wäre was anderes.

[1:00:49] Das Gehalt, das ich dieser Person zuordne, ist ein personenbezogenes Datum.

[1:00:52] Der Stundensatz eines Anwendungsentwicklers aber nicht,

[1:00:55] weil der wird zum Beispiel mit diesen Gemeinkosten und dies und das

[1:00:58] und über die Menge der Entwickler hinweg berechnet und nicht für eine einzelne Person.

[1:01:02] Also von daher, da muss man das ein bisschen abgrenzen.

[1:01:04] Ansonsten eigene Episode zu Datenschutz, Datensicherheit und Datensicherung

[1:01:08] habe ich schon aufgenommen.

[1:01:09] Unbedingt reinhören.

[1:01:10] Klassische Prüfungsthemen, nicht nur im Fachgespräch,

[1:01:13] auch in der schriftlichen Prüfung vor allem.

[1:01:15] So ein letzter Punkt heute da.

[1:01:18] Gefühlt haben wir da auch öfter schon Leute nachgefragt,

[1:01:20] aber in diesem Jahr oder in diesem Durchgang wohl nicht so viele.

[1:01:23] Variablen-Deklaration in JavaScript.

[1:01:25] Da gibt es drei Möglichkeiten.

[1:01:26] Let, war, Konst.

[1:01:27] Was ist der Unterschied?

[1:01:29] Denn man sieht dann munter im Code verstreut,

[1:01:31] mal steht da Let, mal war, mal Konst, also eigentlich eher Let oder war.

[1:01:35] Und die wenigsten können es aber richtig erklären.

[1:01:38] Ganz kurz erklärt zwischen Let und war, insbesondere der Unterschied,

[1:01:42] das ist nämlich das, was am meisten durcheinander gebracht wird, war,

[1:01:44] da wird die Variable im Scope der ganzen Funktion definiert.

[1:01:49] Und bei Let ist sie beschränkt auf ihren umgebenden Block,

[1:01:53] also quasi um die letzten geschweiften Klammern,

[1:01:56] die um diese Variable drumherum gezogen werden.

[1:01:59] Das ist also eine Scoping-Frage.

[1:02:02] Ganz einfach gesagt, Let-Variablen haben einen kleineren Scope als war-Variablen.

[1:02:06] Und Konst, um das abzugrenzen, das sagt ja schon das Schlüsselwort Konst,

[1:02:10] eine Konstante ist also nicht veränderbar, der Wert.

[1:02:13] Auch da kannst du den Scope noch mal im Detail angucken.

[1:02:15] Ich bin kein JavaScript-Entwickler.

[1:02:17] An der Stelle würde mir das hier schon reichen,

[1:02:18] wenn das jemand erklären kann.

[1:02:20] Wenn du JavaScript entwickelst,

[1:02:21] solltest du die Details auf jeden Fall noch mal angucken

[1:02:23] und noch besser erklären können, als ich das gerade gemacht habe.

[1:02:25] Am besten noch mit Beispielen.

[1:02:26] Das wäre für so eine Prüfung eigentlich ideal.

[1:02:29] So, jetzt sind wir meine Liste durchgegangen.

[1:02:31] Das waren so die häufigsten Fragen.

[1:02:33] Wir haben natürlich noch mehr gefragt.

[1:02:34] Ich habe es schon gesagt, aber ich habe jetzt die genommen,

[1:02:36] die wir mindestens zweimal gefragt haben.

[1:02:39] Und ja, dann hoch bis zum Stundensatz,

[1:02:41] den wir fast in jedem Fachgespräch gefragt haben.

[1:02:44] Ich fand das heute mal eine ganz interessante Episode,

[1:02:46] damit du mal siehst, was bei uns so gefragt wird

[1:02:48] und aus welchen verschiedenen Bereichen.

[1:02:50] Klar, die großen Bereiche bleiben immer gleich.

[1:02:52] Programmierung, Datenbanken, Wirtschaft.

[1:02:54] Ja, aber zwischendrin war ja auch schon mal was anderes dabei,

[1:02:57] wo man vielleicht nicht unbedingt so daran denkt,

[1:02:58] dass das mal gefragt wird.

[1:02:59] Also ich hoffe, es hat dir heute ein bisschen geholfen.

[1:03:02] Ich hoffe, du bereitest dich insbesondere auf diese Fragen noch mal vor.

[1:03:04] Ich habe dir meine ganzen genannten Podcast-Episoden

[1:03:06] alle verlinkt in den Shownotes unter itberufe-podcast.de

[1:03:10] slash 177.

[1:03:11] Schau da gerne rein.

[1:03:13] Und ansonsten google einfach mal die Features,

[1:03:15] die du bei deiner Programmierung benutzt.

[1:03:17] Das wäre grundsätzlich, glaube ich, eine gute Idee,

[1:03:19] wenn du das alles verstehst und auch erklären kannst.

[1:03:21] Und im Zweifel fragst du Ausbilder und Ausbilderinnen.

[1:03:23] Dafür sind die da, dass die dir das erklären,

[1:03:25] was du eigentlich so den ganzen Tag machst.

[1:03:28] So, damit ist meine Episodenreihe zur Sommerprüfung 22 beendet.

[1:03:31] Mal gucken, ob ich das im nächsten Jahr auch wieder mache,

[1:03:33] wenn es denn Neuigkeiten gibt.

[1:03:35] Denn ja, so spannend ist der Prüferjob dann auch nicht.

[1:03:38] Es sind über die letzten Jahre hinweg auch immer wieder die gleichen Fragen,

[1:03:41] natürlich, die hochkommen.

[1:03:42] Also von daher, ich glaube, diese Episode ist schon recht zeitlos.

[1:03:45] Aber wenn sich das jetzt krass ändern sollte,

[1:03:47] dann nehme ich bestimmt noch mal eine neue auf.

[1:03:49] Ich wünsche dir auf jeden Fall ganz viel Erfolg bei deiner Prüfung,

[1:03:51] falls sie noch vor dir liegt,

[1:03:53] bei Doku, Präsi und Fachgespräch natürlich.

[1:03:55] Und ich würde mich freuen, wenn du vielleicht mein Newsletter abonnierst.

[1:03:59] Da habe ich nämlich für dich zusammengestellt,

[1:04:01] über die ganzen drei Ausbildungsjahre hinweg,

[1:04:03] eine Ausbildungsbegleitung.

[1:04:04] Jede Woche mindestens kriegst du eine Mail von mir,

[1:04:07] passend zu deinem aktuellen Ausbildungsstand.

[1:04:08] Also, was du dir vielleicht aktuell mal angucken solltest,

[1:04:10] wann du dir mit der Prüfungsvorbereitung loslegen solltest und so weiter.

[1:04:13] Und das Ganze habe ich für Azubis

[1:04:15] und auch für Ausbilder und Ausbilderinnen zusammengestellt.

[1:04:17] Also, kannst dich gerne anmelden.

[1:04:19] Dann kommt als erstes eine Mail,

[1:04:21] was bist du denn eigentlich, Azubi oder Ausbilder?

[1:04:22] Und dann kriegst du passend für dich die Mails.

[1:04:24] Und das Ganze halt übers Jahr verteilt, alles komplett kostenfrei.

[1:04:28] In jeder Mail findest du einen Abmelden-Link.

[1:04:30] Wenn du keinen Bock mehr drauf hast,

[1:04:31] findest du unter it-berufepodcast.de slash Newsletter.

[1:04:34] Trag dich doch gerne ein.

[1:04:35] Und ich würde mich natürlich auch über dein Feedback freuen.

[1:04:38] Das war jetzt die dritte Episode zur Sommerprüfung.

[1:04:40] Falls du selber Prüfer, Prüferin bist und andere Erfahrungen gemacht hast,

[1:04:43] melde dich gerne bei mir.

[1:04:44] Falls du selber Prüfling warst,

[1:04:45] melde dich gerne bei mir, wenn du andere Erfahrungen gemacht hast.

[1:04:48] Würde mich freuen, insbesondere Fragen im Fachgespräch.

[1:04:51] Wenn du was ganz anderes gefragt wurdest,

[1:04:53] dass du es vielleicht als Kommentar unter die Episode packst.

[1:04:55] Also ich freue mich auf deine Rückmeldung,

[1:04:57] wenn du irgendwas beizutragen hast.

[1:04:59] In diesem Sinne für heute sage ich erst mal vielen Dank für die Aufmerksamkeit

[1:05:02] und bis zum nächsten Mal. Tschüss.