Zum Inhalt springen

Wie ich ein GitHub-Profil-README erstellt habe, das es eigentlich nicht geben sollte (aber es gibt es)

Diese Übersetzung wurde von einer generativen KI mithilfe von Action Continuous Translation erstellt. →

A beautiful cover image with the text "GitHub Profile"

Der Anfang: Ein README, das wie ein Wikipedia-Dump aussah

Jede großartige Geschichte beginnt mit einem Problem, und meines war einfach: Mein trueberrylessGitHub-Profil README war ein komplettes Chaos. Es war lang. Es hatte zu viel Text. Es war überfüllt mit Abzeichen — 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 Abzeichen gab, hatte ich es.

Am Anfang dachte ich, das wäre in Ordnung. Es zeigte schließlich alles über mich, oder? Aber eines Tages sah ich es an und stellte fest:

Das ist nicht stilvoll. Das ist ein überladenes Desaster.

Ich brauchte etwas Neues. Etwas Sauberes. Etwas Visuell Beeindruckendes. Ich wollte ein Bento-Grid, das die Leute dazu bringt, stehen zu bleiben und es zu bewundern, anstatt verwirrt daran vorbeizuscrollen. Ein Design, das so gut ausgeführt ist, dass jeder, der es sieht, sofort eines für sich haben wollte.

Das war der Traum. Jetzt musste ich ihn nur noch realisieren.

Phase 1: Der HTML-Traum (und Markdown-Albtraum)

Der erste Schritt war einfach: Entwerfen meines perfekten Profils in HTML und CSS. Und ich kann dir sagen, es sah unglaublich aus. Es hatte das perfekte Layout, sanfte Animationen und genau das richtige Gleichgewicht zwischen Inhalt und Raum. Dann kam die Realität. Dies 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 drückte Speichern.

githubGitHub: Absolut nicht.

Die GitHub-Markdown entfernt nicht eine riesige Anzahl von HTML-Tags, aber wichtige. Aus Sicherheitsgründen natürlich (und das respektiere ich vollkommen, GitHub, wirklich ❤️), aber das bedeutete, dass mein perfektes Design komplett unbrauchbar war.

Ich habe versucht, es anzupassen. Nicht unterstützte Tags durch funktionierende zu ersetzen. Vielleicht konnte ich etwas retten? Nein. Die Einschränkungen von Markdown machten mein Traum-Layout unmöglich.

Phase 2: Der “Einfach Ein Python-Skript Benutzen”-Kompromiss

Wenn du dir unsicher bist, automatisiere es. Wenn ich mein HTML nicht direkt einfügen konnte, vielleicht konnte ich etwas Dynamisches mit einem Skript generieren? Also habe ich ein Python-Skript zusammengestellt, um mein neuestes GitHub-Repository abzurufen und in mein README einzufügen. Ich lasse hier einfach ein paar zufällige Bytes, die einige als Python-Code bezeichnen könnten:

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 funktionierte. Aber es löste nicht mein eigentliches Problem. 😢

Es ging nicht um dynamischen Inhalt — es ging um Design. Und keine Menge Python-Scripting würde Markdown schön aussehen lassen.

Phase 3: “Na Gut, Ich Nehme Einfach Einen Screenshot” (Tiefpunkt)

Zu diesem Zeitpunkt war ich verzweifelt. Ich dachte an das Undenkbare: Einfach einen Screenshot vom HTML machen und ihn als Bild in mein README einfügen. Es war ein brutaler Ansatz. Es war faul. Es war… effektiv?

Einen Moment lang dachte ich tatsächlich darüber nach, es zu tun. Aber tief im Inneren wusste ich, dass ich mir nie verzeihen würde, wenn ich das als endgültige Lösung akzeptieren würde.

Zur Referenz hätte ich Puppeteer und FFmpeg verwendet — keine Ahnung, was diese Tools sind.

Phase 4: SVGs treten auf den Plan (Das Licht am Ende des Tunnels)

Ich ließ den verfluchten Screenshot-Plan fallen und suchte nach etwas Flexiblerem.

SVGs.

SVGs konnten skalieren, sie unterstützten sowohl Text als auch Bilder, und — was am wichtigsten war — sie konnten HTML innerhalb von ihnen einbetten.

Also versuchte ich etwas wie das:

<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ß, es zu debuggen, und kehrte nie zu dieser Idee zurück.

Eine gute Idee wegwerfen

Phase 5: SVGs in SVGs in SVGs (Inception-Stufe 100)

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 einfügen konnte, ich es vortäuschen konnte, indem ich verschachtelte SVGs verwendete. (Übrigens ist dies stark vereinfacht; der tatsächliche Prozess dauerte Tage, die sich wie Wochen, wenn nicht Monate anfühlten, aber ich weiß, dass ihr das sowieso nicht alles lesen würdet, also wen interessiert’s?)

Und dann, nach Stunden der Recherche, stieß ich auf eine lebensverändernde Stack Overflow-Antwort:

https://stackoverflow.com/a/65049620/22573601

Das führte mich zur aktuellen Lösung:

  1. Mein HTML-Layout nach SVG konvertieren.
  2. Alle Bilder in Base64 kodieren (da GitHub Markdown keine externen Bilder innerhalb eines SVG mit HTML lädt).
  3. Dynamische SVGs einbetten (wie meine GitHub-Statistiken, Spotify-Status usw.).
  4. Alles mit GitHub Actions automatisieren.

Das große Finale: Das ultimative GitHub-Profil-README

  • Ein schlankes Bento-Grid-Layout, perfekt in SVG strukturiert.
  • Ein live-aktualisierender Spotify-Status, in SVG eingebettet.
  • GitHub-Statistiken, dynamisch über Automatisierung eingefügt.
  • Vollständig responsiv, vollständig skalierbar und vollkommen verrückt zu erstellen.

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.

Schauen Sie sich ein konkretes Beispiel der Endergebnisse irgendwann in der Vergangenheit an.

Final result

Ist das nicht schlecht im Vergleich zum alten README.md. Und kommentier bitte nicht, warum ich K-Pop höre! Es ist besser, als du denkst, glaub mir.

Sieh dir die Live-Version auf meinem GitHub trueberrylesstrueberryless an — falls ich beschlossen habe, sie zu behalten… — und folge mir, wenn du schon da bist, falls dir das Lesen gefallen hat! ❤️


Abschließende Gedanken: War es das wert?

Absolut.

Diese Reise war frustrierend, zeitaufwendig und voller Hindernisse, mit denen ich nie gerechnet hätte. Aber ich habe so viel über SVGs, die Einschränkungen von Markdown, GitHub Actions und Automatisierung gelernt.

Würde ich es wieder tun? Definitiv.

Würde ich es empfehlen? Nur, wenn du eine Menge Geduld hast. 😅

Aber am Ende habe ich ein githubGitHub-Profil-README erstellt, das eigentlich nicht existieren sollte — aber es existiert. Und ich liebe es.