Devcartes

Distro Hopping

Tristan — Wed, 14 Oct 2026 00:00:00 +0000

Was ist Distro Hopping

Distro Hopping nennt man das ständige Wechseln der Linux-Distribution, meist in kurzer Zeit.

Warum ist es so interessant

Distro Hopping ist ein Phänomen der Linux-Szene, das ich nicht wissenschaftlich untersucht habe, allerdings kann ich aus eigener Erfahrung sprechen und von den Berichten von Freunden und Bekannten erzählen.

In Gesprächen mit besagten Freunden und Bekannten waren wir uns über die Gründe fürs Distro Hopping ziemlich schnell einig:

Spannung: Etwas Neues und Unbekanntes auszuprobieren.
Basteln: Den eigenen PC modifizieren, um zu schauen, was man mit einer anderen womöglich schlankeren¹ Distribution noch heraus holen kann.
Diversität: Die volle Vielfalt, die einem das Linux-Universum bietet, erleben.
Neustart: Mit einem sauberen System starten, quasi eine Art radikaler Frühjahrsputz.

Was sollte man beachten

Grundsätzlich ist es nicht schlimm, ein Distro Hopper zu sein, in Foren sind einige Nutzer sogar stolz darauf. Wenn man allerdings mit seinem PC arbeitet und darauf angewiesen ist, dass dieser immer stabil läuft und alles installiert ist, was man zum Arbeiten braucht, sollte man das Distro Hopping zumindest auf eine zweite Festplatte beschränken.

Wenn man regelmäßige Backups macht und wichtige Daten ausschließlich auf Servern und Repositories speichert, fällt der Wechsel umso leichter.

Wenn man eine Distro nur mal kurz ausprobieren möchte, bietet sich beispielsweise ein Live-USB-Stick an.

Schlussworte

Auch ich bin lange Zeit von Distro zu Distro gesprungen (SuSE Linux, Ubuntu, Debian, Fedora, Arch, MX Linux uvm.) und manchmal auch wieder zurück. Mit den Jahren waren es mit Sicherheit über 50 an der Zahl, bis ich mich vor 3 Jahren auf Arch eingeschossen habe.

Seither bleibt meine "Haupt"-Platte unangetastet und nur die zweite SSD wird für neue Distros hin und wieder genutzt. Distro-Hopping light sozusagen.

Aktuell habe ich auf meiner zweiten Platte übrigens MX Linux installiert.

Zum Beispiel Damn Small Linux, AntiX oder Void

Godot jenseits von Spielen: Intro

Tristan — Thu, 01 Oct 2026 00:00:00 +0000

Einleitung

Eine Game Engine nutzen, um eine Desktop Anwendung zu schreiben?

Klingt auf den ersten Blick abwegig, aber gerade Godot eignet sich aus mehreren Gründen extrem gut dafür.

Warum Godot

Dass man ausgereifte und komplexere Desktopanwendungen mit Godot bauen kann, zeigt der Editor für die Godot Engine, der nämlich ebenfalls in Godot geschrieben ist. Außerdem hat Godot eine sehr gute Crossplattform-Unterstützung, was man auch daran sieht, dass der Editor sowohl im Browser, als auch für mobile Endgeräte zur Verfügung steht. Gerade auch die geringe Größe der ausführbaren Dateien macht Godot zu einer interessanten Engine für mobile Geräte und das Web. Auch GUIs lassen sich mit dem Editor oder dynamisch aus dem Code sehr einfach bauen und zwar ohne großen Aufwand responsive. Das ist bei anderen etablierten Desktop-GUI-Frameworks (z.B. Delphi oder .NET) nicht immer so einfach. Wer Bedenken wegen der Ressourcennutzung hat, für den hat Godot einen Low Processor Mode, der dafür sorgt, dass das Bild seltener und nur bei Bedarf erneuert wird.

Proof of Concept

Ich schreibe aktuell eine kleine Desktopanwendung mit Godot, die in erster Linie als Proof of Concept (PoC) gedacht war, sich mittlerweile aber als sehr nützlich für mein Studium erwiesen hat.

KOReader, eine beliebte eBook-Lese-App, speichert Lesestatistiken, Notizen und Highlights in einem bestimmten Format, die ich exportieren, aufbereiten und später zum Nachschlagen nutzen möchte.

Beispiel-Export

Am Ende soll eine Datei herauskommen, die in etwa so aussieht, wie der beispielhafte Ausschnitt aus dem Buch What is it like to be a bat von Thomas Nagel. Um den Text soll es an dieser Stelle aber überhaupt nicht gehen, es sind auch keine echten Highlights oder Notizen, sondern nur Beispiele.

Title: What Is It Like to Be a Bat? / Wie ist es, eine Fledermaus zu sein?

Author: Thomas Nagel

===========================================================================

Page 7 (yellow)
Das Thema ›Bewusstsein‹ macht das Leib-Seele-Problem praktisch unlösbar.

===========================================================================

Page 8 (yellow)
Es ist höchst unwahrscheinlich, dass irgendeines dieser mit dem Leib-Seele-Problem nicht verwandten Beispiele erfolgreicher Reduktion die Beziehung zwischen Psyche und Gehirn erhellen wird.

===========================================================================

Page 47 (yellow)
But no matter how the form may vary, the fact that an organism has conscious experience at all means, basically, that there is something it is like to be that organism.

===========================================================================

Page 53 (yellow)
Yet if I try to imagine this, I am restricted to the resources of my own mind, and those resources are inadequate to the task.

===========================================================================

Page 55 (purple)
Our own experience provides the basic material for our imagination, whose range is therefore limited. It will not help to try to imagine

---------------------------------------------------------------------------
Note:
Das ist eine Notiz von mir an mich
---------------------------------------------------------------------------

===========================================================================

Erklärung zum Export

Ich färbe meine Highlights und Notizen immer mit bestimmten Farben, die alle ihre eigene Bedeutung haben, um sie später einfacher zuordnen zu können.

So kann ich ohne großen Aufwand und mit minimaler Unterbrechung Notizen beim Lesen machen und habe diese später in einer einfachen und sortierten Form vorliegen, die ich entweder ausdrucken oder digital weiterverwenden kann. Durch die Seitenzahlen finde ich die Textstellen schnell wieder.

Zum Ende

In diesem Artikel bin ich auf das Was und Warum eingegangen. In den folgenden Artikeln werde ich auf das Wie eingehen und Wo Godot nicht die passende Wahl ist.

Migration von Hugo zu Zola

Tristan — Sun, 27 Sep 2026 00:00:00 +0000

Was passiert hier

Ich habe mich nach langer Überlegung dazu entschlossen meine Website von Hugo zu Zola umzuziehen.

Du fragst dich nun vielleicht, "Wer ist Hugo und was hat diese Zola mit ihm zu schaffen?" und, wenn du meinen Blog schon eine Weile verfolgst, wirst du dich vielleicht ebenfalls fragen, "Wo sind all die Artikel hin".

Auf diese Fragen möchte ich in diesem Artikel kurz eingehen.

Hugo und Zola

Static Site Generators (SSG)

Static Site Generators sind Programme, die aus Textdateien, oft Markdown, eine statische Webseite generieren.

Statische Seiten haben Vorteile gegenüber dynamischen bzw. server-seitig gebauten Seiten:

Laden extrem schnell
Sind sehr sicher (keine DB Zugriffe, kein JavaScript)
Einfach neuen Content zu schreiben und zu veröffentlichen
Kein spezieller Server zum Hosten benötigt

Hugo


Sprache	Go
Setup	Ausführbare Binärdatei
Konfiguration	YAML, TOML, JSON
Template Engine	Go Template
Community	Groß
Komplexität	Hoch
Lernkurve	Steil
Dokumentation	Sehr gut

Zola


Sprache	Rust
Setup	Ausführbare Binärdatei
Konfiguration	TOML
Template Engine	Tera
Community	Klein
Komplexität	Niedrig
Lernkurve	Flach
Dokumentation	Sehr gut

Warum das ganze

Ich finde Hugo nicht schlecht, im Gegenteil, es gab und gibt gute Gründe, warum ich mich ursprünglich dafür entschieden habe. Deshalb möchte ich hier auch keinen wertenden Vergleich anstellen, sondern nur die wenigen Punkte hervorheben, die mich veranlasst haben zu wechseln.

Was sind denn nun die Gründe für meinen Umzug?

Schlankere Themes: Die Zola Themes bestehen aus deutlich weniger Dateien und sind somit leichter anpassbar.
Tera: Ist eine mächtige, einfach zu erlernende Template Engine, die ich aus einem anderen Projekt bereits kenne.
Schlichtheit: Zola hat weniger Umfang, aber es macht genau das, was es soll und das mag ich an Werkzeugen.

Wann ist es fertig

Technischer Stand

Technisch ist die Seite bereits umgezogen, wenn du diesen Artikel hier liest. Meine CI/CD Pipeline für die Seite funktioniert und auch sonst bin ich mit dem Aufbau zufrieden.

Die Artikel

Wie bereits angesprochen, sind meine Artikel aktuell nicht sichtbar.

Das liegt erstens daran, dass ich die sogenannten "Frontmatter" anpassen muss, da diese nur bedingt kompatibel sind zwischen Hugo und Zola.
Zweitens habe ich mir bei der Umstellung alle Artikel nochmal durchgelesen und bin mit der Qualität nicht zufrieden.

Das bedeutet konkret, dass die Artikel nach und nach wieder online kommen werden. Alles in allem wird der Prozess vermutlich 1-2 Monate dauern.

Abschlussworte

Ich hoffe du schaust auch während der Umbauphase regelmäßig vorbei, es könnte sich lohnen, denn während ich die bestehenden Artikel einer Generalüberholung unterziehe, kommen auch neue Artikel dazu.

Guard Clauses

Tristan — Sun, 23 Aug 2026 00:00:00 +0100

Einleitung

Softwareentwickler aller Erfahrungsstufen, weltweit kennen das Problem:
Man schaut sich Code von Kollegen oder eigenen, älteren Code an und hat keine Ahnung, was dieser eigentlich macht. Er ist so tief verschachtelt und nimmt so viele Abzweigungen, dass man überhaupt nicht mehr weiß, welches Kriterium nun zum Abbruch der Funktion geführt hat oder welchen Wert eine Variable zu Zeitpunkt des Ausstiegs hat.

Viel schöner wäre es doch, wenn man seine Funktion lesen könnte wie ein Buch, von oben nach unten, und dabei auf einen Blick erkennen kann, an welcher Stelle die Funktion vorzeitig verlassen wird und warum.

Eines der Werkzeuge, auch Patterns genannt, in der Softwareentwicklung, das genau diesem Zweck dient, nennt man Guard Clauses.

Sie machen deinen Code sowohl lesbarer und wartbarer als auch robuster.

Was sind Guard Clauses

Guard Clauses (ins Deutsche frei übersetzt Schutzklausel), sind ein Pattern, bei dem man frühzeitig aus einer Funktion aussteigt, wenn eine bestimmte Bedingung eintritt, die die weitere Abarbeitung des Codes unnötig macht.

Das Prinzip ist, dass man Ausnahmen zuerst behandelt und dann den eigentlichen Programmfluss.

Entscheide selbst, welchen der beiden folgenden Codeabschnitte du lesbarer findest:

if user.is_logged_in {
    if user.has_permission {
        if user.name == "Max" {
            // logik kommt hier
        }
    }
}

if !user.is_logged_in { return; }
if !user.has_permission { return; }
if user.name != "Max" { return; }
//logik kommt hier

Wichtig! Die Bedingungen der Guard Clauses sind logisch negiert, da wir prüfen, wann wir nicht weitermachen dürfen.

Wann solltest du Guard Clauses nutzen

Wenn dein Code zu tief verschachtelt ist
Bei Vorbedingungen (Preconditions), die den Rest der Funktion hinfällig machen (z.B. Null-Checks)
Wenn die Ausnahmen klar vom Normalfall abgegrenzt werden können
Wenn du Code von oben nach unten lesen willst, wie ein Buch

Wann solltest du Guard Clauses nicht nutzen

Wenn es nicht den einen Normalfall gibt, sondern mehrere gleichwertige Zweige
- z.B. wenn je nach User-Rolle unterschiedliche Logik ausgeführt werden soll (Zweige sind gleichwertig)
Wenn es viele Vorbedingungen (mehr als 5 - 6) gibt, dann lohnt es sich in eine eigene Validierungsfunktion auszulagern

Best Practices

Guard Clauses am Anfang der Funktion bündeln
Eine Bedingung pro Guard Clause
Aussagekräftige Fehler zurückgeben oder sauberes Logging statt stiller returns
Guards nicht schachteln
Reihenfolge nach Wahrscheinlichkeit, statistisch häufige Fehler zuerst prüfen
Trotzdem das Single Responsibility Principle einhalten
In Teams das Pattern klar als Standard definieren, das spart Zeit und Diskussionen im Code Review

Schluss

Du siehst also, Guard Clauses sind ein sehr einfaches und nützliches Pattern, um deinen Code zu verbessern. Sie reduzieren Verschachtelung und erhöhen somit die Lesbarkeit.

Doch trotz der Einfachheit nutzen nicht alle erfahrenen Entwickler sie.

Was denkst du, woran liegt das?
Liegt es vielleicht daran, dass viele Entwickler mit if-else-Verschachtelungen groß geworden sind und Guard Clauses sich fremd anfühlen?

Empfehlungen: Exercism

Tristan — Thu, 04 Jun 2026 00:00:00 +0100

Quick Facts:

Anbieter: Exercism.org (gemeinnützig, Open Source)
Gründung: 2013
Sprachen: Über 70 Programmiersprachen – z.B. Python, Go, Rust, C# uvm.
Formate: Browser-basierte Aufgaben + Kommandozeilen-Tool
Besonderheit: 1:1 Mentoring durch erfahrene Entwickler:innen
Preis: komplett kostenlos
Link: exercism.org

Worum geht es?

Auf Exercism lernst du Programmieren durch praktische Übungen und wertvolles Feedback von erfahrenen Mentoren. Hier gibt es keine Videokurse oder Tutorials im eigentlichen Sinn, was aus meiner Sicht ein absoluter Vorteil ist und für die Plattform spricht.

Für wen ist die Plattform?

Ideal für:

Einsteiger, die nach den Grundlagen einer Sprache üben wollen
Fortgeschrittene, die eine neue Sprache schnell und idiomatisch lernen möchten
Autodidakten, die konstruktives Feedback vermissen

Du solltest mitbringen:

Grundlegendes Verständnis von Variablen, Schleifen, Funktionen (je nach Track unterschiedlich)
Motivation, Probleme selbstständig zu lösen
Englischkenntnisse (alle Aufgaben und Diskussionen sind auf Englisch)

Eher nicht geeignet, wenn:

Du einen klassischen Videokurs mit Dozent suchst
Du ein großes Projekt bauen willst (Exercism fokussiert kleine, isolierte Übungen)
Du keinen englischen Text lesen magst

Wie funktioniert es?

Exercism ist in sogenannte Tracks aufgeteilt, einen Track pro Programmiersprache. Jeder Track enthält Dutzende bis hunderte Übungen, sortiert nach Schwierigkeit.

Der typische Workflow:

Track auswählen: z. B. Go, Python oder Rust.
Erste Übung: meistens "Hello World", um die Umgebung zu testen.
Aufgabe herunterladen: entweder im Browser-Editor oder per CLI.
Code schreiben: bis alle Tests bestehen.
Lösung einreichen: optional mit einer Frage an den Mentor.
Feedback erhalten: meist innerhalb weniger Stunden bis zwei Tage.
Überarbeitung: basierend auf dem Feedback die Lösung verbessern.
Nächste Übung: der Track schaltet nach und nach neue Aufgaben frei.

Zusätzlich gibt es "Practice"-Übungen und "Concept"-Übungen (die ein bestimmtes Sprachfeature erklären, z. B. Slices in Go oder Pattern Matching in Rust).

Was lernst du?

Neben der Syntax einer Sprache, lernst du hier auch wie man idiomatischen Code schreibt. Hierbei helfen vor allem die sehr geduldigen und erfahrenen Mentoren.

Warum lohnt sich Exercism?

Sowohl Anfänger, als auch Profis können hier viel lernen und sich mit anderen austauschen. Jeder in seiner jeweiligen Geschwindigkeit und bis zu der Tiefe, die für ihn angenehm ist.

Bonus: Alles Open Source. Du kannst sogar eigene Übungen beitragen oder Fehler in den Aufgaben korrigieren.

Wie startest du am besten?

Meine Empfehlung für einen schnellen Einstieg:

Wähle eine Sprache, die du schon ein bisschen kennst – nicht die erste, die du lernen willst, sonst kämpfst du mit Syntax und dem Workflow.
Installiere das CLI-Tool (exercism auf der Kommandozeile). Das Browser-Interface ist okay, aber mit lokalem Editor (VS Code etc.) und echten Tests macht es mehr Spaß.
Setze dir ein wöchentliches Ziel: Zwei bis drei Übungen pro Woche sind realistisch, wenn du nebenbei arbeitest oder studierst.
Nutze das Mentoring aktiv – stelle deine Fragen so konkret es geht, denn je genauer deine Frage, umso besser das Feedback.
Schau dir nach dem eigenen Lösen die Community-Lösungen an – nachdem du deine Lösung eingereicht hast, werden dir oft andere Ansätze gezeigt. Fremden Code zu lesen und zu verstehen ist auch eine wichtige Fähigkeit für einen Entwickler.

Persönliches Highlight

Mein persönliches Highlight war der Rust-Track, hier sind vor allem die Mentoren, die ich bisher erlebt habe sehr ausführlich, geduldig und erfahren. Außerdem ist der Track sehr ausgereift.

Zum Schluss

Exercism ist eine echte Perle unter den Lernplattformen und meiner Meinung nach viel zu unbekannt.

Wenn dir die Seite also gefällt, dann lass den Entwicklern doch eine kleine Spende da oder hilf mit, indem du Dokumentation schreibst, Aufgaben verbesserst oder sogar neue einreichst. Oder empfehle sie einfach nur weiter.

Bist ein echter Profi in einer Sprache, dann könntest du auch als Mentor mithelfen.

Besucht auch gerne mein Exercism Profil und schaut euch meine Lösungen, Testimonials oder Contributions an.

Rusty Bytes: Traits und mehr

Tristan — Wed, 11 Mar 2026 00:00:00 +0100

Was sind Traits?

Traits sind Rusts Version von Interfaces. Ein Trait definiert eine Schnittstelle, eine Menge von Methoden, die ein Typ implementieren muss, außer es gibt eine Standardimplementierung. Wer schon mit Interfaces aus C#, Java oder Kotlin gearbeitet hat, kennt das Konzept.

trait Greet {
    fn hello(&self) -> String;
}

struct German;
struct English;

impl Greet for German {
    fn hello(&self) -> String {
        String::from("Hallo!")
    }
}

impl Greet for English {
    fn hello(&self) -> String {
        String::from("Hello!")
    }
}

Traits können auch eine Standardimplementierung mitbringen, die ein Typ überschreiben kann aber nicht muss:

trait Greet {
    fn hello(&self) -> String {
        String::from("Hi!")
    }
}

So weit, so bekannt.

Interessant wird es, wenn man Traits als Parameter verwendet, denn da beginnt die eigentliche Frage: Was passiert dann zur Compile-Zeit und welche Auswirkungen hat es auf die Laufzeit?

Monomorphisierung – Polymorphismus zur Compile-Zeit

Wenn eine Funktion einen generischen Typ mit Trait-Bound erwartet, erzeugt der Rust-Compiler für jeden konkreten Typ, mit dem die Funktion aufgerufen wird, eine eigene spezialisierte Version. Das nennt sich Monomorphisierung.

fn greet<T: Greet>(g: &T) {
    println!("{}", g.hello());
}

Der Compiler sieht, dass greet mit German und English aufgerufen wird, und erzeugt intern je eine Funktion für Englisch und eine für Deutsch:

fn greet_german(g: &German) { println!("{}", g.hello()); }
fn greet_english(g: &English) { println!("{}", g.hello()); }

Das ist gleichbedeutend mit dem impl Trait-Syntax, der etwas lesbarer ist:

fn greet(g: &impl Greet) {
    println!("{}", g.hello());
}

Vorteil:
Zur Laufzeit gibt es keinen Overhead. Der Compiler kennt den konkreten Typ, kann ihn inline optimieren und direkt den richtigen Funktionsaufruf einsetzen.

Nachteil:
Die Binärgröße wächst, denn für jeden Typ, mit dem die Funktion genutzt wird, landet eine eigene Kopie im kompilierten Code.

Dynamic Dispatch – Polymorphismus zur Laufzeit

Manchmal ist der konkrete Typ erst zur Laufzeit bekannt, so zum Beispiel wenn verschiedene Typen in einer Liste gesammelt werden sollen.

Hier kommt dyn Trait ins Spiel.

fn greet(g: &dyn Greet) {
    println!("{}", g.hello());
}

Statt einer spezialisierten Funktion pro Typ erzeugt der Compiler ein Trait Object. Das ist ein sogenannter Fat Pointer, der aus zwei Teilen besteht, einem Zeiger auf die Daten und einem Zeiger auf eine vtable.

Die vtable wiederum ist eine Tabelle mit Funktionszeigern für alle Methoden des Traits, wo zur Laufzeit die richtige Implementierung nachgeschlagen und aufgerufen wird.

let greeters: Vec<Box<dyn Greet>> = vec![
    Box::new(German),
    Box::new(English),
];

for g in &greeters {
    println!("{}", g.hello());
}

Das wäre mit Monomorphisierung nicht möglich, da der Compiler den Typ jedes Eintrags zur Compile-Zeit kennen müsste.

Vorteil:
Flexibel, kleinere Binärgröße, heterogene Collections möglich.

Nachteil:
Laufzeit-Overhead durch den vtable-Lookup, keine Inlining-Optimierungen möglich.

Wann was?

	`impl Trait` / Generics	`dyn Trait`
Auflösung	Compile-Zeit	Laufzeit
Performance	Höher	Etwas geringer
Binärgröße	Wächst pro Typ	Konstant
Heterogene Collections	✗	✓
Typinformation	Vollständig bekannt	Zur Compile-Zeit nicht bekannt

Als Faustregel gilt:

impl Trait ist der Standard
dyn Trait kommt zum Einsatz wenn der Typ erst zur Laufzeit bekannt ist oder eine heterogene Collection benötigt wird.

Fazit

Traits sind mehr als nur Interfaces. Die Entscheidung zwischen Monomorphisierung und Dynamic Dispatch ist eine Entscheidung zwischen Compile-Zeit-Garantien und Laufzeit-Flexibilität.

Im Vergleich zu Java oder C#, wo jeder Methodenaufruf über eine virtuelle Tabelle aufgelöst wird, gibt Rust einem die Wahl und man muss sich explizit entscheiden, was man möchte.

Explizit und ohne Overhead, sind zwei Grundprinzipien bei Rust, die man sich mit einer etwas steileren Lernkurve und mehr Boilerplate-Code erkauft.

Empfehlungen: IT-Berufe Podcast

Tristan — Fri, 06 Feb 2026 00:00:00 +0000

Worum geht es?

Seit über zehn Jahren begleitet mich der IT-Berufe Podcast.

Stefan Macke behandelt in seinem Podcast alle Themen, die für die Ausbildung in den IT-Berufen wichtig sind, mit leichtem Schwerpunkt auf die Anwendungsentwicklung. Er erklärt, wie man sich bewirbt, was man für den Einstieg benötigt, welche Inhalte prüfungsrelevant sind und vieles mehr.

Für wen ist der Podcast?

Auszubildende
Studierende
Quereinsteiger
Ausbilder
Mentoren
Teamleiter

Was gibt es zu hören?

Interviews
Prüfungstipps
Praxisbeispiele
Lernstrategien
Ausbildungsrecht
Soft Skills

Warum lohnt sich der Podcast?

Ich bin überzeugt, dass jede Person in der IT‑Ausbildung diesen Podcast hören sollte.

Viel zu oft sitzen Azubis oder Studenten in der Ecke und wissen gar nicht genau, was sie denn jetzt eigentlich lernen sollen. Betreuer wissen oft nicht, welche Themen für ihre Mentees wirklich wichtig sind.

Und genau hier kommt der IT-Berufe Podcast von Stefan Macke ins Spiel. Er führt sehr kurzweilig in alle wichtigen Themen ein, so dass man ihm gerne zuhört, auch wenn es mal ein vermeintlich trockenes Thema ist.

Besonders interessant für Auszubildende dürften die expliziten Folgen zur Prüfungsvorbereitung sein.

Auch nach so vielen Jahren ist der Podcast für mich eine der zuverlässigsten Quellen, wenn es um gute IT‑Ausbildung geht.

Viele der Themen sind zeitlos, wie z.B. "Zahlensysteme, Zweierpotenzen und Binärzahlen", "Eigenschaften und Unterscheidung von Programmiersprachen", "Normalisierung einer Datenbank am konkreten Beispiel" und viele mehr.

Wie hört man ihn am besten?

Der Podcast eignet sich hervorragend für den Arbeitsweg oder während konzentrierter Pausen. Stefan Mackes Erklärungen sind kompakt und durchdacht, man sollte ihm definitv aufmerksam zuhören.

Ich empfehle, früh in der Ausbildung oder im Studium einzusteigen. Die Themen bauen nicht streng aufeinander auf, aber ein grundlegendes Verständnis hilft, die Zusammenhänge besser zu erfassen.

Noch besser: Notizen machen. Block oder Tablet zur Hand nehmen und mitschreiben, das erhöht den Lerneffekt.

Wie aktiv ist der Podcast?

Seit über zehn Jahren erscheinen mehrere Folgen pro Jahr. Stefan Macke liefert konstant, zuverlässig und mit hoher Qualität ab.

Persönliches Highlight

Es ist schwer, mich auf eins zu beschränken, aber ich würde sagen, dass gerade die Rückblicke auf vergangene Prüfungen und die Folge "Aufbau und Ablauf der IHK-Abschlussprüfung in den IT-Berufen" besondere Highlights darstellen. Stefan Macke versteht es, den Auszubildenden die Angst vor dem Unbekannten, der Abschlussprüfung, zu nehmen.

Zum Schluss

Gute Ausbildung braucht gute Ressourcen und dieser Podcast gehört auf jeden Fall dazu.

Willkommen

Tristan — Sun, 01 Feb 2026 00:00:00 +0000

Wer

Ich heiße Tristan, bin hauptberuflich Softwareentwickler und übe mich in Philosophie. Neben meinem Beruf bilde ich mich gerne weiter (aktuell Informatik, Mathematik, Philosophie).

Worüber

Philosophie, Informatik, Softwareentwicklung, Mathematik, Technik, Open Source und vieles mehr.

Warum

Ich schreibe gerne, bin aber noch nicht sehr geübt darin. Außerdem möchte ich meine Ideen mit anderen teilen.

Rhythmus

Alle zwei bis vier Wochen erscheint ein neuer Artikel, mal ein Essay oder ein Praxisbericht. Zwischen den Hauptartikeln streue ich manchmal kürzere Stücke ein wie Tools, News, Empfehlungen, Gedanken, die keinen ganz so langen Atem benötigen.

Hin und wieder kann es auch vorkommen, dass es länger als 4 Wochen dauert, bis ein neuer Artikel kommt.
Das kann dann daran liegen, dass mir entweder gerade kein Thema einfällt, überr das ich schreiben möchte oder ich zu viel mit anderen Dingen beschäftigt bin.

Außerdem

Ich teile hier meine Gedanken, Überzeugungen und mein Wissen. Wenn ich falsch liege, freue ich mich über eine Mail von dir.

Wichtige Links

Wenn du mehr über mich erfahren möchtest, schau auf meiner About-Seite vorbei, dort werde ich immer mal wieder Updates zu mir veröffentlichen.