Herzlich Willkommen zu einer neuen Folge des zu du Developer
Podcast mit Robin Manuel Thiel und mir Malte Landin und Manuel
wie läuft's heute Hey malte Guten morgen alle zusammen grüßt
euch ich freu mich ich freu mich, dass wieder ein Thema
mitgebracht haben. Aber vorher starten wir mal ein
bisschen in Dankeschön und Feedback rein.
Wir haben nämlich Kaffee spendiert bekommen.
Für die letzte Folge und zwar 3 ganze Kaffee von Peter, vielen,
vielen Lieben dank dafür. Wer gar nicht weiß, wovon wir
reden, wenn Ihr in Folge fällt, dann freuen wir uns immer sehr,
n Kaffee auszugeben. Dafür gibt es einen Link unten
in der Beschreibung vom Podcast aber erstmal die Folge an und
entscheidet nachher, ob n Kaffee einladen.
Wir freuen uns auf jeden Fall sehr, ganz ganz lieben Dank an
Peter genau und natürlich könnt ihr euch auch dazu hinreißen
lassen, die jetzt schon auf den Kaffee Link zu klicken.
Wenn ihr einfach Denkweisen patsche.
Würden die Podcast aufnehmen, Gewicht meinen Kaffee aus, aber
macht es gerne auch vom Content abhängig?
Apropos Content Die letzte Folge da ging es ja über das Thema Red
Flags. Bei den Software Unternehmen,
bei denen man sich bewirbt. Wenn ich auf der Suche nach
einem neuen Arbeitgeber bin und da haben wir zahlreiche Feedback
bekommen. Vielen Dank auf jeden Fall
dafür. Wir freuen uns über den
Austausch mit euch und insbesondere das Thema
Interviewprozess ist natürlich ein Thema was für euch ganz heiß
ist und da haben wir zum Beispiel Feedback von von Julia
bekommen, die sagt absolut Thread Flags für sie, wenn man
Coding. Alles machen muss, obwohl man
super erfahren ist und dann auch Coding Challenges, die
tatsächlich nichts mit den Aufgaben im späteren Job zu tun
haben, sprich solche Spiele Aufgaben, wo man irgendwelche 0
815 Algorithmen nach implementieren muss, das ist für
sie ein absoluter Redflag, wenn ich ganz spannend, irgendwie auf
linkedin kommentiert. Als die gepostet hat irgendwie
in dem entsprechenden Reelle einlassen mit dem, was sie von
solchen Aufgaben hält und ist aber trotzdem zum Gespräch
eingeladen worden, was ja wohl dankend abgesagt hat, fand ich
ne coole Aktion. Ja, und dann haben wir noch von
Cyan Crystal auf Spotify Feedback bekommen und für sie
oder für ihn ist das Thema Teamzusammensetzung im
zukünftigen Entwicklungsteam, in dem man anfangen würde, auch ein
ganz wichtiges Thema und da werden absolutes Red Flag, wenn
man mit dem Team spricht oder mal nachfragen, dann die
Rückmeldung kriegt das fast nur Junior Developer dabei sind also
alle Leute, die irgendwie ganz frisch aus der Uni oder
Werkstudenten oder gerade mit der Ausbildung fertig.
Das ist ein absolutes Red Flag. Ich gehe davon aus, dass dies
natürlich vor allen Dingen daran, dass man entweder mit
einer Firma arbeitet oder arbeiten würde, die einfach
extrem aufs Geld guckt und deswegen bei den Personalkosten
spart oder dass die Teams sich regelmäßig verändern und gerade
die erfahrenen Leute in andere Projekte abgezogen werden oder
die Firma verlassen, also das auch wirklich n Red Flag von
meiner Seite. Vielen Dank für das Feedback.
Dann hat auch auf Spotify noch jemand geschrieben das ist n Red
Flag ist nicht also irgendwie fehlende Weiterbildung, also
dass eine Teilnahme an Konferenzen verwehrt wird oder
nicht möglich ist oder dass man generell da irgendwie keine
Möglichkeit der Weiterbildung hat?
Hab ich glaube ich in meinem in meiner Top 5 gar nicht erwähnt,
bin ich aber auch dabei also ich mir ist es ja eh immer super
wichtig, ganz relativ aktuell auf meinem meinem Wissensstand
zu bleiben, wenn das meinem Arbeitgeber nicht unterstützt
wird, dann passt wahrscheinlich auch nicht zusammen ich r Punkt
und auch fand ich generell spannend ist f, die sehr viel
Feedback bekommen haben. Das macht immer viel Spaß mit
euch zu diskutieren und das ist auch ganz geil.
Spotify jetzt irgendwie eingeführt hat, dass sie folgen
kommentieren könnt. Also wenn wir nachher in unserem
Thema Quatsch erzählen oder irgendwie noch n nach
Ergänzungen habt ihr ne Frage habt ihr Kommentar habt dann
scheut nicht davor zurück und das entweder in die
Kommentarfunktion hier bei Spotify.
Schreiben oder wenn ihr anderen Player unterwegs seid, könnt ihr
auch gerne eine Mail hinterlassen unten in der
Videobeschreibung findet die e Mail Adresse.
Oder kommentiert oder ihr ihr findet schon weg zu erreichen.
Wir freuen uns auf jeden Fall immer also haltet euch nicht
zurück und sagt uns gerne auch ihr spannend findet einfach auch
die Feedbacks aus der Community ein bisschen zurück zu bekommen,
dann in der nächsten Folge jeweils.
Wir finden es selber super spannend und ich glaube auch ihr
könnt alle davon profitieren. Einfach noch mehr Inspirationen
auch von anderen zu bekommen, die diesen Podcast hören,
steigen wir ins heutige Thema ein und das heutige Thema ist ja
schon im Titel gesehen, geht Hooks Robin Manuel das Thema
hast du für heute mitgebracht, warum hast du dich mit dem
Thema? Auseinander auseinandergesetzt.
Und warum beschäftigt sich gerade damit ja ganz genau genug
gelabert jetzt mal wieder ein Thema?
Und zwar, ich beschäftige mich eigentlich immer sehr viel damit
zu Teameffektivität und Effizienz zu optimieren mein
großer Fan davon eigentlich Coding Style in Repositories zu
haben und im Rahmen dieser Optimierung ist bei uns in
einigen Projekten immer wieder aufgefallen, dass es zu ja
relativ viel Frustration kommen kann, wenn manche Dinge erst
auffallen, wenn der Pole Quest automatisiert gecheckt wird,
dann vielleicht nochmal Zuordnung.
Die Flows sind bei uns eigentlich fast immer so und das
ist glaube ich auch mal. Immer so.
Ein Entwickler Entwicklerin schreibt Coach auf einem eigenen
Branch dieser Branche wird dann im Rahmen eines Requests oder
Mercury Quest so je nachdem, welches Tool man verwendet, dann
in quasi als Vorschlag, um es in den Branchen Energie irgendwo
bereitgestellt und dann gibt es ein menschliches Review und
gleichzeitig laufende automatisierte CI Checks ab.
Das heißt irgendwelche checken zum Beispiel, ob sich an den
eigentlichen Style gehalten wurde, checken, ob der Code
überhaupt baut, ob die ganzen Tests durchlaufen und wenn das
alles irgendwie grün ist, dann sollte überhaupt erst ein Mensch
drauf gucken. Und und?
Wenn das beides halt irgendwie durch das Review gegangen ist,
wird der Code akzeptiert und nehme Branch Gemerged und jetzt
kann es vorkommen, dass jemand sich ganz viel Mühe gibt, auch
schreibt und den dann irgendwie eincheckt und dann?
Ja, eigentlich fertig ist mit seiner oder ihrer Arbeit sich
vielleicht schon neue Aufgabe widmet und dann 10 Minuten
später eine Email bekommt. Von dem von github zum Beispiel
sagen Hey dein dein Bild hier ist fehlgeschlagen, oder?
D Checks sind fehlgeschlagen, weil du dich zum Beispiel nicht
an den Coding Style gehalten hast und das kann einfach sein,
weil hier am Ende ein Leerzeichen zu viel ist und wir
eigentlich gesagt haben, dass alle, dass alle trailing
Leerzeichen verschwinden sollen oder ne also wir haben ja
eigentlich den ganzen ganzen Coding Styles und sowas
automatisiert. Es kann aber auch sein, dass
sowas heißt wie EY die Tests laufen hier eigentlich fehl
hättest du eigentlich mal bei dir bei dir ausführen sollen?
Das ist technisch kein Problem, dann geht muss man halt einfach
nochmal an das heißt man checkt sich diesen Brunch nochmal aus
fix die Sachen meistens kann man das auch automatisiert über den
fixen ne keiner von uns baut mehr Coding Style, wo man per
Hand jede Datei checken muss. Da haben wir auch eine Folge
hier im Podcast mal zugemacht. Aber da ist man vielleicht aus,
weil man schon seit 10 Minuten was anderes macht, muss da
wieder in diesem schreiben muss dann Sachen fixen, muss dann
einen neuen Comic verpacken. Diesen kommt wieder, pushen die
ganze Bild Pipeline läuft wieder los.
Und das wollen wir ändern. Wir wussten, da gibt es, da gibt
es irgendwas, das heißt, es haben wir aber nicht angeguckt,
das war auch schon lange auf unserer To do Liste und vor
allem so im Prozess dieses ganzen Shift Left motions, weil
ich so wirklich so früh wie möglich erkennen, haben wir uns
überlegt, dass auch sowas wie Styling und Ling Issues oder der
Code nicht baut oder dass die Tests nicht laufen.
Im Idealfall noch ein bisschen früher auffällt als erst in
dieser Pipeline und dafür haben wir uns gehts angeguckt.
Das heißt, wir sprechen jetzt über ein Konzept.
Was in Git also in dieser Versionskontrolle mit Git fest
eingebautes spricht man eher mit anderen Version Control System
arbeitet mittlerweile arbeiten fast alle, aufgeht, aber es gibt
natürlich noch Projekte, die auf anderen Systemen arbeiten.
Dann könnt ihr dieses System verwenden.
Hooks kennt man auch aus anderen Zusammenhängen, zum Beispiel
Webhooks. Das ist das englische Wort für
Haken hook das heißt, ich kann an diesem Haken Dinge einhängen
und im Rahmen von github. Das bedeutet das, dass ich
bestimmte Skripte an bestimmten Situationen aufhängen kann,
sprich wenn bestimmte Dinge passieren oder zu bestimmten
Zeitpunkten führt dieser Hook dazu, dass bestimmte Skripte
ausgeführt werden und diese Skripte können genau diese Dinge
tun, die du gerade beschrieben hast, die häufig natürlich in
der CI stattfinden. Aber ich habe dann die
Möglichkeit, diese Skripte auch schon sehr früh, also während
der Entwicklungsphase und in bestimmten Situationen ausführen
zu lassen und damit viele Probleme schon relativ früh zu
erkennen und zu beheben. Sprich wenn der Source Code.
Auf meinen Remote Repository gepusht wird, wo ich dann
letzten Endes den Pool request aufmache, dann sind viele
Probleme bereits beseitigt und ich kann wirklich, während ich
noch an dem Code arbeite oder noch bevor ich den Podcast
aufmache, viele Probleme beseitigen und hab dann halt
nachher nicht den Stress, dass ich viele Iterationen habe, wo
ich dann zusätzliche Commits auf den Pool request drauf pushe und
das ist natürlich nicht nur für mich nervig und hat gesagt ich
hab mich vielleicht mit anderen Themen auseinandergesetzt, bis
dann irgendwann die Rückmeldung von meinem CI Process bekommt,
aber ist natürlich auch für alle Reviewer, die in der Regel bei
jedem weiteren Push dann Notification bekommen.
Dass ich am Pool request geändert hat.
Gegebenenfalls müssen bestimmte Checks neu ausgeführt werden,
die dann wieder sehr long Running sind.
Das heißt, das hat natürlich diverse Implikationen nicht nur
das Reviewer, dann nochmal drauf schauen müssen, was sich wieder
verändert hat auf diesem Request, sondern natürlich auch
langlaufende Prozesse, die gegebenenfalls noch mal
durchgeführt werden müssen, weil man ja einfach durch den
weiteren Commit per se vielleicht gar nicht erkennen
kann, ob sich da jetzt substanziell was einem Code
geändert hat oder ob Robin Manuel einfach nur das
vergessene Leerzeichen entfernt hat und dementsprechend sind
solche lokal ausgeführten Skripte sehr hilfreich.
Welche gibt es denn? Ja, das hier aufzulisten
wahrscheinlich viel zu lang. Es gibt nämlich eine ganze ganze
Liste wird auf github x Punkt com geht da gibt es ein User hat
sich die Mühe gemacht, die alle aufzulisten.
Die spannendsten sind aber glaub ich sowas wie E Commit Hook also
in dem Moment bevor ich n kommt abschicken wird dein Skript
ausgeführt und nur wenn das mit dem Exit Code 0 endet, dann kann
darf ich überhaupt auch kommen. Ansonsten gibt in dem Fall
Fehlermeldung zurück. Pre push finde ich spannend,
also ich sagen kannst kommen, so willst bevor du einen Remote
Repository pushst, wo dann noch der Polizist aufmachen würdest,
da möchte ich möchte nochmal Checks durchlaufen lassen oder
ich durchlassen irgendein Skript, einfach irgendein Skript
und was ich spannend finde, ist ich glaube message oder sowas
heißt das da kann man dann bevor jemand oder eine Message
abschickt Script laufen lassen und das wird in der Regel dafür
verwendet, dass sich. Halt schaue Herr Kommissar ist,
dass ich halt in der Regel, dass meine vielleicht einen gewissen
Standard unterliegt, wenn ich das denn machen möchte und das
ist vor allem wenn es kann sein, dass ich zum Beispiel
Conventional Commits verwende ist eigentlich ein sehr
spannendes Thema habe ich nie darüber gesprochen, werde ich
unten verlinken in der Beschreibung aber Conventional
Commits sind zum Beispiel das Folgen kommen bestimmte.
Das heißt ich bringe oder bugfix NT hinzufüge, dann muss ich das
direkt in der Comic Message angeben und zum Beispiel Klammer
auf Breaking eckige Klammer zu. Und das coole ist, dass ich
darauf auch später automatisch zum Beispiel die Versionsnummer
generieren kann, wenn niemand einen Breaking Change.
Gemacht habe nur Fixes gab zähle ich einfach die, wenn ich
semmering, mache ich die Pension zum Beispiel hoch und so weiter.
Also Semantik also wenn ich eine bestimmte Semantik in meinen
Kompass haben will oder was wir zum Beispiel sofort eingeführt
haben, ist, dass man keinen, dass bestimmte Wörter da
verboten sind. Also ich werde nicht reagiert,
total allergisch, wenn man einfach nix oder WIP für Work in
Progress heißt und dann kannst du alles machen, kannst K
ausführen und einfach sagen so das ist mein x wenn das da rein
wenn da nicht reinfällt, dann darf ich diese Message gar nicht
kommen. Mhm, das sind ja alles klar
einseitige Hooks, sprich die werden dann auf deiner Maschine
ausgelöst und führen dann Skripte auf deiner lokalen
Entwicklungsmaschine aus. Es gibt natürlich auch Server
Side Hooks, die auf manchen Source Control Systemen direkt
auch verwenden können, zum Beispiel den Pre receive Hook,
wo dann etwas ausgeführt wird, bevor der eigene Sourcecode dann
empfangen wird. Von dem Git Server.
Sie haben durchaus Herausforderungen, weil man die
natürlich dann in dem eigenen Source Control System Server
einbinden muss. Das funktioniert natürlich bei
den ganzen Cloud. Services schon mal in der Regel
per se nicht. Das heißt, wenn ich sowas wie
github verwende, kann ich gar keine verwenden, wenn ich zum
Beispiel einen eigenen Server betreibe für meinen Git, dann
kann ich sowas in der Regel einbinden, aber ich sollte mich
halt nicht darauf verlassen, dass es so etwas gibt, weil es
nur in bestimmten Szenarien überhaupt zur Verfügung steht
und es führt natürlich eine gewisse Komplexität ein, wie zum
Beispiel eine Last, die auf dem Server erzeugt wird, weil wenn
bei jedem Push 1 Developers bestimmte Skripte auf dem Server
ausgeführt werden und ich halt n paar 1000 d irgendwie darauf
arbeiten kann, das natürlich dazu führen, dass mein Server
ordentlich Last kriegt. Also das ist durchaus komplex.
Wohingegen die kleinen Sidekicks eigentlich sehr leicht zu
handeln sind, weil sie halt nur die lokale Maschine des
Developers betreffen, was aber wiederum auch ein Nachteil sein
kann, weil ich natürlich das ganze nicht so ohne weiteres als
zentrales System etablieren kann.
Ich kann nicht als Unternehmen sagen, bestimmte Skripte und
bestimmte Hooks werden von allen Developern eingerichtet, weil
ich natürlich die lokale Maschine dementsprechend
konfigurieren muss. Da kann ich natürlich auch
Konfigurationsskripte mitgeben, die so etwas automatisiert
machen. Aber natürlich hast du und wir
hatten ja auch in der Folge über die Reflexe.
Darüber gesprochen du willst volle Kontrolle über den Rechner
haben und natürlich kannst du dann auch als Developer hingehen
und sagen Ach, das nervt mich ich stelle jetzt mal das den
Script aus was hat das Ding jedes Mal durchführt?
Das können wir natürlich dann vielleicht als zentrale Instanz,
denen das wichtig ist, nicht erzwingen, aber der Vorteil ist,
dass natürlich alles auf der lokalen Maschine möglich ist und
wir jetzt dann nicht an der zentralen Stelle irgendwie
unnötig Last erzeugen oder Probleme für alle verursachen.
Genau das ist ein ganz wichtiger Punkt, also a Ich finde g,
sondern sollen Kontrollen kontrollinstrument, sondern es.
Um Frustration zu vermeiden deswegen finde ich auch ganz
wichtig diese x sollten ganz schnell sein, sollten jetzt
irgendwie kurz n 2 Sachen könnte ich jedes Mal einen 10 Minuten
warten, bis da irgendwie was was durchläuft und du hast es gerade
schon gesagt, einer der Hauptprobleme von G ist einfach
umgangen werden können. Also entweder ich stell sie
einfach auf meiner lokalen Maschine.
Ich kann aber auch wenn ich wenn ich dem Git commit command das
Flag minus minus no Verify mitgebe werden gar keine Gettos
ausgeführt. Deswegen wenn ich das wenn ich
da etwas abprüfen möchte, ob ein Code bestimmten Standards
entspricht, dann muss ich das auf jeden Fall auf meinem Server
im PR chake. Nochmal prüfen also für mich
sind ein Instrument, um Frustration beim bei meinem
Development zu vermeiden, und deswegen hoffe ich auch, dass
das gerne angenommen wird, wenn jemand sagt nee, möchte ich
nicht dann OK von mir aus nicht weil es spätestens auf dem
Server wird es nochmal gegengecheckt sollte es sein wo
sich ein Lokal. Genau meine meine Checks
durchlaufen lassen kann. Vielleicht noch einmal
zusammenfassend wofür ist es gut geeignet?
Also hat es gerade gesagt für sowas Styling, Lenting, Commit
Messages zu checken zu gucken, welche Branchen es werden
verwendet, so allgemein die Coding Styles also alles, was
sehr schnell gemacht werden kann, was ich eigentlich auch
schon als Developer möglichst früh fixen sollte, wofür es
relativ schlecht geeignet ist natürlich alles ist möglich,
aber es gibt natürlich Szenarien.
Da nervt man dann die Developer mehr oder hat ein Problem am
Ende mit der Sicherheit. Wenn man nämlich zum Beispiel
hingeht und Code Security oder Code Ability Scanning auf der
lokalen Maschine über github. Auslöst oder vielleicht Secret
Scanning lokal auslöst, kann am Ende nicht schaden.
Aber bei Security sollte man natürlich sichergehen, dass das
auf jeden Fall gecheckt wird und das sind in der Regel auch etwas
länger laufende Prozesse gerade solche Ability Scanner brauchen
halt einige Minuten und da möchte ich natürlich nicht meine
Developer bei jedem Push auf den Server irgendwie erstmal in die
Warteschleife schicken, bevor sie letzten Endes den Push
durchführen können und das sind Sachen, die sollten auf jeden
Fall müssen auf jeden Fall im CI eingebunden werden, um
sicherzugehen, dass die Security sichergestellt ist.
Wenn ich noch zusätzlich bestimmte Checks auf der lokalen
Maschine den Developern zumuten möchte, dann muss ich mir das
überlegen, ob ich das tue, aber grundsätzlich würde ich eher
sagen für solche sicherheitsrelevanten Dinge sind
github x weniger geeignet, insbesondere weil du vielleicht
auch auf Deiner Development Maschine gar nicht so viel
Rechenpower hast, um halt in wirklich überschaubarer Zeit
solche komplexen Scans auch durchzuführen.
Jahrhundert Prozent also ich kann ja mal gucken, was wir
damit machen also das Einzige was wir damit tun, dass wir
Linden commit messages, das machen wir wir Linden, Brunch
names das machen wir und wir gucken einfach unser.
Codingstyle. Passt und das ist vor allem bei
uns einfach so ne Mischung aus Editorconfig es Lindt und so
weiter was so schnell reden kannst.
Und das ist ganz wichtig zu verstehen, dass diese gibt es
eher eine ja ein Angebot, eine Option sind für die Entwickler
und Entwicklerinnen im Team denn nicht nicht nur können sie oft
umgangen werden, ich gleich mal kurz auf einen funktionieren,
dann versteht man auch so ein bisschen, das gar nicht
standardmäßig jeder Maschine einfach aktiviert ist.
Das heißt es ist nicht so, dass sie ein Repository aus checke
und dann automatisch diese gibt es beim Kommen und sowas
eingeführt werde, sondern ich muss sie mehr oder weniger
aktivieren oder meinen Ordner kopieren, weil es gibt einfach
Umgebungen, die diese diese Titus komplett ignorieren würden
bedeutet wenn ich zum Beispiel. Browser kann nicht einzelne
Dateien nochmal kurz editieren und dann irgendwie einchecken
werden. Überhaupt aufgerufen habe ich
keine Möglichkeit oder selbst wenn ich mir irgendwie eine
remote Umgebung zusammen konferieren Death Container oder
Beta irgendwie spaces oder sowas das by Default haben die meine
nicht installiert und das liegt an folgendem ja Probleme oder
Herausforderungen B Designs sind.
Und das liegt daran, dass es im Punkt Ordner liegen gibt es
nämlich m Punkt Ordner da mal reingeguckt.
Da gibt es einen Ordner Hooks und da gibt es dann für jeden
Hund, der nicht ausführen kann kann ich einen Skript
hinterlegen, das genauso heißt wie d, also wenn ich ein Premium
haben will, muss ich ein Skript hinterlegen, was einfach nur
minus Comic heißt und dem Halt Ausfuhrrechte geben also
trainiert Maschinen C plus X und den Namen der Datei und das
Problem an der ganzen Geschichte ist, dass der Punkt gibt Ordner
nicht Teil meiner Versionskontrolle ist das ist
der wird also da hab ich keine History oder irgendwas drauf,
der ist da nicht Teil von. Als ich muss eigentlich jeder
Developer in meinem Team, in diesem Punkt git Ordner unter in
dem Ordner slash x diese Skripte hinterlegen.
Jetzt ist natürlich totaler Quatsch und deswegen gibt es die
Möglichkeit, dieses Krypto natürlich auch irgendwo anders
einzuchecken also ich kann mir zum Beispiel einen Ordner in
meinem Repository anlegen heißt Food oder bei uns heißt der oft
Punkt Hooks und kann dann mein Lokales geht so konfigurieren,
dass sich die Hooks aus diesem Ordner nimmt, dann kommt sagen
und dann sagen mein Hund passt jetzt nicht mehr Stars also
nicht mehr aus dem Gegner, sondern bitte der Punkt geht
hops Ordner auf meinem root Ebene von einem Repository, aber
dieses Kommando muss ich eben ausführen, einmalig um das
Lokale gibt so zu konfigurieren. Das bedeutet wenn wenn
irgendjemand Neues in meinem Team oder eine Remote.
Umgebung sich mein Gipsy Klont hat es nicht es mag sein, dass
dieser liegt, aber auch dann muss ich einmal g config Core,
Punk, Party und so weiter ausführen, um meinen geht
entsprechend so zu konfigurieren, dass sich aus
diesem. Ordner nimmt das heißt, es gibt
ganz viele Umgebungen, in denen die gar nicht greifen.
Die Hooks können umgangen werden.
Mit diesem Minus minus no Verify Flag das heißt, es sollte
eigentlich eine Hilfestellung sein, um nicht zu häufig einen
failing Check in meinem meinem Pull request Checks zu haben und
früh und frühzeitig eben Dinge. Ja, Dinge zu erkennen.
Du hast jetzt die Möglichkeit, Hilfestellung zu geben, aber wir
hatten ja vorher schon gesagt ist es sehr schwer, ist dann
auch letzten Endes zu erzwingen. Das heißt, es ist wie gesagt ne
Hilfe und keinen Kontrollmechanismus, wenn ihr im
Projekt Chucks einsetzen wollt, ist wirklich gute Idee, die
wirklich mit zu Versionieren im Kontrollsystem aber dann ein
kleines Skript und wie beizulegen die halt diese Konfig
dann für die Developer ausführt. Vielleicht einfach als reminder
hey, wenn ihr zum ersten Mal das Repository Klont, führt dieses
diesen Onliner aus, um halt eure Hooks richtig einzurichten.
Damit ihr halt sicher gehen können, dass bestimmte Checks
lokal ausgeführt werden und da gibt es natürlich ein weiteres
Problem, wenn ich diese Checks ausführe habe gerade gesagt das
ist meistens einfacher Scripte. Dann weiß ich nicht, wie
vielleicht auch irgendwelche Tools, die ich vielleicht noch
gar nicht installiert habe, also ganz klassisch.
Es gibt zum Beispiel Tool, das heißt Clint, Das ist einfach
Kommandozeilentool mit dem kann ich messages Linden das heißt,
ich kann mir Punkt Lind Datei in den Router meines Repositories
legen, wo die ganzen Regeln aufgelistet sind, nach denen ich
meine Commit Messages Linden möchte und wenn ich dann gelingt
ausführen auf der Kommandozeile oder in einem Skript oder wo
auch immer kann ich eben dann meine einen aktuellen oder alle
kommt Messages aktuellen Branches oder sowas linton.
Jetzt, in meinem meinem github Script git Lind Aufrufe und der
Developer oder der die Remote Umgebung durch das Ausführen des
Kling Tool gar nicht installiert hat.
Dann fällt dann fällt natürlich auch dieses Skript heißt ich
muss eigentlich nur die Skripte von meinen gehalten, sondern
muss auch irgendwie zu verwalten, die darin verwendet
werden und ihr merkt schon. Das ist so komplex, dass sich
dann natürlich schon mal Gedanken darüber gemacht hat,
das zu vereinfachen und da gibt es eine ganze Menge Tools da
draußen, die einem so n bisschen helfen, geht es einfach zu
machen. Ich glaube das am weitesten
verbreitet ist Husky. Das ist ein Tool, was besonders
beliebt bei bei Java Script Projekten oder bei Halo Jazz
Projekten, weil ich da einfach in meine Package Punkt Jason
Datei auch eintragen kann. Das heißt, ich kann ich
verwandelte E schon Meyer dependency Dependencies also
sowas wie geht Lind oder EC Lind oder was mir irgendwie Clint
kann ich natürlich dann e über meine Dependencies in der Page
Punkt Jason Verwalten und Husky konfigurieren, dass sich die
Skripte oder einfach das dann ausgeführt werden soll.
Bei Prequel mit bei Pre Push und so weiter.
Auch in dieser Passage Jason verwalten kann.
Ist sehr beliebt, hab ich nicht so gerne verwendet aus dem
Hauptgrund, dass es sich halt einfach, dass es braucht eine
Jason und j habe oder sowas dann hab ich die nicht klar könnte
ich die auch haben, aber es integriert sich sehr in diese
neue javascript Welt. Ich bin irgendwann Tools sehr
cool, finde und das heißt Preco mit und bei Preco mit ist das
Land kommandozeilentool kann ich halt geht hohes aller Art in
einer zentralen Datei managen und auch dessen oder deren
Dependencies, das heißt ich kann mit Pre commit sagen Hey hier,
ich verwende git Lind und gib Link kriegt man übrigens da und
da her und das heißt meine Developer müssen, wenn sie
meinen Repository auschecken nur einmal preco mit Install
ausführen und der holt sich dann sowohl die ganzen Dependencies.
Die meisten verwendet werden. Als auch konfigurierter
Manipulator, so dass er diese Skripte dann eben
zusammenbastelt und in den Punkt Slash Ordner kopiert ohne und
das coole ist auch, dass ich das selbe Tool dann auch quasi
verwenden kann, um in meiner CI nochmal zu checken, ob diese
Regeln nennen verwendet wurden also das absolute Empfehlung von
Precor mit einzusetzen. Also alles, was wir gerade hier
nennen ohne nochmal verlinkt aber damit kann ich sowohl meine
Chucks konfigurieren und dafür sicherstellen, dass Dependencies
eben lokal installiert sind auf der Maschine.
Als auch nachher Checks durchzuführen ob das auch
wirklich verwendet wurde? Ich hab da mehrere Blogspots
gefunden, ich schreibe aber gerade nochmal in einem, weil
ich weil ich das irgendwie nirgendwo so richtig gut
zusammengefasst bekomme. Das heißt sollte ich das
schaffen, diesen blogspot jetzt noch rechtzeitig zu schreiben
und zu Publishen findet ihr nochmal in die Ultimate Guide to
go. Da würde ich alles, was ich noch
mal zusammenfassen, auch von der Chain.
Ist das meine Empfehlung? Ich würde wahrscheinlicher,
dieses Skript da nicht selber einchecken, sondern sowas wie
git wie bekommt oder Husky verwenden auch ein ganz
spannendes Projekt ist von paar Jahren nicht vor 2 Jahren von
github Open Source worden, nennt sich super.
Linter ist ein Tool für diverse Entwicklungssprachen.
Also ist halt alles von Infrastruktur als Code Templates
über C Sharp Java Script ist alles in einem.
Schul drin funktioniert halt sowohl in C Systemen als auch
lokal, wenn man das möchte primär gedacht für das CI System
aber durchaus wenn man sich mit diesen Tools auseinandersetzt,
durchaus mal etwas was man sich angucken kann.
Wenn ich spannend, weil wir bisher irgendwie so ein
Mischmasch haben? EC Link Wir haben.
Es lint wir haben. Was haben wir noch, wenn
Prettier und die ganzen Sachen also eigentlich ist da auch Zeit
für Konsolidierung stimmt? Ja, das ist eigentlich das geht
x zusammenfassend vielleicht sogar die irgendwie gemerkt
haben? Bei uns ist also ich finde immer
toll und verlässlich sein, sonst habe ich einen Showdown in
meinem normalen Zyklus und das führt auch immer zu
Frustrationen, also mal eben schnell irgendwas checken und
ich sollte mir gut überlegen Check ich wirklich bekommt oder
Check vielleicht bevor ich pushe also muss muss jeder meiner
commits Code enthalten, der sauber baut, wo die Tests
durchlaufen und die Decoding stimmt oder muss ich einfach
wenn ich pushe? Einen Stand haben, der baut wenn
überhaupt wenn überhaupt, würde nuscheln und das gleiche gilt
für Tests auf meinen Style nicht j richtig gestylt ist das
wichtigste am Ende. Das was ich da pushe vom Brunch
richtig gestylt ist, hängt wahrscheinlich n bisschen drauf
an was für ne Mergim Strategie ich habe, wenn ich Squash commit
habe, ist mir egal, wie die Comics vorher waren, wenn ich
die ganze eigentlich die 1 Komma behalte, dann will ich
vielleicht damit richtig gelistet ist da kann ich mir ein
bisschen überlegen und das zweite Thema, das fand ich immer
ganz wichtig bei dieser Recherche.
Das ist aber meinungsfrage können uns auch gerne mal sehen,
was ihr dazu meint oder wie ihr das seht.
Ich finde also meiner Meinung nach sollten gibt es nichts
verändern, sondern nur validieren.
Es gibt Menschen, Repositories und Projekte da draußen, wo.
Die geht einfach automatisch die Coding Styles machen oder
einfach automatisch, also auch Dateien verändern und das dann
einfach einstecken und das fühlt sich für mich irgendwie nicht
richtig, dass dieses eine andere Datei eingecheckt wird, die
gerade eben habe. Kann natürlich so ein
Convenience Feature sein, dass ich sage das ist ja nicht das
verändert ja nix, aber generell finde ich, dass diese Hooks nur
checken sollten, also nur verlieren sollten.
Und nichts verändern sollten und mein Dritter und letzter Tipp
wäre immer es nochmal Richtung Performance, wenn man so Files
checkt, dann reicht es ja eigentlich nur die Änderungen zu
checken, also was die meisten Tools ja machen, wenn ich jetzt
so e oder irgendwie so n. Sonst k Aufrufe, dann wird das
ja aber alle Dateien aber lassen und ich sag mal 90% Dateien boy
hab ich gar nicht angefasst sollten also cool sein.
Und ich sollte eigentlich nur die Stage Changes checken, also
nur die Änderungen, dann noch mehr Performance e rausholen
wenn ich nur 10 Dateien checke oder 20 Dreiecke, die vielleicht
gerade in diesem angefasst wurden und nicht das Ganze durch
ein komplettes Reboot laufen lasse, vielleicht noch eine
ergänzende Sache, die ich ganz spannend finde ist, dass das
ganze ja immer im Zusammenhang mit internen Style, Guidelines
und Konvention steht. Das heißt man hat nicht nur die
Skripte und die Hooks, sondern hat halt auch seinen Dokument wo
alles dokumentiert ist, welche Coding Styles verwendet.
Man verweise ich nochmal auf. Ich glaube es war Folge 2 die
wir aufgenommen haben, wo es um Coding.
Es ging aber auch zu Themen wie die Definition wie Commit
Messages aufgebaut werden sollen und wie ich halt auch auf
bestimmte Workitems referenziere.
Das muss natürlich alles klar dokumentiert sein und erst, wenn
ich das erarbeitet habe, kann ich überhaupt den nächsten
Schritt machen und das Tooling einführen.
Spricht diese ganzen Link Tools in Place bringen die dann
letzten Endes auf Basis der Detox laufen?
Das heißt erster Schritt ist erstmal zu dokumentieren was
möchte ich erreichen? Und im zweiten Schritt die
entsprechenden Tools zu etablieren und am besten auf
keinen Fall? Den zweiten Schritt nach dem
Ersten machen, weil natürlich bringen alle diese Linter, die
man dann über Gips einbinden kann, irgendwelche Standard
Settings mit, aber ihr müsst als erstes mal hingehen und euch mit
dem Team auf einen Standard einigen, weil letzten Endes dann
alle das gleiche Skript laufen lassen und auf dem gleichen
Standard sein werden und damit müssen natürlich auch alle
irgendwo einverstanden sein beziehungsweise es akzeptieren,
dass alle auf diesem gleichen Standard arbeiten.
Genau da hilft. Da helfen natürlich auch so
opinionated Story ja gar nicht verändern kann sowas wie hier
aber dazu höre ich am besten einfach die Folge an, im
Idealfall die beste Vorbereitung für g, sich für die letzten 62
du kannst folgen einmal durchzuhören.
So die wir eingegangen sind wahrscheinlich ganz gut
beschrieben, ansonsten freut uns natürlich auch, wenn diese
hilfreich findet, lasst uns gerne Feedback zu da wie schon
eingangs erwähnt es fand auch viel Kaffee einladen wollt, dann
könnt ihr das unten gerne tun, wenn ihr Meinungen zu gittys
habt, könnt ihr das natürlich auch gerne mit uns teilen.
Wir freuen uns über Kommentare. Wir freuen uns über Mails, lasst
uns da gerne Feedback, da auch wir generell diese Folge findet
und was wir insbesondere toll finden, sind natürlich
Bewertungen auf Apple Podcasts. Da sieht es aktuell noch ein
bisschen mau aus. Also wenn ihr uns auf einem
Apple Device hört über Apple Podcast Last auch gerne.
Eine Bewertung da wir freuen uns nicht nur über jeden Stern,
sondern auch über euer Feedback. So ist es, dann bleibt uns
glaube ich nichts anderes übrig, als uns wieder zu verabschieden
danke, dass ihr dabei wart und zugehört habt.
Wir hören uns in 2 Wochen wieder der Lukas erscheint alle 2
Wochen montags, bis dahin schreibt ganz viel Code hab ne
gute Zeit und bis ganz bald bis dahin.