möchte­gern­geek

Ostern ist ein Feiertag, dessen Zeitpunkt mit einer Regel festgelegt wird, die unnötig kompliziert scheint. Der erste Sonntag nach dem ersten Vollmond im Frühling. Den meisten bleibt da als Lösung nicht viel mehr übrig als in einem Kalender nachzusehen welches Datum es denn wohl ist und sich auf den Kalenderhersteller zu verlassen. Aber nicht mit mir! Ich werde es Big-Calendar zeigen und hier die geheime Formel veröffentlichen, mit der man das Osterdatum berechnet!

from datetime import date

def easter(year: int) -> date:
    y = year
    g = y % 19 + 1                    # golden number
    c = y // 100 + 1                  # century
    x = (3 * c) // 4 - 12             # correction: dropped leap years
    z = (8 * c + 5) // 25 - 5         # correction: synchronize with moon's orbit
    d = (5 * y) // 4 - x - 10         # find sunday
    e = (11 * g + 20 + z - x) % 30    # epact
    if e == 25 and g > 11 or e == 24:
        e += 1
    n = 44 - e                        # full moon in march
    if n < 21:
        n += 30
    n = n + 7 - (d + n) % 7           # advance to next sunday
    month, day = (4, n - 31) if n > 31 else (3, n)

    return date(year, month, day)

Mir persönlich gefällt besonders gut, dass jede Zeile schlimmer ist als die vorherige.

Dieser Algorithmus ist übrigens von Lilius und Clavius Ende des 16. Jahrunderts entwickelt worden. Ich bin durch eine Erwähnung in einer Übungsaufgabe in Donald Knuths The Art of Computer Programming 1 (Third edition, S. 159f) darauf gestoßen.

Wir alle kennen die Situation: Eine neue Idee, mit der wir unser bestehendes Projekt mit dem Namen alt erweitern, sodass wir sogleich im zugehörigen Repository ein Unterverzeichnis neueIdee anlegen. Die Idee stellt sich dann als so gut heraus, dass sie auch außerhalb des Projektes alt nützlich wäre. Es wäre also sehr sinnvoll ein neues Repository neu anzulegen, das nur den Inhalt des Unterverzeichnisses neueIdee enthalten soll. Tatsächlich scheint dieses Problem wohl so oft vorzukommen, dass es seit 2012 ein extra git Subcommand für diesen Zweck (und etwas kompliziertere Fälle) gibt: git subtree

Neues Repository aus einem Unterverzeichnis

alt/
├─ neueIdee/
│  ├─ lib.rs
├─ main.rs

Wir wechseln also in das Repository alt führen dort folgendes Kommando aus:

git subtree split --prefix=neueIdee/ --branch=nurNeueIdeeBranch

Dies erzeugt in diesem Repository zunächst einen neuen Branch nurNeueIdeeBranch, der nur den Inhalt von neueIdee hat — also ein anderes Wurzelverzeichnis. Dieser Branch enthält also eine neu geschriebene History, die nur aus Commits besteht, die (auch) Einfluss auf Dateien unterhalb von neueIdee hatten.

Nun können wir unser neues Repository neu anlegen und den soeben erzeugten Branch pullen.

cd .. ; mkdir neu ; cd neu
git init
git pull ../alt nurNeueIdeeBranch

Und schon haben wir ein neues Repository, das nur den gewünschten Inhalt hat.

alt/
├─ main.rs
neu/
├─ lib.rs

Möglicherweise wollen wir noch einen Commit im alten Repository tätigen, der das neueIdee Unterverzeichnis löscht. Möglicherweise müssen wir im neuen Repository noch Änderungen am Infrastrukturcode vornehmen.

Verschieben eines Unterverzeichnisses in ein bestehendes Repository

Womöglich fällt uns aber auch auf, dass der Code besser in ein anderes Repository statt eines Neuen passt? Vielleicht weil wir gerade dabei sind unseren Code in einem Monorepo zu sammeln? Auch kein Problem!

alt/
├─ neueIdee/
│  ├─ lib.rs
├─ main.rs
monorepo/
├─ project1/
├─ project2/

Wir haben oben bereits den nurNeueIdeeBranch erstellt, den wir nun in das Unterverzeichnis guteIdeedes Repositorys monorepo einfügen wollen. Auch hier hilft uns wieder git subtree weiter:

cd monorepo
git branch mitGuterIdeeBranch
git checkout mitGuterIdeeBranch
git subtree add --prefix=guteIdee/ ../alt nurNeueIdeeBranch

Sobald wir uns in dem neuen Branch mitGuterIdeeBranch überzeugt haben, dass alles zu unserer Zufriedenheit geklappt hat und wir möglicherweise noch Infrastrukturcode angepasst haben, können wir den Branch nach main mergen und sind fertig.

alt/
├─ neueIdee/
│  ├─ lib.rs
├─ main.rs
monorepo/
├─ project1/
├─ project2/
├─ guteIdee/
│  ├─ lib.rs

Fira ist eine humanist Sans-Serif Schriftart, die für FirefoxOS entwickelt wurde, und wird zur Zeit für die Sans-Serif Typen, wie die Überschriften, in diesem Blog genutzt. Aber eigentlich geht es mir hier um Fira Mono die dicktengleiche Variante, die später mit Ligaturen (und mehr) zu Fira Code erweitert wurde. Ich sehe wie in genau diesem Moment im Geist des Lesers die Frage „Ligaturen in einer dicktengleichen Schrift?!“ auftaucht. Beziehungsweise „Ist da ein Tippfehler in dickengleich?“ oder „Was sind Ligaturen?“ falls der Leser kein Hobby-Typographie-Nerd ist.

Für letztere klären wir erstmal kurz die beiden Fragen:

Die Dickte bezeichnet die Breite der Metall-Lettern im klassischen Buchdruck; wenn sie für alle Glyphen gleich ist, stehen die Buchstaben immer in perfekt ausgerichteten Spalten untereinander, was von vielen für das Schreiben von Code bevorzugt wird. Die meisten Schreibmaschinen haben ebenfalls solche Schrifttypen verwendet.

Ligaturen sind Kontraktionen von mehreren Glyphen in eine Glyphe. Die typischen Ligaturen sind fi oder fl (allerdings nicht in der Schriftart, in der diese Zeilen geschrieben sind, weshalb ich hier ein Bild der fi Ligatur in Computer Modern zeige). Ein paar Ligaturen haben sich mittlerweile zu eigenen Symbolen entwickelt, wie das Kaufmannsund &, das ursprünglich eine Ligatur von et war (Latein für und). Aber dieses Konzept beißt sich anscheinend mit einer dicktengleichen Schrift, in der jeder Buchstabe die gleiche Breite haben soll. Der Clou an der Sache ist, dass Fira Code Ligaturen für übliche Ausdrücke für mathematische Symbole in Programmiersprachen wie >=, != und -> hat, die wie folgt dargestellt werden: >=, !=, ->. Nur zu, kopiert diese Symbole in einen Editor eurer Wahl, um zu sehen, wie sie sich wieder in ihre Bestandteile zerlegen

Nur eine Spielerei? Möglicherweise. Aber ich bin begeistert davon, und verwende Fira Code in allen Editoren, die Ligaturen unterstützen. Der Fairness halber sollte gesagt werden, dass Fira Code nicht als erstes Projekt diese Idee hatte. Hasklig beispielsweise hatte ihr erstes Release 2 Jahre vor der Veröffentlichung von Fira Code im Jahr 2014. Und mittlerweile sind Code-Ligaturen so ziemlich im Mainstream angekommen, seitdem JetBrains Mono im letzten Jahr von dem gleichnamigen IDE-Entwickler veröffentlicht wurde.

Zum Schluss möchte ich noch auf eine Kleinigkeit aufmerksam machen, die wohl nur die wenigsten Nutzer von Fira Code bewusst bemerken würden, die aber zweifellos demonstriert wie durchdacht diese Schrift ist. Denn Fira Code passt die Position von arithmetischen Symbolen an die benachbarten Glyphen an: ein + zwischen zwei Großbuchstaben ist höher als eines zwischen zwei Kleinbuchstaben.

Ich persönlich weiß solche Details sehr wertzuschätzen. Es ist ein Beispiel dafür, dass alle Aspekte unserer modernen Gesellschaft, so wenige Gedanken wir uns auch darum machen und für wie trivial wir sie halten, zahllose Stunden Design und Entwicklung gekostet haben und ständig verbessert werden. Typographie — und um das klarzustellen, ich bin beileibe kein Experte — fasziniert mich. Schriften sind exakt, mit klar definierter Funktion, aber obwohl wir sie seit Jahrtausenden benutzen, ist ihre Entwicklung noch lange nicht abgeschlossen. Mit jedem neuen Medium gibt es neue Anforderungen. Marken haben steten Bedarf an individuellen Schrifttypen als Teil ihres Brandings. Für jede neue Anwendung gibt es andere Optimierungskriterien.

Und jedes Mal wenn in meinem Code = und > wieder zu => verschmelzen, freue ich mich erneut über die Magie.