200 Folgen

Der Podcast für Auszubildende, Ausbilder und IHK-Prüfer in den IT-Berufen (Fachinformatiker für Anwendungsentwicklung/Systemintegration/Daten- und Prozessanalyse/Digitale Vernetzung, IT-Systemelektroniker, Kaufmann für IT-Systemmanagement, Kaufmann für Digitalisierungsmanagement). Stefan Macke gibt Tipps für die Ausbildung, die IHK-Prüfungen und alles, was sonst noch mit den Berufsbildern zu tun hat. Aber auch für bereits ausgebildete Softwareentwickler/Programmierer/Administratoren und alle, die Interesse an der Softwareentwicklung oder IT haben, ist bestimmt etwas Interessantes dabei!



https://it-berufe-podcast.de

IT-Berufe-Podcast Stefan Macke

    • Technologie
    • 5,0 • 145 Bewertungen

Der Podcast für Auszubildende, Ausbilder und IHK-Prüfer in den IT-Berufen (Fachinformatiker für Anwendungsentwicklung/Systemintegration/Daten- und Prozessanalyse/Digitale Vernetzung, IT-Systemelektroniker, Kaufmann für IT-Systemmanagement, Kaufmann für Digitalisierungsmanagement). Stefan Macke gibt Tipps für die Ausbildung, die IHK-Prüfungen und alles, was sonst noch mit den Berufsbildern zu tun hat. Aber auch für bereits ausgebildete Softwareentwickler/Programmierer/Administratoren und alle, die Interesse an der Softwareentwicklung oder IT haben, ist bestimmt etwas Interessantes dabei!



https://it-berufe-podcast.de

    Angemessene fachliche/technische Tiefe des Abschlussprojekts für Anwendungsentwickler:innen – IT-Berufe-Podcast #186

    Angemessene fachliche/technische Tiefe des Abschlussprojekts für Anwendungsentwickler:innen – IT-Berufe-Podcast #186

    Um die angemessene fachliche bzw. technische Tiefe des Themas für das IHK-Abschlussprojekt für Anwendungsentwickler:innen geht es in der einhundertsechsundachzigsten Episode des IT-Berufe-Podcasts.



    Inhalt

    Viele Projektanträge zum Abschlussprojekt werden abgelehnt, weil das umzusetzende Projekt nicht die nötige fachliche bzw. technische Tiefe aufweist. In unserem Prüfungssystem gibt es dafür sogar einen expliziten Ablehnungsgrund. Doch was heißt es genau, dass die fachliche Tiefe nicht erreicht wurde? Welche fachliche Tiefe ist überhaupt angemessen und wie erkenne ich als Prüfling, ob ich sie erreiche?

    Mein Standardbeispiel: Projektverwaltung

    Ich führe als Beispiel für eine übliche Projektarbeit für Anwendungsentwickler:innen immer eine klassische Web-Anwendung an. Nehmen wir das oft strapazierte Beispiel einer Zeiterfassungssoftware oder einer Projektverwaltung. Dabei handelt es sich um eine kleine Web-Anwendung mit ein paar Datenbanktabellen, etwas fachlicher Logik und ein paar netten Oberflächen.

    In solch einer Anwendung kann ich als Anwendungsentwickler:in alles zeigen, was ich in meiner dreijährigen Ausbildung gelernt haben sollte. Soll ich ein Projekt enpfehlen, führe ich deswegen gerne dieses Beispiel für ein fachlich ausreichendes Projekt für die Abschlussprüfung an.



    * Ich kann eine Datenbank modellieren, z.B. mit einem ERM oder Tabellenmodell.

    * Ich kann ein Klassendesign entwerfen, z.B. mit einem Klassendiagramm oder gar mit Test Driven Development.

    * Ich kann die Oberflächen gestalten, natürlich nach ergonomischen Gesichtspunkten und mit Mockups für den ersten Entwurf.

    * Außerdem muss ich mich um das Zusammenspiel der Komponenten kümmern und brauche dafür eine tragfähige Architektur, z.B. MVC.



    Kurz gesagt ist in solch einem Projekt alles Technische enthalten, was man heutzutage in der Programmierung können muss. Und ich kann mich vieler Methoden der Softwareentwicklung bedienen, die mein planvolles Vorgehen dokumentieren.

    Hast du auch ein paar konkrete Zahlen?

    Als ganz grobe Daumenregel für Anwendungsentwickler:innen führe ich immer ein „klassisches“ Webprojekt an: kleine Datenbank, ein bisschen Logik, Frontend drüber. Da kann man das volle Spektrum der Entwicklungstätigkeiten zeigen.



    * ca. fünf Datenbanktabellen („eine Hand voll“)

    * ca. fünf Oberflächen dazu

    * ca. zehn Klassen (tendenziell eher mehr)



    Sollte die Anwendung eine komplizierte Logik umsetzen, kann natürlich bei den anderen Komponenten entsprechend gekürzt werden. Diese grobe Richtlinie ist sicherlich nicht allgemeinverbindlich. Es kommt immer auf den Einzelfall an. Ich möchte nur deutlich machen, dass eine triviale Konsolenapplikation, die eine Textdatei einliest und wieder speichert, nicht ausreicht. Es sei denn, die Applikation verwendet dafür einen selbst programmierten Verschlüsselungsalgorithmus. 😉

    Die Diagramme aus dem Titelbild dieser Episode sollten offensichtlich zeigen, dass dieser Umfang für ein Abschlussprojekt nicht ausreicht! 😂 Aber ich habe schon Artefakte in echten Dokus gesehen, die nicht viel umfangreicher waren (z.B. nur zwei Use-Cases oder drei Aktivitäten).

    Brauche ich alle Komponenten – Datenbank, Logik, UI?

    Das heißt nicht, dass jedes Abschlussprojekt alle genannten Komponenten umfassen muss. Nicht alle Unternehmen haben die Anforderung, Weboberflächen über Datenbanken zu gestalten. In vielen Betrieben wird eine bestehende Software erweitert, eine Oberfläche angepasst, oder eine Datenbank um zusätzliche Tabellen erweitert. Oft werden auch Programme benötigt, die gar keine grafische Oberfläche haben. Wenn es z.B. um den Datenabgleich zwischen ERP-System und Webshop geht, der nachts als Batchjob laufen soll, ist es völlig unnötig, eine schön gestaltete grafische Oberfläche dazu zu entwickeln. Auch werden inzwischen oft REST-APIs als Abschl...

    • 37 Min.
    Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung – IT-Berufe-Podcast #185

    Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung – IT-Berufe-Podcast #185

    Um den sinnvollen Aufbau eines IHK-Abschlussprojekts für Fachinformatiker:innen Anwendungsentwicklung geht es in der einhundertfünfundachzigsten Episode des IT-Berufe-Podcasts.



    Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung

    Oft lese ich Projektdokumentationen für den Beruf Fachinformatiker:in Anwendungsentwicklung, die in sich einfach nicht stimmig sind. Der Projektablauf folgt keinem roten Faden und Artefakte werden wild durcheinandergewürfelt. Oft werden auch einfach nur Kapitel aus Dokumentationsvorlagen „ausgefüllt“, scheinbar ohne über ihre Sinnhaftigkeit nachzudenken.

    In dieser Podcast-Episode gebe ich einen Überblick über einen – aus meiner Sicht – sinnvollen Ablauf eines IHK-Projekts im Bereich Anwendungsentwicklung inkl. möglicher Artefakte und ihrem Zweck. Dabei gehe ich nicht auf die Beschreibung des Projekts, die Wirtschaftlichkeitsbetrachtung, das Projektmanagement, die Ressourcenplanung usw. ein, sondern nur auf die Planung und Durchführung der eigentlichen Aufgabe: der Entwicklung einer Softwarelösung. Selbstverständlich gehören aber alle genannten Punkte auch in eine IHK-Projektdokumentation.

    Wahl des Vorgehensmodells

    Fast immer ist das Wasserfallmodell das einzig sinnvolle Vorgehensmodell, da das IHK-Projekt vom Prüfling alleine in einer fest vorgegebenen Zeit mit vorgegebenem (weil im Antrag genehmigten) Umfang umgesetzt werden muss.

    Praxisbeispiele für unpassende Prozesse:



    * Scrum gewählt, aber



    * klassische Wasserfallphasen durchgeführt/beschrieben

    * Lasten-/Pflichtenheft erstellt statt User Stories

    * Projekt alleine umgesetzt ohne Team/Scrum Master/Product Owner

    * gesamtes Projekt ist ein einziger Sprint





    * XP gewählt, aber



    * keine Praktiken (z.B. Pair Programming, Test Driven Development) angewendet





    * Kanban gewählt, aber



    * Lanes nur ToDo/Doing/Done







    Artefakte methodisch sinnvoll einsetzen



    * Software soll nicht einfach „runterprogrammiert“ werden, sondern methodisch entwickelt werden. Dabei helfen verschiedene Artefakte wie Entity-Relationship-Modelle, UML-Diagramme usw.

    * Diagramme können oft auf zwei Arten eingesetzt werden: zur Modellierung (vor der Implementierung) und zur Dokumentation (nach der Implementierung). Sie haben keinen Selbstzweck, sondern sollen immer den jeweiligen Prozessschritt unterstützen.

    * Ihr Einsatz muss zum gewählten Prozess passen. Ein Klassendiagramm zur Modellierung passt z.B. nicht so gut zu Test-Driven-Development, bei dem die Klassen sich erst bei der Implementierung ergeben.

    * Die Artefakte müssen auch zeitlich sinnvoll im Projekt untergebracht werden. Die Anforderungen erst nach der Implementierung zu dokumentieren ist sinnfrei.

    * Artefakte sollen im Prozess auch einen erkennbaren Mehrwert für die späteren Prozessschritte bieten. Mockups sind z.B. sehr hilfreich, um auf ihrer Basis ein Datenmodell zu erzeugen. Und auf Basis des Datenmodells können dann wiederum Klassen modelliert werden usw.

    * Durch den passenden Einsatz der Artefakte in den jeweiligen Prozessschritten füllt sich die Projektdokumentation automatisch mit spannenden Inhalten für die Prüfer:innen! 😀



    Anforderungen aufnehmen



    * Ist-Analyse durchführen



    * Bisherige Lösung untersuchen, Schwachstellen aufdecken.

    * mögliche Ergebnisse: Aktivitätsdiagramm/EPK/BPMN, Screenshots/Fotos der bisherigen Lösung





    * Anforderungen an neue Lösung strukturiert erfassen



    * Interviews mit Stakeholdern führen

    * Priorisierung der Anforderungen

    * Ergebnis: z.B. User Stories, MoSCoW





    * Anwendungsfälle modellieren



    * Was wollen die Stakeholder mit der Anwendung fachlich machen/erreichen?

    * Ergebnis: Use-Case-Diagramm

    • 1 Std. 45 Min.
    Verträge, AGBs, SLAs – IT-Berufe-Podcast #184

    Verträge, AGBs, SLAs – IT-Berufe-Podcast #184

    Um alles rund um Verträge als Vorbereitung auf die AP1 geht es in der einhundertvierundachzigsten Episode des IT-Berufe-Podcasts.



    Inhalt

    Für die AP1 ist es sinnvoll, einige grundsätzliche Vertragsarten zu kennen und unterscheiden zu können. Sowohl auf Anbieter- als auch auf Nachfragerseite ist es wichtig zu verstehen, welche Art von Vertrag vorliegt, da daraus unterschiedliche Rechte und Pflichten entstehen können.

    Disclaimer: Das hier ist keine Rechtsberatung! 🙂

    Vertrag

    Ein Vertrag ist die von zwei (oder mehr) Vertragsparteien erklärte Einigung über die Begründung eines Schuldverhältnisses (siehe § 311 BGB). Hierfür sind zwei übereinstimmende Willenserklärungen erforderlich. Beispiel: Angebot und Annahme, Bestellung und Lieferung.

    Verträge können schriftlich, mündlich oder durch „konkludentes Handeln“ entstehen.

    Vertragsarten



    * Kaufvertrag: Verkäufer:in verkauft etwas an Käufer:in.



    * Beispiele in der IT: Hardware-/Softwarekauf





    * Lizenzvertrag: Lizenzgeber:in räumt Lizenznehmer:in Rechte an einem geschützten Werk (z.B. Patent, Marke, Urheberrecht) ein.



    * Beispiele in der IT: Lizenzierung von Software, Bildrechte einkaufen





    * Servicevertrag: Regelt die Erbringung produktbezogener Leistungen zwischen Anbieter:in und Kund:in.



    * Beispiele in der IT: Wartungsverträge für Software (z.B. für Patches und Updates) oder Hardware durch Dienstleister





    * Mietvertrag: Vermieter:in überlässt Mieter:in eine bewegliche oder unbewegliche Sache zur zeitweisen Nutzung.



    * Beispiele in der IT: Miete eines Autos für eine Dienstreise, Miete von Software





    * Leasingvertrag: Leasinggeber:in (Vermieter:in) überlässt Leasingnehmer:in (Mieter:in) eine Sache zur Nutzung wie bei der Miete, aber mit Fokus auf eine langfristige Nutzung mit der Möglichkeit des Erwerbs am Ende der Vertragslaufzeit. Außerdem sind bestimmte Sachverhalte anders geregelt, z.B. die Inspektion beim geleasten Auto oder die Wahl des konkreten Modells und der Ausstattung durch den/die Leasingnehmer:in.



    * Beispiele in der IT: Leasing teurer Hardware statt einmaligen Kaufs





    * Werkvertrag: Unternehmer:in (Auftragnehmer:in) verpflichtet sich zur Herstellung eines bestimmten Werks für den/die Auftraggeber:in (Besteller:in). Hier muss das Endergebnis klar definiert sein („Werk“).



    * Beispiele in der IT: Programmierung einer kompletten Individualsoftware für eine Kundin





    * Dienstvertrag: Schuldner:in verpflichtet sich zur Leistung eines Dienstes an den/die Gläubiger:in. Hierbei steht die Dienstleistung an sich im Vordergrund und nicht das Endergebnis.



    * Beispiele in der IT: Programmierung für einen Kunden auf Basis von Tagessätzen





    * Fernabsatzvertrag: Bei Verträgen, die über Fernkommunikationsmittel (Internet, Telefon usw.) geschlossen werden, haben Verbraucher:innen besondere Rechte, insb. ein Widerrufsrecht.

    * Arbeitsvertrag: Definiert die Rechte und Pflichten von Arbeitgeber:in und Arbeitnehmer:in.



    Vertragsbestandteile

    z.B. Leistungsbeschreibung, Termine/Fristen, fällige Entgelte, Lasten- und Pflichtenheft (insb. bei Softwareerstellung), Konventionalstrafen, Haftung

    Allgemeine Geschäftsbedingungen (AGB)

    Mit AGBs regeln Unternehmen ihre grundsätzliche Vertragsgestaltung, also Inhalte, die für alle Verträge gelten.

    Beispielinhalte:



    * Informationen zum Vertragsschluss (z.B. Telefon, E-Mail), Bestätigungen usw.

    * Zahlungsbedingungen (z.B. Fristen, Zahlungsmöglichkeiten)

    * Eigentumsvorbehalt

    * Lieferungskonditionen und -möglichkeiten

    * übliche Geschäftszeiten

    * Gewährleistung/Garantie

    * Haftung



    Service-Level-Agreement (SLA)

    Ein SLA legt fest,

    • 1 Std. 18 Min.
    Softwarequalität nach ISO 9126 – IT-Berufe-Podcast #183

    Softwarequalität nach ISO 9126 – IT-Berufe-Podcast #183

    Um Softwarequalität nach ISO 9126 geht es in der einhundertdreiundachzigsten Episode des IT-Berufe-Podcasts.



    Inhalt

    Definition von Qualität



    Qualität ist der Grad der Übereinstimmung mit den Anforderungen.



    Da verschiedene Stakeholder unterschiedliche Anforderungen an unser Projekt haben, ist die Qualität recht subjektiv. Alle Stakeholder zu 100% zufrieden zu stellen, wird in einem echten Projekt wohl nicht möglich sein.

    Maßnahmen zur Qualitätssicherung

    Die Softwarequalität kann mit verschiedenen konkreten Maßnahmen während der Entwicklung sichergestellt werden. Diese nicht vollständige Liste enthält einige Maßnahmen, die Prüflinge auch in ihrem eigenen Abschlussprojekt anwenden können.



    * Audits

    * Code Reviews

    * Testmethoden

    * Entwicklungsprozess

    * Dokumentation

    * Statische Codeanalyse

    * Pair Programming

    * Bugtracking

    * Continuous Integration/Delivery/Deployment



    Softwarequalität nach ISO 9126



    * Funktionalität



    * Angemessenheit

    * Interoperabilität

    * Ordnungsmäßigkeit

    * Richtigkeit

    * Sicherheit





    * Änderbarkeit



    * Analysierbarkeit

    * Modifizierbarkeit

    * Testbarkeit

    * Stabilität





    * Übertragbarkeit



    * Anpassbarkeit

    * Austauschbarkeit

    * Installierbarkeit

    * Koexistenz





    * Effizienz



    * Verbrauchsverhalten

    * Zeitverhalten





    * Zuverlässigkeit



    * Fehlertoleranz

    * Reife

    * Wiederherstellbarkeit





    * Benutzbarkeit



    * Attraktivität

    * Bedienbarkeit

    * Erlernbarkeit

    * Verständlichkeit







    Literaturempfehlungen

    Hier gibt es diese Podcast-Episode noch einmal als Video bei YouTube:



    Links



    * Permalink zu dieser Podcast-Episode

    * RSS-Feed des Podcasts

    * Video zur Podcast-Episode bei YouTube

    * ISO/IEC 9126 in der Wikipedia

    • 57 Min.
    Eigenschaften und Unterscheidung von Programmiersprachen – IT-Berufe-Podcast #182

    Eigenschaften und Unterscheidung von Programmiersprachen – IT-Berufe-Podcast #182

    Um Eigenschaften und Unterscheidungsmerkmale von Programmiersprachen geht es in der einhundertzweiundachzigsten Episode des IT-Berufe-Podcasts.



    Inhalt

    Was ist eine Programmiersprache?



    * Programmiersprache: „Eine Programmiersprache ist eine formale Sprache zur Formulierung von Datenstrukturen und Algorithmen, d.h. von Rechenvorschriften, die von einem Computer ausgeführt werden können.“ [Herv. d. Verf.]

    * Bausteine von Algorithmen: Sequenz, Verzweigung (z.B. if, switch, aber auch Pattern Matching), Wiederholung (GOTO, Schleifen, Rekursion)

    * Turing-complete: „[…] die Eigenschaft einer Programmiersprache oder eines anderen logischen Systems, sämtliche Funktionen berechnen zu können, die eine universelle Turingmaschine berechnen kann.“



    Demnach sind keine Programmiersprachen: HTML/XML (Auszeichnungssprache), CSS (Stylesheet-Sprache), SQL (Datenbankabfragesprache).

    Sprache vs. Plattform vs. Ökosystem

    Programmiersprachen bringen meistens „eingebaute“ („native“) Funktionen mit, die direkt in der Syntax der Sprache formuliert werden können:



    * Ein-/Ausgabe-Befehle, um Daten verarbeiten zu können

    * Deklaration von Variablen zum Speichern von Informationen

    * mathematische Funktionen wie Addition, Multiplikation usw.

    * Steueranweisungen für Verzweigung und Wiederholung

    * Möglichkeiten zur Programmunterteilung (z.B. Funktionen, Subprogramme)

    * Einbinden von (externen) Bibliotheken zur Wiederverwendung



    Viele Programmiersprachen bringen außerdem noch eine umfangreiche Bibliothek an vorgefertigten Implementierungen (z.B. in Form von Klassen in objektorientierten Sprachen) mit. Diese Bibliothek ist bei der Einarbeitung in eine neue Sprache meist schwieriger/langwieriger zu lernen als die Syntax. Oftmals teilen sich mehrere Programmiersprachen die Bibliotheken einer gemeinsamen Plattform, z.B. der JVM bei Java und Kotlin bzw. .NET bei C# und Visual Basic.

    Darüber hinaus existiert meist auch noch ein ganzes Ökosystem rund um die Sprache/Plattform:



    * Build-Tools, z.B. Maven, Gradle

    * Dependency-Management, z.B. NPM, RubyGems

    * Test-Frameworks, z.B. JUnit

    * weitere Frameworks und Libraries, z.B. Spring, a href="/java-ee-7-lernzielkontrolle-anwendungsentwickler-podcast-54" title="Java EE 7...

    • 1 Std. 42 Min.
    Stellenangebot: Softwareentwickler (m/w/d) in Vechta – IT-Berufe-Podcast

    Stellenangebot: Softwareentwickler (m/w/d) in Vechta – IT-Berufe-Podcast

    In dieser Sonder-Episode des IT-Berufe-Podcasts geht es um eine Stellenausschreibung als Softwareentwickler:in (m/w/d) bei meinem Arbeitgeber, der ALTE OLDENBURGER Krankenversicherung AG in Vechta.



    Inhalt

    Bei meinem Arbeitgeber, der ALTE OLDENBURGER Krankenversicherung AG aus Vechta, suchen wir zum nächstmöglichen Zeitpunkt Unterstützung im IT-Bereich. Wir schreiben aktuell eine Stelle als Softwareentwickler:in aus. Selbstverständlich sind Bewerbungen von Personen aller Geschlechter erwünscht.

    Kurzübersicht der Stelle



    * Bezeichnung: Softwareentwickler (m/w/d)

    * Art der Anstellung: unbefristete Festanstellung

    * Arbeitsort: ALTE OLDENBURGER Krankenversicherung AG, Alte-Oldenburger-Platz 1, 49377 Vechta

    * Homeoffice: bis zu 60% der wöchentlichen Arbeitszeit können im Homeoffice erbracht werden

    * Beginn: schnellstmöglich

    * Sonderleistungen: Urlaubs- und Weihnachtsgeld (14 Gehälter), Fahrtkostenzuschuss zur Arbeitsstelle, 40 EUR vermögenswirksame Leistungen pro Monat, Firmenfitness, Mitarbeiterrabatte für Versicherungen, betriebliche Altersvorsorge, Kinderbetreuungszuschuss

    * Wöchentliche Arbeitszeit: 38 Stunden im Gleitzeitmodell ohne Kernarbeitszeit (bei einer Vollzeitbeschäftigung)

    * Jährlicher Urlaubsanspruch: 30 Tage

    * zusätzlicher Urlaub: Möglichkeit zur Umwandlung eines Teils des Urlaubsgelds in 5 Tage zusätzlichen Urlaub

    * Weiterbildungsmöglichkeiten: (Duales) Studium (z.B. Wirtschaftsinformatik, technische Informatik), IHK-Weiterbildungen, externe Technologieschulungen, Konferenzbesuche

    * Sonstiges: frisches Obst, kostenlose Kaffeespezialitäten, modern und ergonomisch ausgestattete Arbeitsplätze (überall höhenverstellbare Tische), betriebliche Gesundheitsförderung, eine kostenfreie Rückenmassage pro Monat (außerhalb der Arbeitszeit), ein hervorragendes Betriebsrestaurant mit bezuschussten Speisen, ein Employee-Assistance-Program, viele gemeinsame Aktivitäten wie z.B. Weihnachtsfeier, Betriebsausflug oder Spargelessen



    Technische Highlights der Arbeit bei der AO



    * Moderne IT-Infrastruktur



    * Windows 10 und SUSE Linux

    * Virtualisierung mit Citrix und VMware





    * Moderne Softwareentwicklung



    * Continuous Integration und Deployment

    * Test Driven Development, Unit-Tests, Codeanalyse

    * Java, Jakarta EE, JBoss/Wildfly, Quarkus





    * Fokus auf optimale Kollaboration



    * Code Reviews, Pair Programming, Pull Requests





    * Fokus auf DevOps



    * Gute Zusammenarbeit zwischen Administration und Entwicklung

    * Auf- und Ausbau der Container-Infrastruktur mit Docker und Kubernetes

    * Tools: Gitea, Jenkins, Gradle, Artifactory, SonarQube







    Detailinformationen zur Stelle

    Unter dem folgenden Link kannst du dir alle Details zu der ausgeschriebenen Stelle anschauen und findest auch die notwendigen Daten für deine Bewerbung bei uns.

    Softwareentwickler (m/w/d) für das Outputmanagementsystem und Drittanbieterschnittstellen

    Softwareentwickler (m/w/d) für das Outputmanagementsystem und Drittanbieterschnittstellen

    Wir suchen zum nächstmöglichen Zeitpunkt einen Softwareentwickler (m/w/d) in Festanstellung, der uns bei der Umsetzung von Fachbereichsanforderungen unterstützt und Systeme weiterentwickelt und optimiert. Deine Schwerpunkte liegen auf der Java-Plattform...

    • 18 Min.

Kundenrezensionen

5,0 von 5
145 Bewertungen

145 Bewertungen

eviprinzessin9 ,

Mega hilfreich

Sehr informativ und sehr locker formuliert, wodurch man sich die Inhalte auch gut merken kann; manchmal gibt es sehr viel Randinformationen, aber wirklich sehr hilfreich

Jackjack2001 ,

Jack

Der Podcast ist sehr Hilfreich bei meiner Umschulung.

Gibt es irgendwann nochmal Folgen über die Firewall & Linux?

Netterkerl1981 ,

Toller Podcast für alle, die mit der Ausbildung in IT-Berufen zu tun haben

Ein toller Podcast. Auch als Ausbilder sehr zu empfehlen, um eine ordentliche Ausbildung zu ermöglichen. Ich konnte vieles lernen. Danke dafür.

Top‑Podcasts in Technologie

Lex Fridman Podcast
Lex Fridman
Freak Show
Metaebene Personal Media - Tim Pritlove
c’t uplink - der IT-Podcast aus Nerdistan
c’t Magazin
Apfelfunk
Malte Kirchner & Jean-Claude Frick
KREWKAST
Felix Bahlinger, Julian Völzke
Computer und Kommunikation - Sendung
Deutschlandfunk

Das gefällt dir vielleicht auch

Quarks
Westdeutscher Rundfunk
Hotel Matze
Matze Hielscher & Mit Vergnügen
Aha! Zehn Minuten Alltags-Wissen
WELT
LANZ & PRECHT
ZDF, Markus Lanz & Richard David Precht
Smarter leben
DER SPIEGEL
Kalk & Welk - Die fabelhaften Boomer Boys
radioeins (rbb)