Auf meiner Website und im Podcast gebe ich ja hauptsächlich konkretere Tipps zur Ausbildung von Anwendungsentwicklern. Viele Inhalte lassen sich aber 1-zu-1 auf die anderen IT-Berufe und insb. auf die Systemintegratoren übertragen. Janik Beck hat auf seiner Website nun einige Tipps für die IHK-Prüfung zusammengestellt, die sich direkt auf den FISI beziehen, z.B.:

• Leitfaden für den Projektantrag als Fachinformatiker
• Prüfungsvorbereitung: Ganzheitliche Aufgaben 1
• Leitfaden: Fachinformatiker – betriebliche Projektarbeit
• Präsentation und Fachgespräch in der Abschlussprüfung als Fachinformatiker

Die Inhalte werden mit zahlreichen Illustrationen angereichert und Literaturhinweise gibt es auch. Insbesondere die Liste der Themen für die schriftliche Prüfung gefällt mir gut. Wir haben gerade unseren ersten AOzubi zum Fachinformatiker Systemintegration eingestellt und ab 2019 darf ich nun auch diesen ganzen Netzwerkquatsch vermitteln! Eine schöne Ergänzung zu meiner Liste mit möglichen Themen der Abschlussprüfung.

Kennst du noch andere Ressourcen (z.B. Websites, Bücher usw.) rund um die Prüfungsvorbereitung oder Ausbildung zum FISI? Ich freue mich auf deinen Kommentar!

Der Beitrag Tipps zur Prüfung für Fachinformatiker Systemintegration erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Ich habe ein neues Lieblingsbuch für die Ausbildung! „Java by Comparison“ wird im Buchclub in der einhundertdreißigsten Episode des Anwendungsentwickler-Podcasts besprochen.

Inhalt

Ich habe das Buch an einem Wochenende komplett verschlungen und es direkt im Anschluss auf die ToRead-Liste meiner Azubis gesetzt. Ab sofort werde ich es mit jedem Azubi lesen. Direkt im 1. Ausbildungsjahr, kurz nach der Bearbeitung der ersten Java-Aufgaben, legen wir los.

Idee des Buchs

Die Idee des Buchs ist schnell erklärt: Es werden 70 Code-Beispiele in Java gezeigt, an denen jeweils einzelne Optimierungen durchgeführt werden. Der „schlechte“ Code steht auf der linken Seite und der „gute“ Code steht auf der rechten Seite. Somit kann man direkt die beiden Beispiele vergleichen und sich auf den jeweiligen Unterschied konzentrieren. Im Prinzip gibt es also 70 kurze Lektionen zum Thema „Clean Code“.

Die Beispiele sind interessant und teilweise auch ein bisschen witzig gewählt, da das Grundthema eine Reise zum Mars ist.

Zielgruppe

Die Zielgruppe des Buches sind Anfänger bis Fortgeschrittene in der Programmierung. Die Beispiele sind zwar komplett in Java, aber ich würde sagen, dass man sie genauso gut in anderen Sprachen anwenden kann. Einige Beispiele, wie z.B. die Verwendung von Optional<T>, sind zwar sehr spezifisch für Java, aber die grundlegenden Ideen (in diesem Fall null zu vermeiden) lassen sich ohne Probleme auf andere Sprachen übertragen.

Damit man die Beispiele und Optimierungen auch versteht, sollte man schon ein wenig Programmierererfahrung mitbringen. In meinem Fall lasse ich die Azubis das Buch direkt nach ihrer Einführung in Java lesen. Die grundlegenden Themen wie Objektorientierung, Vererbung, Interfaces und Teile der funktionalen Programmierung sind dann schon bekannt und die weiteren Optimierungen des Buches können verstanden und auch angewendet werden. Das Buch schlägt vor, das „FizzBuzz“-Problem zu lösen. Wenn das klappt, gehört man zur Zielgruppe! Hier habe ich das Problem übrigens selbst schonmal auseinandergenommen: Don’t Repeat Yourself (DRY).

Für mich als Ausbilder ist das Buch ebenfalls sehr interessant, da ich Erklärungen zu Anmerkungen in meinen Code Reviews nun nicht mehr jedesmal ausformulieren und erklären muss, sondern im Prinzip einfach auf das kurze Buchkapitel dazu verweisen kann. Bei meinen Erklärungen schweife ich nämlich gerne auch mal sehr weit ab und am Ende haben wir dann eine halbe Stunde über Themen diskutiert, die mit dem eigentlichen Problem gar nichts mehr zu tun haben. Hier hilft mir das Buch weiter, da jedes Kapitel sich auf ein einziges Problem fokussiert und es in zwei Seiten gut nachvollziehbar erklärt.

Inhalt des Buches

Die einzelnen Kapitel des Buches bauen ein wenig aufeinander auf. Es startet mit einfachen Beispielen und wird immer komplexer. Wobei auch die späteren Beispiele immer noch gut verständlich sind. Es geht los mit einfachen Möglichkeiten, den eigenen Code aufzuräumen (z.B. die unten genannten unnötigen Vergleiche). Danach folgen etwas weitergehende Möglichkeiten wie z.B. Enhanced-For-Schleifen statt For-Schleifen einzusetzen. Es gibt ein eigenes Kapitel zum Thema Kommentare und auch zur Benennung von Variablen oder Methoden. Einiges davon wird auch in Clean Code* schon erklärt, aber hier werden halt aussagekräftige, kurze Beispiele mitgeliefert, mit denen auch Einsteiger etwas anfangen können.

Es gibt des Weiteren ein eigenes Kapitel zur Fehlerbehandlung und insbesondere auch zum Thema Unit-Tests, was ich sehr begrüße. Denn meiner Erfahrung nach haben gerade beim Thema Tests meine Azubis und Studierenden die meisten Probleme. Am Ende des Buches gibt es dann noch ein wenig über das Design von Klassenstrukturen zu lesen und eine kurze Einführung in die funktionale Programmierung mit Java, also beispielsweise Streams und Lambda-Ausdrücke. Auch Methodenreferenzen werden erläutert. Zum Abschluss gibt es dann einen Ausblick auf das „echte Leben“. Hier geht es dann z.B. um Continuous Integration oder den Einsatz eines Logging-Frameworks, anstatt alles auf die Konsole zu schreiben.

Konkrete Beispiele

Um ein Gefühl für den Inhalt zu vermittelt, beschreibe ich einfach mal drei Beispiele aus dem Buch.

Unnötige Vergleiche

Gleich das allererste ist eines, dass mir in der Praxis bei meinen Azubis und Studierenden immer wieder unterkommt: der Vergleich mit booleschen Werten. Es ist völlig unnötig, bei einer Abfrage einen booleschen Wert mit true oder false zu vergleichen. Stattdessen kann dieser direkt in der Abfrage verwendet werden.

Nicht so gut:

if (istErwachsen == true) { rabatt = 0; }

Besser:

if (istErwachsen) { rabatt = 0; }

Domänensprache nutzen

Ein weiteres schönes Beispiel ist die Verwendung von Domänen-Terminologie. Wir schreiben Code für andere Menschen und nicht für den Computer! Daher ist es wichtig, dass fachlich versierte Leser unseres Codes ihn gut verstehen und nicht durch missverständliche Begriffe abgelenkt werden.

Nicht so gut:

b = (summeR / lookupTabelleKS) * ax;

Besser:

monatsbeitrag = (rueckstellungen / kopfschaden) * rentenbarwart;

Optionals als Stream verwenden

Das letzte Beispiel ist sehr spezifisch für Java. Hier geht es um das schon erwähnte Optional<T>. Anstatt die Methode isPresent() zu verwenden, sollte man den funktionalen Ansatz wählen und das Objekt so nutzen, wie es gedacht ist.

Nicht so gut:

if (optional.isPresent() { doSomething(optional.get()); }

Besser:

optional.ifPresent(this::doSomething);

Literaturempfehlungen

Logisch, oder?

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Website zum Buch: Become a Better Java Developer in 70 Examples
• Podcast-Interview Simon Harrer: Java by Comparison. Vorher/Nachher-Vergleiche zu Clean Code in Java
• Reviews des Buchs: Java by Comparison bei heise Developer, Java by Comparison bei InfoQ

Der Beitrag Buchclub: Java by Comparison – Anwendungsentwickler-Podcast #130 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Von der Mikado-Methode habe ich schon öfter etwas gehört, mich aber bisher noch nicht so richtig damit beschäftigt. Mit diesem Artikel von David Tanzer hat sich das nun geändert: Legacy Code: The Mikado Method.

Die Methode soll dabei helfen, Legacy Code Schritt für Schritt zu refaktorisieren. Im Prinzip zerlegt man seine Refactorings in kleinere Teilschritte und nutzt seine Versionsverwaltung, um bei Fehlern zurück zum lauffähigen letzten Stand zu gelangen.

Das Vorgehen kam mir sehr bekannt vor, weil ich es intuitiv schon genau so angewendet habe. Aber es einmal aufgeschrieben und mit einem eingängigen Namen versehen zu sehen, hilft mir, wenn ich das Vorgehen meinen Azubis erklären muss. Wie auch bei Design Patterns ist eine gemeinsame Sprache wichtig, um sich auf hohem Niveau verständlich austauschen zu können.

Kanntest du die Mikado-Methode schon oder hast sie vielleicht sogar schon einmal angewendet?

Der Beitrag Die Mikado-Methode erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Einen kurzen Einstieg in einige grundlegende Begriffe der Kryptographie – die drei Schutzziele und die symmetrische und asymmetrische Verschlüsselung – gebe ich in der einhunderteinunddreißigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Meist wird bei der Erklärung von kryptografischen Verfahren der Nachrichtenaustausch zwischen zwei Personen als Anwendungsfall verwendet. Person A (meist „Alice“ genannt) möchte mit Person B (meist „Bob“ genannt) kommunizieren und dabei gewisse Ziele erreichen. Nehmen wir einfach an, Alice möchte Bob eine E-Mail schicken.

• Kryptographie ist die Wissenschaft der Verschlüsselung von Informationen.
• Ein Schlüssel wird zum ver- bzw. entschlüsseln von Informationen verwendet und kann z.B. ein Passwort sein oder einfach eine lange Zahl, z.B. eine Kette aus 128 Bit.
  • Um Schlüssel zu knacken, kann man einfach alle Kombinationsmöglichkeiten ausprobieren. Das wären bei 64 Bit z.B. ca. 18 Trilliarden. Dieses Verfahren heißt Brute Force und dauert tendentiell sehr lange.
  • Da die Computer aber immer schneller werden (und damit auch schneller Schlüssel durchprobieren können), sollte die verwendete Schlüssellänge regelmäßig erhöht werden. Das Bundesamt für Sicherheit in der Informationstechnik gibt z.B. regelmäßig Empfehlungen zur Schlüssellänge heraus.
• Schutzziele der Informationssicherheit
  • Vertraulichkeit: Der Inhalt der Nachricht kann nur vom Empfänger gelesen werden und nicht von einem Angreifer. Üblicherweise muss der Inhalt dafür verschlüsselt werden.
  • Integrität: Der Inhalt der Nachricht wurde auf dem Weg zum Empfänger nicht durch einen Angreifer verändert. Hierzu werden meist Hashverfahren eingesetzt.
  • Authentizität: Die Nachricht stammt sicher vom angegebenen Absender und nicht von einem Angreifer. Hierfür sind meist mehrere Verfahren (Verschlüsselung und Hashverfahren) nötig.
• Symmetrische vs. asymmetrische Verschlüsselung
  • Wird zum Ver- und Entschlüsseln der Nachricht der gleiche Schlüssel verwendet, spricht man von symmetrischer Verschlüsselung.
    • Beispiel: Alice verschlüsselt die Mail an Bob mit einem Kennwort, das auch für das Entschlüsseln benötigt wird.
    • Vorteil: Wenig rechenintensiv, da Schlüssellänge aufgrund des geheimen Schlüssels kürzer sein darf (z.B. 128 Bit).
    • Nachteil: Schlüssel muss auf sicherem Wege zwischen Absender und Empfänger ausgetauscht werden.
  • Wenn zum Verschlüsseln ein anderer Schlüssel verwendet wird, als für das Entschlüsseln, spricht man von asymmetrischer Verschlüsselung.
    • Es werden zwei Schlüssel („Schlüsselpaar“) benötigt, die mathematisch miteinander in Beziehung stehen, sich also berechnen lassen.
    • Dieses Schlüsselpaar besteht aus dem privaten Schlüssel, der unbedingt geheimgehalten werden muss, und dem öffentlichen Schlüssel, der für Jederman einsehbar sein darf (und auch sollte).
    • Damit alle Schutzziele erreicht werden können, braucht jeder Teilnehmer (Alice und Bob) sein eigenes Schlüsselpaar.
    • Beispiel: Alice verschlüsselt die Mail an Bob mit dessen öffentlichem Schlüssel. Bob kann die Mail dann nur mit seinem privaten Schlüssel entschlüsseln.
    • Vorteil: Schlüsselaustausch kann einfach erfolgen, sogar auf „unsicherem“ Weg (z.B. Mail, Internet).
    • Nachteil: Rechenintensives Verfahren mit Schlüsseln, die z.B. 40x so lang sind wie symmetrische Schlüssel (4096 Bit).
• Beispiel für asymmetrische Verschlüsselung
  • Um mit asymmetrischer Verschlüsselung die Vertraulichkeit zu wahren, verschlüsselt der Absender mit dem öffentlichen Schlüssel des Empfängers die Inhalte.
  • Nun kann ausschließlich der Empfänger, der als einziger das Gegenstück zu seinem öffentlichen Schlüssel – seinen privaten Schlüssel – besitzt, die Inhalte entschlüsseln.
  • Auch der Absender kann die von ihm versendeten Inhalte nun nicht mehr lesen.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Kryptographie – Wikipedia
• Informationssicherheit – Wikipedia
• IT-Schutzziele: Vertraulichkeit, Integrität, Verfügbarkeit
• Kryptographische Verfahren: Empfehlungen und Schlüssellängen

Der Beitrag Kryptographie – Schutzziele und Verschlüsselung – Anwendungsentwickler-Podcast #131 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Die Fortsetzung zum Oberthema Kryptographie mit Hashverfahren und elektronischer Signatur gibt es in der einhunderzweiunddreißigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

• Hashes
  • Hashverfahren erzeugen aus einer Eingangszeichenfolge beliebiger Länge eine Ausgangszeichenfolge fixer Länge, „Hash“ oder „Prüfsumme“ genannt.
  • Sie sind mathematische Einwegverfahren, die keinen Rückschluss auf die Eingangsdaten zulassen, wenn die Ausgangszeichenfolge bekannt ist.
  • Die erzeugten Hashes sollten sich selbst bei kleinsten Änderungen an den Eingangsdaten deutlich verändern, damit sofort ersichtlich ist, dass die Eingangsdaten verändert wurden.
  • Hashverfahren sollten möglichst „kollisionsarm“ sein. Das heißt, dass es sehr unwahrscheinlich sein muss, dass zwei unterschiedliche Eingangszeichenfolgen zum gleichen Hashwert führen.
  • Beispiele für Hashverfahren: MD5, SHA1, SHA256. Sie unterscheiden sich im verwendeten Algorithmus und/oder der Länge des erzeugten Hashwertes.
  • Ein Hashverfahren gilt als unsicher, wenn mit vertretbarem Aufwand eine Kollision herbeigeführt werden kann, z.B. indem einer veränderten Zeichenfolge weitere bewusste Änderungen hinzugefügt werden, um dann wieder zum ursprünglichen Hashwert zu gelangen. Das Verfahren MD5 gilt heute als unsicher.
• Elektronische Signatur
  • Die elektronische Signatur soll die Integrität und Authentizität von Daten sicherstellen.
  • Beispiel: Bob möchte sicherstellen, dass die erhaltene Mail von Alice auch wirklich von ihr stammt (und nicht von einem Angreifer, der vorgibt, Alice zu sein) und auf dem Weg durch das Internet nicht von einem Angreifer manipuliert wurde (also z.B. Alices IBAN nicht durch die des Angreifers ersetzt wurde).
  • Aufbau: Der Hash der Eingangsdaten wird mit dem privaten Schlüssel des Absenders verschlüsselt. Der Empfänger entschlüsselt den Hash mit dem öffentlichen Schlüssel des Absenders und erzeugt mit dem gleichen Hashverfahren den Hash über die empfangenen Daten. Wenn der entschlüsselte Hash mit dem selbst erstellten übereinstimmt, weiß der Empfänger, dass Integrität und Authentizität eingehalten wurden.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Kryptographische Hashfunktion – Wikipedia
• Message-Digest Algorithm 5 – Wikipedia

Der Beitrag Kryptographie – Hashverfahren und elektronische Signatur – Anwendungsentwickler-Podcast #132 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Ein Interview mit Julian Hirche zum Thema Ausbildung der Ausbilder (AdA) nach Ausbilder-Eignungsverordnung (AEVO) gibt es in der einhundertdreiunddreißigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Allgemeines zur Person

• Wie ist dein Name und wo arbeitest du (falls gewünscht)?
  • Julian Hirche, 34 Jahre alt
  • Ich arbeite in Hamburg in einem Unternehmen, das Software für Banken entwickelt.
  • Ich bin dort Teamleiter von 3 Entwicklern und 2 Testern.
• An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob?
  • Wir erstellen Reports für Banken und haben z.B. eine Drag/Drop-Oberfläche zum „Klicken“ von Reports programmiert. Außerdem machen wir Reporting mit SQL und PL/SQL oder Datenexport nach Excel.
  • Wir haben leider noch keine automatische Testabdeckung. Daher gibt es viele manuelle Tests. Wir planen aber, das zu automatisieren.
  • Wir haben „richtige“ Tester, die z.B. Akzeptanztests durchführen.
• Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?
  • Ich programmiere seit ich 8 Jahre alt war. Bin mit dem C64 angefangen. Programmieren fand ich spannender als Spielen.
  • Im Jahr 2000 habe ich die Realschule abgeschlossen und wollte Fachinformatiker werden, habe aber keinen Ausbildungsplatz gefunden.
  • Das Arbeitsamt hat mir eine Ausbildung zum Mechatroniker empfohlen. Danach habe ich dann mehrere Jahre aks Mechatroniker gearbeitet, aber letztlich gekündigt, weil ich in die IT wollte.
• Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?
  • Ich habe zunächst eine Informatikassistentenausbildung in Wedel absolviert an einer privaten Fachhochschule. Dort habe ich auch viel zusammen mit Bachelor-Studenten gemacht.
• Mit welcher/n Programmiersprache/n arbeitest du im Alltag?
  • Hauptsächlich C#. Früher auch Java oder PHP.
  • Früher meinte ich mal „Microsoft ist doof“, aber inzwischen gefällt mir C# sehr gut. Auch .NET Core unter Linux ist eine tolle Sache.
  • Wir entwickeln aktuell mit React im Frontend.
• Was ist deine Lieblingsprogrammiersprache und warum?
  • C#, weil man mit ihr viele coole Sachen machen kann.

Ausbildereignungsprüfung, AdA und AEVO

• Was heißen die ganzen Abkürzungen: AdA, AEVO?
  • AEVO ist die Ausbilder-Eignungsverordnung, die insb. die berufs-/arbeitspädagogische Eignung der Ausbilder definiert.
  • AdA steht für Ausbildung der Ausbilder, also den Weg, wie man zum Ausbilder wird (z.B. durch entsprechende Kurse).
• Wer darf einen Ausbilderschein machen? Welche Voraussetzungen gibt es?
  • Die Person muss persönlich (z.B. keine Vorstrafen) und fachlich (z.B. selbst die Ausbildung gemacht oder 5 Jahre im Beruf gearbeitet) geeignet sein.
• Warum hast du den Ausbilderschein gemacht?
  • Ich gebe mein Wissen gerne weiter.
  • Ich war schon lange im Internet aktiv und nutze viele Foren.
  • In unserem Betrieb finden wir keine Mitarbeiter, warum also nicht einfach selbst ausbilden?
  • Letztes Jahr haben wir es aber aufgrund von Projekten leider nicht geschafft, jemanden einzustellen.
• Wie und wo hast du den Ausbilderschein gemacht (z.B. Kurs, Selbststudium)?
  • Ich habe einen Kurs besucht. Über 2 Monate hinweg habe ich in der Abendschule die Inhalte gelernt. Ich hätte alternativ auch 2 Wochen in Vollzeit lernen können.
  • Die Dozenten waren Lehrer an der Schule, die auch in dem Bereich gearbeitet haben.
  • Wir waren 20 Teilnehmer. Ich war der einzige ITler. Die anderen waren aus den Büroberufen oder dem Einzelhandel.
  • Viele haben den Kurs im Rahmen ihrer Meister-Ausbildung gemacht.
• Braucht man den Schein überhaupt (noch)? Welche gesetzlichen Grundlagen gibt es?
  • Nach AEVO muss ein Unternehmen einen Ausbilder haben, wenn es ausbilden will.
• Welche Inhalte wurden in deinem Kurs vermittelt? Was hast du gelernt? Was konntest du konkret für deinen Berufsalltag mitnehmen?
  • Die Inhalte haben mit den konkreten Berufen nichts zu tun. Sie sind berufsunabhängig.
  • Wir sind z.B. das komplette BIBB durchgegangen, aber auch das JAschG war wichtig. Auch der Sinn und die Vorteile der Ausbildung wurden besprochen.
  • Es gibt grundsätzlich 4 Handlungsfelder, die man lernt: Ausbildung prüfen, vorbereiten, durchführen und abschließen.
  • Zur Vorbereitung zählen z.B. das Planen der Probezeit, Literatur raussuchen, den ersten Arbeitstag gestalten.
  • Das Abschließen umfasst insb., den Azubi durch die Prüfung zu bringen, aber auch das Erstellen eines Arbeitszeugnisses und die Gestaltung des Arbeitsvertrags bei Übernahme.
  • Beim Durchführen der Ausbildung haben wir uns u.a. die verschiedenen Lehrmethoden angeschaut: 4-Stufen-Modell, Lehrgespräch, Projektarbeit.
  • Aber auch das Feedback geben mit einem Evaluierungsbogen haben wir gelernt, z.B. ob der Azubi wissbegierig und pünktlich ist, wie er mit Kollegen umgeht und ob er sein Arbeitspensum schafft.
  • Das Motivieren von Azubis war auch Bestandteil des Kurses und manchmal ist auch ein wenig Erziehung nötig, wenn die Aubis noch jünger sind.
• Was hat es mit den Lehrmethoden auf sich?
  • Es geht darum, wie man den Azubis Wissen optimal vermittelt.
  • Für Gruppen aus mehreren Azubis und das Vermitteln von Grundlagen eignet sich evlt. Frontalunterricht.
  • Bei tiefergehenden Themen und mehreren Azubis ist vielleicht eher eine Projektarbeit sinnvoll.
  • Die 4-Stufen-Methode aus Erklären, Vormachen, Nachmachen und Wiederholen ist eine Art Schritt-für-Schritt-Anleitung und heute nicht mehr so gerne gesehen.
  • Es sollen eher in einem Lehrgespräch offene Fragen gestellt werden, über die der Azubi das Problem selbst lösen kann.
  • Diese Gespräche haben wir im Kurs auch mit den anderen Teilnehmern gemeinsam geübt. Ich selbst durfte z.B. von einem Paketierer lernen, wie man Pakete platzsparend packt und verklebt.
• Aus welchen Teilen besteht die Prüfung?
  • Es gibt einen schriftlichen Teil über 180 Minuten und einen mündlichen über 30 Minuten.
• Wie läuft die Prüfung konkret ab?
  • Die schriftliche Prüfung ist eine Multiple-Choice-Prüfung mit 70 Fragen mit angegebener Anzahl korrekter Antworten.
  • Ähnlich zur IHK-Prüfung gibt es viele fachliche Fragen z.B. zur Länge der Probezeit.
  • Es gibt auch Fallstudien mit Beispielen: Azubi schafft die Prüfung nicht, wie geht es weiter? Welche Lehrmethoden sind sinnvoll bei einzelnen Berufen? Viele rechtliche Fragen.
  • Die mündliche Prüfung besteht aus einem Rollenspiel über 15 Minuten und einem Fachgespräch über 15 Minuten.
  • Eine Präsentation ist optional auch möglich. Dort müsste man dann zeigen, wie man einen Azubi anlernen würde.
  • Im Kurs haben wir die mündliche Prüfung mit den anderen Kursteilnehmern durchgespielt. Man muss genau auf 15 Minuten kommen, also muss die komplette Lerneinheit dann fertig sein.
  • Als Ergebnis bekommt man ein Zeugnis mit Note.
• Wie lief deine eigene Prüfung ab?
  • Ich habe in einem Lehrgespräch den Bubble-Sort erklärt.
  • Der Azubi musste den Algorithmus selbst finden.
• Wer war dein Azubi?
  • Ein Prüfer hat den Azubi gespielt.
• Würdest du den Ausbilderschein weiterempfehlen?
  • Auf jeden Fall! Der Kurs war für mich sehr lehrreich.
  • Unser duales System der Berufsausbildung in Deutschland ist insg. super und sollte weiterverfolgt werden. Bei uns können nicht nur starke Schüler ausgebildet werden. Haupt- oder Realschule reichen auch für eine tolle Ausbildung.
• Was macht einen guten Ausbilder aus?
  • Ein guter Ausbilder sollte den Azubi nicht als Ressource oder Maschine ansehen, sondern als Menschen akzeptieren. Es sollte z.B. auch bei privaten Problemen helfen und Empathie zeigen.

Aus- und Weiterbildung

• Welche Quellen kannst du für die Aus- und Weiterbildung im Bereich Programmierung empfehlen und warum?
  • Informatik macchiato*. Hier werden für Schüler oder Studenten gut verständlich Informatikprobleme z.B. mit Bildern erklärt.
• Was ist dein absolutes Lieblingsbuch mit Bezug zur IT/Programmierung und warum?
  • Robert C. Martin: Clean Code*. Das hat mir persönlich sehr viel gebracht. Ich habe gelernt, meinen Code sauber zu halten.

Abschluss

• Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren?
  • Twitter
  • Blog
  • Fachinformatiker.de

Literaturempfehlungen

*

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Ausbilder-Eignungsverordnung vom 21. Januar 2009
• Ausbilder-Eignungsverordnung – Wikipedia
• BIBB
• Vier-Stufen-Methode – Wikipedia

Der Beitrag Ausbildung der Ausbilder nach AEVO mit Julian Hirche – Anwendungsentwickler-Podcast #133 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Mein viertes Wissenshäppchen hat das Open Closed Principle zum Thema.

Inhalt

Das OCP ist das zweite der SOLID-Prinzipien. Es wurde vor Robert „Uncle Bob“ Martin bereits 1988 von Bertrand Meyer definiert:

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

Ursprünglich ging es darum, durch Vererbung die Anpassung („modification“) bereits bestehender Klassen zu verhindern, indem Subklassen abgeleitet werden, die die vorhandene Funktionalität erweitern („extension“). Heutzutage ist Vererbung aber eher nicht mehr so gerne gesehen, da es eine starke Kopplung an die Basisklasse zur Folge hat, was das Design inflexibel macht. Stattdessen sollte man besser von vornherein Interfaces mit potentiell verschiedenen Implementierungen einsetzen.

Erklärung

• Bei Änderungen an einem Programm sollen bestehende Komponenten bestenfalls gar nicht angepasst werden müssen, da diese Anpassungen Fehler nach sich ziehen können, die auch das bereits bestehende Verhalten betreffen.
• Neue Funktionalität wird dem Programm immer durch neue Komponenten hinzugefügt, also z.B. indem neue Klassen oder Methoden ergänzt werden.
• Fallunterscheidungen auf Basis von Typen (z.B. mit instanceof in Java) oder Enumerations (insb. wenn diese in einem switch verwendet werden) sind oft ein Hinweis auf Verletzung des OCP und sollten durch Polymorphie ersetzt werden.

Beispiel

class Manager
end

class Developer
end

class Payroll
    def self.calculate_bonus(employee)
        if employee.is_a?(Manager)
            return 1000
        end
        if employee.is_a?(Developer)
            return 500
        end
    end
end

puts Payroll.calculate_bonus(Manager.new) # 1000
puts Payroll.calculate_bonus(Developer.new) #500

Wenn diese Bonusberechnung um einen neuen Mitarbeitertyp Administrator erweitert werden soll, muss die bestehende Implementierung von calculate_bonus() angepasst werden:

def self.calculate_bonus(employee)
    if employee.is_a?(Manager)
        return 1000
    end
    if employee.is_a?(Developer)
        return 500
    end
    if employee.is_a?(Administrator)
        return 250
    end
end

Stattdessen sollte von Anfang an die Berechnung des Bonuses an die Mitarbeiterklassen delegiert werden.

class Manager
    def bonus
        1000
    end
end

class Developer
    def bonus
        500
    end
end

class Payroll
    def self.calculate_bonus(employee)
        employee.bonus
    end
end

puts Payroll.calculate_bonus(Manager.new) # 1000
puts Payroll.calculate_bonus(Developer.new) # 500

Dadurch ist eine spätere Erweiterung um neue Mitarbeitertypen ohne Anpassung des bisherigen Codes möglich:

class Administrator
    def bonus
        250
    end
end

puts Payroll.calculate_bonus(Administrator.new) # 250

In dynamisch typisierten Sprachen (wie im Beispiel Ruby) ist das OCP übrigens meist noch einfacher umzusetzen als in statisch typisierten, da durch das Duck-Typing umfangreiche Klassenhierarchien oder Interfaces unnötig werden. Dies sieht man auch im Beispiel oben: Manager und Developer haben keinerlei Beziehung zueinander. Trotzdem funktioniert der Code, da beide Klassen die Methode bonus() anbieten.

Vorteile

• Bei Erweiterungen der Funktionalität sinkt die Wahrscheinlichkeit, Fehler in den bereits funktionierenden Code einzubauen.
• Klassen behalten ihre Aufgabe „ein Leben lang“. Abhängige Klassen können sich darauf verlassen, dass sich die Funktionalität nicht ändert.
• Erweiterungen sind ggfs. einfacher zu implementieren, da nicht an mehreren Stellen Code angepasst, sondern „nur“ neuer Code geschrieben werden muss.

Nachteile

• Meist ist gar nicht im Voraus bekannt, welche Stellen im Code später einmal erweitert werden müssen. Einfach nur noch mit Abstraktionen zu arbeiten, macht den Code aber schwer verständlich. Außerdem verletzten wir damit das YAGNI-Prinzip.

Literaturempfehlungen

Da Uncle Bob die SOLID-Prinzipien so schön aufgeschrieben hat, kann ich wieder einmal seinen Klassiker Clean Code* empfehlen.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Open Closed Principle
• ArticleS.UncleBob.PrinciplesOfOod (Artikel von Uncle Bob, Beispiel in C++)
• Open-Closed-Prinzip – Wikipedia
• SOLID – Das Open Closed Principle | Informatik Aktuell (ausführliche Diskussion der Nachteile, Beispiel in C#)
• SOLID Design Principles Explained – The Open/Closed Principle with Code Examples (Beispiel in Java)

Der Beitrag Open Closed Principle (OCP) – Wissenshäppchen #4 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Mein Link der Woche hat heute ausnahmsweise einmal nichts mit Technik zu tun. Ich ernähre mich bereits seit einigen Monaten vegetarisch und möchte nun den nächsten Schritt gehen und meine Ernährung vegan gestalten. Die erste Hürde, die ich dabei nehmen muss, ist der allmorgendliche Kaffee auf der Arbeit. Den genieße ich nämlich seit Jahren mit einem ordentlichen Schuss Milch. Das ist in einer veganen Ernährung so nicht mehr möglich (und natürlich auch absolut in Ordnung so).

Auf dieser Website werden 10 verschiedene vegane Alternativen zu Kuhmilch vorgestellt, die man in den Kaffee geben kann: Milchalternativen im Test – Cappuccino mal ohne Kuhmilch.

Ich habe die meisten davon inzwischen selbst probiert und muss ehrlich sagen, dass sie mich überhaupt nicht überzeugt haben. Um nicht zu sagen: Der Kaffee schmeckte scheußlich! Aber bei der letzten Variante, die ich getestet habe, bin ich nun hängengeblieben: Sojamilch. Seit einigen Tagen trinke ich meinen Kaffee nun morgens mit Sojadrink anstatt Milch und ich muss sagen, dass ich mich geschmacklich sogar verbessert habe. Die Sojamilch bringt eine interessante Geschmacksnote mit und hat auch eine sehr cremige Konsistenz. Es fühlt sich fast an, als hätte man Sahne im Kaffee. Von meiner Seite aus spricht nun nichts mehr gegen den Verzicht auf Kuhmilch!

Bei Quarks & Co wurde vor Kurzem auch über Milchalternativen berichtet, die übrigens eine deutlich bessere Klimabilanz haben als Kuhmilch: Braucht Milch einen Ersatz?

Spätestens damit sollte nun auch klar sein, was die Milchalternative auf einer Website für Softwareentwickler verloren hat. Denn ich denke, dass wir als Gesellschaft alle dafür verantwortlich sind, dass wir unseren Planeten noch ein paar Jahre nutzen können. In unserer IT-Branche gibt es seit langer Zeit die Idee, unsere Ressourcen bestmöglich zu nutzen. Ergebnisse sind z.B. virtuelle Maschinen oder aktuell die allgegenwärtigen Docker-Container. Wir tun alles, damit unsere stromfressenden Computer ihre Aufgaben effizienter erledigen. Warum also nicht auch in unserem Alltag das Problem der Ressourcenverschwendung angehen, wo wir einen viel größeren Effekt mit unserem Handeln erzielen können?

Wie ernährst du dich? Hältst du die nächtlichen Programmiersitzungen nur mit Energy Drinks und Chips durch, oder achtest du auf eine gesunde Ernährung? Bist du vielleicht sogar schon vegetarisch oder vegan unterwegs? Ich freue mich auf deinen Kommentar!

Der Beitrag Veganer (Milch-)Kaffee erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

In diesem Artikel stellt Javin Paul eine Liste mit 10 Dingen auf, die man seiner Meinung nach als Softwareentwickler/-in wissen muss: 10 Things Every Programmer and Software Engineer Should Know: Datenstrukturen und Algorithmen, Versionsverwaltung, Texteditoren, IDEs, Datenbanken und SQL, Linux, Excel, Programmiersprachen, Netzwerkgrundlagen, Skriptsprachen.

Falls du noch etwas auffrischen musst, kann ich dir für einige der Punkte die folgenden Ressourcen empfehlen.

• Datenstrukturen und Algorithmen: A Common-Sense Guide to Data Structures and Algorithms*
  *
• Versionsverwaltung: Einführung in die Versionsverwaltung mit Git (Teil 1)
• Texteditoren: Practical Vim*
  *
• Datenbanken und SQL: SQL – Häufige Fragen im Fachgespräch
• Linux: Der eigene Webserver (Teil 1)
• Programmiersprachen: Häufige Fragen im Fachgespräch – Programmierung (Teil 1)
• Netzwerkgrundlagen: Das ISO/OSI-Modell (Teil 1)

Ich bin die Liste mit meinen Azubis durchgegangen und wir konnten die meisten Punkte abhaken – spätestens am Ende der Ausbildung! Wie viele schaffst du?

Der Beitrag Was man als Softwareentwickler wissen muss erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Im fünften Wissenshäppchen geht es um das Liskov Substitution Principle.

Inhalt

Das LSP ist das dritte der fünf SOLID-Prinzipien. Es wurde 1987 von Barbara Liskov definiert, die ihm auch seinen Namen gab:

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

Man könnte sagen, dass dies quasi die Grundanforderung ist, um Polymorphie zu ermöglichen. Denn überall dort, wo eine Basisklasse oder ein Interface erwartet wird, müssen auch alle abgeleiteten bzw. implementierenden Klassen erlaubt sein. Dies ist in den heutigen Programmiersprachen auch der Fall und der Compiler prüft dies (statisch). Aber das LSP geht noch einen Schritt weiter und fordert auch zur Laufzeit ein korrektes Verhalten.

Erklärung

• Subklassen müssen sich so verhalten, wie es von ihren Basisklassen erwartet wird. Dies gilt auch für Interfaces und ihre Implementierungen.
• Statisch ist das kein Problem: Der Compiler prüft, ob alle geforderten Methoden von den Subklassen bzw. implementierenden Klassen angeboten werden.
• Die korrekte Verhaltensweise der Implementierung in den Subklassen bzw. implementierenden Klassen kann jedoch nicht statisch geprüft werden. Hierfür ist der Entwickler zuständig, um das LSP nicht zu verletzen.
• Wenn beispielsweise eine Subklasse in einer überschriebenen Methode eine NotImplementedException wirft, anstatt sie zu implementieren, wird das LSP verletzt.
• Aber auch unerwartete Nebeneffekte der Implementierungen in überschriebenen Methoden verletzten das LSP (Beispiel: Square erbt von Rectangle und setzt beim Aufruf von setA() auch die Seite b auf den gleichen Wert).

Beispiel

Die Basisklasse Employee gibt die Methode work_overtime() vor, die damit in allen Subklassen (Manager und Developer) zur Verfügung steht. Somit kann das Project gerade noch erfolgreich fertiggestellt werden.

class Employee
    def work_overtime
        puts "Working in the evening and on weekends..."
    end
end

class Manager < Employee
end

class Developer < Employee
end

class Project
    def finish(employees)
        employees.each { |e| e.work_overtime }
        "Project done"
    end
end

puts Project.new.finish([Manager.new, Developer.new])

# Working in the evening and on weekends...
# Working in the evening and on weekends...
# Project done

Aber was passiert, wenn sich der Developer zwar formell an den „Vertrag“ seiner Basisklasse hält, die Methode work_overtime() aber wie folgt überschreibt?

class Developer < Employee
    def work_overtime
        raise "Sorry, I use XP and adhere to the 40 hour workweek"
    end
end

puts Project.new.finish([Manager.new, Developer.new])

# Working in the evening and on weekends...                                                          
# Traceback (most recent call last):                                                                 
#         4: from ./LSP.rb:23:in `<main>'                                                            
#         3: from ./LSP.rb:18:in `finish'                                                            
#         2: from ./LSP.rb:18:in `each'                                                              
#         1: from ./LSP.rb:18:in `block in finish'                                                   
# ./LSP.rb:12:in `work_overtime': Sorry, I use XP and adhere to the 40 hour workweek (RuntimeError)  

Autsch! Das Project ist wohl zum Scheitern verurteilt! Es hatte ja keine Ahnung, dass man Developer nicht zu Überstunden verdonnern kann, denn das geht ja schließlich bei allen Employees…

Vorteile

• Der Code wird deutlich besser nachvollziehbar, da keine unerwarteten Fehler zur Laufzeit auftreten, obwohl laut Compiler alles ok ist.
• Klassen verhalten sich so, wie man es von ihnen erwarten würde („Principle of Least Astonishment“), und überraschen den Entwickler nicht.

Nachteile

• Die Möglichkeiten der Vererbung werden ein wenig eingeschränkt.

Literaturempfehlungen

Auch beim dritten SOLID-Prinzip empfehle ich wieder Uncle Bobs Clean Code*.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Liskov Substitution Principle
• ArticleS.UncleBob.PrinciplesOfOod (Artikel von Uncle Bob, Beispiel in C++)
• Liskovsches Substitutionsprinzip – Wikipedia

Der Beitrag Liskov Substitution Principle (LSP) – Wissenshäppchen #5 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Das sechste Wissenshäppchen hat das Interface Segregation Principle als Thema.

Inhalt

Das ISP ist das vierte SOLID-Prinzip.

The dependency of one class to another one should depend on the smallest possible interface.

Im Prinzip kann man das ISP so zusammenfassen: Verwende immer nur die kleinstmögliche Schnittstelle zu deinen Abhängigkeiten. Je mehr Funktionen eine Komponente an ihren Abhängigkeiten aufrufen kann, desto abhängiger wird sie von ihr. Wenn sich diese Funktionen nämlich ändern (z.B. die Signatur einer Methode), muss die nutzende Komponente neu kompiliert werden. Außerdem können Funktionen aufgerufen werden, die die nutzende Komponente weder benötigt, noch anwenden soll, z.B. die clear()-Methode einer Liste, die sie eigentlich nur durchlaufen soll. Zuletzt müssen auch implementierende Klassen von zu großen Interfaces für sie unnötige Methoden implementieren, nur um der Schnittstelle zu entsprechen.

Erklärung

• Zu große Interfaces oder Basisklassen bieten evtl. Zugriff auf verschiedene Funktionalitäten, die nicht zusammengehören (z.B. Repository.getUser() und Repository.getArticle()), oder über das benötigte/erlaubte Verhalten hinausgehen (z.B. Repository.deleteUser()).
• Komponenten, die von diesen Schnittstellen abhängen, können mit ihnen „zu viel“ machen und müssen angepasst (mind. rekompiliert) werden, wenn sich diese ändern, auch wenn sie die geänderte Funktionalität gar nicht nutzen.
• Komponenten, die die vorgegebenen Schnittstellen anbieten möchten, müssen mehr implementieren, als sie eigentlich wollen (oder dies nicht tun und das LSP mit einer NotImplementedException verletzen).
• Tests von Komponenten, die Abhängigkeiten auf große Schnittstellen haben, werden schwieriger, da viele eigentlich unnötige Funktionen gestubbt oder gemockt werden müssen.
• Auch eine „große“ Klasse kann mehrere „kleine“ Interfaces anbieten und damit wohldefinierte „Fenster“ auf ihre Funktionalität anbieten.

Beispiel

Die Methode printEmployees() im folgenden Beispiel erwartet eine List<Employee>, obwohl sie diese lediglich durchlaufen können muss. Durch das „zu große“ Interface kann sie darüber hinaus jetzt auch die Liste leeren, was für den Aufrufer unschöne Konsequenzen hat.

public class ISP
{
    public static void main(String[] args)
    {
        List<employee> employees = new ArrayList<>();
        employees.add(new Employee("Stefan", "Macke"));
        employees.add(new Employee("Karl", "Meier"));
        employees.add(new Employee("Hans", "Georg"));
        printEmployees(employees);
        System.out.println(employees.size());
    }

    private static void printEmployees(List</employee><employee> employees)
    {
        for (var employee : employees)
        {
            System.out.println(employee);
        }
        employees.clear();
    }
}

// Ausgabe:
// Stefan Macke
// Karl Meier
// Hans Georg
// 0

Die Methode sollte stattdessen das kleinstmögliche Interface benutzen, das sie braucht, um ihre Aufgabe erfüllen zu können. In Java wäre das z.B. ´Iterable´:

private static void printEmployees(Iterable<employee> employees)
{
    for (var employee : employees)
    {
        System.out.println(employee);
    }
}

Der restliche Code funktioniert wie vorher, aber es sind nun keine modifizierenden Aufrufe mehr möglich, da das kleinere Interface die Methoden nicht anbietet.

Dynamisch typisierte Sprachen haben hier einen Vorteil, da sie dank Duck-Typing ohnehin kaum Basisklassen oder gar Interfaces benötigen. Sie rufen einfach nur die Methoden auf, die sie brauchen. Das kann allerdings auch zu impliziten Abhängigkeiten führen, die nicht vom Compiler geprüft werden, da der Zugriff auf die Klasse nicht durch ein Interface „geschützt“ ist.

Vorteile

• Kleinere Komponenten machen uns das Entwicklerleben einfach: klare Zuständigkeiten, einfachere Tests, weniger unnötige Abhängigkeiten.
• Durch klar definierte Schnittstellen wird die fehlerhafte oder unerlaubte Verwendung von Funktionen verhindert.
• Kleinere Schnittstellen entsprechen dem Single Responsibility Principle.

Nachteile

• Insgesamt steigt die Anzahl der Typen im System durch kleine Schnittstellen an (siehe auch SRP).

Literaturempfehlungen

Es wird schon langweilig: Auch beim vierten SOLID-Prinzip empfehle ich wieder Uncle Bobs Clean Code*.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Interface Segregation Principle
• ArticleS.UncleBob.PrinciplesOfOod (Artikel von Uncle Bob, Beispiel in C++)
• Interface-Segregation-Prinzip – Wikipedia
• Das Interface Segregation Principle (Deutsches Beispiel in C#)

Der Beitrag Interface Segregation Principle (ISP) – Wissenshäppchen #6 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Im siebten Wissenshäppchen geht es um das Dependency Inversion Principle.

Inhalt

Das DIP ist das letzte der fünf SOLID-Prinzipien.

High level modules should not depend upon low level modules. Both should depend upon abstractions.

Oder:

Abstractions should not depend upon details. Details should depend upon abstractions.

Welche Abhängigkeiten werden hier „umgedreht“? Komponenten, die andere Komponenten benötigen, erzeugen sich diese nicht selbst, sondern bekommen sie von außen hineingegeben. Braucht ein Service beispielsweise ein Repository um arbeiten zu können, erzeugt er es sich nicht selbst, z.B. mit this.repo = new Repository() in seinem Konstruktor, sondern bekommt es stattdessen schon fertig als Parameter übergeben, z.B. public Service(Repository repo). Das heißt, obwohl die Abhängigkeit vom Service zum Repository geht, wird sie „umgekehrt“ aufgelöst, indem das Repository dem Service übergeben wird.

Erklärung

• Wenn Komponenten sich ihre Abhängigkeiten selbst erzeugen, sind diese später nur umständlich oder gar nicht mehr austauschbar.
• Tests von Komponenten, die sich ihre Abhängigkeiten selbst erzeugen, sind schwierig/unmöglich/langsam/fehleranfällig, da die Abhängigkeiten nicht so einfach gegen Fake-Objekte ausgetauscht werden können.
• Die Abhängigkeiten sind nicht explizit in der API sichtbar. Der obige Service „braucht“ ein Repository, aber das sieht man nur, wenn man sich den Quelltext von Service anschaut. Beim Erzeugen eines Services ist dies nicht offensichtlich, weil er sich das Repository „heimlich“ selbst erzeugt.

Beispiel

Um alle Employees zu bezahlen, erzeugt sich die Payroll ihr eigenes MySqlEmployeeRepository. Dadurch wird auch im Test die echte Datenbank verwendet und ein Austauschen gegen eine Oracle-Datenbank erfordert eine Anpassung der Klasse Payroll (vgl. Open Closed Principle).

class Payroll
    def initialize
        @repo = MySqlEmployeeRepository.new
    end

    def pay_employees
        @repo.find_all.each { |employee| employee.pay }
    end
end

class MySqlEmployeeRepository
    def find_all
        puts "Accessing the database and reading all employees"
        [Employee.new] * 10
    end
end

class Employee
    def pay
        puts "Thank you for paying me"
    end
end

Payroll.new.pay_employees

# Accessing the database and reading all employees 
# Thank you for paying me
# ...
# Thank you for paying me

Statt dieser „harten“ und versteckten Abhängigkeit sollte Payroll sich lieber die Implementierung eines Repositorys liefern lassen. Das erfordert nur eine kleine Umstrukturierung des Codes und ermöglicht deutlich einfachere Tests.

class Payroll
    def initialize(repo)
        @repo = repo
    end

    def pay_employees
        @repo.find_all.each { |employee| employee.pay }
    end
end

class MySqlEmployeeRepository
    def find_all
        puts "Accessing the database and reading all employees"
        [Employee.new] * 10
    end
end

class FakeEmployeeRepository
    def find_all
        [Employee.new] * 1
    end
end

class Employee
    def pay
        puts "Thank you for paying me"
    end
end

puts "Production:"
Payroll.new(MySqlEmployeeRepository.new).pay_employees

puts "Test:"
Payroll.new(FakeEmployeeRepository.new).pay_employees

# Production:
# Accessing the database and reading all employees
# Thank you for paying me
# ...
# Thank you for paying me
# Test:
# Thank you for paying me

Außerdem kann Payroll nun auch ohne Anpassungen (!) mit einer Oracle-Datenbank arbeiten.

class OracleEmployeeRepository
    def find_all
        puts "Reading employees from Oracle database"
        [Employee.new] * 100
    end
end

puts "Using Oracle:"
Payroll.new(OracleEmployeeRepository.new).pay_employees

# Reading employees from Oracle database
# Thank you for paying me
# ...
# Thank you for paying me

Vorteile

• Abhängigkeiten sind explizit sichtbar und können bei geänderten Anforderungen oder in Tests einfach ausgetauscht werden.
• Neue Funktionalitäten können dem Programm einfacher hinzugefügt werden, da durch die Abhängigkeit von Abstraktionen oftmals auch das OCP umgesetzt wird.

Nachteile

• Ein Problem könnte wieder ein „Overengineering“ sein. Es ist wahrscheinlich nicht sinnvoll, jede Kleinigkeit hinter einer Abstraktion zu verbergen. Aber wie entscheidet man, welche Abstraktion sinnvoll ist?
• Bei vielen Abhängigkeiten wird das Erstellen von Objekten (und damit auch deren Test) schwierig, weil viel Arbeit vorab erledigt werden muss. Hier könnte dann ein DI-Container zum Einsatz kommen.

Literaturempfehlungen

Wie sollte es anders sein: Auch für das letzte SOLID-Prinzip empfehle ich noch einmal Clean Code* von Uncle Bob.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Dependency Inversion Principle
• ArticleS.UncleBob.PrinciplesOfOod (Artikel von Uncle Bob, Beispiel in C++)
• Dependency-Inversion-Prinzip – Wikipedia
• Das Dependency Inversion Principle | Informatik Aktuell (Deutsches Beispiel in C#)

Der Beitrag Dependency Inversion Principle (DIP) – Wissenshäppchen #7 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Über die Neuordnung der IT-Berufe in den Jahren 2018 und 2020 spreche ich in der einhundertvierunddreißigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Die fünf IT-Berufe (Fachinformatiker der Fachrichtungen Anwendungsentwicklung und Systemintegration, Informatikkaufleute, IT-Systemkaufleute und IT-Systemelektroniker) werden in der Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik beschrieben. Diese wurde im Jahr 1997 erstellt und ist seitdem nicht angepasst worden, was aber auch nicht unbedingt nötig war. Die Inhalte sind nämlich bewusst so allgemein formuliert, dass man nicht alle zwei Wochen die Verordnung aktualisieren muss, nur weil es gerade mal wieder irgendeinen Trend in der IT-Branche gibt. Anstatt konkrete Programmiersprachen oder Netzwerkprotokolle als Lerninhalt vorzuschreiben, werden allgemeine Formulierungen verwendet wie z.B.

• (FIAE) 9.1 Kundenspezifische Anpassung und Softwarepflege (§ 10 Abs. 2 Nr. 9.1)
  • 9.1a Anwendungslösungen entsprechend den kundenspezifischen Anforderungen einrichten, konfigurieren und anpassen
  • 9.1b Software an eine veränderte Umgebung anpassen und weiterentwickeln
  • 9.1c Anwendungslösungen mit Hilfe von Applikationssprachen erweitern
• (FISI) 8.1 Systemkonfiguration (§ 10 Abs. 4 Nr. 8.1)
  • 8.1a Rechner- und Systemarchitekturen sowie Betriebssysteme beurteilen und einordnen
  • 8.1b Betriebssysteme unter Berücksichtigung ihrer Vor- und Nachteile für bestimmte Anwendungsbereiche auswählen und konfigurieren
  • 8.1c Betriebssystemsteuersprachen anwenden

Gerade ist übrigens die Rangliste 2018 der Ausbildungsberufe nach Anzahl der Neuabschlüsse beim BIBB erschienen. Der Fachinformatiker ist auf Platz 7 vorgerückt. Das Interesse an unserem Beruf ist also ungebrochen und wächst sogar. Ein Grund mehr, die Berufsinhalte auf den Prüfstand zu stellen.

Ergebnisse der Vorstudie zur Novellierung der IT-Berufe

Folgende Themen wurden im Rahmen einer Vorstudie (Umfrage bei Arbeitgebern, Schulen, Azubis) als besonders relevant für die Ausbildung identifiziert:

• Wichtige Inhalte: IT-Security, Industrie 4.0, personale und soziale Kompetenzen
• Zusammenlegung von Informatikkaufmann und IT-System-Kaufmann
• Aufteilung der beiden Fachinformatiker in separate Berufe
• Wahlqualifikationen einführen, um stärker spezialisieren zu können
• Abschlussprüfung erneuern (gestreckte Prüfung)

Novellierung der IT-Berufe zum 01.08.2018

Zum 01.08.2018 wurden die IT-Berufe nun zum ersten Mal überarbeitet. Es sind aber nur ein paar wenige Punkte verändert worden, indem das Stichwort „IT-Sicherheit“ ergänzt wurde. Der große Rest ist gleichgeblieben.

Für alle Azubis, die ihre Ausbildung am oder nach dem 01.08.2018 begonnen haben, gilt bereits die neue Verordnung!

Die konkreten Änderungen habe ich aus der Ersten Verordnung zur Änderung der Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik übernommen.

Man erkennt schnell, dass damit insb. auf die aktuell immer häufiger auftretenden Hacker-Angriffe gegen Netzwerke reagiert werden soll. Aber auch der Datenschutz wurde explizit erwähnt, der inzwischen dank DSGVO aber ja auch deutlich weiter geht als nur das Fernmeldegeheimnis.

Wichtig ist, dass die Anpassungen hauptsächlich in den Bereichen vorgenommen wurden, die für alle IT-Berufe identisch sind. Es geht hier also um Grundwissen und nicht um FISI-Spezialwissen. IT-Sicherheit und Datenschutz sind auch für Anwendungsentwickler absolut wichtig und müssen z.B. bei der Programmierung der eigenen Anwendungen berücksichtigt werden. Wenn vom Anwendungsentwickler Passwörter im Klartext in der Datenbank abgelegt werden, kann der Systemintegrator noch so tolle Firewalls davorschalten, die Daten bleiben kompromittierbar!

Führen des Berichtshefts

Einige gestrichene Paragraphen beziehen sich übrigens auf das Führen des Berichtshefts, insb. der für die beiden Fachinformatiker gültige § 13:

Der Auszubildende hat ein Berichtsheft in Form eines Ausbildungsnachweises zu führen. Ihm ist Gelegenheit zu geben, das Berichtsheft während der Ausbildungszeit zu führen. Der Ausbildende hat das Berichtsheft regelmäßig durchzusehen. (§ 13 ITKTAusbV)

Das Führen von Ausbildungsnachweisen ist aber selbstverständlich weiterhin Bestandteil der Ausbildung. Nur das dies nun für alle Berufe verbindlich im Berufsbildungsgesetz geregelt wird und nicht mehr in den einzelnen Ausbildungsordnungen:

Ausbildende haben Auszubildende zum Führen der Ausbildungsnachweise nach § 13 Satz 2 Nummer 7 anzuhalten und diese regelmäßig durchzusehen. Den Auszubildenden ist Gelegenheit zu geben, den Ausbildungsnachweis am Arbeitsplatz zu führen. (§ 14 (2) BBiG)

Auszubildende haben sich zu bemühen, die berufliche Handlungsfähigkeit zu erwerben, die zum Erreichen des Ausbildungsziels erforderlich ist. Sie sind insbesondere verpflichtet, einen schriftlichen oder elektronischen Ausbildungsnachweis zu führen. (§ 13 7. BBiG)

Geplante Anpassungen in 2020

Die Überarbeitung (Änderungsverordnung) der IT-Berufe 2018 war erst der Anfang. Im Jahr 2020 sollen weitere Anpassungen vorgenommen werden (Neuordnung).

• Inhaltlich wird es um Themen wie IT-Security, Virtualisierung, Cloud-Computing, Big Data oder Mobile Computing gehen. (Vgl. Neuordnung der IT-Berufe 2018 und 2020)
• Die Berufe Informatikkaufmann und IT-System-Kaufmann sollen stärker voneinander abgegrenzt werden. Der Informatikkaufmann soll ein neues Profil, eine neue Ausrichtung, neue Inhalte und eine neue Berufsbezeichnung bekommen (der Arbeitstitel ist Datenkaufleute). (Vgl. Zukunft der IT-Berufe: Informationen zum Neuordnungsverfahren)
• Einführung einer gestreckten Abschlussprüfung, bei der die Zwischenprüfung durch einen ersten Teil der Abschlussprüfung ersetzt wird.

Katalog der vorläufigen Fertigkeiten, Kenntnisse und Fähigkeiten (Qualifikationskatalog) für Anwendungsentwickler

Vgl. Eckwerte Fachinformatiker/-in

Berufsprofilgebende Fertigkeiten, Kenntnisse und Fähigkeiten

• Planen, Vorbereiten und Durchführen von Arbeitsaufgaben in Abstimmung mit den kundenspezifischen Geschäfts- und Leistungsprozessen
• Informieren und Beraten von Kunden, Bearbeiten von Anfragen
• Beurteilen marktgängiger IT-Produkte und kundenspezifischer Lösungen
• Konzeptionierung und Realisierung von kundenspezifischen Softwareanwendungen
• Testen und dokumentieren Anwendungen
• Modifizieren bestehender Anwendungen
• Einsetzen von Projektplanungs- und Steuerungsinstrumenten
• Anwenden von Softwareentwicklungswerkzeugen
• Entwickeln von anwendungsgerechten und ergonomischen Bedienoberflächen
• Durchführen von qualitätssichernden Maßnahmen
• Beseitigen von Störungen in informations- und telekommunikationstechnische Systemen
• Umsetzen, integrieren und prüfen von IT-Sicherheitsmaßnahmen und gesetzlichen Vorgaben
• Schulen und Beraten der Nutzer
• Übergeben der Leistungen an den Kunden

Integrative Fertigkeiten, Kenntnisse und Fähigkeiten

• Berufsbildung, Arbeits- und Tarifrecht
• Aufbau und Organisation des Ausbildungsbetriebes
• Sicherheit und Gesundheitsschutz bei der Arbeit
• Umweltschutz
• Selbstgesteuertes, bedarfs-und handlungsorientiertes Lernen
• Persönliche, soziale und interkulturelle Kompetenzen

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik
• Artikel 1 – Erste Verordnung zur Änderung der Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik (1. ITKTAusbVÄndV) bzw. als PDF bei der IHK Oldenburg
• Infoveranstaltung zur Neuordnung in den IT-Berufen von Stefan Ernst am 19.03.2018
• Neuordnung der IT-Berufe von Michael Assenmacher, DIHK e. V.

Der Beitrag Neuordnung der IT-Berufe – Anwendungsentwickler-Podcast #134 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Vincent Doppelmann hat in der Winterprüfung 2018/2019 von der IHK Oldenburg 100% für die Projektpräsentation seiner betrieblichen Projektarbeit bekommen. Herzlichen Glückwunsch zu dieser tollen Leistung!

Vincent war so nett, die Arbeit der Allgemeinheit zur Verfügung zu stellen. Du kannst sie hier herunterladen.

Bewertung

Die Projektpräsentation ist ein sehr gutes Beispiel für eine Projektarbeit. Insbesondere folgende Punkte fallen mir positiv auf:

• Durchgängig wird der Bezug zum „Maskottchen“ Schiggi als roter Faden genutzt und mit witzigen Bildern illustriert. Das Plüschtier war übrigens auch bei der Prüfung mit vor Ort und hat für Erheiterung im Prüfungsausschuss gesorgt. Genau das richtige Maß an „Nerd-Faktor“ für ITler!
• Statt Stockfotos werden ausschließlich eigene Bilder verwendet. Das macht die Präsentation sehr individuell.
• Die Präsentation startet mit einer interessanten Geschichte, erneut angelehnt an das Pokemon-Konzept.
• Alle wichtigen Artefakte des Projekts werden gezeigt (z.B. Use Cases, ERM, Komponentendiagramm, Code).
• Alle Projektphasen werden mit ihren Ergebnissen vorgestellt.
• Die Kostenplanung ist auf das Wesentlich reduziert, gut lesbar und verständlich dargestellt.
• Komplexe Diagramme werden Schritt für Schritt aufgebaut und durch Setzen von Highlights wie Hervorhebungen oder roten Rahmen erklärt.
• Kleine Teile von Diagrammen werden zur Erläuterung herangezoomt.
• Es wird interessanter Code mit Einsatz moderner Programmierkonzepte (z.B. Stream<T>) gezeigt.
• Die Qualitätssicherung mit Unit-Tests und Mocks wird vorgestellt. Auch Sonarqube als statische Codeanalyse ist integriert.
• Die fertige Anwendung wird gezeigt.
• Die Präsentation endet mit einem Verweis auf die Einstiegsgeschichte und ergibt damit ein rundes Gesamtbild.

Metadaten

• Titel der Projektarbeit: AO-Schiggi – Staatlich geförderte ergänzende Pflegeversicherung Input/Output
• Ausbildungsberuf: Fachinformatiker Anwendungsentwicklung
• Prüfung: Winterprüfung 2018/2019
• Bewertung: 100%
• IHK: IHK Oldenburg
• Name des Prüflings: Vincent Doppelmann
  • Kontaktmöglichkeiten: Xing
• Ausbildungsbetrieb: ALTE OLDENBURGER Krankenversicherung AG
  • Kontaktmöglichkeiten: Website, Facebook, Instagram, Xing

Wenn du deine Projektarbeit auch auf dieser Seite veröffentlichen möchtest, dann sprich mich gerne an. Ich suche (sehr gute) Beispiele aus allen IT-Berufen.

Download

Vielen Dank an Vincent Doppelmann und ALTE OLDENBURGER Krankenversicherung AG für das Bereitstellen der Projektpräsentation. Alle internen Angaben oder personenbezogenen Daten wurden entweder unkenntlich gemacht oder durch fiktive Werte ersetzt.

• Projektpräsentation Fachinformatiker Anwendungsentwicklung von Vincent Doppelmann (PDF) (IHK Oldenburg, Winterprüfung 2018/2019)
  
• Projektpräsentation Fachinformatiker Anwendungsentwicklung von Vincent Doppelmann (PPTX)

Weitere Infos zur Projektpräsentation

Du suchst noch mehr Tipps rund um die Projektpräsentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektpräsentation.

Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektpräsentation herunterladen.

Der Beitrag Projektpräsentation von Vincent Droppelmann (mit 100% bewertet) erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Über den Inhalt und die Erstellung eines betrieblichen Ausbildungsplans für Fachinformatiker spreche ich in der einhundertfünfunddreißigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Begriffsdefinitionen

• Ausbildungsrahmenplan: Gibt die allgemeinen Inhalte der Ausbildung vor. Er ist bewusst so formuliert, dass er eine lange Gültigkeit hat und nicht ständig aktualisiert werden muss. Er enthält also z.B. keine Programmiersprachen oder Netzwerk-Protokolle. Die aktuelle Version, die 2018 lediglich leicht ergänzt wurde, ist seit dem Jahr 1997 gültig. Der Ausbildungsrahmenplan wird als Teil der Ausbildungsordnung vom Bundesministerium für Bildung vorgegeben (siehe Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik).
• Rahmenlehrplan: Er enthält die Inhalte, die in der Berufsschule vermittelt werden müssen. Der Rahmenlehrplan wird von der Kultusministerkonferenz vorgegeben (siehe Rahmenlehrplan Fachinformatiker/Fachinformatikerin).
• Betrieblicher Ausbildungsplan: Überträgt die allgemeinen Inhalte aus dem Ausbildungsrahmenplan auf das konkrete Ausbildungsunternehmen. Hier werden einzelne Technologien, Schulungen usw. konkreten Zeiten während der dreijährigen Ausbildungszeit zugeordnet. Der betriebliche Ausbildungsplan wird vom Ausbildungsunternehmen erstellt und für jeden Azubi individuell angepasst.

Wofür braucht man einen betrieblichen Ausbildungsplan?

Die vorgegebenen Inhalte aus dem Ausbildungsrahmenplan müssen durch das Ausbildungsunternehmen innerhalb der drei Jahre der Ausbildung dem Azubi vermittelt werden. Wie genau das erfolgen soll, muss jedes Unternehmen selbst entscheiden. Vielleicht durchläuft der Azubi im ersten Lehrjahr eine Abteilung, die sich mit Netzwerken beschäftigt, und erst im zweiten Jahr kommt er in die Anwendungsentwicklung. Diesen spezifischen Abläufen wird mit dem betrieblichen Ausbildungsplan Rechnung getragen. Das Unternehmen muss sicherstellen, dass alle nötigen Inhalte (was) vermittelt werden, aber wie, wann, von wem und wo kann es selbst entscheiden. Der betriebliche Ausbildunsplan kann sogar für jeden einzelnen Azubi des Unternehmens individuell erstellt werden, wenn das sinnvoll ist, z.B. wenn bestimmte Abläufe in der Ausbildung von Jahr zu Jahr wechseln.

Als Ausbilder

Für den Ausbilder ist der betriebliche Ausbildungsplan wichtig, damit er sichergehen kann, dass seinen Azubis alle nötigen Kenntnisse des Berufs vermittelt werden, die auch in der Abschlussprüfung abgefragt werden. Außerdem gibt es ganz nebenbei auch eine gesetzliche Vorgabe, nach der jedes Ausbildungsunternehmen verpflichtet ist, einen betrieblichen Ausbildungsplan zu erstellen. Und zwar schon vor Beginn der Ausbildung, da er Teils des Ausbildungsvertrags ist:

Ausbildende haben unverzüglich nach Abschluss des Berufsausbildungsvertrages, spätestens vor Beginn der Berufsausbildung, den wesentlichen Inhalt des Vertrages gemäß Satz 2 schriftlich niederzulegen; die elektronische Form ist ausgeschlossen. In die Niederschrift sind mindestens aufzunehmen 1. Art, sachliche und zeitliche Gliederung [Herv. d. Verf.] sowie Ziel der Berufsausbildung, insbesondere die Berufstätigkeit, für die ausgebildet werden soll […]

Quelle: Berufsbildungsgesetz (BBiG), § 11 Vertragsniederschrift, Absatz 1, Satz 2, Nummer 1

Im BBiG wird diesem Plan auch sein Namen gegeben:

Auf einen betrieblichen Ausbildungsplan [Herv. d. Verf.] im Sinne von § 11 Absatz 1 Satz 2 Nummer 1 […]

Quelle: Berufsbildungsgesetz (BBiG), § 36 Antrag und Mitteilungspflichten, Absatz 1, Satz 3

Und auch laut Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik muss jedes ausbildende Unternehmen einen Ausbildungsplan erstellen, der auf dem Ausbildungsrahmenplan zum Fachinformatiker basiert:

§ 11 (Ausbildungsrahmenplan)

Die in § 10 genannten Fertigkeiten und Kenntnisse sollen nach den in Anlage 2 enthaltenen Anleitungen zur sachlichen und zeitlichen Gliederung der Berufsausbildung (Ausbildungsrahmenplan) vermittelt werden. Eine von dem Ausbildungsrahmenplan abweichende sachliche und zeitliche Gliederung des Ausbildungsinhaltes ist insbesondere zulässig, soweit betriebspraktische Besonderheiten die Abweichung erfordern.

§ 12 (Ausbildungsplan)

Der Ausbildende hat unter Zugrundelegung des Ausbildungsrahmenplanes für den Auszubildenden einen Ausbildungsplan zu erstellen.

Als Azubi

Der Azubi hat auch ein Interesse an einem sinnvollen betriebliche Ausbildungsplan, damit er seine für die Berufspraxis und auch für die Abschlussprüfung nötigen Kenntnisse optimal erlernen kann. Aufeinander aufbauende Themen sollten also z.B. nacheinander und in der richtigen Reihenfolge behandelt werden. Außerdem sollten die schwierigeren Themen vielleicht eher gegen Ende der Ausbildung vermittelt werden. Zuletzt kann der Azubi anhand des betrieblichen Ausbildungsplans auch kontrollieren, ob er in seinem Unternehmen korrekt ausgebildet wird.

Woher bekomme ich als Azubi meinen betrieblichen Ausbildungsplan?

Deinen betrieblichen Ausbildungsplan bekommst du von deinem Ausbildungsunternehmen. Er muss dir zusammen mit deinem Ausbildungsvertrag ausgehändigt werden (s.o.). Solltest du noch keinen Ausbildungsplan bekommen haben, wende dich an deinen Ausbilder oder eure Personalabteilung.

Wie erstelle ich als Ausbilder einen betrieblichen Ausbildungsplan?

Die fachlichen Inhalte der Ausbildung sind durch den Ausbildungsrahmenplan (siehe Anlage 2 Teil A ITKTAusbV) vorgegeben. Auch eine mögliche Aufteilung auf die drei Ausbildungsjahre inkl. Vorschlägen für die zeitliche Dauer ist vorgegeben (siehe Anlage 2 Teil B ITKTAusbV). Die ca. 200 einzelnen Punkte müssen also „nur noch“ in den betrieblichen Ausbildungsplan überführt werden. Dazu kann man z.B. Excel verwenden (siehe Vorlagen weiter unten).

W-Fragen zum Einstieg

Zu jedem Punkt aus der Liste sollte man sich grundsätzlich erst einmal einige „W-Fragen“ stellen (und beantworten):

• Was soll vermittelt werden? Das steht zwar im Ausbildungsrahmenplan, aber die bewusst allgemein gehaltenen Formulierungen (z.B. 5.2b Programmierlogik und Programmiermethoden anwenden) müssen teilweise erstmal in die Neuzeit bzw. auf konkrete Technologien übersetzt werden (z.B. Java und C#).
• Wo wollen wir die Inhalte vermitteln? Bei Unternehmen mit mehreren Standorten oder Abteilungen, die die Azubis durchlaufen, muss z.B. der geeignete Ort für den konkreten Inhalt ausgewählt werden.
• Wer übernimmt die Vermittlung der Inhalte? Das können Ausbilder, Ausbildungsbeauftragte, Paten, externe Dozenten etc. sein.
• Wie sollen die Inhalte optimal vermittelt werden? Welche Lehr- und Lernmethoden sollen angewendet werden, z.B. Projektarbeit, Selbststudium, Lehrgespräch.
• Wann werden die Inhalte am besten vermittelt? In welches Ausbildungsjahr passen die Inhalte am besten und welche vorbereitenden Themen müssen evtl. abgehakt sein?

Kritische Bewertung des Ausbildungsplans

Zusätzlich bieten sich die folgenden Fragen an, die vielleicht bei der Abarbeitung der großen Liste helfen und zu einem sinnvollen Plan führen:

• Welche Ausbildungsinhalte kann das Unternehmen selbst vermitteln bzw. vermittelt es vielleicht sogar schon? Hier kann man die konkreten Schulungen oder Projekte zusammentragen (z.B. Einführungsschulung, Datenbank-Training), ihren Zeitbedarf festhalten, eine sinnvolle Reihenfolge der Inhalte festlegen, zuständige Mitarbeiter benennen und die konkreten Einsätze planen.
• Welche Ausbildungsinhalte kann das Unternehmen nicht selbst vermitteln? Hier sind evtl. externe Schulungen einzuplanen oder gar Kooperationen mit anderen Unternehmen abzuschließen. Alternativ können die fehlenden Inhalte auch in-house aufgebaut werden.
• Welche fachlichen Inhalte lassen sich gut gemeinsam vermitteln (z.B. Java und SQL in einem Programmierprojekt mit Datenbankanbindung)?
• Welche Inhalte lassen sich (auch lehrjahrübergreifend) mehreren Azubis gleichzeitig vermitteln, um Zeit zu sparen?
• Wie wird der Lernerfolg bei den Azubis kontrolliert, z.B. mit Tests oder Lernzielkontrollen?

Vorlage für den betrieblichen Ausbildungsplan für Fachinformatiker Anwendungsentwicklung und Systemintegration

Vor einiger Zeit habe ich hier im Blog schon einmal eine Vorlage für den Ausbildungsplan zum Fachinformatiker Anwendungsentwicklung in Excel bereitgestellt. Diese Vorlage habe ich nun überarbeitet und sie außerdem auch für Fachinformatiker Systemintegration erstellt.

Sachliche und zeitliche Gliederung

Die Excel-Dateien enthalten sowohl die sachliche, als auch die zeitliche Gliederung aus Anlage 2 (Ausbildungsrahmenplan für Fachinformatiker) der Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik für beide Fachrichtungen des Fachinformatikers inkl. der Änderungen durch die Neuordnung der IT-Berufe im Jahr 2018.

Die sachliche Gliederung enthält alle zu vermittelnden Inhalte, die im Rahmen der Ausbildung den Auszubildenden beigebracht werden müssen.

Die zeitliche Gliederung enthält die obigen Inhalte auf die drei Ausbildungsjahre verteilt. Hier wird eine sinnvolle Verteilung vorgeschlagen, die die Ausbildungsunternehmen aber nicht einhalten müssen. Vielmehr müssen diese die Inhalte auf die eigenen Bedürfnisse und Möglichkeiten anpassen und damit genau den betrieblichen Ausbildungsplan erstellen.

Zu ergänzen sind dann u.a. noch konkrete Beispiele für die Vermittlung der Inhalte und wer die Unterweisung in welcher Form (z.B. Schulung, Selbststudium) durchführen soll.

Download der Ausbildungspläne

• Ausbildungsplan Fachinformatiker Anwendungsentwicklung ab 2018
• Ausbildungsplan Fachinformatiker Systemintegration ab 2018

Der Vollständigkeit halber habe ich hier auch noch einmal die bis 2018 gültigen Ausbildungspläne verlinkt. Sie sind aufgrund der Neuordnung der IT-Berufe inzwischen veraltet und sollten nicht mehr zum Erstellen neuer Ausbildungspläne genutzt werden.

• Achtung, veraltet: Ausbildungsplan Fachinformatiker Anwendungsentwicklung bis 2018
• Achtung, veraltet: Ausbildungsplan Fachinformatiker Systemintegration bis 2018

Mein Vorgehen

Als kleine Hilfe zum Einstieg in die Erstellung des betrieblichen Ausbildungsplans habe ich hier zusammengestellt, wie ich selbst den betrieblichen Ausbildungsplan für die ALTE OLDENBURGER Krankenversicherung AG erstellt bzw. nach der Neuordnung 2018 aktualisiert habe.

Zunächst habe ich mir zu allen Punkten konkrete Beispiele überlegt, um die abstrakten Vorgaben etwas greifbarer zu machen, z.B. die konkrete Programmiersprache Java mit ihren Features. Dann habe ich überlegt, welche Maßnahmen ich bereits für meine Azubis vorbereitet bzw. geplant habe und sie den passenden Punkten zugeordnet (z.B. Java-Schulung oder Azubi-Projekte). Dabei habe ich gleich dokumentiert, in welchem Ausbildungsjahr sie optimalerweise durchgeführt werden sollten bzw. schon werden (z.B. Einführung in Java im 1. Lehrjahr). Und zum Schluss habe ich dann noch Ressourcen ergänzt, die für die Vermittlung verwendet werden können. Für Punkte, die ich noch klären muss (z.B. Inhalte mit Ausbildungsbeauftragten abstimmen) habe ich mir dann nebenbei auch noch einige TODOs ergänzt.

Diese Spalten habe ich rechts neben Spalte C „Fertigkeiten und Kenntnisse, die unter Einbeziehung selbständigen Planens, Durchführens und Kontrollierens zu vermitteln sind“ ergänzt und gefüllt:

• Beispiele: Welche konkreten Inhalte sind zu vermitteln?
• Maßnahme: Im Rahmen welcher (bestehenden) Ausbildungsmaßnahmen (z.B. Projekt, Schulung) werden die Inhalte vermittelt?
• Ausbildungsjahr: In welchem Ausbildungsjahr (1-3) sind die Inhalte sinnvoll?
• Planung: Findet die Vermittlung immer wieder zu einem bestimmten Zeitpunkt statt oder wenn es gerade zu den sonstigen Tätigkeiten passt?
• Methodik: Welche Lehrmethode soll eingesetzt werden (z.B. Selbststudium, Lehrgespräch, Projektarbeit)?
• Ressourcen: Welche (bereits vorhandenen) Ressourcen können zur Vermittlung genutzt werden (z.B. Schulungsunterlagen, Podcast-Episoden)?
• TODO: Was muss zu diesem Punkt noch geklärt werden, z.B. Rückfragen bei der IHK oder den Ausbildungsbeauftragten oder das Erstellen von Schulungsmaterial.

So sieht dann z.B. das Ergebnis für „5.4 IT-Sicherheit, Datenschutz und Urheberrecht (§ 10 Abs. 1 Nr. 5.4)“ aus:

Checkliste für die sachliche Gliederung

• Enthält die sachliche Gliederung alle Fertigkeiten und Kenntnisse aus dem Ausbildungsrahmenplan?
• Werden in der Probezeit Ausbildungsinhalte vermittelt, die Aussagen über die Eignung und die Interessen des Auszubildenden ermöglichen?
• Werden Fertigkeiten und Kenntnisse zu Ausbildungseinheiten zusammengefasst, die sich einzelnen Bereichen des Unternehmens zuordnen lassen?
• Haben die einzelnen Ausbildungseinheiten einen sinnvollen Umfang (nicht zu lang und nicht zu kurz) bzw. wurden größere Einheiten in mehrere Teile zerlegt?
• Werden in der gesamten Ausbildung und auch in jeder Ausbildungseinheit die grundlegenden Kenntnisse zuerst vermittelt und die tiefergehenden später?
• Werden externe Schulungen zeitlich mit den innerbetrieblichen Maßnahmen abgestimmt?

Checkliste für die zeitliche Gliederung

• Lassen sich die Inhalte in einer normalen dreijährigen Ausbildung vollständig und verständlich vermitteln?
• Folgt die zeitliche Gliederung einem pädagogischen Konzept?
• Werden die Termine der Zwischen- und Abschlussprüfungen berücksichtigt?
• Wird auch die Abwesenheit des Azubis berücksichtigt (z.B. Urlaub)?
• Falls in der Ausbildungsordnung konkrete Zeiten vorgeschrieben werden, sind diese berücksichtigt?
• Besteht die zeitliche Gliederung aus überschaubaren Abschnitten, die max. 6 Monate lang sind?

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik
• Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik Anlage 2 Teil A (zu § 11) Ausbildungsrahmenplan für die Berufsausbildung zum Fachinformatiker/zur Fachinformatikerin – Sachliche Gliederung
• Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik Anlage 2 Teil B (zu § 11) Ausbildungsrahmenplan für die Berufsausbildung zum Fachinformatiker/zur Fachinformatikerin – Zeitliche Gliederung
• Beispiel für eine sachliche und zeitliche Gliederung der Berufsausbildung als Anlage zum Berufsausbildungsvertrag
• Beispielhafte Handlungshilfen zum Erstellen eines betrieblichen Ausbildungsplanes
• Wie erstelle ich den Ausbildungsplan?
• Beispiele für betriebliche Ausbildungspläne
  • Beispiel für einen Ausbildungsplan für Fachinformatiker Systemintegration von der RWTH Aachen (von 2019)
  • Beispiel für einen Ausbildungsplan für Fachinformatiker Anwendungsentwicklung der UBEN GmbH (von 2012)
  • Beispiel für einen Ausbildungsplan für Fachinformatiker Systemintegration von Max Bögl (von 2004)

Der Beitrag Betrieblicher Ausbildungsplan für Fachinformatiker – Anwendungsentwickler-Podcast #135 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Um den Aufbau von URLs geht es in der einhundertsechsunddreißigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Use Case

• Was passiert technisch, wenn der Browser eine Website anzeigt?
  • Übrigens: Unterschied Website/Homepage: Eine Website ist die Gesamtheit an Inhalten des Anbieters, während die Homepage lediglich die Startseite des Angebots bezeichnet.
• Der Client ruft eine Adresse im Browser auf und der Server liefert HTML zurück, das der Browser rendert (in eine grafische Darstellung umwandelt) und auf dem Client darstellt.
  • Übrigens: Intranet vs. Internet: Der grundsätzliche Vorgang ist derselbe, nur der Webserver steht im internen Netz bzw. ist nur aus dem internen Netz heraus erreichbar.

URLs

• Woher wissen Client und Server, wohin sie ihre Daten schicken müssen?
• Der Client muss zunächst die Zieladresse kennen. Dies ist meistens ein URL wie z.B. www.google.com
• URL steht für Uniform Resource Locator.
• Wie sind URLs aufgebaut?
  • Beispiel: http://blog.macke.it/posts/post.php?id=123#comments
  • Der erste Teil ist das sogenannte Schema oder Protokoll. Davon gibt es mehrere, nicht nur http, sondern z.B. auch noch ftp oder mailto (Pseudo-Protokoll).
  • Die Domain ist hierarchisch von rechts nach links absteigend aufgebaut. Die Top Level Domain ist z.B. de oder com. Danach kommt die eigentliche Domain mit ggfs. Subdomain und Hostname. Das www ist übrigens der Hostname (übliche Bezeichnung des Webservers) und nicht verpflichtend in einem URL!
  • Danach kommt der Pfad, der vergleichbar mit einem Pfad und einer Datei auf einer Festplatte ist. Das php steht für die Programmiersprache PHP, mit der Websites entwickelt werden können.
  • Nach dem Dateinamen können Parameter als Schlüssel/Wert-Paare angegeben werden, um z.B. mit einer physikalischen Datei unterschiedliche Artikel in einem Warenkorb anhand ihrer ID anzeigen zu können.
  • Zuletzt ist noch ein Abschnitt möglich, über den man z.B. direkt auf eine Überschrift mitten auf der aktuellen Seite springen kann. Das Zeichen # heißt übrigens „Hash“ und nicht „Hashtag“.
  • Benutzername und Passwort zum Zugriff auf die Ressourcen können ebenfalls angegeben werden. Sie werden vor die Domain geschrieben: http://benutzer:passwort@macke.it.

Literaturempfehlungen

Im guten alten IT-Handbuch für Fachinformatiker* werden in Kapitel 4 Netzwerkgrundlagen die meisten hier genannten Inhalte ausführlich erläutert. In meinem Buchclub gehe ich auf die Inhalte auch noch einmal im Detail ein.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Website
• Homepage
• Uniform Resource Locator
• Domain (Internet)

Der Beitrag URLs (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #136 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Um den Aufbau und die Darstellung von IP-Adressen geht es in der einhundertsiebenunddreißigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

IP-Adresse

• URLs sind für Menschen einigermaßen gut zu verstehen und zu merken, aber Computer kommunizieren leider nicht über URLs, sondern über IP-Adressen.
• Eine IP-Adresse ist eine 32 Stellen lange Folge von Nullen und Einsen. Das Bit ist die kleinste Informationseinheit der Informatik und kann genau diese beiden Werte annehmen. Also ist eine IP-Adresse 32 Bit lang.
• Da sich wenige Menschen 32 Stellen lange Zahlen merken können, gibt es eine bessere Schreibweise für IP-Adressen: man spaltet die 32 Bit in 4 x 8 Bit auf und wandelt diese Teile jeweils um in eine Dezimalzahl.
• Das funktioniert ganz einfach: Jede Stelle einer Binär- bzw. Dualzahl steht von rechts ausgehend für ein Vielfaches von 2. Die Summe der entsprechenden Stellen der Binärzahl malgenommen mit dem Wert der ihnen zugeordneten Zweierpotenzen ergibt die Dezimalzahl.
• Die minimale Dezimalzahl für eine Stelle der IP-Adresse ist 0. Die maximale Dezimalzahl für eine Stelle der IP-Adresse ist 255.
• 10101000 (Basis 2) = 168 (Basis 10)
  • 10101000 = 1 * 2^8 + 0 * 2^7 + 1 * 2^6 + 0 * 2^5 + 1 * 2^4 + 0 * 2^3 + 0 * 2^2 + 0 * 2^1 = 128 + 32 + 8 = 168

Literaturempfehlungen

Im guten alten IT-Handbuch für Fachinformatiker* werden in Kapitel 4 Netzwerkgrundlagen die meisten hier genannten Inhalte ausführlich erläutert. In meinem Buchclub gehe ich auf die Inhalte auch noch einmal im Detail ein.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• IP-Adresse
• IPv6

Der Beitrag IP-Adressen (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #137 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Um zwei zentrale Technologien der Netzwerkgrundlagen – DNS und DHCP – geht es in der einhundertachtunddreißigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

DNS

• Theoretisch können wir auch im Internet surfen, indem wir die IP-Adressen der Websites eingeben, aber das kann sich kein Mensch merken.
• Daher sind Websites über einen sprechenden Namen, die Domain, erreichbar. Dafür brauchen wir dann aber eine Übersetzung von Domainname in IP-Adresse, damit der Computer kommunizieren kann.
• Einfachste Möglichkeit: Datei mit Übersetzung von IP in Domain (gibt es tatsächlich: hosts unter Windows z.B. unter C:\Windows\System32\drivers\etc, die Paare aus IP-Adressen und Hostnamen enthält). Dann müsste aber jeder Computer die gesamte Liste aller verfügbaren Domains kennen. Das ist nicht machbar.

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#       127.0.0.1       localhost
#       ::1             localhost

136.243.146.110 macke.it

• Die Lösung ist DNS (Domain Name System), ein „Telefonbuch“ für Websites/IP-Adressen, das auf viele Server verteilt ist.
• Mit dem Kommandozeilentool nslookup können DNS-Server abgefragt werden.
  
• DNS kann kaskadiert werden. Wenn ein Server nicht weiter weiß, fragt er den übergeordneten Server und speichert (cacht) ggfs. das Resultat für die nächste Anfrage.
• Die letzte Instanz der Kaskade sind die sog. Root-Server.
• Die sogenannten Websperren gegen „verbotene“ Websites funktionieren im Prinzip so, dass einzelne „Telefonbücher“ (z.B. die der deutschen Internetprovider) gesäubert werden. Aber man kann sie einfach umgehen, indem man bewusst einen anderen DNS-Server verwendet, der z.B. in einem anderen Land steht.

DHCP

• Zurück zu unserem Aufruf: Der Client ruft eine Adresse im Browser auf und der Server liefert ihm HTML zurück. Aber dazu braucht der Client auch eine IP-Adresse.
• Die Zieladresse ist dank DNS bekannt, aber man braucht auch eine Quelladresse für den Client. Die kann man selbst vergeben, aber das wird bei mehreren PCs immer schwieriger, da sie eindeutig sein müssen (sonst weiß das Netzwerkpaket der Antwort nicht, wo es hin muss).
• Die Lösung heißt DHCP (Dynamic Host Configuration Protocol). Das ist ein Dienst, den ein Server (zuhause z.B. die FRITZ!Box*) bereitstellt, der sich dann z.B. die Liste der bereits verwendeten IP-Adressen merkt und keine doppelt vergibt. Außerdem kann man viele weitere Einstellungen (wie z.B. den zu nutzenden DNS-Server) per DHCP an die Clients verteilen.
  

Literaturempfehlungen

Im guten alten IT-Handbuch für Fachinformatiker* werden in Kapitel 4 Netzwerkgrundlagen auch DNS und DHCP erläutert. In meinem Buchclub gehe ich auf die Inhalte auch noch einmal im Detail ein.

*

Für die Prüfungsvorbereitung musst du aber dein Wissen noch vertiefen! Literaturempfehlungen zur Netzwerktechnik evaluiere ich aktuell und reiche sie später nach.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Domain Name System
• Root-Nameserver
• Dynamic Host Configuration Protocol

Der Beitrag DNS und DHCP (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #138 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Meine Erkenntnisse (positiv wie negativ) aus der IHK-Sommerprüfung 2019 teile ich mit euch in der einhundertneununddreißigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Projektdokumentation

• Verwendung unnatürlicher Sprache („bei dem“ statt „beim“, „Leerung der Datenbank“ statt „Datenbank leeren“)
• Kapitel meiner Vorlage werden ausgefüllt, auch wenn die Inhalte überhaupt nicht sinnvoll sind
  • „Eine Nutzwertanalyse war nicht sinnvoll, deswegen habe ich darauf verzichtet.“
  • Identische Inhalte werden gleich mehrfach wiederholt (u.a. aus dem Antrag übernommen), z.B. bei der Projektbegründung und Zieldefinition
• Wichtige Inhalte fehlen
  • insgesamt viel zu wenig Text (8 Seiten statt 15)
  • Benutzer-/Entwickler-Dokumentation (gibt direkt >10% Abzug), und nein, ein PHP-Doc-Block ohne Inhalt reicht nicht aus
  • trotz explizitem Hinweis der Prüfer im Antrag wurden keine Diagramme erstellt, weil diese „nicht sinnvoll“ waren
  • Qualitätssicherung fehlt häufig komplett (abgesehen vom scheinbar obligatorischen „Code-Review“)
• Qualitätssicherung
  • „Die Methoden wurden auf Komplexität geprüft“ (sind im Anhang aber >70 Zeilen lang)
  • „Viel Wert auf Clean Code gelegt“ (aber doppelter Code, Magic Numbers, harte Pfade, komplexe switches im Anhang)
  • „Die Übertragung muss verschlüsselt erfolgen“ (aber alle URLs beginnen mit http)
  • „Code Coverage muss >90% sein“ (aber nicht einen Test gezeigt)
  • Debugger/Konsole wird für „Tests“ genutzt
• Fehler in der Wirtschaftlichkeits-/Amortisationsrechnung
  • „Pauschale“ für Ressourcennutzung angesetzt, wird aber nicht mit eingerechnet
  • laufende Kosten des Projekts gibt es nicht
  • Kosten des Unternehmens werden Einsparungen des Kunden gegenübergestellt
  • bei der Kostenplanung werden große Kostenverursacher „vergessen“
  • Vergleich mit fiktiven Kosten von einer Website, die Kosten für Apps schätzt
• Fehler in Diagrammen
  • ERM enthält m:n-Tabellen
  • include vs. extends im Use-Case-Diagramm
• Aktionen werden nicht in der Zeitplanung berücksichtigt (4h Schulung)
• Uninteressante Inhalte werden viel zu detailliert dargestellt
  • langweiliger Sourcecode über mehrere Seiten im Anhang, 8 (!) Seiten Mockups und 6 Seiten Quelltext im Anhang
  • Hardware des Arbeitsplatzrechners bis runter auf die RAM-Art und Typ der Grafikkarte erklärt
  • Zeitplanung/Projektaufbau in drei verschiedenen Varianten dargestellt (Gantt, Tabelle, Projektstrukturplan)
  • lächerlich einfache Abläufe mit Diagrammen dargestellt (Sequenzdiagramm mit einmal hin und zurück, Aktivitätsdiagramm mit einer einzigen Verzweigung)
  • teils völlig sinnlose und nicht im Zusammenhang zum Inhalt stehende Komponenten (z.B. Auszug aus pom.xml ohne Erläuterung)
  • minified (!) CSS/JavaScript wird gezeigt
• Overkill
  • Kostenkalkulation über 3 Seiten mit zig mathematischen Formeln mit Indizes (z.B. K_Kunde + K_fix) etc.
  • komplette Seite für typographische Konventionen
  • 5 (!) Überschriftenebenen (z.B. „3.1.1.4. a)“)
  • Diagramm der Amortisationsrechnung mit mathematischer Software geplottet
  • „wissenschaftliche“ Erklärung von Vorgehensmodellen mit Quellennachweis und wörtlichen Zitaten über mehrere Zeilen, aber aus der Wikipedia
• nervige Kleinigkeiten
  • Abkürzungsverzeichnis nicht sortiert
  • Seitennummerierung fehlerhaft
  • Quellennachweise, die lediglich Links enthalten ohne Bezug zu irgendeinem Inhalt
• handwerkliche Fehler
  • Passwörter im Klartext in der Applikation speichern oder sogar übers Netzwerk schicken
  • Geschäftslogik im Controller

Projektpräsentation

• viele Frameworks verwendet, aber nur die (nichtssagenden) Logos gezeigt
• Codebeispiele enthalten TODOs und Hinweise der IDE
• Rechtschreibfehler auf den Folien
• winziger Text
• Grafiken überlagern Textelemente
• Cliparts verwendet
• Unternehmen zu lang vorgestellt
• eigenen Namen nicht genannt und nicht gezeigt
• Tabelle mit Zeitplanung zeilenweise vorgelesen

Fachgespräch

• GA1 hat viele gute Prüflinge stark runtergezogen
• Wirtschaftsfragen gehen gar nicht (Stundensatz, Gehaltsabrechnung, brutto/netto, Einzel-/Gemeinkosten, BAB)
• Sourcecodebestandteile können nicht erläutert werden
  • Nullable Types, Structs, Lambdas, Generics, Typinferenz, Traits, Typisierung der verwendeten Sprache, Type Hints in PHP
  • ===, ??, static, finally, out-/ref-Parameter
• Architekturen können nicht erläutert werden
  • MVC, Dependency Injection, Domain Driven Design
• Rechtsform des eigenen Unternehmens kann nicht erläutert werden
• Urheberrechtshinweis auf eigenem Deckblatt kann nicht erläutert werden
• Datenschutz vs. Datensicherung vs. Datensicherheit können nicht abgegrenzt werden
• „Habe ich das so geschrieben?“ (Prüfling kennt die eigene Doku nicht)

Lichtblicke

• Zusammenhang zwischen Lasten- und Pflichtenheft hergestellt (baut aufeinander auf)
• Mockups auf Papier selbst gezeichnet
• Tickets statt (fiktivem) Lastenheft verwendet
• Präsentation einer Webanwendung wie Browser-Tabs gestaltet
• direkter Vergleich des entworfenen Mockups mit der finalen Oberfläche der Webanwendung
• Entscheidung für ein Vorgehensmodell sauber begründet (Wasserfall, da Anforderungen feststehen)
• Inhalte der Präsentation auf Prüfungsausschuss individualisiert (als Adresse auf einem Aufkleber die der BBS verwendet)
• Amortisationsrechnung im Nachhinein durch Vergleich der Planung mit den echten Zeitersparnissen validiert

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts

Der Beitrag Rückblick auf die IHK-Sommerprüfung 2019 – Anwendungsentwickler-Podcast #139 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.

Um private IP-Adressbereiche und das Routing von Netzwerkpaketen geht es in der einhundertvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Private IP-Adressbereiche

• Da es im aktuellen Standard IPv4 nicht genug IP-Adressen für alle Teilnehmer auf der Welt gibt, muss eine Möglichkeit geschaffen werden, IP-Adressen abgeschlossen vom Internet zu vergeben, um interne Netzwerke betreiben zu können.
• Es gibt einige fest definierte IP-Adressbereiche, die im Internet nicht verfügbar sind: die privaten IP-Adressbereiche 10.0.0.0, 172.16.0.0 (bzw. genauer 172.16.0.0 bis 172.31.255.255) und 192.168.0.0.
• Aber wenn sie im Internet nicht verfügbar sind, wie kommt man dann ins Netz?

Routing und NAT

• Es wird ein Gerät benötigt, dass zwischen das private und das öffentliche Netz geschaltet wird: ein Router. Der „übersetzt“ quasi zwischen Intra- und Internet.
• Private IP-Adressen sind im Internet nicht auffindbar (sie werden nicht „geroutet“). Daher ersetzt der Router auf dem Hinweg die private Quell-IP-Adresse des Clients durch seine eigene öffentliche IP-Adresse des Internetanschlusses (z.B. per DSL oder Kabel). An diese kann der Webserver die Antwort auf die Anfrage dann zurückschicken.
• Wenn dann später die Antwort des Webservers im Router eintrifft, muss dieser die Ziel-IP-Adresse des Pakets wieder auf die private IP-Adresse des Clients setzen und das Paket an diesen weiterleiten.
• Dafür muss sich der Router „merken“, welcher Client welche Anfrage an welchen Server gestellt hat, damit er die Antworten passend zuordnen kann.
• Dieses Prinzip heißt NAT (Network Address Translation) und ermöglicht mehreren Clients mit verschiedenen privaten IP-Adressen über einem gemeinsamen Router mit einer einzigen öffentlichen IP-Adresse ins Internet zu gelangen.
• Auch der Router hat meist keine direkte Verbindung zum Zielserver, sondern muss die Pakete auf eine „Reise“ durch das Netzwerk schicken, bis es (ggfs. über mehrere weitere Router hinweg) beim Ziel ankommt. Aber woher weiß der Router, an welchen anderen Router er das Paket ggfs. schicken muss?
• Das Default Gateway ist der „nächste Knoten“ im Netzwerk auf dem Weg zur Zieladresse. Dieser wird immer angesprungen, wenn der Zielknoten nicht direkt erreichbar ist. Diese Übersetzung kann man beliebig fortführen. Ein Client muss dazu nur die Adresse seines Routers kennen, der dann wiederum einen Router kennt, der dann das weitere Routing übernimmt usw. Irgendwann landet das Paket bei einem Knoten, der direkt mit dem Ziel kommunizieren kann, und es wird zugestellt.
• In unserem Heimnetzwerk übernimmt die Fritzbox übrigens mehrere Rollen gleichzeitig: DHCP- und DNS-Server sowie Router und Default Gateway.
• Gateways müssen nicht immer Router sein, aber de facto sind sie es heute so gut wie immer, da die historische Aufgabe, Netzwerke unterschiedlicher Technologien (z.B. IP und IPX/SPX) miteinander zu verbinden, durch den flächendeckenden Einsatz von IP nicht mehr benötigt wird.
• Mit dem Kommandozeilentool tracert (oder traceroute unter Linux) kann man den Weg zum Ziel über alle Knoten dazwischen verfolgen. Dazu wird der TTL-Eintrag (Time to live) des IP-Pakets genutzt, den jeder Knoten automatisch herunterzählt. Bei 0 angekommen wird das Paket verworfen. Dabei wird aber eine Info an den Sender mit der Adresse des verwerfenden Knotens geschickt. tracert verschickt nun der Reihe nach Pakete mit TTL 1, 2, 3, 4 usw. und gibt die Adressen der verwerfenden Knoten aus.
  

Literaturempfehlungen

Im guten alten IT-Handbuch für Fachinformatiker* werden in Kapitel 4 Netzwerkgrundlagen die meisten hier genannten Inhalte ausführlich erläutert. In meinem Buchclub gehe ich auf die Inhalte auch noch einmal im Detail ein.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Private IP-Adresse
• Router
• Gateway (Informatik)
• Netzwerkadressübersetzung
• Time to Live

Der Beitrag Routing (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #140 erschien zuerst auf Fachinformatiker Anwendungsentwicklung.