Play Store Updates // TypeScript 5.3 // Angular 17 // Ruby on Rails: The Documentary

Hallo und herzlich willkommen zu einer weiteren Folge der programmierbaren News. Wir sind in der KW 46 und haben deswegen auch die News Nummer 46 und ich bin der Fabi und mir gegenüber hinter der Mattscheibe sitzen der Jan. Hallo. Und der Sebi. Hi. Hi. Wir haben mal wieder einige Themen für euch dabei. Und zwar hat Angular eine neue Version rausgebracht mit ihrer Version 17. Wir haben GitHub Univers, die stattgefunden hat. Wir haben eine neue TypeScript Version. Im PlayStore gibt es was Neues und der Jan hat uns eine Dokumentation mitgebracht über Rubian Rates. Ich bin schon ganz gespannt. Lass uns mal mit Kleinigkeiten anfangen. Jan, was gibt es im PlayStore Neues? Ja, am 9. November ging die Pressemitteilung raus von Google, dass sich die Anforderungen an die PlayStore Entwickler ändern. Und zwar müssen alle neuen Accounts, also es betrifft nicht Leute, die jetzt schon irgendwie aktiv Apps haben, die auch schon gepublished sind, sondern jetzt erst mal nur die neuen, quasi mehr Spam zu verhindern, müssen ihre Apps mit mindestens 20 Usern, 20 Geräten über mindestens zwei Wochen lang quasi in der Private-Beta vortesten, bevor Google sich überhaupt so Apps oder Submissions anguckt. Unter der Annahme, dass das natürlich schon mal hilft, die ganz offensichtlichen Fehler auszumerzen, die du vielleicht als Entwickler in der Betriebsblindheit nicht gefunden hast, aber die deine ersten paar Betatester auf jeden Fall sehen würden. Und. Sie sagen... 20 User und wie lange hast du gesagt? Zwei Wochen. Zwei Wochen. Also schon so ein Zeitfenster, was man in so einen Release. Zyklus planen muss. Ja, und gibt's da... Also wie aktiv müssen diese Leute sein? Muss man 20 Downloads haben oder wie wird. Dieser User definiert? Das war nicht genau ausgeführt. Aber ich nehme an, das, was sie zumindest tracken können, ist schon so der Fall. Also du musst es schon installieren und vielleicht auch mal aufgemacht haben. Und was danach passiert ist dann glaube ich auch. Ich meine, es ist ja wie in allen Betatests. Nur weil du Beta User hast, heißt es ja noch lange nicht, dass du auch irgendwie qualitatives Feedback zurückbekommst. Aber es ist zumindest mal so ein Minimum, was sie eben auch entforsten können. Es erinnert mich an diesen Talk, wo dieser eine Entwickler irgendwie weiß ich nicht, wie viele tausend Android Cookie-Clicker in unterschiedlichen Variationen rausgebracht hat. Fabi, erinnerst du dich an das? Also Cookie-Clicker, meinst du das? Game-cookie-klicker? So ganz viele. Variationen davon. Also irgendein Cookie-Clicker und er hat das dann gebaut, dass er automatisiert neue Cookie Clicker unterschiedlich gesiemt, automatisch im AppStore releasen konnte. Das ist ja schon Ewigkeiten her. Das stimmt, das sagt mir auch was. Aber das ist genauso der Use Case, den es eben zu verhindern gilt. Dieses reinige Spamme und Apps, die direkt beim Aufmachen kaputt gehen und sowas. Sie haben noch ein paar andere Kriterien, die Sie jetzt enforcen. Sie sagen auch, Sie nehmen sich jetzt mehr Zeit zum Testen, insbesondere für Apps, die Sie so als kritisch bezeichnen, was in der PR-Meldung auf alle Fälle so Apps, die für Kinder sind oder Apps, die halt besonders sensible Permissions irgendwie Require, da nehmen sie sich jetzt auch noch mal mehr Zeit zu gucken. Da stellt man sich beim Lesen die Frage, cool, aber warum hat es jetzt, wenn Sie das so bemerken. Und gleichzeitig sagen sie natürlich auch, dass sie versuchen, das ohne irgendwie Impact auf die Reviewzeit zu machen. Also wird es wahrscheinlich irgendwie mit mehr Staffing auf deren Seite gehen müssen. Und an anderen Stellen versuchen sie einfach rein formell, ich sage mal nachzuziehen zu dem was andere Stores schon so lange haben. Du musst jetzt irgendwie eine verifizierte Adresse angeben, die auch veröffentlicht wird zu deiner App. Du musst irgendwie deine DanZ Nummer angeben. Das war bei iOS, also bei Apples AppStore glaube ich schon von Anfang an ein Requirements, wenn ich mich recht erinnere. Also alle DefiCounts, die ich da jemals aufgemacht habe, haben das schon gebraucht. Und ja, also es sind alles sicherlich richtige Schritte. Aber wie immer fragt man sich halt was, also was zeigt dir das? Zeigt es, dass es gerade besonders schlecht läuft und sie deshalb irgendwie da mehr drauf gucken müssen? Oder zeigt es, dass es jetzt irgendwie besonders gut läuft und dass sie sich quasi erlauben könnten, jetzt quasi die Latte so ein bisschen höher zu hängen? Das ist so ein bisschen das Rätsel für mich da hinten dran noch. Aber alles in allem bestimmt keine Maßnahmen, die per se schlecht sind oder so. Auf jeden Fall. Ich hätte mich gefragt, wie viel ändert es wirklich? Aber klar, so automatisierte Cookie Clicker Releases, das wird es auf jeden Fall unterbinden. Ansonsten für die, die eh schon einen gewissen professionellen Anspruch an ihrer App haben, macht es wahrscheinlich eh keinen großen Unterschied. Außer dass man jetzt noch einen offiziellen Step durchwarten muss. Wahrscheinlich muss man es einfach in seinem Release Planning so ein bisschen mit einbeziehen, wenn es vorher halt interne Tests waren. Aber ganz ehrlich, wenn du halt so einen gewissen Anspruch schon an dich selbst hattest und du machst eine Beta, dann hast du, also wie hoch ist die Chance, dass du eh auch 20 Leute hast und das eh auch über zwei Wochen geht? Also ich glaube, die allermeisten, die das gut und ernst meinen im Store, die wird das nicht wirklich Impacten. Genauso wie es uns ja auch überhaupt nicht wehtun würde, wenn hinter jeder unserer Apps am Ende die Adresse von Lothum noch im Klartext steht, so im Store. Also kannst du eh im Internet rausfinden. Wir haben hier keine schlechten Absichten, kann ruhig jeder wissen. Die, denen das halt weh tut, sind am Ende die, die es glaube ich auch treffen soll. Ja. Ja, coole Änderung auf jeden Fall. Sebi, was gibt es? Wir haben einen neuen Release-Kandidat, hast du mir wieder TypeScript gebracht, 5.3. Was gibt es da Unspannendes? Ist nicht so spannend. Ich habe rausgefunden, ich habe nicht rausgefunden, also es gibt Import Attributes bzw. Vor einiger Zeit in JavaScript ist sowas rausgekommen, das hieß Typaserts, dass beim Importieren mein Typ der Datei angeben konnte, hauptsächlich für den Use Case, ich möchte Json in meiner JavaScript Datei importieren. Und das hatte ein bisschen Vorteile, was die Sicherheit betrifft, und so, dass ich in dem Json eben dann keinen Code ausführe und so was. Und das heißt jetzt Import Attributes und ist in TypeScript 5.3 mit drin, also das ECMO Script Konsortium, naja, wie auch immer das heißt, wahrscheinlich irgendwie so, hat die Typaserts jetzt geändert in Import Attributes und die dienen jetzt mehr so als Hints für die Runtime. Naja, jedenfalls – da kann man mal durchlesen irgendwie – ich finde es nicht so super spannend. Wenn der Browser oder eben meine… Wenn Node oder sowas diesen Typ dann kennt, dann kann die irgendwas speziell damit machen oder speziell nicht machen z. B. Keinen Code ausführen beim Importieren. Ja, da hat sich nur die Schreibweise geändert, also wenn ich ein Typ-Assert vorher mit einem Asert hingeschrieben habe, dann heißt es jetzt with Typ. So, das ist die Änderung und deswegen finde ich es nicht so spannend. Aber es ist Ihre Haupt Änderung. Das heißt, ab jetzt wird es nur noch unspannender. Achtung, schön aufpassen. Quality Content bei der Programmierbar. Auf jeden Fall. Der Sebi, der weiß einfach, wie er seinen Content gut verkaufen kann. Ja, ich finde es richtig spannend. Es gibt nur noch drei Sachen, was ich vorher noch nie verwendet habe, aber was jetzt hoffentlich ein tolles Ding ist. Switch True Statements. Also sonst weiß ich in JavaScript okay, ich kann ja ein Switch Statement schreiben, wo ich dann eine Variable einfüge und dann da prüfe, was das für Werte hat in den Cases. Switch True gibt es aber auch und dann sieht das alles so ein bisschen pettermatchy aus. Und das hat TypeScript bisher ein bisschen aus dem Tritt gebracht. Aber jetzt nicht mehr. Für die vielen JavaScript Entwickler, die Switch True und Case Statements verwendet haben, kann ich jetzt erst mal prüfen: Ist das ein String? Und dann kann ich prüfen: Ist es ein Array? Und der weiß es jetzt. Jetzt ist es ein String oder ein Array. Ich verstehe es gar nicht. Ich kenne Switch True Statement überhaupt nicht. Ich schreibe Switch und dann schreibe ich einfach nur True rein. Und dann was prüfe ich. Im Case? Ja, genau. Case kann ich über alles prüfen, worauf ich Lust habe oder was? Im Case ist quasi ein Conditional drin, der auf True evaluieren muss. Und wenn alles auf True evaluiert, dann bist du in dem Step von einem Switch drin. So, und dann kannst du ganz unterschiedliche Sachen abprüfen da drin. Und dann hast du diesen Fall through, dass wenn du keinen Break machst in dem Case, dass er dann eben weiter rattert und in dem ganzen Fall merkt er sich dann so was hat er eigentlich vorher schon geprüft und welche Variablen sind jetzt schon sichergestellt, dass die welchen Typ haben könnten? Ich bin mal gespannt. Habt ihr schon mal Switch True eingesetzt in der freien Wildbahn? Ja, aber tatsächlich nicht in der Sprache. Aber bestimmt nur, weil der Support vorher. Halt so schlecht war. Richtig. Ich habe es gerade halb gesagt, nicht hinbekommen, da hat man es nicht verwendet. Mounts. So, dann eine Sache, die in diese gleiche Kerbe schlägt wie Google hier. Warum hat das eigentlich vorher nicht funktioniert? Angenommen, ich habe einen Typ Predicate geschrieben, also eine Funktion, die mir zurückliefert, ob das von dem Typ ist, also den Parameter, den ich reingebe und dann ist da hinten steht dann irgendwie Doppelpunkt T, also das oder P der Parameter ist und dann der Typ String z. B. So, und wenn ich das jetzt in einem if verwendet habe, dann schreibe ich ja dann also if und dann die Funktion oder Parameter und dann hat TypeScript alles hinbekommen. Wenn ich das Ding aber dann auf True überprüft habe, also der Rückgabewert von dieser Funktion, die Funktion gibt ja tatsächlich nur True zurück, dann hat das TypeScript nicht mehr bekommen. Aber in Zukunft bekommt es das hin. Technologie. So, und jetzt kommt das absolut Unspannendste. Achtung, mal gucken, wer es jetzt schafft, wach zu bleiben. Mein Respekt. Symbol. Hasinstance. Ja, wer kennt es nicht? Für den alltäglichen Fall, dass ich meiner Klasse vorgaukeln möchte bei einem Instance of Check irgendwas anderes zurückzuliefern als sich selber. So, wenn. Ich das als Type Predicate jetzt implementiere auf meiner Klasse, dann schnackelt das TypeScript auch. Okay, das habe ich noch nie benutzt. Auch nicht in anderen Sprachen. Ich weiß auch gar nicht. Warum? Warum? Ja, nichtsdestotrotz eine Sache, die ist das Breaking, ist aber ganz cool. Das wusste ich auch nicht. Wenn ich in einer Vererbungshierarchie in Super und dann also Superpunkt und dann eine Methode aufrufe auf meinem Parent, dann funktioniert das bei Methoden ganz gut und TypeScript mag das auch, wenn ich eine Property habe, die eine Function ist, kann ich das auch mit Super aufrufen. Das mag die Runtime aber nicht, weil in der Runtime steht das irgendwie nicht zur Verfügung, steht in der Doku. Und das weiß jetzt TypeScript auch. Das heißt, jetzt meckert er an, wenn ich mit super auf eine Property zugreifen möchte. Was wäre denn das super von der Function? Du hast gesagt, wenn ich das auf einer Function mache, dann geht das nicht. Also wenn ich die Methodenschreibweise nehme, dann wird die Methode an den Prototyp gehängt. Und wenn ich aber nur eine Property habe, dann hängt die nicht am Prototyp. So haben sie das irgendwie erklärt. Und deswegen wirft das in der Runtime einen Fehler, weil aktuell hat wahrscheinlich TypeScript da nicht rumgemeckert, weil es für ihn einfach aussah wie eine Methodensignatur. Ja, cool. Der Release-Kanal ist verfügbar. Ja, also wer mal richtig Lust hat auf spannende Neuerungen, installieren. Ich meine, du sagst es jetzt so langweilig, aber man muss es ja auch einfach mal positiv sehen. Das sind ja auch alles … Jetzt … Du hast keine Sachen, die irgendwie hart das Risiko eingehen, dass sie irgendwas an deinem Flow oder deiner Codebase kaputt machen, außer du bist jetzt sehr nischig vielleicht unterwegs. Aber das ist ja auch mal gut, wenn es einen Release gibt, den du so relativ sorgenfrei. Mitnehmen kannst. Völlig richtig. Genau. Und du hast diese kleine Verbesserung noch, dass du ein bisschen typsicher ist, weil die Runtime dir ins Genick schlägt, wenn du super auf einer Property aufrufst. Und die anderen Sachen sind nicht wahnsinnig Breaking, sei denn, du hast bisher schon Typoservice verwendet, dann nimmst du jetzt halt das andere Schlüsselwort. Also ist eine super coole neue Version, die man einfach mal installieren kann und nur Vorteile von hat eigentlich. Das ist der richtige Weg, das zu verkaufen. Danke schön. Jetzt bin ich auch. Überzeugt, Fabi, oder? Jetzt bin ich auch überzeugt. Aber mit Fabi, was ich auch überzeugt bin, ist die GitHub Univers, die stattgefunden hat von GitHub, ihre Konferenz, wo sie einige neue Dinge vorgestellt haben und so ein bisschen, sie haben in GitHub mal gegründet auf Git, jetzt auf AI. Also der Fokus ist schon sehr stark AI und einige neue Themen mit dabei. Ich probiere es mal grob zusammenzufassen. Der GitHub Co-Pilot Chat geht in die General Availability im Dezember und ist dann für alle GitHub Co-Pilot Kunden ab dann verfügbar. Der Co-Pilot Chat kommt dann auch in die ChatBrain IDE's. Das war ein lange gewünschtes Feature wohl von den Leuten, die ChatBrain benutzen. Also viel Spaß damit. Ansonsten kommt es auch in die mobile App und auf github. Com der Chat. Generell GitHub Co-Pilot Chat. Willst du. Vielleicht einmal ganz kurz für die Leute, die den Chat noch nicht benutzt haben, abreißen, was der Chat macht oder warum er den haben will? Github Universe ist. Die jährliche Konferenz von Github, wo sie neue Dinge vorstellen. Und da haben sie das vorgestellt. Das sind der Großteil der Keynote-Inhalte, die ich hier vorstelle. Und Gitter-Koppello-Chat, ich habe ihn ehrlich gesagt auch selbst noch gar nicht, ich nutze ihn noch gar nicht, wenn ich auf einer von euch schon Zugriff darauf hatte. Dann Silbi, kannst du ja gerne mal erzählen, wofür du Gitter-Koppello-Chat benutzt oder benutzt? Ich habe ihn heute verwendet. Achtung, einen Farbhacks-Wert in einen RGB-Wert umzuwandeln. Das wäre viel geiler gewesen, wenn du jetzt gesagt hättest, du hast den benutzt, Switch. True Statement zu schreiben. Ich habe so eine Ist-Irade. Bitte schreiben wir jetzt in Switch True Also du hast beschränkte auch gar nicht so spannend. Wir sollten nochmal vielleicht in die Marketing-Schule gehen mit dir. Ich brauche mal ein bisschen Hype Wasser. Also der GitHub Kopilow Chat ist so eine, so was wie so ein kleines Chat-GPT, was ich in der ID habe, was Zugang zu meinen angeblich allen gerade offenen Dateien hat, aber irgendwie wahrscheinlich nur zu der, die ich mir auch gerade anschaue. Das ist also so der Kontext, auf dem ich dann mit dieser Datei chatten kann. Oder ich kann ihn dann fragen und dann kann ich ihm sagen: So, hier kannst du, das habe ich auch schon gemacht, kannst du mir mal bitte diese Datei einfach reviewen? Und dann sagt er so ein paar Sachen, die ihm auffallen. Oder kannst du mal, ist das irgendwie korrekt? Findest du einen Bug? Irgendwie sowas kannst du ihn dann fragen. Ja, wahrscheinlich sind da noch ein paar andere versteckte Sachen drin. Mit so Slashfix und Slashdokument oder so kannst du ihm dann auch sagen, er soll das irgendwie dokumentieren oder irgendwas fixen oder so. Aber ich bin gespannt, weil ich hab den Chat noch nicht bisher genutzt, weil sie haben jetzt auf der Enterprise so als neues Feature die Slash Commands genannt mit Slashfix und Slashtests, dass du direkt automatisch Tests schreiben kannst zu etwas oder etwas fixen lassen kannst. Das war aber vorher auch schon so, wenn man Chat hat, ist das einfach ein Feature, was mit GitHub Grupple Chat kommt? Kann ich dir nicht genau sagen. Ich habe dieses Chat Ding auch schon irgendwie sechs Monate oder so, als ich da in der Beta war. Aber du nützt es nicht so aktiv. Aber du nützt es nicht so aktiv. Aber du nützt es nicht so aktiv. Aber du nützt. Es nicht so aktiv. Weil du einfach schon dabei. Nein, ich schreibe ja eh keine Tests. Wir werden. Gerade Hände über dem Kopf zusammengeschlagen, das sieht. Keiner da draußen. Ich benutze es nicht so aktiv, weil ich nicht so oft … Also in der Tat nutze ich es jedes Mal, wenn ich sonst auf ChatGPT gehen würde und ihn irgendwas frage, wie man irgendwas codet oder so, dann kann ich das jetzt direkt in der ID machen. Aber dass ich ihn jetzt wirklich produktiv dazu nutze, dass er mir irgendwie nebenbei noch Sachen oder Tests oder Verbesserungsvorschläge oder Reviews oder sowas macht, so leider nicht. Aber für so Kleinigkeiten wie zum Beispiel jetzt mal ein Hexwert, RGB umwandeln oder sowas, das ist eigentlich ganz nice. Vielleicht liegt es ja auch an noch Dingen, die sie jetzt auch verbessern, dass er vielleicht einfach noch nicht so viel kann, was du brauchen könntest. Einerseits basiert es jetzt auf GPS4, der Co-Pilot Chat, das haben sie geupdatet und ein paar Sachen, die ich zuerst ehrlich gesagt erst mal übersprungen hatte, weil ich dachte, okay, nicht interessant für mich, Co-Pilot Enterprise, weil ich dachte, okay, irgend so ein Enterprise Feature Kram, so gucke ich mir an für einen Podcast, aber habe ich erst mal übersprungen. Und dann habe ich noch mal angeschaut, Co-Pilot Enterprise ist ab Februar 2024, also in knapp drei Monaten, dreieinhalb, und ist ihr Pricing Tier, also aktuell kostet ja Co-Pilot Business 19 Dollar pro User pro Monat, Coupilote Enterprise kostet 39 Dollar pro User pro Monat an Features, die dann mitkommen sind, dass der Chat komplett personalisiert ist, ob die gesamte Codebase. Also er hat komplett deine CodeBase als kompletten Kontext und eben nicht nur das, was du jetzt gerade in deiner ID aufmachst, sondern hat die komplette CodeBase, kann auch deine Dokumentation durchsuchen, wie auch immer man die verlinkt, weiß ich nicht so ganz genau. Man kann hier Pull Requests Summaries erstellen, hat irgendwelche Code Review Skills, die sie jetzt hier erst mal nur angeteasert haben, aber nicht genau definiert haben. Also generell dieses ganze Thema rund den Kontext deiner CodeBase bringt es mit, wenn man auf CodePilot EnterpriseDatet, was dann aber das Doppelte pro Monat pro User kostet. Haben Sie dazu gesagt, wie das funktioniert? Ich meine, ich habe ja von diesem ganzen Code nicht ganz so viel Ahnung. Aber das ist ja ein ziemlich großes Kontextfenster, was man da braucht, wenn man sich jetzt vorstellt, dass mein gesamtes Repository mit allen Quelldateien, die da drin sind, gegebenenfalls auch die Dependencys irgendwie mitverstehen, irgendwie alles sauber durch zu pausen. Das ist ja jetzt nicht einfach so mit, weiß ich nicht, 10.000 Tokens getan oder sowas. Gut, trainieren Sie da so ein Feingetunktes? Genau, also Sie schreiben auch als Endpunkt Feintuning Models. Also ich denke mal schon, dass Sie vielleicht auf der Code Basis feintunen, damit es grundsätzlich den Kontext hat und dann wird es ansonsten werden Sie eine Vektordatenbank wahrscheinlich füllen mit deinem... Also mit Embeddings deines CodeBases und dann probieren die jeweils passenden Stellen dann in den Prompt mit rein zu injecten, denke ich mal. Aber sie schreiben zumindest Feintuning Models. Ich denke, es ist wahrscheinlich eine Kombination daraus, so. Dass grundsätzlich... Ja, das macht ja Sinn. Knowledge irgendwie darüber hat, aber vielleicht ein Punkt, den ich in der AI News Folge nächste Woche mit dem Philipp nochmal besprechen kann. Aber genau, also Feintuning Models schreiben sie und ich denke mal, aber ich meine, ein größeres Context-Window jetzt, also gut, noch nicht bei GPT4, aber dann bei GPT4 Turbo, obwohl sie, weiß ich nicht, also sie haben nur geschrieben GPT4. Ich tippe mal, dass auch direkt auf GPST4 Turbo ist, aber man weiß es nicht so genau. Aber auf jeden Fall, deswegen dieses Github Co-Pilot Enterprise habe ich für mich immer so ausgeklammert, weil ich dachte, es ist einfach eher wirklich für Enterprises, aber es bringt hier einfach ein anderes Feature halt mit und auch kleine Teams können auf Github Co-Pilot Enterprise wechseln, diese Features zu bekommen. Genau, ansonsten noch zwei weitere Features. Also es klingt auf alle Fälle so, als ob man es haben will. Ja, wenn man sich leisten kann. Aber ich glaube, ich kann mir schon vorstellen, dass das einen krassen Performance Boostern hat, wenn der Chat wirklich den Kontext des gesamten Repositorys hat, so also zumindest mal wert zu testen. Ansonsten noch zwei interessante Dinge auf der Univers, das Co-Pilot Partner Programm. Also es gibt jetzt im Co-Pilot-Chat die Möglichkeit Apps zu integrieren oder Partner können Apps bereitstellen innerhalb von CoPilot Chat. Also sie haben als Launchpartner jetzt sowas wie DataStack, Postman, Haschikop und DataDock genannt und dass man dann zum Beispiel so Dinge fragen kann. Sie hatten ja ein Beispiel, dass man die DataStacks App fragen konnte. Hier, man konnte irgendwie eine SQL Query in seinem Repository markieren, sagen hier ist die performant und hat es an diese Anfrage an die DataStack App geschickt. Und dann wurde da direkt eine Analyse dieses Queries gemacht und eine Summary, wie sozusagen das 99% perzentil, wie schnell die Abfragen sind und so was, ob es ein Bottom-Leck ist und dass man so generell Apps irgendwie integrieren kann, die dann, also die man irgendwie mit integriert haben muss, angebunden haben muss und dann wahrscheinlich noch mehr Kontext zur Applikation, zu Live Daten irgendwie liefern können innerhalb der App. Kann man auch vorstellen, keine Ahnung, vielleicht wenn man so was wie Centry anbinden kann, fragen kann, hier gibt es dafür zu der Codestelle irgendwelche Laterst Bugs oder so was und fassen wir das mal zusammen, was da so kam. So Dinge, für so was könnte es wohl mal genutzt werden. Und das letzte, da bin ich mal gespannt auf GitHub Co-Pilot Workspacees. Das ist ein Preview für ein Feature, wie man mit wieder mal AI noch mehr in den Coding Alltag integrieren kann. Und zwar sagen sie, dass die meisten Implementierung anfangen mit einem GitHub Issue, mit irgendeinem GitHub Issue, dass man sich schnappt und darauf implementieren möchte. Und GitHub Co Pilot Workspace ist, wenn man ein GitHub issue öffnet, wird automatisch ein Plan, ein Implementierungsplan von GitHub Co Pilot erzeugt. Also mit erst mal einer textlichen Solution Beschreibung, was getan werden müsste, dann ein Step by Step Plan und dann einem Implement Button. Und man kann sowohl diese Solution Description als auch diesen Step by Step Plan vorher editieren und sagen Okay, fügt noch mal das hinzu, mach noch mal das und kann diesen Implement Button ausführen. Und dann wird GitHub Co-Pilot das probieren, das komplette GitHub issue für einen zu implementieren. Man kann an jeder Stelle diese Implementierung, sei es an dem Solution, an dem Step by Step Plan oder an dem Code, der später rauskommt, editieren. Und wenn man, deswegen heißt es auch GitHub Co-Pilot Workspace in ihrem Beispiel hat man das Ganze im GitHub Workspace ausgeführt, also in dieser Web ID. Sagen Sie, es kann dann auch automatisch ausgeführt, gebaut werden und getestet werden. Und GitHub Co-Pilot kann auch automatisch Dinge, die in diesen Tests aufkommen, fixen. Was erst mal nach einem ganz coolen Workflow aussah. Ich weiß aber nicht, ob das Ganze überhaupt dann funktioniert, wenn man nicht im GitHub CodePilot Workspace wirklich arbeitet. Zumindest dieser Build Run and Test Step auf jeden Fall nicht, aber zumindest für eine erste Implementierung und dann auch später wird auch eine Zusammenfassung für die Pull Requests geschrieben. Klang erst mal ganz interessant. Mal schauen. Hängt stark davon ab, wie gut die Implementierung davon dann wirklich ist und wie viel man das dienen muss und wie hoch die Accuracy ist bei diesen Implementierung. Skeptische Blicke. Vielleicht ist das ja endlich das Feature, was die Leute dazu bringt, mehr Tests zu schreiben. Wenn sie dann so sehen okay, wenn ich mehr Test Coverage habe, kann ich auch mehr Vertrauen in so einen Co-Pilot Fix haben, weil er mir zumindest schon mal weniger nebenbei noch kaputt machen kann und im Idealfall auch den eigentlichen Fehler löst. Na ja, gut, dann geht der Co-Pilot schreibt doch die Tests auch mit. Der könnte ja auch die Test Coverage hoch. Ich suche ja immer noch die AI, die das andersrum macht. Eigentlich will ich ja nur die Tests schreiben. Und. Der Code, der das erfüllen muss, der kann ja von mir aus Autogeneriert sein, weil da weiß dann am Ende ja auch, dass es funktioniert. Weil ich habe ja die Tests dafür und die Tests zu schreiben und sich die Edge Cases auszudenken, das ist ja eigentlich die größte Transferleistung. Am Ende Quelltext zu schreiben, der dafür sorgt, dass das alles grün ist, das ist ja eigentlich super oder sollte ja super leicht automatisierbar sein, gerade weil es so gut testbar ist. Also das kannst du ja super reinforced lernen darauf. Das heißt du, aber du willst gerne testen, wirst aber auf jeden Fall auch nicht abgeben als Arbeit, die willst du schreiben. Die Tests sind viel spannender als der eigentliche Code. Da stehe ich so ein bisschen alleine mit. Ich habe schon bei einem Semi habe ich es eh gemerkt. Er schreibt keine Tests. Aber ich finde, das ist schon immer die schwierigere Aufgabe, so von vornherein zu überlegen, was könnten so die Edge Cases sein? Was ist so die Businesslogik, die du eigentlich abbilden willst und so? Und je präziser dein Test Case ist, desto mehr von deiner eigentlichen Businesslogik ergibt sich ja direkt daraus, wenn du ihn liest. Und deshalb denke ich mir die ganze Zeit so, das ist doch irgendwie der viel naheliegendere Case. Ob das jetzt für jeden schön ist so zu arbeiten, sei mal so dahingestellt. Aber aus AI Sicht muss es ja super trivial sein zu sagen Okay, du hast hier diese 20 Tests und ich schreibe jetzt so lange Code, bis ich das halt irgendwie alles abhaken kann. Aber ich meine, aber trotzdem greifst du jetzt irgendwie in einen Step rein, den die AI eigentlich tun soll. Sie fangen ja viel früher an. Sie sagen, du hast ein Problem. Die AI schreibt dir einen Lösungsplan dafür, einen Step by Step Plan und wird höchstwahrscheinlich diese Tests, zu validieren, dass sie den Plan, den sie dir vorgeschlagen hat, auch wirklich so implementiert hat, ja hoffentlich auch dazu schreiben, dass du anhand der Tests siehst, okay, es funktioniert wirklich, was die AI da gemacht hat. Also gefühlt greifst du ja alles. Ist das jetzt der Moment, wo wir alle Angst haben müssen, arbeitslos zu werden? Nee, es muss ja noch einer auf den Implement Button drücken. Der drückt sich. Ja nicht. Von alleine. Du hast mir nicht richtig zugehört. Da gab es einen grünen Implement Button. Dieses Feature, Github Workspacewar ja auch nur in den Laps. Das war ja jetzt gar nicht, dass das irgendwie direkt auf die Leute ausgerissen wird, oder? Genau. Deswegen ist ein Preview Feature ja. Das ist noch nicht. Das ist noch nicht G. Okay, aber so viel zur Github Univers. Wir haben noch zwei Themen. Ich probiere mal Angular 17 ein bisschen schneller zusammenzufassen, dass wir gleich ein bisschen Zeit haben für die Rubi und Rales Dokumentation. Genau, Angular hat eine neue Major Version rausgebracht. Wir haben schon schon lange nicht mehr drüber unterhalten und ich glaube, sie wollen auch mal wieder frisch und jung wirken. Deswegen kommt Angular 17 daher mit einem neuen Logo, einer neuen Website, neuen Developer Dokumentation, die auch wirklich ganz cool aussehen. Also haben sie ein süß neues Logo da gemacht. Cool auf jeden Fall. Und ansonsten viele Dinge, die man irgendwie so liest, fragt man sich so, dass das Angular Entwickler wirklich noch mit so Dingen gearbeitet haben mit manchen Syntax Konstrukten. So freut mich, dass ihr jetzt auch bessere Dinge bekommt. Und zwar also eine neue Features sind einerseits die Ferral Views, also dass man jetzt bestimmte Komponenten lasiloten kann. Hat auch ganz coole Features, zu definieren, wann genau sie gelasen werden sollen. Also beispielsweise wenn der Browser gerade nichts zu tun hat nach einer gewissen Zeit, wenn eine andere Komponente irgendwie in den View kommt, fangt dann an nachzuladen. Hat auf jeden Fall coole Syntax für Fallback, für Placeholder zu definieren und generell jetzt die Möglichkeit Views lasi zu loden. Und ansonsten, ich glaube, dass zumindest von der Syntax her das größte Neue, was aber erst mal noch im Developer Preview ist und noch nicht in General Availability erst mit der Angular Version 18 dann kommen soll, sind eine neue Syntax für diese ganzen NGF, NG Switch, NG4 Statements, die ja, ich weiß nicht, habt ihr schon mal mit Angular irgendwas geschrieben? So NGF, NG4, NG Switch? Machen auf jeden Fall keinen Spaß, wenn man. Ja, du hast ja gesagt. Ja, also ich habe tatsächlich Angular in den ersten zwei Versionen damals benutzt und schon damals gab es ja diese Framework Konstrukte und die waren immer sehr komplex im Handling, sagen wir mal. Ja und genau, also Angular Version 2 war auch noch die Version mit der ich gearbeitet habe. Danach bin ich ausgestiegen und jetzt gibt es neue Control Flows und sagen wir mal einfach etwas, was näher an JavaScript Syntax ist und was man glaube ich von anderen Frameworks auf jeden Fall so auch näher besser kennt. Also if Statements kann man jetzt wirklich, so wie man es aus JavaScript eigentlich kennt, eigentlich schreibt man JavaScript, if irgendwas, geschweifte Klammer auf, geschweifte Klammer zu, else das und Präfix das einfach nur mit einem @-Zeichen. Und schaut euch die Syntax einfach mal an. Macht auf jeden Fall jetzt einfach viel mehr Sinn und bestimmte Statements wie eben z. B. Das else direkt zu schreiben ist jetzt auf jeden Fall einiges einfacher geworden. Ansonsten sind ihre Implementierung für Signals, was so, wenn man jetzt aus der View-Welt kommt, was z. B. Refs sind oder Reaktives, sind Signals in Angular, die sind jetzt in Stable und können genutzt werden bis auf die Effektfunktion, das ist was in View Watch ist. Ist jetzt noch nicht in Stable, sondern weiterhin im Developer Preview. Auf jeden Fall auch super cool. Ansonsten weit in VEAD und ES Bild sind jetzt auch die Vorläufer bisher im Developer Preview. Das heißt, wenn man ein neues Angular Projekt aufsetzt, nutzt es VEAD und ES Bild, gibt ein paar neue Lifecycle Hooks. Und genau, schaut ansonsten einfach mal in die Doku rein. Die Nummer 17. Jetzt live. Jan, du hast uns ansonsten noch eine Dokumentation zu Rubi und Rales mitgebracht. Was ist das für eine Dokumentation? Ja, und. Zwar holen wir mal ein Stück weit aus. Hany Pot, also ich weiß nicht wer Hany Pot kennt, Hany Pot. I/o ist so eine Job Plattform und die haben vor ein paar Jahren so eine Community Content Page aufgebaut. Hany Pot Kalt heißt es so ein bisschen fragwürdig im Naming vielleicht, aber inhaltlich ganz cool, was die da machen. Und die haben unter diesem Namen Hany Pot Originals jetzt schon so verschiedene Dokus rausgebracht über The Original von React und View und Kubernetes und Docker und Prometheus und keine Ahnung was noch alles. Und ja, also. Dokumentation, du meinst keine Website? Nein, nein, nein, tatsächlich eine filmische Dokumentation, ein Hintergrundgespräch mit den Leuten, die sich das irgendwie ausgedacht haben, Interviews, irgendwie Nacherzählungen von irgendwelchen besonderen Ereignissen und so was alles. Also tatsächlich eine Dokumentation. Jetzt höre ich zu. Jetzt hörst. Du zu. Jetzt wird es ja spannend. Jetzt kommt der spannende Teil, nachdem wir alle Angular und Typeskripto. Irgendwie durchgehört haben. Also es ist tatsächlich immer sehr gut gemacht. Hoher Produktion Value, den sie da haben. Und da kam eben letzte Woche der Beitrag zu Rubi on Rales, das sind glaube ich so dreiviertel Stunde oder so, kann man sehr empfehlen und fängt eben so ein bisschen an zu erzählen, wo kommt Rubi on Rales her? Was ist der Hintergrund von von PAP, wie es da eben kam? Es hat Interviews mit den Gründern von 37 Signals, die ja Basecamp gebaut haben und Basecamp hat ja quasi Rubi und Rales hervorgebracht, weil sie ein Web Framework für Basecamp gebraucht haben. Und das hat eben super viele Insights. Das ist ja schon jetzt auch bald 20 Jahre her. Wie hat man damals zusammengearbeitet? Weil Coming from GitHub Universum, GitHub gab es ja damals noch gar nicht. Also wie hat man so Code ausgeteilt? Wie hat man so Versionen irgendwie verteilt? Wie hat man mit den Leuten Kontakt gehalten? Und ja, es gab kein GitHub. Aber warum gab es kein GitHub? Weil GitHub selbst ja auf Rubi und Rales gebaut ist. Das muss man sich halt auch mal so vor Augen halten, wie jung das irgendwie alles noch ist. So. Und wie grundlegend Rales dann am Ende halt auch ist, weil es einfach viel von dem, was heute so selbstverständlich ist, halt irgendwie darauf gebaut. Airbnb, Hirok, Basecamp und so weiter, das sind alles Rubi und Rales Produkte und das decken die da so ein bisschen ab. Wie gesagt, mit Json Freet, 37 Signals, Gespräch dabei auch mit David Heinemeyer-Hansson, der ja der Autor von Rubion Rates ist. Da muss man natürlich so ein kleines Ausrufezeichen dran machen. Also je nachdem, wie man selber so drauf und empfindlich ist, ist der Typ halt schon so ein laufendes Red Flag mit manchmal ganz fragwürdigen Äußerungen und Meinungen. Aber ich glaube, das muss man an der Stelle einfach ein bisschen sauber trennen. Und was für mich irgendwie auch ganz cool war, ich komme ja vorher noch von Shopify, Tobi Lütge, Gründer von Shopify war auch dabei, weil Shopify ja auch einer der ersten und größten Rales Nutzer ist und war für mich auch ganz cool, da Tobi nochmal drüber sprechen zu hören. Das war immer so ein bisschen creepy, wenn man bei Shopify gearbeitet hat und man arbeitet dann gerade am Rales, also am Framework Rales Source Code und auf einmal meldet sich so Tobi bei dir so: „Hey, ich sehe, du baust da was an RALS, am Core Framework, und hier ist meine Meinung dazu, wollen wir da mal irgendwie drüber quatschen? Okay, da ist schon irgendwie noch ziemlich investiert da und das merkt man auch irgendwie in der Doku noch. Also, summa summarum, irgendwie ganz cool. Ich glaube, RALS ist irgendwie bei vielen Leuten nicht so auf dem Radar, obwohl es eigentlich ein super, super Stack ist, riesengroße Produkte noch damit laufen. Und wenn man gerade in der Doku so ein bisschen sieht, dass am Anfang die Vorwürfe so waren, ja, Rubi, das kann ja irgendwie nicht skalieren und komm, hier lasst mal euer Hobby Projekt irgendwie da bei euch im Keller, wo es hingehört. Und heutzutage läuft irgendwie super viel vom Internet irgendwie auf auf Rubi und Rales. Ähnlich wie das auch immer so vom Framing her mit mit PAPs. Ist schon ganz nice. Also kann man kann man empfehlen. Sind glaube ich 45 gut investierte Minuten, wenn man so ein bisschen Kunst und Künstler brennen kann an der Stelle. Cool. Dann haben wir auch einen Sebi abgeholt, also dadurch, dass es keine Dokumentationsseite ist, und er sich berieseln lassen kann, heute Abend auf der Couch. Yes, klingt gut. Sehr gut. Ja, vielen Dank. Ich habe noch nie so eine Technologie oder Programmierdoku gesehen, glaube ich. Also das ist tatsächlich so der sehr emotionale Teil da dran, weil es natürlich, wir alle programmieren hier viel, wir beschäftigen uns damit und auf einmal hebt es halt so diesen Teil von unserem Leben in so eine Medienform, die du halt sonst irgendwie gar nicht damit in Verbindung bringst. Und das ist schon cool, wenn ich gucke, ich habe das auf dem Sofa am Fernseher geguckt. Ah, den Typ, den kenne ich, mit dem habe ich schon mal irgendwie auf einer Konferenz gesprochen. Oder ja, in dieses Problem im Slack bin ich auch schon mal gerannt und so. Und das ist so was, was du, glaube ich, was halt so vielleicht in anderen Jobs schon irgendwie immer mal gab, wenn man so Mainstream-iger unterwegs ist. Aber für uns ist das irgendwie, glaube ich, so ein sehr neues Erlebnis und macht es trotzdem irgendwie greifbarer und menschlicher. Das sind echt coole Formate, die sie da geschaffen haben. Ja, stimmt. Das ist echt, habe auch noch nicht drüber nachgedacht, dass es ja sonst selten das in diesem Format gibt. Ansonsten sind es halt eher Dinge, die irgendwie spielfilmiger produziert sind. Ich glaube wir hatten auch schon mal als Pick of the Day irgendwo The Billion Dollar Code von Netflix, wenn ihr die Serie gesehen habt. Das finden wir auch super cool zu sehen, wo es so ein bisschen natürlich ähnliche Vibes, aber nicht wirklich die Technologie geht, aber auch Technologie und so ein bisschen für das Nerd Herz, Nerd Herz höher schlagen lässt. Und am Ende zeigt es natürlich auch, dass alle irgendwie nur mit Wasser kochen auch. Also du siehst da so Leute, ich weiß nicht, ich fand das in der React Demo, in der React Doku super cool. Ja, also wir haben halt irgendwie was gebraucht, was dieses Problem für uns löst und haben dann so ein bisschen Code gegen die Wand geworfen, bis halt was funktioniert. Und auf einmal ist halt so durch so ein virales Schneeballsystem quasi so ein riesen Framework daraus entstanden. Ja okay, krass. Die haben also auch nicht von Anfang an den Masterplan gehabt, wie das so zu entstehen ist. Das ist auch so ein Aspekt, der in der in der Rales Doku jetzt hier wieder rauskommt. Die haben jetzt nicht erst überlegt, wie müsste das das ideale Framework aussehen, sondern wir haben Base Camp als Webprodukt gebaut und dann lernen von dem, was sie da gebraucht haben gesagt okay, und den Webteil von diesem Stack, den extrahieren wir jetzt in eigenstehendes Framework und das nicht in so einer Elfenbeinturm Diskussion sehr hochtrabend sich alles überlegt, sondern sehr pragmatisch da irgendwie rangegangen. Das ist natürlich schon immer so ein bisschen ein bisschen erfrischend, weil natürlich gerade auch bei uns in der Bubble das dann immer so ein bisschen overhyped wird und die Leute so ein bisschen über-ikonisiert werden von wegen ja, die haben ja, also die müssen ja mega schlau sein, wenn sie sich sowas ausgesacht haben. Nee, also die haben am Ende auch nur gebaut und gelernt dabei, wie wir alle irgendwie auch. Ja, cool, werde ich auf jeden Fall mal anschauen. Cooler Tipp. Dann Sebi, Jan, vielen Dank euch. Jan, ich glaube, du wolltest noch ein bisschen die Werbetrommel rühren, oder? Ja, einmal in eigener Sache. Also wir haben am 7. Dezember wieder das nächste Programmierbar Meetup anstehen. Das sind knapp gut drei Wochen. Diesmal mit einem starken Fokus auf Flutter. Wir werden was hören zu Widget Book, eine Bibliothek für Flutter, UI, Widget Management und Kollaboration. Und wir werden was über Animationen in Flutter hören. Und wir würden uns natürlich super freuen, wenn ganz, ganz viele von euch da vor Ort sind. Ihr könnt euch anmelden oder mehr Details dazu finden unter programmier. Bar/meetup. Und es wäre super cool, wenn ihr euch, wenn ihr kommen wollt, was ihr bestimmt alle wollt, auch im Vorfeld anmeldet, weil wir dann Catering und Verpflegung alles besser planen können. Wir freuen uns. Super. Dann bis dann. Ansonsten lasst uns immer Feedback da, podcast@programmier. Bar und wir hören uns nächste Woche wieder. Bis dann. Ciao. Ciao. Genau, bis dann. Ciao.