IT-Berufe-Podcast Archiv

Die Fortsetzung zum Oberthema Kryptographie mit Hashverfahren und elektronischer Signatur gibt es in der einhunderzweiunddreißigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Mit Hash-Verfahren prüfe ich, ob sich Daten verändert haben: Aus beliebig langen Daten entsteht ein Hash-Wert mit fester Länge, den du mit dem Hash der Originaldaten vergleichst. Eine elektronische Signatur verbindet diesen Hash mit dem privaten Schlüssel der absendenden Person und macht damit auch die Herkunft prüfbar. Wenn ich die signierte E-Mail zusätzlich mit dem öffentlichen Schlüssel der empfangenden Person verschlüssele, bleibt ihr Inhalt vertraulich. Für deine Abschlussprüfung solltest du die Eigenschaften von Hash-Verfahren und den Ablauf beim Signieren kennen. Kapitelmarken [00:00:00] Einstieg in Kryptografie Teil 2 [00:01:33] Asymmetrische Verfahren und Schlüsselpaare [00:02:21] Integrität und Authentizität [00:04:37] Hash-Verfahren und feste Hash-Längen [00:05:46] Kollisionen und Einwegverfahren [00:07:09] Gehashte Passwörter und Begriffe in der Prüfung [00:08:47] Gleiche Eingaben und kollisionsarme Verfahren [00:12:45] Hash-Längen und die Schwächen von MD5 [00:14:44] Downloads mit dem Original-Hash vergleichen [00:16:18] Kleine Änderungen und deutlich andere Hash-Werte [00:17:54] Eigenschaften von Hash-Verfahren für die Prüfung [00:19:45] Hash-Werte beim E-Mail-Versand [00:21:03] Angriffe auf ungeschützte Hash-Anhänge [00:21:44] Herkunft mit dem privaten Schlüssel nachweisen [00:26:20] Mehrere Schutzschichten für eine E-Mail [00:28:38] Den Hash mit dem privaten Schlüssel absichern [00:29:53] Elektronische Signatur und die Unterschrift im Mietvertrag [00:33:57] Ablauf beim signierten und verschlüsselten E-Mail-Versand [00:36:02] Schlüssel austauschen und Aufwand in der Praxis [00:36:41] Prüfungsbezug und Abschluss 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 Zusammenfassung Schlüssel und Schutzziele Wenn ich dir eine vertrauliche Nachricht schicke, verschlüssele ich sie mit deinem öffentlichen Schlüssel. Du kannst sie mit deinem privaten Schlüssel wieder entschlüsseln. Für dieses asymmetrische Verfahren brauchst du ein Schlüsselpaar, dessen privater Teil geheim bleiben muss. Den öffentlichen Teil kannst du weitergeben. Bei einer E-Mail möchtest du außerdem prüfen können, ob ihr Inhalt unterwegs verändert wurde und von wem sie stammt. Dafür stehen die Schutzziele Integrität und Authentizität. Als Grundlage für die folgenden Abläufe brauchst du die asymmetrischen Verfahren, die ich in Episode 131 behandelt habe. Wie ein Hash entsteht Wenn ich eine Datei durch eine Hash-Funktion laufen lasse, erhalte ich einen Hash-Wert, auch Prüfsumme genannt. Die Eingabedaten dürfen beliebig lang sein. Wie lang das Ergebnis ist, legt das jeweilige Verfahren fest: MD5 erzeugt beispielsweise 128 Bit lange Hash-Werte; als weiteres Beispiel kommt SHA mit 256 Bit vor. Für Hash-Verfahren gelten folgende Eigenschaften: Gleiche Daten ergeben denselben Hash. Dadurch kannst du das Ergebnis erneut berechnen und vergleichen. Die Länge des Ergebnisses bleibt fest. Sie hängt vom Verfahren ab, auch wenn du eine große Datei oder nur einen Buchstaben eingibst. Das Verfahren arbeitet in eine Richtung. Aus dem Hash lässt sich die ursprüngliche Datei als Ganzes nicht zurückrechnen. Kleine Änderungen sollen den Hash deutlich verändern. Bereits ein geändertes Bit soll zu einem erheblich anderen Ergebnis führen. Ein gutes Verfahren ist kollisionsarm. Unterschiedliche Eingaben sollen möglichst selten denselben Hash ergeben. In meinen Prüfungen kommt es vor, dass Prüflinge gehashte Passwörter als "verschlüsselt" bezeichnen. Der passende Begriff lautet hier gehasht. Hash-Verfahren sind mathematische Einwegverfahren. Beim Verschlüsseln bleiben die Informationen erhalten, sodass du die Originaldaten mit dem passenden Schlüssel wiederherstellen kannst. Kollisionen und die Sicherheit eines Verfahrens Weil ein Hash eine feste Länge hat, gibt es nur eine begrenzte Anzahl möglicher Hash-Werte. Für die Eingabedaten stehen beliebig viele Möglichkeiten zur Verfügung. Deshalb können verschiedene Eingaben denselben Hash erzeugen. Das heißt Kollision. Ein geeignetes Verfahren muss es rechnerisch schwer machen, solche passenden Eingaben zu finden. Die Sicherheit hängt davon ab, wie viel Aufwand ein Angriff erfordert. Schnellere Rechner können diesen Aufwand verringern; auch die Länge des Hash-Werts spielt dabei eine Rolle. MD5 wird als Beispiel für ein bereits geknacktes Verfahren behandelt. Für schützenswerte Daten solltest du es deshalb nicht mehr einsetzen. Sobald sich mit vertretbarem Aufwand passende manipulierte Daten erzeugen lassen, ist das betreffende Verfahren für diesen Zweck unsicher. Eine heruntergeladene Datei prüfen Wenn ich eine Datei herunterlade, brauche ich zum Prüfen den Hash der Originaldatei. Diesen kann der/die Hersteller:in beispielsweise neben dem Download auf der Website veröffentlichen. Du gehst so vor: Lade die Datei herunter und berechne ihren Hash mit dem angegebenen Verfahren. Vergleiche dein Ergebnis mit dem veröffentlichten Original-Hash. Bei abweichenden Werten unterscheiden sich die Daten. Die Ursache musst du gesondert herausfinden: Beim Übertragen kann ein Fehler passiert sein, ebenso können die Daten gezielt verändert worden sein. Der Hash-Vergleich zeigt dir die Abweichung, ohne ihren Grund zu bestimmen. Den Hash einer E-Mail absichern Wenn ich den Hash einer E-Mail als Anhang mitschicke, kannst du selbst einen Hash über den empfangenen Inhalt berechnen und beide Werte vergleichen. Ein:e Angreifer:in könnte allerdings den Text verändern und dazu einen neuen passenden Hash anhängen. Deshalb muss auch die Herkunft des mitgeschickten Hash-Werts prüfbar sein. Dafür kommt der private Schlüssel der absendenden Person ins Spiel. Im vereinfachten Ablauf verschlüssele ich den Hash mit meinem privaten Schlüssel. Du prüfst ihn mit meinem öffentlichen Schlüssel, dessen Zugehörigkeit zu mir sicher feststehen muss. Elektronische Signatur Aus dem Hash des Inhalts und dem privaten Schlüssel entsteht die elektronische Signatur. Wenn ich eine E-Mail signiere, läuft das im beschriebenen Modell so ab: Ich berechne einen Hash über den E-Mail-Inhalt. Diesen Hash verschlüssele ich mit meinem privaten Schlüssel und hänge ihn an die Nachricht. Du entschlüsselst den angehängten Hash mit meinem öffentlichen Schlüssel. Über den empfangenen E-Mail-Inhalt berechnest du selbst einen Hash und vergleichst beide Werte. Der öffentliche Schlüssel macht die Herkunft prüfbar. Der Hash-Vergleich prüft, ob der Inhalt seit dem Signieren unverändert geblieben ist. Voraussetzung ist, dass mein privater Schlüssel geheim geblieben ist und du meinen öffentlichen Schlüssel sicher zuordnen kannst. Als Bild dafür verwende ich meinen Mietvertrag, den ich auf jeder Seite unterschreiben musste. Die Unterschrift ordnet den Vertrag einer Person zu; durch die unterschriebenen Seiten sollen ausgetauschte Seiten auffallen. Eine elektronische Signatur verfolgt ebenfalls die Schutzziele Integrität und Authentizität. Eine signierte Nachricht bleibt lesbar, solange ihr Inhalt offen übertragen wird. Eine signierte E-Mail vertraulich verschicken Für eine vertrauliche E-Mail ergänze ich den Ablauf um einen weiteren Schritt. Beide beteiligten Personen brauchen dafür ein eigenes Schlüsselpaar und den öffentlichen Schlüssel der jeweils anderen Person. Beim Senden Ich berechne den Hash des E-Mail-Inhalts und signiere ihn mit meinem privaten Schlüssel. Die Signatur hänge ich an die E-Mail. Anschließend verschlüssele ich die gesamte Nachricht einschließlich Anhang mit deinem öffentlichen Schlüssel. Beim Empfangen Du entschlüsselst die Nachricht mit deinem privaten Schlüssel und erhältst den Inhalt samt Signatur. Mit meinem öffentlichen Schlüssel prüfst du die Signatur beziehungsweise erhältst im beschriebenen Modell den angehängten Hash. Du berechnest selbst den Hash des E-Mail-Inhalts u

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. TL;DR Mit Alice und Bob als Beispiel zeige ich dir, wie Kryptografie vertrauliche Nachrichten ermöglicht und welche Rolle sie in deiner IT-Ausbildung spielt. Zu den behandelten Schutzzielen gehören Vertraulichkeit, Integrität und Authentizität. Beim symmetrischen Verschlüsseln verwenden beide Seiten denselben geheimen Schlüssel, der sicher übermittelt werden muss. Das asymmetrische Verfahren arbeitet mit einem öffentlichen und einem privaten Schlüssel; dabei erfordert das Rechnen mehr Aufwand und der private Schlüssel muss geschützt bleiben. Kapitelmarken [00:00:00] Einstieg in die Kryptografie [00:00:33] IT-Sicherheit in Ausbildung und Abschlussprüfung [00:02:32] Was Kryptografie bedeutet [00:03:40] Schutzziele der Informationssicherheit [00:04:06] Vertraulichkeit am Beispiel von Alice und Bob [00:05:47] Integrität von Nachrichten [00:06:47] Authentizität der absendenden Person [00:08:31] Klartext, Chiffrat und Schlüssel [00:09:53] Symmetrisch verschlüsseln [00:12:04] Den geheimen Schlüssel sicher übermitteln [00:15:28] Schlüssellängen und Brute Force [00:17:10] Rechenleistung und Empfehlungen des BSI [00:19:24] Asymmetrische Verfahren und Schlüsselpaare [00:22:22] Schlüsselpaare mit PGP erzeugen [00:23:00] Private und öffentliche Schlüssel [00:25:09] Mit Bobs öffentlichem Schlüssel verschlüsseln [00:27:33] Rechenaufwand asymmetrischer Verfahren [00:29:52] Vertraulich in beide Richtungen kommunizieren [00:31:40] Schlüssel im privaten Alltag handhaben [00:32:44] Client-Server-Kommunikation und HTTPS [00:35:34] Rückblick auf die behandelten Grundlagen [00:38:18] Ausblick auf Integrität und Authentizität 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 Zusammenfassung Kryptografie in deiner IT-Ausbildung Seit der Überarbeitung der IT-Berufe im Jahr 2018 sind IT-Sicherheit und Datenschutz ausdrücklich im Ausbildungsrahmenplan verankert. Als IT-Azubi brauchst du diese Grundlagen auch in der Anwendungsentwicklung. Fragen zu kryptografischen Verfahren kamen bereits zuvor in Abschlussprüfungen vor. Mit Alice und Bob als Beispiel zeige ich dir, wie du Nachrichten vertraulich austauschen kannst. Kryptografie bezeichnet ursprünglich die Wissenschaft davon, Informationen zu verschlüsseln. Im hier verwendeten erweiterten Sinn gehören auch Hash-Verfahren und elektronische Signaturen dazu. Schutzziele beim Austausch von Nachrichten Wenn Alice eine E-Mail an Bob schickt, spielen folgende Schutzziele eine Rolle: Vertraulichkeit: Nur die vorgesehene Person darf den Inhalt lesen können. Alice kann ihre Nachricht dafür so verschlüsseln, dass Bob sie mit dem passenden Schlüssel wieder lesen kann. Integrität: Der Inhalt bleibt auf dem Weg zur empfangenden Person unverändert. Ändert ein:e Angreifer:in beispielsweise einen Rechnungsbetrag, ist dieses Schutzziel verletzt. Hash-Verfahren werden als Verfahren genannt, um solche Änderungen zu erkennen. Authentizität: Eine Nachricht stammt von der angegebenen absendenden Person. Dafür kommen unter anderem kryptografische Verfahren und Hash-Verfahren zum Einsatz. Die technischen Details zu Hash-Verfahren und elektronischen Signaturen bleiben für eine weitere Folge vorgesehen. Vom Klartext zum Chiffrat Ein Algorithmus verarbeitet den lesbaren Inhalt zusammen mit einem Schlüssel zu einem Chiffrat. Mit dem passenden Schlüssel lässt sich daraus der ursprüngliche Text wiederherstellen. Für deine Prüfung solltest du verstehen, wie symmetrische und asymmetrische Verfahren funktionieren und welche Schlüssel dabei erforderlich sind. Symmetrisch verschlüsseln Beim symmetrischen Verfahren verwendest du zum Verschlüsseln und Entschlüsseln denselben geheimen Schlüssel. Ein Beispiel ist ein kennwortgeschütztes ZIP-Archiv: Das beim Erstellen festgelegte Kennwort brauchst du später auch zum Entpacken. Alice könnte ihre Nachricht in eine Textdatei schreiben, diese in einem verschlüsselten ZIP-Archiv ablegen und das Archiv an Bob schicken. Sobald Bob das Kennwort kennt, kann er den Inhalt lesen. Beide können den gemeinsamen Schlüssel anschließend für Nachrichten in beide Richtungen verwenden. Das Verfahren benötigt wenig Rechenaufwand. Als Beispiel für einen technischen Schlüssel wird eine Bitfolge mit 128 Bit genannt. Den geheimen Schlüssel sicher übermitteln Damit Bob die Nachricht entschlüsseln kann, muss Alice ihm den Schlüssel über einen sicheren Weg zukommen lassen. Dafür braucht sie einen gesonderten Kanal. Aus meiner Praxis kenne ich verschlüsselte ZIP-Anhänge, deren Kennwort kurz darauf in einer zweiten E-Mail ankommt. Wer Zugriff auf das betroffene E-Mail-Konto oder den Mailserver hat, kann beide Nachrichten lesen und damit den Anhang entschlüsseln. Ein Telefonat ist ein möglicher zweiter Weg. Beim Diktieren komplexer Kennwörter können Fehler entstehen; außerdem muss die andere Person erreichbar sein. Auch Mithören oder Abhören bleibt ein Risiko. Für alltägliche private Dateien wird ein verschlüsseltes ZIP-Archiv mit einem Kennwort genannt, das beispielsweise telefonisch oder per SMS übermittelt wird. Schlüssellängen und Brute Force Technisch bestehen Schlüssel aus Bitfolgen. Bei einem Brute-Force-Angriff werden mögliche Schlüssel systematisch ausprobiert, bis einer passt. Mit 128 Bit gibt es bereits sehr viele Kombinationen, wodurch vollständiges Durchprobieren viel Rechenzeit erfordert. Die verfügbare Rechenleistung beeinflusst, welche Schlüssellängen als sicher gelten. Auch mögliche Auswirkungen von Quantencomputern werden angesprochen. Das Bundesamt für Sicherheit in der Informationstechnik, kurz BSI, veröffentlicht regelmäßig Empfehlungen zu geeigneten Schlüssellängen. Die genannten Zahlen dienen als Größenbeispiele im behandelten Kontext. Asymmetrisch verschlüsseln Ein kryptografisches Programm erzeugt ein Schlüsselpaar, dessen beide Teile mathematisch zusammenhängen. Als Beispiel wird PGP genannt, ausgeschrieben "Pretty Good Privacy". Für deine Ausbildung brauchst du das Prinzip; die Schlüssel von Hand mathematisch herzuleiten gehört laut den Ausführungen zum Ausbildungswissen,...

Ich habe ein neues Lieblingsbuch für die Ausbildung! "Java by Comparison" wird im Buchclub in der einhundertdreißigsten Episode des Anwendungsentwickler-Podcasts besprochen. TL;DR Ich nehme Java by Comparison in die Leseliste für meine IT-Azubis auf: Das Buch zeigt anhand von 70 Codebeispielen, wie du deinen Code verständlicher und weniger fehleranfällig schreibst. Die kurzen Beispiele mit ihren überarbeiteten Fassungen eignen sich bereits im ersten Ausbildungsjahr, sobald du grundlegende Programmierkenntnisse hast; viele Regeln lassen sich auch auf C# oder PHP übertragen. Dein:e Ausbilder:in kann bei Code-Reviews auf passende Kapitel verweisen, während du dir die Hintergründe selbst erarbeitest. Kapitelmarken [00:00:00] Buchclub zu Java by Comparison [00:02:09] Buchidee und Aufbau der Codebeispiele [00:05:31] Regeln auf andere Programmiersprachen übertragen [00:06:43] Zielgruppe und FizzBuzz als Einstiegstest [00:08:41] Geplanter Einsatz in Ausbildung und Code-Reviews [00:11:18] Grundlagen, Kommentare und lesbarer Code [00:12:47] Namen, Domänensprache und Fehlerbehandlung [00:13:49] Unit-Tests und Klassen entwerfen [00:14:42] Streams, Lambdas und Methodenreferenzen [00:15:08] Builds, Continuous Integration und weitere Praxisthemen [00:17:13] Fachliche Namen am Beispiel der Krankenversicherung [00:19:45] Optionals funktional mit ifPresent verarbeiten [00:23:33] Autoren und Hintergründe zum Buch [00:25:23] Links, Codebeispiele und ergänzende Beiträge 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, 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. 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 Zusammenfassung Wie du mit dem Buch lernst Nachdem ich Java by Comparison komplett gelesen habe, möchte ich es mit meinen IT-Azubis bereits im ersten Ausbildungsjahr lesen. Das englischsprachige Buch von Simon Harrer, Jörg Lenhardt und Linus Dietz ist bei den Pragmatic Programmers erschienen. Die Autoren haben Java an deutschen Hochschulen gelehrt und ihre Erfahrungen aus der Lehre eingebracht. Auf jeweils zwei gegenüberliegenden Seiten findest du ein Codebeispiel und seine überarbeitete Fassung. Dazu erfährst du, warum die Änderungen helfen und wie du sie umsetzt. Insgesamt enthält das Buch 70 Beispiele auf ungefähr 165 Seiten. Als fachlicher Rahmen dient eine Reise zum Mars, bei der unter anderem Raketen und Mars-Rover vorkommen. Mit einfachen Regeln für Bedingungen beginnt das Buch, bevor es zu anspruchsvolleren Themen wie funktionaler Programmierung übergeht. Die Beispiele sind kurz und brauchen wenig zusätzlichen Kontext. Welche Vorkenntnisse du brauchst Wenn du bereits mit Schleifen und Bedingungen programmieren kannst, hast du die Grundlagen für den Einstieg. Damit eignet sich das Buch für IT-Azubis mit ersten Erfahrungen ebenso wie für fortgeschrittene Entwickler:innen und Ausbilder:innen. Ich halte es nach ungefähr einem halben Jahr eigener Programmierpraxis für zugänglich. Als Einstiegstest schlägt das Buch FizzBuzz vor. Dabei gibst du die Zahlen von 1 bis 100 aus und ersetzt bestimmte Zahlen: Bei durch 3 teilbaren Zahlen erscheint Fizz. Bei durch 5 teilbaren Zahlen erscheint Buzz. Ist eine Zahl durch beide teilbar, erscheint FizzBuzz. Alle übrigen Zahlen gibst du unverändert aus. Kannst du diese Aufgabe selbstständig in ungefähr einer Viertelstunde lösen, bringst du die empfohlenen Vorkenntnisse mit. Obwohl alle Beispiele in Java geschrieben sind, lassen sich viele Regeln auf ähnliche Sprachen wie C# oder PHP übertragen. Spätere Kapitel behandeln Java-Konzepte wie Streams und Optionals. Vergleichbare Ansätze gibt es auch in anderen Sprachen, etwa LINQ in C#. Welche Themen das Buch behandelt Beim Lesen arbeitest du dich durch folgende Bereiche: Bedingungen und grundlegende Sprachmittel: Boolesche Werte direkt abfragen, positiv formulierte Begriffe wählen und bei if-Konstrukten konsequent Klammern setzen. Kommentare und lesbarer Code: Durch sprechende Methodennamen bleibt Code verständlich. Benannte Konstanten machen die Bedeutung von Zahlen im Code sichtbar. Namen und Domänensprache: Begriffe aus dem Fachbereich helfen dir, Variablen und Methoden nachvollziehbar zu benennen. Fehler behandeln: Ressourcen zuverlässig schließen, etwa mit Javas try-with-resources, das Dateien automatisch schließt. Unit-Tests: Tests sinnvoll aufbauen, die Argumente bei assertEquals richtig anordnen und Rundungsfehler bei Gleitkommazahlen berücksichtigen. ...

Ein interessantes Interview mit Jan Bauer, einem Experten für Umschulungen im IT-Bereich, führe ich in der einhundertneunundzwanzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Mit Jan Bauer bespreche ich, wie du über eine Umschulung zum/zur Fachinformatiker:in einen IT-Beruf erlernen kannst. In Vollzeit dauert sie meist zwei Jahre und führt zum gleichen IHK-Abschluss wie die duale Ausbildung, wobei ein Kostenträger häufig die Lehrgangskosten und deinen Lebensunterhalt übernimmt. Bei einem Bildungsträger lernst du die Theorie und erste praktische Grundlagen, bevor du im Betrieb meist sechs Monate Praxis sammelst. Für den Berufseinstieg zählen deine eigenen Programmiererfahrungen und deine Bereitschaft, weiterzulernen; das Praktikum bietet zugleich die Chance, anschließend im Betrieb zu bleiben. Kapitelmarken [00:00:00] Einstieg: Umschulungen in der IT [00:01:19] Jan Bauer und seine Arbeit als Ausbilder [00:03:48] Jans Weg vom Quereinstieg zur Umschulung [00:06:38] Programmiersprachen passend zum Projekt wählen [00:08:49] Gleicher IHK-Abschluss und damalige Prüfungsregeln [00:10:10] Betriebliche und außerbetriebliche Umschulung [00:12:24] Dauer in Vollzeit und Teilzeit [00:13:34] Betrieb und Berufsschule bei einer Umschulung [00:14:42] Ablauf beim Bildungsträger bis zur Prüfung [00:18:03] Lehrgangskosten und Kostenträger [00:19:47] Einen Praktikumsplatz finden [00:21:21] Kosten und Aufgaben des Praktikumsbetriebs [00:22:48] Geld für den Lebensunterhalt [00:24:44] Gründe für eine Umschulung und Interesse an IT [00:27:42] Kursstarts und Gruppengrößen [00:30:31] Unterricht, virtuelle Klassenzimmer und Betreuung [00:34:49] Zeit für Theorie und eigene Programmierpraxis [00:39:07] Coding-Bootcamps und Erfahrung beim Programmieren [00:42:18] Mit IHK-Aufgaben auf die Prüfung vorbereiten [00:45:07] Vorbehalte bei Betrieben und Chancen durch das Praktikum [00:48:33] Anforderungen an Praktikumsplätze und Berufseinstieg [00:51:39] Hinweise für Betriebe, die Umschüler:innen ausbilden [00:54:55] Programmiersprachen und Austausch mit dem Bildungsträger [00:59:51] Bücher, Stack Overflow und Englischkenntnisse [01:04:01] Informatiklehrbücher und ergänzende Erklärungen [01:07:29] IT-Azubis individuell begleiten [01:09:45] Jan per E-Mail erreichen [01:10:49] Kommentare und weitere Fragen Inhalt Allgemeines zur Person Wie ist dein Name und wo arbeitest du? Jan Bauer, 48 Jahre alt, Fachkraft für Aus- und Weiterbildung beim Volkswagen-Bildungsinstitut. Wir bilden Berufe aus, die VW braucht, insb. auch Fachinformatiker. Vorher war ich 9 Jahre als Dozent und Lernbegleiter tätig in der Umschulung für mehrere IT-Berufe. An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob? Ich bin Ausbilder für Fachfinformatiker Anwendungsentwicklung. Ich programmiere täglich, aber eher kleine Projekte, da die Ausbildung im Vordergrund steht. Wie bist du zur Informatik bzw. Softwareentwicklung gekommen? Ich habe klassisch mit dem C64 begonnen, dann zum Amiga gewechselt. Informatik war eher ein Hobby. Mein Studium habe ich im Bereich Ingenieurswesen absolviert, aber viel nebenbei in der IT gearbeitet. Im Internetboom hatte ich keine Probleme, als Quereinsteiger einen Job zu finden, und habe bei Lycos gearbeitet. Dort habe ich viel gelernt und gute Jahre gehabt. Aber dann ging die New Economy unter. 2006/2007 war es schwierig, ohne formale Ausbildung einen Job zu bekommen und eine "normale" Ausbildung war aufgrund meines Alters schwierig. Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert? Aus obigem Grund habe ich selbst eine Umschulung zum Fachinformatiker Anwendungsentwicklung absolviert. Aktuell studiere ich nebenbei Wirtschaftsinformatik. Mit welcher/n Programmiersprache/n arbeitest du im Alltag? C# Was ist deine Lieblingsprogrammiersprache und warum? C# ist sehr modern, aber ich mag auch PHP im privaten Bereich. Ich bin da sehr undogmatisch und finde es langweilig, darüber zu diskutieren, welche Sprache die beste ist. Alle Sprachen haben Stärken/Schwächen. Umschulung zum Fachinformatiker Warum hast du eine Umschulung absolviert? Mir hat ein formaler Abschluss gefehlt. Warum hast du dich für eine Umschulung entschieden und machst nicht eine normale Ausbildung? Mit Mitte 30 kam für mich eine normale Ausbildung nicht in Frage. Welche Arten der Umschulung gibt es? Normale Ausbildung: Betrieb + Berufsschule. Betriebliche Umschulung: Betrieb + Berufsschule, aber Einstieg ins 2. Lehrjahr, da vorher Berufsausbildung absolviert und Grundlagen bekannt sind. Außerbetriebliche Umschulung: Bildungsträger (quasi wie Berufsschule, der die Theorie vermittelt) + Praktikum im Betrieb (6 Monate waren vorgegeben). Welche Unterschiede gibt es zwischen Umschulung und Ausbildung? Umschüler haben oft keine Zwischenprüfung. Die Berufsschule wird durch den Bildungsträger ersetzt. Die Praxis im Unternehmen dauert oft nur 6 Monate. Es gibt Bildungsträger, die Zwischenprüfungen machen (rein freiwillig). Die Dauer des Praktikums ist abhängig davon, was die örtliche Kammer vorschreibt. Es gibt durchaus auch längere Praktika. Wie lange dauert eine Umschulung? Nicht pauschal zu sagen. Vollzeit dauert normalerweise 2 Jahre, aber es gibt auch Bildungsträger, die 2,5 Jahre anbieten inkl. einiger Zertifikate. Die vorhandene Förderung bestimmt die Dauer. Bildungsgutscheine sind meist nur für 2 Jahre gültig. Teilzeitumschulungen gibt es auch, z.B. 4 Stunden/Tag vor Ort, dafür aber 3 Jahre lang. Eine Umschulung dauert nicht exakt 24 Monate, sondern einige Monate weniger, da nach der Prüfung Schluss ist. Der genaue Ablauf kann sich je nach Bildungsträger unterscheiden. Bei meinem Träger: 1 Jahr waren alle Teilnehmer vor Ort für Schulungen und die Vermittlung von Praxis. Ein guter Einstieg ins Praktikum sollte möglich sein. Danach gab es ein halbes Jahr Praxis im Unternehmen und danach kamen die Umschüler zurück zur Prüfungsvorbereitung (6-8 Wochen vor der Prüfung) und zur Dokumentation der Projektarbeit. Die Zeit bis zur mündlichen Prüfung haben wir für das Üben der Präsentation usw. gebraucht. Was hat der Bildungsträger davon? Der Bildungsträger bekommt Geld dafür. Eine Umschulung zum FIAE kostet ca. 20.000-30.000 EUR. Wer bezahlt die Umschulung? Der Kostenträger (z.B. Agentur für Arbeit, Jobcenter, Rentenversicherung, Bundeswehr, Selbstzahler) bezahlt die Bildungsträger und die Umschüler. Wie findet man einen Praktikumsbetrieb? Die Umschüler sollten sich selbst bewerben. Eigeninitiative ist gefordert (und gewünscht). Kontakte der Bildungsträger zu Unternehmen sind aber auch vorhanden und helfen zur Not. Was haben die Unternehmen davon, Umschüler zu beschäftigen? Ein Umschüler ist für den Praktikumsbetrieb zunächst kostenfrei. Der Bildungsträger übernimmt die Sozialversicherung usw. Unternehmen haben aber trotzdem Kosten durch Umschüler (z.B. für den Ausbilder usw.). Der Betrieb bekommt kein Geld für die Umschüler. Ausblick auf potentielle Arbeitskraft ist hilfreich. Wovon bestreitet ein Umschüler seinen Lebensunterhalt? Der Kostenträger zahlt, z.B. Arbeitslosengeld 1 oder 2. Wer macht allgemein eine Umschulung? Menschen, die in ihrem alten Job nicht mehr arbeiten können oder wollen. Das muss aber gut begründet sein, da der Kostenträger überzeugt werden muss. Einige Umschüler werden auch durch ihre Berater in die Umschulung bzw. gewisse Berufe gedrängt. Beispiel: Intelligenter junger Mann, der aber keinerlei IT-Affinität hatte, wurde zum FIAE angemeldet, weil das ein guter Job sei. Wie viele Umschüler sitzen in einem Kurs? Das schwankt extrem, da die Politik unterschiedlich stark fördert. Üblicherweise haben wir 15-45 Leute im Jahrgang, von denen die ITler nur einen Teil bilden, ca. 3-10 Leute. Unterstützen die Dozenten die Umschüler gut? Wie sieht dein Alltag als Umschüler aus? Die meiste Zeit geht für die Vermittlung theoretischer Inhalte drauf. Die sind für alle IT-Berufe gleich, da die Rahmenlehrpläne zu großen Teilen gleich sind. Die Praxis ist schwierig zu vermitteln, gerade für FISI und FIAE. Da sind eigene Projekte nötig, um gut auszubilden. Fallstudien helfen hier weiter. Es besteht eine Art Lehrer-/Schüler-Verhältnis zwischen Dozenten und Umschülern. Es wird nicht komplett Frontalunterricht gemacht, sondern eher Fallstudien bearbeitet. Auch Bücher zu lesen kann ein Auftrag sein. Virtuelle Klassenzimmer werden teils komplett ohne Präsenzunterricht eingesetzt. Die Bedürfnisse der Teilnehmer unterscheiden sich stark, was ein großes Problem für viele Teilnehmer ist. Ein großer Kritikpunkt an Umschulungen ist oft die schlechte Betreuung. Braucht man viel eigene Motivation für die Umschulung? Das ist sehr typabhängig. Grundsätzlich ist aber gerade für FIAE viel intrinsische Motivation nötig, um vernünftig programmieren zu lernen. Was sind die Inhalte der Umschulung? Macht man in 2 Jahren den Inhalt von 3 Ausbildungsjahren? Ich habe mal ausgerechnet, dass wir ca. 2,5x so viel Zeit für die Theorievermittlung in der Umschulung haben wie es Stunden in der Berufsschule für die Ausbildung gibt. Und vieles fällt weg: Deutsch, Ethik, Sport. Die Theorienoten unserer Umschüler waren immer besser als der IHK-Schnitt. Aber die Praxis fehlte, die natürlich aber wichtig ist für den späteren Job. Meine Erwartung an angehende FIAEler ist daher, dass man auch zuhause programmieren muss. Nicht weil das Pflicht ist, sondern weil man es sonst nicht vernünftig lernt. Wie bereitet man sich auf die Abschlussprüfung vor? Übungsaufgaben habe ich auch zum Einstieg wie die IHK-Aufgaben gestellt. Die Prüfungsvorbereitung war in die Umschulung komplett integriert. Wir haben auch Aufgaben aus der Zwischenprüfung verwendet. Das Abschlussprojekt wird im Praktikum im Unternehmen umgesetzt. Nach der langen Praxisphase ist häufig viel Theoriewissen wieder weg und muss neu aufgebaut werden kurz vor der Prüfung. Wie ist deine Einschätzung zur Anerkennung der Umschulung bei Arbeitgebern? ...

Wie steigt man in das automatisierte Testen einer Java-EE-Anwendung ein, wenn man bereits eine bestehende Anwendung hat und bislang nicht getestet hat? Diese und weitere Fragen kläre ich im Interview mit Matthias Bünger in der einhundertachtundzwanzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Bei bestehenden Java-EE-Anwendungen starte ich mit schnellen Unit-Tests für die Fachlogik und ergänze schrittweise Tests für die Infrastruktur. Über Konstruktor-Injection kannst du Abhängigkeiten direkt übergeben und Klassen im Java-SE-Kontext testen. Echte Implementierungen kommen infrage, wenn sie schnell und zuverlässig laufen; Zugriffe auf externe Ressourcen ersetze ich zunächst durch Test doubles. Arquillian verwende ich für wenige umfassende Tests im Application-Server, die auch das Zusammenspiel mit der echten Datenbank prüfen. Kapitelmarken [00:00:01] Einstieg ins Testen von Java-EE-Anwendungen [00:02:34] Matthias Bünger und sein Arbeitsumfeld [00:05:09] Aufbau der Backend-Anwendung und XML-Verarbeitung [00:07:57] Vorhandene Tests und Fragen zu Arquillian und Mocking [00:10:50] Von der Fachlogik nach außen testen [00:13:39] Automatische Regressionstests und reproduzierbare Testdaten [00:15:59] Aufwand und Einsatz von Arquillian [00:18:05] Domäne isolieren und Komponenten verbinden [00:19:39] Persistenz mit lokalen und echten Datenbanken testen [00:21:11] Testpyramide und vollständige Benutzerabläufe [00:22:28] CDI und Logging im bestehenden Projekt [00:24:12] Abhängigkeiten durch Konstruktor-Injection sichtbar machen [00:27:09] Logger übergeben und bestehende Klassen testbar machen [00:29:48] Objekte und Abhängigkeiten im Test vorbereiten [00:32:10] Lesbare Tests mit sprechenden Hilfsmethoden [00:33:59] Welche Abhängigkeiten werden gemockt? [00:38:43] Schnelle Tests und Infrastrukturtests getrennt halten [00:40:16] Den Einstieg auf Fachlogik und kurze Laufzeiten ausrichten [00:42:48] Oracle oder lokale Datenbank als Testziel [00:45:01] Datenbankrechte und getrennte Testkonfigurationen [00:46:12] JPA im Java-SE-Kontext mit eigenem EntityManager [00:49:10] Datenbanktests mit Arquillian abwägen [00:51:34] Umfangreiche Mock-Setups als Anlass zum Refactoring [00:54:17] Austauschbare Abhängigkeiten früh einplanen [00:56:16] Quellen zum Testen und Unterschiede zwischen Stubs und Mocks [00:58:54] Mockito als Framework für den Einstieg [01:00:36] Clean Code und Continuous Integration [01:02:21] Maven und plattformunabhängige Builds [01:04:07] Kontakt und Fragen zur Episode [01:05:14] Praktische Ausbildung und Hürden beim Einstieg [01:07:16] Weitere Fragen und Shownotes Inhalt Allgemeines zur Person Wie ist dein Name und wo arbeitest du? Matthias Bünger, aus Bonn, beschäftigt beim ITZBund (Informationstechnikzentrum Bund, IT-Dienstleister). An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob? Qualitätssicherung, Buildmanagement, automatisches Testen. Automatisierung ist mir sehr wichtig. Ich möchte die Grundlagen für automatische Tests schaffen. Ansonsten bin ich hauptsächlich in der Backend-Anwendung tätig. Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert? Nach der Schule habe ich eine Ausbildung zum Fachinformatiker Anwendungsentwicklung absolviert. Danach habe ich noch Informatik studiert. Mit welcher/n Programmiersprache/n arbeitest du im Alltag? Java (EE) Was ist deine Lieblingsprogrammiersprache und warum? Java Automatisiertes Testen von Java-EE-Anwendungen Mein aktueller Wissensstand zum Testen ist etwas durcheinander. Ich bin verwirrt durch zahlreiche Blog-Beiträge, die unterschiedliche Meinungen propagieren. Zum Beispiel: "Mocke nur, was du unter Kontrolle hast!" oder "Mocks sind gemacht worden, um sie wieder abzuschaffen!". Ja was denn nun? Gibt es aktuell noch gar keine Tests in eurer Anwendung? Es gibt ein paar Unit-Tests ohne Mocking oder Dependency Injection. In vielen Komponenten werden Logger eingesetzt, die die Tests erschweren. Ich habe eine Schulung zu Arquillian besucht und kann theoretisch damit loslegen. Was mich abschreckt ist das Deployment bei Arquillian, das recht lange dauert. Was macht die Anwendung überhaupt? Welche Frameworks/Technologien werden eingesetzt? Backend zur Verarbeitung von XML-Dateien, die ins Dateisystem geliefert werden. Die Daten aus den XML-Dateien werden dann mit JPA in eine Datenbank geschrieben, von wo aus sie weiter verarbeitet werden. Fachlich geht es um Freistellungsaufträge von Banken. Unsere Herausforderungen sind die parallele Verarbeitung und eine hohe Last. Im Hintergrund läuft WebSphere. Die fachliche Logik ist nicht allzu komplex. Was sind deine Herausforderungen beim Testen? Wir verwenden häufig einen Logging Interceptor. Wie mockt man den? Wir setzen stark auf CDI mit @Inject an den Attributen. Wie testet man das? Ansonsten gibt es viele Data Access Objects. DB-Zustände müssen evtl. zum Testen hergestellt und danach zurückgesetzt werden. Wie findet man einen Einstieg ins Testen? Ich würde mit Unit-Tests für die Fachlichkeit beginnen. Dieser Teil der Anwendung "verdient das Geld". Die EE-Technik geht eher nicht kaputt und muss nicht zu Beginn getestet werden. Das bringt kaum Mehrwert. Ich würde nicht mit Arquillian beginnen, sondern mit "einfachen" Unit-Tests mit JUnit, ggfs. unterstützt durch Mocks mit Mockito. Was mockst du? Ich habe verschiedene Meinung gelesen: Nur mocken, was man vollständig versteht. Niemals Fremdimplementierungen mocken. Keine Legacy-Anwendungen mocken. Das sehe ich anders: Ich mocke alles, was mir im Weg steht und insb. die Infrastruktur berührt (Netzwerk, Datenbank, Dateisystem). Wenn die Mocks zu aufwändig werden, ist das ein Zeichen dafür, dass die zu testende Klasse verkleinert werden muss. Würdest du auch die Datenbank mocken? Erstmal ja, um die Tests zu beschleunigen. Aber danach würde ich gegen eine lokale oder In-Memory-DB testen und am Schluss auch gegen eine "echte" Datenbank, z.B. eine Entwicklungsdatenbank. Die jeweilige Zieldatenbank (z.B. Oracle) ist halt nicht H2. Die Systeme verhalten sich unterschiedlich. Und wichtig ist, dass die Software später auf dem echten Zielsystem lauffähig ist. Ich würde die echten DB-Tests aber nicht mit EE im Application Server laufen lassen, sondern komplett ohne Arquillian mit einem JPA-Provider wie EclipseLink oder Hibernate im SE-Kontext. Das ist schneller als ein komplettes Deployment. Welche DB-Benutzer verwendest du zum Testen? Technische User mit erweiterten Rechten zum Anlegen von Schemas, z.B. bei DB-Migrations nötig. Ich setze auf zwei verschiedene Persistence-Units für main und test, damit der Produktivcode keine Ahnung von der zweiten DB haben muss. Welche Ressourcen kannst du zum Thema empfehlen? "Test automation without a headache: Five key patterns" von Gojko Adzic auf der "Norwegian Developers Conference 2016" in London Martin Fowler - Mocks Aren't Stubs: Hier werden die Begriffe Stub, Mock, Spike usw. erklärt und abgegrenzt, da sie häufig falsch benutzt werden. Hast du eine allgemeine Buchempfehlung? Clean Code* finde ich sehr wichtig, auch wenn ich nicht alle Inhalte teile. Ich habe daraufhin CheckStyle usw. eingeführt und achte mehr auf Code-Qualität und Wartbarkeit. Alles rund um Continuous Integration! Automatisierung ist viel wert! Einmal aufsetzen, für immer die Vorteile genießen. Für mich wichtig ist die erreichte Plattformunabhängigkeit, keine Dependencies, die ich im Classpath manuell setzen muss etc. Bei uns kann mit Git und Maven jeder direkt in neue Projekte einsteigen. Außerdem findet der CI-Prozess auch Fehler in den Projekten. Abschluss Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren? Ich bin nicht online vertreten. Facebook halte ich privat. Höchstens bei StackOverflow oder bei einer Bewerbung auf unsere Stellenausschreibungen! ;-) Literaturempfehlungen * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Test automation without a headache: Five key patterns von Gojko Adzic auf der "Norwegian Developers Conference 2016" in London Mocks Aren't Stubs von Martin Fowler 100% Code Coverage - TDD mit Java EE von Stefan Macke auf der JavaLand 2018 Zusammenfassung Ausgangspunkt: Eine bestehende Java-EE-Anwendung testen Im Gespräch mit Matthias Bünger gebe ich dir Einblicke aus meinen Projekten. Matthias arbeitet beim ITZ Bund an einer Backend-Anwendung, die XML-Dateien mit Meldungen zu Freistellungsaufträgen einliest und über JPA in einer relationalen Datenbank verarbeitet. Durch hohe Last und parallele Abläufe entstehen besondere Herausforderungen. Die vorhandenen Unit-Tests prüfen vor allem Hilfsfunktionen für Strings; die fachlichen Regeln sollen zusätzlich automatisch getestet werden. Mit automatischen Tests kannst du nach Änderungen auch bereits vorhandene Funktionen erneut prüfen. Das hilft etwa bei einem Hotfix. Für reproduzierbare Ergebnisse brauchst du definierte Testdaten und einen Ausgangszustand, den du vor jedem Test wiederherstellst. Mit der Fachlogik beginnen Für den Einstieg arbeite ich mich von der fachlichen Domäne nach außen vor. Eine Berechnung lässt sich mit einem selbst erzeugten Java-Objekt testen, dessen Eigenschaften du passend zum Testfall setzt. Die Domäne sollte möglichst frei von technischen Abhängigkeiten sein, damit solche Tests direkt im Java-SE-Kontext laufen. Anschließend verbinde ich Komponenten miteinander und prüfe ihre Zusammenarbeit. Sobald eine Komponente auf Infrastruktur zugreift, ersetze ich diese Abhängigkeit zunächst durch ein Test double. Ein Repository kann beispielsweise vorgegebene Datensätze liefern. Bei einer neuen Anforderung habe ich auch schon mit einem umfassenden Integrationstest begonnen, wie es im Buch Growing Object-Oriented Software, Guided by Tests beschrieben wird. Dieser Test bleibt zunächst rot, während kleinere Unit-Tests die einzelnen Schritte begleiten. Sobald der große Test erfolgreich durchläuft,...

Weißt du schon, was du nach deiner Ausbildung zum Fachinformatiker machst? Eine tolle Alternative zum Studium bespreche ich mit Simon Stork in der einhundertsiebenundzwanzigsten Episode des Anwendungsentwickler-Podcasts: die IHK-Weiterbildung zum Operative Professional. TL;DR Mit Simon Stork schaue ich auf den Operative Professional, eine IHK-Weiterbildung für deinen beruflichen Weg nach der Ausbildung zum/zur Fachinformatiker:in. Du lernst Methoden für die Projektleitung und bereitest dich darauf vor, Mitarbeiter:innen zu führen und Aufgaben im mittleren Management zu übernehmen. Simon hat berufsbegleitend zwei Jahre gebraucht und damals rund 5.900 Euro einschließlich Prüfungsgebühren bezahlt, wobei er über Meister-BAföG einen Teil erlassen bekam. Seine Erfahrungen zeigen, wie der Abschluss bei Bewerbungen helfen und zu einem höheren Gehalt beitragen kann. Kapitelmarken [00:00:01] Operative Professional und berufliche Wege nach der Ausbildung [00:01:54] Simon Stork und seine Arbeit im CAD- und PLM-Bereich [00:04:24] Von der IT-Ausbildung zur berufsbegleitenden Weiterbildung [00:09:09] Der Operative Professional und seine vier Ausrichtungen [00:11:30] Lerninhalte für Projektleitung und mittleres Management [00:15:20] Erwartungen und persönliche Ziele vor der Weiterbildung [00:17:16] Blended Learning und Workshops vor Ort [00:20:11] Projektmethoden im beruflichen Alltag [00:22:58] Schriftliche Prüfung mit Situationsaufgaben [00:26:32] Projektdokumentation und Niveau des Abschlusses [00:28:34] Dauer und Abgabetermine [00:30:08] Das passende Projekt und Vorgaben der IHK [00:31:50] Kosten und Finanzierung über Meister-BAföG [00:34:10] Bildungsträger auswählen und Zusatzkosten einplanen [00:36:21] Gehalt und beruflicher Aufstieg [00:38:04] Erfahrungen mit Bewerbungen und Arbeitgebern [00:41:17] Weiterbildung zum Strategic Professional [00:43:08] Simons Gründe für den Operative Professional [00:48:23] Persönlicher und finanzieller Ertrag [00:50:25] Verkürzter Bachelor nach dem Operative Professional [00:51:37] Erprobter Zugang zum Masterstudium [00:53:13] Anerkennung im öffentlichen Dienst [00:54:09] OP-Blog und Kontakt zu Simon [00:55:33] Hinweise für deinen weiteren Berufsweg Inhalt Allgemeines zur Person Wie ist dein Name und wo arbeitest du (falls gewünscht)? Simon Stork, im Consulting tätig, eher Projektleitung und IT, kein Programmierer. 35 Jahre alt, verheiratet, komme aus Paderborn. An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob? CAD/PLM, Consulting, Einführung von Systemen, Change Management, Requirements Engineering, ca. 50/50 technisch/Projektleitung. Wie bist du zur Informatik bzw. Softwareentwicklung gekommen? Ich bin ein Kind der 80er Jahre, war technikinteressiert und bin mit dem C64 über Spiele in den Umgang mit Computern eingestiegen. Mit 13 hatte ich meinen ersten PC. Dann kam das Internet und mein Einstieg in HTML/PHP. Programmieren war mir zu monoton und ich wollte lieber FISI werden und mit Netzwerken arbeiten. Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert? 2001 habe ich die Ausbildung zum FISI angefangen, dann kurz Lehramt studiert, aber doch wieder zum gewechselt. Operative Professional (OP) Wie bist du selbst zu der Weiterbildung gekommen? Welche Alternativen hast du dafür ausgeschlagen? "Nur" eine Ausbildung reichte mir nicht. Zertifikate (z.B. MCSA) sind aber zeitlich begrenzt und sehr teuer. Ich suchte eine Weiterbildung ohne Verfallsdatum. Ein Studium war die Alternative. Ich habe den OP im Netz gefunden. Ich war schon Projektleiter und der OP passte inhaltlich sehr gut dazu. Was ist der Operative Professional? Der OP ist eine Art "Meister" für ITler. Offiziell: "Aufstiegsweiterbildung" im Anschluss an die Ausbildung. Welche Ausrichtungen des OP gibt es? Entwickler, Ökonom, Berater, Projektleiter Projektleiter ist mit ca. 80% die verbreitetste Form. Inhalte der Richtungen gleichen sich zu 90%. Aber die Projektarbeit am Ende unterscheidet sich vom Fokus und es gibt leicht andere Aufgaben in der Prüfung. Welche Ausrichtung hast du für dich selbst gewählt und warum? Projektleiter, weil das genau zu meinem Aufgabengebiet passte. Welche Inhalte werden beim OP vermittelt? Der OP hat eigentlich nichts mit Technik zu tun. Es geht um die Vorbereitung auf eine Karriere im mittleren Management. Themen: Personalmanagement, Projektanbahnung, Requirements Engineering, Konfliktmanagement, Projektblockaden auflösen, Methoden, Controlling, Pflichtenheft. Wir haben z.B. Rollenspiele gemacht, um praktische Erfahrungen im Team zu sammeln. War dir die fehlende Technik bewusst? Was sagen andere Teilnehmer dazu? Ja, ich habe mich sogar bewusst dafür entschieden. Ca. 80% der Teilnehmer wussten ebenfalls bescheid, aber auch der Rest war letztlich mit den Inhalten zufrieden. In welcher Form hast du die Weiterbildung absolviert (z.B. via Präsenzveranstaltungen oder komplett online)? Würdest du evtl. auch ein komplettes Selbststudium empfehlen? Ich habe ein "Blended Learning" absolviert, also Vorbereitung Online und Präsenzphasen vor Ort. Mit einem Tutor hatten wir alle 6-8 Wochen 2 Tage Vollzeit Veranstaltungen vor Ort. Dort haben wir Aufgaben gelöst, präsentiert (!) und Gruppenarbeiten durchgeführt. Ein Selbststudium ist nicht zu empfehlen, da die Bildungsträger besser wissen, was die IHK hören will, und die Fragestellungen kennen. Sind die vermittelten Inhalte von Wert und für die Praxis relevant? Wie hoch war der Anteil an Lehrstoff, den du direkt in der Praxis anwenden konntest? Wichtig ist das Wording: Begriffe (FMEA, RAKI) und Methoden sollte jeder Projektleiter kennen. Sie sind enorm wichtig für eine gute Kommunikation. Es wurden auch typische Projektmethoden nach PMBOK oder ISO gelernt. Auch Zertifikate wie PRINCE/ITIL/AdA sind möglich. Wie sieht die Prüfung aus? Es gibt eine Präsentation, Klausuren und eine Projektdokumentation. Es wird keine reine Begriffsabfrage durchgeführt, sondern konkrete Fragestellungen zu Beispielprojekten werden bearbeitet. Es wird eher Modellierung/Dokumentation mit EPKs usw. gefordert, die z.B. die Wahl des korrekten Abstraktionslevels erfordern. Es wird Bezug zum konkreten Projekt mit Bewertung und Planung der Projektphasen hergestellt. Es geht um die praktische Anwendung und den Transfer des gelernten Wissens. Meine Projektdokumentation war ca. 65 Seiten lang. Das Projekt sollte min. 1/2 Jahr, max. 1 Jahr dauern. Das Projekt sollte "echt" sein und nicht hypothetisch. Wie lange hat deine Fortbildung zum OP gedauert? Normalerweise dauert der OP 1,5 Jahre. Man hat 1 Jahr Zeit für die Projektdoku. Was kostet der OP? Eigentlich fallen nur die Prüfungskosten an, wenn man alles im Selbststudium macht. Mit Bildungsträger liegt man bei ca. 5.900 EUR (rein Bildungsträger und Prüfung, keine Fahrt-/Hotelkosten). Eine Finanzierung ist über (Meister-)Bafög möglich. Bei erstmaligem Bestehen der Prüfung werden 50% der Kosten erlassen. Firmen bezahlen auch häufig die Weiterbildung. Ein Aufstieg im Job ist ja meist das Ziel, also sollte sich der OP amortisieren. Ich selbst hatte eine deutliche Gehaltssteigerung durch den OP. Allerdings ist der konkrete Anteil des OP daran schwer einzuschätzen, da ich mich auch persönlich weiterentwickelt habe. Welchen Bildungsträger würdest du empfehlen? Das muss jeder selbst entscheiden. Ich habe meinen (manQ) gewählt, weil er nah an meinem Wohnort lag. Aber viele Teilnehmer kamen auch von weiter weg. Reine Online-Seminare gibt es auch, da Blended Learning nicht für alle Teilnehmer klappt. Offiziell ist der OP gleichwertig zu einem Bachelor. Wie schätzt du die tatsächliche Anerkennung in der Arbeitswelt ein? Ich habe einen sehr positiven Eindruck. Ich habe inzwischen mehrere Jobwechsel vollzogen und der OP war bekannt und anerkannt. Mein erster Jobwechsel fand während des OPs statt und mit einem Nachweis vom Bildungsträger über den zeitlichen Umfang in Stunden in der Bewerbung konnte ich einen guten Eindruck machen. Im Vorstellungsgespräch wurde der OP dann auch direkt angesprochen und hinterließ einen positiven Eindruck beim Arbeitgeber. Wird der OP tendenziell von Kollegen anerkannt oder wird man eher geliebäugelt? Ich selbst habe zwei Kollegen, die auch den OP gemacht haben. Viele wissen vom OP, aber denken eher an ein Studium. Der OP ist an den Umfang des Bachelors angelehnt, aber eben nicht das gleiche, da er kein akademischer, sondern ein IHK-Abschluss ist. Es gibt auch noch die "Strategic Professionals", sprich z.B. den "Geprüften Wirtschaftsinformatiker". Macht das "Upgrade" dazu Sinn? Die Strategic Professionals sind vergleichbar mit einem Master. Aber sie werden meines Wissens nach nicht so stark nachgefragt. Die genauen Inhalte sind mir auch nicht bekannt, da es sehr wenige Informationen online gibt. Das Ziel ist aber wohl die Vorbereitung auf eine Laufbahn im höheren Management. Technik wird wieder nicht vertieft. Wovon würdest du die Entscheidung zwischen OP und Studium abhängig machen? Wann wäre ein Studium sinnvoller? Ich war zum Start des OP schon in der Arbeitswelt und ich wollte nicht mehrere Jahre berufsbegleitend studieren. Der zeitliche Aufwand ist immer interessant. Ein Bachelor läuft 4-5 Jahre berufsbegleitend, was ich sehr lang finde. Im Bachelor lernt man auch erneut viele Grundlagen, die fertige Fachinformatiker nicht unbedingt weiterbringen. Der Bachelor ist auf dem Papier schön und zeigt die Fähigkeit zur akademischen Arbeit. Außerdem lernt man Grundlagen wie Mathe/BWL usw. Die eigene Motivation ist wichtig, auch langfristig! Je länger es dauert, umso wahrscheinlicher bricht man ab. Auch bei 1,5 Jahren hat man mal Hänger! Wie schätzt du die weitere Entwicklung rund um den OP ein? Ich glaube, dass viele Firmen aktuell umdenken. Bachelor/Master sind nicht mehr so wichtig wie früher. Die Fachlichkeit ist eher gefragt. Das mag auch am Fachkräftemangel liegen. ...

Über verschiedene Möglichkeiten zur Verbesserung unserer Programmierfähigkeiten spreche ich mit Dennis Dierkes in der einhundertsechsundzwanzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Ich zeige dir gemeinsam mit Dennis Dierkes, wie du als IT-Azubi deine Programmierfähigkeiten durch Coding Dojos, Fachbücher und kleine eigene Projekte weiterentwickelst und über Meetups Kontakte knüpfst. Dabei gehören Zeit zum Lernen im Betrieb und konkretes Feedback durch dein:e Ausbilder:in ebenso dazu wie deine eigene Neugier, die dich auch nach der Ausbildung begleitet. Kapitelmarken [00:00:01] Einführung in Continuous Improvement [00:01:36] Dennis Dierkes und sein Weg in die Softwareentwicklung [00:02:49] Spring, Kotlin und aktuelle Projekte [00:05:26] Warum du nach der Ausbildung weiterlernst [00:06:35] Eigeninitiative und Zeit zum Lernen im Betrieb [00:08:09] Tech Fridays und gemeinsame Lernformate [00:10:58] Lebenslang lernen und neugierig bleiben [00:12:05] Kotlin mit Übungen und Pair Programming lernen [00:13:14] Coding Katas und Coding Dojos [00:14:09] Eigene Lernprojekte überschaubar halten [00:15:18] Fachbücher lesen und bestehenden Code prüfen [00:17:19] Dojos und Bücher miteinander verbinden [00:18:19] Lösungen vergleichen und Design Patterns ausprobieren [00:19:41] Wie ein Open Space abläuft [00:22:02] Meetups und die Java User Group [00:23:56] Programmieren mit den Bielefelder Software Kids [00:28:08] Anschluss bei Veranstaltungen finden [00:29:21] Treffen suchen oder selbst organisieren [00:30:58] Auf Workshops und Meetups vorbereiten [00:32:06] Notizen, Beispielcode und Sketchnotes [00:33:17] Fachbücher und Buchclubs in der IT-Ausbildung [00:36:12] Growing Object-Oriented Software, Guided by Tests [00:37:49] Pair Programming und konkrete Code Reviews [00:39:30] Dennis online erreichen [00:40:50] Weitere Anregungen und Links zur Episode Inhalt Allgemeines zur Person Wie ist dein Name und wo arbeitest du? Dennis Dierkes, 21 Jahre alt, Prüfung zum Fachinformatiker Anwendungsentwicklung vor 2 Wochen bestanden. An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob? Java-lastige Sachen wie Spring, Kotlin und funktionale Programmierung mit Vavr, aber auch SOAP, Bootstrap, AWS, Vue.js. Wie bist du zur Informatik bzw. Softwareentwicklung gekommen? Klassisch über Computerspiele. Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert? Ausbildung FIAE, vorher Realschule. Mit welcher/n Programmiersprache/n arbeitest du im Alltag? Java, Kotlin Was ist deine Lieblingsprogrammiersprache und warum? Kotlin bietet enorm viele coole Möglichkeiten für Entwickler. Continuous Improvement Warum sollte ich meine Fähigkeiten als Softwareentwickler ständig ausbauen? Ich kann höhere Qualität abliefern, schneller entwickeln und Probleme lösen, langfristig Zeit sparen. Liegt Weiterbildung in meiner eigenen Verantwortung oder in der meines Arbeitgebers? Es sollte Eigeninitiative vorhanden sein, die dann optimalerweise Unterstützung durch das Unternehmen bekommt. Ich persönlich habe auch nach einem vollen Arbeitstag noch Lust, nach Feierabend weiter zu programmieren und zu lernen. Die Motivation steigt, wenn der Arbeitgeber unterstützt. Wir machen z.B. Coding Dojos gemeinsam mit den Kollegen. Ist man irgendwann auch mal "fertig" mit der Weiterbildung? Hoffentlich nicht! Ich würde gerne lebenslang lernen! Ich finde es nicht gut, wenn Kollegen, die kurz vor der Rente stehen, nicht mehr mitmachen. Womit verbesserst du deine (Programmier-)Fähigkeiten? Kotlin habe ich über ein Tutorial bei GitHub gelernt. Pair Programming hilft sehr beim Wissenstransfer. In Side Projects kann man ohne Druck lernen und sich ausprobieren. Aktuell habe ich ein Side Project für die Arbeit erstellt mit Vue.js. Das Side Project sollte nicht zu groß werden, damit es weiter Spaß macht. Was ist ein Coding Dojo/Barcamp/Code Retreat und was macht man da konkret? Coding Katas sind kleine Übungsaufgaben für Programmierer. Coding Dojos sind Treffen in einer Gruppe, um die Katas gemeinsam zu bearbeiten. Ich persönlich mag das "Hands On" im Coding Dojo und nehme dann noch ein Buch zur Vertiefung. Sehr spannend war z.B. das Bearbeiten der Katas von mehreren Programmierpaaren und der anschließende Vergleich der Lösungen. Dabei haben wir dann z.B. Design Pattern angewendet und ihre Vor- und Nachteile besprochen. Welche Ressourcen verwendest du zur persönlichen Weiterbildung? Bücher. Mit neuem Wissen auf alten Code schauen. Retrospektiven durchführen. Kannst du konkrete Bücher/Kurse/Veranstaltungen empfehlen? Clean Code*, Growing Object-Oriented Software, Guided by Tests* Was ist ein Open Space? Eine "Unkonferenz" mit mehreren Räumen. Es gibt eine Tafel für die Themenwahl. Jeder darf eine Session mitbringen oder sich eine wünschen. Man kann jederzeit Vorträge verlassen ("Gesetz der zwei Füße"). Welche Veranstaltungen (für Entwickler) hast du bislang besucht? Verschiedene Treffen über Meetup.com im Raum Bielefeld, Java User Group (JUG), CloudLab, Socramob. Ich organisiere auch selbst eine Veranstaltung, um Kinder und Jugendliche an die Programmierung heranzuführen, z.B. mit Little Bits oder dem Calliope. Wir haben auch schonmal einen Minecraft-Bot programmiert. Wo findest du die Kinder/Jugendlichen, die mitmachen? Es gab eine Info an die Teilnehmer des Open Spaces, die ihre Kinder angesprochen haben. Außerdem schreibe ich Schulen an. Was mache ich, wenn ich eher schüchtern/zurückhaltend bin? Das sind doch alle! Einfach hingehen und mitmachen. Die Teilnehmer sind alle ganz offen. Zur Not einen Kollegen mitnehmen, mit dem man quatschen kann. Wie findet man Veranstaltungen für Entwickler? Meetup.com, Softwerkskammer. Was mache ich, wenn in meiner Region keine Veranstaltungen stattfinden? Selbst eine organisieren oder halt weiter fahren. Die Softwerkskammer hilft vielleicht. Wie bereitest du dich auf Veranstaltungen vor? Meistens gar nicht so viel. Ich gehe einfach hin. Manchmal wird aber empfohlen, etwas mitzubringen (z.B. Repo von GitHub klonen, IDE installieren). Es ist aber immer gut, einen Laptop mitzunehmen. Wie nimmst du das Optimum aus den Veranstaltungen mit (z.B. Notizen, Ziele setzen)? Ich nutze eine Notizen-App. Nebenbei probiere ich meist live das Gezeigte aus. Im Nachhinein lade ich den Beispielcode herunter und mache selbst weiter. Aktuell probiere ich Sketchnotes aus. Aus- und Weiterbildung Bildest du selbst Entwickler-Nachwuchs aus und wenn ja, wie ist das Vorgehen? Zum 01.08. bekommen wir unseren ersten Azubi zum Fachinformatiker Anwendungsentwicklung. Hast du Tipps für Ausbilder/-innen im IT-Bereich? Nehmt euch ausreichend Zeit für eure Azubis! Macht z.B. Pair Programming mit ihnen. Wichtig sind auch intensive Code Reviews, bei denen alles angemerkt werden soll, was euch auffällt. Schaut euch detailliert den Code an und nickt nicht einfach alles ab. Nur durch Feedback lernt man. Abschluss Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren? Bei Twitter (@deenerin0), Xing, GitHub oder Instagram. Ansonsten einfach zu einem Meetup im Raum Bielefeld kommen! :-) Literaturempfehlungen Robert C. Martin - Clean Code: A Handbook of Agile Software Craftsmanship* * Growing Object-Oriented Software, Guided by Tests* * Java By Comparison: Become a Java Craftsman in 70 Examples (Affiliate)*. Den erwähnten Podcast zum Buch gibt es hier: InnoQ-Podcast: Java by Comparison. * Die Sketchnote Starthilfe: Über 200 Strich-für-Strich-Anleitungen und Schriften zum Nachzeichnen* * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Meetup.com Cloud Lab Bielefeld Java User Group Bielefeld (Bielefeld, Deutschland) | Meetup Softwerkskammer Münster/Osnabrück/Bielefeld Oldenburger Münsterland Bielefelder Software Kids littleBits (Lernprojekt für den Arduino) CALLIOPE mini* (Microcontroller zum Lernen) JetBrains Kotlin Workshop Material Zusammenfassung Deine Programmierfähigkeiten weiterentwickeln Dennis Dierkes hat seine Ausbildung zum/zur Fachinformatiker:in für Anwendungsentwicklung gerade abgeschlossen und arbeitet inzwischen in einem kleinen Unternehmen. Dort entwickelt er Webanwendungen mit Spring und beschäftigt sich für kommende Projekte mit Kotlin und Vue.js. Im Gespräch mit ihm greife ich auf, wie du auch nach deinem Abschluss weiterlernst. Wenn du neue Technologien kennenlernst und deine Fähigkeiten ausbaust, kannst du hochwertigere Software schreiben. Was du lernst, hilft dir auch, wenn du bestehenden Code später erweiterst oder überarbeitest. Für mögliche Arbeitgeber:innen wirst du durch zusätzliche Kenntnisse interessanter. Dennis möchte seine Neugier über das gesamte Berufsleben behalten. Wie viel Zeit du dafür aufbringen kannst, hängt auch von deinen Lebensumständen ab. Zeit zum Lernen im Betrieb Dennis lernt während der Arbeitszeit und beschäftigt sich aus eigenem Interesse auch abends mit Softwareentwicklung. Sein Unternehmen stellt Zeit bereit, um neue Themen kennenzulernen. Persönliche Initiative und die Unterstützung durch den Betrieb gehören dabei zusammen. Für Technologien, die du bei der Arbeit brauchst, sollte dein:e Arbeitgeber:in Zeit zum Lernen einräumen. Ob du dich zusätzlich in deiner Freizeit damit beschäftigst, entscheidest du selbst. In Dennis’ Unternehmen wurde ein früherer Tech Friday verändert, nachdem einigen Kolleg:innen Ideen oder Interesse fehlten. Freitags finden inzwischen gemeinsame Coding Dojos und Vorträge aus dem Team statt, etwa zu Vue.js. Auch für neue Themen außerhalb eines konkreten Projekts gibt es Zeit. Die Teilnahme ist freiwillig. Bei mir im Unternehmen arbeiten sich Kolleg:innen während der Arbeitszeit in Technologien ein, die ein Projekt erfordert. Bei Bedarf sind auch Kurse möglich. Ein festes Format für frei gewählte Lernthemen gibt es zum Zeitpunkt des Gesprächs noch nicht. Mit Coding Katas und Pair Programming üben ...

Die noch fehlenden Teile der IHK-Sommerprüfung 2018 - Projektdokumentationen und Fachgespräche - bespreche ich in der einhundertfünfundzwanzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Bei der IHK-Sommerprüfung 2018 habe ich häufig Projektarbeiten gelesen, deren methodisches Vorgehen kaum erkennbar war. Für deine Projektdoku brauchst du klar erfasste Anforderungen und einen begründeten Entwicklungsprozess, während passende Diagramme dein Projekt verständlich machen. Im Fachgespräch musst du die eingesetzten Technologien erklären können und fachliche Grundlagen beherrschen; dazu gehören auch Datenschutz und kaufmännische Themen wie die Kostenrechnung. Kapitelmarken [00:00:01] Hinweise zum Fachgespräch [00:00:37] Rückblick auf die IHK-Sommerprüfung 2018 [00:01:37] Unterschiedliche Projektthemen und Technologien [00:02:31] Methodisches Vorgehen in der Projektarbeit [00:05:17] Quelltext lesbar in die Doku einfügen [00:07:07] Agile Entwicklungsprozesse beschreiben und begründen [00:09:19] Amortisation aus der passenden Perspektive berechnen [00:10:53] Projektumfeld und interne Begriffe erklären [00:13:01] Anforderungen erfassen und priorisieren [00:14:36] Architektur und Oberflächen visuell darstellen [00:16:38] Stundensatz und Kosten des eigenen Projekts [00:18:44] Projektdoku gegenlesen lassen [00:19:35] Den Betrieb knapp und projektbezogen vorstellen [00:21:41] Grundlagen im Fachgespräch [00:23:36] Datenschutz und IT-Sicherheit [00:24:59] Lambda-Ausdrücke und funktionale Programmierung [00:25:54] AJAX und asynchrone Aufrufe [00:27:54] REST und vertiefende Schnittstellenfragen [00:29:08] Vertraute Technologien für das Prüfungsprojekt wählen [00:30:00] Betriebsabrechnungsbogen und Kostenrechnung [00:31:08] Funktionale Anforderungen und Softwarequalität [00:32:18] TypeScript und Typisierung [00:33:14] Frameworks und Annotationen verstehen [00:33:52] Entwurfsmuster erklären [00:35:50] Domain-Driven Design im Fachgespräch [00:37:50] Rückblick auf wiederkehrende Prüfungsfehler [00:38:52] Shownotes und Kommentare [00:39:14] Newsletter und kostenlose Checklisten Inhalt Projektdokumentationen Fehlende Methodik bleibt das Hauptproblem vieler Projektarbeiten. Code auf schwarzem Hintergrund in der Dokumentation geht gar nicht. "Agil" ist das neue "wir wissen nicht, was wir tun". Bei der Amortisationsrechnung werden häufig fälschlicherweise interne Kosten mit externen Zeiteinsparungen verglichen. Interne Begriffe werden als allgemein bekannt vorausgesetzt und nicht erklärt. Für mehrere Projekte wurden die Anforderungen nicht sauber aufgenommen. Stattdessen wurde wohl einfach drauflos programmiert. Gerade bei komplexen Architekturen oder Oberflächen sagt ein Bild weiterhin mehr als tausend Worte! Es gibt immer noch Prüflinge, die ihr Bruttogehalt als alleinige Basis für ihren Stundensatz nehmen. Einige Dokumentationen wurden offensichtlich in keinster Weise korrigiert oder auch nur gelesen. Unternehmensvorstellung auf einer ganzen Seite mit ganzseitiger Grafik der Standorte im Anhang. Fachgespräch Es hakt oft an den Basics! Klasse/Objekt, Kardinalitäten, Lasten-/Pflichtenheft. Datenschutz war das dominierende Thema (dank DSGVO). Grundlagen der funktionalen Programmierung sind bei den meisten Prüflingen immer noch nicht vorhanden. Mal abgesehen von Lambda-Ausdrücken. AJAX wird fast überall benutzt, aber die Abkürzung kennt kaum jemand. Asynchrone Programmierung wird eingesetzt, ohne sie erklären zu können. Häufig wird synchron mit parallel durcheinandergebracht. REST bleibt weiterhin eine zentrale Komponente vieler Projekte, aber kann ebenfalls nur selten korrekt erklärt werden. Viele Prüflinge setzen Technologien für ihr Projekt zum ersten Mal ein. Tiefergehende Fragen können daher meist nicht beantwortet werden. Der Betriebsabrechnungsbogen ist vielen Prüflingen nicht bekannt. Funktionale und nicht-funktionale Anforderungen waren oft nicht bekannt. Typescript scheint sich für die Frontend-Entwicklung zu etablieren. Aber dann sollte man auch erklären können, warum man es einsetzt. Viele Frameworks -> viele Annotationen -> viel Magie -> viele unerklärliche Abläufe. Wer viele Pattern einsetzt, sollte sie auch erklären können. Und auch die Grundidee von Pattern an sich. Domain Driven Design ist toll. Wenn man es erklären kann. Literaturempfehlungen Da ich erneut so ziemlich alle erdenklichen Themen angerissen habe, kann ich mal wieder nur das IT-Handbuch für Fachinformatiker* von Sascha Kersken empfehlen. *(direkt beim Rheinwerk-Verlag bestellen*) Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Berechnung des eigenen Stundensatzes in der Projektdokumentation Zusammensetzung des Stundensatzes - Häufige Fragen im Fachgespräch Zusammenfassung Erfahrungen aus der IHK-Sommerprüfung 2018 Bei über 20 Prüflingen habe ich 2018 sehr unterschiedliche Projekte gesehen, die auf das jeweilige Unternehmen zugeschnitten waren. Die Bandbreite reichte von Java und C# bis zu TypeScript oder Visual Basic. Häufig gingen Punkte verloren, weil aus der Projektdoku kaum hervorging, wie die Software planvoll entwickelt wurde. Auch im Fachgespräch zeigten sich wiederkehrende Lücken. Dein Vorgehen in der Projektdoku zeigen Eine der Arbeiten enthielt 25 Seiten Quelltext im Anhang, während Belege für das methodische Vorgehen fehlten. Deine Doku muss nachvollziehbar machen, wie du dein Projekt geplant hast und wie du beim Entwickeln vorgegangen bist. Halte fest, welche Ressourcen du brauchst und wie du deine Arbeit zeitlich planst. Erfasse die Anforderungen, bevor du die Software entwirfst. Zeige mit passenden Modellen, wie du Abläufe oder Datenstrukturen durchdacht hast. Dafür kommen beispielsweise Aktivitätsdiagramme oder ein ER-Modell infrage. Beschreibe deinen Entwicklungsprozess und begründe, warum er zu deinem Projekt passt. Fehlen zusätzlich die Doku für Benutzer:innen und die Doku für Entwickler:innen, wirkt sich das auf die Note aus. Anforderungen aufschreiben und priorisieren In mehreren Arbeiten waren die Anforderungen auf wenige Sätze beschränkt. Schreibe auf, was deine Anwendung leisten soll und welche Qualitätsanforderungen gelten. Du kannst dafür ein Lastenheft und ein Pflichtenheft erstellen oder mit User Stories arbeiten. Prioritäten lassen sich etwa über Muss-, Soll- und Kann-Kriterien festlegen. Anhand dieser Vereinbarungen kann dein:e Auftraggeber:in später prüfen, ob du das Projekt erfolgreich umgesetzt hast. Ein Pflichtenheft kann zum Vertragsbestandteil werden und damit helfen, Streit über den vereinbarten Umfang zu vermeiden. Den Entwicklungsprozess konkret beschreiben Wenn du agil arbeitest, musst du den gewählten Prozess mit seinen Regeln beschreiben. Scrum und Feature Driven Development sind konkrete Vorgehensweisen. Bei Extreme Programming gehören beispielsweise Test Driven Development und Pair Programming zu den Praktiken. Für die damals vorgesehenen 70 Projektstunden solltest du prüfen, wie sich dein Prozess im verfügbaren Zeitrahmen durchführen lässt. Bereits nach einer Iteration kann das Projekt weitgehend vorbei sein. Auch beim Wasserfallmodell muss erkennbar sein, wie du die Phasen in deinem Projekt durchläufst. Dein Projekt verständlich darstellen Das Umfeld knapp erklären Beschreibe dein Unternehmen in wenigen Sätzen und erläutere anschließend das Umfeld, das für dein Projekt relevant ist. Interne Softwarebezeichnungen und Abkürzungen brauchen eine Erklärung, damit ich als Prüfer:in nachvollziehen kann, woran du arbeitest. Halte außerdem fest, welche Aufgaben dein Unternehmen übernimmt und welche bei deinen Kund:innen liegen. Unklare Rollen erschweren es, den Zweck des Projekts und seine Wirtschaftlichkeit zu bewerten. Wie ausführlich du deinen Betrieb vorstellst, richtet sich danach, welche Informationen zum Verständnis des Projekts erforderlich sind. Architektur und Oberflächen zeichnen Wenn mehrere Systeme zusammenarbeiten, zeigt eine Architekturskizze, wo welche Software läuft und wohin Daten übertragen werden. Dafür eignet sich ein UML-Komponentendiagramm; auch eine einfache Zeichnung mit Pfeilen kann die Zusammenhänge sichtbar machen. Für eine geplante Oberfläche bietet sich ein Mock-up an. Eine eingescannte Handskizze kann bereits zeigen, wie ein Dialog aufgebaut ist. Solche Darstellungen gehören auch in deine Präsentation, wenn sie dein Projekt verständlich machen. Quelltext lesbar setzen Setze Code als Text auf weißem Hintergrund in einer Monospace-Schrift, beispielsweise Courier New. Dabei haben alle Zeichen dieselbe Breite. Farben zum Hervorheben der Syntax sind möglich. Screenshots mit schwarzem Hintergrund verbrauchen beim Drucken viel Toner und erschweren es mir, Anmerkungen am Code zu machen. Die Doku gegenlesen lassen In einigen Arbeiten fand ich zahlreiche Sprachfehler und abgebrochene Sätze. Lass eine andere Person prüfen, ob deine Sätze verständlich und grammatisch korrekt sind. Sie kann auch auf Rechtschreibung und Satzzeichen achten, ohne dein Projekt fachlich beurteilen zu müssen. Schwer lesbare Inhalte erschweren die Bewertung und beeinflussen die Note. Kosten für dein konkretes Projekt berechnen Frage im Rechnungswesen deines Unternehmens nach einem passenden Stundensatz. Darin müssen neben deiner Ausbildungsvergütung auch Lohnnebenkosten und Gemeinkosten berücksichtigt werden. Die Beispielrechnungen in meinen Vorlagen sind unvollständig und müssen an dein Projekt angepasst werden. Wenn du ein Teilprojekt umsetzt, berechne dessen Kosten und Wirtschaftlichkeit. Die Zahlen des Gesamtprojekts liefern dafür keine ausreichende Grundlage. Bei der Amortisationsrechnung muss die Perspektive durchgehend zusammenpassen: Für ein internes Projekt berechnest du, wann die internen Einsparungen die internen Projektkosten ausgleichen. Bei einem verkauften Produkt rechnest du aus Sicht deines Unternehmens mit den Verkaufserlösen. Je nach Geschäftsmodell kann dafür eine bestimmte Zahl verkaufter Lizenzen erforderlich sein. ...

Wie bereits im letzten Jahr gibt es auch für die IHK-Sommerprüfung 2018 einen Rundumschlag über all meine Erfahrungen in der einhundertvierundzwanzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Bei der IHK-Sommerprüfung 2018 in Oldenburg habe ich wiederkehrende Fehler gesehen, aus denen du für deine eigene Prüfung lernen kannst. Prüfe dein Projektthema mit deinem/deiner Ausbilder:in auf sinnvolle Alternativen und bereite ausgewählte Codeausschnitte lesbar für die Dokumentation auf. Für die schriftliche Prüfung brauchst du sichere SQL-Grundlagen und Übung in WiSo. Deine Projektpräsentation sollte deine eigene Arbeit mit verständlichen Grafiken zeigen, innerhalb von 15 Minuten bleiben und technisch vorbereitet sein; im Fachgespräch zählt, dass du Zusammenhänge anhand von Beispielen erklären kannst. Kapitelmarken [00:00:01] Einstieg und Hinweise zur IHK-Prüfung [00:00:38] Rückblick auf die Sommerprüfung 2018 in Oldenburg [00:02:26] Wiederkehrende Probleme und Prüfungsergebnisse [00:04:19] Referenzielle Integrität im Fachgespräch [00:05:20] Projektthema prüfen und Alternativen besprechen [00:07:47] Live-Demo vorbereiten und Zeit einhalten [00:10:12] Quellcode lesbar und druckfreundlich aufbereiten [00:13:03] Aussagekräftige Codeausschnitte für den Anhang auswählen [00:14:27] LaTeX-Folien und visuelle Gestaltung [00:16:09] Beispiel für 100 Prozent in Präsentation und Fachgespräch [00:18:21] SQL-Syntax und Platzhalter im Prüfungsbeiblatt [00:22:30] WiSo vorbereiten und Fragestellungen genau lesen [00:24:36] Corporate Design und Platz für Folieninhalte [00:26:03] Hintergrundprogramme und Benachrichtigungen ausschalten [00:27:40] Eigene Projektarbeit und technische Grundlagen [00:30:16] Standardisierte Diagramme fachgerecht einsetzen [00:31:52] Diagramme und Punktlisten schrittweise einblenden [00:34:06] Folienwechsel und umfangreiche Präsentationsnotizen [00:36:55] Ausblick auf Projektdokumentation und Fachgespräch [00:37:40] Shownotes und Kommentare [00:38:17] Newsletter erneut abonnieren und Checklisten herunterladen Inhalt Meine Highlights Frage nach referentieller Integrität, Gegenfrage: "Gehört das zu Datenbanken?" Projektarbeit, die mit wenigen Zeilen Code erledigt gewesen wäre. Fremdschämen bei hakeliger Live-Demo mit Tippfehlern, verschobenen Fenstern usw. 25 Seiten Quelltext als einziger Anhang. Präsentation auf Basis von LaTeX. Leider fast nur Text ohne Bilder. Eine 100% im Fachgespräch über Lambdas, Generics, Polymorphie, Java 8, Dependency Injection, Typisierung, das Diamond-Problem usw. Schriftliche Prüfung SQL sollte jeder Prüfling kennen. Ist aber leider nicht so. Stattdessen wird die Syntax vom Beiblatt ohne Hinterfragen falsch übernommen. WiSo hat mal wieder vielen guten Kandidaten die Note versaut. Projektpräsentationen Corporate Designs verschlingen teilweise 50% der Folien und überdecken (!) Inhalte. Unerwarteter Sound während der Präsentation verunsichert Prüfling. Trivialitäten und allgemein bekannte Technologien (z.B. Request/Response bei REST) werden lang und breit erklärt. Statt UML wurden teils selbst ausgedachte Diagrammformen verwendet. Komplexe Diagramme und Punktlisten werden als Ganzes dargestellt, anstatt sie schrittweise einzublenden. Folien werden ohne sichtbaren Unterschied "weitergeklickt" (vermutlich für die Notizen). Literaturempfehlungen Da ich erneut so ziemlich alle erdenklichen Themen angerissen habe, kann ich mal wieder nur das IT-Handbuch für Fachinformatiker* von Sascha Kersken empfehlen. *(direkt beim Rheinwerk-Verlag bestellen*) Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Rückblick auf die Sommerprüfung 2017 Themenfindung für das Abschlussprojekt Live-Demo in der Projektpräsentation Sourcecode gehört nicht in die Präsentation - Mythen der Projektpräsentation Verwendung eines Laserpointers bei der Abschlusspräsentation Zusammenfassung Erfahrungen aus der Sommerprüfung 2018 In Oldenburg habe ich 2018 an drei Tagen mehr als 20 Prüfungsteilnehmer:innen geprüft und zusätzlich die schriftliche Prüfung korrigiert. Viele Probleme bei den Projektdokumentationen und im Fachgespräch waren mir bereits aus dem Vorjahr bekannt. Die Ergebnisse lagen überwiegend im Bereich einer schwächeren Zwei oder einer guten Drei; bei den mündlichen Prüfungen gab es zwei Einsen sowie einige Vieren. Dein Projektthema fachlich prüfen Bei einem Projekt zur Datenbankoptimierung blieb offen, ob wenige Zeilen Programmcode die Aufgabe ebenfalls hätten lösen können. Der/die Prüfungsteilnehmer:in konnte die Fragen dazu nur teilweise beantworten. Besprich dein Thema vorab mit deinem/deiner Ausbilder:in oder einem/einer erfahrenen Kolleg:in. Dabei solltest du klären, welchen Zweck das Projekt erfüllt und welche anderen Lösungswege infrage kommen. Gehe mögliche kritische Fragen durch, indem du das Projekt aus Sicht eines/einer Prüfer:in hinterfragst. So bereitest du dich darauf vor, deine Entscheidungen fachlich zu begründen. Quellcode in der Projektdokumentation Zum Korrigieren drucke ich Projektdokumentationen aus und schreibe Anmerkungen auf das Papier. In einer Dokumentation bestand der Anhang aus 25 Seiten Code, der als Screenshot auf schwarzem Hintergrund eingefügt war. Das verbraucht viel Toner und erschwert handschriftliche Anmerkungen. Screenshots können außerdem beim Skalieren verzerren oder unterschiedlich große Schrift zeigen. Bereite deine Codeausschnitte als lesbaren Text auf hellem Hintergrund auf. Der schwarze Hintergrund allein blieb bei mir ohne Notenabzug. Wähle selbst aus, welche Ausschnitte deine Arbeit fachlich zeigen. Als Faustregel empfehle ich drei bis vier Seiten interessanten Code. Ergänzend kommen beispielsweise ein Unit-Test oder ein Build-Skript infrage. Mit einem ER-Modell und passenden UML-Diagrammen kannst du zeigen, wie du methodisch gearbeitet hast. SQL für die schriftliche Prüfung üben In mehreren Lösungen zu einer CREATE TABLE-Aufgabe standen die Datentypen in spitzen Klammern. Im Beiblatt kennzeichneten diese Klammern Platzhalter. Beim Übertragen in ausführbaren SQL-Code müssen die Platzhalter durch konkrete Angaben ersetzt werden, wobei die Klammern entfallen. Für die fehlerhafte Syntax gab es Punktabzug. Übe die grundlegenden SQL-Befehle so, dass du sie selbst schreiben und Angaben aus einem Beiblatt richtig übertragen kannst. In den Prüfungen der vergangenen Jahre kamen SQL-Aufgaben regelmäßig vor. Dazu gehörten Abfragen mit SELECT, Änderungen mit UPDATE und auch das Anlegen von Tabellen mit CREATE TABLE. WiSo gezielt vorbereiten Bei einigen Prüfungsteilnehmer:innen verschlechterte WiSo das schriftliche Gesamtergebnis. Eine Person hatte beispielsweise in GA1 und GA2 jeweils eine Eins, kam durch eine schwache Drei in WiSo insgesamt aber auf eine Zwei. Arbeite frühere Prüfungen durch, etwa aus den letzten fünf Jahren. Wiederkehrende Inhalte lassen sich teilweise auswendig lernen. Auch bei Multiple-Choice-Aufgaben solltest du die Fragestellung genau lesen. WiSo prüft berufsübergreifende Inhalte und beeinflusst deine Note als Fachinformatiker:in. Deine Projektpräsentation vorbereiten Live-Demo und Technik Eine Live-Demo macht dein Ergebnis sichtbar. In einem Prüfungsbeispiel führten Tippfehler und Probleme mit Fenstern auf dem Beamer dazu, dass die Demo stockte. Anschließend überschritt der/die Prüfungsteilnehmer:in die vorgesehenen 15 Minuten, was ebenfalls Punkte kostete. Übe den Ablauf intensiv und starte die benötigten Programme schon vor der Präsentation. Als Alternative empfehle ich dir ein aufgezeichnetes Video, dessen Dauer du vorab festlegen und zu dem du während der Präsentation sprechen kannst. Schließe alle Programme, die du während der Präsentation entbehren kannst, und schalte Benachrichtigungen sowie unnötige Töne aus. Bei einer Prüfung unterbrach ein Hintergrundprogramm mit seiner Soundausgabe den Vortrag. Der/die Prüfungsteilnehmer:in verlor dadurch Zeit und wirkte anschließend verunsichert. Folien verständlich gestalten Auch mit LaTeX erstellte Folien brauchen eine passende visuelle Gestaltung. Eine Präsentation mit fast ausschließlich Textpunkten und wenigen kleinen Bildern erhielt Punktabzug. Zeige deine Inhalte mit aussagekräftigen Grafiken, beispielsweise einem UML-Diagramm. Ein umfangreiches Corporate Design kann viel Platz beanspruchen. In einem Beispiel belegte es ungefähr die Hälfte der Folie und verdeckte sogar Teile der Grafiken. Ich empfehle dir, solche Gestaltungselemente wegzulassen, damit deine Inhalte ausreichend Platz haben. Deine eigene Arbeit zeigen Mehrere Prüfungsteilnehmer:innen verbrachten viel Zeit damit, grundlegende Technologien wie REST zu erklären. Teilweise gingen dafür fünf Minuten der Präsentation drauf. Zeige, wie du die Technologie in deinem Projekt eingesetzt hast und welche Arbeit du dabei selbst geleistet hast. Bei den Prüfer:innen kannst du Grundlagenwissen zu HTTP oder AJAX voraussetzen. Eine kurze Erklärung zu einer speziellen Komponente ist sinnvoll, wenn sie hilft, dein Projekt nachzuvollziehen. Dazu gab es ein passendes Beispiel mit React und Redux, bei dem eine frameworkspezifische Besonderheit auf einer Folie knapp erläutert wurde. Etablierte Diagramme verwenden Wähle eine standardisierte Darstellung, die zu deinem Inhalt passt. Für Abläufe kommen beispielsweise UML-Aktivitätsdiagramme oder ereignisgesteuerte Prozessketten infrage. Datenstrukturen kannst du mit einem ER-Modell zeigen. Auch Programmablaufpläne und Nassi-Shneiderman-Diagramme wurden als Möglichkeiten genannt. Achte auf korrekte Syntax. Damit zeigst du, dass du die etablierten Methoden kennst und fachgerecht einsetzen kannst. Komplexe Inhalte schrittweise zeigen Wenn ein großes Diagramm vollständig erscheint, beschäftigen sich die Prüfer:innen zunächst damit, es zu verstehen. Bei einer komplett eingeblendeten Punktliste lesen sie häufig schon voraus, während du noch den ersten Punkt erläuterst. Blende die Bestandteile passend zu deinem Vortrag schrittweise ein....

Mein drittes Wissenshäppchen hat das Single Responsibility Principle zum Thema. TL;DR Das Single-Responsibility-Principle (SRP) ist das erste SOLID-Prinzip: Eine Klasse soll genau eine Aufgabe und damit einen Grund haben, geändert zu werden. Ich übertrage diesen Gedanken auch auf Methoden und andere Komponenten, damit du ihren Code leichter verstehen und getrennt testen kannst. Dabei brauchst du einen passenden Ausgleich zwischen hoher Kohäsion und geringer Kopplung, weil viele kleine Komponenten zusätzliche Abhängigkeiten erzeugen und das Gesamtsystem schwerer überschaubar machen können. Kapitelmarken [00:00:26] SRP als erstes SOLID-Prinzip [00:01:37] Kohäsion: Zusammenhang von Methoden und Attributen [00:02:45] Fehler durch mehrere Aufgaben in einer Klasse [00:03:37] SRP für Variablen und Methoden [00:04:33] Datenbankzugriff und E-Mail-Versand getrennt testen [00:06:30] SRP auf Architekturebene und bei Microservices [00:08:01] Mehrere Aufgaben an Namen erkennen [00:08:48] Allgemeine Klassennamen und Repository-Methoden [00:10:31] Architekturschichten und Wiederverwendung [00:11:59] Legacy-Software und automatisierte Tests [00:13:42] Die Gott-Klasse als Anti-Pattern [00:15:00] Verständlicher Code und isolierte Tests [00:17:35] Überblick über viele kleine Komponenten behalten [00:20:06] Zusätzliche Abhängigkeiten durch kleine Klassen [00:22:11] Hohe Kohäsion und geringe Kopplung abwägen [00:23:12] Fachbegriffe: Cohesion und Coupling [00:23:50] Kleine Komponenten früh voneinander trennen [00:25:42] Weiterführende Links und Feedback Inhalt Das SRP ist das erste der sogenannten SOLID-Prinzipien. Robert "Uncle Bob" Martin definiert es so: There should never be more than one reason for a class to change. Jede Klasse sollte genau einen einzigen Grund haben, um geändert zu werden. Man kann das Prinzip aber auch auf anderen Ebenen (z.B. Variablen, Methoden oder ganze Komponenten) berücksichtigen. Erklärung Nur Dinge, die zusammengehören, werden auch zusammen abgebildet. Jedes Ding (Variable, Methode, Klasse, Komponente) darf nur eine Aufgabe haben. Die Kohäsion der Dinge sollte hoch sein. Verletzung ist erkennbar an Wörtern wie und oder oder. Unklare Namen wie z.B. Manager oder Verwaltung sind auch häufig ein Anzeichen für die Verletzung des Prinzips. Wenn viele Abhängigkeiten und Dinge, die nichts miteinander zu tun haben, in einer Klasse zusammengefasst werden, kann beim Anpassen einer (Teil-)Implementierung eventuell eine damit gar nicht in Zusammenhang stehende Implementierung negativ beeinträchtigt werden. Praxisbeispiel: Klasse, die Daten aus der Datenbank liest und diese direkt in der Oberfläche anzeigt. Klasse hat nicht nur eine Aufgabe, sondern drei verschiedene: Geschäftslogik, Datenzugriff, Anzeige. Ein Test der Logik ohne Datenbank und/oder Oberfläche ist nun unmöglich. Die Wiederverwendbarkeit der Klasse leidet auch, da die Logik nun nicht mehr ohne Datenbank und/oder Oberfläche aufgerufen werden kann. Das ist oft ein großes Problem in Legacy-Anwendungen. Ein krasses Gegenbeispiel/Antipattern zum SRP wäre eine Gott-Klasse, die alles Mögliche macht. Vorteile Die Klassen, Methoden und Variablen sind insgesamt kürzer und besser verständlich. Entwickler können Anpassungen durchführen, ohne dabei Fehler an anderer Stelle einzubauen. Komponenten sind einfacher testbar. Das Test-Setup ist kleiner, weil unnötige Abhängigkeiten nicht bereitgestellt werden müssen. Probleme bei der Testbarkeit und Verständlichkeit entstehen häufig, wenn zu viel auf einmal passiert. Zu wenig ist meistens kein Problem. Nachteile Durch viele kleine Methoden und Klassen leidet evtl. die Übersicht über das Gesamtsystem und man findet sich schwieriger zurecht. Dem kann man aber entgegenwirken und es ist erstmal nicht schlimm, viele kleine Klassen anzulegen, anstatt eine große. Dateien kosten nichts. Dateien/Klassen können in IDEs mit Shortcuts schnell gefunden/geöffnet werden. Wenn auf eine vernünftige (einheitliche) Benennung geachtet wird, sind Klassen auch so gut auffindbar. Weitere Konventionen (z.B. die Einordnung in Package-Strukturen) helfen auch bei der Organisation. Wenn Klassen nur eine einzige Aufgabe haben dürfen, steigt automatisch die nötige Kopplung zu anderen Klassen, weil deren Funktionalität benötigt wird, um die Gesamtaufgabe zu erfüllen. Hier gilt es, einen guten Mittelweg zu finden, der eine möglichst hohe Kohäsion bei gleichzeitg geringer Kopplung ermöglicht. Literaturempfehlungen Wie zu fast jedem Wissenshäppchen kann ich jeder/m Anwendungsentwickler/in nur wärmstens Clean Code* von Uncle Bob ans Herz legen. Das SRP wird hier auch erklärt und gleich praktisch angewendet. * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts SRP: The Single Responsibility Principle ArticleS.UncleBob.PrinciplesOfOod Single-Responsibility-Prinzip Zusammenfassung Eine Aufgabe pro Komponente Robert C. Martin, auch als Uncle Bob und Autor von Clean Code bekannt, beschreibt das Single-Responsibility-Principle (SRP) über den Grund, eine Klasse zu ändern: Für jede Klasse soll es genau einen solchen Grund geben. Wenn du ihre Aufgabe anpasst, änderst du den dazugehörigen Code. Ich übertrage dieses erste SOLID-Prinzip auch auf Variablen und Methoden sowie auf ganze Programme. Jede dieser Einheiten soll eine klar abgegrenzte Aufgabe erfüllen. Wie gut gehört der Code zusammen? Wenn du prüfst, welche Attribute die Methoden einer Klasse verwenden, bekommst du Hinweise darauf, wie eng ihre Bestandteile zusammengehören. Der Fachbegriff dafür ist Kohäsion, auf Englisch Cohesion. Über Softwaremetriken lässt sich dieser Zusammenhang messen. Greifen verschiedene Methoden jeweils auf völlig getrennte Attribute zu, lohnt sich ein genauerer Blick auf die Aufgaben der Klasse. Darin können mehrere Verantwortlichkeiten stecken. Wenn ich in einer solchen Klasse ein Attribut ändere, kann das eine weitere Funktion beeinflussen, die ebenfalls darauf zugreift. Solche Fehler erschweren es dir, den Code zu pflegen und ihre Ursache nachzuvollziehen. Beispiel: Daten speichern und eine E-Mail verschicken Bei einer Registrierung gehören das Speichern eines neuen Kontos und das Verschicken einer Bestätigungs-E-Mail zum selben fachlichen Ablauf. Technisch sind es eigenständige Aufgaben. Ich verteile sie auf getrennte Methoden. Die Methode für den Datenbankzugriff kann Ergebnisse liefern, die anschließend als Parameter an die Methode für den E-Mail-Versand gehen. Eine übergeordnete Komponente verbindet die Schritte. Dadurch kannst du den Datenbankzugriff separat testen. Enthält eine Methode beide Aufgaben, hängt ihr Test zusätzlich vom E-Mail-Versand ab. Ein fehlender Mailserver kann dann einen Test scheitern lassen, der das Speichern prüfen soll. Auch eine boolesche Variable kann mehrere Aussagen bündeln, etwa "Person ist über 18 und bekommt einen Nachlass". Später lassen sich die einzelnen Prüfergebnisse daraus schwer wieder gewinnen. Wenn du die Bedingungen an dieser Stelle immer gemeinsam brauchst, kann ein gemeinsamer Wert sinnvoll sein. Hinweise auf mehrere Verantwortlichkeiten Beim Lesen von Namen und Tests kannst du nach folgenden Anzeichen suchen: "Und" oder "oder" im Namen: Eine Methode wie "Speichere Konto und verschicke Bestätigungs-E-Mail" beschreibt mehrere Aufgaben. Allgemeine Klassennamen: Begriffe wie "Manager" oder "Verwaltung" können darauf hinweisen, dass die eigentliche fachliche Aufgabe noch unklar ist. Hier fehlt häufig eine passende Abstraktion, etwa eine getrennte Klasse zum Lesen oder Schreiben von Objekten. Aufwendige Tests: Wenn du für eine kleine Funktion viele Abhängigkeiten bereitstellen musst, solltest du die Verantwortlichkeiten der Klasse prüfen. Besonders verschachtelte Mocks und Stubs können ein Hinweis sein. Bei einem Repository sollten die CRUD-Aktionen mindestens eigene Methoden bekommen. Eine einzige Methode, die über einen Aktionsparameter und einen großen Switch entscheidet, was sie tun soll, übernimmt mehrere Aufgaben. Bei einer strengen Auslegung des SRP lassen sich Lesen und Schreiben auch auf eigene Klassen verteilen. Architektur und Wiederverwendung Wenn Geschäftslogik fest mit einer Weboberfläche verbunden ist, erschwert das ihren Einsatz in einer Konsolenanwendung. Eine fest eingebaute Datenbankabhängigkeit bindet sie außerdem an diese Datenquelle. Aus meinem Alltag mit Legacy-Software kenne ich Komponenten, die innerhalb einer Datenbankschleife Geschäftslogik ausführen und Ergebnisse direkt auf einer Oberfläche anzeigen. Um die Logik zu testen, brauchst du dann die Datenbank samt passenden Daten. Wartet die Oberfläche auf Eingaben, muss zusätzlich eine Person eingreifen, was automatisierte Tests behindert. Die Gott-Klasse ist ein Anti-Pattern, bei dem nahezu das gesamte Programm in einer Klasse steckt. Ein Fehler kann große Teile des Programms beeinträchtigen. Einzelne Funktionen lassen sich wegen der vielen verbundenen Aufgaben schwer isoliert prüfen. Auf Architekturebene lässt sich derselbe Gedanke bei Microservices wiederfinden: Ein Service bildet eine abgegrenzte Fachlichkeit ab. Änderungen innerhalb dieses Bereichs bleiben dadurch zunächst auf die betreffende Komponente begrenzt. Gemeinsam zugängliche Datenfelder können dagegen dazu führen, dass weitere Komponenten Werte verändern, die fachlich zu einem anderen Bereich gehören. Was kleine Komponenten erleichtern Wenn eine Komponente eine klar umrissene Aufgabe erfüllt, enthält sie meist weniger Code. Du kannst sie schneller verstehen und die passende Stelle für eine Änderung leichter finden. Getrennte Verantwortlichkeiten erleichtern außerdem, vorhandenen Code erneut einzusetzen. Für mich spielt besonders das isolierte Testen eine Rolle. Externe Abhängigkeiten lassen sich dabei durch Mocks oder Stubs ersetzen. Je kleiner der Bereich ist, den du prüfst, desto weniger musst du für den Test vorbereiten. Überblick und Abhängigkeiten Durch viele kleine Klassen kann es schwieriger werden,...

Elena Hollen hat ihre Bachelorarbeit über Code Reviews und Extreme Programming geschrieben und erzählt mir alles darüber in der einhundertdreiundzwanzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Mit Code Reviews findest du Fehler früh und lernst durch den Austausch über fremden Code. Gemeinsam mit Elena Hollen habe ich bei der Alte Oldenburger erprobt, wie sich Reviews im Arbeitsalltag einführen lassen: In drei Wochen entstanden bei 26 Reviews rund 350 Anmerkungen und 18 gefundene Fehler in 30.000 Codezeilen. Als IT-Azubi kannst du dabei auch erfahrenen Entwickler:innen Feedback geben und andere Lösungswege kennenlernen. Für den Einstieg reichen Kommentare im Code und eine Versionsverwaltung, wobei du Zeit für die Reviews einplanen und respektvoll über den Code sprechen solltest. Kapitelmarken [00:00:00] Einstieg ins Thema Code Reviews [00:01:03] Elena Hollen und ihre Arbeit mit technischen Dokumenten [00:04:02] Weg in die IT und bevorzugte Programmiersprache [00:06:24] Bachelorarbeit zu Softwarequalität und Extreme Programming [00:07:34] Werte und Praktiken von Extreme Programming [00:09:16] Feedback und Kommunikation durch Code Reviews [00:10:49] Was ein Code Review ist und welche Formen es gibt [00:12:06] Qualität und Wartbarkeit durch Reviews verbessern [00:13:33] Offline-Reviews in der ersten Testphase [00:15:42] Checklisten und gemeinsame Programmierregeln [00:17:03] Statische Codeanalyse und Best Practices im Wiki [00:19:09] Fragebogen zum Auswerten der Reviews [00:20:53] Ergebnisse aus 26 Reviews [00:22:25] Austausch über Codequalität im Team [00:23:48] IT-Azubis reviewen erfahrene Entwickler:innen [00:25:06] Respektvoll über Code sprechen [00:26:45] Aufwand und mögliche Schwierigkeiten [00:28:03] Reviews einführen und in den Arbeitsablauf einbauen [00:29:54] Fachlichen Kontext geben und Code während der Entwicklung prüfen [00:30:48] Reviews mit Pair Programming und TDD verbinden [00:31:32] Fachliche Fehler im Code erkennen [00:32:09] Anforderungen an Review-Werkzeuge [00:34:37] Erfahrungen mit Agile Review [00:35:42] Gemeinsame Snippets und einheitliche Review-Kommentare [00:37:51] Reviews mit Code-Kommentaren und Versionsverwaltung [00:38:48] Freiwillige Reviews im weiteren Arbeitsalltag [00:42:06] Wirtschaftliche Gründe und Unterstützung durch Führungskräfte [00:45:06] Bücher zu Extreme Programming und Soft Skills [00:47:30] Fachbücher und weitere Quellen zum Lernen [00:50:33] Regelmäßige Code Reviews in meiner Ausbildung [00:51:14] Rückblick und Kontaktmöglichkeiten Inhalt Allgemeines zur Person Wie ist dein Name und wo arbeitest du? Elena Hollen, Technische Redakteurin bei der ALTE OLDENBURGER Krankenversicherung AG An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob? Technische Redaktion, Toolauswahl für Code Reviews, viel schreiben, Compliance-Anforderungen, DSGVO, Dokumentation für den Fachbereich Wie bist du zur Informatik bzw. Softwareentwicklung gekommen? Nach der Realschule bin ich auf ein Fachgymnasium Wirtschaft gewechselt und habe dort im Abitur bereits etwas über Informatik gelernt, z.B. PHP, HTML, CSS, SQL, Excel. Der Bereich BWL hat mir aber auch viel Spaß gemacht. Ich bin kein "klassischer" Nerd! :-) Aber ich mag es sehr, Probleme zu lösen. Meine persönliche Entscheidung war dann aber nach der Ausbildung, dass ich nicht 24/7 programmieren möchte. Daher habe ich die Stelle als technische Redakteurin angenommen. Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert? Ausbildung zur Fachinformatikerin Anwendungsentwicklung, dann duales Studium der Wirtschaftsinformatik in Lingen, aktuell Master in Wirtschaftsinformatik an der Ostfalia. Was ist deine Lieblingsprogrammiersprache und warum? Java, da in Ausbildung und Studium gelernt und auch aktuell im Einsatz. Code Reviews und Extreme Programming Worum geht es in deiner Bacherlorarbeit (z.B. Thema, Zielsetzung)? Code Reviews zur Steigerung der Codequalität. Ich habe eine Studie zu Code Reviews bei der ALTE OLDENBURGER durchgeführt. Ziel war die Verbesserung der Kommunikation und Feedback. Was ist Extreme Programming und wer braucht das? Extreme Programming wurde von Kent Beck entwickelt. Es legt den Fokus auf den Menschen. Die Werte sind u.a. Feedback und Kommunikation, die Prinzipien z.B. Menschlichkeit und Praktiken sind z.B. TDD und Code Reviews. Was sind Code Reviews? Eine manuelle Prüfung von Code ohne Automatisierung. Der Code, der von einem Autor erstellt wird, wird von einem Reviewer kontrolliert. Was sind die Ziele von Code Reviews? Fehler finden, Selbstkontrolle, Einheitlichkeit des Codes, langfristige Wartbarkeit. Welche Varianten von Code Reviews gibt es? Walkthrough, Review mit Checkliste, Inspektion mit detaillierten Phasen. Was wurde bei der AO gemacht? Einfache Reviews ohne Checkliste. Es gab einen Leitfaden mit Fragen, z.B. Anzahl Lines of Code gereviewt, Fehler/Anmerkungen gefunden, technischer Mehrwert und was habe ich gelernt? Die Auswertung war auch eine gute Begründung für den Chef. Es gab eine Testphase mit 17 Entwicklern, die 1x pro Woche ein Review durchgeführt haben. Insgesamt wurden 26 Reviews durchgeführt. Was sind die Vor- und Nachteile von Code Reviews? Vorteile: Einfacher Start ohne großen Aufwand möglich. Eine Checkliste sollte gemeinsam erarbeitet werden. Best Practices ergeben sich im Prozess. Nachteile: Gefühl von Kontrolle. Es entstehen Kosten (Arbeitszeit), der Chef sollte also gefragt werden. Was sind die Ergebnisse deiner praktischen Studie zu Code Reviews in der AO? 30.000 LOC gereviewt, 18 Fehler gefunden, 350 Anmerkungen geschrieben, Wissenssilos aufgebrochen, viel gelernt (jeder Teilnehmer), Anregung über Qualität nachzudenken, Austausch mit anderen Entwicklern, keine Probleme aufgetreten, zwischenmenschlich hat es super geklappt. Welche praktischen Tipps für die Einführung von Code Reviews hast du? Zu Beginn muss oft eine ablehnende Haltung der Entwickler überwunden werden. Ein Kümmerer als Ansprechpartner ist nötig. Eine Integration in den Entwicklungsprozess ist nötig. Das Feedback der Teilnehmer muss berücksichtigt werden. Zu Beginn sollte erstmal eine Einführung in den zu reviewenden Code gegeben werden, damit der Reviewer weiß, worum es geht. Perfekter Code ist nicht nötig! Fachliche Fehler können gefunden werden. Macht Pair Programming Code Reviews überflüssig? Nein, sie bilden eine Symbiose, auch TDD passt gut dazu. Können auch Azubis schon Code Reviews durchführen? Ja! Ein Austausch mit langjährigen Entwicklern war möglich. Andere Meinungen werden diskutiert. Es wurden viele Fragen gestellt. Und sogar Anmerkungen von Azubis wurden umgesetzt. Welche Tools benötigt man für Code Reviews? Erstmal sind keine Tools nötig, Kommentare im Code reichen. Tool ist evtl. Overkill im Prozess. Es gibt aber viele Tools am Markt. Zunächst sind die eigenen Anforderungen zu klären und dann ein Tool zu suchen (z.B. IDE-Plugin, Git, keine DB, Gruppenverwaltung). Fehler vs. Anmerkungen sollten unterschieden werden können. Wie geht es mit den Code Reviews bei der AO weiter? Jeder Entwickler entscheidet selbst, ob und wie oft Code Reviews durchgeführt werden. Tool suchen. Es gibt keine Kontrolle, die war nur für die Bachelorarbeit nötig. Langfristige Motivation ist nötig, ein Kümmerer ist sinnvoll. Code Reviews werden bereits in die Ausbildung integriert. Kann man die Einführung von Code Reviews auch monetär begründen? Na klar! Wann sind Fehler am teuersten? Wenn der Code schon auf der Produktion läuft! Wir haben in 3 Wochen 18 Fehler gefunden, und zwar vor derm Deployment! Das Management muss von Anfang an einbezogen werden. Aus- und Weiterbildung Was ist das letzte Fachbuch mit Bezug zur Programmierung, das du selbst gelesen hast? Soft Skills von John Sonmez. Was ist dein absolutes Lieblingsbuch mit Bezug zur IT/Programmierung und warum? Extreme Programming Explained von Kent Beck (bitte auf Englisch!). Welche Quellen kannst du für die Aus- und Weiterbildung im Bereich Programmierung empfehlen und warum? Wissenschaftliches Arbeiten macht Spaß und man lernt sehr viel dabei. Quellen sind u.a. Springerlink und Google Scholar. Auf GitHub findet man viel Code, an dem man selbst lernen kann. Abschluss Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren? Auf Xing, LinkedIn oder Twitter. Literaturempfehlungen * * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Snipmatch AgileReview Zusammenfassung Wie Elena zum Thema kam Bei der Alte Oldenburger hat Elena Hollen ihre Ausbildung zur Fachinformatiker:in für Anwendungsentwicklung bei mir abgeschlossen und anschließend Wirtschaftsinformatik studiert. Nach ihrem Bachelor begann sie ein berufsbegleitendes Masterstudium. Beruflich schreibt sie technische Dokumente und kümmert sich darum, wie diese geordnet und gepflegt werden. Dabei arbeitet sie mit Fachabteilungen und IT-Kolleg:innen zusammen, etwa wenn Abläufe beschrieben oder rechtliche Vorgaben berücksichtigt werden müssen. Über den Informatikunterricht am Wirtschaftsgymnasium fand sie zur Anwendungsentwicklung. Java blieb ihre bevorzugte Programmiersprache, auch nachdem sie sich beruflich stärker mit Dokumenten beschäftigte. Der Bezug zu Extreme Programming Für ihre Bachelorarbeit untersuchte Elena, wie Praktiken aus Extreme Programming (XP) die Softwarequalität im Unternehmen verbessern können. Das von Kent Beck entwickelte agile Vorgehen richtet sich an kleine bis mittelgroße Projekte und stellt die Menschen, die Software entwickeln, in den Mittelpunkt. Aus abstrakten Werten ergeben sich Prinzipien, aus denen konkrete Praktiken folgen. Beispielsweise gehört Feedback zu den Werten; Test-Driven Development ist eine konkrete Praktik. Code Reviews greifen den Wunsch nach Rückmeldungen auf und schaffen einen Anlass, mit anderen Entwickler:innen über Code zu sprechen. Bei der Alte Oldenburger kamen bereits einzelne XP

Über das spannende Thema User Experience (UX) und Usability spreche ich mit Patrick Ziegler in der einhundertzweiundzwanzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Ich spreche mit Patrick Ziegler darüber, wie du als Fachinformatiker:in Anwendungsentwicklung Software gestaltest, die zu den Aufgaben deiner Benutzer:innen passt. Usability beschreibt die Gebrauchstauglichkeit während der Bedienung; User Experience umfasst auch Erwartungen vorab und Eindrücke danach. Wenn du früh mit deiner Zielgruppe sprichst und einfache Prototypen testest, kannst du Anforderungen genauer bestimmen und Nutzungsprobleme früh erkennen. Für den Einstieg helfen dir die Dialogprinzipien der ISO 9241, UI-Guidelines und überschaubare Usability-Tests im eigenen Betrieb. Kapitelmarken [00:00:00] Einführung in Usability und User Experience [00:00:48] Patrick Ziegler und sein Weg zur UX-Arbeit [00:05:26] CPUX und berufliche Qualifikation [00:07:00] Systematisch Produkte gestalten: das PiepEi [00:10:59] Arbeitsumfeld verstehen und technische Erfahrung einbringen [00:15:38] Methoden auswählen in der Zertifizierungsprüfung [00:17:22] Usability und User Experience verstehen [00:20:06] Zielgruppen und Gebrauchstauglichkeit [00:22:01] Eindrücke nach dem Gebrauch und Markenimage [00:23:44] SAP-Beispiel und Oberflächen für unterschiedliche Rollen [00:26:27] Nutzungsfehler und Dialogprinzipien [00:28:28] Formulare und Eingaben verständlich gestalten [00:31:42] User Journey und lautes Denken im Test [00:33:01] UI-Guidelines und etablierte Interaktionsmuster [00:37:15] Die Funktionssuche in Microsoft Office [00:40:10] Ideen finden und konkrete Probleme untersuchen [00:42:47] Erfordernisse und Anforderungen lösungsneutral formulieren [00:45:49] Beispiele: Heizung und Flipchart-Marker [00:49:42] Interviews und Befragungen auswerten [00:50:24] Anforderungen als Entwickler:in hinterfragen [00:53:41] Fokusgruppen und früher Kontakt zur Zielgruppe [00:56:03] Papierprototypen und digitale Entwürfe [00:58:31] Mit Lego schrittweise zum MVP [01:00:14] Walking Skeleton und vollständige Anwendungsfälle [01:02:16] Agile Projekte und agiler Festpreis [01:04:36] Usability-Tests im eigenen Betrieb [01:07:37] Anwendungen anhand von Kriterien inspizieren [01:09:05] Arbeitsergebnisse: Click-Dummy und User Journey [01:11:58] Wireframes und visuelle Gestaltung [01:14:49] Affordance und vertraute Bedienmuster [01:16:56] UX als gesamter Prozess und interdisziplinäre Zusammenarbeit [01:20:22] Plattformwahl und Internetverbindung im Arbeitsumfeld [01:21:26] UX in den Entwicklungsprozess einbinden [01:24:12] Meetups und Don't Make Me Think [01:27:09] Trainings, Blogs und weitere Quellen für den Einstieg [01:32:58] Unterschiedliche Perspektiven im Team [01:34:31] IT-Azubis in echte Aufgaben einbeziehen [01:37:13] Datenbanken, Sicherheit und Algorithmen praktisch vermitteln [01:40:38] Ideen von IT-Azubis und Design Thinking [01:42:53] Patricks technische Arbeit und R für Datenanalysen [01:45:57] Buchempfehlung: The Clean Coder [01:47:22] Kontakt zu Patrick Ziegler [01:49:42] Hinweise zu Shownotes und weiteren Beiträgen Inhalt Allgemeines zur Person Wie ist dein Name und wo arbeitest du (falls gewünscht)? Patrick Ziegler, Agentur für Design und Beratung mit ~15 MA An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob? Relaunch einer Webseite (Konzeption, Design, Rollout), Prozessanalysen, Schulgründung Wie bist du zur Informatik bzw. Softwareentwicklung gekommen? Umwege über Studium, Lehramt, Soziologie, IT, ursprünglich Zocken, später dann Hinterfragen "Wie geht das eigentlich?" Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert? Fachinformatiker Anwendungsentwicklung Mit welcher/n Programmiersprache/n arbeitest du im Alltag? Notgedrungen AppleScript ;-), sonst aber C#, JavaScript (Angular, React), R Was ist deine Lieblingsprogrammiersprache und warum? R, weil sie unglaublich schlank und elegant ist, sonst an sich das ETL-Framework SSIS Usability und User Experience Was sind Usability und User Experience? Usability = Gebrauchstauglichkeit, User Experience = Vor Benutzung, Während der Benutzung, Nach der Benutzung Warum brauchen wir UX? Weil ohne gute Benutzbarkeit Produkte nicht oder nur ungern genutzt werden. Auch: Fehleranfällig Welche Beispiele gibt es für gute UX? Neuland-Marker. Farbe hinten drauf, "Rollböppel" Welche Beispiele gibt es für schlechte UX und was hätte man anders machen können? SAP, Norman Doors Wie misst bzw. testet man die UX seiner Software? Net Promoter Score, Quantitative und Qualitative Benutzerbefragungen Hat UX auch etwas mit ansprechendem Design zu tun? Ja, wobei visuelle "Ästhetik" keine so große Rolle spielt wie ein sauber designter Prozess Was macht ein UX-Experte? Konzeption, Entwurf und Umsetzung oder Begleitung von kompletten Projekten oder UX-Teilen aus Projekten, (Wireframes, Prototypen, Workshopplanung und Durchführung, Benchmarking, Interviews, Usability-Tests, Fokusgruppen) Wie wird man zum UX-Experten? Da gibt es verschiedene Optionen, zum einen relativ klassisch über das Studium. Es gibt direkt Studiengänge "User Experience Design", die sich mit der Thematik beschäftigen. Oder für den digitalen Background Mensch-Computer-Design. Oder eben Industriedesign, alles Studiengänge mit hohem Grad an Benutzerfokussierung. Alternativ dazu gibt es die Option, den Weg über Zertifizierungen zu gehen. Da ich selbst 3 Kinder habe und für ein Vollzeitstudium momentan keine Kapazitäten vorhanden sind, habe ich diesen Weg gewählt. Das UXQB (User Experience Qualification Board) ist eine Organisation, die aus dem Deutschen Berufsverband der Usability Professionals (UPA) gegründet wurde. Da gibt es verschiedene Trainings, eins davon habe ich im Fachinformatiker-Forum auch schon in einem Blog-Post rezensiert. Welche Tools oder Methoden setzen UX-Experten ein? Da gibt es ganz verschiedene Ansätze. Entweder man geht über die emotional-kreative Route, wählt den analytischen Weg, oder nutzt eine Mischung aus beidem. Je nach Problem. Geht es eher um ein konkretes Problem, empfiehlt sich meiner Erfahrung nach eher ein analytischer Ansatz aus Fokusgruppen, A/B-Tests und konkreten, sogenannten kontextuellen Interviews mit vom Problem betroffenen. Soll eine Innovation geschaffen werden ohne ein konkretes Problem, sind es oft eher Methoden aus dem Bereich Design Thinking und Ideation, die zum Einsatz kommen. Da geht es erstmal darum, zu potentiellen Geschäftsfeldern einer Firma möglichst viel Input zu sammeln, der dann in späteren Runden und Iterationen verdichtet und konkretisiert wird. Zum Tooling kommt es auch auf das Problem an. Oft zum Einsatz kommen aber verschiedene Tools zum Erstellen von Wireframes oder Klickdummies, zumindest bei Softwareprojekten. Für eher analogere Ansätze tun es oft auch Skizzen oder neuerdings 3D-Drucke. Was man aus dem Rapid Prototyping eben so kennt. Die steigende Menge an Makerspaces, die es in vielen Städten gibt, ist da durchaus von Vorteil. Was können Softwareentwickler tun, um ihre Software benutzerfreundlicher zu gestalten? Zu allerst einmal den Benutzern zuhören, deren Problem die Software lösen soll, damit auch alle am Projekt Beteiligten wissen, worum es geht. Bei "neuen" Problemen empfiehlt sich zudem meiner Erfahrung nach eine iterative Vorgehensweise, z.B. Scrum. Was viele Entwickler gar nicht wissen, ist, dass es für so ziemlich alle Systeme und von allen Herstellern sogenannte Styleguides gibt, die schon jahrelang gesammeltes Wissen rund um die Gestaltung von Benutzeroberflächen enthalten. Z.B. von Apple, Microsoft, Google, Oracle und SAP. Darüberhinaus ist es natürlich immer gut, in regelmäßigen Usability-Tests (idealerweise vor und nach einem Release zu Vergleichsgründen) abzufragen, wie bestimmte Features angenommen werden. Wichtig ist hier meiner Einschätzung nach besonders, mit tatsächlichen potentiellen Nutzern zu sprechen, nicht mit Käufern der Software. Gibt es konkrete Tipps, um bei der täglichen Arbeit UX miteinzubeziehen? Es gibt ein großartiges Buch für Entwickler von Software mit dem Namen Don't make me think*, dessen Lektüre ich jedem wärmstens ans Herz legen kann. Das oberste Credo ist hier für mich insgesamt, das eigene Ego hinten anzustellen und das Bedürfnis der Benutzer an oberste Stelle zu setzen. Um bzgl. der Methoden und Co. auf dem aktuellen Stand zu bleiben, lohnt es darüber hinaus, sich mit anderen Leuten zu vernetzen, auf Meetups zu gehen und/oder diverse Newsletter rund um das Thema zu lesen (z.B. Nielsen Norman Group). Wie sieht ein Entwicklungsprozess aus, der UX optimal einbindet? Da gibt es tatsächlich einen in der ISO 9214 spezifizierten Prozess für, nämlich den "Prozess für menschzentrierte Gestaltung". Allgemein ist aber jedes Projektvorgehen, das Iterationen und regelmäßige Lieferungen an Benutzer vorsieht gut geeignet, für eine gute Benutzererfahrung zu dienen. Aus- und Weiterbildung Bildest du selbst Entwickler-Nachwuchs aus und wenn ja, wie ist das Vorgehen? Momentan nicht, bei meinem letzten Arbeitgeber habe ich das aber getan. Mein Vorgehen als solches war, Azubis und Praktikanten so oft wie möglich auf Augenhöhe in Problemlösungen mit einzubeziehen und sie da abzuholen, wo sie grade stehen. Was ist das letzte Fachbuch mit Bezug zur Programmierung, das du selbst gelesen hast? Das ist schon eine Weile her und dürfte The Clean Coder* von Robert C. Martin gewesen sein. Wobei das eher ein permanent genutztes Arbeitsbuch als ein "Einmal gelesen und dann weggelegt"-Buch ist. Momentan bin ich eher auf Meta- und Projektebene in Printliteratur unterwegs und lese Beiträge mit Programmierbezug meist online. Was ist dein absolutes Lieblingsbuch mit Bezug zur IT/Programmierung und warum? Ich muss gestehen, so viel technische Literatur mit IT oder Programmierbezug lese ich gar nicht. Das oben schon angesprochene Don't make me think*

Ein spannendes Interview mit Martin Helmich zum Thema Docker gibt es in der einhunderteinundzwanzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Mit Martin Helmig gehe ich der Frage nach, wie Docker dir als IT-Azubi beim Entwickeln hilft: Container kapseln Anwendungen samt Laufzeitumgebung, lassen sich schnell starten und über Images automatisiert bereitstellen. Dadurch kannst du deine produktive Umgebung lokal nachbauen und dieselben Images später auf einem Server betreiben. Kubernetes verteilt Container auf mehrere Server, wobei du dich um dauerhaften Speicher und die Netzwerkanbindung kümmern musst. Für deine Anwendungen spielen dabei möglichst zustandslose Prozesse und klar beschriebene Abhängigkeiten eine Rolle. Kapitelmarken [00:00:00] Einführung in Docker und Containerisierung [00:01:12] Martin Helmig und seine Arbeit bei Mittwald [00:02:22] Ausbildung, Studium und der Einstieg in Docker [00:05:18] Programmiersprachen im Arbeitsalltag [00:08:14] Go: Typsicherheit und ausführbare Programme [00:11:40] Was Docker ist und wie Container funktionieren [00:14:16] Container und virtuelle Maschinen [00:15:52] Schnell starten und Abläufe automatisieren [00:17:23] Infrastructure as Code und Immutable Infrastructure [00:20:22] Kubernetes und Container-Orchestrierung [00:22:32] Container-Netzwerke und externe Zugriffe [00:24:43] Vorteile für deinen Entwicklungsalltag [00:29:18] Docker unter Windows [00:32:08] Software aktualisieren und Container ersetzen [00:33:38] Basis-Images und differenzielle Schichten [00:36:51] Go, PHP und geeignete Anwendungsarchitekturen [00:40:32] Desktop-Anwendungen, Kommandozeilentools und Batch-Jobs [00:43:35] Container-Landschaften und Kubernetes bei Mittwald [00:45:53] Dauerhafte Daten und Netzwerkspeicher [00:48:50] Herausforderungen beim produktiven Cluster-Betrieb [00:50:57] Einarbeiten und mit Minikube ausprobieren [00:52:31] Anwendungen für Container entwickeln [00:55:20] Weitere Container-Lösungen: rkt, LXC und LXD [00:57:27] IT-Ausbildung und interne Trainings [00:58:32] Barcamps und Austausch im Unternehmen [01:02:44] Neue Themen praktisch erlernen [01:04:44] Buchempfehlung: The Clean Coder [01:06:11] Kontakt zu Martin Helmig [01:07:44] Docker in der Ausbildung und Shownotes Allgemeines zur Person Wie ist dein Name und wo arbeitest du? Martin Helmich von Mittwald. An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob? Einsatz von Containern in Hosting-Umgebungen. Wie bist du zur Informatik bzw. Softwareentwicklung gekommen? Als Kind schon mit dem Programmieren angefangen. Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert? Wirtschaftsinformatik (Bachelor) an der PHWT Vechta und danach Master in Informatik mit Schwerpunkt Mobile Anwendungen an der Hochschule Osnabrück. Mit welcher/n Programmiersprache/n arbeitest du im Alltag? JavaScript (NodeJS), Go, PHP. Was ist deine Lieblingsprogrammiersprache und warum? Go, weil sie Vieles besser/einfacher/sicherer macht als C. Docker Was ist Docker? Eine Software zur Containervirtualisierung. Warum gibt es aktuell so einen Hype rund um Docker? Wird viel im Zusammenhang mit DevOps verwendet. Container sind in aller Munde. Viele Buzzwords, die durch die Entwicklerszene geistern. Warum nimmt man nicht einfach die "guten alten" virtuellen Maschinen? Zu aufwändig für einzelne Services/Prozesse. Kleiner und leichter zu (ver-)teilen (siehe Docker Hub). Bessere Performance. Einfache Automatisierung. Was hat das Ganze mit "infrastructure as code" zu tun? Bei Docker spricht man eher von "immutable infrastructure", also zustandsloser Infrastruktur. Wozu braucht man in der Praxis Container? Infrastrukturbetrieb soll einfacher werden. Leicht in die Breite zu skalieren. Was ist Kubernetes und wofür braucht man das? Docker kann nicht selbst clustern usw. Kubernetes oder Docker Swarm sind Container Orchestrators, die das übernehmen. Kubernetes ist der de-facto Standard. Die Orchestrierer abstrahieren von der konkreten Infrastruktur (Hardware, Netzwerk usw.). Wichtig, wenn Container untereinander kommunizieren sollen, z.B. Webanwendung mit Datenbank. Welche Vorteile bieten mir als Softwareentwickler Container? Entwicklungs-/Produktionsumgebung exakt nachbauen. Versionen und Abhängigkeiten exakt nachstellen. Zielumgebung für Deplyoment kann durch Entwickler vorgegeben werden. Spart Zeit und gibt Sicherheit beim Deployment. Fehler können besser nachgestellt werden. Verhindert das "Works on my machine"-Syndrom. Ist der Einsatz von Docker auch auf auf Windows möglich? Man kann Linux-Container unter Windows starten. Man kann auch Windows-Container starten. Wie (einfach) aktualisiert man vorhandene Container (z.B. bei Betriebssystemupdates)? Ein Container soll sich eigentlich nicht mehr ändern. Images können auf Basis neuer Images neu gebaut werden. Das Basisimage ist z.B. Ubuntu und nur die Unterschiede werden in den darüberliegenden Containern gespeichert. Docker ist sehr intelligent, wenn es um das Ermitteln der Deltas geht. Gibt es Programmiersprachen oder -umgebungen, die sich besonders gut zum Einsatz in Containern eignen? Eigentlich geht alles. Für welche Applikationen/Unternehmen eignet sich der Einsatz von Containern besonders gut? Nur für Webanwendungen? Das Schreiben von Daten geht nicht und muss auf externe Speicher umgeleitet werden. Am besten fährt man den Container hoch und fasst ihn nie wieder an. Es gibt auch Kommandozeilentools, die als Container verpackt werden und z.B. ein komplettes Java mit allen Abhängigkeiten mitbringen. Wofür setzt du konkret Docker ein? Welche Vorteile hast du dadurch? Aufbau einer Containerlandschaft z.B. für TYPO3-/Wordpress-Hosting. Automatisierung dieser Infrastruktur mit Kubernetes und Erweiterung von Kubernetes um eigene Funktionen. Wo speichern die Datenbanken ihre Daten? Extern gemountete Partitionen können persistenten Speicher bereitstellen. Netzwerk-Storages werden auch von Kubernetes angeboten und sind transparent durch Kubernetes vom konkreten Dateisystem abstrahiert. Gibt es deiner Erfahrung nach auch Probleme/Nachteile beim Einsatz von Docker? Netzwerkspeicher und Datenbanken können umziehen. (IP-)Adressen ändern sich. Zustandslosigkeit der Services ist Voraussetzung. Das interne Netzwerk führt ggfs. zu Latenzen. Traffic von außen in das Containernetzwerk zu bekommen und Load Balancer einzurichten könnte schwierig sein. Initial ist es ein hoher Aufwand, die Infrastruktur ans Laufen zu bekommen. Es gibt aber z.B. Minikube als Startprojekt oder man startet direkt in der Cloud, z.B. mit AWS oder Azure. Ist die Architektur der Anwendung betroffen? Was hat Docker z.B. mit Microservices/DDD zu tun? Das Dateisystem kann wechseln, IP-Adressen ändern sich, root-Rechte sollten nicht erforderlich sein. Microservices passen gut in Container, aber das Umgekehrte gilt nicht zwingend. Gibt es Alternativen zu Docker? rkt, LXC, LXD. Aber Docker ist der Platzhirsch. Aus- und Weiterbildung Bildest du selbst Entwickler-Nachwuchs aus und wenn ja, wie ist das Vorgehen? Nein, ich arbeite eher bei innerbetrieblichen Fortbildungen mit. Wir haben z.B. ein Barcamp bei Mittwald durchgeführt. Außerdem nehme ich an Konferenzen teil. Was ist dein absolutes Lieblingsbuch mit Bezug zur IT/Programmierung und warum? The Clean Coder* von Uncle Bob. * Wie bildest du dich selbst weiter? Einfach anfangen! Z.B. ein Tutorial durcharbeiten. Ich bin eher "hands on", Bücher funktionieren bei mir nicht so gut. Mehr über Martin und Mittwald Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren? Auf meiner Website oder bei GitHub. Mehr über Mittwald gibt es auf der Website und der speziellen Karriereseite. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Zusammenfassung Martin Helmigs Weg zur Softwarearchitektur Mein Gesprächspartner Martin Helmig arbeitet als Systemarchitekt bei Mittwald und beschäftigt sich dort mit Container-Infrastrukturen. Er begann als Kind zu programmieren und verband später eine Ausbildung zum/zur Fachinformatiker:in Anwendungsentwicklung mit einem dualen Studium der Wirtschaftsinformatik. Anschließend absolvierte er einen Informatik-Master mit dem Schwerpunkt verteilte und mobile Anwendungen. In seiner betrieblichen Masterarbeit untersuchte er, wie sich eine über Jahrzehnte gewachsene PHP-Anwendung in eine moderne Architektur überführen lässt. Dabei beschäftigte er sich mit Microservices und Docker. Für eigene Projekte arbeitet Martin vor allem mit Node.js samt TypeScript oder mit Go. An Go schätzt er die statische Typisierung, durch die der Compiler Fehler früh erkennen kann. Die Sprache kompiliert zu nativem Maschinencode und kommt mit wenig Speicher aus. Zahlreiche Bibliotheken erleichtern ihm die Arbeit; außerdem übernimmt die Sprache das Speichermanagement. Passend kompilierte Go-Anwendungen lassen sich als eigenständige ausführbare Datei verteilen. Wie Docker-Container funktionieren Docker isoliert Prozesse, die auf demselben Rechner laufen. Ein Container erhält dafür eine eigene Umgebung mit einem Dateisystem. Üblicherweise läuft darin ein einzelner Dienst, etwa ein Webserver oder ein Applikationsserver. Alle Container teilen sich den Betriebssystemkern des Hosts. Eine virtuelle Maschine besitzt einen eigenen Kernel und bringt ein vollständiges Betriebssystem mit. Bei Docker beschränkt sich die Umgebung auf das, was der jeweilige Dienst braucht. Zusätzliche Systemdienste wie ein SSH-Server gehören üblicherweise nicht dazu. Der gemeinsame Kernel bestimmt, welche Container direkt auf einem Host laufen können. Für einen Windows-Container ist ein Windows-Kernel erforderlich. Docker stellt Werkzeuge bereit, mit denen du Images bauen und Container daraus starten kannst. Ein Image enthält das Dateisystem und die benötigte Software. Du beschreibst, wie es aufgebaut werden soll, und kannst den Ablauf automatisieren....

Den Abschluss der Episodenreihe zum Thema Cloud Computing bilden die Themen Auswahlkriterien für eine Cloud-Plattform und mögliche IHK-Aufgaben in der einhundertzwanzigsten Episode des Anwendungsentwickler-Podcasts. TL;DR Für die Wahl einer Cloud-Plattform habe ich sechs Kriterien zusammengestellt, mit denen du die Anforderungen deiner Anwendung prüfen kannst: Kosten, Skalierbarkeit, Ausfallsicherheit, Datenschutz, Datensicherheit und Abhängigkeiten vom Anbieter. Nichtmonetäre Kriterien kannst du in einer Nutzwertanalyse gewichten und bewerten. Für deine IHK-Prüfung gehören außerdem die Cloud-Modelle und Service-Level-Agreements zum Lernstoff, wobei viele Aufgaben dein vorhandenes Grundwissen auf einen Cloud-Anwendungsfall beziehen. Kapitelmarken [00:00:01] Abschluss der Cloud-Computing-Reihe [00:01:00] Kriterien für die Wahl einer Cloud-Plattform [00:01:49] Entscheidungen mit einer Nutzwertanalyse begründen [00:03:19] Kosten für Hardware, Cloud-Dienste und Personal [00:06:42] Skalierbarkeit bei Lastspitzen und neuen Projekten [00:08:52] Ausfallsicherheit und Betrieb rund um die Uhr [00:12:12] Datenschutz und Serverstandort [00:14:59] Datensicherheit und mögliche Angriffe [00:17:40] Abhängigkeiten von Cloud-Anbietern [00:20:04] Support und Aufwand beim Anbieterwechsel [00:21:19] Eingestellte Dienste und langfristig verfügbare Laufzeitumgebungen [00:23:57] Cloud Computing als Thema der IHK-Prüfung [00:25:37] Grundwissen auf Cloud-Aufgaben anwenden [00:27:26] Infrastructure, Platform und Software as a Service [00:27:55] Public, Private und Hybrid Cloud [00:29:37] Vor- und Nachteile sowie Kosten berechnen [00:30:37] Rechtliche Aspekte und Service-Level-Agreements [00:31:38] Neue Cloud-Themen und das Fachgespräch [00:33:37] Shownotes und Kontakt Inhalt Kriterien für die Auswahl einer Plattform/eines Anbieters Kosten Wie wichtig ist Kostentransparenz? Muss evtl. auf eigene Mitarbeiter verzichtet werden? Wie viel Leerlauf erzeugt die Anwendung? Wie viel Last erzeugt die Anwendung? Skalierbarkeit Gibt es Lastspitzen, die abgefangen werden müssen? Ist ein großes Kundenwachstum zu erwarten? Soll vielleicht nur ein Testballon gestartet und danach alles wieder eingestampft werden? Ausfallsicherheit Muss die Anwendung im 24/7-Betrieb laufen? Wie hoch ist der finanzielle Verlust im Fall eines Ausfalls? Gibt es harte Anforderungen bzgl. Antwortzeiten? Datenschutz Werden personenbezogene Daten verarbeitet? Müssen die Server in Deutschland stehen? Wurde der eigene Datenschutzbeauftragte befragt? Datensicherheit Was passiert, wenn der Anbieter gehackt wird? Was passiert, wenn wir selbst gehackt werden? Wie wird Datensicherheit im Unternehmen behandelt? Ist das nötige Know-How vorhanden? Abhängigkeit Dürfen etwaige Kernkompetenzen aus der Hand gegeben werden? Können wir uns von einem ausländischen Anbieter abhängig machen? Wie schnell reagiert der Anbieter auf unsere Anfragen? Was passiert, wenn der Anbieter den Dienst einstellt oder verändert? Wird die verwendete Programmiersprache überhaupt (langfristig) angeboten? Mögliche Aufgaben in der IHK-Prüfung Cloud Computing wird oft als Aufhänger für grundlegende Fragen wie Sicherheit, Datenschutz, Energieverbrauch usw. genommen. XaaS voneinander abgrenzen und Vor-/Nachteile nennen. Public vs. Private vs. Hybrid Cloud. Vor-/Nachteile nennen von Cloud und On Premise nennen, z.B. Auslastung der Server, Skalierbarkeit, Kosten, Time to Market. Strom- bzw. Betriebskosten berechnen und mit Alternativen vergleichen. Rechtliche Aspekte: Datenschutz, Service Level Agreements (SLA) Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Amazon-Mitarbeiter legte mit Tippfehler Teile des Internets lahm Warum ein Ausfall bei Amazon große Teile des Internets lahmlegte Zusammenfassung Eine Cloud-Plattform auswählen Wenn du eine Anwendung in die Cloud bringen möchtest, hängt die passende Plattform vom konkreten Projekt ab. Dabei kommen unterschiedliche Betriebsmodelle infrage, vom eigenen Server bis zu Angeboten wie Infrastructure as a Service oder Software as a Service. Für eine Nutzwertanalyse kannst du nichtmonetäre Kriterien festlegen, die möglichen Lösungen mit Punkten bewerten und diese Punkte gewichten. Aus den gewichteten Werten berechnest du einen Gesamtwert, der deine Entscheidung nachvollziehbar macht. Das Verfahren eignet sich auch für dein Abschlussprojekt und dessen Dokumentation. Die Kosten behandelst du als monetäres Kriterium gesondert. Kosten Hardware kaufen: Für eigene Server brauchst du Geld zu Beginn des Projekts. Dieses Geld bleibt in der Hardware gebunden. Gerade bei einem kleinen Unternehmen kann das verfügbare Budget die Entscheidung beeinflussen. Laufende Cloud-Kosten: Cloud-Dienste werden beispielsweise monatlich oder nach Last abgerechnet. Bei Function as a Service hängt der Preis von den Aufrufen ab. Wenn du deren Anzahl schwer abschätzen kannst, werden auch die Ausgaben schwerer planbar. Personal einplanen: Eigene Server müssen betreut werden. Dafür brauchst du Administrator:innen oder Entwickler:innen, die während dieser Arbeit weniger Zeit zum Programmieren haben. Auslastung berücksichtigen: Prüfe, wie viel Last deine Anwendung erzeugt und wie lange Ressourcen unbeschäftigt bleiben. Eine kurze Lastspitze kann dazu führen, dass du leistungsfähige Hardware anschaffst, deren Kapazität während eines großen Teils des Jahres frei bleibt. Skalierbarkeit Bei saisonalen Lastspitzen oder einem erwarteten Zuwachs an Kund:innen kann es sinnvoll sein, die Kapazität schnell anzupassen. Wie viel Skalierbarkeit du brauchst, ergibt sich aus dem Verlauf der Last deiner Anwendung. Auch wenn du eine Produktidee ausprobieren möchtest, kannst du mit wenig Cloud-Kapazität starten. Steigt die Nachfrage, erhöhst du die Ressourcen. Beendest du den Versuch, kannst du den gebuchten Server wieder abbestellen. Berücksichtige bei deiner Entscheidung deshalb auch, wie lange das Projekt laufen soll und wie sicher du die Nachfrage einschätzen kannst. Ausfallsicherheit und Antwortzeiten Für eine interne Geschäftsanwendung können die Arbeitszeiten bestimmen, wann sie erreichbar sein muss. Bei einem Online-Shop oder dem Backend einer mobilen App können Kund:innen auch nachts zugreifen. In meinem Unternehmen können Versicherte über eine App Arztrechnungen einreichen. Weil sie das auch am Wochenende und außerhalb der Geschäftszeiten tun, muss die Anwendung rund um die Uhr erreichbar sein. Prüfe für dein Projekt: Zu welchen Zeiten muss die Anwendung laufen? Welchen finanziellen Schaden verursacht ein Ausfall? Welche Antwortzeiten wurden vertraglich vereinbart? Wer kümmert sich um eine Störung, wenn sie nachts auftritt? Große Cloud-Anbieter beschäftigen Fachleute, die ihre Infrastruktur betreiben und nach Störungen wiederherstellen. Auch dort können ganze Rechenzentren ausfallen. Während einer solchen Störung bist du darauf angewiesen, dass der Anbieter sie behebt; auf dessen Hardware kannst du selbst nicht zugreifen. Datenschutz Sobald deine Anwendung personenbezogene Daten verarbeitet, musst du die rechtlichen Vorgaben beachten. Dazu gehören etwa Namen und unter bestimmten Umständen auch IP-Adressen. Der rechtliche Rahmen umfasst das Bundesdatenschutzgesetz und die DSGVO, deren Start im Podcast für Mai 2018 angekündigt wird. Verstöße können hohe finanzielle Folgen haben. Bevor du dich für einen Anbieter entscheidest, klärst du, welche Daten verarbeitet werden und welche Vorgaben für den Serverstandort gelten. Beziehe deine:n Datenschutzbeauftragte:n ein, sofern dein Unternehmen eine solche Stelle hat. Dabei ist auch zu prüfen, welche Rolle ein ausländisches Unternehmen hinter dem Cloud-Angebot spielt, selbst wenn dessen Rechenzentrum in Deutschland steht. Datenschutzanforderungen können eine Lösung ausschließen. Für die sensiblen Gesundheitsdaten in meinem Krankenversicherungsunternehmen kommt ein Wechsel in die Cloud unter den beschriebenen Bedingungen kaum infrage. Datensicherheit Bei der Entscheidung gehören mögliche Angriffe auf den Cloud-Anbieter ebenso in die Prüfung wie Angriffe auf dein eigenes Unternehmen. Entscheidend sind die internen Sicherheitsrichtlinien und das vorhandene Fachwissen. Große Anbieter beschäftigen Sicherheitsexpert:innen und betreiben aufwendig abgesicherte Infrastruktur. Ihre Plattformen sind zugleich attraktive Ziele für Angreifer:innen. Für eigene Server musst du klären, ob dein Unternehmen ausreichend Fachwissen hat, um sie abzusichern. Ein eigenes Servernetz ohne Verbindung zum Internet begrenzt Angriffe von außen. Angriffe durch Mitarbeiter:innen bleiben dabei ein Risiko. Wie sicher eine Lösung ist, hängt von den konkreten Umständen ab. Abhängigkeiten vom Anbieter Wenn du Aufgaben an einen Cloud-Anbieter abgibst, solltest du klären, welche Fähigkeiten im Unternehmen bleiben sollen und welche Tätigkeiten ausgelagert werden dürfen. Ein Unternehmen kann sich dadurch stärker auf seine eigentliche Arbeit konzentrieren. Interne Vorgaben können verlangen, bestimmte Aufgaben selbst zu übernehmen. Weitere Kriterien betreffen den Anbieter und deine technische Umgebung: Support: Prüfe, wie schnell du bei einem Fehler Hilfe bekommst und welchen Einfluss du als kleine:r Kund:in auf das Angebot hast. Dienste: Ein Anbieter kann Angebote verändern oder einstellen. Dann brauchst du eine andere Lösung und musst deine Anwendung gegebenenfalls anpassen. Anbieterwechsel: Besonders bei Serverless Computing können technische Abhängigkeiten einen Wechsel aufwendig machen. Der Aufwand hängt davon ab, wie viel du an den Anbieter ausgelagert hast. Programmiersprache und Laufzeitumgebung: Die benötigte Umgebung muss verfügbar sein und langfristig unterstützt werden. In meinem Unternehmen wird beispielsweise Natural für das Bestandssystem eingesetzt, wodurch die Auswahl passender Cloud-Angebote eingeschränkt ist. Bei einer großen vorhandenen Codebasis bedeutet ein Sprachwechsel erheblichen Aufwand. Cloud Computing in der IHK-Prüfung ...