title

Anwendungsentwickler-Podcast

Stefan Macke

0
Followers
1
Plays
Anwendungsentwickler-Podcast
Anwendungsentwickler-Podcast

Anwendungsentwickler-Podcast

Stefan Macke

0
Followers
1
Plays
OVERVIEWEPISODESYOU MAY ALSO LIKE

Details

About Us

Der Podcast rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung. Aber auch für ausgebildete Softwareentwickler oder Programmierer und alle, die Spaß an der Softwareentwicklung haben.

Latest Episodes

Routing (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #140

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

45 MIN23 hours ago
Comments
Routing (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #140

Rückblick auf die IHK-Sommerprüfung 2019 – Anwendungsentwickler-Podcast #139

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

68 MIN2 weeks ago
Comments
Rückblick auf die IHK-Sommerprüfung 2019 – Anwendungsentwickler-Podcast #139

DNS und DHCP (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #138

Um zwei zentrale Technologien der Netzwerkgrundlagen – DNS und DHCP – geht es in der einhundertachtunddreißigsten Episode des Anwendungsentwickler-Podcasts. Inhalt DNS * Theoretisch können wir auch im Internet surfen, indem wir die IP-Adressen der Websites eingeben, aber das kann sich kein Mensch merken. * Daher sind Websites über einen sprechenden Namen, die Domain, erreichbar. Dafür brauchen wir dann aber eine Übersetzung von Domainname in IP-Adresse, damit der Computer kommunizieren kann. * Einfachste Möglichkeit: Datei mit Übersetzung von IP in Domain (gibt es tatsächlich: hosts unter Windows z.B. unter C:\Windows\System32\drivers\etc, die Paare aus IP-Adressen und Hostnamen enthält). Dann müsste aber jeder Computer die gesamte Liste aller verfügbaren Domains kennen. Das ist nicht machbar. # Copyright (c) 1993-2009 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost 136.243.146.110 macke.it * Die Lösung ist DNS (Domain Name System), ein „Telefonbuch“ für Websites/IP-Adressen, das auf viele Server verteilt ist. * Mit dem Kommandozeilentool nslookup können DNS-Server abgefragt werden. * DNS kann kaskadiert werden. Wenn ein Server nicht weiter weiß, fragt er den übergeordneten Server und speichert (cacht) ggfs. das Resultat für die nächste Anfrage. * Die letzte Instanz der Kaskade sind die sog. Root-Server. * Die sogenannten Websperren gegen „verbotene“ Websites funktionieren im Prinzip so, dass einzelne „Telefonbücher“ (z.B. die der deutschen Internetprovider) gesäubert werden. Aber man kann sie einfach umgehen, indem man bewusst einen anderen DNS-Server verwendet, der z.B. in einem anderen Land steht. DHCP * Zurück zu unserem Aufruf: Der Client ruft eine Adresse im Browser auf und der Server liefert ihm HTML zurück. Aber dazu braucht der Client auch eine IP-Adresse. * Die Zieladresse ist dank DNS bekannt, aber man braucht auch eine Quelladresse für den Client. Die kann man selbst vergeben, aber das wird bei mehreren PCs immer schwieriger, da sie eindeutig sein müssen (sonst weiß das Netzwerkpaket der Antwort nicht, wo es hin muss). * Die Lösung heißt DHCP (Dynamic Host Configuration Protocol). Das ist ein Dienst, den ein Server (zuhause z.B. die FRITZ!Box*) bereitstellt, der sich dann z.B. die Liste der bereits verwendeten IP-Adressen merkt und keine doppelt vergibt. Außerdem kann man viele weitere Einstellungen (wie z.B. den zu nutzenden DNS-Server) per DHCP an die Clients verteilen. Literaturempfehlungen Im guten alten

41 MINJUN 17
Comments
DNS und DHCP (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #138

Latest Episodes

Routing (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #140

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

45 MIN23 hours ago
Comments
Routing (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #140

Rückblick auf die IHK-Sommerprüfung 2019 – Anwendungsentwickler-Podcast #139

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

68 MIN2 weeks ago
Comments
Rückblick auf die IHK-Sommerprüfung 2019 – Anwendungsentwickler-Podcast #139

DNS und DHCP (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #138

Um zwei zentrale Technologien der Netzwerkgrundlagen – DNS und DHCP – geht es in der einhundertachtunddreißigsten Episode des Anwendungsentwickler-Podcasts. Inhalt DNS * Theoretisch können wir auch im Internet surfen, indem wir die IP-Adressen der Websites eingeben, aber das kann sich kein Mensch merken. * Daher sind Websites über einen sprechenden Namen, die Domain, erreichbar. Dafür brauchen wir dann aber eine Übersetzung von Domainname in IP-Adresse, damit der Computer kommunizieren kann. * Einfachste Möglichkeit: Datei mit Übersetzung von IP in Domain (gibt es tatsächlich: hosts unter Windows z.B. unter C:\Windows\System32\drivers\etc, die Paare aus IP-Adressen und Hostnamen enthält). Dann müsste aber jeder Computer die gesamte Liste aller verfügbaren Domains kennen. Das ist nicht machbar. # Copyright (c) 1993-2009 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost 136.243.146.110 macke.it * Die Lösung ist DNS (Domain Name System), ein „Telefonbuch“ für Websites/IP-Adressen, das auf viele Server verteilt ist. * Mit dem Kommandozeilentool nslookup können DNS-Server abgefragt werden. * DNS kann kaskadiert werden. Wenn ein Server nicht weiter weiß, fragt er den übergeordneten Server und speichert (cacht) ggfs. das Resultat für die nächste Anfrage. * Die letzte Instanz der Kaskade sind die sog. Root-Server. * Die sogenannten Websperren gegen „verbotene“ Websites funktionieren im Prinzip so, dass einzelne „Telefonbücher“ (z.B. die der deutschen Internetprovider) gesäubert werden. Aber man kann sie einfach umgehen, indem man bewusst einen anderen DNS-Server verwendet, der z.B. in einem anderen Land steht. DHCP * Zurück zu unserem Aufruf: Der Client ruft eine Adresse im Browser auf und der Server liefert ihm HTML zurück. Aber dazu braucht der Client auch eine IP-Adresse. * Die Zieladresse ist dank DNS bekannt, aber man braucht auch eine Quelladresse für den Client. Die kann man selbst vergeben, aber das wird bei mehreren PCs immer schwieriger, da sie eindeutig sein müssen (sonst weiß das Netzwerkpaket der Antwort nicht, wo es hin muss). * Die Lösung heißt DHCP (Dynamic Host Configuration Protocol). Das ist ein Dienst, den ein Server (zuhause z.B. die FRITZ!Box*) bereitstellt, der sich dann z.B. die Liste der bereits verwendeten IP-Adressen merkt und keine doppelt vergibt. Außerdem kann man viele weitere Einstellungen (wie z.B. den zu nutzenden DNS-Server) per DHCP an die Clients verteilen. Literaturempfehlungen Im guten alten

41 MINJUN 17
Comments
DNS und DHCP (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #138

Listen Now On Himalaya