[Sammelthread] Der Gehalts- und Arbeitsplatzthread

[p4n0]

@Geforce3M3
Stark vereinfacht steht ihr doch vor folgender Herausforderung:
Du / Ihr schreibt code. Dieser Code muss irgendwo ausgefuehrt werden, damit hinten ein Ergebnis rausfaellt.

Und genau diese ausfuehrende Umgebung ist in so nem CI/CD Konstrukt nichtmehr dein eigener Rechner, sondern ein remote-rechner, der genau fuer diese Aufgabe maßgeschneidert ist.

Das einzige was du als User tust: Du pushed und commitest deinen Code in ein Repository. Danach rennt die Pipeline los, checked den Code aus und fuehrt ihn auf dem Buildagent aus.
Diesen Buildagent zu bauen kostet am Anfang recht viel Zeit und Aufwand. Doch danach profitierst du nur noch.
Der Agent kann beispielsweise nen bare-metal Server sein (macht man heute nichtmehr) auf dem python, alle dependencies etc.. installiert sind - quasi wie dein eigener Computer.
Du kannst de Agenten aber auch in nen Docker Container packen (diese lassen sich dann auch fuer eure unterschiedlichen Anforderungen parametrisieren/unterschiedlich voneinander gestalten).


Aber es ist halt super flexibel und du musst dich nichtmehr mit den eigenen User-Umgebungen herumschlagen. Kann naemlich sein dass bei dir der Code laeuft und bei deinem Kollegen halt nich, weil ihm ne env-variable oder sonstwas fehlt. Und dann muss man halt immer rumfrickeln.

Weitere Vorteile sind: Es ist egal ob du nen Mac nutzt und dein Kollege ne Windows buechse. Ihr braucht nur ne Entwicklungsumgebung auf euren Maschinen, das ist alles. Der Rest passiert wo anders - standardisiert, fuer alle gleich.

Soll nicht belehrend sein hier, evtl. hilfts dir ja weiter

//edit: Je mehr User damit arbeiten oder je hoeher die Fluktuation der Kollegen ist, desto mehr lohnt es sich sich mit dem Thema auseinanderzusetzen.

 

[Geforce3M3]

@p4n0. Erst einmal danke für die Erklärung.

Soll nicht belehrend sein hier, evtl. hilfts dir ja weiter

Keine Sorge, habe ich so nicht verstanden, freue mich über Feedback.

Das allgemeine Problem ist folgendes:
1. Die Daten (input für den Code) sind nie exakt gleich. Code A funktioniert bei Person/Gehirn X. Bei Person Y (anderes Gehirn) benötigt du Code A1.
Beispiel: du hast 40 Personen in einer Studie gescannt. Bei 20 Personen funktioniert der Code. Bei anderen 20 kommt Unsinn bei raus. D.h. Code muss individuell je nach Person angepasst werden.

2. Die genauen Ziele der Analyse sind immer anders. Was heißt das? Das heißt dass du, wenn du erstmal brauchbare Ergebnisse hast, am Ende die gesamte Pipeline von A bis Z auf deine spezifische Analyse anpasst/tailorst! Alleine das gesamte Preprocessing der Daten, d.h. die Vorverarbeitung/Aufbereitung bevor du die eigentlichen Analysen beginnst musst du individuell auf die Analysen anpassen die du nacher eben anstellen willst.
Welche Preprocessing Schritte sind optimal für Messung X oder Y? Da scheiden sich je nach Fall schon die Geister. Bei manchen Schritten stimmen alle überein, bei anderen gibts Diskussionen und unterschiedliche Ansichten.

D.h. es kann keine Codepipeline geben die allgemein zu guten oder sehr guten Ergebnissen führt. Die ganze Pipeline hängt von individuellen Analysen und Zielen ab. Dazu von Eigenschaften des Datasets. Mit welchen Scannersettings wurde aufgenommen etc? All das und viel mehr beeinflusst den notwendigen Code.

Und was in welchem Fall ideal ist kann man a priori nicht vollständig sagen da auch viel trial and error dabei ist. Stattdessen muss du immer wieder neu coden und anpassen. Ansonsten könnte ich natürlich einfach Code auf github und co hochladen oder sogar wie du sagst eine ideale "workenvironment" auf einen Server schaffen.

Jetzt verstanden? Oder reden wir aneinander vorbei und ich verstehe dich nicht?

Das Problem ist weniger dass die Software hier und da mal "verkackt" weil beispielsweise ne dependency fehlt, sondern weil die Daten die verarbeitet werden komplex sind und individuelle Handhabung benötigen, quasi no one code to rule them all.

 

[p4n0]

1. Die Daten (input für den Code) sind nie exakt gleich. Code A funktioniert bei Person/Gehirn X. Bei Person Y (anderes Gehirn) benötigt du Code A1.
Beispiel: du hast 40 Personen in einer Studie gescannt. Bei 20 Personen funktioniert der Code. Bei anderen 20 kommt Unsinn bei raus. D.h. Code muss individuell je nach Person angepasst werden.

Das ist kein Problem. Gesondertes Repo, Forks, Staging Branches etc.. Kann man mit nem passendem GitHub Setup abbilden.
Die Pipeline laesst sich parametrisieren durch welchen 'Compiler' dein Input-Code durchgenudelt wird.

Alleine das gesamte Preprocessing der Daten, d.h. die Vorverarbeitung/Aufbereitung bevor du die eigentlichen Analysen beginnst musst du individuell auf die Analysen anpassen die du nacher eben anstellen willst.
Welche Preprocessing Schritte sind optimal für Messung X oder Y? Da scheiden sich je nach Fall schon die Geister. Bei manchen Schritten stimmen alle überein, bei anderen gibts Diskussionen und unterschiedliche Ansichten.

Ich verstehe zwar nicht ganz im Detail was ihr da genau tut aber auch hier ist ne Pipeline parametrisierbar in unterschiedliche Stages.
Du kannst unterschiedliche Pipelines bauen (Kannst du dir wie ein Kochbuch vorstellen).

Um das etwas zu veranschaulichen:
1.) Code auschecken. Das sollte fuer alle Faelle allgemeingueltig sein.
2.) Pre-Processing. Hier kann es sein, dass das eine Gericht erst kochendes Wasser braucht. Also wird die Pipeline erst den Herd einschalten damit das Wasser kocht.
Dieser 2. Schritt MUSS nicht in jeder Pipeline vorkommen. Bei ner anderen Pipeline kann der Code direkt durch den Compiler gejagt werden.
etc. etc..

Diese Schritte koennen aber auch generelle Themen wie Codeanalysis, securitychecks oder sonstwas sein. z.B: Pruefen ob sich jeder an eure Programmier-Regeln haelt etc. Unit tests etc..

Ich glaube schon langsam zu verstehen dass ihr recht flexible Anforderungen an eure 'Build-Umgebung' habt. Warscheinlich waere das in deinem Fall mit Kanonen auf Spatzen geschossen. Steckt wohl zuviel Arbeit dahinter das sauber zu 'Verpipe-Linen'.