onli blogging

Direkt. Das ist wohl Rock mit Chorgesang und Hammondorgel. Irgendwo zwischen Colour Haze und Queen und Pop.

Die Anleitung wie man das nette CSS-Framework Spectre manuell kompilieren und so anpassen kann ist nicht vollständig. Sie besagt:

npm install
gulp build

Nach vorherigem Herunterladen der Quellcodedateien natürlich.

Stattdessen musste ich so vorgehen:

npm install npm-install-peers
npm install

Danach warf npx gulp build aber einen Fehler:

fs.js:27
const { Math, Object } = primordials;
                         ^

ReferenceError: primordials is not defined
    at fs.js:27:26
    at req_ (/home/onli/spectre/node_modules/natives/index.js:143:24)
    at Object.req [as require] (/home/onli/spectre/node_modules/natives/index.js:55:10)
    at Object.<anonymous> (/home/onli/spectre/node_modules/graceful-fs/fs.js:1:37)

Stackoverflow kennt die Antwort: Man muss eine Datei npm-shrinkwrap.json mit folgendem Inhalt anlegen:

{
  "dependencies": {
    "graceful-fs": {
      "version": "4.2.2"
    }
  }
}

Und dann nochmal npm install ausführen.

Also: Gulp wird nicht automatisch vollständig installiert, um es auszuführen bedarf es npx. Die Version die spectre braucht ist aber sowieso inkompatibel mit neueren node-Version (in meinem Fall: 13.2.0). Deswegen der Fix per shrinkwrap-Datei.

Ich hasse die npm-Welt aus vollem Herzen.

Es ist eigentlich Unsinn, Daten wie Zeitreihen in SQLite zu speichern, da Timeseries-Datenbanken noch vor kurzem ein kleines Hype-Thema waren. Es gibt also einige Alternativen. Jedoch fand ich keine zu meinem Projekt passende. Sie alle sind entweder gedacht zur Analyse von Serverevents, benutzen Java, werden nicht mehr gepflegt oder sind zu komplex aufzusetzen. rrdtool kommt einer simplen Lösung noch am nächsten, aber die nötige Vorgabe der Taktung macht es für mich unpassend. Mein Ziel, jahrelange Preishistorien mit jeweils unterschiedlicher Taktung und auch mal einigen Lücken effizient zu speichern ohne einen Kubernetes-Cluster laufen lassen zu müssen scheint außerhalb der Javawelt zu selten zu sein.

Also blieb mein Provisorium bestehen. Eine SQLite-Datenbank mit dieser Tabelle:

CREATE TABLE IF NOT EXISTS priceHistory(
    id TEXT,
    date INTEGER,
    vendor TEXT,
    price REAL
);"

Später kam noch ein Index dazu, weil die Performance ohne zu schlecht war:

CREATE INDEX priceHistory_ean_vendor ON priceHistory(ean, vendor);

Das funktioniert! Es ist sogar trotz steigender Datenmenge auch einige Monate später noch schnell genug.

Diese steigende Datenmenge ist aber doch ein Problem: Mittlerweile ist diese Datenbank schon über 4GB groß, die Hälfte davon ist der Index. Das müsste kein Problem sein, Speicherplatz ist ja billig. Nur stimmt das nicht; nicht relativ zu den Serverkosten eines kleinen Projekts und angesichts möglicher zukünftiger Einschränkungen bei der Serverwahl, wenn die Datenbank weiter wächst. Und unbeschränktes Wachstum mit einer dann immer schwieriger handhabbaren Datenbankdatei bereitet mir Kopfschmerzen. Gut für die Performance kann die Lösung auf Dauer auch nicht sein.

Also durchforstete ich nochmal das Angebot an Zeitreihendatenbank und fand wieder nichts genau passendes. Zeit, einen Schritt zurückzugehen und zu überlegen, ob das nicht in SQLite bleiben und trotzdem etwas optimiert werden kann.

Strategie: Nur speichern was nötig ist

Die Daten dienen nur einem Zweck: Den Preisverlauf von Produkten anzuzeigen. Das sieht zum Beispiel so aus:

Wir zeichnen also im Grunde Strecken, wirklich dynamisch ändern sich die Preise nicht. Für eine Strecke brauche ich aber nicht mehr als zwei Punkte. Im gezeigten Diagramm sind es dagegen viele Punkte für jeden Abschnitt, da sich über eine längeren Zeitraum am Preis genau gar nichts getan hat. Das ist das erste Einsparpotential: Speichere nur, wenn sich der Wert geändert hat.

An der Datenbank muss man dafür nichts ändern. Die Optimierung kann rein im Code beim Abspeichern eines neuen Preises passieren. Trotzdem änderte ich den Index, passend zu den Daten:

CREATE TABLE IF NOT EXISTS priceHistory(
    id TEXT,
    date INTEGER,
    vendor TEXT,
    price REAL,
    UNIQUE(id, url, size)
);"

Unnötige Doppelungen zu verhindern kann nur helfen.

Dann muss die Logik beim Datenzufügen angepasst werden. Vorher war das ein einfaches INSERT. Jetzt sieht der Code in etwa so aus:

def storePrice(id:, price:, vendor:)
    # first we see whether the new entry differs from the last two, because if not we replace the last one. We need only two points to paint a trend line segment
    lastEntries = @db.execute("SELECT rowid, price FROM pmdb.priceHistory WHERE id = ? AND vendor = ? ORDER BY date DESC LIMIT 2", id, vendor)

    if price == lastEntries[0]['price'] && price == lastEntries[1]['price']
        @db.execute("DELETE FROM pmdb.priceHistory WHERE rowid = ?", lastEntries[0]['rowid'])
    end

    # regardless what happened before, now we can just insert
    @db.execute("INSERT INTO pmdb.priceHistory(id, price, vendor, date) VALUES(?, ?, ?, strftime('%s','now'))", id, price, vendor)
end

Ich fand, ein paar Visualisierungen machen das schneller klar.

Die naive Lösung hat einfach alles eingefügt.

Jetzt aber schaut der Code, ob die vorherigen Datenpunkte den gleichen Preis anzeigten. Wenn ja, verlängert er die Strecke, indem der letzte Datenpunkt gelöscht und stattdessen der neue (mit gleichem Preis, aber späterem Zeitpunkt) abgespeichert wird.

Wenn aber der Preis sich geändert hat bleiben die alten Datenpunkte bestehen und der neue kommt hinzu.

Sogar die bestehende Datenbank kann so verkleinert werden. Ich muss nur alle gespeicherten Datenpunkte entnehmen und mit dieser Strategie einzeln in eine neue Datenbanktabelle einfügen. Das Ergebnis behält tatsächlich seine Form, von der nun störenden Linienglättung mal abgesehen:

Und die Datenbank schrumpfte von 4.8GB auf 384MB, sehr ordentlich!

Weitere Kompressionsstrategien

Der nächste Schritt wäre das Bilden von Durchschnittswerten über definierte Zeiträume, Downsampling. Vielleicht kriege ich derzeit, je nach Händler, jede Stunde oder jeden halben Tag einen neuen Preis. Sind zwei Monate vergangen interessiert nur noch, wie teuer das Produkt durchschnittlich an einem Tag war. Nach 6 Monaten reichen die durchschnittlichen Preise in einer Woche. Nach einem Jahr der Durchschnittspreis in einem Monat.

Je nach Art der Zeitreihendaten ist diese Strategie deutlich besser, oder nur unnötig kompliziert. Hängt ganz davon ab wie oft sich die Preise bzw die Zeitreihendatenwerte ändern.

Sie lässt sich mit Code umsetzen, der in regelmäßigen Abständen durch die Datenbank geht und die Daten zusammenfasst. Es wäre toll, wenn es eine kleine Datenbank gäbe, der man solche Daten geben kann und die solche Konsolidierungen automatisch durchführt. Influxdb kann das zum Beispiel (wenn es entsprechend konfiguriert wird), aber ich würde eine Lösung bevorzugen, die nicht als zu wartende Infrastruktur auf einem Port läuft, sondern wie SQLite oder rrdtool einbindbar ist.

Vielleicht gibt es eine passende Datenbank und ich kenne sie nur nicht?

Auf den ersten Blick wirkt dieser Film sehr seltsam. Warum ist da ein offensichtlich animiertes Mädchen in einem Realfilm, noch dazu ein Scifi-Actionfilm, und warum mit diesen künstlichen Riesenaugen? Ist das Disney?

Wer Science-Fiction mag sollte Alita trotzdem eine Chance geben, denn er überrascht. Nach etwas Gewöhnungszeit wirkt sie nicht mehr so seltsam, tatsächlich ist die Figur im Rahmen des Möglichen hervorragend umgesetzt. Vor allem aber versucht der Film so einiges (aber Achtung, Spoiler), um den Zuschauer auf Alitas Seite zu ziehen, was dann auch absolut funktioniert.

Sie ist deplatziert in einer Welt, die nicht die ihre ist. Aber anstatt dort hilflos zu sein hat sie ein paar Überraschungen auf Lager. Es ist ja dann doch – anders als der Trailer suggeriert – ein Actionfilm, kein emotionales Drama. Aber eines, das seine CGI-Figur und die Schauspielerin dahinter ganz anders mischt, als Ghost in the Shell das gemacht hat.

Aber warum nur? Alita ist trotzdem ein guter Film geworden, aber eben: Trotzdem. Ich verstehe diese CGI-Entscheidung nicht. Wenn man sich die Frau anschaut, die das Motion Capturing gemacht hat, sieht sie sogar aus wie Alita. Nur halt echt. Warum dann nicht doch Ghost in the Shell folgen und ein echtes Gesicht nehmen, nur was ein menschlicher Körper nicht kann und nicht ist mit dem Computer erschaffen, anstatt so viele Zuschauer durch den Komplett-CGI-Hauptcharakter zu vergraulen? Denn egal wie gut Alita geworden ist, sie sieht keinen Moment real aus. Und entsprechend ist der Film an den Kinokassen gescheitert.

Das ist schade, denn wie gesagt: Man kann mitfiebern mit diesem Charakter, wie sie Hindernisse bewältigt, ihre Vergangenheit entdeckt und wie sich gegen Ende des Film eine Geschichte für den Nachfolger aufbaut. Wider Erwarten ist es keine herzlose künstliche Story, sondern ein sehr sorgfältig gemachter und überraschend emotionaler Film, der auch nicht zu kitschig wird, dabei einige sehr gute Actionszenen hat sowie im Kern eine gute Scifi-Story.

Surviving Mars ist ein Aufbauspiel in der harschen Umgebung des namensgebenden Planeten, umgesetzt von den Macher von Tropico 3 bis 5.

Es gibt eine Linuxversion, aber da sie bei mir nicht funktionierte spielte ich die Windowsversion via Proton.

Ähnlich wie in Tropico steht erstmal eine Art Szenarioauswahl an: Welche Nation, Kult oder Firma ist Sponsor der Mission, welches Profil hat der Kommandant, außerdem gibt es ein spielbegleitendes Mysterium mit Entscheidungsmöglichkeiten. In meinem ersten Durchlauf war mein Sponsor Europa (wodurch z.B. jeder Forschungsfortschritt Geld einbrachte), mein Kommandant ein Futurist (schnellere Freischaltung von Forschungsdurchbruchtechnologien) und das zufällig gewählte Mysterium drehte sich um eine KI, die in meinen Forschungstürmen wohnen wollte. Der Fokus meiner Kolonie war also eindeutig vorgegeben.

Zuerst aber ist wenig mit Forschung, sondern eine einzelne Rakete mit Vorräten (inklusive vorgebauter Gebäude) sowie Drohnen ist auf dem gewählten Marsterrain zu platzieren. Die Drohnen bringen dann ein Wirtschaftssystem in Gang: Produktionsgebäude wie Zementextraktoren wollen errichtet werden, die brauchen Stromerzeugung via Solarzellen, Windräder und magischen Sterling-Generatoren, Wasser muss abgebaut oder mit Verdunstungsanlagen generiert werden, womit Treibstoff hergestellt werden kann, mehr Drohnenhubs steuern weitere Drohnen und erweitern das Einflussgebiet - alles mit dem Ziel, eine erste kleine Kuppel für Kolonisten zu bauen. Die dann mit einer weiteren Rakete landen.

Denn nur Kolonisten können forschen und die fortgeschrittenen Rohstoffe herstellen, zum Beispiel Maschinenteile, die zur Wartung der Windräder oder zur Errichtung einiger anderer tollen Gebäude gebraucht werden. Bis das Wirtschaftssystem auf dem Mars diese Ressourcen herstellen kann ist der Spieler also auf Importe von der Erde angewiesen, die allerdings Geld kosten. Geld kommt automatisch durch den Sponsor oder durch Exporte von Metallen von Seltenen Erden, die aber auch nur Kolonisten abbauen können. Man sieht: Anfangs ist da durchaus Potential, sich in eine Sackgasse zu manövrieren. Die zu vermeiden und autark zu werden ist aber auch ein gutes Spielziel.

Zu erreichen ist dieses Ziel gar nicht so einfach, denn um alle benötigten Ressourcen abzubauen wächst die Kolonie auf dem Mars schnell auf eine beachtliche Größe, was gut verwaltet werden muss und nochmal mehr Ressourcen benötigt. Denn alle Gebäude verbrauchen Rohstoffe bei der regelmäßig notwendigen Wartung. Mir fehlte zum Beispiel zwischendurch auf einmal Metall, das vorher im Überschuss vorhanden war. Und ein andermal hatte ich mich mit der Essensproduktion verschätzt und meine Kolonisten hungerten etwas.

Erschwerend kam hinzu, dass Essen und andere Rohstoffe ja nicht nur vorhanden sein, sondern auch am richtigen Ort liegen müssen. Ich hatte z.B. noch Verpflegung, nur nicht in Reichweite der hungernden Kolonisten in der entfernteren Kuppel. Erst langsam brachten die Drohnen diese heran, immer von Lager zu Lager über die Einflussgebiete der mehreren Drohnenhubs, welche die Kuppeln verbanden. Erst später können die fliegenden Shuttle weite Transporte besser bewältigen, sie ermöglichen auch die Migration zwischen fernen Kuppeln.

Diese Migration nehmen die Kolonisten in Anspruch, wenn sie an einem anderen Ort besser aufgehoben wären. Denn jeder Kolonist hat eine Spezialisierung oder ist ein noch formbarer Generalist, und ein Wissenschaftler arbeitet lieber im Forschungszentrum als im Kasino, in dem sich der Generalist wohlfühlt. Jeder hat zudem eigene Bedürfnisse, wie das Glücksspiel im Kasino, und will eine eigene Wohnung, die in einer Residenz komfortabler als im platzsparenden Apartmentgebäude sind. Oder die negativen Eigenschaften greifen, so ist ein Einsiedler in Kuppeln mit mehr als 30 Einwohnern schnell unglücklich und will dann zurück zur Erde oder rebelliert. Auf dem Mars geborene Kolonisten – was in ausreichend komfortablen Kuppeln schnell geschieht, die Kinder werden auch schnell erwachsen – hingegen bleiben immer auf dem Mars und können durch Forschung viele Vorteile erhalten. Auch bei der Bevölkerungsverwaltung gibt es also immer viel Optimierungspotential.

So vielen Facetten beachten zu müssen hat mir zwischendurch durchaus gut gefallen. Aber als ich jetzt nach der Weihnachtspause die Erweiterungen (die im Bundle dabeiwaren) antesten wollte fehlte mir etwas die Motivation, nochmal von vorne anzufangen. Denn es ist alles doch etwas gemächlich und mühselig. Von dem Spiel wird viel Mikromanagement und einiges an Wartezeit gefordert. Gleichzeitig sind die Survival-Elemente nicht so spannend, wie das erst wirkt. Man muss ja nur die Grundlagen (Essen, Sauerstoff, Wasser) abdecken und den Wirtschaftskreislauf am Laufen halten, was nur selten schwierig ist. Eigentlich nur während der seltenen Katastrophen wie Meteoritenschauern, die dann Gebäude und Leitungen beschädigen können. Die häufiger auftreten zu lassen wäre mir aber wieder zu stressig.

Surviving Mars wird bei mir wahrscheinlich ähnlich wie Cities Skylines nach etwas Wartezeit wiederentdeckt werden, wenn ich wieder Geduld für das Spiel übrig habe. Denn die Erweiterung Green Planet scheint etwas zu bringen, was vorher fehlte: Mit dem Terraforming Spielziele für große Kolonien. Das sollte mich dann doch bald wieder reizen.

Diesmal war ich nicht ratlos, sondern fand nach etwas Zögern eine klare Position: Rise of Skywalker ist nicht gelungen.

Leichte Spoiler

Im Artikel zum Vorgänger prophezeite ich:

Aber ansonsten ist die Ausgangsposition in meinen Augen ziemlich einfach. Da das Imperium mit neuem Führer, dort die Überlebenden der Rebellion, die im nächsten Teil durch einen Aufstand der Massen im richtigen Moment den Sieg davontragen.

Volltreffer! Und dieser so offensichtliche Kniff ist gleichzeitig so richtig schlecht. Denn schon wieder passiert, was immer passiert: Die Schlacht läuft gut, dann agiert der Böse und sie kippt, alles sieht düster aus – doch da kommt die Erlösung. Wenn es so vorhersehbar ist, ist es dann noch ein Deus Ex Machina? Ein besonders billiges vielleicht?

Mich hat viel handwerkliches gestört. Die vielen Zitate für Menschen mit kurzer Konzentrationsspanne zum Beispiel: Unterschätze nie einen Droiden sagt die Prinzessin, zehn Minuten später wiederholt Rey das, völlig unpassend in einer Actionszene. Wohin verschwindet die alte Frau in der Endszene, warum läuft sie mitten in der Wüste vor einem verlassenen Haus herum? Warum buchstabiert der Oberbösewicht so deutlich, warum Rey ihr Vorhaben nicht umsetzen sollte – obwohl er will, dass sie genau das doch tut? Was will Finn Rey sagen, wie kann soetwas einfach vergessen werden?

Ich hatte aber auch schlicht unrecht: Ich dachte, der Verlauf der weiteren Story sei klar. Das stimmt nicht, weil alles aus dem Vorgänger ignoriert oder negiert wird. Der Kniff, dass Reys Eltern unbedeutend waren: Ätschie Bätsch, das Gegenteil ist der Fall. Eine neue Balance der Macht, mittels der Anziehung zwischen Rey und Kylo Ren? Vergiss es. Luke entsagt den Jedis? Quatsch, er hatte nur Angst und das jetzt im Jenseits erkannt. Der Oberböse war im keinem der Vorgänger angelegt und taucht daher total lächerlich aus dem Nichts auf.

Weil alles unmotiviert geschieht und komplett hanebüchen ist, scheitert erst der Anfang, es packt einen nicht. Dann wird es etwas besser, die Eckpfeiler einer Story stehen, fast wird es spannend. Doch drei Episoden in einem Film, entsprechend viele bemüht große Storymomente und (teils immerhin gute) Actionszenen: Unter diesem Ballast kracht dann alles ganz schnell zusammen. Skywalkers Aufstieg landet auf der Schnauze.

Das Szenario und die Schauspieler sollten den Film verkaufen. George Clooney, Ewan McGregor, Jeff Bridges und Kevin Spacey spielen die Hauptrollen in einer absurden Geschichte um von der US-Armee im Zuge der Hippiebewegung ausgebildeten Jedikrieger, die mittels eventuell vorhandenen übernatürlichen Fähigkeiten alle Kriege beenden sollten. Ob es diese Kräfte gibt, daran lässt der Film immer einen Hauch Zweifel.

Ewan McGregor spielt einen Reporter, der von seiner Frau verlassen wird und daraufhin in den Irakkrieg zieht. Er kommt erst gar nicht über die Grenze, trifft dann aber George Clooney, den Jeff Bridges in dieser Hippie-Einheit ausgebildet hatte. Kevin Spacey war da auch drin und neidisch und mischt dann auch im Irak nochmal mit.

Das ganze ist schon ein bisschen amüsant und nicht langweilig, aber es ist auch nicht richtig lustig. Gerade wenn man das mit Wayne's World vergleicht. Oder wenn man wegen Jeff Bridges an The Big Lebowski denkt, dann fehlt hier die ganze Atmosphäre. Für eine Komödie ist das nicht gut genug, ein absurdes Szenario und gute Schauspieler reichen manchmal eben nicht.

Diese Komödie ist unlösbar mit Mike Myers verbunden. Dessen Filme mit Austin Powers ich toll fand, und Love Guru wie der Rest der Welt dann nicht mehr. Wenn man sich Wayne's World anschaut ist der Kontrast verblüffend: Auch dieser Film ist albern, aber gleichzeitig irgendwie cool und vor allem nicht eklig.

Wayne's World ist von der Struktur her eine romantische Komödie. Aber die Frau und der Protagonist passen auf den ersten Blick nicht, Cassandra (Tia Carrere) und Wayne optisch ein ungleiches Paar. Ein paar Szenen durchbrechen das gut.

Dazu sind Wayne und sein Partner Garth Algar (Dana Carvey) schon an sich absurde Charaktere, erfolglose Rockfans, die eine unfreiwillig komische Fernsehsendung im Keller von Waynes Eltern produzieren. Die ein Produzent kaufen will, der natürlich an Cassandra interessiert ist. Damit ist die Handlung dann klar.

Nur dass das alles noch teilweise im Stil einer Doku gefilmt wird, Wayne und Garth dann auch direkt zur Kamera und also zum Zuschauer reden, Mittel für einige der Gags.

Die Komödie funktioniert, die meisten Witze sitzen. Natürlich sind es eben Popkulturanspielungen aus einem anderen Jahrtausend (und manche die man kennt wurden wohl hier geprägt), aber das macht es weder langweilig noch unlustig.

Nicht jeder mag Blade Runner. Aber für andere ist es ein absoluter Kultfilm. Einen Nachfolger zu so einem Film zu machen muss schwierig sein: So viele Chancen, alte Fans zu vergraulen, das Ansehen des Vorgängers zu beschädigen oder in das andere Extrem zu rennen: Nur absolute Fans des Vorgängers anzusprechen.

Meinem Eindruck nach ist Blade Runner 2049 ein toller Film geworden, der diese Schwierigkeiten hervorragend löst. Ich will Spoiler vermeiden, daher sei zur Handlung nur gesagt dass sie sich wieder um einen Blade Runner dreht, der Replikanten jagt. Und dabei auf eine größere Sache stößt.

Der Film ist gelungen, weil er:

1. Die Ästhetik des Vorgängers einfängt und doch auch eigene Akzente setzt. Und dabei ganz nebenbei hervorragend aussieht.
2. Die Welt behutsam erweitert.
3. Die vorherige Handlung nicht ignoriert.
4. Trotzdem nicht alle Mysterien löst.
5. Hervorragende Schauspieler hat. Und damit meine ich nicht nur Ryan Gosling, sondern auch Ana de Armas und Robin Wright.

Man vergleiche das mit Star Wars, besonders Harrison Fords Rolle.

Ich muss das mit der Ästhetik nochmal betonen. Da sind zwei Aspekte: Da ist diese Kopie der futuristischen, aber düsteren Stadt. Mit fliegenden Autos, leuchtenden Plakaten und gigantischer menschenfeindlicher Architektur. Diese Szenen vermitteln genau den gleichen Eindruck wie zuvor, als ob sie die gleiche Technik verwendet hätten. Und dann sind da Erweiterungen, die Hologramme beispielsweise oder die weiten Landschaften außerhalb, die 2049 einen eigenen Charakter geben. Unheimlich gut gemacht.

Der ersten Blade Runner gefiel mir übrigens, aber ich habe ihn nur einmal und vor nicht zu langer Zeit gesehen.

Ein paar von euch hatten ja Pipes ausprobiert. Ich bin derzeit sehr am Überlegen, wie sich die Seite im nächsten Jahr entwickeln soll. Ich habe ein paar Ideen, will aber gar nicht zu sehr beeinflussen, denn: Ich habe zum Ideensammeln eine Umfrage angelegt. Wer ein bisschen Interesse an der Seite hat sei hiermit herzlich gebeten, die (sehr kurze!) Umfrage auszufüllen oder mir auf sonstigem Wege seinen Eindruck oder seine Ideen zukommen zu lassen.

Später schreibe ich dazu bestimmt noch etwas mehr.

Ich war mal wieder am Performance-Debuggen von pc-kombo. Die Seite soll schneller laden, wenn der Cache noch nicht befüllt ist, was doch immer wieder Besucher trifft. Dabei stolperte ich über diesen Abschnitt des Flamegraphs:

tt ist der Übersetzungshelfer, lru-redux der genutzte Cache, Grundlage das Gem i18n. Und dieser Abschnitt machte einen gewichtigen Teil des Seitenladevorgangs aus.

Also habe ich das alte Übersetzungssystem auf FastGettext umgestellt. Der Code in Sinatra sieht in etwa so aus:

helpers do
    include FastGettext::Translation

    def t(token, opts = {})
        _(token.to_s) % opts
    end
end

configure do    
    FastGettext.add_text_domain('pckombo', path: 'locales', type: :yaml)
end

before do
    FastGettext.text_domain = 'pckombo'
    if request.env['HTTP_ACCEPT_LANGUAGE']
        languages = HTTP::Accept::Languages.parse(request.env['HTTP_ACCEPT_LANGUAGE'])
        languages.each do |language|
            case language.locale
            when /en[_]*/
                FastGettext.locale = "us"
                break
            when /de[_]*/
                FastGettext.locale = "de"
                break
            when /fr[_]*/
                FastGettext.locale = "fr"
                break
            when /es[_]*/
                FastGettext.locale = "es"
                break
            end
        end
    end
end

Die alten yaml-Übersetzungen konnten weiterverwendet werden. So beginnt z.B. die locales/de.yml:

de:
    cpu: Prozessor

Es ist also fast eine einfach so einsetzbare Alternative mit minimalen Codeänderungen.

Das Ergebnis:

Die Übersetzungen beim ersten Laden brauchen nun einen Bruchteil der Zeit. Das beste daran: Das wird nicht nur den speziellen Seitenaufruf beschleunigen den ich da betrachtet hatte, sondern generell der gesamten Webseite helfen.

Wer Übersetzungen in Ruby umsetzen muss, für den ist FastGettext ist definitiv einen Blick wert.

Ruby kann ja RSS lesen und schreiben, aber die Dokumentation für das Modul ist ungenügend und es scheint generell wenig genutzt zu werden, sodass man auch wenig Hilfe findet. Ich stand jetzt vor einem Rätsel: Wie kann ich den Items in einem erstellten RSS-Feed Kategories hinzufügen, also category setzen? Doch jetzt habe ich es gelöst. Und zwar geht das so:

rss = RSS::Maker.make("rss2.0") do |maker|
    …
    maker.items.new_item do |newItem|
        …
        categories = [{name: 'abc', scheme: 'https://www.example.com'}]
        categories.each do |category|
            target = newItem.categories.new_category
            target.content = category[:name]
            target.domain = category[:scheme]
        end
end

Wie baut man am besten eine Suchmaschine für eine einzelne Webseite? In meinem Fall war das Szenario so: Ich habe eine Sammlung statischer HTML-Dokumente, will aber eine Suchfunktion anbieten. Also brauchte ich etwas, was die ganzen HTML-Dokumente indexiert und dann durchsuchen kann. Genau das kann Xapian. Speziell für Webseiten gibt es vom Xapian-Projekt die vorgefertigte Omega-Suchmachine.

Also, Xapian kann alles mögliche durchsuchen, man könnte dem Xapian-Index auch programmatisch Elemente der Datenbank hinzufügen. Und es muss nicht für eine Webseite sein, es kann auch sonstwo eingebunden werden – mancher mag sich an xapian als nervenden Prozess in Ubuntu erinnern. Ich aber wollte nur HTML-Seiten durchsuchbar machen und das online anbieten, und genau dafür ist Omega gedacht. Allerdings: Omega hat ein eigenes Webfrontend, das per CGI eingebunden wird. Das wollte ich nicht nutzen, denn ich habe sowieso schon ein zusätzliches dynamisches Backend laufen, und die Template-Funktion von Omega sah unschön und kompliziert aus.

Xapian und Xapian-Fu installieren

Xapian samt Omega sollte in den Quellen sein. Bei mir mit void:

sudo xbps-install xapian-omega

Dazu empfehle ich für die Sinatra-Integration das Gem xapian-fu. Also in die Gemfile:

gem 'xapian-fu'

und dann installieren mit bundle install.

Allerdings reichte das nicht. Xapian-fu braucht die Ruby-bindings von xapian, und die waren bei mir nicht in den Quellen enthalten. Also muss in dem Fall noch das Archiv xapian-bindings heruntergeladen und die Ruby-Bindings kompiliert werden:

unp xapian-bindings-*
cd xapian-bindings-VERSION
./configure --with-ruby
cd ruby
make
sudo make install

Mit omindex indexieren

Omindex installierte sich in den PATH und ist einfach bedienbar. Meine HTML-Dateien liegen im Ordner public/, Bilder sollten ignoriert werden, dafür kam ich auf diesen Befehl:

omindex --db omega/data/default/ --filter image/*:skip public/

Der Code in Sinatra

Statt jetzt den CGI-Part von Omega zu nutzen übernimmt Sinatra mit Xapian-Fu die Suche:

require 'sinatra'
require 'xapian-fu'
include XapianFu

get '/search' do
    searchterm = params['searchterm']
    db = XapianDb.new(:dir => 'omega/data/default/', :create => false)
    results = db.search(searchterm).map{|match| {url: match.data.split("\n").detect{|x| x.start_with?('url=')}.to_s.sub('url=', ''), caption: match.data.split("\n").detect{|x| x.start_with?('caption=')}.to_s.sub('caption=', '')} }
    erb :search, locals: {searchresults: results, searchterm: searchterm}
end

Man sieht: Der Code nimmt die Datenbank als Quelle, die vorher omindex angelegt hat.
Die Zuweisung in den results-Hash ist hässlich. Ich fand leider keinen Weg, mit xapian-fu die Suchergebnisse richtig strukturiert auszulesen. Nur match.data ist zugänglich, womit man etwas anfangen kann. Der Weg über einen XapianDocValueAccessor, mit dem man wohl die Felder gezielt auslesen können sollte, funktionierte bei mir nicht. Eventuell codiert omindex den Suchindex zu speziell.

Die Suchergebnisse gehen dann an ein ERB-Template:

<h1>Search results for <%= h searchterm %></h1>

<% if searchresults.size > 0 %>
<ol id="searchresults">
    <% searchresults.select{|item| ! item[:caption].empty? }.each do |result| %>
        <li>
            <a href="<%= result[:url] %>">
                <span><%= result[:caption] %></span>
            </a>
        </li>
    <% end %>
</ol>

Xapian/Omega ist keine Lösung, wenn die Webseite nur aus statischen HTML-Seiten bestehen darf. Aber es ist wohl eine gute Lösung wenn es einen echten Server gibt. Die Integration in Ruby/Sinatra ist relativ einfach.

Dass die xapian-bindings nicht einfach per gem installierbar sind ist der problematischste Punkt, auch das vorgelagerte indexieren wird nicht in jedes Projekt gut passen. Ohne statischen Webseitengenerator im Zentrum würde ich omega und omindex ignorieren und stattdessen nur mit xapian-fu arbeiten. Dann kämen die Daten eben direkt aus der Datenbank.

Hier aber war das Parsen der HTML-Seiten die perfekte Lösung.

Die Geschichte des Remakes ähnelt sehr der Geschichte der Vorlage, soweit ich mich an sie erinnere. Ein guter Polizist wird schwer verletzt. Anstatt ihn sterben zu lassen wird er in einen Robocop verwandelt, noch ein Cyborg, aber einem Großteil seiner Menschlichkeit beraubt. Was natürlich keine gute Sache ist und entsprechend schiefgeht - wobei hier mit weniger direktem Kampf um Kontrolle über ihn als vielmehr Robocop als Mittel zum Zweck.

Da gibt es dann wenige Überraschungen. Aber dafür ordentliche Actionszenen, eine geradlinige Story, keine schlechten Schauspieler. Mir gefiel, wie offensichtlich die Parallele zwischen dem Bestreben nach Robotern als Sicherheitskräfte und der schon bestehenden Praxis des Mordens per Roboter gezogen wird, zu Fox News als Propagandamaschine und dem US-Nationalismus als Faschismus.

An ein paar Stellen stolpert die Story, z.B. wenn der eigentlich als positive Figur positionierte Doktor ohne besonderen Zwang seine Prinzipien verrät und Robocop manipuliert. Wie der dann dieser Manipulation auf einmal entgehen kann, wunderbarerweise. Und wie der Oberbösewicht am Ende sich bewusst blöd verhält. Eben alles ein bisschen sehr einfach.

Fraglich auch was das Remake über das Original hinaus liefert. Und das war ja wohl schon kein besonders guter Film. Aber ich erwartete einen sehr schlechten Film, und so schlecht war das gar nicht. Eher ein kompetenter Actionfilm ohne besondere Größe mit einer mittlerweile nicht mehr originellen Story.

Story of Your Life von Ted Chiang habe ich tatsächlich gelesen, bevor der darauf basierende Film herauskam. Immerhin, sie blieb im Gedächtnis. Aber insgesamt habe ich die kurze Geschichte nicht übermäßig gemocht und daher auch bisher den Film gemieden.

Es gibt ja verschiedene Arten von Science-Fiction. Die Skala reicht in etwa von leicht futuristisch angehauchter Fantasy bis hin zu hochintellektuellen Zukunftsvisionen. Chiangs Geschichte war eher letzteres, sogar mehr nur eine Gedankenübung mühsam ausgebaut zu einer Geschichte – wobei ich es lieber mag, wenn die Geschichte im Vordergrund steht und der intellektuelle Hintergrund eben im Hintergrund bleibt (also Star Trek, Interstellar, Blade Runner). Keine gute Voraussetzung für den Film, nicht nur um mir zu gefallen, sondern wie will man so etwas verfilmen?

Das gelingt Arrival überraschend gut. Um den losen Rahmen der Buchhandlung herum wird die Geschichte aufgefüllt. Das Verhalten der Menschen um die Forscher herum, der Nationen, auch der Aliens rückt mehr in den Fokus. Und was im Buch nur angedeutet wurde wird im Film einfach gezeigt. Erklärungsmodelle werden auch gegeben. Das ist dann zwar nicht mehr ganz wie in der Vorlage, aber die Grundidee kommt sehr wohl rüber. Ebenso wie die enthaltene Traurigkeit; besonders durch Amy Adams, die ausspielt was vorher nur skizzierte Pointe war.

Trotzdem finde ich die Grundlage des Filmes weiterhin nicht stark, das macht das ganze Drumrum dann doch nicht ganz wett.