[Musik]
Du Nico, die wollen jetzt auf der Arbeit, dass ich programmiere.
Das muss ich also ein bisschen vernünftiger machen als bei meinen Apps.
Da musst du mir helfen.
Okay, ja.
Du darfst da keine Bugs reinbringen.
Okay, ja, jetzt kriegen wir das hin.
Das wird auch unser Thema heute.
Wir reden über, wie man Bugs findet und wie man die backt.
In Folge 14 vom App Store-Tagebuch.
Richtig, aber vorher kommen wir erstmal zu Nachrichten.
Und der Holger hat uns auch schon was mitgebracht.
Er hat verkünden lassen, dass es für Mac OS auf Apple Silicon, also M1 und zukünftiger Apple Silicon Max, keine Kernel Extensions mehr geben wird.
Und man soll stattdessen ein neues Tool benutzen, eine sogenannte System Extension.
Ich glaube der Unterschied bei diesen beiden Sachen, also Kernel Extensions, sind ja so eine ganz tief in Mac OS dann eingreifende Erweiterung, die ein Entwickler schreiben kann, wenn er irgendwie einen besonderen Treiber schreiben möchte.
Und das Besondere bei denen ist wohl, dass die überhaupt nicht bei der Speicher Sicherheit beachtet werden.
Und unsigniert laufen, glaube ich, sogar, also auf jeden Fall sehr gefährlich für das System, aber man sollte sie nicht benutzen, wenn man nicht weiß, was man macht.
Und das neue System System Extensions ist da halt wohl besser.
Und deswegen wird man das in Zukunft noch benutzen dürfen.
Also ich habe, glaube ich, mein erster Berufspunkt war mit Kernel Extensions, als ich damals, bevor ich überhaupt noch irgendwie auf Mac war, von meinem iPhone 3G und dann irgendwie auf die Idee kam, hey, ich kann mir auf meinem Median-Netbook, was das damals war, ein schorottiges Teil Hackintorschdorf installieren konnte.
Und da weiß ich gar nicht, wie wild Kernel Extensions installiert sind.
Und ich wusste gar nicht, was es ist und was es tut und habe einfach nur den Tutorial gefolgt.
Wahrscheinlich einfach das, was Sie im Forum verlinkt haben, hast du untergeladen und installiert.
Und man das halt macht früher.
Ja, aber auf jeden Fall ein guter Schritt zu sehen, dass da in Punktensicherheit etwas vorangeht und nicht mal Löcher ausgemacht werden.
Genau und so häufig, also ich glaube nicht, dass ich irgendeine Kernel Extensions installiert habe, aber so häufig braucht man die ja, glaube ich, auch gar nicht.
Ja, ich glaube, das ist wirklich ganz, ganz speziell hart, weil das kann natürlich sein, dass das irgendjemand hat, so ganz, ganz speziell hart, die noch, die wahrscheinlich auch extrem teuer war, die an meiner Kernel Extensions kam, aber wo der Entwickler auch nichts mehr für macht.
Das ist natürlich doof.
Ja, ok, dann kommen wir mal zum nächsten.
Mittlerweile ist jetzt iOS 14 auf 85 Prozent aller Geräte.
Das ist schon krass, oder?
Das ist gut, ja.
Das ist ja bei den Appleträten häufig so, dass die Updates relativ schnell laufen, außer denn es wird irgendwo in der Tagesschau vor allem geplant oder sowas, weil jemand es nicht toll findet.
Wenn WhatsApp nicht mehr läuft, dann will man nicht mehr updaten.
Ja, das ist auf jeden Fall sehr cool, finde ich, weil es zeigt, zeigt man auch als Entwickler, man kann weitergehen und muss nicht, sage ich mal, jahrelang oder zu lange irgendwelche alten Dinge unterstützen, weil im Prinzip ist auch in der Code-Basis Dinge erfordert, die hässlich sind und umständlich sind.
Ja, halt, ich eigentlich einen kreativen Entwicklungsarbeit von hey, ich will ein gutes Feature machen, muss aber noch einbauen, ja, es geht auf iOS 12 nicht, weil, was weiß ich, was benutzt, irgendwas Neues.
Ja, man kann halt einfach Zöpfe abschneiden.
Ich habe letztes Mal erzählt, dass ich auch jemanden hatte, der auf meiner Apple Watch 1 noch benutzt hat und ich muss Zöpfe abschneiden und habe gesagt, ok, jetzt ist WatchOS 6 Minimum und dann, oh, ein Stern mal ganz böse.
Ja, das haben wir in der Stackoverflow-Folge auch, da wo ich eine Sache von der Tabelle, in so einer Search Bar irgendwann mal gesagt habe, wie das unter den alten, alten Aggressivitäten geht.
Aber sowas brauchen wir halt nicht mehr machen, das ist schon ganz gut.
Ja, das ist auf jeden Fall gut und dafür, dass es auch wirklich ein großer Vorteil an Apple ist, dass für Entwickler, dass das so zügig vorangeht, den Update.
Auf jeden Fall.
Weil halt auch das System, die Leute eigentlich schon gängelt und sagt, ey, hier gerade update, aber bitte.
Wenn es überhaupt noch facht, nämlich auch häufig ist es ja, glaube ich, die Vollteilung sogar so, dass es sich einfach mal an einen update tut.
Was ich auch gut finde, also ich habe keine Probleme mit.
Ja, ok, nächstes Thema, die DK, die will eventually wieder mit, Apple wird jetzt wirklich zurückkommen bis zum 31.3.
Bezahlen die auf das Porto oder musst du selber bezahlen, Porto?
Woher weiß ich noch gar nicht, ich habe noch nicht geguckt, ich habe gestern noch vergessen, die E-Mail gekriegt, also sie wollen jetzt wirklich zurückkommen.
Also nicht erst zum Ende des Jahres und dann kriegt man seinen 500 Dollar-Gutschein, was ich glaube umgerechnet 417 Euro sind. Also ich mache ein bisschen Verlust und darf dann Apple noch irgendwann bis zum Ende des Jahres für alle möglichen Apple Produkte bis auf Gutscheinkarten und weiß nicht was, war es noch mal ausgeschlossen.
Ah ja und Apple Care kannst du nicht damit kaufen und du kannst nicht sagen, ok, ich kaufe jetzt ein paar Airpods und den Rest, weiß ich nicht was, ne, das muss die 417 Euro, die 500 Dollar überschreiten.
Ok, also 5 Jahre iTunes-Abo-Nummer oder so was, das geht auch nicht, ne?
Das glaube ich nicht, ne. Also du musst online bestellen und kannst den da irgendwie lösen.
Heißt Neubau weg für dich?
Nö, ich kann auch für andere Dinge verwenden und ich hatte eh mal überlegt mir ein iPad zu holen, einfach aus weiches, eigentlich mit diesem, jetzt auch so aus so ein bisschen von 3D-Druck-Videos und so, da gibt es dann so ein paar echt coole Tools, die du ein bisschen auch Konstruktionskram machen kannst und mit Stift und so, wo ich dann eigentlich so gedacht habe, ich sehe das Ganze nett aus und ja, ich habe schon wie gesagt seit dem ersten iPad kein iPad mehr gehabt und finde das eigentlich ein cooles Gerät. Leider fehlt mir halt auch immer die Zeit um die ganzen Dinge zu bespielen, irgendwie man hat sein Handy und den Laptop und dann hier und Playstation und den Fernseher und den Apple TV, also man kann gar nicht, man steht ja noch und irgendwie haben wir gar nicht so viel Zeit.
Ja, aber so ein iPad zum Zeichnen, das war schon ganz cool und zum Lesen und so, generell zum Konsumieren, also Konsumieren und Zeichnen kann man doch ganz gut drauf haben.
Ja, das war es eigentlich zum DTK. Ich habe noch was.
Ganz ehrlich, hast du das eigentlich wirklich benutzt? Das DTK?
Ne, nicht wirklich, weil im Prinzip meines in einem broken state war, bis ich jetzt vor drei Wochen nochmal, also ich konnte es ja nicht updaten, ich hab es am Anfang mal benutzt und dann hieß es hier updaten updaten und bei mir lief die Xcode 12 Beta 1 drauf, super buggy halt und ich habe versucht abzudetten und das horriblt gefailed an so vielen Stellen, bis ich dann, ich habe ja mehrere Sys-Diagnosen an Apple über die Feedback abgeschickt und ja, geschrieben geht nicht, geht nicht, geht nicht, da braucht es noch ein bisschen Zeit.
Da habe ich monatelang nichts getan, ich habe dann auch nicht mehr reingeguckt, weil ich dachte, das ist mir zu doof irgendwie.
Dann schick das gar nicht zurück, dann sagst du, du hast das Füten aus dem Fenster geschmissen.
Ja, aber ich weiß nicht, ob man da vielleicht in zehn Jahren auf Ebay und für irgendeinen blöden Sammler und so, aber ich weiß nicht, wo ich mir lieber jetzt die Kohle wieder, nicht dass wir da jetzt noch aufs Dach steigen und sagen, du musst das Ding zurückgeben.
Wenn ich schon mehr mit in den Accounts wäre, das wäre natürlich ganz schlecht und das möchte ich nicht, weil da hängt halt schon ein bisschen was dran.
Ja klar.
Und das ist mir nicht wert, deswegen gebe ich es schön brav zurück.
Noch zurück zu dem, wir haben ja noch mal geschrieben, vor drei Wochen irgendwie so, ja, update mal dein Feedback und prüfe mal, das war mir jetzt auch zu doof. Nach dem ganzen RCK-KIA, ja, ihr kriegt 200 Dollar und schönen Tag noch. Jetzt ist es auch schon fast vorbei, was soll ich da jetzt noch updaten? Jetzt kriege ich meine Kohle zum größten wieder. Dann ist das auch gut. Für die nächste DTK, weiß ich nicht, muss man mal gucken, ist das jetzt eine Entwickler-Community, ein bisschen umgesprochen, wie sich das abgelaufen ist und ja, gucken wir es nächstes Mal durch.
Na, das war es mal beim vorherigen, bei der Intel-Transition bekommen hat, das hat man ja diesmal nicht bekommen.
Ja, da war Apple noch kleiner und nett und mittlerweile sind sie groß und gierig.
Dann kommen wir zum nächsten Gear-Thema, da geht es um Werbung und zwar auch in eigener Sache und ich habe auch, ich weiß nicht, wie man iPhone-Ticker kennt, das ist eine deutsche News-Webseite zum Thema Apple und Mac und so weiter.
Die haben auch in eigener Sache über diesen IDFA, diesen Advertising Identifier, den Apple jetzt seit 2014, fünf enforced für App-Entwickler, dass du als App-Entwickler fragst, hey, dürfen wir dich tracken?
Und da hat auch, weil die iPhone-Ticker-App selber auch Google-Werbebanner drin hat, hat dasselbe Problem getroffen und die müssen natürlich ihr das anzeigen. Da ist die ganze Namensgebung ein bisschen schwierig, weil im Prinzip trackst du ja nicht als Entwickler, sondern eigentlich dein Werbenetzwerk, was du einbindest und ja, im Prinzip, ich als einzelner Entwickler oder, weiß nicht, die auch als Entwickler sind gar nicht an Tracking-Informationen wirklich interessiert, das geht ja nicht nur. Diese IDFA wird dazu benutzt. Angenommen, du kaut in App A, kriegst du ein Werbebanner für App B zum Unterladen, dann lädst du über diese Werbebanner App B runter und dann erkennt dich die B-App sozusagen, dass du von A gekommen bist sozusagen, das ist das Tracking, was die da machen.
Also das war ja auch schon diesen Identifier, da konntest du ja schon seit iOS 11, 12, weiß nicht genau, konntest du den schon zurücksetzen als in den Privazeiten einstellen und so sagen, hier, mach mir eine neue Nummer und dann wurdest du schon, komm, das ist nicht mehr getrackt werden.
Und jetzt musst du halt als User wirst mit einer sehr, sehr angstlösenden Nachricht, so ja, hier Tracking erlauben oder nicht erlauben. Und das ist halt, ich kenne es selber bei mir, ich drücke immer auf ne.
Und auf jeden Fall ganz nett, aber du überlesen muss ich ich habe mich jetzt auch mit meiner App bei mir ist noch nicht drin, solange ich jetzt keine Arbeit hochschiebe, muss tauchte auch nichts auf, aber ich muss mich darum kümmern und es ist stressige Arbeit und Apple eigentlich damit irgendwie forciert, weil an der Werbung verdienen sie nichts und sie wollen nicht eigentlich in den Modell rein drängen, auch als Entwickler.
Ja, also ich habe ja bei meinem Game Collect auch die Google jetzt drin und also mich stört es halt schon, dass jetzt im App Store auch drin steht, die App trägt dich, obwohl ich die App nicht trägt, also ich trägt die Leute ja gar nicht.
Das ist ja schon so, dass ich gar keine Daten von den Leuten spreche. Und jetzt überlege ich, ob ich will raushauen. Ja, ich würde halt, ich müsste doch jemanden Werbnetzwerk machen, so hier ist "Socially Accepted", das ist ich, Öko Netzwerk, schieß mich tot. Was hat aber gesagt, okay, wir liefern random Werbung aus, keine Tracking-Mechanismen, wahrscheinlich ist dann Revenue nicht ganz so gut oder wer weiß, wer wäre ganz gut, wenn es so was geben würde.
Gab es ja eigentlich mal von Apple, nannte sich iELTS, dann haben sie aber eingestammt. Ja, da haben sie sich glaube ich auch ein bisschen was anderes vorgestellt, als sie das gestartet haben. Die wollten ja nur High Quality iELTS haben mit irgendwelchen Spielen integriert, aber das hat ja auch keiner interessiert, also auch keiner, der die Werbung gesehen hat.
Ich hatte es ja eine Zeit lang benutzt und wollte mich auch nicht mehr, weil es dann auch tot war. Und sie haben mir auch ein bisschen gut haben geschenkt, dass ich ein bisschen selber 200 Euro sogar, das war echt viel, das kannst du selber auch werben.
Ja, das war es zu dem. Dann würde ich sagen, fangen wir mal an mit unserem heutigen Thema.
Ja, und zwar heute soll es ein bisschen gehen, um Bugs zu finden, um die dann halt auszumerzen, damit die Software wieder runterläuft.
Ja, am besten einfach keine Bugs schreiben und das war's dann für diese Woche. Ciao.
Ja, die Bugs entstehen halt häufig, weil man kann halt nicht an alles denken. Die Software macht halt Sachen, die man zwar gesagt hat, dass sie machen soll, aber man weiß halt nicht genau was.
Gerade wenn man User-Input-Content hat oder mit irgendwelchen Server-Generatoren können halt Sachen kommen, an die man nicht gedacht hat.
Ja, und das passiert den besten und da braucht man sich ja keine Sorgen machen. Also was natürlich immer hilft, ist dagegen viel, viel testen, die App selber benutzen und in allen möglichen Kombinationen und was auch immer man machen kann testen, dass man sowas halt auch rauskriegt.
Ja, das ist immer gut und mein Chef sagt immer, wenn man ihm eine App in die Hand gibt, er kriegt sie dann schon. Das ist dann wie, als wenn du dein Handy in den Hafenküftchen reinschmeißt und dann wird viel drauf rumgetascht.
Vielleicht kann ich immer meine Apps geben.
Ja, aber es ist immer witzig, wenn man eine App anders benutzt, als sie gedacht ist.
Aber es ist eigentlich auch ganz gut, dass es jemanden ist, der eigentlich auch gar kein Interesse hat an so einer App, die erst mal in die Hand zu geben. Also, keine Ahnung, Freund, Frau, wie auch immer.
Ja, ja. Okay, was ist denn das Einfachste, mit dem man die Bugs benutzen kann?
Das Einfachste, was ich tatsächlich viel zu häufig benutze, ist, Logs zu schreiben. Also, wenn der Code läuft, den Aufruf bei einer Funktion, wenn ich mich wundere, warum irgendwas nicht funktioniert und ich eine Funktion geschrieben habe, die hat diese Funktion eigentlich machen soll, die ich da haben möchte, dann schreibe ich halt am Anfang von dieser Funktion einen Log mit rein, sodass ich in der Konsole, das ist ein kleines Feld in Xcode unten, dass ich dort sehen kann, ob diese Funktion überhaupt aufgerufen wird oder nicht. Und wenn ich der eine Variable übergebe oder die eine Variable generiert aus irgendeinem Grund, dann könnte man die auch mit reinschreiben in diesen Log. Dann könnte man sehen, aha, hier, der hat die Funktion addieren aufgerufen und zwar mit den Werten X und Y, aber der hat nicht X plus Y hinterher abgegeben, sondern irgendwas anderes.
Dann kann man nachgucken, aha, da liegt wohl irgendwo der Fehler.
Ja, und das ist auch so die simpelste Methode, um zu debuggen, wenn man sich einfach Nachrichten für sich in den Code reinschreibt, während das Programmfluss sozusagen auf die Konsole geprintet wird.
Habe ich auch nachgedacht, weil man muss halt das Telefon mit dem Xcode verboten haben, sonst sieht man die Sachen nicht.
Richtig, ja, aber es ist ja, wenn man entwickelt, auf jeden Fall immer dieses Ding, dass man einfach, habe ich auch genug Print Statements für, ja, hier, weiß ich nicht, hat funktioniert, dies das. Was ich auch immer gerne mache, ist dann Emojis reinpacken, weil dann kannst du irgendwie logisch Dinge gruppieren, weiß ich nicht.
Das ist für, keine Ahnung, für, weiß ich nicht, du willst eine Mail in der App verschicken, dann machst du ein Briefsymbol davor oder hier ist ein Fehler passiert, dann machst du ein X oder weiß ich nicht.
Oder es ist gut, gut gewesen, dann machst du den grünen Haken, dann kann man das auch schnell in der Konsole sehen.
Ja, also Print kennt man bestimmt den Ausdruck in Swift, früher, ob man das sieht, dieses NSLog, NSLog kann man auch immer noch benutzen, ist halt alter Kram, sollte man vermeiden. Was das ganz neue eigentlich ist seit, ich glaube iOS 12 oder 13, wenn man das so sieht, 2020, nee, das ist eigentlich erst seit letztem Jahr oder vorletzend, wenn man unsicher ist, nennt sich OSLog, also OS-Log, ist quasi eigentlich das aufgebohrte Logging Framework von Apple, mit dem man auch, also ich habe es jetzt ja auch mal nicht schon ausgeschrieben, also ein OSLog, kann man aufschreiben, dann schreibst du deine Nachricht, weiß ich nicht, x ist gleich ein Objekt, Punkt Description und so weiter und dann sagst du, dann kommt der nächste Parameter, der heißt Punkt, der Log und dann sagst du, okay, OSLog.deaf, wo ist das?
Du kannst also deine Logs in verschiedenen Levels unterteilen, zum Beispiel in Debug, in Info, in Error, in sonst irgendwas, die dir dann auf der Konsole ausgepültet werden, du kannst das dann irgendwie auch anbinden und dir in Logfiles schreiben, also dass du dir Logs, die auch was du in der Konsole siehst, geschrieben wird, kannst du so machen, dass es parallel in eine Datei geschrieben wird, die auf dem Gerät abgelegt wird, halt irgendwo in deinem App-Container und die man dann theoretisch irgendwie auch wieder rausholen kann über, was weiß ich für mich, alles mögliche bauen, per E-Mail verschicken, per AirDrop, per sonst irgendwas zippen, man kann alles möglich machen.
machen. Dieses Ding ist auch wie Apple sagt sehr performant. Also das ist ja auch immer das, wenn man mehrere Logging Geschichten anbindet, dass das natürlich auch auf die App Performance gehen kann und Apple hat das so gut so performant wie möglich gemacht, dass du da loggen kannst, ohne dass deine App beeinträchtigt wird. Also auch im Arbeitskontext benutzen wir das sehr sehr viel und das ist auch sehr wichtig, wir machen Automotive Apps, und wenn dann irgendwelche Leute die Apps testen und so weiter, da kommen dann Backreports, die müssen sich die Logs exportieren und die kommen dann in einen Ticket rein und dann werden die Logs genau analysiert und da muss auch wirklich viel, also es ist schon wichtig, dass man viel loggt und damit viele Informationen hat, die man später zum ja im Prinzip eigentlich wie wenn du Mord aufklärst, um je mehr du loggst, umso mehr bewahrtest du.
So was in logg Dateien habe ich auch schonmal gemacht, ich weiß nicht, entweder habe ich ns log umgebogen, dass es in der Datei geschrieben hat oder ich habe print umgebogen, dass es in der Datei geschrieben hat und weil ich irgendwas auch unterwegs testen wollte und habe mir die dann angeschlossen an xcode und dann runtergezogen. Natürlich wenn du das bei mir auf dem Usergerät loggst, dann kannst du dir nicht sagen schick mir mal dein iPhone her, damit ich das hier anschließen kann, sondern das ist richtig, wenn der Supportbutton drückt, dann muss die Loggfile irgendwie mitgeschickt werden.
Was sich noch dazugehört ist, was man natürlich mit aufgebohrten Bloggingen und viel mehr macht,
kann man natürlich auch sich in dem Blog, wenn man nur Print macht und steht einfach nur der Texteck,
ausgeprintet werden soll, man kann natürlich auch in so, in das Logging einbauen, okay, zeig mir die Methoden an, zeig mir die Zeile an,
zeig mir die Uhrzeit in, weiß ich nicht Millisekunden an und so weiter, Emojis hatte ich schon gesagt.
Sowas kann man da alles reinschreiben und ja, wir haben uns auf der Arbeit auch Tools gebaut,
dass wir hatten zum Beispiel Signale gelockt, die wir dann interpretiert haben und die haben uns zum Beispiel einen Logtracer gebaut,
der dir dann die Signale visualisiert hat, das heißt du hast die Logfile genommen, hast sie in diesen Logtracer reingeschmissen und hast dann gerade bekommen, wie ja hier, ah, da ist das passiert zu dem Zeitpunkt, da ist das runter hochgegangen und kannst dann genau sehen, wie es im zeitlichen Ablauf, weiß nicht, sieben Signale passiert oder so, also da kann man extrem viel machen und ist auch wichtig, das zu haben, egal, also umso komplexer natürlich eine App wird und umso mehr Leute dran arbeiten, umso wichtiger wird es, sich Logging zu bauen, wenn man jetzt an einer kleinen App baut, ich glaube dann reicht auch Print, das mache ich in meinen eigenen Apps, übertreibe ich es damit auch nicht, ja, das muss man jetzt aber wissen, wie weit man das braucht.
Ja, dann kann man auch so Breakpoint setzen, so eine zweite Methode, die ich ab und zu benutze, wenn ich halt was neu schreibe und ich nicht hundertprozentig sicher bin, wie der Code funktioniert, den ich da geschrieben habe, dann kann man in Xcode halt neben der Zeile klicken, dann kommt so ein Böppel hin und dann, wenn man die App dann auf ein Gerät startet oder auf ein Simulator startet, hält der Code an dieser Stelle an und dann kann man halt auch einzeln weiterspringen bis zum nächsten Breakpoint oder in die nächste Zeile und was ich ganz praktisch finde ist, das dauert bei meinem Rechner so nach 20 Sekunden oder so was und danach kann man über die Variable im Code gehen und kann sehen, was in diesen Variablen zu dem Zeitpunkt des Breakpoints ausführen,
was drin stand und das finde ich echt praktisch, also wenn du halt dich wundern, warum keine Ahnung, der die X+Y nicht funktioniert hat, dann kannst du vielleicht sehen, dass in Y gar nicht drin war, was in Y drin sein soll.
Ja, also Breakpoints ist auf jeden Fall ein sehr wichtiges Werkzeug, mit dem man umgehen lernen sollte, weil es einfach sehr powerfulles Tool ist, also wie du schon sagtest, dass man das an einer bestimmten Stelle im Code setzt und sozusagen das Programm zu dem Zeitpunkt dann anhält, wenn er an dieser Zeile vorbei läuft, hält er an, deine App wirklich freest auch, also du bist auf einem Screen, die App bleibt dann wirklich da stehen, dein Xcode braucht eine Sekunde, bis du dann sagst, ok, jetzt hab ich's gefunden und dann kannst du auch wirklich in den Speicher gerade reingucken, also wie du schon gerade gesagt hast,
man kann die einzelne Variablen angucken, man kann, da gibt's dann so einen Debugger neben der Konsole, ich weiß jetzt nicht wie es heißt, auf und dann kannst du auch gucken, ok, wie sieht mein Objekt gerade, wie sieht self aus, wie schauen meine Scope Variablen aus, was steht da gerade drin, die kann man aufklappen, kann sie rechtsklicken, sich Descriptions ausprinten lassen, man kann da deutlich mehr dann einsehen, als wenn man irgendwas ausprintet, klar kann man sich das auch alles ausprinten, aber man hat einfach einen schnelleren Überblick über den State, der gerade in deiner App ist.
muss man nicht wissen was man sich ausprobieren kann. Okay, irgendwas auf die ganze ganz ganz schief.
Ich mach mal hier stopp und gucke mal alles nach und nach ein und guck mal ob da irgendwas was nil ist, was nicht nil sein sollte oder so.
Sagt dir, sagt dir PO was? Nein.
PO heißt Print Object und im Prinzip kannst du, wenn du einen Breakpoint, ähm, wenn der getriggert wurde und du da stehen bleibst, dann kannst du nämlich unten in deine Konsole da wo deine Logs reingeschrieben werden, kannst du selber Commands rein schreiben, hier auf der Command Line.
Und PO heißt Print Object, P heißt Print, dann im Prinzip kannst du, du hast deine ganz eigene unten sozusagen ne Kommandozeile, in der du Dinge ausführen kannst.
Also mit P, wenn ich jetzt P mache, kann ich eins plus drei reinschreiben und dann wird mit vier ausprobieren. Zum Beispiel kannst du ganz simple Dinge machen, aber mit PO kannst du zum Beispiel Self ausprobieren und dann sagt dir, okay, ah Self ist, äh, u-Controller, Speicheradresse, so.
Wenn es gerade nicht aufgeschrieben wird, kannst du dann, okay, PO self.welcome-label.text und dann printet er dir aus, okay, der Text steht da drin.
Und dann kommt man halt auch teilweise an Dinge rein, die man jetzt über diesen, äh, weiß ich nicht, visuelles Ding, wo du dann Sachen ausklapsst und guckst und so weiter, kommst du dann besser an Dinge ran.
PO ist ungefähr dem Command, der sehr wichtig ist, dass man halt wirklich gut debacken kann und dann kann man auch, gerade wenn man irgendwie merkt, oh, weiß ich nicht, ein komisches Verhalten und dann kann man mit PO auch gucken, okay, ist das ein Objekt, was ich denke, dass es die selbe Speicheradresse ist, wie das, was irgendwo anders referenziert ist und dann merkst du vielleicht auch so, ah, das ist dieselbe Klasse, aber das ist eine unterschiedliche Speicheradresse, das heißt, es sind zwei Instanzen da und dann wurde kopiert und nicht referenziert und dann, ja.
Genau, also mit PO kann man da sehr, sehr viel rausfinden.
Ähm, ja.
Hast du schon mal einen, sag dir einen Symbolic Breakpoint, was hast du schon benutzt?
Hm, ich glaube nicht.
Okay, aber so Constraints, Warnings, also zu UI-Volumes.
Aber da hab ich keine Ziele bekommen, das da. Okay, das hast du schon mal gesehen und dann gibt's auch immer von Apple eine Nachricht, die sagt dir, hey, mach einen Symbolic Breakpoint auf UI-View Alert for unsatisfiable Constraints.
Also du kannst eigentlich dir einen Constraint, also einen Breakpoint setzen für ein Symbol, was irgendwann mal aufgerufen wird und also UI-View Alert for unsatisfiable Constraints ist irgendeine Methode von Apple in UIKit, die getriggert wird, wenn Constraints kaputt gehen, sozusagen damit du die Lockmessage auf die Konsole kriegst und du kannst dir dann sagen, okay, und wenn diese Funktion getriggert wird, dann möchte ich bitte, dass mein Programm stehen bleibt und du kannst halt sehen, ah, und an der Stelle, an der Stelle passt mein Layer kaputt.
Genau, und du kannst diesen Symbolic Breakpoint für viel machen, also du kannst natürlich auch, weiß ich nicht, für externe Frameworks machen, wo du erstmal keine Ahnung hast, wie das intern aussehen könnte oder aussehen.
Kann man sich natürlich auch für eigene Sachen machen, aber wenn man selber herüberkommt, ist über den Code, dann brauchst du es wahrscheinlich nicht.
Aber ja, das ist auf jeden Fall auch ein Werkzeug mit Breakpoints, was man kennen sollte und zu wissen, also wissen sollte, meiner Meinung nach.
Ja, und dann gibt's auch noch ein paar lustige Sachen, hast du schon mal mit Sounds debugged?
Ich bin da nicht, ich benutze auch keine Sounds in meinen Apps eigentlich, deswegen.
Ja, aber das hat ja keine Namen dabei.
Schrei das Telefon an, dann hört es auf zu arbeiten.
Nein, nein, nein, manchmal ist ja auch Code irgendwie darauf, also zeitabhängig.
Also manchmal kann es ja sein, dass wenn du deinen Code anhältst, dass zum Beispiel du hälst den Code an und machst irgendeinen Netzwerk-Call und du hälst aber deinen Code an und er hat irgendwas nicht fertig gemacht und dann kommt irgendwie was gefailt zurück oder das ist irgendeine Animation, ich hab keine Ahnung, wie ich das zusammenkonstruiere.
Aber im Prinzip kannst du halt in einem Breakpoint sagen, ok, du hältst bitte nicht an, wenn du da vorbeikommst, aber spiel mir einen Ton auf dem Mac ab.
Also ein Bing oder Bong oder sonst irgendwas sein und du kannst halt an mehrere Töne, also angenommen du erwartest von deinem Programm, es kommt da vorbei, macht Bing, dann kommt es an den vorbeim, dann macht es Bong und dann kommt es an den dritten Punkt vorbei, dann macht es Peng.
So und du erwartest ein Bing-Bong-Peng, Bing-Bong-Peng, das soll immer kommen, jetzt kommt auch mal Bing-Peng-Bong und dann meinst du, ah, das stimmt irgendwas nicht, weil du irgendwie eine falsche Reihenfolge gemacht hast.
Also klingt interessant, ich glaube, das kann ich gebrauchen tatsächlich.
Ja, es gibt Cases, wo man gerade wenn du nicht willst, dass dein Programm anhält, aber du willst wissen, ok, ich bin jetzt gerade vorbeigekommen und dann kannst du genau so was machen, dass du sozusagen mit deinem Gehör debauchst, ob da was schief ist.
Wenn du die richtigen Töne auswählst, kannst du mit der Melodie damit spielen.
Die erste Oper ist gut geschrieben.
Irgendwer hat bestimmt schon so was gemacht.
Kannst du das bestimmt machen, ja. Und dann kann man die ganzen schönen Standard-Macs auswählen.
Man kann auch Yaziri Dinge sprechen lassen oder du kannst alles möglich machen, also da bist du nicht beschränkt.
Du kannst auch Skript ausführen. Dieser D-Bagger hat so viele Möglichkeiten. Ich kenne sie selbst nicht alle. Ich habe schon mal Videos gesehen, wo es dann richtig gefilzt würde.
Wo dann Leute zeigen, ja, das kann man auch mal mit dem D-Bagger anlesen.
Ok, krass, das braucht man jetzt nicht alltäglich, aber es geht.
Genau, dann gibt es genau das selbe für eine Breakpoint-Condition.
Also angenommen, ich möchte, dass mein Breakpoint nur anhält, wenn in einem Label-Text drin steht "Hallo Holger", ansonsten macht man ganz normal weiter.
Also erst wenn "Hallo Holger" in dem Label drin steht, möchte ich, dass du anhältst und so was kann man auch machen.
Das gibt Auffälle, wo man einfach so was braucht, um weiter hervorzugehen.
Genau, dann kann man sich auch Argumente ausprinten lassen. Das ist dann mit $1, $2, $3.
Das kann man auch immer wieder brauchen, gerade auch wenn man über diese symbolic Breakpoints, über die Methoden, kann man sich da was ausgeben lassen.
Aber wir haben auch noch einen Artikel, den verlinken wir, da gibt es dann auch nochmal schön mehr Insights zu den einzelnen Dingen.
Oder man ekoziatis und schaut nochmal selber nach, über was wir hier sprechen.
Das ist natürlich immer ein bisschen viel.
Und wenn du gar nicht damit zufrieden bist, was der D-Bagger ausprintet, zum Beispiel zu deinen Objekten, kannst du das auch selber übernehmen.
Und zwar hast du schon mal was von dem Protokoll "Custom String Convertible" und "Custom Debug String Convertible" gehört?
Wahrscheinlich nicht. Nein, aber das was hier bei uns in den Tunes oder in unserem kleinen Faden steht, das habe ich schon mal gesehen.
Also das "Descriptive" und "Descriptive" hast du schon mal gesehen.
Genau, und im Prinzip ist das auch das, Apple macht es auch oft selber mal über sein Ding, dass du ".descriptive" eingeben kannst.
Und im Prinzip kannst du in so einer ".descriptive" oder ".debugdescriptive", das ist einfach eine Variable, also wenn du das Protokoll implementierst, musst du eine Variable haben, die heißt "descriptive" oder eine "computer property", besser gesagt "descriptive" oder "debugdescriptive".
Und wenn die gecallt wird, gib bitte einen Text zurück. Und den kannst du dir als Entwickler sozusagen schön formatieren.
Das heißt du kannst dann Ebojis reinballern und Newlines und so weiter.
Dann kannst du dann einfach ein schön angenommenes, komplexes Objekt, das viele Variablen hat und du willst, dass es sauber ausgeprintet wird, also dass du sagst "okay, gib mir Object.debugdescription", dann kannst du den Variable wieder auf der Adresse "telefon" immer...
Genau, und dann kriegst du einen schönen Blog und dann ist es auch gut.
Und dann kannst du halt auch die in einem ganz normalen Log-State oder Print-State zu sagen "und jetzt printen wir bitte von meinem Object.debugdescription, die Debugdescriptions in das alle Felder beispielsweise".
Genau, und das erfordert ein bisschen Arbeit bei Entwicklern. In Arbeitskontext haben wir das auch genutzt, weil wir da auch viel mit Google "Point of Interest" und da sind halt auch viele Daten drin, die ausgeprintet werden müssen zum Debuggen halt und für Logs usw.
Und jetzt kommen wir noch zum letzten bei Breakpoints, da gibt es noch Watchpoints und da kann man auch mit Breakpoints sagen, er soll nur bei Änderungen triggern.
Also das ist im Prinzip ähnlich wie diese Condition Breakpoints, aber da kannst du sagen "Okay, solange der den gleichen Wert hat, mach ich nichts", aber sobald er sich ändert, sag mal Bescheid.
Achso, jetzt hab ich noch einen kleinen vergessen, den nennt sich der "Exception Breakpoint", gerade wenn man auch mit anderen Sprachen noch rummacht, zum Beispiel mit C++ oder mit Objective-C oder sonstiges, gibt es noch "Exception Breakpoints".
Wenn man die anmacht, dann sollte man eh eigentlich immer noch immer anhaben, weil selbst wenn Xcode die abcrashet und dir keinen richtigen Output gibt, das gibt es auch manchmal auf der Konsole, dass du nicht wirklich Ahnung hast, was gerade passiert ist, dann kannst du einen "Exception Breakpoint" anmachen und hoffen, manchmal gibt es dir noch mehr Informationen, was jetzt gerade passiert ist.
Der wird dann ausgeführt, bevor es crasht. Wenn die "Exception" kommt.
Genau, genau. Und das wird dann ausgeführt, bevor es crasht.
Ja, also das war es jetzt zu Breakpoints. Und da gibt es noch viel, viel, viel mehr.
Ja, und jeder macht das falsch ein bisschen anders. Das ist aber gut so, die Verschiebung groben Überblick zu haben. Das ist sehr interessant, weil ich halt bei meiner App immer so ein 3-Schritte-Prozess habe, mit 2 Servercalls dazwischen drin. Und das ist glaube ich ganz interessant.
Ja, definitiv ein Ausprobieren, das habe ich auch schon mal gemacht. Kann man mal.
Ok, hast du schon mal, da gibt es nämlich auch ein relativ neues Feature, seit Xcode 11, meine ich, der Memory Graph, hast du den schon mal gesehen?
Ist das so neu? Ich weiß nicht, was ich gesehen habe, ist, dass du halt während das Programm läuft im Simulator oder auf dem Gerät, das halt angezeigt wird, wie viel Speichergeile verbraucht wird.
Nein, das ist nicht das, was ich meine. Wenn du deinen D-Bug erstattest, also du startest die App und dann kommt unten dein D-Bug hoch und dann kommt da so ein Icon, das sieht aus wie so 3 Notes, die dann miteinander verbunden sind.
Also lass es wie ein Fidget Spinner sein, der dem einen Stich fehlt. Also wenn man auf den draufklickt, dann hält das Programm ähnlich wie bei einem Breakpoint an und dann sagt dir oben im Ding hier Capturing Memory Graph vor, bei mir heißt es Test.
Und du siehst halt wie zum Beispiel einen Graph an, wie dein Speicher belegt wird.
Also Graph sind ja auch Baumdiagramme, ne?
Genau, so ein Baum, der sagt ok, das Objekt klingt davon ab und davon und davon und da kann man halt auch Dinge erkennen, wo wir auch schon mal darüber geredet haben über Cycles zum Beispiel.
Wenn du dann das kann dir dann auch anzeigen, dass du sagst ok, ich sehe das hier ist ein Objekt, zeig das andere, aber das andere auch und dann kann dir dann solche Cycles anzeigen.
Du siehst wie oft, zum Beispiel hier bei meiner Test-App gerade, der App Delegate und dann siehst du daneben in Klammer 1, das heißt, das ist genau eine App Delegate da.
Wenn du jetzt angenommen hast und du machst diesen View-Debugger und siehst auch mal, ja aber da steht ein 7 neben meinem View-Controller, dann sollte das ein Hinweis sein, da ist 7 mal eine Instanz da, da wird irgendwas nicht abgeräumt. Also auf jeden Fall auch ein weiteres Tool, um Quatsch aus deiner App rauszukommen, der einem dabei hilft.
Dieses Ding kann dir auch Warnings anzeigen, also man kann sich da viel durchklicken, Speicheradressen anzeigen lassen, da ist sehr sehr viel drin und Dinge anklicken und einfach mal mit rumspielen, kann auf jeden Fall helfen.
Kaputt machen kann man nichts.
Nee, genau, kaputt machen kann man nichts, aber es hilft auch ein bisschen Dinge zu verstehen, was da passiert und ja. Okay, aber von dem, weil du jetzt von dem noch nichts gehört hast, hast du den mal schon von View Hierarchy die Begeleitung?
Ich hoffe, das ist das Ding. Da wo man aus der App pausiert mit dem Breakpad oder so und dann kann man sehen, wie die ganzen Views, die man erstellt hat ineinander verschachtet sind und man kann die auch so leicht verschieben, dann stehen die alle voreinander und das sieht dann so aus, als ob man ein Blatt Papier, das ist das iPhone oder das ist die Hauptview, dann hast du so kleine Post-It-Sitze drüber quasi kleben, die sind dann deine Einzelviews und da sind noch kleinere Post-It-Sitze drin, so nah, sieht das aus.
Ja, das trifft schon ganz gut im Prinzip, das ist das iPhone neben unseren Fidgets wieder, das sieht aus wie so, naja, so lass es drei, lass es so ein Coverflow-View sein, mit drei so Covers irgendwie.
Ja, auf jeden Fall wird dir dann ein wirklich 3D-View von deinem jetzigen gerade User-Interface, was wirklich auf deinem Simulator oder Gerät sichtbar ist, dem man dann auch auf dem Touchpad mit drei Fingern drehen kann.
Also man kann dann wirklich sozusagen, die View Hierarchy bei iOS ist, also muss man vorstellen wirklich wie Schicht über Schicht und so weiß ich nicht, mein Level liegt ganz unten und unten liegt irgendwie, der hat einen schwarzen Hintergrund und dahinter liegt noch irgendwas und so was.
Und so kann man dann wirklich, wenn man so in diesen 3D-View geht, kann man sehen, wie die Schichten aufgebaut sind, die man sich gemacht hat und da kann man dann auch Fehler erkennen und herausfinden.
Bei der Tabelle sieht man das, das ist das Level, das liegt in einer Zelle, die Zelle liegt in einer Liste, die Liste liegt in einer Scroll-View, das ist schon vierschichtig irgendwie.
Genau, da kann man dann auch einzelne Elemente anklicken und die doppelt klicken und in Fokus bringen und dann kann man sich in dem Property Inspector, da kann man sich verschiedene Properties angucken, man kann sich die Constraints angucken, man kann gucken, welche Größe es hat, man kann, also da ist man, da ist auch wieder eine ganz eigene Welt drin an Dingen, die man tun kann, um seine App zu debacken.
Also da hilft es ja auch, wenn man irgendwie nicht weiter weiß und irgendwie ein selbstes Verhalten hat, dass man in seiner App seine Views auf einmal, weiß nicht, alle pink macht, grün macht, sonst irgendwas, dann erkennt man halt auch, in diesem View-Debagger siehst du dann ganz genau so, ah, mein View geht jetzt von da bis da, weil den hab ich gerade pink gemacht und der Rest sieht normal aus und dann kann man auch Fehler erkennen, die man vielleicht so nicht erkennt.
Also auch ein sehr wichtiges Werkzeug und umso komplexer eine App wird, umso wichtiger wird es, dass man da mal reinguckt.
Also sollte man auch immer nicht mal viel reingucken, weil es sieht halt auch schon sehr cool aus, wenn man vielschichtigen Kram hat und sieht das.
Ja, wenn man zu viele Tabellen hat, kann das was sehr erdrückend wirken, wenn auch so tausend kleine Fenster aufeinander, übereinander liegen. Aber dann muss man vielleicht mal gucken, was sein Views einfach ist, weil es halt vielleicht zu schlimm aussieht.
Naja, also es muss natürlich nicht schlimm sein, dass viele Layer, dass es schlecht ist, aber ja, einfach einfach ist.
Das ist eigentlich immer eine gute Idee, ne?
Ja, ok, dann kommen wir zum letzten Icon da unten, was für uns heute interessant ist, das ist jetzt, neben den Fidgets bin ich da rechts, ist zwei Switches und das sind die...
Instruments.
Nee, nicht Instruments, sorry, in dem Sound-Los habe ich das übersprungen, das machen wir gleich danach. Die Vibrant-Overwrites, das sind ja die Dinge, wo man, wenn man am Simulator ist, kann man zum Beispiel den Dark Mode anschalten oder man kann Dynamic Type oder man kann Accessibility Features anmachen und im Prinzip kann man da halt auch Dinge debuggen, die eher auf higher level visuell passieren, also du kannst halt deine Schriftgrößen verändern und schauen, ah, verändert sich auch wirklich meine Schriftgröße im Simulator und so.
Oder wie sieht meine App im Light Mode aus, oder Dark Mode, kann man jemanden her switchen oder Accessibility Funktionen anmachen, die man sonst wenn man das halt ständig übers Handy machen würde oder so, dann ist alles ein bisschen anstrengender und dann kann man das relativ zügig da triggern.
Relativ straight forward, glaube ich, gibt es nicht viel zu sagen. Ich bin eher so ein Device-Kind, ich arbeite wenig mit dem Simulator und viel auf dem realen Device, weil es dann doch irgendwie, ich finde es halt irgendwie cooler mit dem Finger drauf rumzutatschen als mit der Maus.
Der Simulator geht halt meist schneller.
Ja, durchaus, das stimmt. Und es kommt auch auf die App auf dem Maul, manchmal kannst du einfach nicht im Simulator machen, wenn du irgendwas mit SceneKit machst oder wenn du Sensoren oder Kamera brauchst, dann hilft dir die Kamera, hilft dir der Simulator auch nicht, weil dann musst du aufs Gerät gehen, also GPS, also da gibt es genug Cases, wo man dann nur NFC, also das geht halt alles an Simulator nicht und dann muss man aufs Gerät gehen und deswegen bin ich da wieder aus dem Brandmarkt und bin ja auf dem Gerät.
Ok, dann kommen wir noch zum letzten und wirklich, ich glaube, das ist das, wenn man merkt, oh fuck, ich komm nicht weiter, meine ganzen Bugs sind alles so schlimm und ich find den Fehler nicht und vielleicht liegt es doch an Apple oder dann gibt es noch die letzte Bastion, die nennt sich Instruments.
Und zwar, wenn man auf oben bei Xcode, Xcode und dann also in der Menu war oben neben meinem Abfüll steht, dann geht man in der App der Appname Xcode und dann geht man Open Developer Tool und dort findet man einen Punkt als Instruments.
Und Instruments ist sozusagen, da kann man wirklich auf Lowest Level runtergehen und also man kann sich sehr sehr viel, viel rausziehen an Informationen, also was verbraucht viel CPU oder was verbraucht viel Energie oder welche Objekte liegen oder man kann sich System Traces exporten, die man auch an Apple weitergeben kann.
Man kann SceneKit und SwiftUI debuggen, man kann irgendwie Zombieobjekte damit tracen, man kann Metal System Traces machen, also da kann man wirklich eine komplette Folge drüber machen und weiß nicht, ob wir da heute noch groß drüber sprechen, aber was ich im Arbeitskontext benutzt habe, ist auf jeden Fall Leaks.
Da hat man gerade auch schon drüber geschrieben, mit dem Memory, dabei dieser Leak Debugger, kann man das auch noch mal besser rausfinden und was ich auch benutzt habe ist der Time Profiler, wo du dann herausfinden kannst, ok, was verbraucht viel CPU in meiner App und wer ist daran schuld, dass auch immer hier meine App auf 50% läuft, wo du erst mal nicht so genau weißt, aber der sagt ja ganz anders, ah, aus der Klasse kommt das.
Du kannst ja sehen, da war irgendwie ein Netzwerk und danach geht der CPU nach oben.
Zum Beispiel.
Weil was komisch ist, wenn du Netzwerk hast, der dann zurückkommt.
Ja genau, weil du irgendwas verbockt hast oder so.
Oder du gehst in eine View rein, wieder raus in eine View rein und hinterher hast du doppelt so viel Speicher verbraucht.
Und dann gibt es hier nochmal genug Tools, um da genug zu analysieren.
Also kenne ich auch aus dem Arbeitsumfeld, wenn man nicht mehr weiter kommt, dann kann man da ran gehen.
Man kann halt auch was man auch machen kann, ist, dass man auch mal laufen, wenn man so einen schwer zu finden Backer, laufen, der Part, jetzt ist man im State, kann es auch wirklich anstecken, jetzt kann man sagen, ok, jetzt erhätscht dich zu dem Prozess, die auf dem Handy läuft und zeigt mir bitte jetzt an, was da gerade passiert.
Ja, also sehr, sehr powervoll.
Ich kenne da auch weitaus nicht alles, ich denke mal, da kann bestimmt auch noch einer was dazu erzählen.
Ich kann es basic benutzen, gibt es auch ganz tolle WC-Videos drüber und genug von Apple, die erklären, was man wie wo machen kann.
Ist jetzt nicht so, was man sich irgendwie zum Spaß reinzieht, sondern das ist eher das, was man sich reinzieht, wenn man nicht mehr weiter kommt.
Ok, das war es zu dem und dann...
Das hilft mir alles nicht weiter bei der Arbeit, weil ich benutze ja kein Xcode.
Die wollen nicht, weil ich im Interesse schreibe.
Ich glaube, das ist ein großes Fass.
Es ist ein großes Fass, aber wir sollten es auf jeden Fall mal anschneiden, weil im Interesse helfen Backer vorbei.
Und wenn ich weniger Backs habe, muss ich weniger debacken.
Ja, im Prinzip, also ein Unit-Test ist eigentlich ein, angenommen wie du definierst, also man kann sagen, ok, fangen wir so an.
Es gibt verschiedene Art von Tests, die man machen kann.
Ein Unit-Test ist wirklich eine einzelne Einheit.
Das ist angenommen, ich habe eine Methode, die macht irgendwas, lasst es sein, addieren und die gibt mir irgendwas zurück und die will ich jetzt abtesten.
Das ist genau eine Unit.
Dann gibt es zum Beispiel auch Integration-Tests, die, wo du dann über mehrere Klassen hinweg irgendwas testest oder irgendeinen Flow-Test oder sonst irgendwas.
Die werden dann komplexer, dann gibt es natürlich noch UI-Tests, wo du sagst, ok, klick bitte auf der UI rum und schau, ob sonst welche auftauchen und so weiter.
Also Tests gibt es genug, aber ein Unit-Test im Prinzip, was auch bei dir die in Arbeit haben wollen, die wollen halt wahrscheinlich so, hey Holger, schreib uns bitte die Software, die dazu benutzt wird, dass das Flugzeug nicht abstürzt.
Ich glaube, da darfst du nicht arbeiten.
Schreib mir bitte den Test dazu und dann, damit du auch sicher sein kannst, dass am Schluss nicht das Flugzeug abstürzt.
Jetzt, im Schluss ein paar Jahre, deswegen ist ja auch gerade in diesem Avionics-Ding so noch glaube ich, in der Autoindustrie, wird halt auch so gearbeitet, dass Tests driven gearbeitet wird.
Weil halt gerade bei so sicherheitskritisch mit dem Menschenleben dranhängen.
Willst du dir eigentlich sicher sein, dass das funktioniert?
Richtig, du willst nicht, dass Leute dabei sterben und da kann halt einfach ein dover Programmierfehler, wie es auch schon bei Boeing war, wo so Dinge gemacht wurden, die, ja, da war es eine Verkettung von Dingen, dass die Flugzeuge abgestürzt sind.
Ja, genau dafür hättest du wahrscheinlich einen Integration-Test gemacht, wenn man den geschrieben hätte und den gemacht hätte, dann wär's nicht gekommen, weil jeder einzelne Komponente hat wahrscheinlich richtig funktioniert, aber die Verkettung an Dingen hat dazu geführt, dass auch mal so ein Flugzeug runterkommt.
Und das will man ja tunlich vermeiden.
Also jetzt für uns als kleine App-Entwickler ist es natürlich weniger schlimm, wenn die App nicht funktioniert oder crasht oder sonst was, aber wenn Menschenleben dranhängen.
Also aber für so einen unit-Test, wenn wir zum Beispiel nochmal wieder zurück zu der Adia-Funktion gehen würden, dann würde ich mir eine extra Funktion und eine extra kleine Mini-App schreiben, die dann diese Adia-Funktion aufruft und sagt hier als Eingangvariable nimmst du mal drei und vier und wenn hinten Herr Siegen rauskommt, dann schreibst du das als Grün auf, weil hat gut geklappt.
Prinzipiell ja, also nicht eine eigene App, sondern du machst dein eigenes Target in der App, das nimmst du dann in den Test-Target und dieses Test-Target, dort schreibst du dann dein Test und dieser Test ruft deine Funktion auf.
Also du machst dann einen, die Test-Funktion müssen wir testen, Anfang anzeigen, du kannst irgendwie deinen Code importieren, mit Attestable irgendwas, Attestable Import heißt das glaube ich, bei Swift.
Wenn wir jetzt zusammen, also ich Test-driven, wenn du es richtig schön nach Lehrbuch machen würdest, dann würden wir uns jetzt zusammen hinsetzen, also das ist auch mal das, was man machen sollte, ist Pair Programming dabei und sagen, einer schreibt den Test und der andere schreibt den Code.
Dann fangen wir an, ich fange mit dem Test an und sage, addiere und dann Parameter xy und ich gebe jetzt addiere 3,4 und dann fängst du jetzt an und schreibst deine Methode und dann denkst du dir so, haha, haben wir schnell gemacht, du schreibst func addiere xint yint, Klammerauf Klammer zu und du hast gesehen aha, der gibt drei und vier rein und dann sagst du, ja genau, das ist dann, und dann füllen wir den Test aus und er ist grün.
Dann schreibe ich den nächsten Test, der heißt addiere 5 und 4, dann füllen wir die Klammer auf und 2 und, haha, wäre doof, aber auf jeden Fall schlägt der Test dann fehl.
Dann musst du mir wieder das nächste schreiben um mich auszutricksen und ich muss dir den nächsten Test schreiben, der dann den nächsten Fehler oder dich wieder austrickst und im Prinzip ist es wie so ein Katz und Maus Spiel und wenn man das richtig durchführt, also das wirklich man Keyboard immer hin und her schiebt und jeder irgendwie Maus und der eine schreibt und der nächste.
Wenn man das hin und her spielt, dann kommt man dann wirklich auch zu qualitativ hochwertigen Tests und qualitativ hochwertigen Codes, weil einfach zwei Gehirne sich gegenseitig, sag ich mal, geärgert haben und versucht haben dem anderen irgendwie, also dem anderen Seite kaputt zu machen.
Wenn dann beide irgendwann am Schluss da sind und sagen, hey jetzt glaube ich haben wir es, jetzt gibt es nichts mehr, dann ist es meistens auch sehr, sehr ballentruf Code.
Oder es ist ja ein langer Spaghetti Code mit F3, 3, 4, dann F5, 4, dann 9.
Richtig, ja, natürlich ist es nicht richtig mit dem anderen verarschen, aber ja.
Habe ich ja eigentlich verstanden.
Habe ich auch einfach die einfachste Implementation vielleicht auch zu finden. Also gibt es immer viele Leute, die auch super smart irgendwas tolles bauen wollen und im Prinzip kann man das auch viel einfacher.
Funktioniert auch und Readability ist halt auch etwas, was gerade bei den großen Projekten arbeitet, weil nicht nur du liest den Code, sondern alle lesen den Code und auch du in der Zukunft wirst deinen Code lesen.
Und lieber schreibst du irgendwas ausführlicher und nicht ganz so kompakt und super fancy, sondern schreibst du so, dass du auch mal lesen kannst, anders versteht, was du da machst.
Ganz stimmt, finde ich das auch mal, wenn irgendwelche Entwickler sagen, hey mein neues Update hat tausende neue Zeilen von Code, voll gut.
Das ist ja ein Qualitätsmerkmal.
Ja doch, vielleicht schon. Vielleicht sind ja tausende Zeilen an Tests dazugekommen.
Diese Tests werden ja gar nicht mit ausgeliefert, also wenn du deine App baust, die haben nichts damit zu tun, die bleiben bei dir lokal, die werden nirgendswo im Appstore auftauen oder so.
Niemand kann den Test sehen.
Zu all diesen Dingen, die wir heute hier erzählt haben, haben wir auch noch ein kleines Ding verlinkt, da könnt ihr euch auch nochmal die einzelnen Funktionen des Liebergs angucken und natürlich Google, Ecosian, DuckDuckGone zu den einzelnen Themen.
Ich glaube, wir haben jetzt nicht alles verlinkt, aber es gibt vieles und hoffentlich hat es dazu geführt, dass auch der eine oder andere vielleicht was Neues gehört hat.
Ich auf jeden Fall.
Ja, das hat auch schon was gemacht und dann haben wir jetzt wahrscheinlich während der Kippe während der Kippe etwas erzählt, ein Konzert an Apple Sounds.
Ich weiß gar nicht, ob das auf meinem Windows Rechner auch mit Sounddebugging machen kann, aber das wäre cool.
Ich glaube nicht, dass das Apple only ist. Kann ich mir gut vorstellen, dass andere ITs ähnliche Funktionen haben.
Ich weiß, mal gucken.
Gut, dann vielen Dank und wir haben noch das Fremdewerk.
Moment, ja ich auch, stimmt, da wollte ich noch was sagen. Wir wurden uns schon auf Twitter geschrieben.
Sollen wir rappen?
Richtig, wir haben, wir haben, wir haben, lass mich mal ganz kurz gucken. Ich hab was und zwar hatte doch hier was in unserem tollen Newsletter, bei dem wir auch schon mal geredet haben.
Hatte ich da nicht was gesehen, was ich ganz cool fand?
Nein, ich habe was anderes gefunden.
Und zwar wir hatten jetzt über Combine geredet und es gibt Combine Extensions.
Hab ich darüber schon geredet?
Ja, hatten wir noch nicht.
Und zwar, das ist auf GitHub ein Repository, weil Combine ist ja noch relativ frisch und da gibt es ein Combine Extensions.
Dieses Ding fügt Combine noch mehr Funktionen hinzu, die andere Combine Reactive Framework können.
Und Apple wird in Zukunft bestimmt noch mehr Funktionalitäten zufügen, aber wem Combine zu wenig bietet, kann man sich dieses Repo reinziehen.
Das Repo der Woche.
Ja, stimmt, also ich eigentlich finde ich sehr, wir haben damit erreicht, dass Leute mit uns auf Twitter interagieren. Vielleicht müssen wir den Leuten so richtig die Ohren zu den Huten bringen.
Combine Extensions, ist das?
Also Holger, ich suche es dir gleich nochmal rein und ich weiß nicht, wie es genau heißt.
Ja, ich glaube Combine Extensions, ja genau, das ist Traktor und Zauberer Emote.
Genau, das bohrt das nochmal ganz auf und da kann man coole Sachen machen.
Ich habe auch die Woche schon wieder viel mit Combine gearbeitet und habe dann auch, was sehr cool ist, ist Combine Latest, wo du dann mehrere Publisher zusammen schachteln kannst und wenn einer davon triggert, dann wird die Methode ausgeführt und kannst echt, also wirklich kompakten, eleganten Code schreiben und das macht schon sehr viel Spaß.
Mein Arbeitskollega hat auch gesagt, oh das ist aber sehr sexy, wenn Nerds sich die Dinge sexy finden.
Genau, dann nächstes Mal singen wir wieder, damit euch auch die Ohren bluten.
Vielleicht, vielleicht rappen wir.
Oh Gott, ich sehe schon die Hörer alle mit so Weichheit auf den Ohren und so verdammt in den Kopf, Blut noch so an den Wattepads.
Gut, dann jetzt aber. Servus.
Servus, würde ich auch sagen.
Moin Moin nach Hamburg.
Das App Store Tagebuch verabredet von Nico und Holger. Die Links zu dieser Sendung wie auch den Link zu dem Intro von Luke Hash findet ihr auf App Store minus Tagebuch.de.