 Okay, willkommen zum Vortrag über GPEDA. Keine Sorge, nicht politisch, hat nichts mit PG da zu tun, es ist wirklich Zufall. Das ist das Git Performance Dashboard. Das ist einer von diesen typischen G-Band-Vorträgen. Irgendwer hat einen persönlichen Scratch geit, ne Annoseum, itch gescratcht und erzählt es darüber. Vielleicht findet ihr das Tool auch interessant. Welches Problem wollte ich lösen? Ich hatte Code, in dem Fall nix Großes, einen Haskell-Compiler, also den Haskell-Compiler. Und ich hatte Performance-Daten. Und zwar schön, für jeden Kommitt kann man mal reinschauen. Jetzt hier nicht mit dem Compiler, sondern mit einem kleinen Beispiel. Ich habe hier ein Repository, das enthält ... Das ist nicht das Richter, was wir im Moment ... Ich habe ein Repository, das enthält einen namens Tweets. Das sind alle möglichen Tweets mit GPN16 drin. Dieses Repository wird gerade mehr oder weniger automatisch befüllt mit neuen Tweets. Also wenn ihr jetzt was tweeten wollt, nehmen her, dann taucht es irgendwann auf. Und in diesem Repository, für dieses Repository habe ich Benchmarks. Benchmarks können jetzt erst mal an Sachen denken, die irgendwie Zeit messen, aber irgendwelche Metrigen über den Code. Es könnte jetzt Performance sein, aber gut, wir haben ja keinen Code, den wir aussehen können. Ich habe aber hier so ein Programm, das mir ein paar Statistiken liefert für über diese Tweets. In dem Fall, wie oft kommt Gulasch vor, wie oft kommt Junk vor, wie oft kommt Conny vor, wie oft kommt Knoblauch vor, keine Ahnung, wie oft solche Ideen kommt, dass man nach diesem Wort sucht. In der Schlafe gibt es auch selten als Gulasch. Tweets gesamt zahlt, zahlen sie noch falsch, weil das ist irgendwie reingedammt und Tweets mit wehren Zeilen werden mehrfach gezählt und wie auch immer. Aber wir haben jetzt so das Statistiken. Das ist was ich jetzt gegeben habe. Also ich habe, ich habe jetzt diese Daten für ganz viele Commits. Verzeichnis mit, heißt es Logs. Da sind ganz viele solche Log-Dateien drin. Und jedes von diesen hier, Enthältes Statistiken. So, was ich haben möchte, geht nicht, oder? Okay. Und was ich jetzt haben möchte, ist, dass irgendwie schön dargestellt. So, und das Problem löst die Peter. Nicht mehr, nicht weniger. So, wie sieht das aus? Also ich habe jetzt hier in einem Verzeichnis, einmal dieses Zeigendes Log, was wir gesehen haben. Das enthält einfach eine Datei pro Commit. Wo die herkommt, ist jetzt nicht mein Problem. Das könnte ein einfaches Best Script sein. Es könnte eine riesen Jenkins-Instation sein. Ihr könnt es vielleicht in Travis reinhauen. Oder ihr könnt ein Tool würzen, was im zweiten Teil des Vortrags von Stefan vorgestellt wird. Aber was jetzt irgendwie so von wegen Modularität dann getrennt gehalten wird. Also ich zeige euch zu sagen, den Weg, das zu Fuß zu machen. So, ich habe dieses Verzeichnis. Das legt irgendwo hin, mit dem Namen Logs. Ihr habt weiterhin dann gleich ein Verzeichnis, das Repository, weil irgendwo müssen die Daten herkommen. Repository selbst ist jetzt hier ein Bear Repository. Also das müsst ihr nicht ausdecken. Das langt so ein Git BearClone. Und da sind die ganzen Git-Daten drin. Und dann braucht ihr noch eine Konfiguration zu teilen. Das ist in dem Fall live, dann sieht man nix. Eine einfache Gamble Datei. Da kann ich ein paar Meter Daten angeben. In dem Fall gebe ich an, wir heißen meinen Projekt hier. Dann kann ich hier so links angeben, wie er auf GitHub verlinken soll. Falls ihr nicht bei GitHub sein soll, könnt ihr andere Sachen eintragen. Oder auch zusätzliche Informationen zu euren Commits. Das sehen wir gleich beim GAC Beispiel. Pandereoption. Und dann könnt ihr noch die Benchmarks beschreiben. Zum Beispiel kann das Tool nicht raten, ob jetzt kleinere Zahlen besser sind oder größere Zahlen. Das ist je nach dem, was ihr messt, mal so und mal anders. Also sagt ihr, okay, meine Benchmarks, diese Regeln hier gelten für alle Benchmarks. Einfaches Globbing. Veränderungen von Größe 1% sind spannend. Kleinere Sachen will ich nicht benachrichtigt werden. In dem Fall ist es besser, wenn größere Zahlen gut sind. Also größere Zahlen sind gut. Mehr Schlaf ist gut. Mehr Gulasch ist gut. Genau, dies sind alles. All die Zahlen sind kleine Integers. Dann wird halt mit plus 1 und minus 1 angezeigt und nicht mit 1%. Das sehen wir gleich. Naja, es war nicht bei allen so. Also haben wir hier noch so eine andere Art von Benchmarks. Das sind jetzt irgendwie Fließkombazahlen, die gemessen werden sollen. Und da habe ich auch ein anderes Wessal. Also kann ich das ein bisschen konfigurieren. Ich brauche nicht viele Zeilen. Wenn ich das da hingeschrieben habe in das Verzeichnis und das Tool isoliert habe, dann lasse ich einmal die Peter laufen und dann macht er dann auf dem Zeug. Dazu noch ein paar JavaScript Sachen runterladen und installieren beim ersten Mal, wenn ihr es nicht schon habt. Und wenn das alles fertig ist, viele schöne Häckchen links, habe ich jetzt in diesem Verzeichnis auch noch ein Verzeichnis-Seit für die Website. Das kann ich öffnen, funktioniert auch lokal. Und da da, ich habe meine Performance-Daten schön visualisieren. Das macht halt eins, wie ich benutze. Also wie ich es aufsetzen. Jetzt kommt Teil 2. Was kann ich damit alles machen? Kleine UI-Übersicht. Was wir hier sehen, ist jetzt eine Übersicht über die letzten Commits. Die sind leider etwas langweilig benahmt. Warum ist der Weibner so komisch? Wir sind ein bisschen langweilig benahmt. Manche Commits sind grün, manche sind weiß. Weiß heißt es ist nicht spannend. Nee, das ist nicht weiß, das ist... Ach je, der BMO tut meine Farben leider licht annähernd authentisch wiedergeben. Also das hier ist grün. Das hier ist so ein rot sein, aber rot ist böse, deswegen habe ich so ein abgeschwächtes Rot genommen, so ein Weizenfarben. Und... Okay, der Hintergrund ist weiß. Ja, also wir haben so ein paar Farben. Was sieht man? Man sieht von wann der Komet ist. Man sieht die Komet-AD, man sieht die Nachricht. Hier rechts so eine kurze Übersicht. Okay, wir haben hier zwei Commits, die haben sich verbessert, einer hat sich verschlechtert. Wir können auch mit der Maus drübergehen und sehen so eine Übersicht. Von sieben insgesamt. Die kann man sich nicht anschauen, indem man auf den Komet klickt. Sieht mir hier gleich die Metadaten. Wer hat es geändert, was ist die Komet-Daten? Und hier eine Tabelle. Das ist ein bisschen unschön. Kam wohl in meinen echten Projekten noch nie vor, dass ich das gezahlen hatte, sonst hätte ich das schon längst gefixt. Aber man sieht hier die Änderung relativ zu dem Vorgänger-Komet, dem Parent, der auch hier verlinkt ist. Kann ich auch draufklicken, mich durchnavegieren. Diese Links hier, wie du dir das z.B. das, was wir vorhin in der Konfig festgelegt haben. Hier kann ich draufklicken, ich komme direkt zu GitHub und sehe, okay, da folgende Tweets wurden zugefügt und haben diese Änderungen gemacht. Was ich auch machen kann ist, ich kann, vielleicht nochmal das jetzt mal an einem ernsthafteren Beispiel. Das hier ist die Instanz für GAC, für den Haskell-Compiler. Das wird automatisch alle Commits gebaut von meinem Rechner unterm Schreibtisch, den ich nicht grau, weil ich mit dem Laptop arbeite. Und ich höre immer, wenn irgendwer Commits committed, weil dann geht der Luft an. Genau, da habe ich hier auch. Jetzt könnte man meinen, GAC hat nur einen Commit, natürlich nur einen Benchmark, das stimmt nicht. Er blendet einfach alles aus, was nicht verändert hat, wenn ich die sehen möchte. Hier oben rechts habe ich Knöpfe, ich kann sagen, ich möchte jetzt nur, als ich möchte, alles ignorieren, was schlechter wurde, das ist so der Kopf-in-Sandstecken-Modus. Oder ich will einfach alles sehen, dann habe ich hier entsprechend viele Benchmarks, verschiedene Art, Größe, Laufzeit, Allokationen und sehe jetzt hier, was ich verbessert oder verschlechtert habe. Hier sieht man auch, wie man einfach eigene Commits, eigene Links noch hier einbauen kann. Also wenn ich jetzt Infotutur habe, wie ein Fabrikator, ist das hier problemlos erreichbar. Oder den Build-Log selbst, der ist hier verlinkt. Der ist groß, hätte ich nicht öffnen sollen. Hier oben hat man so ein paar Fragezeichen, was kann man damit machen, damit kann ich die liebigere Visionen vergleichen. Also wenn ich sage, okay, ich möchte wissen, was er sich inzwischen der letzten Version geändert und nehmen wir mal folgendem Branch hat. Hochrollen, reinziehen, habe hier einen Link und jetzt habe ich die Veränderung zwischen zwei. Okay, für das Beispiel, da ist keine Veränderung drin, aber ich hätte jetzt hier ein Tabelle, wo ich sehe, was sich zwischen diesen geändert hat und kann ja auch zum GitHub Vergleich springen. Das waren so ein bisschen viel Tabellen. Eigentlich sind ja Grafen schön. Also schauen wir mal an, ob wir auch irgendwo Grafen herbekommen. Hier, wenn ich da drauf gehe, gibt es einen Link zum Grafen und schon habe ich schön den Grafen. Und wenn ich den Grafen hier sehe, sehe ich, okay, welcher Komet war das? Ah, das war von Mittwoch. Da kann ich auch draufklicken und komme wieder zur Tabellenübersicht. Also einigermaßen intuitiv zu bedienen, hat, kann nicht furchtbar viel, aber ich finde das, was es kann, das tut es. Und erstaunlicherweise habe ich einfach auch kein anderes Projekt gefunden, was das irgendwie in der Form konnte. Also ein nicht-projekt-spezifisches Dashboard für Performance-Daten, das Git kann. Ich habe eins gefunden, das ist, das kann Git auch, aber es kann auch anderes. Deswegen packt es alle diese Funktionalität von Git und Subversion und anderen Sachen irgendwie abstrakt rein und schon hat man Probleme, wenn man ein Rebase macht und plötzlich fünf Commits bei Git das gleiche Datum haben und er dann die Reihenfolge der Commits nicht mehr richtig hinkriegt. Deswegen dieser Git-Fokus. Ich denke, heutzutage ist der angemessen und hilfreich. Genau, deswegen versteht es auch Branches. Es weiß wie was ein Branch ausmacht, dass ein Branch vielleicht mehrere Commits vom Master weg ist und zeigt dann hier die Veränderung nicht des letzten Commits nur an, sondern wirklich die Änderung seit der Merge-Base-Loud-Git. Kann man drum spielen. Genau, man kann es eben jetzt auch für, also das ist natürlich der prototypische Anwendungsfall, ich habe echte Performance-Daten. Man kann auch ganz lustige Sachen machen. Als ich meinen Disk geschrieben habe, habe ich hier einen Benchmark gehabt, der Menge an Tinte auf dem Papier in Seiten gewessen hat und mit jeder Änderung meiner Dissertation konnte ich sehen, wie ich mehr Tinte aus Papier bringe. Also komprimiert würde meine Diss-12-Seiten lang sein, wenn man das ganze Weißezeug weglassen würde. Man kann sich ja viele andere Arten von Daten vorstellen, die man hier visualisieren muss und alles, was man eben braucht, ist eben dieses einfache, ich habe ein Verzeichnis, ich habe für alle meinen Commits eine Datei oder für alle, wo ich fast alle, wie auch immer, möglichst viele, so eine Datei, die hat so ein Format. Beziehungsweise, man sieht es schon am Namen, das ist eigentlich kein Log, was da steht. Der Gedanke ist, dass man irgendwelche Build-Logs da reindampft, die sind auch sonst nützlich und dann gibt man noch dieses Skript hier an, was hier Log2.csv heißt, was aus der Log-Datei die Benchmark-Daten rausgrappt. In dem Fall hier am Beispiel ist es einfach bin-cat, weil die Log-Dateien sind schon im richtigen Format. In einem echten Projekt würde man hier wahrscheinlich andere Ausgabe im Log-Versignis haben und die dann mit irgendeinem Skript umwandeln. Das ganze Tool ist vielleicht noch ein paar Worte so ein bisschen zum Hintergrund, wie man es deployen kann und wie es funktioniert. Es ist selbst ein Haskell geschrieben, benutzt einen Politik namens Shake, was eigentlich dafür gedacht ist, Build-Systeme, also so etwas wie Make zu reimplementieren, mit Abhängigkeiten und so. Das hat den Effekt, dass wenn ich GP da laufen las, er jetzt nicht irgendwie alle Dateien neu durchnudelt, sondern er weiß genau, welchen Dateien er aktualisieren muss. Wenn ich jetzt zum Beispiel in... Enden mal irgendeine Log-Dateien und bescheißen hier und machen... Okay, da waren es sieben Chancs. Tungs, wie auch immer. Und ich lasse es neu laufen. Dann werden eben alle Teile der Ausgabe, die davon beeinflusst werden, neu gebaut. In dem Fall dieser Commit und wahrscheinlich der nachfolgende Commit, dessen Parent sie jetzt geändert hat. Das Ganze produziert eine statische Seite. Das heißt, man kann es einfach deployen, indem man es auf Github-Pages oder auf seinen sonstigen statischen Haustern schmeißt. Wie sieht das aus? Wir haben eine Index-HTML, die ist fix. Die erinnert sich nicht. Und wir haben dann einen Haufen Jason-Dateien. Also gut, es sind nicht so arg viele hier, aber bei dem GRC mit vielen tausend Commits sind es doch einige. Und dann ist die gesamte Logik der Anzeige passiert im Browser auf dem Client, das normales JavaScript mit Handelbar als Templating-Engine, lädt sich eben die Jason-Dateien runter, die es braucht, was man anzeigen möchte. Vielleicht ganz nett, ein bisschen konzeptuell. Konzeptuell ist es ein ganz großes Jason-Document. Und all die Dateien, die wir hier haben, sind Fragmente davon, die man im Grunde mörschen könnte. Also wenn ich, das sieht man nicht gut. Aber man kann sich so vorstellen, ich hab den Gips nicht als Dateien, ich hab einen Riesenbaum in allen Daten und jede von diesen Dateien enthalten, sozusagen einen kleinen Teilbaum. Und in dem kleinen kann ich dann einfach, eine weitere Datei brauche für irgendein Ansicht, lade ich die Datei und mörsche es in meine kleinseitige Sicht der Daten. Da hab ich immer eine partielle, aber konstente Sicht der Gesamtdaten. Ja, das wäre es eigentlich schon für das Tool. Also wenn man, was braucht man dafür? Haskell Compiler, man muss irgendwie diese Log-Dateien generieren, diese CSV-Dateien, das ist ein ganz einfaches Teilformat. Aber wie ihr gesehen, einfach Benchmark-Name, Simecolon Wert, können Ganzzahlwertes sein, können Floats sein. Was ich euch nicht erklärt habe ist, wie kriegt ihr eure Log-Dateien erzeugt. Im Falle von GRC ist es ein Bash-Script, was irgendwie WhileTrue macht und schaut, ob was Neues zu bauen ist und es baut. Das funktioniert, das läuft stabil. Wer was Schöneres haben will, der darf jetzt den zweiten Teil lauschen. Sebastian hat da nicht auch was Cooles gebastelt, was jetzt schön mit Gepäder interagiert. Dann bauen wir schon um. Wir bauen ganz normal die ersten Fragen. Dann ist die Pause nicht so lang. Und denkt dran, ihr könnt twiten, damit ihr jetzt bei der Demo auftaut. Ja, gibt ja das Kabel. Ist das so? Ja, perfekt. Wie bitte? Ich wechsle jetzt auf HDMI. Hä? Ne, warte mal. Ist das der gleiche Adapter? Ja, genau. Der passt. Sehr gut. Ich bin Sebastian. Ich habe so ein bisschen den Gedanken fortgespielt. Was wäre, wenn man jetzt um Gepäder herum noch so ein Tool schreiben würde, was das Ganze ein bisschen automatisiert? Was ein bisschen mehr Arbeit abnehmen würde, insbesondere dann automatisch das Skid-Repository-Polen in einem bestimmten Zeitintervall, die Benchmarks automatisch generieren, indem man ein bisschen Konvention aber konvigrationmäßig irgendwelche Benchmark-Scripte angibt, die dann einfach funktionieren und dann eben versuchen, genau diese CSV-Dateien auszugeben. Und ja, das Ganze ist dann in Feed-Gepäder gelandet. Was es dann eventuell macht, ist sowas wie Travis für Benchmarks sein. Die Idee ist, dass man eigentlich nur irgendwo im Internet, in irgendeinem Gid-Repository so eine Liste von Repositories hat, wo man sein eigenes Repository dann eintragen kann. Das Ganze wird dann auf irgendein CI-Server geladen, irgendwie gesinkt. Das löst dann eben diese ganzen Benchmarks aus und hoffentlich nach einiger Zeit findet man dann eben das Ergebnis auf der von Peter generierten Seite. Ja, also wie läuft das? Im Prinzip rufen wir Gepäder einfach auf für eine Liste von vorkonfigurierten Repositories auf. Dann wird für jedes Repository-Commit-Pal eine temporäre Benchmark-Suntbox erstellt, in der dann ebenfalls vorkonfigurierte Benchmark-Script ausgeführt wird. Genau, das kann ich mal hier vorführen. Also das hat natürlich zur Folge, dass man eine zusätzliche Settingserzeit hat, in der dann einfach irgendwie jammelkodiert die Liste von Repositories steht. Kann man sehen, oder? Genau. Jetzt ruf ich da mal Feed-Gepäder drauf auf. Die Flex erkläre ich gleich. Und zwar, also das Config-Flegg ist dann einfach nur dafür da, dass man eben den besonderen Pfeilalken gibt. Defaultmäßig wird einfach irgendwie unter dem Homeverzeichnung nachgeschaut und man kann dann eben einfach, falls das nicht reichen sollte, eben selber was angeben. Deploy2 gibt an, wohin dann hinterher die generierte Seite hinkommt. Das ist nicht mehr so einfach wie vorher noch bei Gepäder, also dazwischen, wir brauchen noch so eine lange Seite, wo wir dann praktisch auf die einzelnen Unterseiten zugreifen. Also weil wir ja jetzt auf einmal mehr Repositories betrachten, haben wir natürlich auch mehrere von Gepäder generierte Seiten. Die Fehler, die sind beides ein. Also das ist alles richtig. Genau, das liegt mehr oder weniger daran, dass wir ein paar Probleme hatten mit UTF-8-Content in der Tweet-Datei. Und genau, wir können uns mal kurz anschauen, das ist das Repository, eben was Joachim auch schon gezeigt hatte. Also das ist diese Tweet-TXT-Datei, haben wir ja gesehen, da sind die ganzen Tweets drin. Und jetzt zum Vergleich, also das ist die Gepäder-Jammel-Datei, die da fehlt einiges an Einstellungen, die dann praktisch von FeedGepädern hinzugefügt werden, wo man vorher eben sehr viel Konfigurationsarbeit vornehmen muss, die man vielleicht gar nicht aufbringen will, wenn man einfach mal just ausprobieren will, ob es das für sein Projekt das Richtige ist. Aber was natürlich angegeben werden muss, ist das Benchmark-Script, was ausgeführt werden soll und eben auch, welche Benchmarks dann hinterher in den CSV-Dateiden vorkommen. Genau, schauen wir mal zurück. Immer noch nicht ganz fertig, genau. Ja, stimmt, ja, schauen wir. Also wenn ich ihn jetzt abbreche, genau, wir haben jetzt mittlerweile schon relativ viele Commits und deswegen, ich blende den meisten Text, also eben aus, die meisten Lock-Messages, weil muss ja nicht. Und genau, wir schauen es jetzt jetzt einmal mal an. So, jetzt starte ich gerade meinen Web-Server. Genau, also das ist die Landeseite und hier sehen wir jetzt das Digital Repository. Ja, und das ist alles genau das Gleiche wie vorher jetzt. Also das war jetzt so das Proof-of-Konzept funktioniert. So, das ist noch nicht alles. Also gut, was ich noch nicht erwähnt habe, ist, dass man auch mehrmals das Programm wieder, wir sind im Fall schon ordentlich, auch mehrmals das Programm wieder aufrufen kann und er dann eben auch WGP da incremental Updates vornimmt. Also zum Beispiel, der Pult hat jedes Mal alle Repositories und schaut, ob neue Commits reingekommen sind und führt dann eben dafür die Benchmarks neu aus. Genau. Und normalerweise würde er relativ schnell wieder aufhören, aber weil wir ja gerade nicht alle Commits durch haben, dauert das wohl noch etwas. Ja, wir gehen trotzdem mal weiter. Und zwar, jetzt ist die Idee, wir können es mehrmals aufrufen und es sind immer incremental Updates. Warum kann ich dann die, warum, also das verrät ja schon so ein bisschen, dass man es sehr gut als Crunch-Up laufen lassen könnte, irgendwie alle 30, alle Minute, einmal praktisch alle Repositories refreshen und gucken, ob neue Commits da sind und eben alle Updates wieder, also die Seite komplett updaten. Das gibt es sogar eingebaut und zwar ist das dann der Watch-Modus. Also, dass dieser Parameter hier, der jetzt noch hinzugekommen ist und zwar ist er einfach nur dazu da, dass er, wie gesagt, alle 30 Sekunden jetzt in dem Fall alle Repositories refreshen und zusätzlich auf Änderungen für diese FeedGipäda-Jammel-Datei schaut. Das heißt, theoretisch müssten wir jetzt, ja, das ist alles ein bisschen kaputt, weil ich die Bildschirme gewechselt hab, müssten wir jetzt. Also, wir sehen, jetzt habe ich den Imvolvers-Modus, sieht man auch, was er so zwischendurch alles macht. Es sind zwar eigentlich eher so Debug-Messages, aber ich wollte einfach nur demonstrieren, das hat tatsächlich was tut. Genau, und das sind gerade noch 10 Kumpeln. Warten, weil lieber noch 10 Kumpeln jetzt ab, weil, also, ich habe gleich noch vor, mal ein anderes Repository hinzuzufügen und damit ich einfach demonstrieren kann, das ist tatsächlich auch funktioniert. So. Jetzt muss ich schnell sein, weil nach 30 Sekunden versorzen wir den Standard-Out. Also, das ist jetzt einfach ein Repository-Benchmark-Test, habe ich jetzt hinzugefügt, das ist einfach ein beliebiges Benchmark-Repository. Also, was da genau passiert, ist eigentlich egal. Das Wichtigste ist, dass es irgendwie 5 Commits hat und sieht man jetzt da unten auf, schön, 5 Commits, die eben jeweils Benchmarks von 30 Minuten haben. Das treffen wir auch gleich wieder an. Also, das wäre jetzt so das Setup, was man betreiben könnte, um Continuous Integration-mäßig einfach als Service im Hintergrund laufen, als den man im Hintergrund laufen lassen könnte und eben einfach auf Änderung auf diese Repository-Liste zu schauen und dann eben für neue Repositories auch die ganzen Benchmarks aufzukämen. Also, ja, stimmt. So. Nun ist es so, das skaliert ja immer nur bis zum gewissen Punkt, also Benchmarks sind ja schon irgendwie performancekritisch, oder das ist wichtig und essentiell, dass man, dass die Maschine auf der, das Benchmark läuft, eben nicht durch andere Prozesse irgendwie stark belastet wird. Und wenn wir jetzt immer nur einen Rechner haben oder einen Rechenknoten, der eben diese ganzen Benchmarks ausführt, dann schaffen wir es wahrscheinlich gar nicht hinterherzukommen, wenn wir da, ich sag mal, 20 sehr aktive Repositories in dieser verkonfigurierten Liste haben. Deswegen habe ich noch einen zusätzlichen Modus um verteilt, um eingebaut, um die Benchmarks zu verteilen. Und zwar ist das eigentlich im Prinzip einfach eine relativ simple Masters Life Architektur und die wird besonders dann explizit, dass man eben angibt, dass man den FeedGP da im Master Modus starten will. Kann man gerade mal was machen. Jedenfalls also ich gebe hier praktisch an den TCP Endpunkt, unter dem man der Master Prozess dann im Prinzip bereichbar ist und ich kann dann Slaves einfach spornen, die eben auch so ein TCP Endpunkt zugewiesen wird und die finden sich dann über UDP-Modulicast-Metzwerk und das funktioniert gut, wenn Multicast funktioniert. Genau, also das ist jetzt hier in der Repository Datei stehen, wieder ist wieder das Benchmark, ist wieder das Repository, wo ein Benchmark 30 Sekunden dauert, deswegen haue ich einfach mal gerade fünf Slaves raus und lasse die ein bisschen rödeln und das ist dann relativ schnell fertigführt. Achso, rechts sieht man die Benchmark-Prozesse, die nach und nach also was es macht jedes Mal ist natürlich einmal das Repository-Klon in so einem Sandbox packen, einmal das Projekt bauen und dann die Benchmarks ausführen und deswegen dauert es mal so ein bisschen bis die Benchmarks im Endeffekt hier auftauchen. Ah ne, doch, genau. Genau und ja, die Hoffnung ist, dass man dann eben einfach die Last auch in irgendeinem echten Zentrum verteilen kann. Genau. Und das war es dann eigentlich auch schon, was ich zu sagen habe. Also, genau. Also es ist im Prinzip so ein bisschen Richtung Continuous Integration gedacht und ja, mal schauen. Vielleicht kannst du ja irgendwer gebrauchen. Ja, habt ihr noch Fragen zu einem der beiden Projekte oder anderen Sachen? Also, wir haben bei uns ein Jenkins bei mir im Geschäft, da läuft irgendein so ein Jenkins-Server, ich habe keine Ahnung wie der funktioniert aber der schmeißt in so einer C++-Programme an mit Make und sonst was und der bastet auch irgendwelche solche Reports. Also so Fehleranzahl, Compiler, sonst was. Könnte wenden, da kann man wahrscheinlich auch einfach was dazu strecken. Also, was ist jetzt hier bei dieser Lösung anders, besser? Also, was ich denke, was besser ist Jenkins hat, soweit ich weiß, immer so eine ziemliche Zeit basiert, da auch der Vortrags-Titels, so ein Zeitbasierter an sich so. Das letzte Mal, als ich gelaufen bin, waren es fünf Fehler, jetzt sind es vier Fehler. Aber es kann es sein, dass die Commits eigentlich logisch in eine andere Reihenfolge sind, weil zum Beispiel die anders umgescheduled wurden oder weil du Rebase gemacht hast oder irgendwie sowas. Also diese Bedeutung der Reihenfolge von Commits aus Git-Sicht wird von diesen Tools oft nicht gesehen. Was man aber jetzt sehr gut machen könnte, wäre, dass man ein kleines Skript schreibt, was die Jenkins-Ausgabe durchgeht und zu jedem Bild die Daten rausnimmt, die Zahlen und eben mit dem Hash des Git-Commits versieht und in so eine Verteidnis reinschmeißt und er lässt mal GP da drüber laufen und kriegt die gleichen schönen Grafen. Also es wäre, ich würde jetzt GP da nicht so Jenkins in dem Sinne sehen, sondern als Ergänzung, wie man die Daten schöner aufbereiten kann. Also wobei natürlich für deinem Tool ist nicht Jenkins an die Konkurrenz sozusagen. Jenkins ist halt ein Riesending und kann mehr und kann anders sein. Ja, das wird auch nicht jeder. Aber also der Vorteil, wenn man jetzt viel GP da benutzen will, ist, dass man, ich denke, um einfach zu starten, ist es weniger Konfiguration. Um das aufzusetzen, ist glaube ich nicht immer ganz verwirrend. Gut, ich habe selber noch nicht mitgearbeitet, aber... Also der Plan für viel GP da ist halt auch nicht irgendwie das für fünf Projekte zu machen, sondern tatsächlich im Fall für das gesamte Ecosystem bereitzustellen. Das kommt aus der Hexgeregge, dass jeder, der eine kleine publik Seh-Dateien-Bibliothek schreibt und da einen fünf Benchmarkskript einfügt mit wenigen Klicks er versorgen kann, dass auch sein Code ohne persönlichen Setup-Aufwand. Also mal schauen, ob wir es schaffen und dann schauen, wie es dann mit den Ressourcen läuft und so, aber das ist der Plan. Und ja, falls jemand den Start-up gründen möchte mit der Idee TravisCI-mäßig für Benchmarks wäre auch interessant. Ich glaube, es gibt einen Markt dafür. Man muss sich überlegt, wie erfolgreich dieser CI-Dienste sind für was, was man auch vorher selber hätte machen können, wenn man sich halt die Mühle macht ein Skript auf den Rechner aufsetzen. Das ist mein Grund, warum es nicht auch genau so gut für Benchmarks funktionieren kann und auch nicht genauso tolle Effekte haben kann. Ja, dann nochmal vielen Dank für die Aufmerksamkeit. Danke.