Eine schöner Ansatz, der zumindest einen großen Teil dieses Gebietes abdeckt, bietet Adaptive Images. Die Software habe ich nicht getestet und sie dürfte für viele ohnehin nicht nutzbar sein, da sie PHP und einen Apache Webserver erfordert. Die Idee ist aber gut und einfach umsetzbar.

Client: Cookie mit Bildschirmdimensionen setzen

Wer generell gegen Cookies und Javascript ist kann jetzt aufhören zu lesen. Via JS setzen wir im Head ein(en?) Cookie mittels JS, in dem die maximale Bildschirmgröße gespeichert wird:

document.cookie = 
    'resolution=' + Math.max(screen.width,screen.height) + '; path=/';

Da wir das Maximum wählen, können wir sicher sein, dass Bilder auch nach dem Kippen des Gerätes ins Querformat noch ordentlich aussehen.

Das war es auch schon. Der Browser sendet ab sofort bei jedem Aufruf die Auflösung mit. Auch bei Bildern, ob aus Img-Element oder CSS.

Server: Bildanfrage abfangen, Bild in neuer Größe erzeugen und umleiten

Serverseitig muss die Anfrage nun auf irgend ein Serverprogramm umgeleitet werden. Dieses kennt den Pfad zum Bild und die gewünschte Dimension. Es nimmt also das Bild, skaliert es herunter und speichert es. Nun schickt es dem Client eine Weiterleitung auf die optimierte Datei. Diese kann sogar permanent sein, da sich die Dimensionen eines Browsers in aller Regel nicht ändern.

Die Skalierung des Bildes ist nur beim ersten mal für eine bestimmte Größe nötig. Später wird auf die bereits erzeugten Varianten verwiesen.

Nur ein Ansatz

Dies ist natürlich nur ein Ansatz. Welche Bilder skaliert werden sollen und wodurch diese vom Server erkannt werden muss für jede Website geklärt werden. Zudem sollte man sich Normgrößen überlegen, damit nicht unzählige Varianten ein und der selben Datei wegen zwei Pixeln Unterschied auf der Platte landen.

Gegenüber verbreiteten Ansätzen gibt es einen zentralen Vorteil. Browser müssen nicht erst alle kleinen Bilder laden um im Nachhinein via Javascript zu erfahren, dass sie diese durch für ihre Größe angemessene Varianten ersetzen sollen. Hier lädt der Client ein Bild und der Server liefert ihm was er braucht.

Der Ansatz funktioniert nicht ohne Javascript und Cookies. Sind diese deaktiviert oder nicht vorhanden, erhält der Browser eine Standardversion des jeweiligen Bildes. Die Website funktioniert somit dennoch wie erwartet, nur die Optimierung fehlt.

Die Farbwahl für Diagramme ist eine Wissenschaft für sich…

Data-Warehouse: Datenintegration und -separation

Ein Data-Warehouse ist eine Datenbank, die zwei grundlegende Ziele verfolgt:

1. Datenintegration aus heterogenen Quellen
2. Separation der Daten; das Data-Warehouse hat keinen Einfluss auf die operativen Daten

Datenintegration

Beide Aspekte sind für Website-Statistiken höchst relevant. Viele Web-Server stellen mehrere Websites mit unterschiedlichen Technologien bereit. Selbst wenn nicht, möchte ich als Admin die Möglichkeit haben, meinen Apache gegen ein Nginx oder mein Typo 3 gegen ein Wordpress auszutauschen. Heterogene Quellen, in welchen die Daten auflaufen, sind somit zumindest potentiell immer gegeben. Ein weiterer Vorteil: Bin ich auf kein festes Format angewiesen, kann ich auch immer die nativen Mechanismen der verwendeten Software nutzen. Apache, Nginx und Co. loggen ohnehin jeden Besucher mit, eine zusätzliche Erfassung der Daten (wie zum Beispiel durch Piwik) ist oft gar nicht nötig. Ein Data-Warehouse kann diese selbstständig integrieren.

Datenseparation

Auch Punkt 2 ist wie fürs Web gemacht: Statistiken sind sicher wichtig, aber nie so, dass sie das eigentliche Webangebot behindern dürften. Ist der Server bereits ausgelastet, so kann ein Aufruf der Statistiken mit unzähligen Leseoperationen und Berechnungen zum großen Problem werden. Spätestes wenn der Speicher voll ist gehen bei kleinen Projekten wie diesem Blog die Lichter aus. Das Prinzip der Datenseparation bietet hier Abhilfe: Die Statistiken werden vollständig von den operativen Daten getrennt. Das Data-Warehouse kann bei Bedarf auf einem anderen Server liegen.

Hierfür müssen die operativen Daten zwar ebenfalls gelesen werden, dies kann in hohen Lastphasen aber einfach unterbunden werden. Der Webserver kann sich auf seinen eigentlichen Job konzentrieren und auch der Statistikaufrufer kriegt schnell und optimiert seine Zahlen. Lediglich Letzterer hat hierbei den Nachteil, dass die Daten nicht mehr ganz in Echtzeit bereitstehen – was wohl zu verkraften sein dürfte. Das Internet ist zwar schnelllebig, die Zugriffe von vor fünf Minuten sind für die meisten aber aktuell genug.

Nachteile

Der Data-Warehouse-Ansatz für die Website-Zugriffsanalyse birgt kaum Probleme. Zwei drängen sich zunächst auf:

• Keine Echtzeitdaten
• Erhöhter Speicherverbrauch durch Datenduplizierung

In meinen Augen sind beide Nachteile unkritisch. Die Aktualitätsspanne zwischen Echtzeit- und Data-Warehouse-Daten lässt sich je nach Kapazität beliebig verkleinern. Je öfter die Daten integriert werden, desto weniger Neuerungen sind zu verarbeiten. Selbst minütliche Syncs sind realistisch, wenn man seine Zugriffsspitzen im Blick hat und nach Bedarf das Intervall anpasst.

Der vermehrte Speicherverbrauch war selbst zu Zeiten der Festplattenkrise kein Problem. Wer jeden Tag gigabyteweise Zugriffsdaten wegschreibt hat sicher andere Sorgen als zehn Festplatten im Jahr…

Skalierbarkeit und Datenstrukturkonzeption

Das Konzept Data-Warehouse ist simpel und überzeugend. Für Website-Statistiken überzeugt vor allem die Skalierbarkeit: Vom kleinen PHP-Webspace mit My-SQL-Datenbank kann eine gut konzipierte Datensammlung mitwachsen und auf beliebig große und verteilte Systeme migriert werden.

Zudem bietet dieses Forschungsfeld interessante Ansätze, wie man Daten effizient an das Anwendungsfeld angepasst strukturiert. OLAP-Cubes und Sternschemas für relationale Datenbanken sind wichtige Stichwörter, die jedoch einen eigenen Artikel rechtfertigen.

Gerade der letzte Punkt wird oft ignoriert, kommt aber schneller als man denkt: Gerade bei einer Entwicklung wie bei Ruby entsteht das Bedürfnis, für die neue Projektversion auch die neue Ruby-Version zu nutzen. Es empfiehlt sich daher, diesen Punkt von Anfang an zu beachten und Ruby auf eine eigene Versionverwaltung zu stellen: RVM. Der Ruby Version Manager kann automatisch bestimmte Ruby-Versionen installieren und parallel unterschiedliche Versionen laufen lassen.

Installation unter Ubuntu 12.04, 12.10 und 13.04

Die Installation macht weitgehend alles selbst, nur mit den Abhängigkeiten hatte ich etwas zu kämpfen. Für 12.04 und 12.10 bin ich auf die folgenden gekommen, damit alles reibungslos funktioniert. Für 13.04 konnte ich das noch nicht testen, die Liste sollte aber auch hier funktionieren oder zumindest ein guter Ansatzpunkt sein:

Abängigkeiten

sudo apt-get install curl git-core patch build-essential bison \
  zlib1g-dev libssl-dev libxml2-dev \
  libxml2-dev sqlite3 libsqlite3-dev autotools-dev \
  libxslt1-dev libyaml-0-2 autoconf automake libreadline6-dev \
  libyaml-dev libtool libgdbm-dev libncurses5-dev pkg-config \
  libffi-dev libpq-dev libpq-dev

Die Liste ist eine Erweiterung von einem Artikel von Ruby auf Schienen.

Installation im Userspace

Der Rest läuft wie von selbst. Im Userspace installiert man das RVM über ein Skript (Administratoren und andere Besorgte gucken natürlich vorher, was das Skript macht, bevor sie es ausführen):

curl -L https://get.rvm.io | bash -s stable

Nach einem Neuladen des Terminals sollte RVM bereit sein und alle verfügbaren Versionen auflisten:

source ~/.bashrc
rvm list known

Erste Schritte mit NVM

Ruby 1.9.3 installieren

rvm install 1.9.3

1.9.3 in der aktuellen Shell aktivieren

Sind mehrere Versionen installiert, lässt sich mit rvm use eine bestimmte für das aktuelle Terminal aktivieren:

rvm use 1.9.3
ruby --version
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

Rails 3.2

Ab dieser Stelle lässt sich Ruby wie gewohnt über mit gem konfigurieren, so dass die Rails-Installation keine Überraschungen birgt:

gem install rails --version '~> 3.2.0'

          17,98 Euro
*            12
=        215,76 Euro
   
  50 000 000,00 Euro
/        215,76 Euro
=    231 738,97

     231 738,97
/            60
=      3 862,32

Über 3000 Menschen zahlen ihr ganzes Leben lang Gebühren, um in der Halbzeitpause zehn Minuten Heute-Journal statt Werbung zu sehen. Das wird man wohl gemeint haben, als man den öffentlich-rechtlichen Rundfunk für die mediale „Grundversorgung“ erfunden hat.

<<<<<<< HEAD
customer.setPriority(42);
=======
client.setPriority(32);
>>>>>>> master

Customer oder Client? 42 oder 32? Die richtige Lösung muss aus dem umliegenden Code abgeleitet werden. Hier kann es wie so oft helfen, den letzten gemeinsamen Stand der Versionen zu sehen.

git config --global merge.conflictstyle diff3

Ab sofort erscheint bei Konflikten mittig die ursprüngliche Variante. Durch diese wird ohne weiteres Code-Studium deutlich, welche Änderungen jeweils gemacht wurden und übernommen werden sollten:

<<<<<<< HEAD
customer.setPriority(42);
||||||| merged common ancestors
client.setPriority(42);
=======
client.setPriority(32);
>>>>>>> master

Im Beispiel wurde client in customer umbenannt und die Priorität auf 32 reduziert. Die sinnvolle Lösung ist demnach:

customer.setPriority(32);

Die ursprüngliche Darstellung lässt sich durch den Wert merge wiederherstellen:

git config --global merge.conflictstyle merge

find . -name '*.rb' -print0 | xargs -0 wc -l | sort -n

Das funktioniert natürlich mit jeder beliebigen Sprache. Einfach die Dateiendung im Find-Befehl anpassen.

Da drängt sich doch die Frage auf, ob das nicht eine subtile Methode zur Aufspürung von Steuerhinterziehern ist, die ihre Tierchen nicht ordnungsgemäß angemeldet haben. Ein paar Leckerlis in die Tasche und der Schwarzbello wird sich schon verraten…

Transaktionen in PostgreSQL

begin;
alter table mytable rename column id to name;
\d mytable

         Table "public.mytable"
   Column   |   Type     |   Modifiers   
------------+------------+--------------
 name       | bigint     | not null

rollback;
\d

         Table "public.mytable"
   Column   |   Type     |   Modifiers   
------------+------------+--------------
 id         | bigint     | not null

Sind die vorgenommenen Änderungen korrekt, können sie mit commit; übernommen werden. Der offizielle SQL-Befehl zum Starten einer Transaktion ist start transaction;. Allerdings unterstützen alle mir bekannten Datenbanken die etwas handlichere Form begin;.

Verschachtelte Transaktionen: Savepoints

Ist der Test komplexer, so dass man Transaktionen schachteln möchte, kann man sogenannte Savepoints verwenden.

begin;
-- Änderung 1
savepoint sp1;
-- Änderung 2a
rollback to savepoint sp1; -- 2a zurücknehmen
-- Änderung 2b
rollback; -- 2b und 1 zurücknehmen

Transaktionen in MySQL

Die PostgreSQL-Beispiele werden auch von MySQL unterstützt.

Umschalter im Benachrichtigungsmenü

Sicher ist es nicht optimal, den Benachrichtigungsbereich zu missbrauchen. Dennoch stufe ich den praktischen Nutzen hier höher als meinen Sinn für Ordnung ein.

Dennoch wäre es schön, wenn Google so etwas nativ im Schnellauswahlmenü hinter dem Knopf oben rechts im Benachrichtigungsbereich integrieren könnte…