
Sign up to save your podcasts
Or


Was haben Lexer, Parser und Counter-Strike gemeinsam? Richtig! Eine schöne Open Source Story.
Computerspiele sind für viele Software-Entwicklerinnen und -Entwickler der Einstieg. Andere wiederum steigen über den klassischen Bildungsweg eines Informatik-Studiums in die Softwareentwicklung ein. Dabei wird oft viel Theorie wie Lexer, Parser und Compilerbau durchgenommen. Doch was haben Computerspiele mit Lexer und Parser gemeinsam?
Andy erzählt eine Story, wie er vor Jahren sich mit Lexer und Parser anhand einer Counter-Strike-Konfigurationsdatei vertraut gemacht hat. Eigentlich nur, um eine datengetriebene Spielanalyse zu betreiben. Raus kam ein Lexer und Parser für das Valve Data Format (VDF).
Eine Geschichte voller Over-Engineering, Open Source, Spaß und einem Job-Angebot.
Bonus: Wie Wolfgang nur ans cheaten denkt, was autoexec mit Maustreibern zu tun hat und was Landmaschinen auf YouTube mit Rabbitholes zu tun haben.
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
(00:00:00) Intro
(00:00:42) Wolfgang und Computer-Spielen, LAN-Parties, 10 Mbit-Netzwerke und End-Terminator
(00:08:57) Der Hintergrund: Wie Andy zu Counter Strike kam und was das mit programmieren zu tun hat
(00:14:25) Counter Strike Game State Integration: Webhooks vom Spiel
(00:19:52) Valve Data Format (VDF), die Source Game Engine
(00:21:29) Daten-getriebene Spiel-Strategien und ein automatischer Installer für eine Webhook-Adresse
(00:25:28) Ein Lexer und Parser für das Valve Data Format (VDF)
(00:30:03) Was ist ein Lexer? Was ist ein Token?
(00:35:14) Was ist ein Parser?
(00:39:18) War es notwendig, einen Lexer und Parser zu schreiben? Und die Testphase des Installers
(00:41:47) Wird die Lexer- und Parser Library von jemandem verwendet? Und ein Job-Angebot
(00:46:31) Anwendungsfälle: Spiele-Analysen, Zimmerlicht auf Basis der Bombe ändern, Streaming-Overlays
(00:49:43) Eine schöne Open Source Story
(00:51:46) Outro
SQL Injections: Eine der weitverbreitetsten Sicherheitslücken im Web, auch im Jahr 2022
Der Großteil aller Applikationen interagiert in irgendeiner Art und Weise mit einer Datenbank. Deswegen werden die meisten Entwicklerinnen und Entwickler bereits von der Sicherheitslücke "SQL Injection" gehört haben. Seit 24 Jahren ist dies eine der weitverbreitetsten Sicherheitslücken im Internet und es ist kein Ende in Sicht. Was ist eigentlich eine SQL-Injection im Detail? Welche verschiedenen Arten gibt es? Was ist der Grund, dass uns dieses Einfallstor so lange beschäftigt? Woher kommt diese und wer hat sie entdeckt? Wie kann man sich schützen und seine Anwendung ausreichend testen? All das und noch viel mehr in dieser Episode.
Bonus: Der Kontrast zwischen Duisburg und Berlin und wie die SQL-Injektion als Nebenprodukt entdeckt wurde.
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
(00:00:00) Intro
(00:00:42) SQL-Injections aus den 90ern und die Vielfalt in Berlin
(00:02:49) Das heutige Thema: Web-Security SQL-Injections in der Tiefe
(00:05:07) Was sind SQL-Injections?
(00:08:48) Sind SQL-Injections auch im Jahr 2022 noch ein Problem?
(00:10:56) Wann gab es die erste SQL-Injection? Woher stammt diese Sicherheitslücke?
(00:13:22) Was sind die Gründe, dass SQL-Injections noch so ein großes Problem sind?
(00:19:37) Verschiedene Arten von SQL-Injections: Output-Based, Error-Based, Blind-SQL-Injections, Time-Based-SQL-Injections, Out-of-Band-SQL-Injections
(00:27:42) Bug Bounty: 2-Channel SQL Injection-Attacke in Kombination mit Cross-Site-Scripting (XSS) bei trivago
(00:29:42) Mehrstufige Attacken und Ausnutzung mehrerer Lücken nacheinander
(00:33:16) Möglicher Schaden durch eine SQL-Injection: Daten verändern, Befehle auf dem Server ausführen, lokale Dateien lesen und schreiben, SQL-Funktionen ausführen, Denial of Service (DoS)
(00:39:09) Gegenmaßnahmen um SQL-Injections zu verhindern: Prepared Statements, Datenbank-Komponenten updaten, limitierte Rechte für Datenbank-User, Web Application Firewalls (WAF)
(00:56:42) Möglichkeiten um deine Anwendung automatisch zu testen: Unit-Tests, statische Analyse, dynamische Analyse mit sqlmap und Fuzzing
(01:02:51) Maßnahmen um Sicherheit zu gewährleisten von Datenbank as a Service-Providern
(01:06:51) Outro
Was ist eigentlich ein Senior Engineer und wie werde ich zu einem?
In der Tech-Industrie werden Titel wie Junior-, Senior-, Staff- und Co genutzt, um Levels und Erfahrung auszudrücken. Doch was ist eigentlich ein Senior-Engineer? Was unterscheidet ein Senior von einem Junior? Wie kann sowas in der Praxis aussehen? Ist Zeit ein wirklicher Faktor für eine Beförderung (10 Jahre Berufserfahrung oder 10x 1 Jahr Berufserfahrung)? Ist "Senior" zu sein ein "Einmal-Aufwand" oder ist kontinuierliche Energie gefordert?
In dieser Episode beschreiben Andy und Wolfgang einige Attribute, die den Unterschied eines Juniors und Seniors darstellen und beschreiben, wie man den Weg zum Senior einschlagen kann.
Bonus: Warum ein Meterstab auch Zollstock genannt wird und warum Wolfgang ein T als hart bezeichnet.
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
(00:00:00) Intro
(00:00:58) Berufserfahrung, Breites vs. tiefes Wissen und Karriere
(00:06:23) Wie wichtig ist Karriere und Titel?
(00:08:03) Umgang mit Positions-Titeln in Firmen
(00:09:28) Heutiges Thema: Wie kann ich ein Senior Engineer werden?
(00:13:02) Erste Schritte zum Senior: Übernahme von kleinen Projekten - Die Arbeit pro-aktiv vorantreiben
(00:18:18) Impact: Was wird im Produkt wirklich gebraucht?
(00:19:34) Technische Skills: Entwicklung von Code und Testing
(00:22:34) Technische Skills: Debugging
(00:24:43) Technische Skills: Monitoring, Alerting und Skalierung
(00:26:13) Technische Skills: Security
(00:28:48) Kommunikations Skills: Feedback, positiv gestimmt, Mentoring und Knowledge Sharing
(00:35:15) Senior Engineer zu sein ist nicht einfach
(00:35:47) Technologie vs. Business-Verständnis: Wann ist eine Lösung gut genug?
(00:39:38) In die Senior-Rolle reinwachsen: Erfahrung und Zeit
(00:42:54) Unterschiedliches Verständnis von der Senior-Rolle
(00:45:07) Der eine Tipp auf dem Weg zum Senior Engineer
(00:47:32) Inflationäre Nutzung des Begriffs "Senior"
(00:48:37) Outro
Ein neues Format: Die gemischte Tüte mit Software Engineers, Git, GitHub, Open Source und Home-Office-Equipment
Eine Episode mit vier verschiedenen Themen, die uns als User-Fragen zugespielt wurden. Es geht um den Unterschied von einem Software Developer und Software Engineer, ob wirklich alles was wir auf GitHub finden als "Open Source" bezeichnet werden kann und benutzt werden darf, ob Git wirklich dezentral ist und wie wir das ganze eigentlich benutzen und wie die Home-Offices von Wolfgang und Andy eigentlich aussehen.
Bonus: Ob Lakritz was in einer gemischten Tüte zu suchen hat.
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
(00:00:00) Intro
(00:00:35) Das Format "die gemischte Tüte"
(00:02:42) Was ist der Unterschied von einem Software Developer und Software Engineer?
(00:08:04) Ist eigentlich alles, was auf Github ist, Open Source und darf ich dies einfach so verwenden?
(00:18:47) Ist Git wirklich dezentral und wir können weiterarbeiten, auch wenn GitHub down ist?
(00:31:14) Wie sieht unser Home-Office Setup aus?
(00:45:39) Outro
Wie würde heutzutage ein moderner Logging, Metriken, Monitoring, Alerting und Tracing-Stack aussehen?
Im Infrastruktur-Bereich gibt es zu jedem Bereich etliche Tools. Cloud-Native ist das Buzzword der Stunde. In dieser Episode erzählt Andy, wie er einen modernen Stack für ein Side-Projekt für die Bereiche Logging, Metriken, Monitoring, Alerting und Tracing aufsetzen würde. Unter anderem geht es dabei um Fragen wie: Was sollte man eigentlich alles loggen? Wie kann man von einem Alert angerufen werden? Wie visualisiert man Daten in schönen Graphen? Brauchen wir Tracing? Und was ist Observability?
Bonus: Engineering Porn und Buzzword-Bingo.
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
(00:00:00) Intro
(00:00:50) Wolfgangs MySQL-Buch
(00:02:11) Heutiges Thema: Wie würde Andy die Themen Monitoring, Alerting, Metriken und Logging bei einem Side Projekt angehen?
(00:04:49) Warum brauchst du Logging, Monitoring, Metriken und Tracing?
(00:07:29) Logging von Exceptions, Warnings und anderen Fehler, Logging und der ELK-Stack
(00:16:06) Was sollte man eigentlich alles loggen?
(00:19:22) Log-Rotation und Log-Retention auf Object-Storage
(00:27:30) Metriken mit Prometheus
(00:31:46) Visualisierung von Metriken mit Grafana
(00:34:25) Intelligente Alerting Systeme und die richtigen Schwellenwerte finden
(00:38:47) Alerts senden und anrufen lassen
(00:43:22) Tracing: Was ist das und brauchen wir das?
(00:48:49) Was ist Observability?
(00:51:42) Iterativer Aufbau seiner Plattform und Alternativen
(00:54:49) Keine bezahlte Werbung
(00:55:14) Outro und Feedback
Lohnt es sich ein IT-Fachbuch zu schreiben?
Es gibt zu jeder Software und zu jedem IT-Thema mindestens ein Buch. Doch wie ist es eigentlich, ein solches Buch zu schreiben? Was macht ein Verlag und braucht man diesen in der heutigen Zeit eigentlich noch? Wird man dadurch reich oder bleibt es Hungerlohn? Was für ein Tech-Stack steckt hinter einem Buch? Und wie würde man eigentlich starten? All das klären wir in dieser Episode mit Wolfgang, der ein Buch über MySQL im Rheinwerk-Verlag (Galileo Press) publiziert hat.
Bonus: Warum Wolfgang eher ein Fan vom Reden ist und warum er wirklich so lange für seinen Dr. Titel benötigt hat.
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
(00:00:00) Intro
(00:00:40) Schreib-Skills
(00:02:42) Thema: Das schreiben von IT Fachbüchern - MySQL, das umfassende Handbuch
(00:03:39) Wie gut kennst du dich im Bereich MySQL aus?
(00:05:19) Überblick über Wolfgangs MySQL Buch
(00:09:34) Wie lange habt ihr benötigt, das Buch zu schreiben?
(00:11:24) Welcher Tech-Stack wurde genutzt, um das Buch zu schreiben?
(00:13:43) Welche Aufgaben hat der Verlag übernommen?
(00:18:54) Wie hast du die Verbindung zum Verlag aufgebaut?
(00:21:17) Was verdient man mit einem IT Fachbuch?
(00:28:21) Warum hast du ein Buch geschrieben? Was bringt es ein Buch zu schreiben?
(00:30:27) Was hat sich durch das Buch bei dir professionell ergeben?
(00:32:22) Wieso habt ihr das Schreiben einer neuen Edition abgelehnt?
(00:33:56) Imposter-Syndrom: Wie viel weißt du über das MySQL Datenbank-Thema, nach deiner Recherche?
(00:35:52) Wie viele Amazon-Reviews hast du gekauft?
(00:38:39) Liest du IT-Fachbücher?
(00:43:24) Würdest du nochmal ein Buch schreiben?
(00:46:32) Würdest du Leuten empfehlen, ein Buch zu schreiben?
(00:51:00) Was würdest du Leuten empfehlen, die ein Buch schreiben möchten?
(00:53:25) Würdest du nochmal ein Buch über eine Software/Software-Version schreiben?
(00:55:50) Hattest du schon Berührungen zu einem Ghostwriter?
(00:58:46) Lohnt sich das Mittel- und Langfristig ein Buch zu schreiben?
(01:01:22) Selbst-Publishing und Print on Demand
(01:03:56) Audio-Rants, Reddit und Outro
Gehälter als Software-Engineer: Wie sind diese aufgebaut?
IT-Gehälter sind so hoch wie noch nie. Doch sind 6-Stellige Gehälter gerechtfertigt, fair und bekommen die Mitarbeiter wirklich diesen Betrag jährlich überwiesen? Um diese Frage und ähnliche Themen geht es in dieser Episode: Welche Gehaltsbausteine gibt es? Lohnt es sich bei US-Gehältern überhaupt noch in Deutschland zu bleiben? Gibt es eine große Imbalance zu anderen Industrien? Sind die Gehälter überhaupt gerechtfertigt und was machen zB kleine Agenturen, wenn diese mit der Entwicklung in der Industrie nicht mithalten können?
Bonus: Wolfgang der Cloud-Hater, ob Deutschland Single-Feindlich ist und was der VW Golf und das Marketing der Cloud damit zu tun haben.
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
(00:00:00) Intro
(00:00:40) Feedback-Cycle beim Podcasting und Feedback zu "#34 Wie cloudy bist du?"
(00:04:51) Format-Idee "Gemischte Tüte"
(00:07:09) Heutiges Thema: Gehalt, Gehaltsbausteine, hohe Gehälter in der Tech-Industrie
(00:08:51) Total Compensation: Vier Gehaltsbausteine - Basis-Gehalt, Signing-Bonus, Equity und jährliche Bonuszahlungen
(00:21:15) Ist Weihnachts- und Urlaubsgeld als Bonuszahlung zu sehen?
(00:22:35) Lohnt es sich langfristig als Entwickler noch in Deutschland zu bleiben, wenn man Gehälter von 300.000€ in anderen Ländern sieht?
(00:27:43) Imbalance von Gehältern zu anderen Industrien, der Impact deiner Arbeit und Gehälter von Web-Agenturen vs. Software as a Service-Firmen
(00:36:14) Agenturen als Talent-Pool für große Tech-Firmen
(00:43:46) Ältere (50+) Entwickler in Agenturen, Möglichkeiten für neue Jobs und die eigene Lerngeschwindigkeit
(00:50:07) Ein Fail für die Formatidee "Gemischte Tüte" und sind hohe steigende Gehälter überhaupt noch fair?
(00:52:40) Outro und Gemischte Tüte: Was ist der Unterschied von einem Softwareentwickler und Software-Engineer?
Der Dauerbrenner in jedem Team: Wie bekommt man ordentliches Knowledge Sharing hin?
Jeder kennt's: Die Kollegin ist im Urlaub und genau in dieser Zeit läuft was mit der einen Komponente schief, wo sie das größte Wissen darüber hat. Knowledge Sharing richtig hinzubekommen und das Wissen breit zu verteilen ist eine Mammutaufgabe. Aber eine wichtige, speziell in einer Remote-Umgebung.
In dieser Episode gehen wir einige Mythen und Techniken durch, die euch beim Knowledge Sharing unterstützen können: Was ist der Bus-Faktor? Muss jeder im Team alles wissen und übernehmen können? Wobei kann Mob-Programming helfen? Was sind Guilds? Und kann man eigentlich zu viel lernen? Und noch viele weitere Themen.
Bonus: Warum das C-Level-Management nicht im selben Flugzeug fliegen darf und ob Podcasts, die Mitarbeiter-Zeitung ablösen.
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
(00:00:00) Intro
(00:00:45) eBay Kleinanzeigen und Landing-Pages für Auto-Reifen
(00:08:20) Das Thema der Episode: Knowledge Sharing
(00:11:11) Der Bus-Faktor
(00:13:01) Warum Knowledge Sharing wichtig für die Kollaboration und Produktivität ist
(00:15:05) Mythos "Jeder im Team muss alles Wissen und übernehmen können"
(00:18:05) Möglichkeiten zur internen Dokumentation: Design Documents / Request For Comments / Discover Documents / Architecture Decision Records und Zielgruppe der Dokumentation
(00:24:43) Pair- und Mob-Programming
(00:28:32) Guilds (Community of Practice), Support vom Management und Kosten von Knowledge Sharing
(00:39:38) Interne Konferenzen, Vorträge halten und das Imposter-Syndrom
(00:49:37) Lunch-Talks
(00:52:21) Welcher Lerntyp bist du? - Viel lesen, Hands-On, Frontal-Lehre, Video-Tutorials, Audio - Das richtige Format
(00:57:28) Kann man zu viel lernen?
(00:59:09) Ist Knowledge-Sharing schwieriger in einem Remote-Umfeld?
(01:02:21) Outro
Die Cloud Native Infrastruktur vs. ein dicker Server - Ein Dauerstreit-Thema
AWS, GCP, Azure und Co bieten viele Cloud Native Services, die dir dein Leben vereinfachen sollen. Serverless, weniger Admins und alles super günstig. Das sind die Versprechen. Doch ist das wirklich so? Wäre ein leistungsstarker Server nicht besser, günstiger, einfacher und ausreichend? Und wie steht das nicht im Konflikt mit einer modernen Microservice-Architektur?
All diese Fragen stellen Wolfgang und Andy in dieser Episode, wo sie einen Artikel "Use One Big Server" besprechen.
Bonus: Was eine Klatsche auf Reddit, Vendor-Lock-in und CV-Driven-Development mit Servern zu tun hat.
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
(00:00:00) Intro
(00:00:43) Intro mit einer Klatsche auf Reddit
(00:03:49) Wir brauchen euren Support: Bewertet uns in eurer Podcast-App
(00:04:26) Warum läuft F-Online auf einem großen Server und nicht Cloud Native und Serverless?
(00:10:43) Saisonaler Traffic, Peak-Usage und Ressourcen richtig ausnutzen bei einem virtuellen Server vs. Cloud Native
(00:17:05) Ist der Vergleich von Monetären Kosten allein sinnvoll? Wie bezieht man die Implementierung mit ein?
(00:18:33) Debugging und Testing von GCP Cloud Functions/AWS Lambdas
(00:21:14) Ein großer Server ist für viele Applikationen die bessere Wahl und das Abhängigkeitsverhältnis zu Cloud Providern
(00:26:14) Fehlende Perspektiven bei dem Artikel "Use One Big Server" und Argumente für Cloud Native
(00:31:06) Optimierung von Cloud Kosten, Vendor-Lock-in, Multi-Cloud und Monolith vs. Microservice
(00:34:20) Ist der LAMP-Stack bereits eine Micro-Service-Architektur?
(00:37:34) Ist ein Micro-Service automatisch eine eigene Applikation? Ist der Micro-Service-Hype vorbei?
(00:40:34) "Boring"-Software kann ein Vorteil sein
(00:43:30) Zusammenfassung und Outro
Wie können Engineering Manager und Tech-Lead-Interviews aussehen?
Jeder, der vom Individual Contributor in eine Engineering Manager und Tech-Lead-Rolle wechseln möchte, muss sich Fragen aussetzen, die nichts mit Code zu tun haben. Fragen über Leadership Styles, Motivationen, Team-Entscheidungen, Business-Prioritäten, Selbst-Reflektion und Schwächen. Denn als Engineering Manager oder Tech-Lead gilt man als Multiplikator. In dieser Episode stellt Wolfgang seinem Co-Host Andy einfach mal die Fragen, die er damals Bewerbern gestellt hat, um sich selbst als Engineering Manager bei trivago zu ersetzen. Dies gibt einen guten Einblick, mit welchen Fragen Ihr so rechnen könnte, falls Ihr euch in eine ähnliche Situation begebt.
Bonus: Warum Wikingerschach der neue Sport ist und was eine Straßenampel mit Continuous Integration zu tun hat.
Feedback (gerne auch als Voice Message)
Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
(00:00:00) Intro
(00:00:33) AI-Generiertes Episoden-Cover mit DALL-E 2
(00:07:09) Das heutige Thema: Leadership styles, eine Art Engineering Manager Interview und Wikingerschach (Kubb)
(00:11:03) Kontext zu dem Interview, dem Team und den Interviewfragen
(00:14:46) "Warum möchtest du überhaupt eine Lead-Rolle übernehmen?"
(00:19:10) "Was wären deine ersten drei Aktionen als neuer Engineering Manager?"
(00:22:29) "Was ist dein Leadership-Style?"
(00:27:39) "Wo ziehst du denn aus dem Alltag als Engineering Manager die Energie raus?"
(00:29:14) "Wie verteilst du Projekte an Mitarbeiter, die keiner machen möchte?"
(00:38:20) "Wie würdest du die Innovation / Innovations-Bereitschaft in deinem Team erhöhen?"
(00:45:14) "Hast du eine Herangehensweise, wie man mit anderen (hartnäckigen) Meinungen umgeht bzw. eine Pattsituation auflöst?"
(00:53:31) "Warum sollte ich dich nicht anstellen?"
(00:56:02) Interview-Abschluss und Retrospektive Betrachtung der Fragen
(00:59:40) Outro und Feedback
From the publisher's feed
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…