Produktivität

Skillbyte Podcast #48: Grundkenntnisse und Skills für ALLE IT-Fachkräfte

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Grundkenntnisse und Skills für ALLE IT-Fachkräfte

// Inhalt //
01:29 – Was euch die Hochschule NICHT beibringt…

02:59 – Themenkomplex: Datenhaltung und -verwaltung
03:34 – SQL – Structured Query Language bei relationalen Datenbanken
05:53 – NoSQL – Not only SQL bei schemafreien Datenbanken
07:02 – Hashtabelle / HashMap
08:23 – häufige Datenvormate: JSON, YAML, CSV
10:37 – Zusammenfassung: Datenhaltung und -verwaltung

10:49 – Themenkomplex: Netze und Protokolle
11:13 – IP Adressen und -netze, Ports, NAT, Router, Gateway, TCP/UDP, Routing, Datenpakete, Firewalls
14:20 – HTTP Protokoll inkl. Status Codes und Zertifikaten für HTTPS
15:19 – REST APIs

16:13 – Themenkomplex: Systeme und Plattformen
16:25 – Linux, Kommandozeile / CLI (Bash), vi, nano, SSH, scp
18:46 – Docker, virtuelle Maschinen
19:35 – Cloud computing, Dienste und Orchestrierung dieser
21:06 – Cloud Native Software Development

23:00 – Themenkomplex: Arbeit mit Sourcode
23:09 – Code Versioning: GIT (branching, merging, rebasing), github.com, gitlab.com
25:17 – Integration von CI/CD Pipelines, GitHub Actions, Gitlab CI/CD (gitlab-ci-yml)

26:14 – Themenkomplex: Debugging
26:19 – Logdateien lesen
27:48 – Debugger konfigurieren und einsetzen

30:06 – Themenkomplex: Produktivität & Zielorientierung

32:45 – Zusammenfassung aller Themengebiete
34:21 – Podcastempfehlungen zur Vertiefung

// Weiterführende Episoden je nach Schwerpunkt //

Podcast #9: Bull’s Eye Software Development – Einfach und fokussiert auf Unternehmensziele
https://soundcloud.com/skillbyte/podcast-9-bulls-eye-software-development-einfach-und-fokussiert-auf-
unternehmensziele

Podcast #8: Must-have Skills, Technologien und Weiterbildung für DevOps
https://soundcloud.com/skillbyte/podcast-8-must-have-skills-technologien-und-weiterbildung-fur-devops

Podcast #7: Must-have Skills, Technologien und Weiterbildung für Data Engineers und Data Scientists
https://soundcloud.com/skillbyte/skillbyte-podcast-7-must-have-skills-technologien-und-weiterbildung-
3fur-data-engineers-und-data-scientists

Podcast #6: Must-have Skills, Technologien und Weiterbildung für Full-Stack Entwickler
https://soundcloud.com/skillbyte/skillbyte-podcast-6-must-have-skills-technologien-und-weiterbildung-
fur-full-stack-entwickler

Podcast #29: Die Zwölf Faktoren des Cloud Native Development (Teil 1)
https://soundcloud.com/skillbyte/podcast-29-die-zwolf-faktoren-des-cloud-native-development-teil-1

Podcast #30: Die Zwölf Faktoren des Cloud Native Development (Teil 2)
https://soundcloud.com/skillbyte/podcast-30-die-zwolf-faktoren-des-cloud-native-development-teil-2

// Weiterführende Blogposts mit mehr Informationen //

Tutorial: IT-Basiswissen für DevOps, Big Data, Developer
https://www.skillbyte.de/tutorial-it-basiswissen-fuer-devops-big-data-developer/

Onboarding neuer IT-Mitarbeiter (DevOps, Big Data, Developer)
https://www.skillbyte.de/onboarding-neuer-it-mitarbeiter-devops-big-data-developer/

Must-have Ressourcen, Skills und Techniken für Data Engineers und Data Scientists
https://www.skillbyte.de/must-have-ressourcen-skills-und-techniken-fuer-data-engineers-und-data-scientists/

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Okay, ich habe jetzt meine Hochschule oder meine Ausbildung abgeschlossen. Was wird denn jetzt tatsächlich von Firmen im Alltag gefordert? Diese Skills werden oft an den Unis vernachlässigt, sind aber ganz relevant für den Berufsalltag, für die Berufspraxis. Wenn ihr mit Kollegen zusammenarbeitet.

Herzlich Willkommen zur Gewalt Podcast Episode Nr. Achtundvierzig Grundkenntnisse und Skills für alle IT-Fachkräfte Abonniert unseren Podcast für mehr spannende Themen aus dem Technologie Umfeld, wenn er IT Entscheider oder die Fachkraft seid. Wenn ihr eine Frage habt, sendet uns gerne eine E-Mail an Podcast Amtsgewalt D Wir freuen uns immer über Bewertungen und ganz besonders an Weiterempfehlung dieses Podcasts, an Freunde und Kollegen, die sich ebenfalls für diese Themen interessieren. Das ist uns ganz wichtig.

Und heute möchte ich darüber sprechen, welche Grundkenntnisse und Grundfähigkeiten denn für alle IT-Fachkräfte wichtig sind. Gerade wenn ihr vor dem Berufseinstieg steht und euch fragt Okay, ich habe jetzt meine Hochschule oder meine Ausbildung abgeschlossen, was wird denn jetzt tatsächlich von Firmen im Alltag gefordert? Und hier ist mir ganz wichtig, dass ich Themen anspreche, diese Wohlfühl Softwareentwickler, Admins, DevOps, Data Engineers von Belang sind und die für alle diese Berufsgruppen wichtig sind. Diese Skills werden oft an den Unis vernachlässigt, sind aber ganz relevant für den Berufsalltag, für die Berufspraxis.

Wenn ihr mit Kollegen zusammenarbeitet und häufig ist es so, dass das so Grundfähigkeiten sind, die euch dann auch niemand mehr so richtig erklären möchte, weil das einfach so ein Brot und Butter Geschäft ist, dass ihr das am besten dann zuhause nachliest oder die Kollegen schon mit den Augenrollen, wenn so eine Frage gestellt wird. Davor möchte ich euch bewahren und einfach ein paar Denkanstöße geben, paar Themen geben, die ja durcharbeiten könnt, wo ihr euch mit beschäftigen könnt und dann voll in den Berufseinstieg glänzen könnt und dadurch starten könnt.

Was befähigt mich dazu? Ich bin seit über 16 Jahren Softwareentwickler und seit über acht Jahren in der IT Beratung tätig, habe also schon viele Unternehmen gesehen und viele Projekte durchgeführt und habe dadurch einen breiten Erfahrungsschatz aufgebaut und sehe dann immer das neue Ankömmlinge Junior Entwickler Junior Dev Orbs Junior Atmens oft die gleichen Fragen haben, die mit einer Woche oder zwei Wochen Vorbereitung zu klären wären und wo man dann einen viel besseren Einstieg ins Berufsleben finden würde. Also vielleicht wenn ihr Einsteiger seid, sendet ihr euren Kommilitonen auch diese Podcast Episode und macht es euch sehr viel einfacher direkt erfolgreich ins Berufsleben einzusteigen.

Ich freue mich auf jeden Fall und wenn ihr Fragen habt. Wie eingangs erwähnt, schick mir gerne eine E-Mail, wenn ich ein Thema vergessen habe. Eurer Meinung nach sendet meine E-Mail an Podcast beide Punkte. Das erste Thema, wobei ich heute sprechen möchte, beschäftigt sich mit der Datenhaltung und Verwaltung. Ihr könnt euch ein Computersystem so vorstellen, dass es sich im Grunde um einen Datentyp handelt oder um mehrere Daten Zöpfe, um die drumherum Code gebaut wird. Also Decode nimmt die Daten, die in einer Eingangs Struktur vorliegen.

Das kann ein Bild sein und konvertiert diese Daten in ein anderes Format, ein Video, ein Bilder, Album usw.. Also im Grunde ist es immer so ihr habt Daten und der Computer Code macht etwas mit diesen Daten, transformiert diese Daten und gerade wenn es um das Thema Datenhaltung geht auch heute noch spielen relationale Datenbanken. Das sind Datenbanken wie Maria DB, My, SQL PostgreSQL, auch Oracle oder MS SQL eine große Rolle. Und alle diese Datenbanken werden über die STANDARD Abfrage Sprache SQL abgefragt.

Und egal in welchen Projekten, dieser SQL STANDARD wird euch immer wieder über den Weg laufen. Das ist auf jeden Fall eine Fähigkeit, die ihr brauchen werdet. In eurem Berufsalltag und die an der mannigfaltigen Stellen einsetzbar ist, ist es sogar so, dass neue Technologien, die hinzukommen z.B. wenn man an die Haddock Daten Platform denkt, die es jetzt auch gar nicht mehr so neu. Dann werden Werkzeuge extra so konzipiert, dass sie auf den vorhandenen SQL Standards aufsetzen können.

Also dass man mit der SQL Sprache, die sehr viele Entwickler bereits können, dann eben auch neue Anwendungsfälle abdecken kann. Also SQL absolut wichtig, um ein paar Beispiele zu geben. Ein paar Select Abfragen auf Tabellen Jeunes sind ganz wichtig. B. Jeune ich Daten zwischen zwei Tabellen Was ist eine Relation? Relation ist im Grunde genommen eine Tabelle. Was ist ein Primärschlüssel? Wie setze ich in die CS? Was für Vorteile haben in die CS? Welche Nachteile haben sie?

Schaut euch mal ihr Diagramme an. Also Entity Relationship Diagramme. Die habt ihr wahrscheinlich im Studium schon gesehen. Die werden auch in der Praxis eingesetzt und letztlich bilden die einfach nur Datenbank Schemas ab. Also an der Stelle nochmal wichtig die SQL Abfrage Sprache ist super wichtig. Schaut euch das an. Macht einfache Kluth abfragen also create read update Lettner fügt was ein, selektiert Ergebnisse, löscht meine Zeile. Update Meine Zeile so als Fingerübung. Da seid ihr auf jeden Fall schon mal gut gewappnet, weil SQL wird ihn mit an Sicherheit grenzender Wahrscheinlichkeit in eurem Berufsleben wieder auftreten.

Hier noch als Erweiterung. Die optionales Wenn ihr das Thema vertiefen wollt, könnt ihr euch auch Objekt relationale Mapper anschauen, sogenannte Ockhams. Hier geht es darum. Programmiersprachen sind häufig objektorientierte und ihr arbeitet mit Objekten. Daten werden aber immer, wenn sie in relationalen Datenbanken liegen, auf Tabellen abgebildet. Das heißt, es sind im Grunde zwei Welten und diese Object relationalen Mapper verbinden diese beiden Welten ist nicht unbedingt Voraussetzung, aber als Erweiterung. Wenn euch das Thema interessiert, würde ich das empfehlen, mal anzuschauen.

Kommt auch sehr häufig vor. Wir befinden uns immer noch in dem Blog Datenhaltung und Verwaltung. Und das zweite Thema, was sehr wichtig ist und was euch im Berufsleben auf jeden Fall über den Weg laufen wird, sind die sogenannten No ASCII Datenbanken wie beispielsweise Mongo DB, No SQL steht hier aber nicht für kein SQL, sondern für Not only SQL und es handelt sich um so genannte Schema freie Datenbanken. Was bedeutet das? Bei den relationalen Datenbanken haben wir schon festgestellt Es gibt Tabellen.

Diese Tabellen haben ein festes Format und alle Daten müssen in diese Tabellen hineinpassen. Bei den Schema freien Datenbanken ist das nicht der Fall. Da könnt euch vorstellen einen Such Index wird häufig mit Schema freien Datenbanken abgebildet und mit Dokumenten, die sich nach und nach erweitern. Also wenn man z.B. ein Dokument hat, das nennt sich Person, dann hat die Person vielleicht Vorname Nachname. Irgendwann kommt ein Führerschein hinzu, irgendwann kommt ein Schulabschluss hinzu, irgendwann heiratet die Person vielleicht und es kommt mir ein Link zu einer anderen Person hinzu.

Und das weiß man vorher alles nicht. Deshalb können die Dokumente in der Datenbank Personen nach und nach erweitert werden. Ohne Schema. Also SQL haben wir, No SQL haben wir, da gehen wir gleich noch genauer drauf ein. Ein weiterer Punkt zur Datenhaltung und Verwaltung, der euch auf jeden Fall begegnen wird, ist die sogenannte Hascht Tabelle oder auf Englisch Hash Map. Schaut euch bitte an, wie funktioniert eine Hash Map? Was für Vorteile habe ich bei der Hash Map?

Was? Eine Hash Map ist einfach eine Datenstruktur, die einen Schlüssel zu einem Wert abbildet. Im Grunde genommen könnt ihr euch vorstellen, ein Schlüssel muss eineindeutig sein wie eine Telefonnummer und der Wert könnte z.B. die Person sein, die hinter der Telefonnummer steckt. Wenn ich jetzt einen neuen Wert mit der gleichen Telefonnummer einfüge in diese Hash Tabelle, dann fällt der alte Wert raus und die neue Referenz. Also sagen wir mal die gleiche Telefonnummer gehört jetzt einer neuen Person, wird dann dort gespeichert.

Der Vorteil von einer hascht Tabelle ist, dass ein sehr schneller Zugriff ermöglicht werden kann, wenn man den Key errät. Wenn man die Telefonnummer weiß, kann man sofort den Namen der Person nachgucken in der O Notation, während er die Zugriffs Zeit würde sich als O von 1 darstellen, was der beste Fall ist und die Hash Tabelle läuft euch sehr sehr häufig über den Weg. Diese Datenstruktur beim Thema Caching, wenn ihr schnellen Zugriff auf Elemente benötigt bei Key Value Stores.

Ein unbekanntes Produkt aus diesem Bereich wäre z.B. Readers. Also schaut euch wirklich an, was ist eine Hash Tabelle? Wie funktioniert die? Gibt’s in allen Programmiersprachen. Macht euch mit dem Konzept vertraut. Das ist ganz wichtig. Als letzten Punkt bei Datenhaltung und Verwaltung möchte ich auf häufige Datenformate eingehen. Also ein häufiges Datenformat ist z.B. Jason Java Skript, Objekt Notation. Das habt ihr bestimmt schon mal gesehen. Das sind einfach abgerollt. Schlüssel, Werte, Kombinationen. Wenn man so möchte, also sucht nach Jason Fall, dann sieht er sofort, was ich meine.

Dieses Dateiformat kommt sehr sehr häufig vor. Und das wird zum Brot und Butter Geschäft während eurer täglichen Arbeitszeit werden bin ich ganz sicher. Ist auch sehr ähnlich beim Zugriff auf Novell SQL Datenbanken. Werdet die Abfragen an diese Datenbanken stellen. Da kommen dann Jason Dokumente zurück, also Jason Objekte zurück, wenn ihr auf irgendwelche Rest APIs zugreift. Da kommen wir gleich noch zu. Wird ebenfalls wie mit Jason Objekten gearbeitet und also an Datenformat. Jason kommt da nicht vorbei.

Wenn ihr nicht wisst was das ist. Schaut es euch an. Macht euch damit vertraut und es ist sehr, sehr wichtig. Ein zweites Datenformat, insbesondere für Konfigurationsdateien ist das sogenannte Jamel Dateiformate.

Jamel und Jason sind austauschbar. Also man kann Jason Datei als Jamil Datei schreiben und eine Jamel Datei als Jason Datei ist ein bisschen der Geschmacksfrage. Jason Dateien werden häufig zur Verwendung von Daten zum Austausch von Daten Objekten verwendet. Jamil Dateien sind oft Konfigurationsdateien, also Latin oder Markup. Länge ist die geschriebene Abkürzung und die neuen Technologien nutzen alle diese Sprache zur Konfiguration. Ein drittes sehr häufig anzutreffen das Dateiformat ist das sogenannte CSV Dateiformat. Häufig liegen Daten Exporte in dem CSV &comma.

Seppl rated beliefs vor. Das könnt euch so vorstellen, dass im Grunde einfach eine Tabelle abgerollt wird und alle Daten mit Kommas getrennt hintereinander geschrieben werden. Und das ermöglicht es auch Systemen, die keine Kenntnis voneinander haben, mit diesen Daten zu arbeiten. Also irgendein System, was mal erstellt wurde, kann Daten in CSV exportieren, z.B. eine Telefonrechnungen und ein anderes System. Was? Einige Jahre später erst danach erzeugt wurde, kann man diese Daten eben wieder einladen. Weil sich beide sind CSV STANDARD halten.

Das wären meine 4 Tipps zum Thema Datenhaltung und Verwaltung. Ich fasse nochmal zusammen SQL Abfrage Sprache superwichtig Der Umgang mit No SQL Datenbanken ist sehr wichtig. Die Funktionsweise einer hascht Tabelle sollte dir kennen und die geläufigsten Datenformate. Mit denen sollte dir auch was anfangen können. Okay, nach Datenhaltung UN-Verwaltung kommen wir jetzt zu dem Block Netze und Protokolle. Das wird einige von euch langweilen, andere von euch, wenn ihr großen Nachholbedarf haben. Das stelle ich immer wieder fest.

Und zwar geht es um nichts weniger als das Verständnis, wie das Internet funktioniert oder spezieller wie TCP IP Netzwerke funktionieren. Was ist eine IP-Adresse? Also ganz genau. Was ist das? Was ist eine IP V4 Adresse? Was ist eine IP V6 Adresse? Warum ist diese Adresse wichtig? Was bezeichnet diese Adresse? Ist diese Adresse änderbar? Wer teilt diese Adressen zu? Wer verwaltet diese Adressen? DHCP In diesem Kontext ist auch wichtig. Alles Stichworte, die er nachgucken könnt und die wichtig sind Ports.

Was ist ein Port? Von einem Service, der auf meinem Rechner läuft. Wie viele Ports gibt es? Welche Ports sind bereits belegt? Gibt Welche Konventionen existieren zu Ports? Hier insbesondere Ports unterhalb der Nummer 1024 dürfen eigentlich nur von Services verwendet werden. Die erhöhte Rechte haben und so weiter und so fort. Das sollte durch angucken gerne auch Wikipedia bietet exzellente Dokumentation zum Thema IP Netze an. Schaut euch das an! Also was sind IP Adressen? Was hat es mit den Ports auf sich?

Was ist ein Router bzw ein Gateway? Ein Router bootet innerhalb von Netzen. Ein Gateway verbindet zwei Netze. Wir sagen zwar im Sprachgebrauch häufig DSL Router, aber streng genommen ist es ein DSL Gateway, denn es verbindet das private Heim Netz mit dem Internet. Was bedeutet Network Address Translation kommt so häufig vor in Kunden Projekten. Bei Network Address Translation geht es einfach darum, dass die IP-Adresse im Internet, die euer Gateway im Internet hat, auf eure lokalen Geräte zuhause beispielsweise abgebildet werden muss.

Das heißt, euer Handy, euer PC, eurer Spielkonsole, euer Fernseher. Die haben alle die gleiche IP V4 Adresse im Internet. Aber trotzdem muss natürlich das Gateway Player DSL Gateway entscheiden. Wo schicke ich denn welche Daten hin und muss die Geräte auseinanderhalten? Wie funktioniert das genau? Ein weiteres Stichwort hier wäre Port vor Wording. Das solltet ihr auch wissen. An das habt ihr aber wahrscheinlich im Studium gelernt. TCP und UDP was ist der Unterschied zwischen TCP Verbindungen und UDP Verbindungen?

Ganz einfach kann man sagen bei TCP Verbindungen fallen Verbindungs Fehler auf und werden behoben. Also verlorene Datenpakete werden an Nacht gesendet. Bei UDP ist das nicht der Fall. Dafür ist UDP schlanker und hat weniger Management Overhead, was die Paket Verwaltung angeht. Das ist manchmal von Vorteil, wenn man einfach möglichst hohe Datenrate erzielen möchte oder wenn verlorene Pakete nicht wichtig sind z.B. bei Skype Verbindung. Wenn da ein Wort fehlt, dann nützt das nichts, das wenige Sekunden nach und später nach zu senden, sondern dann lässt man Safa weg und macht weiter.

Generell Wie funktioniert Routing? Was sind Datenpakete? Wie funktionieren Firewalls? Das ist Grundlagenwissen, aber immer wichtig in Firmen, weil Unternehmen oft sehr komplexe Systeme im Einsatz haben, die eben mit dem Netz verbunden sind. Und oftmals, wenn es Probleme gibt, liegt das an Komponenten in dem Netz, die eben diese Einzelkomponenten verbinden. Und wenn man nicht versteht, wie Alpines zu funktionieren, dann kann man den Fehler nicht entdecken und beheben. Es ist der einfache Grund.

Der zweite Punkt bei Netzen und Protokollen. Neben der Funktionsweise des Internets sein grundlegendes Verständnis des http Protokolls. Also was gibt es für Methoden geth post put die z.B.. Und was gibt es für http status codes? Viele kennen bestimmt den Status Code 404. Das ist wenden eine Ressource eine Webseite in dem Fall nicht gefunden wurde. Gibt auch den Status Quo 200, wenn der Request erfolgreich verarbeitet wurde. Es gibt noch viele, viele weitere Status Codes, die alle eine andere semantische Bedeutung haben.

Da sollte man sich mal die Tabelle anschauen, um einfach einen Überblick zu bekommen, was es alles gibt. Die muss man nicht auswendig können, aber man muss z.B. Klassen von Status Code sollte man wissen. Also die fünf Hunderter Codes bezeichnen Server Fehler als bei vier Hunderter Codes ist häufig eine Ressource einfach nicht gefunden worden. Bei 200 Codes ist der Request erfolgreich durchgeführt worden. Aber es gibt halt verschiedene Rückmeldungen, dass man einfach diese Klassen kennt. Das ist sehr wichtig und hochgradig Praxis irrelevant.

Ein dritter Punkt bei Netzen und Protokollen, der sehr wichtig und in den letzten Jahren noch an Wichtigkeit. Sind die sogenannten Rest APIs als Schnittstelle zwischen Microservices oder zwischen zwei Systemen, die miteinander sprechen, meistens über Jason? Geht es darum, System A ruft z.B. bei System B ein Login auf, System B sendet System A zurück. Okay, erfolgreich eingeloggt. Daraufhin kann System A System B sagen wieder ein Request schicken. Ok. Dann bitte möchte ich die und die Daten abrufen.

Dann weiß System B anhand von Informationen, die gesendet werden. System AS autorisiert und kann dann die entsprechenden Informationen zurück liefern. Immer wenn ihr euch irgendwo auf einer Website einloggt, wird im Hintergrund genau dieser Datenaustausch durchgeführt. Also Rest APIs in Verbindung mit dem HTTP Protokoll und der Funktionsweise des Internets. Also es sind absolute Basis Baustein und die braucht ihr mit Sicherheit grenzender Wahrscheinlichkeit auf jeden Fall in meinem Berufsleben. Kommen wir nach der Datenhaltung und Verwaltung über das Thema Netze und Protokolle.

Nun zum dritten Thema Systeme und Plattformen. Hier ist es wichtig zu wissen, wie das System Linux aufgebaut ist. Linux wird nach wie vor auf den meisten Servern eingesetzt. Auch die ganz Docke isierung und die ganzen Cloud Umgebungen basieren zum größten Teil auf Linux und sehr, sehr häufig. Wenn ihr Software entwickelt, die irgendwo ausgerollt werden soll, passiert das auf Linux Systemen. Und da sollte dir einfach ein grundlegendes Verständnis davon haben, wie das System aufgebaut ist. Da gibt es tolle Youtube-Videos zu, die das in der Kürze erklären.

Also was ist der Kernel, was ist der User Space? Was sind die häufigsten Verzeichnisse bei einer Linux Installation oder auch im Docker Container? Ist es oft so ähnlich? Was sind Konfigurationsdateien also häufig unter Slash etc., die wichtig sind, wo ich dein Haus eintragen kann oder irgendwelche anderen Systemeinstellungen verändern kann? Das lohnt sich immer. Also generell Linux System Aufbau verstehen und die häufigsten Verzeichnisse kennen. Das führt mich direkt zum nächsten Punkt dem Umgang mit der Linux Kommandozeile.

Ob das jetzt das Basch Terminal ist oder TCS h WGT, da Entwickler durch seine eigene Vorliebe. Es ist aber wichtig hier, dass ihr euch für einen Terminal entscheidet, dass ihr das so konfiguriert, dass er damit auch umgehen könnt und euch dann eben auf der Kommandozeile wegen könnt. Ob das jetzt Linux ist oder MacOS, das ist erst mal nicht so wichtig, aber dass ihr in Verzeichnissen navigieren könnt. Also mit CD in ein Verzeichnis reinspringen oder wieder rausspringen, das Sie mit lässt euch das Verzeichnis Inhalt anzeigen lassen können, dass ihr Dateien editieren könnt entweder mit den Editoren wie ein Nano oder euer Lieblings Editor, dass ihr per 6h auf einen Server zugreifen könnt.

CH Leerzeichen Server Namen entspringt er auf den Host, dass ihr z.B. mit SCP Daten zwischen Servern hin und her kopieren könnt oder von einem Server auf eurem Rechner kopieren könnt. Das wird häufig benutzt bei Log Dateien. Wenn man da etwas nachschauen möchte, das man erstmal vom Server auf den eigenen Rechner kopiert, dass man Dienste stoppen kann und neustarten kann und dass man sich einfach sicher auf der Kommandozeile bewegt. Das ist sehr, sehr sehr wichtig und das ist absolutes Grundlagenwissen.

Hab ich häufiger schon in meinem berufst Kontext gesehen, dass das nicht beherrscht wurde. Und dann entsteht im Team sehr, sehr oft Frustration, weil das eine Grundkenntnisse ist, die vorausgesetzt wird. Also wer mit dem System Ausbau von Linux besprochen und die Navigation auf Linux Kommandozeile auch die Verwendung von Docker und virtuellen Maschinen wie VirtualBox sind sehr, sehr wichtig zu wissen, wie man damit umgeht, weil die Entwicklung doch mehr und mehr in Docker Containern vollzogen wird oder auch in virtuellen Maschinen statt auf der eigenen lokalen Hardware.

Das hat einfach den Vorteil, dass man, wenn man einen Docker Container baut oder Diplomat, dass er sich überall gleich verhält und man nicht mehr das Problem hat, dass eine Software auf dem lokalen Rechner anders funktioniert als dann später in der Produktion auf dem Server, weil man das vermeiden möchte. Also schaut euch an, wie Docker funktioniert, wie man Docker Container runterlädt, wie das langjÃhrigen der Falz Systeme der Docker Images funktioniert und wie der Docker Dienst generell funktioniert auf der Linux Infrastruktur.

Ich denke ah es ist sehr interessant und b ist es auch hochgradig Praxis relevant. Ein weiterer Punkt bei System und Plattform ist natürlich, dass in den letzten Jahren immer stärker in den Vordergrund tretende Cloud-Computing auf der einen Seite versus der On Priamos Rechenzentren, die auf der anderen Seite noch laufen bei vielen Unternehmen und ich denke, es wird dahin gehen, dass bis auf sehr, sehr wenige Ausnahmen fast alle Anwendungen in der Cloud betrieben werden. Heute sind wir in einem Zwischenzustand, dass noch viele alte Anwendungen, die seit Jahren bestehen, im eigenen Rechenzentrum laufen und nicht in die Cloud wandern.

Aber Anwendungen, die neu entwickelt werden eben schon auf der Cloud Infrastruktur angelegt werden. Und da muss man sich dann einfach auskennen. Also auch mit der Terminologie Wie heißt eine virtuelle Maschine in der Amazon Cloud oder in der Cloud oder in der Google Cloud, je nachdem, welchen Cloud Provider man da verwendet?

Da ist es auch wieder wichtig. Ich die Netze und Protokolle zu verstehen. Wie können die Maschinen untereinander kommunizieren? Welche Cloud Tools gibt es? Wie heißt jetzt zum Beispiel DNS namens Auflösung jetzt bei dem Cloud Provider und so weiter und so fort. Also hier am besten wie kommt ihr da rein? Die meisten Club Weida bieten ja so ein Free Plan an, dass man sich da einfach anmelden kann und dann eine einfache Website auf diesem Cloud Host installieren. Ich glaube, da kann man sehr schnell Erfolge erzielen und sich sehr schnell in diese Infrastruktur als Dienst oder Infrastruktur as a Service Umgebungen einarbeiten.

Oft ist es auch so, dass Unternehmen schon eine Cloud Infrastruktur hab und wir die nicht von Null aufbauen müssen, sondern eben erweitert. Aber da muss man sich dann auch auskennen, welche Werkzeuge es da alles gibt. Wenn man schon bei Cloud Computing ist, muss man auch meiner Ansicht nach das Cloud Native Software Bell abmahnt ansprechen. Da haben wir bei Skill BYD 2 Podcast Episoden zu gemacht, die Episode Nummer neun und zwanzig und dreißig. Denn Anwendungs Software, die für Cloud Umgebungen entwickelt wird, die wird etwas anders entwickelt als man das vielleicht bei Legacy Anwendungen früher gemacht hat, wo alles auf einem Server ausgeführt wurde.

Heute ist es so, dass das Thema State zentral gehalten wird, dann Cloud Datenbanken oder Cloud Now, SQL Datenbanken und die Microservices drumherum. Diese Daten transformieren sehr schön. Da sind wir wieder bei dem Bild, was ich eingangs gezeichnet habe, dass man im Grunde sich einen Computer Computersystem als Datentyp vorstellen kann mit Code drumherum. Genauso ist es in der Cloud auch. Aber es gibt ja ein paar Besonderheiten, auf die man achten sollte bei der Anwendungsentwicklung, die eben unter Cloud Native Development zusammengefasst sind, damit man auch alle Vorteile der Cloud nutzen kann.

Also damit man so super breit skalieren kann, damit man sich Maschinenhaus fahren kann und im Grunde eine Milliarde User App frühstücken kann, muss man die Anwendungen in einer bestimmten Art und Weise entwickeln. Und das ist das Cloud Native Development, würd ich auch sagen. Schaut euch das mal an, müsste euch nicht so tief anschauen, aber ist auf jeden Fall wichtig. Und in dem Zuge Cloud Entwicklung macht euch mit so Schlagwörtern vertraut wie CDN konnte Delivery Network Was bedeutet AWS?

Was bedeutet CCP? Was bedeutet esgab? Wie gehe ich mit der neuen Infrastruktur aus der Cloud um statt echter Hardware im Server? Vielleicht steigt er auch direkt auf Cloud Services ein und kennt gar nicht mehr echte Server. Das ist auch okay, aber der Umgang mit den Cloud Diensten, das halte ich für sehr, sehr wichtig und hochgradig Praxisräume und auf jeden Fall. Und auch die meisten Cloud-Anbieter bieten Kommandozeile Tools. Als wenn man sich auf der Kommandozeile bewegen kann, kann man auch die Tools der Cloud-Anbieter verwenden.

Nach System und Plattform wäre der vierte Punkt von mir nun das Arbeiten mit Source Code. Wie geht man damit um? Und hier ist ein ganz, ganz grundlegendes System, was man auf jeden Fall beherrschen sollte und sich anschauen sollte. Das Git Code Version im System von Linus Torvalds himself, gegründet vor einem Jahr. Was heißt ersetz? Installiert euch Git schaut an, wie man einen Branch macht, wie man Branches wieder merkt, wie Rhee Basinger funktioniert, welche Vorgehensweise es gibt, Feature Entwicklung auf sogenannten Branches durchzuführen.

Dann, wenn das Feature entwickelt ist, muss der Branche wieder in den Master Branch zurückgemeldet werden. Da gibt es verschiedene Vorgehensweisen. Also ich sage nicht, dass man sich das alles anschauen muss, aber man muss Git so benutzen können, dass man Code einchecken kann, Code Versionierung kann, die geläufigsten Kommandos kennt, also mit blame schaut wer hat diese Code Datei geschrieben und wen kann ich da fragen z.b. Und wo kommt diese Änderung her, dass man einen Branch ziehen kann, dass man ein Branch wieder marjan kann?

Das ist super wichtig und habt ihr vielleicht schon im Studium benutzt. Wenn nicht, schaut euch bei Jude Ami oder bei YouTube an Git Kurs an, der euch die Basics vermittelt und wirklich die Basics Bronchien Marching Rebalancing. Damit seid ihr schon gut aufgestellt. Da gibt es noch sehr fortgeschrittene Themen, die wenn euer Unternehmen das einsetzt, werden sie euch das zeigen. Aber zumindest die Basis Sachen solltet ihr kennen, um damit umzugehen, dass es immer wieder ein Knackpunkt.

Und da solltet ihr zumindest Grunderfahrungen haben, um da nicht direkt anzuecken bei eurer neuen Stelle. Wenn ihr wollt, macht euch ein Account bei GitHub und komm oder Güttler Punkt kommen. Erstellt euch dort euer eigenes Repository zum Ladet mal Dateien hoch, ladet das runter. Fragt einen Freund, die Dateien zu ändern und die wieder hochzuladen, sodass er euch einfach. Ja, vielleicht nutzt er im Studium schon vor eurer Abschlussarbeit oder irgendein Text. Könnt ihr mal Git benutzen, um gemeinsam an einem Werk zu arbeiten und dann kriegt er schon Erfahrung, was für Probleme es gibt und was auch Git leistet.

Und das ist sehr sehr wichtig. Es gibt noch andere Wirsching Systeme außer Git z.B. SVR oder CVS, aber Git hat im Grunde genommen alle verdrängt. Und wenn ihr Git verstanden habt, dann könnt ihr auch mit allen anderen umgehen. Deshalb halte ich es für das Allerwichtigste. Ein weiterer Punkt Wenn ihr das Codewort Oenning mit Git beherrscht, ist die Integration von Kaikki. Die Pipeline, also Continuous Integration Continuous Delivery haben nämlich meistens in Unternehmen hört man ja nicht auf, wenn man denkt Sourcecode eingecheckt hat, sondern jetzt muss der Source Code ja in ein Programm überführt werden oder in einen Container überführt werden.

Und dieser Container wird dann ausgerollt auf dem Testsystem, auf dem Produktionssystem, je nachdem, was man gerade macht. Da gibt es bei GitHub die sogenannten GitHub Actions, die es machen können. Bei Gelabt gibt es die Key ICD Pipeline über die Gitter i-Punkt Jamel Datei lässt sich das steuern. Also schaut euch die Integration dieser Sie als Hedy Pipelines an ist ein etwas fortgeschrittenes Thema, wird aber auch hochgradig Praxis relevant. Hab ich in jedem Projekt bisher gehabt. Was man da zumindest verstehen muss.

Was da vor sich geht und gegebenenfalls auch Anpassungen durchführen können muss, würde ich empfehlen, sich auf jeden Fall da mal ein Youtube-Video zu anzugucken. Okay. Soviel zur Arbeit mit Sourcecode. Mein fünfter Punkt, der absolut wichtig ist, heißt Debugging. Womit die Bar gegen meine ich erstmal, dass ihr Log falls lesen könnt Dienste Linux Dienste System Dienste auch Windows System Dienste schreiben Ereignisse in Log Dateien Diese Log Dateien sind die erste Anlaufstelle, wenn es zu Fehlern kommt, wenn es zu Problemen kommt, wenn man irgendwie schauen muss, wie verhält sich der Dienst.

Und das ist tägliches Brot und Butter Geschäft, das man in Lokführers schauen kann. Also entweder springt man auf der Kommandozeile per Asha direkt auf die Maschine oder in den Docker Container und betrachtet dann eben die Lock falls mit den gebräuchlichen Editoren wie wie nano less more. Dies sind keine Editoren, aber Betrachter um dann die Log Dateien anzeigen zu können. Ihr könnt jeden Editor benutzen, der für euch passt. Wichtig ist, dass ihr wisst, wo sind Lokführers zu finden unter war oder jeweils an der konfigurierten Stelle im Container und dass ihr dort reinschauen könnt.

Superwichtig gibt auch so Log Aggregation Dienste wie e.K. Zum Beispiel oder Cubaner die Log Falls sammeln gerade in verteilten Umgebungen und die dann an zentraler Stelle aggregieren. Ihr könnt euch vorstellen, wenn ihr 20 Container habt, dann möchtet ihr nicht 20 Container abklappern per Kommandozeile, sondern möchtet die Log falls zentral an einer Stelle einsehen können. Dann habt ihr schon einen Dienst, der euch das abnimmt, die Lock Fields zu sammeln. Aber das Sorgfalt selber betrachten müsst ihr dann immer noch eben auf einer Web Oberfläche und vielleicht nicht in der Kommandozeile.

Aber Log falls lesen will gelernt sein kommt aber auch jeden Tag vor. Ein ganz ganz großes Thema. Was mir am Herzen liegt beim Thema Debugging ist das Richtige die Backen. Ich halte das für extrem wichtig für effektive Arbeit zu machen. Also stellt euch vor. Ihr baut eine Website und jedes Mal, wenn ihr eine Änderung gemacht hat, müsst ihr den Webserver neu starten, um zu gucken, welche Änderungen hat meine Änderungen denn jetzt bewirkt? Wie sieht die Webseite jetzt aus?

Wie sieht die Webseite jetzt aus? Jetzt würdet ihr so ein Plugin verwenden wie z.B. Hoth Reload, was einfach, wenn ihr die Datei speichert, die Webseite neu lädt und ihr sofort seht, was eure Änderung bewirkt hat. Und das ist jetzt nur Webentwicklung. Das kann man für alle möglichen Technologien gibt es einen dieBürger. Ob das im Browser ist, eine JavaScript Code schreibt, ob das auf JVM Sprachen ist wie Java oder Scala, da gibt es die Bagger.

Ob das bei iOS ist? Wenn ihr Apps entwickelt oder bei PHP. Überall gibt es die Braga, welche die Entwicklung und das Bugfixes extrem vereinfachen. Ihr könnt Breakpoint setzen, also an bestimmten Stellen im Programm stehen bleiben. Dann könnt ihr euch angucken, welche Werte alle Variablen haben. Ihr könnt oft auch die variablen Werte an dieser Stelle ändern. Teilweise könnt ihr das Programm zurückspulen, eine Änderung machen und dann nochmal vorwärts über diese Änderungen drüber gehen und gucken, ob eure Änderungen den gewünschten Effekt hat.

Ihr könnt variablen Werte ansehen und editieren. Ihr könnt OT Reload benutzen. Das heißt, dass ihr die geänderte Datei direkt kompilieren und wieder einladen könnt und direkt den geänderten Code testen könnt. Vorwärts rückwärts über eine Stelle gehen und kommt so viel schneller einem Back auf die Schliche. Oder wenn ihr auch Software entwickelt, als wenn ihr immer wieder den Server neu startet oder den Dienst neu startet und euch bis an diese Stelle durchklicken. Also nutzt ein Debugger. Das ist mein Appell.

Das ist auch ein riesen Hebel. Ich bin immer wieder überrascht. Auch fortgeschrittene Entwickler benutzen nicht immer einen Debugger, sondern erarbeiten erst einmal relativ lange ohne, bis sie dann die Bagger abklemmen. Und die Bagger ist für mich eins der Nummer eins Produktivitäts Werkzeuge überhaupt, um Softwareentwicklung zu betreiben oder Bugfix sing. durchzuführen. Also investiert wirklich die Zeit in die Bagger kennenzulernen und einzurichten. Das ist eine etwas größere Hürde. Oftmals muss man ihn konfigurieren und muss erst mal ein paar Settings gerade ziehen, bis man ihn auch nutzen kann.

Das sollte aber auf jeden Fall machen, auch wenn es etwas lästig ist, weil die Zeit holt er hinterher immer wieder raus. Nach dem Thema Diba gegen was ich abschließen möchte, komme ich zu dem sechsten Punkt und der sechste Punkt ist im Grunde genommen keine Werkzeug Empfehlung wie vorhin, sondern eine Empfehlung zu eurer generellen Einstellung. Der sechste Punkt heißt Produktivität und Zielorientierung und das ist ein ganz wesentlicher Punkt. Die Herangehensweise an ein IT bzw. Software Problem ist ganz wesentlich für euern Erfolg und ich sehe es sehr sehr oft, dass das ein Haupt Unterscheidungsmerkmal ist zwischen einem Entwickler, der vielleicht weniger Erfahrung hat und einem Entwickler, der sehr viel Erfahrung hat.

Die Entwickler mit sehr viel Erfahrung, die überlegen erst auf dem Papier, die planen eine Funktion, die schauen sich an, die lesen sehr viel. Was ist denn schon da? Was kann ich wiederverwenden? Gibt es eine Open Source Library, die ich benutzen kann, die mir schon sehr viel Arbeit abnimmt? Was ist denn schon da? Also wie ist genau mein Weg zum Ziel? Und sehr, sehr viel Zeit wird für die Planung aufgewendet, wohingegen eher Junior Entwickler meistens direkt anfangen Code zu tippen.

Ah hier, da weiß ich, da kann ich etwas implementieren und hier machen wir die Suchfunktion und so. Also die springen direkt ins Thema rein, statt erst mal zu planen. Und da ist mein Erbteil an euch. Überlegt erst einmal genau, was erreicht werden muss, was die Anforderungen sind und dann überlegt euch einen minimalen Weg, wie ihr genau diese Anforderungen auch umsetzen könnt. Nicht zu viel implementieren und gerne needed genau gucken. Okay, wie ist ein effektiver Weg von meiner Anforderung hin zur Implementierung?

Viel Zeit in das Verstehen des Problems zu investieren und auch viel Zeit in die gedankliche Entwicklung der Lösung zu investieren und dann erst mit dem Cone anzufangen und die einzelnen Blöcke zusammenzuziehen. Also desto Me im Vorfeld überlegt und plant, desto weniger Code schreibt ihr am Ende. Weniger Code heißt weniger Fehler, teils besseres Programm, bessere Software. Wichtig wäre bei dem Punkt auch noch daran zu appellieren, dass ihr, bevor er eine Änderung durchführt, überlegt Welchen Impact hat diese Änderung denn für das Business?

Und ist das wirklich wichtig? Sehr oft beobachte ich, dass Entwickler dann diese Technologie und jene Technologie und dies noch verwenden wollen. Aber das löst überhaupt nicht das Ziel Problem. Also man muss sich wirklich jeden Morgen deshalb ist das Daily bei Scrum auch so wichtig nochmal zentrieren und sagen Okay, was sind denn die wichtigsten Themen, die ich erledigen muss, damit die Anforderung umgesetzt wird, um nicht vom Weg abzukommen? Eine Podcast Episode, die genau das Thema aufgreift, ist die Episode Nummer 9 Bulls als Software Development.

Da geht es darum, wie man fokussiert auf die Unternehmensziele hin entwickelt und möglichst genau den Kurs hält. Ich fasse nochmal zusammen als der erste Themenblock Datenhaltung und Verwaltung. Da geht es darum, SKL solltet ihr beherrschen no SQL Datenbanken sollte die verwenden können und beherrschen, was eine hascht Tabelle ist Wissen und die häufigsten Datenformate Jason, Jamel und CSV verwenden können. Bei Thema 2 in Netzen und Protokollen sollte die Funktionsweise des Internets verstehen. Was sind IP Adressen usw.. Das HTTP bzw.

https Protokoll verstehen auch. Was hat es mit der Verschlüsselung auf sich und wie werden Zertifikate eingesetzt? Und ihr solltet Rest APIs ansprechen können und verwenden können. Bei Systeme und Plattformen den Linux System Aufbau verstehen, euch auf der Linux Kommandozeile sicher bewegen können. Docker und virtuelle Maschinen einsetzen können. Den Unterschied zwischen Cloud-Computing und Prims Rechenzentrums Anwendungen verstehen vielleicht die Faktoren des Cloud Native Development mal anschauen im Podcast Episode Nr. neun und zwanzig und dreißig und die geläufigsten Cloud Services habe ich mal angeschaut haben.

Also Google, Microsoft und Amazon sind hier zu nennen. Bei der Arbeit mit dem Sourcecode solltet ihr mit Geld umgehen können und die Integration von KI, als sie die Pipelines verstehen. Warum macht man das und wie geht das prinzipiell? Beim Thema Debugging Lock Falls lesen können und den Debugger einrichten. Das ist ganz wichtig, damit ihr produktiv arbeiten könnt und beim Thema Produktivität und Zielorientierung euch immer wieder daran erinnern. Planen. Problem verstehen. Möglichst viel über das Problem wissen und dann erst eine Lösung entwickeln.

Weil desto mehr man über das Problem weiß, desto einfacher ist die Lösung hinterher. Für weitere Podcast Episoden zu den Themen die packe ich euch in die Shownotes. Aber den Podcast Nr. neuen Bullshit Software Development einfach und fokussiert auf Unternehmensziele in entwickeln Must-Have Skills und Technologien für DevOps findet ihr in der Podcast Episode Nr. 8 für Data Ingenieurs und Data Scientists in der Podcast Episode Nr. 7 für Faulstich Entwickler. In der Podcast Episode Nr. 6 und die 12 Faktoren des Cloud Native Development findet ihr in der Episode 29.

und 30.. Nochmal wichtig zu sagen all die angesprochenen Themen haben eine sehr hohe Praxis Relevanz, das kann ich euch sagen aus 16 Jahren IT Erfahrung und über acht Jahren I Beratungs Erfahrung. Wenn ihr Fragen habt oder Feedback zu der Episode, weil ihr glaubt, dass ich ein wichtiges Thema vergessen habt, sendet uns gerne eine E-Mail an Podcasts. Gilbert D. Wenn euch die Podcast Episode gefallen hat, abonniert unseren Podcast und lass deine 5-Sterne Bewertung. Wir freuen uns auch immer über Weiterempfehlung an Freunde und Kollegen, die sich ebenfalls für Technologie Themen interessieren.

Ansonsten freuen wir uns noch, wenn ihr uns Gilbert D. Slash Blog vorbeischaut. Vielen Dank fürs Zuhören und bis zum nächsten Mal.

Maurice KnoppSkillbyte Podcast #48: Grundkenntnisse und Skills für ALLE IT-Fachkräfte
Mehr

Skillbyte Podcast #45: Das Spring Boot Framework

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Das Spring Boot Framework

// Inhalt //
02:35 – Was ist Spring Boot?
03:26 – Erfahrungsbericht: Spring Boot Anwendungsentwicklung
14:43 – Spring Boot Paradigma: Convention over Configuration
15:16 – Lohnt sich der Einsatz von Spring Boot? Lernkurve?
16:39 – Ein kleiner Vergleich mit der Pyhton Welt
18:16 – Features von Spring Boot
22:31 – Spring initilizr auf start.spring.io
23:45 – Spring Support von IntelliJ IDEA
26:41 – Spring Boot Banner
27:44 – Dokumentation der Spring Boot Anwendung
29:00 – Fallstricke & Tipps
33:02 – Fazit: Ist Spring Boot empfehlenswert?

Show Notes:

Podcast #29: Die Zwölf Faktoren des Cloud Native Development (Teil 1)
-> https://soundcloud.com/skillbyte/podcast-29-die-zwolf-faktoren-des-cloud-native-development-teil-1

Podcast #30: Die Zwölf Faktoren des Cloud Native Development (Teil 2)
-> https://soundcloud.com/skillbyte/podcast-30-die-zwolf-faktoren-des-cloud-native-development-teil-2

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Ich denke auch, dass sich das als Blaupause und Grundlage für die voll regelrecht für Java Anwendungsentwicklung nehmen würde, weil die meisten Anforderungen aus Umgebungen kommen, wo man das eben gut umsetzen kann. Ich meine missis in den letzten Jahren nichts untergekommen, wo man jetzt auf einen klassischen ein Maschienen Server oder einen großen Mainframe irgendwas hätte entwickeln müssen, sondern man kommt eben immer eigentlich gerade wenn es Java sein soll in diese Microservices Richtung bzw. kann seine Anwendung zum Lösen eines Problems so designen, dass sie auch sinnvoll so umzusetzen ist.

Und dann ist Spring Boot wirklich ein Top Tool.

Herzlich willkommen zu unserer Skill bei Podcast Episode Nummer fünfundvierzig Das Spring Boot Framework abonniert unseren Kanal für mehr spannende Themen aus dem Technologie Umfeld. Wenn ihr die Entscheider oder die Fachkraft seid, wenn ihr eine höhrer Frage habt im Verlauf der Episode sendet uns gerne eine E-Mail an Podcast Skill Bild.de:. Wir freuen uns immer über Bewertungen und weitere Empfehlungen dieses Podcasts an eure Freunde und Kollegen, die sich ebenfalls für diese Themen interessieren.

Wenn ihr aktuell in der IT-Branche auf Jobsuche seid, schaut auch auf Skill weite Isles Jobs vorbei. Ich bin heute hier mit den beiden Skill BYD Data Ingenieurs Oliver und Andreas.

Hallo ihr zwei Callboys. Schön wieder dabei zu sein. Hallo Moritz Fela, endlich mal dabei zu sein.

Oli kennen ja schon einige Zuhörer, Andreas. Für dich ist es heute ein Novum. Aber ich freue mich wirklich, euch beide dabei zu haben, weil ihr euch sehr intensiv jetzt in dem letzten halben Jahr bzw. kann man so sagen die zweite Jahreshälfte 2000 und 20 mit dem Spring Boot Framework beschäftigt habt und auch eine recht komplexe Anwendung darauf entwickelt hat.

Genau. Wir haben als Projekt. Ich glaube, so ab August letzten Jahres bis Ende des Kalenderjahres genau haben wir eine Spring gut basierte Anwendung für den Kunden gebaut, was für uns ein völlig neuer Text steckt. Zu dem Zeitpunkt war uns aber die Möglichkeit gegeben hat, da sehr, sehr schnell production ready zu werden und eine Anwendung zu haben, mit der wir sehr schnell weiterentwickeln und testen können. Das war eine ziemlich coole Sache. Da kann Andreas aber auch noch was zu sagen, weil auch für den war das glaube ich ein neuer Einstieg.

Ja, genau. Also für mich war das eigentlich alles Komplettem, weil sowohl Java als auch Bimbos und bin tatsächlich erstaunlich schnell reingegangen. Das hat mich auch ein bisschen überrascht. Sobald man sich einmal an die Annotationen gewöhnt hat, ist man eigentlich sofort dran.

Genau das ist ja auch das Kernziel des Spring Boot Frameworks. Vielleicht kennt der ein oder andere Zuhörer ist noch nicht so oder kann auch nicht genau was damit anfangen. Deshalb würde ich kurz sagen, dass es sich um einen Quell offenes Framework für die Java Plattform handelt, welches meist genutzt wird, um eben Webanwendung zu implementieren, Microservices zu implementieren. Und das Ziel dieses Frameworks ist es eben möglichst schnell komplett Laufwege Anwendung erzeugen zu können, weil die default Einstellung der Konfiguration im Grunde sinnvoll sind.

Das ist der Anspruch, den dieses Projekt hat. Und wie das so ist z.B. beim Schachner im Menace to learn alive to Master, so ist das auch ein bisschen bei Spring Boot gestartet ist man sehr schnell, kann dann aber die Anwendung nach und nach um weitere Komponenten erweitern und eine sehr komplexe Anwendung bauen, was er ja auch gemacht hat.

Auf die genauen Inhalte müssen wir ja jetzt gar nicht eingehen, aber die Anwendung sollte als System von mehreren kleinen Microservices ineinander greifen. Wir brauchten unter anderem einen einfach zu nutzen. Das Web frommt und wir brauchten den eigentlichen Controller dahinter. Wir brauchten eine Datenbank Anbindung. Wir mussten die Möglichkeit haben, Daten im lokalen Dateisystem zu paar sistieren und und und. Das waren viele einzelne Komponenten, die wir dann entsprechend damit strukturieren konnten. Und das hat dem Ganzen wirklich einen hervorragenden Rahmen gegeben, wo man dann die Arbeit auch de facto gut aufteilen konnte, um eben das Ganze schön gekapselt zu haben.

Das hatte auch ganz viele Aspekte von der Pull-Faktor App, über die wir ja schon mal zusammen gesprochen haben, wie wir das dann Gebaute nachher auch die PEUT haben.

Andreas War das für dich? Hattest du das Gefühl, dass man es gut aufteilen kann und dass du dann so einzelne Häppchen abarbeiten konntest?

Ja, das ging eigentlich Duterte als ich zu dem Projekt dazugekommenen, was aber nur zwei Wochen war, nachdem Oliver auch damit angefangen hat, war quasi schon ein bisschen ein Grundgerüst da und werden dann aber recht schnell gemerkt. Wir brauchen jetzt noch zusätzliche Rest API Endpunkte von quasi zusätzliche Microservices. Und da hat es mich überrascht, wie einfach es war, da dann zusätzliche Sachen zu schreiben. Dann hat man einfach einen zusätzlichen Controller hochgefahren und dem Endpunkte gegeben und die konnten unabhängig voneinander dann bearbeiten.

Das hat einfach sofort funktioniert.

Das Gute ist halt bei dem Spring Framework und Spring Boot ist ja letztlich nur eine Geschmacksrichtung des großen vollumfänglichen Spring Frameworks, dass man diese Inversion of Control eben nutzen kann. Also Andreas hat es eben schon angesprochen per Annotation. Also Edin Denkakt oder Auto wiederholt sich dann die einzelnen Komponenten in die Klasse durch den Container oder durch das Framework Injektor lassen kann. Das deutsche Wort wäre glaub ich verdrahten lassen kann und dann eben diese Komponente vollumfänglich zu nutzen. Habt ihr das so Komponenten Weise aufgeteilt?

Die Arbeit oder jeder hat so ein bisschen Überblick über den gesamten Code gehabt.

Das werden glaub ich beide einen ganz guten Überblick über alles. Aber gut, wenn man zu zweit arbeitet, dann teilt man sich schon ein bisschen die Arbeit auf und Alianza ein bisschen mehr Erfahrung mit Docker Containern schon an denen, die. Deswegen hat er sich da mehr darum gekümmert und ein bisschen mehr um die Rest API selber, dann würde ich auch genau so unterschreiben und es war wirklich praktisch, dass man die ganzen Dependency es, die man ansonsten berücksichtigen müsste, dass man diese ganzen Weg gekapselt module dann sich einfach über dieses Auto via O-Ring direkter reinholen kann.

Da kann man vielleicht später nochmal kurz drüber sprechen, aber so angeteasert. Das hat es für uns dann eben auch super gemacht, das ganze mit Unit Test Abdeckung nachher zu versehen. Also diese modularer Bauweise, die hat uns da das Leben in vielerlei Hinsicht vereinfacht.

D. h. ihr habt dann wirklich Komponente für Komponente g Unit testet im Rahmen der Zeit, die wir zur Verfügung hatten.

Ja, also die war von Anfang an begrenzt. Das waren die letzten paar Wochen im Projekt Scope. Und wir haben mit den Kern Komponenten, die für den Betrieb nötig waren, entsprechend angefangen und haben entsprechend dann doch noch ein sehr akzeptables Level an Test Abdeckung für die ganze Applikation geschafft. Am Ende ja. Und das haben wir genauso gemacht.

Er war auch ein bisschen überrascht, dass wir dann doch noch so eine hohe Testa Abdeckung hingekriegt haben, weil dadurch das ganze zeitlich limitiert war. Haben wir jetzt nicht Testpiloten Development von Anfang an gemacht, da vor allem auch vieles zum Anfang noch nicht klar war, wie es am Ende aussehen würde, aber zumindest Järvi alle gesagt hat. Die Kernidee Teile der App und mit der nachträglich ziemlich einfach noch mit Tests versehen.

Das heißt, die Anwendung wurde zuerst entwickelt. Ich glaube, das kann man sagen. Es handelte sich um eine Brücke, einen Exporteur und einen Importeur von zwei verschiedenen Systemen, der einfach Daten transformiert hat zwischen diesen Systemen. So, und da waren wahrscheinlich die Schnittstellen nicht ganz klar und es hat sich erst im Verlaufe des Projektes herausgestellt und dann am Ende, als die Schnittstellen klar waren und die schon bespielt werden konnten. Habt ihr das dann nochmal getestet? Richtig. Also das Ganze war, wenn man es drastisch formuliert, wirklich als One-Shot Anwendung konzipiert.

Man hätte das natürlich dadurch, dass sowohl das Quelle als auch das Zielsystem weitverbreitet sind in der Branche, in der der aktuelle Kunde da unterwegs ist. Aber die Systeme waren jeweils so spezifiziert und an die Bedürfnisse des Kunden angepasst, dass es viel mehr Aufwand gewesen wäre, das deutlich generischer zu machen, um es als Produkt dann auszuarbeiten, sodass wir da wirklich eine maßgeschneiderte, schnell entwickelte Lösung gebaut haben.

K Perfekt. Jetzt habt ihr diese Anwendung gebaut. Wenn ich das richtig verstanden habe, Oliver, du hast dich so ein bisschen um die Pakete gekümmert. Docker Den Betrieb oder die DevOps Komponente. Andreas Du hast vielleicht etwas mehr an der Anwendungs Logik gearbeitet. Hattet ihr das Gefühl, dass euch springender Gut unterstützt, also dass ihr euch wirklich auf eure Kernthemen konzentrieren könnt Infrastruktur oder Anwendungs Logik? Oder hattet ihr oft das Gefühl oh ich schreib hier Boiler Pleite Code um die x te Datenbank Verbindung aufzumachen oder sowas?

Das muss doch einfacher gehen.

Er sei ein bisschen hatte ich schon den Eindruck, dass man ein bisschen Boiler Plaid Code schreibt. Gleichzeitig hatte ich aber auch den Eindruck, dass es weniger ist als meine Java sonst machen müsste. Da ich wohl noch nicht so Java Erfahrung hatte, war mir bewusst, dass ich da mehr bei der Palette Code schreiben muss, als z.B. ein Payton war. Das hat sich dadurch ein bisschen in Grenzen gehalten.

Hast du ein Beispiel für Boiler Plaid er gut alle Geta an CETA hat man einen Partner z.B. einfach nicht. In Ada kann man vieles umgehen in der Stelle.

Für mich hats massiv Code gespart. Du hast das Stichwort Datenbank Anbindung gerade genannt. Da ist durch JPY zu den technischen Feinheiten kannst du vielleicht gleich noch kurz etwas sagen ist uns extrem viel Arbeit abgenommen worden. Also da bringt Spring Boot von Hause aus die Möglichkeit mit, das sehr elegant zu nutzen, in dem nicht nur einfach die Gredenko sieals und die Konnektivität Informationen zu einer Datenbank übergeben werden, sondern man hat auch über vordefinierte Funktionen hat man die Möglichkeit, die Tabellen selber direkt anzulegen.

Also die Schemata. Das wird alles von Springflut über sehr viele einzelne Komponenten ermöglicht, ohne viel Aufwand an der Datenbank selber betreiben zu müssen. Das ist wirklich schön gemacht.

Ja, das stimmt. Also ein sehr komplexes Datenbank Schema, wie wir dann letztendlich doch eigentlich hatten, halte ich glaube ich hier. Wenn ich die hätte selber schreiben müssen ich in der Zeit hinbekommen. Auf jeden Fall.

Vor allem wenn man noch die SQL Schnittstelle selber in irgendeiner Form hätte bauen oder mit kleine SQL Code hätte bedienen müssen. Und da nimmt einem JPC dann eben schon extrem viel Arbeit ab. Und das hat dann auch def abseitig viel gespart, weil man einfach die Datenbank zur Verfügung gestellt hat, die Konfiguration in JPL mit ein paar Zeilen schnell gemacht hat und dann lief das. Das muss man einfach dazusagen. Das war wirklich einfach die JPL. Hier steht ja für die java persistent api die eben genau.

Für. Daten bank. anbindungen. Da ist. Oder persistenz. Schicht anbindungen da ist. Und das schöne hier ist. Dass man im grunde. Das es gerade gesagt. Diese tabellen relationen. Oder das datenbank schema. Das kann man einmal anlegen. Und jpl kümmert sich dann darum. Je nach dem ob du eine postgresql datenbank hast. Maisie. Soldaten. Bank. Oracle. Datenbank. Den. Richtigen exkl. Dialekt nenne ich es mal zu generieren, so dass das konkrete Backend dann eben unterstützt wird.

Und das macht natürlich auf Migration sehr einfacher. Der eine Kunde setzt die Datenbank Technologie ein, der andere Kunde setzt die Datenbank Technologie ein. Da möchte man kein Wenn du Login haben, sondern die JPL benutzt, läuft es überall oder auf allen Datenbank Plattform, die eben JPY Unterstützung erfahren, was die meisten sein dürfen.

Ja, das Thema Parketts hierum hast du eben angesprochen. Hass hat für mich auch nochmal leicht gemacht. Das war dann die Zusammenarbeit von Spring bzw. Spring gut und eben Maven als Paket Manager dies mir extrem leicht gemacht hat. Die Anwendung dann einfacher dem Docker Container zu betreiben, also sowohl schon für Entwicklungs Zwecke wirklich jeder auf seinem Entwickler Laptop was auch praktisch war war. In Docker waren wir dann eben auch völlig unabhängig davon, weil ich habe es offene Meek gemacht Andreas glaube ich auf einem Linux System.

Das lief dann alles sofort und auch der Roll outs beim Kunden war dadurch viel einfacher, weil der Ebene Container Umgebung zur Verfügung gestellt hat und wir dann nur noch da rein diplomen mussten und dann eben mit dessen, der vom Team geklärt wurde, wie dann der Betrieb abläuft. Aber dadurch, dass wir eben die Pakete hierum über Maven und Spring buht dann eben hatten und das ganze schon im Docker Container betriebsbereit zur Verfügung stellen konnten. Sehr einfach war das ein Kinderspiel und schnell gemacht.

Das war echt toll. Da habt ihr direkt eine Stärke von Spring Boot voll ausgespielt in Kombination mit Docker, weil ich sag euch das früher war das nicht so, dass man eine Java Anwendung direkt ausführen konnte oder es war ganz ungewöhnlich, sondern es gab einen sogenannten Application Server an Tomcat aus dem freien Bereich oder auch verschiedene proprietäre Produkte. Von RedHat hieß es z.B. J. Bors und das war ein sehr schwergewichtige Server, die also teilweise mehrere Minuten benötigt haben um zu starten.

Und da wurde dann die Anwendung alzu war fail oder eher fail wurde die Anwendung rein die bloed und rein geladen und die wurde dann auf diesem Server ausgeführt. Das ist natürlich heute in der kybernetisch Umgebung Microservices Umgebung ist das überhaupt nicht praktikabel, dass man da einen Server hat, der sehr viele Ressourcen braucht und der mehrere Minuten zum Starten braucht, sondern da möchte man eine kleine ausführbare Code Einheit haben, die ihre dedizierte Aufgabe übernimmt. Und da bietet sich natürlich das selbst laufende Spring Boot Programm an oder die selbst laufende Applikation ist es ja ein derFall was man direkt starten kann.

Wir haben in dem Zusammenhang genau das bekommen, nämlich ein Zerfall, was schon alle Dependency es enthielt. Man musste da keine Libraries mehr installieren und gar nichts. Man konnte mit einem minimalistischen Docker Image anfangen. Es musste nur Java installiert sein. Dann hat man das ja ausgeführt. Wenn man wollte noch ein paar Laufzeit Parameter mitgegeben und dann lief die Anwendung und die ethical schon eben diese Webserver Komponente. Zum Beispiel wenn ich mich erinnere an meiner Anfangszeit in dem Projekt, wo ich noch nicht so vertraut war.

Damit hab ich noch einen extra Docker Container hochgefahren, wo ich in Engine X Webserver drin betrieben habe, damit ich diese Rest API überhaupt irgendwie ansprechen konnte. Und irgendwann haben wir dann verstanden, dass Springflut das schon von Hause aus mitbringt. Aber da hat Andreas viel mehr mitarbeitet als ich.

Ja, da kam dann aber nochmal die zweite Erkenntnis. Also erstmal wie obligat gesagt hat, des Rest Framework selber. Aber man habe dann festgestellt, dass es ja wirklich war, seinen kompletten Webserver der auf Heilberufe mitliefert. Wir hatten dann nämlich doch nochmal eine Endings dazu, die Plots, um einfach statisch ein paar Fails für das Frontend können und das fand ein selber und dann feststellte Wir können das einfach direkt staatlich mit einbinden. Wir nennen einfach einen Ordner Public und dann passiert alles automatisch.

Das war dann nochmal so ein Aha-Erlebnis.

Das ist diese Opinio Nahtod Konfiguration. Also bring but leg dir schon so die Fold Ordner an oder bzw. die kannst du anlegen, wo dann Settings drin liegen können für die Anwendung oder eben statische HTML Falz, wo man sich dann nicht weiter kümmern muss, wenn man sich an diese die Fold Konfiguration hält. Man kann auch alles konfigurieren, aber das Ziel von Spring Boot ist es zu sagen Hammer, wir geben dir einen vernünftigen Grundstock auf dem kannst du aufsetzen und du kannst alles konfigurieren.

Aber so wie wir es dir liefern, ist es erst einmal in Ordnung für die meisten Anwendungen. Also könnt ihr bestätigen Spring Boot hat euch fÃr eure Entwicklung doch ordentlich unter die Arme gegriffen. Ihr seid schnell zu Rande gekommen, habt wenig kämpfen müssen. Leute, die um die Millennium Wende Java entwickelt haben, die kennen noch, wie schwerfällig das alles war. Habt euch gut in der STANDARD Konfiguration zurecht gefunden und wenn ihr Zusatz Komponenten eingebaut habt. Ich weiß jetzt nicht ob ihr den Spring Logger benutzt habt oder wahrscheinlich die Spring Datenbank Anbindung und so, dann war das wahrscheinlich mit 20.

Mal googeln. Bildung ist natürlich hier die Website, die sofort auf ploppt, war das relativ schnell eingebunden. Ja, würde ich genau so unterschreiben. Es war zunächst mal intuitiv ziemlich viel verständlich, muss ich sagen. Nun muss ich dazu gestehen, dass ich zumindest Java schon mal vorher gemacht hatte und auch Maven vorher schon mal gesehen hatte. Das hat mir die Grundlage ein bisschen bereitet, aber nachdem ich dann in die einzelnen Sachen besser reingekommen war, lief das sehr schnell.

Die Lernkurve war sehr steil und auch einfachste Internet-Recherche. Meistens kann man eben bei Bildung raus, hat da schon geholfen, weils eben auch so viel genutzt wird und so viele Leute sich damit beschäftigen und damit arbeiten.

Für mich war da die Lernkurve noch ein bisschen Tayler, weil ich hatte tatsächlich vorher noch keine einzige Zeile Java Code geschrieben. Aber selbst damit war das ohne Probleme machen. Also mit den Web Ressourcen kann man dann schnell zu Rande Andreas. Gibt es denn in der Python Welt ein mit Spring Boot vergleichbares Framework? Also was ähnliche Features anbietet oder was die vielleicht immer wieder aufgefallen ist, dass du gedacht hast oh stimmt, das ist so wie bei Falcon oder so.. Also mir geht es ganz häufig so Wenn ich mich in einer Welt relativ gut auskenne und dann mich in neue Themen einarbeitet, dann stelle ich fest Ah, okay.

Die NPD ist eine neue Form von Maven oder Gretl oder dass man quasi diese queer Referenzen herstellen kann.

Ich würde sagen, es gibt nicht so ein monolithischer Ding, was es alles kann. Ein bisschen. Also es gibt gute Respawn Frameworks, dem Rass ähnlich komfortabel auch eine Rest API aufziehen kann. Aber dann muss man halt nochmal einen Webserver dazu machen, was man zwar auch leicht geht, aber es halt erst ein anderes Projekt. Dependency Injection ist nochmal komplett anders. Man braucht es einmal in Payton nicht ganz so viel, da man in der Laufzeit natürlich viel austauschen kann.

Dynamisch auch, aber wenn man es wirklich vollständig benutzen will, dann muss man zu anderen Paketen gehen. Also es gibt nichts, was das alles miteinander verbindet und einem von Anfang an was funktionierendes gibt. Man muss das ein bisschen zusammensuchen, mehr und auch Entscheidungen treffen, welches man dann von mehreren Möglichkeiten wählt. Swing gibt’s ja auch Alternativen.

Genau, aber Spring Boot muss man schon sagen. Ich will nicht vom de facto STANDARD sprechen, aber das ist für Berat, also Rapid Application Development in der Java Welt so über die letzten Jahre ist das ein sehr, sehr großer Player geworden und man startet meistens damit, dass ganz viele große Applikationen, die man kennt, bestehen ja heutzutage aus vielen, vielen kleinen Microservices. Und diese Microservices, die die Arbeit im Hintergrund verrichten, die sind sehr oft mit Springflut geschrieben.

Welche Features von Spring Boot habt ihr denn verwendet? Also wir haben eben schon über ETT Auto Wired gesprochen. Andreas hatte die Notationen erwähnt. Das ist natürlich das Ding, oder? Diese Inversion of Control ist das Konzept, mit dem Spring damals bekannt wurde, Anfang der 2000er Jahre, dass man eben nicht mehr New Klassisch schreibt und damit eine harte Kopplung hat, sondern man sich über ET Auto Wired z.B. einen Logger in Jack tat, eine Datenbank in Jack That oder ein Transaction Manager in Jack That und dieser Transaktion Manager ist quasi entkoppelt davon, solang der ein gewisses Interface implementiert.

Bleiben wir mal beim Logger ist es egal, ob das ein Festplatten Logger ist, ein Screen Logger, ein Netzwerk Logger oder ein Logger auf einem ganz anderen Medium. Ein na Logger, der einfach nur alle Log Zeilen wegschmeißt oder ein Rauchzeichen lagert. Zur Not. Das Konzept ist ja ganz zentral und ich denke, das hat euch auch relativ früh. Habt ihr das bemerkt?

Ja also die Cernko Komponente für uns war, würde ich jetzt für mich sagen das Auto, wir O-Ring, dass man eben nicht jedes mal neue Instanzen von Klassen erzeugen muss, sondern wirklich diese Benes hat. Und wir haben die auch meistens eben als Singleton benutzt. Das war wirklich etwas, wo wir uns dann auch sukzessive beim Design der Anwendungen Gedanken drum gemacht haben. Also wir haben dann wirklich versucht, wo wir eigentlich zuerst intuitiv gesagt hätten Okay, wir brauchen mehrere Instanzen davon von der gleichen Klasse, dann haben wir trotzdem versucht, unser Design Pattern so umzubauen, auch gedanklich, dass wir eben diese Singleton Auto Viri Funktionalität benutzen können.

Und es hat uns halt auch beim Testing dann begleitet. Entsprechend ja eben das Logging. Andreas Was kann ich mir, wie haben wir das gemacht? Haben wir das von Spring genutzt?

Das Logging ist es auch per Annotation. Das war der SL vor J. Logger lassen hab der Franz Spring Boot selber ist oder?

Meistens sind das externe Libraries, die du einfach in Jackets. Beim Logging kippt es mehrere Standards. Es gibt Lock vor J, dann in CV. JJ Logger. Da gibt’s noch zwei, drei andere. Ich benutze den, der in der Anwendung schon drin ist, weil ich da kaum Unterschiede feststelle oder zumindest mit allen leben kann.

Sagen wir so. Was mir noch einfällt, das ist relativ gegen Ende gekommen, als es darum ging, die Anwendung beim Kunden in den Container Cluster. Zwar Masons zu Diplomen ging es darum, wie wir Health Checks unserer Anwendung im Betrieb machen können. Und weil das vom Dev OPs Team des Kunden angefragt wurde, wie man sicherstellen kann, dass die Anwendung auch vernünftig läuft und ich meine, da hättest bring uns die Funktionalität intrinsisch zur Verfügung gestellt. No Matrix Ja, genau, dass wir da nicht noch selber Health Brookes verschreiben mussten mit dedizierten Endpunkten in der API.

Genau. Wenn ihr das Micro Service Profil benutzt habt, haben wir glaube ich Letz endlich nämlich nicht.

Aber wir haben dann letztendlich die eigenen Endpunkte geschrieben gehabt und dann festgestellt, dass es bringt uns eigentlich frei Haus geliefert hätte. Aber da war es in dem Fall schon zu spät. Das lag dann eher daran, dass wir uns nicht genug damit auskannten. Okay, gut.

Aber das heißt im Grunde jetzt wisst ihr, dass es das gibt. Beim nächsten Service könnte man sich diese STANDARD Matrix also hier RAM verbraucht CPU Jukic, Disk Space könnte man sich auch sparen, sondern einfach die vordefinierten nutzen und die dann eben entsprechend erweitern. Wenn man das braucht.

Ja, was Oleh mir auch gesagt hat. Wir hatten dann ganz viele Klassen mit Autoritären, was am Ende darauf hinausgelaufen, dass wir ganz viele einzelne Klassen hatten, die quasi ein Objekt aus der einen Umgebung der neuen Umgebung übersetzen konnte. Und all diese Übersetzer waren dann letztendlich Singleton Wins, die dann an einer entsprechenden Stelle, wo sie benötigt wurden, einfach nur initiiert worden.

Genauso macht man es auch auch. Ich nehme an, als sie dann die einzelnen Komponenten getestet habt, dann injektor dir dann einfach Mock Objekte statt der realen Instanzen um dann die Kernfunktion einer Klasse zu testen. Richtig, genau so haben wir es dann gemacht.

Genau das war immer der Punkt. Wir haben versucht, das, was wir als Bian eben dann Jack Thot haben, vorher getestet zu haben, um es dann eben an einer anderen Stelle als fertigen Mock benutzen zu können.

Habt ihr bei Projektstart ich glaube es gab schon im Template Oleh Wanne. Ihr habt nicht den Spring Finisher Leisure, also auf Startpunkt Spring dort AIO gibt es den, den habt ihr nicht benutzen müssen, oder?

Nee, tatsächlich nicht. Da hatte ein Kollege schon was vorbereitet, um so eine grobe Projekt Struktur auch mal in Form von Place holder Klassen angelegt und eine grobe Funktionalität war auch schon gegeben. Also ich glaube man hat die Möglichkeit eine Liste zu migrieren oder Objekte einzulesen aus einem Testfall. Und es gab schon eine Anbindung an eine Postkarte oder Mail SQL Datenbank. Genau das war so unser Startpunkt zu dem Zeitpunkt und entsprechend gab es dann eben auch schon ein POM Fall mit dem ganzen Maven Setup A okay war.

Es gibt auch Startpunkt Spring Punkt Видео gibt es diesen Spring in leiser und da kann man dann sagen ich möchte eine Springflut Anwendung schreiben mit Datenbank Zugriff mit Maven oder Greendale Build System und man klickt so ein paar Sachen zusammen und am Ende fällt ein Zipfel raus, was quasi so die Basis Anwendung mit den getroffenen Einstellungen schon enthält. Quasi dieses schlachte schnell und kümmert sich um die Anwendungs Logik auf die Spitze getrieben. Jetzt habt ihr beide ja intelligent Diaa benutzt. Für das Projekt hat euch die Idee gut unterstützt.

Bei Spring Boot Anwendungen ist der Support dafür reif.

Der Support der war super. Tatsächlich. So war von den Socken. Wie einfach es doch ist, damit all die Sachen, die man sonst sehr manuell nachschauen muss in Variablennamen merken und dann ins Java natürlicher nach ner typisierte Sprache, d. h. das kommt noch dazu. All das. Da nimmt es einem ziemlich viel Arbeit ab.

Und auch die Kenntnis der Fidi über die Projekt Struktur. Also was kann ich überhaupt per Auto via O-Ring einbinden? Also was hab ich zur Verfügung? Oder wenn ich jetzt gerade nochmal an das Pom fail zurückdenke. Wenn ich da versuche in Versions takk von etwas einzubinden, was in der Form so nicht existiert, werde ich darauf hingewiesen oder dass ich das dann erst runterladen muss, damit es zur Verfügung steht. Für mich jetzt lokal all solche Sachen, um die man sich ansonsten zu einem späteren Zeitpunkt Gedanken machen müsste, um dann wieder zurückzugehen, um es zu fixen.

Das war schon klasse und natürlich die Möglichkeit, selbst in Module reinspringen zu können, die man nicht selber geschrieben hat, sondern die aus externen Libraries stammen und im Zweifelsfall dann eben de kompilierte Code vor sich zu haben. Was aber immer noch besser ist, als nicht zu wissen, was passiert.

Ja, das stimmt. Du hast Andreas hat eben auch gesagt die Gather und Zeta. Das stimmt, dass man die schreiben muss, das ist schon. Da entsteht diese riesen Text Tapete. Ich mache mal mit ALD einfügen generiere ich die einfach und habt ihr dann für alle Properties. Deshalb stört mich das gar nicht so sehr. Obwohl das eigentlich natürlich schöner geht, hat Andreas vollkommen recht. Was ich bei der Springflut Unterstützung ganz klasse finde ist Du kriegst ja dieses Blättchen, dieses Ahornblatt oder so wird dann angezeigt und dann siehst du die einzelnen Pins, dann kannst du bei den Autor via Pins kannst du so dadurch springen oder er schlägt dir dann schon die Methoden der Pins vor, wenn du da unten arbeitest.

Meistens läuft es da so hinaus. Du was hat deine Klasse, die die Anwendungs Logik enthält und du? Historiker Klassen, die dir halt zuarbeiten, also z.B. Du hast deine Anwendungs Logik und hast ein Database Worker, der Objekte aus der Datenbank holt, Objekte in die Datenbank speichert usw.. Kannst du die dann sehr einfach in deine aktuelle Klasse rein? Metten?

Ja, die Funktionalität hab ich zumindest auch hin und wieder mal benutzt. Was mir noch als Randnotiz positiv im Gedächtnis geblieben ist, ist die Tatsache, dass sehr intuitive Nomenklatur vorgeschlagen wird von der Idee. Also wenn ich das schreibe oder was haben möchte an möglicherweise vordefinierten Strukturen innerhalb meiner Klasse, dann ist die Nomenklatur entsprechend schon an das angepasst, was die tun soll. In dem Zusammenhang wies für mich jetzt gerade notwendig ist, auch wenn dann das schon mal sehr lange Methoden Namen bei rauskommen.

Aber es ist sehr gut. Human Redtube möchte ich mal sagen, was die Idee da einem vorschlägt. Also sie unterstützt da auch schon den menschlich intuitiven Zugang sehr.

Habt ihr eigentlich? Fällt mir gerade ein, bei Convention over Configuration habt ihr auch ein eigenes Banner erzeugt vor einer Anwendung.

Ja, ich hab das sogar in zwei erzeigt.

Wäre ja, ich hab zwischendurch mal gewechselt. Das ist richtig. Am Anfang habe ich ein Corporate Identity ähnliches Banner aus Asti Artzt da hinzugefügt. Genau Asgard Generatoren gibt’s ja genug online frei verfügbar und danach hab ich mir ein Zitat aus einem Musikstück, was ich sehr schätze da eingebaut, was in den Zusammenhang von dieser ganzen Worker Struktur ganz gut reinpasst. Richtig, das war so ein bisschen Selbstverwirklichung, muss ich zugeben. Aber ja. Haben wir gemacht.

Vielleicht für unsere Zuhörer. Kurz. Es gibt eine Band TX t, die kann man auch auf einem standardisierten Pfad ablegen. Und wenn die Anwendung gestartet wird, wird automatisch diese Textdatei quasi ins Lock Fail übertragen. Also normalerweise steht an Spring Boot Version 5.1 Delete, aber man kann das halt mit seiner eigenen SII Banner Punkt txt überschreiben. Was immer ganz interessant ist, was die Leute sich da ausdenken, weil das so ein Freitagnachmittag Task ist. Habt ihr denn auch die einzelnen Methoden dokumentieren müssen oder viel Dokumentation schreiben müssen?

Hat euch das bringt Boot irgendwie unterstützt?

Also da gibt es ja Bild Targets Chewie Java Doc die Dokumentation extrahieren. Da gibt es auch so Spring Boot Plug-Ins das ist alles ein bisschen schöner aussieht. Da purzelt dann diese Java STANDARD Dokumentation raus. Ich weiß nicht, ob das in dem Projekt gefordert war.

Das war nicht in Förderturm manuell dokumentiert, was zu dokumentieren war. Aber zwischendurch hatte ich mir tatsächlich auch diese automatischen Tools angeschaut. Die sind teils sehr umfangreich im Sinne von, dass sie natürlich automatisch alles dokumentieren, was in dem Fall einfach mehr war, als wir brauchten. Dann hätte man sich da dann nur die Teile rausziehen müssen, die man braucht. Von daher war es quasi. Es hat einem zu viel schon gegeben, mehr als von den Verbrauchter.

Zumindest war das mein Eindruck, was aber definitiv am Projekt Scope lag. Das war einfach nicht immer Anforderungsprofil der Aufgabe enthalten. Da ging es mehr um eine Übersicht Dokumentation und weniger in die Tiefe einzelner Methoden rein Dokumentation zu schreiben nach dem Festlegen vorgelegten Schema, sodass wir dann da eher eine Markdown Read Me geschrieben haben, die auch eher kurz ausgefallen ist und auf die Punkte eingegangen ist, die wirklich nötig waren. Deswegen konnten wir das Feature nicht nutzen. Sinnvoll.

Gab es denn bei dem Projekt irgendwie Fallstricke, die mit Spring Boot zusammenhängen, wo ihr sagen würdet Oh, wenn ich das nochmal machen würde, da hab ich viel Zeit gelassen, das würde ich anders machen. Also so Tipps, die im Grunde euch selber geben würdet, wenn ihr das Projekt nochmal durchführen würdet.

Ich weiß nicht, ob ich sie anders machen würde, aber auf jeden Fall Fallstricke, über die man wegkommen muss. Schon an seinem bisschen. Vor allem wann etwas ein Singleton Objekt ist und wann es kein Singleton Objekt mehr ist bzw. wenn du mal kein Singleton Objekt haben willst, musst du einfach ein bisschen mehr Arbeit machen oder muss überlegen ob du es wirklich nicht Singleton brauchst oder haben Singleton nicht auch ausreicht, weil einige Teile der Anwendung Wandern nachher ermutigt werdet. Da musste man dann ganz genau nachdenken, dass man da jetzt nicht dem Singleton irgendwie einen State verleiht, der dann von zwei setzt, sich gegenseitig überschreibt oder solche Dinge.

Da kann man perfekt wie Pattern einzelne Instanzen pro Thread Instance Ihren oder eben das ist ja fast schon dein generische Inversion of Control Anwendungs Design. Was du beschreibst.

Genau. Aber da fehlt ein bisschen die Zeit, dann auch für irgendwann. Aber ich würde sagen, dass das der wichtigste Punkt war, weil das einfach ein Konzept ist, was keiner von uns beiden zu dem Zeitpunkt wirklich angewandt hatte. Mal im Alltag, in der Programmierung und wenn man sich damit mal ein bisschen intensiver auseinandergesetzt hat, vielleicht auch auf einer theoretischen Ebene und an einfachen Beispielen angefangen, dann erleichtert das den Einstieg vor allem ins Design von so einer Anwendung, weil wenn man ständig wieder drei Schritte zurückgehen muss, um dann den Ansatz für eine Problemlösung doch nochmal komplett auf links zu drehen, weil man eben genau bei dieser Inversion of Control irgendwie das konzeptionell dann doch nicht richtig gemacht hat für den eigenen Anwendungsfall Gespartes schon.

Zeit, wenn man da einfach von vornherein das bei seinem Design Pattern berücksichtigt, als sie die Anwendung designt habt. Ich meine, wir haben eben schon kurz drüber gesprochen, habt ihr genug Beispiele für Spring gut Problem im Internet gefunden, also Bildung. Die Seite haben wir erwähnt und auch sonst bei Stack Overflow hattet ihr Immi Probleme für euern Fall was zu finden oder war das eigentlich immer gut? Wie würdet ihr die Dokumentation Situation einschätzen?

Ich würde sagen, Bildung war da sehr umfangreich. Es kam ein paar Mal vor, dass ich nach dem hin. Das reicht mir jetzt nicht nochmal einen halben Tag auf die Suche im Internet gegangen, nur um dann am Ende beim gleichen Bildung Artikel wieder zu landen und zu sehen. Okay, eigentlich stimmt es ja doch, was hier steht. Und wenn man es richtig liest und einen mit ein bisschen Abstand nochmal liest, dann steht da eigentlich alles drin.

Ich glaube, bei sehr spezifischen Problemen kommt es dann wie eigentlich immer ein bisschen aufwändiger werden zu recherchieren. So grundsätzlich war das Vorhandensein von Documentation ja schon gut ausgeprägt, aber ich erinnere mich, dass wir bei dem Thema Parallelisierung und dann eben Multi Reading unserer Anwendung doch die eine oder andere technische Hürde hatten, die ein bisschen schwieriger zu überwinden war, sowohl vom Design als auch von der technischen Umsetzung nachher, was dann auch ein bisschen mehr Recherche und Refactoring bei uns dann eben auch nötig gemacht hat.

Aber das sind dann schon sehr spezifisch die Themen der parallele Entwicklung oder?

Neben läufige Entwicklung ist natürlich immer noch ein Komplexität Stufe höher, einfach weil man eine ganze Menge bedenken muss, damit das auch funktioniert.

Ich hatte noch einen zweiten Fallstrick. Vielleicht hat mir eben am Anfang schon über das dpa gesprochen und wie Einfaches zu sagen gemacht hat, die Datenbank aufzubauen. Man hat dann aber am Ende schon gemerkt, wenn man relativ komplexe Abhängigkeiten mit mehreren von Civey, Strands und auch Manitoba Bennie Relationships. Irgendwann kommt man dann halt auch da ans Ende dieses Modells und kommt dann halt an Stellen, wo es dann noch mal her sich herausstellt. Okay, wenn ich das jetzt aber von der Seite aufziehe, funktioniert es perfekt und von der anderen Seite generiert es mir dann halt ganz ineffizienten ASCII Code.

Da muss man dann halt ein bisschen aufpassen, wenn man da angelangt ist.

Also einfach ein bisschen Augen offenhalten und vielleicht nicht nur eine Doku Stelle im Internet aufsuchen, sondern 2 3, um dann eben das für sich passende da rauszusuchen.

Genau da braucht ein bisschen mehr Recherche und muss sagen ein bisschen auch selber mehr ausprobieren, was dann da der beste Ansatzes würde.

Dir den Spring Boot als Plattform weiter empfehlen oder nochmal verwenden, wenn ihr eine weitere Java Anwendung in sagen wir mal im Kybernetisch Cluster betreiben wollen würdet oder auch einfach so auf dem Server betreiben wollen würdet.

Auf jeden Fall. Also ich würd mit nichts anderem anfangen wollen in Java.

Ich denke auch, dass sich das als Blaupause und Grundlage für, ja als die Fall regelrecht für Java Anwendungsentwicklung nehmen würde, weil die meisten Anforderungen aus Umgebungen kommen, wo man das eben gut umsetzen kann. Ich meine missis in den letzten Jahren nichts untergekommen, wo man jetzt auf einen klassischen ein Maschienen Server oder einen großen Mainframe irgendwas hätte entwickeln müssen, sondern man kommt eben immer eigentlich gerade wenn es Java sein soll in diese Microservices Richtung bzw. kann seine Anwendung zum Lösen eines Problems so Design, dass sie auch sinnvoll so umzusetzen ist.

Und dann ist Spring Boot wirklich ein Top Tool würde ich jetzt sagen. Und das ist doch glaube ich für den Einstieg gut. Also wenn man sagt, man kann bisschen programmieren, man kann objektorientierte programmieren, dann steigt man in Java ein, dann kann man mit Spring Boot auch sehr zufriedenstellend schnell ein Ergebnis erzielen, was wirklich Produktions reif. Innerhalb kurzer Zeit ist das eine tolle Sache.

Da kommt glaube ich dieses Opinio Native was du meintest Magix gut durch es. Es hat halt an vielen Stellen einfach sinnvoller die Falz und außer wenn du weißt, dass das unbedingt anders haben willst, ist halt anders. Aber der Default ist erstmal sinnvoll.

Ja genau. Also diese Opinio native Settings spielen eine Rolle. Deshalb läuft die Anwendung sofort, weil man im Grunde alles hat, was eine Anwendung benötigt. Der Webserver oder der Tomcat in dem Fall ist eingebaut, Matrix sind eingebaut, Health Checks sind eingebaut. Externe Konfiguration, also das Laden von Settings aus Properties. Falls wenn man zum Beispiel einen Dart Mac anbinden möchte und da ein Username Passwort und Connection String hinterlegen muss, ist dabei. Also ja, es funktioniert direkt und man kann dann anpassen, was man braucht.

Ich fand euer Beispiel sehr schön, weil ihr eigentlich ein Micros Service der Daten Transformationen hauptsächlich Macht implementiert habe, dann aber gesehen hat. Oh wir müssen noch irgendwie eine Web Komponente nachrüsten, weil wir statische Dateien aus liefern möchten oder Web Dateien ausliefern möchten. Ist das wirklich für eine Web Oberfläche gedacht gewesen, als wo jemand auf diesen Service springt und im Browser etwas machen kann? Oder war das einfach nur um Dateien auszulagern, die für diese Transformation notwendig sind?

Das war tatsächlich dann eine Oberfläche. Einfach weil sonst der Zustand der App ein bisschen schwierig zu monitoren waren. Brauchten wir da etwas, um den Überblick der dem Garzón in dem Fall zu behalten? Einfach weil ja da mehrere Zehntausend. Datenpunkte migriert werden mussten und das durch verschiedene Snakes durch. Erstmal exportiert werden musste, im neuen System importiert. Nebenbei noch Sachen hochgeladen werden mussten und da den Überblick zu behalten. Damals hat man ja im Frontend für gebastelt. Okay.

Und das Frontend ist nur für euch gewesen. Oder guckt der Kunde das auch an, wenn er diese Software einsetzt?

Das war jetzt in dem Fall für uns mehr als die Person, die dann die eigentliche Migration macht. Was in dem Fall ein Kollege von uns ist. Also nicht ganz für uns selber, aber der Kunde benutzt es in dem Fall nicht.

Er könnte es aber benutzen, wenn er wollte. Wenn die Anwendung in unserem Fall, auf dem wir entwickelt haben und er unser Benchmark Punkt war Björn ist gerade gesagt, ein paar 10 000 Datenpunkte, um die es ging, da war die Laufzeit für den kompletten Migrations Prozess im Bereich von Stunden. Das ist was, was man theoretisch morgens starten. Und wenn man es Büro verlässt, ist die Anwendung fertig betreiben kann.

Nicht nur theoretisch, sondern praktisch, ja sogar richtig.

Das wird sich dann hoffentlich bald zeigen. Aber es gab auch den Use Case. Ein bisschen mehr in der Zukunft, dass wir über mehrere 100 000 Datenpunkte vergleichbare Einzel Größe reden. Und dann würde die Anwendung halt schon deutlich länger laufen und man möchte vielleicht aktives Monitoring davon haben. Und das wäre eben darüber möglich gewesen, dass man dann eben mal reinschaut, wie es gerade der Stand der Dinge.

Und insbesondere hat dieses Webforen dann letztendlich nichts anderes getan, als gewisse Endpunkte unserer App anzusprechen. Und mit diesen Endpunkten hätte man dann auch ein beliebiges anderes Monitoring aufziehen können.

Na okay, ater sind die nachgerüstet von Matrix, die ihr eingebaut hat.

Unter anderem genau Azawad. Einige Standards, Sachen wie ihr Herzschlag und Memory Konsumption. Aber dann halt auch einfach wie viele sind schon prozessiert?

Wie viele sind in den unterschiedlichen Stages der Migration solche Sachen? Den letzten Fallstrick hatte ich noch als beiten Entwickler. Man muss sich an die Annotationen gewöhnen, dass sie einfach was ganz anderes sind als Payton Annotationen. Wenn man damit dem momentanen Modell sich einmal umgedacht hat, dann funktioniert es. Also das ist halt wirklich nur Annotation. Sind also zusätzliche Informationen, die dann irgendwie interpretiert wird, nicht Code, der ausgeführt wird.

Die Annotationen gibt es auch in neueren Pfeifen Versionen, zum Beispiel bei den Data Classes und ich hatte das so verstanden, dass die was ähnliches machen wie auch in der Java Welt oder ich hab sie so benutzt.

Sie sehen ähnlich aus, aber letztendlich sind sie nichts anderes als Haja oder Functions. Also die Funktionen als Argumente nehmen und dir deine modifizierte Funktion zurückgeben. Während Java Annotationen ja eigentlich nur ein Hinweis an ein Paket sind, jetzt irgend eine Magie zu verführen, aber nicht an den Annotation selber gekoppelt ist. Klar, man kann Annotation auch selber schreiben, aber es ist schon so, dass die Annotation so eine Art Auszeichnung sind, um die nachfolgende Funktion oder so eben zu Parameter visieren oder das nachfolgende Objekt genau innehabe.

Das eigentlich paar Interesieren passiert in Java soweit ich es verstanden hab, ja nochmal einfach anders. Also irgendetwas anderes nimmt dir Annotation und macht dann etwas damit Sphären in Python. Es ist die Annotation selber, die etwas macht.

Genau das Spring Framework werte die Annotationen aus und sagt Ach guck mal, hier ist ein Auto Wired, da muss ich ja diese Biene reinstecken, die ich hier initialisiert hab. Also das kann man vielleicht noch sagen, das Spring Framework geht hin, wenn die Anwendung gestartet wird, guckt das alle Bins also also eine Java Klassen hier als Service definiert habt oder als Controller definiert habt, guckt es an, instanziiert diese Klassen und dann erst guckt es in die einzelnen Klassen rein.

Wo steht dein Auto Wired und stöpseln jetzt diese initialisiert Klassen eben zusammen, damit die Anwendung loslaufen kann? Das passiert sozusagen alles im Vorfeld von dem Framework selber. Wenn ihr Fragen habt oder Feedback, sendet uns gerne eine E-Mail an Podcast Skill bei Tee. Wir freuen uns immer über Bewertungen und wenn ihr den Podcast an Freunde und Kollegen weiterempfehlen, die sich für ähnliche Themen interessieren. Wenn ihr aktuell im IT-Bereich auf Jobsuche seid, schaut gerne auf das G.H. Die Slash Job Seite vorbei.

Weitere spannende Technologien Themen findet ihr auch im Skill Bait Blog. Oli Andreas, ich danke euch ganz herzlich, dass ihr heute Abend meine Gäste wart.

Danke Maurice. Es war mir eine Freude. Ich wünsche euch beiden noch einen schönen Abend. Danke dir auch.

Maurice KnoppSkillbyte Podcast #45: Das Spring Boot Framework
Mehr

Skillbyte Podcast #44: Mentoring für IT-Fachkräfte

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Mentoring für IT-Fachkräfte

// Inhalt //
01:00 – Intro Dr. Tina Ruseva von Mentessa.com
01:30 – Definition und Bedeutung von Mentoring
05:23 – Faktoren für erfolgreiches (IT)-Mentoring
06:50 – Abgrenzung: Unterschied zwischen Mentoring und Coaching
09:50 – Mentoring für IT-Fachkräfte
11:03 – yCombinator Mentoring: Modell der Zukunft?
17:17 – Tina’s Mentoren
18:44 – Bedarf für IT-Mentoring; Diversity, Kulturwandel, Millenials
25:16 – Wie Mentoren bzw. Mentees finden?
27:26 – Mentoring-Netzwerke sind bereichernd
29:47 – Literatur Tipps zum Thema Mentoring
31:54 – Was ist Mentessa.com?
36:28 – Welche Mentoring-Themen sind von IT-Fach- und Führungskräften besonders gefragt?
39:51 – Ist Online-Mentoring möglich?
43:08 – Fallstricke beim Mentoring
48:05 – Mentoring Success Stories
49:35 – Mentor oder Mentee gesucht? Sprecht Tina an 🙂

Show Notes:

Buchtipp: Harvard Business Essentials: Coaching and Mentoring: How to Develop Top Talent and Achieve Stronger Performance
Link: https://www.amazon.de/Coaching-Mentoring-Stronger-Performance-Essentials/dp/159139435X

Buchtipp: Der Mentoring Kompass für Unternehmen und Mentoren
Link: https://www.amazon.de/Mentoring-Kompass-Unternehmen-Mentoren-Erfahrungsberichte/dp/3658225297

Mentessa.com skillbasierte Plattform für Mentoring- und Wissensnetzwerke https://mentessa.com
Kontakt zu Mentessa.com: https://mentessa.com/contact

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Ich glaube, da kann sich jeder von uns privat hineinversetzen. Wie wäre es, wenn wir Mentoring als durch People Grow definieren, also Menschen beim Wachstum helfen? Und wenn wir von unserem Arbeitgeber sagen Du bekommst einen Mentor, sprich We want you to grow. Das ist natürlich eine viel bessere Basis als We want to fixie. So viel öfters finden wir diesen Ansatz in Performance, Reviews etc. drÃngt.

Herzlich Willkommen zum Skill by Podcast Episode Nr. 44 Mentoring für IT-Fachkräfte Abonniert unseren Kanal und unseren Podcast für mehr spannende Themen aus dem Technologie, Umfeld, Venia it Entscheider oder IT-Fachkräfte Seite. Wir freuen uns immer über Hörer, Fragen an Podcasts. Je weiter man uns einen riesen Gefallen tun wollt, dann lasst uns gerne eine Bewertung dar. Auch freuen wir uns sehr über Weiterempfehlung an Freunde und Kollegen, für die die Themen auch spannend sind. Heute habe ich einen ganz besonderen Gast hier, nämlich Dr.

Tina Josepha, Gründerin und Geschäftsführerin von Mend Tessa Kommen, ausgebildeter Coach, Buchautorin und Kino.to Speakern. Hallo Tina, schön, dass du da bist.

Hallo Morris, vielen Dank, dass ich da sein darf. Und in dieser Runde bin ich natürlich vor allem Vollblut Informatikerin, die sich sehr für Technologie begeistert. Das freut mich.

Also ich freue mich genauso, dich heute hier zu haben und mit dir über das Thema Mentoring zu sprechen. Wie bist du denn? Vielleicht erinnerst du dich noch an das Thema Mentoring gekommen. Was war dein erster Kontakt damit?

Das ist wirklich eine tolle Frage, die ich oft beantworten muss, denn das Thema Mentoring ist ein bisschen so staubig. Es ist ein wenig Mentoring Hype gewesen in den Achtzigern oder nicht Hype, sondern ein Thema gewesen. Und man fragt sich jetzt ja warum, woher und wie kann das cool werden? Und in der Tat bin ich auf die Idee für mein Testa durch meine persönliche Erfahrung als Informatikerin gekommen. Ich bin nämlich eine von wenigen Studierenden gewesen an der Uni Women in Tech, sagt man heute.

Damals hatte sich gar nicht so cool angehört. Es war aber genauso einsam. Und natürlich war ich als solche die Mischehe, eine von vielen Mentoring-Programm, die es an der Uni gab. Für Frauen, aber später auch im Beruf. Irgendwann hab ich dann promoviert. Ich hab dann selber ein Startup gegründet und ich blieb die Micheline von solchen Mentoring-Programm. Aber eben als Mentorin. Und ich habe seit 2012 mich sehr intensiv engagiert in dutzenden Programmen als Mentorin. Und ich habe selber auch ein paar Mentoring Programme gestaltet.

Und mittlerweile blicke ich auf die Erfahrung von circa 30 Programmen zurück. Also 32 sind es Stand heute. Und das, was sie alle vereint, ist das grossartige Engagement von vielen Menschen, die sich ehrenamtlich dafür als Mentorin einsetzen. Das großartige Interesse von vielen anderen Menschen, die sich dafür interessieren und die das gerne in ihr Leben mitnehmen möchten. Aus beruflichen Gründen oder einfach aus privatem Interessen. Und dann das großartige Scheitern von diesem Programm, wenn es darauf ankommt, das richtige Matching zu machen, sodass die Mentoren und die Montez richtig zueinander geführt werden.

Das richtige Onboarding zu machen, sodass alle das gleiche Programm bekommen. Und vor allem scheitern diese Programme daran, dass heute Matschen kein großes Thema geworden ist und niemand von uns sich von jemandem matschen lassen möchte. Heute sitzen wir im Paradox zwischen dem Wunsch nach Hörster Individualisierung, persönlicher Anpassung, aber auch nach dem Wunsch für Effizienz, für Garni Zeit darin investieren. Und wie macht man automatisch individuelles Matching? Und das begeistert mich an dem Thema. Ich glaube, das kann Mentoring für viel mehr Menschen öffnen.

Und vor allem in der Arbeitswelt, wo wir mit Testa anbieten, für sehr viel mehr Vielfalt, für sehr viel mehr interdisziplinäre Zusammenarbeit, für sehr viel mehr Kreativität und Innovationskraft sorgen. Und das begeistert mich.

Das heißt, dein Hintergrund ist früher als Mentor gestartet und über die Zeit selber zum Mentor geworden und hast dich intensiv mit dem Thema beschäftigen können. Was bedeutet denn für dich Mentoring? Also vielleicht kannst du so eine kurze Definition geben oder der Begriff verändert sich ja auch je nachdem, wie man ihn einsetzen möchte. Aber was bedeutet Mentoring genau für dich?

Mentoring? Für mich bedeutet To help people grow. Das ist eine gängige Definition. Die habe ich auch nicht selber formuliert, sondern vom Buch von Sheryl Sandberg, die berühmte CEO von Facebook. Auch ein IT Lied, wenn man so möchte, eine berühmte Führungskraft in der Tech Welt übernommen und in ihrem Buch beschreibt sie die Erfahrung als eben bekannte Führungskraft von ganz, ganz vielen Menschen stetig auf Mentoring angesprochen zu werden und eben als Mentorin angefragt zu werden. In dem Buch sagt sie Es ist aber schwer, ja zu sagen, denn Mentoring means helping people grow.

Das bedeutet, dass ich die Personen kenne, weil damit ich möchte, dass jemand sich weiterentwickelt. Dann brauche ich eine in Bezug zu dieser Person und eine Beziehung dazu.

Man muss ja wissen, in welche Richtung die Person wachsen möchte oder wachsen kann oder wo sie unter ihrem Potenzial steht. Also im Grunde braucht man schon so eine Art von. Wissenschaft, um gutes Mentoring durchzuführen, oder? Ja, auf jeden Fall. Oder zumindest eine richtige Beziehung. Und das ist meine Definition geworden. Ich glaube, Mentoring ist eine persönliche Beziehung wie jede andere. Die benötigt Zeit, um sich zu entfalten. Sie benötigt auch ein Bewusstsein dafür, dass es sie gibt und auch einen Einsatz von beiden Seiten.

Ein Commitment. Und natürlich wie jede gesunde Beziehung ist es auch eine, die auf Freiwilligkeit besteht und nicht auf Abhängigkeit. Und das ist sozusagen die Elemente, die für mich mein Twink ausmachen.

Ja, Mentoring hat ja ganz inhärent so eine Freiwilligkeit. Wenn du das nicht freiwillig machen würdest, dann wäre das ja im Grunde wie Schule. Also jemand setzt dir quasi den Lehrplan vor und sagt dir, in welche Richtung du wachsen willst. Mentoring setzt ja schon voraus, dass der Mensch tief wachsen möchte und der Mentor ihn sozusagen an die Hand nimmt, auch im deutlichen Informationsvorsprung bei dem Thema hat und eben sagt Okay, komm, ich zeig dir, wie ich arbeite und dann lernen wir beide voneinander.

Also ich finde, beim Mentoring ist auch immer wichtig, dass es so eine bilaterale Beziehung ist, also dass nicht der eine den anderen hochhebt, sondern dass beide die unterschiedlichen Perspektiven des jeweils anderen dann verstehen können und beide letztlich auch was davon haben.

Das hast du schön gesagt. Genauso ist es. Und genau da liegt z.B. auch der Unterschied zwischen Mentoring und Coaching. Auch eine Frage, die ich oft beantworte. Ich glaube, eine Frage, die sich viele von uns stellen, wenn sie mit dem Wunsch für berufliche Weiterentwicklung aufwachen Was brauche ich jetzt? Brauche ich einen Berater, einen Coach, einen war die einen Mentor? Und die Antwort hierzu gibt es in Dutzenden von Studien und Sachbüchern von Harvard Business School bis hier an der LMU München forscht ein Team auch über das Thema.

Aber die Unterschiede sind in drei Kategorien. Und einer davon ist in der Tat Coaching kann tatsächlich eine berufliche Vereinbarung sein. Das heißt oft Besonders wenn wir im Unternehmens Kontext uns diese Begriffe anschauen, ist Coaching eine stille Vereinbarung, eine stillschweigende Vereinbarung zwischen Führungskraft und implodierte. Also nicht ganz freiwillig. Das ist etwas, was passieren kann und was er wünscht ist, aber eben stattfindet, wenn sie stattfindet. Und Mentoring ist immer auf Freiwilligkeit basieren.

Klar, ich würde das so abgrenzen, um das einfach mal mit einem plastischen Beispiel zu unterfüttern sagen, weil jemand ist ein ganz toller Verkäufer und ein Junior Verkäufer sagt Oh, das möchte ich auch werden und schließt sich eben mit dem Star Verkäufer zusammen. Und der Star Verkäufer ist ja dann tendenziell etwas älter, weil er schon viele Jahre Berufserfahrung hat. Und dass da Verkäufer zeigt dem jungen Verkäufer wie er arbeitet und wie er so erfolgreich ist. Und der junge Verkäufer zeigt quasi dem älteren Verkäufer, wie die Jugend so tickt oder worauf sie achtet.

Und so lernen beide voneinander. Coaching sehe ich eher so Stell dir vor, du bist Manager und du bist es gewohnt, Teams zu führen. Und jetzt steigst du auf und hast irgendwann sehr viel repräsentative Funktion, muss vor großen Menschenmengen sprechen usw.. Dann würdest du in ein Coaching gehen, in ein Präsentation Coaching, in ein freies Reden Coaching, wo du dann gezielt diese Skills von dem Coach lernen möchtest. Und das ist auf jeden Fall so eine Geschäfts Vereinbarung.

Vielleicht spreche ich nicht so gut Englisch, dann möchte ich ein Englisch Coach haben, der mir ermöglicht vor englischem Fachpublikum frei zu sprechen. So, das wäre für mich Coaching, aber nicht unbedingt Mentoring.

Genau. Und weil du jetzt über Englisch sprichst, fällt mir gerade eine supertolle Differenzierung zwischen den beiden auf Englisch Coaching ist about the job. Mentoring ist but your career. In diesem Sinne definiert man Coaching als eigentlich einen Unterteil von Mentoring, was etwas viel Größeres ist und eben auch Raum gibt für diese Beziehung. Und damit fangen die Probleme mit Mentoring im beruflichen Kontext schon mal an. Denn Beziehungen im Unternehmen sind sowieso schwer natürlich zu schaffen, besonders in der Art und Weise, wie wir arbeiten, also oft noch mit Silos denken und ganz klare Trendwenden zwischen den Abteilungen und den Funktionen.

Und mit diesem Hirarchie denken. Und da sehe ich ein Riesenpotenzial. Und damit sind wir beim Thema Mentoring für IT-Fachkräfte. Denn gerade heute, wo unsere Welt quasi Technologie getrieben ist, ist es für die Unternehmen notwendig, auch Personal von der IT-Abteilung zu Führungskräften auszubilden, in anderen Abteilungen zu integrieren oder einfach den Austausch zwischen diesen zu ermöglichen. Und gerade da sehe ich ein richtig großes Potenzial vom Mentoring als Instrument, die für andere greifbarer zu machen, aber auch für die IT.

Die Wege in die Organisation zu schaffen, damit organisch weitere Innovationen. Geschaffen werden können und Beziehungen entstehen können. Du sagst es im Grunde schon. Die Technologie wird immer wichtiger. Und so ein CTO, der ja auch, ich sag mal Führungskraft ist oder vorwiegend Führungskraft und ganz wenig nur noch Fachkraft ist, der hat natürlich eine riesen Verantwortung für das Unternehmen, für den zukünftigen Kurs des Unternehmens, da die richtigen Entscheidungen a zu treffen und b dann auch so zu kommunizieren, dass die Fachkräfte das dann mittragen wollen und mit umsetzen wollen.

Also das ist definitiv ein ganz wichtiger Bereich für die Wertschöpfung. Wo wir noch über Mentoring sprechen, hattest du mir von dem Why Kombinats Modell erzählt. Das ist ja sozusagen Mentoring auf Steroiden. Möchte sodass kurz nochmal erläutern.

Ja, das ist wirklich eine super interessante Entwicklung, die ich beobachtet habe. Vielleicht kurz zu meinem Hintergrund Ich hatte einen Startup und bin dann als zweifache Mutter irgendwann ausgestiegen. Zurück ins Büro. Und was macht man als Start up Gründerin? Ich habe in der Gründer Förderung gearbeitet, fünf Jahre in verschiedenen Großkonzernen, aber auch in öffentlichen Einrichtungen. Und unter anderem haben wir Mentoring Programme für Startups umgesetzt. Aber ganz, ganz viel Forschung betrieben. Und ich habe so die beiden Ökosysteme in Deutschland und Amerika verglichen.

In Bezug auf die Qualität der Startups, auf die Innovationskraft z.B. Patent Anzahl. Und ich habe wirklich nach sehr sehr sehr viel Einlesen einen großen Unterschied zwischen den beiden Ökosystem gefunden. Jetzt bin ich gespannt. Und zwar Mentoring. Und zwar genau einer. Denn wenn man das verfügbare Kapital, die Anzahl an Innovation und alles andere skaliert auf die Größe der Märkte, stehen wir dem Ökosystem in Silicon Valley nichts nach. Aber der entscheidende Faktor Mentoring hinkt in Deutschland noch hinterher.

Das ist viel mit unserem hierarchischen Denken hier in Europa, das auch noch in der Arbeitswelt herrschend ist, verbunden aber auch mit anderen Faktoren. Und im Zuge dieser Recherche habe ich eigentlich eine kleine Evolution von dem Begriff Mentoring festgestellt. Mentoring gibt es ja seit Odysseus und seit Mentor Telemachos quasi weiterbilden und auf ihn aufpassen musste, weil sein Vater im Trojanischen Krieg gekämpft hat. Also richtig lig dich lange. Dann gab es das eben in den Achtzigern im Corporate Umfeld auch mit verschiedenen Programmen langsam in die akademische Welt überfließen.

Und irgendwann passierte es, dass Why Kombinate das erfolgreichste Accelerator weltweit bis heute kam und bot eine andere Art von Mentoring an und zwar kein Programm. Zwar ist das Kombinate selbst ein Programm, aber das Programm besteht ja darin, dass ich Recht auf Mentoring bekomme und zwar nicht auf ein Mentor. Ich werde nicht einmal gemacht, so wie das hierzulande üblich ist, sondern ich bekomme ein Pool aus Mentoren und kann je nach Bedarf gerade zu dem Zeitpunkt, wo ich Probleme lösen muss, in verschiedenen Fachgebieten, was weiß ich Finanzierung, Marketing, Business Development, produktive Axels cetera kann ich mir diese Mentoren, wenn ich will, mehrfach an Tag reinziehen.

Genau. Vielleicht sollten wir ganz kurz sagen, weil ich nicht sicher bin, ob alle Zuhörer das wissen, wie Combined da ist. Ein Inkubator also. Teams finden sich dort ein, die in sehr kurzer Zeit ein eigenes Produkt entwickeln möchten. Und hinterher entscheidet eine ganze Phalanx an Venture Kapitalgebern, welche Idee besonders vielversprechend ist, welches Team besonders gut gearbeitet hat und fördert das dann mit sehr viel Geld, um das Projekt weiterzuentwickeln. Und in diesem Schmelztiegel, wo diese Teams dann in kurzer Zeit versuchen, ihre Idee umzusetzen oder einen Prototypen umzusetzen, haben sie Zugriff auf ganz viele unterschiedliche Mentoren.

Richtig, Tina Also für Online-Marketing, für Softwareentwicklung, für Webdesign, für UX. So stelle ich mir das vor.

Ja, und genau das, was du gesagt hast mit dem CTO. Das sind alles bereits gestandene Unternehmer und nicht einfach nur Marketing, Berater oder sonstiges. Und diese neue Art von Mentoring kam aus der Startup-Szene, sozusagen aus Silicon Valley, rüber in die Arbeitswelt und rüber in die Startup-Szene nach Deutschland und geht langsam auch in die Unternehmenswelt ein. Also flexiblere Mentoring, Programme mehr, selbst gesteuertes Matching mehr. Wir Informatiker würden sagen on demand und mehr self Service. Und das ist eine super interessante Entwicklung, denn es ist nicht die erste Arbeit Innovation, die über die Tech-Branche in die Businesswelt kommt.

Also wir kennen ja schon Agave Development und drin Methoden und Virtue Teams et cetera. All das findet irgendwie heutzutage Fuß. Zuerst in im IT Raum. Ich glaube, das zeigt, dass einfach ITler super innovativ sind, sich gerne auch in dieser Technologie basierten Welt sich mit Technologien als erste auseinandersetzen und deswegen oft doch tolle Lösungen entwickeln, die dann für den Rest des Unternehmens auch machbar sind.

Das ist so verrückt, dass du das sagst. Ich bin heute mit 3 IT Leuten waren wir im Supermarkt einkaufen und den ganzen Rückweg haben wir uns darüber unterhalten, wie ineffizient das eigentlich an der Kasse ist, da einzelnd abzukassieren und so und warum wir quasi schon mit unserer Berufskrankheiten Brille diese ganzen Ineffizienzen sehen und schon 5 Vorschläge machen können, wie man das alles effizienter löst. Ja, das stimmt auf jeden Fall, dass in der IT Effizienz eine ganz starke Komponente hat und dass man sehr schnell Dinge ausprobiert, die versprechen, ein effizienter zu machen oder einen Mehrwert zu bieten.

Einfach weil es auch eine relativ junge Wissenschaft in Anführungszeichen ist und da sehr viele neue Technologien entstehen und man sowieso gewohnt ist, mit vielen neuen Dingen zu experimentieren. Aber was mich wirklich beeindruckt ist, dass du gesagt hast Okay, eigentlich liegt es am Mentoring, dass amerikanische Startups so viel erfolgreicher sind als deutsche Startups. Und ich glaube, du hast recht, in Deutschland hört man auch oft Na, ich kann nicht über meine Idee sprechen, aber das wird ganz groß.

Also gehen die Startups raus, die vergessen, dass die Leute, mit denen sie sprechen, allen Jopp haben und nicht sagen Oh, das ist eine tolle Idee. Ich lass alles stehen und liegen und programmiere eine App nach oder so. Und in Amerika ist man da sehr offen, weil man weiß, die Idee ist eigentlich nichts.

Oder ein Prozent und 99 prozent sind einfach harte Arbeit bei der Umsetzung dieser Notte Hackbrett auf jeden Fall. Ideen gibt’s ganz viele, aber die Umsetzung, die gute Umsetzung. Da liegt der Hase im Pfeffer. Hast du denn selber aktuell auch einen oder mehrere Mentoren?

Ja, also ich hab ja meine Philosophie geteilt. Ich glaube sehr am Lernen, am Wissen. Ich bin ja selber Taki. Also ich möchte auch effizient lernen. Und beim Mentoring geht es ja auch darum, dass ich möglichst schnell davon lerne. Was mich jetzt gerade beschäftigt und was ich sein will oder werden möchte und deswegen. Also ja, ich habe die ganze Zeit Mentorinnen und Mentoren und ja, die sind nicht jeden Tag die gleichen. Manchmal switchen wir die Rollen und ich glaube, das ist so die Zukunft der Arbeit.

Aber auch das heute. Denn keine einzige Person kann über eine richtig lange Zeit von so einem neuen Berufsfeld wie z.B. Entwickler oder Start up Gründer oder jetzt diese turbulente Zeit als Gründerin, wo jeder Tag sich alles ändern, umfassen und Dasein Erfahrung mitgeben. Einen Mentor hab ich doch die ganze Zeit gefühlt. Das ist meine Mama. Also sie war die jenige, die als ich sechs war nach Hause einen Computer gebracht hat und so nicht die ganze Zeit mein ganzes Leben lang verstärkt hat, einfach zu experimentieren und zu mir zu stehen.

Und an dieser Stelle schöne Grüße nach Hause. Aber so andere Personen kommen und gehen natürlich und die Beziehungen sind das, was bleibt. Ich glaube, da kann man auch andocken, wenn die gesund sind und auf gesunde Basis stehen.

Auf jeden Fall und das Vertrauensverhältnis vorhanden ist. Aber das gehe ich mal davon aus, dass bei deiner Mama das gegeben ist. Lass uns mal über den Bedarf Verity Mentoring sprechen oder Mentoring ganz allgemeine Militärbereich. Aktuell ist es ja so Die Arbeitswelt verändert sich schnell. Jetzt durch die weltweite Pandemie wird das noch beschleunigt. Die fungiert sozusagen noch als Katalysator. Die Globalisierung macht zumindest in der IT einen Riesensprung nach vorne einfach. Auf der einen Seite hat man den Fachkräftemangel, auf der anderen Seite sitzen Menschen in Ländern, wo das ich sag mal Gehaltsniveau nicht ganz so gut ist und die durch eben IT Arbeiter guten Ausweg finden können.

Das führt dazu, dass natürlich sehr viele verschiedene Kulturen zusammenarbeiten und ich könnte mir vorstellen, dass in dem Bereich ein großes Betätigungsfeld für Mentoring entsteht. Einfach, dass man die Kulturen besser versteht.

Ja, auf jeden Fall. Das ist ein Bereich, in dem man Mentoring gezielt einsetzt. Also wenn die Organisationen noch nicht von Mentoring als eine Art neue Zusammenarbeit, überhaupt als eine neue Lernmethode überzeugt ist, dann gibt es trotzdem so Programm für Diversity oder für Kulturwandel, die durch Mentoring-Programm unterstützt werden. Im Großen und Ganzen aber haben Organisationen erkannt, dass wir heutzutage in diesem schnellen Veränderungsprozess lediglich ich glaube, Studien zeigen 10 prozent unseres Wissen durch formelle Trainings erlangen und der ganze übrige Rest die 90 prozent, die entstehen durch informellen Wissensaustausch, unter anderem durch Mentoring und Coaching und andere eben Interaktionen im Büro, bei der Arbeit, die stattfinden.

Das ist so das große Versprechen. Und wenn man gezielt jetzt auf Mentoring von IT Fachkräften hinein summ, dann kommen genau die Begriffe. Die du genannt hast. Wir haben natürlich die veränderte Bedeutung von Technologie und Mentoring kann man fantastisch dafür nutzen, um eben diese Human Assets für die Organisation auszubilden, zu trainieren, gezielt diesen Fachkräftemangel zu schließen, indem man z.B. macht man das in Deutschland, indem man talentierten Azubis einen Mentor von Unternehmen an die Seite stellt. Ein zweiter Grund oder eben ein zweiter Vorteil von Mentoring, speziell Théo IT ist es, dass es ein sehr effizientes Instrument ist, um immaterielles Wissen, also um informelles Wissen.

Man nennt das Sticky neulich in das Unternehmen zu transportieren. Ob dieses sticky bedeutet, auf Englisch klebrig, ob diese klebrige Information, die sich nicht aussprechen lassen, die eben an den Personen haften, die sie tragen. Ob das Informationen sind über neue digitalen Trends? Darüber, wie soziale Medien funktionieren oder im Bereich Kultur, wie man in dem Land arbeitet oder was die besonderen Herausforderungen für Frauen in der Tech-Branche sind. Das ist hier nicht von Bedeutung. Aber Mentoring hat sich als ein toller Mixer erwiesen, um informelles Wissen über Generationen, Abteilungen und Hierarchien hinweg in die Organisation zu transportieren.

Dort ist mir gesagt, dass sehr viele Millennials mittlerweile in Unternehmen arbeiten und die einen sehr starken Wunsch verspüren nach einem Mentor.

Ja, absolut. Und das ist so der dritte Punkt und Vorteil von Mentoring überhaupt. Employee Marketing und Imprint Retention würde man auf Englisch sagen. Ja, also Millennials sind nach einem Why getrieben. Sie ziehen einen Mentor vor einem Seminar vor. Dazu gibt es Studien, z.B. von Salesforce. Salesforce kennen die meisten ITler. Hier in München haben sie einen großen Standort und Salesforce als Unternehmen, als Software. Gigant mittlerweile aber ehemaliges Start-Up hat dieses Potenzial von Mentoring früher erkannt, eben um den Fachkräftemangel zu schließen.

Auch Frauen für Tech Berufe weiter auszubilden und Salesforce haben deswegen ganz viele Studien zur Effektivität und Effizienz von Mentoring-Programm speziell im Tech Bereich durchgeführt. Diese kann man im Internet finden, aber eine Kennzahl habe ich aus einer dieser Studien, dass nämlich neun von zehn Millenniums sich einen Mentor wünschen. Und in der Studie wurden hierfür zwei Gruppen gebildet und eine Gruppe bekam jeweils einen Mentor zur Seite gestellt und die andere Gruppe keinen. Und nach Ablauf der Testphase, wobei beiden beiden Gruppen Aufgabenbereiche und Trainingsprogramm und der Rest das gleiche war, hat man die befragt.

Wie glücklich sei man mit dem Job? Welche Potenziale man darin für sich sieht und ob man bleiben möchte. Stichwort Imprint Retention. Und die Gruppe mit dem Mentor hat in neun von zehn Fällen all diese Fragen bejaht und die andere eben nicht.

Wow, okay, das ist ja schon ein ziemlich eindeutiges Ergebnis.

Ja, und man muss auch bedenken Millenniums sind in wenigen Jahren schon die Hälfte der Arbeitswelt. Da gibt es ganz unterschiedliche Zahlen hierzu. Also ich war der Meinung, dass es in den nächsten fünf Jahren auf 50 prozent zu steigen werden. Irgendwann jetzt neulich las ich, dass es bis zu 75 prozent werden. Ich glaube hier, die Message ist nicht in der konkreten Zahl, sondern liegt darin. Es gibt viele News in der Arbeitswelt. Es gibt viel Wettbewerb, besonders um die besten Kräfte.

Und Mentoring scheint nicht nur ein tolles Marketinginstrument zu sein, sondern ein wirklich effektives Mittel mit ganz vielen Vorteilen, um die besten Mitarbeiter zu gewinnen, um Mitarbeiter weiterzuentwickeln und auch um eine Kultur des Teilens und der Vielfalt zu schaffen.

A Möchtest du natürlich gute Mitarbeiter haben oder die besten Mitarbeiter haben und b wenn sie durch Mentoring noch besser werden, ist das ja auch noch besser im Grunde für das Unternehmen. Und zusätzlich sind Sie zufrieden. Das heißt, die Retention oder die Fluktuation, würde man auf Deutsch sagen, sinkt auch.

Ja, absolut. Ja gut, ich glaube, da kann sich jeder von uns privat hineinversetzen. Wie wäre es, wenn wir Mentoring als durchlebe people grow definieren, also Menschen beim Wachstum helfen? Und wenn wir von unserem Arbeitgeber sagen Du bekommst einen Mentor, sprich We want you to grow. Das ist natürlich eine viel bessere Basis als We want you to work oder We want to fixie.

So viel öfters finden wir diesen Ansatz in Performance, Reviews etc..

Wenn ich das Fach oder Führungskraft bin, welchen Rat würdest du mir geben, wenn ich einen Mentor suche? Also wie finden meine Teams zu Mentoren bzw. Mentoren, die vielleicht das Bedürfnis verspüren zu Montez?

Also dazu gibt es natürlich verschiedene. Faktoren, die eine Rolle spielen. Ich würde mir überlegen, was will ich lernen? Was ist das Ziel, was ich mit dem Mentoring verfolge? Ich würde mir z.B. überlegen Soll das ein Mentor aus dem Unternehmen sein oder jemand von extern? Ich würde mir überlegen, soll das ein Branchen Experte sein oder jemand mit einem ganz anderen Blickwinkel? Ich würde mir auch überlegen, wieviel Zeit ich darin investieren möchte und welchen Zeit Commitment ich auch davon erwarte.

Und mit diesen Kriterien habe ich schon eine ganz gute Entscheidungs Matrix und einige Möglichkeiten, die ich angehen kann. Zum Punkt 1 bieten viele Unternehmen mittlerweile Mentoring Programme in irgendeiner Form an. Oft darf man sich aber dafür nur in bestimmten Fällen bewerben, z.B. erst nachdem man zig Jahre im Unternehmen schon tätig gewesen ist oder erst, wenn man quasi als frische Führungskraft einen neuen Tenure Track beginnt. Also meistens kommen diese nicht so on demand in Frage, wie man sich das wünscht.

Man muss bestimmte Voraussetzungen erfüllen, weil natürlich Mentoring Zeit in Anspruch nimmt. Ich nehme an, Baumanns vom Unternehmen aus anbietet nimmt es natürlich Arbeitszeit in Anspruch. Und dann möchte wahrscheinlich das Unternehmen sicherstellen, dass das Mentoring auch entsprechend wertgeschätzt wird und dass das nicht jeder als Stunde Kaffeeklatsch benutzen kann.

Und deswegen lohnt es sich, sich auch nach externen Mentoring-Programm umzuschauen. Und da kommen wir zur Frage Nr. 2 Also bin ich interessiert an eben Branchen, Mentoring, Programme. Da kann ich beiden Verbänden schauen oder in verschiedenen Vereinen. Ich kann auch einfach googlen. Jetzt, besonders durch die Pandemie, gibt es ganz, ganz viele Programme, die rein digital stattfinden, bezahlte und auch unbezahlte Programme. Und ich kann aber auch mich dafür entscheiden, mich mit anderen Menschen zu vernetzen, was ich glaube heute unbedingt sehr wertvoll ist.

Wir leben ja in einer Plattform Wirtschaft. Das bedeutet, dass Wertschöpfung Innovationen in sozialen Netzen entsteht, also nicht in sozialen Medien, aber in den Köpfen von Menschen. Deswegen lohnt es sich, sich auch mit anderen Disziplinen auszutauschen, um sein Corazon zu erweitern. Besonders wenn man früh in dieser Mentoring Entwicklungsphase ist und man noch nicht so ganz genau weiß, was dabei rauskommen soll. Da ist diese Öffnung für andere Blickwinkel und für Menschen aus anderen Fachgebieten sehr, sehr fruchtbar.

Es gibt diesen Spruch auf Englisch Your Network ist ja Networks. Ist natürlich sehr platt ausgedrückt, aber es zeigt schon, dass natürlich das Netzwerk oder die Menschen, mit denen man sich umgibt, sehr deutlich auch das eigene Denken beeinflussen oder eben jemanden weiterentwickeln können, wenn diese Person auch das Ziel haben.

Und danke, dass du das sagst, weil das meiner Meinung nach ein Grund für Mentoring Programme für IT-Fachkräfte ist, der gar nicht so oft angesprochen wird. Aber wenn wir in einer Welt leben, in der Netzwerke wirklich wichtig sind und nicht einfach nur Marketing sind, sondern indem wir über Netzwerke lernen, wachsen, Jobs finden, Produkte bauen. Denken wir mal an die Open Source Bewegung und wir uns aber überlegen, was so typische ITler lieber machen würden. LinkedIn oder Reddit sehen wir schon, dass wir hierfür Programme brauchen, um vielen IT-Fachkräfte, die sich z.B. nicht trauen würden, auf andere zuzugehen, aber verdammt viel Wissen und verdammt viel Meinung auch haben und was auch zu geben haben für diese Welt.

Da sehen wir schon, wie wichtig und fruchtbar solche Programme sein könnten, die eben den ersten Schritt ermöglichen, für jemanden, der lieber Jac Kommentare liest, als solche zu schreiben, der lieber sich im Hintergrund bewegt und Sachen eher verstehen möchte, als sich im Vordergrund zu stellen und Selfies von sich zu posten. Und da glaube ich, die Brücke zwischen den zwei Welten zu schlagen, kann unheimlich bereichernd sein für alle Seiten.

Das denke ich auch. Kannst du denn vielleicht Literatur empfehlen, wenn ich z.B. jetzt noch ganz am Anfang stehe, noch keinen Mentor gefunden habe, mich dabei irgendwie mit beschäftigen möchte, um sozusagen da ranzukommen und auch für mich festzulegen Okay, was suche ich denn eigentlich? Wie gehe ich das an? Wie stelle ich dem Mentor qualifizierte Fragen? Gibt es da irgendwie in Web Ressourcen, die wir vielleicht verlinken können? Oder ein Buch, was dir sehr weitergeholfen hat oder was du empfehlen möchtest?

Auf jeden Fall. Und das können wir gerne verlinken. Ich empfehle immer ein Buch von Harvard Business Design Shows von 2004. Das heißt Coaching und Mentoring. Krauter Dehalb Top Talent in der Chief Stronger Performance. Das ist ein Buch nicht nur für Führungskräfte, die sich für die Einführung von Mentoring-Programm. In der Organisation interessieren, sondern auch ein wirklich praktisches, gut durchdachtes, sehr prägnantes Ratgeber auch für jeden, der sich mit Mentoring neu auseinandersetzen möchte.

Und trotzdem zeitlos, trotz seines Alters von ja nun, fast 17 Jahren. Absolut, ja.

Ja gut. Ich glaube, das spielt auch die Harvard Autorität seine Rolle. Aber das ist so mein Stammbuch. Ein zweites Buch kann ich gerne empfehlen aus dem deutschen Sprachraum, und zwar von Stefan Flaum, ein Forscher von der LMU München. Meine Alma Mater und auch der Programmverantwortlichen für das Mentoring an der LMU München. Das Buch heißt der Mentoring Compas für Unternehmen und Mentoren und ist im Springer-Verlag vor wenigen Jahren erschienen. Ich finde das super praktisch mit ganz vielen z.B. Frage Listen und Tipps für das Matching kann man auch sowohl als Mentor als auch als Monti als auch als Organisations Entwickler für die ersten Schritte im Mentoring nutzen.

Was ich natürlich gerne empfehlen möchte, ist man Tessa zu folgen auf sozialen Medien. Denn auch wir bemühen uns, viel über dieses Wissen zu transportieren. Denn wir glauben, ein Umdenken bezüglich Mentoring ist notwendig, damit wir überhaupt ein Umdenken in der Arbeitswelt schaffen können.

Genau. Lass uns mal über mein Thema Punkt kommen sprechen. Du hattest mir gesagt, ihr versucht das Organigramm so umzustellen, dass man Task Force Gruppen vereinzelt Themen erstellt und nicht mehr so einen streng hierarchischen Baum, wie das oft noch der Fall ist.

Mein PC ist eine Skill basierte Plattform für Mentoring und Wissens Netzwerke. Das bedeutet, wir ermöglichen es, dass man liquide Strukturen wie z.B. ein Netzwerk, ein Verein, eine Work Force organisiert, dass man bestimmte soziale Regeln anwendet, aber bestimmte Freiheit und Macht Möglichkeiten effizient ermöglicht. Und damit kann man natürlich das Organigramm ersetzen. Denn dieses ist heutzutage immer noch in den meisten Unternehmen, die ich kennengelernt habe, das Instrument, indem man denkt bezüglich Kommunikation, Zusammenarbeit in Projekten, Führungskräfte, Entwicklung oder Talent Entwicklung.

Und das ist schade, denn wir müssen alle etwas schneller werden, etwas kreativer, etwas mehr miteinander wagen. Also nicht nur aus Solidaritäts Gründen, sondern aus wirtschaftlichen Gründen. Und auch wollen Menschen Hierarchien immer weniger. Und zwar nicht Hierarchien in dem Sinne, dass man keinen Vorgesetzten haben möchte. Wir haben dazu Befragungen durchgeführt und ganz interessant. Also wenn man sagt, ich möchte in einem Unternehmen mit flachen Hierarchien arbeiten, dann meinen die Leute gar nicht, dass sie keinen Chef haben wollen.

Das, was man meint, ist, dass man näher mit seinen Peers auf der gleichen Ebene zusammenarbeiten möchte. Und das ermöglichen wir mit Mindestziel. Denn bei uns kann man sehr einfach auf Basis von Skills eine Person finden, einen Termin vereinbaren, mehr mit der Person machen, die Gespräche bewerten, sich in einem Programm anmelden und diesen gesamten Prozess hintendran, das gerade von Personen gemacht wird und deswegen die Programme für so wenige freigegeben sind.

Digital abbilden eurer Zielgruppe sind aber nicht nur IT-Fachkräfte, sondern generell ja Facharbeiter unterschiedlicher Branchen. Oder gibt es dann ein Schwerpunkt?

Also meine These ist an sich eine technologische Plattform. Wir bieten diese an Unternehmen an, die sie für ihre Initiativen und für ihre Mitarbeiter verwenden. Das heißt, wir haben keinen Branchen Fokus, bieten aber die Plattform vorwiegend an Unternehmen mit mehr als 250 Mitarbeiter an. Denn dann wird es für die Mitarbeiter selbst oft unübersichtlich. Dann wird es auch für die Personalabteilung nicht mehr so intim. Und man kennt die Personen nicht. Wie soll man sie machen? Oft sind es keine Programme, die rein für ITler gedacht sind, aber solche, die ITler mit anderen auch sehr gut vernetzen.

Okay, also doch IT. Schwerpunkt, aber nicht ausschließlich. Es richtet sich dann eben nach der Firma, die eure Lösung einsetzt oder nach der Branche der Firma. Genau.

Oft ist das Thema Diversity da noch wichtig oder Innovations Netzwerke und da spielt das Thema eine Rolle.

Wie funktioniert das dann? Dann können sich Leute, die Mentor werden möchten und Leute, die Mantis sein möchten, auf der Plattform registrieren innerhalb der Firma. Und die finden dann zusammen. Oder wie ist da der Prozess?

Genau so meine These ist eine Whitley Bohrplattform. Die wird vollständig in die bestehenden Kanäle und Tools vom Unternehmen integriert. Das heißt, von außen sieht man nicht, dass man beim Interesse ist, sondern das sieht wie der Rest des Intranets aus oder einfach wie ein. Ein bisschen schönere App auf der Plattform kann man sich frei vernetzen. Also dass es dieses angemahnten Self Service Faktor, den wir besprochen hatten, aber auch kann man sich dort ganz formell für Mentoring-Programm bewerben, die komplett über die Plattform abgebildet sind.

Das heißt, der gesamte Prozess von Bewerbung, Zulassung, Matching, tatsächliches Mentoring, Terminvereinbarung und dann Evaluierung und eben Auswertung von Mentoring Ergebnissen. Das findet alles über unsere Plattform statt, ohne den Bedarf von technischem Aufwand.

Ja, das war cool. Als wir unser erstes Gespräch hatten, hast du mir auch einen Link zugeschickt, wo ich mir dann Termine aus deinem Terminkalender aussuchen konnte oder freie Slots. Da hab ich ja quasi schon Vorgeschmack bekommen. Ja, auf jeden Fall ne coole Funktion.

Also wir sind einfach ja auf Effizienz hinaus, oder?

Ja, kommt mir total entgegen und er fand ich cool. Hast du denn so einen Einblick? Ich meine, wenn ihr mehrere Unternehmen betreut, welche Themen besonders gefragt sind, kann man das sagen? Gibt es da Fachthemen? Vielleicht Technologie, Themen, die besonders gefragt werden oder bei Führungskräften spezielle Schwerpunkte? Hast du da einen Überblick?

Ja, das ist wirklich spannend, denn wenn man sich mit Tessa als eine Suchmaschine für Menschen vorstellt, dann erzeugen natürlich die Suchbegriffe alle zusammen und in anonymer Form eine Landkarte von den Bedürfnissen der Mitarbeiter in dem Netzwerk gerade. Und das ist eine extra Funktionalität, die wir anbieten. Diese Skills in Echtzeit zu messen und die Bedarfe auch zu ermitteln, sodass man bei großen Gaps eingreifen kann und auf Basis von Daten Programme entwickeln kann, Trainings anbieten kann, externe Coaches einladen, kein et cetera.

Aber wohl wissend, dass das jetzt wirklich gebraucht wird. Und nein, um ehrlich gesagt gibt es keine Themen. Sehr, sehr selten. Sucht man nach Klassikern und sehr, sehr oft sind es kleine Dinge, die einen in den Weg zu stehen scheinen, wie z.B. Führen in Remote Work oder Präsentation Skills ausbauen. Also wenn wir ein öffentliches Programm anbieten würden in einem Unternehmen, um diese Skills quasi um ihre Entwicklung zu unterstützen, dann würden sich wahrscheinlich wenige Mitarbeiter und vielleicht auch noch weniger IT-Fachkräfte dafür anmelden.

Aber dadurch, dass es bei MEND teste, wie in eine Art Tinder wenn man so möchte eben anonym möglich ist, erstmal nach jemanden zu suchen, sich ein Bild zu machen und dann eine Anfrage zu schicken, trauen sich die Leute auch eben wirklich, die Themen zu recherchieren, die sie interessieren.

Okay, da hilft die Plattform einfach, dass man seiner Interessenslage folgen kann, ohne Angst haben zu müssen, oh, entdeckt zu werden. Oder warum interessierst du dich denn ausgerechnet für dieses Thema?

Ja und Stichwort Millennial Welcher Millennial geht heutzutage zu a physisch? Mach die Tür auf und sagt Ich möchte ein Mentor, weil ich mit meinem Team nicht zusammenkommen kann, weil ich mich langweile oder weil ich Probleme habe in der Kommunikation. Aber jeder von uns möchte das auch in der Art machen. Und noch eine Referenz zu Silicon Valley. Ich vergleiche mit Tessa oft mit Tinder und da gehen natürlich Augenbrauen hoch. Es ist ja ein höchst unangebrachter Vergleich, wenn man über sterile Unternehmens Umgebungen nachdenkt und Online-Dating.

Aber Tinder wurde angeblich von Takis in Silicon Valley entwickelt, die sich nicht getraut hätten, auf andere zuzugehen. Und wenn man sich das Thema genau anschaut, dann stellt man schnell fest, dass im Arbeits Kontext genau die gleiche psychologische Unsicherheit herrscht, wenn es darauf ankommt, Probleme anzusprechen, sich Hilfe zu holen. Und oft sind es wirklich banale Sachen, die man zum Glück bei uns lösen kann.

Ja, das Impfstoffes Syndrome. Ob es beim Dating ist oder bei Fachthemen ist natürlich allgegenwärtig. Und ich denke, da leisten digitale Plattformen guten Dienst, dass man anonym oder pseudonym da bequem auf der Couch mal eine Anfrage stellen kann. Ja, das verstehe ich absolut. Du hast ja viel Erfahrung mit Mentoring und ich habe mal gelesen, dass es ganz wichtig ist, wenn man einen Mentor hat, dass man den regelmäßig trifft. Also wirklich im echten Leben physikalisch, dass man sich trifft, Erfahrungen austauscht und möglichst auch einen regelmäßigen Termin etabliert.

Jetzt haben wir natürlich heute durch das Internet ist die Welt quasi die Quelle für Montez und Mentoren. Funktioniert das auch rein online? Also weil ja, Mentor und Monti hat wahrscheinlich gegebenenfalls viel zu tun und sind nicht immer nah. Oder er wohnt gar nicht in meinem Land. Funktioniert auch reines online Mentoring, was wir zu sagen ja auf.

Jeden Fall also. Ich kann das absolut bejahen. Wie schon am Anfang der Sendung gesagt Mentoring ist ja eine Beziehung wie alle anderen und selbstverständlich sind Beziehungen, die in der echten Welt entstehen und gepflegt werden, mit einer anderen Tiefe vielleicht verbunden. Aber selbstverständlich können diese digital beginnen und sich auch dort entfalten. Ich glaube, was viel, viel wichtiger dafür ist, ist eben das allein man in der Erwartungshaltung zwischen Mentor und T. Dass beide diese Zeit wertschätzen, dass sie sich auch diese Zeit nehmen, dass man sich gegenseitig auch zuhört.

Das ist ein Kommunikations CEO, den viele von uns nicht sehr gut beherrschen und dass man sich ernsthaft dafür interessiert, sich beim Wachsen zu helfen. Und dann ist, glaube ich, das Medium nicht so wichtig und ich drücke die Daumen, dass die Pandemie bald vorbei ist und man solche Beziehungen auch natürlich mit offline treffen verstärken kann. Aber ja. Also hundertprozentig. Mentoring geht online und kann dort auch komplett stattfinden.

Okay, ja, das ist ein ganz wertvoller Hinweis, dass man sozusagen das Feld für Mentoring dann weltweit aufmacht. Oder man spricht vielleicht mehrere Sprachen, dann hat man diese unterschiedlichen Sprachräume eben als Quelle, aus denen man sich dann Mentoren heraussuchen kann.

Ja, ja und nochmal der Hinweis rein theoretisch wäre die ganze Welt ein Mentoring Pool. Aber wir sind schon wieder bei dieser Sache. You need to know people to und durchaus grow. Du musst die Person kennen, um ihr beim Wachsen zu helfen. Dafür sind besondere Netzwerke sehr, sehr wichtig. Man kann sich nicht über Link den einen Mentor finden. Link. Den hat eigentlich auch diese Funktion. Wer das ausprobieren möchte, kann auf Linke hingehen und eben angeben, dass man gemacht werden möchte.

Ich habe das auch ausprobiert. Circa drei Jahre. Es klappt nicht. Man wird gemerkt, man tauscht sich aus. Also hallo und höfflich. Aber dieses warum sollen wir jetzt die Zeit miteinander investieren und nicht mit jemandem anderen? Das fehlt. Und deswegen viel besser ist es, sich in einem Netzwerk einzubringen, wozu man einen Bezug hat. Und einen Tipp habe ich noch einen guten, z.B. die ehemalige Schule oder die Uni oder ein Verein, indem man es.

Diese haben sehr sehr oft Alumni Mentoring Programme, die einen matschen und die einfach eine gute erste Anlaufstelle anbieten.

Na super. Vielen Dank. Ich würde gerne noch zwei Fragen stellen, die mir unter den Nägeln brennen. Und zwar gibt es Fallstricke. Oder hast du mal erlebt, dass jemand gesagt hat Ich möchte gerne mit dem Mentoring beginnen? Also entweder aus Mentor Sicht oder aus Sicht und ja, ein vielleicht nicht so gute Erfahrungen gemacht hat. Gibt es Fallstricke? Worauf sollte man achten? Welche Fehler sollte man vermeiden, die vielleicht häufig vorkommen?

Als Mentor oder als Monti? Beides.

Fangen wir mal als Mentor an. Natürlich gibt es das und wie in anderen Beziehungen auch. Also wenn wir an Beziehungen im berufst Kontext denken, können wir doch oft fehlende Authentizität bemerken oder einfach Intransparenz oder eine gewisse Gezwungen heit. Und es gibt es auch beim Mentoring z.B. etwas, was durch die Art und Weise wie Mentoring Programme heute funktionieren hierarchisch. Dass Mentor und Mentor nicht freiwillig zueinander kommen, sondern von einer dritten Person gemacht werden, findet man sich schon immer wieder in Situationen, in dem man keine Sympathie entwickeln kann, indem man keinen Bezug zu dem Thema wachsen lassen kann, indem man einfach nicht freiwillig da ist, sondern weil man zugeordnet wurde.

Ja, wollte ich gerade sagen, die Freiwilligkeit fehlt. Das hat es ja schon angesprochen.

Ja, absolut. Das ist ein unheimlich wichtiger Faktor. Was für meine These spricht aber was überhaupt das Alleinstellungsmerkmal von Mentoring sein sollte. Es ist eine reine freiwillige Beziehung auf beiden Seiten. Und wenn man in dieser Situation ist, dann hab ich einen Tipp. Ich würde das einfach offen ansprechen und eben gemeinsam einen Plan entwickeln, wie man damit umgehen möchte, dass man jetzt gemischt ist und in dieser Situation ein Projekt oder eine Aufgabe erledigen muss, eine Periode zusammen quasi durchhalten soll.

Aber ich würde nicht so tun, als wäre das nicht freiwillig. Ein zweiten Tipp hab ich auch und das ist sozusagen ein Watch out. Denn oft finden wir diese Sympathie nicht für Menschen, die anders sind als wir. Stichwort Diversity, Stichwort Empathie. Und ich persönlich challenge mich immer in diesen Situationen über mich hinauszugehen und möglichst mich von Bayes zu befreien und möglichst proaktiv zu versuchen, meine Fühler für die andere Person auszustrecken, sodass ich. Zumindest mal kurz in ihrer Welt mich eintauchen kann offen sein und lernen.

Absolut, absolut offen sein und klären, das hast du so schön einfach gesagt. Einfach entspannt darauf sich einlassen und nicht so erstarren und das quasi innerlich ablehnen. Ja, das zweite, was passieren kann, ist die fehlende Transparenz. Und das passiert oft durch die Mentoring-Programm äh, wieder, wie sie heute gemacht werden. Ich bin für viele Studierenden und Schüler Mentorin und man sieht es bei den Schülern. Die sind wirklich oft in den Mentoring Programme, weil sie das interessiert, manchmal aber, weil sie ihre Eltern hierfür angemeldet haben.

Ich bin Mentorin in einem Gurs in Teck Programm, wo man Mädchen an die Programmierung heran bringt und dort ist es manchmal so, ja, da werden die Kinder von den Eltern angemeldet. Ein zweites Beispiel habe ich aus den Studierenden in den Programmen, in denen ich mich an der TUM engagiere. Und sonst? Und zwar ist es so, dass die Teilnahme an einem Mentoring-Programm oft sehr gut im Lebenslauf aussieht. Und oft sind die Studenten nichts an dem Austausch mit dem Mentor tatsächlich interessiert, sondern einfach an dieser Auszeichnung in ihrem CV.

Das ist eine andere Art von und Freiwilligkeit. Dort gilt genau das Gleiche Einfach Transparenz zu schaffen und das quasi möglichst zu thematisieren, aber auch offen zu bleiben und zu lernen und das nicht persönlich zu nehmen. Jeder von uns hat immer Gründe für alles, was wir tun. Das sind so die zwei grossen Stolpersteine, die ich sehe.

Also Freiwilligkeit ist ein ganz wichtiger Punkt. Und Authentizität ist ein ganz wichtiger Punkt.

Ich daraus ehrliches Commitment und das gilt ja viel. Montez wie auch für Mentoren ist im Prinzip universal gültig.

Absolut. Und danke, dass du das sagst. Denn genau andersherum gibt es viele Mentoren, die am ersten Tag, indem sie ein Mentoring-Programm joinen, das in ihrem Linkt in prophetischer Stellen aber dann doch nie Zeit haben für die Meetings und das nur so halbherzig mitmachen.

Okay, verstehe. Ja, für das Zertifikat ja.

Und da wäre ich als Monti sehr souverän. Und ich würde einfach sagen Ja, es hat mich sehr gefreut. Ich habe keine weiteren Fragen und ich würde mir einen anderen Mentor suchen, um wachsen zu können.

Um wirklich intensiven Austausch zu betreiben, muss ja ein ehrliches Interesse von beiden Seiten bestehen, dass man sich helfen möchte. Hast du denn vielleicht zum Abschluss noch Sexes Storys? Eine ganz besondere, wo du mal einen ganz besonders tollen Mentoring Erfolg miterlebt hast oder eine andere erfolgreiche Geschichte, die dir einfällt?

Ach natürlich, jetzt über die Jahre haben sich sehr schöne Gegebenheiten ergeben. Also ich meine, ich habe Tandems zusammengebracht, die dann später gemeinsam gegründet haben. Ich habe Mentorinnen, mit denen ich schon seit Jahren im Kontakt bin. Ich habe Mentorinnen, die mich später quasi zu sich ins Unternehmen Beirat eingeladen haben. Es gibt alle möglichen Fälle, wenn man offen ist zum Lernen und sich wirklich ehrlich und freiwillig einer Beziehung und ihrem bestmöglichen Zustand verpflichtet. Ich persönlich glaube, dass das Wichtigste Erfolgsfaktor ist in allem, was wir tun.

Und ich bin sehr gespannt, was wir andere Erfolgsstorys sich noch über Montessori und über unserem gemeinsamen Weg ergeben.

Da bin ich sicher, dass da noch einiges hinzukommt. Das ist ja auch oft so. Man sieht das gar nicht so, weil man jeden Tag lernt, jemanden klein bißchen was dazu. Und irgendwann nach Jahren stellt sich dann dieser Durchbruch ein. Man denkt so okay, wo kommt das her? Aber dieser tägliche Fortschritt ist halt nicht so sichtbar. Aber es ist super schön zu sehen, wenn was wächst. Und wenn Mentor und Monti voneinander profitieren.

Ja übrigends, ich biete das gerne deinen Zuhörern an. Also jeder, der ehrlich nach einem Mentor sucht oder nach einem Monti, bitte meldet euch bei mir. Ich habe ein riesengroßes Netzwerk mittlerweile über meine These kostenlos organisiert in einer offenen Community. Ich kenne die meisten Leute in dem Netzwerk auch persönlich und würde mich sehr freuen, euch dabei zu helfen, jemanden zu finden. Perfekt.

Ich stelle gerne den Kontakt Link oder deine E-Mail-Adresse in die Shownotes, sodass die Leute sich direkt bei dir melden können.

Danke gerne. Ich genieße das Gespräch mit dir, Maurice und wenn du mich gefragt hattest, kann sich sowas auch digital ergeben. Du und ich, wir haben uns ja noch nie im echten Leben getroffen und es macht so Spaß.

Vielleicht machen wir nochmal eine Folge zusammen.

Ja, absolut gerne, wenn du ein zweites Thema einfällt. Sehr, sehr gerne.

Wunderbar. Vielen Dank, Tina. Wenn unsere Zuhörer fragen. Haben oder uns Feedback senden wollen, könnt uns gerne eine E-Mail schicken an Podcast Skill bei Tee. Wir freuen uns immer über Bewertungen und wenn ihr den Podcast abonniert. Natürlich empfiehlt uns auch gerne an Freunde und Kollegen weiter, die auch über Technologie Themen auf dem Laufenden gehalten werden möchten. Für weitere Infos schaut auf das Gilbert Website Skill Bildpunkte vorbei. Tina. Es hat eine Menge Spaß gemacht heute Abend. Ich danke dir, dass du heute mein Podcast Gast warst.

Vielen Dank.

Vielen Dank.

Maurice KnoppSkillbyte Podcast #44: Mentoring für IT-Fachkräfte
Mehr

Skillbyte Podcast #43: Helm – Der Kubernetes Paketmanager

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Helm – Der Kubernetes Paketmanager

// Inhalt //
01:23 – Definition: Was ist Helm und wie wird es eingesetzt?
04:14 – Einsatzszenarien für Helm Charts
08:03 – Warum benötigt man Helm Charts ?
09:13 – Vorteile von Helm Charts und deren Einsatz
14:32 – Zusammenfassung Vorteile Helm Charts
16:12 – Von Terraform über Kubernetes zu Helm
22:18 – Beispiele: Betrieb hoch-skalierbarer Anwendungen
26:09 – Neue Anwendungen werden Cloud-native entwickelt; selten Migrationen von Bestandssystemen
29:18 – Bestandteile und Funktionen eines Helm Charts
34:25 – Handhabung von Helm auf der Kommandozeile
36:23 – Helm 2 vs Helm 3
37:35 – Flux – CI/CD in Perfektion
41:53 – Fortgeschrittene Deployments: Canary und Blue Green Deployments; Istio

Show notes:

Podcast #25: Kubernetes: Flexibles und leistungsfähiges Rechenzentrum für Unternehmen
https://soundcloud.com/skillbyte/podcast-25-kubernetes-flexibles-und-leistungsfahiges-rechenzentrum-fur-unternehmen

Podcast #36: Terraform – Virtuelles Rechenzentrum mit dem Infrastructure as a Service Werkzeug
https://soundcloud.com/skillbyte/podcast-36-terraform-virtuelles-rechenzentrum-mit-dem-infrastructure-as-a-service-werkzeug

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Das Wichtigste zu verstehen ist, dass man mit Helm eigentlich nur kybernetisch Ressourcen verwaltet. D.h. Anstatt dass ich jetzt mit meiner Cubes Btl hingehe und sage create deployment create secret create config map, sag ich einfach nur Haman Stall und im Hintergrund läuft halt genau das. Aber das Schöne an der ganzen Sache ist, dass das alles kybernetisch Native ist. Also im Prinzip kann ich es nicht best practice, aber im Nachhinein kann ich beliebig auch die Ressourcen per Hand wieder editieren.

Ist natürlich nicht empfohlen, weil dazu gibt’s ja Helm. Herzlich Willkommen zum Skill bald Podcast Nr. dreiundvierzig Helm Der Kybernetisch Paket Manager abonniert unseren Podcast für mehr spannende Technologien aus dem Technologie Umfeld, wenn er IT Entscheider oder ity Fachkraft seid. Wenn ihr eine Frage habt im Verlauf der Episode sendet uns gerne eine E-Mail an Podcasts Skill BYD Punkt D Wir freuen uns auch immer über Bewertungen und ganz besonders wichtig für uns sind Weiterempfehlung an eure Freunde und Kollegen, die sich auch für Technologie Themen interessieren.

Wenn ihr aktuell ity Jobs sucht, schaut gerne auch auf das Gebiet Jopp Seite vorbei. Ich bin heute hier mit Julius, einem DevOps Ingenieur von Skill bald und ich freue mich super auf dich. Hallo Julius, hi Maurice. Ja und heute sprechen wir über Helm und das Thema kybernetisch bzw. was Helm genau ist. Und Helm ist eine Technologie. A kann man sagen, die in den letzten 2 3 Jahren doch deutlich an Verbreitung zugenommen hat und ja auch so ein bisschen gehypt es, oder?

Ja, auf jeden Fall. Also das Tool ist ja schon ein bisschen älter. Aber wie du gesagt hast, es ist jetzt in den letzten Jahren hat das enorm zugenommen. Auch. Vor allem wird das viel verwendet. Also eingebettet in andere Systeme, wie z.B. Rangiere oder so. Also das ist auf jeden Fall sehr populär zurzeit genauso.

Entwicklungsgeschichtlich kann man ja sagen, diese Kuba Metis Infrastruktur ist entstanden und die Leute haben begonnen eben ihre Anwendungen in kombiniertes Cluster zu Diplomen, die zu managen und haben dann aber festgestellt okay, so eine Anwendung aus mehreren Microservices im Kybernetisch Cluster, das ist relativ viel Handarbeit, diese zu warten und die einzelnen Komponenten zu aktualisieren. Es wäre doch schön, wenn man so eine Art Paket Manager hätte, wie man das aus z.B. Linux-Distributionen kennt wie APT, get oder Pacman und dieses Konzept auch für kybernetisch Anwendungen, die wie gesagt aus mehreren Microservices bestehen können, verwenden kann.

Das Ziel ist es eben kybernetisch Anwendungen möglichst einfach zu managen, also wie man bei abgeht install Paket Name sagt und Linux Pakete installieren kann. Genauso möchte man das auch in der Kybernetisch Welt haben und natürlich auch genau so einfach mit einem an install. Wofür hast du denn Helm bisher benutzt?

Ja, im Prinzip genau wie du jetzt gerade erwähnt hast. Also der Zustand, dass man eben irgendein fertiges Tool schnell installieren will, gerade auch zu Demo Zwecken oder um mal so ein kleines Proof of Concept zu machen. Wenn man zu einem Kunden fährt, den einfach zeigen will, was möglich ist und wie schnell das alles geht. Da benutzt man gern Helme, weil wie du schon gesagt hast im Linux Umfeld ist das ja auch sehr gängig, dass man da einfach schnell was installiert um es auszuprobieren, weil man sich eben nicht durch irgendeinen Install Wizard durchklicken muss und auch eben nicht viel konfigurieren muss, sondern das eigentlich out of the Box funktioniert.

Also Helm ist wie kybernetisch selbst auch OpenSource richtig. Genau. Ja, das ist ein Open-Source-Projekt, was von der Cloud Native Computing Foundation betreut wird. Und so kann auch jeder im Prinzip da dran mit basteln.

Contribution Ja, das machen ja die großen Cloud Provider. Alle oder die großen alten Namen bringen sich dann natürlich ein, weil sie auch gesehen haben der Trend geht ganz klar eben zum Paket Manager auf Kuba net des Container Anwendungen. Wenn unsere Zuhörer noch mehr zu kybernetisch wissen möchten, empfehlen wir auch gerne unsere Folge Nr. 25 Da geht es intensiv um das Thema Kybernetisch, um komplexe kombiniertes Anwendungen eben betreiben zu können oder installieren, deinstallieren, abzugrasen zu können. Wie genau macht man das denn mit Helm?

Stell dir einfach mal vor, wir haben entweder Ein und Promos Rechenzentrum oder ein Cloud kybernetisch Cluster hochgefahren. Ist ja egal, ob der jetzt bei einem der großen Cloud Provider läuft oder im eigenen Rechenzentrum. Und ich möchte die Helm Technologie einsetzen. Wie würde ich da denn jetzt dran gehen?

Ja. Also grundsätzlich gibt’s ja dann erstmal die Frage Möchte ich das jetzt für meine spezielle Anwendung, die ich zum vielleicht auch selbst entwickel machen oder für eine Anwendung, die eben noch nicht im Heim Repository mit drin ist? Oder eben so eine typische STANDARD Anwendung? Das weiß ich an Engine X Server oder typisch sind auch ein Monitoring primitives oder sonst was mit allen möglichen Abhängigkeiten. Im letzteren Fall würde man dann halt wirklich gucken, in welchem Repository das drin ist. Meistens sind die auch in den STANDARD Repositories drinnen.

Da gab’s jetzt plötzlich viel Umstrukturierung. Aber die großen Sachen, die sind eigentlich immer zu finden. Und dann würde man ähnlich wie beim Paket Manager tatsächlich einfach sagen Heim ins Daul den Release Namen. Also da kann ich selbst an einen Namen vergeben, der dann unique in meinem Cluster halt erscheint und dann eben der Name des Pakets. Im Prinzip also im Heim Umfeld nennt man das Helmut Shard. Und ja, man kann da beliebig dann auch Variablen in dem Shard verändern und anpassen.

Aber im. SIB reicht ein einfaches Heim in Stall, den Release Namen und das Shard, was ich installieren will und dann läuft das eigentlich schon von selbst alles an, mit allen Abhängigkeiten und einem möglichen.

Das heißt, ich konfigurierte Helm benutze ich von der Kommandozeile Karl gegen den kubanisches Cluster, gegen den ich es benutzen möchte. Ob on primus oder in der Cloud.

Richtig, genau genauso siehts aus. Und es gibt schon Repositories an die Helm Charts enthalten für STANDARD Komponenten wie z.B. Webserver, Engine X oder Datenbanken. Wobei Datenbanken in kubanisches Clustern ist immer so eine Sache, aber für fertige Komponenten und da kann ich meine eigene Software, die vielleicht ein Webserver braucht ne, wenn es Microservices ist, kann ich sozusagen darauf basieren lassen, oder?

Ja, das ist eben der Vorteil. Ähnlich wie beim Paket Manager wieder, dass sich eben Abhängigkeiten auch in meiner eigenen Anwendung einfach reinziehen kann. Und wie du schon gesagt hast, das ganze Management von Abhängigkeiten. Das passiert alles klein seitig und im Prinzip werden dann einfach ganz normal die Sachen nach und nach in kybernetisch Cluster installiert von Hän und ich muss mir da gar nicht viel Gedanken machen.

Also Helm geht dann hin, lädt die einzelnen @Helmut Charts die ich als Abhängigkeiten markierter. Bleiben wir mal beim Webserver runter, lädt die Docker Images runter Diplome die dem kybernetisch Cluster und sieh zu, dass alle Komponenten ordentlich starten. Und ja, die beschriebenen Wolli ums gemault teeth werden die Ports die angegeben werden freigeschaltet sind verschiedene krit. Dunkels gesetzt werden. Also als variablen Beispiel, sodass nach und nach die Anwendungen wirklich wie ausgepackt aus einem Paket in dem kybernetisch Cluster lauffähig gemacht wird.

Genau ungefähr so ist es natürlich schon noch so, dass Kuba Annettes sich um Sachen kümmert, wie jetzt die Container runterzuladen und so weiter. Das wichtigste zu verstehen ist, dass man mit Helm eigentlich nur kybernetisch Ressourcen verwaltet. D.h. Anstatt dass ich jetzt mit meiner Cubes Ctrl hingehe und sage create deployment create secret create config map, sag ich einfach nur ha’m. Im Stall und im Hintergrund läuft halt genau das. Aber das Schöne an der ganzen Sache ist, dass das alles kybernetisch Native ist.

Also im Prinzip kann ich es nicht best practice. Aber im Nachhinein kann ich beliebig auch die Ressourcen per Hand wieder editieren. Ist natürlich nicht empfohlen, weil dazu gibt’s ja Helm.

Das ist ja genau der Punkt, dass man eben nicht Anwendungen händisch installieren möchte. Das würde ja auch funktionieren. Und dass man dann hinterher sagt Okay, die Anwendung läuft. Ich habe drei Tage dafür gebraucht. Welche Befehle hab ich denn sozusagen abgesetzt, um die Anwendung zu installieren und daraus mir ein Script mache, sondern das genau soll ja Helm machen. Man beschreibt in diesem Helm schade, dass es eine Jamel Datei beschreibt man quasi die Abhängigkeiten und den Zustand der App und Helm sieht einfach zu, dass dieser Zustand hergestellt wird und führt die dazu notwendigen Kommandos aus.

Genau, ja.

Also das ist wie du schon gesagt hast, in DE klarer, tiefer Ansatz, typischer Orchestrierung. Use case also ich sag halt was ich haben will und Heyl guckt was hab ich und was muss ich tun, damit ich den Zustand erreiche? Also da haben wir noch gar nicht drüber gesprochen. Auch Sachen wie Updates und so weiter können von Heyme auch direkt behandelt werden. Und PAME vergleicht halt einfach nur Ist und soll und guckt dann, dass die Aktion ausgeführt werden, die nötig sind.

Ja, das ist ja auch wie bei einem Linux Paket Manager. Na da kann man ja auch die Updates direkt über dem Paket Manager machen und die werden dann eben eingespielt entsprechend.

Genau, ja. Also die Vorteile von HAMCHA sind ganz klar. Wir haben schon von der Jamel Datei gesprochen, dass man diesen Infrastructure Ascot Ansatz noch weiter treibt. Die Jamel Datei ist natürlich einfach eine flache Datei, die man in git Versionierung kann. Man sieht wer welche Änderungen gemacht hat, man hat reproduzierbare Installationen. Ich könnte ja jetzt auch sagen wir ich habe drei kybernetisch cluster test Akzeptanz Umgebung und Produktions Umgebung und könnte dann in schneller Folge ein komplexes Helmi Chat mit vielen Komponenten in allen drei Umgebungen installieren.

Das wäre überhaupt kein Problem. Richtig.

Genau das ist eben auch der Vorteil. Ich hab’s eben schon ein bisschen angerissen. Man kann diese Hemme Charts, die bestehen auch aus Templates. Also diese ganzen kubanisches Ressourcen werden getrampt rated und dazu wird go template im Englischen benutzt. Das heißt, dass ich dann auch abhängig von dem Environment, wo ich mein Deployment mache, auch Variablen setzen kann. Das heißt in Produktion kann ich z.B. sagen, die Praktikas von dem Container, also wie viele Container gleichzeitig für meine Anwendung laufen, ist höher als jetzt in einem Test in Valmont, wo ich halt eben nur kurz Funktionalität durch testen will.

Okay. Das heißt, die Ausfallsicherheit ist dann quasi noch die Umgebung anpassbar, sodass ich pro Umgebung das festlegen kann. Genau.

Also es kommt natürlich aufs hammerhart an. Wenn ich jetzt was vorge Bauteils nehme. Irgendein offiziös. Dann muss ich halt gucken, was ist da g Templates. Also was kann ich durch Variablen ändern? Aber wenn ich jetzt ein eigenes Chart Bauer z.B. für meine Anwendung, die ich jetzt selber entwickelt hab mit allen Abhängigkeiten kann ich beliebig in diesen kybernetisch Ressourcen wie jetzt bei eben schon erwähnt mittels den go templates kann ich dann einfach jeden beliebigen Punkt also ob es jetzt in der Environment variabel ist, obs Memory Limits oder sonst was sind, kann ich alles beliebig als variabel definieren.

Im Template und dann eben in einem separaten Pfeil kann ich dann sagen okay, das sind meine Values, die eben für Produktion sind. Das sind meine Waldis, die für die Testumgebung sind. Und so lässt sich das dann beliebig anpassen auf die Infrastruktur im Beispiel jetzt auch wenn man ein fertiges Chart hat. Das macht das Ganze auch so mächtig. Nicht jeder will sein Monitoring gleich aufsetzen. Der eine hat eben andere Ansprüche, auch an Verfügbarkeit oder auch die viele Daten überhaupt gespeichert werden.

Wenn es jetzt Richtung Valium Claims und so geht und das lässt sich dann halt eben beliebig konfigurieren und das macht das Ganze auch so mächtig. Ja, verstehe.

z.B. in meinem Alltag ist es total sinnvoll, dass man sagt in der Produktions Umgebung hab ich z.B. 50 Ports um die ganze Last abzuwickeln. Also dieser Produktions Anwendungen. Aber in meiner Testumgebung, der teste ja nur ich. Da brauche ich viel weniger Disk Space, kann die kleinen Cloud Instanzen nehmen, das kostet dann weniger Geld wenn man will ja nicht. Vielleicht zum ganzen Cluster nur für die Entwicklung dann Überstunden betreiben und kann das dann eben so konfigurieren, dass das passt.

Und das ist auf der einen Seite viel Last bewältigen kann, im Produktionsbetrieb aber im Development Betrieb dann sehr kostengünstig ist, dass man theoretisch ein paar Dollar am Tag jeder Entwickler seine eigene Umgebung hoch und runterfahren kann mit nur wenigen Maschinen aus dem gleichen Hemsworth heraus.

Genau das kann man auf jeden Fall machen. Wie gesagt, es kommt da immer auf das Template an, was genau jetzt konfigurierbar ist und was nicht. Aber das ist auch das Schöne an diesem ha’m Ansatz, wenn ich jetzt selber einen Chart entwickel. Wir hatten ja schon angesprochen, die Struktur ist so, ich hab da mal einen Chart dort Jamel mein Haupt Jamel Fall, was halt so einen Namen vergibt Version Abhängigkeiten und dann kommt halt ein Template Ordner, indem eben diese ganzen Ressourcen liegen.

Und im Prinzip kann ich erstmal von alleine kybernetisch Ressource ausgehen. Also wenn ich jetzt mir einen Cube Citi alte Skripte mache auf eine Ressource im Jamil Format, dann kriege ich im Prinzip schon die Datei, die kann ich in dem Template Ordner ablegen und dann ist das Ding erstmal gelaufen. Ich kann dann eben im Nachhinein sagen okay, hier steht jetzt Reply CAS 3 drin. Ich möchte das jetzt konfigurierbar machen und dann kann ich eben da ganz einfach das mit dem GO Template in Format teilt.

Ja, Template draus machen und da gibt’s natürlich ganz viel Advanced darf das man halt auch anfangen kann Funktionen zu bauen, die dann von bestimmten Sachen wie jetzt welchen Get Lab Branch ich das jetzt baue und so weiter die Variablen anpassen. Aber das ist alles advanced. Das Schöne ist, dass man halt wirklich so step by step das Ganze aufbauen kann.

Das heißt, man kann sehr schnell starten, weil man es einfach verstehen kann. Aber die Erweiterungen Möglichkeiten sind mannigfaltig, sodass man auch komplexe Enterprise Anwendungen im @Helmut Charts verpacken kann.

Genau hier also für jeden der kybernetisch benutzt, ist das eigentlich überhaupt kein Problem Helmuts zu bauen, weil man eben immer bei den Intels Ressourcen anfängt und dann eben bestimmte Sachen konfigurierbar macht.

Das heißt mit Helm Charts sind im Grunde diese Dateien gemeint, die eben diese Orchestrierung beschreiben.

Ja, also das ist ein bisschen verwirrend, weil das Startort Jamel ist ein Fail, was zu einem Heyme Chart gehört. Aber genau wie du sagst das ganze Paket. Also die Templates, das Valerius Free und das Chart dort Jamel, also die Beschreibung von dem ganzen Chart, das ganze Paket, das Wandel, das nennt man eben Chart.

Okay, verstehe. Das heißt, wenn wir nochmal die Vorteile von Helmi Charts zusammenfassen, was bringt mir deren Verwendung? Dann kann man schon sagen erstmal bündelt es die Anwendungs Informationen. Also welche Dienste brauche ich, welche Williams brauche ich, welche Ports brauche ich? Die sind da ja alle beschrieben und einfach erweiterbar. Also wenn man ein weiteres Molden brauch, kann ich das einfach da eintragen und es würde dann hinzugefügt. Änderungen durch die Git Versionierung keit können einfach nachverfolgt werden und es gibt bereits eine große Bibliothek von vorhandenen Pane Charts, die ich entweder inkludieren kann oder als Basis für eigene Entwicklung nutzen kann.

Ja genau. Was vielleicht noch ganz interessant zu wissen ist. Wir haben ja schon gesagt, Heyme macht eben diesen ist Säufer gleich und das gantzer Kommando. In diesem Fall wäre das dann Häme Upgrade. Das ist eidam potent, also idR impotent im Deutschen. Das bedeutet, ich kann das Kommando so oft ich will absetzen und es ändert eigentlich nichts, außer dass jetzt die Release Noma hoch gezählt wird im Cluster. Aber abgesehen davon läuft meine Applikation. Ohne angefasst weiter.

Wenn ich jetzt keine Änderungen gemacht habe und das ist natürlich eine super Grundlage für Scripting, dann also, wenn ich das jetzt in der Pipeline packe oder so, kann das halt dann super einfach immer abgesetzt werden, weil das sich eben selbst darum kümmert, die nötigen Schritte durchzuführen.

Naja, okay, verstehe. Das heißt, wenn zwei Maschinen fehlen und du setzt Upgrade ab, dann Start. Der hat die zwei Maschinen. Und wenn das gleiche Kommando eine Minute später nochmal abgesetzt würde, würde einfach gar nichts passieren, weil er erkennt Ah, der Zustand, wie ich ihn beschrieben habe im HAMCHA. Das ist der Zustand, der auch im Cluster vorliegt. Das heißt, ich muss nichts machen. Genau. Wir haben in Episode Nr. sechsunddreißig über Terraforming gesprochen.

Das nutzt ganz ähnliche Mechanismen, um die Basis Infrastruktur, also z.B. diesen Kybernetisch Cluster aus der Taufe zu heben. Auf einer Cloud Lösung oder einer vorhandenen Infrastruktur und das ist natürlich in Kombination mit Kobanê des und Helmut Scharz kann man sozusagen von den Maschinen über den Cluster bis hin zur Anwendung eine komplette Basis Infrastruktur aus der Taufe heben mit dem Infrastructure as a Service Ansatz.

Das ist vielleicht noch ganz interessant, wo du jetzt Terraforming erwähnst. Viele Leute bringen das ja durcheinander. Terraforming hän Antriebe. Wo ist jetzt hier die Abgrenzung eigentlich? Und wie du schon gesagt hast, Terraforming ist halt eher Infrastructure Xcode. Also da hole ich mir dann irgendwie einen Cluster aus dem stampfe ich mir aus dem Boden und im hellen Bereich. Da ist man dann halt eher so bei den Applikationen, Middleware und sowas wie du gesagt hast. Terraforming hält ja auch für Zustand.

Bei Terraforming ist es so, dass der Kleinen seitig gehalten wird in dem Pfeil. Dieses Fall kann ich auch angucken und bearbeiten. Bei Helm ist es so, dass sich das ist auch abhängig von der Version. Da hat sich auch viel getan von der Version 2 zu 3, aber im Prinzip werden die ganzen Informationen im Cluster gehalten. Bei der neuen Version Version 3, da werden die Informationen in dem Namespace gehalten, wo auch mein Release läuft, also die Applikation, die ich installiert hab.

Und das hat eben den Vorteil, dass dann auch so Sachen wie jetzt Rol based Access Control von kybernetisch aus direkt umgesetzt werden. Also dass der Benutzer, der dazu berechtigt ist, das Deployment zu ändern oder überhaupt was zu Diplomen die Möglichkeit kriegt, wobei jemand anders, der dann eben nicht die Rolle hat, diese Möglichkeit unterbunden ist.

Also so eine Art Zugriffs Beschränkung mit Hilfe der Aarburg Policy genau Vorjahr bei Hellem 2 war das nicht ganz so einfach.

Das hat super funktioniert, wo Kybernetisch Arbat noch nicht implementiert hat. Weida hatte noch einen Server im Kybernetisch Cluster der laufen musste. Der sogenannte Tilla Server oder Tilla wird er auch einfach nur genannt. Und dieser Tilla hat halt als Server funktioniert für das Ziel n Tool vom Client aus und der hat halt seine ganzen Ressourcen innerhalb seines Namens Spaces abgelegt. Also enorm viel war das in dem Cubes System namespace. Da lief halt der Tilla und der hat dann Config Maps erstellt oben eben seine Ressourcen und seinen Zustand zu halten.

Und jetzt? Neu ist eben bei Hemme 3, dass die Ressourcen in dem Target namens Bake, also da wo ich meine Deployment wirklich mache, abgelegt werden, was eben diesen Vorteil hat, dass man die Arak Funktion von Kybernetisch direkt mit einbindet. Na weil wenn ich jetzt mit meinem Kleintieren gehe und keine Rechte hab, dann kann ich natürlich auch diese config maps gar nicht lesen oder bearbeiten.

Ja, das ist auch Tilla. War ja auch so ein Sicherheitsproblem, weil halt alle Leute, die sozusagen mit dem Tiller sprechen können, auf alle verwalteten Ressourcen Zugriff haben. Und jetzt über die Arbaces kann man das etwas feien Granulat wa steuern? Also man sollte auch für unsere Zuhörer, wenn man heute anfängt, auf jeden Fall mit der Version 3 von Helm beginnen. Genau hier. Ja, das ist vielleicht nochmal, um diesen Zweck klarzumachen. Ich finde das ganz interessant.

Du musst dir einfach vorstellen, oder? Unsere Zuhörer können sich einfach vorstellen, man hat diese laufenden Server einfach im Rechenzentrum, also hunderte oder tausende davon. Mittels Terraforming bündelte ich einige dieser Server zusammen zu einem Kybernetisch Cluster. So und der Cubaner? Das Cluster ist sozusagen ein STANDARD, der ob er jetzt bei Escher läuft, bei Google in der Cloud läuft oder bei AWS Amazon in der Cloud läuft oder irgendwo anders auch im eigenen Rechenzentrum sich mehr oder weniger gleich verhält.

Und auf diesem kybernetisch Cluster oder in diesen kybernetisch Cluster kann ich jetzt mittels Helm meine kybernetisch Anwendungen diplomen. Und wenn man diese drei Werkzeuge zusammennimmt also Terraforming Kybernetisch Helm komme ich relativ weit weg von diesem Vendor Lock in genau.

Ja wie du schon sagst. Also ich meine Kuba Annettes generell ist schon ein richtiger Schritt in die Richtung, dass man halt einfach eine Basis schafft und dann eben man nimmt ja gerne den Begriff Cloud Agnostikern in den Mund, also dass man eigentlich sich nicht wirklich drum kümmern muss, was unterhalb von Kybernetisch läuft, weil man da eben diese fest definierten Standards von Kybernetisch hat, also die Ressourcen und so weiter. Und klar, wenn ich dann ein. Dann bin ich da flexibel.

Also wenn du Helm benutzt, bist du da flexibel und hast quasi den ganzen Steg aus dem Vendor Lock in herausgezogen. Genau hier. Das heißt also, das ist ja wirklich toll, diese drei Komponenten oder softer Komponenten, die auch frei verfügbar sind in Kombination binnen Minuten hab ich quasi aus STANDARD Servern hab ich ein komplettes System aufgesetzt. Ich hab meine Infrastruktur pro Visionär. Ich hab mein kybernetisch klasse laufen plus ich habe meine kubanisches Anwendungen laufen und kann zu Testzwecken ja ganz beliebig diese Infrastruktur binnen Minuten hoch und runter fahren.

Kann Updates einspielen, kann Roll backs durchführen. Das hast du eben schon angesprochen, dass Helmut Shard selber dient. Natürlich auch. Jetzt muss man sagen für Entwickler auch als eine Art Dokumentation der Anwendung, weil ja genau beschrieben ist, was hängt von welchen Komponenten ab, welche Ports kommunizieren miteinander. Alleine das hat ja schon ein Wert, dass man sozusagen eine Anwendungs Dependency Graw generieren kann. Aus dem Hemd Shard. Ich weiß nicht. Gibt es da ein Kommando, dass man es irgendwie visualisieren kann?

Deshalb gute Frage. Das weiß ich tatsächlich gar nicht. Aber wie du schon sagst, das ist ein enormer Vorteil, den ich auch immer wieder gerne kommuniziere. Dass man eben durch das Coden von Schritten, die man durchführen muss, im Prinzip die Dokumentation überflüssig macht und auch damit eigentlich Fehler beseitigt. Wenn jetzt Sachen manuell durchgeführt werden, dann können immer Fehler entstehen. Man muss jemanden da haben, der aktiv zur Seite steht, mit dem Kopf da ist und wenn man das eben einfach automatisiert hat, sowohl mit Tera Form an.

Simple aber auch eben helfen könne einen dieser Fehler nicht so schnell unterlaufen.

Um ein plastisches Beispiel zu geben Stell dir mal vor, du bist verantwortlich für den sagen wir mal für den Server oder für die Helm Anwendung, die hier die Server betreibt, wo jeden Tag 20 Millionen Leute die Liste der Coruña infizierten runterlädt. Also das Beckhams sozusagen verdienender Corona Server. Und du würdest jetzt feststellen oh, die Anwendung wird sehr oft aus den App-Stores geladen. Ich muss irgendwie hoch skalieren. Das wäre eine relativ einfache Änderung. Würdest du das dann im @Helmut Chat mittels Reply CAS ändern oder was genau würdest du da einstellen?

Lustigerweise ist das Coruña App oder Coruña Waren App Server Beispiel eigentlich ziemlich gut, weil man da mehrere Komponenten drin hat. Zum einen Documentation. Wenn ich jetzt meine Heimat Charts publiziere einem Ghetto Chopra Satori Open Source, dann kann jeder sehen was läuft da eigentlich? Wie ist die Infrastruktur aufgesetzt? Wo läuft das Ganze? Und das hilft halt wirklich dann auch bei der Dokumentation, dass der Punkt 1, wie du sagst. Dadurch, dass ich dann mit meinen Templates eben diesen Replika Faktor einfach schnell hochsetzen kann, kann ich dann auch super schnell reagieren auf irgendwelche Anfragen.

Der Anstieg von Anfragen gut kybernetisch macht das natürlich auch schon mittels Autos Gayle. Aber wenn man jetzt in die Richtung geht, dass man mehrere Standorte hat, also eine globale Applikation hat, dann kann ich halt auch wirklich sagen Hey, wir haben jetzt einen neuen Markt irgendwo in Asian Pacific Area, dann kann ich einfach sagen So, da fangen wir jetzt an und da brauche ich jetzt ein Rechenzentrum und da hilft mir halt sowohl Theaterformen für die Infrastruktur, aber auch ha’m, vor allem, weil ich eben meine Applikationen in Minuten ausrollen kann oder eher Sekunden.

Ja, ich glaube auch an ein anderes gutes Beispiel ist, wenn ein ganz verbreiteter Messenger für Mobilfunk, Geräte oder für Smartphones seine Policy, seine Daten Policy ändert und auf einmal die anderen Messenger einen immensen Nutzer Ansturm zu verzeichnen haben. Das wäre auch so eine Situation, die in klassischen Server Umgebungen oh Gott, jetzt muss ich Server bestellen und die Immi mieten. Okay, ich bin in der Cloud, das heißt, ich kann in ein paar Klicks hinzufügen, aber das möchte man eigentlich auch nicht.

Man möchte im Grunde eine Anwendung so resilient implementiert haben, dass sie von selber, wenn sie wächst mehr Server Kapazitäten WIP mit kybernetisch mit Autos galligen automatisch sich beschafft bis zu einem gewissen Schwellwert.

Naja, das ist definitiv ein Vorteil. Ja und das ist dann eben ne kybernetisch Funktion bzw. in Helm selber kann man ja auch darauf Einfluss nehmen. Ja also wenn man zwei Beispiele genannt der Coruña ERP Listen Server und die anmeldest Server für Smartphone Messenger. Das ist natürlich auch eine Unternehmenskunden, die uns zuhören. Interessant wenn sie Nutzer Ansturm haben bei gewissen ich sag mal Black Friday Verkäufen oder Medienberichterstattung zu einem Unternehmen oder wenn Marketingkampagne laufen, wo halt in kurzer Zeit viele Kunden die Angebote nutzen.

Oder ein jüngstes Beispiel aus der vergangenen Woche, wo teilweise Server von Brokern Probleme hatten, weil eben ganz viele Aktien gehandelt werden auf einen Schlag. Da kann man dann gegenhalten.

Auf jeden Fall. Das hilft halt einfach schnell zu reagieren, weil ich eben dann nicht manuell. Irgendwelche Schritte einleiten muss, meinen Experten, der dann vielleicht im Urlaub ist, irgendwie ans Telefon kriegen muss. Sondern ich habe eben einfach die Dokumentation mehr oder weniger da und eben kann ich auch einfach Änderungen vornehmen direkt im Code, muss nicht mal irgendwo groß rum klicken, sondern ich mach das halt wirklich genau an der Stelle, wo ich brauch. Und da es so einfach ist, kann das natürlich auch automatisiert passieren, also direkt vom Computer.

Bevor wir jetzt noch auf weitere Details von Helmut Charts eingehen, würde ich dich noch fragen. Gerne zu deinem Erfahrungsschatz. Und zwar ist es deiner Erfahrung nach so, dass Firmen eher anfangen, neue Anwendungen auf Kuba nettes zu entwickeln und dann auch direkt zu @Helmut Charts zu erstellen? Oder werden auch viele Bestands Anwendungen also vielleicht alte Monolithen, die jetzt noch nicht so dem Mikroskops Paradigma folgen auch in Kuba Annettes Pakete verpackt und dann auch mit Helm Charts ausgerollt? Wie ist da deine Praxiserfahrung?

Also meine Praxiserfahrung ist eigentlich fast immer das gleiche und zwar dieses ganze Klout Thema kommt ja auf die Firmen zu und die wissen auch, dass die da was tun müssen. Die meisten haben kurz vor 12, also da ist das wirklich ein heißes Thema. Und da dann meistens auch relativ viel Funding in der Region dann zur Verfügung gestellt wird, passiert das doch meistens, dass Anwendungen grundsätzlich nochmal neu überdacht werden und dann auch eben der Microservices Ansatz umgesetzt wird, weil man eben, wenn man sowieso alles umzieht.

In diesem alten monolithischen Umfeld hat man natürlich seine großen Anwendungen irgendwo auf dem Server, der von irgendwem mit Hand konfiguriert wurde und wahrscheinlich irgendwo ne ganz dicke Dokumentation auf dem Schreibtisch liegt. Und da jetzt zu sagen Okay, ich hole das jetzt alles in die Cloud, das ist sowieso Arbeit. Und dann überlegen sich die Unternehmen meistens, dass es dann sinnvoller ist, das Ganze sowieso direkt schon um zu design, weil diese großen monolithischen Anwendungen haben ja auch was Skalierung betrifft Probleme.

Die sind meistens auch überhaupt nicht dafür gebaut, Verteil zu laufen. Und diese ganzen Cloud Native Komponenten API, Gate, Boyce und allen möglichen Sachen wären da gar nicht wirklich gut eingebunden. Wobei, wenn man dann nochmal wirklich sich anguckt, was gibt’s heutzutage für Frameworks, was ist der Stand der Dinge, dann kann man da seine Applikationen schön direkt Cloud Native neu designen. Und das ist auch das, was ich zurzeit hauptsächlich beobachte dass der Schritt eben auch direkt gemacht wird und die Applikation neu Design wird.

Man hat ja auch aus seinen Fehlern gelernt. Man weiß, wo sind die Schwachpunkte und manchmal sind das ja wirklich grundlegende Sachen, wo halt die Struktur von dem alten System einfach nicht so richtig passt.

Ja, genau, also das ist auch meine Erfahrung. Die alten Systeme funktionieren ja irgendwie, sonst wären sie ja nicht mehr da. Die lässt man vielleicht noch einfach weiterlaufen und steckt da gar nicht so viel Liebe rein. Aber wenn zukünftige Anwendungen entwickelt werden, benutzt man natürlich die neuen Technologien oder erweitert die alten Technologien um eine Komponente, die dann eben schon in der Cloud läuft. So ist auch meine Erfahrung. Also ich habe auch noch nicht gesehen, dass man Monolithen eins zu eins einpackt und dann in Kybernetisch betreibt.

Das wäre sicher auch dann ungünstig.

Ja, da hat sich einfach sehr viel getan, jetzt auch in der letzten Zeit. Wie einfach Applikationen strukturiert werden und implementiert werden, also gerade Sachen Richtung Datenspeicher und so in der Cloud geht man halt nicht davon aus, dass man immer so lokal seinen Speicher direkt bei der Anwendungs Logik hat, sondern geht da dann eher hin und benutzt externe Komponenten. Es kann ja auch eine skalierbare Datenbank sein, die auch im Cluster läuft. Aber eben dadurch, dass alles fein Granularität strukturiert ist, kann ich eben auch beliebig hoch und runter skalieren, so eben wie die Funktion benutzt werden von der Anwendung.

Lass uns doch nochmal etwas ins Detail gehen und nochmal genau besprechen, wie ein Helm Shard genau zusammengebaut wird oder wie das funktioniert. Möchte uns da kurz mit an die Hand nehmen, um das einfach mal strukturiert nochmal von Anfang bis Ende kurz zusammenzufassen, weil wir haben ja jetzt schon hier und da das Thema mal angeschnitten.

Ja, also das Hemd Shard ist eigentlich ein Wandel aus verschiedenen Dateien. Und die Haupt Datei ist eben dieser Chat dort Jamel, die eben dann einfach nur grunt information über das Chat enthält wie jetzt den Namen Version Abhängigkeiten. Und weiter gehts dann eben mit dem Templates Folder. Das ist so standardisiert der Ordner, der eben diese ganzen kybernetisch Ressourcen beinhaltet. PM nimmt dann einfach alles in dem Ordner und Diplomat das ins Cluster. Das heißt, wenn ich ein Pfeil da drin habe was überhaupt nicht ein Template ist, was einfach nur eine kybernetisch Ressource ist, dann wird hier auch genauso im Cluster ausgerollt.

Dann kann ich natürlich keine Konfiguration Änderungen machen mittels variabel, aber manchmal ist das ja auch gewollt. Dann die des Template Ding selbst. Das funktioniert eben mit diesen Gol Templates und alle goh lang internen Funktionen Template Funktionen sind abgebildet. Also wenn man da in der Sprache schon ein bisschen Erfahrung hat, hilft das natürlich immens. Aber Heimat auch noch weitere. Funktion hinzugefügt, dies dann leicht machen eigentlich alles mögliche zu Templeton, was Person nur Beispiel Funktionen, die man nutzt.

Also ich hab jetzt noch nicht viel mit Go lang gemacht, aber gibt es vielleicht eine funktionierende häufiger nutzt und die dir hierzu direkt einfällt?

Ja, also es gibt verschiedene Möglichkeiten, aber es gibt ja auch bestimmte Anwendungen. Wollen ja auch irgendeinen random character String haben, z.B. um krypto grafische Strukturen zu initialisieren.

Und da könnte man dann jetzt einfach in dem hammerhart sagen Gib mir random alpha numerische Ziffern generieren er ID oder sowas und das ist mein zaehlt für irgendwie eine Verschlüsselung Funktion, oder?

Genau das wäre jetzt ein Beispiel. Ich meine, ähnlich würde es oft auch mit Passwörtern gemacht, die eben nur Admin Passwörter für irgendwelche Datenbanken, die nur innerhalb des Clusters einem Sekrete sein sollen. Und da will man das Passwort ja explizit auch randomisiert haben. Das heißt, dass man halt gar nicht erst irgendwie eine Schwachstelle hat, wo irgendwer das Passwort kennt zu irgendeiner Datenbank, sondern das wird einfach direkt alles innerhalb des Clusters abgespeichert und keiner braucht da Zugang zu genau bei den Templates.

Ist vielleicht noch interessant für die, die da jetzt noch nicht so mächtig sind. Mit der Jamel Syntax ist natürlich empfohlen, das in Jamel zu machen. Das wird ja in vielen anderen Bereichen auch verwendet, weil das eben so schön lesbar ist. Aber für die, die’s Probleme macht Jamil ist ja eine obere Menge von Jason, also jede valide Jason Struktur ist natürlich gleichzeitig eine valide Jamel Struktur. Das erlaubt mir dann auch Jamil zu schreiben und wenn ich mal nicht weiterkommen.

Kurz die Ressource oder die Struktur eben in Jason darzustellen. Das wird ganz normal dann verwendet von Ham wie jedes andere Jamil und ja, funktioniert auch so was dann vielleicht noch interessant ist, ist das Beliefs. Das hatten wir schon ein paarmal ein bisschen angerissen. Hier nochmal explizit das ist eben ein Fall, was einfach Variablen definiert. Alles, was ich in dem Chart konfigurieren kann, kann ich in diesem Various Fall anpassen. Das heißt, ich kann dann eben, wie wir schon vorher gesagt haben, die Replika aus einer Anwendung anpassen und ich kann eben auch verschiedene Valerius Fails für verschiedene in Wassermanns benutzen.

Das heißt, wenn ich jetzt z.B. einen Gegenpol Süd-Korea kann ich auf jedem Bronstein auch ein unterschiedliches Belgiers Fall ablegen. Wenn es jetzt Development ist, was dann in die Test in Valmont geprobt wird, will ich da vielleicht andere Werte, andere Hoch Verfügbarkeit Werte haben als jetzt bei Produktion in Wahrnehmens.

Ich könnte auch Suchtest Nutzernamen da unterbringen. Dann heißt der User auf Test heißt der User minus test und auf in der Produktion wird er ganz weggelassen.

Wo solche Geschichten dafür wäre das welches Faltern da genau das Beliefs Fall ist natürlich auch wenn ich mir jetzt irgendwie von extern eine Ressource rein hole. Wenn ich jetzt z.B. einen Promi fürs Monitoring aufsetze, dann ist das Fall eigentlich die einzige Komponente, die ich mir dann auch selber privat abspeichern muss in meinem Git Repository, wo ich meine Changes Tracker, weil ich im Prinzip mit dem Chat dann direkt gar nichts zu tun habe. Ich passe nur dann Sachen an wie jetzt wie viel Speicher klemme ich, damit eben bestimmte Metriken abgespeichert werden und so weiter.

Und das ist alles was, was ich einfach bei mir in dem Delius enda aber grundsätzlich die Templates des Shard, das fasse ich gar nicht an, weil wenn da dann Änderungen Fixes eingespielt werden, dann werden die halt auch eben mit jedem Upgrade dann automatisch ausgerollt.

Das heißt, ich hab jetzt das Hemd Shard zusammengebaut mit Radius Jamil Templates, TV-Gelder, Charts, Jamil hab das auf der Festplatte oder es ist ne sollte ich lieber sagen. Und wie installiere ich das jetzt? Also ich hab die Anwendung da orchestriert in dem Helm Chart. Und wie schafft die Anwendung es jetzt in den Kybernetisch Cluster?

Also ganz konkret passiert das eigentlich mit Helm in Stowe und dann kann ich dem eben mit Minus ein Wadephul geben und dann gebe ich dem ganzen noch einen Release Namen. Den kann ich mir eigentlich mehr oder weniger aussuchen und dann bestimme ich halt noch welches Chart das ist. Das kann natürlich ein externes sein. Da sage ich dann bei einem Engine X z.B. Vietnam Nami Schrägstrich Engine X, also aus dem Vietnam Repository, dass Engine X Chart und dann wird das direkt installiert.

Also dann werden die Schritte eingeleitet, dass im Prinzip alle Abhängigkeiten und alles installiert werden in dem Cluster. Wenn ich jetzt natürlich das Ganze schon am Laufen hab, dann würde ich nicht mehr ins Stäube nutzen, weil Naniten. Steul schlägt fehl. Ein Stall ist nicht wieder impotent, sondern das Install ist ein mehr oder weniger imperatives Kommando, was halt einfach die Installation vornimmt. Normalerweise benutzt man tatsächlich Helme Upgrade und ich benutze eigentlich am liebsten Helme Upgrade minus AI, was soviel heißt wie machen Upgrade und wenn nichts da ist installierst.

Also dieses Kommando ist sozusagen alles in allem. Das Shard wird installiert, wenn es nicht da ist. Und ja, das ist auch das, was man dann eigentlich in Çiçek Scripte oder. Wo bei Automation einbaut, weil das eben diese idem Potenz hat. Okay, verstehe. Das heißt, man braucht sich im Grunde nur ein Kommando zu merken Upgrade minus ai oder minus y und Trends nicht installiert. Es wird die Anwendung installiert in der Version und wenn sie bereits installiert ist in der gleichen Version wird nichts gemacht, außer das Toyo Release Nummer instrumentiert wird und wenn die Anwendung installiert ist in einer vorherigen Version wird auf die aktuelle Version gab geredet.

Genau. Also es gibt natürlich dann auch Advanced Sachen, also haben unterstützt auch Semantic Versionen. Aber also da kann man dann die Release Nummer entsprechend anpassen. Aber das sind dann Sachen, die relativ Fettwanst sind.

Für jeden der jetzt kurz nach einer Anwendung erstmal die Pointe reicht das auch erstmal so dann die Unterschiede zwischen der Helm Version 2 mit dem Tilla Server, der sozusagen im Kybernetisch Cluster läuft und alle Aktionen durchführt und der Version 3, die mittels Airbag auf die ihr zugewiesenen rechte Bereiche zugreifen kann, um die Aktionen durchzuführen. Da bist du ja schon drauf eingegangen. Wie verbreitet ist Helm denn und lohnt es sich das genauer unter die Lupe zu nehmen? Ich glaube da haben wir fast schon eine Antwort gegeben im Verlaufe des Podcast.

Aber vielleicht fassen das nochmal zusammen.

Ja klar. Also das ist auch wirklich haben wir die Sache ganz am Anfang ja angerissen, dass Helme einfach extrem an Popularität zugenommen hat. Also es ist einfach inzwischen auch Grundlage für viele andere Systeme. Also im Ranga Rangiere ist ein Overlay über ein kybernetisch Cluster und das vereinfacht einfach die Verwaltung von kybernetisch Clustern. Da gibt’s ne schicke Joi, wo man das alles verwalten kann und da gibt’s eben auch einen Katalog.

Also das ist im Prinzip wie so eine App Store voll Kybernetiker und der basiert natürlich auf Helme und andere Bonnard sozusagen unter der Motorhaube im Hintergrund.

Genau da läuft dann natürlich Helm ganz normal und da sind auch die offiziellen Helme Repositories. Dann weiter geht’s ja dann noch, das geht ob’s Tool Flachs, Version 2 und das benutzt auch Helm Charts für Deployment. Also das Richtige ist hier natürlich die Version 2, weil da hat sich ja viel geändert zur Version 1, aber das ist so ein Get up Stuhl, wo man eben seine ganze Infrastruktur und Deployment alles entgeht, Repositories hat und Flachs bildet. Die Brücke zwischen den Geth Repositories und der Infrastruktur also ist guckt einfach aktiv.

Hab ich Änderungen in den Geth Repositories? Wenn ja, dann führt das eben die nötigen Kommandos aus. Also sozusagen das Scripten von Ham Upgrade.

Das finde ich richtig cool, muss ich mal sagen. An der Stelle du hast Watcher auf dein Git Repository yum, der bei Änderungen losgeht und dein kybernetisch cluster Status aktualisiert oder updated. Also das ist schon SII ICD auf höchstem Niveau finde ich persönlich es auf jeden Fall.

Das ist für mich auch so der letzte Schritt, der eigentlich alles zusammen packt. Dann war man hat natürlich das Problem, dass die Akzeptanz von Infrastructure oder auch Konfiguration oder sonst was. Ascot halt immer ein bisschen unterschiedlich ist. Es gibt ja auch gewisse Kollegen, die dann auch doch Änderungen manuell vornehmen. Wenn dann wirklich die Hütte brennt, dann hat man manchmal auch das Gefühl, jetzt hier in den Code zu gehen, das zu ändern, das zu Kometen Commit Message zu schreiben, zu pushen, dann wieder nicht woanders einzuloggen, eine Pipeline zu triggern oder sonst was.

Da haben viele dann irgendwie das Gefühl, wenn dann wirklich mal was los ist, dass das zu lange dauert. Und dann kann es schnell passieren, dass der Zustand, in dem geht Repository und in der Infrastruktur divergieren. Und soweit ich da bin, wird’s wirklich kompliziert. Das Schöne ist beim flachst, dass ich den Benutzern gar nicht mehr die Möglichkeit geben muss, manuell Sachen zu ändern. Bei jeder oder jeder. Der muss hat Zugang zu den Repositories und kann da einfach seine Änderungen machen.

Und das wird dann einfach im Hintergrund automatisch auf die Infrastruktur ausgerollt.

Ich sehe da noch einen ganz anderen Vorteil und zwar bis flux. Ja, so eine Art erweiterter Commit Hook. Das heißt, ich weiß, wenn ich mein Kotaku Mitte und auf Master Merge oder auf einen Release Branch merge, der wird dann automatisch Diplomat. So und das auf Entwickler Seite erzeugt dann eine Art erhöhtes Qualitäts Gefühl. Lass mich das nochmal sagen. Ich glaube auch, dass Flags und die Konsequenz daraus, dass wenn ich etwas Kommittee und auf den Master Branch merge, dass das automatisch Diplomat wird.

Das führt dazu, dass man das Testing noch ernster nimmt und noch mehr Tests schreibt, um einfach zu sagen Okay, wenn ich das jetzt hier committee, kontrolliert das kein Mensch mehr, sondern es wird wirklich produktiv ausgerollt. Wenn man das möchte und so einstellt. Und ja, das ist eigentlich eine gute Sache, dass man im Prinzip dann noch mehr Tests schreibt oder die Tests nochmal gründlicher checkt. Manuel checkt, um zu sagen Das muss ja alles Test Bar sein, sonst kann es sein, dass sich vorne was kaputt mache.

Das hilft auf jeden Fall dabei. Und das hilft natürlich auch der. Die Akzeptanz, also, dass Änderungen dann auch wirklich zur Infrastruktur kommen. Die Zeit ist einfach geringer, weil ich weiß, sobald ich was da rein packe, ich muss niemand Bescheid sagen, ich muss keinem sagen Hey, ich hab hier wieder eine Änderung. Roll das doch mal bitte auf die Infrastruktur aus, sondern das passiert dann einfach. Und das ermöglicht natürlich auch wiederum ganz andere Reaktionen bei den Entwicklern, weil die natürlich ihre Changes instant auf der Infrastruktur haben und einfach die Anwender profitieren ja auch ganz deutlich.

Da ein fertig gestelltes Feature ja schneller ist, in die Produktion schafft und schneller dann auch aktiv genutzt werden kann, von den entweder ein Nutzer da draußen oder den Unternehmens Benutzern. Das möchte man ja auch, dass man die Time to Market würde man im BWL Kontext sagen ich sag mal code to user time möglichst gering hält. Auch als Entwickler ist es ja möglichst erstrebenswert, dass wenn doch noch Probleme oder Rückfragen kommen, dass man die möglichst zeitlich nahe zur Implementierung dann erhält und nicht Monate später, wenn man sich dann nochmal eindecken muss.

Unser Muss. Okay, was war denn jetzt nochmal genau Sachstand da?

Okay Julius, vielen, vielen Dank für die intensiven Einblicke in das Ökosystem von Helm Kybernetisch Terraforming. Es hat mich super gefreut.

Sehr gerne, ja. Mich hat es auch gefreut, dabei zu sein. Vielleicht nochmal einen kleinen TISA am Ende. Was natürlich möglich macht, es in Verbindung mit anderen Tools auch komplexe Deployment Strategien umzusetzen, also z.B. Canary Deployment oder Blue Green Deployment. Bei Canary Deployment würde ich halten Feature erstmal an eine kleine Gruppe von Leuten ausrollen und dann testen wie reagieren die da drauf? Ist die Responses Zeit von dem User? Also wie lange braucht der User durch die Seite zu browsen?

Ist die schneller? Ist die langsamer? Wird das UI plötzlich verwirrend oder wird das eindeutiger für den Benutzer? Und dann kann ich Stück für Stück das halt als Produktions STANDARD haben. Und bei Blue Green ist eben dieser Situation, dass ich im Prinzip meinen Production impliziere und meine neue Version in ein zweites Produktion in Valmont, die Pleuger und dann eben einfach den Traffic komplett von dem einen Production in das andere Router und so halt dann auch ohne irgendeine Art Downtime halt einfach um switchen kann auf eine andere Version und Tools wie jetzt zum Beispiel ist Théo, die helfen mit Helm zusammen ebenso Sachen automatisiert umzusetzen und sowas ist natürlich Next Level.

Also das ist wirklich advanced. Aber das ist auch das, was man wirklich braucht, wenn man Ansprüche an Verfügbarkeit hat und Automatisierungsgrad.

Wenn unsere Zohra eine Frage haben oder Feedback zur aktuellen Episode, freuen wir uns über eine E-Mail an Podcast Skill bei Gilbert. Wir freuen uns immer über Bewertungen des Podcasts und natürlich Weiterempfehlung an eure Freunde und Kollegen. Das ist ganz ganz wichtig, wenn ihr die Podcast Episoden und die Inhalte als wertvoll erachtet. Empfehlt den Podcast gerne an Freunde und Kollegen. Weiter schaut Rolfs Gilbert de Slash Blog vorbei für weitere spannende Technologie Themen. Vielen Dank Julius für die Einblicke in Helm.

Und bis bald.

Bis bald.

Maurice KnoppSkillbyte Podcast #43: Helm – Der Kubernetes Paketmanager
Mehr

Skillbyte Podcast #38: Darum müssen IT-Manager programmieren können!

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Darum müssen IT-Manager programmieren können!

// Inhalt //
01:20 – Was ist das Problem?
03:35 – Nur general Management Skills reichen nicht für IT-Projekte
06:29 – IT-Management braucht zwigend technischen Sachverstand
07:40 – Kardinalfehler: Aufgrund mangelnden IT-Verständnisses werden fachliche Anfoderungen sehr ungenau spezifiziert
09:14 – Technischer Sachverstand und Coding Skills helfen extrem bei der Anforderungermittlung mit der Fachseite
12:02 – Technischer Sachverstand ist nötig um vom Team respektiert zu werden
13:05 – So schaffen IT-Manager den Programmier-Einstieg (Bugfix, Unittest, Hello-world, neue Technologien sichten)
17:07 – IT-Zeitabschätzungen validieren
21:36 – Technologiekenntnisse boosten die Anforderungsanalyse und die Ergebnisspräsentation
27:42 – Wo können IT-Manager coden im Projekt lernen?
31:02 – Workaround wenn keine Technikskills vorhanden sind
31:44 – Gegenfrage: Darum sollten Entwickler auch Management-Aufgaben übernehmen!

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #38: Darum müssen IT-Manager programmieren können!
Mehr

Skillbyte Podcast #36: Terraform – Virtuelles Rechenzentrum mit dem Infrastructure as a Service (IaaS) Werkzeug

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Terraform – Virtuelles Rechenzentrum mit dem Infrastructure as a Service (IaaS) Werkzeug

// Inhalt //
01:10 – Definition: Was ist Terraform? Was leistet die Software?
06:23 – Software eats Hardware -> Infrastructure as a Service
07:42 – Welches Problem löst Terraform und wie erfolgt der Einsatz?
08:40 – So sieht ein typisches Terraform Projekt aus
11:53 – Der Terraform State – am besten remote in der Cloud
16:18 – Vorteile von Terraform
16:28 – Vorteil: Infrastructure as Code / Versionierbar in GIT
16:48 – Vorteil: Infrastrukturänderungen können sofort getestet werden
17:12 – Vorteil: Integration in CI/CD Pipeline
17:50 – Vorteil: Zentrale Infrastrukturpakete /-module
20:11 – Vorteil: Buildserver kann Terraform ausführen
20:44 – Vorteil: Portierbarkeit zwischen Cloudplattformen
23:22 – Nachteile von Terraform (Funktionsgrenzen, Cloud Limits)
23:30 – Nachteil: keine Einheitliche Benamung bei unterschiedlichen Providern; unvollständige Dokumentation
26:20 – Detaileinrichtung von VMs benötigt weitere Werkezuge (Ansible, Puppet, Chef)
27:48 – Vorteil: Kubernetes Umgebungen können mit Terraform provisioniert werden
28:35 – Nachteil: Proprietäre Cloud Features via Terraform nicht oder später verfügbar
31:48 – Nachteil: Abstraktionsschichten erhöhen immer die Komplexität
32:47 – Vorteile: Infrastruktur versionierbar, kurzfristige Wartezeit auf Ressourcen, Rückgabe nicht verwendeter Ressourcen, große Community
34:17 – Variablen in Terraform Templates für unterschiedliche Umgebungen
35:54 – Terraform Graph: stets aktuelle Dokumentation der Infrastruktur

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #36: Terraform – Virtuelles Rechenzentrum mit dem Infrastructure as a Service (IaaS) Werkzeug
Mehr

Skillbyte Podcast #33: Traumjob IT?! – 10 Dinge die dir keiner sagt!

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Traumjob IT?! – 10 Dinge die dir keiner sagt!

// Inhalt //
01:52 – Punkt 1: Verstehe das Problem exakt BEVOR du eine Lösung konzipierst
07:09 – Punkt 2: Wie du eine Problem löst, ist meist zweitrangig
10:56 – Punkt 3: Du liest mehr Code als das du schreibst
14:31 – Punkt 4: Nach Abschluss der Entwicklung, startet die Entwicklung er richtig (aka Softwareprojekte sind nie fertig)
19:21 – Punkt 5: Du verschätzt dich beim Entwicklungstempo – IMMER!
23:56 – Punkt 6: Es wird sehr stressige und extrem ruhige Phasen geben
28:19 – Punkt 7: Mit weitreichenden Rechten, kommt große Verantwortung
33:42 – Punkt 8: Du wirst eine Menge Spaß haben und viel lernen!
36:31 – Punkt 9: Du wirst unglaublich schlaue Leute treffen; (sind besser als du)
39:05 – Punkt 10: Du verbringst sehr viel Zeit mit Detailproblemen

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Man muss sich ja vorstellen, man selber hat vielleicht Stunden an der Tafel gestanden, um die Prozesse durch zu planen und jetzt kommt der Computer hin und kann diese Prozesse tausendfach millionenfach pro Sekunde ausführen und Zehntausende, hunderttausende Nutzer gleichzeitig versorgen mit den Prozessen, die man sich selber überlegt hat. Ich finde das nach wie vor auch nach 15 Jahren noch immer ein ganz besonderer Moment wie bei Cast Away. Ich habe Feuer gemacht.

Herzlich Willkommen zu unserem skillbyte Podcast Episode Nr. 33 Traumjob IT 10 Dinge, die dir keiner sagt. Abonniert unseren Podcast für mehr spannende Themen aus dem Technologie Umfeld. Wenn ihr Entscheider oder IT-Fachkräfte seid, wenn ihr Hörer Fragen im Verlauf des Podcasts habt, sendet uns gerne eine E-Mail an Podcast Skill D Wir freuen uns auch immer über Bewertungen oder wenn ihr den Podcast Freunden und Kollegen weiter empfehlen. Heute bin ich mit einem ganz besonderen Gast hier am Start.

Meinem Bruder Nikolai. Hallo Nikolai, hallo Maurice. Nikolai und du arbeitest ja auch für einen großen internationalen Softwarekonzern und ich bin sicher, dass die 10 nachfolgenden Punkte uns beiden seit vielen Jahren mehr als geläufig vorkommen werden. Ja, auf jeden Fall. Wie lange arbeitest du im IT-Bereich jetzt auch schon?

Ja, tatsächlich arbeiten seit knapp acht Jahren knapp acht Jahren. Wahnsinn, wie die Zeit vergeht. Unglaubliche acht Jahre. Klingt irgendwie gar nicht so lang. Aber wenn man mal überlegt, wie lange acht Arbeitsjahre sind, dass es auf einmal schon wieder eine ganze Menge.

Bei mir waren es letztens 15 Jahre und da habe ich auch schon gedacht Oh mein Gott, das ist auch ne ganz schöne Zeit. Viele Probleme haben sich verändert in der Zeit, aber viele grundlegende Konzepte sind auch gleich geblieben. Was auch schön ist im schnelllebigen IT-Bereich, dass sich nicht alles von heute auf morgen verändert.

Nein, es ist interessant, wie sich die eigene Perspektive auf dieselben Dinge in der Zeit verändert. Absolut. Möchtest du mit dem ersten Punkt beginnen? Aber sicher. Verstehe das Problem exakt, bevor du eine Lösung konzipiert. Ach, die Beispiele sind endlos. Ein kleines Beispiel Als Praktikant habe ich damals eine kleine Aufgabe zur Implementierung einer Web API gekriegt. Die hatte so zirka zehn Befehle, die abgebildet werden mussten in Python und ich dachte Oh, da kann man doch mit Sicherheit aus der Beschreibung der API von der Webseite automatisch die Methoden generieren.

In Python ist ja alles dynamisch. Geil machst du das. Wenn dann nämlich noch irgendwas dazukommt in der Zukunft, dann muss man einfach nur Copy Paste machen. Und dann sind die neuen Methoden auch direkt drin, ohne dass man weiteren Code schreiben muss. War vielleicht eine ganz tolle Idee, wenn man an der Uni irgendein Quiz lösen möchte. Aber für diese API, die sich nie wieder verändert hat und die eigentlich nur so an einem Nachmittag implementiert werden sollte, habe ich dann halt zwei Wochen dran gesessen und hatte am Ende eine total verschnörkelt Lösung, die auch an sich nur noch ich dann wirklich pflegen konnte.

Also super Ding, was sich unersetzlich gemacht bei deiner eigenen Aufgabe.

Es war hervorragend und es hat dann zwar am Ende funktioniert, aber ich habe viel zu lange gebraucht und es war auch einfach eine Ende schnoddrige Lösung. Aber sie hatte ne coole Idee.

Es war halt irgendwie so richtig schöner Schnörkeln und ich hab mich dann auf dieses wackelige Konstrukt darunter gesetzt, statt es einfach beide Burk zusammen zu schmeißen. Und es funktioniert und nie denkt wieder jemand drüber nach. War mir ziemlich sicher. Da hat so ein oder anderer noch ganz schön lange drüber nachgedacht und mich verflucht, als ich weg war. Ja, ich finde das ist so ein Punkt. Da sieht man ein bisschen die Seniorität des Entwicklers. Also man sieht sofort, ob die Leute sich direkt in die Lösung stürzen, die nicht vielleicht die ganzen Anforderungen verstanden haben, sondern direkt losstürmen an die Tastatur und anfangen Code zu schreiben.

Oder die Leute, die sie schon sehr lange machen. Meiner Erfahrung nach. Die stellen erst einmal sehr viele Fragen, also teilweise richtig lästig, viele Fragen für die Fach Seite oder für die anderen Kollegen, die, wenn sie zum Beispiel zu einem Team hinzu stoßen Warum machen wir das? Welchen Nutzen hat das? Welchen Vorteil bringt das? Warum nutzen wir nicht einen STANDARD, den alle schon benutzen? Warum machen wir das selbst also wichtig? Bohren Und früher, als ich angefangen hab, hab ich gedacht, das sind die Verweigerer und Meckerer.

Mittlerweile sehe ich das ganz anders. Java Mit vielen Fragen tötet man halt auch ein Projekt dann oder schnelle Entwicklung. Aber es ist ganz entscheidend, dass man weiß Was möchte ich denn hier eigentlich lösen? Ändert sich die RPI noch? Ja? Nein. Hätte man da vorher drüber nachgedacht, ist das jetzt eine ganz wichtige Information. Also Erweiterbarkeit. Wer setzt das ein? Erwarte ich 100 Requests am Tag da? Oder 10 000 pro Sekunde? Das sind ja alles Parameter, die es zu bedenken gilt und sich wirklich intensiv mit dem Problem auseinanderzusetzen, um dann zu sagen Okay, ich hab jetzt verstanden, was sie eigentlich wollt, wie eine Lösung aussehen muss und dann erst anfangen, diese Lösung zu entwickeln.

Also in der Skorbut Podcast Episode Nummer 9 Bulls Software Development gehen wir da auch schon ganz im Detail drauf ein, aber ich halte das für ganz, ganz wichtig und auch wie du das sagst.

Das sind die Verweigerer usw.. Wenn ich da an meine jetzt wirklich noch nicht lange Karriere zurückdenke am Anfang dachte ich mir Fragen stellen, da kommt man dumm rüber oder man weiß es ja nicht. Und jetzt denke ich immer die Leute, die dann mit so einer Frage so richtig in den Kern dessen, was ich übersehen hab, rein schießen. Ich liebe es mit Menschen zu arbeiten, weil da hab ich mir wochenlang oder im schlimmsten Fall mir und anderen Leuten wochenlang die falsche Richtung gehen erspart.

Einfach weil jemand die richtige Frage gestellt hat und keine Angst hat, die zu stellen.

Das muss natürlich auch die Situation hergeben, dass man so mutig ist und auch die unangenehmen Fragen stellen kann.

Und ich hab ein paar Kollegen, die haben das zur Perfektion getrieben. Wenn die irgendwie zu einem Design was fragen dachte am Anfang war Boah er die hassen mich, weil die wollen mich einfach. Kriegen, weil die auf jeden Fehler eingehen und inzwischen weiß ich, dass diese Menschen Schätze sind, weil sie sofort sagen Das ist unklar oder Das kann so nicht funktionieren. Sie attackieren mein schlechtes Design und nicht meine Persönlichkeit und das hat lange gedauert, bis ich das gemerkt habe.

Aber ich finde es endlich wertvoll und halt diese Fragen auch fragen zu können und sie zu erkennen.

Was ich als Hinweis hier noch geben kann, ist. Ich bin ein sehr grafischer Typ und habe auch festgestellt, dass das interdisziplinären Teams oder Teams mit sehr unterschiedlichen Wissen ständen. Auch hilft ist, sich einfach mal die Problemstellung zu verbildlichen. Also entweder an einer Tafel oder jetzt wo alle im Homeoffice sind. An so einem Online Whiteboard oder auch bei so einem Diagramm Tool also Druckpunkt AIO z.B. ist ein Online Diagramm Tool, wo man dann eben gemeinsam Diagramme erstellen kann, um einfach das Problem die einzelnen Fälle, die Unterscheidungen durchzugehen und möglichst viel von dem Problem zu verstehen, bevor man eben eine Lösung implementiert und konzipiert.

Weil die Lösung ist dann idealerweise sehr viel weniger Code und das freut mich auch wenn ich Softwareentwickler bin. Sehr viel weniger Kodes und weniger Backs ist weniger Wartung ist bessere Software wie z.B. eine automatische AWI Pasing Schnittstelle ist bei uns ähnlich.

Man schreibt oft bei komplexeren Sachen erst einfach Design Document. Und das wird dann könnte jetzt sagen zerrissen oder reviewed. Und diese ganzen Diskussionen schleifen sparen dann einfach viel Zeit, weil am Ende schreibt man genau das, was man denkt, was man braucht. Und das kann sie im Nachhinein dann immer noch zeigen, dass man etwas übersehen hat. Aber es ist so viel weniger vergeudete Zeit, auch wenn man vielleicht im Design Review eine Woche gebraucht hat. Aber dann weiß man das wäre vermutlich, wenn er sonst drei Monate Implementierung für die Katz gewesen.

Der zweite Punkt, wie du ein Problem löst, ist meist zweitrangig. Der konterkarierte jetzt ein bisschen in erst, sehe ich. Aber es gibt immer Umstände, Zeitdruck, Kostendruck. Gewisse Schlüsselpersonen mit Fähigkeiten, die gebraucht werden, sind gerade nicht da, die dazu führen, dass man auf sehr kreative Art und Weise ein Problem löst, was so nicht unbedingt vielleicht ins Lehrbuch schaffen sollte. Aber solange die Lösung funktioniert, wird sich außerhalb der IT niemand darüber aufregen.

Ist meine Beobachtung aus meiner Zeit.

Ja, oft stimmt das. Also ich denke, es kann einem das gleiche Problem mehrfach begegnen. Aber es ist nicht unbedingt immer die gleiche Lösung, die man dann braucht. Weil wie du schon sagst manchmal für die richtige Lösung sind die Personen oder die Ressourcen nicht da. Ich würde sagen, es ist zweitrangig, ob man das jetzt nach dem Lehrbuch macht. Das ist oft nicht das, was man braucht, aber es ist halt genau, dass man auch abschätzt.

In welchem Kontext brauche ich diese Lösung? Brauche ich jetzt einfach nur eine kurze kleine Lösung, die dieses Problem, was ich jetzt habe, aus dem Weg räumt? Oder wenn ich damit fertig bin, kommt der nächste. Dann kommt der Nächste. Meinst diese Broken window Theorie? Also eine Unsauberkeit zieht die nächste an, zieht die nächste an, zieht die nächste an und irgendwann kannst du das ganze Projekt wegschmeißen, weil es so kaputt gehuscht wurde, dass man es neu schreibt.

Ich finde neu schreiben nicht schlimm. Es gibt Leute, die fürchten sich sehr davor. Ich denke, dass man jede Software, die sich hinreichend bewährt im Einsatz und die sich weiterentwickelt, weil sie einfach ein wertvolles Problem löst, irgendwann neu geschrieben werden muss. Weil man einfach zu einem gegebenen Zeitpunkt, wenn man sich Jahre schon mit dem Problem beschäftigt hat, viel mehr weiß als zu dem Zeitpunkt, als die Software ursprünglich entwickelt wurde. Man hat das Problem einfach besser verstanden.

Da sind wir auch bei Punkt 1 wieder und da kann dann eben eine bessere Lösung implementieren.

Aber wie gesagt, man muss gucken, quick and dirty ist oft gut, aber man möchte halt auch nicht ein Problem für andere Leute hinterlassen. Aber ich habe oft gesehen, dass es so ganz nach dem Lehrbuch machen different man sich oft in Probleme, die man sonst nicht hätte. Genau.

Und Hauptsache es funktioniert. Ich möchte vielleicht mit einem Negativbeispiel den zweiten Punkt abschließen, und zwar, dass ist wirklich jetzt schon viele Jahre her. Also bestimmt 12 oder 13, da gab es eine Änderung in einer Software. Es war eine Website und das System in PHP geschrieben und ich sollte die Erweiterung machen und stieß im Source Code auf eine IF Abfrage und da stand wirklich sowas wie if I die gleich 214 und dann Block und da drüber stand ein 5 heiliger Kommentar.

Sorry, sorry, sorry ich weiß, das ist total dreckig was ich hier mache, aber ich habe in 2 Stunden 3 Wochen Urlaub und ich kann mich jetzt echt nicht damit beschäftigen, das hier sauber zu lösen. Entschuldigung für denjenigen, der das hier mal finden wird. Immerhin ehrlich, immerhin ehrlich nicht unbedingt toll, aber es ist mir im Gedächtnis geblieben. Auf jeden Fall. Und die Lösung lief zu dem Zeitpunkt. Ich glaube schon. 3 Jahre. Also das ist ein Extrembeispiel für sollte nicht ins Lehrbuch.

Funktioniert irgendwie und keiner köpft einen sofort. Aber vielleicht 3 Jahre später holt einen ein.

Wobei da jetzt auch da fühle ich mich verpflichtet aufzuweisen. Nochmal. Der Kontext ist ganz wichtig. Im Bereich Security ist in der Regel das Lehrbuch der richtige Weg, weil wenn es funktioniert, ist es nicht unbedingt immer noch sicher. Das ist ja auch offen, wenn jetzt Internet of Things usw. deswegen in manchen Bereichen, also hab ich für mich daraus gezogen, ich weiß. Hab ich zu wenig Ahnung. Deswegen versuche ich mich da gar nicht erst dran. Außer ich nehme irgendeine fertige Lösungen aus dem Schrank.

Genau da wäre die gleich 214 glaub ich. Wenn das im Anmelde Prozess ist, hätte ich da bissi Bauchschmerzen.

Security ist so ein Thema, wo man auch das Problem ganz genau verstehen sollte, bevor man irgendetwas macht. Und Security. Ich glaube das ist so ein Thema. Entweder du widmest dem dein Leben oder du nimmst, was andere clevere Leute, die diesem Thema ihr Leben widmen, bereits produziert haben. Dritter Punkt.

Du liest mehr Code als du schreibst. Ja, das ist auch. Außer man fängt bei Null an, weil man gerade Ich nehme mal an, ich habe noch nie ein Startup gegründet, aber ich denke, wenn man mal mit einem Projekt von Null anfängt und es ist noch gar nichts da, dann schreit man vielleicht tatsächlich mehr als man liest, bis die ersten 2, 3, 4, 5 Mitarbeiter oder Mitarbeiterinnen dann auch daran rumpfuschen, weil dann liest man ja auch deren Zeug.

Ich glaube sogar am zweiten, dritten Tag liest du schon mein Herz, dass du schreibst, weil du ja wieder liest, was du gestern geschrieben hast, damit du das wieder verstehst und dann da weitermachen kannst. So ist das gedacht.

Ja gut, dann wäre es jetzt gut. Chris von tÃnt fast Fingers, da war ich zu lange allein gemacht. Aber ja, gerade wenn man in ein Projekt einsteigt, wo man nicht von Anfang mit dabei war. Und ich meine, ich hab bei einem großen Konzern angefangen und war leider nicht Mitarbeiter Nr. 3 und kann mich jetzt darauf ausruhen. Da ist Lesen, Lesen, Lesen und Sezieren und die Dokumentation, wenn es denn welche gibt, finden und durcharbeiten.

Und dann? Am Ende setzt man quasi wie der Chirurg mit dem Skalpell den einen Schnitt und dann liest man wieder. Also die Menge an Recherche verstehen, verzweifeln, experimentieren, die dann da reingeht, bis am Ende dann oft die relativ kleine Änderungen, die es braucht, rauskommt. Das habe ich am Anfang auch nicht so erwartet. Ich dachte, als Programmierer macht man vor allem eins Programmieren. Aber ich glaube, der Begriff ist deutlich weiter, als man das denkt.

Ja, und es geht ja nicht darum, Code nur zu lesen. Also für mich ist das so ein mehrstufige Prozess. Für mich ist die erste Stufe ich lese den Code und orientiere mich so ein bisschen und gucke Okay, was passiert hier eigentlich? Die zweite Stufe ist Ich gehe wirklich mit dem Debugger Schritt für Schritt durch die Zeilen und gucke Was passiert hier? Also gerade wenn ich eine Änderung machen muss. Da möchte ich ja verstehen, was ist der neue Zielzustand und was ist der bisherige Zielzustand oder was produziert der Code und wie ist das Delta?

Was muss ich hier an dieser Stelle ändern? Das wundert mich immer wieder, wie viele Leute nicht in die Bagger benutzen, um genau das nachzuvollziehen, weil das so einfach Zeile für Zeile. Man kann überall reingucken, kann alles lesen. Man liest dann noch mehr, weil man auch noch die ganzen Variablen sieht. Aber man kann sehr genau das Detail Problem verstehen und dann eben zielgerichtet die Änderungen durchführen.

Ja, ich muss sagen, ich benutze die Bagger jetzt auch beim entwickelnd relativ wenig, weil wenn dir jetzt bei Dingen, die irgendwie als Server Prozess woanders laufen, also entweder im Testsystem, wo man dann überhaupt mit dem Bagger sich einklinken kann, ist es dann teilweise auch etwas schwierig sich da einfach dran zu hängen. Aber ich kenne es halt oft, sodass man dann, wenn man sich nicht klar ist wie der Code funktioniert, dann guckt man Unit Tests, die es hoffentlich geben sollte an, weil die so ein bisschen auch als ausführbare Dokumentation eingeben, was zu erwarten.

Oder wenn der Code komplizierter ist, hat hoffentlich jemand ein Kommentar dagelassen, der erklärt warum. Es ist so kompliziert, dass man sich die Mühe macht, erst den Code ob jetzt die Bagger oder ob man per Kopf das durchgeht, erstmal zu verstehen, was macht der Code? Vielleicht bin ich auch einfach manchmal vom Ergebnis getrieben. Je häufiger ich direkt achte, machst du hier mal schnell, dass das rechtlich eigentlich oft, weil dann a eine Randbedingung hin misst.

Ja, genau deswegen, dass sich einfach jemand vor das weiße Blatt Papier setzt und sofort das runter rockt. Man muss viel kombinieren und knobeln.

Deshalb lohnt es sich auch ordentlich zu kordon. Nicht unbedingt, weil man selber dann besonders toll das geschrieben hat, sondern weil es eben mindestens zehnmal gelesen wird. Wahrscheinlich auch von anderen Menschen. Und man macht denen ihr Leben leichter und kommt eben schneller voran. Ne Code sauber strukturiert ist und den abgesprochenen Guidelines folgt.

Ich glaube, das kann man vermutlich schon so sagen, dass die Kolleginnen und Kollegen auf jeden Fall wissen, wer den schludrige Code und wer den hervorragend schönen Bilderbuch Code schreibt.

Alle machen doch Bilderbuch Code um und die dies nicht machen. Das merkt man.

Der vierte Punkt Nach Abschluss der Entwicklung startet die Entwicklung erst richtig. Auch bekannt als Software. Projekte sind nie fertig. Jetzt stöhnen ganze Legionen von Managern auf. Wahrscheinlich bei diesem Punkt. Das ist eine da meine Vorbereitung noch drüber gesprochen. Es kommt ein bisschen darauf an. Man kann natürlich eine Software abschließen, wenn sie lediglich innerhalb einer Firma benutzt wird und z.B. nicht mit dem Internet in Kontakt kommt und dies dafür macht, was sie soll. So ein Converter wäre z.B. ein gutes Beispiel.

Oder wenn du eine Schnittstelle angesprochen wird, die irgendwie SMS verschickt oder so. Dann ist diese Software sehr wenig volatil. Aber alle Software Projekte, die Kontakt zum Internet haben und es dürften wohl die meisten sein, die sind nie abgeschlossen. Denn es tritt neue Sicherheitslücken auf. Browser bekommen neue Fähigkeiten, alte Fähigkeiten gehen verloren oder alte Technologien werden Dupree Created werden abgeschaltet, werden nicht mehr unterstützt. Das heißt, dass es ein fortlaufendes Monitor. O-Ring und mindestens minimale Anpassung der Anwendung an die aktuellen Gegebenheiten und das sind nur die Dinge, die man nicht in der Hand hat.

Weil ich glaube, sobald Endnutzer ein System nutzen, kommen natürlich auch Begehrlichkeiten auf wie Ach, könnte das nicht auch diese und jene Funktion haben? Oder ich nehme an, auch in-house. Wenn einfach die Nutzergruppen groß genug sind. Man kann sie natürlich vorher viel überlegen, aber ich glaube, dass man von Anfang an perfekt weiß, was die Anforderungen der Nutzerschaft am Ende sind. Das glaube ich, das gibt es selten. Und dann muss man natürlich auch gucken, dass man nachschieben kann.

Genau deshalb hat er diese ganze agile Softwareentwicklung so einen riesen Schub erfahren und tut es immer noch, weil man eben gemerkt hat Na gut, das funktioniert nicht, dass jemand Spezifikationen aufschreibt, anderthalb Jahre Software entwickelt wird und dann hinterher hat man etwas, was man gar nicht mehr braucht, weil sich die Welt ein Stück weitergedreht hat, sondern dass man kontinuierlich nach steuert. Wie auch? Wenn du mit dem Auto in die Kurve fährst, dann fängst du ja auch nicht so ein.

Das ist eine 40 Grad Kurve. Dann schlage ich mein Lenkrad um 40 Grad ein und mach die Augen zu, bis ich hinten wieder rauskomme, sondern du steuerst ja im Grunde durch die Kurve durch. Und genau das macht der Scrum Prozess eben bei deinem Software Projekt. Aber wichtig ist nach der Entwicklung ist vor der Entwicklung bei allen Themen, die mit dem Internet zu tun haben und die dann eben auch betrieben werden müssen. Es gibt Monitoring System, es muss geguckt werden, ob Sicherheitslücken zu stopfen sind, ob ne neue Version erschienen ist und solche Sachen.

Ja und vielleicht auch noch. Also ja Software Aktualisierung einfach von außen nötig werden. Aber was ich jetzt auch schon mehrfach erlebt habe, ist gerade wenn man Infrastruktur baut Infrastruktur, Software.

Dann werden Dinge ermöglicht, die vorher nicht gingen. Und dann kommen auf einmal Ah, jetzt, weil wir das können, können wir dann auch diese und jene ist. Wenn z.B. eine Sorte Datenspeicher ist, können wir auch das und das da drin unterbringen. Ja, das war eigentlich so nicht vorgesehen. Aber gut, müssen wir mal gucken. Und das klar.

Man kann sich nicht für alle Eventualitäten rüsten, aber oft wird man vom eigenen Erfolg auch überrascht, dass dann auf einmal das geschnitten Brot da liegt. Und jetzt will jeder etwas haben. Und mit so viel Anfragen und so weiter hat man gar nicht gerechnet. Da können sie sich dann auch einfach, weil man dann auf einmal das Problem besser versteht. Ist immer wieder bei Punkt 1, glaube ich. War es. Also kann quasi das ein riesiges Luxusproblem sein, dass man auf einmal jetzt wieder richtig rein klotzen muss, weil man einfach gemerkt hat, man hat richtig Nerv getroffen.

Was schön ist. Natürlich.

Genau das kann natürlich ungünstig sein, wenn man eigentlich gedacht hat, man ist damit fertig oder wenn man das Projekt gehasst hat. Ist natürlich auch nicht mehr echt. Aber das etwas fertig ist. Ich glaube außer man brennt es am Ende auf den Raum und dann läuft es irgendwo als Aufzugs Steuerungen und wird nie wieder angepackt. Ich denke es ist hatten’s große Systeme.

Ja oder Daten Converter. Also du hast ein System A in Betrieb und möchtest zu System B migrieren. Und einmal müssen alle Daten übersetzt werden aus System A im System B und dann Bausteine Software, die einmal produktiv läuft und diese Konvertierung durchführt und dann es das so, in dem Fall wäre es dann schon fertig.

Genau. Und da hab ich auch erlebt, dass manchmal, wenn man sowas im Vorfeld so einschätzt, dass es eine solche einmal und dann Schlussakte ist. Ist auch oft ne gute Idee, das so zu kommunizieren, dass man sagen Okay, wir bauen euch das. Wir machen das. Und dann sind wir aber auch da raus, weil ansonsten kann es passieren. Dann. Ach nee, aber eigentlich wir müssen jetzt doch noch ein paar Migrationen machen.

Könne da nochmal genau da gab es bei einem Projekt, wo ich vor vielen Jahren mal gearbeitet habe. Das war ganz interessant. Da gab’s in der Firma den Namespace Quand, also CU Ant. Und alle Projekte aus dem Namen Space Quand durften nicht verwendet werden für das eigene Projekt ohne umfangreiche Anpassungen. Dann mussten sie auch aus dem Quand namespace rausgenommen werden, sondern alles, was in Quand war, war quasi abgeschlossen und nicht für die Weiterverwendung gekennzeichnet. Und irgendwann habe ich gefragt Warum heißt es denn Corinth?

Es ist quick and dirty. Also wenn du was von dem Quand Stapel nimmst, bist du dafür verantwortlich, dass erst einmal eine Form zu bringen, die Wartburg ist.

Aber da sind wir ja auch schon bei Punkt 5 Du verschätzt die ich beim Entwicklungstempo immer. Ich bin jetzt selber kein Projektmanager, habe aber als Entwickler selbst schon ich sag mal meinen Anteil an absolut hanebüchenen Schätzungen abgegeben. Ich schätze mich immer nach unten. Das ist so AIA. Das ist 4 Stunden Arbeit. Sag mal lieber Safe und sagst zwei Tage.

Ja und dann nach zwei Wochen ist es dann auch endlich rum. Ich bin sicher, es gibt Leute, die sind da besser drin als ich. Aber prinzipiell hab ich auch vom Gespräch mit Projektmanagerin bei uns mein größeres Projekt hatten wir alles sehr genau durchgeboxt wurde. Hab ich dann auch irgendwie gehört. Ja, wir nehmen eure Schätzungen und dann machen wir da mindestens mal Faktor 2 oder 3, dann hoffen wir, dass es so einigermaßen passt.

Wir nehmen eure Schätzung und machen Faktor 2 oder 3, das heißt ja, dass man selber sich immer deutlich nach unten verschätzt.

Das scheint wohl so zu sein. Man ist ja auch optimistisch. Man will ja dass schnell erledigt.

Ja. Ich glaube, selbst wenn man die tatsächliche Arbeit, die man selber reinzustecken hat, irgendwie einschätzt und sagt Ja, hier, da die Komponente umbauen. Ich weiß in etwa, wie die aufgebaut ist. Und dann hat man aber im Rechenzentrum auf einmal nicht die Kapazitäten oder derjenige, der einem die Zugänge gibt, ist nicht da. Dann ist auf einmal irgendetwas anderes, ist auch selten an genau einer einzigen Sache nur dran und dann hat man irgendwie drei Meetings mehr als man dachte.

Es gibt tausend Gründe, die man nicht in der Hand hat. Und ich glaube, niemand sagt ja gerne stottert Trauer drei Monate her, wenn man denkt, es ist halt zwei Tage lang.

Nein, ich glaube, viele Dinge werden einfach unterschätzt. Alleine, dass man einen Zeitpunkt kommuniziert, ist glaube ich, nicht gut. Im Grunde müsste eine realistische Schätzung, müsste man sagen Ja, ich gehe davon aus, mit einer Wahrscheinlichkeit von 50 prozent, der sich zwei Tage brauchen werde. Wenn du es mit einer 75 prozentigen Wahrscheinlichkeit fertig haben möchtest, dann müsste ich von vier Tagen ausgehen. Also dass man quasi so ein Zeitfenster angibt, indem es fertig wird, weil Software Projekte sind ja Individual Projekte.

Wenn das nicht der Fall ist und die Software schon gibt, dann muss man sich fragen warum programmiere ich das, was es schon gibt? Wenn es geknackt ist oder gelöst ist, dann kann man oft nehmen, was vorhanden ist. Das geht sowieso viel schneller und hat eine höhere Qualität als sich selber etwas auszudenken. Und keiner schreibt auf die Zeitplanung. Unerwartete Treiber Probleme 2 Tage BIOS falsch eingestellt, einen Tag. Du hast es eben schon angesprochen. Ansprechpartner ist im Urlaub, deshalb bekomme ich kein Datenbank Zugriff.

Völlig normal 2 Tage, weil derjenige, der die Berechtigungen vergeben kann, nicht da ist. So, das sind aber in großen Firmen und wahrscheinlich auch in vielen kleinen genau die Punkte, wo die Zeit bei draufgeht.

Ja und ich würde schon sagen, dass so die Softwareentwicklung auch ein sehr kreativer Prozess ist. Leute, die nicht viel damit zu tun haben, schmunzeln jetzt vielleicht, aber es ist genau wie gesagt sagtest, wenn die Lösung von vornherein klar ist, dann stellt sich die Frage Warum muss man sich damit überhaupt beschäftigen? Es ist auch einfach schwierig, glaube ich genau abzuschätzen, welche Sachen auf dem Weg alle sind. Inkompatible Version oder irgendeine Abhängigkeit ist auf einmal nicht erfüllt.

Also es gibt ja tausend Dinge, die dazwischen kommen können und manchmal steht man auch einfach auf dem Schlauch und ist ein Tag irgendwie matt. Es ist halt nicht einfach Fliessband, wo man genau weiß. Pro Stunde schreibe ich 40 Zeilen Code und es braucht 200 Zeilen Code. Also brauche ich 5 Stunden. Ich hoffe meine Mathematik stimmt. Ich habe auch großen Respekt vor Projektmanagerin, die auf solchen ich sag es jetzt mal flach Müll daten. Ich meine nicht wie riecht kriegt trotzdem, weil so ein Projekt irgendwie durchziehen können.

Weil das wäre für mich wäre das ein Albtraum, wenn das mein Job wäre, weil ich einfach damit nicht umgehen kann. Ich glaube, es ist auch mit Du hast ein bisschen bewegendes Ziel. Du hast natürlich viele Aussagen. Es ist ein kreativer Prozess. Das wäre mal ein interessanter Vergleich. Künstler werden ja auch nicht gefragt oder selten gefragt Wann ist dein Bild fertig? Ob deren Voraussagen ungefähr der Qualität entsprechen, wie das bei IT-Projekte der Fall ist? Aber ja, ich gebe dir Recht.

In der IT ist es eigentlich sehr einfach. Entweder muss eine Lösung selber entwickelt werden und man schätzt den Lösungsweg ab, ohne ihn genau zu kennen. Das ist aber im Grunde wie eine Wanderung in einem Gebiet wurde noch nie warst, oder? Es gibt eine Komponente, die ist fertig. Die kannst du im Grunde mit minimalem Aufwand direkt verwenden und das sollte man immer machen. Wenn da sind wir wieder bei. Verstehe das Problem exakt, wenn teile Probleme deines großen problem schon gelöst sind mit Komponenten.

Nimm diese Komponenten.

Das spart am meisten Zeit und auch indirekt, wenn man etwas nimmt, was schon eine Weile existiert, von anderen Leuten vielleicht auch gebaut wurde. Die hatten auch schon alle ihre Bugs drin und haben viele gefixt. Ist natürlich immer noch genug drin, aber wenn man selber von Null anfängt, hat man das doch alles vor sich. Manchmal ist dann vielleicht auch einfach das bisschen, was es länger braucht, sich mit etwas anderem bekannt zu machen. Das spart man hintenraus, weil viel.

Ich sag mal stad. Krankheiten sind einfach schon raus gebügelt.

Der sechste Punkt Es wird sehr stressige und sehr sehr ruhige Phasen geben. Dem kann ich voll und ganz beipflichten. Das Problem mit den stressigen Phasen ist, dass in IT Projekten. Das kennt jeder. Wenn etwas nicht funktioniert, funktioniert es jetzt nicht sofort nicht und zwar für alle Benutzer. Und je nachdem welche Prozesse da dranhängen, hat man sofort ein großes Problem. Also wie bei einem Flugzeug, wenn beide Motoren gleichzeitig ausfallen. Unter Strom hat man sofort ein großes Problem, um das man sich kümmern muss.

Und das sorgt natürlich für Stress. Das sind die stressigen Phasen. Die ruhigen Phasen sind, wenn alles funktioniert und man nicht angerufen wird. Man wird auch nicht gelobt. Niemand meldet sich. Aber das ist das bestmögliche Zeichen, was ihr in einem IT-Projekte haben kann. Weil wenn sich niemand meldet und alle sich nicht um euch kümmern, dann läuft die Software ideal. Wenn sich keiner beschwert.

Ich glaube das ist so, wie du es beschreibst. Von wegen wenn. Wenn sich niemand meldet, ist alles gut. Ja, ich glaube, das macht auch ein bisschen den Unterschied. In was für einem bei Anwender Software oder in was für einem Umfeld, in was für einer Firma das ist. Weil in meinem Fall ist Software das Hauptgeschäft. Da ist natürlich auch einfach die Aufmerksamkeit glaub ich eine andere.

Ich nehme nur an, wenn Firmen, wo IT an sich so ein Mittel zum Zweck ist, um. Ich weiß nicht Content online bereitzustellen oder sowas, aber eigentlich das Hauptgeschäft Content. Dann ist natürlich, wenn alles läuft, dann hat man mit dem Software Gedöns nichts zu tun, weil das macht ja was es soll. Der Content ist da. Deswegen kommen die stressigen Phasen dann halt nur, wenn auf einmal das Hauptprodukt gefährdet ist, wo Software.

Wicklungen quasi das Kerngeschäft ist natürlich die Aufmerksamkeit immer da. Nur ist der Unterschied da oft ist das Projekt, an dem man gerade arbeitet, ist das intern oder extern sichtbar? Ich meine, es gibt viele Projekte. Jetzt kann man sich fragen Ja, wenn das nicht sichtbar ist, warum interessiert sich dann überhaupt einer dafür? Ich meine, die Rohre an meinem Waschbecken sind auch nicht sichtbar, aber solange die tun, kümmert es auch niemanden. Aber sobald auf einmal externe Interessen, gerade wenn es dann irgendwelche Verträge sind mit anderen Firmen oder man muss die bedienen, sonst gibt es irgendwelche Fristen, die verstreichen.

Da habe ich gemerkt, das ändert den Ton im Projekt aber ganz entscheidend, weil dann ist auf einmal das Weihnachtsgeschäft vor der Tür und das Ding muss raus. Dann kommen wir wieder zu Punkt 1. Dann wird halt auf einmal dann doch irgendwie egal, wie man es macht, Hauptsache es ist schnell und man kann irgendetwas schicken. Dann sind eventuell die Gesichter im Hintergrund lang, weil dann die Qualität natürlich gelitten hat. Aber unter Druck entstehen Diamanten oder es ist nicht so gut.

Ich mag die ruhigen Phasen dann durchaus mehr, weil es eben auch einfach die Möglichkeit gibt.

Ich sag mal bessere Arbeit zu machen.

Ich bin da vielleicht so ein bisschen Software bipolar. Also ich habe gemerkt, diese stressigen Phasen, die gehen extrem an die Substanz. Allerdings lernt man in drei Tagen so viel wie sonst in einem halben Jahr. Also das kann durchaus passieren, weil man einfach so voller Adrenalin ein Problem nachjagt. Also so ein Fokus hat man wirklich selten. Was natürlich unangenehm ist, weil man das Problem lösen muss. Und in ruhigen Phasen, da kommt es auch ein bisschen darauf an.

Viele Entwickler fangen dann an, technische Schulden abzubauen, wenn ihnen die Zeit dazu gegeben wird, was total sinnvoll ist. Ich bin eher so der Typ, der sich dann weiterbilden möchte. Ich gucke mir dann Themen an, die strategisch vielleicht interessant sind und sage Okay, das ist eine neue Technologie, davon hab ich gehört. Können wir die hier einsetzen, um direkten ganzen Problemen Kontext zu erschlagen oder wie funktioniert das? Was können neue Technologien? Wie helfen die dabei, unser Business besser zu machen?

Was hab ich bisher verpasst, wenn man das so sagen möchte? Bin eher so der Typ, der über den Tellerrand schaut und sagen würde Okay, was gibt’s da draußen noch außerhalb meines Stress Kosmos? Was ich mir jetzt anschauen kann.

Ich denke mal in ruhigen Phasen ist insbesondere der kreative Teil dieses Prozesses. Der kann sich dann austoben, wie du sagst weiterbilden oder halt auch Pflege. Wenn jetzt gerade nichts Brennendes ansteht, dann kann man die ganzen Ecken und Kanten, die man weiß, die hatte man drin. Die kann man dann pflegen, weil oft sagt man Na gut, wenn jetzt irgendwie ein wichtiges dringliches Ding da liegt, dann ist dieses kleine Feature, das kann dagegen einfach nicht anstehen. Aber er weiß sehr gut, wenn man das jetzt macht.

Die Benutzer haben dann eine kleine Verbesserung ihres Alltags. Das hat dann Platz. Die stressigen Phasen manchmal auch sehr spannend, weil wie du schon sagst, man lernt viel, gerade wenn man sieht, was für Unwetter man abgewandt hat. Vielleicht. Mir persönlich ist einfach wichtig, dass diese stressigen Phasen, wenn sie auftreten, auch von ruhigen Phasen wieder abgelöst werden. Wenn man das Gefühl hat, man rennt vom ein Chaos ins nächste. Das ist, glaube ich, kein gutes Zeichen für den Allgemeinzustand der Umgebung.

Wie auch hier die Dosis macht das Gift. Ja, zu den sieben Punkt ansprechen.

Ja, mit weitreichenden Rechten kommt große Verantwortung. Das ist oft. Als Softwareentwickler besteht man im Maschinenraum der Irmer. Was wir eben schon gesagt hatten, insbesondere wenn die IT das Werkzeug ist, was den eigentlichen Firmen Betrieb aufrecht erhält, dann hat man natürlich auch Zugang zum Maschinenraum dessen, was den ganzen Laden am Laufen hält. Da kann sowohl mit den Passwörtern, die man jetzt hat, zum einen böswillig eine ganze Menge Schaden anrichten. Und was halt auch durchaus vorkommen kann, ist, dass man mit Unachtsamkeit versehentlich ganz schön Schaden anrichten kann.

Dann ist auf einmal nicht die Tests, sondern die Produktions Datenbank gelöscht. Und das ist der Stoff, aus dem Albträume gemacht sind. Da gibt es Geschichten im Internet, die genau diese Horrorvisionen beschreiben. Es geht hier bei dem siebten Punkt einfach darin, dass man merkt Okay, die Firma vertraut dir als Person, dass du ihr dabei hilfst, ihre Geschäftsidee zu erreichen mithilfe von Technologie. Du bist da der Experte und natürlich hast du dann Zugriff auf sensible Infrastruktur.

Wir haben eben die hektischen Phasen Angesprochener. In den hektischen Phasen bewegt man sich vielleicht auf Systemen, die man sonst nicht gut kennt oder ist gezwungen, in der Datenbank zu gucken, um zu schauen. Also gar nicht einmal einem die Daten interessieren, sondern weil man einfach wissen möchte, ob man ist dieser Eintrag an einem Schalttag von dem Schaltjahr erfasst worden ist, dass das Problem. Also da muss man einfach relativ schnell sich dadurch hangeln, um zu gucken Okay, ich muss das Problem hier lösen, dann spürt man schon, dass man eine große Verantwortung hat, einfach weil man da am Nervensystem von Firmen oder von technischen Systemen arbeitet und man das vertrauen, was einem die Firma gibt.

Und man muss aber auch gucken, wenn die Firma ein Produkt hat, dann hat man ja an sich auch implizit das Vertrauen der Nutzer, weil die Nutzer natürlich davon ausgehen, dass die Firma mit den Daten kein Schindluder treibt oder zumindest nicht mehr als man der Firma zurechnen. Also es ist manchmal unheimlich, wenn man bedenkt, welchen Zugriff man teilweise einfach haben muss und die Arbeit machen zu können und einem vertraut wird, dass man nicht links und rechts nebendran guckt. Klar, es kann sein, dass es Audit Systeme gibt.

Das heißt, wenn man Schwachsinn macht, bleibt es nicht unerkannt. Also gerade diese versehentlich etwas umzustoßen ist natürlich da.

Tippt man ganz vorsichtig auf der Kommandozeile und guckt zweimal auf den Befehl, bevor man ihn durch. Ja, das hab ich tatsächlich häufiger schon gesehen, dass man dann einfach bei ich sage mal kretischen Sachen dann auch per Programming macht oder so. Zweiter Vorsitz, dass dann einer sein kann. Also diese Leerzeichen vergessen und auf einmal löscht man das Verzeichnis statt irgendwie den Pfad.

Man wollte ja oder auch so ein Tink laut, dass man sagt, der eine sagt so, ich zeige jetzt den Inhalt des Verzeichnisses an, jetzt verschiebe ich das Verzeichnis lib und dann sagt der Nachbar Ah, du musst Punkt lieb schreiben und nicht Slash lieb, oder? Also ganz natürlich, wie in allen anderen Bereichen und Branchen auch, dass man so ein Vier-Augen-Prinzip einführt und sagt Wir arbeiten jetzt hier am offenen Herzen und wir müssen hier vorsichtig sein.

Und ich meine, es wird immer noch etwas schief gehen. Da hab ich auch gesehen, dass wenn was schief geht, wenn man es dann noch versucht zu vertuschen, dann nein, wenn’s schief geht, sofort Alarmglocken. Gut, leicht kommt das auch auf die Position des Jeweiligen an, aber ich sag mal, in einem funktionierenden Umfeld sollte das am Ende so ein oh Mist alle Hände auf Deck Moment sein. Und dann, wenn die Wogen geglättet sind, dann kann man mal gucken, was eigentlich schiefgelaufen.

Da hab ich eine Horror Story aus meinem Entwickler leben. Genau zu dieser Situation. Und zwar, dass es auch schon viele Jahre her. Da hab ich an Diplomen durchgeführt auf einen Webserver, der aber nicht einer Firma gehört, sondern einem ganz großen Unternehmen. Und alle Agenturen haben die Inhalte, die sie zugeliefert haben, eben auf diesem Server abgelegt. Und so hab auch ich meine Inhalte abgelegt und ich hab den Installations Prozess gestartet, gucke und gucke und gucke der Server weg, gucke auf die Webseite von der ganz großen Firma der Server weg, gucke auf die anderen Dienstleistungs Agenturen, Verzeichnisse nichts.

Das war der Moment, wo wirklich mir heiß und kalt wurde. Da bin ich aufgestanden, zu dem Verantwortlichen gegangen, hab davon berichtet, der wurde auch ganz nervös. Dann hat er ganz panisch rum telefoniert und dann kam nach 5 6 Minuten raus, dass dieses ganz ganz große Unternehmen ein unangekündigte Wartungs Fenster für diesen Server durchgeführt hat. Genau in dem Moment, wo ich quasi die Installation gestartet habt. Es war also eine geplante Umstellung und ich banu zufällig genau in der Sekunde da und hab gedacht, es läge an mir.

Da war ich dann doch. Wieder habe ich einige Kilos abgenommen im Zuge dieses Anrufs.

Jetzt lacht man da drüber. Nee, aber ich glaube so 6 Minuten oder Herzschlag war damit ganz schön anstrengend.

Ja, also ich weiß noch, wie ich da saß. Ich weiß noch, was ich empfunden habe. Ich weiß noch, wie ich aufgestanden bin, mit dem Kloß im Hals zum verantwortlichen Manager gegangen und gesagt habe Des Ford Server XY Z lebt nicht mehr.

Und ich glaub, ich bin schuld.

Da kann man auch viel über das Management erfahren. Wie dann, wie die damit umgehen. Ja, es gab überhaupt keine Zeit, um mit dem Finger irgendwo drauf zu zeigen, weil man wusste, wenn das so ist, ist Katastrophe und dann muss jetzt reagiert werden. Es war denn Gott sei Dank so, dass sich dann hinterher auch dieses ganz große Unternehmen entschuldigt hat, bei all den Partnern, die halt diesen Server benutzt haben für die eigenen Komponenten, weil es gesagt hat Ja, irgendwie haben wir das nicht korrekt kommuniziert.

Oder es war eine kritische Sicherheitslücke, die ganz kurzfristig gestopft werden musste. Ich weiß es nicht mehr. Ich weiß nur das hinterher war alles in Ordnung. Es geht nicht dein Blut am Server. Ganau. Ich war nicht der Auslöser, sondern ich bin da reingeraten. Sozusagen. Kommen wir direkt zu Punkt 8 Du wirst eine Menge Spaß haben und viel Spaß haben wir ja jetzt, wo wir es überlebt haben.

Aber ich hatte nochmal so eine Katastrophen Situation, wo alle Leute die helfen konnten im Urlaub waren und ich das dann irgendwie alleine machen musste. Also heute ist das witzig und es macht mich auch stolz, dass sich das so geschafft habe nach einiger Zeit. Aber in der Situation selber war das nicht so angenehm. Ich meine, wie du schon vorher sagte ist unter Stress lernt man viel, aber oft hat man den Spaß dann auch, insbesondere wenn es ohne beinahe Herzinfarkt zwischendrin man irgendwie einen Milestone abgeschlossen hat, wenn irgendwie ein Projekt, was lange lief, vielleicht auch die eine oder andere Träne gekostet hat.

Am Ende wird es dann aber ausgeliefert und es funktioniert tatsächlich sogar. Da kann man dann viel rausziehen.

Für mich ist das immer wie Magie. Ich will jetzt nicht sagen, wie der Moment, wo Frankenstein von der Bahre aufsteht. Aber du hast viele Monate an einem System gearbeitet oder ein Team hat viele Monate an einem System gearbeitet, sich unfassbar viele Gedanken gemacht, viel Gehirnschmalz investiert und auf einmal sieht man, wie so aufersteht und wie es genutzt wird. Und man sieht halt den Nutzen, den es bringt für die Zielgruppe. Und man muss sich ja vorstellen, man selber hat vielleicht Stunden an der Tafel gestanden, um die Prozesse durch zu planen.

Und jetzt kommt der Computer hin und kann diese Prozesse tausendfach millionenfach pro Sekunde ausführen und zehntausende, hunderttausende Nutzer gleichzeitig versorgen mit den Prozessen, die man sich selber überlegt hat. Ich finde das nach wie vor auch nach 15 Jahren noch immer ein ganz besonderer Moment wie bei Cast Away.

Ich habe Feuer gemacht, gerade wenn man irgendwie dann auch sieht, wie Leute davon profitieren, was man gebaut hat. Der ewig lange manuelle Prozess ist endlich automatisiert. Oder wenn das Produkt in den Händen der Nutzer ist, erzeugt es Freude, weil es einfach Spaß macht zu bedienen. Also einfach, wenn das Ziel erreicht ist und man tatsächlich auch sieht, dass Leute die Früchte sehen. Auf jeden Fall oder auch davon profitieren, dass z.B. das habe ich relativ häufig, dass ein Arbeitsschritt dann entfällt.

Man erweitert eine Software und Dinge, die vorher manuell gemacht werden mussten, werden jetzt entweder das ist ideal vollautomatisch übernommen oder mit deutlich weniger Aufwand können sie durchgeführt werden. Und die Nutzer, wenn es jetzt Endnutzer sind, bedanken sich richtig dafür, dass man ihnen den Aufwand, diese mühevollen Aufwand dann erspart. Zukünftig superschön.

Gerade bei Infrastruktur Arbeit ist auch oft, dass am Ende das Ausbleiben von einer Sache das Ziel ist. Man hat diesen nervigen Schritt weg optimiert und jetzt kann die Person, die das vorher gemacht hat, sich anderen spannenden Dingen widmen. Oder man hat neue Möglichkeiten geschaffen, indem man irgendwie Flexibilität hergestellt hat, die vorher nicht da waren oder auch in einer anderen Art und Weise, wenn man endlich den Bug gefunden hat, der einen seit Tagen gefixt hat.

Das ist richtig.

Oh ja, und da EZA fehlten Coma oder irgendeinen Kast. Der Teufel liegt im Detail und dann auf einmal hat man erwischt.

Es ist schon oft, dass man so richtig Heureka Momente hat, weil man einfach A. Es hat geklickt. Sehr schön. Okay. Punkt neun. Du wirst unglaublich schlaue Leute treffen und von diesen lernen dürfen, weil sie besser sind als du. Genau das muss ich am Anfang ganz schön mit auch erst einmal umgehen können. Wenn man jetzt bei mir im Fall von der Uni kommt usw. Man denkt, man hat so viel gelernt und dann fängt man an zu arbeiten und stellt fest Boah, die Leute laufen alle Kreise um mich und ich lerne jetzt gerade erst, was man alles noch zu lernen hat.

Fand ich am Anfang ein bisschen schwierig mit umzugehen, aber mit der Zeit hab ich dann einfach gemerkt das ist einfach eine Riesenchance. Diese Leute haben schon viel Erfahrung. Vielleicht hätten die mir auch gesagt bauen nicht diese komplizierte Lösung, nur um hier irgendwie drei Anfrage irgendwohin zu schicken. Das ist wirklich. Diese Leute bereichern einen wirklich, weil man auch in diesem Umfeld natürlich schnell von denen sich viel abgucken kann. Ja und auf so viele Dimensionen. Also a Software technisch kannst du dir viel abgucken.

B Ich finde es mal ganz spannend zu gucken, welche Tools benutzt jemand und wie geht er damit um? Also auch da lernt man viel und auch methodisch. Wie gehen die an die Probleme heran? Beim Punkt verstehe, das Problem haben wir ja schon gesagt stellen die viele Fragen stürzen die sich in die Lösung? Dann gibt es Leute, hab ich festgestellt, die unglaublich viele Variablen im Kopf halten können. Richtig beeindruckend, wie viel gleichzeitige Informationen sie im Kopf halten können.

Dann gibt es so die Startblock Sprinter, die sofort losrennen. Dann gibt es die Leute, die das über die Distanz ordentlich Fahrt aufnehmen. Also es ist einfach interessant und inspirierend zu sehen, wie viele Arbeitsweisen es gibt, die zum Erfolg führen können.

Ja und gerade so bei unerwarteten Problemen, die dann auftauchen.

Sowas wie kühlen Kopf bewahren, aber dann auch genau wissen Ah, okay, ja, da sind wir jetzt außerhalb unserer Möglichkeiten. Dann wissen, zu wem man gehen muss. Also auch einfach das Verständnis von, wie ein Team Teil der Lösung sein kann und nicht nur man selbst jetzt da vor sich hin bastelt und quasi all diese Komponenten miteinander verknüpft. Das ist halt nicht einfach nur wie schon sagt ist, technisch ist, sondern das tatsächlich auch so ein bisschen Menschen dazugehören, dass man weiß Oh, das ist jetzt algorithmisch schwierig, da müssen wir jetzt hier das super Brain ist jetzt nicht so der beste Designer von großen Infrastruktur Sachen, aber Algorithmen voll dabei, diese Leute auch zu erkennen und dann auch zu wissen, wer welche Stärken hat.

Was man dann auch weiß, was man von wem lernen kann. Und einfach das wertschätzen. Ah, da weiß jemand was mehr als ich.

Wie macht er das? Das hält ja auch neugierig und fit, weil also zumindest mir geht es so, wenn ich dann das Gefühl hab, ich werde irgendwie abgehängt. Das ist nicht so. Da setz ich mich da lieber hin. Gerückt. Gerückte. Wie kann ich da dranbleiben? Also ich glaube vielleicht auch wenn einem das in einem gewissen Umfeld fehlt, wird man auch irgendwann, weil sie nicht bequem ist, mir jetzt noch nicht passiert. Aber es wäre schon schade, wenn jemand da ist, der irgendwie beeindruckt und mitzieht.

Punkt 10 Das kann man gar nicht überbetonen. Du verbringst sehr viel Zeit mit Details, Problemen und mit Detail Problemen, meine ich. Der Treiber passt nicht zur Datenbank. Das Encoding stimmt nicht. Kein Platz mehr auf der Festplatte. Die API ist Version 4, aber meine Ansteuerung Software nutzt noch Version 3, das muss ich migrieren. Hier passen irgendwie die Pfade nicht aufeinander. Die Konfiguration Einstellungen sind nicht korrekt und und und und Authentifizierung in jeglicher Couleur zähle ich auch mit dazu.

Also die Arbeit als Softwareentwickler macht viel Spaß. Aber diese Detail Probleme, die können auch sehr nervenaufreibend sein, weil die stehen auf keinem Projektplan. Aber die kosten sehr viel Energie. Wo liegt das Lock Fall? Schreibt der ein Fehler ins Lock Fail schreibt er nicht. Wo kann ich noch gucken? Kann ich mir im dieBürger dran gehen? Hab ich die Zugriffsrechte? Und und und und.

Oft kommt einem das so unnötige Probleme. Diese Version, dass die nicht zusammenpassen. Das hat auch mit meinem eigentlichen Problem nichts zu tun. Ja, aber leider halt doch, weil es irgendwie im Weg steht. Wenn dein Zug die Reifen zu breit für die Schienen freut und mit rauf fahren muss, war das Pech. Dann musste irgendwie basteln.

Ich glaube, das kann man mit dem Gefühl vergleichen, wenn die Bahn ausfällt oder bestreikt wird und du nicht zur Arbeit kommst. Du hast ein Problem, bevor du deine eigenen. Arbeit überhaupt beginnen kannst und ich glaube, das findet man drin, dass man man kann gar nicht zur Datenbank sich verbinden, weil die Treiber Version nicht passt. Oh Mann. Und eigentlich möchte man ja auf die Datenbank zugreifen und Dinge abspeichern und wieder rausholen. Und jetzt muss man sich mit diesen Treiber Problem beschäftigen.

Netzwerk Problemen in allen möglichen Facetten.

Ja, die Lösung könnte ganz einfach sein, wenn man einfach nur auf die andere Version updaten könnte. Aber leider hängt all der andere Kram, der schon läuft von der alten Version ab. So etwas macht man. Sieht man das parallel auf, kann man die alten Sachen mit updaten lassen. In der Regel auch die weniger schönen Probleme zu lösen, weil es einfach Mist ist, durch den man irgendwie durch muss. Aber ich glaube, das gibt’s überall. Das ist halt auch einfach die ich will ich unbedingt sagen Undankbaren.

Aber die, die kosten sehr viel Kraft und man sieht sehr wenig Fortschritt.

Und am Ende des Tages kann man sagen Ich habe den Zugriff auf die Datenbank ermöglicht, heute in acht Stunden und man kriegt einfach keinen Applaus, außer von den Leuten, die es vorher versucht haben und aufgegeben haben, verdient man da hinten der, der am allermeisten Wadenbeißer geblieben ist, sonst noch irgendwie weg probiert hat.

Diese Probleme sind an sich täglich Brot, weil ich auch, dass es die IDF Lichtarbeit von nix kommt.

Nix. Manchmal muss man halt auch sich mit so einem Dreck rumärgern.

Wenn unsere Zuhörer Fragen haben, können sie uns gerne eine E-Mail an Podcast etc. bei DE senden. Bitte hinterlasst uns eine 5-Sterne Bewertung und abonniert unseren Podcast für weitere spannende Themen. Wir freuen uns auch über Weiterempfehlung an Freunde und Kollegen. Für mehr spannende Technologie Themen könnt ihr auch auf Skill bei T. Slash Blog vorbeischauen. Nikolai, ich danke dir heute ausgesprochen für das Gespräch mit den 10 Punkten. Vielen, vielen Dank! Ja, danke.

Maurice hat echt Spaß gemacht. Ja, fand ich auch gut. Was besser?

Maurice KnoppSkillbyte Podcast #33: Traumjob IT?! – 10 Dinge die dir keiner sagt!
Mehr

Skillbyte Podcast #32: Women in Tech / Frauen in der IT!

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Women in Tech / Frauen in der IT!

// Inhalt //
01:15 – Wann hast du dich für Technologie interessiert?
03:04 – Ausbildung und Studium
04:09 – Welche Technologie Themen begeistern dich?
05:51 – Erste Hands-on Praxiserfahrungen im Talent Program
09:16 – Hohe Komplexität und Abwechslungsreichtum im Job
10:42 – Permanente Weiterbildung ist notwendig
11:30 – Frauen in der IT – Wie ist das für dich?
15:09 – Empfehlungen für Frauen die in die IT oder die einen technischen Beruf ergreifen möchten
19:37 – Digitale Bildung früh ermöglichen
20:31 – Mentoren
21:23 – Spielerisches Lernen für Kinder z. B. mit dem Calliope
23:16 – codiviti.de – Kreatives coding für Kinder
28:52 – Franziskas Fazit

Kreatives coding für Kinder: https://www.codiviti.de

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

 

TRANSKRIPT der Folge Skillbyte Podcast #32: Women in Tech / Frauen in der IT!

[00:00:01.050] – Franziska
Man muss sich als Frau tendenziell öfter beweisen, zumindest am Anfang. Also, es kann eine ganz klassische Situation sein, dass man irgendwie in einem Workshop sitzt und man ist eigentlich vielleicht die Expertin für das Thema. Aber das wird den anderen im Raum erst durch viele, viele Wortbeiträge bewusst.

[00:00:23.090] – Maurice
Herzlich Willkommen zur Skillbyte Podcast Episode Nr. 32: Women in Tech / Frauen in der IT! Abonniert unseren Podcast, wenn ihr mehr spannende Themen aus dem Technologie-Umfeld hören möchtet, wenn ihr IT-Entscheider oder -Fachkraft seid, ist das besonders interessant für euch. Wenn im Verlauf des Podcast Fragen aufkommen, sendet uns gerne eine Hörerfrage an podcast@skillbyte.de und lasst uns eine Bewertung da, da freuen wir uns immer sehr. Ebenso über die Weiterempfehlung an Freunde und Kollegen. Und heute zu diesem ganz besonderen Podcast habe ich einen ganz besonderen Gast. Hallo Franziska, ich freue mich super, dass du heute hier bist.

[00:00:58.580] – Franziska
Hallo Maurice, vielen Dank für die Einladung. Ich freue mich auch.

[00:01:01.970] – Maurice
Gerne. Ja, wir können ja keine Folge Women in Tech machen, ohne eine Frau dabei zu haben. Ganz klar.

[00:01:08.990] – Franziska
Da stimme ich dir zu.

[00:01:10.130] – Maurice
Ich bin wirklich gespannt, was wir in der nächsten halben-, Dreiviertelstunde, was du erzählen wirst. Vielleicht möchtest du uns ganz kurz erzählen, seit wann du dich für Technologie interessierst.

[00:01:21.860] – Franziska
Ja, also bei mir war das tatsächlich, muss ich sagen, ein ziemlicher Entwicklungsprozeß. Also ich bezeichne mich da selber eigentlich auch eher so als Spätzünderin. Ich glaube, ganz offiziell bin ich ein Digital Native mit meinen 27 Jahren. Aber meine Eltern haben zum Beispiel auch erst recht spät ihren ersten PC angeschafft und dementsprechend ist man dann auch erst über Social-Media, die Chat-Funktionen wie ICQ und Co., so richtig darauf aufmerksam geworden. Und ja, ich glaube, ein großer Punkt war da auch, dass in der Schule leider super wenig Fokus darauf gelegt wurde, uns an die IT auch heranzuführen. Ich weiß nicht, ob sich das wirklich stark bis heute verändert hat, aber ich hatte noch keinen Informatik- oder Digitalkurs in der Schule und bin dann erst im Studium ganz klassisch durch „Grundlagen des Programmierens in Java“ so in die Technologie-Schiene geraten.

[00:02:11.490] – Maurice
Und das hat dich dann so fasziniert, dass du gedacht hast, da würdest du gerne mehr drüber erfahren?

[00:02:15.810] – Franziska
Definitiv. Also ich hab da direkt gemerkt Programmieren macht mir einfach wahnsinnig Spaß. Also für mich ist das ein bisschen wie eine Fremdsprache, mit der du aber so viel ganz logisch irgendwie darstellen kannst, was dann ja irgendwie zu einem ganz konkreten Output auch führt. Also irgendwie, nichts ist unmöglich und das ist echt super spannend, finde ich.

[00:02:36.110] – Maurice
Also du meinst so ein bisschen die Mächtigkeit. Wenn du diese Sprache beherrschst, beherrscht du die Maschine.

[00:02:41.930] – Franziska
Genau das bringt das eigentlich ziemlich genau auf den Punkt.

[00:02:45.160] – Maurice
Ja, also das fasziniert mich immer wieder, wenn du Code schreibst, an dem du tagelang, wochenlang gearbeitet hast, dass das in dem Moment, wo du das Problem geknackt hast, ist es gelöst. Also wirklich wie so ein Zaubermoment.

[00:02:56.450] – Franziska
Genau. Und das sind eben auch so kleine Erfolgserlebnisse, die einen dann immer wieder pushen, noch etwas Neues zu lernen und auszuprobieren.

[00:03:03.980] – Maurice
Aber auch bei dir war es also so, dass du sagst, okay, die Schule hast du relativ untechnologisch überstanden und hast erst im Studium dazu gefunden. Weil du einfach gemerkt hast, weil du zufällig Algorithmen und Programmieren hattest und dann gemerkt hast, dass dir Programmieren Spaß macht.

[00:03:19.700] – Franziska
Genau. Also ich würde sagen, so eine naturwissenschaftliche Prägung hatte ich schon immer. Also auch so klassisch den Mathe Leistungskurs gewählt. Aber ja, die Informatik war mir ganz fremd. Also man hat da wahrscheinlich auch gewisse Stereotypen natürlich mit verbunden. Ne, der Nerd, der da die Nacht irgendwie in seinem Keller am Computer verbringen. Ja, dass das ein ganz falsches Bild ist, das wurde mir eigentlich erst im Nachhinein klar, ne.

[00:03:42.620] – Maurice
Ja, also das ist immer. Es tut mir wirklich weh, so etwas zu hören, dass sich da so wenig getan hat. Ich hatte zwar Informatik in der Schule, aber auch auf einem ganz seichten Niveau, möchte ich mal sagen. Und dann so als AG noch angeflantscht, auf gar keinen Fall Plicht Kurs und ja, kann das gut nachvollziehen. Aber jetzt sind wir ja bei dir. Das heißt, du hast auf einmal, der Funke ist übergesprungen und du hast festgestellt, okay, das macht mir richtig viel Spaß. Gibt es was, was dich ganz besonders bei Technologie-Themen reizt, außer dieser Sprache?

[00:04:14.210] – Franziska
Also ich glaube natürlich ist für mich auch das bigger picture immer wieder faszinierend. Ne, also, wenn ich mir allein meine kurze Lebensspanne bisher anschaue und überlege, was sich da weiterentwickelt hat. Also wir sprechen irgendwie mit Unternehmen wie Volocopter nun über die Option eines Flugtaxis. Wir haben Apps, die uns eigentlich in jeglichem Lebensbereich, sei das jetzt bei so etwas Simplen wie Splitwise, wo du deine Ausgaben mit dem Partner teilst, ne, bis hin zu irgendwie Google Maps, was wirklich mein Leben grundsätzlich verändert hat, ganz neue Möglichkeiten, ne. Und ich sehe das alles als Riesenchance. Also ich bin eigentlich fest davon überzeugt, muss man sagen, dass Technologien unser Leben massiv vereinfachen und bereichern werden, wenn wir eben lernen, auch damit richtig umzugehen, ne. Also da ist auch wieder das Thema Bildung. Das kommt jetzt bei uns an vielen Stellen heraus ein ganz, ganz großes Thema.

[00:05:04.910] – Maurice
Ja, auf jeden Fall. Und vielfach in den Medien wird ja, wenn man von Technologie spricht, wird ja wirklich nur Social-Media gezeigt. Oder die Konsumentenseite, also Social-Media, Gaming, ne. Die Leute benutzen Technologie, um sich zu unterhalten und diese kreative Seite, dass ich mit Technologie etwas erschaffen kann, ein Programm erschaffen kann, Kunst erschaffen kann, ganz viele verschiedene Dinge, da wird meist nicht so drüber berichtet.

[00:05:30.890] – Franziska
Ja genau, und vielleicht da auch nochmal einzuhaken. Technologie oder im Technologiesektor zu arbeiten bedeutet ja jetzt nicht per se immer, man muss jetzt wirklich der Software Developer sein und den ganzen Tag programmieren. Das ist eine Komponente davon. Aber es gibt ja so viele verschiedene Berufe in dieser Welt, was vielen gar nicht bewusst ist, ne.

[00:05:50.540] – Maurice
Auf jeden Fall. Jetzt warst du irgendwann ja auch mit dem Studium fertig, offensichtlich. Und dann hast du dir wahrscheinlich überlegt, was mache ich denn jetzt? Und da war für dich schon klar, dass du unbedingt was mit Technologie machen willst oder sogar mit Softwareentwicklung?

[00:06:04.370] – Franziska
Genau. Also mir war eigentlich nach dem Studium recht schnell klar, es soll weiter in diese Richtung gehen. Also ich hab nach der Schule ganz klassisch mit einem Wirtschaftsingenieurwesen-Studiengang angefangen und da mich dann recht schnell eben im Informatikbereich auf der einen Seite und im Statistikbereich auf der anderen spezialisiert. Also es ist glaub ich ganz klassisch, Wirtschaftsingenieurwesen ist erstmal sehr breit aufgestellt und man findet dann irgendwie so seine Leidenschaft, ne.

[00:06:31.550] – Maurice
Vertiefungsrichtung.

[00:06:32.840] – Franziska
Genau und bei mir war es dann auch so, ich hab mich im Master, als das dann alles auch deutlich ausgeprägter war, noch dazu entschieden, sozusagen für ein Jahr einen zweiten Master draufzusetzen, da bin ich ins Ausland für gegangen. Da gab’s schon recht früh sehr praxisorientierte Studiengänge. Bei mir war das dann ein Kurs, der hieß „Business Analytics“. Ich bezeichne das immer so als „Hands-on-Data-Science-Projekt-Kurs“, weil du wirklich ein Jahr lang programmiert hast, verschiedene Projekte durchgespielt hast und auch wirklich mit Unternehmen zusammen gearbeitet hast. Und das war für mich dann irgendwie so der letzte Indikator, okay, hier bist du richtig. So diese Richtung Data Science, also Schnittstelle zwischen Computer Science und Statistik und Mathematik. Genau.

[00:07:13.460] – Maurice
Ja perfekt, da kommt ja sozusagen, kommen ja alle deine Stärken dann wieder zum Einsatz, ne, die mathematische Komponente, die statistische Komponente und dennoch darfst du Code schreiben, um das alles zu verknüpfen, miteinander. Und dann musstest du dir überlegen, gehe ich jetzt in die Wissenschaft oder zu einem Unternehmen?

[00:07:29.420] – Franziska
Ja, irgendwie so eine klasse Frage, die sich glaube ich ziemlich viele Leute nach dem Studium dann stellen. Also mir hat das wissenschaftliche Arbeiten immer viel Spaß gemacht, aber nichtsdestotrotz habe ich mir irgendwie beide Welten ein bisschen genauer angeschaut, mir da auch Zeit genommen, um wirklich ja, meine Optionen so bisschen besser kennenzulernen und bin dann eigentlich mehr durch Zufall auf das Traineeprogramm Median von Bertelsmann gestoßen. Das ist ein Talent Programm, was sich eben speziell auf Data Science spezialisiert. Also ich glaube, da auch so das erste und einzige bisher, was ich gefunden habe. Und ja, das hat mich überzeugt. Einfach ohne jetzt hier Eigenwerbung machen zu wollen, weil mir so die Möglichkeit gegeben wurde, ganz ganz viele verschiedene Facetten des Data Science, in auch ganz verschiedenen Industrien, eben kennen zu lernen.

[00:08:15.530] – Maurice
Ja, cool. Das finde ich supergut, dass Unternehmen, meistens etwas vor dem Bildungsapparat erkennen, wohin die Zukunft geht und diese Programme auflegen. Und innerhalb des Programms gibt es noch viele Unabwägbarkeiten, weil es eben sehr neu und sehr jung ist.

[00:08:32.130] – Franziska
Definitiv. Also die neueste war ja die Corona-Krise. Aber selbst das konnte man eben sehr gut managen, einfach weil, das finde ich immer wieder schön, bei digital aufgestellten Teams, die können eben auch sehr schnell auf remote umsteigen. Also das ging ganz easy.

[00:08:46.560] – Maurice
Und jetzt bist du quasi von der Uni in dieses ja, ich möchte nicht sein Traineeprogramm oder ist es ein Traineeprogramm?

[00:08:54.470] – Franziska
Genau. Also ich bezeichne es manchmal eher so als Talent Program, weil Trainee, glaube ich, im Ausland auch oft Praktikum heißt. Und ich finde das darf man nicht verwechseln, ne.

[00:09:04.160] – Maurice
Also wahrscheinlich so ein Job-Einstiegs-Programm. Du hast in relativ kurzer Folge viele verschiedene Stationen durchlaufen und einen guten Einblick in den Konzern bekommen, aber immer mit Fokus auf Daten.

[00:09:15.030] – Franziska
Genau.

[00:09:15.410] – Maurice
Perfekt. So und jetzt bist du ja schon seit einiger Zeit im Job, und haben sich die Erwartungen an das Technologie-Umfeld, die du vielleicht hattest, auch im Job bestätigt. Bist du glücklich mit deiner Wahl?

[00:09:28.190] – Franziska
Definitiv. Also ich hab den Data Science Beruf immer als sehr abwechslungsreich empfunden und das hat sich auf jeden Fall bestätigt. Also es ist ja ein sehr komplexes Gebiet. Ich glaube Maurice, das kannst du auch aus deinen Erfahrungen als Data Ingenieur beispielsweise bestätigen, man lernt eigentlich ja täglich dazu. Man muss sich irgendwie auch immer fortbilden, ne.

[00:09:49.280] – Maurice
Es ist, ich kann es ja sagen, ich hab jetzt schon 10 Jahre Perspektive auf dieses Feld. Es ist eine rasante Entwicklung. Es war damals schon eine rasante Entwicklung, aber man merkt, das explodiert nochmal oder das steigt noch mal exponentiell an. Einfach weil, du hast es schon bei deiner Motivation gesagt, Technologie wird immer wichtiger in verschiedenen Bereichen des Lebens oder in nahezu allen Bereichen des Lebens. Und früher hat man häufig mit einer technologischen Lösung, Datenbank, auf viele Probleme geantwortet. Und in den letzten Jahren sieht man, dass sich so immer weiter Verästelungen und Spezialisierungsformen bilden, also dass sich diese Branche einfach immer weiter, ja spezialisiert auf die einzelnen Anwendungsfälle. Und da es immer mehr Anwendungsfälle im Leben gibt und immer weitere Spezialanwendungen dafür gebaut werden – in Summe wächst dieser Bereich extrem.

[00:10:42.910] – Franziska
Genau. Und ich glaube, da ist es auf der einen Seite natürlich sehr spannend mit dran zu wachsen. Auf der anderen Seite eben auch eine Herausforderung. Also das Lernen hört sozusagen nicht im Studium auf, sondern ich sitze gerade auch wieder an einem neuen Coursera Kurs, um eben noch tiefer in das ganze Thema Cloud Engineering reinzusteigen.

[00:11:01.420] – Maurice
Ich glaube das ist ganz wichtig, was du sagst, also Leben heißt lernen auch für mich. Und so wie du das kennengelernt hast im Studium, dass man im Prinzip einen breiten Überblick hat und dann sein Steckenpferd findet in dieser Galaxie, genauso ist es auch im Technologie-Umfeld. Man kommt relativ schnell an Grenzen, man kann nicht alles können, sondern man muss da sein Spezialfeld finden und auch das ist groß genug. Aber es freut mich außerordentlich, dass du da bisher so einen schönen Weg beschritten hast. Jetzt bist du ja, als weibliche Person in der IT-Umgebung, oftmals in der Unterzahl. Ne, das kannst du wahrscheinlich so unterschreiben.

[00:11:38.920] – Franziska
Gerade im Projektteam bin ich tatsächlich die einzige Frau.

[00:11:42.220] – Maurice
Genau. Also das war schon zu der Zeit, als ich studiert habe, das ist jetzt auch gut 10 Jahre her, so da war es, war der Frauenanteil noch geringer als es heute ist, also es tut sich auf jeden Fall was. Aber die Stereotypen haben richtig durchgeschlagen. Stellst du denn geschlechterspezifische Unterschiede fest, jetzt in deiner tagtäglichen Arbeit?

[00:12:00.790] – Franziska
Also ich fühle mich in der Tech-Branche sehr wohl und das liegt vor allem daran, dass eben der Teamzusammenhalt wahnsinnig gut ist, dass ich nicht das Gefühl eben habe, dass es große geschlechtsspezifische Unterschiede gibt. Es gibt natürlich einige Dinge, wo wir glaub ich, soziokulturell noch so geprägt sind, dass natürlich, ja gewisse Dinge auffallen. Ich glaube, wir alle sind von Rollenklischees nicht ganz befreit und ich glaube, so ein Beispiel, was mir spontan einfällt, ist immer das Thema: Man muss sich als Frau tendenziell öfter beweisen, zumindest am Anfang. Also es kann eine ganz klassische Situation sein, dass man irgendwie in einem Workshop sitzt und man ist eigentlich vielleicht die Expertin für das Thema, aber das wird den anderen im Raum erst durch viele, viele Wortbeiträge bewusst. Und man merkt dann auch so richtig, wie sich das Verhalten gegenüber ändert, ne. Also das ist nur so meine eigene Erfahrung. Aber es wird mir von vielen Bekannten und aus meinem Netzwerk eben auch bestätigt. Und ich denke, das kommt natürlich von zwei Seiten. Einmal eben, wie du es beschreibst, gewisse Stereotypen, von denen wir auch nicht befreit sind und auf der anderen Seite eben, dass vielleicht Frauen eben durch ihre kulturelle Prägung gewisse andere Charakteristika an den Tag legen, um mal Stichworte wie Impostor-Syndrom, was bei Frauen eben stärker ausgeprägt ist, zu nennen oder eben Zurückhaltung generell.

[00:13:21.190] – Maurice
Das wäre jetzt wahrscheinlich gar nicht mal auf den Technologiebereich gemünzt, sondern generisch.

[00:13:26.830] – Franziska
Genau. Also ich denke, Unterschiede bestehen, wenn eben immer noch in ja, in strukturellen Problemen oder strukturellen Dingen, die wir angehen müssen. Technologisch sollte es da keine Unterschiede geben, in der Sache an sich.

[00:13:40.520] – Maurice
Nee, das sehe ich ganz genauso. Also es ist natürlich, als Frau ist man erst mal ungewöhnlich. Ich glaube, das kann man einfach schon mal sagen in dem Bereich. Wobei ich auch schon in Teams gearbeitet habe, wo es wirklich 50:50 verteilt war. Und das war, ich arbeite auch so gerne mit Frauen zusammen, überhaupt kein Problem. Also ich bin, und ich glaube der Tech-Bereich begünstigt das auch so ein bisschen, da zählt halt Fachlichkeit und fachliche Kompetenz sehr viel und man hat generell so ein kollaborativen Ansatz. Eben weil dieses Feld so riesig ist, weiß man okay, alleine bin ich hier verloren, ich muss mit den anderen Menschen zusammenarbeiten und man hat nicht so viele Ellenbogen-Typen.

[00:14:19.720] – Franziska
Das kann ich auf jeden Fall bestätigen. Und ich glaube, das ist auch der Hauptgrund, warum ich mich in meinem Job und dem Umfeld sehr wohlfühle. Es ist ein Miteinander und niemand muss sich auch schämen, dass er irgendwie vielleicht am Anfang natürlich noch nicht die besten Programmiertricks kennt oder sich in gerade diese komplexen Sachverhalte auch immer neu reinarbeiten muss, sondern da ist viel Teamarbeit gefragt und auch immer, ja willkommen, würde ich sagen.

[00:14:44.560] – Maurice
Ja, genau. Also weil eben dieser riesen Bereich als Einzelperson kaum zu beherrschen ist und man darauf angewiesen ist, von Außenstehenden oder was heißt Außenstehenden, anderen Projekt-Mitgliedern, zu lernen und dann eben auch lernen möchte, ne. Also das glaube ich, es gibt keinen IT-Menschen, der sagt Nö, ich hab genug gelernt und lern jetzt nix mehr.

[00:15:03.910] – Franziska
Ist mir noch nicht untergekommen.

[00:15:05.770] – Maurice
Das würde auch nicht lange gutgehen, glaube ich. Was würdest du denn jetzt anderen Frauen empfehlen, die damit liebäugeln, in dem IT-Bereich oder in einem Technologiebereich, es gibt ja auch andere Bereiche, z.B. Physik oder so, Fuß fassen zu wollen.

[00:15:19.930] – Franziska
Also auf jeden Fall erstmal, probiert es einfach aus. Ihr werdet schnell genug merken, ob euch das Spaß macht. Also ich kann auch gerade empfehlen, mal vielleicht ein Praktikum in dem Bereich zu machen, weil man dadurch eben schon mal so eine gewisse Einschätzung bekommt. Ist das was für mich oder nicht? Bestes Beispiel von meiner Seite. Ich habe mein erstes Praktikum bei der Audi AG in der Logistik Planung gemacht und mir war sehr schnell klar, dass ist ein toller Bereich, aber eben nicht mein Bereich und so stellt man diese Dinge eben fest, ne. Und auf der anderen Seite würde ich auch immer sagen, wenn ihr eine Chance bekommt, nehmt diese auf jeden Fall an und sagt nicht nein. Also auch wenn ihr vielleicht im ersten Moment denkt, oh, bin ich dem denn schon gewachsen. Also ein klassisches Beispiel hier sind ja immer so Stellenausschreibungen. Da ist ja allgemein bekannt Frauen bewerben sich erst, wenn sie irgendwie 90 Prozent der Kriterien erfüllen. Niemand erfüllt diese Anforderungsliste. Also es werden ja gefühlt oft fünf Programmiersprachen, dann noch drei Jahre Berufserfahrung et cetera pp gefragt. Und ich würde dann immer sagen, man hat ja auch nichts zu verlieren. Also die Bewerbung wird ja dann gescreent und wenn die Leute dich kennenlernen wollen, dann kommen sie auf dich zu und das ist doch super.

[00:16:31.120] – Maurice
Auf jeden Fall. Dieser offene Ansatz öffnet ganz viele Türen und Möglichkeiten. Ja, ich finde auch eine prima Möglichkeit, um so in diese IT-Welt mal reinzuschnuppern. Sind zum Beispiel Hackathons, die oft von Firmen am Wochenende durchgeführt werden, wo man einfach innerhalb von 48 Stunden in einem Projektteam zu irgendeiner Aufgabenstellung ein Ergebnis liefern muss. Und das muss nicht immer Sourcecode sein. Also gerade auch im Bereich Produktdesign Planung, Präsentation kann man da sehr viel lernen und die Leute sind super offen. Ne, kann kann man sich vorstellen wenn die schon in ihrer Freizeit da hingehen, dann sind das tendenziell interessierte Leute, die auch Technologie lieben. Oder Coursera Kurse oder Udemy Kurse, die es auch noch gibt. Wahrscheinlich auch bei YouTube gibt es jede Menge Material, um sich gewisse Technologien mal anzuschauen oder das einfach mal zu probieren.

[00:17:19.810] – Franziska
Genau. Und vielleicht um nochmal bei dem Hackathon-Thema einzuhaken das ist echt ein guter Punkt. Da kommt auch nochmal dieser Teamspirit eben raus, der in der Tech-Branche eben ganz groß ist. Und ich finde auch, da sind gerade heterogene Teams super wichtig, um eben auch bei diesen innovativen Gedanken, ja alle möglichen Facetten zu berücksichtigen. Bei mir selber war es so, ich hab mich lange nicht getraut, an Hackathons teilzunehmen, eben auch, weil ich dachte, oh, da muss man jetzt bestimmt schon mega gut programmieren können. Und war dann ganz froh, als ich mich das erste Mal getraut habe, weil es wirklich auch viel um eben das gemeinsame Ideen generieren und Brainstorming geht. Und das war einfach echt ein super Wochenende für mich.

[00:17:59.440] – Maurice
Ja, also ich habe auch schon einige gemacht, aber wahrscheinlich ist das jetzt auch wieder so ein Stereotyp. Ich hab mich nie nicht getraut, sondern ich hatte immer am meisten Spaß, wenn ich da hingegangen bin mit mindestens einer Person, die ich irgendwie kannte. Also das wär auch noch eine Empfehlung von mir. Nehmt einen Freund, nehmt eine Freundin mit, meldet euch zusammen an. Oftmals sind diese Hackathons auch kostenlos und ihr lernt, also ihr werdet so viel Spaß haben. Ihr werdet tolle Menschen kennenlernen. Es wird auch aufregend sein, keine Frage. Meistens ist das Essen auch gut. Also das kann ich jetzt so aus meiner Erfahrung sagen, es ist ein rundum gelungenes Wochenende, sehr intensiv, aber das macht super viel Spaß. Auf jeden Fall. Und es ist ein relativ niedrigschwelliger Einstieg in die Technologie und in alle Aspekte davon. Also sowohl Coding als auch Problemanalyse, das ist ja auch ganz wichtig, es geht ja nicht nur ums Programmieren, sondern auch um eine Vorstellung davon zu bekommen, was bauen wir eigentlich hier? Wie ist das sinnvoll? Wie muss die App aussehen? Wie muss die Website aussehen? Design jetzt auch wirklich optisch? Wie muss die Website aussehen oder die App aussehen? Ich hab mal an einem Hackathon für Kinder, war ich Mitorganisator und eine Gruppe von vier Mädels hat für ein Spiel, das Spiel war quasi fertig, hat nur mit dem Level Editor möglichst kreative Levels gebaut. Zwei Tage lang. Und das war super hinterher, also das hätte man so direkt als Produkt verkaufen können, unglaublich. Und die Eltern dieser Kinder haben das selber kaum glauben können, also das war einfach super schönes persönliches Erlebnis von mir.

[00:19:23.290] – Franziska
Ja, cool.

[00:19:24.240] – Maurice
Und wirklich, also ich glaube, was wir beiden sagen können oder in die Welt hinaus rufen können ist: Technologie ist ein super großes, spannendes Feld und niemand muss Angst davor haben und schon gar nicht, sich damit zu beschäftigen und da einzutauchen. Genau. Es ist auch manchmal etwas traurig. Also mir sagte auf diesem Hackathon ein Waldorfschüler, dass, also das ist jetzt auch schon ein paar Jahre her, das war glaube ich 2017, dass bei ihm an der Schule alle elektronischen Geräte verboten sind und man sich damit gar nicht beschäftigen dürfe. Das ist natürlich ein Wahnsinn, wenn man sich das überlegt, dass da Kinder nicht lernen, wie man eine E-Mail schreibt oder im Internet etwas recherchiert, eine Reise bucht, einen Mietwagen besorgt oder so. Also bitte, bitte, liebe Eltern, macht das nicht. Digitale Bildung ist genauso wichtig wie normale Bildung.

[00:20:09.580] – Franziska
Ja, definitiv. Also du sprichst da den super wichtigsten Punkt an, Bildung muss eben in der Schule und so früh wie möglich ansetzen, in jeglichem Bereich. Und wenn der digitale Bereich bei uns mittlerweile so einen Stellenwert einnimmt, dass ja wirklich jeglicher Bereich unseres Lebens davon geprägt ist, dann muss das eben ein zentraler Bestandteil sein.

[00:20:30.300] – Maurice
Auf jeden Fall. Hast du denn schon mal Freundinnen oder Bekannte ermutigt, die vielleicht so an der Schwelle standen und nicht wussten, traue ich mich das, kann ich das? Das du gesagt hast, ja, du musst das probieren?

[00:20:41.340] – Franziska
Also ich bin sehr froh darüber, dass ich in meinem Studium und auch schon in der Schulzeit immer sehr starke weibliche Mentorinnen an der Seite hatte, die mich selber auch darin bestätigt haben, Dinge einfach mal auszuprobieren. Und natürlich ist es mir eine Herzensangelegenheit, das auch weiterzugeben. Also ich sehe mich mittlerweile auch als Mentorin.

[00:21:00.030] – Maurice
Bist du.

[00:21:01.240] – Franziska
Dankeschön. Und mache das auch sehr aktiv. Also ich hab ein Netzwerk, aus Studentinnen, mit denen ich mich da regelmäßig austausche, aber möchte eigentlich auch sehr gerne noch viel mehr, ja ich sag mal in früheren Jahren da ansetzen. Weil, ich glaube auch gerade die Ermutigung von jungen Frauen, das heißt Frauen, die sich irgendwie noch in der Schule befinden, so in der Mittel- und Oberstufe. Das ist ein toller, also ein toller Zeitpunkt, um hier eigentlich anzusetzen.

[00:21:23.400] – Maurice
Genau, und auch um spielerisch das ganze Thema kennenzulernen. Da gibt es ja auch mittlerweile tolle Technologien, diesen Calliope zum Beispiel, ich hoffe, ich spreche das richtig aus. Das ist so ein kleiner Technick Bausatz, den man, ja mit Point-and-Click-Mechanismen programmieren kann. Also verschiedene Sensoren und Aktoren können da miteinander verknüpft werden. Entweder blinken nur Lichter oder das Gerät hat noch andere Optionen und ist relativ günstig und wird an Schulen eingesetzt. Ich hab mal bei einem Event gesehen wie Kinder, die waren aber so im Bereich, würde sagen zwischen 9 und 12 Jahre, es war eine gemischte Gruppe, Jungs wie Mädchen. Sie haben Armbänder programmiert, also so LED Armbänder und die Blinksequenz und die Farbsequenz konnte angepasst werden und das war, also mit erwachsenen Augen könnte man das ja belächeln, aber die hatten so einen unfassbaren Spaß damit und auch eine Kreativität. Also, ja es war eine Freude das zu sehen.

[00:22:19.470] – Franziska
Ja, das ist sehr super. Also das sind ja genau diese Projekte, ja, die ich auch im Kopf habe. Es muss ja nicht immer etwas direkt programmiert werden, was dann einen riesigen Mehrwert schafft, sondern es geht auch erstmal darum, den Spaß an dieser Technologie für sich zu entdecken und überhaupt zu verstehen. Aha, was ist denn möglich, ne?

[00:22:37.830] – Maurice
Auf jeden Fall. Also das ist auch was, was man vielleicht sagen soll. Versucht nicht direkt mit dem selbstfahrenden Auto, das als erstes Projekt anzugehen, sondern irgendwelche kleinen Dinge, ne. Ob es jetzt das blinkende Armband ist, ob es irgendwie eure eigene Webseite ist, wo ihr selber die Urlaubsfotos drauf stellt, ob es eine App ist mit den letzten Karnevalsfotos oder ob ihr euch einfach nur, das ist ja auch technologisch getrieben, ob er euch hinsetzt und zum Beispiel euren eigenen Podcast aufnehmt und selber schneidet und produziert oder selber mit Musikerstellung anfangt. Elektronische Musikerstellung, da gibt es in allen Facetten, Farben und Formen, gibt es da Werkzeuge für. An dieser Stelle möchte ich ein Shout Out an das codiviti-Projektteam, um Irena und Marianne platzieren, ich packe die URL in die Shownotes zu dieser Podcast Episode. Da geht es ja um Kinder, insbesondere Mädchen im grundschulfähigen Alter oder etwas darüber hinaus, die eben an dieses Technologie-Thema herangeführt werden. Da hast du ja auch vor, ich glaube zwei oder drei Wochen, vorgesproche, willst du dazu kurz etwas sagen?

[00:23:42.840] – Franziska
Ja, super gerne. Du hast da ja tatsächlich die Verknüpfung hergestellt. Dafür nochmal vielen Dank. Weil ich finde, das ist ein wahnsinnig tolles Projekt, was die beiden da aufgebaut haben.

[00:23:52.180] – Maurice
Finde ich auch.

[00:23:53.060] – Franziska
Ich hatte eine, ja kleine Rolle da drin, indem ich eben mal vorgestellt habe, was ich gemacht habe im Studium und wie ich mich eben in meine Rolle als Data Scientist entwickelt habe. Und die Mädchen konnten dann mir Fragen dazu stellen und die waren wirklich super interessiert. Man hat gemerkt, dass die sich wirklich durch dieses Projekt für Technik begeistern konnten und es hieß dann auch so, wann legen wir endlich los? Da war ganz viel Power, sag ich mal dahinter. Und das sind eben genau die Projekte, auf die es glaube ich ankommt. Also natürlich geht es generell darum, alle jungen Menschen für Technologie zu begeistern, das will ich auch nochmal betonen. Aber ich hatte ja eben dieses Thema Sozialisierung angesprochen und es ist einfach für Mädchen doch noch ein bisschen schwieriger, mit dem Thema in Kontakt zu kommen und auch dieses nötige Selbstvertrauen da aufzubauen. Und ja, mit solchen Workshops kann da eben massiv viel bewirkt werden. Das finde ich einfach richtig klasse.

[00:24:46.000] – Maurice
Also die Workshops von codiviti, diese digitale Bildung für Kinder, das ist super wichtig. Ich habe, ich weiß nicht, wie deine Erfahrungen sind, aber ich habe auch festgestellt, dass oftmals die größten Blockaden in den Köpfen der Eltern oder der Lehrer lagen, also dass die ganz erstaunt waren, oh, mein Kind kann das, ne einfach, weil die sich selber nicht damit beschäftigt haben und vielleicht je nach Alter auch nicht mehr müssen. Und jetzt fangen die Kinder an, so spielerisch diese Levels zu bauen, Designs zu erstellen, Programme zu schreiben, Videos zu bearbeiten. Das ist auch heute auf jedem Handy möglich. Webseiten zu programmieren, dass die Eltern das gar nicht für möglich gehalten haben, sondern für schwarze Magie, die man nicht so einfach erlernen kann, ich weiß es nicht. Und ich glaube, wir haben hier in Deutschland einen großen Nachholbedarf für Mädchen wie auch für Jungs generell, das Thema Technologie und den kreativen Einsatz von Technologie, also das man selber etwas erschaffen kann. Diesen jungen Menschen näherzubringen, zu zeigen, was ist möglich, um auch als Hochtechnologieland zu bestehen. Weil andere Kulturen tun das und ich meine, man sieht es am Silicon Valley oder an, ja auch vielen, vielen Unternehmen, die jetzt aus China kommen, wie Tik Tok zum Beispiel oder ByteDance, also der Hersteller von Tik Tok, dass da auch ganz schön was im Umbruch ist.

[00:26:01.560] – Franziska
Ja, definitiv. Und ich glaube, es ist ja auch irgendwie der Auftrag eines Landes, seine, ja seine Gesellschaft so auszubilden, dass sie für diese Entwicklungen gewappnet ist und auch egal aus welchen gesellschaftlichen Strukturen sie eben kommen, es muss einfach eine, ja eine gewisse Grundausbildung hier passieren.

[00:26:20.630] – Maurice
Ich denke, es ist ganz wichtig, dass Menschen generell verstehen, wie Technologie funktioniert. Also was macht ein Computer? Warum ist er so schnell bei manchen Sachen und warum kann er einen Hund nicht von einer Katze unterscheiden? Oder warum ist das ein ganz, ganz schwieriges Problem für einen Computer, aber es ist kein schwieriges Problem, eine Milliarde Zahlen zu addieren, ne. Warum? Warum kommt das? Warum ist es so gelagert, wie es ist? Und dass man ein generell solides, technologisches Grundverständnis bekommt.

[00:26:47.040] – Franziska
Weil so kann man ja auch nur, also in einer transparenten Welt, die man auch versteht, kann man ja auch nur sinnvolle und mündige Entscheidungen treffen, ne.

[00:26:56.610] – Maurice
Ja, genau. Und die Angst geht ein bisschen verloren. Also manchmal, das ist auch schon ein bisschen traurig, sieht man Leute vor diesen moderneren Fahrkartenautomaten so ein bisschen verzweifeln, weil sie nicht mehr wissen, wie man das so bedient mit Touchscreen. Und da sitzt keiner mehr drin, der einem die richtige Fahrkarte anreichert, einfach weil es viel günstiger ist, nur so einen Automaten da hinzustellen. So, und für die Jungen ist es heute kein Problem, so ein Gerät zu bedienen und das ist total wichtig, dass das jeder kann. Nahezu alle Berufe werden in Zukunft den Einsatz digitaler Werkzeuge absolut voraussetzen. Also wir sind immer in so einer Blase und für uns ist das völlig normal, eine Videokonferenz durchzuführen, E-Mails zu schreiben, im Internet zu recherchieren, Präsentationen zu machen und die im Internet zu zeigen, mit digitaler Musik, mit digitalen Videos umzugehen, XING, LinkedIn für Jobbewerbungen und so zu benutzen. Das darf man nicht vergessen, dass das für uns total natürlich ist und für viele andere Menschen eben nicht.

[00:27:51.800] – Franziska
Ja, aber es ist durchaus noch erlernbar.

[00:27:54.010] – Maurice
Auf jeden Fall.

[00:27:55.670] – Franziska
Ich finde, für mich war jetzt die Corona Krise tatsächlich ein sehr, ja positives und irgendwie empowerndes Beispiel, weil einfach die Blockade auch Richtung Mobil Office, so Team Konferenzen, ne also Teams-Konferenzen, wo du wirklich dann digital miteinander sprichst. Das ist einfach gefallen durch, ja durch absoluten need das jetzt so einzuführen. Und viele haben ganz neue und bereichernde Elemente auch daran für sich entdecken können, ne.

[00:28:22.970] – Maurice
Auf jeden Fall. Also jung wie alt, ich meine, wenn man sich nicht besuchen kann und eine Videokonferenz die einzige Möglichkeit ist, dass man sich mit der Familie verknüpfen kann, dann geht’s auf einmal, ne. Oder wenn in vielen Unternehmen Homeoffice kein Thema ist, so aber die Leute nicht mehr in das Büro kommen dürfen, weil das Gesundheitsamt abgesperrt hat, dann geht’s auf einmal. Das ist immer, wenn etwas geschehen muss oder man andere Motivationen hat, dann geht es oft dann sehr schnell, ja. Das stimmt auf jeden Fall hoffnungsvoll. Also ich fasse nochmal zusammen, du bist mit deiner Berufsentscheidung auf jeden Fall zufrieden.

[00:28:56.540] – Franziska
Auf jeden Fall und ich möchte auch wirklich nochmal betonen, dass ich glaube, dass gerade eine super Zeit eigentlich für Frauen in der IT-Branche ist. Also ich habe bisher wirklich nur positive Erfahrungen gemacht, viele Mentoren gehabt, die mich gepusht haben und viel Bestätigung. Und das ist doch einfach eine schöne Sache.

[00:29:14.810] – Maurice
Ja, ich würde auch sagen, auch Männer haben in der IT eine gute Zeit oder gute Jobaussichten. Frauen natürlich auch. Und in diesem kollaborativen Umfeld, wer würde da nicht gerne arbeiten?

[00:29:26.210] – Franziska
Genauso sehe ich das auch.

[00:29:28.040] – Maurice
Und vielfältige Aufgaben gibt’s auch. Und Bedarf ist natürlich auch da.

[00:29:31.730] – Franziska
Mir bleibt vielleicht noch zu sagen, wirklich, an alle Frauen oder generell alle IT-Begeisterten da draußen. Wenn euch das Thema reizt schnuppert, einfach mal rein. Ihr werdet glaube ich begeistert werden, von dieser Welt. Und genau ansonsten dir Maurice, herzlichen Dank für die Einladung, das war ein super spannendes und ja, bereicherndes Gespräch. Danke.

[00:29:53.540] – Maurice
Ich gebe das gerne zurück. Vielen, vielen Dank, dass ich dich heute hier im Podcast haben darf. Wenn unsere Zuhörer Fragen haben oder Feedback zur Podcast Episode, können Sie uns gerne eine E-Mail schicken an podcast@skillbyte.de. Wir freuen uns immer über Bewertungen oder wenn ihr den Podcast abonniert. Empfehlt uns auch an eure Freunde und Kollegen weiter. Wenn ihr Informationen zu mehr spannenden Technologie-Themen haben möchtet, schaut auf skillbyte.de/blog vorbei. Franziska, ich wünsche dir noch einen schönen Abend.

[00:30:19.310] – Franziska
Dir auch, danke.

Maurice KnoppSkillbyte Podcast #32: Women in Tech / Frauen in der IT!
Mehr

Skillbyte Podcast #30: Die Zwölf Faktoren des Cloud Native Development (Teil 2)

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Die Zwölf Faktoren des Cloud Native Development (Teil 2)

// Inhalt //
01:16 – Faktor 7: Bindung an Ports / Port binding
06:36 – Faktor 8: Nebenläufigkeit / Concurrency
14:31 – Faktor 9: Einweggebrauch / Disposability
19:34 – Faktor 10: Dev&Prod Vergleichbarkeit / Dev&prod parity
25:05 – Faktor 11: Logs
29:37 – Faktor 12: Administrationsprozesse / Admin processes

Twelve Factor App: https://12factor.net/

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #30: Die Zwölf Faktoren des Cloud Native Development (Teil 2)
Mehr

Skillbyte Podcast #29: Die Zwölf Faktoren des Cloud Native Development (Teil 1)

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Die Zwölf Faktoren des Cloud Native Development (Teil 1)

// Inhalt //
06:34 – 5 Leistungsversprechen von 12 Factor Apps
06:44 – Generelles Ziel: Verwednung deklarativer Formate
08:12 – Generelles Ziel: saubere Abgrenzung
08:43 – Generelles Ziel: Gleichartige Umgebungen (Dev, Stage, Prod)
08:55 – Generelles Ziel: Cloud-Deployments
09:00 – Generelles Ziel: Skalierbarkeit
10:56 – Faktor 1: Codebasis / Codebase
15:32 – Faktor 2: Abhängigkeiten / Dependencies
21:03 – Faktor 3: Konfiguration / Configuration
25:47 – Faktor 4: Unterstützende Dienste / Backing Services
29:59 – Faktor 5: Build, release, run
35:47 – Faktor 6: Prozesse / Processes

Twelve Factor App: https://12factor.net/

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #29: Die Zwölf Faktoren des Cloud Native Development (Teil 1)
Mehr