Im Universum Bremen haben wir die Sonderausstellung KI besucht. Dort konnte man an einer Station prüfen, ob man Chihuahuas von Muffins unterscheiden kann. Die Kinder hatten einen Riesenspaß, da das Ganze auf Zeit ging und sie daraus einen Wettbewerb machen konnten. Wer schneller im Unterscheiden war, hatte gewonnen. Eine bessere Zeit zählt jedoch nicht, wenn Karten dabei falsch zugeordnet wurden.

Um überprüfen zu können, wie gut eine Klassifizierung ist, können wir Metriken definieren. Vorher brauchen wir aber noch ein paar grundlegende Begriffe.

Begriffe

Die Unterscheidung zwischen Chihuahua und Muffin ist gar nicht so leicht. Grundsätzlich gibt es vier mögliche Ergebnisse: Ein Chihuahua kann korrekt als Chihuahua erkannt werden, oder er wird fälschlicherweise als Muffin eingeordnet. Umgekehrt kann ein Muffin korrekt als Muffin erkannt werden, oder er wird für einen Chihuahua gehalten. Das sind die vier Klassifikationsmöglichkeiten.

Die Klasse der Objekte, die man erkennen möchte, gilt als der positive Wert. In unserem Fall möchten wir Chihuahuas erkennen.

Ein False Positive wird auch als Typ-1-Fehler bezeichnet, ein False Negative als Typ-2-Fehler.

Beispiel

Wenn sich meine Tochter zwanzig Bilder von Muffins und Chihuahuas anschaut (8 Muffins und 12 Chihuahuas)
und sie 10 davon als Chihuahuas klassifiziert, sich unter diesen zehn jedoch tatsächlich 2 Muffins befinden,
ergibt sich folgendes Bild:

• 8 True Positives – korrekt als Chihuahua erkannt
• 2 False Positives – Muffin fälschlicherweise als Chihuahua eingeordnet
• 6 True Negatives – korrekt als Muffin erkannt
• 4 False Negatives – Chihuahua fälschlicherweise als Muffin klassifiziert

Mit diesen Werten berechnen wir im Folgenden die Metriken.

Metriken

Metriken dienen der Überprüfung der Qualität von Machine-Learning-Algorithmen. Sie funktionieren besonders gut bei Supervised-Learning-Algorithmen, da wir gelabelte Trainings- und Testdaten (Ground-Truth-Labels) vorliegen haben und somit überprüfen können, ob eine Klassifikation korrekt oder falsch erfolgte.

Precision

Die Präzision – auch als positive predictive value bezeichnet – gibt den Anteil der korrekt als positiv klassifizierten Ergebnisse an der Gesamtheit der als positiv klassifizierten Ergebnisse an.

In unserem Beispiel beträgt die Präzision 8 / (8 + 2) = 4/5 oder 80 %.

Recall

Der Recall – auch Sensitivität genannt – gibt die Wahrscheinlichkeit an, mit der ein positives Objekt korrekt als positiv klassifiziert wird.

Da bekannt ist, dass es tatsächlich 12 Chihuahuas gibt und meine Tochter 4 davon übersieht (falsch-negative Ergebnisse), beträgtihre Trefferquote (Recall) 8 / (8 + 4) = 2/3 oder rund 67 %.

Accuracy

Der Accuracy-Score berechnet sich aus dem Anteil aller korrekt klassifizierten Ergebnisse:

In unserem Beispiel ergibt das:

(8 + 6) / 20 = 14/20 = 7/10 = 70 %

F1-Score

Der F1-Score ist das harmonische Mittel zwischen Precision und Recall und bietet sich besonders dann an, wenn beide Größen gleichermaßen wichtig sind.

Für unser Beispiel: 2 / (1 / (4/5) + 1 / (2/3)) = 2 / (5/4 + 3/2) = 2 / (11/4) = 2*(4/11) = 8/11 = 0,727

Fazit

Precision, Recall, Accuracy und F1-Score sind vier grundlegende Metriken, um die Qualität eines binären Klassifikationsmodells zu bewerten. Welche Metrik im Vordergrund steht, hängt dabei vom konkreten Anwendungsfall ab:

• Ist es besonders wichtig, keine positiven Fälle zu verpassen (z. B. bei medizinischen Diagnosen), rückt der Recall in den Fokus.
• Soll hingegen vermieden werden, zu viele Fehlalarme zu produzieren, ist Precision die relevantere Größe.
• Der F1-Score bietet sich an, wenn beide Aspekte gleich gewichtet werden sollen.

Darüber hinaus gibt es weitere Metriken – etwa den ROC-AUC-Score oder die Konfusionsmatrix –, die ein noch detaillierteres Bild liefern können.

Beim Unsupervised Learning gelten zudem andere Regeln: Da keine Ground-Truth-Labels vorliegen, kommen dort eigene Verfahren wie der Silhouetten-Koeffizient oder der Davies-Bouldin-Index zum Einsatz – aber das ist Stoff für einen eigenen Artikel.

The post Qualitätsmetriken bei binärer Klassifikation appeared first on Creatronix.

Wer mit Robotern arbeitet, wird früher oder später eine Zustandsmaschine programmieren müssen, da Roboter typischerweise verschiedene Betriebszustände einnehmen können.

Was sind State Machines?

Eine State Machine (deutsch: Zustandsautomat) ist ein Modell, das beschreibt, wie sich ein System abhängig von seinem aktuellen Zustand und einem Ereignis verhält. Statt viele verschachtelte if-Anweisungen zu verwenden, definiert man klar:

• Zustände – z. B. „Aus”, „Ein”, „Pause”
• Ereignisse – z. B. Tastendruck oder Timer
• Übergänge – wann von einem Zustand in einen anderen gewechselt wird
• Aktionen – was beim Wechsel oder innerhalb eines Zustands passiert

Boost SML

Boost State Machine Language wurde 2016 von Kris Jusiak entwickelt.

• Erste öffentliche Version auf GitHub: 2016
• Anzahl der Contributors: ~50
• Ein bis zwei Releases pro Jahr
• Kein offizieller Teil von Boost

Projektseite: https://github.com/boost-ext/sml

Installation

Variante 1 – Download Header

Die erste Variante ist, eine flache Kopie des Headers direkt ins Projekt zu legen:

cd ~/robot_sml_demo
mkdir boost
wget https://raw.githubusercontent.com/boost-ext/sml/master/include/boost/sml.hpp

Einbinden mit

#include "boost/sml.hpp"

Variante 2 – Globale Verfügbarkeit

Alternativ kann auch das Repo ins Home-Verzeichnis geklont werden:

cd ~
git clone https://github.com/boost-ext/sml

Erstellt dafür den Ordner sml im Home, dann kann man über CMake das Verzeichnis inkludieren

target_include_directories(robot_sml_tutorial PRIVATE
    $ENV{HOME}/sml/include
)

Einbinden kann man nun mit

#include <boost/sml.hpp>

Variante 3 – git submodules

Eine weitere Variante ist die Einbindung über git submodules.

mkdir external
git submodule add https://github.com/boost-ext/sml external/boost
git submodule update --init --recursive

#include "../external/boost/include/boost/sml.hpp"

Einfache State Machine

Im folgenden Implementieren wir eine einfache State Machine für einen Roboter. Hier sind die Zustände und Übergänge tabellarisch:

Ein Bild sagt aber mehr als 1000 Worte:

Erste Implementierung

Eine State Machine in SML benötigt drei Dinge:

• Zustände + Events
• Transition Table
• Transition durch die Zustände mit process_event()

Modellierung der Zustände und Events

In Boost.SML können Zustände und Events durch structs implementiert werden:

// States
struct Idle {};
struct Driving {};
struct Fault{};

// Events
struct Start{};
struct Stop{};
struct Error{};
struct Reset{};

Transition Table

Die Transition Table ist das Herzstück der State Machine. Der Startzustand wird über * definiert, dann folgt die Modellierung der Zustandsübergänge nach dem Muster:

src_state + event = dst_state

struct Robot
{
    auto operator()() const
    {
        using namespace sml;
        return make_transition_table(

            *state<Idle>+ event<Start> = state<Driving>,
            state<Driving> + event<Error> = state<Fault>,
            state<Driving> + event<Stop> = state<Idle>,
            state<Fault> + event<Reset> = state<Idle>
        );
    }
};

TEST(SimpleStateMachine, TestStartState) {
    const sml::sm robot{};

    robot.visit_current_states([](auto state) {
        EXPECT_STREQ(state.c_str(), "Idle");
    });
}

Im Grunde ist Robot hier keine State Machine, sondern eine Konfigurationsklasse. Der operator()()-Ausdruck bedeutet, dass der Funktionsaufruf-Operator überladen wird. Klassen, die diesen Operator implementieren, erzeugen Objekte, die wie ganz normale Funktionen aufgerufen werden können. Solche Objekte nennt man auch Funktoren.

Transition durch die Zustände

Eine Transition von einem Zustand in einen anderen wird durch process_event ausgelöst:

TEST(SimpleStateMachine, TestTransition) {
    sml::sm robot{};

    robot.process_event(Start{});

    robot.visit_current_states([](auto state) {
        EXPECT_STREQ(state.c_str(), "Driving");
    });
}

Actions

Jedem Zustandübergang kann eine Aktion zugeordnet werden, hier im Beispiel mit Lambdas

src_state + event / action = dst_state

struct Robot
{
    auto operator()() const
    {
        using namespace sml;
        return make_transition_table(

            *state<Idle> + event<Start> / [] { std::cout << "Received <<Start>> Event";} = state<Driving>,
            state<Driving> + event<Error> / [] { std::cout << "Received <<Error>> Event";} = state<Fault>,
            state<Driving> + event<Stop> / [] { std::cout << "Received <<Stop>> Event";} = state<Idle>,
            state<Fault> + event<Reset> / [] { std::cout << "Received <<Reset>> Event";} = state<Idle>
        );
    }
};

Actions als Function Objects / Funktoren

Eleganter hingegen ist es, Actions ebenfalls als Funktor zu definieren, da das die Transition Table deutlich übersichtlicher macht:

struct start_action {
    void operator()() const {
        std::cout << "Start\n";
    }
};
struct stop_action {
    void operator()() const {
        std::cout << "Stop\n";
    }
};
struct error_action {
    void operator()() const {
        std::cout << "Error\n";
    }
};
struct reset_action {
    void operator()() const {
        std::cout << "Reset\n";
    }
};

...
return make_transition_table(

     *state<Idle>+ event<Start> / start_action{} = state<Driving>,
     state<Driving> + event<Error> / error_action{} = state<Fault>,
     state<Driving> + event<Stop> / stop_action{} = state<Idle>,
     state<Fault> + event<Reset> / reset_action{} = state<Idle>
 );

Guards

Ein Guard ist eine Bedingung, die entscheiden darf, ob ein Übergang stattfinden soll.

state + event [ guard ] = next_state;

Beispiel

auto battery_ok = [] { return true; };

...
*state<Idle>+ event<Start>[battery_ok] = state<Driving>,

Mehrere Guards verknüpfen

Das ist ein besonderes Feature von SML: Guards können mit &&, || und ! kombiniert werden.

state + event [ guard1 || guard2 ] / action = next_state;

Dependency Injection

Eine weitere große Stärke von SML ist die Verwendung von Dependency Injection.

Hier injiziert SML das RobotContext-Objekt in den Guard:

struct RobotContext {
    bool battery_ok = true;
};
...
*state<Idle>+ (StartEvent)[([](const RobotContext& ctx) {return ctx.battery_ok;})] = state<Driving>,

...
RobotContext ctx;
sml::sm robot{ctx};
robot.process_event(StartEvent());

User-Defined Literals (UDLs)

Zu Deutsch benutzerdefinierte Literale.

States

Für Zustände definiert SML das Literal _s, dadurch ist "Idle"_s ein gültiger Zustand.

Events

Für Events existiert das Literal _e:

auto start_event = "Start"_e;

Die Transitiontabelle wird dadurch etwas besser lesbar:

return make_transition_table(

    *"Idle"_s    + start_event  = "Driving"_s,
     "Driving"_s + stop_event  = "Idle"_s,
     "Driving"_s + error_event = "Fault"_s,
     "Fault"_s   + reset_event = "Idle"_s
    );

Im process_event muss es dann so aufgerufen werden:

robot.process_event(start_event());

Fazit & Ausblick

SML ist eine kleine, schlanke Library für State Machines in C++. Sie überzeugt durch ihre ausdrucksstarke Syntax, Dependency Injection und die Möglichkeit, Guards flexibel zu kombinieren.

Links

Die Codebeispiele findest Du in diesem Repo:
https://github.com/jboegeholz/boost_sml_tutorial

The post Boost SML Tutorial appeared first on Creatronix.

Der Mensch ist im Grunde kein faules Tier. Er ist nur sehr konsequent darin, unnötige Mühen als persönliche Beleidigung zu empfinden.

Irgendwann stand also einer da, hatte zwei Arme voll Zeug und dachte: „Nee, komm, dat kann doch nich alles gewesen sein.“ Zack: Rad. Ein anderer kaute auf rohem Fleisch herum wie auf einem alten Fahrradmantel und kam zu dem Schluss, dass die Evolution ruhig mal einen Gang höher schalten könnte. Also Feuer.

Später saß jemand vor einem getippten Text und verschmierte Tipp-Ex. Daraus wurden dann Textverarbeitung, Backspace-Taste und dieses stille Glück, einen Fehler einfach verschwinden lassen zu können.

Im Kern geht es immer um dasselbe: Das Gehirn will nicht mehr Energie verbrauchen als unbedingt nötig. Es möchte rationale Entscheidungen treffen, Aufwand senken und den erwarteten Nutzen erhöhen. Klingt trocken, ist aber menschheitsgeschichtlich gesehen der rote Faden vom Faustkeil bis zur Tabellenkalkulation.

Und deshalb forscht der Mensch heute an KI: nicht nur, weil er bequem ist, sondern weil er verstehen will, wie Intelligenz funktioniert, wie man nützliche Aufgaben automatisiert und wie daraus Werkzeuge für Wissenschaft, Wirtschaft und Gesellschaft entstehen.

Kurz gesagt: Der Mensch denkt gern. Aber wenn eine Maschine das Vorsortieren übernehmen kann, sagt er auch nicht nein.

Historie der KI

“Ich baue ein Neuron so, dass es eine feste Regel ausführt.”

Die Sache mit der KI fing nicht erst an, als irgendein Start-up-Mensch mit Macha Latte in einem Co-Working-Space „disruptiv“ sagte.

Schon 1943 saßen Warren McCulloch und Walter Pitts da und dachten sich sinngemäß: „Wenn das Gehirn mit Neuronen arbeitet, kann man doch mal gucken, ob man sowas nicht auch in ordentlich nachbauen kann.“ Also beschrieben sie einfache Einheiten, die miteinander verknüpft werden – ein Netz, das grob an Nervenzellen im Gehirn erinnert. Das Paper hieß “A Logical Calculus of the Ideas Immanent in Nervous Activity”.

Das Neuron konnte als Boolesche Variable die Zustände wahr und falsch annehmen und „feuerte“ (= wahr), wenn die Summe der Eingangssignale einen Schwellenwert überschritt.

Und siehe da: Mit solchen künstlichen Neuronen ließen sich theoretisch so ziemlich jede logische oder arithmetische Funktion berechnen. Also alles, wofür normale Menschen später Taschenrechner, Computer und irgendwann Kaffee brauchten.

Das Perzeptron

“Ich gebe dem Neuron Beispiele, und es verändert seine Gewichte, bis es die Regel selbst gelernt hat.”

Dann kam das Perzeptron. Es wurde 1957 von Frank Rosenblatt vorgestellt und ist ein vereinfachtes künstliches neuronales Netz. Sein wichtigster Beitrag: die Anpassung der Gewichte erfolgte jetzt dynamisch. Die Ausgabe des Neurons blieb dank der Schwellwertfunktion aber digital 0 oder 1, auch wenn die Eingaben jetzt kontinuierliche Werte verarbeiten konnte.

Einlagiges Perzeptron

Nehmen wir ein Perzeptron mit 2 Eingaben und einer Ausgabe:

Die Verbindung vom Neuron x1 zu Neuron z wird mit dem Gewicht w1 multipliziert, die von x2 mit w2.
Zusätzlich wird noch ein unabhängiger Bias b addiert.
So kommt die Formel

zustande.

Jetzt Butter bei die Fische, wir rechnen jetzt mit konkreten Werten:

Eingabewerte

Gewichte

Bias
b = 0.1

Damit ergibt sich:

Aktivierungsfunktion

Jetzt kommt noch die Aktivierungsfunktion dazu.
Bei einem klassischen Perceptron verwendet man häufig eine Schwellenfunktion, auch Heaviside-Funktion oder Step Function genannt.
Das bedeutet: Liegt die gewichtete Summe über einem bestimmten Schwellwert, gibt das Neuron eine 1 aus. Liegt sie darunter, gibt es eine 0 aus.

Da -0.2 kleiner als 0 ist, bleibt der Ausgang auch auf 0

Error / Loss Function

Der Fehler ist die Differenz zwischen dem berechneten Wert und dem erwarteten Wert.
Beim Perceptron wird jetzt der Fehler berechnet, indem der Vorhersagewert vom echten Wert des Traininglabels abgezogen wird.

Für unser Beispiel erwarten wir eine 1 am Ausgang, bekommen aber eine 0, also ist der Fehler 1

Lernregeln und Lernrate

Konfuzius soll gesagt haben: “Ein Fehler, den man nicht korrigiert, ist der eigentliche Fehler.”

Beim Perzeptron gilt:

• Stimmen Ausgabe und Zielwert überein, bleiben Gewichte und Bias unverändert.
• Ist die Ausgabe 0, obwohl sie 1 sein sollte, werden die passenden Gewichte erhöht.
• Ist die Ausgabe 1, obwohl eine 0 erwartet wurde, werden sie verringert.

Mathematisch
w_i' = w + \Delta w \\ b' = b + \Delta b

Die Größe der Anpassung wird durch die Lernrate eta gesteuert:
\Delta w = \eta (y_{soll} - y_{ist}) * x_i \\ \Delta b = \eta (y_{soll} - y_{ist})

Nehmen wir eine Lernrate von:

Dann werden die Gewichte angepasst:

Auch der Bias verändert sich:

Mit den neuen Werten erhalten wir:

Nach der Aktivierungsfunktion:

Nach nur einem Lernschritt liefert das Perzeptron den gewünschten Wert.

Epoche

In unserem Beispiel war bereits nach einer Anpassung das richtige Ergebnis erreicht. Das ist in der Praxis nicht immer so.

Häufig müssen sämtliche Trainingsbeispiele mehrfach verarbeitet werden, bis brauchbare Gewichte gefunden sind.

Einen vollständigen Durchlauf durch alle Trainingsdaten nennt man eine Epoche oder auf Englisch epoch.

Das klingt gewaltiger, als es ist. Im Grunde bedeutet es nur: einmal alles durchsehen und anschließend feststellen, dass man noch mal von vorne anfangen muss.

Beispiel: Festival-Entscheider

Schluss mit trockener Theorie, wir brauchen ein praktisches Anwendungsbeispiel!
Ich war auf Rock im Park mit einem Kumpel und das Lineup war gut und wir haben Camping-Tickets bekommen. Das Jahr drauf hat mir das Lineup nicht zugesagt und es waren keine Camping-Tickets verfügbar, also bin ich nicht gegangen.

Daraus können wir ein sehr einfaches Entscheidungsmodell bauen. Unser erster Eingang x1 beschreibt, ob mir das Line-up gefällt. Unser zweiter Eingang x2 beschreibt, ob ein Camping-Ticket verfügbar ist.

Eine 1 bedeutet „ja“, eine 0 bedeutet „nein“. Der Ausgang y beschreibt meine Entscheidung: Fahre ich hin, ist der Ausgang 1. Bleibe ich zu Hause, ist er 0.

Wir setzen das jetzt mit Python um. Ich verschone euch vorerst mit numpy, pytorch und Konsorten.
Für das Perzeptron reicht Vanilla Python völlig aus.

X = [
[0, 0],
[0, 1],
[1, 0],
[1, 1]
]
y_train = [0, 0, 0, 1]

Die Gewichte und den Bias initialisieren wir jeweils mit 0:

weights = [0.0, 0.0]
bias = 0.0

Als Lernrate nehmen wir wieder 0,1

eta = 0.1
number_of_epochs = 10

Die Schwellenfunktion liefert 1, sobald z mindestens null ist:

def step_function(z):
    return 1 if z >= 0 else 0

Nun folgt das Training:

print(f"Start training: weights {weights}, bias {bias}")
for epoch in range(number_of_epochs):
    for x, y_true in zip(X, y_train):
        z = x[0] * weights[0] + x[1] * weights[1] + bias
        y_pred = step_function(z)

        error = y_true - y_pred

        weights[0] = weights[0] + eta * error * x[0]
        weights[1] = weights[1] + eta * error * x[1]
        bias = bias + eta * error

    print(f"Epoch {epoch} weights {weights}, bias {bias}")


print(f"Finished training: weights {weights}, bias {bias}")

Das Programm geht alle Beispiele durch, berechnet eine Vorhersage und korrigiert bei Bedarf Gewichte und Bias.

Grenzen des Perzeptrons

Ein einzelnes Perzeptron kann nur Probleme lösen, die linear separierbar sind.

Das bedeutet: Die verschiedenen Klassen müssen sich durch eine gerade Linie, beziehungsweise in höheren Dimensionen durch eine Ebene, voneinander trennen lassen.

Unsere Festivalentscheidung funktioniert. Nur wenn sowohl Line-up als auch Camping stimmen, fahren wir hin. Diese Fälle lassen sich sauber trennen. Beim XOR-Gatter klappt das nicht. Für solche Probleme braucht man mehrere Schichten beziehungsweise komplexere neuronale Netze.

Ausblick auf das ADALINE

Das klassische Perzeptron lernt anhand der fertigen Entscheidung. Es sieht also nur die ausgegebene 0 oder 1.

ADALINE, kurz für Adaptive Linear Neuron, verwendet für das Lernen dagegen den linearen Rohwert vor der Schwellenfunktion.

Dadurch erkennt ADALINE nicht nur, ob eine Vorhersage falsch war, sondern auch, wie weit sie danebenlag.

Paper

https://www.cs.cmu.edu/~epxing/Class/10715/reading/McCulloch.and.Pitts.pdf
https://bpb-us-e2.wpmucdn.com/websites.umass.edu/dist/a/27637/files/2016/03/rosenblatt-1957.pdf

Links

https://neuralnetworksanddeeplearning.com/chap1.html

Frank Rosenblatt und das Perceptron

https://www.nutsvolts.com/magazine/article/the_perceptron_circuit

Videos

Hardware Perceptron 
Perceptron Algorithm with Code Example
Adaline
Perceptron Research 

The post Das Perzeptron appeared first on Creatronix.

Jeder kennt und nutzt Git. Es gibt bis auf Ausnahmen (ich schaue dich an, Perforce) keine ernstzunehmenden Alternativen mehr.

Ich lasse Azubis ab der ersten Woche schon mit Git arbeiten, allerdings zunächst im Kontext einer IDE,
damit sie ihren Code entspannt versionieren können.

Im zweiten Lehrjahr gibt es dann den Blick hinter die Kulissen, also auf die Kommandozeile.

Inhalt

• Basics: Installation, Konfiguration, Repository erstellen, Status & Log, Commits, .gitignore, Remote, Fetch & Pull
• Intermediate: Branching, Merging, Merge-Konflikte, Stash, Diff, Tags
• Advanced: Rebase, Squashen von Commits, Cherry-Pick, Reflog, Bisect

Voraussetzungen

• Ein Terminal / eine Shell (bash, zsh, PowerShell, …)
• Grundlegende Erfahrung mit der Kommandozeile (cd, mkdir, ls/dir)
• Optional: ein GitHub- oder GitLab-Account für Remote-Repositories

Basics

Installation

Damit etwas unter Versionskontrolle gestellt werden kann, muss Git zuerst installiert sein.

Windows:

Download von https://git-scm.com/download/win und Installer ausführen

Linux (Debian/Ubuntu):

sudo apt install git

macOS:

brew install git

Wir können nun testen, ob die Installation erfolgreich war:

git --version

Konfiguration

Bevor wir loslegen, teilen wir Git unseren Namen und unsere E-Mail-Adresse mit.
Diese Infos werden in jedem Commit gespeichert.

git config --global user.name "Dein Name"
git config --global user.email "deine@email.de"

Optional – Standardbranch auf main setzen:

git config --global init.defaultBranch main

Repository erstellen (init)

mkdir my_workspace
cd my_workspace
git init

Damit haben wir ein leeres Git-Repository. Jetzt legen wir die ersten Dateien an:

touch .gitignore
touch README.md
touch app.py

Status & Log

Zwei Befehle, die man ständig braucht sind:

git status # Zeigt den aktuellen Zustand des Repositories
git log # Zeigt die Commit-Historie
git log --oneline # Kompakte Einzeiler-Ansicht

Staging & Commit

Dateien müssen zunächst in die Staging Area und können dann committet werden:

git add . # Alle Änderungen stagen
git add README.md # Einzelne Datei stagen
git commit -m "initial commit" # Commit mit Nachricht

Tipp: Gute Commit-Messages beschreiben was und warum, nicht wie.

.gitignore

Die Datei .gitignore definiert, welche Dateien Git ignorieren soll (Build-Artefakte, IDE-Konfiguration, Secrets, …):

# Beispiel .gitignore
pycache/
*.pyc
.idea/
.env
build/

Remote hinzufügen und pushen

Ein Remote-Repository (z. B. auf GitHub) wird so verknüpft:

git remote add origin https://github.com/user/repo.git
git push -u origin main

-u setzt das Upstream-Tracking, sodass git push danach ohne weitere Argumente funktioniert.

Änderungen vom Remote holen

git fetch # Holt Änderungen, merged aber NICHT
git pull # Holt Änderungen UND merged in den aktuellen Branch

Faustregel: fetch ist sicher und unverbindlich, pull verändert den lokalen Branch.

Intermediate

Remote-Repo clonen

Statt ein Repository von Grund auf neu zu erstellen, kannst du ein bestehendes Remote-Repository mit git clone auf den eigenen Rechner kopieren.
Dabei passiert automatisch einiges:

1. Ein neuer Ordner mit dem Repository-Namen wird erstellt
2. Die gesamte Historie (alle Commits, Branches, Tags) wird heruntergeladen
3. Ein Remote namens origin wird angelegt, der auf die Quell-URL zeigt
4. Der Standard-Branch (z. B. main) wird ausgecheckt

Grundsyntax:

git clone https://github.com/user/repo.git

Einen bestimmten Branch clonen:

git clone -b develop https://github.com/user/repo.git

Damit wird direkt der Branch develop ausgecheckt, nützlich, wenn du nicht auf main arbeiten möchtest.

Tipp: Nach dem Clonen kannst du dir den eingerichteten Remote anzeigen lassen:

cd repo
git remote -v

#origin https://github.com/user/repo.git (fetch)
#origin https://github.com/user/repo.git (push)

Branching

Branches sind einer der größten Vorteile von Git. Sie erlauben paralleles Arbeiten an Features, Bugfixes usw.

git branch # Alle lokalen Branches anzeigen
git branch feature/login # Neuen Branch erstellen
git checkout feature/login # In den Branch wechseln
git checkout -b feature/login # Erstellen + Wechseln in einem Schritt

Merging

Wenn ein Feature fertig ist, wird der Branch zurück in main gemerged:

git checkout main
git merge feature/login

Merge-Konflikte

Wenn zwei Branches dieselbe Stelle in einer Datei geändert haben, entsteht ein Merge-Konflikt.
Git markiert die betroffenen Stellen:

<<<<<<< HEAD
Deine Änderung
=======
Änderung aus dem anderen Branch
>>>>>>> feature/login

Lösung: Datei manuell bereinigen, dann:

git add <datei>
git commit

Stash

Unfertige Änderungen kann man zwischenspeichern, ohne zu committen:

git stash # Änderungen wegstashen
git stash list # Alle Stashes anzeigen
git stash pop # Letzten Stash wiederherstellen und entfernen
git stash apply # Letzten Stash wiederherstellen, aber behalten

Diff

Änderungen anzeigen lassen:

git diff # Unstaged-Änderungen
git diff --staged # Staged-Änderungen (vor dem Commit)
git diff main..feature # Unterschied zwischen zwei Branches

Tags

Releases oder Meilensteine markieren:

git tag v1.0.0
git tag -a v1.0.0 -m "Erstes Release"
git push origin v1.0.0

Advanced

Rebase

Rebase schreibt die Commit-Historie um und setzt Commits auf eine neue Basis.
Nützlich, um einen sauberen, linearen Verlauf zu erzeugen:

git checkout feature/login
git rebase main

Achtung: Rebase verändert die Historie. Deshalb nicht auf bereits gepushten, geteilten Branches verwenden.

Squashen von Commits

Mehrere Commits zu einem zusammenfassen (z. B. vor einem Merge Request):

git rebase -i HEAD~3 # Die letzten 3 Commits interaktiv bearbeiten

Im Editor dann pick für die gewünschten Commits durch squash (oder s) ersetzen.

Cherry-Pick

Einen einzelnen Commit aus einem anderen Branch übernehmen:

git cherry-pick <commit-hash>

Reflog

Das Sicherheitsnetz: Zeigt alle Aktionen, auch nach einem versehentlichen Reset:

git reflog
git checkout <hash> # Verlorenen Stand wiederherstellen

Fazit

Git ist ein mächtiges Werkzeug. Die Basics reichen für den Alltag, aber wer Rebase, Squash und Bisect beherrscht,
kann auch in komplexen Projekten souverän arbeiten.

Weiterführende Ressourcen:

• Git Branching interaktiv lernen
• Pro Git Book (kostenlos)
• Git Cheat Sheet
• git help <befehl>: Die eingebaute Hilfe ist besser, als man denkt

The post Das große Git-Tutorial appeared first on Creatronix.

Motivation

Das Erlernen einer Programmiersprache kann herausfordernd sein. Es gibt zwar unzählige Artikel und Tutorials, doch echtes Verständnis entsteht vor allem durch regelmäßige Wiederholung und praktische Anwendung.

Wer Konzepte immer wieder in kleinen Übungen, Katas und realen Problemen einsetzt, entwickelt mit der Zeit eine Art Muscle Memory fürs Programmieren. Genau diese Routine hilft dabei, Syntax, Denkweisen und Lösungsstrategien nachhaltig zu verinnerlichen.

Die Herausforderungen

Die Programmieraufgaben sind sprachunabhängig, sodass du jede moderne Sprache verwenden kannst, die das Schreiben von Konsolenanwendungen unterstützt.

🟢 Level 1 – Grundlagen (Syntax & einfache Logik)

1. Schreibe das berühmte / berüchtigte „Hello World“
2. Schreibe ein Skript, das alle Zahlen von 1 bis 365 in die Konsole ausgibt
3. Schreibe ein Skript, das 10 Zufallszahlen zwischen 1 und 10 ausgibt
4. Schreibe ein Skript, das alle Buchstaben des Alphabets (großgeschrieben) mit ihrer jeweiligen Position ausgibt, z. B. 1: A, 2: B
5. Schreibe deinen ersten Unit-Test für eine Funktion is_even(num), die true zurückgibt, wenn die Zahl gerade ist

🟡 Level 2 – Einfache Funktionen & Kontrolle

1. Schreibe eine Funktion to_upper, die einen String von lower_case nach upper_case umwandelt
2. Die Funktion compare(num1, num2) soll
   1. -1 zurückgeben, wenn num1 kleiner als num2 ist
   2. ansonsten 1 zurückgeben
   3. wenn beide Werte gleich sind, 0 zurückgeben
3. Die Funktion simple_sum(num) soll alle Zahlen von 1 bis num aufsummieren
   1. Beispiel: Bei Eingabe 4 soll das Ergebnis 10 sein
   2. Für Testfälle liegt num zwischen 1 und 1000
4. Die Funktion time_convert(minutes) soll Minuten in Stunden und Minuten umwandeln (z. B. 63 → 1:03)
5. Die Funktion first_reverse(input) soll den String umdrehen

🟠 Level 3 – Strings & Arrays

1. Die Funktion alphabet_soup(input) soll den String alphabetisch sortieren
2. Die Funktion longest_word(sentence) soll das längste Wort zurückgeben
3. Die Funktion letter_changes(input) soll Buchstaben ersetzen und Vokale kapitalisieren

🔵 Level 4 – Mathematische Grundlagen

1. Die Funktion factorial(num) soll die Fakultät berechnen
2. Schreibe eine Funktion, die Fibonacci-Zahlen erzeugt (inkl. Memoization)
3. Schreibe eine Funktion, die die Collatz-Sequenz als Liste zurückgibt
4. Schreibe eine Funktion, die den Mittelwert (Mean) eines Integer-Arrays berechnet
5. Schreibe eine Funktion, die den Median eines Integer-Arrays berechnet

🟣 Level 5 – Klassische Algorithmen

1. Schreibe eine Funktion, die ein Integer-Array mit Bubble Sort sortiert
2. Schreibe eine Funktion, die eine Liste von Primzahlen mithilfe des Siebs des Eratosthenes zurückgibt
3. Schreibe eine Funktion, die den größten gemeinsamen Teiler mithilfe des euklidischen Algorithmus berechnet

🔴 Level 6 – Anspruchsvoll / Interview-Level

1. Schreibe eine Funktion, die römische Zahlen in Dezimalzahlen konvertiert
2. Schreibe eine Funktion, die Dezimalzahlen in römische Zahlen konvertiert
3. Die Funktion kaprekars_constant(num) berechnet die Anzahl der Schritte bis 6174 erreicht wird

🧪 Hinweis

Ab der Funktion simple_sum sollte nach dem TDD-Prinzip gearbeitet werden (Test → Implementierung → Refactoring).

The post Lerne neue Programmiersprachen schneller mit diesen Coding Challenges appeared first on Creatronix.

Disclaimer

Die folgende Unterteilung in Programmierung, Entwicklung und Engineering ist ein Versuch einer Einordnung von Prozessen, Methoden und Tools. Ich habe dieses Modell entwickelt, um unseren Auszubildenden und Praktikanten, die oft keine Vorkenntnisse hatten, Software-Engineering beizubringen.

Daher enthält es einige persönliche Ansichten und möglicherweise keine präzisen Definitionen. Es spiegelt meine fast 20-jährige Erfahrung in der Softwarebranche als Entwickler, Tester, QA-Mitarbeiter und Teamleiter wider.

Programmierung: der Kern

Ein bekannter Spruch lautet:

A programmer is an organism that turns coffee and pizza into code.

Programmieren bedeutet, Anforderungen des Kunden in ausführbare Anweisungen, die ein Computer versteht, zu übersetzen. Das kann eine einzelne Person — ein Programmierer — tun.

Programmiersprachen

Ein Programmierer braucht eine oder mehrere Programmiersprachen um Quellcode zu erstellen. Quellcode oder oft nur Code ist Text in einer Sprache wie C, C++, Java oder Python. Jede Sprache definiert klare Regeln für Syntax und Semantik.

Vom Quelltext zum Programm

1. Quelltext schreiben (Editor oder IDE)
2. Kompilieren (z. B. C/C++)
3. Linken und ausführbare Datei erzeugen

Beispiel in C:

#include <stdio.h>

int main(void) {
    printf("Hello world\n");
    return 0;
}

gcc -Wall -g -c hello.c
gcc -o hello hello.o -lm

Das reicht schon, damit wurde bereits ein Programm erstellt. Für echte Projekte oder Produkte reicht das reine
Programmieren aber noch nicht aus.

Softwareentwicklung: vom Code zum Produkt

Sobald mehrere Personen beteiligt sind oder Kundennutzen im Fokus steht, kommen Prozesse, Rollen und Werkzeuge hinzu.

Requirements Tracking – Anforderungen erfassen und klären

Damit ein Team von Programmierern das Richtige baut, müssen Anforderungen des Kunden klar beschrieben werden. Eine Anforderung, die in Textform niedergeschrieben wurde, nennt man auch Requirement. Für die Formulierung haben sich zwei Formate etabliert:

• User Story: Als Rolle möchte ich Funktion, damit Nutzen.
• Use Case: strukturierte Beschreibung einer Interaktion zwischen Nutzer und System

Anforderungen erhalten IDs, Status und Verweise auf Implementierung und Tests. So bleibt über den gesamten Lebenszyklus nachvollziehbar, was umgesetzt, geändert oder verworfen wurde.

Auch die guten alten Lastenhefte (Was der Kunde will) und Pflichtenhefte (Was wir verstanden haben und auch umsetzen werden) haben oft noch ihre Daseinsberechtigung.

Neue Rollen

Dedizierte Tester entlasten ein Team von Programmierern und erhöhen die Produktqualität, weil sie Programme systematisch aus Nutzer- und Risikoperspektive prüfen.

Typische Aufgaben für Tester sind:

• Testfälle aus den Anforderungen ableiten
• Teststrategie und Testdaten definieren
• Manuelle und automatisierte Tests durchführen
• Fehler sauber dokumentieren und priorisieren
• Regressionsrisiken vor Releases bewerten

Wichtig: Tester “testen nicht nur am Ende”, sondern arbeiten früh mit den Programmierern zusammen. So werden Qualitätsprobleme früher sichtbar und deutlich günstiger behoben.

Dokumentation

Gute Dokumentation entlastet Teams im Alltag und reduziert Wissensinseln.

• Produktdokumentation: Was kann das System aus Nutzersicht?
• Technische Dokumentation: Architektur, Schnittstellen, Betriebswissen
• Entscheidungsdokumentation: Warum wurde etwas so gebaut?

Wichtig ist nicht “möglichst viel Text”, sondern aktuelle, auffindbare und wartbare Dokumentation.

Versionsverwaltung nutzen

Werkzeuge wie Git speichern den kompletten zeitlichen Verlauf einer Codebasis. Sie ermöglichen damit:

• Zusammenarbeit im Team
• Nachvollziehbare Änderungen
• Rückkehr zu früheren Ständen

Hinweis: Git ersetzt kein vollständiges Backup-Konzept.

Builds automatisieren & Abhängigkeiten verwalten

Moderne Anwendungen nutzen viele oft externe Bibliotheken. Package Manager wie cargo, npm oder gradle helfen bei einheitlichen Builds und reproduzierbaren Versionen. Ziel: Alle können jederzeit denselben Build erzeugen.

Zusätzlich braucht es klare Build Tools und ein belastbares Build System:

• standardisierte Build-Kommandos lokal und in CI
• reproduzierbare Artefakte über Umgebungen hinweg
• schnelle, stabile Pipelines mit klarer Fehlerdiagnose

IDE

Während beim reinen Programmieren ein einfacher Texteditor ausreichen kann, verwenden Softwareentwickler in der Praxis meist leistungsfähige IDEs.

Eine IDE bündelt zentrale Entwicklungsaufgaben in einem Werkzeug:

• Code schreiben mit Syntaxprüfung und Autovervollständigung
• Navigation durch große Codebasen (z. B. “Gehe zu Definition”)
• Refactoring mit geringem Fehlerrisiko
• Debugging mit Breakpoints und Variableninspektion
• Direkte Integration von Tests, Linter und Build-Prozessen
• Anbindung an Versionsverwaltung wie Git

Der eigentliche Nutzen liegt in der Produktivität und Qualität: Teams arbeiten schneller, konsistenter und machen weniger vermeidbare Fehler.

Issue Tracking – Arbeit transparent machen

Issues, Bugs und Aufgaben werden in einem Tracking-System verwaltet (z. B. Jira, YouTrack, GitHub Issues). So bleiben Prioritäten, Zuständigkeiten und Fortschritt nachvollziehbar.

Projektorganisation mit Scrum oder Kanban

Damit Teamarbeit planbar und transparent bleibt, wird Arbeit in kleine, priorisierte Einheiten aufgeteilt und sichtbar gemacht.

Bei Scrum erfolgt die Planung meist in festen Iterationen (Sprints), z. B. alle ein bis zwei Wochen:

• Ziele für den Sprint festlegen
• Aufgaben gemeinsam schätzen und zuschneiden
• Fortschritt täglich abstimmen
• Ergebnisse am Sprint-Ende überprüfen und verbessern

Bei Kanban steht der kontinuierliche Fluss im Vordergrund:

• Aufgaben visualisieren (z. B. To-do, In Arbeit, Erledigt)
• Parallelarbeit mit WIP-Limits begrenzen
• Engpässe früh erkennen und aktiv beseitigen

Beide Ansätze helfen, Lieferfähigkeit und Qualität im Alltag stabil zu halten.

Qualität absichern

Qualität entsteht nicht zufällig, sondern durch disziplinierte Routinen:

• Tests (Unit, Integration, End-to-End)
• TDD (Test-Driven Development)
• Debugging
• Logging
• Linting und statische Codeanalyse
• Code Reviews

TDD sinnvoll einsetzen

Bei TDD schreibst du zuerst einen fehlschlagenden Test, implementierst dann den minimal nötigen Code und verbesserst anschließend die Struktur (Red-Green-Refactor).

TDD ist besonders hilfreich bei:

• Geschäftslogik mit klaren Regeln
• APIs und Modulen mit stabilen Schnittstellen
• Codebereichen, die häufig geändert werden

So entsteht oft besser testbarer, klarer strukturierter Code und Regressionen werden früher erkannt.

Struktur schaffen mit Design Patterns

Design Patterns werden benötigt, weil in Softwareprojekten viele Probleme immer wieder auftreten. Statt jedes Mal eine neue, ungeprüfte Lösung zu bauen, nutzt du bewährte Strukturen.

Sie helfen konkret bei:

• Verständlichkeit: Andere Entwickler erkennen schneller, wie dein Code aufgebaut ist.
• Wartbarkeit: Änderungen sind einfacher, weil Verantwortlichkeiten klarer getrennt sind.
• Erweiterbarkeit: Neue Features lassen sich oft mit weniger Umbau integrieren.
• Teamkommunikation: Begriffe wie Factory, Observer oder Strategy sind eine gemeinsame Sprache.
• Risikoreduktion: Patterns sind praxiserprobt und vermeiden typische Architekturfehler.

Kurz: Design Patterns machen Code nicht “magisch besser”, aber sie machen komplexe Systeme robuster und für Teams beherrschbarer.

Software-Engineering – erfolgreich Großprojekte umsetzen

Sobald mehrere Teams parallel an einem Produkt arbeiten, reicht reine Softwareentwicklung nicht mehr aus. Spätestens bei Teamgrößen von etwa 8 bis 12 Personen (oder mehreren unabhängigen Feature-Teams) steigen Koordinationsaufwand, Integrationsrisiken und Betriebsverantwortung deutlich.

Dann geht es nicht nur um “Features bauen”, sondern auch um:

• einheitliche technische Leitplanken
• verlässliche Release- und Betriebsprozesse
• klare Verantwortlichkeiten zwischen Entwicklung, Produkt und Betrieb
• skalierbare Qualitätssicherung über Teamgrenzen hinweg

Genau hier beginnt der eigentliche Mehrwert von Software Engineering.

Neue Rollen

Mit wachsender Produkt- und Teamgröße entstehen zusätzliche Rollen, die Entwicklung strukturieren und skalierbar machen.

Projektleiter koordinieren Zeit, Budget, Abhängigkeiten und Risiken.
Sie sorgen dafür, dass Entscheidungen transparent sind und Teams in die gleiche Richtung arbeiten.

Requirements Engineers präzisieren Anforderungen und übersetzen fachliche Ziele in umsetzbare Spezifikationen.
Dadurch sinken Missverständnisse zwischen Fachseite, Produktmanagement und Entwicklung.

DevOps-Teams bauen die Brücke zwischen Entwicklung und Betrieb.
Sie verantworten u. a. CI/CD-Pipelines, Deployment-Prozesse, Monitoring und stabile Betriebsabläufe.

Wichtig ist das Zusammenspiel: Diese Rollen ersetzen nicht die Entwicklung, sondern schaffen den Rahmen, in dem Entwicklung zuverlässig liefern kann.

Architektur definieren

Architektur beschreibt die grobe Struktur und die Kommunikationswege eines Systems, z. B.:

• Frontend – Backend – Datenbank
• Schichtenarchitektur
• Event-basierte Systeme (Pub/Sub)
• Dependency-Injection-Frameworks

Sie legt die Leitplanken fest, nicht jedes Implementierungsdetail.

Software betreiben und ausliefern

Zum Engineering gehört auch der Betrieb:

• CI/CD (Continuous Integration / Continuous Deployment) für automatisches Bauen, Testen und Ausrollen
• Staging-Umgebungen vor Produktion
• Branching-Strategie (z. B. Trunk-Based oder Gitflow)
• Containerisierung mit Docker/Kubernetes
• Monitoring und Qualitätsmetriken
• Release Notes pro Version oder Deployment
• Artifact Mirror/Artifact Repository für kontrollierte Abhängigkeiten und Build-Artefakte

Quality Dashboards nutzen

Quality Dashboards machen Qualität messbar statt gefühlt. Typische Kennzahlen sind:

• Testabdeckung und Fehlerraten
• Build- und Deployment-Stabilität
• Laufzeitmetriken wie Latenz, Fehlerquote und Verfügbarkeit
• technische Schulden (z. B. statische Analyse, Duplikate, Komplexität)

Nicht jede Metrik passt für jedes Team. Entscheidend ist, wenige Kennzahlen konsequent zu nutzen und Trends zu beobachten.

Blindspots im Alltag

Einige Themen fehlen in vielen Teams anfangs, sind aber zentral für professionelles Software Engineering:

• Security by Design: Threat Modeling, Dependency-Scans, Secret-Management, Sicherheitsupdates
• Reliability Engineering: SLOs, Alerting, Runbooks, Incident- und Postmortem-Prozesse
• Wartbarkeit: technischer Schuldenabbau, regelmäßige Refactorings, klare Ownership
• Wissensverteilung: Onboarding, Pairing, Reviews und Dokumentation statt “Single Points of Failure”

Fazit

Software Engineering ist mehr als Programmieren. Es verbindet Technik, Prozesse und Zusammenarbeit, damit Software langfristig zuverlässig, wartbar und nutzbar bleibt.

Wie ich eingangs erwähnte: Dies ist ein gedankliches Modell. Die Grenzen zwischen den Bereichen sind fließend: Man kann natürlich von Anfang an Versionskontrolle einsetzen und ein CI/CD-System für ein einfaches „Hello World“-Programm einrichten. Mein Hauptanliegen ist es, das Bewusstsein dafür zu schärfen, dass Softwareentwicklung eine Vielzahl von Werkzeugen und Praktiken umfasst, deren Lernkurve steil ist, wenn man versucht, alles auf einmal zu beherrschen. Durch die Unterteilung des Fachgebiets in drei Ebenen lassen sich die Konzepte möglicherweise leichter schrittweise erfassen und die Fähigkeiten von innen nach außen entwickeln.

Links

Die Junior und die Senior-Rolle

Wie baue ich eine entwicklungsbegleitende Software-Qualitätssicherung auf?

Wie TDD die Welt rettet und deine Nerven schont

Pytest Tutorial

So verwendest du Google Test in deinem C++-Projekt

Alles was du über Scrum wissen musst

Writing as a complementary skill for your SW engineering career

Literatur

The Software Engineer’s Guidebook

Mein erster Kontakt mit TDD (old but gold) 

The post Was ist Software Engineering? Eine verständliche Einführung appeared first on Creatronix.

Eine einzelne Ubuntu-Maschine zu warten, ist noch überschaubar. Man loggt sich per SSH ein, installiert ein paar Pakete, macht ein Update – und dann läuft die Kiste wieder.

In der Robotik bleibt es aber selten bei einer Maschine. Sobald mehrere Roboter im Einsatz sind, sitzt man plötzlich vor einem kleinen Zoo aus Linux-Systemen.

Dann beginnt die klassische Runde:
SSH auf Rechner eins, Updates einspielen.
SSH auf Rechner zwei, dieselben Updates einspielen.
SSH auf Rechner drei – na, Du ahnst es schon.

Spätestens nach dem fünften Roboter merkt man: Das ist weniger Systemadministration und mehr Fleißarbeit mit Copy-Paste.

Genau hier kommt Ansible ins Spiel. Mit sogenannten Playbooks beschreibt man einfach den gewünschten Zustand der Systeme – welche Pakete installiert sein sollen, welche Konfigurationen gelten, welche Updates eingespielt werden. Ansible kümmert sich dann darum, diese Zustände automatisch auf allen Zielrechnern umzusetzen.

Gerade in Robotik-Umgebungen mit vielen verteilten Rechnern sorgt dieser Ansatz dafür, dass Wartung nicht mehr Handarbeit ist – sondern planbar, reproduzierbar und vor allem deutlich entspannter.

Ansible

Ansible wurde 2012 von Michael DeHaan entwickelt und als Open-Source-Projekt veröffentlicht. 2015 wurde das Unternehmen Ansible, Inc. von Red Hat übernommen, das wiederum seit 2019 zu IBM gehört.

Es ist ein agentenloses Automatisierungstool – das heißt, auf den Zielrechnern muss keine zusätzliche Software installiert werden. Ansible verbindet sich einfach per SSH und führt die gewünschten Aufgaben aus.

Setup

Für dieses Tutorial brauchst Du einen Ubuntu-PC und einen Raspberry Pi mit einem installierten Ubuntu. Auf deinem Control-Rechner (also deinem PC) läuft Ansible und der SSH Client, auf dem Raspberry (also dem Remote-Rechner) muss der SSH-Server aktiviert sein.

Installation

Auf deinem Control-Rechner installierst du Ansible wie folgt:

sudo apt update
sudo apt install ansible
sudo apt install sshpass

Jetzt kannst Du testen, ob die Installation geklappt hat:

ansible --version

SSH aktivieren

Damit Ansible funktioniert, muss auf dem Raspberry aka Remote-Rechner SSH eingerichtet sein.
Probier mal im Terminal deines Control-Rechners aus, dich mit dem Raspberry zu verbinden:

ssh pi@192.168.178.50

Falls das nicht klappt, musst du SSH auf dem Raspberry aktivieren. Das geht ganz einfach über die raspi-config:

sudo raspi-config

Dann navigierst du zu “Interfacing Options” -> “SSH” und aktivierst den SSH-Server.

Projektordner

Auf deinem Control-Rechner legst du dir z.B. einen Projektordner an:

mkdir ~/ansible
cd ansible
touch hosts
touch ansible.cfg
touch update_pi.yml

Die Ordnerstruktur soll nachher so aussehen:

ansible/
├── hosts
├── update_pi.yml
└── ansible.cfg

hosts-Datei anlegen

In der hosts-Datei stehen die Rechner und ihre IP-Adressen bzw. ihre A-Records.

[raspberry]
pi1 ansible_host=192.168.178.66 ansible_user=<username>

ansible.cfg

Die ansible.cfg Datei ist die Konfigurationsdatei für Ansible.
Hier kannst du verschiedene Einstellungen vornehmen, z.B. den Pfad zu deiner hosts-Datei.
Ein einfaches Beispiel sieht so aus

[defaults]
inventory = hosts

Playbooks

Playbooks sind die Ansible-Äquivalente zu Skripten, sie beschreiben die gewünschten Zustände der Zielrechner.
Ein einfaches Playbook für die Updates des Raspberrys könnte so aussehen:

update_pi.yml

---
- name: Update Raspberry Pi
  hosts: raspberry
  become: yes

  tasks:
    - name: Update apt cache
      apt:
        update_cache: yes

    - name: Upgrade all packages
      apt:
        upgrade: dist

Im Detail

Ansible starten

Wenn du diese drei Dateien anegelegt hast, kann es auch schon losgehen

ping

Der ping-Befehl ist ein Testmodul von Ansible, das überprüft, ob der Host erreichbar und ausführbar ist.
Wenn du Passwort-Login benutzt musst du Ansible sagen, dass es nach einem SSH-Passwort fragen soll:
Das -k steht für –ask-pass

ansible -i hosts raspberry -m ping -k
SSH password:

Wenn alles funktioniert, solltest du folgenden Output sehen:

pi1 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}

Playbook starten

Jetzt zum eigentlichen Task:

ansible-playbook -i hosts update_pi.yml -k -K

Da wir sudu apt update / upgrade machen wollen, müssen wir auch das root-PW übergeben. Das machen wir mit dem Flag -K.
-K steht für –ask-become-pass, damit wird Ansible nach dem sudo-Passwort fragen.

Zertifikat-Login

Da wir aber nicht permanent die
Ansible unterstützt auch die Authentifizierung mit Zertifikaten, was sicherer ist als die Passwort-Authentifizierung.
Dazu musst du auf deinem Control-Rechner ein SSH-Schlüsselpaar generieren und den öffentlichen Schlüssel auf den
Zielrechner kopieren.

ssh-keygen -t rsa -b 4096 -C "@ansible-controller"
ssh-copy-id @192.168.178.66

Danach kannst du Ansible ohne Passwort verwenden, indem du einfach den Hostnamen angibst:

ansible-playbook -i hosts update_pi.yml -K

Weitere Beispiele

Ubuntu-Pakete installieren

Man kann natürlich auch andere Pakete installieren, z.B. git:

tasks: 
- name: Install git 
  apt: 
    name: git 
    state: present 
    update_cache: yes

Git Repository klonen

Auch das Klonen eines Git-Repositories ist mit Ansible kein Problem:

tasks: 
- name: Clone Git repo 
    git:
      repo: https://github.com/user/meinprojekt.git 
      dest: /home/pi/meinprojekt 
      version: main

Fazit

Ansible ist ein mächtiges Werkzeug, um die Wartung von Robotern zu automatisieren. Es ermöglicht dir, den Zustand deiner
Systeme zu beschreiben und automatisch umzusetzen, ohne dich manuell auf jedem Rechner einzuloggen. Gerade in Umgebungen
mit vielen verteilten Rechnern spart das enorm viel Zeit und Nerven.

The post So verwaltest du deine Roboter mit Ansible appeared first on Creatronix.

SCRUM wurde von Ken Schwaber und Jeff Sutherland entwickelt und ist ein agiles Framework für die Softwareentwicklung.
Es hilft Teams, komplexe Projekte zu managen und schnell auf Veränderungen zu reagieren.
SCRUM fördert die Zusammenarbeit, Transparenz und kontinuierliche Verbesserung.

Werte

Commitment, Focus, Openness, Respect, and Courage

Vorgehensmodell

Interativ & Inkrementell

Entwicklungszeitraum wird in Sprints unterteilt

Sprints

Dauer: 2-4 Wochen
Ziel: funktionierende Software nach jedem Sprint mit neuen Features die den Geschäftswert des Produkte maximieren

Messen der Velocity

• Velocity = Anzahl der Story Points, die in einem Sprint abgeschlossen wurden
• hilft bei der Planung zukünftiger Sprints

Rollen

Product Owner

Stellvertreter des Kunden und der Stakeholder
Der Product Owner ist verantwortlich für:

• Produktvision und Strategie
• Product Backlog erstellen und priorisieren
• Anforderungen verstehen, übersetzen und priorisieren
• Wert für das Produkt maximieren
• Stakeholder koordinieren

Er ist die zentrale Entscheidungsinstanz für das Produkt.

Scrum Master

• coacht Teammitglieder und Organisation
• verwaltet impediment backlog
• löst impediments auf
• moderiert Meetings mit dem Ziel, die Effizienz des Teams zu verbessern
• schützt das Team vor äußeren Störungen
• fördert die Einhaltung von Scrum-Prinzipien und -Praktiken

Scrum Team

• schätzt User Stories
• setzt Stories um
• arbeitet selbstorganisiert
• cross-funktional (Entwickler, Tester, Designer etc.)
• verantwortlich für die Lieferung von Inkrementen am Ende jedes Sprints

Artefakte

Inkrement

Neue Software, die am Ende eines Sprints fertiggestellt und potenziell auslieferbar ist.

Product-Backlog

• enthält User Stories mit Definition of Done (DoD) und Akzeptanzkriterien
• priorisiert nach Business Value
• dynamisch, wird während des Projekts angepasst

Sprint-Backlog

• alle Items für den Sprint, inkl. DoD und Akzeptanzkriterien
• Burndown / Burnup Chart für Fortschrittsverfolgung

Impediment-Backlog

Für Hindernisse, die das Team daran hindern, die Sprint-Ziele zu erreichen
Beispiele:

• CI Pipeline funktioniert nicht
• Zugang zu Testdaten fehlt
• API Dokumentation unvollständig
• Fehlende Hardware für Tests

Termine

Backlog Refinement (früher Backlog Grooming)

Zeitpunkt: 1-2 mal pro Sprint, oft in der Mitte des Sprints
Dauer: 1-2 Stunden
Ziel: User Stories mit DoD, Akzeptanzkriterien und Story Points versehen, damit sie für die Sprintplanung bereit sind

Planning Poker

Wie geschätzt wird, lässt Scrum offen, aber Planning Poker ist beliebt.
Jeder Teilnehmer erhält Karten mit Zahlen (z.B. Fibonacci-Folge: 1, 2, 3, 5, 8, 13)

Die Zahlen stehen für die Komplexität der Aufgabe von 1 – sehr simpel bis 13 sehr komplex.
Der Product Owner liest eine User Story vor, und die Teilnehmer schätzen gleichzeitig, indem sie eine Karte mit ihrer Schätzung hochhalten
Nach der Schätzung diskutieren die Teilnehmer, um ein gemeinsames Verständnis zu erreichen.

Sprint Planning

Zeitpunkt: Am Anfang eines Sprints
Dauer: 4-8 Stunden (je nach Sprintlänge)
Ziel: Sprint-Ziele festlegen, User Stories auswählen, die im Sprint bearbeitet werden sollen, und Aufgaben planen

Daily Standup

Zeitpunkt: Täglich, meist morgens
Dauer: 15 Minuten
Ziel: Mini-Retro: Awareness für erledigte und aktuelle Tätigkeiten, Impediments an Scrum Master kommunizieren

Sprint Retro

Zeitpunkt: Am Sprint-Ende
Dauer: 1-2 Stunden
Ziel: Reflexion über den vergangenen Sprint, Identifikation von Verbesserungsmöglichkeiten, Maßnahmen für den nächsten Sprint planen

Scrum but – Antipatterns

Wenn Scrum nicht richtig umgesetzt wird, können verschiedene Probleme auftreten, z.B.:

• Scrum Master ist nur ein Titel, aber keine echte Rolle im Team
• Product Owner ist nicht verfügbar oder hat keine Entscheidungsbefugnis
• Team arbeitet nicht selbstorganisiert, sondern wird von außen gesteuert
• Sprints werden nicht eingehalten, sondern ständig verlängert oder verkürzt
• Meetings werden nicht effektiv genutzt, sondern sind reine Zeitverschwendung
• Keine klare Definition of Done, was zu unklaren Anforderungen und Qualitätsproblemen führt
• Keine regelmäßige Retrospektive, was zu fehlender kontinuierlicher Verbesserung führt
• Keine klare Priorisierung im Product Backlog, was zu ineffizienter Arbeit und fehlendem Fokus führt

Quellen

https://scrumguides.org/scrum-guide.html

The post Alles, was Du über SCRUM wissen musst appeared first on Creatronix.

In Robotik-Projekten wird in den meisten Fällen mit einer Linux-Distribution wie Ubuntu gearbeitet, deswegen ist es von Vorteil, sich auch auf der Linux-Konsole aka shell auszukennen.

Die Standard-Shell ist meistens Bash (Bourne Again Shell). Viele ROS-Tools erwarten explizit Bash:

source /opt/ros/humble/setup.bash

Informationen über Kommandos

Mit dem Kommando man kann man sich Infos zu den Kommandos geben lassen:

man ls

Eine moderne Alternative ist tldr:

tldr ls

Du kannst es unter Ubuntu mit

sudo snap install tldr

installieren.

Datei-Handling

Benutzer & Rechte

Linux-Pakete & Versionsinformationen

Prozesse

Netzwerke

USB

The post Linux Shell Kommandos Cheatsheet appeared first on Creatronix.

Tests sind ein zentraler Bestandteil moderner Entwicklung. Das Framework pytest macht das Schreiben, Organisieren und Ausführen von Tests einfach, flexibel und leistungsfähig.

Tests schreiben und ausführen

Installation

Zuerst installierst du pytest mit:

pip install pytest

pytest ist kompatibel mit unittest-Tests und erfordert keine Testklassen.

Namenskonventionen

Damit pytest Tests automatisch findet, müssen Dateien und Funktionen bestimmte Namen haben:

• Dateinamen haben test im Namen
• Funktionsnamen beginnen mit test_

Beispiel:

def test_example():
    x = 5
    assert x == 5

Mit pytest im Terminal führt pytest alle passenden Tests aus.

Testauswahl

Du kannst gezielt Tests ausführen:

pytest test_module.py::test_function
pytest -k "keyword"

Optionen wie -v (verbose), -x (bei Fehler abbrechen) oder -s (print-Ausgaben anzeigen) sind sehr praktisch.

Um Optionen nicht immer per Hand eingeben zu müssen, können diese auch in einer pytest.ini angegeben werden:

[pytest]
pythonpath = .
addopts = -x --durations=0 -vv

Fortgeschrittene pytest-Techniken

Fixtures

import pytest

@pytest.fixture(scope="function")
def simple_fixture():
    return 42

def test_function(simple_fixture):
    assert simple_fixture == 42

Fixture scopes

pytest-Fixtures haben einen Scope, der bestimmt, wie oft eine Fixture erzeugt und wiederverwendet wird.
Der Standard-Scope ist function, d. h. die Fixture wird für jeden Test neu ausgeführt.

Weitere Scopes sind:

• class – einmal pro Testklasse
• module – einmal pro Datei
• package – einmal pro Paket
• session – einmal pro gesamtem Testlauf

Größere Scopes verbessern die Performance, bergen aber das Risiko von geteiltem Zustand zwischen Tests.
Daher gilt: so klein wie möglich, so groß wie nötig.

Setup and teardown

Mit pytest können wir klassische setup / teardown Methoden mit fixtures nachbauen

import pytest

def test_setup_and_teardown():
    assert True

@pytest.fixture(autouse=True, scope="function")
def setup_and_teardown():
    print("SetUp")
    # setup code goes here
    yield
    print("TearDown")
    # teardown code goes here

Parametrisierung

Mit Parametrisierung lässt sich derselbe Test mit verschiedenen Daten ausführen. So umgehst du Duplikate:

import pytest

@pytest.mark.parametrize("data, expected", [
    ([1], 1),
    ([1, 2], 1.5),
    ([1, 2, 3], 2),
])
def test_calculate_mean(data, expected_mean):
    mean = calculate_mean(data)
    assert mean == expected_mean

def calculate_mean(data):
    return sum(data) / len(data)

Das definiert mehrere Testinstanzen automatisch.

Marker

Marker helfen, Gruppen von Tests zu steuern.
Marker eignen sich z. B. zur Gruppierung nach Plattform, Kategorie oder Dauer.

Es gibt drei eingebaute Marker:

• skip
• skipif
• xfail

import pytest
import sys

@pytest.mark.skip(reason="Feature not yet implemented")
def test_future():
    pass

@pytest.mark.skipif(sys.platform == "win32", reason="Linux only")
def test_linux_only():
    pass

@pytest.mark.xfail(reason="Bug #123")
def test_known_bug():
    pass

Eigene Marker

import pytest

@pytest.mark.slow
def test_slow():
    pass

In pytest.ini:

[pytest]
...
markers =
    slow: mark slow tests

Dann kannst du testen mit:

pytest -m slow

Oder alle nicht langsamen Tests laufen lassen:

pytest -m "not slow"

Nahezu gleiche Vergleiche

Für Fließkommazahlen ist ein exakter Vergleich oft ungeeignet. pytest bietet das approx-Feature:

assert 2.2 == pytest.approx(2.3, 0.1)

Erlaubt eine Toleranz statt exakter Übereinstimmung.

Exceptions testen

Mit pytest kannst du das Auftreten von Ausnahmen elegant testen:

def test_zero_division():
    with pytest.raises(ZeroDivisionError):
        1 / 0

Das prüft, ob ein Fehler erwartet korrekt geworfen wird.

Test-Reporting & Coverage

Testabdeckung mit pytest-cov

Mit dem Plugin pytest-cov lässt sich messen, wie viel deines Codes getestet wird:

pip install pytest-cov

pytest --cov=my_app 10_app_test

Ergebnis: Coverage-Statistiken zeigen an, wie viele Zeilen getestet wurden.

HTML-Reports

Du kannst mit demselben Plugin HTML-Berichte erzeugen:

pytest --cov=my_app --cov-report=html

Eine visuelle Übersicht über die Abdeckung hilft bei der Analyse.

Integration mit Werkzeugen

Coverage-Daten lassen sich in Tools wie SonarQube einbinden:

pytest --cov-report=xml:coverage.xml

Dadurch kannst du Metriken in CI/CD-Pipelines oder Dashboards verwenden.

Assertions mit Hamcrest (optional, aber mächtig)

Neben den eingebauten assert-Anweisungen von pytest kann man auch Hamcrest verwenden.
Hamcrest ist eine Matcher-Bibliothek, die Tests lesbarer und ausdrucksstärker machen kann – besonders bei komplexen Datenstrukturen.

Installation

pip install pyhamcrest

Import in Tests:

from hamcrest import assert_that, equal_to

Warum Hamcrest?

Vergleich:

def test_hamcrest_assert():
    result = 42
    assert_that(result, equal_to(42))

Der Vorteil zeigt sich bei komplexeren Assertions:

def test_hamcrest_start_with():
    name = "Max Mustermann"
    assert_that(name, starts_with("Max"))

def test_hamcrest_has_length():
    items: Sized = ['apple', 'banana', 'cherry']
    assert_that(items, has_length(3))

Tests lesen sich mehr wie Spezifikationen.

Listen & Collections

from hamcrest import assert_that, has_items
from collections.abc import Sequence

def test_compare_list_of_items():
    actual_list_of_items: Sequence[str] = ['apple', 'banana', 'cherry']
    assert_that(actual_list_of_items, has_items("apple", "banana"))

Fazit

pytest ist ein einfaches, doch mächtiges Framework zur Testautomatisierung in Python. Es kombiniert:

• geringe Einstiegshürde – einfache Tests schnell geschrieben
• hohe Flexibilität – Marker, Parameter, Coverage
• gute Tools-Integration – HTML-Reports oder CI-Coverage

Damit eignet es sich sowohl für Einsteiger als auch für professionelle Test-Pipelines.

Code

https://github.com/jboegeholz/pytest_tutorial

The post Pytest Tutorial appeared first on Creatronix.