Code

Ein neues Feature meines Hardwareempfehlers sind Übersichtsseiten für die einzelnen Komponenten. Jede Seite soll so nützlich wie möglich sein: So stehen dort neben den aktuellen Preisen die ganzen Spezifikationen, Bilder, Links zu Reviews und zur Herstellerseite, und bei Prozessoren und Grafikkarten auch die Benchmarkbewertung.

Mein Lieblingsfeature aber ist inspiriert von einem Reddit-Thread. Dort hatte ein Nutzer eine Reihe von Gehäusen mit CAD gerendert, und es war wirklich aufschlussreich die Dimensionen der Gehäuse im Vergleich zu sehen. Sowas wollte ich für die Übersichtsseiten der Gehäuse haben. Mit WebGL und three.js konnte ich es nun bauen.

Das ist das Ergebnis, als Beispiel die Übersichtsseite samt Größendarstellung des NZXT Source 340:

Was ich schon hatte waren die Dimensionen der Gehäuse: Höhe, Breite, Tiefe. Es geht hier nicht darum, detailgetreue Nachbildungen zu schaffen, sondern abstrakt die Größe darzustellen. Dafür reichen diese drei Werte, denn mit ihnen kann man einen Quader zeichnen. Diesen Quader des aktuellen Gehäuses stelle ich dann neben den Quader nach den Durchschnittswerten aller Mid-Tower in der Datenbank, und auf der anderen Seite den Quader nach den Durchschnittswerten aller Mini-Gehäuse.

Three.js erwies sich dabei als hervorragendes Hilfsmittel. Es ermöglicht das Programmieren von WebGL auf einer hohen Abstraktionsebene, dadurch wird es ziemlich einfach. Dazu gibt es für three.js einige Beispiele und eine hilfreiche Dokumentation.

Der gekürzte Code:

var scene = new THREE.Scene();
scene.background = new THREE.Color(0xE5E5E5);
scene.fog = new THREE.FogExp2( 0xcccccc, 0.02 );
var camera = new THREE.PerspectiveCamera( 60, 400/300, 0.1, 1000 );

var renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.setPixelRatio( window.devicePixelRatio );
renderer.setSize( 400, 300 );
document.querySelector('#visualize_size').insertBefore(renderer.domElement, document.querySelector('#case_explanation'));

// current case
var geometry = new THREE.BoxGeometry(WIDTH, HEIGHT, DEPTH );
var materialCurrent = new THREE.MeshPhongMaterial( {
            color: 0x156289,
            emissive: 0x072534,
            side: THREE.DoubleSide,
            flatShading: true
        } )
var cube = new THREE.Mesh( geometry, materialCurrent );
scene.add( cube );

var pointLight = new THREE.PointLight( 0xE6E6FA, 1, 100 );
pointLight.position.set( 10, 10, 10 );
scene.add( pointLight );

var light = new THREE.AmbientLight( 0x222222 );
scene.add( light );

camera.position.set(0.5, 0.5, 2)
camera.lookAt(0, 0, 0)

controls = new THREE.OrbitControls( camera, renderer.domElement )

var animate = function () {
    requestAnimationFrame( animate );
    
    renderer.render(scene, camera);
};

animate();

Zuerst erstellt dieser Code die Umgebung: Es gibt eine Szene, eine Camera, einen Renderer. Dann wird ein Objekt erstellt, ein Cube (=Quader), mit den Daten des Gehäuses. Das Objekt wird in die Szene gesetzt, dann noch Licht hinzugefügt, die Kamera positioniert und mit den OrbitControls steuerbar gemacht. Der Nutzer kann die Kamera später in alle Richtungen bewegen. Schließlich wird das alles gerendert.

Die Lichter waren knifflig für mich, und da meine Lösung dort wahrscheinlich nicht optimal ist habe ich das auch weitestgehend ausgelassen. Die Farben der Lichter beeinflussen ja die Farbe der Gehäuse, und man will gleichzeitig alle Seiten beleuchten, sie aber alle leicht unterschiedlich haben, sodass die Kanten sichtbar sind. Die Szene braucht dafür noch ein paar Lichter mehr, um die Gehäuse von der anderen Seite zu beleuchten.

In meinem echten Code kommen noch die zwei anderen Gehäuse dazu, um einen Größenvergleich zu haben, und ein Rasternetz unten zur Orientierung.

Ein Problem blieb: Mit den drei Gehäusen nebeneinander hatte man immer noch nicht wirklich eine Idee, wie groß sie in Wirklichkeit sind. Wer sich vorstellen kann, wie groß ein durchschnittliches PC-Gehäuse ist, für den funktionierte das. Doch selbst ich fand das schwierig. Deswegen baute ich eine Banane ein, die rechts neben dem aktuellen Gehäuse steht. Ist zwar ein halber Witz, macht es aber doch einfacher.

Ich bin ziemlich glücklich über das Ergebnis. Besonders die Größen von ITX-Gehäusen zu sehen finde ich interessant. Der Kolink Satellite z.B. ist deutlich kleiner als der Thermaltake Core V1, aber Fractals Node 202 hat nochmal einen ganz anderen Ansatz.

Mich hat es auch gefreut WebGL nutzen zu können. Bisher hatte ich mich immer gefragt, warum man solch eine Technik im Browser haben muss. Hier aber war es eindeutig praktisch, und viel einfacher als ich erwartet hatte.

Definition Lists (DLs) bzw. description lists (siehe Matthias Kommentar) sind ein kaum genutztes HTML-Element, das ich aber ganz gerne mag. Ihre semantische Aufgabe ist es, Definitionen zu einem Schlagwort aufzulisten. Spinnt man das etwas weiter macht es das zum einzigen geeigneten Element, wenn man Eigenschaften einer Sache auflisten will. Zum Beispiel die Eigenschaften eines Prozessors, wie Prozessortakt und die Anzahl der Kerne.

DLs sind ein <dl> Element, in dem dann mindestens ein <dt> ist - das zu definierende Ding - dem ein oder mehrere <dd> folgen - die Definitionen.

Im Browser werden DLs so normalerweise angezeigt:

DT
    DD
    DD
    ...

Die <dd> stehen also rechts eingerückt (Firefox löst das mit margin-left: 40px) unter dem Schlagwort. Hier nochmal als Fiddle:

Das ist nicht immer ideal. Diese Art der Darstellung wirkt schlicht unfertig und sie nimmt viel vertikalen Platz weg. Entsprechend gibt es seit Jahren ein paar wenige (denn wie erwähnt, das Element wird selten benutzt) Artikel, wie man DL anders darstellen kann.

Eine hübsche Lösung bietet sich mit CSSs relativ neuem grid-Layout an. Eine sinnvolle Darstellung für DLs ist eine tabellarische: Links die Schlagworte, rechts die Definitionen. Das war bisher aber nicht ganz einfach, wenn man weiterhin die mehreren <dd> unter einem <dt> unterstützen will, und gleichzeitig float zu vermeiden wünscht.

Mit grid ist es nun ganz einfach:

dl {
    display: grid;
    grid-template-columns: 50% 50%;
}

dt {
    grid-column-start: 1;
}

.specs dd {
    grid-column-start: 2;
    margin-left: 0;
    padding-left: 1em;
}

Das sieht dann so aus:

Da fehlt dann nur noch etwas übliches Tabellenstyling für ein gutes Ergebnis.

Übrigens: Support für grid ist mit den letzten Browserversionen in alle Mainstream-Browser gerutscht, wobei IE wie Edge noch ein Prefix benötigt und nicht die aktuelle Version der Spezifikation unterstützt.

Für mein derzeitiges Softwareprojekt arbeite ich mit RSS- und Atom-Feeds. Dabei entdeckte ich, dass Ruby in der Standardbibliothek ein Modul zum Arbeiten mit diesen Formaten hat.

Es gibt einen Parser zum Lesen (Beispielcode aus der Dokumentation):

require 'rss'
require 'open-uri'

url = 'http://www.ruby-lang.org/en/feeds/news.rss'
open(url) do |rss|
  feed = RSS::Parser.parse(rss)
  puts "Title: #{feed.channel.title}"
  feed.items.each do |item|
    puts "Item: #{item.title}"
  end
end

Und eine Klasse zum Erstellen:

require "rss"

rss = RSS::Maker.make("rss2.0") do |maker|
    maker.channel.updated = Time.now.to_s
    maker.channel.title = 'Testing the RSS 2.0 maker'
    maker.channel.link = 'http://www.ruby-lang.org/en/feeds/news.rss'
    maker.channel.description = 'An important description' 

    maker.items.new_item do |newItem|
        newItem.title = 'Item title'
        newItem.updated = Time.now.to_s
        newItem.link = 'https://www.onli-blogging.de/1641/Space-Hulk-Ascension.html'
        newItem.content_encoded = 'A mediocre game'
        newItem.guid.content = 'https://www.onli-blogging.de/1641/Space-Hulk-Ascension.html'
    end
end

puts rss

Allerdings ist dieses Modul nicht unproblematisch. Abgesehen von der Readme gibt es nahezu keine Dokumentation. Auch Google findet kaum Diskussionen über den Code, das macht das Arbeiten damit schwierig. Ein Beispiel, in das ich heute gerannt bin, steckt im obigen Beispielcode: In bestimmten Situationen gibt der RSS-Bauer einfach nichts aus.

Deswegen ist es eine wichtige maker.channel.description. Ist diese nämlich nil oder leer (""), scheitert die Erstellung ohne Fehlermeldung und es gibt keine Ausgabe.

Eine weitere Stolperstelle steckt in der guid. Normalerweise würde man die ja einfach über newItem.guid = 'die guid' setzen. Weil dieser Setter aber nicht implementiert ist, muss stattdessen newItem.guid.content aufgerufen werden.

Den Parser nutze ich gar nicht erst direkt, weil ich eine Normalisierung von Atom und RSS brauche. Das kleine Gem feedparser kann das, nutzt ihn allerdings intern. Ansonsten hätte ich auf feedjira gesetzt, das normalisiert wohl auch, wirbt aber nicht explizit damit, was mich zögern lässt.

Zum Erstellen hätte ich aber keinen anderen Weg, außer das wie bei ursprung manuell über ein Template zu erledigen.

Trotzdem: Sehr schön, so etwas in der Standardbibliothek zu haben. Jetzt müsste es nur noch dokumentiert sein.

Das tolle an SQLite ist, dass es eine Datenbank in einer Datei ist. Das hat viele Vorteile: Einfache Installation, einfache Konfiguration, einfache Backups. Und die Performance ist trotzdem nicht schlecht. Es hat aber auch einen Nachteil: Wie soll man Daten synchronisieren?

Also, ein Beispiel: Eine Webapp auf dem Produktivsystem aktualisiert die Datenbank mit neuen Produktpreisen, und hat dafür eine eigene Tabelle offers. Gleichzeitig wird auf dem Entwicklungssystem die Tabelle products angepasst, also welche Produkte die Webapp überhaupt kennt. Jetzt sollen gleichzeitig die Preise aktuell gehalten und irgendwie die neue Produkt-Tabelle ins Produktivsystem geschoben werden.

In einem solchen Szenario kann man die Datenbank aufteilen. Die aktuellen Preise bleiben in einer Datei namens offers.db, die Produkte landen in products.db. SQLite kann die dann mit ATTACH zusammenfügen.

$ sqlite3 products.db
SQLite version 3.17.0 2017-02-13 16:02:40
Enter ".help" for usage hints.
sqlite> ATTACH DATABASE 'offers.db' as odb;

Danach können die Tabellen in offers.db ganz normal in SQL-Abfragen benutzt werden. Bei Kollisionen hilft das Namenspräfix. Sogar neue Tabellen können damit zielgerichtet in dieser Datei erstellt werden:

CREATE TABLE odb.sales(link TEXT, price REAL); 

Mit dieser Funktion kann man wunderbar die Daten in permanente und regelmäßig aktualisierte aufteilen, sodass das Überschreiben der ersten nicht die Aktualisierungen der anderen verlorengehen lässt.

Für den Hardwareempfehler gibt es natürlich Übersetzungen, schon weil er nicht nur den deutschen Markt unterstützt. Worauf ich damals aber nicht kam war, die Sprache je nach der Browsersprache zu wählen. Der Browser sendet die als Header mit, Accept-Language. Den müsste man nur auslesen, und das geht mit einem passenden Gem ziemlich einfach. Ich glaube, beides war mir damals nicht richtig klar.

In Sinatras configure-Block werden die Übersetzungen initialisiert. Diese liegen unter locales/. Im before-Block wird vor jedem Seitenaufruf die passende Sprache gewählt. Das Gem i18n verwaltet die Übersetzungen, http-accept liest den Accept-Language-Header aus. Leider fehlt da eine Hilfsfunktion, um die regionsübergreifende Sprache zu bekommen (z.B. englisch, egal ob der Header nun en_GB oder en_US sendet). Aber das erledigt dann die Regexpression bei der Case-Abfrage.

configure do
    I18n::Backend::Simple.send(:include, I18n::Backend::Fallbacks)
    I18n.load_path = Dir[File.join(settings.root, 'locales', '*.yml')]
    I18n.backend.load_translations
    I18n.default_locale = :"de"

    I18n.exception_handler = lambda do |exception, locale, key, options|
        case exception
        when I18n::MissingTranslation
            return key.to_s
        end
    end
end

before do
    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[_]*/
                I18n.locale = "us"
                return
            when /de[_]*/
                I18n.locale = "de"
                return
            when /fr[_]*/
                I18n.locale = "fr"
                return
            when /es[_]*/
                I18n.locale = "es"
                return
            end
        end
    end
    I18n.locale = "us"
end

Wenn dann die Seite nach dem Neuladen die Sprache ändert, nur weil in den Browsereinstellungen eine neue gewählt wurde, wirkt das schon ein bisschen wie cooles Voodoo.

Sinatra-portier ist ein Fork des Gems sinatra-browserid, das ich ebenfalls vorher geforkt hatte. Es funktioniert für den Entwickler noch genauso, der Unterschied ist, dass statt dem Button ein Formular erstellt wird, und dass Portier zum Bestätigen der Email benutzt wird.

Ein Sinatra-Projekt von Persona auf Portier umstellen

Sinatra-portier ist ganz offiziell als Gem registriert und kann darüber installiert werden:

gem install sinatra-portier

Im Sinatra-Projekt bindet man aber weiterhin sinatra/browserid ein:

require 'sinatra/browserid'

Dadurch kann man ohne Codeanpassung von Persona zu Portier wechseln. In den meisten Projekten muss man nur in der Gemfile gem sinatra-browserid mit gem sinatra-portier ersetzen und dann schauen, ob das Loginformular anstatt des Buttons im bestehenden Design ebenfalls funktioniert.

Die API

Es werden einige weniger Helferfunktionen und sinatraweit globale Variablen definiert, mit denen das Gem genutzt wird:

authorized?

True wenn der Nutzer sich mit Portier eingeloggt hat. Die Kernfunktion.

authorized_email

Die Email (als String), mit welcher der Nurzer eingeloggt ist. Kann benutzt werden um die genauen Rechte des Nutzers zu prüfen.

authorize!

Leitet zur Loginseite weiter, wenn der Nutzer nicht bereits eingeloggt ist.

render_login_button

Gibt das HTML des Loginformulars aus.

logout!

Loggt den Nutzer aus, authorized? ist danach false und authorized_email leer.

Ein Codebeispiel zeigt, wie die Funktionen benutzt werden können:

require 'sinatra/base'
require 'sinatra/browserid'

module MyApp < Sinatra::Base
    register Sinatra::BrowserID

    set :sessions, true

    get '/'
        if authorized?
            "Welcome, #{authorized_email}"
        else
            render_login_button
        end
    end

    get '/secure'
        authorize!                 # require a user be logged in

        email = authorized_email   # browserid email
        ...
    end

    get '/logout'
        logout!

        redirect '/'
    end
end

Nutzungspattern

Mit der obigen API gibt es mehrere Wege, wie man am besten Nutzer anmeldet und ihre Email prüft. Aber ich weiß noch, dass ich eine Weile brauchte um das für mich durchzustrukturieren, trotz des Beispiels. Nicht einfach zu prüfen, ob das eingegebene Passwort das gespeicherte ist, war ungewohnt. Aber im Grunde ist es noch einfacher: Prüfen, ob man die Emailadresse bereits kennt (=ist sie in der Datenbank?) und welche Rechte sie hat.

Ersten Nutzer zum Admin machen

Aber wo fängt man an? Bei der ersten Nutzung ist die Datenbank ja noch leer, es gibt nichts abzugleichen. Meine Projekte, die dieses Gem nutzen (ursprung, feedtragón und music-streamer) zeigen daher einen kleinen Installer, wenn die Datenbank leer ist. In diesem loggt der Nutzer sich über Portier ein, und diese erste Emailadresse wird dann als Adminadresse in der Datenbank gespeichert. Später prüft man, ob authorized_email die gespeicherte Emailadresse ist, und kann so zu schützende Bereiche der Seite abriegeln.

Weitere Helfer erstellen

Um die Emailadresse auf Adminrechte zu prüfen definiert man am besten zwei weitere Helfer:

helpers do
    def isAdmin?
        if authorized?
            if Database.new.getAdminMail == authorized_email
                return true
            end
        end
        return false
    end

    def protected!
        unless isAdmin?
            throw(:halt, [401, "Not authorized\n"])
        end
    end
end

…

get %r{/([0-9]+)/editEntry} do |id|
    protected!
    …
end

Mit Nutzerliste abgleichen

Was aber, wenn man mehr als einen Nutzer haben will? Dann vergleicht man mit der Nutzerdatenbank.

helpers do
    def isAdmin?
        if authorized?
            return Database.new.getAdminMail == authorized_email
        end
        return false
    end

    def isRegistered?
        if authorized?
            return Database.new.registered?(authorized_email)
        end
    end

    def protected!
        unless isRegistered?
            halt 401, erb(:login)
        end
    end

    def adminProtected!
        if (isRegistered? && isAdmin?)
            return true
        else
            halt 401, erb(:login)
        end
    end
end

Routen, die normale Nutzer aufrufen können, werden wie zuvor mit protected! geschützt. Hier wird nur geschaut, ob in der Datenbank der Nutzer registriert ist. Music-streamer z.B. hat eine Liste in den Einstellungen, in die der Admin neue Adressen und damit neue Nutzer hinzufügen kann. adminProtected! hingegen prüft, ob authorized_email die gespeicherte Emailadresse des Admins ist.

Das könnte dann mit einem kompletten Rollensystem erweitert werden, in dem der Code für jede Email prüft, welche Rolle und damit welche Rechte er hat. Und die Datenbankstruktur dafür bleibt simpel:

CREATE TABLE IF NOT EXISTS users(
    mail TEXT PRIMARY KEY,
    role TEXT
);

Das schöne an dem System ist, was auch bei Persona schon hübsch war: Wir haben mit dem bisschen Code eine komplette Nutzerverwaltung in ein Sinatra-Projekt eingebaut, ohne ein einziges Passwort zu speichern oder auch nur einen Gedanken an Hashverfahren zu verschwenden.

Die schnellere Pagination ohne Offset habe ich inzwischen wirklich für ursprung umgesetzt. Das war letzten Endes einige Arbeit.

Statt einem Link wie archive/older=datum sollte es dann doch wieder ein Link mit Seitenzahl sein, also archive/2 für Seite 2. Also brauchte das System eine Liste, um Seitenzahlen auf eine Datumsangaben zu mappen. Außerdem muss das System sich merken, welcher Eintrag bereits in der Pagination berücksichtigt ist. Denn immer dann, wenn die neu erstellt wird (bei jedem Löschen eines Eintrags) muss dies gezählt werden, statt einfach nur die Anzahl insgesamt vorhandener Einträge zu zählen.

Die Kernfunktion ist das Hinzufügen eine Seite zur Pagination und deren Anpassung:

# Add the page to the precomputed mapping of page to entry date, to enable the no offset pagination
# This also has to take care of shrinking the buffer (the second archive page, n -1), so that all other archive pages remain stable
def addToPagination(entry:)
    limit = 5
    # the tag can't just be nil, because in sqlite3 INSERT OR REPLACE on shared primary keys detects ('abc', NULL) and ('abc', NULL) not as a conflict
    tags = entry.tags.empty? ? [self.NOTAG] : (entry.tags << self.NOTAG)
    tags.each do |tag|
        totalPages, totalEntries = self.getTotalPages(limit, tag)
        totalEntries += 1   # the current entry is not already counted by that function
        page = (totalEntries > 1 && totalEntries % limit == 1) ? totalPages + 1 : totalPages
        # start date of n is now entry.date
        @@db.execute("INSERT OR REPLACE INTO pagination(page, tag, startDate) VALUES(?, ?, ?)", page, tag, entry.date)

        if totalEntries > limit
            # now the start second archive page, the shrinking and growing buffer, has to be set as well
            tagSQL = tag == self.NOTAG ? "" : "AND id IN (SELECT entryId FROM tags WHERE tag = '#{SQLite3::Database.quote(tag)}')"
            bufferStart = @@db.execute("SELECT date FROM entries WHERE date < (SELECT startDate FROM pagination WHERE page = ? AND tag = ?) #{tagSQL} ORDER BY date DESC LIMIT ?", page, tag, limit).last['date']
            @@db.execute("INSERT OR REPLACE INTO pagination(page, tag, startDate) VALUES(?, ?, ?)", page - 1, tag, bufferStart)

            if (totalEntries > (limit * 2)) && (totalEntries % limit == 1)
                # if we have more than two pages and the buffer just overgrew, we can set it back to 1 and move the full amount of entries to a stable page
                bufferEnd = @@db.execute("SELECT date FROM entries WHERE date < (SELECT startDate FROM pagination WHERE page = ? AND tag = ?) #{tagSQL} ORDER BY date DESC LIMIT ?", page - 1, tag, 1).last['date']
                # this will never be changed again
                @@db.execute("INSERT OR REPLACE INTO pagination(page, tag, startDate) VALUES(?, ?, ?)", page - 2, tag, bufferEnd)
            end
        end
    end
    @@db.execute("UPDATE entries SET paginated = 1 WHERE id = ?", entry.id)
end

Schließlich hat es aber durchaus funktioniert. Das Aufrufen einer Archivseite in einem vollen Blog ist schneller geworden, ohne dass sich für den Nutzer etwas geändert hätte. Es fehlt nur noch ein schlaueres Vorgehen beim Löschen eines Eintrags, dass die Pagination angepasst wird statt sie zu löschen und neu zu erstellen.

Wobei ich das Gefühl nicht loswerde, dass meine Implementation unnötig kompliziert ist.

Die Amazon-Api durchgängig nur 1-mal pro Sekunde anzusprechen führt natürlich dazu, dass die Anwendung nun deutlich länger braucht. Denn vorher wurden Anfragen so schnell losgeschickt wie möglich, und diese Bursts tolerierte Amazon – nur eben nicht immer und nicht zuverlässig. Daher brauchte es einen Weg, weniger Anfragen zu benutzen und so wieder akzeptable Geschwindigkeiten hinzukriegen.

Naheliegende Lösung war, Amazons Apiantworten für eine Weile zu cachen. Statt über SQLite zu funktionieren sollte dieser Cache jedoch im Speicher liegen. Genau das tut LruRedux, ist thread-safe und hat dazu einige nette Funktionen, beispielsweise ebenfalls eine Time-To-Live-Variante.

require 'lru_redux'

class Amazon
  
    def initialize()
        begin
            @@cache
        rescue
            @@cache = LruRedux::TTL::ThreadSafeCache.new(200, 86400) # 24h
            …
        end
     end

    def getOffer(hardware)
        return @@cache.getset(hardware.type) do
            … 
            self.search(hardware.type)
        end
    end
end

Die getset-Methode ist besonders hilfreich. Der übergebene Block wird nur ausgeführt, wenn die id (hardware.type hier) nicht bereits im Cache ist. Ansonsten wird der Block einmal ausgeführt, sein Ergebnis direkt gecached und zusätzlich noch returned. Ansonsten kann der Cache einfach wie ein Hash benutzt werden – allerdings wie ein Hash, der hier nur 200 Einträge fasst und sie nach 24 Stunden wieder vergisst.

LruRedux ist damit genau das, was ich hier brauchte: Ein pfeilschneller und einfach zu benutzender Cache, den ich als Klassenvariable setzen kann. Wie throttle-queue scheint er hervorragend zu funktionieren.

Ruby habe ich damals angefangen, weil ich Sinatra mochte. Inzwischen mag ich auch die Sprache selbst, aber es ist immer noch das Ökosystem drumherum, das besonders toll ist. Ich hätte sowohl cache als auch queue selbst bauen können, aber es wäre so viel mehr Arbeit und das Endergebnis schlechter gewesen. Ein spezifisches Problem durch kleine hilfreiche Gems zu erschlagen ist immer wieder eine schöne Erfahrung.

Mit der throttle-queue wird ein bestimmter Codeblock nur x mal pro Sekunde ausgeführt. Das ist besonders praktisch für ausgehende Apiabfragen, wenn z.B. wie bei Amazons Produktapi regulär nur eine Anfrage pro Sekunde rausgeschickt werden darf und sonst der Zugang blockiert wird.

require 'throttle-queue'

class AmazonApi

    def initialize()
        begin
            @@throttle    # have only one throttle for all objects
        rescue
            @@throttle = ThrottleQueue.new 1    # 1 request per second
            …
        end
    end

    def search(keyword)
        result = ""    # temporary variable because we can't return in the queue
        @@throttle.foreground(rand) {     # random id, so new requests don't replace waiting requests 
            result = @@api.item_search query: {  … }
        }
        return result
    end

Alternativ könnte man den Codeblock auch im Hintergrund ausführen lassen, was je nach Anwendungsfall sehr praktisch sein kann.

Es ist ein relativ neues Gem, das erst seit November 2014 auf Github existiert. In meinen Tests funktionierte es einwandfrei und schien wie beworben thread-safe zu sein. Eine schöne Überraschung, so etwas überhaupt und dann noch ohne Abhängigkeit von eventmachine zu finden.

Alles was länger dauert, z.B. Trackbacks zu verschicken, sollte eine Webanwendung besser im Hintergrund ausführen. Sinatra hat dafür aber keinen Mechanismus parat. Ruby kann zwar Threads starten, aber ein Thread in einem Webserverthread könnte am Ende der Anfrage abgewürgt werden. Beim von mir genutzten Webserver puma würde genau das passieren.

Es gibt natürlich Lösungen, Delayed::Job zum Beispiel. Aber das kommuniziert über die Datenbank, braucht seine eigene Tabelle, und sah sehr Rails-lastig aus. Sucker Punch klang erst perfekt, weil es innerhalb des Sinatra-Prozesses läuft. Aber es braucht angepasste Worker-Objekte, und die Objektstruktur wollte ich nicht anpassen.

Meine einfache Lösung basiert auf der Idee eines Worker-Threads im Sinatra-Prozess. Nur dass statt eines einzelnen Threads ein Threadpool aus dem Gem ruby-thread bereitgehalten wird, dem der Code übergeben werden kann. Das funktioniert so:

require 'sinatra/base'
require 'thread/pool'

class Threadexample < Sinatra::Application
    class << self; attr_accessor :pool end    # thread pool as class variable
    @pool = Thread.pool(2)
    
    get '/'
        DoingSomething.new()
    end
end

class DoingSomething
    def initialize()
        Threadexample::pool.process {    # send the normal code to the threadpool
            puts "send trackback now in the background, while the pageload is already finished"
        }
    end
end

Der Threadpool läuft dauerhaft im Sinatra-Prozess, beim modularen Stil gespeichert als Klassenvariable. Der Code im von Sinatra aufgerufenen Objekt wird an den Pool gesendet. Das schöne an der Lösung ist, dass der Code und die Objektstruktur nicht verändert werden müssen. Und dass die Threads im Pool nacheinander bearbeitet werden, bestehende Threads werden nicht einfach überschrieben.

Ich bin nicht sicher, ob Metaprogrammierung die richtige Bezeichnung ist - vor allem, weil es etwas hochtrabend klingt. Es geht um ein simples Problem: Man hat einen String und will eine Funktion oder eine Variable aufrufen, die so heißt wie der Inhalt des Strings.

Also: Ich habe "auto" in der Variable id und will A.autoBahn aufrufen. Das passiert in der Praxis öfter mal, wenn in bestimmten Teilen des Codes Variablen mit einer id konstruiert werden, z.B. autoBahn, fahrradBahn, eisenBahn…

class A
    attr_accessor :autoBahn
    def initialize
        self.autoBahn = "A44"
    end
end

a = A.new
id = "auto"

puts a.send(auto + "Bahn")   # => A44

Ruby kennt auch eval, was sich genau so verhält wie erwartet: Es führt den Inhalt eines String als Programmcode aus. Nichts für von Nutzern wählbare Variablen, mächtiger als nur zum Variablen oder Methoden aufrufen, aber auch dafür kann man es nutzen.

eval "A.#{id}Bahn"   # => A44

Variablen dynamisch zu lesen ist super. Es fehlt nur noch, sie ebenso schreiben zu können. Mit instance_variable_set geht das auch. Ich bin anfangs nur darüber gestolpert, dass das erste Zeichen des Namens ein @ sein muss.

A.instance_variable_set('@Landstrasse', "B44")

Vielleicht ist es meistens nicht toll, so etwas benutzen zu müssen. Aber richtig eingesetzt kann es sehr viele Zeilen voller Wiederholungen auf einige wenige komprimieren.

Ich muss immer mal wieder Statistik anwenden, meist ohne dann wirklich Zeit dafür zu haben. R oder Julia ist mir fremd, daher griff ich meist auf handgeschriebene Bash-Skripts zurück und machte die schwierigeren Sachen, wie die Faktor- oder Signifikanzanalyse, mit externen Tools. Was eben gerade da ist.

Diesmal bin ich über statsample gestolpert. Das gem implementiert die relevanten Statistikfunktionen. Ich benutzte diesmal sowieso Ruby, da passte das gut in meine Datenverarbeitungsskripte. Und in meinen Augen hat es sich bewährt.

Zwei Beispiele: Ich habe in einer SQLite-Datenbank eine Sammlung von Kommentaren mit ihren Upvotes, und die Kommentare kann ich in zwei Gruppen unterteilen. Ich will wissen, ob die Verteilung der Upvotes zwischen den Gruppen sich signifikant unterscheidet, und wähle dafür einen t-Test. Das geht so:

require 'sqlite3'
require 'statsample'
include Statsample::Test

db = SQLite3::Database.new "database.db"

aUpvotes = db.execute("SELECT upvotes FROM comments WHERE group = 'a'";).flatten.to_scale
bUpvotes = db.execute("SELECT upvotes FROM comments WHERE group = 'b'";).flatten.to_scale

t_2=Statsample::Test::T::TwoSamplesIndependent.new(aUpvotes, bUpvotes)
puts t_2.summary

Die Ausgabe enthält dann alle wichtigen Informationen und verrät mir, dass die zweite Stichprobe deutlich kleiner, die Varianz gleich ist und das benötigte Signifikanzniveau p = 0.5522 weit von statistischer Signifikanz weg ist.

= Two Sample T Test
  Mean and standard deviation
+----------+--------+---------+------+
| Variable |  mean  |   sd    |  n   |
+----------+--------+---------+------+
| Vector 1 | 9.1267 | 44.8019 | 3332 |
| Vector 2 | 7.4539 | 59.6217 | 293  |
+----------+--------+---------+------+

  Levene test for equality of variances : F(1, 3623) = 0.4437 , p = 0.5054
  T statistics
+--------------------+--------+----------+----------------+
|        Type        |   t    |    df    | p (both tails) |
+--------------------+--------+----------+----------------+
| Equal variance     | 0.5945 | 3623     | 0.5522         |
| Non equal variance | 0.4687 | 321.6479 | 0.6396         |
+--------------------+--------+----------+----------------+

  Effect size
+-------+--------+
| x1-x2 | 1.6727 |
| d     | 0.2467 |
+-------+--------+

Das zweite Beispiel ist ein chi²-Test um zwischen zwei Stichproben mit Kategorien zu unterscheiden. Ich habe bei der ersten Stichprobe 60 Leute in Kategorie A, 10 in B, 30 in C. Bei der zweiten sind es 60 in A, 25 in B und 15 in C. Signifikanter Unterschied?

m=Matrix[[60, 10, 30], [60, 25, 15]]
x_2=Statsample::Test.chi_square(m)
puts x_2.probability   # => 0.003…

Hier gibt es keine schöne Ausgabe, sondern nur den p-Wert. Der ist mit 0.003 unterhalb einiger typischer Signifikanzniveaus, also ist der Unterschied zwischen den Beobachtungen für p < 0.01 beispielsweise signifikant.

Ich habe ein bisschen das Drumrum erklärt weil dort das Problem des Gems ist: Es fehlt Dokumentation. Klar, es ist nicht die direkte Aufgabe des Gems, dem Nutzer einen Statistikkurs zu geben. Es ist ein Werkzeug, mit dem Leute, die wissen was sie machen müssen, diese Aufgabe durchführen können. Aber selbst wenn man eine vage Ahnung hat findet man zu wenig darüber, wie man die Funktionen aufzurufen hat.

Meinen Feedreader feedtragón nutze ich praktisch jeden Tag. Ich bin soweit zufrieden, aber nach der Eingewöhnungsphase fiel mir auf, dass er etwas langsam war. Gemessen und uff: Die längste Wartezeit kam durchs Warten auf eine Antwort vom Server. Kein gutes Zeichen. In diesem Artikel werde ich beschreiben, wie ich das Problem anging und dabei diese Verbesserung produzierte:

Die Wartezeit wurde reduziert auf ein 84stel, von 2,8 Sekunden am Anfang auf ~33ms.

Schritt 1: Index setzen

Jedes mal, wenn eine Seite geladen wird, holt feedtragón eine Liste aller abonnierten Feeds vom Server, und prüft dann jeden Feed auf ungelesene Einträge. Dafür muss er die Einträge aus der Datenbank holen, das macht er mit diesem Query:

SELECT url, title, content, id FROM entries WHERE feed = ? AND read = 0 AND id > ? LIMIT 10;

Er beschränkt sich also auf 10 Einträge mit einer höheren ID als die Start-ID, so funktioniert das Endless-Scrolling, aber das ist hier nicht weiter wichtig. Wichtig ist der Rest des WHERE-Statemends: feed = ? AND read = 0. Da werden also zwei Spalten abgefragt. Und insgesamt dauerte das alles 2,8 Sekunden - also nicht nur dieser Query, sondern alle zusammen.

Ich bin kein Datenbankexperte, aber ich vermutete, dass diese Abfrage schneller funktionieren könnte. Das ist eine SQLite-Datenbank, dort kann man das mit EXPLAIN QUERY PLAN prüfen:

sqlite> EXPLAIN QUERY PLAN SELECT url, title, content, id FROM entries WHERE feed = ? AND read = 0 AND id > ? LIMIT 10;
0|0|0|SEARCH TABLE entries USING INTEGER PRIMARY KEY (rowid>?)

Was heißt das jetzt? Ich musste es nachgucken. Dass er hier nur mit dem Primary Key sucht heißt, dass er für read und feed keine andere Möglichkeit hat als manuell zu suchen. Also muss dafür je ein Index her:

sqlite> CREATE INDEX entries_read_idx ON entries(read);
sqlite> CREATE INDEX entries_feed_idx ON entries(feed);
sqlite> EXPLAIN QUERY PLAN SELECT url, title, content, id FROM entries WHERE feed = ? AND read = 0 AND id > ? LIMIT 10;
0|0|0|SEARCH TABLE entries USING INDEX entries_feed_idx (feed=? AND rowid>?)

feedtragón gestartet, den Browser aufgemacht, in die Netzwerkanalyse geschaut und mich gefreut: Die Wartezeit auf den Server schrumpfte von 2,8s auf 0,5s. Damit war die Sache für mich erstmal abgehakt und feedtragón ausreichend optimiert.

Schritt 2: Join (Arbeitsvermeidung)

Später kam mir dann der Gedanke, dass es besser gehen müsste. Denn das Vorgehen, das ich oben beschrieb - alle Feeds holen, ans Template schicken, dort deren Einträge holen, dann nur die Feeds mit ungelesenen Einträgen anzeigen - ist keineswegs effizient. Es folgt aus einer strikten Einhaltung der für dsnblog skizzierten Architekturprinzipen: Objekte ohne Controller, die für ihre Daten zuständig sind. Das ist toll zu schreiben, besonders das Datenbanklayer bleibt einfach beherrschbar, aber Dee erwähnte damals das möglicherweise kostspielige Befüllen der Daten. Und die Einträge des Feeds aus der Datenbank zu holen ist kostspielig.

Vorher holte er also alle Feeds aus der Datenbank:

SELECT url, id, name FROM feeds;

und filterte dann im Template die Feeds aus, die keine neuen Einträge haben:

feeds.each do |feed| 
    erb :feedlink, :locals => {:feed => feed, :current_feed_id => current_feed_id} if ! feed.entries.nil? && feed.entries.size > 0
end

wobei feed.entries() wieder die Datenbank aufruft, mit dem im ersten Schritt optimierten Query.

Stattdessen könnte man auch direkt nur die Feeds übergeben, die ungelesen Einträge haben. Dafür muss nur die Feed- und die Eintragstabelle gejoint werden:

SELECT DISTINCT feeds.url, feeds.id, feeds.name FROM feeds JOIN entries ON (entries.feed = feeds.id) WHERE entries.read = 0;

Das Filtern kann dann entfallen. Und so schrumpften die 0,5s noch einmal, auf diesmal 0,033s.

Das ist vielleicht etwas spezifisch. Der Kern hier ist: Unnötige Datenbankabfragen durch einen geschickten Join zu vermeiden ist eine gute Idee, und es auch wert wenn es etwas gegen die vorhandene Struktur geht.

Schlusswort

Natürlich sind das keine konstanten Werte. Wären mehr Feeds und mehr Einträge in der Datenbank bräuchte alles länger. Der Server hat wahrscheinlich eine langsamere Platte als mein Rechner mit seiner SSD. Außerdem ist nun nur die Wartezeit auf den Server minimiert, er muss immer noch danach etwaige Bilder herunterladen, außerdem kommt die Transportzeit zum Server dazu.

Trotzdem: Der Unterschied ist auch auf dem Server da. Statt "Klick, Warten, Rendern, da" ist es nun "Klick, Rendern, da" - den Schritt auf realistisch gesehen etwa unter eine Sekunde Ladezeit, von vorher über 3, spürt man deutlich.

Anlass war natürlich mein momentanes Projekt, ich brauchte einen Weg, vom Server aus den Browser über Updates der Feeds zu benachrichtigen. Dafür soll der Browser nicht alle paar Sekunden beim Server anfragen, der Server soll von sich aus den Browser benachrichtigen. Und genau das geht mit Websockets.

Auf Javascriptseite wird ein neuer Websocket erstellt, dann kann über seine Funktionen auf die Nachrichten vom Server reagiert werden:

var socket = new WebSocket('ws://' + location.host + '/updated' );

socket.onopen = function() {
    socket.send('erste nachricht an den server');
}

socket.onmessage = function(msg){
    console.log(msg);
}

Ein reales Beispiel findet sich hier.

Auf der Serverseite läuft bei mir Ruby mit Sinatra, und der Rack-Server ist puma. Ich habe nach einer Kollision damit in einem anderen Projekt gerne etwas Distanz zu EventMachine. Und es gibt auch ein passendes Gem, mit dem selbst bei diesem etwas seltenem Setup Websockets schnell funktionieren: sinatra-hijacker. Mein Beispielcode:

require 'sinatra'
require 'sinatra/hijacker'
register Sinatra::Hijacker

websockets = []

websocket '/updated' do
    websockets << ws
    ws.onmessage  do |msg| 
        puts msg
    end
    ws.onclose do
        websockets.delete(ws)
    end
    "Done"
end

Ein reales Beispiel findet sich hier.

Funktionierte am Ende erstaunlich gut. Ich muss mich allerdings noch an dieses neue Werkzeug gewöhnen. So übertrage ich bis jetzt damit nur Benachrichtigungen und hole die neuen Elemente dann per Ajax, das ist eigentlich nicht nötig, es ginge sicher auch direkt. Und ich brauchte ein bisschen um zu realisieren, dass es nicht mehr als ein Websocket pro Verbindung braucht, wenn man verschiedene Events per JSON unterscheidbar macht.

Vor einiger Zeit ging Final Term durch die Newsseiten. Ein moderner Terminalermulator, der mit modernen Features und Aussehen punkten will, aber noch Alpha-Software ist. Durch Zufall an das Projekt erinnert, prüfte ich vor drei Tagen den aktuellen Stand.

Neu ist, dass sie auf Bountysource Preise fürs Bugfixen verteilen. Sehr sympathisch, der Hauptentwickler verzichtet auf Spenden, das soll nur neuen Entwicklern zugute kommen, die das Projekt brauche. Eine der Bugs ist mir ins Auge gefallen: Segfaults, GTK errors and hangs with NestingContainer. Absurde Abstürze, damit habe ich seit Simdock ein bisschen Erfahrung, daher schien mir der Versuch eines Bugfixes wie ein guter Weg, etwas neues zu lernen.

Tatsächlich ist Final Term derzeit komplett instabil. Einen Tab zu schließen führt zu Absturz oder Freeze. Interessant, denn der in Vala geschriebene Code ist nicht wirklich hässlich, höchstens fehlen ein paar Kommentare und ausgerechnet der NestingContainer ist teilweise eher verkompliziert als elegant.

Etwas Debugging später hatte ich eine Absturzursache gefixt: Das Programm sendet ein kill-Signal an den pty-Prozess und wartete danach nicht. Ich bin mir nicht völlig sicher, warum das zu Problemen führt, ich hatte nur eine Ahnung. Tatsächlich hilft ein Timeout, seitdem können zumindest auf meinem System Tabs ohne Abstürze geschlossen werden.

Freudig sendete ich den Pull-Request, nur um darauf hingewiesen zu werden, dass dies noch lange nicht alles sei: Ein Strg+D führe regelmäßig ebenfalls zu Abstürzen und Freezes, sogar noch häufiger. Und das stimmt, auch bei mir, auch mit meinem Fix. Eine Menge Debugging später fand ich heraus, wo genau er einfriert: Beim Entfernen des Tabs aus dem GTK-Notebook per

notebook.remove_page(notebook.page_num(child));

Er scheint dort aus irgendeinem Grund in eine Race-Condition(?) zu laufen und hängt sich in einem Mutex-Lock fest:

#0  0xb7fdd424 in __kernel_vsyscall ()
#1  0xb7012d4b in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
#2  0xb72648ec in __pthread_cond_wait (cond=0x80db7d0, mutex=0x80da6fc)
    at forward.c:149
#3  0xb6a70607 in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1
#4  0xb6a70a88 in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1
#5  0xb6a70b2a in xcb_writev () from /usr/lib/i386-linux-gnu/libxcb.so.1
#6  0xb6f0a130 in _XSend () from /usr/lib/i386-linux-gnu/libX11.so.6
#7  0xb6f0a70a in _XReply () from /usr/lib/i386-linux-gnu/libX11.so.6
#8  0xb6f05f5b in XSync () from /usr/lib/i386-linux-gnu/libX11.so.6
#9  0xb774df26 in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0
#10 0xb772a7ae in gdk_display_sync ()
   from /usr/lib/i386-linux-gnu/libgdk-3.so.0

Hat jemand den Fehler schonmal gesehen? Ich versuche mich derzeit an Workarounds.

Ein Wort hier zu Vala: Das erscheint mir ziemlich kompliziert. Es ist nett, objektorientiert schreiben zu können, aber wenn am Ende doch auf Speicherverwaltung geschaut werden muss und die zusätzliche Abstraktion vom C-Code eine Hürde beim Bugfixen ist, erscheint mir das ziemlich sinnlos. Ich sehe nicht, wo finalterm einen Fehler gemacht hat, es sollte durch die Verwendung moderner Frameworks nicht so instabil sein, wie es derzeit ist. Vielleicht war GTK/Clutter/Mx/Vala einfach die falsche Wahl.

Finalterm selbst macht einen guten Eindruck. Frühe Alpha-Software zwar, und ich weiß nicht, ob der Ansatz mit seinen Animationen und Menüs etwas für mich ist. Aber ich würde darauf wetten, dass es einen bleibenden Platz in der Linuxwelt bekommen wird, falls es bald genug etwas stabiler und kompletter wird.

Edit: Inzwischen hab ich den Bug meiner Meinung nach gelöst.