By Wolfgang Gassler, Andy Grunwald
Der Engineering Kiosk ist der deutschsprachige Software-Engineering-Podcast mit Wolfgang Gassler und Andy Grunwald rund um die Themen Engineering-Kultur, Open Source, Menschen, Technologie und alle
... more
The podcast currently has 146 episodes available.
Zeitsynchronisation: Ein Element, wovon wir ausgehen, dass es einfach funktioniert
So gut wie jede Applikation benötigt die aktuelle Zeit als ein Element zur Berechnung, zum Logging oder auch zur Synchronisation. Besonders bei mehreren Systemen, die miteinander kommunizieren, ist die Synchronisation der Zeit essenziell. Dazu zählen z.B. verteilte Systeme wie Datenbanken oder auch IP-basierte Funk- und Videoübertragungssysteme.
Doch wie funktioniert das eigentlich und was steckt dahinter? In dieser Episode geht es also um Zeit und Zeitsynchronisation.
Wir sprechen über die beiden Protokolle NTP, das Network Time Protocol und PTP, das Precision Time Protocol. Was sind das für Protokolle? Wo kommen diese zum Einsatz, welche Genauigkeit legen diese zu Grunde und wo kommen diese an ihre Grenzen? Und was sind Boundary Clocks und Transparent Clocks?
Weiterhin schauen wir uns mal an, wozu spezifische Hardware zur Zeitsynchronisation gebraucht wird und woher die Ursprungszeit eigentlich stammt.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an [email protected].
(00:01:08) Daniel Boldt und Thomas Behn von Meinberg
(00:05:46) Was ist das Network Time Protocol (NTP)?
(00:06:35) Werbung/Info
(00:07:35) Was ist das Network Time Protocol (NTP)?
(00:22:54) Stratum-Server, Zeit-Hierarchien und symmetrische Netzwerke
(00:30:29) Sicherheit bei Network Time Protocol (NTP)
(00:33:03) Was ist das Precision Time Protocol (PTP)?
(00:44:03) Anwendung von Precision Time Protocol (PTP) und dedizierte Hardware
(00:49:27) Die Probleme vom Precision Time Protocol (PTP)
(00:58:42) Dedizierte Hardware zur Zeitsynchronisation
Dein Code ist nichts wert, bevor er nicht in Produktion ist!
Viele Software-Entwickler*innen haben sich bereits in der Situation gefunden, wo wir immer und immer wieder über den eigenen Source Code iterieren, um diesen noch schöner zu machen. Soviel Spaß dies auch macht … ist das schönste Gefühl jedoch, wenn jemand meinen Source Code wirklich nutzt. Und das geht nur, wenn wir diesen auch deployen.
Oder etwas direkter gesagt: Dein Source Code ist solange nichts wert, bis dieser nicht in Produktion ist und vom Kunden genutzt werden kann. Klingt hart, ist aber Fakt.
Deswegen geht's in dieser Podcast Episode um das Thema Deployment.
Wir sprechen über Anti-Patterns wie manuelle Deployments, Big-Bang Deployments und Deployment Monolithen. Wir schauen uns an welche Herausforderungen wir bereits in unserer beruflichen Laufbahn bei Deployments gesehen haben, wie zB Caching, CDNs, Deployment unter Hochlast oder das Einspielen von Datenbankänderungen und geben mal eine Tour durch verschiedene Deployment-Arten, mit u.a. Canary Deployments, der Blue-Green-Stratgie, Feature Flags oder Shadow Deployments bzw. Dark Launches.
Final bringen wir die Frage auf den Tisch, wann du das letzte mal deinen Rollback getestet hast.
Bonus: Wie macht man eine Podcast-Episode über Deployment ohne Continuous Delivery und Continuous Deployment (CD) zu erwähnen?
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an [email protected].
(00:00:00) Intro
(00:01:04) Der Wert von automatisierten Deployments
(00:04:46) Werbung/Info
(00:05:46) Der Wert von automatisierten Deployments
(00:13:40) Datenbank-Deployments und Rollbacks
(00:19:04) Anti-Pattern: Komplizierter Deployment Prozess
(00:24:47) Anti-Pattern: Big-Bang-Deployment
(00:30:10) Ein schneller Feedback-Cycle
(00:32:45) Anti-Pattern: Deployment-Monolith
(00:42:28) Herausforderungen beim Deployment: Caching, CDN und Traffic
(00:52:24) Deployment-Strategien
(01:08:34) Metriken für deinen Deployment-Prozess
(01:13:18) Nicht jede Software braucht 5 Deployments pro Tag
Home Office vs. Return to Office: Der Machtkampf der Arbeitsweisen.
Home Office, Telearbeit, mobiles Arbeiten, Full Remote oder ab und zu auch Sofa-Zentrale, Küchen-Kontrollzentrum oder Pyjama-Büro. Obwohl diese Begriffe rechtlich und steuerlich teils eine andere Bedeutung haben, ist das Ergebnis das gleiche: Arbeiten von Zuhause bzw. nicht aus dem Büro deines Unternehmens.
Zur Corona Pandemie sind wir alle, freiwillig oder gezwungen, in den Genuss des Home Offices bekommen. Einige Unternehmen haben das Home Office als festen Bestandteil beibehalten. Andere haben Regeln für ein Hybrid-Modell eingeführt und wiederum andere springen auf den 5 Tage Return to Office Zug auf. Das Thema ist hoch subjektiv, denn jeder hat eine Meinung, welches Arbeitsmodell das beste ist.
Doch wie sehen denn eigentlich die Zahlen und Fakten zu diesem Thema aus? Jean-Victor Alipour, Dr. im Bereich Volkswirtschaft, hat mit den Forschungen zu diesem Thema bereits vor der Corona Pandemie begonnen. Mit ihm klären wir, wie das Ansehen von Home Office vor der Pandemie war, welche Verbreitung Home Office und Hybrides Arbeiten heute hat, Inwieweit die Produktivität steigt bzw. sinkt, ob es eine Return To Office-Bewegung gibt und ob bzw. wie sich die städtischen Ballungsgebiete im Hinblick auf Remote work ändern.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an [email protected].
(00:00:00) Home Office und Return to Office mit Dr. Jean-Victor Alipour
(00:04:04) Werbung/Info
(00:05:04) Home Office und Return to Office mit Dr. Jean-Victor Alipour
(00:15:41) Was ist eigentlich mit Home Office gemeint?
(00:19:38) Attraktivität und Vorurteile von Home Office vor Corona
(00:28:59) Längeres Arbeiten gleich höhere Produktivität im Home Office?
(00:41:33) Fully Remote vs. Hybrid-Arbeit
(00:51:29) Was sind gute und schlechte Home Office Konzepte?
(00:59:41) Gibt es einen Return to Office-Trend?
Welche Rolle spielt Softwareentwicklung im Datenjournalismus?
Datenjournalismus ist eine spezialisierte Form des Journalismus, die u.a. darauf abzielt (offene) Daten (und somit auch interessante Fakten) durch interaktive Visualisierungen und Diagramme zugänglich zu machen. Doch um ein konsumierbares Ergebnis zu erhalten, ist viel Arbeit notwendig. Was steckt also dahinter?
In dieser Episode sprechen wir mit Michael Kreil. Michael ist freier Datenjournalist und gibt uns Einblicke in seine Arbeit. Wir klären, was Datenjournalismus eigentlich ist, inwieweit das ganze in Relation zu Data Analytics oder Data Science steht, woher eigentlich die Arbeitsgrundlage, also die Daten, stammen, wie viel Software-Engineering in diesem Prozess involviert ist, welche handwerklichen Fehler bei der Arbeit mit Daten gemacht werden können, aber auch wie Datenjournalisten für Open Data und “Public Money, Public Code oder Public Data” kämpfen.
Bonus: Wenn Daten präsentiert werden, schalten Menschen ihren Kopf aus.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an [email protected].
(00:00:00) Datenjournalismus und Open Source Karten mit Michael Kreil
(00:04:04) Was hat dich dazu bewegt in den Journalismus zu gehen?
(00:05:53) Sponsor/Info
(00:06:53) Was ist Datenjournalismus?
(00:14:09) Wie verwandt ist der Datenjournalist mit Data Analytics und Data Science?
(00:19:00) Sind Datenjournalisten-Projekte "On-Off"-Projekte?
(00:20:36) Wo bekommen Datenjournalisten die Rohdaten her?
(00:30:52) Was müssen wir beim Umgang mit Daten bzw. Statistiken beachten?
(00:39:10) Korrelation ist nicht Kausalität
(00:47:56) Typische Fehler bei der Visualisierung von Daten
(00:57:47) Die Kunst, Elemente weg zu lassen
(01:00:21) Wie werde ich Datenjournalist?
Eine technische Vision für die technische Leitlinie.
Klare Regeln, eine klare Richtung, in die dein Team läuft, sind essentiell, um schnelle Entscheidungen ohne Streit zu treffen. Jedes Software-Team hat als Ziel, sich schnell zu bewegen, dynamisch und agil zu sein. Doch dafür sind ein paar Leitlinien notwendig und die Richtung muss für alle klar sein.
Doch wie macht man dies? Das Stichwort der Stunde heißt “technische Vision”. Wir klären was das für eine Vision ist, wo der Unterschied zur Produkt-Vision ist, warum diese Vision auf Team- oder auf Firmenebene gesetzt werden kann, wer diese setzen sollte, untermalen das ganze mit ein paar griffigen Beispielen, setzen verwandte Hilfsmittel wie das Techradar und ein Engineering Manifesto in Relation und geben euch eine kleine Anleitung wie man eine technische Vision erstellt.
Bonus: Wie Berater mit der Antwort “It depends” immer wieder punkten.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an [email protected].
(00:00:00) Streit auf LinkedIn
(00:03:08) Was ist eine technische Vision?
(00:04:16) Werbung/Info
(00:05:16) Was ist eine technische Vision?
(00:17:52) Product-Vision vs. technische Vision
(00:26:06) Wird Innovation durch eine technische Vision verhindert?
(00:31:05) Wie kommt man zu einer technischen Vision?
(00:38:01) Reichweite und Entscheidungsfindung einer technischen Vision
(00:45:18) Woher weiß ich, dass ich eine gute technische Vision habe?
(00:51:28) Das Problem mit dem Wort "technische Vision"
FeedbackSecurity Engineering und Hacking-Wettbewerbe “Capture the Flag”
Alles wird digital und für alles gibt es eine App. Bei einer solch rasanten Verbreitung, weckt dies Begehrlichkeiten bei böswilligen Hackern. Was ist also die passende Gegenwehr? Security Engineering! Doch was ist das eigentlich?
Wir sprechen mit Frederik Braun, Security Engineering Manager bei Mozilla und zuständig für den Firefox Browser. Er erklärt uns die Gemeinsamkeiten und Unterschiede von Security und Software-Engineering, wie sich der Bereich Security von einer Web-App und einem Browser unterscheidet, wie Security selbst bei Mozilla aussieht, wie Sicherheitslücken mittels Gamification und Capture The Flag Events gefunden und das suchen geübt werden kann und wie du in das Thema Security Engineering einsteigen kannst.
Bonus: Hackerpraktika an der Universität Bochum
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an [email protected].
(00:00:00) Intro
(00:00:56) Security Engineering mit Frederik Braun
(00:05:01) Frederiks Kontakt mit Security Engineering
(00:07:51) Werbung/Info
(00:08:51) Frederiks Kontakt mit Security Engineering
(00:18:16) Sub-Bereiche im Security Engineering und Software Entwicklung
(00:28:00) Softwareentwicklung eines Browsers zu anderen Softwarearten
(00:43:34) Was ist Capture the Flag, Bug Bounty und pwn2own?
(01:06:31) Der Einstieg in Security Engineering und Capture the Flag
Alternatives Arbeitsmodell: Job-Sharing mit Tandem
Die Welt wird immer komplexer. In diesem Kontext ist die Digitalisierung nicht immer förderlich. Die erhöhte Komplexität der Umgebung hat auch einen Effekt auf den eigenen Job und auf Leads und andere Führungskräfte. Firmen stehen immer wieder vor der Herausforderung, die richtige Person für eine Stelle zu finden.
Doch was wäre denn, wenn wir nicht eine Person für eine Stelle, sondern gleich zwei neue Mitarbeiter für eine offene Stelle suchen würden?
Bestimmt springen dir gerade ganz viele (negative) Gedanken durch den Kopf und du fragst dich “Hä? Wat?”.
Doch simplifiziert fasst dies das alternative Arbeitsmodell des Job-Tandems zusammen. Und genau darum geht es in dieser Episode. Wir sprechen mit Anna Drüing-Schlüter von der Firma Twise, die uns Einblick in diese Art von doppelter Führung gibt.
Bonus: Alles muss man vielleicht doch nicht allein machen.
**** Diese Episode wird von We Manage gesponsert.
Für Agenturen und kleinere Unternehmen ist es oft eine Herausforderung, ein vollständiges DevOps-Team aufzubauen. We Manage bietet DevOps und SRE as a Service an – passend für alle Projektgrößen. Ob als Unterstützung für bestehende Mitarbeiter⋅innen, damit diese in den Urlaub fahren können, oder als vollumfängliches Infrastruktur-Team mit optionaler 24/7-Bereitschaft. We Manage ist der ideale Partner für Digitalunternehmen, Startups und Agenturen, die auf der Suche nach finanziell vernünftiger und robuster Infrastruktur sind. Mehr Infos findest du unter https://engineeringkiosk.dev/wemanage
****
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an [email protected].
Links(00:00:00) Intro
(00:01:16) Job-Tandem mit Anna Drüing-Schlüter
(00:05:09) In Bezug auf Flexibilität und Karriere: Was hat sich in den letzten Jahren im Arbeitsmarkt geändert?
(00:06:07) DevOps & SRE as a Service (Werbung)
(00:07:35) In Bezug auf Flexibilität und Karriere: Was hat sich in den letzten Jahren im Arbeitsmarkt geändert?
(00:26:19) Entscheidungsfindung im Tandem
(00:33:58) Wie offen sind Firmen für dein Tandem-Modell?
(00:40:48) Doppelte Kosten im Job-Sharing?
(00:49:33) Verantwortlichkeiten im Tandem
(00:54:21) Erfahrung bei der Arbeit im Tandem
(01:00:25) Kommunikation nach Außen
(01:06:57) Wie starte ich mit dem Job-Sharing-Modell?
Eine (Schalt)-Sekunde kann für ganz schön viele Probleme sorgen
Alle 4 Jahre haben wir ein Schaltjahr, ein zusätzlicher Tag wird eingefügt. Was aber vielen nicht bekannt ist: Immer mal wieder gibt es auch eine Schaltsekunde. Auf einmal hat der Tag nicht 86.400 Sekunden sondern 86.401 Sekunden.
Und eine solch zusätzliche Sekunde kann, zumindest bei IT-Systemen, für eine ganze Menge Probleme sorgen. Und auch eine ganze Podcast-Episode füllen.
Wir sprechen über die Schaltsekunde und warum diese seit 1970 nur 27 mal eingefügt wurde.
Wir thematisieren die Probleme die eine zusätzliche Sekunde erzeugt,
Welche Lösungsmöglichkeiten es gibt, diese Probleme vorzubeugen, zB wie Windows damit umgeht, wann man eine monotonic Clock verwenden sollte, oder Warum Google und Amazon einzelne Sekunden in ihrem Zeit-Server verlangsamen und somit die Schaltsekunde “schmieren”.
Und wir sprechen über die Zukunft der Schaltsekunde, also ob wir diese noch brauchen oder nicht.
Es dreht sich also alles um Zeit bzw. um eine Sekunde.
Bonus: Du hast nur 27 Versuche, den Bug zu finden
**** Diese Episode wird gesponsert von easybill.
Suchst du nach einer neuen Herausforderung in einem spannenden, wachsenden Software-Team? Easybill kümmert sich um Rechnungserstellung für Freelancer und Händler auf Plattformen wie Ebay, Amazon oder Shopify und sucht Verstärkung im Bereich SRE sowie EntwicklerInnen für PHP, Ruby und etwas Rust. Arbeiten kannst du vollständig remote und mit modernen Technologien wie Kubernetes, Percona Cluster und mehr.
Klingt interessant? Schau doch mal unter https://easybill.de/jobs vorbei!
****
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an [email protected].
(00:00:00) Intro
(00:01:16) Was ist eine Schaltsekunde und wieso hat ein Tag 86400 Sekunden?
(00:03:54) Jobs mit Impact bei easybill (Werbung)
(00:05:55) Was ist eine Schaltsekunde und wieso hat ein Tag 86400 Sekunden?
(00:18:29) Welchen Einfluss hat eine zusätzliche Sekunde auf die IT?
(00:30:44) Probleme in der klassischen Software-Entwicklung
(00:33:26) Lösungen: Reboot, ignorieren und Smear-Second
(00:44:05) Die Zukunft der Schaltsekunde
Gesundheit ist das höchste Gut des Menschen (welches wir noch nicht kaufen können)
Als Tech- bzw. Knowledger-Worker*in arbeiten wir zwar alle an unterschiedlichen Projekten, Produkten und in anderen Kontexten, doch eins haben wir (leider) alle gemeinsam: Wir sitzen den Großteil des Tages recht statisch auf einem Stuhl vor einem Computer. Es ist zwar oft bequem, aber wie gut ist es für den eigenen Körper?
Und auch sonst: Der Alltag ist oft stressig. Eine Deadline jagt die nächste. Back to back Meetings stehen an und niemand hat bzw. nimmt sich die Zeit, sich mal was halbwegs gesundes zu kochen. Stattdessen: Schnell zum Imbiss nebenan.
Deswegen widmen wir uns mal diesem wichtigen, doch recht techniklosen Thema der eigenen Fitness und Gesundheit und sprechen über die Probleme beim dauerhaften Sitzen, die Folgen von Stress, die Bedeutung von Fitness und die die Extreme in Social Media. Und das ganze mit Patrick Cole, einem Personal Trainer.
Bonus: Es gibt Bandscheibenvorfälle im oberen Rücken.
Videos von Andy und Patrick findet ihr unter https://www.instagram.com/engineeringkiosk/
**** Diese Episode wird gesponsert von der IU Internationale Hochschule
Für dich ist Bildung wichtig und du glaubst an Technologie als Enabler? Kannst du dich mit der Mission der IU “Educate People with the Best Technology" identifizieren?
Dann schau doch mal unter https://engineeringkiosk.dev/iu, wenn du die Bildung von morgen gestalten willst.
****
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an [email protected].
(00:00:00) Fitness mit Patrick Cole
(00:04:46) Viele Knowledge-Worker haben die gleichen Probleme
(00:05:43) Die Bildung von morgen gestalten, als Dev bei der IU (Werbung)
(00:06:48) Viele Knowledge-Worker haben die gleichen Probleme
(00:13:11) Bandscheibenvorfall, Migräne, Stress und mentale Gesundheit
(00:18:38) Verantwortung von Arbeitnehmer und Arbeitgeber
(00:24:01) Welche "Körperschäden" sind korrigierbar und Arten des Muskelaufbaus
(00:30:30) Einfache Übungen zum Start für zuhause
(00:38:05) Ernährung: Zugang zum Essen, unter Stress essen und Kalorien zählen
(00:53:51) Der Effekt von Alkohol und Fitness erkennt man nicht anhand der Körperform
(00:58:37) Gadgets und Technik
(01:01:50) Einfach mal anfangen
Design Documents und Request for Comments (RFCs): Die Engineering Art der Planungsphase
Wir alle haben schon mal von einer Planungsphase gehört, um ein neues Projekt zu starten, und denken dabei an aufgeblasene Prozesse und lange Wasserfall-Diagramme. Und das Engineering-Team fragt sich oft: Wann kommen wir endlich mal zu den Details?
Da kommen die Begriffe Design Documents und Request for Comments (RFCs) ins Spiel.
Das doofe nur … Jemand muss diese Dokumente auch schreiben.
Und da sind wir bei gleich zwei von Andy's Lieblingsthemen: Schreiben und Design Docs.
Wir klären, wozu Design Documents eigentlich gut sind, worauf es ankommt, wo der Unterschied zu RFCs ist, ob das ganze nicht ein riesiger Wasserkopf ist, um einfach Dinge auf die Straße zu bringen und welche Kultur das ganze benötigt.
Viel Spaß.
Bonus: Wer schreibt, der bleibt.
Das schnelle Feedback zur Episode:
👍 (top) 👎 (geht so)
Feedback
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an [email protected].
(00:00:00) Intro
(00:01:15) Welche Relevanz haben Design Documents?
(00:07:25) Was ist ein Design Document?
(00:15:23) Wer schreibt das Design Document? Wie startet man?
(00:21:26) Mein Design hat Abhängigkeiten zu anderen Teams
(00:26:59) Design Document als zeitlicher Overhead
(00:31:56) Wie detailliert und lang soll ein Design Document sein?
(00:41:12) Request for Comments (RFCs) als ursprung für Design Documents
(00:50:10) Schreibtipps für dein erstes Design Document
(00:56:13) Box ticking exercise und Entscheidungs-Fatigue
The podcast currently has 146 episodes available.