WEBVTT

00:00:00.387 --> 00:00:21.065
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.

00:00:21.417 --> 00:00:29.239
Ich habe mich gerade nebenbei gefragt gibt es hier mit emojis klar ja freilich es gibt emoji.

00:00:29.761 --> 00:00:36.486
Ja, ja, pfff, schön nerdig, nix mit Frontend, aber letztlich ja auch nichts wirklich mit Backend.

00:00:36.855 --> 00:00:39.033
Betrifft halt alle, ne? Ja, nur End.

00:00:39.600 --> 00:01:03.920
Music.

00:01:04.762 --> 00:01:07.257
Revision 569,

00:01:10.775 --> 00:01:14.777
Diese Revision von Working Draft wird euch präsentiert von Midwild, dem Hoster für

00:01:14.777 --> 00:01:16.051
Agenturen und Freelancer.

00:01:16.483 --> 00:01:19.129
Bei Midwild findet ihr für jedes Projekt das passende Hosting.

00:01:19.706 --> 00:01:22.748
Zum Beispiel könnt ihr auf dem ProSpace eine eigene virtuelle Maschine konfigurieren.

00:01:23.045 --> 00:01:26.394
RAM auswählen, CPU-Kerne abzählen, Speicherplatz festlegen und BÄM, fertig.

00:01:26.880 --> 00:01:30.937
Jetzt denkt ihr euch vielleicht, nije, das kann ich bei meinem alten Gammel-Hoster auch machen, jahaha.

00:01:31.472 --> 00:01:34.829
Aber bei Midwild könnt ihr auch, wenn ihr wollt, zum nördigen Space-Server upgraden.

00:01:35.137 --> 00:01:38.777
Damit verfrachtet ihr all eure Projekte in die Managed Cloud, profitiert von maximaler

00:01:38.777 --> 00:01:42.697
und habt trotzdem alles an einem Ort, zentral verwaltet hinter einem Login.

00:01:42.857 --> 00:01:47.442
Und dann ist es plötzlich ein leichtes, sich Shop-System-Installationen mit Redis-Anbindung zu verwalten.

00:01:48.648 --> 00:01:52.137
Oder vielleicht wollt ihr auch nur drei WordPress-Installationen unterbringen.

00:01:52.177 --> 00:01:55.742
Egal, was ihr vorhabt, bei Midwald findet ihr für jedes Projekt das passende Hosting.

00:01:56.657 --> 00:02:05.635
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.

00:02:06.067 --> 00:02:10.057
Alle Infos zu Midwald findet ihr natürlich auch in den Chownotes zu dieser Revision.

00:02:10.136 --> 00:02:13.697
Wir danken mit Wald für die Unterstützung von dieser Revision von Working Draft.

00:02:18.481 --> 00:02:28.240
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.

00:02:28.681 --> 00:02:32.552
Hallo hi zugeschaltet aus düsseldorf.

00:02:33.452 --> 00:02:48.971
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.

00:02:49.051 --> 00:02:54.531
Ich bin geboren jetzt bin ich hier was ist dazwischen passiert ich komme tatsächlich aus bayern.

00:02:55.076 --> 00:03:02.259
Aufgewachsen mochte immer schon computer habt ihr auch computer science studiert in bayreuth und bin jetzt seit 2014 in düsseldorf.

00:03:02.439 --> 00:03:08.138
Hab angefangen hier bei Trivago zu arbeiten, das ist eine Hotelsuche, war da im Backend.

00:03:08.849 --> 00:03:13.351
Hab da viel Elasticsearch und Container und Cloud gemacht.

00:03:14.106 --> 00:03:17.351
Dann angefangen Go zu lernen und andere Programmiersprachen.

00:03:17.351 --> 00:03:22.351
Und hab dann irgendwann gemerkt, Python und Go, das ist vielleicht nicht so meine Welt.

00:03:22.351 --> 00:03:27.351
Ich suche mir mal was anderes und ich fand es eigentlich auch ganz spannend mal in Rust reinzuschauen.

00:03:27.351 --> 00:03:32.871
Mich da auch ein bisschen festgesetzt und dann angefangen zu bloggen und hatte auch

00:03:32.871 --> 00:03:36.411
mal einen YouTube-Channel zu Rust und dann dachte ich irgendwann, ich mache mich selbstständig

00:03:36.411 --> 00:03:41.311
in dem Bereich und mache jetzt mittlerweile Firmenberatung und Performance-Optimierung

00:03:41.581 --> 00:03:44.093
im Backend-Bereich, hauptsächlich Rust.

00:03:45.146 --> 00:03:49.773
Hattest du auch ein podcast war nicht auch was oder war das dieser youtube channel.

00:03:50.156 --> 00:03:59.064
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.

00:03:59.892 --> 00:04:12.585
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,

00:04:12.676 --> 00:04:19.676
Das hatte ich zusammen gemacht mit Wolfgang Gaßler und im Rahmen dieses Projekts haben wir so einen kleinen Podcast gestartet.

00:04:19.886 --> 00:04:25.278
Der ist aber jetzt auch schon wieder ausgelaufen. Der Wolfgang macht allerdings auch weiterhin Podcasts mit Engineering Kiosk.

00:04:25.676 --> 00:04:26.422
Grüße gehen raus.

00:04:27.007 --> 00:04:30.122
Ja. Und der ganzen Materie bin ich nicht fern, ja.

00:04:31.202 --> 00:04:40.976
Cool. Genau, und heute wollen wir aber gar nicht über Rust sprechen und auch nicht über Elasticsearch.

00:04:41.095 --> 00:04:45.776
Oder mutmaßlich nicht, vielleicht kommt Elasticsearch ja trotzdem vor.

00:04:45.836 --> 00:04:50.376
Sondern du hattest mal erzählt,

00:04:50.436 --> 00:04:59.276
dass du quasi einen URL-Crawler letztendlich gebaut hast, was ja erst mal so relativ banal klingt vielleicht.

00:04:59.658 --> 00:05:06.676
Und man sich relativ einfach vorstellt, also so, ja, wenn ich einen Link-Crawler bauen will,

00:05:06.932 --> 00:05:09.976
was brauche ich da? Zwei Abende und dann ist das Ding wahrscheinlich fertig.

00:05:09.976 --> 00:05:13.676
Aber der Twist ist natürlich, so einfach ist es nicht.

00:05:14.683 --> 00:05:22.576
Und ja, du hast irgendwie bei diesem Projekt allerlei wilde Dinge

00:05:22.576 --> 00:05:26.251
erlebt und gesehen und Probleme lösen müssen.

00:05:26.548 --> 00:05:36.276
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.

00:05:37.630 --> 00:05:46.938
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.

00:05:47.865 --> 00:05:49.891
Hat sich aber rausgestellt ist gar nicht der fall.

00:05:50.827 --> 00:05:56.480
Also wenn man jetzt irgendwie tief im back end ist und marktroller oder parser dann ist es nie langweilig aber.

00:05:57.317 --> 00:06:04.700
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,

00:06:04.879 --> 00:06:26.656
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.

00:06:27.619 --> 00:06:30.491
Jetzt gar nicht zur Bewertung, sondern einfach nur, um festzustellen,

00:06:30.896 --> 00:06:34.700
wie ist so generell die Richtung von der Code-Quality in der Case-Study.

00:06:34.700 --> 00:06:40.700
Und dafür hatte ich einen Linter gesucht, oder ein statisches Code-Analyse-Tool damals, für PHP.

00:06:40.700 --> 00:06:45.700
Und es gibt viele PHP-Tools, und habe angefangen, eine Liste zu schreiben.

00:06:45.700 --> 00:06:50.700
Einfach eine ganz normale Markdown-Datei und dann halt 10 oder 20 Tools da reingeschrieben.

00:06:51.133 --> 00:06:53.700
Und dann ist die Liste halt immer weiter gewachsen und gewachsen.

00:06:53.700 --> 00:07:00.420
Und irgendwann waren es halt dann 700 Tools und 11.000 Sterne auf GitHub und Leute haben halt

00:07:00.420 --> 00:07:05.860
dann angefangen, ihre eigenen Tools hinzuzufügen und Firmen haben dann ihre Listen maintained

00:07:05.860 --> 00:07:13.660
und so weiter. Und das wurde dann irgendwann ein richtiges Side-Project und dann habe ich gemerkt,

00:07:13.660 --> 00:07:19.220
dass es sehr nervig ist, das zu maintainen, weil ungefähr jede Woche sind zwei oder drei

00:07:19.220 --> 00:07:24.580
Tools einfach verschwunden oder die Webseiten waren down und das ist ein riesen Problem,

00:07:24.580 --> 00:07:33.220
wenn man halt 700 Links checken muss, regelmäßig mit URL und GitHub und so weiter. Und Anfang August

00:07:33.220 --> 00:07:37.780
2020 habe ich dann festgestellt, okay, da muss eine Lösung her. Ich will das nicht selber machen.

00:07:40.186 --> 00:07:53.402
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.

00:07:53.933 --> 00:08:07.994
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.

00:08:08.778 --> 00:08:14.096
Und der war aber leider nicht mehr maintained. Und dann hatte ich andere gefunden,

00:08:14.278 --> 00:08:18.239
auch die großen Markter und LinkCheck zum Beispiel, aber die waren ziemlich langsam.

00:08:18.716 --> 00:08:23.096
Und dann hatte ich welche gefunden, da habe ich einfach die Runtime nicht gehabt.

00:08:23.096 --> 00:08:27.096
Also ich wollte nicht irgendwo eine große Ruby- oder Python-Runtime installieren.

00:08:27.096 --> 00:08:30.096
Ich wollte was Kleines haben, was wenig Speicher braucht

00:08:30.096 --> 00:08:32.418
und was vor allen Dingen wenig False Positives hat.

00:08:33.174 --> 00:08:36.596
Weil, wie wir wahrscheinlich noch sehen werden, es ist ein komplexes Problem

00:08:36.596 --> 00:08:40.015
Und es gibt ziemlich, ziemlich viele Fallstücke, an die man am Anfang nicht denkt.

00:08:40.799 --> 00:08:44.596
Und ich hab dann auch nicht gedacht, weil ich dachte eigentlich auch, ich schreib das an einem Wochenende.

00:08:44.596 --> 00:08:48.596
Und tatsächlich war es so, dass ich gar nicht gedacht hab, dass das jetzt ein Projekt wird,

00:08:48.596 --> 00:08:51.511
sondern ich hab das als Episode für Hello Rust gemacht.

00:08:51.601 --> 00:08:54.596
Das heißt, wer uns interessiert, der kann sich einfach die Folge anschauen.

00:08:54.596 --> 00:08:59.199
Und da sieht man die erste Version, also von der ersten Zeile an, wie das Tool entstanden ist.

00:08:59.784 --> 00:09:04.596
Und am Ende von dem Wochenende hatte ich halt ein Tool, was zumindest mein Repository checkt,

00:09:04.596 --> 00:09:13.846
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.

00:09:14.521 --> 00:09:28.457
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.

00:09:29.627 --> 00:09:46.434
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.

00:09:46.516 --> 00:09:52.556
Und dann wurde das in das README aufgenommen von dem Tool und dieses Tool hatte sehr viele User und deswegen kamen,

00:09:53.600 --> 00:09:57.836
zum allerersten Mal eigene User und die wollten vielleicht auch eigene Features wieder haben.

00:09:58.542 --> 00:10:03.876
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.

00:10:03.876 --> 00:10:07.112
Und dann kannst du vielleicht die Sache noch einbauen und dann ist er wirklich fertig.

00:10:08.598 --> 00:10:14.107
Die erste Funktionalität, die ich eingebaut habe, die nicht alle Linkchecker hatten, war GitHub Support.

00:10:15.070 --> 00:10:18.948
Weil ziemlich schnell läuft man in rate-limiting-Problemen bei GitHub.

00:10:19.008 --> 00:10:26.248
Wenn man 700 Tools checkt, Open-Source-Tools, dann ist bei 500 vielleicht Schluss oder bei weniger.

00:10:27.016 --> 00:10:31.662
Und deswegen dachte ich, okay, wenn's ein GitHub-Link ist, dann check ich das über die API.

00:10:32.589 --> 00:10:36.948
Und ja, das funktioniert ziemlich cool. Man kann den API-Key angeben.

00:10:37.126 --> 00:10:41.663
Und der Vorteil ist auch, dass man dann seine privaten Repos checken kann dadurch.

00:10:42.023 --> 00:10:49.378
Weil das ist ja ein Token, das man hat. Und das gilt ja auch für private Repositories.

00:10:49.594 --> 00:10:53.249
Und von Anfang an haben wir ja auch gewusst, dass das Tool asynchron sein muss.

00:10:53.448 --> 00:11:02.260
Weil Link-Checking ist network-bound. Das heißt, man hat ziemlich hohe Latenzen auf verschiedene Webseiten.

00:11:02.620 --> 00:11:08.337
Aber man kann sehr, sehr viele Webseiten konkurrierend, also concurrent prüfen.

00:11:08.661 --> 00:11:12.448
Das geht sehr, sehr gut. Und der Vorteil davon ist, dass eigentlich

00:11:12.448 --> 00:11:16.133
der Kernel die meiste Arbeit macht und nicht der Userspace.

00:11:16.916 --> 00:11:22.448
Und dadurch kann man die Memory-Usage und die CPU-Usage extrem runterdrehen, weil eigentlich

00:11:22.448 --> 00:11:24.448
die ganze Arbeit auf der Netzwerkkarte passiert.

00:11:24.928 --> 00:11:28.448
Und damit kann man die Netzwerkkarte eigentlich auslasten, bis zu

00:11:28.448 --> 00:11:32.448
einem gewissen Punkt. Und deswegen wollte ich das von Anfang an haben.

00:11:32.448 --> 00:11:37.306
Das war so der Anfang, wo es dann losging, wo Leute gemeint haben, ah ja, okay, das ist vielleicht ein Tool,

00:11:37.450 --> 00:11:40.142
das mehr bietet als manche anderen Tools.

00:11:42.448 --> 00:11:50.413
Und das hast du in Rust dann geschrieben, weil du gesagt hast, das hast du in deinem YouTube vorgestellt?

00:11:50.575 --> 00:11:50.900
Ja, oder?

00:11:52.133 --> 00:12:00.370
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,

00:12:00.793 --> 00:12:10.606
immer mehr tools auch im frontend bereich werden jetzt mittlerweile in rust geschrieben vor zwei tagen hat rough das ist ein python linter,

00:12:11.038 --> 00:12:17.555
ein vier millionen dollar funding bekommen von versell gebackt und das ist auch in rust geschrieben.

00:12:18.293 --> 00:12:25.643
Und man sieht halt einfach immer mehr, dass so Infrastruktur-Tools und so Developer-Tools immer öfter in Rust auch geschrieben werden.

00:12:25.643 --> 00:12:30.643
Das ist schon definitiv der Fall. Für mich war es irgendwie klar, dass es in Rust sein muss,

00:12:30.643 --> 00:12:35.643
weil Rust hat ein relativ gutes asynchrones Ecosystem mit Tokio.

00:12:35.643 --> 00:12:43.643
Und in Tokio kann man Network-Links asynchron checken und man hat den Vorteil, dass man keine Runtime hat.

00:12:43.643 --> 00:12:49.657
Eine Runtime hat. Das heißt, man hat keinen Overhead wie in JavaScript mit Promises beispielsweise.

00:12:49.882 --> 00:12:57.363
Und es ist eine relativ einfache Umgebung. Man programmiert einfach nur Rust. Aber im

00:12:57.363 --> 00:13:01.483
Hintergrund passieren sehr, sehr viele Dinge mehr oder weniger magisch und gesichert durch

00:13:01.483 --> 00:13:08.603
das Typ-System, was das Ganze extrem schnell und elegant macht. Und deswegen ist es einfach

00:13:08.603 --> 00:13:11.416
Und eine gute Sprache dafür, genau für dieses Problem.

00:13:12.181 --> 00:13:19.403
Mhm. Ja, da kann man auch noch mal verweisen auf die ... Wir haben auch eine Rust-Folge gemacht vor ein paar Monaten.

00:13:19.572 --> 00:13:25.643
Genau, da hier der Stefan aus unserem Team, der ist auch so ein Rust-Nerd, der ...

00:13:25.683 --> 00:13:30.163
Und wir hatten auch zwei Gäste da, die ein Rust-Buch geschrieben haben.

00:13:30.203 --> 00:13:33.885
Und die drei haben dann wild vor sich hin erzählt.

00:13:34.336 --> 00:13:43.977
Stefan K natürlich. Natürlich. Genau, und da fiel natürlich auch Tokio und äh genau ähnliche Frameworks.

00:13:44.562 --> 00:13:45.003
Ja, cool.

00:13:46.516 --> 00:13:51.330
Ja, also vielleicht mal ganz kurz zur Architektur von so einem Tool.

00:13:51.330 --> 00:13:59.330
Also wie funktioniert grundsätzlich der Ablauf? Es ist ja so, erstmal ist die Frage, welche Inputs hat man denn überhaupt?

00:13:59.330 --> 00:14:01.330
Wo kommen die Links denn überhaupt her?

00:14:01.540 --> 00:14:04.880
Da gibt es natürlich die Möglichkeit, dass man Markdown-Dateien prüft.

00:14:05.330 --> 00:14:10.330
Und da muss man sich ja fragen, welches Markdown? Weil es gibt ja nicht ein Markdown-Format.

00:14:10.330 --> 00:14:12.330
Es gibt ja verschiedene.

00:14:12.640 --> 00:14:20.530
Weil Markdown ist ja von Gruber in Version 1.0 mehr oder weniger stabilisiert worden,

00:14:20.530 --> 00:14:23.930
aber danach gab es natürlich immer noch weitere Entwicklungen. Es gibt zum Beispiel das GitHub

00:14:23.930 --> 00:14:30.410
Markdown und Common Mark und so weiter. Und deswegen gibt es quasi einen Parser,

00:14:30.410 --> 00:14:35.650
der die Markdown-Dateien liest. Und ebenso gibt es einen Parser für HTML. Das ist die,

00:14:36.370 --> 00:14:42.204
Die Browser-Engine Servo, die hat einen Parser und der ist auch sehr, sehr gut.

00:14:42.370 --> 00:14:47.740
Damit wird HTML geparst und dann gibt's die Möglichkeit, Webseiten zu checken.

00:14:48.170 --> 00:14:54.843
Das wird auch mit Requests geparst. Das ist ein Crate, ein Rust-Crate für HTTP-Requests.

00:14:55.610 --> 00:14:59.974
Und dann gibt's aber noch einen Plain-Text-Parser, der alles andere parst, was es so gibt.

00:15:00.170 --> 00:15:04.448
Aber was ganz wichtig ist bei der Sache, so ein naiver Ansatz reicht nicht.

00:15:04.570 --> 00:15:08.570
Also, jeder Backend-Ingenieur hat vielleicht schon mal einen Link-Checker geschrieben,

00:15:08.570 --> 00:15:13.568
aber die meisten haben dann irgendwie gemeint, okay, ich nehme den regulären Ausdruck, ich gehe über die Datei

00:15:13.640 --> 00:15:18.546
und ich prüfe halt irgendwie, wo zum Beispiel Doppelpunkt Slash steht oder www Punkt und so weiter.

00:15:18.645 --> 00:15:22.570
Aber das Problem an der Sache ist, dass man sehr, sehr viele False Positives hat.

00:15:22.570 --> 00:15:25.712
Hat. Also beispielsweise...

00:15:26.891 --> 00:15:31.572
Nicht jede Webseite hat www. beispielsweise. Es gibt mehrere Möglichkeiten.

00:15:32.022 --> 00:15:36.334
Man kann auch zum Beispiel sagen, okay, dann fängt halt ein Link mit http:// an.

00:15:37.072 --> 00:15:43.707
Ist auch nicht der Fall, weil es gibt auch https. Es gibt auch zum Beispiel Slack-Schemes oder File.

00:15:44.058 --> 00:15:46.516
Aber es gibt auch zum Beispiel Links, die haben überhaupt kein Scheme.

00:15:46.948 --> 00:15:54.240
Und wenn man zum Beispiel www.// hat, dann verweist das auf das Scheme von der Origin-Webseite.

00:15:54.807 --> 00:16:00.965
Und solche Sachen vergisst man oft. Und dann ist auch die Frage zum Beispiel, wie handle ich Query-Parameter?

00:16:01.352 --> 00:16:02.684
Sind die relevant oder nicht?

00:16:03.161 --> 00:16:09.778
Was ist mit Ankern in URLs? Und so weiter und so weiter. Das heißt, so ein naiver Ansatz funktioniert nicht.

00:16:10.435 --> 00:16:14.486
Das heißt, man muss aufpassen, dass man von Anfang an den richtigen Parser benutzt.

00:16:14.945 --> 00:16:23.317
Und dieser Parser liest dann die Datei und schmeißt diese Links, die er findet, in eine Queue.

00:16:23.741 --> 00:16:26.468
Und dieser Teil nennt sich Extractor.

00:16:27.215 --> 00:16:30.741
Und dann in dieser Queue, das ist einfach nur eine Warteschleife,

00:16:30.852 --> 00:16:35.101
da werden diese Links dann abgearbeitet, nach und nach, und zwar asynchron.

00:16:35.141 --> 00:16:43.374
Das heißt, man liest mehrere Links aus der Queue und prüft die dann mehr oder weniger concurrent, also gleichzeitig.

00:16:43.554 --> 00:16:47.029
Und die Ergebnisse werden dann wiederum gesammelt in einer anderen Queue,

00:16:47.344 --> 00:16:48.848
wo die dann weiterverarbeitet werden.

00:16:49.298 --> 00:16:52.021
Jetzt fragt man sich natürlich, warum ist das so kompliziert?

00:16:52.115 --> 00:16:53.772
Wieso brauche ich überhaupt zwei Queues?

00:16:54.384 --> 00:16:59.605
Naja, man will auf jeden Fall vermeiden, dass an irgendwelcher Stelle irgendwelche Bottlenecks entstehen,

00:16:59.661 --> 00:17:00.830
dass man sich blockiert.

00:17:01.021 --> 00:17:06.141
Und jetzt könnte man zum Beispiel sagen, okay, wenn ich jetzt beispielsweise nur eine Queue hätte

00:17:06.181 --> 00:17:11.254
und würde da alle Links reinschmeißen und würde dann zum Beispiel auch direkt die Ausgabe machen,

00:17:11.758 --> 00:17:13.235
das würde ja auch gehen.

00:17:13.381 --> 00:17:17.221
Aber dann kann es halt passieren, dass diese Queue zum Beispiel geblockt wird

00:17:17.261 --> 00:17:25.221
durch irgendeine Webseite, die zu langsam ist. zum Beispiel auf der Ausgabeseite dann blockiert und solche Sachen muss man halt dann entsprechend vermeiden.

00:17:26.468 --> 00:17:30.024
Und ja, letztendlich gibt's auch verschiedene Ausgabeformate,

00:17:30.546 --> 00:17:37.280
JSON, Markdown und so weiter für verschiedene, ja, Verwendungsmöglichkeiten, sag ich jetzt mal.

00:17:38.618 --> 00:17:41.970
Das ist so ganz grob der Überblick, wie das Ding jetzt aufgebaut ist.

00:17:44.004 --> 00:17:50.945
Bei dem HTTP und HTTPS hatte ich erst vor ein, zwei Wochen das Gespräch mit iOS-Developern,

00:17:51.251 --> 00:17:55.718
die mich gefragt hatten, du, wir bekommen grad von uns kein Backend,

00:17:55.879 --> 00:17:59.178
Da steht einfach nur slash, slash, das kann doch nicht gültig sein.

00:17:59.178 --> 00:18:05.458
Und dann muss ich auch erst mal so an früher überlegen. Und hab gesagt, doch, doch, das funktioniert im Browser.

00:18:05.458 --> 00:18:08.558
Weil es schaut dann nach, ob es HTTPS gibt, denke ich.

00:18:08.734 --> 00:18:12.158
Und wenn ja, nimmt's das. Und wenn's es nicht gibt, dann fällt's zurück auf HTTP.

00:18:12.389 --> 00:18:14.558
Damit konnte die iOS-App allerdings anfangen.

00:18:14.810 --> 00:18:20.578
Ich weiß nicht, was jetzt damit genau der Plan war, ob sich das in einem Browser hätte öffnen sollen oder was anderes.

00:18:20.578 --> 00:18:28.258
Aber auf jeden Fall, die waren, was sollen wir machen? Ich meine, so, mach mal HTTPS, das wird schon funktionieren.

00:18:28.258 --> 00:18:33.346
Vielleicht was sogar für Bilder oder irgendwie so was. Aber das, ja, ist naiv, funktioniert nicht überall.

00:18:33.994 --> 00:18:40.728
Mhm. Ja, das wird vor allen Dingen dann benutzt, wenn man eine Webseite hat, die HTTP und HTTPS unterstützt.

00:18:41.223 --> 00:18:47.258
Und man nicht will, dass ein User zum Beispiel das Protokoll ändern muss, um mit der Seite zu kommunizieren.

00:18:47.696 --> 00:18:50.180
Also nicht jeder Browser kann zum Beispiel HTTPS.

00:18:50.621 --> 00:18:53.258
Es gibt auch alte Screenreader, die das nicht beherrschen beispielsweise.

00:18:53.610 --> 00:18:56.482
Und dann ist es vollkommen okay, wenn die HTTP weiterhin benutzen.

00:18:56.914 --> 00:19:00.506
Aber man müsste ja auf der Webseite dann irgendwie so ein Fallback haben.

00:19:01.100 --> 00:19:04.258
Und um das zu vermeiden, kann man dem Browser einfach mitteilen,

00:19:04.258 --> 00:19:07.762
benutze einfach das Protokoll, das du eigentlich eh schon benutzt hast vorher.

00:19:08.473 --> 00:19:17.758
Ja. Vorsichtig bin ich auch geworden bei unserem Projekt. Da kann man Learning Resources hochladen und da einen Link hinterlegen.

00:19:18.069 --> 00:19:21.758
Und ich hab mir schon überlegt, ob ich's überhaupt validieren soll.

00:19:21.758 --> 00:19:25.829
Im schlimmsten Fall öffnet sich halt eine kaputte Seite, wenn die URL nicht stimmt.

00:19:26.058 --> 00:19:29.438
Aber ich dachte mir, ich schaue zumindest nach, ob es eine gültige URL ist.

00:19:29.438 --> 00:19:33.398
Ansonsten schreibe ich hin, bitte gibt eine gültige URL ein.

00:19:33.398 --> 00:19:40.503
Es war sehr schwierig, eine Regex zu finden, die tatsächlich aussagen kann, ob das eine gültige URL ist.

00:19:40.898 --> 00:19:45.463
Ich habe ja an offensichtliche, an für mich offensichtliche Details habe ich dran gedacht.

00:19:45.678 --> 00:19:50.058
Aber aus irgendeinem Grund habe ich gedacht, weil ich weiß ernsthaft nicht, warum,

00:19:50.058 --> 00:19:53.907
dass es zumindest drei Buchstaben haben sollte, der innere Teil.

00:19:54.555 --> 00:20:00.605
Aber die eine Domain war v2, Punkt. Okay, die ist nicht durchs Raster gekommen.

00:20:01.586 --> 00:20:04.908
User hat sich gnädigerweise beschwert, dann konnte ich's anpassen.

00:20:05.034 --> 00:20:09.103
Ja, Twitter wurde doch jetzt auch in Xcorp umbenannt.

00:20:09.652 --> 00:20:13.100
Also, Twitter heißt tatsächlich nicht mehr Twitter die Firma.

00:20:13.196 --> 00:20:22.136
Und das liegt daran, dass der bekloppte Elon, der hat quasi diese Xcorp schon immer für SpaceX und Co.

00:20:22.196 --> 00:20:24.436
Und der hat auch die Domänen x.com.

00:20:24.866 --> 00:20:26.279
Mhm. Genau.

00:20:26.796 --> 00:20:38.796
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.

00:20:38.796 --> 00:20:42.796
Man denke an Localhost beispielsweise. Und auch das Protokoll ist nicht nötig.

00:20:42.796 --> 00:20:49.361
Und wenn man jetzt nur Localhost beispielsweise nimmt, ja das ist schon ziemlich schwierig im Plaintext zu parsen.

00:20:50.045 --> 00:20:55.159
Und da fallen diese ganzen Krücken dann auseinander irgendwie.

00:20:57.652 --> 00:21:02.596
Aber es gibt zum Beispiel noch viel naivere Dinge, an die man am Anfang gar nicht denkt.

00:21:02.596 --> 00:21:06.141
Also zum Beispiel auch einfach langsame Webseiten oder große Webseiten.

00:21:06.396 --> 00:21:11.396
Wenn man jetzt zum Beispiel einen Linkchecker schreibt und man sagt, ich checke jetzt example.com.

00:21:12.902 --> 00:21:26.216
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.

00:21:27.126 --> 00:21:32.248
Und oder aski und das andere was passieren kann ist die webseite.

00:21:32.977 --> 00:21:36.209
Liefert erstmal gar nichts zurück, sondern wartet einfach erstmal 10 Minuten.

00:21:36.479 --> 00:21:40.242
Ist das dann jetzt ein Fehler oder nicht? Wo setzt man jetzt da das Limit an?

00:21:40.467 --> 00:21:44.272
Oder die Webseite ist super groß. Also angenommen man hat jetzt eine Webseite,

00:21:44.272 --> 00:21:47.786
die ist unglaublich groß. 10 Terabyte groß.

00:21:48.533 --> 00:21:52.272
Das ist ja größer als der Arbeitsspeicher, den die meisten Laptops haben.

00:21:52.272 --> 00:21:59.957
Und wenn man jetzt so eine Webseite trotzdem parsen will, dann reicht es nicht, wenn man einen naiven Parser benutzt.

00:22:00.272 --> 00:22:04.215
Weil man kann nicht das ganze Dokument auf einmal in den Arbeitsspeicher laden.

00:22:04.701 --> 00:22:07.060
Das heißt, man muss das stückweise laden.

00:22:07.636 --> 00:22:10.272
Und da muss man auch zum Beispiel einen Streaming-Encoder einsetzen.

00:22:10.535 --> 00:22:15.117
Und deswegen sind wir zum Beispiel auch weggegangen von dem Server-Browser,

00:22:15.558 --> 00:22:18.272
weil der das nämlich macht, der liest alles in den Speicher.

00:22:18.272 --> 00:22:20.707
Und das geht bei manchen Seiten einfach nicht.

00:22:21.272 --> 00:22:25.272
Und haben dann angefangen, den eigenen HTML-Browser oder eine Engine zu schreiben.

00:22:25.272 --> 00:22:31.272
Und bevor jetzt alle weglaufen, also, ich hab das jetzt nicht alleine gemacht,

00:22:31.483 --> 00:22:35.272
sondern das ist der Markus Unterwadetzer, der auch bei Sentry ist.

00:22:35.272 --> 00:22:39.828
Der hat angefangen, einen Streaming-HTML-Parser zu schreiben. Der heißt HTML-Gum.

00:22:40.728 --> 00:22:45.272
Und damit kann man Webseiten parsen und gleichzeitig die Links checken.

00:22:45.272 --> 00:22:50.091
Und dann macht man das so in dem Streaming-Verfahren. Das heißt, man hat einen konstanten Speicherbedarf.

00:22:50.703 --> 00:22:58.992
Und das sind sachen an die man definitiv am anfang jetzt erstmal nicht denkt das sind aber eigentlich auch noch die relativ harmlosen sachen.

00:22:58.992 --> 00:23:06.745
Man kann das beliebig forttreiben, man kann absolut paranoid werden und sich nur noch auf Link-Checking konzentrieren.

00:23:08.248 --> 00:23:13.046
Und nach zwei jahren sitz mal hier und der matthias macht immer noch link checking.

00:23:14.730 --> 00:23:18.378
Na ja zumindest nach acht jahren wenn ich jetzt richtig gerechnet habe.

00:23:18.925 --> 00:23:31.366
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.

00:23:31.780 --> 00:23:58.778
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.

00:23:59.300 --> 00:24:13.058
Genau, und dann wahrscheinlich, also du hast gesagt, du hast Markdown-Parser und Plaintext-Parser

00:24:13.058 --> 00:24:16.978
und HTML-Parser schon für den Input,

00:24:16.978 --> 00:24:22.138
das heißt also, man kann entweder eine wahrscheinlich eine Datei auf dem lokalen System einfüttern,

00:24:22.138 --> 00:24:30.736
oder man sagt, hier ist quasi im Web eine URL oder eine Ressource und bitte prüfe die.

00:24:31.150 --> 00:24:34.978
Genau, also wenn man auf den lokalen Fall zum Beispiel zurückgeht,

00:24:34.978 --> 00:24:41.978
dann ist ein großer Use Case von Litschi, dass Leute ihre Entwicklerdokumentation checken wollen.

00:24:41.978 --> 00:24:46.978
Das heißt, die haben irgendwo einen Static Site Generator, der generiert HTML-Dateien.

00:24:46.978 --> 00:24:53.978
Die liegen dann irgendwo in einem Ausgabeverzeichnis, zum Beispiel slash public oder slash private.

00:24:53.647 --> 00:24:59.642
Und da liegen dann die gerenderten HTML-Dateien drin. Und dann will man einfach nur checken.

00:25:00.272 --> 00:25:02.775
Sind diese Links untereinander valide?

00:25:03.081 --> 00:25:07.097
Also die Verlinkung in der Webseite selbst, ist die korrekt?

00:25:07.097 --> 00:25:10.297
Und dafür muss man gar nicht eine Netzwerk-Request machen.

00:25:10.499 --> 00:25:18.349
Legi kann nämlich rekursiv über ein Dateisystem gehen, alle validen Links suchen und dann auch die Verlinkung zueinander prüfen.

00:25:18.907 --> 00:25:21.428
Man kann dann zum Beispiel so einen Base-Directory einstellen.

00:25:21.842 --> 00:25:28.497
Du kannst sagen, okay, wenn du Slash hast, also zum Beispiel einen relativen Link, der mit Root beginnt,

00:25:28.665 --> 00:25:30.781
also sagen wir mal slash about.html,

00:25:31.312 --> 00:25:34.097
dann mach das relativ zu diesem Verzeichnis.

00:25:34.097 --> 00:25:42.897
Dann steht dann irgendwie slash public slash about.html oder slash public slash about slash index.html.

00:25:42.897 --> 00:25:49.173
Das ist ja in manchen Browsern oder beziehungsweise Webservern auch valide oder äquivalent.

00:25:49.596 --> 00:25:56.437
Und da ist zum Beispiel auch die Sache, wenn man jetzt eine Webseite hat, die hat einen

00:25:56.437 --> 00:26:02.622
About-Link, und man weiß jetzt nicht, auf welchem Webserver das läuft, dann kann man

00:26:02.757 --> 00:26:08.177
unmöglich entscheiden, ob ein Link valide ist, wenn es eine Webseite gibt, slash about

00:26:08.177 --> 00:26:12.737
slash index.html, weil das kommt zum Beispiel auf die Konfiguration vom Webserver drauf,

00:26:13.380 --> 00:26:13.737
an.

00:26:13.737 --> 00:26:20.897
Kann man einstellen, ja, index.html ist das Root oder man kann sagen, nein, es gibt kein Root.

00:26:21.158 --> 00:26:26.622
Und machen Datei-Listing beispielsweise. Und ja, wie prüft man sowas, ja?

00:26:28.108 --> 00:26:46.558
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?

00:26:46.558 --> 00:26:55.681
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.

00:26:56.005 --> 00:27:07.556
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.

00:27:09.113 --> 00:27:20.618
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.

00:27:21.410 --> 00:27:24.399
Wenn der Statuscode 200 ist, dann ist die Seite korrekt.

00:27:25.371 --> 00:27:29.431
Und ansonsten nicht. Dann könnte man sagen, okay, was ist denn mit 204?

00:27:29.773 --> 00:27:34.658
204 liefert dir zum Beispiel keinen Content zurück, aber ist auch technisch gesehen valide.

00:27:34.658 --> 00:27:40.658
Wird oft bei API-Requests zum Beispiel benutzt. Dann könnte man sagen, ja, okay, dann ist halt jeder 200er

00:27:40.658 --> 00:27:45.658
oder 2xx-Request ist dann valide, und alles, was drüber ist oder drunter,

00:27:45.658 --> 00:27:46.850
das ist dann inkorrekt.

00:27:47.658 --> 00:27:55.638
Ja, dann müsste man zum Beispiel sagen, was ist mit 303 oder 302, also ein Redirect. Ist der dann

00:27:55.638 --> 00:28:02.558
valide oder nicht? Also akzeptiere ich zum Beispiel einen Redirect oder zwei oder hundert oder tausend,

00:28:02.558 --> 00:28:04.153
Also ist das auch ein valider Case?

00:28:04.972 --> 00:28:09.962
Und die Antwort ist, es kommt darauf an, ja, wie man das halt selber sieht.

00:28:09.962 --> 00:28:17.802
In Litchi kann man den Status-Code einstellen, den man als valide bezeichnet und kann das halt selber bestimmen.

00:28:17.802 --> 00:28:22.622
LinkedIn beispielsweise liefert dir einen 999-Status-Code zurück,

00:28:22.715 --> 00:28:28.462
der in keiner Dokumentation vom Web, soweit ich weiß, korrekt ist.

00:28:28.462 --> 00:28:30.421
Es gibt keinen 999-Status-Code.

00:28:30.943 --> 00:28:34.322
Aber was die damit sagen, ist, ich will nicht, dass du mich crawlst, ja?

00:28:34.322 --> 00:28:39.422
Und da muss man zum Beispiel auch einen Workaround finden, um LinkedIn zu crawlen oder zu sagen,

00:28:39.422 --> 00:28:40.963
okay, ist die Seite valide oder nicht.

00:28:41.638 --> 00:28:47.688
Jetzt, wenn eine Seite beispielsweise partout nicht will, dass man sie crawlt, dann kann man wenig machen.

00:28:48.390 --> 00:28:54.622
Und heutzutage ist es halt so, dass viele Webseiten sehr JavaScript-intensiv sind

00:28:54.989 --> 00:28:56.422
und man nicht an die Links kommt.

00:28:56.537 --> 00:29:02.022
Oder dass die hinter Cloudflare-CDNs liegen und da ist nochmal so eine Bot-Detection davor.

00:29:02.686 --> 00:29:07.522
Und man kann natürlich anfangen mit Browserspoofing. Und auch da haben wir schon rumgespielt.

00:29:07.522 --> 00:29:11.022
Aber das sind lauter Edge-Cases, die relativ schwierig sind.

00:29:11.022 --> 00:29:13.522
Und die das Ganze halt wirklich extrem schwierig machen.

00:29:14.136 --> 00:29:17.022
Und irgendwann geht man halt her und hat dann eine Browser-Engine,

00:29:17.022 --> 00:29:19.466
die man selber laufen lässt.

00:29:19.628 --> 00:29:24.022
Und ein Ansatz wäre zum Beispiel, einen Headless-Chrome-Browser zu benutzen.

00:29:24.022 --> 00:29:30.022
Aber nicht in jeder Umgebung. Zum Beispiel auf FreeBSD oder auf OpenBSD gibt's einen Headless-Chrome.

00:29:30.241 --> 00:29:37.822
Und was ist dann die Möglichkeit? Und der aktuelle Ansatz, mit dem wir jetzt momentan auch arbeiten,

00:29:38.082 --> 00:29:42.922
zwei Studenten aus, in der Schweiz, die arbeiten tatsächlich auch an dem Problem gerade,

00:29:42.922 --> 00:29:47.238
die versuchen, so eine kleine Web-Assembly-Runtime zu bauen,

00:29:47.481 --> 00:29:53.822
in der dann ein Dino-Worker läuft und dann die Webseite mit der JavaScript-Engine,

00:29:53.822 --> 00:29:57.203
also V8, dann rendert und dann die Links extrahiert.

00:29:58.184 --> 00:30:00.642
Das ist zum Beispiel ein Ansatz, den man wählen kann.

00:30:02.181 --> 00:30:06.822
Ja, aber tatsächlich, um überhaupt zu wissen, ob eine Webseite valide ist,

00:30:06.989 --> 00:30:09.822
muss man sehr, sehr viel über den Use Case wissen.

00:30:10.094 --> 00:30:16.322
Und selbst dann gibt es immer noch Edge Cases, die man sehr, sehr schwer abdecken kann.

00:30:16.738 --> 00:30:19.322
Also, ich nenne jetzt einfach mal nochmal, ich hau mal noch einen raus,

00:30:19.322 --> 00:30:22.822
ich nenne mal nochmal einen Edge Case, an den man vielleicht auch nicht denkt,

00:30:23.562 --> 00:30:26.822
wenn man beispielsweise einen YouTube-Link kontrollieren will.

00:30:26.822 --> 00:30:32.462
Will. Also man hat zum Beispiel ein YouTube-Video und man sagt, ist das jetzt online oder nicht,

00:30:32.663 --> 00:30:38.822
dann reicht es nicht zu sagen, nimm die YouTube-URL und schau, ob das Video da ist oder schau,

00:30:38.822 --> 00:30:44.782
ob ich einen 200er zurückkriege. Weil bei YouTube ist es so, dass ein Video zum Beispiel privat sein

00:30:44.782 --> 00:30:49.942
kann. Und YouTube liefert sogar einen 200er zurück, selbst wenn das Video gar nicht existiert.

00:30:51.037 --> 00:30:56.247
Das heißt, da muss man einen Workaround finden. Und man muss vor allen Dingen einen Workaround finden,

00:30:56.307 --> 00:31:01.047
der ohne JavaScript-Engine funktioniert, weil das ja auf der Kommandozeile ausgeführt wird.

00:31:01.107 --> 00:31:03.928
Und ein Weg, das zu tun ist, das Thumbnail zu prüfen.

00:31:04.486 --> 00:31:12.967
Weil YouTube die Thumbnails separat ablegt. Und die liefern tatsächlich einen 404 beispielsweise zurück,

00:31:13.027 --> 00:31:15.901
wenn die Thumbnail nicht existiert.

00:31:16.135 --> 00:31:17.828
Und die löschen gleichzeitig das Video.

00:31:18.458 --> 00:31:23.382
Ja. Aber das ist hier wirklich schon extremes Detailwissen. Das kann sich ja auch jederzeit ändern.

00:31:23.553 --> 00:31:29.727
Also, Sie könnten ja sich umentscheiden. Wir hatten ein ziemlich ähnliches Problem,

00:31:29.727 --> 00:31:32.167
von gerade diesen Learning Resources, von denen ich gesprochen habe,

00:31:32.167 --> 00:31:38.326
wo man die URL hinterlegen kann, können die Personen natürlich auch Vimeo-Videos oder Sonstiges hochladen.

00:31:38.875 --> 00:31:41.332
Oder Microsoft Share, was weiß ich was.

00:31:41.963 --> 00:31:46.950
Und wir versuchen, sie auch zu embetten. Das funktioniert bei manchen Sachen extrem einfach.

00:31:47.337 --> 00:31:50.827
Und manche andere Sachen können dann hinter Passwörtern liegen.

00:31:51.109 --> 00:31:56.547
Aber für uns existiert die Seite, die Seite existiert, also versuchen wir, sie zu embedden.

00:31:56.825 --> 00:32:02.747
Und es geht noch halbwegs, wenn man ein Passwort braucht, weil sie es dann auch im iFrame benutzen dürfen,

00:32:03.019 --> 00:32:08.147
aber manchmal ist es dann einfach mit einem SSO-Login und das müsste dann der Account im Browser sein,

00:32:08.438 --> 00:32:10.547
und dann wird schon ziemlich schwierig.

00:32:10.547 --> 00:32:16.547
Also wir haben halt schon immer als Ausweg noch, oder klick auf dieses Icon, dann öffnet sie es einfach

00:32:16.547 --> 00:32:18.547
in einem Topf auf die richtige Seite.

00:32:19.647 --> 00:32:25.847
Aber es gibt keine richtig gute Lösung, außer wir würden da wirklich eine Person mal sehr lange

00:32:25.847 --> 00:32:27.604
dran setzen, um das alles durchzudenken.

00:32:27.747 --> 00:32:31.047
Und das macht man nicht mal zwischen den Meetings.

00:32:34.447 --> 00:32:39.447
Das Tragische ist eigentlich, dass Crawling oder eigentlich das komplette Web,

00:32:40.873 --> 00:32:43.747
zumindest maschinenlesbar nicht funktioniert.

00:32:43.747 --> 00:32:48.907
Es ist eigentlich ausgelegt auf Menschen, die den Content lesen,

00:32:48.907 --> 00:32:51.874
aber es ist kein maschinenlesbares Format.

00:32:52.270 --> 00:32:57.707
Und das ist vielleicht auch ganz gut so, weil wir sind ja vielleicht, viele von uns sind mit HTML groß geworden

00:32:57.707 --> 00:32:59.907
und haben da unsere ersten Schritte gemacht.

00:32:59.907 --> 00:33:05.907
Ich finde das supergut, dass man das lesen kann und dass man das mit einem normalen Texteditor schreiben kann.

00:33:05.907 --> 00:33:11.407
Nur das macht es natürlich umso schwieriger, um das auf Scale zum Beispiel zu betreiben

00:33:11.407 --> 00:33:16.666
und damit Millionen von Links in der Woche zu checken, weil es halt einfach so so viele Edge Cases gibt.

00:33:17.891 --> 00:33:25.741
Das ist das Tragische schon. Hast du denn dein eigenes Problem, also wie hast du das denn lösen können?

00:33:25.741 --> 00:33:34.741
Weil du hattest ja gesagt, du hast diese Tool-Sammlung oder eben quasi eine Sammlung von Code-Quality-Tools

00:33:34.741 --> 00:33:42.741
und hast dann 700 Stück irgendwann zusammen und da waren irgendwie immer wieder welche, die dann verschwunden sind.

00:33:43.196 --> 00:33:48.741
Wenn du jetzt Litchi darauf angesetzt hast, wie ...

00:33:49.588 --> 00:33:56.741
Also, ich stell mir halt vor, du hast irgendein Tool, das ist vielleicht auf einem GitHub-Repo gewesen oder so was,

00:33:56.741 --> 00:34:00.741
und dann wird das GitHub-Repo gelöscht, und ich weiß nicht, was dann passiert.

00:34:00.741 --> 00:34:03.741
Dann wird wahrscheinlich auf die GitHub-Startseite umgeleitet,

00:34:03.741 --> 00:34:06.741
oder ... Obwohl, nee, dann gibt's auch eine 404-Seite, ne?

00:34:06.741 --> 00:34:13.001
Genau, also da hast du dann schon relativ viel viel eigentlich Erfolg gehabt, in Anführungszeichen,

00:34:13.061 --> 00:34:18.401
mit, du kriegst schon relativ viel 404-Rückmeldung.

00:34:18.461 --> 00:34:22.401
Also würdest du sagen, das Web ist generell einigermaßen okay konfiguriert,

00:34:22.461 --> 00:34:23.801
was Status-Codes angeht?

00:34:23.861 --> 00:34:28.009
Oder ist das Web tendenziell eher scheiße konfiguriert und nur manchmal gut?

00:34:31.501 --> 00:34:36.057
Es wird schlechter. Mhm. Sehr, sehr viele Links gehen kaputt.

00:34:36.175 --> 00:34:40.941
Überraschend viele interne Links. Ich habe mal irgendwie eine Statistik gehört, ich weiß nicht, ob das stimmt,

00:34:41.153 --> 00:34:43.441
dass die Hälfte der Links innerhalb von zwei Jahren kaputt gehen.

00:34:43.441 --> 00:34:45.213
Also die Halbwertszeit ist wirklich nicht gut.

00:34:45.744 --> 00:34:49.441
Und vor allen Dingen für Ressourcen, die öffentlich zugänglich sein sollten,

00:34:49.441 --> 00:34:53.441
also sprich Public Data oder so, ist es sehr, sehr schlimm.

00:34:53.792 --> 00:34:58.941
Also wir haben zum Beispiel einen User, der hat immer wieder Probleme mit diesen DOI-Links.

00:34:58.941 --> 00:35:07.441
Das sind Buchreferenzen, und damit kann man permanente Links zum Beispiel erstellen

00:35:07.800 --> 00:35:20.376
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.

00:35:21.672 --> 00:35:35.770
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.

00:35:36.994 --> 00:35:48.697
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.

00:35:49.282 --> 00:35:53.764
Und das ist eigentlich extrem schade, finde ich. Also, das ist ein Riesenproblem.

00:35:53.764 --> 00:36:01.764
Und man muss auch archive.org extrem loben. Ohne die wird extrem viel Information einfach verloren gehen.

00:36:02.200 --> 00:36:07.764
Und ich finde, das ist eine extrem wichtige Ressource. Und das benutzen wir zum Beispiel auch als Fallback.

00:36:07.764 --> 00:36:12.764
Also, Ritchie hat jetzt auch die Möglichkeit vorzuschlagen, einen Link zu ersetzen, der kaputt ging.

00:36:12.850 --> 00:36:20.493
Und das ist so der erste Schritt in Richtung vielleicht Service und auch eine Möglichkeit, den Status quo ein bisschen zu verbessern.

00:36:21.096 --> 00:36:26.713
Und in die Richtung soll es eigentlich auch weitergehen, dass man, wenn man Pull-Request erstellt, automatisch sieht,

00:36:26.785 --> 00:36:29.764
wenn ein Link kaputt ist und den vielleicht nicht mergt.

00:36:29.764 --> 00:36:34.764
Oder wenn man einen großen Browser-Projektumzug macht, von einer Browser-Engine auf die andere,

00:36:34.764 --> 00:36:40.199
oder von einem Framework auf das andere, meine ich, dass man dann sieht, wo die ganzen Links jetzt kaputt gehen.

00:36:40.829 --> 00:36:48.524
Und ja. Also ich finde, der der Status vom Web ist sehr sehr wünschenswert.

00:36:49.237 --> 00:37:02.084
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.

00:37:02.084 --> 00:37:06.204
Also manche Sachen gibt es ja dann noch, aber die gehen dann verschütt,

00:37:06.449 --> 00:37:10.524
weil einfach nicht die passenden Weiterleitungen da sind und die dann

00:37:10.524 --> 00:37:17.924
auch nicht irgendwie kolportiert werden dadurch und naja und und die oder die irgendwann dann

00:37:17.924 --> 00:37:23.472
dann gibt es sie aber dann gibt es sie halt nach ein paar jahren nicht mehr weil man denkt also

00:37:23.884 --> 00:37:30.604
jetzt haben das ja alle indexer kapiert und alle haben bestimmte noch den link auf das die aktuelle

00:37:30.604 --> 00:37:39.416
url und genau dem ist es ja oft nicht so also so eine webseite die die launch man einmal mit links und dann...

00:37:40.739 --> 00:37:56.549
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,

00:37:56.943 --> 00:38:00.022
es ist einfach keine sache die glamourös ist.

00:38:00.751 --> 00:38:06.469
Und deswegen machen es viele halt einfach nicht. Also man schreibt einen Artikel, veröffentlicht den,

00:38:06.469 --> 00:38:11.349
kriegt vielleicht das, was man will oder auch nicht. Und dann vergisst man aber, dass der Artikel existiert

00:38:11.349 --> 00:38:13.228
und diese Backlinks gehen dann irgendwann kaputt.

00:38:13.795 --> 00:38:18.189
Und das ist halt dieser Status, in dem wir uns befinden leider.

00:38:18.710 --> 00:38:22.829
Und deswegen ist vielleicht auch die Idee, dass man den Leuten ein Tool an die Hand gibt,

00:38:22.829 --> 00:38:24.427
um das automatisch zu tun.

00:38:24.499 --> 00:38:28.189
Also es wird wahrscheinlich demnächst auch ein Dashboard geben,

00:38:28.189 --> 00:38:32.034
wo man halt dann den Status von seiner Webseite sieht, also ähnlich wie so ein Health-Check,

00:38:32.466 --> 00:38:37.709
und dass man sieht, wie viele kaputte Links habe ich denn, und dass man dann irgendwann einschalten kann und sagt,

00:38:37.709 --> 00:38:38.789
okay, da muss ich was tun.

00:38:38.789 --> 00:38:42.413
Hier sind auf, in dem Bereich zum Beispiel, sind die meisten Links kaputt,

00:38:42.584 --> 00:38:43.863
dass es so eine Initiative gibt.

00:38:44.268 --> 00:38:47.869
Oder dass man zum Beispiel auch hergeht, und wenn das ein Open-Source-Repository ist,

00:38:47.869 --> 00:38:53.666
dass man das auch automatisch dann fixen kann, indem dass man dem Repository ein Pull-Request schickt und sagt,

00:38:54.297 --> 00:38:56.269
oh, ich habe jetzt alle deine Links gefixt zum Beispiel.

00:38:56.269 --> 00:38:59.629
Oder hier sind 20 Links, da weiß ich, die gibt es nicht mehr.

00:39:00.589 --> 00:39:14.093
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,

00:39:14.624 --> 00:39:25.985
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.

00:39:26.498 --> 00:39:40.046
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

00:39:40.451 --> 00:39:45.979
nur weil ich zum Beispiel auf Amazon mein Buch verlinke beispielsweise, heißt das ja nicht, dass es das Buch noch gibt.

00:39:46.582 --> 00:39:50.840
Es kann ja auch sein, dass der Link 200 zurückliefert und das Buch einfach nicht mehr da ist.

00:39:51.488 --> 00:39:55.299
Und da kann man vielleicht auch ansetzen und so einen kleinen Validator bauen,

00:39:55.299 --> 00:39:58.249
der dann wirklich auch den Content von den Webseiten checkt.

00:39:58.681 --> 00:40:04.299
Und ja, das ist halt auch so ein Ding, wenn man dann den WebAssembly, die Runtime hat,

00:40:04.299 --> 00:40:06.081
dann kann man seine eigenen Checks bauen.

00:40:06.299 --> 00:40:11.299
Und die Idee ist, dass man so eine Art Konfigurationsdatei hat,

00:40:11.662 --> 00:40:12.661
wo man einstellen kann.

00:40:13.299 --> 00:40:17.648
Übrigens, für alle Links, die so aussehen, nimm diesen Validator.

00:40:17.899 --> 00:40:22.105
Und der gibt dann zurück, ist das valide oder nicht. Und dann kann man viel tiefer reingehen.

00:40:22.780 --> 00:40:26.552
Ich kann beispielsweise sagen, okay, wenn's ein Amazon-Shortlink ist,

00:40:27.020 --> 00:40:35.539
dann lass diesen JavaScript-Code laufen, um zu prüfen, ob der Artikel zum Beispiel noch verfügbar ist.

00:40:35.619 --> 00:40:41.027
Und das ist wiederum ein eigenes Projekt, Das man vielleicht auch monetarisieren kann, irgendwann.

00:40:43.962 --> 00:40:53.531
Ja, aber super viel Arbeit, also weil man ja wirklich dann dediziert für jede, für jede Ziel-Webseite im Prinzip einen angepassten,

00:40:54.306 --> 00:41:00.812
Crawler im Prinzip nochmal oder Crawler-Plugin bauen muss und das ja auch nur so lange funktioniert,

00:41:01.345 --> 00:41:04.812
wie die Seite eben nicht auf links gedreht wird.

00:41:05.063 --> 00:41:05.702
Ganz genau.

00:41:06.812 --> 00:41:10.812
Ja, es ist bei vielen Tools so, dass es dann irgendwann so ein Marketplace wird,

00:41:11.275 --> 00:41:15.612
wo Leute einfach die Infrastruktur benutzen, um dann ihre eigenen Probleme zu lösen.

00:41:16.112 --> 00:41:26.885
Also eine andere Sache, über die ich mir auch Gedanken mache, ist es gibt super viele Agenturen oder vielleicht auch sagen wir mal.

00:41:29.372 --> 00:41:36.172
Ja, Rechtsberatungen beispielsweise, die Legal Documents haben und wie checken die eigentlich ihre Links?

00:41:36.172 --> 00:41:50.615
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.

00:41:51.110 --> 00:41:58.105
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.

00:41:58.960 --> 00:42:05.672
Aber ich glaube auch, dass reine Link-Checking an sich ist nichts, wofür viele Leute viel Geld ausgeben würden.

00:42:07.989 --> 00:42:22.204
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.

00:42:22.528 --> 00:42:30.252
Ha ne äh lisch also leider von der benahmung her ein bisschen schwierig ja lisch ist in go geschrieben.

00:42:30.738 --> 00:42:45.659
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.

00:42:45.719 --> 00:42:56.579
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.

00:42:56.763 --> 00:43:04.010
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.

00:43:04.523 --> 00:43:07.746
Und dann leider auch wieder verschwinden weil sie einfach keine zeit haben.

00:43:08.799 --> 00:43:16.019
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.

00:43:16.506 --> 00:43:21.340
Ja, das ist, wir haben ja den ganzen Podcast, ne, Berlin Checking, also schon bald 600 Folgen.

00:43:21.790 --> 00:43:31.379
Ja, zurecht, zurecht, weil es auch sehr, sehr spannend ist. Aber wir haben schon ab und zu mal Maintainer, die großes leisten,

00:43:31.379 --> 00:43:34.379
ein großes Refactoring machen oder ein großes Feature zum Beispiel,

00:43:34.379 --> 00:43:35.879
das die brauchen, auch Contributen.

00:43:35.996 --> 00:43:38.879
Aber ich glaube, das ist so ähnlich wie bei Curl.

00:43:39.461 --> 00:43:44.179
Es gibt halt irgendwie einen oder zwei Core-Maintainer und die halten das Ding halt zusammen.

00:43:44.179 --> 00:43:49.779
Also, wenn ich jetzt komplett wegfallen würde, glaube ich, würde es das Projekt in der Form irgendwann nicht mehr geben.

00:43:50.741 --> 00:43:53.046
Und dann müsste das jemand wegforken.

00:43:54.954 --> 00:44:07.026
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.

00:44:08.044 --> 00:44:14.138
Oder kriegst du da irgendwie gibts hast du so ein open collective laufen oder sowas.

00:44:15.128 --> 00:44:23.149
Ja genau es gibt ein open collective aber das ist alles noch sehr sehr am start sehr am anfang also.

00:44:23.564 --> 00:44:33.529
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.

00:44:34.492 --> 00:44:39.191
Ich glaube so auf lange Sicht wird Sponsoring relativ schwer.

00:44:39.822 --> 00:44:44.926
Also bei diesem ursprünglichen Projekt Analysis Tools, wofür ich das auch gebaut habe, ist das viel, viel leichter.

00:44:45.223 --> 00:44:50.223
Da haben wir relativ große Sponsoren, die halt statische Code-Analyse-Tools bauen.

00:44:50.223 --> 00:44:53.223
Und die wollen halt in erster Linie Marketing für ihre Tools machen.

00:44:53.406 --> 00:44:54.963
Weil die wissen, Open Source ist wichtig.

00:44:55.486 --> 00:44:59.627
Und deswegen sponsern die das Projekt, um halt diese Visibility zu kriegen und den Zugang zum Repo.

00:45:00.223 --> 00:45:03.223
Weil Leute das in erster Linie finden, wenn sie googeln danach.

00:45:03.223 --> 00:45:11.923
Aber bei Litchi ist es viel schwieriger, weil Leute nicht normalerweise nach dem Tool suchen, sondern nach einer Lösung für ihr Problem.

00:45:11.923 --> 00:45:19.207
Die sagen, Link kaputt oder Website redesign, Links checking oder irgend so was.

00:45:19.333 --> 00:45:24.203
Und deswegen glaube ich, dass Sponsoring nicht der richtige Weg ist.

00:45:25.913 --> 00:45:38.480
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.

00:45:38.939 --> 00:45:48.833
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.

00:45:49.184 --> 00:46:01.580
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.

00:46:01.895 --> 00:46:07.783
Und dann ist mir aufgefallen, nein, eigentlich habe ich schon einen Marketplace, den nennen sie nämlich GitHub.

00:46:07.900 --> 00:46:16.895
GitHub ist der Marketplace, weil ich habe heute Morgen mal nachgeschaut, 3482 Repositories benutzen das.

00:46:17.334 --> 00:46:23.375
Und die haben das eingebaut in ihre Repositories. Das heißt, das wäre dumm, von denen zu verlangen,

00:46:23.375 --> 00:46:27.495
dass die irgendwo anders hinmigrieren oder irgendwas wissen. Das heißt, eigentlich ist

00:46:27.495 --> 00:46:32.895
es gut, den Ansatz zu wählen, dass man da Pro Features in die GitHub-Action einbaut.

00:46:33.394 --> 00:46:40.095
Und meine Idee war jetzt, okay, es gibt einen Paid Plan, da kriege ich dann automatisch eine

00:46:40.095 --> 00:46:45.295
Authentifizierung über eine GitHub-App und dann kriege ich automatisch mehr oder weniger kostenlos

00:46:45.673 --> 00:46:48.581
Das ist ein Dashboard und da sehe ich dann meine Links.

00:46:48.655 --> 00:46:52.255
Aber momentan kriege ich halt ein Issue, wenn irgendein Link kaputt geht.

00:46:52.533 --> 00:46:57.975
Und wenn ziemlich viele Links regelmäßig kaputt gehen, hat man eine Menge Issues.

00:46:57.975 --> 00:47:00.761
Ja, Story of my life.

00:47:01.346 --> 00:47:04.911
Aber deshalb geht es dann mit so einem Dashboard vielleicht.

00:47:05.298 --> 00:47:09.975
Ich kann mir vorstellen, dass, also es gibt doch auch total viel so SEO-Tools,

00:47:09.975 --> 00:47:13.455
die gucken, ob man kaputte Links auf der Seite hat und so.

00:47:13.455 --> 00:47:21.955
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...

00:47:23.321 --> 00:47:38.436
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.

00:47:39.183 --> 00:47:46.700
Und wenn du das eben nur für interne zwecke benutzt oder eben für selber selber kostenlose tools verteilt dann dann eben nicht.

00:47:46.979 --> 00:47:59.681
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.

00:48:00.149 --> 00:48:06.595
Und in der community wurde das jetzt nicht so gern gesehen was die gemacht haben aber es macht total sinn.

00:48:07.279 --> 00:48:17.469
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.

00:48:17.974 --> 00:48:22.091
Und die wollten halt solche Licensing-Probleme in Zukunft vermeiden.

00:48:22.091 --> 00:48:26.949
Also dass du nicht einfach hergehen kannst und kannst ein Open-Source-Projekt dann kommerzialisieren.

00:48:27.300 --> 00:48:32.782
Und übrigens OpenSearch benutzt Litchi für Link-Checking. Ich droppe das jetzt einfach mal.

00:48:32.931 --> 00:48:36.338
Aha, da liegt doch Geld rum.

00:48:36.626 --> 00:48:49.103
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.

00:48:49.455 --> 00:48:55.411
Wenn man dazu amazon hingeht und sagt hey amazon du benutzt das in 15 repositories von dir.

00:48:55.927 --> 00:49:05.211
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.

00:49:05.488 --> 00:49:09.891
Der ist ja jetzt auf seiner jacht der macht ja bei amazon nix mehr.

00:49:10.043 --> 00:49:18.064
Das ist das aber es gibt jemanden mit dem ich auch tatsächlich früher schon zusammengearbeitet hab der zufälligerweise bei amazon ist.

00:49:19.045 --> 00:49:22.781
Und mit dem hatte ich früher einen Slack-API-Client geschrieben.

00:49:24.023 --> 00:49:27.895
Und der hat auch zu Litchi schon contributed, und ist bei OpenSearch.

00:49:27.895 --> 00:49:31.895
Das heißt, vielleicht gibt es eine Möglichkeit, dass man mal mit solchen Leuten spricht.

00:49:31.895 --> 00:49:35.895
Aber ich glaube, generell ist das Problem, die großen Firmen vor allen Dingen,

00:49:35.895 --> 00:49:40.740
geben relativ zu ihren Gewinnen viel zu wenig an Open Source ab.

00:49:41.046 --> 00:49:45.895
Also nicht mal 1%, nicht mal 0,1% von ihren Gewinnen.

00:49:47.582 --> 00:49:53.455
Da muss ich übrigens auch mal an der Stelle Trivago löblich erwähnen, weil die zu einem

00:49:53.455 --> 00:49:59.935
gewissen Zeitpunkt auch mal fast genauso viel gesponsert haben wie Facebook und waren aber

00:49:59.935 --> 00:50:07.576
ein Hundertstel so groß. Und viele Firmen haben Open Source nicht so verstanden wie Trivago. Dafür

00:50:07.815 --> 00:50:14.575
muss man dankbar sein. Hatte ich auch mitbekommen. Also genau, ja, Webpack war ja irgendwie,

00:50:14.575 --> 00:50:17.406
Die wurde ja auch stark gesponsert damals, glaub ich.

00:50:17.569 --> 00:50:18.874
Und noch diverse andere.

00:50:19.459 --> 00:50:24.995
Genau, wir hatten den ersten Core-Maintainer vollständig bezahlt von dem Geld.

00:50:25.815 --> 00:50:29.795
Und Babel, das ist die ... Ich weiß gar nicht, was das ist.

00:50:29.835 --> 00:50:32.375
Ist das nicht so ein JavaScript-Translation-Ding?

00:50:32.415 --> 00:50:34.871
So ein Transpiler, ja. Mhm, das auch.

00:50:36.335 --> 00:50:42.955
Ja, nee, das ist schon cool. Ja, ich vermute immer bei so Buden wie Amazon ist ...

00:50:42.955 --> 00:50:47.069
Die sind ja auch einfach schon, obwohl die eine Tech-Company sind,

00:50:47.465 --> 00:50:49.395
wirken die schon sehr verkrustet.

00:50:49.455 --> 00:50:55.255
Da ist wahrscheinlich so auch niemand, der eine Kreditkarte irgendwie nutzen könnte

00:50:55.315 --> 00:50:57.055
für irgendwelche solche Dinge.

00:50:57.115 --> 00:51:02.031
Und muss sich wahrscheinlich das erst mal von was weiß ich wie vielen C-Levels absegnen lassen.

00:51:03.318 --> 00:51:09.332
Ist eigentlich seltsam. Also, es ist ja eigentlich so eine Tech-Company, eine moderne.

00:51:09.854 --> 00:51:13.955
Aber irgendwie unter den Tech-Companies dann wieder die eher altbacken.

00:51:16.507 --> 00:51:23.955
Viel leichter ist es bei kleineren Firmen, kleinen Startups beispielsweise und dann kann man mit

00:51:23.955 --> 00:51:27.955
denen wachsen. Also es gibt schon Firmen mit denen man dann auch reden kann, wo man vielleicht

00:51:27.955 --> 00:51:29.749
den CTO oder so mal persönlich

00:51:29.955 --> 00:51:35.955
sprechen kann und die verstehen meistens eher noch das Problem und die sind auch dann

00:51:35.955 --> 00:51:39.955
in der Position, dass sie eine Entscheidung treffen können und das

00:51:39.955 --> 00:51:44.135
funktioniert dann meistens über einen kurzen Dienstweg viel besser, als wenn man das offiziell

00:51:44.135 --> 00:51:48.775
macht. Große Firmen haben viel Zeit.

00:51:51.453 --> 00:51:59.303
Hast du denn noch irgendwie so Themen, die du beackern möchtest?

00:51:59.303 --> 00:52:03.303
Oder also abgesehen von denen, die du gerade genannt hast,

00:52:03.303 --> 00:52:07.303
also mit diesem so, es wäre cool, wenn wir mal so ein Feature hätten,

00:52:07.303 --> 00:52:12.303
das irgendwie vielleicht Links automatisch ersetzt und Pull-Requests erstellt und so.

00:52:12.303 --> 00:52:17.303
Gibt's noch irgendwelche? Ich meine, das geht ja jetzt schon total lange.

00:52:17.303 --> 00:52:20.083
Man würde ja denken, im Grunde,

00:52:20.477 --> 00:52:28.056
bis auf solche richtig krassen Luxusfeatures, die Basics sind ja alle da, alles ist super, alle Bugs raus.

00:52:29.326 --> 00:52:32.783
Gibt's da trotzdem noch Dinge, die du so auf dem Schirm hast,

00:52:32.843 --> 00:52:37.643
die du gerne irgendwie gefixt sehen würdest oder die du gerne eingebaut haben würdest?

00:52:38.022 --> 00:52:38.931
Es ist komplett.

00:52:39.381 --> 00:52:43.730
Nein, leider nicht. Also, es gibt schon noch sehr, sehr viel, was passieren muss.

00:52:44.009 --> 00:52:45.483
Irgendwie hab ich das Gefühl,

00:52:45.483 --> 00:52:51.603
das Ding wird jeden Tag größer statt kleiner. Und die Issues werden auch mehr statt weniger,

00:52:51.603 --> 00:52:58.443
obwohl das Projekt schon mehr kann. Zwei große Features, die wir momentan angehen,

00:52:59.195 --> 00:53:03.203
also ich spreche in dem Fall von wir, weil es tatsächlich mehr Leute sind, die dann arbeiten,

00:53:03.203 --> 00:53:09.883
das finde ich gut so, das ist Retry Handling und Recursion Support. Jetzt fragt man sich

00:53:09.883 --> 00:53:16.363
notiere ich. Was ist Retry-Handling überhaupt? Also beispielsweise ich habe einen Link-Checker,

00:53:16.363 --> 00:53:24.083
der eine Webseite checkt. Beispielsweise alle GitHub-Repositories. Dann kommt GitHub irgendwann

00:53:24.083 --> 00:53:30.163
und macht den Hahn zu und das geht super schnell und dann kommt man nicht mehr an diese Repositories

00:53:30.163 --> 00:53:36.083
ran, weil die natürlich Rate-Limiting eingebaut haben. Die schicken dir dann 429 und sagen,

00:53:36.083 --> 00:53:39.083
warte einfach kurz und lasst dir ein bisschen mehr Zeit.

00:53:39.732 --> 00:53:46.421
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.

00:53:47.240 --> 00:53:53.083
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

00:53:53.083 --> 00:53:56.083
und hier ist der Timestamp und dann meldest du dich bitte wieder.

00:53:56.083 --> 00:54:02.083
Wenn man dann jetzt anfängt noch weiter zu checken, dann checkt einem GitHub einfach immer weiter 429,

00:54:02.706 --> 00:54:05.083
bis man dann irgendwann aus GitHub ausgelockt wird.

00:54:05.254 --> 00:54:10.403
Und das passiert tatsächlich relativ häufig, auch beim Testing, leider, und dann ist GitHub

00:54:10.403 --> 00:54:14.443
für mich einfach mal eine Stunde lang down, weil ich halt einfach geblockt werde.

00:54:14.443 --> 00:54:17.923
Dann bist du generell mit all deinen Projekten bei GitHub geblockt.

00:54:17.923 --> 00:54:20.923
Ganz genau, ja. Ja, das ist eine böse Bot-Detection.

00:54:22.088 --> 00:54:35.790
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.

00:54:36.258 --> 00:54:44.036
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.

00:54:44.522 --> 00:54:52.858
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,

00:54:52.858 --> 00:54:57.278
hat mir dann 10 Immobilienberater rausgesucht und habe einfach mal,

00:54:57.998 --> 00:55:08.666
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.

00:55:09.242 --> 00:55:13.230
Und hab's tatsächlich geschafft, drei von den zehn Seiten komplett down zu bringen.

00:55:13.347 --> 00:55:15.498
Äh, eigentlich aus Versehen.

00:55:15.625 --> 00:55:19.638
Aber ja, das ist halt wirklich das Problem, wenn man nie aufpasst bei so was.

00:55:20.081 --> 00:55:21.338
Also, Retry-Handling.

00:55:22.214 --> 00:55:25.509
Jetzt muss man sich natürlich überlegen, wie macht man sauberes Rate-Limiting?

00:55:25.716 --> 00:55:30.038
Also, wie prüft man überhaupt, ob man zu viele Links checkt oder nicht?

00:55:30.569 --> 00:55:32.117
Wie viele Requests darf ich denn machen?

00:55:32.828 --> 00:55:36.398
Man kann ja erst mal naiv sagen, okay, einer pro Sekunde.

00:55:37.311 --> 00:55:41.198
Und viele Leute können sich jetzt vielleicht so vorstellen, wie die das programmieren würden.

00:55:41.965 --> 00:55:48.038
Ich habe zum Beispiel eine Liste an Links und dann sage ich for link in links check link und

00:55:48.038 --> 00:55:56.078
dann lasse ich das laufen, so schnell wie es geht, irgendwo in der Loop, ein Request pro Einheit,

00:55:56.078 --> 00:55:59.318
also sequentiell und irgendwann werde ich halt geblockt und dann denke ich mir,

00:55:59.318 --> 00:56:04.838
okay, es leapt 10 und damit ist das Problem für die meisten gelöst. Aber wenn man das

00:56:04.838 --> 00:56:09.758
sauber machen will, dann muss man sich überlegen, okay, wie viele Links darf ich denn wirklich

00:56:09.758 --> 00:56:19.514
checken? Also, im HTTP, wie sagt man denn, im Spec, genau, da ist beschrieben, wie das zu,

00:56:20.198 --> 00:56:27.358
handhaben ist. Und zwar können Webseiten einem einen Rate-Limit-Header schicken. Und da steht

00:56:27.358 --> 00:56:31.918
genau drin, wie lange man warten muss, wie viele Requests man machen darf pro Intervall und wie

00:56:31.918 --> 00:56:37.878
wie lange das Intervall ist. Problem ist allerdings, dass es dafür sieben oder acht verschiedene

00:56:37.878 --> 00:56:45.158
Implementierungen gibt. Also Reddit und GitHub und Twitter und andere Webseiten haben ihre

00:56:45.158 --> 00:56:49.599
eigene Implementierung davon. Und die Headers sehen halt leicht anders aus und die haben,

00:56:50.078 --> 00:56:53.838
leicht andere Funktionen und so weiter.

00:56:52.885 --> 00:56:55.154
Das heißt, wenn man das sauber machen will, muss man die parsen.

00:56:55.955 --> 00:57:00.447
Und deswegen habe ich eine Library geschrieben, die diese Rate-Limit-Header parst,

00:57:00.996 --> 00:57:04.354
und dann halt zurückgibt, ob man geblockt wird und wenn ja, wie lang.

00:57:04.984 --> 00:57:09.719
So, und dann geht man her und sagt, dann muss ich warten, bis ich wieder darf.

00:57:10.007 --> 00:57:13.735
Aber ich kann natürlich die anderen Webseiten in der Zeit natürlich weiterchecken.

00:57:13.735 --> 00:57:20.144
Das heißt, man muss dann so ein Bucket machen, und dann braucht man den State von der Webseite, um den zu checken.

00:57:21.278 --> 00:57:24.222
Aber was ist zum Beispiel mit Webseiten, die keinen Red-Limit-Header schicken?

00:57:24.483 --> 00:57:27.292
Ja, da geht's jetzt ziemlich ins Detail. Ich kürze das Ganze mal ab.

00:57:27.724 --> 00:57:32.450
Man kann vielleicht mal mit einem Request pro Sekunde starten, schauen,

00:57:32.621 --> 00:57:36.717
funktioniert das stabil, dann vielleicht auf zwei, dann auf vier, dann auf acht, dann 16 hochgehen.

00:57:37.347 --> 00:57:41.866
Oder man kann zum Beispiel mit einem Burst anfangen, dass man 16 auf einmal checkt,

00:57:42.010 --> 00:57:43.811
und dann sieht, kommen die alle sauber zurück.

00:57:44.315 --> 00:57:48.609
Und dann braucht man halt Retry-Handling. Deswegen, das ist ein super komplexes Thema.

00:57:49.158 --> 00:57:56.535
Kein Link-Checker kann das und es gibt auch keine Libraries außer dieser einen, die Rate-Limit-Header

00:57:56.535 --> 00:58:04.723
passt und das ist halt ein Feature, was spannend ist und hoffentlich auch bald eingebaut wird.

00:58:04.984 --> 00:58:10.341
Und das andere, darüber verliere ich jetzt weniger Worte, ist einfach Recursion-Support,

00:58:10.535 --> 00:58:15.445
das heißt, ich checke eine Webseite und ich gehe komplett über die komplette Webseite,

00:58:15.595 --> 00:58:20.423
Da gibt es zum Beispiel die Probleme, wo kriege ich eigentlich alle Links her, Stichwort

00:58:20.595 --> 00:58:28.175
Sitemap, XML, oder wie weit gehe ich in die Tiefe, oder prüfe ich zum Beispiel alle Bereiche

00:58:28.175 --> 00:58:30.083
von der Webseite oder nur manche und so weiter.

00:58:30.524 --> 00:58:38.035
Genau, das sind so die zwei Themen. Also zum einen Retry Handling und Rate Limiting und zum anderen Recursion Support.

00:58:40.813 --> 00:58:47.763
Ja, dann geht auf jeden Fall mal einen Aufruf an alle interessierten Hörerinnen und Hörer,

00:58:47.763 --> 00:58:54.363
die dann auch Rust-mächtig sind, nehme ich an, ist ja dann nötig, voraussetzung.

00:58:54.363 --> 00:58:59.263
Oder halt einfach das Ding mal testen auf der eigenen Webseite und einen Bug-Report erstellen.

00:58:59.263 --> 00:59:02.653
Also ein Issue kann man durchaus mal erstellen ohne Rust-Support.

00:59:02.968 --> 00:59:05.763
Fände ich natürlich super, wenn der eine oder andere sich denkt,

00:59:05.763 --> 00:59:10.422
ja, das nehme ich her, um Rust vielleicht auch zu lernen, wenn ich das eh lernen will.

00:59:11.052 --> 00:59:18.203
Und ich bin auch jemand, der jetzt nicht unfreundlich ist, wenn jemand sagt, ich hab's jetzt nicht ganz perfekt hinbekommen,

00:59:18.203 --> 00:59:19.037
kannst du mir helfen?

00:59:19.478 --> 00:59:23.628
Also, das ist, glaube ich, auch ein gutes Projekt, an dem man sich ein bisschen üben kann.

00:59:24.303 --> 00:59:28.043
Und wenn man da jetzt ein bisschen tiefer einsteigen will, vielleicht eine Netzwerkprogrammierung

00:59:28.043 --> 00:59:31.883
oder asynchrone Abarbeitung, dann finde ich das spannend.

00:59:32.081 --> 00:59:35.619
Ja, auch wenn Link-Checking an sich jetzt vielleicht nicht das Megaspannendste ist.

00:59:35.745 --> 00:59:42.605
Äh, die Vanessa, äh, find's auch gut, aber nicht jeder musste so tief einsteigen wie wir jetzt

00:59:42.776 --> 00:59:45.008
in das Thema, um da beitragen zu können.

00:59:45.513 --> 00:59:48.803
Ja. Na ja, gut, aber man braucht ja auch immer irgendwelche Aufhänger,

00:59:48.863 --> 00:59:52.012
um bestimmten Problemfeldern überhaupt erst mal zu begegnen, ne?

00:59:52.263 --> 00:59:58.881
Also ohne Link-Checker wirst du wahrscheinlich nie so in diese Welten abgetaucht.

00:59:59.115 --> 01:00:02.003
Genau, und das vielleicht da auch noch als kleiner Tipp.

01:00:02.833 --> 01:00:08.405
Wenn jemand nicht weiß, was er für ein Open-Source-Projekt oder Side-Project machen will,

01:00:08.720 --> 01:00:15.023
Sucht euch die einfachste Aufgabe aus, die ihr euch vorstellen könnt. Das allereinfachste überhaupt.

01:00:16.066 --> 01:00:25.583
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,

01:00:25.583 --> 01:00:29.143
wertvolle Tools bauen.

01:00:28.715 --> 01:00:32.564
Da so ein bisschen funktionieren diese Code-Cutters auch so,

01:00:32.564 --> 01:00:38.564
dass du quasi guckst, wie müsste es eigentlich bilderbuchmäßig laufen.

01:00:38.564 --> 01:00:44.564
Und dann hatten wir auch mal den Wolfram Kiesing, der solche Cutters veranstaltet.

01:00:44.564 --> 01:00:48.564
Da wird dann, glaube ich, die Speck erst mal gelesen.

01:00:48.970 --> 01:00:53.564
Und dann merkt man, solche Charakter können da auch noch vorkommen drin.

01:00:53.564 --> 01:00:57.564
Und dann müssen die ja auch korrekt verarbeitet werden.

01:00:57.792 --> 01:01:09.364
Und danach baut man quasi, versucht man eben eine Implementierung davon nach Speck irgendwie zu machen und sich der Korrektheit anzunähern.

01:01:09.364 --> 01:01:12.313
Und das ist wohl nicht so ganz einfach.

01:01:12.655 --> 01:01:16.283
Du warst auch schon da, ne? Waren es da bei den Code-Cutters vom Wolfram, oder?

01:01:16.949 --> 01:01:22.864
Ja, beziehungsweise, ja, da war ich bei einem. Das, was mir aber für immer in Erinnerung geblieben ist,

01:01:22.864 --> 01:01:27.940
ist das Refactoring in 30-Sekunden-Workshop.

01:01:28.462 --> 01:01:29.309
Das war ...

01:01:30.146 --> 01:01:33.644
Halbe Stunde Erfahrung hat mich, glaub ich, für immer verändert,

01:01:33.644 --> 01:01:36.492
wie man Code anfasst und Code verbessert. Mhm.

01:01:37.150 --> 01:01:42.623
Ich hab mich grad nebenbei gefragt, gibt's URLs mit Emojis? Klar, ja.

01:01:43.496 --> 01:01:50.392
Freilich. Es gibt Emoji-URLs. Jaja, diese ganz berühmten sind die .ws-Domains.

01:01:51.572 --> 01:01:59.322
Das ist nicht auf jeder tl die erlaubt aber auf manchen haben sie das nicht explizit ausgeschlossen und manche haben dann einfach.

01:01:59.584 --> 01:02:06.065
Es geschafft, Emoji-Domains zu registrieren, aber manche Registrars haben das dann auch wieder beendet,

01:02:06.224 --> 01:02:11.424
weil das halt schon in manchen Ecken dann Probleme verursachen kann.

01:02:11.719 --> 01:02:13.664
Nicht jede Infrastruktur ist dafür ausgelegt.

01:02:15.166 --> 01:02:19.816
Es sind ja Umlaute auch schon ein Riesenproblem in URLs für manche Services.

01:02:19.974 --> 01:02:27.751
Und deswegen wird das ja alles im Endeffekt einfach nochmal vom Browser dann kodiert als ASCII, damit das auch sauber durchgeht überall.

01:02:28.436 --> 01:02:33.816
Aber Emoji-Domains, ja, super, super Sache. Sollte man auch mal einen Testcase damit machen.

01:02:33.816 --> 01:02:39.895
Also wenn einer mal auch Testcases für Link-Checking oder so braucht oder für seine Tools,

01:02:40.310 --> 01:02:45.776
Es gibt relativ coole Seiten. Eine heißt BrokenSSL.com, glaube ich.

01:02:45.776 --> 01:02:47.746
Ja, muss ich mal nachschauen hier.

01:02:47.853 --> 01:02:49.776
Und die andere heißt HTTP-Status.

01:02:50.005 --> 01:02:54.947
Also HTTP-Start.us. Und da sind alle Edge-Cases aufgelistet.

01:02:55.802 --> 01:03:03.391
Ja, muss ich mal nachschauen, wie das Ding heißt hier. BadSSL.com heißt die andere Seite, genau.

01:03:04.454 --> 01:03:18.296
Und da seht ihr alle SSL-Edge-Cases. Litchi kann die alle, aber hat ein bisschen gedauert und der andere ist http start.us

01:03:18.296 --> 01:03:24.896
und der zeigt dir alle Status Codes an, die es gibt und die du eigentlich handeln solltest

01:03:24.896 --> 01:03:26.248
ja und auch noch ein bisschen mehr.

01:03:28.049 --> 01:03:38.896
Dann wäre meine abschließende Frage nur, triffst du dich mit dem Curl-Macher und so

01:03:38.896 --> 01:03:44.196
den fünf anderen weltweiten, ähm, HTTP-Spezies

01:03:44.256 --> 01:03:45.756
auf irgendwelchen Konferenzen

01:03:45.816 --> 01:03:48.403
und dann fachsimpelt ihr über so Zeugs?

01:03:50.956 --> 01:03:56.196
Ich kenn den Daniel Stenberg. Ich war schon auf ein paar Konferenzen, wo er auch war.

01:03:56.280 --> 01:03:58.233
Zum Beispiel auf der FOSDEM.

01:03:59.214 --> 01:04:02.798
Ich hab ihn noch persönlich nicht gesprochen, oder wenn, dann nur ganz kurz.

01:04:03.156 --> 01:04:06.425
Aber ich find, er macht seine Sache richtig gut.

01:04:06.623 --> 01:04:10.196
Auf Wiedersehen, bis zum nächsten Mal, also auch noch mal sehr viel Spaß beim Ablösen.

01:04:08.028 --> 01:04:16.283
Ich würde mir wünschen dass es eine netflix Dokumentation über ihn gibt weil er seit jahren einfach nur curl baut und.

01:04:10.196 --> 01:04:12.232
Und zwar, bis zum nächsten Mal. Bis zum nächsten Mal meine Lieben.

01:04:12.356 --> 01:04:13.976
Bis zum nächsten Mal. Tschüss.

01:04:14.608 --> 01:04:16.535
Am besten bis zum nächsten Mal. Bis zum nächsten Mal. Bis zum nächsten Mal.

01:04:16.877 --> 01:04:21.225
Ich immer wieder anhören muss wie leicht das doch ist und es gibt sogar eine Webseite.

01:04:17.056 --> 01:04:18.916
Bis zum nächsten Mal. Bis zum nächsten Mal. Bis zum nächsten Mal.

01:04:18.916 --> 01:04:20.936
Bis zum nächsten Mal. Bis zum nächsten Mal. Bis zum nächsten Mal.

01:04:20.936 --> 01:04:21.225
Bis zum nächsten Mal. Bis zum nächsten Mal.

01:04:21.873 --> 01:04:29.453
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.

01:04:22.629 --> 01:04:23.436
Bis zum nächsten Mal. Bis zum nächsten Mal. Bis zum nächsten Mal.

01:04:23.436 --> 01:04:24.916
Bis zum nächsten Mal. Bis zum nächsten Mal. Bis zum nächsten Mal.

01:04:24.916 --> 01:04:26.416
Bis zum nächsten Mal. Bis zum nächsten Mal. Bis zum nächsten Mal.

01:04:26.416 --> 01:04:27.916
Bis zum nächsten Mal. Bis zum nächsten Mal. Bis zum nächsten Mal.

01:04:30.137 --> 01:04:47.269
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.

01:04:47.917 --> 01:04:49.938
Und ja, ich würde ihn supergerne mal treffen.

01:04:50.032 --> 01:04:54.183
Er wohnt ja in Schweden. Und vielleicht fahr ich da wirklich mal hoch,

01:04:54.258 --> 01:04:55.632
schreib ihm mal eine E-Mail.

01:04:55.798 --> 01:05:01.198
Er hatte auch bei Trivago, glaub ich, schon mal fast einen Vortrag gegeben oder so.

01:05:01.258 --> 01:05:02.898
Und dann hat's nicht geklappt.

01:05:02.958 --> 01:05:07.238
Aber er ist auf jeden Fall jemand, der auch sehr interessiert an der Community ist

01:05:07.298 --> 01:05:10.144
und auch gerne mal vorbeikommt, wenn's irgendwie klappt.

01:05:10.298 --> 01:05:14.996
Und das find ich einfach supergut. Es bräuchten mehr Leute wie ihn oder auch Linus Torvalds,

01:05:15.617 --> 01:05:20.118
ihr leben lang nichts anders tun als das und die disziplin haben ja.

01:05:21.000 --> 01:05:27.401
Und litschi ist natürlich genau auf derselben ebene wie diese zwei projekte curl und linux also.

01:05:28.130 --> 01:05:34.999
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.

01:05:35.170 --> 01:05:42.273
Er vielleicht so eine Rehabilitationsanstalt oder so, so ein Hospital.

01:05:42.444 --> 01:05:47.836
Da fallen mir doch gleich mehrere Personen ein, die da gerne auch dann hingehen würden.

01:05:48.502 --> 01:05:49.726
Wahrscheinlich, ja.

01:05:50.870 --> 01:05:57.700
Ja, aber cool. Also, äh, waren, äh, spannendes Thema, das du heute mitgebracht hast.

01:05:57.740 --> 01:06:04.121
Also, so schön nerdig, nix mit Frontend, aber letztlich ja auch nichts wirklich mit Backend.

01:06:04.337 --> 01:06:07.173
Also, es ist einfach so, ist ja quasi eher so ein ...

01:06:07.776 --> 01:06:10.135
Einfach nur End. Einfach nur End an alle, ne? Ja, nur End.

01:06:11.020 --> 01:06:16.980
Ja. Das ist ... Ja. Ja, da kommen wir halt alle nicht, alle nicht drumrum.

01:06:17.020 --> 01:06:20.397
Zumindest, wenn wir im Web sind, um diese Themen.

01:06:23.062 --> 01:06:26.820
Fand ich auch super spannend, das mal vielleicht auch in der Tiefe

01:06:26.820 --> 01:06:28.820
erklären zu können, auch wenn vielleicht der ein oder

01:06:28.820 --> 01:06:30.820
andere das jetzt nicht auf dem Schirm hatte.

01:06:31.389 --> 01:06:34.820
Generell ist es natürlich auch super spannend, wenn man ein Projekt baut, was

01:06:34.820 --> 01:06:36.673
Leute benutzen, weil man dann

01:06:36.820 --> 01:06:42.820
in interessante Probleme auch reinläuft, wie zum Beispiel Packaging von so einem kleinen Service. Also Litchi

01:06:42.820 --> 01:06:50.820
gibt's jetzt für Homebrew, NixOS, Arc, 3BSD, es gibt's für Windows, Chocolattie und Winget.

01:06:50.951 --> 01:06:53.320
Da gibt's zum Beispiel auch nochmal verschiedene Edge Cases dann.

01:06:53.320 --> 01:06:57.820
Also ich kann das einfach jedem empfehlen, das mal auszuprobieren, so ein kleines Tool zu schreiben

01:06:57.820 --> 01:07:01.820
und ein kleines Problem zu lösen, weil dann merkt man einfach,

01:07:01.820 --> 01:07:05.660
okay, man braucht einfach ein bisschen Tooling, ein bisschen Infrastruktur und das macht schon Spaß.

01:07:06.588 --> 01:07:12.574
Man muss jetzt nicht das Leben bestimmen. Ja, es gibt wichtiger Gerüst als Links im Leben.

01:07:13.331 --> 01:07:17.540
Aber immer wieder spannend, wenn man sich so eine kleine Ecke im Internet aussucht, denke ich.

01:07:19.551 --> 01:07:33.234
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.

01:07:34.162 --> 01:07:36.916
Ja cool dann vielen dank.

01:07:37.537 --> 01:07:52.373
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.

01:07:52.652 --> 01:07:57.892
Wenn es in die nächste folge die wir mit dir aufnehmen dann müssen wir deinen tool noch mal auf die alte.

01:07:58.333 --> 01:08:14.159
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.

01:08:14.348 --> 01:08:24.141
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.

01:08:24.214 --> 01:08:42.541
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.

01:08:42.660 --> 01:08:47.350
Ja, weiß nicht, ob heute noch jemand das vorhat, aber… Nee, nee, ich hab nix vor.

01:08:47.781 --> 01:08:55.488
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.

01:08:56.722 --> 01:09:01.381
Ja, und dann kommt halt der Alkohol ins Spiel leider, ne? Und dann hast du halt ein Suchtproblem auch noch zusätzlich, ja?

01:09:01.381 --> 01:09:04.229
Und dann hast du nicht nur ein Linkproblem, sondern auch ein Suchproblem irgendwann.

01:09:04.994 --> 01:09:15.437
Also schaue ich hoffe zu halten die alkoholkurve zum besser programmieren ja ja je tiefer du reinschaust desto desto tiefer schaute sind ich.

01:09:16.076 --> 01:09:24.052
Ich komme ja aus bayern ich kann ja nach zwei mass kann ich ja noch nach hause fahren.

01:09:25.376 --> 01:09:30.759
Ja na bevor wir so falsch abbiegen hier würde ich sagen machen wir lieber den deckel drauf.

01:09:31.677 --> 01:09:41.778
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.

01:09:41.967 --> 01:09:50.276
Und genau dann sind wir nächste Woche wieder am Start und macht's gut bis dann tschüss.

01:09:50.708 --> 01:09:51.563
Tschau.

01:09:52.240 --> 01:10:15.120
Music.