Transcript
[0:00] Ja das erste problem war dass dieses repository lisch. Das hat irgendein issue gehabt wo jemand nach einem link checker gefragt hat und da hatte ich einfach naiverweise geantwortet ich habe einen geschrieben und hier ist meine version die erste funktionalität die ich eingebaut habe die nicht alle link checker hatten war github support.
Ich habe mich gerade nebenbei gefragt gibt es hier mit emojis klar ja freilich es gibt emoji.
Ja, ja, pfff, schön nerdig, nix mit Frontend, aber letztlich ja auch nichts wirklich mit Backend.
Betrifft halt alle, ne? Ja, nur End.
[0:40] Music.
[1:05] Revision 569, Diese Revision von Working Draft wird euch präsentiert von Midwild, dem Hoster für Agenturen und Freelancer.
Bei Midwild findet ihr für jedes Projekt das passende Hosting.
Zum Beispiel könnt ihr auf dem ProSpace eine eigene virtuelle Maschine konfigurieren.
RAM auswählen, CPU-Kerne abzählen, Speicherplatz festlegen und BÄM, fertig.
Jetzt denkt ihr euch vielleicht, nije, das kann ich bei meinem alten Gammel-Hoster auch machen, jahaha.
Aber bei Midwild könnt ihr auch, wenn ihr wollt, zum nördigen Space-Server upgraden.
Damit verfrachtet ihr all eure Projekte in die Managed Cloud, profitiert von maximaler und habt trotzdem alles an einem Ort, zentral verwaltet hinter einem Login.
Und dann ist es plötzlich ein leichtes, sich Shop-System-Installationen mit Redis-Anbindung zu verwalten.
Oder vielleicht wollt ihr auch nur drei WordPress-Installationen unterbringen.
Egal, was ihr vorhabt, bei Midwald findet ihr für jedes Projekt das passende Hosting.
Schaut's euch an unter midwald.de slash workingdraft. Das schreibt sich M-I-T-T-W-A-L-D punkt D-E slash workingdraft.
Alle Infos zu Midwald findet ihr natürlich auch in den Chownotes zu dieser Revision.
Wir danken mit Wald für die Unterstützung von dieser Revision von Working Draft.
Revision 569: Von Link-Checkern und Rabbit Holes
[2:18] Wir sind heute zu dritt aus dem team hätten wir da die vanessa hallo ich bin der schepp und das bedeutet dass wir wieder ein gast da haben und zwar den matthias endler.
Hallo hi zugeschaltet aus düsseldorf.
Aber bayer erzähl doch mal wer bist du was machst du. Ja wir haben hier ich sitze in düsseldorf du sitzt in düsseldorf äh vanessa ist äh bei bayerin du bist bayer also da haben wir schon die connection.
Ich bin geboren jetzt bin ich hier was ist dazwischen passiert ich komme tatsächlich aus bayern.
Aufgewachsen mochte immer schon computer habt ihr auch computer science studiert in bayreuth und bin jetzt seit 2014 in düsseldorf.
Hab angefangen hier bei Trivago zu arbeiten, das ist eine Hotelsuche, war da im Backend.
Hab da viel Elasticsearch und Container und Cloud gemacht.
Dann angefangen Go zu lernen und andere Programmiersprachen.
Und hab dann irgendwann gemerkt, Python und Go, das ist vielleicht nicht so meine Welt.
Ich suche mir mal was anderes und ich fand es eigentlich auch ganz spannend mal in Rust reinzuschauen.
Mich da auch ein bisschen festgesetzt und dann angefangen zu bloggen und hatte auch mal einen YouTube-Channel zu Rust und dann dachte ich irgendwann, ich mache mich selbstständig in dem Bereich und mache jetzt mittlerweile Firmenberatung und Performance-Optimierung im Backend-Bereich, hauptsächlich Rust.
[3:45] Hattest du auch ein podcast war nicht auch was oder war das dieser youtube channel.
Das war nur der youtube channel wir hatten tatsächlich einen kleinen podcast ja das war der podcast für open podcast jetzt wird es natürlich.
Sehr recursiv aber wir hatten ein kleines startup oder beziehungsweise ein projekt was gefördert wurde von der bayerischen staatsregierung und da geht es um eine offene podcast analyse plattform, Das hatte ich zusammen gemacht mit Wolfgang Gaßler und im Rahmen dieses Projekts haben wir so einen kleinen Podcast gestartet.
Der ist aber jetzt auch schon wieder ausgelaufen. Der Wolfgang macht allerdings auch weiterhin Podcasts mit Engineering Kiosk.
Grüße gehen raus.
Ja. Und der ganzen Materie bin ich nicht fern, ja.
[4:31] Cool. Genau, und heute wollen wir aber gar nicht über Rust sprechen und auch nicht über Elasticsearch.
Oder mutmaßlich nicht, vielleicht kommt Elasticsearch ja trotzdem vor.
Sondern du hattest mal erzählt, dass du quasi einen URL-Crawler letztendlich gebaut hast, was ja erst mal so relativ banal klingt vielleicht.
Und man sich relativ einfach vorstellt, also so, ja, wenn ich einen Link-Crawler bauen will, was brauche ich da? Zwei Abende und dann ist das Ding wahrscheinlich fertig.
Aber der Twist ist natürlich, so einfach ist es nicht.
Und ja, du hast irgendwie bei diesem Projekt allerlei wilde Dinge erlebt und gesehen und Probleme lösen müssen.
Und da haben wir gesagt, da könnten wir eigentlich ja mal im Podcast drüber sprechen, was dir da so alles untergekommen ist und wie man das halt macht generell.
[5:38] Der eine hat der andere ist jetzt wahrscheinlich schon weggeknickt ich hoffe jetzt mal nicht dass das langweiligste thema aller zeiten ist zumindest dachte ich am anfang dass es super langweilig ist.
Hat sich aber rausgestellt ist gar nicht der fall.
Also wenn man jetzt irgendwie tief im back end ist und marktroller oder parser dann ist es nie langweilig aber.
Kann mir vorstellen für die allermeisten leute ist es jetzt nicht unbedingt ein thema für eine cocktail party also wie ging das ganze los das war 2015, Da hatte ich nämlich bei Trivago irgendwann die Aufgabe bekommen im Recruiting mitzumachen und wir haben sehr, sehr viele Case Studies bekommen und ich wollte ein Tool haben, was einfach verschiedene Linter auf diese Case Studies laufen lässt, um mir so ein paar Hinweise zu geben, in welche Richtung ich mal nachschauen soll und wo es vielleicht Inspirationen gibt, dass man Verbesserungsvorschläge macht.
[6:28] Jetzt gar nicht zur Bewertung, sondern einfach nur, um festzustellen, wie ist so generell die Richtung von der Code-Quality in der Case-Study.
Und dafür hatte ich einen Linter gesucht, oder ein statisches Code-Analyse-Tool damals, für PHP.
Und es gibt viele PHP-Tools, und habe angefangen, eine Liste zu schreiben.
Einfach eine ganz normale Markdown-Datei und dann halt 10 oder 20 Tools da reingeschrieben.
Und dann ist die Liste halt immer weiter gewachsen und gewachsen.
Und irgendwann waren es halt dann 700 Tools und 11.000 Sterne auf GitHub und Leute haben halt dann angefangen, ihre eigenen Tools hinzuzufügen und Firmen haben dann ihre Listen maintained und so weiter. Und das wurde dann irgendwann ein richtiges Side-Project und dann habe ich gemerkt, dass es sehr nervig ist, das zu maintainen, weil ungefähr jede Woche sind zwei oder drei Tools einfach verschwunden oder die Webseiten waren down und das ist ein riesen Problem, wenn man halt 700 Links checken muss, regelmäßig mit URL und GitHub und so weiter. Und Anfang August 2020 habe ich dann festgestellt, okay, da muss eine Lösung her. Ich will das nicht selber machen.
[7:40] Immer die issues klausen von leuten die irgendwelche tools nicht mehr finden können und das ist frustrierend und dann dachte ich ja gut nimmst du halt einfach einen link checker suchst du ein github tool und baust das ein und fertig.
Und es gab zu dem zeitpunkt schon ziemlich viele link checker das ist jetzt nichts was ich erfunden habe es gab zum beispiel einen der hieß litsch oder lich von ravik und der war super gut der war in go geschrieben.
[8:09] Und der war aber leider nicht mehr maintained. Und dann hatte ich andere gefunden, auch die großen Markter und LinkCheck zum Beispiel, aber die waren ziemlich langsam.
Und dann hatte ich welche gefunden, da habe ich einfach die Runtime nicht gehabt.
Also ich wollte nicht irgendwo eine große Ruby- oder Python-Runtime installieren.
Ich wollte was Kleines haben, was wenig Speicher braucht und was vor allen Dingen wenig False Positives hat.
Weil, wie wir wahrscheinlich noch sehen werden, es ist ein komplexes Problem Und es gibt ziemlich, ziemlich viele Fallstücke, an die man am Anfang nicht denkt.
Und ich hab dann auch nicht gedacht, weil ich dachte eigentlich auch, ich schreib das an einem Wochenende.
Und tatsächlich war es so, dass ich gar nicht gedacht hab, dass das jetzt ein Projekt wird, sondern ich hab das als Episode für Hello Rust gemacht.
Das heißt, wer uns interessiert, der kann sich einfach die Folge anschauen.
Und da sieht man die erste Version, also von der ersten Zeile an, wie das Tool entstanden ist.
Und am Ende von dem Wochenende hatte ich halt ein Tool, was zumindest mein Repository checkt, das dann eingebaut und wollte dann einfach nicht mehr weitermachen an der Stelle und dann kamen Leute mit ihren eigenen Problemen und so ist das dann entstanden.
Aber die haben das dann sozusagen missverstanden oder also das war dann sozusagen ein eigenes kleines Repo und dann sind Leute angekommen haben das gefunden und wollten das benutzen und dann hat sie die alle sozusagen an den Hacken.
[9:30] Ja, das erste Problem war, dass dieses Repository Lish, das hat irgendein Issue gehabt, wo jemand nach einem Linkchecker gefragt hat. Und da hatte ich einfach naiverweise geantwortet, ich habe einen geschrieben, ich fand den vorherigen auch gut und hier ist meine Version.
Und dann wurde das in das README aufgenommen von dem Tool und dieses Tool hatte sehr viele User und deswegen kamen, zum allerersten Mal eigene User und die wollten vielleicht auch eigene Features wieder haben.
Und ich habe halt so ein Helfer-Syndrom und dachte mir, okay, die kleine Sache kannst du noch einbauen und dann ist das Tool komplett.
Und dann kannst du vielleicht die Sache noch einbauen und dann ist er wirklich fertig.
[10:09] Die erste Funktionalität, die ich eingebaut habe, die nicht alle Linkchecker hatten, war GitHub Support.
[10:15] Weil ziemlich schnell läuft man in rate-limiting-Problemen bei GitHub.
Wenn man 700 Tools checkt, Open-Source-Tools, dann ist bei 500 vielleicht Schluss oder bei weniger.
Und deswegen dachte ich, okay, wenn's ein GitHub-Link ist, dann check ich das über die API.
Und ja, das funktioniert ziemlich cool. Man kann den API-Key angeben.
Und der Vorteil ist auch, dass man dann seine privaten Repos checken kann dadurch.
Weil das ist ja ein Token, das man hat. Und das gilt ja auch für private Repositories.
Und von Anfang an haben wir ja auch gewusst, dass das Tool asynchron sein muss.
Weil Link-Checking ist network-bound. Das heißt, man hat ziemlich hohe Latenzen auf verschiedene Webseiten.
Aber man kann sehr, sehr viele Webseiten konkurrierend, also concurrent prüfen.
Das geht sehr, sehr gut. Und der Vorteil davon ist, dass eigentlich der Kernel die meiste Arbeit macht und nicht der Userspace.
Und dadurch kann man die Memory-Usage und die CPU-Usage extrem runterdrehen, weil eigentlich die ganze Arbeit auf der Netzwerkkarte passiert.
Und damit kann man die Netzwerkkarte eigentlich auslasten, bis zu einem gewissen Punkt. Und deswegen wollte ich das von Anfang an haben.
Das war so der Anfang, wo es dann losging, wo Leute gemeint haben, ah ja, okay, das ist vielleicht ein Tool, das mehr bietet als manche anderen Tools.
[11:42] Und das hast du in Rust dann geschrieben, weil du gesagt hast, das hast du in deinem YouTube vorgestellt?
Ja, oder?
Rust ist natürlich die sprache die mir am meisten liegt aber ich finde auch dass es die sprache ist die mit am meisten sinn macht für so ein tool, immer mehr tools auch im frontend bereich werden jetzt mittlerweile in rust geschrieben vor zwei tagen hat rough das ist ein python linter, ein vier millionen dollar funding bekommen von versell gebackt und das ist auch in rust geschrieben.
Und man sieht halt einfach immer mehr, dass so Infrastruktur-Tools und so Developer-Tools immer öfter in Rust auch geschrieben werden.
Das ist schon definitiv der Fall. Für mich war es irgendwie klar, dass es in Rust sein muss, weil Rust hat ein relativ gutes asynchrones Ecosystem mit Tokio.
Und in Tokio kann man Network-Links asynchron checken und man hat den Vorteil, dass man keine Runtime hat.
Eine Runtime hat. Das heißt, man hat keinen Overhead wie in JavaScript mit Promises beispielsweise.
Und es ist eine relativ einfache Umgebung. Man programmiert einfach nur Rust. Aber im Hintergrund passieren sehr, sehr viele Dinge mehr oder weniger magisch und gesichert durch das Typ-System, was das Ganze extrem schnell und elegant macht. Und deswegen ist es einfach Und eine gute Sprache dafür, genau für dieses Problem.
[13:12] Mhm. Ja, da kann man auch noch mal verweisen auf die ... Wir haben auch eine Rust-Folge gemacht vor ein paar Monaten.
Genau, da hier der Stefan aus unserem Team, der ist auch so ein Rust-Nerd, der ...
Und wir hatten auch zwei Gäste da, die ein Rust-Buch geschrieben haben.
Und die drei haben dann wild vor sich hin erzählt.
Stefan K natürlich. Natürlich. Genau, und da fiel natürlich auch Tokio und äh genau ähnliche Frameworks.
Ja, cool.
[13:47] Ja, also vielleicht mal ganz kurz zur Architektur von so einem Tool.
Also wie funktioniert grundsätzlich der Ablauf? Es ist ja so, erstmal ist die Frage, welche Inputs hat man denn überhaupt?
Wo kommen die Links denn überhaupt her?
Da gibt es natürlich die Möglichkeit, dass man Markdown-Dateien prüft.
Und da muss man sich ja fragen, welches Markdown? Weil es gibt ja nicht ein Markdown-Format.
Es gibt ja verschiedene.
Weil Markdown ist ja von Gruber in Version 1.0 mehr oder weniger stabilisiert worden, aber danach gab es natürlich immer noch weitere Entwicklungen. Es gibt zum Beispiel das GitHub Markdown und Common Mark und so weiter. Und deswegen gibt es quasi einen Parser, der die Markdown-Dateien liest. Und ebenso gibt es einen Parser für HTML. Das ist die, Die Browser-Engine Servo, die hat einen Parser und der ist auch sehr, sehr gut.
Damit wird HTML geparst und dann gibt's die Möglichkeit, Webseiten zu checken.
Das wird auch mit Requests geparst. Das ist ein Crate, ein Rust-Crate für HTTP-Requests.
[14:56] Und dann gibt's aber noch einen Plain-Text-Parser, der alles andere parst, was es so gibt.
Aber was ganz wichtig ist bei der Sache, so ein naiver Ansatz reicht nicht.
Also, jeder Backend-Ingenieur hat vielleicht schon mal einen Link-Checker geschrieben, aber die meisten haben dann irgendwie gemeint, okay, ich nehme den regulären Ausdruck, ich gehe über die Datei und ich prüfe halt irgendwie, wo zum Beispiel Doppelpunkt Slash steht oder www Punkt und so weiter.
Aber das Problem an der Sache ist, dass man sehr, sehr viele False Positives hat.
Hat. Also beispielsweise...
[15:27] Nicht jede Webseite hat www. beispielsweise. Es gibt mehrere Möglichkeiten.
Man kann auch zum Beispiel sagen, okay, dann fängt halt ein Link mit http:// an.
Ist auch nicht der Fall, weil es gibt auch https. Es gibt auch zum Beispiel Slack-Schemes oder File.
Aber es gibt auch zum Beispiel Links, die haben überhaupt kein Scheme.
Und wenn man zum Beispiel www.// hat, dann verweist das auf das Scheme von der Origin-Webseite.
Und solche Sachen vergisst man oft. Und dann ist auch die Frage zum Beispiel, wie handle ich Query-Parameter?
Sind die relevant oder nicht?
Was ist mit Ankern in URLs? Und so weiter und so weiter. Das heißt, so ein naiver Ansatz funktioniert nicht.
Das heißt, man muss aufpassen, dass man von Anfang an den richtigen Parser benutzt.
Und dieser Parser liest dann die Datei und schmeißt diese Links, die er findet, in eine Queue.
Und dieser Teil nennt sich Extractor.
[16:27] Und dann in dieser Queue, das ist einfach nur eine Warteschleife, da werden diese Links dann abgearbeitet, nach und nach, und zwar asynchron.
Das heißt, man liest mehrere Links aus der Queue und prüft die dann mehr oder weniger concurrent, also gleichzeitig.
Und die Ergebnisse werden dann wiederum gesammelt in einer anderen Queue, wo die dann weiterverarbeitet werden.
Jetzt fragt man sich natürlich, warum ist das so kompliziert?
Wieso brauche ich überhaupt zwei Queues?
Naja, man will auf jeden Fall vermeiden, dass an irgendwelcher Stelle irgendwelche Bottlenecks entstehen, dass man sich blockiert.
Und jetzt könnte man zum Beispiel sagen, okay, wenn ich jetzt beispielsweise nur eine Queue hätte und würde da alle Links reinschmeißen und würde dann zum Beispiel auch direkt die Ausgabe machen, das würde ja auch gehen.
Aber dann kann es halt passieren, dass diese Queue zum Beispiel geblockt wird durch irgendeine Webseite, die zu langsam ist. zum Beispiel auf der Ausgabeseite dann blockiert und solche Sachen muss man halt dann entsprechend vermeiden.
Und ja, letztendlich gibt's auch verschiedene Ausgabeformate, JSON, Markdown und so weiter für verschiedene, ja, Verwendungsmöglichkeiten, sag ich jetzt mal.
Das ist so ganz grob der Überblick, wie das Ding jetzt aufgebaut ist.
[17:44] Bei dem HTTP und HTTPS hatte ich erst vor ein, zwei Wochen das Gespräch mit iOS-Developern, die mich gefragt hatten, du, wir bekommen grad von uns kein Backend, Da steht einfach nur slash, slash, das kann doch nicht gültig sein.
Und dann muss ich auch erst mal so an früher überlegen. Und hab gesagt, doch, doch, das funktioniert im Browser.
Weil es schaut dann nach, ob es HTTPS gibt, denke ich.
Und wenn ja, nimmt's das. Und wenn's es nicht gibt, dann fällt's zurück auf HTTP.
Damit konnte die iOS-App allerdings anfangen.
Ich weiß nicht, was jetzt damit genau der Plan war, ob sich das in einem Browser hätte öffnen sollen oder was anderes.
Aber auf jeden Fall, die waren, was sollen wir machen? Ich meine, so, mach mal HTTPS, das wird schon funktionieren.
Vielleicht was sogar für Bilder oder irgendwie so was. Aber das, ja, ist naiv, funktioniert nicht überall.
Mhm. Ja, das wird vor allen Dingen dann benutzt, wenn man eine Webseite hat, die HTTP und HTTPS unterstützt.
Und man nicht will, dass ein User zum Beispiel das Protokoll ändern muss, um mit der Seite zu kommunizieren.
Also nicht jeder Browser kann zum Beispiel HTTPS.
Es gibt auch alte Screenreader, die das nicht beherrschen beispielsweise.
Und dann ist es vollkommen okay, wenn die HTTP weiterhin benutzen.
Aber man müsste ja auf der Webseite dann irgendwie so ein Fallback haben.
Und um das zu vermeiden, kann man dem Browser einfach mitteilen, benutze einfach das Protokoll, das du eigentlich eh schon benutzt hast vorher.
[19:08] Ja. Vorsichtig bin ich auch geworden bei unserem Projekt. Da kann man Learning Resources hochladen und da einen Link hinterlegen.
Und ich hab mir schon überlegt, ob ich's überhaupt validieren soll.
Im schlimmsten Fall öffnet sich halt eine kaputte Seite, wenn die URL nicht stimmt.
Aber ich dachte mir, ich schaue zumindest nach, ob es eine gültige URL ist.
Ansonsten schreibe ich hin, bitte gibt eine gültige URL ein.
Es war sehr schwierig, eine Regex zu finden, die tatsächlich aussagen kann, ob das eine gültige URL ist.
Ich habe ja an offensichtliche, an für mich offensichtliche Details habe ich dran gedacht.
Aber aus irgendeinem Grund habe ich gedacht, weil ich weiß ernsthaft nicht, warum, dass es zumindest drei Buchstaben haben sollte, der innere Teil.
Aber die eine Domain war v2, Punkt. Okay, die ist nicht durchs Raster gekommen.
[20:02] User hat sich gnädigerweise beschwert, dann konnte ich's anpassen.
Ja, Twitter wurde doch jetzt auch in Xcorp umbenannt.
Also, Twitter heißt tatsächlich nicht mehr Twitter die Firma.
Und das liegt daran, dass der bekloppte Elon, der hat quasi diese Xcorp schon immer für SpaceX und Co.
Und der hat auch die Domänen x.com.
Mhm. Genau.
Ja, also so naive Ansätze funktionieren definitiv nicht. Also zum Beispiel hat nicht jede URL ne TLD, also .com oder so muss ja nicht sein.
Man denke an Localhost beispielsweise. Und auch das Protokoll ist nicht nötig.
Und wenn man jetzt nur Localhost beispielsweise nimmt, ja das ist schon ziemlich schwierig im Plaintext zu parsen.
Und da fallen diese ganzen Krücken dann auseinander irgendwie.
[20:58] Aber es gibt zum Beispiel noch viel naivere Dinge, an die man am Anfang gar nicht denkt.
Also zum Beispiel auch einfach langsame Webseiten oder große Webseiten.
Wenn man jetzt zum Beispiel einen Linkchecker schreibt und man sagt, ich checke jetzt example.com.
Was kann da alles so schlimmes passieren also beispielsweise kann die webseite in den coding zurückgeben mit dem man nix anfangen kann also nicht jede seite ist ja unicode.
[21:27] Und oder aski und das andere was passieren kann ist die webseite.
Liefert erstmal gar nichts zurück, sondern wartet einfach erstmal 10 Minuten.
Ist das dann jetzt ein Fehler oder nicht? Wo setzt man jetzt da das Limit an?
Oder die Webseite ist super groß. Also angenommen man hat jetzt eine Webseite, die ist unglaublich groß. 10 Terabyte groß.
Das ist ja größer als der Arbeitsspeicher, den die meisten Laptops haben.
Und wenn man jetzt so eine Webseite trotzdem parsen will, dann reicht es nicht, wenn man einen naiven Parser benutzt.
Weil man kann nicht das ganze Dokument auf einmal in den Arbeitsspeicher laden.
Das heißt, man muss das stückweise laden.
Und da muss man auch zum Beispiel einen Streaming-Encoder einsetzen.
Und deswegen sind wir zum Beispiel auch weggegangen von dem Server-Browser, weil der das nämlich macht, der liest alles in den Speicher.
Und das geht bei manchen Seiten einfach nicht.
Und haben dann angefangen, den eigenen HTML-Browser oder eine Engine zu schreiben.
Und bevor jetzt alle weglaufen, also, ich hab das jetzt nicht alleine gemacht, sondern das ist der Markus Unterwadetzer, der auch bei Sentry ist.
Der hat angefangen, einen Streaming-HTML-Parser zu schreiben. Der heißt HTML-Gum.
[22:41] Und damit kann man Webseiten parsen und gleichzeitig die Links checken.
Und dann macht man das so in dem Streaming-Verfahren. Das heißt, man hat einen konstanten Speicherbedarf.
Und das sind sachen an die man definitiv am anfang jetzt erstmal nicht denkt das sind aber eigentlich auch noch die relativ harmlosen sachen.
Man kann das beliebig forttreiben, man kann absolut paranoid werden und sich nur noch auf Link-Checking konzentrieren.
[23:08] Und nach zwei jahren sitz mal hier und der matthias macht immer noch link checking.
Na ja zumindest nach acht jahren wenn ich jetzt richtig gerechnet habe.
Jaja aber der der link checking part der war erst 2020 aber zu tun hat man damit eigentlich sein leben lang ja ja ja das ist wie finanzamt man hat sein leben lang damit zu tun genau.
Ja, das ist das ja irgendwie so, dass das Schöne und das Blöde am Web, dass irgendwie jeder alles erlaubt ist, aber genau uns, aber quasi keine, es gibt zwar Standards und Regeln, aber am Ende sind es halt doch sehr viele, ja genau, 22 und ja cool.
[23:59] Genau, und dann wahrscheinlich, also du hast gesagt, du hast Markdown-Parser und Plaintext-Parser und HTML-Parser schon für den Input, das heißt also, man kann entweder eine wahrscheinlich eine Datei auf dem lokalen System einfüttern, oder man sagt, hier ist quasi im Web eine URL oder eine Ressource und bitte prüfe die.
Genau, also wenn man auf den lokalen Fall zum Beispiel zurückgeht, dann ist ein großer Use Case von Litschi, dass Leute ihre Entwicklerdokumentation checken wollen.
Das heißt, die haben irgendwo einen Static Site Generator, der generiert HTML-Dateien.
Die liegen dann irgendwo in einem Ausgabeverzeichnis, zum Beispiel slash public oder slash private.
Und da liegen dann die gerenderten HTML-Dateien drin. Und dann will man einfach nur checken.
[25:00] Sind diese Links untereinander valide?
Also die Verlinkung in der Webseite selbst, ist die korrekt?
Und dafür muss man gar nicht eine Netzwerk-Request machen.
Legi kann nämlich rekursiv über ein Dateisystem gehen, alle validen Links suchen und dann auch die Verlinkung zueinander prüfen.
Man kann dann zum Beispiel so einen Base-Directory einstellen.
Du kannst sagen, okay, wenn du Slash hast, also zum Beispiel einen relativen Link, der mit Root beginnt, also sagen wir mal slash about.html, dann mach das relativ zu diesem Verzeichnis.
Dann steht dann irgendwie slash public slash about.html oder slash public slash about slash index.html.
Das ist ja in manchen Browsern oder beziehungsweise Webservern auch valide oder äquivalent.
Und da ist zum Beispiel auch die Sache, wenn man jetzt eine Webseite hat, die hat einen About-Link, und man weiß jetzt nicht, auf welchem Webserver das läuft, dann kann man unmöglich entscheiden, ob ein Link valide ist, wenn es eine Webseite gibt, slash about slash index.html, weil das kommt zum Beispiel auf die Konfiguration vom Webserver drauf, an.
Kann man einstellen, ja, index.html ist das Root oder man kann sagen, nein, es gibt kein Root.
Und machen Datei-Listing beispielsweise. Und ja, wie prüft man sowas, ja?
[26:28] Wie prüfst du denn die Links, also was ist für dich dann oder in dem Tool ein Link, der okay ist, also du klapperst quasi dein Input-Dokument ab und dann reicht es schon, wenn da quasi unter dem Request dann was zurückkommt?
Wahrscheinlich nicht, das hast du ja jetzt gerade angedeutet, weil das würde ja bei einem Directory-Listing würde ja auch eine HTML-Seite zurückkommen, nur eben einfach überhaupt nicht die erwartete.
Also nicht konkret ein dokument genau kannst du kann man das irgendwie kann man das überhaupt maschinell bewerten so ob das sinnvoll ist was da zurückkommt oder nicht.
[27:09] Tatsächlich ist das auch ein ungelöstes problem und es gibt sehr sehr viele was wenn fälle in der situation also wiederum der naive ansatz wäre zu sagen.
Wenn der Statuscode 200 ist, dann ist die Seite korrekt.
[27:25] Und ansonsten nicht. Dann könnte man sagen, okay, was ist denn mit 204?
204 liefert dir zum Beispiel keinen Content zurück, aber ist auch technisch gesehen valide.
Wird oft bei API-Requests zum Beispiel benutzt. Dann könnte man sagen, ja, okay, dann ist halt jeder 200er oder 2xx-Request ist dann valide, und alles, was drüber ist oder drunter, das ist dann inkorrekt.
Ja, dann müsste man zum Beispiel sagen, was ist mit 303 oder 302, also ein Redirect. Ist der dann valide oder nicht? Also akzeptiere ich zum Beispiel einen Redirect oder zwei oder hundert oder tausend, Also ist das auch ein valider Case?
Und die Antwort ist, es kommt darauf an, ja, wie man das halt selber sieht.
In Litchi kann man den Status-Code einstellen, den man als valide bezeichnet und kann das halt selber bestimmen.
LinkedIn beispielsweise liefert dir einen 999-Status-Code zurück, der in keiner Dokumentation vom Web, soweit ich weiß, korrekt ist.
Es gibt keinen 999-Status-Code.
Aber was die damit sagen, ist, ich will nicht, dass du mich crawlst, ja?
Und da muss man zum Beispiel auch einen Workaround finden, um LinkedIn zu crawlen oder zu sagen, okay, ist die Seite valide oder nicht.
Jetzt, wenn eine Seite beispielsweise partout nicht will, dass man sie crawlt, dann kann man wenig machen.
[28:48] Und heutzutage ist es halt so, dass viele Webseiten sehr JavaScript-intensiv sind und man nicht an die Links kommt.
Oder dass die hinter Cloudflare-CDNs liegen und da ist nochmal so eine Bot-Detection davor.
Und man kann natürlich anfangen mit Browserspoofing. Und auch da haben wir schon rumgespielt.
Aber das sind lauter Edge-Cases, die relativ schwierig sind.
Und die das Ganze halt wirklich extrem schwierig machen.
Und irgendwann geht man halt her und hat dann eine Browser-Engine, die man selber laufen lässt.
Und ein Ansatz wäre zum Beispiel, einen Headless-Chrome-Browser zu benutzen.
Aber nicht in jeder Umgebung. Zum Beispiel auf FreeBSD oder auf OpenBSD gibt's einen Headless-Chrome.
Und was ist dann die Möglichkeit? Und der aktuelle Ansatz, mit dem wir jetzt momentan auch arbeiten, zwei Studenten aus, in der Schweiz, die arbeiten tatsächlich auch an dem Problem gerade, die versuchen, so eine kleine Web-Assembly-Runtime zu bauen, in der dann ein Dino-Worker läuft und dann die Webseite mit der JavaScript-Engine, also V8, dann rendert und dann die Links extrahiert.
Das ist zum Beispiel ein Ansatz, den man wählen kann.
[30:02] Ja, aber tatsächlich, um überhaupt zu wissen, ob eine Webseite valide ist, muss man sehr, sehr viel über den Use Case wissen.
Und selbst dann gibt es immer noch Edge Cases, die man sehr, sehr schwer abdecken kann.
Also, ich nenne jetzt einfach mal nochmal, ich hau mal noch einen raus, ich nenne mal nochmal einen Edge Case, an den man vielleicht auch nicht denkt, wenn man beispielsweise einen YouTube-Link kontrollieren will.
Will. Also man hat zum Beispiel ein YouTube-Video und man sagt, ist das jetzt online oder nicht, dann reicht es nicht zu sagen, nimm die YouTube-URL und schau, ob das Video da ist oder schau, ob ich einen 200er zurückkriege. Weil bei YouTube ist es so, dass ein Video zum Beispiel privat sein kann. Und YouTube liefert sogar einen 200er zurück, selbst wenn das Video gar nicht existiert.
[30:51] Das heißt, da muss man einen Workaround finden. Und man muss vor allen Dingen einen Workaround finden, der ohne JavaScript-Engine funktioniert, weil das ja auf der Kommandozeile ausgeführt wird.
Und ein Weg, das zu tun ist, das Thumbnail zu prüfen.
Weil YouTube die Thumbnails separat ablegt. Und die liefern tatsächlich einen 404 beispielsweise zurück, wenn die Thumbnail nicht existiert.
Und die löschen gleichzeitig das Video.
Ja. Aber das ist hier wirklich schon extremes Detailwissen. Das kann sich ja auch jederzeit ändern.
Also, Sie könnten ja sich umentscheiden. Wir hatten ein ziemlich ähnliches Problem, von gerade diesen Learning Resources, von denen ich gesprochen habe, wo man die URL hinterlegen kann, können die Personen natürlich auch Vimeo-Videos oder Sonstiges hochladen.
Oder Microsoft Share, was weiß ich was.
Und wir versuchen, sie auch zu embetten. Das funktioniert bei manchen Sachen extrem einfach.
Und manche andere Sachen können dann hinter Passwörtern liegen.
Aber für uns existiert die Seite, die Seite existiert, also versuchen wir, sie zu embedden.
Und es geht noch halbwegs, wenn man ein Passwort braucht, weil sie es dann auch im iFrame benutzen dürfen, aber manchmal ist es dann einfach mit einem SSO-Login und das müsste dann der Account im Browser sein, und dann wird schon ziemlich schwierig.
Also wir haben halt schon immer als Ausweg noch, oder klick auf dieses Icon, dann öffnet sie es einfach in einem Topf auf die richtige Seite.
[32:20] Aber es gibt keine richtig gute Lösung, außer wir würden da wirklich eine Person mal sehr lange dran setzen, um das alles durchzudenken.
Und das macht man nicht mal zwischen den Meetings.
[32:34] Das Tragische ist eigentlich, dass Crawling oder eigentlich das komplette Web, zumindest maschinenlesbar nicht funktioniert.
Es ist eigentlich ausgelegt auf Menschen, die den Content lesen, aber es ist kein maschinenlesbares Format.
Und das ist vielleicht auch ganz gut so, weil wir sind ja vielleicht, viele von uns sind mit HTML groß geworden und haben da unsere ersten Schritte gemacht.
Ich finde das supergut, dass man das lesen kann und dass man das mit einem normalen Texteditor schreiben kann.
Nur das macht es natürlich umso schwieriger, um das auf Scale zum Beispiel zu betreiben und damit Millionen von Links in der Woche zu checken, weil es halt einfach so so viele Edge Cases gibt.
[33:18] Das ist das Tragische schon. Hast du denn dein eigenes Problem, also wie hast du das denn lösen können?
Weil du hattest ja gesagt, du hast diese Tool-Sammlung oder eben quasi eine Sammlung von Code-Quality-Tools und hast dann 700 Stück irgendwann zusammen und da waren irgendwie immer wieder welche, die dann verschwunden sind.
Wenn du jetzt Litchi darauf angesetzt hast, wie ...
Also, ich stell mir halt vor, du hast irgendein Tool, das ist vielleicht auf einem GitHub-Repo gewesen oder so was, und dann wird das GitHub-Repo gelöscht, und ich weiß nicht, was dann passiert.
Dann wird wahrscheinlich auf die GitHub-Startseite umgeleitet, oder ... Obwohl, nee, dann gibt's auch eine 404-Seite, ne?
Genau, also da hast du dann schon relativ viel viel eigentlich Erfolg gehabt, in Anführungszeichen, mit, du kriegst schon relativ viel 404-Rückmeldung.
Also würdest du sagen, das Web ist generell einigermaßen okay konfiguriert, was Status-Codes angeht?
Oder ist das Web tendenziell eher scheiße konfiguriert und nur manchmal gut?
[34:32] Es wird schlechter. Mhm. Sehr, sehr viele Links gehen kaputt.
Überraschend viele interne Links. Ich habe mal irgendwie eine Statistik gehört, ich weiß nicht, ob das stimmt, dass die Hälfte der Links innerhalb von zwei Jahren kaputt gehen.
Also die Halbwertszeit ist wirklich nicht gut.
Und vor allen Dingen für Ressourcen, die öffentlich zugänglich sein sollten, also sprich Public Data oder so, ist es sehr, sehr schlimm.
Also wir haben zum Beispiel einen User, der hat immer wieder Probleme mit diesen DOI-Links.
Das sind Buchreferenzen, und damit kann man permanente Links zum Beispiel erstellen und die sollten einfach nie kaputt gehen und man sollte eigentlich schon die möglichkeit haben zu sehen ob die online sind oder nicht aber gerade bei diesen links gibt es ein großes issue weil die.
[35:22] Infrastruktur dafür ist dezentral und einzelne host da haben einzeln unterschiedliche konfigurationen von ihren webservern und liefern halt entsprechend dann informationen zurück oder nicht das heißt man kämpft gegen windmühlen weil man.
Die den admins zum beispiel eine e-mail schreiben muss und in das problem erklärt die verstehen am anfang gar nicht was überhaupt phase ist und dann irgendwann haben sie es geschnallt aber da ist dann auch schon ein halbes jahr vergangen bis dass es vielleicht eine änderung gibt.
Und das ist eigentlich extrem schade, finde ich. Also, das ist ein Riesenproblem.
Und man muss auch archive.org extrem loben. Ohne die wird extrem viel Information einfach verloren gehen.
Und ich finde, das ist eine extrem wichtige Ressource. Und das benutzen wir zum Beispiel auch als Fallback.
Also, Ritchie hat jetzt auch die Möglichkeit vorzuschlagen, einen Link zu ersetzen, der kaputt ging.
Und das ist so der erste Schritt in Richtung vielleicht Service und auch eine Möglichkeit, den Status quo ein bisschen zu verbessern.
Und in die Richtung soll es eigentlich auch weitergehen, dass man, wenn man Pull-Request erstellt, automatisch sieht, wenn ein Link kaputt ist und den vielleicht nicht mergt.
Oder wenn man einen großen Browser-Projektumzug macht, von einer Browser-Engine auf die andere, oder von einem Framework auf das andere, meine ich, dass man dann sieht, wo die ganzen Links jetzt kaputt gehen.
Und ja. Also ich finde, der der Status vom Web ist sehr sehr wünschenswert.
[36:49] Also lässt zu wünschen übrig. Naja, da wird da wird viel gelöscht und und und dann auch nicht oder auch nicht weitergeleitet.
Also manche Sachen gibt es ja dann noch, aber die gehen dann verschütt, weil einfach nicht die passenden Weiterleitungen da sind und die dann auch nicht irgendwie kolportiert werden dadurch und naja und und die oder die irgendwann dann dann gibt es sie aber dann gibt es sie halt nach ein paar jahren nicht mehr weil man denkt also jetzt haben das ja alle indexer kapiert und alle haben bestimmte noch den link auf das die aktuelle url und genau dem ist es ja oft nicht so also so eine webseite die die launch man einmal mit links und dann...
[37:41] Tschau tschau das war's jetzt autopilot es ist halt auch das riesenproblem dass es dafür keine ressourcen innerhalb von firmen gibt also es gibt keinen link beauftragten oder so und das wäre auch vielleicht falsch so eine rolle zu haben aber, es ist einfach keine sache die glamourös ist.
Und deswegen machen es viele halt einfach nicht. Also man schreibt einen Artikel, veröffentlicht den, kriegt vielleicht das, was man will oder auch nicht. Und dann vergisst man aber, dass der Artikel existiert und diese Backlinks gehen dann irgendwann kaputt.
Und das ist halt dieser Status, in dem wir uns befinden leider.
Und deswegen ist vielleicht auch die Idee, dass man den Leuten ein Tool an die Hand gibt, um das automatisch zu tun.
Also es wird wahrscheinlich demnächst auch ein Dashboard geben, wo man halt dann den Status von seiner Webseite sieht, also ähnlich wie so ein Health-Check, und dass man sieht, wie viele kaputte Links habe ich denn, und dass man dann irgendwann einschalten kann und sagt, okay, da muss ich was tun.
Hier sind auf, in dem Bereich zum Beispiel, sind die meisten Links kaputt, dass es so eine Initiative gibt.
Oder dass man zum Beispiel auch hergeht, und wenn das ein Open-Source-Repository ist, dass man das auch automatisch dann fixen kann, indem dass man dem Repository ein Pull-Request schickt und sagt, oh, ich habe jetzt alle deine Links gefixt zum Beispiel.
Oder hier sind 20 Links, da weiß ich, die gibt es nicht mehr.
[39:01] Ich hab die mal mit ner Archived Version ersetzt und ich glaub schon, dass das nen riesen Mehrwert bietet, aber das Problem ist, dass Leute das nicht als Problem sehen und glaub das Problem hat Archive.org auch, dass es ein relativ schlechtes Businessmodell ist, weil Leute sagen, ja das krieg ich doch for free, also das Web, das hat ja immer funktioniert, also warum soll ich jetzt dafür zahlen, für mich ist das kein Problem.
Problematisch wird es dann, wenn Leute mit den Links Geld verdienen, also wie zum Beispiel Affiliate-Links und davon gibt es ja Millionen auch im Web und Affiliate-Links zu checken ist dann nochmal ein ganz anderes Problem, weil nur weil ich zum Beispiel auf Amazon mein Buch verlinke beispielsweise, heißt das ja nicht, dass es das Buch noch gibt.
Es kann ja auch sein, dass der Link 200 zurückliefert und das Buch einfach nicht mehr da ist.
Und da kann man vielleicht auch ansetzen und so einen kleinen Validator bauen, der dann wirklich auch den Content von den Webseiten checkt.
Und ja, das ist halt auch so ein Ding, wenn man dann den WebAssembly, die Runtime hat, dann kann man seine eigenen Checks bauen.
Und die Idee ist, dass man so eine Art Konfigurationsdatei hat, wo man einstellen kann.
Übrigens, für alle Links, die so aussehen, nimm diesen Validator.
Und der gibt dann zurück, ist das valide oder nicht. Und dann kann man viel tiefer reingehen.
[40:23] Ich kann beispielsweise sagen, okay, wenn's ein Amazon-Shortlink ist, dann lass diesen JavaScript-Code laufen, um zu prüfen, ob der Artikel zum Beispiel noch verfügbar ist.
Und das ist wiederum ein eigenes Projekt, Das man vielleicht auch monetarisieren kann, irgendwann.
[40:44] Ja, aber super viel Arbeit, also weil man ja wirklich dann dediziert für jede, für jede Ziel-Webseite im Prinzip einen angepassten, Crawler im Prinzip nochmal oder Crawler-Plugin bauen muss und das ja auch nur so lange funktioniert, wie die Seite eben nicht auf links gedreht wird.
Ganz genau.
Ja, es ist bei vielen Tools so, dass es dann irgendwann so ein Marketplace wird, wo Leute einfach die Infrastruktur benutzen, um dann ihre eigenen Probleme zu lösen.
Also eine andere Sache, über die ich mir auch Gedanken mache, ist es gibt super viele Agenturen oder vielleicht auch sagen wir mal.
Ja, Rechtsberatungen beispielsweise, die Legal Documents haben und wie checken die eigentlich ihre Links?
Also beispielsweise ich habe eine PDF-Datei und der Link zu meinem Impressum ist zum Beispiel kaputt oder zu den Terms of Service oder ich gebe irgendwie ein Angebot raus und der Link zu meinem Produkt ist kaputt.
Also das ist ja auch ein Riesenproblem für die und da kann man vielleicht auch einen Service bauen, dann speziell für spezielle Kundengruppen eben.
Aber ich glaube auch, dass reine Link-Checking an sich ist nichts, wofür viele Leute viel Geld ausgeben würden.
[42:08] Ja wie ist das denn bei euch im projekt also du du bist jetzt seit 2015 dran also dieses litschi hast du dann quasi gefolgt und oder weiterentwickelt oder du hast du das quasi übergeben bekommen du meintest das gab es schon vorher ne.
Ha ne äh lisch also leider von der benahmung her ein bisschen schwierig ja lisch ist in go geschrieben.
Und glitchy ist in rust geschrieben und das hatte ich tatsächlich from scratch also ganz ganz neu geschrieben ja ja okay also das das lisch das ist noch auf github aber das ist mittlerweile deprecated und auf der redmi wird dann verlinkt auf.
Das ist das neue rust tool genau beziehungsweise eures wie viel wie viel commentator seid ihr da jetzt ja das ist ein schwieriges problem weil leute kommen und gehen.
Es hat sie noch keiner wirklich lange gehalten leider es gibt immer so leute die vielleicht mal reinkommen für ein halbes jahr und dann sehr sehr viel machen.
Und dann leider auch wieder verschwinden weil sie einfach keine zeit haben.
[43:09] Oder weil vielleicht linkchecking aus irgendwelchen gründen auch nicht wirklich so spannend ist also ich kann es mir nicht vorstellen aber kann ja auch ein grund sein.
Ja, das ist, wir haben ja den ganzen Podcast, ne, Berlin Checking, also schon bald 600 Folgen.
Ja, zurecht, zurecht, weil es auch sehr, sehr spannend ist. Aber wir haben schon ab und zu mal Maintainer, die großes leisten, ein großes Refactoring machen oder ein großes Feature zum Beispiel, das die brauchen, auch Contributen.
Aber ich glaube, das ist so ähnlich wie bei Curl.
Es gibt halt irgendwie einen oder zwei Core-Maintainer und die halten das Ding halt zusammen.
Also, wenn ich jetzt komplett wegfallen würde, glaube ich, würde es das Projekt in der Form irgendwann nicht mehr geben.
Und dann müsste das jemand wegforken.
[43:55] Und hast du denn die möglichkeit auch für irgendwie also auch monetäre irgendwas für dich rauszuziehen für die für die arbeit die du da reingesteckt hast.
[44:08] Oder kriegst du da irgendwie gibts hast du so ein open collective laufen oder sowas.
Ja genau es gibt ein open collective aber das ist alles noch sehr sehr am start sehr am anfang also.
Es gab jetzt noch nicht so viele Sponsoren, ich habe eine Sponsoring-Seite, wo man sich das mal anschauen kann, sich mal überlegen kann, ob das wirklich auch was ist, wofür man auch sponsoren will.
Ich glaube so auf lange Sicht wird Sponsoring relativ schwer.
Also bei diesem ursprünglichen Projekt Analysis Tools, wofür ich das auch gebaut habe, ist das viel, viel leichter.
Da haben wir relativ große Sponsoren, die halt statische Code-Analyse-Tools bauen.
Und die wollen halt in erster Linie Marketing für ihre Tools machen.
Weil die wissen, Open Source ist wichtig.
Und deswegen sponsern die das Projekt, um halt diese Visibility zu kriegen und den Zugang zum Repo.
Weil Leute das in erster Linie finden, wenn sie googeln danach.
Aber bei Litchi ist es viel schwieriger, weil Leute nicht normalerweise nach dem Tool suchen, sondern nach einer Lösung für ihr Problem.
Die sagen, Link kaputt oder Website redesign, Links checking oder irgend so was.
Und deswegen glaube ich, dass Sponsoring nicht der richtige Weg ist.
[45:26] Ich mag mich täuschen also vielleicht ist es ja der richtige weg ich würde mich freuen wenn der ein oder andere sich denkt ja da würde ich mal eine mark für da lassen aber ich glaube auch man kann schon mehr richtung services gehen.
Also am anfang dachte ich wie kriege ich die leute weg von github und hin zu einem service zum beispiel zu einer webseite wo leute das tool dann benutzen können.
Und dann dachte mir, nee, eigentlich gibt's ja tausende von Marketplaces da draußen und es macht viel mehr Sinn, eine API-Anbindung zu haben, damit Leute das verwenden können.
Und dann ist mir aufgefallen, nein, eigentlich habe ich schon einen Marketplace, den nennen sie nämlich GitHub.
GitHub ist der Marketplace, weil ich habe heute Morgen mal nachgeschaut, 3482 Repositories benutzen das.
Und die haben das eingebaut in ihre Repositories. Das heißt, das wäre dumm, von denen zu verlangen, dass die irgendwo anders hinmigrieren oder irgendwas wissen. Das heißt, eigentlich ist es gut, den Ansatz zu wählen, dass man da Pro Features in die GitHub-Action einbaut.
[46:33] Und meine Idee war jetzt, okay, es gibt einen Paid Plan, da kriege ich dann automatisch eine Authentifizierung über eine GitHub-App und dann kriege ich automatisch mehr oder weniger kostenlos Das ist ein Dashboard und da sehe ich dann meine Links.
Aber momentan kriege ich halt ein Issue, wenn irgendein Link kaputt geht.
Und wenn ziemlich viele Links regelmäßig kaputt gehen, hat man eine Menge Issues.
Ja, Story of my life.
[47:01] Aber deshalb geht es dann mit so einem Dashboard vielleicht.
Ich kann mir vorstellen, dass, also es gibt doch auch total viel so SEO-Tools, die gucken, ob man kaputte Links auf der Seite hat und so.
Also ich weiß ja nicht, ob die nicht vielleicht, also ich weiß nicht, Screaming Frog ist doch auch so ein Ding, glaube ich, also ob die nicht unter der Haube...
Hier und da auch dein projekt verwenden und vielleicht könnte man ja auch dann sagen okay so wenn du mit dem ding irgendwie wiederum produkte baust mit denen du geld verdienst dann dann lass halt mal ein euro rüber wachsen.
[47:39] Und wenn du das eben nur für interne zwecke benutzt oder eben für selber selber kostenlose tools verteilt dann dann eben nicht.
Jetzt kommen trotzdem noch auf elastic search zu sprechen ist ja interessant weil die haben nämlich ihre licensing regulierung geändert dahingehend dass vier men eine commercial license kaufen müssen.
Und in der community wurde das jetzt nicht so gern gesehen was die gemacht haben aber es macht total sinn.
[48:07] Weil open search das ist ein fork von elastic search. Die sind einfach hergegangen und haben das für Amazon gebaut eben und Amazon benutzt halt jetzt einen Fork.
Und die wollten halt solche Licensing-Probleme in Zukunft vermeiden.
Also dass du nicht einfach hergehen kannst und kannst ein Open-Source-Projekt dann kommerzialisieren.
Und übrigens OpenSearch benutzt Litchi für Link-Checking. Ich droppe das jetzt einfach mal.
Aha, da liegt doch Geld rum.
Ja aber das schwierige dran ist halt bei diesen fortune 500 firmen jemanden zu finden der dann zustimmen kann der das sponsoring zum schluss absegnet das ist bei kleineren firmen viel leichter.
Wenn man dazu amazon hingeht und sagt hey amazon du benutzt das in 15 repositories von dir.
Gib geld dann sagt amazon gar nix weil man einfach nie eine antwort von denen kriegt also ich könnte mal bei chef bis ausklingen.
Der ist ja jetzt auf seiner jacht der macht ja bei amazon nix mehr.
Das ist das aber es gibt jemanden mit dem ich auch tatsächlich früher schon zusammengearbeitet hab der zufälligerweise bei amazon ist.
Und mit dem hatte ich früher einen Slack-API-Client geschrieben.
[49:24] Und der hat auch zu Litchi schon contributed, und ist bei OpenSearch.
Das heißt, vielleicht gibt es eine Möglichkeit, dass man mal mit solchen Leuten spricht.
Aber ich glaube, generell ist das Problem, die großen Firmen vor allen Dingen, geben relativ zu ihren Gewinnen viel zu wenig an Open Source ab.
Also nicht mal 1%, nicht mal 0,1% von ihren Gewinnen.
[49:48] Da muss ich übrigens auch mal an der Stelle Trivago löblich erwähnen, weil die zu einem gewissen Zeitpunkt auch mal fast genauso viel gesponsert haben wie Facebook und waren aber ein Hundertstel so groß. Und viele Firmen haben Open Source nicht so verstanden wie Trivago. Dafür muss man dankbar sein. Hatte ich auch mitbekommen. Also genau, ja, Webpack war ja irgendwie, Die wurde ja auch stark gesponsert damals, glaub ich.
Und noch diverse andere.
Genau, wir hatten den ersten Core-Maintainer vollständig bezahlt von dem Geld.
Und Babel, das ist die ... Ich weiß gar nicht, was das ist.
Ist das nicht so ein JavaScript-Translation-Ding?
So ein Transpiler, ja. Mhm, das auch.
Ja, nee, das ist schon cool. Ja, ich vermute immer bei so Buden wie Amazon ist ...
Die sind ja auch einfach schon, obwohl die eine Tech-Company sind, wirken die schon sehr verkrustet.
Da ist wahrscheinlich so auch niemand, der eine Kreditkarte irgendwie nutzen könnte für irgendwelche solche Dinge.
Und muss sich wahrscheinlich das erst mal von was weiß ich wie vielen C-Levels absegnen lassen.
Ist eigentlich seltsam. Also, es ist ja eigentlich so eine Tech-Company, eine moderne.
Aber irgendwie unter den Tech-Companies dann wieder die eher altbacken.
[51:17] Viel leichter ist es bei kleineren Firmen, kleinen Startups beispielsweise und dann kann man mit denen wachsen. Also es gibt schon Firmen mit denen man dann auch reden kann, wo man vielleicht den CTO oder so mal persönlich sprechen kann und die verstehen meistens eher noch das Problem und die sind auch dann in der Position, dass sie eine Entscheidung treffen können und das funktioniert dann meistens über einen kurzen Dienstweg viel besser, als wenn man das offiziell macht. Große Firmen haben viel Zeit.
[51:51] Hast du denn noch irgendwie so Themen, die du beackern möchtest?
Oder also abgesehen von denen, die du gerade genannt hast, also mit diesem so, es wäre cool, wenn wir mal so ein Feature hätten, das irgendwie vielleicht Links automatisch ersetzt und Pull-Requests erstellt und so.
Gibt's noch irgendwelche? Ich meine, das geht ja jetzt schon total lange.
Man würde ja denken, im Grunde, bis auf solche richtig krassen Luxusfeatures, die Basics sind ja alle da, alles ist super, alle Bugs raus.
[52:29] Gibt's da trotzdem noch Dinge, die du so auf dem Schirm hast, die du gerne irgendwie gefixt sehen würdest oder die du gerne eingebaut haben würdest?
Es ist komplett.
Nein, leider nicht. Also, es gibt schon noch sehr, sehr viel, was passieren muss.
Irgendwie hab ich das Gefühl, das Ding wird jeden Tag größer statt kleiner. Und die Issues werden auch mehr statt weniger, obwohl das Projekt schon mehr kann. Zwei große Features, die wir momentan angehen, also ich spreche in dem Fall von wir, weil es tatsächlich mehr Leute sind, die dann arbeiten, das finde ich gut so, das ist Retry Handling und Recursion Support. Jetzt fragt man sich notiere ich. Was ist Retry-Handling überhaupt? Also beispielsweise ich habe einen Link-Checker, der eine Webseite checkt. Beispielsweise alle GitHub-Repositories. Dann kommt GitHub irgendwann und macht den Hahn zu und das geht super schnell und dann kommt man nicht mehr an diese Repositories ran, weil die natürlich Rate-Limiting eingebaut haben. Die schicken dir dann 429 und sagen, warte einfach kurz und lasst dir ein bisschen mehr Zeit.
Dann kann man ja wie gesagt erstmal so einen API-Token erstellen und dann kann man schon viel mehr machen, dann kann man vielleicht so 1000 Links checken.
[53:47] Und dann kommt GitHub wieder und sagt, aber jetzt ist erstmal Schluss und ich sag dir auch wann du wieder anklopfen darfst und das ist in 10 Minuten und hier ist der Timestamp und dann meldest du dich bitte wieder.
Wenn man dann jetzt anfängt noch weiter zu checken, dann checkt einem GitHub einfach immer weiter 429, bis man dann irgendwann aus GitHub ausgelockt wird.
Und das passiert tatsächlich relativ häufig, auch beim Testing, leider, und dann ist GitHub für mich einfach mal eine Stunde lang down, weil ich halt einfach geblockt werde.
Dann bist du generell mit all deinen Projekten bei GitHub geblockt.
Ganz genau, ja. Ja, das ist eine böse Bot-Detection.
[54:22] Genau und das muss gelöst werden halt weil viele Projekte bauen ganz naiv in ihre Projekte ein und sagen ja das ist ja nur ein einfacher link checker und dann merken die irgendwie ja der checkt halt leider in.
Zwei Minuten 70.000 links und dann bist du halt nicht bei jeder seite bist du da mal ausgenutzt also ich hatte zum beispiel auch mal den fall.
Ich wollte mal eine Beratung für eine Immobilie haben und ich habe mir gedacht okay wie komme ich jetzt relativ günstig an eine Beratung ran, hat mir dann 10 Immobilienberater rausgesucht und habe einfach mal, Litschi gestartet und habe einfach mal geschaut ob die irgendwelche kaputten Links haben und wollte denen einfach mal eine E-Mail schicken so von wegen hier sind ein paar kaputte Links und übrigens ich bräuchte auch eine Beratung vielleicht kann man sich da arrangieren.
Und hab's tatsächlich geschafft, drei von den zehn Seiten komplett down zu bringen.
Äh, eigentlich aus Versehen.
Aber ja, das ist halt wirklich das Problem, wenn man nie aufpasst bei so was.
Also, Retry-Handling.
Jetzt muss man sich natürlich überlegen, wie macht man sauberes Rate-Limiting?
Also, wie prüft man überhaupt, ob man zu viele Links checkt oder nicht?
Wie viele Requests darf ich denn machen?
Man kann ja erst mal naiv sagen, okay, einer pro Sekunde.
[55:37] Und viele Leute können sich jetzt vielleicht so vorstellen, wie die das programmieren würden.
Ich habe zum Beispiel eine Liste an Links und dann sage ich for link in links check link und dann lasse ich das laufen, so schnell wie es geht, irgendwo in der Loop, ein Request pro Einheit, also sequentiell und irgendwann werde ich halt geblockt und dann denke ich mir, okay, es leapt 10 und damit ist das Problem für die meisten gelöst. Aber wenn man das sauber machen will, dann muss man sich überlegen, okay, wie viele Links darf ich denn wirklich checken? Also, im HTTP, wie sagt man denn, im Spec, genau, da ist beschrieben, wie das zu, handhaben ist. Und zwar können Webseiten einem einen Rate-Limit-Header schicken. Und da steht genau drin, wie lange man warten muss, wie viele Requests man machen darf pro Intervall und wie wie lange das Intervall ist. Problem ist allerdings, dass es dafür sieben oder acht verschiedene Implementierungen gibt. Also Reddit und GitHub und Twitter und andere Webseiten haben ihre eigene Implementierung davon. Und die Headers sehen halt leicht anders aus und die haben, leicht andere Funktionen und so weiter.
Das heißt, wenn man das sauber machen will, muss man die parsen.
[56:56] Und deswegen habe ich eine Library geschrieben, die diese Rate-Limit-Header parst, und dann halt zurückgibt, ob man geblockt wird und wenn ja, wie lang.
So, und dann geht man her und sagt, dann muss ich warten, bis ich wieder darf.
Aber ich kann natürlich die anderen Webseiten in der Zeit natürlich weiterchecken.
Das heißt, man muss dann so ein Bucket machen, und dann braucht man den State von der Webseite, um den zu checken.
[57:21] Aber was ist zum Beispiel mit Webseiten, die keinen Red-Limit-Header schicken?
Ja, da geht's jetzt ziemlich ins Detail. Ich kürze das Ganze mal ab.
Man kann vielleicht mal mit einem Request pro Sekunde starten, schauen, funktioniert das stabil, dann vielleicht auf zwei, dann auf vier, dann auf acht, dann 16 hochgehen.
Oder man kann zum Beispiel mit einem Burst anfangen, dass man 16 auf einmal checkt, und dann sieht, kommen die alle sauber zurück.
Und dann braucht man halt Retry-Handling. Deswegen, das ist ein super komplexes Thema.
Kein Link-Checker kann das und es gibt auch keine Libraries außer dieser einen, die Rate-Limit-Header passt und das ist halt ein Feature, was spannend ist und hoffentlich auch bald eingebaut wird.
Und das andere, darüber verliere ich jetzt weniger Worte, ist einfach Recursion-Support, das heißt, ich checke eine Webseite und ich gehe komplett über die komplette Webseite, Da gibt es zum Beispiel die Probleme, wo kriege ich eigentlich alle Links her, Stichwort Sitemap, XML, oder wie weit gehe ich in die Tiefe, oder prüfe ich zum Beispiel alle Bereiche von der Webseite oder nur manche und so weiter.
Genau, das sind so die zwei Themen. Also zum einen Retry Handling und Rate Limiting und zum anderen Recursion Support.
[58:41] Ja, dann geht auf jeden Fall mal einen Aufruf an alle interessierten Hörerinnen und Hörer, die dann auch Rust-mächtig sind, nehme ich an, ist ja dann nötig, voraussetzung.
Oder halt einfach das Ding mal testen auf der eigenen Webseite und einen Bug-Report erstellen.
Also ein Issue kann man durchaus mal erstellen ohne Rust-Support.
Fände ich natürlich super, wenn der eine oder andere sich denkt, ja, das nehme ich her, um Rust vielleicht auch zu lernen, wenn ich das eh lernen will.
Und ich bin auch jemand, der jetzt nicht unfreundlich ist, wenn jemand sagt, ich hab's jetzt nicht ganz perfekt hinbekommen, kannst du mir helfen?
Also, das ist, glaube ich, auch ein gutes Projekt, an dem man sich ein bisschen üben kann.
Und wenn man da jetzt ein bisschen tiefer einsteigen will, vielleicht eine Netzwerkprogrammierung oder asynchrone Abarbeitung, dann finde ich das spannend.
Ja, auch wenn Link-Checking an sich jetzt vielleicht nicht das Megaspannendste ist.
Äh, die Vanessa, äh, find's auch gut, aber nicht jeder musste so tief einsteigen wie wir jetzt in das Thema, um da beitragen zu können.
Ja. Na ja, gut, aber man braucht ja auch immer irgendwelche Aufhänger, um bestimmten Problemfeldern überhaupt erst mal zu begegnen, ne?
Also ohne Link-Checker wirst du wahrscheinlich nie so in diese Welten abgetaucht.
Genau, und das vielleicht da auch noch als kleiner Tipp.
[1:00:03] Wenn jemand nicht weiß, was er für ein Open-Source-Projekt oder Side-Project machen will, Sucht euch die einfachste Aufgabe aus, die ihr euch vorstellen könnt. Das allereinfachste überhaupt.
[1:00:16] Und versucht das richtig zu machen. Und ihr werdet feststellen, es gibt überall eine unendliche Tiefe und aus dieser Nische heraus könnt ihr richtig gute, solide, wertvolle Tools bauen.
Da so ein bisschen funktionieren diese Code-Cutters auch so, dass du quasi guckst, wie müsste es eigentlich bilderbuchmäßig laufen.
Und dann hatten wir auch mal den Wolfram Kiesing, der solche Cutters veranstaltet.
Da wird dann, glaube ich, die Speck erst mal gelesen.
Und dann merkt man, solche Charakter können da auch noch vorkommen drin.
Und dann müssen die ja auch korrekt verarbeitet werden.
Und danach baut man quasi, versucht man eben eine Implementierung davon nach Speck irgendwie zu machen und sich der Korrektheit anzunähern.
Und das ist wohl nicht so ganz einfach.
Du warst auch schon da, ne? Waren es da bei den Code-Cutters vom Wolfram, oder?
Ja, beziehungsweise, ja, da war ich bei einem. Das, was mir aber für immer in Erinnerung geblieben ist, ist das Refactoring in 30-Sekunden-Workshop.
Das war ...
Halbe Stunde Erfahrung hat mich, glaub ich, für immer verändert, wie man Code anfasst und Code verbessert. Mhm.
Ich hab mich grad nebenbei gefragt, gibt's URLs mit Emojis? Klar, ja.
[1:01:43] Freilich. Es gibt Emoji-URLs. Jaja, diese ganz berühmten sind die .ws-Domains.
[1:01:52] Das ist nicht auf jeder tl die erlaubt aber auf manchen haben sie das nicht explizit ausgeschlossen und manche haben dann einfach.
Es geschafft, Emoji-Domains zu registrieren, aber manche Registrars haben das dann auch wieder beendet, weil das halt schon in manchen Ecken dann Probleme verursachen kann.
Nicht jede Infrastruktur ist dafür ausgelegt.
[1:02:15] Es sind ja Umlaute auch schon ein Riesenproblem in URLs für manche Services.
Und deswegen wird das ja alles im Endeffekt einfach nochmal vom Browser dann kodiert als ASCII, damit das auch sauber durchgeht überall.
Aber Emoji-Domains, ja, super, super Sache. Sollte man auch mal einen Testcase damit machen.
Also wenn einer mal auch Testcases für Link-Checking oder so braucht oder für seine Tools, Es gibt relativ coole Seiten. Eine heißt BrokenSSL.com, glaube ich.
Ja, muss ich mal nachschauen hier.
Und die andere heißt HTTP-Status.
Also HTTP-Start.us. Und da sind alle Edge-Cases aufgelistet.
Ja, muss ich mal nachschauen, wie das Ding heißt hier. BadSSL.com heißt die andere Seite, genau.
Und da seht ihr alle SSL-Edge-Cases. Litchi kann die alle, aber hat ein bisschen gedauert und der andere ist http start.us und der zeigt dir alle Status Codes an, die es gibt und die du eigentlich handeln solltest ja und auch noch ein bisschen mehr.
[1:03:28] Dann wäre meine abschließende Frage nur, triffst du dich mit dem Curl-Macher und so den fünf anderen weltweiten, ähm, HTTP-Spezies auf irgendwelchen Konferenzen und dann fachsimpelt ihr über so Zeugs?
[1:03:51] Ich kenn den Daniel Stenberg. Ich war schon auf ein paar Konferenzen, wo er auch war.
Zum Beispiel auf der FOSDEM.
Ich hab ihn noch persönlich nicht gesprochen, oder wenn, dann nur ganz kurz.
Aber ich find, er macht seine Sache richtig gut.
Auf Wiedersehen, bis zum nächsten Mal, also auch noch mal sehr viel Spaß beim Ablösen.
Ich würde mir wünschen dass es eine netflix Dokumentation über ihn gibt weil er seit jahren einfach nur curl baut und.
Und zwar, bis zum nächsten Mal. Bis zum nächsten Mal meine Lieben.
Bis zum nächsten Mal. Tschüss.
Am besten bis zum nächsten Mal. Bis zum nächsten Mal. Bis zum nächsten Mal.
Ich immer wieder anhören muss wie leicht das doch ist und es gibt sogar eine Webseite.
Bis zum nächsten Mal. Bis zum nächsten Mal. Bis zum nächsten Mal.
Bis zum nächsten Mal. Bis zum nächsten Mal. Bis zum nächsten Mal.
Bis zum nächsten Mal. Bis zum nächsten Mal.
I could build curl in a weekend oder so wo er das alles sammelt und so dieses feedback und das ist super lustig zu lesen wie leute das halt beschreiben.
Bis zum nächsten Mal. Bis zum nächsten Mal. Bis zum nächsten Mal.
Bis zum nächsten Mal. Bis zum nächsten Mal. Bis zum nächsten Mal.
Bis zum nächsten Mal. Bis zum nächsten Mal. Bis zum nächsten Mal.
Bis zum nächsten Mal. Bis zum nächsten Mal. Bis zum nächsten Mal.
[1:04:30] Aber curl kann über 20 protokolle und viele davon hat er als erstes in c implementiert und leute sagen das ist ja super einfach ich benutze die library und meistens ist die library also er war der erste der irgendwie diese library implementiert hat also von dem her ich finde das super magisch was er tut.
Und ja, ich würde ihn supergerne mal treffen.
Er wohnt ja in Schweden. Und vielleicht fahr ich da wirklich mal hoch, schreib ihm mal eine E-Mail.
Er hatte auch bei Trivago, glaub ich, schon mal fast einen Vortrag gegeben oder so.
Und dann hat's nicht geklappt.
Aber er ist auf jeden Fall jemand, der auch sehr interessiert an der Community ist und auch gerne mal vorbeikommt, wenn's irgendwie klappt.
Und das find ich einfach supergut. Es bräuchten mehr Leute wie ihn oder auch Linus Torvalds, ihr leben lang nichts anders tun als das und die disziplin haben ja.
Und litschi ist natürlich genau auf derselben ebene wie diese zwei projekte curl und linux also.
Ja ich finde spannend man man sollte mal so eine konferenz machen für für leute die leid geplagt sind wegen web problemen irgendwie.
Er vielleicht so eine Rehabilitationsanstalt oder so, so ein Hospital.
Da fallen mir doch gleich mehrere Personen ein, die da gerne auch dann hingehen würden.
Wahrscheinlich, ja.
[1:05:51] Ja, aber cool. Also, äh, waren, äh, spannendes Thema, das du heute mitgebracht hast.
Also, so schön nerdig, nix mit Frontend, aber letztlich ja auch nichts wirklich mit Backend.
Also, es ist einfach so, ist ja quasi eher so ein ...
Einfach nur End. Einfach nur End an alle, ne? Ja, nur End.
Ja. Das ist ... Ja. Ja, da kommen wir halt alle nicht, alle nicht drumrum.
Zumindest, wenn wir im Web sind, um diese Themen.
[1:06:23] Fand ich auch super spannend, das mal vielleicht auch in der Tiefe erklären zu können, auch wenn vielleicht der ein oder andere das jetzt nicht auf dem Schirm hatte.
Generell ist es natürlich auch super spannend, wenn man ein Projekt baut, was Leute benutzen, weil man dann in interessante Probleme auch reinläuft, wie zum Beispiel Packaging von so einem kleinen Service. Also Litchi gibt's jetzt für Homebrew, NixOS, Arc, 3BSD, es gibt's für Windows, Chocolattie und Winget.
Da gibt's zum Beispiel auch nochmal verschiedene Edge Cases dann.
Also ich kann das einfach jedem empfehlen, das mal auszuprobieren, so ein kleines Tool zu schreiben und ein kleines Problem zu lösen, weil dann merkt man einfach, okay, man braucht einfach ein bisschen Tooling, ein bisschen Infrastruktur und das macht schon Spaß.
Man muss jetzt nicht das Leben bestimmen. Ja, es gibt wichtiger Gerüst als Links im Leben.
Aber immer wieder spannend, wenn man sich so eine kleine Ecke im Internet aussucht, denke ich.
Ja eine kohi viel in seinem bereich wird ja wenn wenn es mal einen kaputten emoti link gibt ja dann bin ich der ansprechpartner damit bitte nicht.
[1:07:34] Ja cool dann vielen dank.
Wir verlinken alles natürlich in den show notes und auch den kontakt zu dir aber hoffentlich keine kaputten links nur nur valide links ja also am anfang werden die noch natürlich valide sein und wenn wir dich dann das nächste mal einladen in die in die nächste.
Wenn es in die nächste folge die wir mit dir aufnehmen dann müssen wir deinen tool noch mal auf die alte.
Schon noch zeitlos lassen bis dahin habe ich wahrscheinlich ganz tiefe augenringe und die alle zähne sind ausgefallen und so weiter in zehn jahren und wenn einer link sagt dann zucke ich so zusammen ja genau dann geben wir dir den rest sozusagen momentan schaffst du das ja frisch aus.
Ja ja das kommt vom klima hier in düsseldorf das ist einfach im norden hier das ist weiße nordwesten ist das einfach entspannt.
Ja ja dafür ist ja auch das wäre gerade erst aufgestanden heißt also ja wir sind eigentlich alle noch frisch quasi ja eigentlich schon wir wollten eigentlich auch noch jetzt die nächsten 23 stunden halt über über link checking reden eben also Marathon.
Ja, weiß nicht, ob heute noch jemand das vorhat, aber… Nee, nee, ich hab nix vor.
Und über… Je länger ich darüber nachdenke, fallen mir immer mehr Probleme ein, die es geben könnte. Das hört nicht auf.
[1:08:57] Ja, und dann kommt halt der Alkohol ins Spiel leider, ne? Und dann hast du halt ein Suchtproblem auch noch zusätzlich, ja?
Und dann hast du nicht nur ein Linkproblem, sondern auch ein Suchproblem irgendwann.
Also schaue ich hoffe zu halten die alkoholkurve zum besser programmieren ja ja je tiefer du reinschaust desto desto tiefer schaute sind ich.
Ich komme ja aus bayern ich kann ja nach zwei mass kann ich ja noch nach hause fahren.
[1:09:25] Ja na bevor wir so falsch abbiegen hier würde ich sagen machen wir lieber den deckel drauf.
Genau und bedanke uns noch bei dir Matthias, bedanke uns bei den Hörerinnen und Hörern für das ihr hier fleißig mitgehört habt.
Und genau dann sind wir nächste Woche wieder am Start und macht's gut bis dann tschüss.
Tschau.
[1:09:52] Music.