Vorgeschlagener Eintrag

rsnake

In meinem letzten Einträgen ist bereits angeklungen, dass ich Rust mag. Und wie die Erfahrung [1, 2, 3] zeigt, dauert es nie lange bis ich eine Snake-Abwandlung programmiere.

Dieses Mal verfolgt der Autopilot die Strategie des smart kinetic walk, (ein Model aus der statistischen Physik zur Simulation von Polymeren,) um sich nicht selbst zu beißen — leider setzt diese Strategie ein unendlich großes Spielfeld voraus.

Die grundlegende Idee ist, dass die Schlange immer wenn sie sich selbst begegnet prüft welcher nächste Schritt sie in einer Schlaufe fängt und welcher nach außen führt. Mit offenen Randbedingungen, also auf einem unendlich großem Feld lässt sich dass das in konstanter Zeit erledigen, wenn die Schlange an jedem Segment ihres Körpers die Anzahl der Rechts- und Linksdrehungen speichert. Bei periodischen Randbedingungen funktioniert das allerdings nicht mehr, sodass der Autopilot eine Best-First-Search durchführt. Auf offenen Randbedingungen würde es ausreichen einen Weg vom potentiell nächstem Schritt zu einem beliebigen Punkt außerhalb eines Rechtecks, das die Schlange einschließt, zu finden. Bei periodischen Randbedingungen ist es nicht so eindeutig. Ich habe mich entschlossen, dass die Schlange sich nur so bewegen soll, dass immer ein Pfad zu ihrem Schwanz existiert. Tatsächlich führt diese Strategie zu unterhaltsamen und nicht perfekten Spielverläufen.

Der Vollständigkeit halber sind noch ein nicht vorausplanender und ein perfekter, aber langweiliger, Autopilot dabei.

Da die Quellen auf GitHub liegen, ist es nur vier Zeilen entfernt — weniger, wenn der Rustcompiler bereits installiert ist.

    # curl https://sh.rustup.rs -sSf | sh  # never copy `| sh` in your terminal
    git clone https://github.com/surt91/rsnake
    cd rsnake
    cargo run --release

Neuste Einträge

Progressive Web App

Seit Anfang September ist dieses Blog eine Progressive Web App. Das bedeutet, dass dieses Blog nun auch offline funktioniert und man es auf dem Smartphone als App hinzufügen kann.

Warum? Lighthouse

Nun, Chrome bietet mit Lighthouse Ratschläge, wie man seine Website verbessern kann. Einer der vier Unterpunkte heißt Progressive Web App und war frustrierend schlecht bewertet. Die folgenden Schritte habe ich also nur für Lighthouse gemacht und es hat sich auf jeden Fall gelohnt:

Lighthouse-Audit Ergebnisse

Wie?

Lighthouse bietet eine Checkliste, auf der neben einigen Punkten, die generell eine gute Idee sind, drei Punkte aufgeführt sind, die erfüllt sein müssen:

  • Site is served over HTTPS
    • Dank Let’s Encrypt ist das kein Problem mehr.
  • The start URL (at least) loads while offline
    • Das ist der aufwendigste Teil. Um dies zu erreichen muss man einen service worker registrieren. Damit der service worker weiß, welche Dateien notwendig sind, benutze ich nach jedem erfolgreichen Build sw-precache mit einer sehr einfachen Konfiguration. Dadurch benötige ich jetzt Node, um das Blog zu erstellen ¯\_(ツ)_/¯
  • Metadata provided for Add to Home screen
    • Damit ist eine manifest.json gemeint. Diese Datei enthält links zu Icons, die als Appsymbol benutzt werden, wenn man die Seite auf Android oder Windows installiert. Und es legt die Farbe der Adressleiste im mobilen Chrome fest. Ein nützlicher Dienst, um ein solches Manifest zu erstellen, ist auf app-manifest.firebaseapp.com

Was jetzt?

Service Worker ermöglichen Benachrichtigungen von einer Website. Ein natürlicher nächster Schritt wäre es also Benachrichtigungen zu versenden, wenn ein neuer Post online ist. Auf der anderen Seite bin ich selbst immer etwas genervt von Websites, die mich benachrichtigen wollen und der Lighthouse Punktestand ist schon optimal, also wird das wohl nicht passieren.

Push to Publish 2

Nachdem ich vor Kurzem einen euphorischen Eintrag über mein automatisiertes Update dieses Blogs via Travis-CI und GitHub pages geschrieben habe, bin ich jetzt auf eine einfachere Lösung gestoßen.

Alles unter einem Dach bei Netlify Netlify Logo

Es gibt einen einfachen Buildservice, der zwar nicht so flexibel ist wie Travis-CI, aber für dieses Blog ausreicht. Netlify baut die Seite also bei jedem Push in ein beobachtetes GitHub Repository. Nach Konfiguration des DNS und einem weiteren Knopfdruck ist die Seite mit einem SSL Zertifikat von Let’s Encrypt ausgestattet und erreichbar. Also Bonus kann man selbst HTTP-Header bestimmen über eine _headers Datei:

/*
    Strict-Transport-Security: max-age=31536000; includeSubDomains

Also kann man HTTP/2 Server Push ausprobieren, ohne einen Server betreiben zu müssen.