Seit ein paar Wochen unterstützt der mobile Safari nun ja auch Push Notifications. Natürlich musste ich das direkt mal ausprobieren und natürlich klappte es nicht sofort, daher hier nochmal kurz zusammengefasst, was man braucht:

1. Erstmal braucht man VAPID Keys, das ist einfach nur ein Keypair, das man sich selber generieren kann, da muss man sich nirgendwo für Anmelden, oder so. Ich verlinke mal keine dieser shady Seiten, wo man das in einem Web-Formular machen kann.
2. Einen Service-Worker. Tatsächlich habe ich mich bisher auch immer sehr gut um dieses Thema drücken können. Das ist so ein bisschen JavaScript, das eine Seite registrieren kann und was der Browser im Hintergrund ausführen kann, auch wenn die Seite nicht offen ist. Das ist essentiell, denn der Service-Worker bekommt die Notification vom System übermittelt und muss selbst dafür sorgen, dass und wie sie angezeigt wird. Hier eine Beispielimplementierung.
3. Ein bisschen JavaScript, dass den Service-Worker registriert und die Anmeldung für Push-Notifications übernimmt. Unter iOS ist hier wichtig, dass die Nachfrage nach den Permissions in einem onclick-Handler passiert und nicht direkt beim Öffnen der Seite
4. Ein Backend, das die Endpoints und Tokens speichert, die man vom Browser bekommen hat.
5. Die App muss auf den Homescreen installiert sein und braucht eine manifest.json. Ich nutzte standalone für das display-Feld im Manifest, sonst klappte es nicht, aber kann sein, dass es auch ohne geht.
6. Eine Backend-Komponente um Pushs zu verschicken. Für PHP benutzte ich da die minishlik/web-push Library.

Fertig, damit funktioniert es! Wenn man weiß wie, ist es ganz einfach.

Ich gebe es zu, ich bin Server-Messi. Spätestens seitdem Hetzner mit seinem Cloud-Angebot durchgestartete und man nur so drei Euro für eine CPU und ein bisschen Speicher zahlte, fing ich an für alles mögliche eine neue VM anzulegen. Zuletzt versuchte ich vor etwa einem Jahr dem Chaos Herr zu werden, leider ohne größeren Erfolg. Am Ende hatte ich noch einen Server mehr.

Aktuell sind es ca. 15 und ich zahle dafür um die 50€ im Monat. Denn, wie alles, sind auch die VMs teurer geworden, spätestens seitdem Hetzner für die kostbaren IPv4-Adressen nochmal extra kassiert. Zu recht natürlich. Ich redete es mir immer schön, in dem ich mir sagte, dass es ewig dauern würde, bis sich der Arbeitsaufwand amortisieren wird. Was sind schon gesparte 5€ für einen Server im Monat! Macht man sich die Mühe und multipliziert das mal mit 12 kommt man allerdings schon auf 60€ und das nochmal mit der Anzahl der Server multipliziert, die man abstellen könnte. Plötzlich kommt man auf einen beträchtlichen Betrag, den man sparen könnte. Davon könnte man sich einige Packungen Kippen kaufen, wenn man rauchen würde!

In diesem Post erzähle ich euch nun ein wenig davon, wie ich dieses Projekt angegangen bin, welche Probleme ich hatte und was das Ergebnis ist. Natürlich habe ich währenddessen mal wieder zu wenige Notizen gemacht und schreibe alles schnell in einer Nacht-und-Nebel-Aktion zusammen, daher werden sicher ein paar Sachen fehlen. Vielleicht ergänze ich sie später, wenn sie mir einfallen!

Weiterlesen →

Gestern Abend wollte ich schnell einen Rezepte-Import in meine Re-Implementierung vom Speiseplaner packen. Ich hatte in den letzten Monaten öfter Github-Repositories gesehen, die sowas anbieten. recipe-scrapers sah ziemlich umfassend aus, ist aber leider in Python geschrieben.

Nun hätte ich sicher Python in mein Docker-Image ziehen können, das alles installieren und per exec drauf zugreifen können, doch ich dachte mir, warum machst du das nicht kurz in sauber und baute eine Flask-App darum. Wobei, bauen kann man das nun wirklich nicht nennen, ich änderte ungefähr eine Zeile aus der Hello World-Beispielapp:

from flask import Flask
from flask import request
from recipe_scrapers import scrape_me

app = Flask(__name__)

@app.route("/")
def hello_world():
    url = request.args.get('url', '')
    scraper = scrape_me(url, wild_mode=True)
    return scraper.to_json()

Dazu diese kurze Dockerfile und fertig ist die Rezepte-Scraping-API.

FROM python:3-alpine

WORKDIR /usr/src/app

COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py ./

CMD [ "flask", "--app", "app", "run", "--host=0.0.0.0"]

Jetzt war es ein leichtes, das Import-Feature in den Speiseplaner zu implementieren, quasi nur noch ein API-Aufruf und fertig. Da freut man sich doch, wie leicht mittlerweile vieles geworden ist.

Im Zuge meiner Server-Konsolidierung musste ich mal wieder auch meinen Last.fm-Ersatz mey anfassen, da er sich leider nicht leicht zu SQLite konvertieren ließ. Immerhin sieht es nun auch ein bisschen hübscher aus!

Leider muss ich nochmal ran, denn die damals importierten Daten sind echt etwas… Lückenhaft. Vielleicht aber auch egal, hauptsache es läuft im Docker Container und ist still.

Nur eine kurze Notiz, für alle, die noch ein oder zwei Wordpresse rumfliegen haben, aber keine Lust dazu haben einen MySQL-Server dafür zu betreiben, weil eh fast kein Traffic drauf ist:

Es existiert diese One-File-Lösung auf Github, die man einfach in wp-content ablegt und schon supported Wordpress SQLite. Verrückt. Um einen bestehenden MySQL-Dump so umzubiegen, dass er in SQLite zu importieren geht, kann man dieses Script benutzen.

Das ganze packt man ins Docker-Image und muss sich nie wieder damit auseinandersetzen, hoffentlich.

Gestern warf Markus einen Link zu airgpu in den Raum. Glücklicherweise war auch gerade das Open Beta-Wochenende für Diablo 4, was für eine gute Kombination, um mal wieder Cloud-Gaming auszuprobieren.

Bei airgpu zahlt man, anders als bei Shadow, auf Stundenbasis. Außerdem benutzt man mit Moonlight einen Open Source-Client und nicht dieses proprietäre Zeug von Shadow. Letztendlich scheint es nur ein Wrapper um g4dn.xlarge-Instanzen von AWS zu sein, mit einem Windows Server-Image, auf dem halt ein paar Sachen vorinstalliert sind.

Ich muss sagen, es lief ziemlich gut. Ich hatte eigentlich keinen einzigen Ruckler während der Stunde Spielzeit. Vielleicht lag es daran, dass ich heute mal direkt neben dem Wifi-Accesspoint saß, keine Ahnung.

Diablo 4 war soweit auch okay. Man läuft halt rum und klickt auf Gegner, bis sie tot umfallen. Ich war jetzt nicht so tief involved, denn auf der einen Seite habe ich keine Lust mich in eine Open Beta reinzunerden, wenn ich danach noch Monate auf den Release warten muss und zum Anderen weiß ich noch gar nicht, wie ich die finale Version spielen soll, weil Blizzard es wohl aufgegeben hat, MacOS-Builds herzustellen.

Jedenfalls sehe ich für mich und airgpu auch keine wirkliche Zukunft. Zwar kostet es keine 30€ im Monat wie Shadow, aber Preise zwischen 1€ und 1,50€ pro Stunde und zusätzlich 7€ für 100GB SSD-Speicher im Monat läppern sich auch schnell zusammen. Letztendlich wären das 15 Stunden spielen und man ist wieder beim Shadow-Preis. Nicht, dass ich das jemals schaffen würde, im Monat 15 Stunden zu spielen, aber es spielt sich auf jeden Fall anders, wenn man im Hinterkopf hat, dass jede Stunde bares Geld kostet. Psychologisch anstrengend!

Da airgpu auch nur AWS-Instanzen reselled könnte man ja mal gucken, ob man sich das selber bauen kann und sich damit die Marge spart, aber ich glaube, das bringt nicht so viel. So wie ich das sehe, kostet eine g4dn.xlarge auch um die 70 Cent und da ist ja noch gar kein Datentransfer dabei. 100GB EBS-Volume kosten auch schon fast 10€ bei AWS, ich weiß gar nicht, wie airgpu die für 7€ anbieten kann. Habe mich vielleicht irgendwo verrechnet.

Achso, eine Kleinigkeit noch: Weil ich seit Jahren fast keine Maus mehr benutzt habe und Diablo 3 auch einige Zeit auf der Switch spielte, ist mir die Konsolensteuerung bei dem Spiel eigentlich fast lieber. Leider wird es Diablo 4 wohl nicht für die Switch geben und eine PS5 will ich wirklich auch nicht haben, schade.