Wie ich ein GitHub-Profil-README erstellt habe, das nicht existieren sollte (es aber tut)

Lesen Sie hier die formellere Geschichte hier
Jede großartige Geschichte beginnt mit einem Problem, und meines war einfach: Mein GitHub-Profil-README war ein komplettes Chaos. Es war lang. Es hatte zu viel Text. Es war überflutet mit Badges – so viele, dass es aussah, als würde ich jede mögliche Internet-Trophäe horten. Hackathons, GitHub-Beiträge, Astro, roadmap.sh – wenn es ein Badge gab, hatte ich es.
Am Anfang dachte ich, das sei in Ordnung. Es zeigte schließlich alles über mich, oder? Aber eines Tages sah ich es an und erkannte:
Das ist nicht stilvoll. Das ist eine überladene Katastrophe.
Ich brauchte etwas Neues. Etwas Sauberes. Etwas Visuell Beeindruckendes. Ich wollte ein Bento-Grid, das die Leute dazu bringt, innezuhalten und es zu bewundern, statt verwirrt daran vorbeizuscrollen. Ein Design, so gut ausgeführt, dass jeder, der es sieht, sofort eines für sich selbst haben möchte.
Das war der Traum. Jetzt musste ich ihn nur noch verwirklichen.
Der erste Schritt war einfach: mein perfektes Profil in HTML und CSS entwerfen. Und lassen Sie mich sagen, es sah fantastisch aus. Es hatte das perfekte Layout, geschmeidige Animationen und genau das richtige Gleichgewicht zwischen Inhalt und Raum. Dann traf mich die Realität. Das musste innerhalb von GitHub-flavored Markdown funktionieren. Kein Problem, oder? Markdown unterstützt HTML! Also kopierte ich mein wunderschönes HTML in mein README und klickte auf Speichern.
GitHub: Auf keinen Fall.
Markdown von GitHub entfernt nicht eine riesige Anzahl von HTML-Tags, aber wichtige. Natürlich aus Sicherheitsgründen (und ich respektiere das völlig, GitHub, wirklich ❤️), aber das bedeutete, dass mein perfektes Design völlig unbrauchbar war.
Ich versuchte, daran zu feilen. Nicht unterstützte Tags mit solchen zu ersetzen, die funktionierten. Vielleicht könnte ich einige davon retten? Nein. Die Beschränkungen von Markdown machten mein Traumlayout unmöglich.
Wenn man zweifelt, automatisiere. Wenn ich mein HTML nicht direkt einfügen konnte, konnte ich vielleicht etwas Dynamisches mit einem Skript generieren? Also bastelte ich ein Python-Skript, das mein neuestes GitHub-Repository abruft und in mein README einfügt. Ich lasse nur diese zufälligen Bytes hier, die von einigen als Python-Code bezeichnet werden:
22 ausgeblendete Zeilen
import requests
github_username = "yourusername"repos_url = f"https://api.github.com/users/{github_username}/repos?sort=pushed"
response = requests.get(repos_url)repos = response.json()
latest_repo = repos[0]["name"] if repos else "No repositories found."
with open("README.md", "r") as file: readme_content = file.readlines()
new_content = []for line in readme_content: if "<!--LATEST_REPO-->" in line: new_content.append(f"- Latest Repo: [{latest_repo}](https://github.com/{github_username}/{latest_repo})\n") else: new_content.append(line)
with open("README.md", "w") as file: file.writelines(new_content)
Das schien ein Schritt in die richtige Richtung zu sein. Es war automatisiert. Es war funktional. Aber das löste mein eigentliches Problem nicht. 😢
Es ging nicht um dynamischen Inhalt – es ging um Design. Und keine Menge an Python-Skripten würde Markdown schön machen.
An diesem Punkt war ich verzweifelt. Ich erwog das Unvorstellbare: einfach einen Screenshot des HTMLs machen und ihn als Bild in mein README einfügen. Es war ein Ansatz mit Gewalt. Es war faul. Es war… effektiv?
Für einen Moment dachte ich tatsächlich darüber nach, es zu tun. Aber ich wusste tief im Inneren, dass ich mir selbst niemals vergeben würde, wenn ich dies als meine endgültige Lösung akzeptieren würde.
Nur der Vollständigkeit halber: Ich hätte Puppeteer und FFmpeg verwendet – keine Ahnung, was diese Tools sind.
Ich gab den verfluchten Screenshot-Plan auf und suchte nach etwas Flexiblerem.
SVGs.
SVGs konnten skalieren, sie unterstützten sowohl Text als auch Bilder, und – am wichtigsten – sie konnten HTML in ihnen einbetten.
Also versuchte ich etwas wie das hier:
<svg width="800" height="400" xmlns="http://www.w3.org/2000/svg"> <foreignObject width="100%" height="100%"> <body xmlns="http://www.w3.org/1999/xhtml"> <h1>Hello from HTML inside SVG!</h1> </body> </foreignObject></svg>
Vielversprechend! Das könnte tatsächlich funktionieren!
Dann wurde ich mit anderen Dingen beschäftigt, vergaß, den Fehler zu beheben, und kehrte nie zu dieser Idee zurück.
Als ich zum Projekt zurückkehrte, war ich entschlossen, es zum Laufen zu bringen.
Mir wurde klar, dass, wenn ich HTML nicht direkt in Markdown einbetten konnte, ich es vortäuschen könnte, indem ich verschachtelte SVGs benutze. (Übrigens ist dies massiv vereinfacht; der eigentliche Prozess dauerte Tage, die sich wie Wochen oder sogar Monate anfühlten, aber ich weiß, dass ihr das sowieso nicht alles lesen würdet, also egal.)
Und dann, nach stundenlanger Recherche, stieß ich auf eine lebensverändernde Stack Overflow-Antwort:
https://stackoverflow.com/a/65049620/22573601
Das führte mich zur aktuellen Lösung:
- Mein HTML-Layout in SVG umwandeln.
- Alle Bilder in Base64 codieren (da GitHub Markdown externe Bilder in einem SVG mit HTML darin nicht lädt).
- Dynamische SVGs inline einfügen (wie meine GitHub-Statistiken, Spotify-Status usw.).
- Alles mit GitHub Actions automatisieren.
- Ein elegantes Bento-Grid-Layout, perfekt in SVG strukturiert.
- Ein Live-aktualisierender Spotify-Status, als SVG eingebettet.
- GitHub-Statistiken, dynamisch per Automatisierung eingefügt.
- Vollständig responsiv, vollständig skalierbar und vollständig wahnsinnig, es zu bauen.
Es aktualisiert sich alle 5 Minuten, läuft vollständig auf GitHub Actions und ist nicht auf externe Dienste angewiesen. Es ist wunderschön. Es ist effizient. Und vor allem ist es technisch absurd – im besten Sinne.
Sehen Sie sich ein konkretes Beispiel aus der Vergangenheit für die Endergebnisse an.
Das ist im Vergleich zum alten README.md gar nicht so schlecht. Und kommentieren Sie nicht, warum ich K-Pop höre! Es ist besser, als Sie denken, glauben Sie mir.
Schauen Sie sich die Live-Version auf meinem GitHub an trueberryless – falls ich sie behalten habe… – und lassen Sie ein Follow da, wenn Sie schon dort sind, falls Ihnen das Lesen gefallen hat! ❤️
Absolut.
Diese Reise war frustrierend, zeitaufwändig und voller mehr Hindernisse, als ich jemals erwartet hätte. Aber ich habe so viel über SVGs, Markdown-Beschränkungen, GitHub Actions und Automatisierung gelernt.
Würde ich es wieder tun? Definitiv.
Würde ich es empfehlen? Nur wenn Sie viel Geduld haben. 😅
Aber am Ende habe ich ein GitHub-Profil-README erstellt, das nicht existieren sollte — aber es tut es. Und ich liebe es.