[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:19] Herzlich willkommen zum Anwendungsentwickler-Podcast,

[0:21] dem Podcast rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung.

[0:26] In dieser Episode gibt es einen Rückblick auf die Fachgespräche zur Sommerprüfung 2016.

[0:31] Viel Spaß!

[0:57] Ich hatte vor einigen Wochen schon mal zu den Dokumentationen berichtet,

[1:00] dann vor zwei Wochen zu den Projektpräsentationen und heute machen wir den Sack zu mit den Fachgesprächen.

[1:06] Auch da habe ich wieder ganz schön viel erlebt dieses Jahr.

[1:09] Ich habe mir auch einige angehört und da habe ich mir so ein paar Sachen mal aufgeschrieben,

[1:13] was ich dir mitgeben möchte, was du vielleicht in deinem Fachgespräch anders machen solltest

[1:18] und auch mal wieder so ein paar Highlights zusammengestellt, die mir besonders aufgefallen sind in den Fachgesprächen.

[1:24] Gut, ich fange einfach direkt mal an mit den Sachen, die ich mir so aufgeschrieben habe.

[1:28] Und die Punkte, die ich jetzt als erstes nenne, die sind mir also in mehreren Prüfungen aufgefallen.

[1:33] Es sind jetzt also nicht so vereinzelt, wo ich mal sage, auch hier und da kennt mal jemand XY, also Thema XY nicht,

[1:39] sondern es ist mir wirklich öfter aufgefallen.

[1:41] Und das muss einfach nicht sein und darf, glaube ich, auch nicht sein, weil es teilweise so wichtige Themen sind.

[1:46] Und da fangen wir direkt mal mit dem ersten an, nämlich dem Datenschutz.

[1:50] Der Datenschutz ist offensichtlich für viele Prüflinge ein Mysterium, möchte ich mal sagen.

[1:56] Anders kann ich mir nicht erklären, warum so wenige Leute das vernünftig erklären können.

[1:59] Das ist einfach Grundwissen für jeden ITler.

[2:03] Wir müssen uns da heute so intensiv mit auseinandersetzen.

[2:06] Es ist ständig in den Medien, dass irgendwelche Sachen gehackt werden und irgendwelche Daten online gestellt werden,

[2:12] Zugangsdaten, Passwörter, weiß der Geier was.

[2:15] Und alle Leute, was heißt alle Leute, aber einige Leute verklagen Facebook, verklagen Google und wen auch immer,

[2:21] weil der Datenschutz nicht eingehalten wird.

[2:23] Jede Website, sogar meine eigene, braucht eine Datenschutzerklärung, weil das heute einfach nicht nur zum Standard gehört,

[2:30] es ist einfach Gesetz.

[2:31] Man muss so etwas haben heutzutage.

[2:33] Und jeder ITler muss sich mit dem Datenschutz auseinandersetzen und den auch zum Beispiel in einer Abschlussprüfung erklären können.

[2:39] Insbesondere, wenn man ein Projekt umgesetzt hat, das datenschutzrelevant ist, was so ziemlich für ganz schön viele Projekte gilt.

[2:47] Insbesondere, wenn man mal wieder diese ominösen Projektverwaltungssachen und Zeiterfassungstools und so als interne Webanwendung sich anschaut.

[2:57] Denn da geht es natürlich um höchst sensible personenbezogene Daten, wie zum Beispiel die Arbeitszeit.

[3:04] Wenn ich da nicht darauf achte, dass ich zum Beispiel meine Daten vor unerlaubten Zugriff schütze, dann habe ich echt ganz schnell ein Problem.

[3:11] Und das muss ich einfach erklären können in einer Prüfung.

[3:14] Also mal grob zusammengefasst, eine klassische Frage, die so oft gestellt wird in der Abschlussprüfung, ist die Unterscheidung der drei großen Datenbegriffe,

[3:23] sage ich jetzt einfach mal, dem Datenschutz, Datensicherung und Datensicherheit.

[3:28] Und das sollte man sowas von abgrenzen können, das gibt es überhaupt nicht.

[3:32] Fangen wir vielleicht mit dem Datenschutz an, weil ich da jetzt ja schon drauf rumreite.

[3:35] Das ist der Schutz personenbezogener Daten vor dem Missbrauch durch Dritte.

[3:40] Heißt insbesondere, was sind personenbezogene Daten?

[3:43] Alle Daten, die ich auf ein Individuum, auf eine konkrete Person zurückführen kann.

[3:48] Also das ist sowas wie Name, Anschrift, Kreditkartennummer, gerne aber auch im Internet die IP-Adresse.

[3:55] Die kann ich über den Anschlussinhaber, ja genau, auf diesen zuordnen.

[3:59] Das kann ich zwar nicht selber direkt tun, aber ich könnte über einen richterlichen Beschluss und hin und her zu einem bestimmten Zeitpunkt herausfinden,

[4:06] wer war denn da hinter dieser IP-Adresse oder wer war mit dieser IP-Adresse im Internet.

[4:12] So, das sind alles solche Sachen, da muss ich dran denken.

[4:15] Und allein schon, wenn ich eine Web-Anwendung betreibe, wie zum Beispiel auf meiner eigenen Website hier,

[4:19] wo du gerade diesen Podcast heruntergeladen hast oder ihn dir gerade anhörst,

[4:23] da gibt es im Hintergrund einen Web-Server und der protokolliert auch ohne, dass ich überhaupt irgendwas dafür kann oder dass ich das angeschaltet hätte,

[4:30] automatisch jeden Zugriff auf die Seite mit IP-Adresse.

[4:34] Und das ist ein personenbezogenes Datum.

[4:36] Und sobald ich so etwas schon auf meiner Website laufen habe, brauche ich eine Datenschutzerklärung,

[4:41] muss gegebenenfalls sogar das Einverständnis des Besuchers einholen, um sowas zu erlauben und so weiter.

[4:48] Wenn du heute im Internet unterwegs bist, siehst du auf jeder Seite fast diese bescheuerte Cookie-Abfrage.

[4:53] Ist es okay, wenn Cookies auf dieser Seite verwendet werden und so weiter.

[4:57] Woher kommt der ganze Kram denn?

[4:59] Das hat ausschließlich mit den Datenschutzrichtlinien zu tun und so wenig Prüflinge können das sauber erklären, was der Sinn da ist und so weiter.

[5:05] Allein schon diese Definition, die ich gerade sagte, der Schutz personenbezogener Daten vor dem Missbau durch Dritte,

[5:10] das können die wenigsten Leute erzählen und ich weiß gar nicht warum.

[5:12] Das ist so ein wichtiger Inhalt, das wird hundertprozentig auch an den Berufsschulen gelehrt

[5:16] und das muss man einfach wissen.

[5:18] Okay, also ich reg mich schon wieder viel zu viel auf über solche grundsätzlichen Sachen.

[5:22] Wir waren noch gar nicht weiter.

[5:23] Der Datenschutz, den hatte ich jetzt abgehakt, aber es gibt ja auch noch die anderen beiden Sachen.

[5:26] Datensicherung und Datensicherheit.

[5:28] Datensicherung, da gibt es einfach ein schönes englisches Wort für, nämlich Backup.

[5:32] Und das ist damit gemeint und nichts anderes.

[5:34] Das heißt, wie schütze ich meine Daten vor Verlust im Prinzip.

[5:38] Durch meinetwegen, was weiß ich, das Haus brennt ab oder der Keller läuft voll mit Wasser

[5:43] oder irgendein Idiot haut mit dem Fuß gegen den PC und die Festplatte crasht.

[5:47] Das sind Situationen, wo ich ganz gerne meine Daten, die auf dieser Festplatte waren,

[5:50] vielleicht nochmal gern wieder hätte, damit mein Unternehmen weiterläuft.

[5:53] Und darum kümmert sich der Bereich Datensicherung.

[5:56] Das ist also ein klassisches Thema, hauptsächlich auch für die Physis unter uns,

[5:59] also die Systemintegratoren, die werden das rauf und runter gefragt.

[6:02] Aber auch Anwendungsentwickler müssen sich damit auseinandersetzen.

[6:05] Du kannst nicht eine Webanmeldung zum Beispiel bauen und deine Datenbank nicht backuppen,

[6:09] wenn man das überhaupt so sagen kann, also einfach sichern.

[6:11] Das geht nicht. Du musst dich darum kümmern.

[6:13] Du kannst nicht einfach sagen, hier ist eine Datenbank, ob die gesichert wird oder nicht, interessiert mich nicht.

[6:17] Ja, das gehört auf jeden Fall auch für Anwendungsentwickler zum Alltag dazu.

[6:21] Und das muss man auch abgrenzen können.

[6:23] Und das wären dann so Klassiker in der Prüfung wie, was für Verfahren gibt es denn da oder für Vorgehensweisen,

[6:28] sage ich mal, Großvater-Vater-Sohn-Prinzip meinetwegen oder inkrementelles und voll bergab unterscheiden und solche Sachen.

[6:34] Und das erwarte ich auch von einem Anwendungsentwickler im Fachgespräch, dass man sowas weiß.

[6:39] Also Datenschutz, Datensicherung abgehakt, dann kommt jetzt die Datensicherheit.

[6:43] Und das wäre dann der Schutz der Daten vor unerlaubtem Zugriff, sei es durch interne oder auch durch externe.

[6:49] Das ist ganz egal.

[6:50] Wenn zum Beispiel meine Personalbuchhaltung irgendwelche Mitarbeitertabellen pflegt, dann soll die vielleicht nicht die Passwörter sehen können.

[6:56] Ja, solche Sachen gehören dazu.

[6:58] Das heißt, ich werde niemals Passwörter im Klartext in meiner Datenbank zum Beispiel hinterlegen.

[7:02] Oder dann sind wir wieder bei so einem schönen Beispiel für eine sinnvolle 1 zu 1 Beziehung in einer Datenbank.

[7:08] Ich würde nämlich genau bei sowas wie Personal solche Sachen wie Gehaltsinformationen in die eine Tabelle und Sachen wie Log-In-Informationen in die andere Tabelle packen.

[7:16] Warum? Weil der Administrator das Passwort ändern soll, aber nicht das Gehalt sehen darf.

[7:20] Und die Sachbearbeiterin darf das Gehalt vielleicht sehen, aber nicht das Passwort.

[7:24] Und solche Sachen, das ist Datensicherheit.

[7:27] Oder auch Zutrittskontrolle gehört auch dazu.

[7:29] Also physikalische Verfahren, aber auch Softwareverfahren.

[7:33] Also wie zum Beispiel 2-Faktor-Authentifizierung und solche Geschichten.

[7:36] Authentifizierung und Autorisierung zum Beispiel.

[7:40] Solche Sachen abgrenzen können.

[7:41] Verschlüsselungsverfahren und so weiter.

[7:43] Das sind Dinge, die zu Datensicherheit gehören.

[7:46] Und diese 3 Begriffe muss jeder ITler drauf haben und auch sauber abgrenzen können.

[7:52] Und ich weiß nicht, wie viele Leute wir gehabt haben, wo Datensicherung und Schutz und Sicherheit und alles wild durcheinander geworfen wurde.

[8:00] Das geht einfach nicht.

[8:01] Das sind so wichtige Begriffe.

[8:03] Auch die Datensicherung natürlich.

[8:05] Wenn der Server abbraucht und ich kann meine Daten nicht wiederherstellen.

[8:09] Also ich werde einen Kopf kürzer gemacht in der Firma, wenn die Leute nicht mehr arbeiten können, weil ich vergessen habe, ein Backup zu machen zum Beispiel.

[8:14] Oder Datensicherheit. Auch das geht ständig durch die Medien, dass wieder irgendwo eingebrochen wurde.

[8:19] Oder dass Passwörter im Klartext abgelegt wurden und so weiter.

[8:22] Das sind solche Sachen, die gehen einfach nicht mehr im Jahr 2016.

[8:26] Und da muss sich auch jeder Anwendungsentwickler mit auskennen.

[8:29] Also bitte, schau dir diese 3 Begriffe an und gerne auch im Detail.

[8:33] Nicht nur so oberflächlich, wie ich sie jetzt gerade beschrieben habe.

[8:36] Aber sowas, was ich gerade gesagt habe, würde ich als Minimum im Fachgespräch unbedingt erwarten von jedem Prüfling.

[8:43] Weiterer Klassiker, den so gut wie niemand richtig beantworten kann, ist die Frage nach dem Stundensatz.

[8:49] Ich habe schon mal eine eigene Episode dazu gemacht, weil das so wichtig ist.

[8:53] Ich meine, so viele wirtschaftliche Fragen stellen wir nicht im Fachgespräch oder die gibt es vielleicht auch gar nicht im Fachgespräch.

[8:58] Das ist ja ein technischer Beruf hier und da wird sicherlich der Fokus auf anderen Bereichen liegen als der Wirtschaft.

[9:03] Aber die Wirtschaft gehört dazu. Wir haben hier einen kaufmännischen Beruf und da muss man mindestens mal erklären können, wie viel man denn die Stunde kostet und warum.

[9:11] Und auch da waren wieder die wildesten Sachen dabei.

[9:14] Ich weiß gar nicht mehr, was da für abstruse Geschichten im Stundensatz drin waren.

[9:20] Und das Highlight war ja auch, dass ein Azubi in seiner Projektdokumentation 120 Euro Stundensatz für einen Azubi angesetzt hat.

[9:27] Das ist doch wirklich völlig wahnsinnig.

[9:29] Das kann ich mir einfach nicht vorstellen, dass irgendein Unternehmen sowas ansetzt und damit dann beim Kunden durchkommt.

[9:34] So, wir haben den Azubi hier mal ein bisschen Webdesign machen lassen, 120 Euro die Stunde übrigens.

[9:38] Also tut mir leid, das ist einfach völlig realitätsfehlend und das muss man beantworten können.

[9:43] Ich will da jetzt gar nicht mehr im Detail drauf eingehen.

[9:45] Ich habe eine ganze Episode zum Stundensatz gemacht, übrigens auch zur Gehaltsabrechnung.

[9:49] Beides werde ich auf jeden Fall nochmal in die Shownotes packen.

[9:52] Hör da auf jeden Fall vorm Fachgespräch nochmal rein, dass du das sauber erklären kannst.

[9:58] Das ist eine so häufige Frage im Fachgespräch.

[10:01] Unbedingt nochmal anschauen.

[10:03] Weiterer Klassiker, der gar nicht ging.

[10:05] Testverfahren oder irgendwas anderes zur Qualitätssicherung.

[10:08] Das einzige, was die Leute wissen, ist Blackbox, Whitebox.

[10:11] So, und das war's dann auch.

[10:13] Und es gibt noch tausend andere Sachen, die man können muss.

[10:15] Wenigstens Blackbox und Whitebox-Tests sauber voneinander abgrenzen.

[10:18] Auch das ist ja schon teilweise echt schwierig bei den Leuten.

[10:20] Aber andere Qualitätssicherungsmaßnahmen wie Codereviews.

[10:23] Ich habe es, glaube ich, bei der Doku-Episode schon mal gesagt.

[10:25] Jeder Hans und Franz macht neuerdings in seiner Projektdokumentation ein Codereview.

[10:30] Aber keiner kann erklären, was überhaupt dabei passiert.

[10:32] Und was der Sinn dahinter ist.

[10:34] Und dass da irgendwie auch gar nichts rauskommt.

[10:36] Da wird einfach ein Codereview gemacht. Ja, das hat drei Stunden gedauert.

[10:38] Und was ist jetzt das Ergebnis? Weiß man nicht.

[10:41] Ist nichts mehr rausgekommen. War alles gut.

[10:43] Der Azubi hat perfekten Code geschrieben.

[10:45] Und dann hat sich jetzt einfach nur der Ausbilder nochmal durchgelesen und schwupp.

[10:47] War's das.

[10:48] So, und das sind einfach Dinge, die gehen einfach nicht.

[10:50] Allein schon die verschiedenen Testverfahren, da kann man ne Stunde drüber reden.

[10:53] Was ist mit Fahrtüberdeckung, Anweisungsüberdeckung.

[10:56] Solche Geschichten.

[10:57] Oder Schreibtischtest.

[10:59] Oder meinetwegen Unit-Tests und Integrationstests und Abnahme.

[11:03] Und weiß der Geier, was es da alles an Möglichkeiten gibt.

[11:05] Also unbedingt drauf schaffen.

[11:07] Qualitätssicherung, die gehört zum Grundwissen jedes Anwendungsentwicklers.

[11:11] Wir programmieren hier nicht einfach Code runter und sind dann fertig und geben den Kram ab.

[11:15] Sondern wir müssen denen auch Qualität sichern.

[11:17] Und da gibt es methodische Verfahren, wie ich sowas tue bei der Softwareentwicklung.

[11:22] Und das erwarte ich von jedem Prüfling, das zu kennen.

[11:25] Insbesondere schau dir mal die entsprechende ISO-Norm an.

[11:28] Packe ich auch in die Shownotes zur Qualitätssicherung in der Softwareentwicklung.

[11:33] Die Dinge kann man durchaus auswendig kennen, die da drin stehen.

[11:36] Das haben wir auch schon öfter mal gefragt.

[11:38] Nennen sie doch mal ein paar Möglichkeiten, wie ich qualitativen Code erkenne.

[11:42] Oder welche Eigenschaften muss der haben und sowas.

[11:45] Und das kann ich wunderbar aus der ISO-Norm aufzählen.

[11:48] Die muss ich nur auswendig lernen.

[11:50] Und das gehört für mich einfach zum Grundwissen.

[11:52] Da gibt es auch keine Ausrede, wenn man sowas nicht beherrscht.

[11:55] Also schau dir das Ding nochmal an, bevor du ins Fachgespräch gehst.

[11:58] Absolutes Grundwissen.

[11:59] Wo wir schon bei Grundwissen sind?

[12:01] MVC.

[12:02] Mensch, es kann nicht wahr sein.

[12:04] Ich sag mal, gefühlte 99% der Anwendungen heute werden mit MVC entwickelt.

[12:09] Zumindest die Prüfung, die ich jetzt gesehen habe.

[12:11] Und ein Bruchteil der Prüflinge kann das sauber abgrenzen, was überhaupt das MVC heißt.

[12:16] Allein da geht es schon los.

[12:18] Model-View-Controlling.

[12:20] Oder ich weiß nicht, was wir für Dinger gehört haben.

[12:22] Also unglaublich.

[12:23] Model-View-Controller heißt das Zeug.

[12:25] Und das hat auch einen Sinn.

[12:26] Und die Vorteile dieses Architekturmusters sollte man erklären können, wenn man seine Anwendung damit umgesetzt hat.

[12:32] Aber auch wenn man sie nicht damit umgesetzt hat, sollte man sie erklären.

[12:34] Weil es einfach ein dominierendes Prinzip heutzutage ist.

[12:38] Und das würde ich genauso wie zum Beispiel ein ER-Modell oder sonst was erwarten von jedem Prüfling, dass er sowas erklären kann.

[12:44] Also, setz dich damit auseinander.

[12:46] Wie spielen die Komponenten zusammen?

[12:48] Wer greift auf wen zu?

[12:49] Wer darf überhaupt auf wen zugreifen?

[12:51] Wo ist die Logik drin zum Beispiel?

[12:53] Ganz grundsätzliche Frage.

[12:55] Und da kommt häufig als Antwort, der Controller enthält die Logik, die fachliche Logik, die Business-Logik.

[13:00] Und das ist einfach völliger Quatsch.

[13:02] Die Logik gehört nicht in den Controller.

[13:04] Die gehört ins Model.

[13:05] Sonst ist das Model nicht wiederverwendbar.

[13:07] Der Controller ist dumm.

[13:08] Der macht gar nichts.

[13:09] Der verdrahtet Model und View.

[13:11] Und dann ist auch Feierabend.

[13:12] Das macht der Controller.

[13:13] Wenn ich mir solche Dinge angucke wie in Rails, zum Beispiel Ruby on Rails, guckt ihr mal den Controller an.

[13:17] Da sind ein paar Zeilen Code.

[13:19] Da steht kaum was drin.

[13:20] Der Rest wird drumherum generiert und meine Logik liegt im Model.

[13:23] Und das View zeigt das Zeug nur noch an.

[13:25] Und dann hat der Controller nichts zu tun.

[13:27] Der muss nur Sachen verdrahten.

[13:28] Und mehr macht er nicht.

[13:29] Und da habe ich aber ganz oft immer die Frage, zum Beispiel im Fachgespräch, wo findet eine Validierung statt?

[13:35] Also meine fachliche Validierung meint wegen, dass ein Alter nicht größer sein darf als 80.

[13:39] Weil wir nur bis 80 irgendwen versichern oder weiß der Geier was.

[13:42] Und das muss im Model stattfinden.

[13:45] Zusätzlich dazu darf eine Validierung gerne auch im View stattfinden.

[13:49] Wird heute auch häufig gemacht.

[13:50] Mit JavaScript zum Beispiel in der Web-Anwendung, dass ich im View direkt validiere, ob meine Eingabe korrekt ist oder nicht.

[13:55] Damit nicht erst die ganze Seite zum Server geschickt werden muss und neu ausgeliefert werden muss.

[14:00] Das kann man auch zum Beispiel mit AJAX mal eben schnell im Frontend schon klären.

[14:04] Könnte man tun.

[14:05] Aber nichtsdestotrotz gehört die unbedingt ins Model, die Validierungslogik.

[14:09] Überlegt doch mal, was ist der Sinn von MVC?

[14:11] Ich kann die einzelnen Komponenten austauschen.

[14:13] Und wenn ich jetzt auf einmal meine View oder meinen Controller austausche und die greifen auf ein Model zu, das keine Validierung enthält,

[14:19] dann sind die auf einmal kaputte Daten in meiner Datenbank, weil das Model nicht prüft.

[14:23] Das geht nicht.

[14:24] Also das Model muss unbedingt validieren und die gesamte Business-Logik gehört auch in dieses Model rein.

[14:29] Dann sind die Komponenten einfach nicht wiederverwendbar.

[14:32] Dann ist auch erstaunlich oft absolutes Basiswissen im Bereich von Encoding, also von Zeichensatz und Kodierung und so nicht vorhanden.

[14:39] Wie oft wir zum Beispiel Umlautproblematiken im Source-Code oder sowas haben.

[14:43] Source-Code-Beispiele, da sind die Umlaute kaputt.

[14:45] Oder es werden irgendwelche Oberflächen gezeigt und das sind dann auf einmal zwei komische Zeichen und so weiter.

[14:51] Ich habe schon mal eine ganze Episode zum Bereich Encoding gemacht.

[14:54] Da will ich jetzt nicht nochmal wieder im Detail drauf eingehen.

[14:57] Aber sowas wie ASCII und Unicode, das muss jeder Anwendungsentwickler auseinanderhalten können.

[15:01] Damit arbeiten wir jeden Tag.

[15:03] Sobald ich irgendwelche Ein- oder Ausgaben in meinem Programm mache, muss ich wissen, wie die kodiert sind.

[15:08] Das geht schon los, wenn ich eine Textdatei öffne.

[15:10] Da kann ich gar nicht anders als das Encoding eingeben.

[15:13] Das ist so wichtig heutzutage.

[15:15] Und das muss man einfach beherrschen.

[15:17] Und wenn ich dann solche Dinger sehe und die Leute können das nicht erklären, warum da jetzt gerade was kaputt gegangen ist oder nicht richtig angezeigt wird,

[15:23] also das kann ich nicht nachvollziehen.

[15:25] Das muss einfach in so einer Ausbildung auch vermittelt werden, weil das ist sowas wie Zeilenumbrüche.

[15:30] Die unterschiedlichen Zeilenumbrüche auf den Betriebssystemen, die muss ich als Anwendungsentwickler in- und auswendig kennen.

[15:35] Und genau so sieht es aus mit dem Encoding.

[15:37] Sonst kann ich doch in der Praxis kaum arbeiten.

[15:39] Ich weiß nicht, wie die Leute das hinkriegen.

[15:41] Die haben offensichtlich in drei Jahren nicht gelernt, was Unicode ist.

[15:43] Wie kriegen die überhaupt eine Textdatei geöffnet, frage ich mich dann immer.

[15:47] Also, hör mal rein in meine Episode zum Encoding.

[15:50] Steht in den Shownotes, wie der ganze Rest, den ich schon erwähnt habe natürlich auch.

[15:54] Ja, kommen wir zu einem modernen Thema.

[15:57] Und das war dieses Jahr so, dass gefühlte 50% der Projekte mit Kanban auf Deutsch umgesetzt wurden.

[16:06] Und das ist wohl der totale Hype aktuell.

[16:08] Letztes Jahr oder Jahre davor war immer Scrum.

[16:10] Jeder hat Scrum gemacht oder Extreme Programming und das als Scrum falsch verstanden.

[16:13] Hatten wir auch schon oft.

[16:14] Aber dieses Jahr war Kanban rauf und runter.

[16:16] Einige haben auch Scrum gemacht oder beziehungsweise gesagt, dass sie Scrum gemacht haben,

[16:20] haben aber eigentlich Kanban gemacht oder wahlweise auch umgekehrt.

[16:22] Das wird alles wild durcheinander geschmissen.

[16:24] Das ist offensichtlich alles das Gleiche heutzutage.

[16:26] Interessiert sich keiner mehr dafür, ob ich jetzt Scrum oder Kanban mache.

[16:29] Das ist alles agil. Agil entwickeln wir heute wunderbar.

[16:31] Aber keiner, also ich will jetzt hier nicht sagen keine Sau, aber kein Mensch kann das hier erklären, was es ist.

[16:37] Und das ist wirklich schrecklich.

[16:38] Genauso wie es in den Jahren zuvor bei Scrum war und die Leute nicht erklären konnten, was ein Scrum Master ist.

[16:43] Das sind so die ersten Begriffe, die mir einfallen, wenn ich was von Scrum höre.

[16:47] Da erwarte ich einfach, dass die Leute das beherrschen, wenn sie sagen, ich habe mein 70-Stunden-Projekt nach Scrum umgesetzt.

[16:52] Und genau das Gleiche gilt für Kanban.

[16:54] Aber wenn ich dann im Fachgespräch als erstes frage, ja Kanban, können Sie mal ein bisschen was erklären?

[16:58] Ja, da habe ich so ein Kanban-Board und da schiebe ich Karten von links nach rechts.

[17:02] Und wenn ich dann anfange mit den absoluten Basics, wie zum Beispiel WIP-Limit, also das Limit von meinem Work in Progress,

[17:08] also ein zentraler Bestandteil von Kanban, die Leute wissen es einfach nicht.

[17:13] Das ist ungefähr so, wie Scrum Master bei Scrum nicht erklären können.

[17:16] Das ist einfach lächerlich.

[17:17] Das heißt für mich, die Leute wissen überhaupt gar nicht, was sie da eigentlich angewendet haben.

[17:22] Kanban ist wieder so ein Mode-Wort, so ein Hype-Ding.

[17:24] Das macht man heute so, aber erklären kann es niemand.

[17:27] Das ist wirklich traurig.

[17:28] Also wenn ich schon in meiner Projektdokumentation schreibe, ich habe mit Kanban gearbeitet,

[17:31] dann erwarte ich, dass ich die Grundlagen dieses Prozesses auch erklären kann.

[17:35] Und erklären kann, was der Vorteil zum Beispiel ist.

[17:37] Und dann würde ich vielleicht auch darauf kommen, dass Kanban bei so einer Softwareentwicklung vielleicht gar nicht so sinnvoll ist,

[17:41] wenn ich als Einziger an diesem Projekt arbeite.

[17:44] Warum brauche ich dann ein Kanban-Board?

[17:46] Das ist einfach lächerlich.

[17:47] Das ist genau dafür da, wenn ich ein Projekt oder einen Prozess mit mehreren Beteiligten habe

[17:52] und ich möchte zum Beispiel meine Flaschenhälse aufzeichnen.

[17:55] Und genau dafür brauche ich auch meinen WIP-Limit.

[17:58] Und wenn ich solche Sachen schon nicht erklären kann, also ich kann das immer nicht nachvollziehen.

[18:02] Überleg dir bei deinem Abschlussprojekt, was für einen Prozess du benutzt.

[18:06] Es ist auch wichtig, dass du einem Prozess folgst.

[18:08] Das ist alles völlig in Ordnung.

[18:10] Aber sei dir bitte bewusst, was dieser Prozess heißt, was den ausmacht und wie du den eigentlich anwenden müsstest,

[18:17] wenn du ihn verstanden hättest.

[18:19] Also bitte nutze nicht irgendein Hype-Zeug, nur weil jeder das angeblich macht,

[18:24] ohne richtig verstanden zu haben, was dahinter steckt.

[18:27] Das geht einfach nicht.

[18:28] Und das kommt auch raus.

[18:29] Also ohne Witz, ich habe glaube ich drei oder vier Mal die Frage gestellt, was ist denn das WIP-Limit?

[18:34] Und da kam nicht einmal eine Antwort.

[18:37] Obwohl die alle mit Kanban angeblich gearbeitet haben.

[18:39] Das geht einfach nicht.

[18:41] Gilt aber nicht nur für Kanban.

[18:43] Ich hatte es gerade schon gesagt, bei Scrum war es genau das gleiche.

[18:45] Und inzwischen sagen auch viele Leute einfach nur, ich habe Agile entwickelt.

[18:48] Da kommt gar kein konkreter Prozess mehr, das ist einfach Agile.

[18:51] So was genau dahinter steht, kann aber auch trotzdem keiner erklären.

[18:54] Also wenn ich schon sowas sage wie Agile, dann muss ich wenigstens grundlegende Sachen erklären können.

[18:58] Wie zum Beispiel die Werte oder die Prinzipien, die es bei diesen Agilen Prozessen gibt und die die alle vereint.

[19:04] Zum Beispiel das Agile Manifest.

[19:06] Das ist ja wirklich mindestens das Grundwissen, wozu ich was sagen muss in meiner Prüfung.

[19:11] Ich kann doch nicht einfach mit Wörtern rumschmeißen und ich weiß null, was dahinter steht.

[19:16] Das ist mir einfach unbegreiflich, wieso die Leute das machen.

[19:19] Ich weiß nicht, ob die Leute denken, wenn ich da irgendwie Agile und Scrum und Kanban reinschreibe, kriege ich eine bessere Note oder irgendwas.

[19:25] Das ist doch völliger Schmarrn.

[19:26] Wenn im Fachgespräch dann rauskommt, dass ich null davon verstanden habe, dann kriege ich doch keine gute Note dafür.

[19:31] Es artet hier aktuell schon wieder aus.

[19:34] Ich kriege schon wieder so einen Hals, wenn ich einfach an diese Fachgespräche denke.

[19:37] Das ist mir einfach unbegreiflich.

[19:39] So, okay. Beruhigen wir uns mal wieder.

[19:42] Dann geht es zu einem schönen fachlichen oder technischen Thema weiter.

[19:46] Denn das ist auch eine klassische Frage, die wir so oft stellen, die ich auch schon in meinen Podcast-Episoden hier besprochen habe zum Thema Datenbanken.

[19:53] Beispiele für Kardinalitäten bei der Datenbankmodellierung.

[19:58] Ich weiß nicht, wie viele Leute nicht ein sinnvolles Beispiel nennen konnten für eine 1-zu-1-Beziehung.

[20:05] Bei M-zu-N und 1-zu-N wird es teilweise schon schwierig.

[20:08] Da werden die Sachen schon durcheinandergeschmissen.

[20:10] Da drücke ich vielleicht noch ein Auge zu.

[20:12] Bei 1-zu-1 war es wirklich sehr, sehr häufig, dass die Leute nicht mal ansatzweise ein Beispiel nennen konnten.

[20:18] Und das, was ich schon vorhin gesagt habe bei der Datensicherheit, dass ich zum Beispiel Login und Benutzerdaten,

[20:25] Benutzerdaten wäre ja quasi das Login, aber meine Mitarbeiterdaten zum Beispiel.

[20:28] Und jeder Mitarbeiter hat ein Login und umgekehrt.

[20:31] Das wäre eine 1-zu-1-Beziehung. Das wäre auch eine sinnvolle 1-zu-1-Beziehung.

[20:35] Dieses Jahr habe ich noch eine schöne dazu gelernt.

[20:37] zum Beispiel Land und Hauptstadt. Die finde ich deswegen zum Beispiel so schön, weil Stadt und

[20:42] Land halt völlig unterschiedliche Entitäten sind, die auch unterschiedliche Attribute haben. Da komme

[20:47] ich nicht mal auf die Idee, die zusammen in eine Tabelle zu packen. Viele Prüflinge sind zum

[20:51] Beispiel der Meinung, dass Log-In-Daten und Mitarbeiterinformationen, also Name, Adresse

[20:55] und sowas, durchaus ja in eine Tabelle gepackt werden kann. Warum denn nicht? Gehört doch zusammen.

[20:59] Aber das kommt beim Land und bei der Stadt zum Beispiel niemandem in den Sinn, weil es einfach

[21:05] zwei unterschiedliche Dinge sind. Aber da kann man schöne 1-zu-1-Beziehungen zeigen, weil ein

[21:09] Land definitiv nur eine Hauptstadt hat und eine Stadt auch nur die Hauptstadt eines Landes sein

[21:13] kann. Also klassische 1-zu-1-Beziehungen. Wenn dir nichts anderes einfällt, nimm doch die. Damit kann

[21:19] man wirklich super sauber begründen, was eine sinnvolle 1-zu-1-Beziehung ist. Denn, das muss

[21:24] man ja auch dazu sagen, wenn du die Sachen zum Beispiel im Podcast hörst und einfach auswendig

[21:28] lernst und sagst, ja, 1-zu-1-Beziehungen wäre Benutzer-Log-In. Und dann frage ich im Fachgespräch

[21:33] warum. Warum ist das denn sinnvoll? Warum packen wir das nicht in eine Tabelle? Und dann kommt,

[21:37] habe ich im Podcast gehört? Da geht natürlich nicht. Also, wenn du das als Beispiel nimmst,

[21:42] musst du natürlich auch auf die Fragen dazu gefasst sein. Wenn ich dich dann frage, warum du das so

[21:47] modellierst und es nicht in eine Tabelle packst, dann erwarte ich natürlich auch eine fundierte

[21:50] und saubere Antwort darauf. Die habe ich gerade geliefert. Datenschutz, Datensicherheit, kann man

[21:56] alles anführen, um Benutzer- und Log-In auseinanderzuziehen. Aber wenn du diese Frage

[22:01] nicht provozieren willst im Fachgespräch, nimm doch einfach Hauptstadt-Land. Das ist ein super

[22:06] Beispiel, versteht man sofort und man kommt auch nicht in die Bedrulle, zu erklären, warum man es

[22:10] denn vielleicht nicht doch besser in eine Tabelle packen könnte. Okay, und letzter Punkt, der mir

[22:16] häufig auffällt, weil den einfach so gut wie jeder in seinem Projekt benutzt heutzutage. Das

[22:20] wird einfach, oder in vielen Sprachen ist das einfach ein Standardwerkzeug, nämlich generics,

[22:24] generische Klassen. Ich rede da glaube ich auch schon seit Jahren davon. Das ist so was wie in

[22:31] Java die List of irgendwas, eine List of Strings zum Beispiel. Gibt es genauso auch in C Sharp oder

[22:35] in anderen statisch typisierten Sprachen. Also Listen oder, sag ich mal, so Collections, die dann

[22:40] eben typisiert sind, wo nur noch ein Datentyp dann reinpasst. Und das sind Dinge, das gilt nicht nur

[22:46] für Listen, das gilt auch für alles mögliche andere, was halt eben, also generische Klassen

[22:49] in C Sharp und Java zum Beispiel mit diesen spitzen Klammern, ja, List und dann spitze

[22:53] Klammer auf, String, spitze Klammer zu. Von den Dingern rede ich hier. Und das sind so dominante

[23:00] oder prominente Quellcode-Beispiele, sag ich mal. Das ist fast in jedem Code irgendwie drin, den ich

[23:05] irgendwo sehe, aber die wenigsten Leute können sauber erklären, was dahinter steckt. Und ich

[23:09] habe es auch schon, glaube ich, in mehreren Episoden erklärt, was es ist. Generische Klassen stellen

[23:13] generische, also allgemeingültige Algorithmen bereit und zwar unabhängig von einem konkreten

[23:18] Datentyp. Das ist genau der Sinn. Ich kann den Algorithmus einmal definieren und ihn dann auf

[23:23] mehrere Datentypen anwenden. Beispiel Sortieralgorithmus. Ich kann einen Sortieralgorithmus

[23:28] super programmieren und das ist ganz egal, ob der Sortieralgorithmus Zahlen oder Texte sortiert.

[23:32] Solange ich zwei Elemente vergleichen kann, also zum Beispiel ob eine Zahl größer oder kleiner ist

[23:36] als eine andere, beziehungsweise ein String größer oder kleiner ist als ein anderer, dann kann ich

[23:40] auch einen Sortieralgorithmus darauf anwenden. Also kann ich den einmal programmieren und dann

[23:44] typisieren, sodass ich sagen kann, dieser Sortieralgorithmus sortiert jetzt aber bitte nur

[23:48] Strings und dann kann ich nicht aus Versehen dann noch eine Zahl dazwischen mogeln zum Beispiel,

[23:52] ja. Ich habe also typsichere Klassen, die aber allgemeingültige, also typunabhängige

[23:58] Implementierungen anbieten und genau das sind generische Klassen. Übrigens auch eine Frage,

[24:04] die ich in meinem Hörbuch zur Prüfungsvorbereitung beantworte unter

[24:08] dasperfektefachgespräch.de kannst du dir mal anschauen, wenn du möchtest.

[24:12] So, dann habe ich zum Ende nochmal so ein paar Highlights zusammengetragen aus einzelnen

[24:18] Fachgesprächen, die mir so in der Erinnerung geblieben sind und da fangen wir dann direkt mit

[24:23] dem Klassiker an. Ich benutze irgendwas, was ich aber überhaupt nicht erklären kann. Und

[24:27] mein Lieblingsgebiet aktuell ist ja Java EE, weil ich selber auch so viel mit Java aktuell arbeite

[24:32] und dann ist das natürlich eine Steilvorlage, wenn da ein Prüfling im Java EE Projekt ankommt,

[24:37] ja. Und dann fahre ich natürlich auch mal in die Details rein. Also was ist denn JPA,

[24:40] JSF und so weiter. Wie hängen die Sachen zusammen? Context and Dependency Injection und so weiter.

[24:44] Da geht es natürlich dann richtig los. Und wenn dann natürlich nix kommt, dann ist es schwierig.

[24:48] Und wenn das auch schon bei den Einstiegsfragen, die ich gerade gesagt habe, zum Beispiel,

[24:51] was ist JPA und JSF, wenn dann kommt, ähm, weiß ich nicht, dann sieht es aber übel aus. Denn das

[24:58] kann eigentlich nur heißen, dass der Typ das entweder gar nicht selber umgesetzt hat oder er

[25:02] einfach irgendwie copy-paste-mäßig was zusammengeklickt hat, aber überhaupt gar nicht versteht, was er da

[25:07] getan hat. Denn wenn ich mit Java EE arbeite und ich weiß nicht mal, wie die Persistenzschicht heißt,

[25:12] nämlich JPA, oder die Frontend-Schicht, nämlich JSF, dann weiß ich nicht, wie überhaupt eine

[25:18] lauffähige Anwendung zustande kommt. Wenn ich diese absoluten Basissachen nicht kenne,

[25:22] das kann ich mir einfach nicht erklären, wie sowas läuft. Das scheint in den Unternehmen so zu sein,

[25:26] dass irgendwie, ich weiß nicht, Projekte vielleicht aus einer Vorlage erstellt werden,

[25:30] da ist alles schon drin und dann muss ich mich mit dem ganzen Kram gar nicht mehr auseinandersetzen.

[25:33] Aber so kann ich doch nicht in Abschlussprüfungen gehen. Ich kann doch nicht lauffähigen Code

[25:37] produzieren, ohne zu verstehen, wie er eigentlich funktioniert und das nicht erklären können in

[25:41] der Prüfung. Also das ist mir einfach unbegreiflich. Also wenn du ein Java-Projekt machst, dann solltest

[25:46] du auch die entsprechenden Java-Technologien beschreiben können und ersetze Java durch

[25:49] Programmiersprache deiner Wahl. In Ruby oder in C-Sharp wäre das genau das Gleiche. Wenn ich mit

[25:54] C-Sharp arbeite, aber zum Beispiel Link nicht erklären kann oder in Ruby und die Model-View-Controller-Geschichte

[26:00] nicht erklären kann, das geht einfach nicht. Also beherrscht die Sachen, die du benutzt hast,

[26:06] in- und auswendig, damit du da auch im Fachgespräch einen entsprechenden Eindruck hinterlassen kannst.

[26:11] Ja, ansonsten ist eigentlich schon fast langweilig, die Basisfragen zur Objektorientierung. Ich habe

[26:18] ja auch immer ein paar Lehrer im Prüfungsausschuss. Ganz normal, die müssen ja auch da drinnen sitzen,

[26:22] weißt du hoffentlich. Der Prüfungsausschuss wird immer aus mindestens drei Personen zusammengesetzt,

[26:26] nämlich einem Lehrervertreter, einem Arbeitnehmervertreter und einem Arbeitgebervertreter.

[26:31] Das heißt, es wird immer ein Lehrer auch im Ausschuss sitzen. Und das Schöne ist, dass die

[26:35] häufig natürlich auch ihre eigenen Schüler prüfen, sind ja an der Berufsschule und dann haben die

[26:39] ihre eigenen Schüler auch im Prüfungsausschuss. Also anders. Die sitzen im Prüfungsausschuss und

[26:46] prüfen ihre eigenen Schüler. Und dann regen sich meine Kollegen auch immer herrlich darüber auf,

[26:50] dass die Schüler Fragen nicht beantworten können, die sie ohne Witz eine Woche vorher noch im

[26:55] Unterricht besprochen haben. Und genau so geht es mir eigentlich auch. Aber wenn ich in so einem

[26:58] Fachgespräch Basiswissen zur Objektorientierung nicht erklären kann, da kriege ich jedes Mal

[27:03] echten Föhn, wenn ich sowas sehe. Dass Leute die Klasse und Objekte nicht auseinanderhalten können,

[27:07] dass die Vererbung nicht erklärt werden kann. Polymorphie, davon sehen wir mal ganz ab. Das

[27:11] können die wenigsten. Aber es sind einfach solche Basissachen, da denke ich mir, mein Gott,

[27:16] wie haben die überhaupt ein lauffähiges Projekt hingekriegt? Das kann einfach nur irgendwie gut

[27:20] Glück gewesen sein, wenn man solche Basissachen nicht erläutern kann. Von daher nochmal dringende

[27:24] Empfehlung. Ich habe einen Haufen kostenfreier Podcast-Episoden rund um die Objektorientierung,

[27:29] Polymorphie, Vererbung, Kapselung, den ganzen Schnickschnack kannst du dir auf jeden Fall

[27:32] anhören, wenn dir das noch nicht reicht. Ich habe es eben schon gesagt, dasperfektefachgespräch.de

[27:37] vier und eine Dreiviertelstunde Prüfungsfragen rund um das Thema. Damit solltest du optimal

[27:44] vorbereitet werden auf das Fachgespräch. Es gibt in meinem, also in meiner Meinung nach,

[27:48] gibt es keine Ausrede dafür, wenn man solche Basisfragen nicht beantworten kann. Dann muss

[27:52] man schon fast durch die Prüfung fallen. Ja, ich weiß es auch nicht. Ich kann es nur noch

[27:56] mal wiederholen. Bereite dich auf solche Sachen vor. Okay, dann hatten wir noch ein schönes

[28:02] Highlight. Da hat nämlich jemand dann auch wohl irgendwie im Podcast was gehört oder auf einer

[28:06] Website was gelesen oder so. Man muss ja auch viele UML-Diagramme auch in der Projektdokumentation

[28:10] zum Beispiel unterbringen. Und da hatte der oder diejenige dann auch in seiner oder ihrer

[28:14] Projektdokumentation ein Deployment-Diagramm benutzt aus der UML, was völlig in Ordnung ist.

[28:20] Ja, da heißt auf Deutsch Verteilungsdiagramm und das kennt jetzt nicht unbedingt vielleicht,

[28:24] kennt nicht unbedingt jeder. Es gibt ja 14 verschiedene UML-Typen und fünf davon sind

[28:29] meiner Meinung nach immer für die schriftliche Abschlussprüfung auch relevant. Das sind das

[28:32] Klassendiagramm, das Aktivitätsdiagramm, das Zustandsdiagramm, das Use-Case-Diagramm und

[28:37] das Sequenzdiagramm. Und das Deployment-Diagramm ist schon eins, was nicht so weit verbreitet ist,

[28:42] was ich zum Beispiel auch, wenn ich es noch nie benutzt hätte, für die Prüfung nicht lernen

[28:45] würde, weil es recht unwahrscheinlich ist, dass sowas abgefragt wird. Ist aber durchaus in der

[28:49] Praxis absolut sinnvoll, denn was stellt das dar, das Deployment-Diagramm? Das zeigt, wie meine

[28:54] Anwendung auf die Hardware oder auf die betroffenen Systeme verteilt wird. Also Beispiel, wenn ich eine

[29:00] Web-Anwendung habe, läuft die vielleicht als Artefakt, meinetwegen in Java, als War-File auf

[29:06] einem Application-Server. Der Application-Server läuft auf einem Linux-Server zum Beispiel. Der

[29:11] kommuniziert aber per REST mit einem Windows-Server, auf dem ein, was weiß ich, IIS läuft, in dem eine

[29:16] .NET-Anwendung läuft oder so. Und um sowas darzustellen, also wie ist die Infrastruktur

[29:20] und meine Anwendung verbunden, sag ich mal, was läuft wo, welche Komponenten laufen auf

[29:24] welcher Hardware, das kann ich wunderbar mit einem Deployment-Diagramm darstellen. Das finde

[29:28] ich auch absolut sinnvoll und benutzen meine Azubis auch häufig in ihren Abschlussdokumentationen.

[29:33] Allerdings hatte der Prüfling dann in seiner Dokumentation dafür auch drei Stunden eingeplant,

[29:39] so ein Deployment-Diagramm zu erzeugen. War auch wirklich ganz toll, war bloß leider gar nicht in

[29:43] der Dokumentation enthalten. War auch nicht in der Präsentation enthalten, von daher habe ich dann

[29:46] meinem Fachgespräch nachgehakt, wo ist denn das Deployment-Diagramm geblieben mit drei Stunden?

[29:50] Und dann kam die Rückfrage, was für ein Diagramm? Deployment-Diagramm? Sagt mir nichts. Und dann

[29:56] habe ich gesagt, steht aber hier mit drei Stunden in der Zeitplanung drin. Und dann wurde er auf einmal

[30:00] ganz still und wusste eigentlich so gar nicht, was er da wohl anscheinend reingeschrieben hat in

[30:04] seiner Dokumentation. Und das geht natürlich gar nicht. Das heißt für mich, oder kann eigentlich

[30:09] nur bedeuten, entweder hat er sich das irgendwo zusammen kopiert, so ein Deployment-Diagramm,

[30:13] habe ich gar nicht gelesen, Copy-Paste, hier mal ein bisschen zwei, drei Wörter anpassen und schwupp

[30:17] ist die Projektplanung fertig, so nach dem Motto. Und das geht natürlich gar nicht. Also was das für

[30:21] einen Eindruck macht, ist hoffentlich offensichtlich, dass drei Stunden meiner Zeit offensichtlich

[30:25] eingeplant wurden für was, was ich gar nicht gemacht habe, wo ich noch nicht mal weiß, was das ist.

[30:28] Das ist also das … ja, eigentlich bin ich fast vom Glauben abgefallen, als ich das gehört habe. Das kann

[30:34] einfach nur bedeuten, dass da irgendwie zusammengeklaut wurde. Anders kann ich es mir eigentlich

[30:39] nicht erklären, sowas. Und das geht natürlich nicht. Ja, und letztes Beispiel für heute, da hatten wir

[30:44] dann mal jemand, der auf dem iPhone was entwickelt hat und natürlich mit Objective-C. Nicht gerade

[30:51] meine Lieblingssprache. Ich möchte sie auch gar nicht lernen. Verstehen muss ich sie auch nicht,

[30:55] aber den Code-Ausschnitt, den er gezeigt hat, den konnte man ganz gut nachvollziehen. Und der

[30:59] wimmelte nur so von Pointern. Ja, Objective-C ist ja, basiert ja auf C und da kann man natürlich

[31:05] hervorragend mit Pointern rumhantieren. Ob man das tun sollte und ob man das gut finden sollte,

[31:10] lasse ich jetzt einfach mal unbeantwortet die Frage. Aber wenn man dann natürlich als Prüfling

[31:15] nicht erklären kann, was ein Pointer ist, dann sieht es wirklich ganz schlecht aus. Und auch in

[31:20] seiner Projekt-Präsentation war ein Beispiel, wo fast in jeder Zeile ein Pointer war. Wirklich. Ich

[31:26] habe die Variablen, die fingen alle mit dem Sternchen an. Das ist ja nun mal sehr offensichtlich,

[31:31] wenn ich mir so ein Code angucke. Alles, was mit dem Sternchen anfängt, ist ein Pointer. Und wenn

[31:35] ich dann die Frage stelle, diese Variablen da oben mit dem Sternchen davor, was ist denn das? Und

[31:41] dann kommt als Ergebnis, weiß ich nicht. Dann frage ich mich, wie kann derjenige überhaupt eine

[31:48] Zeile Code programmiert haben, wenn er so eine grundsätzliche Geschichte in seinem eigenen Code

[31:52] gar nicht verstanden hat. Das ist einfach wirklich traurig. Und ich hoffe, die Beispiele, die ich

[31:57] heute gebracht habe, zeigen dir, dass du diesen Kram einfach beherrschen musst. Wenn du etwas in

[32:03] deinem Projekt umsetzt, dann bitte, bitte, bitte, musst du das auch erklären können. Du kannst

[32:12] nicht einfach Sachen benutzen, ohne zu verstehen, wie sie funktionieren. Das geht einfach nicht. Das

[32:16] muss und das wird dir auch auf jeden Fall von den Punkten abgezogen, die du fürs Fachgespräch

[32:20] bekommst. Definitiv. Okay, so, damit bin ich jetzt durch mit meinem Rückblick auf die Sommerprüfung

[32:26] 2016. Waren hoffentlich ein paar interessante Sachen auch für dich dabei. Vor allem aber war

[32:31] hoffentlich was dabei, was du dir nicht als Vorbild nimmst, sondern wo du sagst, okay,

[32:36] darauf muss ich noch mal achten, bevor ich in die Prüfung gehe. In der Doku, in der Präse und im

[32:40] Fachgespräch, da habe ich jetzt ein paar Highlights zusammengefasst und ich hoffe, du hältst dich dran

[32:45] und verhinderst, dass in deiner Prüfung solche Sachen passieren, wie ich jetzt mehrfach genannt

[32:51] habe. Wenn du noch Unterstützung brauchst, guck auf die Website. Ich habe einen Haufen an Podcasts

[32:57] zu diesen ganzen Inhalten, die ich gesagt habe. Du kannst dich auch in meinen Newsletter eintragen

[33:01] und bekommst als Ergebnis sofort Zugriff auf meine Checklisten zu allem, was ich gesagt habe,

[33:06] zur Dokumentation, zur Präsentation und so weiter. Die kannst du einfach durchgehen und abhaken,

[33:10] ob die Sachen in deiner Doku und in deiner Präse erfüllt sind. Also, es gibt keine Ausrede,

[33:17] solche Sachen nicht zu kennen heutzutage. Die Show Notes, wo du diese ganzen Sachen findest,

[33:22] die sind wie immer zugänglich unter anwendungsentwicklerpodcast.de

[33:26] slash 69 für die 69. Episode, die das hier heute war. Wenn dir die Episode gefallen hat,

[33:35] dann würde ich mich über eine Rezension freuen, zum Beispiel bei iTunes unter

[33:39] anwendungsentwicklerpodcast.de slash iTunes oder wahlweise auch slash Stitcher. Da kannst du mich

[33:44] auch bewerten. Oder du schreibst mir einfach einen Kommentar. Das freut mich auch. Oder eine

[33:48] E-Mail gerne auch. Kontaktformular findest du auf der Website. Ich freue mich immer über Feedback

[33:52] von Hörern und von Lesern. Dann weiß ich, dass ich das hier nicht im luftleeren Raum produziere,

[33:56] sondern dass sich Leute das auch anhören und hoffentlich zu Herzen nehmen. Bitte, bitte,

[34:00] bitte. Ich möchte einfach nicht mehr diese geruseligen Antworten im Fachgespräch hören.

[34:03] Das ist wirklich schrecklich. Da frage ich mich, was die Leute eigentlich gelernt haben in drei

[34:07] Jahren. Das soll es für heute gewesen sein. Ich sage vielen, vielen Dank fürs Zuhören und bis zum

[34:16] nächsten Mal. Tschüss!