Aimbot für Moorhuhnjagd

Wieder einmal ist mir aufgefallen, dass das Spiel noch viel zu kompliziert ist, und weitere Vereinfachung not tut. Anstatt einer Auto-Simulation gibt es jetzt das beliebte Mohrhuhnjagd-Spiel. Das enthält noch weniger Aktionsmöglichkeiten und lässt sich hoffentlich leichter als Referenz-Implementierung für eine Künstliche Intelligenz umsetzen. Für den Anfang sieht man im Screenshot zwei Modi: einmal die normale Version ohne Head up Display und einmal die Version mit Headup Display. Der User kann zwischen beiden Modi umschalten.

Wie nicht anders zu erwarten war, ist die Version mit Head-Up-Display um einiges effizienter zu bedienen. Wenn damit der menschlicher Spieler interagiert, wird er mehr Moorhühner pro Sekunde erlegen als jemals zuvor. Die Features sind dort im Detail: einmal gibt es oben in der Statuszeile eine Positionsangabe in absoluten Pixeln, dann gibt es die Zahl der erfolgreichen Schüssen, die Zahl der misslungenen Schüsse, den Framecounter. Ferner gibt es noch einen Aimbot-artigen Kreis der sich verfärbt man in die Nähe des Ziels kommt und ganz wichtig gibt es noch eine Linie zwischen Ist und Soll Position so dass man immer weiß, in welche Richtung man die Maus bewegen muss.

Das Spielprinzip selber ist das gleiche, es geht darum, dass man das Fadenkreuz über das blaue Moorhuhn bringt und dann auf die Fire-Taste drückt. Der Unterschied ist der, dass die Variante mit eingeblendetem HuD zu einer besseren kognitiven Performance führt. Ich habe das jetzt nicht genau ausgerechnet, aber vermutlich wird egal wer das Spiel ausprobiert mit dem HuD einen höheren Punktestand erzielen, weniger oft daneben schießen und effizienter die Maus bewegen.

Jetzt fehlt nur noch die Variante 3, wo man zusätzlich zum Headup Display noch eine Automatik aktiviert, also eine Software, die das Fadenkreuz über das Ziel bewegt und automatisch abdrückt. Diese Automatik wäre dann die eigentliche KI, welche aller voraussicht nach die beste Performance erzielt, weil sie das Spiel 24/7 durchspielen kann und niemals einen Fehler macht.

Es gilt also zwischen 3 Modi zu unterscheiden: einmal das normale Moorhuhn-Spiel, dann die Version mit Headup Display und zuletzt die Künstliche Intelligenz mit Automatik-Zielvorrichtung. Wenn man direkt eine KI programmiert ohne zuvor den Modus mit dem Head-up Display wird es schwer bis unmöglich. Das heißt, man müsste sich er grundlegende Dinge überlegen, also das HuD vorwegnehmen. Einfacher ist es, wenn man zuerst das HuD implementiert und erst danach die KI programmiert.

Vielleicht fragt der eine oder andere: wozu das ganze? Zugegeben, Moorhuhnjagd ist nicht besonders anspruchsvoll, der Hauptgrund warum ich diese Domäne gewählt habe war, dass sie sich in unter 100 Lines of Code implementieren lässt. Man anhand dieses Beispiel aber gut erklären kann was ein HuD ist.

UPDATE
Soeben habe ich den dritten Mode “Auto” implementiert. Wenn man den aktiviert wird der Schriftzug “Auto” angezeigt und die KI setzt das Fadenkreuz auf das Ziel und drückt auf Fire. Das ergebnis kann sich sehen lassen. Pro Sekunde erzielt das System mindestens 5 Treffer. Man kann dabei zuschauen wie ein Treffer nach dem anderen durchgeführt wird. Unmöglich zu schlagen für einen menschlichen Spieler. Die KI agiert perfekt.

Wichtig zu erwähnen, dass man jederzeit auf den normalen Mode zurückschalten kann, also entweder ohne oder mit HuD. Das heißt, der Spieler hat die volle Kontrolle. Die KI selber ist lächerlich einfach, sie besteht aus zwei Befehlen:

self.mouse = self.myenemy.pos
self.fire()

Was die machen ist selbsterklärend. Es handelt sich um einen klassischen Aimbot, also ein System was zielt und feuert. Ausnahmsweise gibt es hier keine Möglichkeit die KI großartig zu verbessern, sie hat das Spiel im Griff, was damit zutun hat, dass Moorhuhnjagd ein sehr übersichtliches Spiel ist. Es ist jedoch vorzuglich geeignet um die Grundprinzipien von User-Interfaces zu erläutern. Also einen kompletten Entwicklungszyklus abzufilden, angefangen vom Programmieren des Spiels, über das Programmieren eines HuD bis hin zur Implementierung einer KI.

Obwohl der Automode die meisten Treffer pro Sekunde erzielt ist der HuD Mode am eindrucksvollsten. Weil in diesem Modus der Human-Operator in-the-loop verbleibt, das heißt er muss manuell den Cursor positionieren erhält aber Zusatzinformationen eingeblendet um effizienter zu werden.

Der Vollständigkeit halber folgt zum Abschluss dieses Kapitels der komplette Sourcecode.

import pygame, random, math, threading, sys

class Stats():
  def __init__(self):
    self.hits = 0
    self.failshots = 0

class Enemy():
  def __init__(self):
    self.pos = (200,100)
    self.width = 30
    self.height = 20
   
class Game():
  def __init__(self):
    self.screen = (600, 338)
    self.fps = 20  # 30 fps
    self.framestep=0
    self.white = (220, 220, 220)
    self.black = (0, 0, 0)
    self.grey = (150, 150, 150)
    self.red = (230, 0, 0)
    self.blue = (0, 0, 230)    
    self.mouse = (0,0)
    self.myenemy = Enemy()
    self.mystats = Stats()
    self.headupdisplay = "low"
    random.seed()
    pygame.init()
    self.window = pygame.display.set_mode(self.screen)
    for self.framestep in range(10000000):
      self.updateGUI()
      if self.headupdisplay=="middle" or self.headupdisplay=="high": self.hud()
      pygame.display.update() 
  def hud(self):
    # aiming
    radius = 50
    p1 = self.mouse
    p2 = self.myenemy.pos
    if self.incircle(p1,radius,p2): color=self.red
    else: color = self.black
    pygame.draw.circle(self.window, color, self.mouse, radius, 3) 
    pygame.draw.line(self.window, self.black, p1, p2, 1)
    # mouseposition
    myfont = pygame.font.SysFont("freesans", 16)
    text = str(self.mouse)+" "+str(self.framestep)
    label = myfont.render(text, True, self.black)
    self.window.blit(label, (220,30))
    # stats
    text = str(self.mystats.hits)+" "+str(self.mystats.failshots)
    label = myfont.render(text, True, self.black)
    self.window.blit(label, (220,50))
    if self.headupdisplay == "high": self.automode()
  def automode(self):
    # high
    myfont = pygame.font.SysFont("freesans", 16)
    text = "Auto"
    label = myfont.render(text, True, self.black)
    self.window.blit(label, (self.mouse[0],self.mouse[1]+20))
    # pos
    self.mouse = self.myenemy.pos
    self.fire()
  def updateGUI(self):
    pygame.time.wait(1000/self.fps)
    self.window.fill(self.white)
    self.inputhandling()
    # aiming
    offset=20
    p1=(self.mouse[0]-offset,self.mouse[1])
    p2=(self.mouse[0]+offset,self.mouse[1])
    p3=(self.mouse[0],self.mouse[1]-offset)
    p4=(self.mouse[0],self.mouse[1]+offset)
    pygame.draw.line(self.window, self.black, p1, p2, 2)
    pygame.draw.line(self.window, self.black, p3, p4, 2)
    # enemy
    pygame.draw.rect(self.window, self.blue, (self.myenemy.pos[0]-self.myenemy.width/2,self.myenemy.pos[1]-self.myenemy.height/2,self.myenemy.width,self.myenemy.height), 0) 
  def incircle(self,p1,radius,p2):
    """ checks if p2 is in circle """
    square_dist = (p1[0] - p2[0]) ** 2 + (p1[1] - p2[1]) ** 2
    return square_dist <= radius ** 2    
  def fire(self):
    if self.incircle(self.myenemy.pos,self.myenemy.width,self.mouse):
      self.mystats.hits +=1
      self.myenemy.pos = (random.randint(0,self.screen[0]),random.randint(0,self.screen[1]))
    else: self.mystats.failshots+=1
  def inputhandling(self):
    for event in pygame.event.get(): 
      if event.type == pygame.QUIT: sys.exit(0) 
      if event.type == pygame.MOUSEMOTION: self.mouse= event.pos
      if event.type == pygame.KEYDOWN:
        if event.key == pygame.K_1: self.fire()
        if event.key == pygame.K_2: 
          if self.headupdisplay == "high": self.headupdisplay = "low"
          elif self.headupdisplay == "low": self.headupdisplay = "middle"
          elif self.headupdisplay == "middle": self.headupdisplay = "high"
      
if __name__ == "__main__":
  myGame = Game()

git graph

Mein neues Lieblingsspielzeug aktuell ist git. Rein von der Größe her ist das Package mit 20 MB relativ leicht. Dennoch enthält das Kommandozeilen-Tool eine Reihe von interessanten Features. Git ist so eine Art von Textadeventure für Erwachsene. Viele denken bei git an github, also an social coding. Aber noch sehr viel interessanter wird es, wenn man git standalone einesetzt auf seiner lokalen Festplatte. Man kann damit sehr übersichtlich komplexe Projekte durchführen, so ähnlich wie das Konzept der objektorientierten Programmierung nur sehr viel weitreichender. Im wesentlichen führt git dazu, dass man anders programmiert. Man lernt wie man sich Sourcecode leichter memorieren kann, und man verzichtet darauf, Programmstrukturen zu erstellen. Damit ist gemeint, dass die Arbeitsstruktur mit git üblicherweise darin besteht, dass man das bestehende kaputt macht. Also wesentlich schneller bereit ist, umfangreiche Änderungen am Code vorzunehmen. Einerseits betrifft das das löschen von auskommentiertem Code, meint aber auch, dass man das Projekt sehr viel aggressiver weiterentwickelt als ohne git.

Hier mal das Beispiellog von einem Robotik-Projekt. Man sieht darin zweierlei: erstens wird jede Aktion am Sourcecode eindeutig mit einem SHA1-Hash-Wert versehen und zweitens sind die Commits untereinander gegliedert, bilden also eine Hierarchie ähnlich wie das Inhaltsverzeichnis eines Texte. Das ganze ist vergleichbar mit einer Todo Liste bestehend aus Tasks und Subtasks, nur rückwirkend weil die Liste schon abgearbeitet wurde.

Ganz am Anfang habe ich noch alle Commits brav in Master hineingeschrieben weil mir Branches noch als zu komplex erschienen. Später habe ich dann vorsichtig zuerst mit einem Development-Branch und später dann auch mit Features Branches gearbeitet.

*   4d2063c (HEAD, master) - legs animation - simple pathplanner
|\  
| * dbf2665 pathplanner for navmesh
| * 7b1a482 pathplanner
| * 227f4b3 improved cyclic fegs
| * 3fc33fd cycling legs
| * 39a5300 framecounter
| * 9371e8a legs
| * bb45697 second path
* |   1609081 lane changing
|\ \  
| |/  
| * 4ae6ca2 move on lane
| * 6872f02 moving at lane
| * 02be8e0 lane class
| * 2c22e99 lane
| * daa4dd8 path + edges
| * eb48f91 steering
* |   4449ef5 rotate triangle: former circle car is replaced by triangle shape. The new triangle can rotate smooth and move to a goal.
|\ \  
| |/  
| * b654077 complex move
| * eb3705f smooth rotation
| * 262257b rotate to mouse
| * a6c6284 improved triangle car
| * f26fd5d rotate point from triangle
| * 943df72 triangle car
* |   613d61e path follow + lyx dokumentation, merge branch 'development'
|\ \  
| |/  
| * ad9999a lyx doku import
| * d12af80 path
* |   9c8b7f0 Merge branch 'development' issue: waypoints
|\ \  
| |/  
| * 0841ee0 task follow
| * 16c20d3 waypoint class
| * 9257764 moveright/left
|/  
*   20a36d9 Merge branch 'followpoint'
|\  
| * caaa4fa minor
|/  
* e8bb9b1 minor changes
* d9e8443 moveto angle
* 0f05c40 better mouse follower
* f2b740e distance
* 9c09559 documentation
* 044d915 show point
* c01927d frame pause
* da3a2b0 textmenu
* fa2248b pygame gui
* 1058153 alles geloescht
* 397a728 (tag: v1.0) reset to old version without objects
* ab7de1e problems with parent object
* ba813d0 robotid as parameter
* 9733e36 threading
* bc1141b dual robotid
* ee2c186 remove task
* c250015 Import
* 396c272 for
* 0470c22 world hinzugefügt

Zur Veranschaulichung noch eine Abbildung aus der gitk GUI:

Für Außenstehende dürfte es reichlich konfus wirken. Aber übersetzt steht da, dass es einmal den Master-Branch gibt, welcher funktionsfähigen und getesten Code enthält. Also das was gedacht ist für den Endverbraucher. Von diesem Master-Branch gibt es einen Spinoff, genannt Development der schon etwas progressiver d.h. aggressiver ist. Dort wird an neuen Dingen gearbeitet. Und von diesem gibt es noch eine weitere Abspaltung, genannt issue/pathtomouse wo an einem sehr experimentellen Detail gearbeitet wird, was aktuell noch überhaupt nicht funktioniert, und das ganze Programm zum Absturz bringen kann. Gewissermaßen hat man also beides: eine penible Übersicht und Raum für Chaos. Einmal beim Kommentar „Not working“ habe ich sogar nicht-funktionsfähigen Code eingescheckt. Das wurde dann aber eine Iteration später wieder korrigiert. Es ging damals konkret um ein Stopschild für die Autosimulation, was irgendwie nicht das gemacht hat, was es sollte.

Die erfahrenen git-User werden sagen, dass die obige Abbildung noch eine von den leichteren ist, und das sie mehrere issue-Branches parallel bearbeiten, die noch dazu von mehreren Leuten verändert werden. Nun, damit kann ich aktuell nicht dienen, ich bin noch ein git-Einsteiger.

Ist Eclipse tod?

Früher habe ich relativ viel mit Eclipse gearbeitet, weil das Werkzeug allgegenwertig war und das Syntax-Highlighting akkurat funktioniert hat. Doch Eclipse besitzt eine Reihe von Nachteilen. Einer ist, dass andere Programmiersprachen außer Java nur schwer einzubinden sind. Für C++ oder Python muss man eigene Plugins installieren, was manchmal schiefgeht und in jedem Fall weitere Konfiguration nach sich zieht. Aber den absoluten Fail mit Eclipse erlebt man, wenn man sich mit Egit beschäftigt, einem Plugin um git Repositories zu verwalten. Das ist wohl die umständlichste Software, der ich jemals begegnet bin, wie damit jemand produktiv arbeiten kann ist mir ein Rätsel. Wer sich selber ein Bild machen möchte, kann sich die Tutorials bei Youtube ansehen. Allein das simple erzeugen eines commits ist bereits ein Kraftakt, von komplexeren Dingen wie „git blame“ oder Branching will ich lieber nicht wissen, wie man das in Eclipse macht.

Kurz gesagt, ich glaube dass die Eclipse IDE der grundsätzlich falsche Ansatz ist. Selbst wenn man in Java programmiert gibt es andere Tools die besser geeignet sind. Hinzu kommt, dass der Umfang des Downloads und die Bootupzeit von Eclipse beträchtlich ist. Ich will nicht behaupten, dass die Geany IDE die beste aller Entwicklungsumgebungen ist, sondern generell würde ich leichte Texteditoren oder leichte IDEs bevorzugen. Wo also lediglich Syntax-Highlighting, vielleicht noch Autocomplete und ein Config-Menü um den Compiler aufzurufen enthalten ist, der Rest dann aber fehlt. Insbesondere das extrem komplexe git lässt sich über die Command-Line am einfachsten bedienen. Man kann sich eine kleine Textdatei schreiben, wo man die 10 wichtigsten git Befehle die man regelmäßig verwendet aufführt und kommt damit am schnellsten zum Ziel.

Git und die Merge-Konflikte

Wenn man alleine am Sourcecode arbeitet, ist git sehr simpel zu bedienen. Es kommt niemals zu merge-conflikten. Es sei denn man verändert mit Absicht zwei Zweige nur um zu sehen wie das geht mit dem mergen. Wer jedoch git in richtigen Projekten einsetzt wo mehr als 1 Entwickler am Code arbeiten sind Merge-Conflikte der Normalfall. Im Grunde gibt es mit git nur an diesem Punkt echte Probleme. Das heißt, es gibt eine Meldung wie „Conflikt“ und plötzlich ist unklar wie es weitergeht. Ja, manch einer fragt sich ob git an sich vielleicht das Problem ist und welche Alternativen dazu in Betracht kommen. Ein wenig näher mit Merge-Conflikten beschäftigt hat sich https://team-coder.com/avoid-merge-conflicts/ Dort wird gleich im Tipp 1 verraten wie man das Problem entschärft, und zwar indem man einen Branch möglichst schnell wieder mit Master zusammenmergt. So nebenbei geht aus der Abbildung auch hervor was die eigentliche Stärke von git ist und warum es trotz aller Probleme einen Siegeszug um die Welt angetreten hat. In der Abbildung wird gezeigt, wie auf einem Master Strang zwei Entwickler gleichzeitig arbeiten, die asyonchron den Sourcecode bearbeiten. Das erinnert ein wenig an einen Patienten der auf dem OP Tisch liegt und jetzt sitzen 2 Doktoren darübergebäugt und operieren parallel. Wenn alles klappt sind sie doppelt so schnell damit fertig und der Patient ist wohlauf.

Jetzt stelle man sich vor, man wollte das gleiche ohne Versionsverwaltung machen. Ein alternativer Arbeitstil könnte so aussehen, dass bei Google jemand neu ins Team kommt, gleichmal den kompletten Sourcecode auscheckt, und dann den anderen 10000 Entwicklern erzählt, dass der Code jetzt eingefroren ist, und das keiner sonst außer er die Dateien bearbeiten darf (setzen eines Update-hooks um den Codefreeze durchzudrücken). Er zieht sich dann mit dem Code zurück ins stille kämmerlein, probiert dort 14 Tage herum und beim Einspielen fällt dann auf, dass erstens die anderen Entwickler für 14 Tage blockiert waren und nebenbei die Änderung auch nicht funktioniert. So ungefähr sieht der Workflow ohne git aus.

In der Ratgeberliteratur zu git wird manchmal das Kommando „cherry picking“ als mögliche Alternative zu einem merge empfohlen. Dabei vermeidet man den merge und stattdessen holt sich der Teamleiter einen benötigten code-snippet aus einem Feature Branch ab. Nur leider ist das nicht die Lösung. Weil ja der Teamleiter nicht selber programmieren will sondern er will, dass das Mergen durch die Programmierer durchgeführt wird. Dadurch kann man Probleme den Leuten selbst anlasten. Wie kann man sich das praktisch vorstellen mit einem Merge-Conflikt? Das Problem ist relativ gut im wikipedia-Universum erforscht, und bedeutet, dass zwei Leute zur selben Zeit einen Text editieren und auf submit klicken. Erstaunlicherweise sind diese Konflikte selten bis extrem selten. Vielleicht ein konkretes Beispiel: Am Montag kopiert man sich einen Wikipedia Artikel auf die lokale Festplatte um ihn zu überarbeiten. Damit lässt man sich eine Woche Zeit und kopiert den Text am Sonntag wieder ins Upload Fenster hinein. Sollte in der Zwischenzeit jemand die selbe Idee gehabt haben, gibt es ein Problem. Erstaunlicherweise ist dieser Fall sehr unwahrscheinlich. Offenbar verteilen sich die Wikipedia-Edit-Wünsche gleichmäßig auf alle Artikel, so dass man hunderte Artikel bearbeiten kann, ohne je zur selben Zeit mit jemand anderes ins Gehege zu kommen. Und selbst wenn es zu Doppelbearbeitungen kommt, kann man diese mit simplen Mausklicks aus der Welt schaffen.

Ungefähr so ähnlich muss man sich auch git vorstellen. Im Normalbetrieb kann man 95% der Commits/Merges auf den Master Branch einchecken ohne dass da was schiefgeht. Das geht besonders dann, wenn die Contributer sich an den Standard halten und nicht zu lange damit warten. Und selbst wenn per Zufall dochmal zwei Leute die selbe Zeile verändert haben, lässt sich das relativ leicht beheben. Die Vorteile die sich ergeben sind immens. Man kann hunderte Leute gleichzeitig am selben code arbeiten lassen. Ein codefreeze wird überflüssig, vielmehr editiert jeder das was ihm Spaß macht.

Zum Thema Merge-Konflikte kann man noch mehr sagen. Angenommen, man hat generell schlechte Erfahrungen damit gemacht, selbst dann sollte man weiterhin git nutzen. Wenn man in einen Merge-Konflikt läuft kann man einfach nachdem die Fehlermeldung auftauchte den Kopf in den Sand stecken. Das heißt, man liest die Fehlermeldung, weiß nicht was zu tun ist und macht dann gar nichts mehr. Das git Projekt und insbesondere der Master Zweig bleiben intakt. weil der abgebrochene Merge bedeutet, dass das Projekt so weiterläuft wie bisher. Also andere die mehr Glück haben ganz normal mergen können. Man selber kann seinen Branch einfach löschen, nochmal auschecken und nochmal sein Glück versuchen. Wirklich falsch ist dieser Stil nicht, ganz im Gegenteil, git selber kann man gar nicht kaputt machen.

Parallelentwicklung
Wie mehrere Programmierer gleichzeitig am Code arbeiten weiß auch https://www.quora.com/How-do-multiple-programmers-work-on-the-same-project-at-the-same-time dort heißt es:

„Version systems simply track history – they don’t prevent conflicts. The good development process prevents conflicts!“

Folgerichtig wird dann weiter unten empfehlen, den Code in Untereinheiten aufzuteilen und die den Teams zuzuweisen. In der Tat, ein nützlicher Vorschlag, der erfrischenderweise nichts mit der Bedienung von git zu tun hat. Wenn es umgesetzt wird, kann man sich git merge Konflikte sparen.

Jemand anderes weiß zu berichten:

„Typically, you won’t have multiple people working on precisely the same module or function, though.“

Anders gesagt, wenn git einen merge Conflikt meldet, hat man vorher in der Projektorganisition schon etwas verkehrt gemacht weil man mehrere Leute an die selbe Aufgabe gesetzt hat. Weiten unter wird noch erläutert, dass auf täglichen Scrum-Meatings solche verantwortlichkeiten festgelegt werden. Auch das hat nichts mit dem eigentlichen Version control System zu tun sondern ist Teil der Projektorganisation.

Git Branches zur Projektverwaltung

In einem früheren Posting https://trollheaven.wordpress.com/2017/07/23/git-probleme-mit-branches/ habe ich Unverständnis gegenüber den git Branches gezeigt. Inzwischen weiß ich, was man damit sinnvolles anfangen kann. Die Vorteile liegen weniger in der Programmierung als solche (die geschieht bekanntlich in einer IDE) sondern Branches werden benötigt um ein Projekt zu strukturieren. Manchmal werden Issue-Tracking-Systeme wie Jira als zentrales Element eines Workflows definiert, doch das eigentlich Kernelement ist git. Vielleich ein kleines Beispiel: Angenommen, ein Projekt besteht aus 10 Leuten. Einer ist der Leiter, 3 Programmierer, 3 Grafiker und 3 Leute für die Dokumentation. Die 10 Leute sind pünktlich um 8 Uhr morgens im Büro, rasiert sind sie auch schon, da kann die Arbeit ja losgehen. Doch wie verteilt man die Arbeit jetzt auf die Personen? Mittels git Branches natürlich. Man erstellt mehrere Branches: Development, Programming, Documentation, Graphics. Die Teammitglieder dürfen nur auf ihre Branches mergen und auf den Hauptbranch und den Development-Branch hat nur der Projektleiter Zugriff. Gleichzeitig hat jeder Lese- und Schreibrechte auf alle Projektordner. Einerseits gibt es also eine klare Hierachie auf der anderen Seite ist das System komplett chaotisch. Diese Komplexität wird über git, die Commits und die Merges erzielt. Schaut man sich das System näher an, stellt man fest dass es ausgezeichnet geeignet ist zur Durchführung von Projekten. Der Vorteil gegenüber einem reinen Ticket/Issue-Tracker besteht darin, dass zusätzlich auch das Dateisystem getrackt wird.

Als besseres Netzwerk-Dateisystem würde ich git dennoch nicht beschreiben wollen. Sondern git ist eher ein Management-Tool um Leute zu führen, vergleichbar mit einem Zeiterfassungssystem. Es ist weniger eine Software sondern mit Verweis auf Scrum und Agile Development auf den Menschen fokussiert.

Rückblickend wird vielleicht git und nicht der Linux-Kernel als die wichtigste Leistung von Linus Torvalds gelten. Und zwar, weil man mit git einiges mehr machen kann als mit Linux. Linux ist nur ein Betriebssystem, es ist ein gut gemachter Unix Clone. git hingegen ist ein Meta-tool, man kann damit sowohl Betriebssysteme entwickeln, kann es aber auch für Spieleprogrammierung einsetzen. Was Linux ist, werden die meisten Informatiker inzwischen verstanden haben. Aber was git ist, das weiß niemand. Es wird bestenfalls sporadisch genutzt, das volle Potenzial ist noch längst nicht ausgereizt.

Wie man git bloßstellt

Das hier ist das Trollheaven Blog. Das heißt, die unterschwellige Zielrichtung besteht darin, Dinge bloßzustellen, sie also lächerlich zu machen. git gilt unzweifelhaft in der Software-Entwicklung als heiliger Gral. Nur zu gerne würde ich meinen Spott darüber ausgießen und mich über die User die es einsetzen lustig machen. Doch nachdem ich einiges über git erfahren habe, muss ich zugeben derzeit keine echte Schwachstelle gefunden zu haben. Klar, man könnte git mit mercurial vergleichen um herauszuarbeiten dass letzteres besser ist. Doch eigentlich ist der Unterschied nicht besonders groß. Sondern wenn man git kritisieren wollte, müsste man das Prinzip der Versionsverwaltung an sich attackieren. Das jedoch funktioniert nicht, weil es zuviele Vorteile hat. Wenn man bei git Schwächen entdeckt dann haben diese üblicherweise damit zu tun, dass man selber mit dem System noch nicht vertraut ist. Hier hilft es, sich einzulesen und man wird erkennen wie man die Probleme löst. Doch woran ich interessiert bin sind eher grundsätzliche Schwächen. Leider habe ich keine gefunden.

Das einzige, was mir jedoch aufgefallen ist, ist das trotz git viele Softwareprojekte scheitern. Es gibt auf Youtube auch ein Video mit dem Titel „how to fail an agile project“ dorin wird erläutert, wie man ein git-System aufsetzt, die Leute fleißig commiten lässt, sich alle mit git anfreunden und trotzdem das Projekt nichts wird. Tatsächlich ist dieser Fall gar nicht mal so selten. In einem Chaosradio Express Vortrag hat beispielsweise mal jemand erzählt, dass er sein InDesign Projekt mit git durchführt. InDesign dürfte die falsche Entscheidung sein, vermutlich scheitert auch das Projekt. Und nach meiner Recherche wird neuerdings auch Microsoft Windows mit git entwickelt und Adobe setzt es auch für den Flash-Player ein. Kurz gesagt, man findet erstaunlich viele projekte die git nutzen aber trotzdem scheitern. An git liegt es vermutlich nicht. Nach meiner Recherche ist das der Gold-Standard zur Softwareentwicklung. Sondern offenbar gibt es noch mehr zu beachten als einfach nur die Versionsverwaltung.

Am ehesten lässt sich git vergleichen mit der fließband-Produktion in der Automobilindustrie: es erhöht den Automatisierungsgrad, lässt aber noch genug Spielraum für menschliche Fehler. Damit ist gemeint, so ähnlich wie ein Autohersteller der auf Fließbandproduktion setzt, Fehler bei der Montage machen kann, könnte git Anwender Fehler bei der Software-Entwicklung machen. Das heißt konkret, dass der Zeitrahmen überschritten wird, dass die Software bugs enthält, dass nicht alle Anforderungen erfüllt werden, dass es zu teuer wird. Der Nachteil von git ist, dass es keine vollautomatische Software-Entwicklung ermöglicht. git-Projekte sind hochgradig abhängig von konkreten Programmierern. Man kann sich das ganze vorstellen als wenn man Maler im Akkord Malen lässt. Wenn sie nicht malen können, wird das Ziel nicht erreicht.

Aber wirklich git anlasten kann man dies nicht. Im Grunde muss man git vergleichen mit dem wie es davor war, und das ist eine massive Verbesserung. Irgendwann wird auch git abgelöst werden, durch etwas besseres. Vielleicht durch einen aufgerüsteten IBM Watson Computer der Teile des Sourcecode automatisch generiert, indem er Volltextdatenbanken auswertet. Das wäre dann in der Tat eine Methode git zu hinterfragen. Weil man damit den menschlichen Faktor weiter aus dem Produktionsprozess herausnehmen könnte. Aktuell ist mir jedoch keine solche Meta-Software bekannt. Vermutlich wird die Informatik mit git noch eine lange Zeit arbeiten müssen / dürfen.

Git wird seit 2016 von Microsoft eingesetzt. Das hat der Konzern eigenhändig in seinem Blog bekannt gegeben. Damit hat git das vorher verwendete Perforce-ähnliche System (Source Depot) ersetzt. Mag Linux eine Nischensoftware sein, die sich nur dort verbreiten konnte wo Unix in Verbindung mit OpenSource gefragt ist, hat git es geschafft auch im Bereich Microsoft Windows plus closedSource vorzudringen. Vermutlich deshalb, weil sich git mit beliebigen Programmiersprachen und beliebigen Firmenphilosophien kombinieren lässt. Und vermutlich auch, weil es in eine Nische vordringt wo es entweder gar nichts gab oder nur sehr schlechte Lösungen. Denn mal ehrlich, wer hat vor git mit einem Versionscontrol-System gearbeitet. Klar, das Polytron Version Control System (PVCS) gab es schon in den 1990’er Jahren und mit etwas suchen findet man auch zeigenössische Artikel dazu. Anders als eine Programmier IDE hat sich Verisonskontrolle jedoch nie so recht durchsetzen können.

ERFOLGSREZEPT
Nach wie vor ist unklar, was das Erfolgsrezept von git ist. Wedet man die Software richtig an, reichen eigentlich zwei Befehle aus: „git commit“ und „git merge“. Aber offenbar sind die Auswirkungen auf das Sofware-Engineering gewaltig. Vielleicht nochmal der Vergleich mit dem Fließband. Rein vom technischen her ist die Erfindung simpel: man benutzt einen Elektromotor um ein Förderband anzutreiben. Theoretisch kann man sogar über eine Handkurbel das Band am laufen halten. Die organisatorischen Auswirkungen sind jedoch immens. Das Fließband führt dazu, dass die Arbeiter sich plötzlich wie Roboter verhalten, also den ganzen Tag die selben Bewegungen ausführen. Den selben Effekt produziert auch git. Es führt dazu, dass plötzlich Kurse durchgeführt werden, wo ernsthaft darüber diskutiert wird, ob man 20 oder vielleicht 30 Branches benötigt. Mit Programmieren hat das wenig bis gar nichts zu tun, sondern es geht um Projektmanagement, die eigene Rolle in einem Team und um Scrum. Die naheliegenste Erklärung für git lautet, dass git wie ein Vokabeltrainer dafür sorgt, dass die Programmierer ihren Sourcecode auswendig lernen. Für Microsoft bedeutet es, dass die Programmierer plötzlich anfangen, die gesammten 100 GB an Sourcecode zu memorieren. Sich also jede einzelne Codezeile ins Gedächtnis holen und zwar über die Zeitachse des Entstehens hinweg. Um git zu verstehen muss man so denken wie git. Und das heißt, man ist auch ohne PC in der Lage sich ältere Versionsstände zurückzuholen, Merge-Diffs anzulegen und einen Entwickler-branch nach vorne zu bringen. Anders gesagt, wenn man git einsetzt wird man sich dessen bewusst wo die eigenen Ineffizienzen liegen und versucht diese zu überwinden. so ähnlich wie man auch an einem Fließband versucht, sich der Maschine anzupassen, also auf überflüssige Bewegungen zu verzichten um schneller arbeiten zu können. Vermutlich wird git plus Scrum langfristig dazu führen, dass die Programmierer sich selbst überfordern. Also dem gesteigerten Tempo nicht gewachsen sind und Krankheiten wir Burnout entwickeln.

Git ausreizen

Aktuell wird git in den meisten Projekten gar nicht ausgelastet. Sowohl der Linux Kernel als auch die meisten Web-Projekte bei denen git zum Einsatz kommt bestehen aus überschaubaren und leicht zu wartenden Programmen. Denn mal ehrlich: wie kompliziert ist es, einen Linux-Kernel zu programmieren oder ein Webframework? Beides sind Dinge die ziemlich gut verstanden wurden, und wo die wissenschaftliche Informatik alles im Detail erforscht hat. Diese Projekte sind aus einem anderen Grund interessant. Und zwar wird git dort eingesetzt, weil man dann noch genug Freiraum hat über die Versionsverwaltung als solche zu berichten. Im Grunde ist Linus Torvalds mit seinem Kernel und den paar Dateisystemen darin gar nicht ausgelastet. Das Pflegen des Codes ist für ihn eine Fingerübung. Genauso wie die meisten Java Projekte, welche in Unternehmen durchgeführt werden. Aber, aus dieser Ecke kommen dann die ersten Erfahrungen, in Bezug auf den Einsatz von git. Wirklich anspruchsvolle Programmierprojekte wären Dinge wie Robotics, Künstliche Intelligenz, Sprachverarbeitung usw. Um dort ebenfalls auf git umzustellen bedarf es eine halbwegs reichhaltige Ratgeberliteratur. Das jedoch sind die Projekte die wirklich von einem verteilten Version-Control-System profitieren würde. Weil das Projekte sind, wo nicht klar ist, wie der fertige Code aussehen soll, wo es eine gute wissenschaftliche Grundlage nicht gibt und wo Programmieren sich nicht als Tagesgeschäft abwickeln lässt.

Natürlich kann man simple Programmierprojekte wie das Schreiben einer Java-GUI oder das Programmieren einer WordPress-Präsenz mit git durchführen lassen. Aber das sind Übungsprojekte, mehr nicht. Auch ohne git kann man solche Projekte durchziehen, weil im wesentlichen klar ist wohin die Reise geht. Eine Java-GUI zu programmoieren ist kein Moonshot Projekt wo erstnoch die Grundlagen erforscht werden, sondern es gibt schon hunderte Beispiele woraus hervorgeht wie es gemacht wird. Schaut man sich existierende git Projekte an, so werden sie überwiegend für solche einfachen Dinge verwendet. Der Grund ist, dass man zwei Dinge aufeinmal machen muss: erstens, das Projekt voranbringen und sich zweitens in git einarbeiten. Wenn man ohnehin weiß, wie man eine Java-GUI programmiert, bleibt umso Zeit sich um die Feinheiten des Branchen und Mergen zu kümmern. Und wie man den zahlreichen git Tutorials entnehmen kann, kommt das Gros der Autoren aus diesem Bereich. Das heißt, git wurde zuerst für jene Projekte eingesetzt, die als wenig anspruchsvoll gelten.

Spannend dürfte die zweite Generation von Git Projekten werden. Wo also im Prinzip klar ist, was die Vorteile sind und wie man das System bedient und man jetzt versucht, damit Roboterprojekte wie die Robocup Challange durchzuziehen. Es gibt zwar schon erste Versuche, so hat das Team IHMC bei der Darpa Challange Jira eingesetzt um agile Programmierung zu realisieren, aber das ganze steckt noch ganz am Anfang. Robotik-Projekte die nach der Scrum Methode inkl. git realisiert werden, sind derzeit die absolute Ausnahme. Aber genau in diesem Segment dürfte git seine Stärken voll ausspielen können. Weil Robotik-Projekte sehr komplex werden könnnen und man dort die volle Leistung wirklich benötigt. Hier https://vimeo.com/142149253 gibt es einen Vortrag von der Roscon welcher im Ansatz Projektmanagement für Robotik-Programmierung erläutert. Das ganze ist kein richtiger git Vortrag und das Niveau ist eher schlecht. Zumindest aber wird git auf einer der Folien erwähnt.

Wenn man das Projektmanagement straffen würde, git sehr viel dezidierter einsetzt, dann ließe sich damit die Robotik-Programmierung voranbringen. In dem Sinne, dass man dann echte Roboter vorweisen könnte, die kontinuierlich weiterentwickelt werden. Also mit einem Entwicklungsryhtmus wie heute der Linux-Kernel alle 2 Monate ein Update erhält. Die Integration von git in die Robotics-Community ist eine Aufgabe für die Zukunft.